Messages in this thread | | | Date | Thu, 3 Nov 2005 01:18:00 +0530 | From | Dipankar Sarma <> | Subject | Re: bad page state under possibly oom situation |
| |
On Wed, Nov 02, 2005 at 04:33:21PM +0000, Hugh Dickins wrote: > On Wed, 2 Nov 2005, Dipankar Sarma wrote: > > > > Bad page state at prep_new_page (in process 'rename14', page ffff810008002aa8) > > flags:0x4000000000000090 mapping:0000000000000000 mapcount:0 count:0 > > Backtrace: > > > > (I don't know that it makes any difference, but was this particular report > from 2.6.9-rc2 or from 2.6.14 or from something else? In both 2.6.9 and > 2.6.14, flags 0x90 mean PG_slab|PG_dirty.) > > > Recently, I tested this with 2.6.14 and it worked. I then tried > > setting rcupdate.maxbatch=10 as it was before 2.6.14 and the bad > > page state problem happened again. Looks like it happens only under > > memory pressure and likely have something to do with slab. > > I am wondering if that rings a bell with anyone. Manfred ? > > > I did look back at that when we discussed your Bad page state before, > and didn't find anything wrong. But now you're reproducing it again, > it would be good to rule it in or out. > > Could you run the rename14 test on whatever kernel suits you, but > built with mm/rmap.c omitting the SLAB_DESTROY_BY_RCU flag to > kmem_cache_create? There's then a tiny chance that rmap will try > to access a freed anon_vma struct, I'm not sure how that would > behave offhand; but that chance should be a lot tinier than what > you're finding quite easy to reproduce.
I am really not comfortable with the SLAB_DESTROY_BY_RCU thing. I am not familiar with rmap code, so I could be wrong but it isn't clear to me why you are protecting only the slab and not the anon_vma slab objects. How do you ensure that the anon_vma objects don't get re-used ? If they do, then how do you prevent freeing an in-use anon_vma ? It seems that the critical sections are not clearly identified here.
> > If you don't get the Bad page state with that kernel, then it'll > be worth scrutinizing the SLAB_DESTROY_BY_RCU path in mm/slab.c.
I tried commenting out SLAB_DESTROY_BY_RCU for anon_vma caache, but I still hit the problem. So, that may not be it. I guess I can look at the bad page and see if I can extract some information from there.
Thanks Dipankar - 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/
| |