On Tue, Jan 26, 2016 at 04:36:11PM -0800, David Rientjes wrote:

On Wed, 27 Jan 2016, Joonsoo Kim wrote:

quoted

quoted

I'd agree if CONFIG_DEBUG_PAGEALLOC only did anything when 
debug_pagealloc_enabled() is true, but that doesn't seem to be the case.  
When CONFIG_DEBUG_SLAB is enabled, for instance, CONFIG_DEBUG_PAGEALLOC 
also enables stackinfo storing and poisoning and it's not guarded by 
debug_pagealloc_enabled().

It seems like CONFIG_DEBUG_PAGEALLOC enables debugging functionality 
outside the scope of the debug_pagealloc=on kernel parameter, so 
DEBUG_PAGEALLOC(disabled) actually does mean something.

Hello, David.

I tried to fix CONFIG_DEBUG_SLAB case on 04/16 of following patchset.

http://thread.gmane.org/gmane.linux.kernel.mm/144527

I found that there are more sites to fix but not so many.
We can do it.

For the slab case, sure, this can be fixed, but there is other code that 
uses CONFIG_DEBUG_PAGEALLOC to suggest debugging is always enabled and is 
indifferent to debug_pagealloc_enabled().  I find this in powerpc and 
sparc arch code as well as generic vmalloc code.  

Yes, I also found it.

If we can convert existing users that only check for 
CONFIG_DEBUG_PAGEALLOC to rather check for debug_pagealloc_enabled() and 
agree that it is only enabled for debug_pagealloc=on, then this would seem 
fine.  However, I think we should at least consult with those users before 
removing an artifact from the kernel log that could be useful in debugging 
why a particular BUG() happened.

Yes, at least, non-architecture dependent code (vmalloc, SLAB, SLUB) should
be changed first. If Christian doesn't mind, I will try to fix above 3
things.

Thanks.