* 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
* we do editing for you
From: Simon @ 2018-07-12 11:51 UTC (permalink / raw)
To: netdev
We are a good team, we can process 200+ images each day for you.
If you need any image editing service, please let us know.
Photos cut out; Photos clipping path; Photos masking; Photo shadow
creation; Photos color correction;
Photos retouching; Beauty Model retouching on skin, face, body; Glamour
retouching; Products retouching.
We deliver the work within 24-48 hours.
We can give you editing test on your photos.
Please reply if you have interests.
Our advantages:
Quality is good
Turnaround time fast
7/24/365 available
Thanks,
Simon Nelson
^ permalink raw reply
* Re: [PATCH bpf v2] bpf: don't leave partial mangled prog in jit_subprogs error path
From: Alexei Starovoitov @ 2018-07-12 21:05 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: ast, netdev
In-Reply-To: <20180712194428.12403-1-daniel@iogearbox.net>
On Thu, Jul 12, 2018 at 09:44:28PM +0200, Daniel Borkmann wrote:
> syzkaller managed to trigger the following bug through fault injection:
>
> [...]
> [ 141.043668] verifier bug. No program starts at insn 3
> [ 141.044648] WARNING: CPU: 3 PID: 4072 at kernel/bpf/verifier.c:1613
> get_callee_stack_depth kernel/bpf/verifier.c:1612 [inline]
> [ 141.044648] WARNING: CPU: 3 PID: 4072 at kernel/bpf/verifier.c:1613
> fixup_call_args kernel/bpf/verifier.c:5587 [inline]
> [ 141.044648] WARNING: CPU: 3 PID: 4072 at kernel/bpf/verifier.c:1613
> bpf_check+0x525e/0x5e60 kernel/bpf/verifier.c:5952
> [ 141.047355] CPU: 3 PID: 4072 Comm: a.out Not tainted 4.18.0-rc4+ #51
> [ 141.048446] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),BIOS 1.10.2-1 04/01/2014
> [ 141.049877] Call Trace:
> [ 141.050324] __dump_stack lib/dump_stack.c:77 [inline]
> [ 141.050324] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
> [ 141.050950] ? dump_stack_print_info.cold.2+0x52/0x52 lib/dump_stack.c:60
> [ 141.051837] panic+0x238/0x4e7 kernel/panic.c:184
> [ 141.052386] ? add_taint.cold.5+0x16/0x16 kernel/panic.c:385
> [ 141.053101] ? __warn.cold.8+0x148/0x1ba kernel/panic.c:537
> [ 141.053814] ? __warn.cold.8+0x117/0x1ba kernel/panic.c:530
> [ 141.054506] ? get_callee_stack_depth kernel/bpf/verifier.c:1612 [inline]
> [ 141.054506] ? fixup_call_args kernel/bpf/verifier.c:5587 [inline]
> [ 141.054506] ? bpf_check+0x525e/0x5e60 kernel/bpf/verifier.c:5952
> [ 141.055163] __warn.cold.8+0x163/0x1ba kernel/panic.c:538
> [ 141.055820] ? get_callee_stack_depth kernel/bpf/verifier.c:1612 [inline]
> [ 141.055820] ? fixup_call_args kernel/bpf/verifier.c:5587 [inline]
> [ 141.055820] ? bpf_check+0x525e/0x5e60 kernel/bpf/verifier.c:5952
> [...]
>
> What happens in jit_subprogs() is that kcalloc() for the subprog func
> buffer is failing with NULL where we then bail out. Latter is a plain
> return -ENOMEM, and this is definitely not okay since earlier in the
> loop we are walking all subprogs and temporarily rewrite insn->off to
> remember the subprog id as well as insn->imm to temporarily point the
> call to __bpf_call_base + 1 for the initial JIT pass. Thus, bailing
> out in such state and handing this over to the interpreter is troublesome
> since later/subsequent e.g. find_subprog() lookups are based on wrong
> insn->imm.
>
> Therefore, once we hit this point, we need to jump to out_free path
> where we undo all changes from earlier loop, so that interpreter can
> work on unmodified insn->{off,imm}.
>
> Another point is that should find_subprog() fail in jit_subprogs() due
> to a verifier bug, then we also should not simply defer the program to
> the interpreter since also here we did partial modifications. Instead
> we should just bail out entirely and return an error to the user who is
> trying to load the program.
>
> Fixes: 1c2a088a6626 ("bpf: x64: add JIT support for multi-function programs")
> Reported-by: syzbot+7d427828b2ea6e592804@syzkaller.appspotmail.com
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Applied, Thanks
^ permalink raw reply
* Re: WARNING in bpf_check
From: Daniel Borkmann @ 2018-07-12 21:15 UTC (permalink / raw)
To: Dmitry Vyukov, syzbot; +Cc: Alexei Starovoitov, LKML, netdev, syzkaller-bugs
In-Reply-To: <CACT4Y+aDK2yFb=8GGMEL8+Tfq6VVJhU-jrhMrQj9KywmMBNHNg@mail.gmail.com>
On 07/12/2018 09:51 AM, Dmitry Vyukov wrote:
> On Thu, Jul 12, 2018 at 9:41 AM, syzbot
> <syzbot+7d427828b2ea6e592804@syzkaller.appspotmail.com> wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit: 671dffa7de7b Merge branch 'bpf-bpftool-improved-prog-load'
>> git tree: bpf-next
>> console output: https://syzkaller.appspot.com/x/log.txt?x=1550b562400000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=a501a01deaf0fe9
>> dashboard link: https://syzkaller.appspot.com/bug?extid=7d427828b2ea6e592804
>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
#syz fix: bpf: don't leave partial mangled prog in jit_subprogs error path
^ permalink raw reply
* Re: [PATCH 00/14] ARM BPF jit compiler improvements
From: Russell King - ARM Linux @ 2018-07-12 21:02 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev, linux-arm-kernel
In-Reply-To: <bf534d05-8f75-20bc-e25e-4536c1123585@iogearbox.net>
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.
--
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 mlx5-next v1 2/8] net/mlx5: Add support for flow table destination number
From: Or Gerlitz @ 2018-07-12 21:00 UTC (permalink / raw)
To: Yishai Hadas
Cc: Doug Ledford, Jason Gunthorpe, Leon Romanovsky, RDMA mailing list,
Saeed Mahameed, linux-netdev
In-Reply-To: <20180711111045.6282-3-leon@kernel.org>
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?
^ permalink raw reply
* Re: [PATCH mlx5-next v1 1/8] net/mlx5: Add forward compatible support for the FTE match data
From: Or Gerlitz @ 2018-07-12 20:53 UTC (permalink / raw)
To: Yishai Hadas
Cc: Doug Ledford, Jason Gunthorpe, Leon Romanovsky, RDMA mailing list,
Saeed Mahameed, linux-netdev
In-Reply-To: <20180711111045.6282-2-leon@kernel.org>
On Wed, Jul 11, 2018 at 2:10 PM, Leon Romanovsky <leon@kernel.org> wrote:
> From: Yishai Hadas <yishaih@mellanox.com>
>
> Use the PRM size including the reserved when working with the FTE
> match data.
is this actually a bug fix?
> This comes to support forward compatibility for cases that current
> reserved data will be exposed by the firmware and could be used by an
> application by DEVX without changing the kernel.
something went wrong in the phrasing/wording of "used by an application by DEVX"
I can't follow on that part of the sentence, please try to improve/fix it.
> Also drop some driver checks around the match criteria leaving the work
> for firmware to enable forward compatibility for future bits there.
not following,
OTOH we can always patch the kernel to add new bits for checking, why
remove these checks?
OTOH, suppose today we check that one of four bits is set and now one
added bit #5 and the
kernel doesn't check it, what removing the existing four checks buys you?
^ permalink raw reply
* Re: [PATCH 1/2] [RESEND] liquidio: use ktime_get_real_ts64() instead of getnstimeofday64()
From: Felix Manlunas @ 2018-07-12 21:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Derek Chickles, Satanand Burla, Felix Manlunas, Raghu Vatsavayi,
David S. Miller, Intiyaz Basha, Rick Farrington,
Veerasenareddy Burru, Vijaya Mohan Guvva, Weilin Chang, netdev,
linux-kernel
In-Reply-To: <20180711123003.453442-1-arnd@arndb.de>
On Wed, Jul 11, 2018 at 02:29:52PM +0200, Arnd Bergmann wrote:
> 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>
> ---
> drivers/net/ethernet/cavium/liquidio/lio_main.c | 2 +-
> drivers/net/ethernet/cavium/liquidio/octeon_console.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/cavium/liquidio/lio_main.c b/drivers/net/ethernet/cavium/liquidio/lio_main.c
> index 19d03fc24305..30884ad0a509 100644
> --- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
> +++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
> @@ -687,7 +687,7 @@ static void lio_sync_octeon_time(struct work_struct *work)
> lt = (struct lio_time *)sc->virtdptr;
>
> /* Get time of the day */
> - getnstimeofday64(&ts);
> + ktime_get_real_ts64(&ts);
> lt->sec = ts.tv_sec;
> lt->nsec = ts.tv_nsec;
> octeon_swap_8B_data((u64 *)lt, (sizeof(struct lio_time)) / 8);
> diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_console.c b/drivers/net/ethernet/cavium/liquidio/octeon_console.c
> index 7f97ae48efed..0cc2338d8d2a 100644
> --- a/drivers/net/ethernet/cavium/liquidio/octeon_console.c
> +++ b/drivers/net/ethernet/cavium/liquidio/octeon_console.c
> @@ -902,7 +902,7 @@ int octeon_download_firmware(struct octeon_device *oct, const u8 *data,
> *
> * Octeon always uses UTC time. so timezone information is not sent.
> */
> - getnstimeofday64(&ts);
> + ktime_get_real_ts64(&ts);
> ret = snprintf(boottime, MAX_BOOTTIME_SIZE,
> " time_sec=%lld time_nsec=%ld",
> (s64)ts.tv_sec, ts.tv_nsec);
> --
> 2.9.0
>
Acked-by: Felix Manlunas <felix.manlunas@cavium.com>
^ permalink raw reply
* Re: [PATCH iproute2-next v2] net:sched: add action inheritdsfield to skbedit
From: Marcelo Ricardo Leitner @ 2018-07-12 20:50 UTC (permalink / raw)
To: Qiaobin Fu
Cc: dsahern, stephen, davem, netdev, jhs, michel, xiyou.wangcong,
dcaratti
In-Reply-To: <20180712160926.163317-1-qiaobinf@bu.edu>
On Thu, Jul 12, 2018 at 12:09:26PM -0400, Qiaobin Fu wrote:
> @@ -156,6 +162,9 @@ parse_skbedit(struct action_util *a, int *argc_p, char ***argv_p, int tca_id,
> if (flags & SKBEDIT_F_PTYPE)
> addattr_l(n, MAX_MSG, TCA_SKBEDIT_PTYPE,
> &ptype, sizeof(ptype));
> + if (pure_flags != 0)
> + addattr_l(n, MAX_MSG, TCA_SKBEDIT_FLAGS,
> + &pure_flags, sizeof(pure_flags));
It is missing 2 spaces ^--- here, to make the indentation right. (as
in the block above)
Marcelo
^ permalink raw reply
* [PATCH net-next 4/4] ARM: net: bpf: improve 64-bit ALU implementation
From: Russell King @ 2018-07-12 20:50 UTC (permalink / raw)
To: netdev, linux-arm-kernel; +Cc: Daniel Borkmann
In-Reply-To: <20180712205003.GU17271@n2100.armlinux.org.uk>
Improbe the 64-bit ALU implementation from:
movw r8, #65532
movt r8, #65535
movw r9, #65535
movt r9, #65535
ldr r7, [fp, #-44]
adds r7, r7, r8
str r7, [fp, #-44]
ldr r7, [fp, #-40]
adc r7, r7, r9
str r7, [fp, #-40]
to:
movw r8, #65532
movt r8, #65535
movw r9, #65535
movt r9, #65535
ldrd r6, [fp, #-44]
adds r6, r6, r8
adc r7, r7, r9
strd r6, [fp, #-44]
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/net/bpf_jit_32.c | 29 ++++++++++++++++++++++++-----
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index 026612ee8151..25b3ee85066e 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -716,11 +716,30 @@ static inline void emit_a32_alu_r(const s8 dst, const s8 src,
static inline void emit_a32_alu_r64(const bool is64, const s8 dst[],
const s8 src[], struct jit_ctx *ctx,
const u8 op) {
- emit_a32_alu_r(dst_lo, src_lo, ctx, is64, false, op);
- if (is64)
- emit_a32_alu_r(dst_hi, src_hi, ctx, is64, true, op);
- else
- emit_a32_mov_i(dst_hi, 0, ctx);
+ const s8 *tmp = bpf2a32[TMP_REG_1];
+ const s8 *tmp2 = bpf2a32[TMP_REG_2];
+ const s8 *rd;
+
+ rd = arm_bpf_get_reg64(dst, tmp, ctx);
+ if (is64) {
+ const s8 *rs;
+
+ rs = arm_bpf_get_reg64(src, tmp2, ctx);
+
+ /* ALU operation */
+ emit_alu_r(rd[1], rs[1], true, false, op, ctx);
+ emit_alu_r(rd[0], rs[0], true, true, op, ctx);
+ } else {
+ s8 rs;
+
+ rs = arm_bpf_get_reg32(src_lo, tmp2[1], ctx);
+
+ /* ALU operation */
+ emit_alu_r(rd[1], rs, true, false, op, ctx);
+ emit_a32_mov_i(rd[0], 0, ctx);
+ }
+
+ arm_bpf_put_reg64(dst, rd, ctx);
}
/* dst = src (4 bytes)*/
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 3/4] ARM: net: bpf: improve 64-bit store implementation
From: Russell King @ 2018-07-12 20:50 UTC (permalink / raw)
To: netdev, linux-arm-kernel; +Cc: Daniel Borkmann
In-Reply-To: <20180712205003.GU17271@n2100.armlinux.org.uk>
Improve the 64-bit store implementation from:
ldr r6, [fp, #-8]
str r8, [r6]
ldr r6, [fp, #-8]
mov r7, #4
add r7, r6, r7
str r9, [r7]
to:
ldr r6, [fp, #-8]
str r8, [r6]
str r9, [r6, #4]
We leave the store as two separate STR instructions rather than using
STRD as the store may not be aligned, and STR can handle misalignment.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/net/bpf_jit_32.c | 52 +++++++++++++++++++++++------------------------
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index 3a182e618441..026612ee8151 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -975,29 +975,42 @@ static inline void emit_a32_mul_r64(const s8 dst[], const s8 src[],
}
/* *(size *)(dst + off) = src */
-static inline void emit_str_r(const s8 dst, const s8 src,
- const s32 off, struct jit_ctx *ctx, const u8 sz){
+static inline void emit_str_r(const s8 dst, const s8 src[],
+ s32 off, struct jit_ctx *ctx, const u8 sz){
const s8 *tmp = bpf2a32[TMP_REG_1];
+ s32 off_max;
s8 rd;
rd = arm_bpf_get_reg32(dst, tmp[1], ctx);
- if (off) {
+
+ if (sz == BPF_H)
+ off_max = 0xff;
+ else
+ off_max = 0xfff;
+
+ if (off < 0 || off > off_max) {
emit_a32_mov_i(tmp[0], off, ctx);
- emit(ARM_ADD_R(tmp[0], rd, tmp[0]), ctx);
+ emit(ARM_ADD_R(tmp[0], tmp[0], rd), ctx);
rd = tmp[0];
+ off = 0;
}
switch (sz) {
- case BPF_W:
- /* Store a Word */
- emit(ARM_STR_I(src, rd, 0), ctx);
+ case BPF_B:
+ /* Store a Byte */
+ emit(ARM_STRB_I(src_lo, rd, off), ctx);
break;
case BPF_H:
/* Store a HalfWord */
- emit(ARM_STRH_I(src, rd, 0), ctx);
+ emit(ARM_STRH_I(src_lo, rd, off), ctx);
break;
- case BPF_B:
- /* Store a Byte */
- emit(ARM_STRB_I(src, rd, 0), ctx);
+ case BPF_W:
+ /* Store a Word */
+ emit(ARM_STR_I(src_lo, rd, off), ctx);
+ break;
+ case BPF_DW:
+ /* Store a Double Word */
+ emit(ARM_STR_I(src_lo, rd, off), ctx);
+ emit(ARM_STR_I(src_hi, rd, off + 4), ctx);
break;
}
}
@@ -1539,16 +1552,14 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx)
case BPF_DW:
/* Sign-extend immediate value into temp reg */
emit_a32_mov_se_i64(true, tmp2, imm, ctx);
- emit_str_r(dst_lo, tmp2[1], off, ctx, BPF_W);
- emit_str_r(dst_lo, tmp2[0], off+4, ctx, BPF_W);
break;
case BPF_W:
case BPF_H:
case BPF_B:
emit_a32_mov_i(tmp2[1], imm, ctx);
- emit_str_r(dst_lo, tmp2[1], off, ctx, BPF_SIZE(code));
break;
}
+ emit_str_r(dst_lo, tmp2, off, ctx, BPF_SIZE(code));
break;
/* STX XADD: lock *(u32 *)(dst + off) += src */
case BPF_STX | BPF_XADD | BPF_W:
@@ -1560,20 +1571,9 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx)
case BPF_STX | BPF_MEM | BPF_H:
case BPF_STX | BPF_MEM | BPF_B:
case BPF_STX | BPF_MEM | BPF_DW:
- {
- u8 sz = BPF_SIZE(code);
-
rs = arm_bpf_get_reg64(src, tmp2, ctx);
-
- /* Store the value */
- if (BPF_SIZE(code) == BPF_DW) {
- emit_str_r(dst_lo, rs[1], off, ctx, BPF_W);
- emit_str_r(dst_lo, rs[0], off+4, ctx, BPF_W);
- } else {
- emit_str_r(dst_lo, rs[1], off, ctx, sz);
- }
+ emit_str_r(dst_lo, rs, off, ctx, BPF_SIZE(code));
break;
- }
/* PC += off if dst == src */
/* PC += off if dst > src */
/* PC += off if dst >= src */
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 2/4] ARM: net: bpf: improve 64-bit sign-extended immediate load
From: Russell King @ 2018-07-12 20:50 UTC (permalink / raw)
To: netdev, linux-arm-kernel; +Cc: Daniel Borkmann
In-Reply-To: <20180712205003.GU17271@n2100.armlinux.org.uk>
Improve the 64-bit sign-extended immediate from:
mov r6, #1
str r6, [fp, #-52] ; 0xffffffcc
mov r6, #0
str r6, [fp, #-48] ; 0xffffffd0
to:
mov r6, #1
mov r7, #0
strd r6, [fp, #-52] ; 0xffffffcc
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/net/bpf_jit_32.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index 6558bd73bbb9..3a182e618441 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -613,12 +613,11 @@ static void emit_a32_mov_i64(const s8 dst[], u64 val, struct jit_ctx *ctx)
/* Sign extended move */
static inline void emit_a32_mov_se_i64(const bool is64, const s8 dst[],
const u32 val, struct jit_ctx *ctx) {
- u32 hi = 0;
+ u64 val64 = val;
if (is64 && (val & (1<<31)))
- hi = (u32)~0;
- emit_a32_mov_i(dst_lo, val, ctx);
- emit_a32_mov_i(dst_hi, hi, ctx);
+ val64 |= 0xffffffff00000000ULL;
+ emit_a32_mov_i64(dst, val64, ctx);
}
static inline void emit_a32_add_r(const u8 dst, const u8 src,
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 1/4] ARM: net: bpf: improve 64-bit load immediate implementation
From: Russell King @ 2018-07-12 20:50 UTC (permalink / raw)
To: netdev, linux-arm-kernel; +Cc: Daniel Borkmann
In-Reply-To: <20180712205003.GU17271@n2100.armlinux.org.uk>
Rather than writing each 32-bit half of the 64-bit immediate value
separately when the register is on the stack:
movw r6, #45056 ; 0xb000
movt r6, #60979 ; 0xee33
str r6, [fp, #-44] ; 0xffffffd4
mov r6, #0
str r6, [fp, #-40] ; 0xffffffd8
arrange to use the double-word store when available instead:
movw r6, #45056 ; 0xb000
movt r6, #60979 ; 0xee33
mov r7, #0
strd r6, [fp, #-44] ; 0xffffffd4
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/net/bpf_jit_32.c | 32 ++++++++++++++++++++------------
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index a9f68a924800..6558bd73bbb9 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -599,9 +599,20 @@ static inline void emit_a32_mov_i(const s8 dst, const u32 val,
}
}
+static void emit_a32_mov_i64(const s8 dst[], u64 val, struct jit_ctx *ctx)
+{
+ const s8 *tmp = bpf2a32[TMP_REG_1];
+ const s8 *rd = is_stacked(dst_lo) ? tmp : dst;
+
+ emit_mov_i(rd[1], (u32)val, ctx);
+ emit_mov_i(rd[0], val >> 32, ctx);
+
+ arm_bpf_put_reg64(dst, rd, ctx);
+}
+
/* Sign extended move */
-static inline void emit_a32_mov_i64(const bool is64, const s8 dst[],
- const u32 val, struct jit_ctx *ctx) {
+static inline void emit_a32_mov_se_i64(const bool is64, const s8 dst[],
+ const u32 val, struct jit_ctx *ctx) {
u32 hi = 0;
if (is64 && (val & (1<<31)))
@@ -1309,7 +1320,7 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx)
break;
case BPF_K:
/* Sign-extend immediate value to destination reg */
- emit_a32_mov_i64(is64, dst, imm, ctx);
+ emit_a32_mov_se_i64(is64, dst, imm, ctx);
break;
}
break;
@@ -1358,7 +1369,7 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx)
* value into temporary reg and then it would be
* safe to do the operation on it.
*/
- emit_a32_mov_i64(is64, tmp2, imm, ctx);
+ emit_a32_mov_se_i64(is64, tmp2, imm, ctx);
emit_a32_alu_r64(is64, dst, tmp2, ctx, BPF_OP(code));
break;
}
@@ -1454,7 +1465,7 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx)
* reg then it would be safe to do the operation
* on it.
*/
- emit_a32_mov_i64(is64, tmp2, imm, ctx);
+ emit_a32_mov_se_i64(is64, tmp2, imm, ctx);
emit_a32_mul_r64(dst, tmp2, ctx);
break;
}
@@ -1506,12 +1517,9 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx)
/* dst = imm64 */
case BPF_LD | BPF_IMM | BPF_DW:
{
- const struct bpf_insn insn1 = insn[1];
- u32 hi, lo = imm;
+ u64 val = (u32)imm | (u64)insn[1].imm << 32;
- hi = insn1.imm;
- emit_a32_mov_i(dst_lo, lo, ctx);
- emit_a32_mov_i(dst_hi, hi, ctx);
+ emit_a32_mov_i64(dst, val, ctx);
return 1;
}
@@ -1531,7 +1539,7 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx)
switch (BPF_SIZE(code)) {
case BPF_DW:
/* Sign-extend immediate value into temp reg */
- emit_a32_mov_i64(true, tmp2, imm, ctx);
+ emit_a32_mov_se_i64(true, tmp2, imm, ctx);
emit_str_r(dst_lo, tmp2[1], off, ctx, BPF_W);
emit_str_r(dst_lo, tmp2[0], off+4, ctx, BPF_W);
break;
@@ -1620,7 +1628,7 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx)
rm = tmp2[0];
rn = tmp2[1];
/* Sign-extend immediate value */
- emit_a32_mov_i64(true, tmp2, imm, ctx);
+ emit_a32_mov_se_i64(true, tmp2, imm, ctx);
go_jmp:
/* Setup destination register */
rd = arm_bpf_get_reg64(dst, tmp, ctx);
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 0/4] Further ARM BPF jit compiler improvements
From: Russell King - ARM Linux @ 2018-07-12 20:50 UTC (permalink / raw)
To: netdev, linux-arm-kernel; +Cc: Daniel Borkmann
Four further jit compiler improves for 32-bit ARM.
arch/arm/net/bpf_jit_32.c | 120 ++++++++++++++++++++++++++++------------------
1 file changed, 73 insertions(+), 47 deletions(-)
--
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
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