* Re: [PATCH] net: smc_close: mark expected switch fall-throughs
From: David Miller @ 2017-10-22 1:08 UTC (permalink / raw)
To: garsilva; +Cc: ubraun, linux-s390, netdev, linux-kernel
In-Reply-To: <20171019220244.GA22041@embeddedor.com>
From: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
Date: Thu, 19 Oct 2017 17:02:44 -0500
> @@ -360,7 +360,8 @@ static void smc_close_passive_work(struct work_struct *work)
> case SMC_PEERCLOSEWAIT1:
> if (rxflags->peer_done_writing)
> sk->sk_state = SMC_PEERCLOSEWAIT2;
> - /* fall through to check for closing */
> + /* to check for closing */
> + /* fall through */
Gustavo please look at what you are doing to the code.
This was a nice easy to read sentence in the comment, and now
you've chopped it up into two pieces and made it awkward and
more difficult to read.
^ permalink raw reply
* Re: [PATCH] net: sched: mark expected switch fall-throughs
From: David Miller @ 2017-10-22 1:07 UTC (permalink / raw)
To: garsilva; +Cc: jhs, xiyou.wangcong, jiri, netdev, linux-kernel
In-Reply-To: <20171019212824.GA7885@embeddedor.com>
From: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
Date: Thu, 19 Oct 2017 16:28:24 -0500
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] soreuseport: fix initialization race
From: David Miller @ 2017-10-22 1:04 UTC (permalink / raw)
To: kraigatgoog; +Cc: netdev
In-Reply-To: <20171019190029.163693-1-kraigatgoog@gmail.com>
From: Craig Gallek <kraigatgoog@gmail.com>
Date: Thu, 19 Oct 2017 15:00:29 -0400
> From: Craig Gallek <kraig@google.com>
>
> Syzkaller stumbled upon a way to trigger
> WARNING: CPU: 1 PID: 13881 at net/core/sock_reuseport.c:41
> reuseport_alloc+0x306/0x3b0 net/core/sock_reuseport.c:39
>
> There are two initialization paths for the sock_reuseport structure in a
> socket: Through the udp/tcp bind paths of SO_REUSEPORT sockets or through
> SO_ATTACH_REUSEPORT_[CE]BPF before bind. The existing implementation
> assumedthat the socket lock protected both of these paths when it actually
> only protects the SO_ATTACH_REUSEPORT path. Syzkaller triggered this
> double allocation by running these paths concurrently.
>
> This patch moves the check for double allocation into the reuseport_alloc
> function which is protected by a global spin lock.
>
> Fixes: e32ea7e74727 ("soreuseport: fast reuseport UDP socket selection")
> Fixes: c125e80b8868 ("soreuseport: fast reuseport TCP socket selection")
> Signed-off-by: Craig Gallek <kraig@google.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH] net: rose: mark expected switch fall-throughs
From: David Miller @ 2017-10-22 1:02 UTC (permalink / raw)
To: garsilva; +Cc: ralf, linux-hams, netdev, linux-kernel
In-Reply-To: <20171019180351.GA11525@embeddedor.com>
From: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
Date: Thu, 19 Oct 2017 13:03:51 -0500
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH] openvswitch: conntrack: mark expected switch fall-through
From: David Miller @ 2017-10-22 1:02 UTC (permalink / raw)
To: garsilva-L1vi/lXTdts+Va1GwOuvDg
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
pshelar-l0M0P4e3n4LQT0dZR+AlfA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171019175503.GA28691-L1vi/lXTdts+Va1GwOuvDg@public.gmane.org>
From: "Gustavo A. R. Silva" <garsilva-L1vi/lXTdts+Va1GwOuvDg@public.gmane.org>
Date: Thu, 19 Oct 2017 12:55:03 -0500
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Notice that in this particular case I placed a "fall through" comment on
> its own line, which is what GCC is expecting to find.
>
> Signed-off-by: Gustavo A. R. Silva <garsilva-L1vi/lXTdts+Va1GwOuvDg@public.gmane.org>
Applied.
^ permalink raw reply
* Re: [PATCH] net: netrom: nr_in: mark expected switch fall-through
From: David Miller @ 2017-10-22 1:00 UTC (permalink / raw)
To: garsilva; +Cc: ralf, linux-hams, netdev, linux-kernel
In-Reply-To: <20171019174308.GA21742@embeddedor.com>
From: "Gustavo A. R. Silva" <garsilva@embeddedor.com>
Date: Thu, 19 Oct 2017 12:43:08 -0500
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH net] net: bridge: fix returning of vlan range op errors
From: David Miller @ 2017-10-22 0:52 UTC (permalink / raw)
To: nikolay; +Cc: netdev, bridge, roopa, stephen
In-Reply-To: <1508433452-23812-1-git-send-email-nikolay@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Thu, 19 Oct 2017 20:17:32 +0300
> When vlan tunnels were introduced, vlan range errors got silently
> dropped and instead 0 was returned always. Restore the previous
> behaviour and return errors to user-space.
>
> Fixes: efa5356b0d97 ("bridge: per vlan dst_metadata netlink support")
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] sock: correct sk_wmem_queued accounting on efault in tcp zerocopy
From: David Miller @ 2017-10-22 0:52 UTC (permalink / raw)
To: willemdebruijn.kernel; +Cc: netdev, edumazet, willemb
In-Reply-To: <20171019164039.20927-1-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Thu, 19 Oct 2017 12:40:39 -0400
> From: Willem de Bruijn <willemb@google.com>
>
> Syzkaller hits WARN_ON(sk->sk_wmem_queued) in sk_stream_kill_queues
> after triggering an EFAULT in __zerocopy_sg_from_iter.
>
> On this error, skb_zerocopy_stream_iter resets the skb to its state
> before the operation with __pskb_trim. It cannot kfree_skb like
> datagram callers, as the skb may have data from a previous send call.
>
> __pskb_trim calls skb_condense for unowned skbs, which adjusts their
> truesize. These tcp skbuffs are owned and their truesize must add up
> to sk_wmem_queued. But they match because their skb->sk is NULL until
> tcp_transmit_skb.
>
> Temporarily set skb->sk when calling __pskb_trim to signal that the
> skbuffs are owned and avoid the skb_condense path.
>
> Fixes: 52267790ef52 ("sock: add MSG_ZEROCOPY")
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Applied.
^ permalink raw reply
* [jkirsher/next-queue PATCH] i40e/i40evf: Revert "i40e/i40evf: bump tail only in multiples of 8"
From: Alexander Duyck @ 2017-10-22 0:51 UTC (permalink / raw)
To: netdev, intel-wired-lan, akp, pstaszewski
From: Alexander Duyck <alexander.h.duyck@intel.com>
This reverts commit 11f29003d6376fb123b7c3779dba49bb56fb0815.
I am reverting this as I am fairly certain this can result in a memory leak
when combined with the current page recycling scheme. Specifically we end
up attempting to allocate fewer buffers than we recycled and this results
in us rewinding the next to alloc pointer which leads to leaks when we
overwrite the rx_buffer_info when processing the next frame.
Fixes: 11f29003d637 ("i40e/i40evf: bump tail only in multiples of 8")
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 9 ---------
drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 9 ---------
2 files changed, 18 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index edbc94c4353d..487e2f483fa1 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -1407,15 +1407,6 @@ bool i40e_alloc_rx_buffers(struct i40e_ring *rx_ring, u16 cleaned_count)
union i40e_rx_desc *rx_desc;
struct i40e_rx_buffer *bi;
- /* Hardware only fetches new descriptors in cache lines of 8,
- * essentially ignoring the lower 3 bits of the tail register. We want
- * to ensure our tail writes are aligned to avoid unnecessary work. We
- * can't simply round down the cleaned count, since we might fail to
- * allocate some buffers. What we really want is to ensure that
- * next_to_used + cleaned_count produces an aligned value.
- */
- cleaned_count -= (ntu + cleaned_count) & 0x7;
-
/* do nothing if no valid netdev defined */
if (!rx_ring->netdev || !cleaned_count)
return false;
diff --git a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
index 6806ada11490..fe817e2b6fef 100644
--- a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
@@ -711,15 +711,6 @@ bool i40evf_alloc_rx_buffers(struct i40e_ring *rx_ring, u16 cleaned_count)
union i40e_rx_desc *rx_desc;
struct i40e_rx_buffer *bi;
- /* Hardware only fetches new descriptors in cache lines of 8,
- * essentially ignoring the lower 3 bits of the tail register. We want
- * to ensure our tail writes are aligned to avoid unnecessary work. We
- * can't simply round down the cleaned count, since we might fail to
- * allocate some buffers. What we really want is to ensure that
- * next_to_used + cleaned_count produces an aligned value.
- */
- cleaned_count -= (ntu + cleaned_count) & 0x7;
-
/* do nothing if no valid netdev defined */
if (!rx_ring->netdev || !cleaned_count)
return false;
^ permalink raw reply related
* Re: [PATCH net-next 0/2] bridge: make setlink/dellink notifications more accurate
From: David Miller @ 2017-10-22 0:45 UTC (permalink / raw)
To: nikolay; +Cc: netdev, roopa, bridge, mrv, dsa
In-Reply-To: <01c5bff2-cb5d-2b52-b11b-d6c2e1ab52a8@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Thu, 19 Oct 2017 19:10:11 +0300
> Self-NAK
> Dave, please ignore this set and apologies for the noise.
OK
^ permalink raw reply
* Re: [PATCH net 0/3] Two BPF fixes for range marking
From: David Miller @ 2017-10-22 0:13 UTC (permalink / raw)
To: daniel; +Cc: alexei.starovoitov, john.r.fastabend, netdev
In-Reply-To: <cover.1508545543.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Sat, 21 Oct 2017 02:34:20 +0200
> The set contains two fixes for direct packet access range
> markings and test cases for all direct packet access patterns
> that the verifier matches on.
>
> They are targeted for net tree, note that once net gets merged
> into net-next, there will be a minor merge conflict due to
> signature change of the function find_good_pkt_pointers() as
> well as data_meta patterns present in net-next tree. You can
> just add bool false to the data_meta patterns and I will
> follow-up with properly converting the patterns for data_meta
> in a similar way.
Series applied and thanks for the merge info.
^ permalink raw reply
* Re: [net PATCH] bpf: devmap fix arithmetic overflow in bitmap_size calculation
From: David Miller @ 2017-10-21 23:54 UTC (permalink / raw)
To: john.r.fastabend; +Cc: richard, alexei.starovoitov, netdev, borkmann
In-Reply-To: <150842903200.12537.10765604428561566031.stgit@john-XPS-13-9360>
From: John Fastabend <john.r.fastabend@gmail.com>
Date: Thu, 19 Oct 2017 09:03:52 -0700
> An integer overflow is possible in dev_map_bitmap_size() when
> calculating the BITS_TO_LONG logic which becomes, after macro
> replacement,
>
> (((n) + (d) - 1)/ (d))
>
> where 'n' is a __u32 and 'd' is (8 * sizeof(long)). To avoid
> overflow cast to u64 before arithmetic.
>
> Reported-by: Richard Weinberger <richard@nod.at>
> Acked-by: Daniel Borkmann <daniel@iogearbox.net>
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Applied.
^ permalink raw reply
* Re: [RFC PATCH] net: realtek: r8169: implement set_link_ksettings()
From: Tobias Jakobi @ 2017-10-21 19:37 UTC (permalink / raw)
To: nic_swsd; +Cc: netdev, tremyfr, davem
In-Reply-To: <20171013164424.4480-1-tjakobi@math.uni-bielefeld.de>
Any comment on this one? I have been using this in my tree since submission. No
issues to far.
I guess I could also put a Fixes-tag?
- Tobias
Tobias Jakobi wrote:
> Commit 6fa1ba61520576cf1346c4ff09a056f2950cb3bf partially
> implemented the new ethtool API, by replacing get_settings()
> with get_link_ksettings(). This breaks ethtool, since the
> userspace tool (according to the new API specs) never tries
> the legacy set() call, when the new get() call succeeds.
>
> All attempts to chance some setting from userspace result in:
>> Cannot set new settings: Operation not supported
>
> Implement the missing set() call.
>
> Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
> ---
> drivers/net/ethernet/realtek/r8169.c | 40 +++++++++++++++++++++---------------
> 1 file changed, 24 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
> index e03fcf914690..24e8f7133038 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -2025,21 +2025,6 @@ static int rtl8169_set_speed(struct net_device *dev,
> return ret;
> }
>
> -static int rtl8169_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
> -{
> - struct rtl8169_private *tp = netdev_priv(dev);
> - int ret;
> -
> - del_timer_sync(&tp->timer);
> -
> - rtl_lock_work(tp);
> - ret = rtl8169_set_speed(dev, cmd->autoneg, ethtool_cmd_speed(cmd),
> - cmd->duplex, cmd->advertising);
> - rtl_unlock_work(tp);
> -
> - return ret;
> -}
> -
> static netdev_features_t rtl8169_fix_features(struct net_device *dev,
> netdev_features_t features)
> {
> @@ -2166,6 +2151,29 @@ static int rtl8169_get_link_ksettings(struct net_device *dev,
> return rc;
> }
>
> +static int rtl8169_set_link_ksettings(struct net_device *dev,
> + const struct ethtool_link_ksettings *cmd)
> +{
> + struct rtl8169_private *tp = netdev_priv(dev);
> + int rc;
> + u32 advertising;
> +
> + if (!ethtool_convert_link_mode_to_legacy_u32(&advertising,
> + cmd->link_modes.advertising))
> + return -EINVAL;
> +
> + del_timer_sync(&tp->timer);
> +
> + rtl_lock_work(tp);
> +
> + rc = rtl8169_set_speed(dev, cmd->base.autoneg, cmd->base.speed,
> + cmd->base.duplex, advertising);
> +
> + rtl_unlock_work(tp);
> +
> + return rc;
> +}
> +
> static void rtl8169_get_regs(struct net_device *dev, struct ethtool_regs *regs,
> void *p)
> {
> @@ -2367,7 +2375,6 @@ static const struct ethtool_ops rtl8169_ethtool_ops = {
> .get_drvinfo = rtl8169_get_drvinfo,
> .get_regs_len = rtl8169_get_regs_len,
> .get_link = ethtool_op_get_link,
> - .set_settings = rtl8169_set_settings,
> .get_msglevel = rtl8169_get_msglevel,
> .set_msglevel = rtl8169_set_msglevel,
> .get_regs = rtl8169_get_regs,
> @@ -2379,6 +2386,7 @@ static const struct ethtool_ops rtl8169_ethtool_ops = {
> .get_ts_info = ethtool_op_get_ts_info,
> .nway_reset = rtl8169_nway_reset,
> .get_link_ksettings = rtl8169_get_link_ksettings,
> + .set_link_ksettings = rtl8169_set_link_ksettings,
> };
>
> static void rtl8169_get_mac_version(struct rtl8169_private *tp,
>
^ permalink raw reply
* Re: [PATCH net-next 3/5] bpf: Add BPF_SOCKET_OPS_BASE_RTT support to tcp_nv
From: Alexei Starovoitov @ 2017-10-21 19:37 UTC (permalink / raw)
To: Lawrence Brakmo
Cc: netdev, Kernel Team, Alexei Starovoitov, Daniel Borkmann,
Blake Matheny
In-Reply-To: <20171020180543.4156833-4-brakmo@fb.com>
On Fri, Oct 20, 2017 at 11:05:41AM -0700, Lawrence Brakmo wrote:
> TCP_NV will try to get the base RTT from a socket_ops BPF program if one
> is loaded. NV will then use the base RTT to bound its min RTT (its
> notion of the base RTT). It uses the base RTT as an upper bound and 80%
> of the base RTT as its lower bound.
...
> Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
> Acked_by: Alexei Starovoitov <ast@fb.com>
^
just noticed the typo above :)
fixing it with:
Acked-by: Alexei Starovoitov <ast@kernel.org>
so patchworks can pick it up automatically.
^ permalink raw reply
* [PATCH net] ipv6: flowlabel: do not leave opt->tot_len with garbage
From: Eric Dumazet @ 2017-10-21 19:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
When syzkaller team brought us a C repro for the crash [1] that
had been reported many times in the past, I finally could find
the root cause.
If FlowLabel info is merged by fl6_merge_options(), we leave
part of the opt_space storage provided by udp/raw/l2tp with random value
in opt_space.tot_len, unless a control message was provided at sendmsg()
time.
Then ip6_setup_cork() would use this random value to perform a kzalloc()
call. Undefined behavior and crashes.
Fix is to properly set tot_len in fl6_merge_options()
At the same time, we can also avoid consuming memory and cpu cycles
to clear it, if every option is copied via a kmemdup(). This is the
change in ip6_setup_cork().
[1]
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 6613 Comm: syz-executor0 Not tainted 4.14.0-rc4+ #127
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
task: ffff8801cb64a100 task.stack: ffff8801cc350000
RIP: 0010:ip6_setup_cork+0x274/0x15c0 net/ipv6/ip6_output.c:1168
RSP: 0018:ffff8801cc357550 EFLAGS: 00010203
RAX: dffffc0000000000 RBX: ffff8801cc357748 RCX: 0000000000000010
RDX: 0000000000000002 RSI: ffffffff842bd1d9 RDI: 0000000000000014
RBP: ffff8801cc357620 R08: ffff8801cb17f380 R09: ffff8801cc357b10
R10: ffff8801cb64a100 R11: 0000000000000000 R12: ffff8801cc357ab0
R13: ffff8801cc357b10 R14: 0000000000000000 R15: ffff8801c3bbf0c0
FS: 00007f9c5c459700(0000) GS:ffff8801db200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020324000 CR3: 00000001d1cf2000 CR4: 00000000001406f0
DR0: 0000000020001010 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
Call Trace:
ip6_make_skb+0x282/0x530 net/ipv6/ip6_output.c:1729
udpv6_sendmsg+0x2769/0x3380 net/ipv6/udp.c:1340
inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:762
sock_sendmsg_nosec net/socket.c:633 [inline]
sock_sendmsg+0xca/0x110 net/socket.c:643
SYSC_sendto+0x358/0x5a0 net/socket.c:1750
SyS_sendto+0x40/0x50 net/socket.c:1718
entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x4520a9
RSP: 002b:00007f9c5c458c08 EFLAGS: 00000216 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000000000718000 RCX: 00000000004520a9
RDX: 0000000000000001 RSI: 0000000020fd1000 RDI: 0000000000000016
RBP: 0000000000000086 R08: 0000000020e0afe4 R09: 000000000000001c
R10: 0000000000000000 R11: 0000000000000216 R12: 00000000004bb1ee
R13: 00000000ffffffff R14: 0000000000000016 R15: 0000000000000029
Code: e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 ea 0f 00 00 48 8d 79 04 48 b8 00 00 00 00 00 fc ff df 45 8b 74 24 04 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85
RIP: ip6_setup_cork+0x274/0x15c0 net/ipv6/ip6_output.c:1168 RSP: ffff8801cc357550
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
---
This is a stable candidate for all stable linux versions.
net/ipv6/ip6_flowlabel.c | 1 +
net/ipv6/ip6_output.c | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
index 8081bafe441b83f60f414114bfdc3529d6ea0a09..15535ee327c5780e80feb050c2ab4e0d1cc3e99c 100644
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -315,6 +315,7 @@ struct ipv6_txoptions *fl6_merge_options(struct ipv6_txoptions *opt_space,
}
opt_space->dst1opt = fopt->dst1opt;
opt_space->opt_flen = fopt->opt_flen;
+ opt_space->tot_len = fopt->tot_len;
return opt_space;
}
EXPORT_SYMBOL_GPL(fl6_merge_options);
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 43ca864327c73015f1724879d7ee8268a0de513b..5110a418cc4d0c1040506394460cb482698d8c15 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1161,11 +1161,11 @@ static int ip6_setup_cork(struct sock *sk, struct inet_cork_full *cork,
if (WARN_ON(v6_cork->opt))
return -EINVAL;
- v6_cork->opt = kzalloc(opt->tot_len, sk->sk_allocation);
+ v6_cork->opt = kzalloc(sizeof(*opt), sk->sk_allocation);
if (unlikely(!v6_cork->opt))
return -ENOBUFS;
- v6_cork->opt->tot_len = opt->tot_len;
+ v6_cork->opt->tot_len = sizeof(*opt);
v6_cork->opt->opt_flen = opt->opt_flen;
v6_cork->opt->opt_nflen = opt->opt_nflen;
^ permalink raw reply related
* Re: [PATCH net 3/3] bpf: add test cases to bpf selftests to cover all access tests
From: John Fastabend @ 2017-10-21 16:40 UTC (permalink / raw)
To: Daniel Borkmann, davem; +Cc: alexei.starovoitov, john.r.fastabend, netdev
In-Reply-To: <3bc01f5985324b0e233e86616f4fe171c0d4ca8b.1508545543.git.daniel@iogearbox.net>
On 10/20/2017 05:34 PM, Daniel Borkmann wrote:
> Lets add test cases to cover really all possible direct packet
> access tests for good/bad access cases so we keep tracking them.
>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
> ---
Acked-by: John Fastabend <john.fastabend@gmail.com>
^ permalink raw reply
* Re: [PATCH net 2/3] bpf: fix pattern matches for direct packet access
From: John Fastabend @ 2017-10-21 16:39 UTC (permalink / raw)
To: Daniel Borkmann, davem; +Cc: alexei.starovoitov, john.r.fastabend, netdev
In-Reply-To: <40e994d92bf40661a94e52de299d12fe5538f9c7.1508545543.git.daniel@iogearbox.net>
On 10/20/2017 05:34 PM, Daniel Borkmann wrote:
> Alexander had a test program with direct packet access, where
> the access test was in the form of data + X > data_end. In an
> unrelated change to the program LLVM decided to swap the branches
> and emitted code for the test in form of data + X <= data_end.
> We hadn't seen these being generated previously, thus verifier
> would reject the program. Therefore, fix up the verifier to
> detect all test cases, so we don't run into such issues in the
> future.
>
> Fixes: b4e432f1000a ("bpf: enable BPF_J{LT, LE, SLT, SLE} opcodes in verifier")
> Reported-by: Alexander Alemayhu <alexander@alemayhu.com>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
> ---
Acked-by: John Fastabend <john.fastabend@gmail.com>
^ permalink raw reply
* Re: [PATCH net 1/3] bpf: fix off by one for range markings with L{T,E} patterns
From: John Fastabend @ 2017-10-21 16:39 UTC (permalink / raw)
To: Daniel Borkmann, davem; +Cc: alexei.starovoitov, john.r.fastabend, netdev
In-Reply-To: <3df9cce096b139eb0efb3b0c7bf9fcc5c5dc6629.1508545543.git.daniel@iogearbox.net>
On 10/20/2017 05:34 PM, Daniel Borkmann wrote:
> During review I noticed that the current logic for direct packet
> access marking in check_cond_jmp_op() has an off by one for the
> upper right range border when marking in find_good_pkt_pointers()
> with BPF_JLT and BPF_JLE. It's not really harmful given access
> up to pkt_end is always safe, but we should nevertheless correct
> the range marking before it becomes ABI. If pkt_data' denotes a
> pkt_data derived pointer (pkt_data + X), then for pkt_data' < pkt_end
> in the true branch as well as for pkt_end <= pkt_data' in the false
> branch we mark the range with X although it should really be X - 1
> in these cases. For example, X could be pkt_end - pkt_data, then
> when testing for pkt_data' < pkt_end the verifier simulation cannot
> deduce that a byte load of pkt_data' - 1 would succeed in this
> branch.
>
> Fixes: b4e432f1000a ("bpf: enable BPF_J{LT, LE, SLT, SLE} opcodes in verifier")
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
> ---
Acked-by: John Fastabend <john.fastabend@gmail.com>
^ permalink raw reply
* Re: [PATCH net 0/3] Fix for BPF devmap percpu allocation splat
From: Tejun Heo @ 2017-10-21 16:00 UTC (permalink / raw)
To: Dennis Zhou
Cc: Daniel Borkmann, davem, ast, john.fastabend, mark.rutland,
richard, sp3485, netdev, linux-kernel
In-Reply-To: <20171018214508.GA12295@localhost.corp.microsoft.com>
Hello,
On Wed, Oct 18, 2017 at 04:45:08PM -0500, Dennis Zhou wrote:
> I'm not sure I see the reason we can't match the minimum allocation size
> with the unit size? It seems weird to arbitrate the maximum allocation
> size given a lower bound on the unit size.
idk, it can be weird for the maximum allowed allocation size varying
widely depending on how the machine boots up.
Thanks.
--
tejun
^ permalink raw reply
* RE: [PATCH net-next v2 1/6] devlink: Add permanent config parameter get/set operations
From: Yuval Mintz @ 2017-10-21 14:12 UTC (permalink / raw)
To: Steve Lin
Cc: netdev@vger.kernel.org, Jiri Pirko, davem@davemloft.net,
michael.chan@broadcom.com, linville@tuxdriver.com,
gospo@broadcom.com
In-Reply-To: <CA+Jmh7Gdud=T47iK=ZjgoXvXj+frBgP=HcvGDWHzJxUzN9L=tA@mail.gmail.com>
> On Thu, Oct 19, 2017 at 4:21 PM, Yuval Mintz <yuvalm@mellanox.com>
> wrote:
> >> Subject: [PATCH net-next v2 1/6] devlink: Add permanent config
> parameter
> >> get/set operations
> >>
> >> Add support for permanent config parameter get/set commands. Used
> >> for parameters held in NVRAM, persistent device configuration.
> >
> > Given some of the attributes aren't Boolean, what about an API that
> > allows the user to learn of supported values per option?
> > Otherwise only way for configuring some of them would be trial & error.
>
> Interesting suggestion. There's a couple of places where this could
> be a factor. (1) When a user wants to know what values are
> defined/available in the API, and (2) When the user wants to know what
> values are supported by a specific driver/device.
>
> The intention for (1) is to push that into userspace. The userspace
> devlink tool patches I am working on (not yet submitted) essentially
> mirror the config parameters and their options, with string "keywords"
> associated with each parameter and option, since it's the userspace
> app that will be parsing the command line strings and converting to
> API enums. So the userspace app can provide the list of
> parameters/options it supports, which could be a subset of what's
> available in the API.
>
> For (2), currently there is no mechanism other than trial/error as you
> suggest (up to driver to either return an error or else make use of
> the value specified by the user). We could contemplate adding such a
> mechanism, but it's a little complicated as some options take a range
> (i.e. # of VFs per PF for example), and others may take one of a set
> of enumerated values (pre-boot link speed for example).
>
> To clarify, are you suggesting some mechanism to allow a driver to
> report which parameters and options it supports (case (2))? Or are
> you suggesting something in the kernel API to handle case (1) above?
I was thinking of (2). And I agree it would take some effort.
>
> >
> >>
> >> Signed-off-by: Steve Lin <steven.lin1@broadcom.com>
> >> Acked-by: Andy Gospodarek <gospo@broadcom.com>
> >> ---
> >> include/net/devlink.h | 3 +
> >> include/uapi/linux/devlink.h | 11 ++
> >> net/core/devlink.c | 234
> >> +++++++++++++++++++++++++++++++++++++++++++
> >> 3 files changed, 248 insertions(+)
> >>
> >> diff --git a/include/net/devlink.h b/include/net/devlink.h
> >> index b9654e1..bd64623 100644
> >> --- a/include/net/devlink.h
> >> +++ b/include/net/devlink.h
> >> @@ -270,6 +270,9 @@ struct devlink_ops {
> >> int (*eswitch_inline_mode_set)(struct devlink *devlink, u8
> >> inline_mode);
> >> int (*eswitch_encap_mode_get)(struct devlink *devlink, u8
> >> *p_encap_mode);
> >> int (*eswitch_encap_mode_set)(struct devlink *devlink, u8
> >> encap_mode);
> >> + int (*perm_config_get)(struct devlink *devlink, u32 param, u32
> >> *value);
> >> + int (*perm_config_set)(struct devlink *devlink, u32 param, u32
> >> value,
> >> + u8 *restart_reqd);
> >> };
> >>
> >> static inline void *devlink_priv(struct devlink *devlink)
> >> diff --git a/include/uapi/linux/devlink.h b/include/uapi/linux/devlink.h
> >> index 0cbca96..47cc584 100644
> >> --- a/include/uapi/linux/devlink.h
> >> +++ b/include/uapi/linux/devlink.h
> >> @@ -70,6 +70,10 @@ enum devlink_command {
> >> DEVLINK_CMD_DPIPE_HEADERS_GET,
> >> DEVLINK_CMD_DPIPE_TABLE_COUNTERS_SET,
> >>
> >> + /* Permanent (NVRAM) device config get/set */
> >> + DEVLINK_CMD_PERM_CONFIG_GET,
> >> + DEVLINK_CMD_PERM_CONFIG_SET,
> >> +
> >> /* add new commands above here */
> >> __DEVLINK_CMD_MAX,
> >> DEVLINK_CMD_MAX = __DEVLINK_CMD_MAX - 1
> >> @@ -202,6 +206,13 @@ enum devlink_attr {
> >>
> >> DEVLINK_ATTR_ESWITCH_ENCAP_MODE, /* u8 */
> >>
> >> + /* Permanent Configuration Parameters */
> >> + DEVLINK_ATTR_PERM_CONFIGS, /* nested */
> >> + DEVLINK_ATTR_PERM_CONFIG, /* nested */
> >> + DEVLINK_ATTR_PERM_CONFIG_PARAMETER, /* u32 */
> >> + DEVLINK_ATTR_PERM_CONFIG_VALUE, /*
> >> u32 */
> >> + DEVLINK_ATTR_PERM_CONFIG_RESTART_REQUIRED, /* u8 */
> >> +
> >> /* add new attributes above here, update the policy in devlink.c */
> >>
> >> __DEVLINK_ATTR_MAX,
> >> diff --git a/net/core/devlink.c b/net/core/devlink.c
> >> index 7d430c1..c2cc7c6 100644
> >> --- a/net/core/devlink.c
> >> +++ b/net/core/devlink.c
> >> @@ -1566,6 +1566,224 @@ static int
> >> devlink_nl_cmd_eswitch_set_doit(struct sk_buff *skb,
> >> return 0;
> >> }
> >>
> >> +static const struct nla_policy devlink_nl_policy[DEVLINK_ATTR_MAX +
> 1];
> >> +
> >> +static int devlink_nl_single_param_get(struct sk_buff *msg,
> >> + struct devlink *devlink,
> >> + uint32_t param)
> >> +{
> >> + u32 value;
> >> + int err;
> >> + const struct devlink_ops *ops = devlink->ops;
> >> + struct nlattr *param_attr;
> >> +
> >> + err = ops->perm_config_get(devlink, param, &value);
> >> + if (err)
> >> + return err;
> >> +
> >> + param_attr = nla_nest_start(msg, DEVLINK_ATTR_PERM_CONFIG);
> >> + nla_put_u32(msg, DEVLINK_ATTR_PERM_CONFIG_PARAMETER,
> >> param);
> >> + nla_put_u32(msg, DEVLINK_ATTR_PERM_CONFIG_VALUE, value);
> >> + nla_nest_end(msg, param_attr);
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static int devlink_nl_config_get_fill(struct sk_buff *msg,
> >> + struct devlink *devlink,
> >> + enum devlink_command cmd,
> >> + struct genl_info *info)
> >> +{
> >> + void *hdr;
> >> + int err;
> >> + struct nlattr *attr;
> >> + int param_count = 0;
> >> + struct nlattr *cfgparam_attr;
> >> + int rem;
> >> + struct nlattr *tb[DEVLINK_ATTR_MAX + 1];
> >> + u32 param;
> >> +
> >> + hdr = genlmsg_put(msg, info->snd_portid, info->snd_seq,
> >> + &devlink_nl_family, 0, cmd);
> >> + if (!hdr) {
> >> + err = -EMSGSIZE;
> >> + goto nla_msg_failure;
> >> + }
> >> +
> >> + err = devlink_nl_put_handle(msg, devlink);
> >> + if (err)
> >> + goto nla_put_failure;
> >> +
> >> + if (!info->attrs[DEVLINK_ATTR_PERM_CONFIGS]) {
> >> + /* No configuration parameters */
> >> + goto nla_put_failure;
> >> + }
> >> +
> >> + cfgparam_attr = nla_nest_start(msg,
> >> DEVLINK_ATTR_PERM_CONFIGS);
> >> +
> >> + nla_for_each_nested(attr, info-
> >> >attrs[DEVLINK_ATTR_PERM_CONFIGS],
> >> + rem) {
> > Isn't it possible that a response for a single request for multiple ATTRs
> > wouldn't fit in a single message?
> >
>
> Hmm... Given the small size and relatively small total number of these
> attributes, even when additional drivers add their own, I think it's
We probably have a different idea about 'small'.
Didn’t your *initial* series attempt to add 35 attributes at once?
> unlikely that a single request would require a multipart message, even
> in the event it's requesting all of the parameters for a given device.
> I guess we could support NLM_F_MULTI type messages, but it didn't seem
> necessary to me for this application? Thoughts?
>
> >> + if (err)
> >> + goto nla_nest_failure;
> >> + param_count++;
> >
> > Looks like an unused parameter
> >> +
> >> + if (restart_reqd) {
> >
> > Doesn't seem like you're ever setting it.
> > A leftover from when this was an attribute of the configs instead
> > of per-config perhaps?
>
> Thanks for catching these two issues - you're right, they are leftover
> from the v1 implementation; apologies for not catching them in v2.
> Will fix in v3.
^ permalink raw reply
* RE: [PATCH net-next v2 5/6] devlink: Adding num MSI-X vectors per VF NVRAM config param
From: Yuval Mintz @ 2017-10-21 13:59 UTC (permalink / raw)
To: Steve Lin, Jiri Pirko
Cc: netdev@vger.kernel.org, Jiri Pirko, davem@davemloft.net,
michael.chan@broadcom.com, linville@tuxdriver.com,
gospo@broadcom.com
In-Reply-To: <CA+Jmh7FT789PfH908KK+x1+ehrvbiaaovori1w9yWe7+CFhFTg@mail.gmail.com>
> On Fri, Oct 20, 2017 at 10:10 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> > Fri, Oct 20, 2017 at 04:03:55PM CEST, steven.lin1@broadcom.com wrote:
> >>On Thu, Oct 19, 2017 at 5:39 PM, Jiri Pirko <jiri@resnulli.us> wrote:
> >>> Thu, Oct 19, 2017 at 10:32:21PM CEST, yuvalm@mellanox.com wrote:
> >>>>> Adding DEVLINK_PERM_CONFIG_MSIX_VECTORS_PER_VF
> permanent
> >>>>> config
> >>>>> parameter. Defines number of MSI-X vectors allocated per VF.
> >>>>> Value is permanent (stored in NVRAM), so becomes the new default
> >>>>> value for this device.
> >>>>
> >>>>Sounds like you're having this enforce the same configuration for all
> child VFs.
> >>>
> >>> Yeah, this sounds like per-port config.
> >>>
> >>
> >>Well, it gets a little tricky here. I assume some cards handle this
> >>per-port. Other cards might handle this per PF, where PF may not
> >>always correspond 1:1 with a port. And some cards maybe just allow a
> >>single value for this parameter for the entire card, covering all
> >>ports/PFs.
> >>
> >>To keep things simple and as general as possible, it made sense to set
> >>all parameters on a per-PCI device level. As I mentioned in my
> >>cover-letter, the devices most likely to use these proposed commands
> >>do not have a single "whole asic" PCI b/d/f with internal mechanism
> >>for accessing ports - most expose each port (and each function on each
> >>port) as a separate PCI b/d/f, with no separate "whole asic" PCI
> >>b/d/f. That's how the BCM cards work, and I think that's how the MLNX
> >>cards work, and others that would be likely to use these cmds.
> >>
> >>So, to summarize, you direct the command to the PCI b/d/f you want to
> >>target. Does this make sense?
> >
> > So you plan to have 1 devlink instance for each vf? Not sure that
> > does sound right to me :/
> >
>
> For the commands proposed in this patchset, AFAIK they all apply on a
> per-PF or broader, i.e. per-port or whole-card, granularity, since
> they affect permanent config that applies at boot-up. So, no, the VFs
> don't really come into play here.
Regardless of whether you're planning on having VFs as devlink instances,
the actual attribute question remains -
you're proposing an attribute that forces all VFs to have the same value.
This probably suits your PCI core limitations but other vendors might have
a different capability set, and accepting this design limitation now would
muck all future extension attempts of such attributes.
I think VF configurations should be planned in advance for supporting a
per-VF Configuration whenever it's possible - even if not required [/possible]
by the one pushing the new attribute.
^ permalink raw reply
* Re: [PATCH net 0/7] net: aquantia: Atlantic driver 10/2017 updates
From: David Miller @ 2017-10-21 11:32 UTC (permalink / raw)
To: igor.russkikh
Cc: netdev, darcari, pavel.belous, Nadezhda.Krupnina, simon.edelhaus
In-Reply-To: <cover.1508159232.git.igor.russkikh@aquantia.com>
From: Igor Russkikh <igor.russkikh@aquantia.com>
Date: Thu, 19 Oct 2017 18:23:52 +0300
> This patchset fixes various issues in driver,
> improves parameters for better performance on 10Gbit link
Series applied.
^ permalink raw reply
* Re: [PATCH net-next] bnxt: Move generic devlink code to new file
From: David Miller @ 2017-10-21 11:28 UTC (permalink / raw)
To: steven.lin1; +Cc: netdev, michael.chan, gospo
In-Reply-To: <1508424356-24619-1-git-send-email-steven.lin1@broadcom.com>
From: Steve Lin <steven.lin1@broadcom.com>
Date: Thu, 19 Oct 2017 10:45:56 -0400
> Moving generic devlink code (registration) out of VF-R code
> into new bnxt_devlink file, in preparation for future work
> to add additional devlink functionality to bnxt.
>
> Signed-off-by: Steve Lin <steven.lin1@broadcom.com>
> Acked-by: Andy Gospodarek <gospo@broadcom.com>
Applied.
^ permalink raw reply
* Re: [net-next 1/1] tipc: fix broken tipc_poll() function
From: David Miller @ 2017-10-21 11:27 UTC (permalink / raw)
To: jon.maloy; +Cc: netdev, parthasarathy.bhuvaragan, ying.xue, tipc-discussion
In-Reply-To: <1508424124-1748-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Thu, 19 Oct 2017 16:42:04 +0200
> In commit ae236fb208a6 ("tipc: receive group membership events via
> member socket") we broke the tipc_poll() function by checking the
> state of the receive queue before the call to poll_sock_wait(), while
> relying that state afterwards, when it might have changed.
>
> We restore this in this commit.
>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 0/2] net: diag: fix a potential security issue
From: David Miller @ 2017-10-21 11:16 UTC (permalink / raw)
To: lucien.xin; +Cc: eric.dumazet, edumazet, netdev, marcelo.leitner, sd
In-Reply-To: <CADvbK_cLxOGpBwdSX+CkE+HLefT4rjz8tbgrkosGg7f+wmQVTA@mail.gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Sat, 21 Oct 2017 17:45:09 +0800
> Let's just see if David could accept the patches if I will
> remove the "security claim" from changelog, considering
> it as an improvement of sock diag.
>
> David ?
No I won't. See my other response.
Use modules.conf or netfilter rules to block "scary networking
protocols" if you are so paranoid about this happening.
Thank you.
^ 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