* Re: [PATCH v4 net-next 4/4] bpftool: implement cgroup bpf operations
From: Jakub Kicinski @ 2017-12-13 22:12 UTC (permalink / raw)
To: Roman Gushchin
Cc: netdev, linux-kernel, kernel-team, ast, daniel, kafai,
Quentin Monnet, David Ahern
In-Reply-To: <20171213151854.21960-5-guro@fb.com>
On Wed, 13 Dec 2017 15:18:54 +0000, Roman Gushchin wrote:
> This patch adds basic cgroup bpf operations to bpftool:
> cgroup list, attach and detach commands.
>
> Usage is described in the corresponding man pages,
> and examples are provided.
>
> Syntax:
> $ bpftool cgroup list CGROUP
> $ bpftool cgroup attach CGROUP ATTACH_TYPE PROG [ATTACH_FLAGS]
> $ bpftool cgroup detach CGROUP ATTACH_TYPE PROG
>
> Signed-off-by: Roman Gushchin <guro@fb.com>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
> Cc: Martin KaFai Lau <kafai@fb.com>
> Cc: Quentin Monnet <quentin.monnet@netronome.com>
> Reviewed-by: David Ahern <dsahern@gmail.com>
Excellent, thank you!
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
^ permalink raw reply
* Re: [PATCH v2 net-next 0/7] net: speedup netns create/delete time
From: Eric Dumazet @ 2017-12-13 21:52 UTC (permalink / raw)
To: Dmitry Torokhov, Eric Dumazet
Cc: Tariq Toukan, David S . Miller, netdev, Eric W . Biederman,
Majd Dibbiny, Yonatan Cohen, Eran Ben Elisha
In-Reply-To: <CAKdAkRTpnxxW0h5smyUDQKm4f94D6-i7G5UK_NnGj_i-cwj35Q@mail.gmail.com>
On Wed, 2017-12-13 at 13:43 -0800, Dmitry Torokhov wrote:
> Hi Eric,
>
> On Thu, Oct 19, 2017 at 7:11 AM, Eric Dumazet <edumazet@google.com> wrote:
> >
> > On Thu, Oct 19, 2017 at 4:48 AM, Tariq Toukan <tariqt@mellanox.com> wrote:
> > >
> > > Hi Eric,
> > >
> > > I just wanted to check if this is solved already, as I don't want to keep an
> > > unnecessary revert patch in our internal branches.
> > > According to my check bug still exists.
> > >
> >
> > I will handle this today, thanks for the reminder.
>
> Did you have a chance to do this? It looks like the original change
> landed on mainline and causes modules to be autoloaded on KOBJ_UNBIND
> again.
>
> Thanks!
I sent the following to Tariq, and he tested it successfully.
I will submit this formally.
diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c
index c3e84edc47c965d40199b652ba78876cdaa9c70c..0795482b15d5a8f1b65b570a071aa1419cb923d8 100644
--- a/lib/kobject_uevent.c
+++ b/lib/kobject_uevent.c
@@ -346,19 +346,25 @@ static int kobject_uevent_net_broadcast(struct kobject *kobj,
static void zap_modalias_env(struct kobj_uevent_env *env)
{
static const char modalias_prefix[] = "MODALIAS=";
+ size_t offset = 0, len;
int i;
for (i = 0; i < env->envp_idx;) {
+ len = strlen(env->envp[i]) + 1;
if (strncmp(env->envp[i], modalias_prefix,
sizeof(modalias_prefix) - 1)) {
i++;
+ offset += len;
continue;
}
- if (i != env->envp_idx - 1)
+ env->buflen -= len;
+ if (i != env->envp_idx - 1) {
+ memmove(env->envp[i], env->envp[i + 1],
+ env->buflen - offset);
memmove(&env->envp[i], &env->envp[i + 1],
sizeof(env->envp[i]) * env->envp_idx - 1);
-
+ }
env->envp_idx--;
}
}
^ permalink raw reply related
* Re: [PATCH net-next v2] bpf/tracing: fix kernel/events/core.c compilation error
From: Daniel Borkmann @ 2017-12-13 21:51 UTC (permalink / raw)
To: Yonghong Song, ast, sfr, netdev; +Cc: kernel-team
In-Reply-To: <20171213183537.83534-1-yhs@fb.com>
On 12/13/2017 07:35 PM, Yonghong Song wrote:
> Commit f371b304f12e ("bpf/tracing: allow user space to
> query prog array on the same tp") introduced a perf
> ioctl command to query prog array attached to the
> same perf tracepoint. The commit introduced a
> compilation error under certain config conditions, e.g.,
> (1). CONFIG_BPF_SYSCALL is not defined, or
> (2). CONFIG_TRACING is defined but neither CONFIG_UPROBE_EVENTS
> nor CONFIG_KPROBE_EVENTS is defined.
>
> Error message:
> kernel/events/core.o: In function `perf_ioctl':
> core.c:(.text+0x98c4): undefined reference to `bpf_event_query_prog_array'
>
> This patch fixed this error by guarding the real definition under
> CONFIG_BPF_EVENTS and provided static inline dummy function
> if CONFIG_BPF_EVENTS was not defined.
> It renamed the function from bpf_event_query_prog_array to
> perf_event_query_prog_array and moved the definition from linux/bpf.h
> to linux/trace_events.h so the definition is in proximity to
> other prog_array related functions.
>
> Fixes: f371b304f12e ("bpf/tracing: allow user space to query prog array on the same tp")
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Yonghong Song <yhs@fb.com>
That's better, applied to bpf-next, thanks Yonghong!
^ permalink raw reply
* Re: [PATCH v2 net-next 0/7] net: speedup netns create/delete time
From: Dmitry Torokhov @ 2017-12-13 21:43 UTC (permalink / raw)
To: Eric Dumazet
Cc: Tariq Toukan, David S . Miller, netdev, Eric W . Biederman,
Eric Dumazet, Majd Dibbiny, Yonatan Cohen, Eran Ben Elisha
In-Reply-To: <CANn89iKiKvzz6_R+T4kO8ztXFC7ke299+vOsGr92q2NfGBwFjw@mail.gmail.com>
Hi Eric,
On Thu, Oct 19, 2017 at 7:11 AM, Eric Dumazet <edumazet@google.com> wrote:
>
> On Thu, Oct 19, 2017 at 4:48 AM, Tariq Toukan <tariqt@mellanox.com> wrote:
> >
> > Hi Eric,
> >
> > I just wanted to check if this is solved already, as I don't want to keep an
> > unnecessary revert patch in our internal branches.
> > According to my check bug still exists.
> >
> I will handle this today, thanks for the reminder.
Did you have a chance to do this? It looks like the original change
landed on mainline and causes modules to be autoloaded on KOBJ_UNBIND
again.
Thanks!
--
Dmitry
--
Dmitry
^ permalink raw reply
* Re: [PATCH net V2 0/3] mlx4 misc fixes
From: David Miller @ 2017-12-13 21:40 UTC (permalink / raw)
To: tariqt; +Cc: netdev, eranbe
In-Reply-To: <1513181531-17522-1-git-send-email-tariqt@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
Date: Wed, 13 Dec 2017 18:12:08 +0200
> This patchset contains misc bug fixes from the team
> to the mlx4 Core and Eth drivers.
>
> Patch 1 by Eugenia fixes an MTU issue in selftest.
> Patch 2 by Eran fixes an accounting issue in the resource tracker.
> Patch 3 by Eran fixes a race condition that causes counter inconsistency.
>
> Series generated against net commit:
> 200809716aed fou: fix some member types in guehdr
...
> v2:
> Patch 2: Add reviewer credit, rephrase commit message.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/5] VSOCK: extract connect/accept functions from vsock_diag_test.c
From: David Miller @ 2017-12-13 21:32 UTC (permalink / raw)
To: stefanha; +Cc: netdev, jhansen, decui
In-Reply-To: <20171213144911.6428-3-stefanha@redhat.com>
From: Stefan Hajnoczi <stefanha@redhat.com>
Date: Wed, 13 Dec 2017 14:49:08 +0000
> +#include <sys/socket.h>
> +#include "../../../include/uapi/linux/vm_sockets.h"
> +
...
> -#include "../../../include/uapi/linux/vm_sockets.h"
> #include "../../../include/uapi/linux/vm_sockets_diag.h"
This really should never be necessary.
As part of the build, before tunning tests, one is required to do
"make headers_install" and whether as root or a normal user, this
will make the UAPI headers of the current kernel available to the
build of the testcases.
So please undo this weird relative include stuff.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 net-next] net: dsa: lan9303: Introduce lan9303_read_wait
From: David Miller @ 2017-12-13 21:25 UTC (permalink / raw)
To: privat; +Cc: andrew, vivien.didelot, f.fainelli, netdev, linux-kernel
In-Reply-To: <20171213144250.27120-1-privat@egil-hjelmeland.no>
From: Egil Hjelmeland <privat@egil-hjelmeland.no>
Date: Wed, 13 Dec 2017 15:42:50 +0100
> Simplify lan9303_indirect_phy_wait_for_completion()
> and lan9303_switch_wait_for_completion() by using a new function
> lan9303_read_wait()
>
> Changes v1 -> v2:
> - param 'mask' type u32
> - removed param 'value' (will probably never be used)
> - add newline before return
>
> Signed-off-by: Egil Hjelmeland <privat@egil-hjelmeland.no>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next 2/2] net/sched: act_csum: don't use spinlock in the fast path
From: David Miller @ 2017-12-13 21:23 UTC (permalink / raw)
To: dcaratti; +Cc: xiyou.wangcong, jiri, netdev
In-Reply-To: <16125b3f16fb9f8c068ec80ce3f6550d0465521c.1513104506.git.dcaratti@redhat.com>
From: Davide Caratti <dcaratti@redhat.com>
Date: Wed, 13 Dec 2017 10:48:38 +0100
> Then, in the data path, use READ_ONCE() to
> read those values, to avoid lock contention among multiple readers.
...
> @@ -544,14 +543,12 @@ static int tcf_csum(struct sk_buff *skb, const struct tc_action *a,
>
> tcf_lastuse_update(&p->tcf_tm);
> bstats_cpu_update(this_cpu_ptr(p->common.cpu_bstats), skb);
> - spin_lock(&p->tcf_lock);
> - action = p->tcf_action;
> - update_flags = p->update_flags;
> - spin_unlock(&p->tcf_lock);
>
> + action = READ_ONCE(p->tcf_action);
> if (unlikely(action == TC_ACT_SHOT))
> goto drop;
>
> + update_flags = READ_ONCE(p->update_flags);
> switch (tc_skb_protocol(skb)) {
> case cpu_to_be16(ETH_P_IP):
> if (!tcf_csum_ipv4(skb, update_flags))
That's not why the lock is here.
We must read both action and flags atomically so that they are consistent
with eachother.
We must never use action from one configuration change and flags from
yet another.
Find a way to load both of these values with a single cpu load, then you
can legally remove the lock.
^ permalink raw reply
* Re: [PATCH 1/2] hp100: Fix a possible sleep-in-atomic bug in hp100_login_to_vg_hub
From: David Miller @ 2017-12-13 21:20 UTC (permalink / raw)
To: baijiaju1990; +Cc: perex, floeff, acme, netdev, linux-kernel
In-Reply-To: <1513158468-14382-1-git-send-email-baijiaju1990@gmail.com>
I want you to review all of your patches and resend them after you
have checked them carefully.
The first patch I even looked at, this one, is buggy.
You changed a schedule_timeout_interruptible(1) into a udelay(10)
That's not right.
schedule_timeout_interruptible() takes a "jiffies" argument, which
is a completely different unit than udelay() takes. You would have
to scale the argument to udelay() in some way using HZ.
Furthermore, the udelay argument you would come up with would
be way too long to be appropirate in this atomic context.
That's why the code tries to use a sleeping timeout, a long wait is
necessary here.
^ permalink raw reply
* Re: [PATCH] net: phy: marvell: avoid pause mode on SGMII-to-Copper for 88e151x
From: David Miller @ 2017-12-13 21:14 UTC (permalink / raw)
To: rmk+kernel; +Cc: andrew, f.fainelli, jon, netdev
In-Reply-To: <E1eP3Ev-0000ZJ-1L@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Wed, 13 Dec 2017 09:22:09 +0000
> @@ -924,6 +924,16 @@ static int m88e1510_config_init(struct phy_device *phydev)
> err = marvell_set_page(phydev, MII_MARVELL_COPPER_PAGE);
> if (err < 0)
> return err;
> +
> + /* There appears to be a bug in the 88e1512 when used in
> + * SGMII to copper mode, where the AN advertisment register
> + * clears the pause bits each time a negotiation occurs.
> + * This means we can never be truely sure what was advertised,
> + * so disable Pause support.
> + */
> + pause = SUPPORTED_Pause | SUPPORTED_Asym_Pause;
> + phydev->supported &= ~pause;
> + phydev->advertising &= ~pause;
> }
>
This function doesn't have a local 'pause' variable in any of my trees.
I wonder what you generated this against, and even more importantly, what
tree the reviewers were considering when looking at this patch :)
^ permalink raw reply
* Re: [PATCH] net: phy: marvell: avoid configuring fiber page for SGMII-to-Copper
From: David Miller @ 2017-12-13 21:13 UTC (permalink / raw)
To: rmk+kernel; +Cc: andrew, f.fainelli, jon, netdev
In-Reply-To: <E1eP3Ep-0000ZC-UN@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Wed, 13 Dec 2017 09:22:03 +0000
> When in SGMII-to-Copper mode, the fiber page is used for the MAC facing
> link, and does not require configuration of the fiber auto-negotiation
> settings. Avoid trying.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Applied.
^ permalink raw reply
* Re: [PATCH net] dwc-xlgmac: Add co-maintainer
From: David Miller @ 2017-12-13 21:13 UTC (permalink / raw)
To: Jie.Deng1; +Cc: netdev, Jose.Abreu
In-Reply-To: <7629e8d0cb525682e3392696bc1b642351e47f98.1493987088.git.jiedeng@synopsys.com>
From: Jie Deng <Jie.Deng1@synopsys.com>
Date: Wed, 13 Dec 2017 12:04:12 +0800
> Jose Abreu will join to maintain dwc-xlgmac.
> He will help with new feature development for
> this driver. Thanks Jose and welcome on board!
>
> Signed-off-by: Jie Deng <jiedeng@synopsys.com>
Applied.
^ permalink raw reply
* Re: Huge memory leak with 4.15.0-rc2+
From: John Fastabend @ 2017-12-13 21:05 UTC (permalink / raw)
To: Paweł Staszewski, Linux Kernel Network Developers
In-Reply-To: <1b1f58e6-3af1-8b14-142d-06deeb458e3b@itcare.pl>
On 12/12/2017 09:57 AM, Paweł Staszewski wrote:
>
>
> W dniu 2017-12-11 o 23:27, Paweł Staszewski pisze:
>>
>>
>> W dniu 2017-12-11 o 23:15, John Fastabend pisze:
>>> On 12/11/2017 01:48 PM, Paweł Staszewski wrote:
>>>>
>>>> W dniu 2017-12-11 o 22:23, Paweł Staszewski pisze:
>>>>> Hi
>>>>>
>>>>>
>>>>> I just upgraded some testing host to 4.15.0-rc2+ kernel
>>>>>
>>>>> And after some time of traffic processing - when traffic on all ports
>>>>> reach about 3Mpps - memleak started.
>>>>>
>>>
>>> [...]
>>>
>>>>> Some observations - when i disable tso on all cards there is more
>>>>> memleak.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> When traffic starts to drop - there is less and less memleak
>>>> below link to memory usage graph:
>>>> https://ibb.co/hU97kG
>>>>
>>>> And there is rising slab_unrecl - Amount of unreclaimable memory used
>>>> for slab kernel allocations
>>>>
>>>>
>>>> Forgot to add that im using hfsc and qdiscs like pfifo on classes.
>>>>
>>>>
>>> Maybe some error case I missed in the qdisc patches I'm looking into
>>> it.
>>>
>>> Thanks,
>>> John
>>>
>>>
>> This is how it looks like when corelated on graph - traffic vs mem
>> https://ibb.co/njpkqG
>>
>> Typical hfsc class + qdisc:
>> ### Client interface vlan1616
>> tc qdisc del dev vlan1616 root
>> tc qdisc add dev vlan1616 handle 1: root hfsc default 100
>> tc class add dev vlan1616 parent 1: classid 1:100 hfsc ls m2 200Mbit ul m2 200Mbit
>> tc qdisc add dev vlan1616 parent 1:100 handle 100: pfifo limit 128
>> ### End TM for client interface
>> tc qdisc del dev vlan1616 ingress
>> tc qdisc add dev vlan1616 handle ffff: ingress
>> tc filter add dev vlan1616 parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate 200Mbit burst 200M mtu 32k drop flowid 1:1
>>
>> And this is same for about 450 vlan interfaces
>>
>>
>> Good thing is that compared to 4.14.3 i have about 5% less cpu load on 4.15.0-rc2+
>>
>> When hfsc will be lockless or tbf - then it will be really huge difference in cpu load on x86 when using traffic shaping - so really good job John.
>>
>>
>>
>>
>
> Yestarday changed kernel from
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
>
> to
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?h=v4.15-rc3
>
>
> And there is no memleak.
> So yes probabbly lockless qdisc patches
>
It seems I was able to produce a similar memleak with qdisc patches
reverted and running TCP traffic overnight. I guess we can do a bisect
and track it down. Will try to get a "good" run tonight.
Thanks,
John
^ permalink raw reply
* Re: [PATCH net] tcp: refresh tcp_mstamp from timers callbacks
From: David Miller @ 2017-12-13 21:04 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, soheil, ncardwell, maloney
In-Reply-To: <1513131772.25033.60.camel@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 12 Dec 2017 18:22:52 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Only the retransmit timer currently refreshes tcp_mstamp
>
> We should do the same for delayed acks and keepalives.
>
> Even if RFC 7323 does not request it, this is consistent to what linux
> did in the past, when TS values were based on jiffies.
>
> Fixes: 385e20706fac ("tcp: use tp->tcp_mstamp in output path")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCH net] tcp: fix potential underestimation on rcv_rtt
From: David Miller @ 2017-12-13 21:03 UTC (permalink / raw)
To: weiwan; +Cc: netdev, edumazet
In-Reply-To: <20171213002858.74188-1-tracywwnj@gmail.com>
From: Wei Wang <weiwan@google.com>
Date: Tue, 12 Dec 2017 16:28:58 -0800
> From: Wei Wang <weiwan@google.com>
>
> When ms timestamp is used, current logic uses 1us in
> tcp_rcv_rtt_update() when the real rcv_rtt is within 1 - 999us.
> This could cause rcv_rtt underestimation.
> Fix it by always using a min value of 1ms if ms timestamp is used.
>
> Fixes: 645f4c6f2ebd ("tcp: switch rcv_rtt_est and rcvq_space to high
> resolution timestamps")
>
> Signed-off-by: Wei Wang <weiwan@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Please, in the future, do not wrap long Fixes: tag lines. Also, do
not add an empty line between Fixes: and other tags like Signed-off-by.
That are all tags and belong together as a seamless block of text.
Thank you.
^ permalink raw reply
* Re: net: phy: consolidate PHY reset in phy_init_hw()
From: Daniel Walker @ 2017-12-13 21:03 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, David S. Miller, netdev@vger.kernel.org
In-Reply-To: <20171213203512.GC932@lunn.ch>
On 12/13/2017 12:35 PM, Andrew Lunn wrote:
> On Wed, Dec 13, 2017 at 10:46:02AM -0800, Daniel Walker wrote:
>> Hi,
>>
>> https://sjc-apl-grt32.cisco.com:8081/gitweb?p=xe-linux/kernel.git;a=commit;h=87aa9f9c61ad56d505641681812e92ad976f8608
> Hi Daniel
>
> This is a 4 year old patch, so i'm kind of surprised nobody noticed
> this before. How did you conclude this patch is the problem?
>
> Thanks
> Andrew
I just did some debugging to find the -ETIMEDOUT error message which I
tracked back to the waiting routine inside this patch. I did do a high
level bisect jumping between major versions, and the issue seemed to go
away around the time when this patch was added. v3.10 didn't have it,
and one of the version of the kernel immediately after had it, either
v3.11 or v3.12 ..
This phy may not be used often, that might be part of it.
Daniel
^ permalink raw reply
* Re: [PATCH net-next 0/6] hv_netvsc: minor changes
From: David Miller @ 2017-12-13 20:57 UTC (permalink / raw)
To: stephen; +Cc: kys, haiyangz, sthemmin, devel, netdev
In-Reply-To: <20171213004840.17507-1-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Tue, 12 Dec 2017 16:48:34 -0800
> This includes minor cleanup of code in send and receive path and
> also a new statistic to check for allocation failures. This also
> eliminates some of the extra RCU when not needed.
>
> There is a theoritical bug where buffered data could be blocked
> for longer than necessary if the ring buffer got full. This
> has not been seen in the wild, found by inspection.
>
> The reference count between net device and internal RNDIS
> is not needed.
Series applied, thanks Stephen.
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] PHYLINK preparatory patches for DSA
From: David Miller @ 2017-12-13 20:55 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, rmk+kernel, andrew, vivien.didelot
In-Reply-To: <20171213000029.8649-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue, 12 Dec 2017 16:00:24 -0800
> In preparation for having DSA migrate to PHYLINK, I had to come up with a
> number of preparatory patches:
>
> - we need to be able to pass phy_flags from an external component calling
> phylink_of_phy_connect()
> - DSA tries to connect through OF first, then fallsback using its own internal
> MDIO bus, in that case we would both show an error, but also not know what
> the correct phy_interface_t would be, instead use the PHY device/driver provided
> one
> - Finally bcm_sf2 makes use of all possible PHYs out there: internal, external,
> fixed, and MoCA, the latter requires a bit of help to signal link notifications
> through a MMIO interrupt, as well a report a correct PORT type
>
> Changes in v2:
>
> - rebased against latest net-next/master
> - added kernel doc documentation
> - dropped error message in phylink_of_phy_connect() as suggested by Russell
Series applied, thanks Florian.
^ permalink raw reply
* Re: [PATH net-next] tcp: pause Fast Open globally after third consecutive timeout
From: David Miller @ 2017-12-13 20:51 UTC (permalink / raw)
To: ycheng; +Cc: netdev, edumazet, ncardwell, weiwan, cpaasch, ddamjanovic,
mcmanus
In-Reply-To: <20171212211040.222118-1-ycheng@google.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Tue, 12 Dec 2017 13:10:40 -0800
> Prior to this patch, active Fast Open is paused on a specific
> destination IP address if the previous connections to the
> IP address have experienced recurring timeouts . But recent
> experiments by Microsoft (https://goo.gl/cykmn7) and Mozilla
> browsers indicate the isssue is often caused by broken middle-boxes
> sitting close to the client. Therefore it is much better user
> experience if Fast Open is disabled out-right globally to avoid
> experiencing further timeouts on connections toward other
> destinations.
>
> This patch changes the destination-IP disablement to global
> disablement if a connection experiencing recurring timeouts
> or aborts due to timeout. Repeated incidents would still
> exponentially increase the pause time, starting from an hour.
> This is extremely conservative but an unfortunate compromise to
> minimize bad experience due to broken middle-boxes.
>
> Reported-by: Dragana Damjanovic <ddamjanovic@mozilla.com>
> Reported-by: Patrick McManus <mcmanus@ducksong.com>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> Reviewed-by: Wei Wang <weiwan@google.com>
> Reviewed-by: Neal Cardwell <ncardwell@google.com>
> Reviewed-by: Eric Dumazet <edumazet@google.com>
Very unfortunate, but I can't suggest anything better at this time.
Applied, thank you.
^ permalink raw reply
* Re: [PATCH v3 net-next] net: ethernet: ti: cpdma: correct error handling for chan create
From: David Miller @ 2017-12-13 20:51 UTC (permalink / raw)
To: ivan.khoronzhuk; +Cc: grygorii.strashko, netdev, linux-omap, linux-kernel
In-Reply-To: <1513112795-20045-1-git-send-email-ivan.khoronzhuk@linaro.org>
From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Date: Tue, 12 Dec 2017 23:06:35 +0200
> It's not correct to return NULL when that is actually an error and
> function returns errors in any other wrong case. In the same time,
> the cpsw driver and davinci emac doesn't check error case while
> creating channel and it can miss actual error. Also remove WARNs
> replacing them on dev_err msgs.
>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: Add support for ethtool i2c dump
From: David Miller @ 2017-12-13 20:49 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, venkatesh, arjun, leedom
In-Reply-To: <1513107245-13703-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Wed, 13 Dec 2017 01:04:05 +0530
> From: Arjun Vynipadath <arjun@chelsio.com>
>
> Adds support for ethtool get_module_info() and get_module_eeprom()
> callbacks that will dump necessary information for a SFP.
>
> Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net] skge: remove redundunt free_irq under spinlock
From: David Miller @ 2017-12-13 20:47 UTC (permalink / raw)
To: stephen; +Cc: netdev, sthemmin
In-Reply-To: <20171212183029.28684-1-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Tue, 12 Dec 2017 10:30:29 -0800
> The code to handle multi-port SKGE boards was freeing IRQ
> twice. The first one was under lock and might sleep.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> Given that multi-port SKGE devices are very old and unlikely
> to still be in use. This patch does not need to go to stable.
Applied, thanks Stephen.
^ permalink raw reply
* Re: [PATCH net-next v4 4/5] bnx2x: Use NETIF_F_GRO_HW.
From: Michael Chan @ 2017-12-13 20:45 UTC (permalink / raw)
To: Chopra, Manish
Cc: davem@davemloft.net, netdev@vger.kernel.org,
andrew.gospodarek@broadcom.com, Elior, Ariel,
Dept-Eng Everest Linux L2
In-Reply-To: <BN3PR0701MB1412837727C4AB036434737289350@BN3PR0701MB1412.namprd07.prod.outlook.com>
On Wed, Dec 13, 2017 at 1:08 AM, Chopra, Manish
<Manish.Chopra@cavium.com> wrote:
>
> Hi Michael, There seems a behavioral change here. This driver support two HW aggregation modes [LRO and GRO]
> With the changes, Interfaces come with HW GRO enabled and LRO disabled by default as opposed to earlier where interfaces used to come with LRO enabled.
Right. Before, you had both NETIF_F_GRO and NETIF_F_LRO set and the
code looked at NETIF_F_LRO first and turned on LRO.
Now, we set NETIF_F_GRO and NETIF_F_GRO_HW by default. NETIF_F_LRO is
turned off since NETIF_F_GRO_HW is on.
If you want, I can change it back to the old default.
>
> Also, there seems some problem when turning on LRO even after GRO disable.
> When I tried to disable GRO and then tried to enable LRO it didn't go well. Not sure why ?
I just put an old BCM57810 card into my machine and it works for me.
As long as I turn off GRO or GRO_HW, I can turn on LRO.
[root@localhost bnx2x]# ethtool -K p1p1 lro on
Cannot get device udp-fragmentation-offload settings: Operation not supported
Cannot get device udp-fragmentation-offload settings: Operation not supported
Could not change any device features
[root@localhost bnx2x]# ethtool -K p1p1 gro off
Cannot get device udp-fragmentation-offload settings: Operation not supported
Cannot get device udp-fragmentation-offload settings: Operation not supported
Actual changes:
generic-receive-offload: off
large-receive-offload: on
rx-gro-hw: off [requested on]
[root@localhost bnx2x]# ethtool -K p1p1 lro on
Cannot get device udp-fragmentation-offload settings: Operation not supported
Cannot get device udp-fragmentation-offload settings: Operation not supported
^ permalink raw reply
* Re: net: phy: consolidate PHY reset in phy_init_hw()
From: Andrew Lunn @ 2017-12-13 20:35 UTC (permalink / raw)
To: Daniel Walker; +Cc: Florian Fainelli, David S. Miller, netdev@vger.kernel.org
In-Reply-To: <e03a30bf-9af0-2375-0b50-6fd2766c2249@cisco.com>
On Wed, Dec 13, 2017 at 10:46:02AM -0800, Daniel Walker wrote:
>
> Hi,
>
> https://sjc-apl-grt32.cisco.com:8081/gitweb?p=xe-linux/kernel.git;a=commit;h=87aa9f9c61ad56d505641681812e92ad976f8608
Hi Daniel
This is a 4 year old patch, so i'm kind of surprised nobody noticed
this before. How did you conclude this patch is the problem?
Thanks
Andrew
^ permalink raw reply
* [PATCH] Fix handling of verdicts after NF_QUEUE
From: Debabrata Banerjee @ 2017-12-13 20:33 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Greg Kroah-Hartman, David S . Miller, netfilter-devel, coreteam,
netdev, stable, dbanerje
A verdict of NF_STOLEN after NF_QUEUE will cause an incorrect return value
and a potential kernel panic via double free of skb's
This was broken by commit 7034b566a4e7 ("netfilter: fix nf_queue handling")
and subsequently fixed in v4.10 by commit c63cbc460419 ("netfilter:
use switch() to handle verdict cases from nf_hook_slow()"). However that
commit cannot be cleanly cherry-picked to v4.9
Signed-off-by: Debabrata Banerjee <dbanerje@akamai.com>
---
This fix is only needed for v4.9 stable since v4.10+ does not have the
issue
---
net/netfilter/core.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/netfilter/core.c b/net/netfilter/core.c
index 004af030ef1a..d869ea50623e 100644
--- a/net/netfilter/core.c
+++ b/net/netfilter/core.c
@@ -364,6 +364,11 @@ int nf_hook_slow(struct sk_buff *skb, struct nf_hook_state *state)
ret = nf_queue(skb, state, &entry, verdict);
if (ret == 1 && entry)
goto next_hook;
+ } else {
+ /* Implicit handling for NF_STOLEN, as well as any other
+ * non conventional verdicts.
+ */
+ ret = 0;
}
return ret;
}
--
2.15.1
^ permalink raw reply related
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