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);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
