Re: 2.6.15-mm2

[Jesper Juhl <jesper.juhl@gmail.com>]

On 1/9/06, Hugh Dickins <hugh@veritas.com> wrote:
> On Mon, 9 Jan 2006, Jesper Juhl wrote:
> > Ok, with that patch the page, flags, mapping, mapcount & count
> > information prints again.
>
> Good, thanks.
>
> > I get the exact same backtrace as before though, but a slightly
> > different hexdump :
>
> (I find -mm's hexdump addition really irritating.  Perhaps it could
> be helpful if properly formatted, but not that dump of bytes.)
>
> > Bad page state in process 'kded'
> > page:c1e75400 flags:0x00000000 mapping:00000000 mapcount:1 count:0
> > Trying to fix it up, but a reboot is needed
> > Backtrace:
> > [<c0103e77>] dump_stack+0x17/0x20
> > [<c0148999>] bad_page+0x69/0x160
> > [<c0148e92>] __free_pages_ok+0xa2/0x120
> > [<c0149c7f>] __free_pages+0x2f/0x60
> > [<c02acb63>] sg_page_free+0x23/0x30
> > [<c02abdb3>] sg_remove_scat+0x63/0xe0
> ....
>
> Having sent you the patch to restore the KERN_EMERGs, I then took a
> look at drivers/scsi/sg.c, and it looks as if changes have gone into
> 2.6.15-git which might make more urgent a fix we knew would be needed
> in some cases.  Could you try the patch below and let us know if it
> fixes your problems?  Thanks...
>
>
> Remove sg_rb_correct4mmap() and its nasty __put_page()s, which are liable
> to do quite the wrong thing.  Instead allocate pages with __GFP_COMP, then
> high-orders should be safe for exposure to userspace by sg_vma_nopage(),
> without any further manipulations.  Based on original patch by Nick Piggin.
>

Unfortunately that patch doesn't change a thing (except some
addresses, but that's exected) :-(

Here's the crash I just got with that patch applied :

Bad page state in process 'kded'
page:c1e87d00 flags:0x00000000 mapping:00000000 macount:1 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
[<c0103e77>] dump_stack+0x17/0x20
[<c0148999>] bad_page+0x69/0x160
[<c0148e92>] __free_pages_ok+0xa2/0x120
[<c0149c7f>] __free_pages+0x2f/0x60
[<c02aca53>] sg_page_free+0x23/0x30
[<c02abcc3>] sg_remove_scat+0x63/0xe0
[<c02ac711>] __sg_remove_sfp+0x41/0xa0
[<c02ac927>] sg_remove_sfp+0xa7/0x120
[<c02a8b39>] sg_release+0x49/0xc0
[<c0166827>] __fput+0x167/0x1b0
[<c01666ab>] fput+0x3b/0x50
[<c0164efc>] filp_close+0x3c/0x80
[<c0164fa9>] sys_close+0x69/0x90
[<c0103009>] syscall_call+0x7/0xb
Hexdump:
000: ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00
010: d0 7c e8 c1 d0 7c e8 c1 ff ff ff ff 00 00 00 00
020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
040: 00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00
050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html
-
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/