[PATCH] ixgbe: check Master Disable bit after setting

From: Dan Streetman <dan.street...@canonical.com> Spec section 8.2.4.1.1 notes that after setting the PCIe Master Disable bit, it must be read to verify it was set before polling the Master Enable status bit. This adds the check to verify the Master Disable bit was set. This also co

[PATCH] ixgbe: Wait for 1ms, not 1us, after RST

From: Dan Streetman <dan.street...@canonical.com> The driver currently waits 1us after issuing a RST, but the spec requires it to wait 1ms. Signed-off-by: Dan Streetman <dan.street...@canonical.com> Signed-off-by: Dan Streetman <ddstr...@ieee.org> --- drivers/net/ethernet/inte

Re: [PATCH] xfrm: dst_entries_init() per-net dst_ops

On Tue, Oct 27, 2015 at 12:15 PM, <dan.street...@canonical.com> wrote: > From: Dan Streetman <dan.street...@canonical.com> > > The ipv4 and ipv6 xfrms each create a template dst_ops object, and > perform dst_entries_init() on the template objects. Then each net > name

Re: [PATCHv2] xfrm: dst_entries_init() per-net dst_ops

On Thu, Oct 29, 2015 at 7:57 AM, kbuild test robot <l...@intel.com> wrote: > Hi Dan, > > [auto build test WARNING on ipsec/master -- if it's inappropriate base, > please suggest rules for selecting the more suitable base] > > url: > https://github.com/0day-ci/linux

[PATCHv2] xfrm: dst_entries_init() per-net dst_ops

with a negative dst_ops count while another winds up with a continually increasing count, eventually reaching its gc_thresh limit, which causes all new traffic on the net namespace to fail with -ENOBUFS. Signed-off-by: Dan Streetman <dan.street...@canonical.com> Signed-off-by: Dan Streetman

[PATCHv3] xfrm: dst_entries_init() per-net dst_ops

with a negative dst_ops count while another winds up with a continually increasing count, eventually reaching its gc_thresh limit, which causes all new traffic on the net namespace to fail with -ENOBUFS. Signed-off-by: Dan Streetman <dan.street...@canonical.com> Signed-off-by: Dan Streetman

Re: [PATCH] xfrm: dst_entries_init() per-net dst_ops

On Wed, Oct 28, 2015 at 9:42 AM, Hannes Frederic Sowa <han...@stressinduktion.org> wrote: > Hello, > > On Wed, Oct 28, 2015, at 14:32, Dan Streetman wrote: >> On Tue, Oct 27, 2015 at 12:15 PM, <dan.street...@canonical.com> wrote: >> > From: Dan St

[PATCH] xfrm: dst_entries_init() per-net dst_ops

From: Dan Streetman <dan.street...@canonical.com> The ipv4 and ipv6 xfrms each create a template dst_ops object, and perform dst_entries_init() on the template objects. Then each net namespace has its net.xfrm.xfrm[46]_dst_ops field set to the template values. The p

Re: [PATCH] ixgbe: Wait for 1ms, not 1us, after RST

irsher, Jeffrey T >> Cc: Brandeburg, Jesse; Nelson, Shannon; Wyborny, Carolyn; Skidmore, >> Donald C; Vick, Matthew; Ronciak, John; Williams, Mitch A; intel-wired- >> l...@lists.osuosl.org; netdev@vger.kernel.org; linux-ker...@vger.kernel.org; >> Dan Streetman; Dan Streetman >

Re: [PATCH] ixgbe: check Master Disable bit after setting

irsher, Jeffrey T >> Cc: Brandeburg, Jesse; Nelson, Shannon; Wyborny, Carolyn; Skidmore, >> Donald C; Vick, Matthew; Ronciak, John; Williams, Mitch A; intel-wired- >> l...@lists.osuosl.org; netdev@vger.kernel.org; linux-ker...@vger.kernel.org; >> Dan Streetman; Dan Streetman

[PATCHv2] ixgbe: Wait for 1ms, not 1us, after RST

The driver currently waits 1us after issuing a RST, but the spec requires it to wait 1ms. This adds a msleep(1) before polling the reset bit. Signed-off-by: Dan Streetman <dan.street...@canonical.com> Signed-off-by: Dan Streetman <ddstr...@ieee.org> --- changes since v1: use mslee

Re: xfrm4_garbage_collect reaching limit

On Fri, Sep 11, 2015 at 5:48 AM, Steffen Klassert <steffen.klass...@secunet.com> wrote: > Hi Dan. > > On Thu, Sep 10, 2015 at 05:01:26PM -0400, Dan Streetman wrote: >> Hi Steffen, >> >> I've been working with Jay on a ipsec issue, which I believe he >> discu

Re: xfrm4_garbage_collect reaching limit

On Wed, Sep 16, 2015 at 4:45 AM, Steffen Klassert <steffen.klass...@secunet.com> wrote: > On Mon, Sep 14, 2015 at 11:14:59PM -0400, Dan Streetman wrote: >> On Fri, Sep 11, 2015 at 5:48 AM, Steffen Klassert >> <steffen.klass...@secunet.com> wrote: >> > &g

xfrm4_garbage_collect reaching limit

Hi Steffen, I've been working with Jay on a ipsec issue, which I believe he discussed with you. In this case the xfrm4_garbage_collect is returning error because the number of xfrm4 dst entries has exceeded twice the gc_thresh, which causes new allocations of xfrm4 dst objects to fail, thus

Re: xfrm4_garbage_collect reaching limit

On Fri, Sep 18, 2015 at 1:00 AM, Dan Streetman <ddstr...@ieee.org> wrote: > On Wed, Sep 16, 2015 at 4:45 AM, Steffen Klassert > <steffen.klass...@secunet.com> wrote: >> On Mon, Sep 14, 2015 at 11:14:59PM -0400, Dan Streetman wrote: >>> On Fri, Sep 11,

Re: xfrm4_garbage_collect reaching limit

On Wed, Sep 16, 2015 at 4:45 AM, Steffen Klassert <steffen.klass...@secunet.com> wrote: > On Mon, Sep 14, 2015 at 11:14:59PM -0400, Dan Streetman wrote: >> On Fri, Sep 11, 2015 at 5:48 AM, Steffen Klassert >> <steffen.klass...@secunet.com> wrote: >> > &g

[PATCH stable] Set a large MTU on ovs-created tunnel devices

Can you queue up these commits for stable? commit 72564b59ffc438ea103b0727a921aaddce766728 Author: David Wragg Date: Wed Feb 10 00:05:55 2016 + vxlan: Relax MTU constraints commit 55e5bfb53cff286c1c1ff49f51325dc15c7fea63 Author: David Wragg

Re: [PATCH stable] Set a large MTU on ovs-created tunnel devices

On Fri, Jun 3, 2016 at 2:44 PM, David Miller <da...@davemloft.net> wrote: > From: Dan Streetman <dan.street...@canonical.com> > Date: Fri, 3 Jun 2016 13:49:09 -0400 > >> Can you queue up these commits for stable? > > This stuff doesn't cleanly backport, I tried

[PATCH 4.4-stable 2/3] geneve: Relax MTU constraints

From: David Wragg Allow the MTU of geneve devices to be set to large values, in order to exploit underlying networks with larger frame sizes. GENEVE does not have a fixed encapsulation overhead (an openvswitch rule can add variable length options), so there is no relevant

[PATCH 4.4-stable 0/3] Set a large MTU on ovs-created tunnel devices

Can you queue these for 4.4 stable? The first 2 are cherry-picked cleanly into 4.4, the last required only context changes to apply. The commits are only needed in 4.4, as the bugs they fix were introduced after 4.1. David Wragg (3): vxlan: Relax MTU constraints geneve: Relax MTU

[PATCH 4.4-stable 3/3] vxlan, gre, geneve: Set a large MTU on ovs-created tunnel devices

From: David Wragg Prior to 4.3, openvswitch tunnel vports (vxlan, gre and geneve) could transmit vxlan packets of any size, constrained only by the ability to send out the resulting packets. 4.3 introduced netdevs corresponding to tunnel vports. These netdevs have an MTU,

[PATCH 4.4-stable 1/3] vxlan: Relax MTU constraints

From: David Wragg Allow the MTU of vxlan devices without an underlying device to be set to larger values (up to a maximum based on IP packet limits and vxlan overhead). Previously, their MTUs could not be set to higher than the conventional ethernet value of 1500. This is a

bnx2x commits needed to use 7.51.10 firmware?

Hi Ariel, I'm trying to update the bnx2x driver in Ubuntu trusty (3.13 kernel) release to use the 7.51.10 firmware; can you help me determine which commits need to be backported? Some reference is in Launchpad bug 1454286: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1454286 basically,

for stable: xfrm: Let the flowcache handle its size by default.

Hi David, can you queue commit c386578f1cdb4dac230395a951f88027f64346e3 for stable? Without it, any system with > 16 cpus and a lot of ipsec use, that leaves xfrmN_gc_thresh set to its default, will (eventually) see failures to create new ipsec connections. It fixes commit

for stable: vxlan, gre, geneve: Set a large MTU on ovs-created tunnel devices

Can you queue this 3-commit patch series for stable? 7e059158d57b79159eaf1f504825d19866ef2c42 ("vxlan, gre, geneve: Set a large MTU on ovs-created tunnel devices") 55e5bfb53cff286c1c1ff49f51325dc15c7fea63 ("geneve: Relax MTU constraints") 72564b59ffc438ea103b0727a921aaddce766728 ("vxlan: Relax

Re: ip_rcv_finish() NULL pointer kernel panic

On Thu, Jan 26, 2017 at 1:04 PM, David Miller wrote: > From: Florian Westphal > Date: Thu, 26 Jan 2017 17:24:33 +0100 > >> Eric Dumazet wrote: >>> > Though possibly with different things not setting the "input" function >>> > pointer

Re: net: hang in unregister_netdevice: waiting for lo to become free

On Thu, May 10, 2018 at 2:46 AM, Dmitry Vyukov <dvyu...@google.com> wrote: > On Mon, Apr 16, 2018 at 9:42 PM, Dan Streetman <ddstr...@ieee.org> wrote: >>>>>> On Wed, Feb 21, 2018 at 3:53 PM, Tommi Rantala >>>>>> <tommi.t.rant...@nokia.com&

Re: net: hang in unregister_netdevice: waiting for lo to become free

On Fri, May 11, 2018 at 5:19 AM, Dmitry Vyukov <dvyu...@google.com> wrote: > On Thu, May 10, 2018 at 12:23 PM, Dan Streetman <ddstr...@ieee.org> wrote: >>>>>>>> <tommi.t.rant...@nokia.com> wrote: >>>>>>>>> On 20.02.2018 18:26

[PATCH] net: tcp: close sock if net namespace is exiting

Signed-off-by: Dan Streetman <ddstr...@canonical.com> --- include/net/net_namespace.h | 10 ++ net/ipv4/tcp.c | 3 +++ net/ipv4/tcp_timer.c| 15 +++ 3 files changed, 28 insertions(+) diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h

Re: net: hang in unregister_netdevice: waiting for lo to become free

On Thu, Apr 12, 2018 at 8:15 AM, Dmitry Vyukov wrote: > On Wed, Feb 21, 2018 at 3:53 PM, Tommi Rantala > wrote: >> On 20.02.2018 18:26, Neil Horman wrote: >>> >>> On Tue, Feb 20, 2018 at 09:14:41AM +0100, Dmitry Vyukov wrote: On Tue, Feb

Re: net: hang in unregister_netdevice: waiting for lo to become free

On Mon, Apr 16, 2018 at 3:35 AM, Dmitry Vyukov <dvyu...@google.com> wrote: > On Fri, Apr 13, 2018 at 5:54 PM, Dmitry Vyukov <dvyu...@google.com> wrote: >> On Fri, Apr 13, 2018 at 2:43 PM, Dan Streetman <ddstr...@ieee.org> wrote: >>> On Thu, Apr 12,