Messages in this thread | | | Date | Fri, 5 Dec 2003 08:21:10 +1100 | From | Nathan Scott <> | Subject | Re: [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/
| |