* Re: [PATCH][net-next] bridge: remove redundant check on err in br_multicast_ipv4_rcv
From: David Miller @ 2019-02-21 21:57 UTC (permalink / raw)
To: lirongqing; +Cc: netdev
In-Reply-To: <1550542629-17121-1-git-send-email-lirongqing@baidu.com>
From: Li RongQing <lirongqing@baidu.com>
Date: Tue, 19 Feb 2019 10:17:09 +0800
> br_ip4_multicast_mrd_rcv only return 0 and -ENOMSG,
> no other negative value
>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/2] xdp: Add devmap_idx map type for looking up devices by ifindex
From: Jakub Kicinski @ 2019-02-21 21:49 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: David Miller, netdev, Jesper Dangaard Brouer, Daniel Borkmann,
Alexei Starovoitov
In-Reply-To: <155075021407.13610.6656977312753058829.stgit@alrua-x1>
On Thu, 21 Feb 2019 12:56:54 +0100, Toke Høiland-Jørgensen wrote:
> A common pattern when using xdp_redirect_map() is to create a device map
> where the lookup key is simply ifindex. Because device maps are arrays,
> this leaves holes in the map, and the map has to be sized to fit the
> largest ifindex, regardless of how many devices actually are actually
> needed in the map.
>
> This patch adds a second type of device map where the key is interpreted as
> an ifindex and looked up using a hashmap, instead of being used as an array
> index. This leads to maps being densely packed, so they can be smaller.
>
> The default maps used by xdp_redirect() are changed to use the new map
> type, which means that xdp_redirect() is no longer limited to ifindex < 64,
> but instead to 64 total simultaneous interfaces per network namespace. This
> also provides an easy way to compare the performance of devmap and
> devmap_idx:
>
> xdp_redirect_map (devmap): 8394560 pkt/s
> xdp_redirect (devmap_idx): 8179480 pkt/s
>
> Difference: 215080 pkt/s or 3.1 nanoseconds per packet.
Could you share what the ifindex mix was here, to arrive at these
numbers? How does it compare to using an array but not keying with
ifindex?
> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
> +static int dev_map_idx_update_elem(struct bpf_map *map, void *key, void *value,
> + u64 map_flags)
> +{
> + struct bpf_dtab *dtab = container_of(map, struct bpf_dtab, map);
> + struct bpf_dtab_netdev *dev, *old_dev;
> + u32 idx = *(u32 *)key;
> + u32 val = *(u32 *)value;
> + u32 bit;
> +
> + if (unlikely(map_flags > BPF_EXIST))
> + return -EINVAL;
> + if (unlikely(map_flags == BPF_NOEXIST))
> + return -EEXIST;
> +
> + old_dev = __dev_map_idx_lookup_elem(map, idx);
> + if (!val) {
> + if (!old_dev)
> + return 0;
IMHO this is a fairly strange mix of array and hashmap semantics. I
think you should stick to hashmap behaviour AFA flags and update/delete
goes.
> + xchg(&dtab->netdev_map[old_dev->bit], NULL);
> + spin_lock(&dtab->index_lock);
> + hlist_del_rcu(&old_dev->index_hlist);
> + spin_unlock(&dtab->index_lock);
> +
> + clear_bit_unlock(old_dev->bit, dtab->bits_used);
> + call_rcu(&old_dev->rcu, __dev_map_entry_free);
> + } else {
> + if (idx != val)
> + return -EINVAL;
> + if (old_dev)
> + return 0;
> + if (!__dev_map_find_bit(dtab, &bit))
> + return -E2BIG;
> + dev = __dev_map_alloc_node(dtab, idx, bit);
> + if (IS_ERR(dev))
> + return PTR_ERR(dev);
> +
> + xchg(&dtab->netdev_map[bit], dev);
> + spin_lock(&dtab->index_lock);
> + hlist_add_head_rcu(&dev->index_hlist,
> + dev_map_index_hash(dtab, dev->ifindex));
> + spin_unlock(&dtab->index_lock);
> + }
> + return 0;
> +}
> +
> const struct bpf_map_ops dev_map_ops = {
> .map_alloc = dev_map_alloc,
> .map_free = dev_map_free,
^ permalink raw reply
* Re: [PATCH] net: remove unneeded switch fall-through
From: David Miller @ 2019-02-21 21:48 UTC (permalink / raw)
To: lirongqing; +Cc: netdev
In-Reply-To: <1550542556-6677-1-git-send-email-lirongqing@baidu.com>
From: Li RongQing <lirongqing@baidu.com>
Date: Tue, 19 Feb 2019 10:15:56 +0800
> This case block has been terminated by a return, so not need
> a switch fall-through
>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: improve definition of __ETHTOOL_LINK_MODE_MASK_NBITS
From: David Miller @ 2019-02-21 21:47 UTC (permalink / raw)
To: hkallweit1; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <d65a539b-dff7-6a00-3166-df47a9efcf0f@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Mon, 18 Feb 2019 21:43:31 +0100
> The way to define __ETHTOOL_LINK_MODE_MASK_NBITS seems to be overly
> complicated, go with a standard approach instead.
> Whilst we're at it, move the comment to the right place.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Hey Heiner, you'll have to respin this after the recent mlx5 pull
into net-next which added new mode values.
Thanks.
^ permalink raw reply
* Re: [PATCH v1 iproute2-next 2/4] Sync up rdma_netlink.h
From: Stephen Hemminger @ 2019-02-21 18:56 UTC (permalink / raw)
To: Steve Wise; +Cc: dsahern, leon, netdev, linux-rdma
In-Reply-To: <ff4f692bee0d683c0638cf88cbf14faf94ea87af.1550773362.git.swise@opengridcomputing.com>
On Thu, 21 Feb 2019 08:19:07 -0800
Steve Wise <swise@opengridcomputing.com> wrote:
> Pull in the latest rdma_netlink.h to get the RDMA_NLDEV_CMD_NEWLINK /
> RDMA_NLDEV_CMD_DELLINK API.
>
> Signed-off-by: Steve Wise <swise@opengridcomputing.com>
> ---
> rdma/include/uapi/rdma/rdma_netlink.h | 74 +++++++++++++++++++++++++++--------
> 1 file changed, 58 insertions(+), 16 deletions(-)
>
> diff --git a/rdma/include/uapi/rdma/rdma_netlink.h b/rdma/include/uapi/rdma/rdma_netlink.h
> index 04c80cebef49..23a90ad52485 100644
> --- a/rdma/include/uapi/rdma/rdma_netlink.h
> +++ b/rdma/include/uapi/rdma/rdma_netlink.h
> @@ -5,8 +5,7 @@
> #include <linux/types.h>
>
> enum {
> - RDMA_NL_RDMA_CM = 1,
> - RDMA_NL_IWCM,
> + RDMA_NL_IWCM = 2,
> RDMA_NL_RSVD,
> RDMA_NL_LS, /* RDMA Local Services */
> RDMA_NL_NLDEV, /* RDMA device interface */
You can't just drop elements from user ABI headers.
That is a break of kernel ABI guarantee.
Instead, mark unused elements:
enum {
RDMA_NL_RDMA_CM = 1, /* deprecated */
RDMA_NL_IWCM,
...
^ permalink raw reply
* Re: [PATCH v2] bonding: fix PACKET_ORIGDEV regression
From: David Miller @ 2019-02-21 21:21 UTC (permalink / raw)
To: soltys; +Cc: zenczykowski, jay.vosburgh, vincent, maheshb, chonggangli, netdev
In-Reply-To: <20190218165528.15575-1-soltys@ziu.info>
From: Michal Soltys <soltys@ziu.info>
Date: Mon, 18 Feb 2019 17:55:28 +0100
> This patch fixes a subtle PACKET_ORIGDEV regression which was a side
> effect of fixes introduced by:
>
> 6a9e461f6fe4 bonding: pass link-local packets to bonding master also.
>
> ... to:
>
> b89f04c61efe bonding: deliver link-local packets with skb->dev set to link that packets arrived on
...
> Fixes: 6a9e461f6fe4 (bonding: pass link-local packets to bonding master also.)
> Reported-by: Vincent Bernat <vincent@bernat.ch>
> Signed-off-by: Michal Soltys <soltys@ziu.info>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] iptunnel: NULL pointer deref for ip_md_tunnel_xmit
From: David Miller @ 2019-02-21 21:19 UTC (permalink / raw)
To: alan.maguire
Cc: netdev, kuznet, yoshfuji, ast, daniel, kafai, songliubraving, yhs
In-Reply-To: <alpine.LRH.2.20.1902181230310.25660@dhcp-10-175-210-25.vpn.oracle.com>
From: Alan Maguire <alan.maguire@oracle.com>
Date: Mon, 18 Feb 2019 12:36:40 +0000 (GMT)
> Naresh Kamboju noted the following oops during execution of selftest
> tools/testing/selftests/bpf/test_tunnel.sh on x86_64:
...
> I'm also seeing the same failure on x86_64, and it reproduces
> consistently.
>
> From poking around it looks like the skb's dst entry is being used
> to calculate the mtu in:
>
> mtu = skb_dst(skb) ? dst_mtu(skb_dst(skb)) : dev->mtu;
>
> ...but because that dst_entry has an "ops" value set to md_dst_ops,
> the various ops (including mtu) are not set:
>
> crash> struct sk_buff._skb_refdst ffff928f87447700 -x
> _skb_refdst = 0xffffcd6fbf5ea590
> crash> struct dst_entry.ops 0xffffcd6fbf5ea590
> ops = 0xffffffffa0193800
> crash> struct dst_ops.mtu 0xffffffffa0193800
> mtu = 0x0
> crash>
>
> I confirmed that the dst entry also has dst->input set to
> dst_md_discard, so it looks like it's an entry that's been
> initialized via __metadata_dst_init alright.
>
> I think the fix here is to use skb_valid_dst(skb) - it checks
> for DST_METADATA also, and with that fix in place, the
> problem - which was previously 100% reproducible - disappears.
>
> The below patch resolves the panic and all bpf tunnel tests pass
> without incident.
>
> Fixes: c8b34e680a09 ("ip_tunnel: Add tnl_update_pmtu in ip_md_tunnel_xmit")
>
> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
This doesn't apply cleanly to the current 'net' tree.
Also, please do not insert an empty line between the Fixes: and other
tags. All tags are equal and should be placed together as an
uninterrupted group.
^ permalink raw reply
* Re: [PATCH net-next] net: sched: potential NULL dereference in tcf_block_find()
From: David Miller @ 2019-02-21 21:11 UTC (permalink / raw)
To: dan.carpenter; +Cc: jhs, vladbu, xiyou.wangcong, jiri, netdev, kernel-janitors
In-Reply-To: <20190218092632.GB7712@kadam>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon, 18 Feb 2019 12:26:32 +0300
> The error code isn't set on this path so it would result in returning
> ERR_PTR(0) and a NULL dereference in the caller.
>
> Fixes: 18d3eefb17cf ("net: sched: refactor tcf_block_find() into standalone functions")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied, thanks.
^ permalink raw reply
* Re: [net PATCH] net: vrf: remove MTU limits for vrf device
From: David Miller @ 2019-02-21 21:10 UTC (permalink / raw)
To: liuhangbin; +Cc: netdev, dsa, dcaratti
In-Reply-To: <20190218091425.11067-1-liuhangbin@gmail.com>
From: Hangbin Liu <liuhangbin@gmail.com>
Date: Mon, 18 Feb 2019 17:14:25 +0800
> Similiar to commit e94cd8113ce63 ("net: remove MTU limits for dummy and
> ifb device"), MTU is irrelevant for VRF device. We init it as 64K while
> limit it to [68, 1500] may make users feel confused.
>
> Reported-by: Jianlin Shi <jishi@redhat.com>
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] lib/test_rhashtable: fix spelling mistake "existant" -> "existent"
From: David Miller @ 2019-02-21 21:09 UTC (permalink / raw)
To: colin.king; +Cc: tgraf, herbert, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20190217225209.17536-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Sun, 17 Feb 2019 22:52:09 +0000
> From: Colin Ian King <colin.king@canonical.com>
>
> There are spelling mistakes in warning macro messages. Fix them.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH net-next v6] ipmr: ip6mr: Create new sockopt to clear mfc cache or vifs
From: David Miller @ 2019-02-21 21:05 UTC (permalink / raw)
To: callum.sinclair
Cc: kuznet, yoshfuji, nikolay, netdev, linux-kernel, nicolas.dichtel
In-Reply-To: <20190217210752.20914-1-callum.sinclair@alliedtelesis.co.nz>
From: Callum Sinclair <callum.sinclair@alliedtelesis.co.nz>
Date: Mon, 18 Feb 2019 10:07:51 +1300
> Created a way to clear the multicast forwarding cache on a socket
> without having to either remove the entries manually using the delete
> entry socket option or destroy and recreate the multicast socket.
>
> Calling the socket option MRT_FLUSH will allow any combination of the
> four flag options to be cleared.
>
> MRT_FLUSH_MFC will clear all non static mfc entries and clear the unresolved cache
> MRT_FLUSH_MFC_STATIC will clear all static mfc entries
> MRT_FLUSH_VIFS will clear all non static interfaces
> MRT_FLUSH_VIFS_STATIC will clear all static interfaces.
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/4] net: phy: improve generic clause 45 aneg configuration
From: David Miller @ 2019-02-21 21:03 UTC (permalink / raw)
To: hkallweit1; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <35d86611-9a07-7239-3310-767d8d1050b5@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Mon, 18 Feb 2019 21:18:35 +0100
> Improve generic clause 45 aneg configuration.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next 0/2] net: phy: improve genphy_read_status
From: David Miller @ 2019-02-21 20:58 UTC (permalink / raw)
To: hkallweit1; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <1a948543-0dc6-d5df-d50a-49134a2a4118@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Mon, 18 Feb 2019 20:28:04 +0100
> Series includes two smaller improvements to genphy_read_status.
Series applied.
^ permalink raw reply
* Re: [PATCH net] MAINTAINERS: mark CAIF as orphan
From: David Miller @ 2019-02-21 20:54 UTC (permalink / raw)
To: jannh; +Cc: netdev, dmitry.tarnyagin, abi.dmitryt, linux-kernel
In-Reply-To: <20190221195816.136157-1-jannh@google.com>
From: Jann Horn <jannh@google.com>
Date: Thu, 21 Feb 2019 20:58:16 +0100
> The listed address for the CAIF maintainer bounces with
> "553 5.3.0 <dmitry.tarnyagin@lockless.no>... No such user here", and the
> only existing email address of the maintainer in git history hasn't
> responded in a week.
> Therefore, remove the listed maintainer and mark CAIF as orphan.
>
> Signed-off-by: Jann Horn <jannh@google.com>
Applied.
^ permalink raw reply
* Re: [net 0/5][pull request] Intel Wired LAN Driver Fixes 2019-02-21
From: David Miller @ 2019-02-21 20:53 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann
In-Reply-To: <20190221193319.22318-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 21 Feb 2019 11:33:14 -0800
> This series contains fixes to ixgbe and i40e.
>
> Majority of the fixes are to resolve XDP issues found in both drivers,
> there is only one fix which is not XDP related. That one fix resolves
> an issue seen on older 10GbE devices, where UDP traffic was either being
> dropped or being transmitted out of order when the bit to enable L3/L4
> filtering for transmit switched packets is enabled on older devices that
> did not support this option.
>
> Magnus fixes an XDP issue for both ixgbe and i40e, where receive rings
> are created but no buffers are allocated for AF_XDP in zero-copy mode,
> so no packets can be received and no interrupts will be generated so
> that NAPI poll function that allocates buffers to the rings will never
> get executed.
>
> Björn fixes a race in XDP xmit ring cleanup for i40e, where
> ndo_xdp_xmit() must be taken into consideration. Added a
> synchronize_rcu() to wait for napi(s) before clearing the queue.
>
> Jan fixes a ixgbe AF_XDP zero-copy transmit issue which can cause a
> reset to be triggered, so add a check to ensure that netif carrier is
> 'ok' before trying to transmit packets.
Pulled, thanks Jeff.
^ permalink raw reply
* RE: [PATCH iproute2-next v1 19/19] rdma: Provide and reuse filter functions
From: Steve Wise @ 2019-02-21 20:39 UTC (permalink / raw)
To: 'Leon Romanovsky', 'David Ahern'
Cc: 'Leon Romanovsky', 'netdev',
'RDMA mailing list', 'Stephen Hemminger'
In-Reply-To: <20190220072136.3840-20-leon@kernel.org>
> -----Original Message-----
> From: linux-rdma-owner@vger.kernel.org <linux-rdma-
> owner@vger.kernel.org> On Behalf Of Leon Romanovsky
> Sent: Wednesday, February 20, 2019 1:22 AM
> To: David Ahern <dsahern@gmail.com>
> Cc: Leon Romanovsky <leonro@mellanox.com>; netdev
> <netdev@vger.kernel.org>; RDMA mailing list <linux-
> rdma@vger.kernel.org>; Stephen Hemminger
> <stephen@networkplumber.org>
> Subject: [PATCH iproute2-next v1 19/19] rdma: Provide and reuse filter
> functions
>
> From: Leon Romanovsky <leonro@mellanox.com>
>
> Globally replace all filter function in safer variants of those
> is_filterred functions, which take into account the availability/lack
"is_filterred" -> "is_filtered"
> of netlink attributes.
>
> Such conversion allowed to fix a number of places in the code, where
> the previous implementation didn't honor filter requests if netlink
> attribute wasn't present.
>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> ---
> rdma/rdma.h | 7 +++---
> rdma/res-cmid.c | 57 +++++++++++++++++++++++++++----------------------
> rdma/res-cq.c | 22 +++++++++++--------
> rdma/res-mr.c | 12 +++++++----
> rdma/res-pd.c | 12 +++++++----
> rdma/res-qp.c | 53 ++++++++++++++++++++++-----------------------
> rdma/utils.c | 26 ++++++++++++++++++----
> 7 files changed, 112 insertions(+), 77 deletions(-)
Reviewed-by: Steve Wise <swise@opengridcomputing.com>
^ permalink raw reply
* Re: [PATCH bpf-next v2] bpf, seccomp: fix false positive preemption splat for cbpf->ebpf progs
From: Alexei Starovoitov @ 2019-02-21 20:36 UTC (permalink / raw)
To: Kees Cook
Cc: Jann Horn, Daniel Borkmann, Andy Lutomirski, Alexei Starovoitov,
Network Development
In-Reply-To: <CAGXu5jKE3PzxNDEMagWFG+37_6FLyQgkLRShHQHB7Ufq-8egDA@mail.gmail.com>
On Thu, Feb 21, 2019 at 11:53:06AM -0800, Kees Cook wrote:
> On Thu, Feb 21, 2019 at 11:29 AM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > On Thu, Feb 21, 2019 at 01:56:53PM +0100, Jann Horn wrote:
> > > On Thu, Feb 21, 2019 at 9:53 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
> > > > On 02/21/2019 06:31 AM, Kees Cook wrote:
> > > > > On Wed, Feb 20, 2019 at 8:03 PM Alexei Starovoitov
> > > > > <alexei.starovoitov@gmail.com> wrote:
> > > > >>
> > > > >> On Wed, Feb 20, 2019 at 3:59 PM Alexei Starovoitov
> > > > >> <alexei.starovoitov@gmail.com> wrote:
> > > > >>>
> > > > >>> On Thu, Feb 21, 2019 at 12:01:35AM +0100, Daniel Borkmann wrote:
> > > > >>>> In 568f196756ad ("bpf: check that BPF programs run with preemption disabled")
> > > > >>>> a check was added for BPF_PROG_RUN() that for every invocation preemption is
> > > > >>>> disabled to not break eBPF assumptions (e.g. per-cpu map). Of course this does
> > > > >>>> not count for seccomp because only cBPF -> eBPF is loaded here and it does
> > > > >>>> not make use of any functionality that would require this assertion. Fix this
> > > > >>>> false positive by adding and using SECCOMP_RUN() variant that does not have
> > > > >>>> the cant_sleep(); check.
> > > > >>>>
> > > > >>>> Fixes: 568f196756ad ("bpf: check that BPF programs run with preemption disabled")
> > > > >>>> Reported-by: syzbot+8bf19ee2aa580de7a2a7@syzkaller.appspotmail.com
> > > > >>>> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> > > > >>>> Acked-by: Kees Cook <keescook@chromium.org>
> > > > >>>
> > > > >>> Applied, Thanks
> > > > >>
> > > > >> Actually I think it's a wrong approach to go long term.
> > > > >> I'm thinking to revert it.
> > > > >> I think it's better to disable preemption for duration of
> > > > >> seccomp cbpf prog.
> > > > >> It's short and there is really no reason for it to be preemptible.
> > > > >> When seccomp switches to ebpf we'll have this weird inconsistency.
> > > > >> Let's just disable preemption for seccomp as well.
> > > > >
> > > > > A lot of changes will be needed for seccomp ebpf -- not the least of
> > > > > which is convincing me there is a use-case. ;)
> > > > >
> > > > > But the main issue is that I'm not a huge fan of dropping two
> > > > > barriers() across syscall entry. That seems pretty heavy-duty for
> > > > > something that is literally not needed right now.
> > > >
> > > > Yeah, I think it's okay to add once actually technically needed. Last
> > > > time I looked, if I recall correctly, at least Chrome installs some
> > > > heavy duty seccomp programs that go close to prog limit.
> > >
> > > Half of that is probably because that seccomp BPF code is so
> > > inefficient, though.
> > >
> > > This snippet shows that those programs constantly recheck the high
> > > halves of arguments:
> > >
> > > Some of the generated code is pointless because all reachable code
> > > from that point on has the same outcome (the last "ret ALLOW" in the
> > > following sample is unreachable because they've already checked that
> > > the high bit of the low half is set, so the low half can't be 3):
> >
> > and with ebpf these optimizations will be available for free
> > because llvm will remove unnecessary loads and simplify branches.
> > There is no technical reason not to use ebpf in seccomp.
> >
> > When we discussed preemption of classic vs extended in socket filters
> > context we agreed to make it a requirement that preemption must be
> > disabled though it's not strictly necessary. RX side of socket filters
> > was already non-preempt while TX was preemptible.
> > We must not make an exception of this rule for seccomp.
> > Hence I've reverted this commit.
> >
> > Here is the actual fix for seccomp:
> > From: Alexei Starovoitov <ast@kernel.org>
> > Date: Thu, 21 Feb 2019 10:40:14 -0800
> > Subject: [PATCH] seccomp, bpf: disable preemption before calling into bpf prog
> >
> > All BPF programs must be called with preemption disabled.
> >
> > Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> > ---
> > kernel/seccomp.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> > index e815781ed751..a43c601ac252 100644
> > --- a/kernel/seccomp.c
> > +++ b/kernel/seccomp.c
> > @@ -267,6 +267,7 @@ static u32 seccomp_run_filters(const struct seccomp_data *sd,
> > * All filters in the list are evaluated and the lowest BPF return
> > * value always takes priority (ignoring the DATA).
> > */
> > + preempt_disable();
> > for (; f; f = f->prev) {
> > u32 cur_ret = BPF_PROG_RUN(f->prog, sd);
> >
> > @@ -275,6 +276,7 @@ static u32 seccomp_run_filters(const struct seccomp_data *sd,
> > *match = f;
> > }
> > }
> > + preempt_enable();
> > return ret;
> > }
> > #endif /* CONFIG_SECCOMP_FILTER */
> > --
> >
> > Doing per-cpu increment of cache hot data is practically free and it makes seccomp
> > play by the rules.
>
> Other accesses should dominate the run time, yes. I'm still not a big
> fan of unconditionally adding this, but I won't NAK. :P
Thank you.
I also would like to touch on your comment:
"A lot of changes will be needed for seccomp ebpf"
There were two attempts to add it in the past and the patches were
small and straightforward.
If I recall correctly both times you nacked them because performance gains
and ease of use arguments were not convincing enough, right?
Are you still not convinced ?
^ permalink raw reply
* RE: [PATCH iproute2-next v1 18/19] rdma: Perform single .doit call to query specific objects
From: Steve Wise @ 2019-02-21 20:35 UTC (permalink / raw)
To: 'Leon Romanovsky', 'David Ahern'
Cc: 'Leon Romanovsky', 'netdev',
'RDMA mailing list', 'Stephen Hemminger'
In-Reply-To: <20190220072136.3840-19-leon@kernel.org>
> -----Original Message-----
> From: linux-rdma-owner@vger.kernel.org <linux-rdma-
> owner@vger.kernel.org> On Behalf Of Leon Romanovsky
> Sent: Wednesday, February 20, 2019 1:22 AM
> To: David Ahern <dsahern@gmail.com>
> Cc: Leon Romanovsky <leonro@mellanox.com>; netdev
> <netdev@vger.kernel.org>; RDMA mailing list <linux-
> rdma@vger.kernel.org>; Stephen Hemminger
> <stephen@networkplumber.org>
> Subject: [PATCH iproute2-next v1 18/19] rdma: Perform single .doit call to
> query specific objects
>
> From: Leon Romanovsky <leonro@mellanox.com>
>
> If user provides specific index, we can speedup query
> by using .doit callback and save full dump and filtering
> after that.
>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> ---
> rdma/rdma.h | 10 +++++-
> rdma/res-cmid.c | 33 +++++++++++++------
> rdma/res-cq.c | 34 ++++++++++++++------
> rdma/res-mr.c | 33 ++++++++++++++-----
> rdma/res-pd.c | 32 ++++++++++++++-----
> rdma/res-qp.c | 32 ++++++++++++++-----
> rdma/res.c | 34 +++++++++++++++++++-
> rdma/res.h | 84 ++++++++++++++++++++++++++++++++-----------------
> rdma/utils.c | 20 ++++++++++++
> 9 files changed, 239 insertions(+), 73 deletions(-)
>
Reviewed-by: Steve Wise <swise@opengridcomputing.com>
^ permalink raw reply
* RE: [PATCH iproute2-next v1 17/19] rdma: Unify netlink attribute checks prior to prints
From: Steve Wise @ 2019-02-21 20:31 UTC (permalink / raw)
To: 'Leon Romanovsky', 'David Ahern'
Cc: 'Leon Romanovsky', 'netdev',
'RDMA mailing list', 'Stephen Hemminger'
In-Reply-To: <20190220072136.3840-18-leon@kernel.org>
> -----Original Message-----
> From: linux-rdma-owner@vger.kernel.org <linux-rdma-
> owner@vger.kernel.org> On Behalf Of Leon Romanovsky
> Sent: Wednesday, February 20, 2019 1:22 AM
> To: David Ahern <dsahern@gmail.com>
> Cc: Leon Romanovsky <leonro@mellanox.com>; netdev
> <netdev@vger.kernel.org>; RDMA mailing list <linux-
> rdma@vger.kernel.org>; Stephen Hemminger
> <stephen@networkplumber.org>
> Subject: [PATCH iproute2-next v1 17/19] rdma: Unify netlink attribute
checks
> prior to prints
>
> From: Leon Romanovsky <leonro@mellanox.com>
>
> Place check if netlink attribute available in general place,
> instead of doing the same check in many paces.
>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> ---
> rdma/res-cmid.c | 9 ++++-----
> rdma/res-cq.c | 22 +++++++++++-----------
> rdma/res-mr.c | 21 +++++++--------------
> rdma/res-pd.c | 20 +++++++++-----------
> rdma/res-qp.c | 10 +++++-----
> rdma/res.c | 16 +++++++++++++---
> rdma/res.h | 6 ++++--
> 7 files changed, 53 insertions(+), 51 deletions(-)
Reviewed-by: Steve Wise <swise@opengridcomputing.com>
^ permalink raw reply
* RE: [PATCH iproute2-next v1 16/19] rdma: Move QP code to separate function
From: Steve Wise @ 2019-02-21 20:29 UTC (permalink / raw)
To: 'Leon Romanovsky', 'David Ahern'
Cc: 'Leon Romanovsky', 'netdev',
'RDMA mailing list', 'Stephen Hemminger'
In-Reply-To: <20190220072136.3840-17-leon@kernel.org>
> -----Original Message-----
> From: linux-rdma-owner@vger.kernel.org <linux-rdma-
> owner@vger.kernel.org> On Behalf Of Leon Romanovsky
> Sent: Wednesday, February 20, 2019 1:22 AM
> To: David Ahern <dsahern@gmail.com>
> Cc: Leon Romanovsky <leonro@mellanox.com>; netdev
> <netdev@vger.kernel.org>; RDMA mailing list <linux-
> rdma@vger.kernel.org>; Stephen Hemminger
> <stephen@networkplumber.org>
> Subject: [PATCH iproute2-next v1 16/19] rdma: Move QP code to separate
> function
>
> From: Leon Romanovsky <leonro@mellanox.com>
>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> ---
> rdma/res-qp.c | 253 +++++++++++++++++++++++++-------------------------
> 1 file changed, 127 insertions(+), 126 deletions(-)
Reviewed-by: Steve Wise <swise@opengridcomputing.com>
^ permalink raw reply
* RE: [PATCH iproute2-next v1 15/19] rdma: Separate PD code
From: Steve Wise @ 2019-02-21 20:29 UTC (permalink / raw)
To: 'Leon Romanovsky', 'David Ahern'
Cc: 'Leon Romanovsky', 'netdev',
'RDMA mailing list', 'Stephen Hemminger'
In-Reply-To: <20190220072136.3840-16-leon@kernel.org>
> -----Original Message-----
> From: linux-rdma-owner@vger.kernel.org <linux-rdma-
> owner@vger.kernel.org> On Behalf Of Leon Romanovsky
> Sent: Wednesday, February 20, 2019 1:22 AM
> To: David Ahern <dsahern@gmail.com>
> Cc: Leon Romanovsky <leonro@mellanox.com>; netdev
> <netdev@vger.kernel.org>; RDMA mailing list <linux-
> rdma@vger.kernel.org>; Stephen Hemminger
> <stephen@networkplumber.org>
> Subject: [PATCH iproute2-next v1 15/19] rdma: Separate PD code
>
> From: Leon Romanovsky <leonro@mellanox.com>
>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> ---
> rdma/res-pd.c | 170 ++++++++++++++++++++++++++------------------------
> 1 file changed, 89 insertions(+), 81 deletions(-)
commit text is wrong.
Reviewed-by: Steve Wise <swise@opengridcomputing.com>
^ permalink raw reply
* RE: [PATCH iproute2-next v1 14/19] rdma: Separate MR code
From: Steve Wise @ 2019-02-21 20:28 UTC (permalink / raw)
To: 'Leon Romanovsky', 'David Ahern'
Cc: 'Leon Romanovsky', 'netdev',
'RDMA mailing list', 'Stephen Hemminger'
In-Reply-To: <20190220072136.3840-15-leon@kernel.org>
> -----Original Message-----
> From: linux-rdma-owner@vger.kernel.org <linux-rdma-
> owner@vger.kernel.org> On Behalf Of Leon Romanovsky
> Sent: Wednesday, February 20, 2019 1:22 AM
> To: David Ahern <dsahern@gmail.com>
> Cc: Leon Romanovsky <leonro@mellanox.com>; netdev
> <netdev@vger.kernel.org>; RDMA mailing list <linux-
> rdma@vger.kernel.org>; Stephen Hemminger
> <stephen@networkplumber.org>
> Subject: [PATCH iproute2-next v1 14/19] rdma: Separate MR code
>
> From: Leon Romanovsky <leonro@mellanox.com>
>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> ---
> rdma/res-mr.c | 178 +++++++++++++++++++++++++-------------------------
> 1 file changed, 90 insertions(+), 88 deletions(-)
The commit description is wrong.
Reviewed-by: Steve Wise <swise@opengridcomputing.com>
^ permalink raw reply
* RE: [PATCH iproute2-next v1 13/19] rdma: Refactor CQ prints
From: Steve Wise @ 2019-02-21 20:27 UTC (permalink / raw)
To: 'Leon Romanovsky', 'David Ahern'
Cc: 'Leon Romanovsky', 'netdev',
'RDMA mailing list', 'Stephen Hemminger'
In-Reply-To: <20190220072136.3840-14-leon@kernel.org>
> -----Original Message-----
> From: linux-rdma-owner@vger.kernel.org <linux-rdma-
> owner@vger.kernel.org> On Behalf Of Leon Romanovsky
> Sent: Wednesday, February 20, 2019 1:22 AM
> To: David Ahern <dsahern@gmail.com>
> Cc: Leon Romanovsky <leonro@mellanox.com>; netdev
> <netdev@vger.kernel.org>; RDMA mailing list <linux-
> rdma@vger.kernel.org>; Stephen Hemminger
> <stephen@networkplumber.org>
> Subject: [PATCH iproute2-next v1 13/19] rdma: Refactor CQ prints
>
> From: Leon Romanovsky <leonro@mellanox.com>
>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> ---
> rdma/res-cq.c | 177 ++++++++++++++++++++++++++------------------------
> 1 file changed, 91 insertions(+), 86 deletions(-)
Reviewed-by: Steve Wise <swise@opengridcomputing.com>
^ permalink raw reply
* RE: [PATCH iproute2-next v1 12/19] rdma: Simplify CM_ID print code
From: Steve Wise @ 2019-02-21 20:26 UTC (permalink / raw)
To: 'Leon Romanovsky', 'David Ahern'
Cc: 'Leon Romanovsky', 'netdev',
'RDMA mailing list', 'Stephen Hemminger'
In-Reply-To: <20190220072136.3840-13-leon@kernel.org>
> -----Original Message-----
> From: linux-rdma-owner@vger.kernel.org <linux-rdma-
> owner@vger.kernel.org> On Behalf Of Leon Romanovsky
> Sent: Wednesday, February 20, 2019 1:21 AM
> To: David Ahern <dsahern@gmail.com>
> Cc: Leon Romanovsky <leonro@mellanox.com>; netdev
> <netdev@vger.kernel.org>; RDMA mailing list <linux-
> rdma@vger.kernel.org>; Stephen Hemminger
> <stephen@networkplumber.org>
> Subject: [PATCH iproute2-next v1 12/19] rdma: Simplify CM_ID print code
>
> From: Leon Romanovsky <leonro@mellanox.com>
>
> Refactor our the CM_ID print code.
>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> ---
> rdma/res-cmid.c | 246 ++++++++++++++++++++++++------------------------
> 1 file changed, 124 insertions(+), 122 deletions(-)
Not sure why you refactored, but ok.
Reviewed-by: Steve Wise <swise@opengridcomputing.com>
^ permalink raw reply
* RE: [PATCH iproute2-next v1 11/19] rdma: Simplify code to reuse existing functions
From: Steve Wise @ 2019-02-21 20:23 UTC (permalink / raw)
To: 'Leon Romanovsky', 'David Ahern'
Cc: 'Leon Romanovsky', 'netdev',
'RDMA mailing list', 'Stephen Hemminger'
In-Reply-To: <20190220072136.3840-12-leon@kernel.org>
> -----Original Message-----
> From: linux-rdma-owner@vger.kernel.org <linux-rdma-
> owner@vger.kernel.org> On Behalf Of Leon Romanovsky
> Sent: Wednesday, February 20, 2019 1:21 AM
> To: David Ahern <dsahern@gmail.com>
> Cc: Leon Romanovsky <leonro@mellanox.com>; netdev
> <netdev@vger.kernel.org>; RDMA mailing list <linux-
> rdma@vger.kernel.org>; Stephen Hemminger
> <stephen@networkplumber.org>
> Subject: [PATCH iproute2-next v1 11/19] rdma: Simplify code to reuse
> existing functions
>
> From: Leon Romanovsky <leonro@mellanox.com>
>
> Remove duplicated functions in favour general res_print_uint() call.
>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> ---
> rdma/res-cmid.c | 4 ++--
> rdma/res-cq.c | 14 +++-----------
> rdma/res-mr.c | 2 +-
> rdma/res-pd.c | 4 ++--
> rdma/res-qp.c | 14 +++-----------
> rdma/res.c | 34 ++--------------------------------
> rdma/res.h | 3 ---
> 7 files changed, 13 insertions(+), 62 deletions(-)
>
Reviewed-by: Steve Wise <swise@opengridcomputing.com>
^ 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