lkml.org 
[lkml]   [2008]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Kernel oops (bug) in fs/buffers.c:create_empty_buffers
> On Sun, 6 Jul 2008 13:23:02 -0700 Arjan van de Ven <arjan@infradead.org> wrote:
> > Hi,
> >
> > caught this one on kerneloops.org:
> > http://www.kerneloops.org/searchweek.php?search=create_empty_buffers
> >
> > void create_empty_buffers(struct page *page,
> > unsigned long blocksize, unsigned long b_state)
> > {
> > struct buffer_head *bh, *head, *tail;
> >
> > head = alloc_page_buffers(page, blocksize, 1);
> > bh = head;
> > do {
> > bh->b_state |= b_state;
> > tail = bh;
> > bh = bh->b_this_page;
> > } while (bh);
> >
> >
> > turns out, alloc_page_buffers() can fail and return NULL (for AIO for
> > example)... yet this code blindly dereferences the result, getting a
> > predictable NULL pointer fault.
> >
> > It's not directly clear what to do about... make this function return
> > the failure to the caller?
>
> isofs has a habit of returning impossible block sizes and the
>
> while ((offset -= size) >= 0) {
>
> consequently loops zero times and alloc_page_buffers() returns null.
>
> Someone was having a look at it - maybe Jan?
Yes, I was looking at that. Actually, I've pinpointed the cause of
the Oopses I've seen to a bug in ide-cd driver. It happily sets blocksize
to whatever value the drive reported and some drives have a habit of
reporting bogus values when unreadable medium is inserted.
Jens has actually cooked up a fix for this bug
(http://thread.gmane.org/gmane.linux.kernel/696582) and it fixes the
problem at least for me.

> I assume that the kernloops.org records link back to the original
> report somewhere but I can't find it?

Honza
--
Jan Kara <jack@suse.cz>
SuSE CR Labs


\
 
 \ /
  Last update: 2008-07-10 00:49    [W:0.042 / U:0.920 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site