* [PATCH] Fix sleeping memory allocation in atomic context
@ 2015-10-15 8:57 Nikolay Borisov
2015-10-15 10:13 ` Nikolay Aleksandrov
2015-10-15 10:16 ` Jozsef Kadlecsik
0 siblings, 2 replies; 4+ messages in thread
From: Nikolay Borisov @ 2015-10-15 8:57 UTC (permalink / raw)
To: kadlec; +Cc: pablo, davem, netfilter-devel, netdev, operations
Ipset 6.26 produces the following splat:
BUG: sleeping function called from invalid context at mm/page_alloc.c:2759
in_atomic(): 1, irqs_disabled(): 0, pid: 9664, name: ipset
CPU: 18 PID: 9664 Comm: ipset Tainted: G O 3.12.47-clouder3 #1
Hardware name: Supermicro X10DRi/X10DRi, BIOS 1.1 04/14/2015
0000000000000002 ffff881fd14273c8 ffffffff8163d891 ffff881fcb4264b0
ffff881fcb4260c0 ffff881fd14273e8 ffffffff810ba5bf ffff881fd1427558
0000000000000000 ffff881fd1427568 ffffffff81142b33 ffff881f00000000
Call Trace:
[<ffffffff8163d891>] dump_stack+0x58/0x7f
[<ffffffff810ba5bf>] __might_sleep+0xdf/0x110
[<ffffffff81142b33>] __alloc_pages_nodemask+0x243/0xc20
[<ffffffff81181c6e>] alloc_pages_current+0xbe/0x170
[<ffffffff81188315>] new_slab+0x295/0x340
[<ffffffff81189a40>] __slab_alloc+0x2c0/0x5a0
[<ffffffff8164000c>] ? __schedule+0x2dc/0x760
[<ffffffff8118a71b>] __kmalloc+0x11b/0x230
[<ffffffffa02bd0ac>] ? ip_set_get_byname+0xec/0x100 [ip_set]
[<ffffffffa02d23fb>] list_set_uadd+0x16b/0x314 [ip_set_list_set]
[<ffffffff81642148>] ? _raw_write_unlock_bh+0x28/0x30
[<ffffffffa02d1cfc>] list_set_uadt+0x21c/0x320 [ip_set_list_set]
[<ffffffffa02d2290>] ? list_set_create+0x1a0/0x1a0 [ip_set_list_set]
[<ffffffffa02be242>] call_ad+0x82/0x200 [ip_set]
[<ffffffffa02bb171>] ? find_set_type+0x51/0xa0 [ip_set]
[<ffffffff8133f275>] ? nla_parse+0xf5/0x130
[<ffffffffa02be8ae>] ip_set_uadd+0x20e/0x2d0 [ip_set]
[<ffffffffa02be013>] ? ip_set_create+0x2a3/0x450 [ip_set]
[<ffffffffa02be6a0>] ? ip_set_udel+0x2e0/0x2e0 [ip_set]
[<ffffffff815b316e>] nfnetlink_rcv_msg+0x31e/0x330
[<ffffffff815b2e91>] ? nfnetlink_rcv_msg+0x41/0x330
[<ffffffff815b2e50>] ? nfnl_lock+0x30/0x30
[<ffffffff815ae179>] netlink_rcv_skb+0xa9/0xd0
[<ffffffff815b2d45>] nfnetlink_rcv+0x15/0x20
[<ffffffff815ade5f>] netlink_unicast+0x10f/0x190
[<ffffffff815aedb0>] netlink_sendmsg+0x2c0/0x660
[<ffffffff81567f00>] sock_sendmsg+0x90/0xc0
[<ffffffff81565b03>] ? move_addr_to_user+0xa3/0xc0
[<ffffffff81568552>] ? ___sys_recvmsg+0x182/0x300
[<ffffffff81568064>] SYSC_sendto+0x134/0x180
[<ffffffff811c4e01>] ? mntput+0x21/0x30
[<ffffffff81572d2f>] ? __kfree_skb+0x3f/0xa0
[<ffffffff815680be>] SyS_sendto+0xe/0x10
[<ffffffff816434b2>] system_call_fastpath+0x16/0x1b
The call chain leading to this as follow:
call_add -> list_set_uadt -> list_set_uadd -> kzalloc(, GFP_KERNEL).
And since GFP_KERNEL allows initiating direct reclaim thus
potentially sleeping in the allocation path, this leads to the
aforementioned splat.
To fix it change that particular allocation type to GFP_ATOMIC, to
correctly reflect that it is happening in an atomic context.
Signed-off-by: Nikolay Borisov <kernel@kyup.com>
---
Even though this patch has been generated against the stand-alone
ipset sources I just checked the 4.3-rc4 sources and the problem
exists there as well.
kernel/net/netfilter/ipset/ip_set_list_set.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/net/netfilter/ipset/ip_set_list_set.c b/kernel/net/netfilter/ipset/ip_set_list_set.c
index b11ba96..0f9195f 100644
--- a/kernel/net/netfilter/ipset/ip_set_list_set.c
+++ b/kernel/net/netfilter/ipset/ip_set_list_set.c
@@ -298,7 +298,7 @@ list_set_uadd(struct ip_set *set, void *value, const struct ip_set_ext *ext,
ip_set_timeout_expired(ext_timeout(n, set))))
n = NULL;
- e = kzalloc(set->dsize, GFP_KERNEL);
+ e = kzalloc(set->dsize, GFP_ATOMIC);
if (!e)
return -ENOMEM;
e->id = d->id;
--
2.5.0
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] Fix sleeping memory allocation in atomic context
2015-10-15 8:57 [PATCH] Fix sleeping memory allocation in atomic context Nikolay Borisov
@ 2015-10-15 10:13 ` Nikolay Aleksandrov
2015-10-15 10:18 ` Jozsef Kadlecsik
2015-10-15 10:16 ` Jozsef Kadlecsik
1 sibling, 1 reply; 4+ messages in thread
From: Nikolay Aleksandrov @ 2015-10-15 10:13 UTC (permalink / raw)
To: Nikolay Borisov, kadlec; +Cc: pablo, davem, netfilter-devel, netdev, operations
On 10/15/2015 10:57 AM, Nikolay Borisov wrote:
> Ipset 6.26 produces the following splat:
>
[snip]
>
> The call chain leading to this as follow:
> call_add -> list_set_uadt -> list_set_uadd -> kzalloc(, GFP_KERNEL).
> And since GFP_KERNEL allows initiating direct reclaim thus
> potentially sleeping in the allocation path, this leads to the
> aforementioned splat.
>
> To fix it change that particular allocation type to GFP_ATOMIC, to
> correctly reflect that it is happening in an atomic context.
>
> Signed-off-by: Nikolay Borisov <kernel@kyup.com>
> ---
>
> Even though this patch has been generated against the stand-alone
> ipset sources I just checked the 4.3-rc4 sources and the problem
> exists there as well.
>
> kernel/net/netfilter/ipset/ip_set_list_set.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/net/netfilter/ipset/ip_set_list_set.c b/kernel/net/netfilter/ipset/ip_set_list_set.c
> index b11ba96..0f9195f 100644
Hi,
You should fix your subject line to include the subsystem [1], something like
netfilter: ipset: fix...
The path to the file being patched is incorrect, patches should be generated in
the root kernel source dir [2].
Also it'd be nice to add a Fixes tag [3] to show which commit introduced the bug,
in this case it looks like it's:
Fixes: 00590fdd5be0 ("netfilter: ipset: Introduce RCU locking in list type")
Cheers,
Nik
[1] Documentation/SubmittingPatches chapter 14
[2] Documentation/SubmittingPatches chapter 1
[3] Documentation/SubmittingPatches chapters 2 and 13
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] Fix sleeping memory allocation in atomic context
2015-10-15 8:57 [PATCH] Fix sleeping memory allocation in atomic context Nikolay Borisov
2015-10-15 10:13 ` Nikolay Aleksandrov
@ 2015-10-15 10:16 ` Jozsef Kadlecsik
1 sibling, 0 replies; 4+ messages in thread
From: Jozsef Kadlecsik @ 2015-10-15 10:16 UTC (permalink / raw)
To: Nikolay Borisov
Cc: Pablo Neira Ayuso, David Miller, netfilter-devel, netdev,
operations
On Thu, 15 Oct 2015, Nikolay Borisov wrote:
> Ipset 6.26 produces the following splat:
>
> BUG: sleeping function called from invalid context at mm/page_alloc.c:2759
> in_atomic(): 1, irqs_disabled(): 0, pid: 9664, name: ipset
> CPU: 18 PID: 9664 Comm: ipset Tainted: G O 3.12.47-clouder3 #1
> Hardware name: Supermicro X10DRi/X10DRi, BIOS 1.1 04/14/2015
> 0000000000000002 ffff881fd14273c8 ffffffff8163d891 ffff881fcb4264b0
> ffff881fcb4260c0 ffff881fd14273e8 ffffffff810ba5bf ffff881fd1427558
> 0000000000000000 ffff881fd1427568 ffffffff81142b33 ffff881f00000000
> Call Trace:
> [<ffffffff8163d891>] dump_stack+0x58/0x7f
> [<ffffffff810ba5bf>] __might_sleep+0xdf/0x110
> [<ffffffff81142b33>] __alloc_pages_nodemask+0x243/0xc20
> [<ffffffff81181c6e>] alloc_pages_current+0xbe/0x170
> [<ffffffff81188315>] new_slab+0x295/0x340
> [<ffffffff81189a40>] __slab_alloc+0x2c0/0x5a0
> [<ffffffff8164000c>] ? __schedule+0x2dc/0x760
> [<ffffffff8118a71b>] __kmalloc+0x11b/0x230
> [<ffffffffa02bd0ac>] ? ip_set_get_byname+0xec/0x100 [ip_set]
> [<ffffffffa02d23fb>] list_set_uadd+0x16b/0x314 [ip_set_list_set]
> [<ffffffff81642148>] ? _raw_write_unlock_bh+0x28/0x30
> [<ffffffffa02d1cfc>] list_set_uadt+0x21c/0x320 [ip_set_list_set]
> [<ffffffffa02d2290>] ? list_set_create+0x1a0/0x1a0 [ip_set_list_set]
> [<ffffffffa02be242>] call_ad+0x82/0x200 [ip_set]
> [<ffffffffa02bb171>] ? find_set_type+0x51/0xa0 [ip_set]
> [<ffffffff8133f275>] ? nla_parse+0xf5/0x130
> [<ffffffffa02be8ae>] ip_set_uadd+0x20e/0x2d0 [ip_set]
> [<ffffffffa02be013>] ? ip_set_create+0x2a3/0x450 [ip_set]
> [<ffffffffa02be6a0>] ? ip_set_udel+0x2e0/0x2e0 [ip_set]
> [<ffffffff815b316e>] nfnetlink_rcv_msg+0x31e/0x330
> [<ffffffff815b2e91>] ? nfnetlink_rcv_msg+0x41/0x330
> [<ffffffff815b2e50>] ? nfnl_lock+0x30/0x30
> [<ffffffff815ae179>] netlink_rcv_skb+0xa9/0xd0
> [<ffffffff815b2d45>] nfnetlink_rcv+0x15/0x20
> [<ffffffff815ade5f>] netlink_unicast+0x10f/0x190
> [<ffffffff815aedb0>] netlink_sendmsg+0x2c0/0x660
> [<ffffffff81567f00>] sock_sendmsg+0x90/0xc0
> [<ffffffff81565b03>] ? move_addr_to_user+0xa3/0xc0
> [<ffffffff81568552>] ? ___sys_recvmsg+0x182/0x300
> [<ffffffff81568064>] SYSC_sendto+0x134/0x180
> [<ffffffff811c4e01>] ? mntput+0x21/0x30
> [<ffffffff81572d2f>] ? __kfree_skb+0x3f/0xa0
> [<ffffffff815680be>] SyS_sendto+0xe/0x10
> [<ffffffff816434b2>] system_call_fastpath+0x16/0x1b
>
> The call chain leading to this as follow:
> call_add -> list_set_uadt -> list_set_uadd -> kzalloc(, GFP_KERNEL).
> And since GFP_KERNEL allows initiating direct reclaim thus
> potentially sleeping in the allocation path, this leads to the
> aforementioned splat.
>
> To fix it change that particular allocation type to GFP_ATOMIC, to
> correctly reflect that it is happening in an atomic context.
Good catch, Pablo please apply the patch.
Acked-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Best regards,
Jozsef
> Signed-off-by: Nikolay Borisov <kernel@kyup.com>
> ---
>
> Even though this patch has been generated against the stand-alone
> ipset sources I just checked the 4.3-rc4 sources and the problem
> exists there as well.
>
> kernel/net/netfilter/ipset/ip_set_list_set.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/net/netfilter/ipset/ip_set_list_set.c b/kernel/net/netfilter/ipset/ip_set_list_set.c
> index b11ba96..0f9195f 100644
> --- a/kernel/net/netfilter/ipset/ip_set_list_set.c
> +++ b/kernel/net/netfilter/ipset/ip_set_list_set.c
> @@ -298,7 +298,7 @@ list_set_uadd(struct ip_set *set, void *value, const struct ip_set_ext *ext,
> ip_set_timeout_expired(ext_timeout(n, set))))
> n = NULL;
>
> - e = kzalloc(set->dsize, GFP_KERNEL);
> + e = kzalloc(set->dsize, GFP_ATOMIC);
> if (!e)
> return -ENOMEM;
> e->id = d->id;
> --
> 2.5.0
>
>
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] Fix sleeping memory allocation in atomic context
2015-10-15 10:13 ` Nikolay Aleksandrov
@ 2015-10-15 10:18 ` Jozsef Kadlecsik
0 siblings, 0 replies; 4+ messages in thread
From: Jozsef Kadlecsik @ 2015-10-15 10:18 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: Nikolay Borisov, pablo, davem, netfilter-devel, netdev,
operations
On Thu, 15 Oct 2015, Nikolay Aleksandrov wrote:
> On 10/15/2015 10:57 AM, Nikolay Borisov wrote:
> > Ipset 6.26 produces the following splat:
> >
> [snip]
> >
> > The call chain leading to this as follow:
> > call_add -> list_set_uadt -> list_set_uadd -> kzalloc(, GFP_KERNEL).
> > And since GFP_KERNEL allows initiating direct reclaim thus
> > potentially sleeping in the allocation path, this leads to the
> > aforementioned splat.
> >
> > To fix it change that particular allocation type to GFP_ATOMIC, to
> > correctly reflect that it is happening in an atomic context.
> >
> > Signed-off-by: Nikolay Borisov <kernel@kyup.com>
> > ---
> >
> > Even though this patch has been generated against the stand-alone
> > ipset sources I just checked the 4.3-rc4 sources and the problem
> > exists there as well.
> >
> > kernel/net/netfilter/ipset/ip_set_list_set.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/net/netfilter/ipset/ip_set_list_set.c b/kernel/net/netfilter/ipset/ip_set_list_set.c
> > index b11ba96..0f9195f 100644
>
> Hi,
> You should fix your subject line to include the subsystem [1], something like
> netfilter: ipset: fix...
> The path to the file being patched is incorrect, patches should be generated in
> the root kernel source dir [2].
> Also it'd be nice to add a Fixes tag [3] to show which commit introduced the bug,
> in this case it looks like it's:
> Fixes: 00590fdd5be0 ("netfilter: ipset: Introduce RCU locking in list type")
The patch was created against the ipset package and not the kernel tree
itself, so yes, a respin is needed.
Best regards,
Jozsef
> [1] Documentation/SubmittingPatches chapter 14
> [2] Documentation/SubmittingPatches chapter 1
> [3] Documentation/SubmittingPatches chapters 2 and 13
>
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-10-15 10:18 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-10-15 8:57 [PATCH] Fix sleeping memory allocation in atomic context Nikolay Borisov
2015-10-15 10:13 ` Nikolay Aleksandrov
2015-10-15 10:18 ` Jozsef Kadlecsik
2015-10-15 10:16 ` Jozsef Kadlecsik
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).