On Sun, 8 Jan 2006, Ryan Richter wrote:
>
> Kernel BUG at mm/swap.c:49
Well, it sure triggered.
> Process taper (pid: 4501, threadinfo ffff8101453d8000, task ffff81017d0143c0)
> Call Trace:<ffffffff8028c614>{sgl_unmap_user_pages+124}
> <ffffffff8028834d>{release_buffering+27}
and it's that same sgl_unmap_user_pages() that keeps on triggering it.
Which was not what I was hoping for. I was hoping we'd see somebody _else_
decrementing the page count below the map count, and get a new clue.
However, the page flags you show later on (0x1c) ended up making me take
notice of something. That's "dirty", and maybe it's from
if (dirtied)
SetPageDirty(page);
in that same sgl_unmap_user_pages() routine.. And it strikes me that that
is bogus.
Code like that should use "set_page_dirty()", which does the appropriate
callbacks to the filesystem for that page. I wonder if the bug is simply
because the ST code just sets the dirty bit without telling anybody else
about it...
Gaah. Hugh, Nick?
Linus
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
