* Re: [PATCH v2 net-next 1/9] lan743x: Add support for ethtool get_drvinfo
From: Andrew Lunn @ 2018-07-12 22:28 UTC (permalink / raw)
To: Bryan Whitehead; +Cc: davem, netdev, UNGLinuxDriver, richardcochran
In-Reply-To: <1531422306-6547-2-git-send-email-Bryan.Whitehead@microchip.com>
On Thu, Jul 12, 2018 at 03:04:58PM -0400, Bryan Whitehead wrote:
> Implement ethtool get_drvinfo
>
> Signed-off-by: Bryan Whitehead <Bryan.Whitehead@microchip.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net] net: Don't copy pfmemalloc flag in __copy_skb_header()
From: David Miller @ 2018-07-12 22:15 UTC (permalink / raw)
To: sbrivio; +Cc: mgorman, eric.dumazet, fw, ptalbert, netdev
In-Reply-To: <93db92329a9964c336965c166e5c858cf46cd0a5.1531305883.git.sbrivio@redhat.com>
From: Stefano Brivio <sbrivio@redhat.com>
Date: Wed, 11 Jul 2018 14:39:42 +0200
> The pfmemalloc flag indicates that the skb was allocated from
> the PFMEMALLOC reserves, and the flag is currently copied on skb
> copy and clone.
>
> However, an skb copied from an skb flagged with pfmemalloc
> wasn't necessarily allocated from PFMEMALLOC reserves, and on
> the other hand an skb allocated that way might be copied from an
> skb that wasn't.
>
> So we should not copy the flag on skb copy, and rather decide
> whether to allow an skb to be associated with sockets unrelated
> to page reclaim depending only on how it was allocated.
>
> Move the pfmemalloc flag before headers_start[0] using an
> existing 1-bit hole, so that __copy_skb_header() doesn't copy
> it.
>
> When cloning, we'll now take care of this flag explicitly,
> contravening to the warning comment of __skb_clone().
>
> While at it, restore the newline usage introduced by commit
> b19372273164 ("net: reorganize sk_buff for faster
> __copy_skb_header()") to visually separate bytes used in
> bitfields after headers_start[0], that was gone after commit
> a9e419dc7be6 ("netfilter: merge ctinfo into nfct pointer storage
> area"), and describe the pfmemalloc flag in the kernel-doc
> structure comment.
>
> This doesn't change the size of sk_buff or cacheline boundaries,
> but consolidates the 15 bits hole before tc_index into a 2 bytes
> hole before csum, that could now be filled more easily.
>
> Reported-by: Patrick Talbert <ptalbert@redhat.com>
> Fixes: c93bdd0e03e8 ("netvm: allow skb allocation to use PFMEMALLOC reserves")
> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Applied and queued up for -stable, thank you.
^ permalink raw reply
* Re: [BUG] bonded interfaces drop bpdu (stp) frames
From: Michal Soltys @ 2018-07-12 22:14 UTC (permalink / raw)
To: Mahesh Bandewar (महेश बंडेवार),
Jay Vosburgh
Cc: Chonggang Li, linux-netdev
In-Reply-To: <CAF2d9jjXmiVZwDu-q+M5bmdrgyMr0U_tiUzxoCUiWwZT4NS5Cw@mail.gmail.com>
On 2018-07-12 23:26, Mahesh Bandewar (महेश बंडेवार) wrote:
> On Thu, Jul 12, 2018 at 11:03 AM, Jay Vosburgh
> <jay.vosburgh@canonical.com> wrote:
>> Michal Soltys <soltys@ziu.info> wrote:
>>
>>>On 07/12/2018 04:51 PM, Jay Vosburgh wrote:
>>>> Mahesh Bandewar (महेश बंडेवार) wrote:
>>>>
>>>>> On Wed, Jul 11, 2018 at 3:23 PM, Michal Soltys <soltys@ziu.info> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> As weird as that sounds, this is what I observed today after bumping
>>>>>> kernel version. I have a setup where 2 bonds are attached to linux
>>>>>> bridge and physically are connected to two switches doing MSTP (and
>>>>>> linux bridge is just passing them).
>>>>>>
>>>>>> Initially I suspected some changes related to bridge code - but quick
>>>>>> peek at the code showed nothing suspicious - and the part of it that
>>>>>> explicitly passes stp frames if stp is not enabled has seen little
>>>>>> changes (e.g. per-port group_fwd_mask added recently). Furthermore - if
>>>>>> regular non-bonded interfaces are attached everything works fine.
>>>>>>
>>>>>> Just to be sure I detached the bond (802.3ad mode) and checked it with
>>>>>> simple tcpdump (ether proto \\stp) - and indeed no hello packets were
>>>>>> there (with them being present just fine on active enslaved interface,
>>>>>> or on the bond device in earlier kernels).
>>>>>>
>>>>>> If time permits I'll bisect tommorow to pinpoint the commit, but from
>>>>>> quick todays test - 4.9.x is working fine, while 4.16.16 (tested on
>>>>>> debian) and 4.17.3 (tested on archlinux) are failing.
>>>>>>
>>>>>> Unless this is already a known issue (or you have any suggestions what
>>>>>> could be responsible).
>>>>>>
>>>>> I believe these are link-local-multicast messages and sometime back a
>>>>> change went into to not pass those frames to the bonding master. This
>>>>> could be the side effect of that.
>>>>
>>>> Mahesh, I suspect you're thinking of:
>>>>
>>>> commit b89f04c61efe3b7756434d693b9203cc0cce002e
>>>> Author: Chonggang Li <chonggangli@google.com>
>>>> Date: Sun Apr 16 12:02:18 2017 -0700
>>>>
>>>> bonding: deliver link-local packets with skb->dev set to link that packets arrived on
>>>>
>>>> Michal, are you able to revert this patch and test?
>>>>
>>>> -J
>>>>
>>>> ---
>>>> -Jay Vosburgh, jay.vosburgh@canonical.com
>>>>
>>>
>>>
>>>Just tested - yes, reverting that patch solves the issues.
>>
>> Chonggang,
>>
>> Reading the changelog in your commit referenced above, I'm not
>> entirely sure what actual problem it is fixing. Could you elaborate?
>>
>> As the patch appears to cause a regression, it needs to be
>> either fixed or reverted.
>>
>> Mahesh, you signed-off on it as well, perhaps you also have some
>> context?
>>
>
> I think the original idea behind it was to pass the LLDPDUs to the
> stack on the interface that they came on since this is considered to
> be link-local traffic and passing to bond-master would loose it's
> "linklocal-ness". This is true for LLDP and if you change the skb->dev
> of the packet, then you don't know which slave link it came on in
> (from LLDP consumer's perspective).
>
> I don't know much about STP but trunking two links and aggregating
> this link info through bond-master seems wrong. Just like LLDP, you
> are losing info specific to a link and the decision derived from that
> info could be wrong.
>
> Having said that, we determine "linklocal-ness" by looking at L2 and
> bondmaster shares this with lts slaves. So it does seem fair to pass
> those frames to the bonding-master but at the same time link-local
> traffic is supposed to be limited to the physical link (LLDP/STP/LACP
> etc). Your thoughts?
>
But, isn't bond de-facto considered the "physical link" ? Not directly
of course, but say an LLDP daemon would likely be more interested in
getting LLDP data from a bond device (or a bridge device, if the bond is
attached to one), than from its enslaved interfaces (and enslaved
interfaces can be changed, not mentioning potentially complex setup
itself, even if usually it's just lacp&go ).
ITOW, blocking link-local multicasts on bond level (among those - bpdu,
pae, lldp) is a bit like if the interface itself hid LACP before bond code.
A few other examples:
- putting bonds in a bridge is pretty normal thing - and whether the
bridge interpretes the spanning tree data itself (via in-kernel classic
stp or userspace daemon for e.g. rstp) or passes the trafic, it must see
the BPDU frames. Otherwise it becomes blind to the whole spanning tree
protocol - and implicitly other switches around - real or virtual ones.
It's literally instant loop disaster. br_input.c specifically takes care
to pass those frames if the bridge has stp turned off
- "group_fwd_mask" (again in bridge context) has been added to bridge
code - and recently as a per-port knob as well - to specifically allow
the control of what kind of "link-local" stuff is passed or not. LLDP
and 802.1X PAE were, afaik, the main reasons for that sysfs variable.
The per-port setting is even more relaxed (iirc, only pause frames are
not passable)
- LLDP daemon example - as above
^ permalink raw reply
* Re: [PATCH bpf] bpf: fix some bad __rcu annotations in bpf/core.c
From: Roman Gushchin @ 2018-07-12 22:26 UTC (permalink / raw)
To: Daniel Borkmann
Cc: netdev, linux-kernel, kernel-team, Alexei Starovoitov, yhs
In-Reply-To: <31c2b14a-8890-0ebd-bb59-01616e9d8d5d@iogearbox.net>
On Tue, Jul 10, 2018 at 10:03:19AM +0200, Daniel Borkmann wrote:
> Hi Roman,
>
> On 07/10/2018 03:59 AM, Roman Gushchin wrote:
> > Sparse shows some "incorrect type" warnings in the bpf core code.
>
> Thanks for taking a stab at these! It would really help if you could
> split the patch into a small series and fix each individual case that
> is problematic here.
>
> Please also add Fixes tags to the patches.
Sure.
The only problem which I have with these sparse warnings,
is that my cgroup local storage patchset touches some of
these lines, and I'm receiving automatic complains.
>
> More below.
>
> > They are caused by bad __rcu annotations:
> > 1) bpf_prog_array_alloc() returns an __rcu pointer, which isn't true.
> > At that moment it's obviously an exclusive "owning" pointer,
> > which is valid for an infinite amount of time, so __rcu is
> > meaningless.
> > 2) The progs local variable in compute_effective_progs should be
> > marked as __bpf too, it's a local variable, not shared with anyone
>
> Typo: __bpf ?
Yep, fixed.
>
> > else at all. The real __rcu variable is array pointer, which should
> > be assigned with rcu_assign_pointer.
> > 3) __rcu progs argument of bpf_prog_array_free() should be casted
> > to a simple pointer before calling kfree_rcu().
> > 4) There is a missing rcu_dereference() annotation in
> > bpf_prog_array_copy_to_user().
> > 5) old_array __rcu pointer in bpf_prog_array_copy() is used as
> > a "normal" non-__rcu pointer.
> >
> > These changes remove the following sparse warnings:
> > kernel/bpf/core.c:1544:31: warning: incorrect type in return expression (different address spaces)
> > kernel/bpf/core.c:1544:31: expected struct bpf_prog_array [noderef] <asn:4>*
> > kernel/bpf/core.c:1544:31: got void *
> > kernel/bpf/core.c:1548:17: warning: incorrect type in return expression (different address spaces)
> > kernel/bpf/core.c:1548:17: expected struct bpf_prog_array [noderef] <asn:4>*
> > kernel/bpf/core.c:1548:17: got struct bpf_prog_array *<noident>
> > kernel/bpf/core.c:1556:9: warning: incorrect type in argument 1 (different address spaces)
> > kernel/bpf/core.c:1556:9: expected struct callback_head *head
> > kernel/bpf/core.c:1556:9: got struct callback_head [noderef] <asn:4>*<noident>
> > kernel/bpf/core.c:1629:34: warning: incorrect type in initializer (different address spaces)
> > kernel/bpf/core.c:1629:34: expected struct bpf_prog **prog
> > kernel/bpf/core.c:1629:34: got struct bpf_prog *[noderef] <asn:4>*<noident>
> > kernel/bpf/core.c:1653:31: warning: incorrect type in assignment (different address spaces)
> > kernel/bpf/core.c:1653:31: expected struct bpf_prog **existing_prog
> > kernel/bpf/core.c:1653:31: got struct bpf_prog *[noderef] <asn:4>*<noident>
> > kernel/bpf/core.c:1681:15: warning: incorrect type in assignment (different address spaces)
> > kernel/bpf/core.c:1681:15: expected struct bpf_prog_array *array
> > kernel/bpf/core.c:1681:15: got struct bpf_prog_array [noderef] <asn:4>*
> > kernel/bpf/core.c:1687:31: warning: incorrect type in assignment (different address spaces)
> > kernel/bpf/core.c:1687:31: expected struct bpf_prog **[assigned] existing_prog
> > kernel/bpf/core.c:1687:31: got struct bpf_prog *[noderef] <asn:4>*<noident>
> >
> > Signed-off-by: Roman Gushchin <guro@fb.com>
> > Cc: Daniel Borkmann <daniel@iogearbox.net>
> > Cc: Alexei Starovoitov <ast@kernel.org>
> > ---
> > include/linux/bpf.h | 2 +-
> > kernel/bpf/cgroup.c | 7 +++----
> > kernel/bpf/core.c | 14 ++++++++------
> > 3 files changed, 12 insertions(+), 11 deletions(-)
> >
> > diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > index 8827e797ff97..943fb08d8287 100644
> > --- a/include/linux/bpf.h
> > +++ b/include/linux/bpf.h
> > @@ -352,7 +352,7 @@ struct bpf_prog_array {
> > struct bpf_prog *progs[0];
> > };
> >
> > -struct bpf_prog_array __rcu *bpf_prog_array_alloc(u32 prog_cnt, gfp_t flags);
> > +struct bpf_prog_array *bpf_prog_array_alloc(u32 prog_cnt, gfp_t flags);
> > void bpf_prog_array_free(struct bpf_prog_array __rcu *progs);
> > int bpf_prog_array_length(struct bpf_prog_array __rcu *progs);
> > int bpf_prog_array_copy_to_user(struct bpf_prog_array __rcu *progs,
> > diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
> > index 3d83ee7df381..badabb0b435c 100644
> > --- a/kernel/bpf/cgroup.c
> > +++ b/kernel/bpf/cgroup.c
> > @@ -95,7 +95,7 @@ static int compute_effective_progs(struct cgroup *cgrp,
> > enum bpf_attach_type type,
> > struct bpf_prog_array __rcu **array)
> > {
> > - struct bpf_prog_array __rcu *progs;
> > + struct bpf_prog_array *progs;
> > struct bpf_prog_list *pl;
> > struct cgroup *p = cgrp;
> > int cnt = 0;
> > @@ -120,13 +120,12 @@ static int compute_effective_progs(struct cgroup *cgrp,
> > &p->bpf.progs[type], node) {
> > if (!pl->prog)
> > continue;
> > - rcu_dereference_protected(progs, 1)->
> > - progs[cnt++] = pl->prog;
> > + progs->progs[cnt++] = pl->prog;
> > }
> > p = cgroup_parent(p);
> > } while (p);
> >
> > - *array = progs;
> > + rcu_assign_pointer(*array, progs);
> > return 0;
> > }
> >
> > diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> > index 1e5625d46414..f6e5b207a0d7 100644
> > --- a/kernel/bpf/core.c
> > +++ b/kernel/bpf/core.c
> > @@ -1538,7 +1538,7 @@ static struct {
> > .null_prog = NULL,
> > };
> >
> > -struct bpf_prog_array __rcu *bpf_prog_array_alloc(u32 prog_cnt, gfp_t flags)
> > +struct bpf_prog_array *bpf_prog_array_alloc(u32 prog_cnt, gfp_t flags)
> > {
> > if (prog_cnt)
> > return kzalloc(sizeof(struct bpf_prog_array) +
> > @@ -1550,10 +1550,11 @@ struct bpf_prog_array __rcu *bpf_prog_array_alloc(u32 prog_cnt, gfp_t flags)
>
> Looks good to me to here.
>
> > void bpf_prog_array_free(struct bpf_prog_array __rcu *progs)
> > {
> > - if (!progs ||
> > - progs == (struct bpf_prog_array __rcu *)&empty_prog_array.hdr)
> > + struct bpf_prog_array *array = rcu_access_pointer(progs);
>
> Can you elaborate on the rcu_access_pointer() part? This looks odd, at minimum
> this needs a comment explaining why it's needed. Is the __rcu annotation above
> even correct?
No, it's not. But fixing it causes to use rcu_access_pointer()
for almost every bpf_prog_array_delete_safe() call.
Still better probably, will go this path in v2.
>
> > +
> > + if (!array || array == &empty_prog_array.hdr)
> > return;
> > - kfree_rcu(progs, rcu);
> > + kfree_rcu(array, rcu);
> > }
> >
> > int bpf_prog_array_length(struct bpf_prog_array __rcu *progs)
> > @@ -1626,7 +1627,7 @@ int bpf_prog_array_copy_to_user(struct bpf_prog_array __rcu *progs,
> > void bpf_prog_array_delete_safe(struct bpf_prog_array __rcu *progs,
> > struct bpf_prog *old_prog)
> > {
> > - struct bpf_prog **prog = progs->progs;
> > + struct bpf_prog **prog = rcu_dereference(progs)->progs;
>
> Can you elaborate here as well? __rcu annotation buggy instead?
But here it's fine. Please, look at bpf_prog_array_length() and bpf_prog_array_copy_to_user().
Same applies here.
If we want to be more precise, the "progs" field in the bpf_prog_array should
also be marked with __rcu, but this is beyond the scope of this patch(set).
>
> > for (; *prog; prog++)
> > if (*prog == old_prog) {
> > @@ -1635,11 +1636,12 @@ void bpf_prog_array_delete_safe(struct bpf_prog_array __rcu *progs,
> > }
> > }
> >
> > -int bpf_prog_array_copy(struct bpf_prog_array __rcu *old_array,
> > +int bpf_prog_array_copy(struct bpf_prog_array __rcu *__old_array,
> > struct bpf_prog *exclude_prog,
> > struct bpf_prog *include_prog,
> > struct bpf_prog_array **new_array)
> > {
> > + struct bpf_prog_array *old_array = rcu_access_pointer(__old_array);
>
> Same comment here, this doesn't look right. We even fetch old_array->progs
> from it later on in this path.
Same here. old_array->progs field is not marked with __bpf currently.
Thanks!
^ permalink raw reply
* Re: Re: [Qemu-devel] [PATCH v3 0/3] Use of unique identifier for pairing virtio and passthrough devices...
From: Siwei Liu @ 2018-07-12 22:19 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Cornelia Huck, si-wei liu, Roman Kagan, Venu Busireddy,
Marcel Apfelbaum, virtio-dev, qemu-devel, Samudrala, Sridhar,
Alexander Duyck, Netdev
In-Reply-To: <20180712235500-mutt-send-email-mst@kernel.org>
On Thu, Jul 12, 2018 at 2:00 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Thu, Jul 12, 2018 at 01:52:53PM -0700, Siwei Liu wrote:
>> The definition is incomplete due to lack of spec. There's no "host"
>> part defined yet in the host-guest interface. If match by MAC is an
>> interface, the same must be done on the host(device) side as well,
>> which has been agreed not the way to go. However, I don't think that's
>> what the author intends to do by interpreting his QEMU patch - it
>> missed the other parts as well, such as the feature negotiation and
>> how it interacts with the paired device.
>>
>> What I said is that match by MAC is just a guest implementation that
>> one can change at any time. We now have the group ID on QEMU, why
>> still sticking to matching by MAC? It shoulnd't be a host-guest
>> interface in the first place anyway.
>
> I think that match by MAC is a simple portable way to match devices.
> E.g. it will work seamlessly with niche things like zPCI. However
That's a good point. I'm not sure if it's a valid assumption that zPCI
should always use the same MAC address as that of virtio. Someone
who's more familiar with the use case may decide and work on that. It
means VFIO device has to take in the MAC address as an identifier to
the "-device vfio-pci,.." QEMU option. I think there's no point to
match device using group ID in QEMU while using MAC in the guest.
Based on that assumption, I'd go with making VIRTIO_NET_F_STANDBY to
match device based on group ID, while someone may come up with another
feature bit later, say VIRTIO_NET_F_STANDBY_BY_MAC when its QEMU
support is available. Would it make sense?
-Siwei
> there are other niche use-cases that aren't addressed by match by MAC
> such as PF pass-through as a primary, and the pci bridge trick addresses
> that at cost of some portability.
>
> So I see no issues supporting both mechanisms, but others on the TC
> might feel differently.
>
> --
> MST
^ permalink raw reply
* Re: [PATCH mlx5-next v1 2/8] net/mlx5: Add support for flow table destination number
From: Jason Gunthorpe @ 2018-07-12 22:05 UTC (permalink / raw)
To: Or Gerlitz
Cc: Yishai Hadas, Doug Ledford, Leon Romanovsky, RDMA mailing list,
Saeed Mahameed, linux-netdev
In-Reply-To: <CAJ3xEMg-cfRwZTwK2Eu2cdH1YuSF5rJy88YWYrbyWywKun5hPg@mail.gmail.com>
On Fri, Jul 13, 2018 at 12:51:10AM +0300, Or Gerlitz wrote:
> On Fri, Jul 13, 2018 at 12:26 AM, Jason Gunthorpe <jgg@mellanox.com> wrote:
> > On Fri, Jul 13, 2018 at 12:00:41AM +0300, Or Gerlitz wrote:
> >> On Wed, Jul 11, 2018 at 2:10 PM, Leon Romanovsky <leon@kernel.org> wrote:
> >> > From: Yishai Hadas <yishaih@mellanox.com>
> >> >
> >> > Add support to set a destination from a flow table number.
> >> > This functionality will be used in downstream patches from this
> >> > series by the DEVX stuff.
> >>
> >> Reading your cover letter, I still don't understand what is missing
> >> in the current mlx5 fs core API for your needs. After all, you do
> >> create flow tables from the IB driver through fs core calls, right?
> >> so @ the end of the day, you have the FT pointer to provide the
> >> core, why you need the FT number?
> >
> > Via the devx API userspace can create flow tables directly without
> > going to the driver's flow steering core.
>
> so why you change the core?
User space flow tables don't get any traffic until they are linked
into the main steering. The only ID the kernel gets for them when
adding this link is the actual PRM handle, not a pointer - hence the
change.
Jason
^ permalink raw reply
* Re: [PATCH iproute2-next v2] net:sched: add action inheritdsfield to skbedit
From: Stephen Hemminger @ 2018-07-12 22:05 UTC (permalink / raw)
To: Qiaobin Fu
Cc: dsahern, davem, netdev, jhs, michel, marcelo.leitner,
xiyou.wangcong, dcaratti
In-Reply-To: <20180712160926.163317-1-qiaobinf@bu.edu>
On Thu, 12 Jul 2018 12:09:26 -0400
Qiaobin Fu <qiaobinf@bu.edu> wrote:
> + if (*flags & SKBEDIT_F_INHERITDSFIELD)
> + print_string(PRINT_ANY, "inheritdsfield", " %s",
> + "inheritdsfield");
Flags should be represented in JSON output as a null value (or boolean).
print_null(PRINT_ANY, "inheritdsfield", " %s", "inheritdsfield");
This will generate:
"inheritdsfield" : null,
Instead of:
"inheritdsfield" : "inheritdsfield",
^ permalink raw reply
* Re: [BUG] bonded interfaces drop bpdu (stp) frames
From: Jay Vosburgh @ 2018-07-12 22:03 UTC (permalink / raw)
To: =?UTF-8?B?TWFoZXNoIEJhbmRld2FyICjgpK7gpLngpYfgpLYg4KSs4KSC4KSh4KWH4KS14KS+4KSwKQ==?=
Cc: Michal Soltys, Chonggang Li, linux-netdev
In-Reply-To: <CAF2d9jjXmiVZwDu-q+M5bmdrgyMr0U_tiUzxoCUiWwZT4NS5Cw@mail.gmail.com>
Mahesh Bandewar (महेश बंडेवार) wrote:
>On Thu, Jul 12, 2018 at 11:03 AM, Jay Vosburgh
><jay.vosburgh@canonical.com> wrote:
>> Michal Soltys <soltys@ziu.info> wrote:
>>
>>>On 07/12/2018 04:51 PM, Jay Vosburgh wrote:
>>>> Mahesh Bandewar (महेश बंडेवार) wrote:
>>>>
>>>>> On Wed, Jul 11, 2018 at 3:23 PM, Michal Soltys <soltys@ziu.info> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> As weird as that sounds, this is what I observed today after bumping
>>>>>> kernel version. I have a setup where 2 bonds are attached to linux
>>>>>> bridge and physically are connected to two switches doing MSTP (and
>>>>>> linux bridge is just passing them).
>>>>>>
>>>>>> Initially I suspected some changes related to bridge code - but quick
>>>>>> peek at the code showed nothing suspicious - and the part of it that
>>>>>> explicitly passes stp frames if stp is not enabled has seen little
>>>>>> changes (e.g. per-port group_fwd_mask added recently). Furthermore - if
>>>>>> regular non-bonded interfaces are attached everything works fine.
>>>>>>
>>>>>> Just to be sure I detached the bond (802.3ad mode) and checked it with
>>>>>> simple tcpdump (ether proto \\stp) - and indeed no hello packets were
>>>>>> there (with them being present just fine on active enslaved interface,
>>>>>> or on the bond device in earlier kernels).
>>>>>>
>>>>>> If time permits I'll bisect tommorow to pinpoint the commit, but from
>>>>>> quick todays test - 4.9.x is working fine, while 4.16.16 (tested on
>>>>>> debian) and 4.17.3 (tested on archlinux) are failing.
>>>>>>
>>>>>> Unless this is already a known issue (or you have any suggestions what
>>>>>> could be responsible).
>>>>>>
>>>>> I believe these are link-local-multicast messages and sometime back a
>>>>> change went into to not pass those frames to the bonding master. This
>>>>> could be the side effect of that.
>>>>
>>>> Mahesh, I suspect you're thinking of:
>>>>
>>>> commit b89f04c61efe3b7756434d693b9203cc0cce002e
>>>> Author: Chonggang Li <chonggangli@google.com>
>>>> Date: Sun Apr 16 12:02:18 2017 -0700
>>>>
>>>> bonding: deliver link-local packets with skb->dev set to link that packets arrived on
>>>>
>>>> Michal, are you able to revert this patch and test?
>>>>
>>>> -J
>>>>
>>>> ---
>>>> -Jay Vosburgh, jay.vosburgh@canonical.com
>>>>
>>>
>>>
>>>Just tested - yes, reverting that patch solves the issues.
>>
>> Chonggang,
>>
>> Reading the changelog in your commit referenced above, I'm not
>> entirely sure what actual problem it is fixing. Could you elaborate?
>>
>> As the patch appears to cause a regression, it needs to be
>> either fixed or reverted.
>>
>> Mahesh, you signed-off on it as well, perhaps you also have some
>> context?
>>
>
>I think the original idea behind it was to pass the LLDPDUs to the
>stack on the interface that they came on since this is considered to
>be link-local traffic and passing to bond-master would loose it's
>"linklocal-ness". This is true for LLDP and if you change the skb->dev
>of the packet, then you don't know which slave link it came on in
>(from LLDP consumer's perspective).
>
>I don't know much about STP but trunking two links and aggregating
>this link info through bond-master seems wrong. Just like LLDP, you
>are losing info specific to a link and the decision derived from that
>info could be wrong.
>
>Having said that, we determine "linklocal-ness" by looking at L2 and
>bondmaster shares this with lts slaves. So it does seem fair to pass
>those frames to the bonding-master but at the same time link-local
>traffic is supposed to be limited to the physical link (LLDP/STP/LACP
>etc). Your thoughts?
I agree the whole thing sounds kind of weird, but I'm curious as
to what Michal's actual use case is; he presumably has some practical
use for this, since he noticed that the behavior changed.
Michal, you mentioned MSTP and using 802.3ad (LACP) mode; how
does that combination work rationally given that the bond might send and
receive traffic across multiple slaves? Or does the switch side bundle
the ports together into a single logical interface for MSTP purposes?
On the TX side, I think the bond will likely balance all STP frames to
just one slave.
As for a resolution, presuming that Michal has some reasonable
use case, I'm thinking along the lines of reverting the new (leave frame
attached to slave) behavior for the general case and adding a special
case for LLDP and friends to get the new behavior. I'd like to avoid
adding any new options to bonding.
-J
---
-Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] net/sched: act_skbedit: lockless data path
From: David Miller @ 2018-07-12 21:54 UTC (permalink / raw)
To: dcaratti; +Cc: xiyou.wangcong, netdev
In-Reply-To: <cover.1531315251.git.dcaratti@redhat.com>
From: Davide Caratti <dcaratti@redhat.com>
Date: Wed, 11 Jul 2018 16:04:48 +0200
> the data path of act_skbedit can be faster if we avoid using spinlocks:
> - patch 1 converts act_skbedit statistics to use per-cpu counters
> - patch 2 lets act_skbedit use RCU to read/update its configuration
>
> test procedure (using pktgen from https://github.com/netoptimizer):
>
> # ip link add name eth1 type dummy
> # ip link set dev eth1 up
> # tc qdisc add dev eth1 clsact
> # tc filter add dev eth1 egress matchall action skbedit priority c1a0:c1a0
> # for c in 1 2 4 ; do
> > ./pktgen_bench_xmit_mode_queue_xmit.sh -v -s 64 -t $c -n 5000000 -i eth1
> > done
>
> test results (avg. pps/thread)
>
> $c | before patch | after patch | improvement
> ----+--------------+--------------+------------
> 1 | 3917464 ± 3% | 4000458 ± 3% | irrelevant
> 2 | 3455367 ± 4% | 3953076 ± 1% | +14%
> 4 | 2496594 ± 2% | 3801123 ± 3% | +52%
>
> v2: rebased on latest net-next
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH net 0/2] sfc: filter locking fixes
From: David Miller @ 2018-07-12 21:52 UTC (permalink / raw)
To: bkenward; +Cc: netdev, linux-net-drivers
In-Reply-To: <ffa1a8d2-7906-29f9-6089-f968aa376681@solarflare.com>
From: Bert Kenward <bkenward@solarflare.com>
Date: Wed, 11 Jul 2018 11:39:39 +0100
> Two fixes for sfc ef10 filter table locking. Initially spotted
> by lockdep, but one issue has also been seen in normal use.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH mlx5-next v1 2/8] net/mlx5: Add support for flow table destination number
From: Or Gerlitz @ 2018-07-12 21:51 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Yishai Hadas, Doug Ledford, Leon Romanovsky, RDMA mailing list,
Saeed Mahameed, linux-netdev
In-Reply-To: <20180712212618.GS30390@mellanox.com>
On Fri, Jul 13, 2018 at 12:26 AM, Jason Gunthorpe <jgg@mellanox.com> wrote:
> On Fri, Jul 13, 2018 at 12:00:41AM +0300, Or Gerlitz wrote:
>> On Wed, Jul 11, 2018 at 2:10 PM, Leon Romanovsky <leon@kernel.org> wrote:
>> > From: Yishai Hadas <yishaih@mellanox.com>
>> >
>> > Add support to set a destination from a flow table number.
>> > This functionality will be used in downstream patches from this
>> > series by the DEVX stuff.
>>
>> Reading your cover letter, I still don't understand what is missing
>> in the current mlx5 fs core API for your needs. After all, you do
>> create flow tables from the IB driver through fs core calls, right?
>> so @ the end of the day, you have the FT pointer to provide the
>> core, why you need the FT number?
>
> Via the devx API userspace can create flow tables directly without
> going to the driver's flow steering core.
so why you change the core?
^ permalink raw reply
* [PATCH net] net/ipv6: Do not allow device only routes via the multipath API
From: dsahern @ 2018-07-12 21:48 UTC (permalink / raw)
To: netdev; +Cc: eric.dumazet, David Ahern
From: David Ahern <dsahern@gmail.com>
Eric reported that reverting the patch that fixed and simplified IPv6
multipath routes means reverting back to invalid userspace notifications.
eg.,
$ ip -6 route add 2001:db8:1::/64 nexthop dev eth0 nexthop dev eth1
only generates a single notification:
2001:db8:1::/64 dev eth0 metric 1024 pref medium
While working on a fix for this problem I found another case that is just
broken completely - a multipath route with a gateway followed by device
followed by gateway:
$ ip -6 ro add 2001:db8:103::/64
nexthop via 2001:db8:1::64
nexthop dev dummy2
nexthop via 2001:db8:3::64
In this case the device only route is dropped completely - no notification
to userpsace but no addition to the FIB either:
$ ip -6 ro ls
2001:db8:1::/64 dev dummy1 proto kernel metric 256 pref medium
2001:db8:2::/64 dev dummy2 proto kernel metric 256 pref medium
2001:db8:3::/64 dev dummy3 proto kernel metric 256 pref medium
2001:db8:103::/64 metric 1024
nexthop via 2001:db8:1::64 dev dummy1 weight 1
nexthop via 2001:db8:3::64 dev dummy3 weight 1 pref medium
fe80::/64 dev dummy1 proto kernel metric 256 pref medium
fe80::/64 dev dummy2 proto kernel metric 256 pref medium
fe80::/64 dev dummy3 proto kernel metric 256 pref medium
Really, IPv6 multipath is just FUBAR'ed beyond repair when it comes to
device only routes, so do not allow it all.
This change will break any scripts relying on the mpath api for insert,
but I don't see any other way to handle the permutations. Besides, since
the routes are added to the FIB as standalone (non-multipath) routes the
kernel is not doing what the user requested, so it might as well tell the
user that.
Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David Ahern <dsahern@gmail.com>
---
net/ipv6/route.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 63f99411f0de..1f1f0f318d74 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -4388,6 +4388,13 @@ static int ip6_route_multipath_add(struct fib6_config *cfg,
rt = NULL;
goto cleanup;
}
+ if (!rt6_qualify_for_ecmp(rt)) {
+ err = EINVAL;
+ NL_SET_ERR_MSG(extack,
+ "Device only routes can not be added for IPv6 using the multipath API.");
+ fib6_info_release(rt);
+ goto cleanup;
+ }
rt->fib6_nh.nh_weight = rtnh->rtnh_hops + 1;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net] net: systemport: Fix CRC forwarding check for SYSTEMPORT Lite
From: David Miller @ 2018-07-12 21:47 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, linux-kernel
In-Reply-To: <20180711094758.1670-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Wed, 11 Jul 2018 02:47:58 -0700
> SYSTEMPORT Lite reversed the logic compared to SYSTEMPORT, the
> GIB_FCS_STRIP bit is set when the Ethernet FCS is stripped, and that bit
> is not set by default. Fix the logic such that we properly check whether
> that bit is set or not and we don't forward an extra 4 bytes to the
> network stack.
>
> Fixes: 44a4524c54af ("net: systemport: Add support for SYSTEMPORT Lite")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] [RESEND] nfp: avoid using getnstimeofday64()
From: David Miller @ 2018-07-12 21:56 UTC (permalink / raw)
To: arnd
Cc: jakub.kicinski, john.hurley, simon.horman, pieter.jansenvanvuuren,
jiri, oss-drivers, netdev, linux-kernel
In-Reply-To: <20180711123003.453442-2-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 11 Jul 2018 14:29:53 +0200
> getnstimeofday64 is deprecated in favor of the ktime_get() family of
> functions. The direct replacement would be ktime_get_real_ts64(),
> but I'm picking the basic ktime_get() instead:
>
> - using a ktime_t simplifies the code compared to timespec64
> - using monotonic time instead of real time avoids issues caused
> by a concurrent settimeofday() or during a leap second adjustment.
>
> Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH 1/2] [RESEND] liquidio: use ktime_get_real_ts64() instead of getnstimeofday64()
From: David Miller @ 2018-07-12 21:56 UTC (permalink / raw)
To: arnd
Cc: derek.chickles, satananda.burla, felix.manlunas, raghu.vatsavayi,
intiyaz.basha, ricardo.farrington, veerasenareddy.burru,
vijaya.guvva, weilin.chang, netdev, linux-kernel
In-Reply-To: <20180711123003.453442-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 11 Jul 2018 14:29:52 +0200
> The two do the same thing, but we want to have a consistent
> naming in the kernel.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH] [RESEND, net-next, v2] tcp: use monotonic timestamps for PAWS
From: David Miller @ 2018-07-12 21:50 UTC (permalink / raw)
To: arnd
Cc: edumazet, kuznet, yoshfuji, harsh, herbert, atul.gupta, gustavo,
werner, linux-crypto, linux-kernel, netdev
In-Reply-To: <20180711101757.3929777-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 11 Jul 2018 12:16:12 +0200
> Using get_seconds() for timestamps is deprecated since it can lead
> to overflows on 32-bit systems. While the interface generally doesn't
> overflow until year 2106, the specific implementation of the TCP PAWS
> algorithm breaks in 2038 when the intermediate signed 32-bit timestamps
> overflow.
>
> A related problem is that the local timestamps in CLOCK_REALTIME form
> lead to unexpected behavior when settimeofday is called to set the system
> clock backwards or forwards by more than 24 days.
>
> While the first problem could be solved by using an overflow-safe method
> of comparing the timestamps, a nicer solution is to use a monotonic
> clocksource with ktime_get_seconds() that simply doesn't overflow (at
> least not until 136 years after boot) and that doesn't change during
> settimeofday().
>
> To make 32-bit and 64-bit architectures behave the same way here, and
> also save a few bytes in the tcp_options_received structure, I'm changing
> the type to a 32-bit integer, which is now safe on all architectures.
>
> Finally, the ts_recent_stamp field also (confusingly) gets used to store
> a jiffies value in tcp_synq_overflow()/tcp_synq_no_recent_overflow().
> This is currently safe, but changing the type to 32-bit requires
> some small changes there to keep it working.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> v2: use time_before32()/time_after32() everywhere as suggested
> Eric Dumazet in https://lore.kernel.org/lkml/67ebb94d-c73f-6c9f-493b-00c86f595120@gmail.com/
Applied.
^ permalink raw reply
* Re: [PATCH 00/14] ARM BPF jit compiler improvements
From: Russell King - ARM Linux @ 2018-07-12 21:35 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev, linux-arm-kernel
In-Reply-To: <fbfa3684-b5a0-670d-c8f7-8c14829565cb@iogearbox.net>
On Thu, Jul 12, 2018 at 11:12:45PM +0200, Daniel Borkmann wrote:
> On 07/12/2018 11:02 PM, Russell King - ARM Linux wrote:
> > On Thu, Jul 12, 2018 at 09:02:41PM +0200, Daniel Borkmann wrote:
> >> Applied to bpf-next, thanks a lot Russell!
> >
> > Thanks, I've just sent four more patches, which is the sum total of
> > what I'm intending to send for BPF improvements for the next merge
> > window.
>
> Great, thanks a lot for the batch of improvements, Russell!
>
> Did you manage to get the BPF kselftest suite working on arm32 under
> tools/testing/selftests/bpf/? In particular the test_verfier with
> bpf_jit_enabled set to 1 and test_kmod.sh has a bigger number of
> runtime tests that would stress it.
I have a big issue with almost all of the tools/ subdirectory, and
that is that it isn't "portable".
It seems that cross-build environments just weren't considered when
the tools subdirectory was created - it appears to require the entire
kernel tree and build tree to be accessible on the target in order
to build almost everything there. (I also exclusively do split-object
builds, I never do an in-source-tree build.)
At least perf has the ability to ask Kbuild to package it up as a
tar.* file. That can be easily transported to the target as a
self-contained buildable tree, and then be able to built from that.
My cross-build environment for the kernel is just for building
kernels, it does not have the facilities to build for userspace - I
have a wide range of userspaces across targets, with a multitude of
different glibc versions, and even when they're compatible versions,
they're built differently.
As far as I can see, basically, most tools/ stuff requires too much
effort to work around this to be of any use to me. Even if I did
unpick it from the kernel source tree by hand, that would be wasted
effort, because I'd need to repeat that same process whenever
anything there gets updated.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up
^ permalink raw reply
* Re: [PATCH] tcp: allow user to create repair socket without window probes
From: David Miller @ 2018-07-12 21:34 UTC (permalink / raw)
To: sbaranoff; +Cc: netdev, avagin, xemul, edumazet, kuznet, yoshfuji
In-Reply-To: <1531258270-1046-1-git-send-email-sbaranoff@gmail.com>
From: Stefan Baranoff <sbaranoff@gmail.com>
Date: Tue, 10 Jul 2018 17:31:10 -0400
> Under rare conditions where repair code may be used it is possible that
> window probes are either unnecessary or undesired. If the user knows that
> window probes are not wanted or needed this change allows them to skip
> sending them when a socket comes out of repair.
>
> Signed-off-by: Stefan Baranoff <sbaranoff@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] tcp: fix sequence numbers for repaired sockets re-using TIME-WAIT sockets
From: David Miller @ 2018-07-12 21:34 UTC (permalink / raw)
To: sbaranoff; +Cc: netdev, avagin, xemul, edumazet, kuznet, yoshfuji
In-Reply-To: <1531257920-573-1-git-send-email-sbaranoff@gmail.com>
From: Stefan Baranoff <sbaranoff@gmail.com>
Date: Tue, 10 Jul 2018 17:25:20 -0400
> This patch fixes a bug where the sequence numbers of a socket created using
> TCP repair functionality are lower than set after connect is called.
> This occurs when the repair socket overlaps with a TIME-WAIT socket and
> triggers the re-use code. The amount lower is equal to the number of times
> that a particular IP/port set is re-used and then put back into TIME-WAIT.
> Re-using the first time the sequence number is 1 lower, closing that socket
> and then re-opening (with repair) a new socket with the same addresses/ports
> puts the sequence number 2 lower than set via setsockopt. The third time is
> 3 lower, etc. I have not tested what the limit of this acrewal is, if any.
>
> The fix is, if a socket is in repair mode, to respect the already set
> sequence number and timestamp when it would have already re-used the
> TIME-WAIT socket.
>
> Signed-off-by: Stefan Baranoff <sbaranoff@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next][RESEND] net/tls: Use aead_request_alloc/free for request alloc/free
From: David Miller @ 2018-07-12 21:45 UTC (permalink / raw)
To: vakul.garg; +Cc: netdev, linux-kernel, borisp, aviadye, davejwatson
In-Reply-To: <20180711090220.14697-1-vakul.garg@nxp.com>
From: Vakul Garg <vakul.garg@nxp.com>
Date: Wed, 11 Jul 2018 14:32:20 +0530
> Instead of kzalloc/free for aead_request allocation and free, use
> functions aead_request_alloc(), aead_request_free(). It ensures that
> any sensitive crypto material held in crypto transforms is securely
> erased from memory.
>
> Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] virtio: support packed ring
From: David Miller @ 2018-07-12 21:44 UTC (permalink / raw)
To: tiwei.bie; +Cc: virtio-dev, mst, netdev, linux-kernel, virtualization, wexu
In-Reply-To: <20180711022711.7090-1-tiwei.bie@intel.com>
From: Tiwei Bie <tiwei.bie@intel.com>
Date: Wed, 11 Jul 2018 10:27:06 +0800
> Hello everyone,
>
> This patch set implements packed ring support in virtio driver.
>
> Some functional tests have been done with Jason's
> packed ring implementation in vhost:
>
> https://lkml.org/lkml/2018/7/3/33
>
> Both of ping and netperf worked as expected.
Michael and Jason, where are we with this series?
^ permalink raw reply
* Re: [BUG] bonded interfaces drop bpdu (stp) frames
From: Mahesh Bandewar (महेश बंडेवार) @ 2018-07-12 21:26 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: Michal Soltys, Chonggang Li, linux-netdev
In-Reply-To: <27709.1531418607@nyx>
On Thu, Jul 12, 2018 at 11:03 AM, Jay Vosburgh
<jay.vosburgh@canonical.com> wrote:
> Michal Soltys <soltys@ziu.info> wrote:
>
>>On 07/12/2018 04:51 PM, Jay Vosburgh wrote:
>>> Mahesh Bandewar (महेश बंडेवार) wrote:
>>>
>>>> On Wed, Jul 11, 2018 at 3:23 PM, Michal Soltys <soltys@ziu.info> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> As weird as that sounds, this is what I observed today after bumping
>>>>> kernel version. I have a setup where 2 bonds are attached to linux
>>>>> bridge and physically are connected to two switches doing MSTP (and
>>>>> linux bridge is just passing them).
>>>>>
>>>>> Initially I suspected some changes related to bridge code - but quick
>>>>> peek at the code showed nothing suspicious - and the part of it that
>>>>> explicitly passes stp frames if stp is not enabled has seen little
>>>>> changes (e.g. per-port group_fwd_mask added recently). Furthermore - if
>>>>> regular non-bonded interfaces are attached everything works fine.
>>>>>
>>>>> Just to be sure I detached the bond (802.3ad mode) and checked it with
>>>>> simple tcpdump (ether proto \\stp) - and indeed no hello packets were
>>>>> there (with them being present just fine on active enslaved interface,
>>>>> or on the bond device in earlier kernels).
>>>>>
>>>>> If time permits I'll bisect tommorow to pinpoint the commit, but from
>>>>> quick todays test - 4.9.x is working fine, while 4.16.16 (tested on
>>>>> debian) and 4.17.3 (tested on archlinux) are failing.
>>>>>
>>>>> Unless this is already a known issue (or you have any suggestions what
>>>>> could be responsible).
>>>>>
>>>> I believe these are link-local-multicast messages and sometime back a
>>>> change went into to not pass those frames to the bonding master. This
>>>> could be the side effect of that.
>>>
>>> Mahesh, I suspect you're thinking of:
>>>
>>> commit b89f04c61efe3b7756434d693b9203cc0cce002e
>>> Author: Chonggang Li <chonggangli@google.com>
>>> Date: Sun Apr 16 12:02:18 2017 -0700
>>>
>>> bonding: deliver link-local packets with skb->dev set to link that packets arrived on
>>>
>>> Michal, are you able to revert this patch and test?
>>>
>>> -J
>>>
>>> ---
>>> -Jay Vosburgh, jay.vosburgh@canonical.com
>>>
>>
>>
>>Just tested - yes, reverting that patch solves the issues.
>
> Chonggang,
>
> Reading the changelog in your commit referenced above, I'm not
> entirely sure what actual problem it is fixing. Could you elaborate?
>
> As the patch appears to cause a regression, it needs to be
> either fixed or reverted.
>
> Mahesh, you signed-off on it as well, perhaps you also have some
> context?
>
I think the original idea behind it was to pass the LLDPDUs to the
stack on the interface that they came on since this is considered to
be link-local traffic and passing to bond-master would loose it's
"linklocal-ness". This is true for LLDP and if you change the skb->dev
of the packet, then you don't know which slave link it came on in
(from LLDP consumer's perspective).
I don't know much about STP but trunking two links and aggregating
this link info through bond-master seems wrong. Just like LLDP, you
are losing info specific to a link and the decision derived from that
info could be wrong.
Having said that, we determine "linklocal-ness" by looking at L2 and
bondmaster shares this with lts slaves. So it does seem fair to pass
those frames to the bonding-master but at the same time link-local
traffic is supposed to be limited to the physical link (LLDP/STP/LACP
etc). Your thoughts?
> -J
>
> ---
> -Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply
* Re: [PATCH mlx5-next v1 2/8] net/mlx5: Add support for flow table destination number
From: Jason Gunthorpe @ 2018-07-12 21:26 UTC (permalink / raw)
To: Or Gerlitz
Cc: Yishai Hadas, Doug Ledford, Leon Romanovsky, RDMA mailing list,
Saeed Mahameed, linux-netdev
In-Reply-To: <CAJ3xEMgFknMqJq=BY9SxWpPJDrm1BYBVfQWzyhYk5cdELsaoRQ@mail.gmail.com>
On Fri, Jul 13, 2018 at 12:00:41AM +0300, Or Gerlitz wrote:
> On Wed, Jul 11, 2018 at 2:10 PM, Leon Romanovsky <leon@kernel.org> wrote:
> > From: Yishai Hadas <yishaih@mellanox.com>
> >
> > Add support to set a destination from a flow table number.
> > This functionality will be used in downstream patches from this
> > series by the DEVX stuff.
>
> Reading your cover letter, I still don't understand what is missing
> in the current mlx5 fs core API for your needs. After all, you do
> create flow tables from the IB driver through fs core calls, right?
> so @ the end of the day, you have the FT pointer to provide the
> core, why you need the FT number?
Via the devx API userspace can create flow tables directly without
going to the driver's flow steering core.
Jason
^ permalink raw reply
* Re: BUG: MAX_LOCK_DEPTH too low! (2)
From: syzbot @ 2018-07-12 21:35 UTC (permalink / raw)
To: davem, e, edumazet, jbenc, linux-kernel, netdev, pshelar,
syzkaller-bugs, yi.y.yang
In-Reply-To: <000000000000798298056e76cbbb@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: 6e6fddc78323 bpf: fix panic due to oob in bpf_prog_test_ru..
git tree: bpf
console output: https://syzkaller.appspot.com/x/log.txt?x=1364db94400000
kernel config: https://syzkaller.appspot.com/x/.config?x=2ca6c7a31d407f86
dashboard link: https://syzkaller.appspot.com/bug?extid=802a5abb8abae86eb6de
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=11572794400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16aff568400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+802a5abb8abae86eb6de@syzkaller.appspotmail.com
IPv6: ADDRCONF(NETDEV_UP): veth0: link is not ready
IPv6: ADDRCONF(NETDEV_UP): veth1: link is not ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
8021q: adding VLAN 0 to HW filter on device team0
BUG: MAX_LOCK_DEPTH too low!
turning off the locking correctness validator.
depth: 48 max: 48!
48 locks held by syz-executor169/4820:
#0: (____ptrval____) (rcu_read_lock_bh){....}, at:
__dev_queue_xmit+0x328/0x3910 net/core/dev.c:3503
#1: (____ptrval____) (&(&sch->seqlock)->rlock){+...}, at: spin_trylock
include/linux/spinlock.h:320 [inline]
#1: (____ptrval____) (&(&sch->seqlock)->rlock){+...}, at: qdisc_run_begin
include/net/sch_generic.h:124 [inline]
#1: (____ptrval____) (&(&sch->seqlock)->rlock){+...}, at: qdisc_run
include/net/pkt_sched.h:117 [inline]
#1: (____ptrval____) (&(&sch->seqlock)->rlock){+...}, at: __dev_xmit_skb
net/core/dev.c:3229 [inline]
#1: (____ptrval____) (&(&sch->seqlock)->rlock){+...}, at:
__dev_queue_xmit+0x13a3/0x3910 net/core/dev.c:3537
#2: (____ptrval____) (dev->qdisc_running_key ?: &qdisc_running_key){+...},
at: dev_queue_xmit+0x17/0x20 net/core/dev.c:3602
#3: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#3: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#4: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#4: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#5: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#5: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#6: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#6: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#7: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#7: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#8: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#8: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#9: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#9: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#10: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#10: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#11: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#11: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#12: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#12: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#13: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#13: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#14: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#14: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#15: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#15: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#16: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#16: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#17: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#17: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#18: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#18: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#19: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#19: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#20: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#20: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#21: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#21: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#22: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#22: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#23: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#23: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#24: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#24: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#25: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#25: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#26: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#26: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#27: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#27: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#28: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#28: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#29: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#29: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#30: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#30: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#31: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#31: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#32: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#32: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#33: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#33: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#34: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#34: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#35: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#35: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#36: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#36: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#37: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#37: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#38: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#38: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#39: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#39: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#40: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#40: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#41: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#41: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#42: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#42: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#43: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#43: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#44: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#44: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#45: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#45: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#46: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#46: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
#47: (____ptrval____) (rcu_read_lock){....}, at: __skb_pull
include/linux/skbuff.h:2080 [inline]
#47: (____ptrval____) (rcu_read_lock){....}, at:
skb_mac_gso_segment+0x229/0x740 net/core/dev.c:2787
INFO: lockdep is turned off.
CPU: 0 PID: 4820 Comm: syz-executor169 Not tainted 4.18.0-rc3+ #8
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
__lock_acquire+0x175d/0x5020 kernel/locking/lockdep.c:3453
lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
rcu_lock_acquire include/linux/rcupdate.h:245 [inline]
rcu_read_lock include/linux/rcupdate.h:631 [inline]
skb_mac_gso_segment+0x263/0x740 net/core/dev.c:2789
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
nsh_gso_segment+0x470/0xb40 net/nsh/nsh.c:111
skb_mac_gso_segment+0x3b5/0x740 net/core/dev.c:2792
__skb_gso_segment+0x3c3/0x880 net/core/dev.c:2865
skb_gso_segment include/linux/netdevice.h:4099 [inline]
validate_xmit_skb+0x640/0xf30 net/core/dev.c:3104
validate_xmit_skb_list+0xbf/0x120 net/core/dev.c:3154
sch_direct_xmit+0x30e/0x1140 net/sched/sch_generic.c:312
qdisc_restart net/sched/sch_generic.c:390 [inline]
__qdisc_run+0x619/0x19f0 net/sched/sch_generic.c:398
qdisc_run include/net/pkt_sched.h:118 [inline]
__dev_xmit_skb net/core/dev.c:3229 [inline]
__dev_queue_xmit+0x1419/0x3910 net/core/dev.c:3537
dev_queue_xmit+0x17/0x20 net/core/dev.c:3602
packet_snd net/packet/af_packet.c:2919 [inline]
packet_sendmsg+0x428e/0x6130 net/packet/af_packet.c:2944
sock_sendmsg_nosec net/socket.c:641 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:651
___sys_sendmsg+0x7fd/0x930 net/socket.c:2125
__sys_sendmsg+0x11d/0x290 net/socket.c:2163
__do_sys_sendmsg net/socket.c:2172 [inline]
__se_sys_sendmsg net/socket.c:2170 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2170
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x446a99
Code: e8 9c bb 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 0b 09 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f18672ffdb8 EFLAGS: 00000297 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00000000006dcc24 RCX: 0000000000446a99
RDX: 0000000000000000 RSI: 0000000020000480 RDI: 0000000000000004
RBP: 00000000006dcc20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000000
R13: 00007ffcf80e967f R14: 00007f18673009c0 R15: 0000000000000007
==================================================================
------------[ cut here ]------------
BUG: KASAN: stack-out-of-bounds in lookup_object lib/debugobjects.c:157
[inline]
BUG: KASAN: stack-out-of-bounds in debug_object_deactivate+0x425/0x450
lib/debugobjects.c:540
ODEBUG: deactivate not available (active state 0) object type: hrtimer
hint: tick_sched_timer+0x0/0x130 kernel/time/tick-sched.c:66
Read of size 8 at addr ffff8801d770f830 by task syz-executor169/4820
WARNING: CPU: 1 PID: 0 at lib/debugobjects.c:329
debug_print_object+0x16a/0x210 lib/debugobjects.c:326
^ permalink raw reply
* Re: [PATCH 00/14] ARM BPF jit compiler improvements
From: Daniel Borkmann @ 2018-07-12 21:12 UTC (permalink / raw)
To: Russell King - ARM Linux; +Cc: netdev, linux-arm-kernel
In-Reply-To: <20180712210236.GV17271@n2100.armlinux.org.uk>
On 07/12/2018 11:02 PM, Russell King - ARM Linux wrote:
> On Thu, Jul 12, 2018 at 09:02:41PM +0200, Daniel Borkmann wrote:
>> Applied to bpf-next, thanks a lot Russell!
>
> Thanks, I've just sent four more patches, which is the sum total of
> what I'm intending to send for BPF improvements for the next merge
> window.
Great, thanks a lot for the batch of improvements, Russell!
Did you manage to get the BPF kselftest suite working on arm32 under
tools/testing/selftests/bpf/? In particular the test_verfier with
bpf_jit_enabled set to 1 and test_kmod.sh has a bigger number of
runtime tests that would stress it.
Thanks,
Daniel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox