[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3e4fc1efb5d7dbe0dd966e3192e84645.squirrel@webmail.greenhost.nl>
Date: Wed, 14 Mar 2012 06:12:52 +0100
From: "Indan Zupancic" <indan@....nu>
To: "Eric Dumazet" <eric.dumazet@...il.com>
Cc: "Will Drewry" <wad@...omium.org>,
linux-kernel@...r.kernel.org,
linux-arch@...r.kernel.org,
linux-doc@...r.kernel.org,
kernel-hardening@...ts.openwall.com,
netdev@...r.kernel.org,
x86@...nel.org,
arnd@...db.de,
davem@...emloft.net,
hpa@...or.com,
mingo@...hat.com,
oleg@...hat.com,
peterz@...radead.org,
rdunlap@...otime.net,
mcgrathr@...omium.org,
tglx@...utronix.de,
luto@....edu,
eparis@...hat.com,
serge.hallyn@...onical.com,
djm@...drot.org,
scarybeasts@...il.com,
pmoore@...hat.com,
akpm@...ux-foundation.org,
corbet@....net,
markus@...omium.org,
coreyb@...ux.vnet.ibm.com,
keescook@...omium.org
Subject: Re: [PATCH v14 01/13] sk_run_filter: add BPF_S_ANC_SECCOMP_LD_W
Hello,
On Tue, March 13, 2012 18:13, Eric Dumazet wrote:
> On Tue, 2012-03-13 at 11:04 +0100, Indan Zupancic wrote:
>> - bpf_jit_compile(fp);
>> + jit = bpf_jit_compile(fp->insns, fp->len, 1);
>> + if (jit) {
>> + fp->bpf_func = jit;
>> + /* Free unused insns memory */
>> + newfp = krealloc(fp, sizeof(*fp), GFP_KERNEL);
>> + if (newfp)
>> + fp = newfp;
>> + }
>>
>> old_fp = rcu_dereference_protected(sk->sk_filter,
>> sock_owned_by_user(sk));
>
> Dont mix unrelated changes in a single patch.
I know, but it was just a quick proof-of-concept. It just showed
a possible advantage of the API change for the current networking
code. The real patch would be split into an API change, the memory
freeing change, and the seccomp support.
>
> Current krealloc() doesnt alloc a new area if the current one is bigger
> than 'new_size', but this might change in next kernel versions.
>
> So this part of your patch does nothing.
Problem is that 'old_size' can be up to 32kB in size and it would be nice
if that memory could be released. If it isn't, then using JIT increases
memory usage, while also not accounting it to the socket.
>
> If it did, this kind of 'optimization' can actually be not good, because
> sizeof(*fp) is small enough (less than half cache line size) to trigger
> a possible false sharing issue. (other part of the cache line could be
> used to hold a often dirtied object)
It could avoid this by allocating at least a cache size. But this is a
problem for all small kmalloc's, isn't it?
What about something like the below:
@@ -625,7 +639,18 @@ int sk_attach_filter(struct sock_fprog *fprog, struct sock *sk)
return err;
}
- bpf_jit_compile(fp);
+ jit = bpf_jit_compile(fp->insns, fp->len, 1);
+ if (jit) {
+ int size = max(cache_line_size(), sizeof(*fp));
+ fp->bpf_func = jit;
+ /* Free unused insns memory */
+ newfp = kmalloc(size, GFP_KERNEL);
+ if (newfp) {
+ memcpy(newfp, fp, size);
+ kfree(fp);
+ fp = newfp;
+ }
+ }
old_fp = rcu_dereference_protected(sk->sk_filter,
sock_owned_by_user(sk));
Not sure whether to use cache_line_size() or just L1_CACHE_BYTES or
something else.
Greeings,
Indan
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
