Re: [Lhms-devel] Re: [PATCH 5/8] Fragmentation Avoidance V17: 005_fallback

[Dave Hansen <haveblue@us.ibm.com>]

On Wed, 2005-10-12 at 12:29 -0500, Joel Schopp wrote:
> > In reality, no and it would only happen if a caller had specified both
> > __GFP_USER and __GFP_KERNRCLM in the call to alloc_pages() or friends. It
> > makes *no* sense for someone to do this, but if they did, an oops would be
> > thrown during an interrupt. The alternative is to get rid of this last
> > element and put a BUG_ON() check before the spinlock is taken.
> > 
> > This way, a stupid caller will damage the fragmentation strategy (which is
> > bad). The alternative, the kernel will call BUG() (which is bad). The
> > question is, which is worse?
> > 
> 
> If in the future we hypothetically have code that damages the fragmentation 
> strategy we want to find it sooner rather than never.  I'd rather some kernels 
> BUG() than we have bugs which go unnoticed.

It isn't a bug.  It's a normal
let-the-stupid-user-shoot-themselves-in-the-foot situation.  Let's
explicitly document the fact that you can't pass both flags, then maybe
add a WARN_ON() or another printk.  Or, we just fail the allocation.  

Failing the allocation seems like the simplest and most effective
solution.  A developer will run into it when they're developing, it
won't be killing off processes or locking things up like a BUG(), and it
doesn't ruin any of the fragmentation strategy.  It also fits with the
current behavior if someone asks the allocator do do something silly
like give them memory from a non-present zone.

-- Dave

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