Re: bad page state under possibly oom situation

[Dipankar Sarma <dipankar@in.ibm.com>]

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/