Re: [PATCH] slab: prevent warnings when allocating with __GFP_NOWARN

Dave Jones
2013-06-11T16:43:44Z

On Tue, Jun 11, 2013 at 09:37:35AM -0700, Eric Dumazet wrote:
> On Tue, 2013-06-11 at 12:19 -0400, Sasha Levin wrote:
>
> > It might be, but you need CAP_SYS_RESOURCE to go into the dangerous
> > zone (>pipe_max_size).
> >
> > So if root (or someone with that cap) wants to go there, as Rusty says:
> > "Root asked, we do."
>
> Yes and no : adding a test to select vmalloc()/vfree() instead of
> kmalloc()/kfree() will slow down regular users asking 32 pages in their
> pipe.
>
> If there is no _sensible_ use for large pipes even for root, please do
> not bloat the code just because we can.

It's not even that this is the only place that this happens.
I've reported similar traces from the ieee802.154 code for some time.

I wouldn't be surprised to find that there are other similar cases where
a user can ask the kernel to do some incredibly huge allocation.

For my fuzz testing runs, I ended up with the patch below to stop the page allocator warnings.

Dave

--- /home/davej/src/kernel/git-trees/linux/net/ieee802154/af_ieee802154.c 2013-01-04 18:57:17.677270225 -0500
+++ linux-dj/net/ieee802154/af_ieee802154.c 2013-05-06 20:34:30.702926471 -0400
@@ -108,6 +108,12 @@ static int ieee802154_sock_sendmsg(struc
{
struct sock *sk = sock->sk;

+ if (len > MAX_ORDER_NR_PAGES * PAGE_SIZE) {
+ printk_once("Massive alloc in %s!: %d > %d\n", __func__,
+ (unsigned int) len, (unsigned int) (MAX_ORDER_NR_PAGES * PAGE_SIZE));
+ return -EINVAL;
+ }
+
return sk->sk_prot->sendmsg(iocb, sk, msg, len);
}