On Tue 24-06-08 20:39:18, Michael Buesch wrote:
quoted text
> On Tuesday 24 June 2008 19:28:12 Jan Kara wrote:
> > > On Mon, 23 Jun 2008 00:28:20 +0200 Michael Buesch <mb@bu3sch.de> wrote:
> > > 
> > > > On Monday 23 June 2008 00:05:51 Michael Buesch wrote:
> > > > > > Note: r9 and r3 are both NULL pointers. r3 is the value returned from alloc_page_buffers.
> > > > > > R9 is a copy of that, which gets accessed.
> > > > > 
> > > > > Hm, yeah. I looked at that code already, but I can't see how it could return
> > > > > a NULL pointer.
> > > > 
> > > > Well, actually, it can return a NULL pointer.
> > > > 
> > > >  928         head = NULL;
> > > >  929         offset = PAGE_SIZE;
> > > >  930         while ((offset -= size) >= 0) {
> > > > ...
> > > >  949         }
> > > >  950         return head;
> > > > 
> > > > So if size, which is a passed in as parameter, is > PAGE_SIZE it will return NULL.
> > > > 
> > > > The size parameter is calculated by doing
> > > > blocksize = 1 << inode->i_blkbits;
> > > > in an earlier function in the callchain.
> > > 
> > > Yes, that's a more likely scenario.  isofs has a history of passing
> > > garbage into the VFS.
> > > 
> > > > So, well. I dunno what i_blkbits is. There's no docs in struct inode.
> > > 
> > > It's log2 of the filesystem blocksize.  It'd be interesting to work out
> > > what value isofs is setting it to, and why.
> >   Well, yes, that looks as a reason at the first sight. But what I don't
> > get is, how can isofs possibly set such a blocksize when it uses
> > sb_set_blocksize() which checks whether blocksize isn't larger than page
> > size... So it must be something less obvious.
> >   bd_set_size() can possibly set blocksize larger than PAGE_SIZE and
> > it's called from do_open() but it uses bdev_hardsect_size() and that
> > shouldn't be larger than PAGE_SIZE either (at least drivers seem to take
> > care of this).
> >   I have seen one more report of this Oops for SLES10 kernel and also in that
> > case an IO error happened so probably that is a trigger... But so far I
> > don't get the details.
> 
> Yeah the IO error is the trigger.
> I noticed that it had obvious troubles accessing the DVD that was in the drive.
> It sweeped over it for several seconds, then hung the system for 2 or 3 seconds
> and then oopsed. But after that everything continued to work as usual.
> (Except kded of course)
  Hmm, by "accessing" do you mean that you've mounted the burned DVD and when
browsing it the IO error and the oops occured or that IO error happened
when burning? It is important because in the first case i_blkbits would be
taken from some ISOFS inode desribing some file while in the second case
i_blkbits are from the inode of the device...

									Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/