lkml.org 
[lkml]   [2003]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Oops] i386 mm/slab.c (cache_flusharray)
On Thu, Dec 04, 2003 at 11:09:29AM -0800, Linus Torvalds wrote:
>
>
> On Thu, 4 Dec 2003, Linus Torvalds wrote:
> > > ---
> > > kernel BUG at include/linux/mm.h:267!
> >
> > YEAH! That's "put_page_testzero()", and either the BUG_ON() or the
> > atomic_dec_and_test() noticing bad things.
>
> Oh, damn. Looking closer, it appears that it's actually XFS being a bit
> too intimate with slab knowledge: the code does
>
> if (pb->pb_pages) {
> /* release the pages in the address list */
> if (pb->pb_pages[0] &&
> PageSlab(pb->pb_pages[0])) {
> /*
> * This came from the slab
> * allocator free it as such
> */
> kfree(pb->pb_addr);
> } else {
> _pagebuf_freepages(pb);
> }
>
> and that code gets really confused by the fact that I'm bypassing the slab
> logic (and thus the PageSlab flag never gets set).
>
> So the oops it found was apparently triggered by the debugging changes,
> not necessarily by a real bug.
>
> Ugh, that XFS code is _broken_. Instead of keeping track of how it got the
> memory, it totally forgets where the memory came from, and then it later
> asks "oh, btw, how the hell did I allocate this?".

Yeah, thats pretty silly stuff - and should be fairly easy to
fix by using a pagebuf flag to differentiate the two. Will do.

thanks.

--
Nathan
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:59    [W:0.053 / U:0.740 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site