'struct xdp_umem_reg' has 4 bytes of padding at the end that makes
valgrind complain about passing uninitialized stack memory to the
syscall:
Syscall param socketcall.setsockopt() points to uninitialised byte(s)
at 0x4E7AB7E: setsockopt (in /usr/lib64/libc-2.29.so)
by 0x4BDE035: xsk_umem__create@@LIBBPF_0.0.4 (xsk.c:172)
Uninitialised value was created by a stack allocation
at 0x4BDDEBA: xsk_umem__create@@LIBBPF_0.0.4 (xsk.c:140)
Padding bytes appeared after introducing of a new 'flags' field.
Fixes: 10d30e301732 ("libbpf: add flags to umem config")
Signed-off-by: Ilya Maximets <[email protected]>
---
tools/lib/bpf/xsk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c
index a902838f9fcc..26d9db783560 100644
--- a/tools/lib/bpf/xsk.c
+++ b/tools/lib/bpf/xsk.c
@@ -139,7 +139,7 @@ int xsk_umem__create_v0_0_4(struct xsk_umem **umem_ptr, void *umem_area,
const struct xsk_umem_config *usr_config)
{
struct xdp_mmap_offsets off;
- struct xdp_umem_reg mr;
+ struct xdp_umem_reg mr = {};
struct xsk_umem *umem;
socklen_t optlen;
void *map;
--
2.17.1
On Wed, Oct 9, 2019 at 8:43 AM Ilya Maximets <[email protected]> wrote:
>
> 'struct xdp_umem_reg' has 4 bytes of padding at the end that makes
> valgrind complain about passing uninitialized stack memory to the
> syscall:
>
> Syscall param socketcall.setsockopt() points to uninitialised byte(s)
> at 0x4E7AB7E: setsockopt (in /usr/lib64/libc-2.29.so)
> by 0x4BDE035: xsk_umem__create@@LIBBPF_0.0.4 (xsk.c:172)
> Uninitialised value was created by a stack allocation
> at 0x4BDDEBA: xsk_umem__create@@LIBBPF_0.0.4 (xsk.c:140)
>
> Padding bytes appeared after introducing of a new 'flags' field.
>
> Fixes: 10d30e301732 ("libbpf: add flags to umem config")
> Signed-off-by: Ilya Maximets <[email protected]>
> ---
> tools/lib/bpf/xsk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c
> index a902838f9fcc..26d9db783560 100644
> --- a/tools/lib/bpf/xsk.c
> +++ b/tools/lib/bpf/xsk.c
> @@ -139,7 +139,7 @@ int xsk_umem__create_v0_0_4(struct xsk_umem **umem_ptr, void *umem_area,
> const struct xsk_umem_config *usr_config)
> {
> struct xdp_mmap_offsets off;
> - struct xdp_umem_reg mr;
> + struct xdp_umem_reg mr = {};
well, guess what, even with this explicit initialization, padding is
not guaranteed to be initialized (and it's sometimes is not in
practice, I ran into such problems), only since C11 standard it is
specified that padding is also zero-initialized. You have to do memset
to 0.
> struct xsk_umem *umem;
> socklen_t optlen;
> void *map;
> --
> 2.17.1
>
On 09.10.2019 18:29, Andrii Nakryiko wrote:
> On Wed, Oct 9, 2019 at 8:43 AM Ilya Maximets <[email protected]> wrote:
>>
>> 'struct xdp_umem_reg' has 4 bytes of padding at the end that makes
>> valgrind complain about passing uninitialized stack memory to the
>> syscall:
>>
>> Syscall param socketcall.setsockopt() points to uninitialised byte(s)
>> at 0x4E7AB7E: setsockopt (in /usr/lib64/libc-2.29.so)
>> by 0x4BDE035: xsk_umem__create@@LIBBPF_0.0.4 (xsk.c:172)
>> Uninitialised value was created by a stack allocation
>> at 0x4BDDEBA: xsk_umem__create@@LIBBPF_0.0.4 (xsk.c:140)
>>
>> Padding bytes appeared after introducing of a new 'flags' field.
>>
>> Fixes: 10d30e301732 ("libbpf: add flags to umem config")
>> Signed-off-by: Ilya Maximets <[email protected]>
>> ---
>> tools/lib/bpf/xsk.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c
>> index a902838f9fcc..26d9db783560 100644
>> --- a/tools/lib/bpf/xsk.c
>> +++ b/tools/lib/bpf/xsk.c
>> @@ -139,7 +139,7 @@ int xsk_umem__create_v0_0_4(struct xsk_umem **umem_ptr, void *umem_area,
>> const struct xsk_umem_config *usr_config)
>> {
>> struct xdp_mmap_offsets off;
>> - struct xdp_umem_reg mr;
>> + struct xdp_umem_reg mr = {};
>
> well, guess what, even with this explicit initialization, padding is
> not guaranteed to be initialized (and it's sometimes is not in
> practice, I ran into such problems), only since C11 standard it is
> specified that padding is also zero-initialized. You have to do memset
> to 0.
OK. Sure. I'll send v2.
>
>> struct xsk_umem *umem;
>> socklen_t optlen;
>> void *map;
>> --
>> 2.17.1
>>
On Sat, Oct 12, 2019 at 9:52 PM Ilya Maximets <[email protected]> wrote:
>
> 'struct xdp_umem_reg' has 4 bytes of padding at the end that makes
> valgrind complain about passing uninitialized stack memory to the
> syscall:
>
> Syscall param socketcall.setsockopt() points to uninitialised byte(s)
> at 0x4E7AB7E: setsockopt (in /usr/lib64/libc-2.29.so)
> by 0x4BDE035: xsk_umem__create@@LIBBPF_0.0.4 (xsk.c:172)
> Uninitialised value was created by a stack allocation
> at 0x4BDDEBA: xsk_umem__create@@LIBBPF_0.0.4 (xsk.c:140)
>
> Padding bytes appeared after introducing of a new 'flags' field.
>
> Fixes: 10d30e301732 ("libbpf: add flags to umem config")
> Signed-off-by: Ilya Maximets <[email protected]>
Something is not right with (e|g)mail.
This is 3rd email I got with the same patch.
First one (the one that was applied) was 3 days ago.
On 13.10.2019 6:59, Alexei Starovoitov wrote:
> On Sat, Oct 12, 2019 at 9:52 PM Ilya Maximets <[email protected]> wrote:
>>
>> 'struct xdp_umem_reg' has 4 bytes of padding at the end that makes
>> valgrind complain about passing uninitialized stack memory to the
>> syscall:
>>
>> Syscall param socketcall.setsockopt() points to uninitialised byte(s)
>> at 0x4E7AB7E: setsockopt (in /usr/lib64/libc-2.29.so)
>> by 0x4BDE035: xsk_umem__create@@LIBBPF_0.0.4 (xsk.c:172)
>> Uninitialised value was created by a stack allocation
>> at 0x4BDDEBA: xsk_umem__create@@LIBBPF_0.0.4 (xsk.c:140)
>>
>> Padding bytes appeared after introducing of a new 'flags' field.
>>
>> Fixes: 10d30e301732 ("libbpf: add flags to umem config")
>> Signed-off-by: Ilya Maximets <[email protected]>
>
> Something is not right with (e|g)mail.
> This is 3rd email I got with the same patch.
> First one (the one that was applied) was 3 days ago.
>
I'm sorry. I don't know why the mail server started re-sending
these e-mails. I'm receiving them too.
That is strange.
Best regards, Ilya Maximets.