Andrew Morton wrote:
> On Wed, 03 Sep 2008 18:27:12 +0200 Tejun Heo <tj@kernel.org> wrote:
> 
>> Andrew Morton wrote:
>>> @@ -674,6 +674,8 @@ static void *disk_seqf_next(struct seq_f
>>>  	struct device *dev;
>>>  
>>>  	(*pos)++;
>>> +	if (seqf->private == NULL)
>>> +		return NULL;
>>>  	dev = class_dev_iter_next(seqf->private);
>>>  	if (dev)
>>>  		return dev_to_disk(dev);
>> Ehh... next can't be called with NULL private.
> 
> My computer disagreed ;)
> 
>>  Where can I take a look
>> at the merged tree?  There have been two separate changes to that area
>> of code.  Ad-hoc behavior fix for 2.6.27 and general clean up scheduled
>> for 2.6.28 and the two use seqf->private for different purposes.  Maybe
>> the two got mixed up?
> 
> It's linux-next-20080903

Hmmm... Can't see how it can happen and can't reproduce it either.
seqf->private is initialized from disk_seqf_start().  If allocation
fails, it returns ERR_PTR(-ENOMEM).  On error return from start, both
seq_file::seq_read and seq_file::traverse() immediately calls ->stop()
and fails, so ->next can't really be called with null ->private.

Just to make sure, I made disk_seqf_start() fail and it works (or
rather fails) as expected.

Argggghh... strange.  Can you please try the attached patch and post
the log?

Thanks.

-- 
tejun