From: Daniel Borkmann <dborkman@redhat.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Alexei Starovoitov <ast@plumgrid.com>,
Pablo Neira Ayuso <pablo@netfilter.org>,
"David S. Miller" <davem@davemloft.net>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH] bpf: fix a false positive kmemcheck warning
Date: Fri, 05 Sep 2014 18:20:24 +0200 [thread overview]
Message-ID: <5409E2C8.2080200@redhat.com> (raw)
In-Reply-To: <alpine.LRH.2.02.1409051157440.5269@file01.intranet.prod.int.rdu2.redhat.com>
Hi Mikulas,
On 09/05/2014 06:01 PM, Mikulas Patocka wrote:
> This patch fixes false positive kmemcheck warning in bpf.
>
> When we try to write the variable len, the compiler generates a code that
> reads the 32-bit word, modifies the bits belonging to "len" and writes the
> 32-bit word back. The reading of the word results in kmemcheck warning due
> to reading uninitialized memory. This patch fixes it by avoiding using bit
> fields when kmemcheck is enabled.
>
> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
You need to submit this patch to netdev (Cc'ed).
> ---
> include/linux/filter.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> Index: linux-2.6/include/linux/filter.h
> ===================================================================
> --- linux-2.6.orig/include/linux/filter.h 2014-09-04 23:04:26.000000000 +0200
> +++ linux-2.6/include/linux/filter.h 2014-09-04 23:43:05.000000000 +0200
> @@ -325,8 +325,13 @@ struct sock;
> struct seccomp_data;
>
> struct bpf_prog {
> +#ifdef CONFIG_KMEMCHECK
> + bool jited;
> + u32 len;
> +#else
> u32 jited:1, /* Is our filter JIT'ed? */
> len:31; /* Number of filter blocks */
> +#endif
> struct sock_fprog_kern *orig_prog; /* Original BPF program */
> unsigned int (*bpf_func)(const struct sk_buff *skb,
> const struct bpf_insn *filter);
I don't really like this if-def. If you really want to fix it, can't
you just use :
kmemcheck_bitfield_begin(bpf_anc_data)
...
kmemcheck_bitfield_end(bpf_anc_data)
et al infrastructure as container (in case in future we will add some more
bit flags, since len doesn't really need all 31 bit universe)?
Note, there are currently some patches pending in patchwork that also fill
the u32 hole thus the extra bool would introduce a new hole after that.
Therefore, I think above would be better.
Thanks,
Daniel
next parent reply other threads:[~2014-09-05 16:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <alpine.LRH.2.02.1409051157440.5269@file01.intranet.prod.int.rdu2.redhat.com>
2014-09-05 16:20 ` Daniel Borkmann [this message]
2014-09-05 17:00 ` [PATCH] bpf: fix a false positive kmemcheck warning Hannes Frederic Sowa
2014-09-05 17:10 ` Daniel Borkmann
2014-09-05 17:13 ` Mikulas Patocka
2014-09-05 17:17 ` Daniel Borkmann
2014-09-05 17:21 ` Alexei Starovoitov
2014-09-05 17:34 ` Daniel Borkmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5409E2C8.2080200@redhat.com \
--to=dborkman@redhat.com \
--cc=ast@plumgrid.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pablo@netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).