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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
