BTF verifier has a size resolution bug which in some circumstances leads to
invalid size resolution for, e.g., TYPEDEF modifier. This happens if we have
[1] PTR -> [2] TYPEDEF -> [3] ARRAY, in which case due to being in pointer
context ARRAY size won't be resolved (because for pointer it doesn't m
BTF size resolution logic isn't always resolving type size correctly, leading
to erroneous map creation failures due to value size mismatch.
This patch set:
1. fixes the issue (patch #1);
2. adds tests for trickier cases (patch #2);
3. and converts few test cases utilizing BTF-defined maps, that p
Add more BTF tests, validating that size resolution logic is correct in
few trickier cases.
Signed-off-by: Andrii Nakryiko
---
tools/testing/selftests/bpf/test_btf.c | 88 ++
1 file changed, 88 insertions(+)
diff --git a/tools/testing/selftests/bpf/test_btf.c
b/tools/te
Convert few tests that couldn't use typedef'ed arrays due to kernel bug.
Signed-off-by: Andrii Nakryiko
---
tools/testing/selftests/bpf/progs/test_get_stack_rawtp.c | 3 ++-
tools/testing/selftests/bpf/progs/test_stacktrace_build_id.c | 3 +--
tools/testing/selftests/bpf/progs/test_stacktrac
On Wed, Jul 10, 2019 at 04:43:18PM -0600, David Ahern wrote:
> On 7/9/19 8:43 AM, Stephen Hemminger wrote:
> > Looks like the stricter netlink validation broke userspace.
> > This is bad.
Actually, the initial bug in systemd and it is where it should be fixed.
>
> I believe other reports have tra
On Wed, Jul 10, 2019 at 9:14 PM Yonghong Song wrote:
>
>
>
> On 7/10/19 6:45 PM, Andrii Nakryiko wrote:
> > On Wed, Jul 10, 2019 at 5:36 PM Yonghong Song wrote:
> >>
> >>
> >>
> >> On 7/10/19 5:29 PM, Andrii Nakryiko wrote:
> >>> On Wed, Jul 10, 2019 at 5:16 PM Yonghong Song wrote:
>
>
On Wed, Jul 10, 2019 at 6:53 PM Yonghong Song wrote:
>
>
>
> On 7/10/19 6:45 PM, Andrii Nakryiko wrote:
> > On Wed, Jul 10, 2019 at 5:36 PM Yonghong Song wrote:
> >>
> >>
> >>
> >> On 7/10/19 5:29 PM, Andrii Nakryiko wrote:
> >>> On Wed, Jul 10, 2019 at 5:16 PM Yonghong Song wrote:
>
>
On 7/10/19 6:45 PM, Andrii Nakryiko wrote:
> On Wed, Jul 10, 2019 at 5:36 PM Yonghong Song wrote:
>>
>>
>>
>> On 7/10/19 5:29 PM, Andrii Nakryiko wrote:
>>> On Wed, Jul 10, 2019 at 5:16 PM Yonghong Song wrote:
On 7/10/19 1:08 AM, Andrii Nakryiko wrote:
> BTF verifier has
On 7/10/19 6:45 PM, Andrii Nakryiko wrote:
> On Wed, Jul 10, 2019 at 5:36 PM Yonghong Song wrote:
>>
>>
>>
>> On 7/10/19 5:29 PM, Andrii Nakryiko wrote:
>>> On Wed, Jul 10, 2019 at 5:16 PM Yonghong Song wrote:
On 7/10/19 1:08 AM, Andrii Nakryiko wrote:
> BTF verifier has
On Wed, Jul 10, 2019 at 5:36 PM Yonghong Song wrote:
>
>
>
> On 7/10/19 5:29 PM, Andrii Nakryiko wrote:
> > On Wed, Jul 10, 2019 at 5:16 PM Yonghong Song wrote:
> >>
> >>
> >>
> >> On 7/10/19 1:08 AM, Andrii Nakryiko wrote:
> >>> BTF verifier has Different logic depending on whether we are follow
test_verifier tests can specify single- and multi-runs tests. Internally
logic of handling them is duplicated. Get rid of it by making single run
retval specification to be a first retvals spec.
Cc: Krzesimir Nowak
Signed-off-by: Andrii Nakryiko
---
tools/testing/selftests/bpf/test_verifier.c |
On 7/10/19 5:29 PM, Andrii Nakryiko wrote:
> On Wed, Jul 10, 2019 at 5:16 PM Yonghong Song wrote:
>>
>>
>>
>> On 7/10/19 1:08 AM, Andrii Nakryiko wrote:
>>> BTF verifier has Different logic depending on whether we are following
>>> a PTR or STRUCT/ARRAY (or something else). This is an optimizati
在 2019/7/11 2:25, Vlad Buslov 写道:
> Recent refactoring of tc block offloads infrastructure introduced new
> flow_block_cb_setup_simple() method intended to be used as unified way for
> all drivers to register offload callbacks. However, commit that actually
> extended all users (drivers) with blo
On Wed, Jul 10, 2019 at 5:16 PM Yonghong Song wrote:
>
>
>
> On 7/10/19 1:08 AM, Andrii Nakryiko wrote:
> > BTF verifier has Different logic depending on whether we are following
> > a PTR or STRUCT/ARRAY (or something else). This is an optimization to
> > stop early in DFS traversal while resolvi
On Wed, Jul 10, 2019 at 09:52:27AM +0200, Jiri Pirko wrote:
> Tue, Jul 09, 2019 at 10:55:50PM CEST, pa...@netfilter.org wrote:
>
> [...]
>
> >+if (!dev || !dev->netdev_ops->ndo_setup_tc)
>
> Why didn't you rename ndo_setup_tc? I put a comment about it in the
> previous version thread. I expe
On 7/10/19 1:08 AM, Andrii Nakryiko wrote:
> BTF verifier has Different logic depending on whether we are following
> a PTR or STRUCT/ARRAY (or something else). This is an optimization to
> stop early in DFS traversal while resolving BTF types. But it also
> results in a size resolution bug, when
No need to annotate the netns on the flow block callback object,
flow_block_cb_is_busy() already checks for used blocks.
Fixes: d63db30c8537 ("net: flow_offload: add flow_block_cb_alloc() and
flow_block_cb_free()")
Signed-off-by: Pablo Neira Ayuso
---
drivers/net/ethernet/mellanox/mlx5/core/en_
Rename this type definition and adapt users.
Signed-off-by: Pablo Neira Ayuso
---
This patch is a dependency for patch 3/3, so include/net/flow_offload.h
does not need to include include/net/sch_cls.h, and hence avoid a
circular inclusion.
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 2 +-
This object stores the flow block callbacks that are attached to this
block. This patch restores block sharing.
Fixes: da3eeb904ff4 ("net: flow_offload: add list handling functions")
Signed-off-by: Pablo Neira Ayuso
---
include/net/flow_offload.h| 5 +
include/net/netfilter/nf_table
> > Reading csum_partial/csum_fold, seems like after calculation of
> > checksum (so-called unfolded checksum), it is supposed to be passed
> > into csum_fold() to convert it into 16-bit one and invert.
Yes, you always need to fold at the end.
The low level code does fold sometimes, but not alway
On Wed, Jul 10, 2019 at 09:25:54PM +0300, Vlad Buslov wrote:
> Recent refactoring of tc block offloads infrastructure introduced new
> flow_block_cb_setup_simple() method intended to be used as unified way for
> all drivers to register offload callbacks. However, commit that actually
> extended all
On Thu, Jul 11, 2019 at 12:03:37AM +0200, Pablo Neira Ayuso wrote:
> On Wed, Jul 10, 2019 at 09:45:04PM +0800, we...@ucloud.cn wrote:
> > From: wenxu
> >
> > [ 697.665184] BUG: kernel NULL pointer dereference, address:
> > 0030
> > [ 697.665550] #PF: supervisor read access in kerne
On Wed, Jul 10, 2019 at 3:52 PM Andrii Nakryiko
wrote:
>
> cc Andi Kleen re: refactoring, do you have any insight here?
OK, let's try again...
>
> On Wed, Jul 10, 2019 at 3:12 AM Paolo Pisati wrote:
> >
> > On Mon, Jul 01, 2019 at 09:51:25PM +, Yonghong Song wrote:
> > >
> > > Below is the
cc Andi Kleen re: refactoring, do you have any insight here?
On Wed, Jul 10, 2019 at 3:12 AM Paolo Pisati wrote:
>
> On Mon, Jul 01, 2019 at 09:51:25PM +, Yonghong Song wrote:
> >
> > Below is the test case.
> > {
> > "valid read map access into a read-only array 2",
> > .in
2019-07-10, 16:07:43 +0100, Edward Cree wrote:
> On 10/07/2019 14:52, Sabrina Dubroca wrote:
> > -static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc,
> > +static int __netif_receive_skb_core(struct sk_buff **pskb, bool pfmemalloc,
> > struct pac
On 7/9/19 8:43 AM, Stephen Hemminger wrote:
> Looks like the stricter netlink validation broke userspace.
> This is bad.
I believe other reports have traced this to
commit 7dc2bccab0ee37ac28096b8fcdc390a679a15841
Author: Maxim Mikityanskiy
Date: Tue May 21 06:40:04 2019 +
Validate req
On 7/5/19 11:30 AM, Lorenzo Bianconi wrote:
> looking at the reproducer it seems to me the issue is due to the use of
> 'NTF_USE' from userspace.
> Should we unschedule the neigh timer if we are in IN_TIMER receiving this
> flag from userspace? (taking appropriate locking)
I think you are right. D
On Wed, Jul 10, 2019 at 10:18:30PM +0800, we...@ucloud.cn wrote:
> From: wenxu
>
> [ 3444.666552] BUG: kernel NULL pointer dereference, address:
> [ 3444.31] #PF: supervisor read access in kernel mode
> [ 3444.666701] #PF: error_code(0x) - not-present page
> [ 3444.666769
On Wed, Jul 10, 2019 at 09:45:04PM +0800, we...@ucloud.cn wrote:
> From: wenxu
>
> [ 697.665184] BUG: kernel NULL pointer dereference, address: 0030
> [ 697.665550] #PF: supervisor read access in kernel mode
> [ 697.665906] #PF: error_code(0x) - not-present page
> [ 697.666297
On 7/10/19 6:40 AM, John Hurley wrote:
> Recent kernel additions to TC allows the manipulation of MPLS headers as
> filter actions.
>
> The following patchset creates an iproute2 interface to the new actions
> and includes documentation on how to use it.
>
> v1->v2:
> - change error from print_st
On 7/10/19 6:39 AM, Parav Pandit wrote:
> Introduce PCI PF and VF port flavour and port attributes such as PF
> number and VF number.
>
> $ devlink port show
> pci/:05:00.0/0: type eth netdev eth0 flavour pcipf pfnum 0
> pci/:05:00.0/1: type eth netdev eth1 flavour pcivf pfnum 0 vfnum 0
>
On 7/7/19 11:51 AM, Vincent Bernat wrote:
> Ability to tweak the delay between gratuitous ND/ARP packets has been
> added in kernel commit 07a4ddec3ce9 ("bonding: add an option to
> specify a delay between peer notifications"), through
> IFLA_BOND_PEER_NOTIF_DELAY attribute. Add support to set and
On Wed, 10 Jul 2019 12:34:17 -0700, Jakub Kicinski wrote:
> > > > + if (sk->sk_prot->unhash)
> > > > + sk->sk_prot->unhash(sk);
> > > > + }
> > > > +
> > > > + ctx = tls_get_ctx(sk);
> > > > + if (ctx->tx_conf == TLS_SW || ctx->rx_conf == TLS_SW
On Tue, 09 Jul 2019 20:33:58 -0700, John Fastabend wrote:
> Jakub Kicinski wrote:
> > On Mon, 08 Jul 2019 19:15:18 +, John Fastabend wrote:
> > > @@ -352,15 +354,18 @@ static void tls_sk_proto_close(struct sock *sk,
> > > long timeout)
> > > if (ctx->tx_conf == TLS_BASE && ctx->rx_conf ==
On Tue, 09 Jul 2019 20:39:24 -0700, John Fastabend wrote:
> Jakub Kicinski wrote:
> > On Mon, 08 Jul 2019 19:14:05 +, John Fastabend wrote:
> > > @@ -287,6 +313,27 @@ static void tls_sk_proto_cleanup(struct sock *sk,
> > > #endif
> > > }
> > >
> > > +static void tls_sk_proto_unhash(struct
On 7/10/19 8:53 PM, Prout, Andrew - LLSC - MITLL wrote:
>
> Our initial rollout was v4.14.130, but I reproduced it with v4.14.132 as
> well, reliably for the samba test and once (not reliably) with synthetic test
> I was trying. A patched v4.14.132 with this patch partially reverted (just
>
On Wed, Jul 10, 2019 at 11:31 AM Javier Honduvilla Coto
wrote:
>
> Adding the following test cases:
FYI, bpf-next is closed, so this won't be able to go in for about 2 weeks.
>
> - bpf_descendant_of(current->pid) == 1
> - bpf_descendant_of(current->real_parent->pid) == 1
> - bpf_descendant_of(1)
On 7/10/19 1:09 PM, Stefano Brivio wrote:
> Jan,
>
> On Wed, 10 Jul 2019 12:59:41 +
> Jan Szewczyk wrote:
>
>> Hi!
>> I digged up a little further and maybe it's not a problem with MTU
>> itself. I checked every entry I get from RTM_GETROUTE netlink message
>> and after triggering "too big p
Jan,
On Wed, 10 Jul 2019 12:59:41 +
Jan Szewczyk wrote:
> Hi!
> I digged up a little further and maybe it's not a problem with MTU
> itself. I checked every entry I get from RTM_GETROUTE netlink message
> and after triggering "too big packet" by pinging ipv6address I get
> exactly the same m
On Wed, Jul 10, 2019 at 11:18 AM Allan Zhang wrote:
>
> Software event output is only enabled by a few prog types right now (TC,
> LWT out, XDP, sockops). Many other skb based prog types need
> bpf_skb_event_output to produce software event.
>
> More prog types are enabled to access bpf_skb_event_
Hello,
This is with my hacked-upon kernel, could be my mistake, etc. But, curious
if anyone else has seen a similar deadlock? I was running a complicated
automated
wifi test, for what that is worth.
66707.212081] ath: regdomain 0x8348 dynamically updated by user
[67044.625948] INFO: task kwor
On 7/10/19 2:29 PM, Eric Dumazet wrote:
> On 7/10/19 8:23 PM, Prout, Andrew - LLSC - MITLL wrote:
>> On 6/17/19 8:19 PM, Christoph Paasch wrote:
>>>
>>> Yes, this does the trick for my packetdrill-test.
>>>
>>> I wonder, is there a way we could end up in a situation where we can't
>>> retransmit a
From: Ilya Leoshkevich
Date: Wed, 10 Jul 2019 13:56:54 +0200
> bpf_helpers.h fails to compile on sparc: the code should be checking
> for defined(bpf_target_sparc), but checks simply for bpf_target_sparc.
>
> Also change #ifdef bpf_target_powerpc to #if defined() for consistency.
>
> Signed-off
On 6/17/19 8:19 PM, Christoph Paasch wrote:
>
> Yes, this does the trick for my packetdrill-test.
>
> I wonder, is there a way we could end up in a situation where we can't
> retransmit anymore?
> For example, sk_wmem_queued has grown so much that the new test fails.
> Then, if we legitimately ne
NFP firmware does not explicitly match on an ethernet type field. Rather,
each rule has a bitmask of match fields that can be used to infer the
ethernet type.
Currently, if a flower rule contains an unknown ethernet type, a check is
carried out for matches on other fields of the packet. If matches
This patchset contains bug fixes for corner cases in the match fields of
flower offloads. The patches ensure that flows that should not be
supported are not (incorrectly) offloaded. These include rules that match
on layer 3 and/or 4 data without specified ethernet or ip protocol fields.
John Hurle
Flower rules on the NFP firmware are able to match on an IP protocol
field. When parsing rules in the driver, unknown IP protocols are only
rejected when further matches are to be carried out on layer 4 fields, as
the firmware will not be able to extract such fields from packets.
L4 protocol disse
On 7/10/19 8:23 PM, Prout, Andrew - LLSC - MITLL wrote:
> On 6/17/19 8:19 PM, Christoph Paasch wrote:
>>
>> Yes, this does the trick for my packetdrill-test.
>>
>> I wonder, is there a way we could end up in a situation where we can't
>> retransmit anymore?
>> For example, sk_wmem_queued has gro
Recent refactoring of tc block offloads infrastructure introduced new
flow_block_cb_setup_simple() method intended to be used as unified way for
all drivers to register offload callbacks. However, commit that actually
extended all users (drivers) with block cb list and provided it to
flow_block inf
From: allanzhang
Software event output is only enabled by a few prog types.
This test is to ensure that all supported types are enabled for
bpf_perf_event_output successfully.
Signed-off-by: Allan Zhang
Acked-by: Song Liu
---
tools/testing/selftests/bpf/test_verifier.c | 12 ++-
.../selftes
From: allanzhang
Software event output is only enabled by a few prog types right now (TC,
LWT out, XDP, sockops). Many other skb based prog types need
bpf_skb_event_output to produce software event.
Added socket_filter, cg_skb, sk_skb prog types to generate sw event.
Test bpf code is generated
Software event output is only enabled by a few prog types right now (TC,
LWT out, XDP, sockops). Many other skb based prog types need
bpf_skb_event_output to produce software event.
More prog types are enabled to access bpf_skb_event_output in this
patch.
v9 changes:
add "Acked-by" field.
v8 cha
On Tue, Jul 9, 2019 at 11:03 AM Allan Zhang wrote:
>
> Software event output is only enabled by a few prog types right now (TC,
> LWT out, XDP, sockops). Many other skb based prog types need
> bpf_skb_event_output to produce software event.
>
> More prog types are enabled to access bpf_skb_event_o
Adding the following test cases:
- bpf_descendant_of(current->pid) == 1
- bpf_descendant_of(current->real_parent->pid) == 1
- bpf_descendant_of(1) == 1
- bpf_descendant_of(0) == 1
- bpf_descendant_of(-1) == 0
- bpf_descendant_of(current->children[0]->pid) == 0
Signed-off-by: Javier Honduvilla Co
Sync kernel uapi headers.
Signed-off-by: Javier Honduvilla Coto
---
tools/include/uapi/linux/bpf.h | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 402208581b2d..505ee91898c2 100644
---
Hi all,
This patch adds the bpf_descendant_of helper which accepts a PID and
returns 1 if the PID of the process currently being executed is a
descendant of it or if it's itself. Returns 0 otherwise. The passed
PID should be the one as seen from the "global" pid namespace as the
processes' PIDs in
This patch adds the bpf_descendant_of helper which accepts a PID and
returns 1 if the PID of the process currently being executed is a
descendant of it or if it's itself. Returns 0 otherwise. The passed
PID should be the one as seen from the "global" pid namespace as the
processes' PIDs in the hier
On Thu, Jul 4, 2019 at 2:32 PM Jiong Wang wrote:
>
> Verification layer also needs to handle auxiliar info as well as adjusting
> subprog start.
>
> At this layer, insns inside patch buffer could be jump, but they should
> have been resolved, meaning they shouldn't jump to insn outside of the
> pa
On Thu, Jul 4, 2019 at 2:32 PM Jiong Wang wrote:
>
> This patch introduces list based bpf insn patching infra to bpf core layer
> which is lower than verification layer.
>
> This layer has bpf insn sequence as the solo input, therefore the tasks
> to be finished during list linerization is:
> -
On Thu, Jul 4, 2019 at 2:31 PM Jiong Wang wrote:
>
> This is an RFC based on latest bpf-next about acclerating insn patching
> speed, it is now near the shape of final PATCH set, and we could see the
> changes migrating to list patching would brings, so send out for
> comments. Most of the info ar
On 7/10/19 6:47 PM, Edward Cree wrote:
> On 10/07/2019 16:41, Eric Dumazet wrote:
>> On 7/10/19 4:52 PM, Edward Cree wrote:
>>> Hmm, I was caught out by the call to napi_poll() actually being a local
>>> function pointer, not the static function of the same name. How did a
>>> shadow like tha
On Wed, Jul 10, 2019 at 4:47 AM Ilya Leoshkevich wrote:
>
> > Am 09.07.2019 um 19:48 schrieb Andrii Nakryiko :
> >
> > On Tue, Jul 9, 2019 at 8:19 AM Ilya Leoshkevich wrote:
> >>
> >> Right now, on certain architectures, these macros are usable only with
> >> kernel headers. This patch makes it p
After recent refactoring of block offlads infrastructure, indr_dev->block
pointer is dereferenced before it is verified to be non-NULL. Example stack
trace where this behavior leads to NULL-pointer dereference error when
creating vxlan dev on system with mlx5 NIC with offloads enabled:
[ 1157.8529
On 7/9/19 11:48 PM, Jiri Pirko wrote:
Tue, Jul 09, 2019 at 09:13:53PM CEST, snel...@pensando.io wrote:
On 7/8/19 11:56 PM, Jiri Pirko wrote:
Tue, Jul 09, 2019 at 12:58:00AM CEST, snel...@pensando.io wrote:
On 7/8/19 1:03 PM, Jiri Pirko wrote:
Mon, Jul 08, 2019 at 09:58:09PM CEST, snel...@pens
On 10/07/2019 16:41, Eric Dumazet wrote:
> On 7/10/19 4:52 PM, Edward Cree wrote:
>> Hmm, I was caught out by the call to napi_poll() actually being a local
>> function pointer, not the static function of the same name. How did a
>> shadow like that ever get allowed?
>> But in that case I _reall
On Wed, Jul 10, 2019 at 4:57 AM Ilya Leoshkevich wrote:
>
> bpf_helpers.h fails to compile on sparc: the code should be checking
> for defined(bpf_target_sparc), but checks simply for bpf_target_sparc.
>
> Also change #ifdef bpf_target_powerpc to #if defined() for consistency.
>
> Signed-off-by: I
On 7/10/19 4:52 PM, Edward Cree wrote:
> Hmm, I was caught out by the call to napi_poll() actually being a local
> function pointer, not the static function of the same name. How did a
> shadow like that ever get allowed?
> But in that case I _really_ don't understand napi_busy_loop(); nothi
Hi,
as Jason suggested some months ago, I looked better at the virtio-net driver to
understand if we can reuse some parts also in the virtio-vsock driver, since we
have similar challenges (mergeable buffers, page allocation, small
packets, etc.).
Initially, I would add the skbuff in the virtio-vso
On 10/07/2019 14:52, Sabrina Dubroca wrote:
> When __netif_receive_skb_core handles a shared skb, it can be
> reallocated in a few different places:
> - the device's rx_handler
> - vlan_do_receive
> - skb_vlan_untag
>
> To deal with that, rx_handlers and vlan_do_receive get passed a
> reference
On 10/07/2019 08:27, Paolo Abeni wrote:
> I'm toying with a patch similar to your 3/3 (most relevant difference
> being the lack of a limit to the batch size), on top of ixgbe (which
> sends all the pkts to the GRO engine), and I'm observing more
> controversial results (UDP only):
>
> * when a sin
On 2019/7/10 13:32, Santosh Shilimkar wrote:
Connections with legitimate tos values can get into usual connection
race. It can result in consumer reject. We don't want tos value or
protocol version to be demoted for such connections otherwise
piers would end up different tos values which can re
On 2019/7/10 13:32, Santosh Shilimkar wrote:
From: Gerd Rausch
The proper "tos" value needs to be returned
to user-space (sockopt RDS_INFO_CONNECTIONS).
Fixes: 3eb450367d08 ("rds: add type of service(tos) infrastructure")
Signed-off-by: Gerd Rausch
Reviewed-by: Zhu Yanjun
Thanks. I am OK
On 2019/7/10 13:32, Santosh Shilimkar wrote:
From: Gerd Rausch
Prior to
commit d021fabf525ff ("rds: rdma: add consumer reject")
function "rds_rdma_cm_event_handler_cmn" would always honor a rejected
connection attempt by issuing a "rds_conn_drop".
The commit mentioned above added a "break",
On 2019/7/10 13:32, Santosh Shilimkar wrote:
RDS composite message(rdma + control) user notification needs to be
triggered once the full message is delivered and such a fix was
added as part of commit 941f8d55f6d61 ("RDS: RDMA: Fix the composite
message user notification"). But rds_send_remove_
From: wenxu
[ 3444.666552] BUG: kernel NULL pointer dereference, address:
[ 3444.31] #PF: supervisor read access in kernel mode
[ 3444.666701] #PF: error_code(0x) - not-present page
[ 3444.666769] PGD 800812dd7067 P4D 800812dd7067 PUD 8207cc067 PMD 0
[ 3444.666843
Wed, Jul 10, 2019 at 02:39:52PM CEST, pa...@mellanox.com wrote:
>Introduce PCI PF and VF port flavour and port attributes such as PF
>number and VF number.
>
>$ devlink port show
>pci/:05:00.0/0: type eth netdev eth0 flavour pcipf pfnum 0
>pci/:05:00.0/1: type eth netdev eth1 flavour pcivf
When __netif_receive_skb_core handles a shared skb, it can be
reallocated in a few different places:
- the device's rx_handler
- vlan_do_receive
- skb_vlan_untag
To deal with that, rx_handlers and vlan_do_receive get passed a
reference to the skb, and skb_vlan_untag just returns the new
skb. Th
From: wenxu
[ 697.665184] BUG: kernel NULL pointer dereference, address: 0030
[ 697.665550] #PF: supervisor read access in kernel mode
[ 697.665906] #PF: error_code(0x) - not-present page
[ 697.666297] PGD 80104e636067 P4D 80104e636067 PUD ff4b02067 PMD 0
[ 697.666710
Willem forgot to change one of the calls to fl6_sock_lookup(),
which can now return an error or NULL.
syzbot reported :
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: [#1] PREEMPT SMP KASAN
CPU: 1 PID: 31763 Com
fl_create() should call static_branch_deferred_inc() only in
case of success.
Also we should not call fl_free() in error path, as this could
cause a static key imbalance.
jump label: negative count!
WARNING: CPU: 0 PID: 15907 at kernel/jump_label.c:221 static_key_slow_try_dec
kernel/jump_label.c
In 323a53c41292 ("ipv6: tcp: enable flowlabel reflection in some RST packets")
and 50a8accf1062 ("ipv6: tcp: send consistent flowlabel in TIME_WAIT state")
we took care of IPv6 flowlabel reflections for two cases.
This patch takes care of the remaining case, when the RST packet
is sent on behalf o
On Tue, Jul 09, 2019 at 03:56:13PM -0500, Henry Orosco wrote:
> On Mon, Jul 08, 2019 at 02:13:39PM +, Jason Gunthorpe wrote:
> > On Sat, Jul 06, 2019 at 04:15:20PM +, Saleem, Shiraz wrote:
> > > > Subject: Re: [rdma 14/16] RDMA/irdma: Add ABI definitions
> > > >
> > > > On Fri, Jul 05, 201
dev_net(dev) is the netns of the device and xi->net is the link netns,
where the device has been linked.
changelink() must operate in the link netns to avoid a corruption of
the xfrm lists.
Note that xi->net and dev_net(xi->physdev) are always the same.
Before the patch, the xfrmi lists may be co
Hi!
I digged up a little further and maybe it's not a problem with MTU itself. I
checked every entry I get from RTM_GETROUTE netlink message and after
triggering "too big packet" by pinging ipv6address I get exactly the same
messages on 4.12 and 4.18, except that the one with that pinged ipv6add
Add a man page describing the newly added TC mpls manipulation actions.
Signed-off-by: John Hurley
Reviewed-by: Jakub Kicinski
---
man/man8/tc-mpls.8 | 156 +
1 file changed, 156 insertions(+)
create mode 100644 man/man8/tc-mpls.8
diff --git
Create a new action type for TC that allows the pushing, popping, and
modifying of MPLS headers.
Signed-off-by: John Hurley
Reviewed-by: Jakub Kicinski
---
tc/Makefile | 1 +
tc/m_mpls.c | 276
2 files changed, 277 insertions(+)
cr
Recent kernel additions to TC allows the manipulation of MPLS headers as
filter actions.
The following patchset creates an iproute2 interface to the new actions
and includes documentation on how to use it.
v1->v2:
- change error from print_string() to fprintf(strerr,) (Stephen Hemminger)
- split
Update the llproto_names array to allow users to reference the mpls
protocol ids with the names 'mpls_uc' for unicast MPLS and 'mpls_mc' for
multicast.
Signed-off-by: John Hurley
Reviewed-by: Jakub Kicinski
---
lib/ll_proto.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/ll_proto.c
Update kernel header to commit:
e41b6bf3cdd4 ("devlink: Introduce PCI VF port flavour and port attribute")
Signed-off-by: Parav Pandit
---
include/uapi/linux/devlink.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/uapi/linux/devlink.h b/include/uapi/linux/devlink.h
ind
Introduce PCI PF and VF port flavour and port attributes such as PF
number and VF number.
$ devlink port show
pci/:05:00.0/0: type eth netdev eth0 flavour pcipf pfnum 0
pci/:05:00.0/1: type eth netdev eth1 flavour pcivf pfnum 0 vfnum 0
pci/:05:00.0/2: type eth netdev eth2 flavour pcivf
[ adding netdev so others can chime in ]
On 7/10/19 2:28 AM, Jan Szewczyk wrote:
> Hi guys!
>
> We can see different behavior of one of our commands that supposed to
> show pmtu information.
>
> It’s using netlink message RTM_GETROUTE to get the information and in
> Linux kernel version 4.12 aft
On 09/07/2019 17:17, Michal Kalderon wrote:
> Create some common API's for adding entries to a xa_mmap.
> Searching for an entry and freeing one.
>
> The code was copied from the efa driver almost as is, just renamed
> function to be generic and not efa specific.
>
> Signed-off-by: Ariel Elior
>
On 09/07/2019 17:17, Michal Kalderon wrote:
> Remove the functions related to managing the mmap_xa database.
> This code was copied to the ib_core. Use the common API's instead.
>
> Signed-off-by: Ariel Elior
> Signed-off-by: Michal Kalderon
Thanks Michal,
Acked-by: Gal Pressman
bpf_helpers.h fails to compile on sparc: the code should be checking
for defined(bpf_target_sparc), but checks simply for bpf_target_sparc.
Also change #ifdef bpf_target_powerpc to #if defined() for consistency.
Signed-off-by: Ilya Leoshkevich
---
v1->v2: bpf_target_powerpc change
tools/testi
Wed, Jul 10, 2019 at 01:03:19PM CEST, tar...@mellanox.com wrote:
>From: Aya Levin
>
>Although devlink health dump show command is given per reporter, it
>returns large amounts of data. Trying to use the doit cb results in
>OUT-OF-BUFFER error. This complementary patch raises the DUMP flag in
>orde
> Am 09.07.2019 um 19:48 schrieb Andrii Nakryiko :
>
> On Tue, Jul 9, 2019 at 8:19 AM Ilya Leoshkevich wrote:
>>
>> Right now, on certain architectures, these macros are usable only with
>> kernel headers. This patch makes it possible to use them with userspace
>> headers and, as a consequence,
Ido Schimmel writes:
> On Tue, Jul 09, 2019 at 03:34:30PM -0700, Jakub Kicinski wrote:
>> On Tue, 9 Jul 2019 15:38:44 +0300, Ido Schimmel wrote:
>> > On Mon, Jul 08, 2019 at 03:51:58PM -0700, Jakub Kicinski wrote:
>> > > On Mon, 8 Jul 2019 16:19:08 +0300, Ido Schimmel wrote:
>> > > > On Sun, Ju
On Wed, Jul 10, 2019 at 12:43:45PM +0200, Vasily Gorbik wrote:
> Ilya Leoshkevich is joining as s390 bpf maintainer. With his background
> as gcc developer he would be valuable for the team and community as a
> whole. Ilya, have fun!
>
> Since there is now enough eyes on s390 bpf, relieve Christia
On Tue, Jul 09, 2019 at 03:34:30PM -0700, Jakub Kicinski wrote:
> On Tue, 9 Jul 2019 15:38:44 +0300, Ido Schimmel wrote:
> > On Mon, Jul 08, 2019 at 03:51:58PM -0700, Jakub Kicinski wrote:
> > > On Mon, 8 Jul 2019 16:19:08 +0300, Ido Schimmel wrote:
> > > > On Sun, Jul 07, 2019 at 12:45:41PM -070
On 2019-06-12 19:14, Maxim Mikityanskiy wrote:
> dev_change_xdp_fd doesn't perform any checks in case it uninstalls an
> XDP program. It means that the driver's ndo_bpf can be called with
> XDP_SETUP_PROG asking to set it to NULL even if it's already NULL. This
> case happens if the user runs `ip l
1 - 100 of 134 matches
Mail list logo
