net: filter: add __GFP_NOWARN flag for larger kmem allocs
When seccomp BPF was added, it was discussed to add __GFP_NOWARN flag for their configuration path as f.e. up to 32K allocations are more prone to fail under stress. As we're going to reuse BPF API, add __GFP_NOWARN flags where larger kmalloc() and friends allocations could fail. It doesn't make much sense to pass around __GFP_NOWARN everywhere as an extra argument only for seccomp while we just as well could run into similar issues for socket filters, where it's not desired to have a user application throw a WARN() due to allocation failure. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Cc: Nicolas Schichan <nschichan@freebox.fr> Cc: Alexei Starovoitov <ast@plumgrid.com> Cc: Kees Cook <keescook@chromium.org> Acked-by: Alexei Starovoitov <ast@plumgrid.com> Signed-off-by: David S. Miller <davem@davemloft.net>
This commit is contained in:
parent
d9e12f42e5
commit
658da9379d
|
@ -371,7 +371,8 @@ static int bpf_convert_filter(struct sock_filter *prog, int len,
|
|||
return -EINVAL;
|
||||
|
||||
if (new_prog) {
|
||||
addrs = kcalloc(len, sizeof(*addrs), GFP_KERNEL);
|
||||
addrs = kcalloc(len, sizeof(*addrs),
|
||||
GFP_KERNEL | __GFP_NOWARN);
|
||||
if (!addrs)
|
||||
return -ENOMEM;
|
||||
}
|
||||
|
@ -839,7 +840,9 @@ static int bpf_prog_store_orig_filter(struct bpf_prog *fp,
|
|||
|
||||
fkprog = fp->orig_prog;
|
||||
fkprog->len = fprog->len;
|
||||
fkprog->filter = kmemdup(fp->insns, fsize, GFP_KERNEL);
|
||||
|
||||
fkprog->filter = kmemdup(fp->insns, fsize,
|
||||
GFP_KERNEL | __GFP_NOWARN);
|
||||
if (!fkprog->filter) {
|
||||
kfree(fp->orig_prog);
|
||||
return -ENOMEM;
|
||||
|
@ -941,7 +944,7 @@ static struct bpf_prog *bpf_migrate_filter(struct bpf_prog *fp)
|
|||
* pass. At this time, the user BPF is stored in fp->insns.
|
||||
*/
|
||||
old_prog = kmemdup(fp->insns, old_len * sizeof(struct sock_filter),
|
||||
GFP_KERNEL);
|
||||
GFP_KERNEL | __GFP_NOWARN);
|
||||
if (!old_prog) {
|
||||
err = -ENOMEM;
|
||||
goto out_err;
|
||||
|
|
Loading…
Reference in New Issue