With libbpf and BTF it is pretty common to have libbpf built for one
architecture, while BTF information was generated for a different architecture
(typically, but not always, BPF). In such case, the size of a pointer might
differ betweem architectures. libbpf previously was always making an
assump
Ensure that types are memory layout- and field alignment-compatible regardless
of 32/64-bitness mix of libbpf and BPF architecture.
Signed-off-by: Andrii Nakryiko
---
.../selftests/bpf/prog_tests/core_reloc.c | 20 +++---
.../selftests/bpf/progs/core_reloc_types.h| 69 ++-
Despite bpftool generating data section memory layout that will work for
32-bit architectures on user-space side, BPF programs should be careful to not
use ambiguous types like `long`, which have different size in 32-bit and
64-bit environments. Fix that in test by using __u64 explicitly, which is
Libbpf built in 32-bit mode should be careful about not conflating 64-bit BPF
pointers in BPF ELF file and host architecture pointers. This patch fixes
issue of incorrect initializating of map-in-map inner map slots due to such
difference.
Fixes: 646f02ffdd49 ("libbpf: Add BTF-defined map-in-map s
Fix compilation warnings emitted when compiling selftests for 32-bit platform
(x86 in my case).
Signed-off-by: Andrii Nakryiko
---
tools/testing/selftests/bpf/prog_tests/bpf_obj_id.c | 8
tools/testing/selftests/bpf/prog_tests/core_extern.c| 4 ++--
tools/testing/selftests/bpf/p
Fix btf_dump test cases by hard-coding BPF's pointer size of 8 bytes for cases
where it's impossible to deterimne the pointer size (no long type in BTF). In
cases where it's known, validate libbpf correctly determines it as 8.
Signed-off-by: Andrii Nakryiko
---
.../selftests/bpf/prog_tests/btf_d
This patch set contains fixes to libbpf, bpftool, and selftests that were
found while testing libbpf and selftests built in 32-bit mode. 64-bit nature
of BPF target and 32-bit host environment don't always mix together well
without extra care, so there were a bunch of problems discovered and fixed.
Fix few compilation warnings in bpftool when compiling in 32-bit mode.
Abstract away u64 to pointer conversion into a helper function.
Signed-off-by: Andrii Nakryiko
---
tools/bpf/bpftool/btf_dumper.c | 2 +-
tools/bpf/bpftool/link.c | 4 ++--
tools/bpf/bpftool/main.h | 10
BPF object files are always targeting 64-bit BPF target architecture, so
enforce that at BTF level as well.
Signed-off-by: Andrii Nakryiko
---
tools/lib/bpf/libbpf.c | 4
1 file changed, 4 insertions(+)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 4a8524b2dda1..738579
The comment in the code describes this in good details. Generate such a memory
layout that would work both on 32-bit and 64-bit architectures for user-space.
Signed-off-by: Andrii Nakryiko
---
tools/bpf/bpftool/gen.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/tools/bpf/b
From: Fugang Duan
Correct the error path for regulator disable.
Fixes: 9269e5560b26 ("net: fec: add phy-reset-gpios PROBE_DEFER check")
Signed-off-by: Fugang Duan
---
drivers/net/ethernet/freescale/fec_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/e
syzkaller reports splat:
[ cut here ]
Buffer overflow detected (80 < 137)!
Call Trace:
do_ebt_get_ctl+0x2b4/0x790 net/bridge/netfilter/ebtables.c:2317
nf_getsockopt+0x72/0xd0 net/netfilter/nf_sockopt.c:116
ip_getsockopt net/ipv4/ip_sockglue.c:1778 [inline]
caused by a co
Hi Rob,
On Wed, Aug 12, 2020 at 10:36 PM Rob Herring wrote:
> Clean-up incorrect indentation, extra spaces, long lines, and missing
> EOF newline in schema files. Most of the clean-ups are for list
> indentation which should always be 2 spaces more than the preceding
> keyword.
>
> Found with yam
On Wed, Aug 12, 2020 at 5:21 AM Willy Tarreau wrote:
>
> On Tue, Aug 11, 2020 at 12:51:43PM +0200, Sedat Dilek wrote:
> > Can you share this "rebased to mainline" version of George's patch?
>
> You can pick it from there if that helps, but keep in mind that
> it's just experimental code that we us
On Mon, Jul 27, 2020 at 03:22:37PM +0300, Vadym Kochan wrote:
> Marvell Prestera 98DX326x integrates up to 24 ports of 1GbE with 8
> ports of 10GbE uplinks or 2 ports of 40Gbps stacking for a largely
> wireless SMB deployment.
>
> The current implementation supports only boards designed for the Ma
On Thu, Aug 13, 2020 at 09:53:11AM +0200, Sedat Dilek wrote:
> On Wed, Aug 12, 2020 at 5:21 AM Willy Tarreau wrote:
> >
> > On Tue, Aug 11, 2020 at 12:51:43PM +0200, Sedat Dilek wrote:
> > > Can you share this "rebased to mainline" version of George's patch?
> >
> > You can pick it from there if t
On Thu, Aug 13, 2020 at 10:06 AM Willy Tarreau wrote:
>
> On Thu, Aug 13, 2020 at 09:53:11AM +0200, Sedat Dilek wrote:
> > On Wed, Aug 12, 2020 at 5:21 AM Willy Tarreau wrote:
> > >
> > > On Tue, Aug 11, 2020 at 12:51:43PM +0200, Sedat Dilek wrote:
> > > > Can you share this "rebased to mainline"
I run a perf session looks like this in my KDE/Plasma desktop-environment:
[ PERF SESSION ]
1016 2020-08-13 09:57:24 echo 1 > /proc/sys/kernel/sched_schedstats
1017 2020-08-13 09:57:24 echo prandom_u32 >>
/sys/kernel/debug/tracing/set_event
1018 2020-08-13 09:57:24 echo traceon >
/sys/kerne
USB alternate seeting of which the packet size is distinct.
The patches are to expose the packet size to user space so that
the user space does not need to hard code those values.
We have verified this patch on Chromebooks which use
- Realtek 8822CE controller with USB alt setting 1
- Intel contro
It is desirable to define the HCI packet payload sizes of
USB alternate settings so that they can be exposed to user
space.
Reviewed-by: Alain Michaud
Reviewed-by: Abhishek Pandit-Subedi
Signed-off-by: Joseph Hwang
---
drivers/bluetooth/btusb.c| 43
in
It is desirable to expose the wideband speech packet length via
a socket option to the user space so that the user space can set
the value correctly in configuring the sco connection.
Reviewed-by: Alain Michaud
Reviewed-by: Abhishek Pandit-Subedi
Signed-off-by: Joseph Hwang
---
include/net/bl
The Common Management Interface Specification (CMIS) for QSFP-DD shares
some similarities with other form factors such as QSFP or SFP, but due to
the fact that the module memory map is different, the current ethtool
version is not able to provide relevant information about an interface.
This patch
Hi Andrew!
I removed all the comments/constants/structs/functions that were
assuming the existence of page 0x10 and 0x11. I sent v3 to Ido (before
submitting it), he helped me test it and everything works fine. Please
let me know if there's anything else that should be changed.
Also, I just notic
On Thu, Aug 13, 2020 at 10:17:35AM +0300, Adrian Pop wrote:
> The Common Management Interface Specification (CMIS) for QSFP-DD shares
> some similarities with other form factors such as QSFP or SFP, but due to
> the fact that the module memory map is different, the current ethtool
> version is not
syzbot has found a reproducer for the following issue on:
HEAD commit:ce8056d1 wip: changed copy_from_user where instrumented
git tree: https://github.com/google/kmsan.git master
console output: https://syzkaller.appspot.com/x/log.txt?x=1015b61690
kernel config: https://syzkaller.ap
Hi!
Sorry for that. I'll resubmit v4 and I'll add diff from v1, diff from
v2 and diff from v3.
I will also add Michal Kubecek.
Adrian
On Thu, 13 Aug 2020 at 12:24, Ido Schimmel wrote:
>
> On Thu, Aug 13, 2020 at 10:17:35AM +0300, Adrian Pop wrote:
> > The Common Management Interface Specificati
Denis Gubin writes:
> Hello everybody!
>
> Could you help me, please?
>
> I use Debian 10 and iproute2 version iproute2
>
> dpkg -l iproute2
> iproute2 4.20.0-2 amd64
>
> My problem is this:
> I can't convert "tc -j filter show u32" command to json format.
> Here it is command:
> tc qdisc
Jonathan Adams writes:
How is that related to core? The x86 subsys prefix is 'x86' and for this
particular thing it's 'x86/irq:'. That applies to the rest of the series
as well.
> Add metricfs support for displaying percpu irq counters for x86.
> The top directory is /sys/kernel/debug/metricfs/
The Common Management Interface Specification (CMIS) for QSFP-DD shares
some similarities with other form factors such as QSFP or SFP, but due to
the fact that the module memory map is different, the current ethtool
version is not able to provide relevant information about an interface.
This patch
Hi Rob,
On 12/08/20 22:36, Rob Herring wrote:
> Clean-up incorrect indentation, extra spaces, long lines, and missing
> EOF newline in schema files. Most of the clean-ups are for list
> indentation which should always be 2 spaces more than the preceding
> keyword.
>
> Found with yamllint (which I
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c: In function
‘i40e_set_vsi_promisc’:
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:1176:14: error: ‘aq_ret’ may
be used uninitialized in this function [-Werror=maybe-uninitialized]
i40e_status aq_ret;
In case the code inside the if statem
On Thu, Aug 13, 2020 at 12:48:10PM +0200, Dmitry Vyukov wrote:
> On Fri, Jun 5, 2020 at 6:44 PM Eric Dumazet wrote:
> >
> > On 6/5/20 5:00 AM, Matthew Wilcox wrote:
> > > From: "Matthew Wilcox (Oracle)"
> > >
> > > The XArray interface is easier for this driver to use. Also fixes a
> > > bug rep
The var extra_uref is introduced to pass the initial reference taken in
sock_zerocopy_alloc to the first generated skb. But now we may fail to pass
the initial reference with newly allocated UDP or RAW uarg when the skb is
zcopied.
If the skb is zcopied, we always set extra_uref to false. This is
On 13/08/20 12:11, Thomas Gleixner wrote:
>> Add metricfs support for displaying percpu irq counters for x86.
>> The top directory is /sys/kernel/debug/metricfs/irq_x86.
>> Then there is a subdirectory for each x86-specific irq counter.
>> For example:
>>
>>cat /sys/kernel/debug/metricfs/irq_x8
If the skb is zcopied, we should increase the skb_uarg refcount before we
involve skb_release_data(). See pskb_expand_head() as a reference.
Fixes: 6fa01ccd8830 ("skbuff: Add pskb_extract() helper function")
Signed-off-by: Miaohe Lin
---
net/core/skbuff.c | 2 ++
1 file changed, 2 insertions(+)
Paolo Bonzini writes:
> On 13/08/20 12:11, Thomas Gleixner wrote:
>>> Add metricfs support for displaying percpu irq counters for x86.
>>> The top directory is /sys/kernel/debug/metricfs/irq_x86.
>>> Then there is a subdirectory for each x86-specific irq counter.
>>> For example:
>>>
>>>cat /
Hello,
I am testing ethtool 5.8, and I noticed it segfaulted with the command
ethtool -s eth0 autoneg on
Backtrace as follows:
(gdb) run -s eth0 autoneg on
Starting program: /tmp/ethtool-5.8 -s eth0 autoneg on
Program received signal SIGSEGV, Segmentation fault.
0x0040bef8 in do_sset ()
(gdb)
On Thu, Aug 13, 2020 at 1:59 PM Miaohe Lin wrote:
>
> The var extra_uref is introduced to pass the initial reference taken in
> sock_zerocopy_alloc to the first generated skb. But now we may fail to pass
> the initial reference with newly allocated UDP or RAW uarg when the skb is
> zcopied.
>
> If
On Thu, Aug 13, 2020 at 2:16 PM Miaohe Lin wrote:
>
> If the skb is zcopied, we should increase the skb_uarg refcount before we
> involve skb_release_data(). See pskb_expand_head() as a reference.
Did you manage to observe a bug through this datapath in practice?
pskb_carve_inside_header is call
Jakub Kicinski writes:
On Wed, 12 Aug 2020 13:10:57 +0300 Shay Agroskin wrote:
This patch also removes the destruction of the timer and reset
services
from ena_remove() since the timer is destroyed by the
destruction
routine and the reset work is handled by this patch.
You'd still have a
On 2020-08-11 7:25 p.m., Cong Wang wrote:
On Sun, Aug 9, 2020 at 4:41 PM Jamal Hadi Salim wrote:
[..]
Not sure if I get you correctly, but with a combined implementation
you can do above too, right? Something like:
(AND case)
$TC filter add dev $DEV1 parent : protocol ip prio 3 handle 1
Em Wed, Aug 12, 2020 at 07:31:32PM -0700, Tom Hebb escreveu:
> On Wed, Aug 12, 2020 at 3:15 PM Daniel Díaz wrote:
> > Makefile.config:414: *** No gnu/libc-version.h found, please install
> > glibc-dev[el]. Stop.
> > Makefile.perf:230: recipe for target 'sub-make' failed
> > make[1]: *** [s
- On Aug 12, 2020, at 5:43 PM, David S. Miller da...@davemloft.net wrote:
> From: Mathieu Desnoyers
> Date: Tue, 11 Aug 2020 15:50:02 -0400
>
>> @@ -465,6 +465,7 @@ static struct rtable *icmp_route_lookup(struct net *net,
>> int type, int code,
>>
On Thu, Aug 13, 2020 at 1:30 AM Jay Vosburgh wrote:
>
> Jarod Wilson wrote:
>
> >Broadcast mode bonds transmit a copy of all traffic simultaneously out of
> >all interfaces, so the "speed" of the bond isn't really the aggregate of
> >all interfaces, but rather, the speed of the lowest active inte
These values come from skb->data so Smatch considers them untrusted. I
believe Smatch is correct but I don't have a way to test this.
The usb_if->dev[] array has 2 elements but the index is in the 0-15
range without checks. The cfd->len can be up to 255 but the maximum
valid size is CANFD_MAX_DL
Broadcast mode bonds transmit a copy of all traffic simultaneously out of
all interfaces, so the "speed" of the bond isn't really the aggregate of
all interfaces, but rather, the speed of the slowest active interface.
Also, the type of the speed field is u32, not unsigned long, so adjust
that acco
On 13/08/20 14:13, Thomas Gleixner wrote:
Add metricfs support for displaying percpu irq counters for x86.
The top directory is /sys/kernel/debug/metricfs/irq_x86.
Then there is a subdirectory for each x86-specific irq counter.
For example:
cat /sys/kernel/debug/met
Paolo Bonzini writes:
> On 13/08/20 14:13, Thomas Gleixner wrote:
>cat /sys/kernel/debug/metricfs/irq_x86/TLB/values
What is 'TLB'? I'm not aware of any vector which is named TLB.
>>> There's a "TLB" entry in /proc/interrupts.
>> It's TLB shootdowns and not TLB.
>
> Yes but it's using
Xiumei reported a bug with espintcp over IPv6 in transport mode,
because xfrm6_transport_finish expects to find IP6CB data (struct
inet6_skb_cb). Currently, espintcp zeroes the CB, but the relevant
part is actually preserved by previous layers (first set up by tcp,
then strparser only zeroes a smal
Turns out there were a few more instances where libbpf didn't save the
errno before writing an error message, causing errno to be overridden by
the printf() return and the error disappearing if logging is enabled.
Signed-off-by: Toke Høiland-Jørgensen
---
tools/lib/bpf/libbpf.c | 12 +++-
ppc6xx_defconfig fails building sfc.ko module, complaining
about the lack of _umoddi3 symbol.
This is due to the following test
if (EFX_MIN_DMAQ_SIZE % reader->value) {
Because reader->value is u64.
As EFX_MIN_DMAQ_SIZE value is 512, reader->value is obviously small
enough for a
On 13/08/2020 15:39, Christophe Leroy wrote:
> ppc6xx_defconfig fails building sfc.ko module, complaining
> about the lack of _umoddi3 symbol.
>
> This is due to the following test
>
> if (EFX_MIN_DMAQ_SIZE % reader->value) {
>
> Because reader->value is u64.
Already fixed in net.git
Looks good, sorry:
Reviewed-by: Christoph Hellwig
On Thu, Aug 13, 2020 at 02:39:10PM +, Christophe Leroy wrote:
> ppc6xx_defconfig fails building sfc.ko module, complaining
> about the lack of _umoddi3 symbol.
>
> This is due to the following test
>
> if (EFX_MIN_DMAQ_SIZE % reader->value) {
>
> Because reader->value is u64.
>
On Thu, Aug 13, 2020 at 4:00 PM Eric Dumazet wrote:
>
> On Thu, Aug 13, 2020 at 1:27 AM Sedat Dilek wrote:
> >
> > I run a perf session looks like this in my KDE/Plasma desktop-environment:
> >
> > [ PERF SESSION ]
> >
> > 1016 2020-08-13 09:57:24 echo 1 > /proc/sys/kernel/sched_schedstats
> >
On Thu, 13 Aug 2020 09:46:11 +0200 Florian Westphal wrote:
> Fixes: fc66de8e16e ("netfilter/ebtables: clean up compat {get, set}sockopt
> handling")
Fixes tag: Fixes: fc66de8e16e ("netfilter/ebtables: clean up compat {get,
set}sockopt handling")
Has these problem(s):
- SHA1 should be at
Hello,
syzbot found the following issue on:
HEAD commit:ce8056d1 wip: changed copy_from_user where instrumented
git tree: https://github.com/google/kmsan.git master
console output: https://syzkaller.appspot.com/x/log.txt?x=14680fd690
kernel config: https://syzkaller.appspot.com/x/.
On Tue, Aug 11, 2020 at 10:26 AM Hideaki Yoshifuji
wrote:
>
> Hi,
>
> 2020年8月9日(日) 19:52 Xin Long :
> >
> > On Fri, Aug 7, 2020 at 5:26 PM Hideaki Yoshifuji
> > wrote:
> > >
> > > Hi,
> > >
> > > 2020年8月6日(木) 23:03 David Ahern :
> > > >
> > > > On 8/6/20 2:55 AM, Xin Long wrote:
> > > > > On Thu,
On Thu, Aug 13, 2020 at 7:29 AM Toke Høiland-Jørgensen wrote:
>
> Turns out there were a few more instances where libbpf didn't save the
> errno before writing an error message, causing errno to be overridden by
> the printf() return and the error disappearing if logging is enabled.
>
> Signed-off
Hi Eric,
On Thu, Aug 13, 2020 at 09:18:34AM -0700, Eric Dumazet wrote:
> syzbot found that at least 2 bytes of kernel information
> were leaked during getsockname() on AF_CAN CAN_J1939 socket.
>
> Since struct sockaddr_can has in fact two holes, simply
> clear the whole area before filling it wit
The Common Management Interface Specification (CMIS) for QSFP-DD shares
some similarities with other form factors such as QSFP or SFP, but due to
the fact that the module memory map is different, the current ethtool
version is not able to provide relevant information about an interface.
This patch
On Thu, Aug 13, 2020 at 7:06 PM Eric Dumazet wrote:
>
> There has been some heat around prandom_u32() lately, and some people
> were wondering if there was a simple way to determine how often
> it was used, before considering making it maybe 10 times more expensive.
>
> This tracepoint exports the
1. Added a skb->len check
This driver expects upper layers to include a pseudo header of 1 byte
when passing down a skb for transmission. This driver will read this
1-byte header. This patch added a skb->len check before reading the
header to make sure the header exists.
2. Added needed_headroom
On Wed, Aug 12, 2020 at 2:59 AM wrote:
>
> From: Tonghao Zhang
>
> To avoid some issues, for example RCU usage warning and double free,
> we should flush the flows under ovs_lock. This patch refactors
> table_instance_destroy and introduces table_instance_flow_flush
> which can be invoked by __dp
On Thu, Aug 13, 2020 at 12:17:13AM -0700, Andrii Nakryiko wrote:
> This patch set contains fixes to libbpf, bpftool, and selftests that were
> found while testing libbpf and selftests built in 32-bit mode. 64-bit nature
> of BPF target and 32-bit host environment don't always mix together well
> wi
After @blk_fill_in_prog_lock is acquired there is an early out vnet
situation that can occur. In that case, the rwlock needs to be
released.
Also, since @blk_fill_in_prog_lock is only acquired when @tp_version
is exactly TPACKET_V3, only release it on that exact condition as
well.
And finally, ad
Andrii Nakryiko writes:
> On Thu, Aug 13, 2020 at 7:29 AM Toke Høiland-Jørgensen
> wrote:
>>
>> Turns out there were a few more instances where libbpf didn't save the
>> errno before writing an error message, causing errno to be overridden by
>> the printf() return and the error disappearing if
A user reported that packets from wireguard were possibly ignored by XDP
[1]. Another user reported that modifying packets from layer 3
interfaces results in impossible to diagnose drops.
Apparently, the generic skb xdp handler path seems to assume that
packets will always have an ethernet header,
On Thu, Aug 13, 2020 at 12:20 PM Alexei Starovoitov
wrote:
>
> On Thu, Aug 13, 2020 at 12:17:13AM -0700, Andrii Nakryiko wrote:
> > This patch set contains fixes to libbpf, bpftool, and selftests that were
> > found while testing libbpf and selftests built in 32-bit mode. 64-bit nature
> > of BPF
On 8/13/20 9:52 PM, Toke Høiland-Jørgensen wrote:
Andrii Nakryiko writes:
On Thu, Aug 13, 2020 at 7:29 AM Toke Høiland-Jørgensen wrote:
Turns out there were a few more instances where libbpf didn't save the
errno before writing an error message, causing errno to be overridden by
the printf()
Fix few compilation warnings in bpftool when compiling in 32-bit mode.
Abstract away u64 to pointer conversion into a helper function.
Signed-off-by: Andrii Nakryiko
---
tools/bpf/bpftool/btf_dumper.c | 2 +-
tools/bpf/bpftool/link.c | 4 ++--
tools/bpf/bpftool/main.h | 10
Fix compilation warnings emitted when compiling selftests for 32-bit platform
(x86 in my case).
Signed-off-by: Andrii Nakryiko
---
tools/testing/selftests/bpf/prog_tests/bpf_obj_id.c | 8
tools/testing/selftests/bpf/prog_tests/core_extern.c| 4 ++--
tools/testing/selftests/bpf/p
Ensure that types are memory layout- and field alignment-compatible regardless
of 32/64-bitness mix of libbpf and BPF architecture.
Signed-off-by: Andrii Nakryiko
---
.../selftests/bpf/prog_tests/core_reloc.c | 20 +++---
.../selftests/bpf/progs/core_reloc_types.h| 69 ++-
Despite bpftool generating data section memory layout that will work for
32-bit architectures on user-space side, BPF programs should be careful to not
use ambiguous types like `long`, which have different size in 32-bit and
64-bit environments. Fix that in test by using __u64 explicitly, which is
Libbpf built in 32-bit mode should be careful about not conflating 64-bit BPF
pointers in BPF ELF file and host architecture pointers. This patch fixes
issue of incorrect initializating of map-in-map inner map slots due to such
difference.
Fixes: 646f02ffdd49 ("libbpf: Add BTF-defined map-in-map s
With libbpf and BTF it is pretty common to have libbpf built for one
architecture, while BTF information was generated for a different architecture
(typically, but not always, BPF). In such case, the size of a pointer might
differ betweem architectures. libbpf previously was always making an
assump
BPF object files are always targeting 64-bit BPF target architecture, so
enforce that at BTF level as well.
Signed-off-by: Andrii Nakryiko
---
tools/lib/bpf/libbpf.c | 4
1 file changed, 4 insertions(+)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 4a8524b2dda1..738579
Fix btf_dump test cases by hard-coding BPF's pointer size of 8 bytes for cases
where it's impossible to deterimne the pointer size (no long type in BTF). In
cases where it's known, validate libbpf correctly determines it as 8.
Signed-off-by: Andrii Nakryiko
---
.../selftests/bpf/prog_tests/btf_d
The comment in the code describes this in good details. Generate such a memory
layout that would work both on 32-bit and 64-bit architectures for user-space.
Signed-off-by: Andrii Nakryiko
---
tools/bpf/bpftool/gen.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/tools/bpf/b
On Thu, 13 Aug 2020 15:51:46 +0300 Shay Agroskin wrote:
> Long answer:
> The ena_destroy_device() function is called with rtnl_lock() held,
> so it cannot run in parallel with the reset function. Also the
> destroy function clears the bit ENA_FLAG_TRIGGER_RESET without
> which the reset function
On Thu, Aug 13, 2020 at 1:39 PM Andrii Nakryiko wrote:
>
> With libbpf and BTF it is pretty common to have libbpf built for one
> architecture, while BTF information was generated for a different architecture
> (typically, but not always, BPF). In such case, the size of a pointer might
> differ be
On Thu, 13 Aug 2020 13:26:38 +0200 Stefan Assmann wrote:
> drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c: In function
> ‘i40e_set_vsi_promisc’:
> drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:1176:14: error: ‘aq_ret’
> may be used uninitialized in this function [-Werror=maybe-uninitiali
Ensure that types are memory layout- and field alignment-compatible regardless
of 32/64-bitness mix of libbpf and BPF architecture.
Signed-off-by: Andrii Nakryiko
---
.../selftests/bpf/prog_tests/core_reloc.c | 20 +++---
.../selftests/bpf/progs/core_reloc_types.h| 69 ++-
Fix btf_dump test cases by hard-coding BPF's pointer size of 8 bytes for cases
where it's impossible to deterimne the pointer size (no long type in BTF). In
cases where it's known, validate libbpf correctly determines it as 8.
Signed-off-by: Andrii Nakryiko
---
.../selftests/bpf/prog_tests/btf_d
The comment in the code describes this in good details. Generate such a memory
layout that would work both on 32-bit and 64-bit architectures for user-space.
Signed-off-by: Andrii Nakryiko
---
tools/bpf/bpftool/gen.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/tools/bpf/b
Despite bpftool generating data section memory layout that will work for
32-bit architectures on user-space side, BPF programs should be careful to not
use ambiguous types like `long`, which have different size in 32-bit and
64-bit environments. Fix that in test by using __u64 explicitly, which is
Libbpf built in 32-bit mode should be careful about not conflating 64-bit BPF
pointers in BPF ELF file and host architecture pointers. This patch fixes
issue of incorrect initializating of map-in-map inner map slots due to such
difference.
Fixes: 646f02ffdd49 ("libbpf: Add BTF-defined map-in-map s
Daniel Borkmann writes:
> On 8/13/20 9:52 PM, Toke Høiland-Jørgensen wrote:
>> Andrii Nakryiko writes:
>>> On Thu, Aug 13, 2020 at 7:29 AM Toke Høiland-Jørgensen
>>> wrote:
Turns out there were a few more instances where libbpf didn't save the
errno before writing an error messa
This patch set contains fixes to libbpf, bpftool, and selftests that were
found while testing libbpf and selftests built in 32-bit mode. 64-bit nature
of BPF target and 32-bit host environment don't always mix together well
without extra care, so there were a bunch of problems discovered and fixed.
With libbpf and BTF it is pretty common to have libbpf built for one
architecture, while BTF information was generated for a different architecture
(typically, but not always, BPF). In such case, the size of a pointer might
differ betweem architectures. libbpf previously was always making an
assump
On Thu, 13 Aug 2020 21:58:16 +0200 Jason A. Donenfeld wrote:
> - cls_bpf does not support the same feature set as XDP, and operates at
> a slightly different stage in the networking stack.
Please elaborate.
> I had originally dropped this patch, but the issue kept coming up in
> user reports, s
Fix compilation warnings emitted when compiling selftests for 32-bit platform
(x86 in my case).
Signed-off-by: Andrii Nakryiko
---
tools/testing/selftests/bpf/prog_tests/bpf_obj_id.c | 8
tools/testing/selftests/bpf/prog_tests/core_extern.c| 4 ++--
tools/testing/selftests/bpf/p
BPF object files are always targeting 64-bit BPF target architecture, so
enforce that at BTF level as well.
Signed-off-by: Andrii Nakryiko
---
tools/lib/bpf/libbpf.c | 4
1 file changed, 4 insertions(+)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 4a8524b2dda1..738579
On 8/13/20 8:08 AM, Adrian Pop wrote:
The Common Management Interface Specification (CMIS) for QSFP-DD shares
some similarities with other form factors such as QSFP or SFP, but due to
the fact that the module memory map is different, the current ethtool
version is not able to provide relevant i
On Wed, Aug 12, 2020 at 10:29:56PM -0700, Jay Vosburgh wrote:
> Did you notice this by inspection, or did it come up in use
> somewhere? I can't recall ever hearing of anyone using broadcast mode,
> so I'm curious if there is a use for it, but this change seems
> reasonable enough regardless
On 8/12/20 12:04 AM, John Fastabend wrote:
[...]
v2->v3: Updated commit msg in patch1 to include ommited line of asm
output, per Daniels comment.
v1->v2: Added fix sk access case
Applied, thanks!
Fix few compilation warnings in bpftool when compiling in 32-bit mode.
Abstract away u64 to pointer conversion into a helper function.
Signed-off-by: Andrii Nakryiko
---
tools/bpf/bpftool/btf_dumper.c | 2 +-
tools/bpf/bpftool/link.c | 4 ++--
tools/bpf/bpftool/main.h | 10
This patch set contains fixes to libbpf, bpftool, and selftests that were
found while testing libbpf and selftests built in 32-bit mode. 64-bit nature
of BPF target and 32-bit host environment don't always mix together well
without extra care, so there were a bunch of problems discovered and fixed.
From: Eric Dumazet
Date: Thu, 13 Aug 2020 10:06:43 -0700
> There has been some heat around prandom_u32() lately, and some people
> were wondering if there was a simple way to determine how often
> it was used, before considering making it maybe 10 times more expensive.
>
> This tracepoint export
From: John Ogness
Date: Thu, 13 Aug 2020 21:45:25 +0206
> After @blk_fill_in_prog_lock is acquired there is an early out vnet
> situation that can occur. In that case, the rwlock needs to be
> released.
>
> Also, since @blk_fill_in_prog_lock is only acquired when @tp_version
> is exactly TPACKET
1 - 100 of 111 matches
Mail list logo
