* Re: [PATCH v4 net-next 01/13] bpf/verifier: rework value tracking
From: Daniel Borkmann @ 2017-08-06 23:35 UTC (permalink / raw)
To: Edward Cree, davem, Alexei Starovoitov, Alexei Starovoitov
Cc: netdev, linux-kernel, iovisor-dev
In-Reply-To: <8a5e37eb-2397-c986-79c5-02908fbbdee0@solarflare.com>
On 08/03/2017 06:11 PM, Edward Cree wrote:
> Unifies adjusted and unadjusted register value types (e.g. FRAME_POINTER is
> now just a PTR_TO_STACK with zero offset).
> Tracks value alignment by means of tracking known & unknown bits. This
> also replaces the 'reg->imm' (leading zero bits) calculations for (what
> were) UNKNOWN_VALUEs.
> If pointer leaks are allowed, and adjust_ptr_min_max_vals returns -EACCES,
> treat the pointer as an unknown scalar and try again, because we might be
> able to conclude something about the result (e.g. pointer & 0x40 is either
> 0 or 0x40).
>
> Signed-off-by: Edward Cree <ecree@solarflare.com>
[...]
> +static int adjust_scalar_min_max_vals(struct bpf_verifier_env *env,
> + struct bpf_insn *insn,
> + struct bpf_reg_state *dst_reg,
> + struct bpf_reg_state *src_reg)
> {
> struct bpf_reg_state *regs = env->cur_state.regs;
[...]
> - } else if (insn->imm < BPF_REGISTER_MAX_RANGE &&
> - (s64)insn->imm > BPF_REGISTER_MIN_RANGE) {
> - min_val = max_val = insn->imm;
> - src_align = calc_align(insn->imm);
> + if (BPF_CLASS(insn->code) != BPF_ALU64) {
> + /* 32-bit ALU ops are (32,32)->64 */
> + coerce_reg_to_32(dst_reg);
> + coerce_reg_to_32(src_reg);
> }
> -
[...]
> - dst_reg->max_value = BPF_REGISTER_MAX_RANGE;
> + if (BPF_CLASS(insn->code) != BPF_ALU64) {
> + /* 32-bit ALU ops are (32,32)->64 */
> + coerce_reg_to_32(dst_reg);
> + coerce_reg_to_32(src_reg);
> }
Looks like the same check was added twice here right after
the first one? Shouldn't we just temporarily coerce the src
reg to 32 bit here given in the actual op the src reg is not
being modified?
Thanks,
Daniel
> + min_val = src_reg->min_value;
> + max_val = src_reg->max_value;
> + src_known = tnum_is_const(src_reg->var_off);
> + dst_known = tnum_is_const(dst_reg->var_off);
>
> switch (opcode) {
^ permalink raw reply
* Re: [PATCH net] sctp: use __GFP_NOWARN for sctpw.fifo allocation
From: Marcelo Ricardo Leitner @ 2017-08-06 23:39 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, davem, Neil Horman
In-Reply-To: <CADvbK_f_q-gJHey9oUZUrxyGSYXasMVj0kqvhEkzDUPsGDzeng@mail.gmail.com>
On Sun, Aug 06, 2017 at 06:14:39PM +1200, Xin Long wrote:
> On Sun, Aug 6, 2017 at 5:08 AM, Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
> > On Sat, Aug 05, 2017 at 08:31:09PM +0800, Xin Long wrote:
> >> Chen Wei found a kernel call trace when modprobe sctp_probe with
> >> bufsize set with a huge value.
> >>
> >> It's because in sctpprobe_init when alloc memory for sctpw.fifo,
> >> the size is got from userspace. If it is too large, kernel will
> >> fail and give a warning.
> >
> > Yes but sctp_probe can only be loaded by an admin and it would happen
> > only during modprobe. It's different from the commit mentioned below, on
> > which any user could trigger it.
> yeah, in this way it's different, I think generally it's acceptable to have
> this kinda warning call trace by admin.
>
> But it could get the feedback from the return value and the warning
> call trace seems not useful. sometimes users may be confused
users or admins?
> with this call trace. So it may be better not to dump the warning ?
>
> Or you think it can be helpful if we leave it here ?
I'm afraid we may be exagerating here. There are several other ways that
an admin can trigger scary warnings, this one is no special. I'd rather
leave this one to the mm defaults instead.
>
> >
> >>
> >> As there will be a fallback allocation later, this patch is just
> >> to fail silently and return ret, just as commit 0ccc22f425e5
> >> ("sit: use __GFP_NOWARN for user controlled allocation") did.
> >>
> >> Reported-by: Chen Wei <weichen@redhat.com>
> >> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> >> ---
> >> net/sctp/probe.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/net/sctp/probe.c b/net/sctp/probe.c
> >> index 6cc2152..5bf3164 100644
> >> --- a/net/sctp/probe.c
> >> +++ b/net/sctp/probe.c
> >> @@ -210,7 +210,7 @@ static __init int sctpprobe_init(void)
> >>
> >> init_waitqueue_head(&sctpw.wait);
> >> spin_lock_init(&sctpw.lock);
> >> - if (kfifo_alloc(&sctpw.fifo, bufsize, GFP_KERNEL))
> >> + if (kfifo_alloc(&sctpw.fifo, bufsize, GFP_KERNEL | __GFP_NOWARN))
> >> return ret;
> >>
> >> if (!proc_create(procname, S_IRUSR, init_net.proc_net,
> >> --
> >> 2.1.0
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] net: Reduce skb_warn_bad_offload() noise.
From: Tonghao Zhang @ 2017-08-07 0:37 UTC (permalink / raw)
To: Eric Dumazet
Cc: Linux Kernel Network Developers, Eric Dumazet, Willem de Bruijn,
Pravin B Shelar
In-Reply-To: <1501853380.25002.38.camel@edumazet-glaptop3.roam.corp.google.com>
On Fri, Aug 4, 2017 at 9:29 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Fri, 2017-08-04 at 06:11 -0700, Tonghao Zhang wrote:
>> This patch will revert the b2504a5dbe "net: reduce
>> skb_warn_bad_offload() noise". The ovs will call the
>> __skb_gso_segment() with tx false. When segmenting UDP with UFO,
>> the __skb_gso_segment raises a warning as below [1], because the
>> ip_summed is CHECKSUM_NONE. While the net-next has removed the
>> UFO support, but the 4.11 and 4.12 kernel don't address that problem.
>>
>> In the kernel, only qdisc_pkt_len_init() (__dev_queue_xmit call it.)
>> uses the SKB_GSO_DODGY to do something. Other places just set it.
>> The warn described in b2504a5dbe is shown [2]. We may know that:
>> 1. the net_device don’t have qdisc.
>> 2. the skb->ip_summed was changed to CHECKSUM_NONE. it maybe
>> changed in skb_checksum_help() when calling validate_xmit_skb().
>> or other place.
>>
>> And we should not revert the 6e7bc478c9 "net: skb_needs_check() accepts
>> CHECKSUM_NONE for tx". The check is necessary.
>
> Why is it necessary ?
I am not familiar with __skb_gso_segment() when tx_path == true. I
should say sorry to you.
>
> If you revert b2504a5dbe, then we also need to revert 6e7bc478c9,
> unless you provide hard facts.
>
The openvswitch kernel module calls the __skb_gso_segment()(and sets
tx_path = false) when passing packets to userspace. The UFO will set
the ip_summed to CHECKSUM_NONE. There are a lot of warn logs. The warn
log is shown as below. I guess we should revert the patch.
>>
>> [1]
>> [321428.168903] WARNING: CPU: 0 PID: 2279 at net/core/dev.c:2562
>> skb_warn_bad_offload+0xc4/0x110
>> [321428.168906] san0: caps=(0x000004009fbb58e9, 0x0000000000000000) len=6769
>> data_len=6727 gso_size=1480 gso_type=2 ip_summed=0
>>
>> [321428.168955] CPU: 0 PID: 2279 Comm: ruby-mri 4.11.12-200.fc25.x86_64 #1
>> [321428.168956] Hardware name: Supermicro SYS-1028U-TNRTP+/X10DRU-i+, BIOS 1.1 07/22/2015
>> [321428.168957] Call Trace:
>> [321428.168962] dump_stack+0x63/0x86
>> [321428.168965] __warn+0xcb/0xf0
>> [321428.168966] warn_slowpath_fmt+0x5a/0x80
>> [321428.168968] skb_warn_bad_offload+0xc4/0x110
>> [321428.168970] __skb_gso_segment+0x190/0x1a0
>> [321428.168977] queue_gso_packets+0x62/0x160 [openvswitch]
>> [321428.168992] ovs_dp_upcall+0x31/0x60 [openvswitch]
>> [321428.168994] ovs_dp_process_packet+0x10d/0x130 [openvswitch]
>> [321428.168997] ovs_vport_receive+0x76/0xd0 [openvswitch]
>> [321428.169013] internal_dev_xmit+0x28/0x60 [openvswitch]
>> [321428.169014] dev_hard_start_xmit+0xa3/0x1f0
>> [321428.169016] __dev_queue_xmit+0x592/0x650
>> [321428.169026] dev_queue_xmit+0x10/0x20
>>
>> [2]
>> WARNING: CPU: 1 PID: 6768 at net/core/dev.c:2439 skb_warn_bad_offload+0x2af/0x390 net/core/dev.c:2434
>> lo: caps=(0x000000a2803b7c69, 0x0000000000000000) len=138 data_len=0 gso_size=15883 gso_type=4 ip_summed=0
>> Kernel panic - not syncing: panic_on_warn set ...
>>
>> CPU: 1 PID: 6768 Comm: syz-executor1 Not tainted 4.9.0 #5
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
>> ffff8801c063ecd8 ffffffff82346bdf ffffffff00000001 1ffff100380c7d2e
>> ffffed00380c7d26 0000000041b58ab3 ffffffff84b37e38 ffffffff823468f1
>> ffffffff84820740 ffffffff84f289c0 dffffc0000000000 ffff8801c063ee20
>> Call Trace:
>
> Why are you adding this trace that was part of the b2504a5dbef3
> changelog ?
I hope we can fix the bug with other solution.
>
>> [<ffffffff82346bdf>] __dump_stack lib/dump_stack.c:15 [inline]
>> [<ffffffff82346bdf>] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
>> [<ffffffff81827e34>] panic+0x1fb/0x412 kernel/panic.c:179
>> [<ffffffff8141f704>] __warn+0x1c4/0x1e0 kernel/panic.c:542
>> [<ffffffff8141f7e5>] warn_slowpath_fmt+0xc5/0x100 kernel/panic.c:565
>> [<ffffffff8356cbaf>] skb_warn_bad_offload+0x2af/0x390 net/core/dev.c:2434
>> [<ffffffff83585cd2>] __skb_gso_segment+0x482/0x780 net/core/dev.c:2706
>> [<ffffffff83586f19>] skb_gso_segment include/linux/netdevice.h:3985 [inline]
>> [<ffffffff83586f19>] validate_xmit_skb+0x5c9/0xc20 net/core/dev.c:2969
>> [<ffffffff835892bb>] __dev_queue_xmit+0xe6b/0x1e70 net/core/dev.c:3383
>> [<ffffffff8358a2d7>] dev_queue_xmit+0x17/0x20 net/core/dev.c:3424
>>
>> Cc: Eric Dumazet <edumazet@google.com>
>> Cc: Willem de Bruijn <willemb@google.com>
>> Cc: Pravin B Shelar <pshelar@ovn.org>
>> Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>> ---
>
>
> IMO, this description is too confusing, I do not understand this patch.
sorry
^ permalink raw reply
* Re:Re: [PATCH net] ppp: Fix a scheduling-while-atomic bug in del_chan
From: Gao Feng @ 2017-08-07 1:32 UTC (permalink / raw)
To: Cong Wang; +Cc: xeb, David Miller, Linux Kernel Network Developers
In-Reply-To: <CAM_iQpVta2EFVjutndCmoLBPWko7dgzP=Q1i2krPqyYuNBV4RA@mail.gmail.com>
At 2017-08-03 01:13:36, "Cong Wang" <xiyou.wangcong@gmail.com> wrote:
>Hi, Gao
>
>On Tue, Aug 1, 2017 at 1:39 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> From my understanding, this RCU is supposed to protect the pppox_sock
>> pointers in 'callid_sock' which could be NULL'ed in del_chan(). And the
>> pppox_sock is freed when the last refcnt is gone, that is, when sock
>> dctor is called. pptp_release() is ONLY called when the fd in user-space
>> is gone, not necessarily the last refcnt.
Hi Cong,
I am sorry to reply you so late, because I took a short trip recently, and didn't check my emails.
I think the RCU should be supposed to avoid the race between del_chan and lookup_chan.
The synchronize_rcu could make sure if there was one which calls lookup_chan in this period, it would be finished and the sock refcnt is increased if necessary.
So I think it is ok to invoke sock_put directly without SOCK_RCU_FREE, because the lookup_chan caller has already hold the sock refcnt,
Best Regards
Feng
>
>Your commit is probably not the right fix. Can you try the following fix?
>
>diff --git a/drivers/net/ppp/pptp.c b/drivers/net/ppp/pptp.c
>index 6dde9a0cfe76..e75bb95c107f 100644
>--- a/drivers/net/ppp/pptp.c
>+++ b/drivers/net/ppp/pptp.c
>@@ -519,7 +519,6 @@ static int pptp_release(struct socket *sock)
>
> po = pppox_sk(sk);
> del_chan(po);
>- synchronize_rcu();
>
> pppox_unbind_sock(sk);
> sk->sk_state = PPPOX_DEAD;
>@@ -564,6 +563,7 @@ static int pptp_create(struct net *net, struct
>socket *sock, int kern)
> sk->sk_family = PF_PPPOX;
> sk->sk_protocol = PX_PROTO_PPTP;
> sk->sk_destruct = pptp_sock_destruct;
>+ sock_set_flag(sk, SOCK_RCU_FREE);
>
> po = pppox_sk(sk);
> opt = &po->proto.pptp;
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2017-08-07 2:01 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Neal Cardwell,
Yuchung Cheng
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/ipv4/tcp_output.c
between commit:
a2815817ffa6 ("tcp: enable xmit timer fix by having TLP use time when RTO should fire")
from the net tree and commit:
bb4d991a28cc ("tcp: adjust tail loss probe timeout")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc net/ipv4/tcp_output.c
index 276406a83a37,d49bff51bdb7..000000000000
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@@ -2377,9 -2375,13 +2375,8 @@@ bool tcp_schedule_loss_probe(struct soc
{
struct inet_connection_sock *icsk = inet_csk(sk);
struct tcp_sock *tp = tcp_sk(sk);
- u32 rtt = usecs_to_jiffies(tp->srtt_us >> 3);
- u32 timeout, tlp_time_stamp, rto_time_stamp;
+ u32 timeout, rto_delta_us;
- /* No consecutive loss probes. */
- if (WARN_ON(icsk->icsk_pending == ICSK_TIME_LOSS_PROBE)) {
- tcp_rearm_rto(sk);
- return false;
- }
/* Don't do any loss probe on a Fast Open connection before 3WHS
* finishes.
*/
@@@ -2402,16 -2408,24 +2399,20 @@@
* for delayed ack when there's one outstanding packet. If no RTT
* sample is available then probe after TCP_TIMEOUT_INIT.
*/
- timeout = rtt << 1 ? : TCP_TIMEOUT_INIT;
- if (tp->packets_out == 1)
- timeout = max_t(u32, timeout,
- (rtt + (rtt >> 1) + TCP_DELACK_MAX));
- timeout = max_t(u32, timeout, msecs_to_jiffies(10));
+ if (tp->srtt_us) {
+ timeout = usecs_to_jiffies(tp->srtt_us >> 2);
+ if (tp->packets_out == 1)
+ timeout += TCP_RTO_MIN;
+ else
+ timeout += TCP_TIMEOUT_MIN;
+ } else {
+ timeout = TCP_TIMEOUT_INIT;
+ }
- /* If RTO is shorter, just schedule TLP in its place. */
- tlp_time_stamp = tcp_jiffies32 + timeout;
- rto_time_stamp = (u32)inet_csk(sk)->icsk_timeout;
- if ((s32)(tlp_time_stamp - rto_time_stamp) > 0) {
- s32 delta = rto_time_stamp - tcp_jiffies32;
- if (delta > 0)
- timeout = delta;
- }
+ /* If the RTO formula yields an earlier time, then use that time. */
+ rto_delta_us = tcp_rto_delta_us(sk); /* How far in future is RTO? */
+ if (rto_delta_us > 0)
+ timeout = min_t(u32, timeout, usecs_to_jiffies(rto_delta_us));
inet_csk_reset_xmit_timer(sk, ICSK_TIME_LOSS_PROBE, timeout,
TCP_RTO_MAX);
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the net tree
From: Neal Cardwell @ 2017-08-07 2:21 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, Networking, Linux-Next Mailing List,
Linux Kernel Mailing List, Yuchung Cheng
In-Reply-To: <20170807120113.5e51eec0@canb.auug.org.au>
On Sun, Aug 6, 2017 at 10:01 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> net/ipv4/tcp_output.c
>
> between commit:
>
> a2815817ffa6 ("tcp: enable xmit timer fix by having TLP use time when RTO should fire")
>
> from the net tree and commit:
>
> bb4d991a28cc ("tcp: adjust tail loss probe timeout")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Sorry about that. Will try to follow that procedure in the future.
thanks,
neal
^ permalink raw reply
* Re: [PATCH v9 0/4] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
From: David Miller @ 2017-08-07 3:47 UTC (permalink / raw)
To: dingtianhong
Cc: leedom, ashok.raj, bhelgaas, helgaas, werner, ganeshgr,
asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw,
l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher,
catalin.marinas, will.deacon, mark.rutland, robin.murphy,
alexander.duyck, linux-arm-kernel, netdev, linux-pci,
linux-kernel, linuxarm
In-Reply-To: <1501917313-9812-1-git-send-email-dingtianhong@huawei.com>
From: Ding Tianhong <dingtianhong@huawei.com>
Date: Sat, 5 Aug 2017 15:15:09 +0800
> Some devices have problems with Transaction Layer Packets with the Relaxed
> Ordering Attribute set. This patch set adds a new PCIe Device Flag,
> PCI_DEV_FLAGS_NO_RELAXED_ORDERING, a set of PCI Quirks to catch some known
> devices with Relaxed Ordering issues, and a use of this new flag by the
> cxgb4 driver to avoid using Relaxed Ordering with problematic Root Complex
> Ports.
>
> It's been years since I've submitted kernel.org patches, I appolgise for the
> almost certain submission errors.
Which tree should merge this? The PCI tree or my networking tree?
^ permalink raw reply
* Re: [RFC PATCH] IP: do not modify ingress packet IP option in ip_options_echo()
From: David Miller @ 2017-08-07 3:49 UTC (permalink / raw)
To: hannes; +Cc: pabeni, netdev, edumazet, kuznet
In-Reply-To: <87a83othjl.fsf@stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Fri, 28 Jul 2017 16:47:42 -0400
> David Miller <davem@davemloft.net> writes:
>
>> The red flag is that we are indexing 'start' with 'doffset' instead of
>> 'soffset'.
>
> As Paolo pointed out, we should not put our own source address into the
> options array.
>
> Do you have any idea why this code was added in the first place? I read
> through 2.0.33 code and even in context of this version, I couldn't
> figure that out.
>
> Because it seems the code and update is dead anyways (besides
> incorrectly updating the ICMP reflected payload) I don't see any problem
> with removing this code. Do you?
Ok, now I'm convinced it's dead code.
Thanks for explaining.
^ permalink raw reply
* Re: [PATCH net-next 0/4] IP: cleanup LSRR option processing
From: David Miller @ 2017-08-07 3:51 UTC (permalink / raw)
To: pabeni; +Cc: netdev, edumazet, hannes
In-Reply-To: <cover.1501775813.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Thu, 3 Aug 2017 18:07:04 +0200
> The __ip_options_echo() function expect a valid dst entry in skb->dst;
> as result we sometimes need to preserve the dst entry for the whole IP
> RX path.
>
> The current usage of skb->dst looks more a relic from ancient past that
> a real functional constraint. This patchset tries to remove such usage,
> and than drops some hacks currently in place in the IP code to keep
> skb->dst around.
>
> __ip_options_echo() uses of skb->dst for two different purposes: retrieving
> the netns assicated with the skb, and modify the ingress packet LSRR address
> list.
>
> The first patch removes the code modifying the ingress packet, and the second
> one provides an explicit netns argument to __ip_options_echo(). The following
> patches cleanup the current code keeping arund skb->dst for __ip_options_echo's
> sake.
>
> Updating the __ip_options_echo() function has been previously discussed here:
>
> http://marc.info/?l=linux-netdev&m=150064533516348&w=2
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH RFC 00/13] phylink and sfp support
From: David Miller @ 2017-08-07 4:00 UTC (permalink / raw)
To: andrew; +Cc: linux, f.fainelli, netdev
In-Reply-To: <20170806182622.GA31844@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Sun, 6 Aug 2017 20:26:22 +0200
> On Tue, Jul 25, 2017 at 03:01:39PM +0100, Russell King - ARM Linux wrote:
>> Hi,
>>
>> This patch series introduces generic support for SFP sockets found on
>> various Marvell based platforms. The idea here is to provide common
>> SFP socket support which can be re-used by network drivers as
>> appropriate, rather than each network driver having to re-implement
>> SFP socket support.
>
> Hi Russell
>
> Please could you repost with all the Reviewed-By added and RFC
> removed. The code should get merged then.
No need, I just merged the series into net-next.
Thanks.
^ permalink raw reply
* Re: [PATCH v4 net-next 02/13] nfp: change bpf verifier hooks to match new verifier data structures
From: David Miller @ 2017-08-07 4:01 UTC (permalink / raw)
To: ecree; +Cc: alexei.starovoitov, ast, daniel, netdev, linux-kernel,
iovisor-dev
In-Reply-To: <3d69276f-9f16-0c1a-4596-5c909abe08fc@solarflare.com>
From: Edward Cree <ecree@solarflare.com>
Date: Thu, 3 Aug 2017 17:11:34 +0100
> Signed-off-by: Edward Cree <ecree@solarflare.com>
Sorry, this doesn't work.
The entire source tree must compile properly after each patch in the
patch series.
So if you change a datastructure, you have to update all of the users
in that patch to keep everything compiling and working.
^ permalink raw reply
* Re: [PATCH v9 0/4] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
From: Ding Tianhong @ 2017-08-07 4:13 UTC (permalink / raw)
To: David Miller, bhelgaas, helgaas
Cc: leedom, ashok.raj, werner, ganeshgr, asit.k.mallick,
patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira,
gabriele.paoloni, David.Laight, jeffrey.t.kirsher,
catalin.marinas, will.deacon, mark.rutland, robin.murphy,
alexander.duyck, linux-arm-kernel, netdev, linux-pci,
linux-kernel, linuxarm
In-Reply-To: <20170806.204744.1934067595236180060.davem@davemloft.net>
On 2017/8/7 11:47, David Miller wrote:
> From: Ding Tianhong <dingtianhong@huawei.com>
> Date: Sat, 5 Aug 2017 15:15:09 +0800
>
>> Some devices have problems with Transaction Layer Packets with the Relaxed
>> Ordering Attribute set. This patch set adds a new PCIe Device Flag,
>> PCI_DEV_FLAGS_NO_RELAXED_ORDERING, a set of PCI Quirks to catch some known
>> devices with Relaxed Ordering issues, and a use of this new flag by the
>> cxgb4 driver to avoid using Relaxed Ordering with problematic Root Complex
>> Ports.
>>
>> It's been years since I've submitted kernel.org patches, I appolgise for the
>> almost certain submission errors.
>
> Which tree should merge this? The PCI tree or my networking tree?
>
Hi David：
I think networking tree merge it is a better choice, as it mainly used to tell the NIC
drivers how to use the Relaxed Ordering Attribute, and later we need send patch to enable
RO for ixgbe driver base on this patch. But I am not sure whether Bjorn has some of his own
view. :)
Hi Bjorn:
Could you help review this patch or give some feedback ?
Thanks
Ding
> .
>
^ permalink raw reply
* Re: repost: af_packet vs virtio (was packed ring layout proposal v2)
From: Adam Tao @ 2017-08-07 4:16 UTC (permalink / raw)
To: Michael S. Tsirkin, g
Cc: Steven Luong, john.fastabend, alexei.starovoitov, netdev,
virtio-dev, virtualization, kvm
In-Reply-To: <20170802164931-mutt-send-email-mst@kernel.org>
On Wed, Aug 02, 2017 at 04:50:03PM +0300, Michael S. Tsirkin wrote:
> On Tue, Aug 01, 2017 at 08:54:27PM -0700, Steven Luong wrote:
> > * Descriptor ring:
> >
> > Guest adds descriptors with unique index values and DESC_HW set in flags.
> > Host overwrites used descriptors with correct len, index, and DESC_HW
> > clear.? Flags are always set/cleared last.
> >
> > #define DESC_HW 0x0080
> >
> > struct desc {
> > ? ? ? ? __le64 addr;
> > ? ? ? ? __le32 len;
> > ? ? ? ? __le16 index;
> > ? ? ? ? __le16 flags;
> > };
> >
> > When DESC_HW is set, descriptor belongs to device. When it is clear,
> > it belongs to the driver.
> >
> > We can use 1 bit to set direction
> > /* This marks a buffer as write-only (otherwise read-only). */
> > #define VRING_DESC_F_WRITE? ? ? 2
> >
> > * Scatter/gather support
> >
> > We can use 1 bit to chain s/g entries in a request, same as virtio 1.0:
> >
> > /* This marks a buffer as continuing via the next field. */
next field seems like a structure field in the software, maybe we need
to change the "next field" to "next desc" to avoid misunderstanding.
> >
> >
> > This comment here is confusing to me. In 1.0, virtq_desc has the next field.
> > When the flag VRING_DESC_F_NEXT is set, the next entry to continue is specified
> > in the next field.
> >
> > Here in 1.1, struct desc does not have the next field, only addr, len, index,
> > and flags. So when VRING_DESC_F_NEXT is set in struct desc's flags field, where
> > is the next entry to continue the current descriptor, the entry immediately
> > following the current entry? ie, if the current entry is at index 10 in the
> > descriptor table and its flags is set for VRING_DESC_F_NEXT, is the entry
> > continuing the current entry in index 11?
> >
> > Steven
>
> Exactly, you got it right.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply
* Re: [PATCH net-next] liquidio: add missing strings in oct_dev_state_str array
From: David Miller @ 2017-08-07 4:18 UTC (permalink / raw)
To: felix.manlunas
Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla,
intiyaz.basha
In-Reply-To: <20170803200824.GA2312@felix-thinkpad.cavium.com>
From: Felix Manlunas <felix.manlunas@cavium.com>
Date: Thu, 3 Aug 2017 13:08:24 -0700
> From: Intiyaz Basha <intiyaz.basha@cavium.com>
>
> There's supposed to be a one-to-one correspondence between the 18 macros
> that #define the OCT_DEV states (in octeon_device.h) and the strings in the
> oct_dev_state_str array, but there are only 14 strings in the array.
>
> Add the missing strings (so they become 18 in total), and also revise some
> incorrect/outdated text of existing strings.
>
> Signed-off-by: Intiyaz Basha <intiyaz.basha@cavium.com>
> Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] liquidio: moved console_bitmask module param to lio_main.c
From: David Miller @ 2017-08-07 4:19 UTC (permalink / raw)
To: felix.manlunas
Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla,
intiyaz.basha
In-Reply-To: <20170803221017.GA2469@felix-thinkpad.cavium.com>
From: Felix Manlunas <felix.manlunas@cavium.com>
Date: Thu, 3 Aug 2017 15:10:17 -0700
> From: Intiyaz Basha <intiyaz.basha@cavium.com>
>
> Moving PF module param console_bitmask to lio_main.c for consistency.
>
> Signed-off-by: Intiyaz Basha <intiyaz.basha@cavium.com>
> Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
Applied.
^ permalink raw reply
* Re: [PATCH v7 net-next] net: systemport: Support 64bit statistics
From: David Miller @ 2017-08-07 4:21 UTC (permalink / raw)
To: jqiaoulk; +Cc: f.fainelli, eric.dumazet, netdev
In-Reply-To: <1501801665-6686-1-git-send-email-jqiaoulk@gmail.com>
From: "Jianming.qiao" <jqiaoulk@gmail.com>
Date: Fri, 4 Aug 2017 00:07:45 +0100
> When using Broadcom Systemport device in 32bit Platform, ifconfig can
> only report up to 4G tx,rx status, which will be wrapped to 0 when the
> number of incoming or outgoing packets exceeds 4G, only taking
> around 2 hours in busy network environment (such as streaming).
> Therefore, it makes hard for network diagnostic tool to get reliable
> statistical result, so the patch is used to add 64bit support for
> Broadcom Systemport device in 32bit Platform.
>
> This patch provides 64bit statistics capability on both ethtool and ifconfig.
>
> Signed-off-by: Jianming.qiao <kiki-good@hotmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net 1/1] netvsc: fix race on sub channel creation
From: David Miller @ 2017-08-07 4:24 UTC (permalink / raw)
To: stephen; +Cc: kys, haiyangz, sthemmin, devel, netdev
In-Reply-To: <20170804001354.17067-2-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Thu, 3 Aug 2017 17:13:54 -0700
> The existing sub channel code did not wait for all the sub-channels
> to completely initialize. This could lead to race causing crash
> in napi_netif_del() from bad list. The existing code would send
> an init message, then wait only for the initial response that
> the init message was received. It thought it was waiting for
> sub channels but really the init response did the wakeup.
>
> The new code keeps track of the number of open channels and
> waits until that many are open.
>
> Other issues here were:
> * host might return less sub-channels than was requested.
> * the new init status is not valid until after init was completed.
>
> Fixes: b3e6b82a0099 ("hv_netvsc: Wait for sub-channels to be processed during probe")
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/2 v2 net-next] tcp cwnd undo refactor
From: David Miller @ 2017-08-07 4:25 UTC (permalink / raw)
To: ycheng; +Cc: netdev, ncardwell, unlcsewsun, stephen
In-Reply-To: <20170804033852.97986-1-ycheng@google.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Thu, 3 Aug 2017 20:38:50 -0700
> This patch series consolidate similar cwnd undo functions
> implemented by various congestion control by using existing
> tcp socket state variable. The first patch fixes a corner
> case in of cwnd undo in Reno and HTCP. Since the bug has
> existed for many years and is very minor, we consider this
> patch set more suitable for net-next as the major change
> is the refactor itself.
>
> - v1->v2
> Fix trivial compile errors
Nice cleanup in patch #2.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: User per-cpu 64-bit statistics
From: David Miller @ 2017-08-07 4:27 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, davem, andrew, vivien.didelot, linux-kernel
In-Reply-To: <20170804043328.4730-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu, 3 Aug 2017 21:33:27 -0700
> During testing with a background iperf pushing 1Gbit/sec worth of
> traffic and having both ifconfig and ethtool collect statistics, we
> could see quite frequent deadlocks. Convert the often accessed DSA slave
> network devices statistics to per-cpu 64-bit statistics to remove these
> deadlocks and provide fast efficient statistics updates.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied with appropriate Fixes: tag added.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 1/1] netvsc: fix rtnl deadlock on unregister of vf
From: David Miller @ 2017-08-07 4:29 UTC (permalink / raw)
To: stephen; +Cc: kys, haiyangz, sthemmin, devel, netdev
In-Reply-To: <20170804191400.22471-2-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Fri, 4 Aug 2017 12:14:00 -0700
> With new transparent VF support, it is possible to get a deadlock
> when some of the deferred work is running and the unregister_vf
> is trying to cancel the work element. The solution is to use
> trylock and reschedule (similar to bonding and team device).
>
> Reported-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> Fixes: 0c195567a8f6 ("netvsc: transparent VF management")
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 1/2] net: stmmac: Add Adaptrum Anarion GMAC glue layer
From: David Miller @ 2017-08-07 4:31 UTC (permalink / raw)
To: alex.g; +Cc: netdev, peppe.cavallaro, alexandre.torgue, robh+dt
In-Reply-To: <20170804200852.16049-1-alex.g@adaptrum.com>
From: Alexandru Gagniuc <alex.g@adaptrum.com>
Date: Fri, 4 Aug 2017 13:08:51 -0700
> Before the GMAC on the Anarion chip can be used, the PHY interface
> selection must be configured with the DWMAC block in reset.
>
> This layer covers a block containing only two registers. Although it
> is possible to model this as a reset controller and use the "resets"
> property of stmmac, it's much more intuitive to include this in the
> glue layer instead.
>
> At this time only RGMII is supported, because it is the only mode
> which has been validated hardware-wise.
>
> Signed-off-by: Alexandru Gagniuc <alex.g@adaptrum.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 2/2] dt-bindings: net: Document bindings for anarion-gmac
From: David Miller @ 2017-08-07 4:31 UTC (permalink / raw)
To: alex.g; +Cc: netdev, peppe.cavallaro, alexandre.torgue, robh+dt
In-Reply-To: <20170804200852.16049-2-alex.g@adaptrum.com>
From: Alexandru Gagniuc <alex.g@adaptrum.com>
Date: Fri, 4 Aug 2017 13:08:52 -0700
> Signed-off-by: Alexandru Gagniuc <alex.g@adaptrum.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 00/14] sctp: remove typedefs from structures part 5
From: David Miller @ 2017-08-07 4:33 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman
In-Reply-To: <cover.1501934086.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Sat, 5 Aug 2017 19:59:50 +0800
> As we know, typedef is suggested not to use in kernel, even checkpatch.pl
> also gives warnings about it. Now sctp is using it for many structures.
>
> All this kind of typedef's using should be removed. This patchset is the
> part 5 to remove all typedefs in include/net/sctp/constants.h.
>
> Just as the part 1-4, No any code's logic would be changed in these patches,
> only cleaning up.
Series applied, thank you.
^ permalink raw reply
* Re: [patch net-next 00/15] net: sched: summer cleanup part 2, ndo_setup_tc
From: David Miller @ 2017-08-07 4:37 UTC (permalink / raw)
To: jiri
Cc: netdev, jhs, xiyou.wangcong, daniel, mlxsw, andrew,
vivien.didelot, f.fainelli, simon.horman, pieter.jansenvanvuuren,
dirk.vandermerwe, alexander.h.duyck, amritha.nambiar, oss-drivers
In-Reply-To: <20170805145337.17728-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Sat, 5 Aug 2017 16:53:22 +0200
> From: Jiri Pirko <jiri@mellanox.com>
>
> This patchset focuses on ndo_setup_tc and its args.
> Currently there are couple of things that do not make much sense.
> The type is passed in struct tc_to_netdev, but as it is always
> required, should be arg of the ndo. Other things are passed as args
> but they are only relevant for cls offloads and not mqprio. Therefore,
> they should be pushed to struct. As the tc_to_netdev struct in the end
> is just a container of single pointer, we get rid of it and pass the
> struct according to type. So in the end, we have:
> ndo_setup_tc(dev, type, type_data_struct)
>
> There are couple of cosmetics done on the way to make things smooth.
> Also, reported error is consolidated to eopnotsupp in case the
> asked offload is not supported.
Series applied, thanks Jiri.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/7] net: l3mdev: Support for sockets bound to enslaved device
From: David Miller @ 2017-08-07 4:39 UTC (permalink / raw)
To: dsahern; +Cc: netdev
In-Reply-To: <1501877823-31365-1-git-send-email-dsahern@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Fri, 4 Aug 2017 13:16:56 -0700
> A missing piece to the VRF puzzle is the ability to bind sockets to
> devices enslaved to a VRF. This patch set adds the enslaved device
> index, sdif, to IPv4 and IPv6 socket lookups. The end result for users
> is the following scope options for services:
>
> 1. "global" services - sockets not bound to any device
>
> Allows 1 service to work across all network interfaces with
> connected sockets bound to the VRF the connection originates
> (Requires net.ipv4.tcp_l3mdev_accept=1 for TCP and
> net.ipv4.udp_l3mdev_accept=1 for UDP)
>
> 2. "VRF" local services - sockets bound to a VRF
>
> Sockets work across all network interfaces enslaved to a VRF but
> are limited to just the one VRF.
>
> 3. "device" services - sockets bound to a specific network interface
>
> Service works only through the one specific interface.
>
> v2
> - remove sk_lookup struct and add sdif as an argument to existing
> functions
>
> Changes since RFC:
> - no significant logic changes; mainly whitespace cleanups
Series applied, thanks David.
^ 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