On Wed, 03 Sep 2008 19:29:28 +0200 Tejun Heo <tj@xxxxxxxxxx> wrote: > Andrew Morton wrote: > > On Wed, 03 Sep 2008 18:27:12 +0200 Tejun Heo <tj@xxxxxxxxxx> 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. I must have screwed up my kernel versions. next-20080903 is OK. -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
