Re: [PATCH 4.9-stable] tcp: add tcp_ooo_try_coalesce() helper

On Thu, 2018-08-09 at 14:47 +0200, Greg KH wrote: > On Thu, Aug 09, 2018 at 08:37:13PM +0800, maowenan wrote: > > There are two patches in stable branch linux-4.4, but I have tested with > > below patches, and found that the cpu usage was very high. > > dc6ae4d tcp: detect malicious patterns in

[PATCH 4.9-stable] tcp: add tcp_ooo_try_coalesce() helper

this tracking for skbs in receive queue, since they are not dropped, unless socket is disconnected. Signed-off-by: Eric Dumazet Acked-by: Soheil Hassas Yeganeh Acked-by: Yuchung Cheng Signed-off-by: David S. Miller Signed-off-by: David Woodhouse --- net/ipv4/tcp_input.c | 23

Re: [PATCH net 0/5] tcp: more robust ooo handling

On Sat, 2018-08-04 at 09:05 +0200, Greg KH wrote: > > Ok, then it's my fault :) > > Odds are it did not apply and so I didn't backport it.  If you think it > should be there, please provide a working backport. It has whitespace issues but that's about it. Will send a version which applies

Re: [PATCH net 0/5] tcp: more robust ooo handling

On Mon, 2018-07-23 at 12:03 -0700, David Miller wrote: > From: Eric Dumazet > Date: Mon, 23 Jul 2018 09:28:16 -0700 > > > Juha-Matti Tilli reported that malicious peers could inject tiny > > packets in out_of_order_queue, forcing very expensive calls > > to tcp_collapse_ofo_queue() and

Re: [PATCH] atm: Preserve value of skb->truesize when accounting to vcc

On Sat, 2018-06-16 at 16:27 -0700, David Miller wrote: > From: "David Woodhouse" > Date: Sat, 16 Jun 2018 20:52:33 - > > >> This Fixes tag shoots the messenger really. > >> > >> I suggest to instead use : > >> > >> Fix

Re: [PATCH] atm: Preserve value of skb->truesize when accounting to vcc

> This Fixes tag shoots the messenger really. > > I suggest to instead use : > > Fixes: 158f323b9868 ("net: adjust skb->truesize in pskb_expand_head()") Oh, I hadn't realised how recent that was. Sure, let's blame you instead :) -- dwmw2

Re: [PATCH] atm: Preserve value of skb->truesize when accounting to vcc

>> Commit 14afee4b609 ("net: convert sock.sk_wmem_alloc from atomic_t to >> refcount_t") did exactly what it was intended to do, and turned this >> mostly-theoretical problem into a real one, causing PPPoATM to fail >> immediately as sk_wmem_alloc underflows and atm_may_send() *immediately* >>

Re: [PATCH 07/17] net: convert sock.sk_wmem_alloc from atomic_t to refcount_t

On Sat, 2018-06-16 at 03:44 +, Kevin Darbyshire-Bryant wrote: > > I can confirm that PPPoA with both vc & llc encapsulations work.  > BR2684 with PPPoE and both vc & llc encapsulations also work.  No > nasty messages noted in dmesg. Thanks. >   I’m actually gobsmacked at how tolerant

[PATCH] atm: Preserve value of skb->truesize when accounting to vcc

the ATM_SKB(skb) structure. Then in atm_pop_raw() subtract precisely that value instead of the then-current value of skb->truesize. Fixes: 14afee4b ("net: convert sock.sk_wmem_alloc from atomic_t to refcount_t") Signed-off-by: David Woodhouse Tested-by: Kevin Darbyshire-Bryant ---

Re: [PATCH 07/17] net: convert sock.sk_wmem_alloc from atomic_t to refcount_t

On Fri, 2018-06-15 at 20:49 +, Kevin Darbyshire-Bryant wrote: > > > That does end up being quite hairy. I don't think it's worth doing. > >  > > This should probably suffice to fix it... > >  > > Kevin this is going to conflict with the ifx_atm_alloc_skb() hack in > > the tree you're

Re: [PATCH 07/17] net: convert sock.sk_wmem_alloc from atomic_t to refcount_t

On Fri, 2018-06-15 at 14:44 +0100, David Woodhouse wrote: > > > Or simply use a new field in ATM_SKB(skb) to remember a stable > > truesize used in both sides (add/sub) > > Right, that was my second suggestion ("copy the accounted value..."). > > It's a bit

Re: [PATCH 07/17] net: convert sock.sk_wmem_alloc from atomic_t to refcount_t

On Fri, 2018-06-15 at 06:39 -0700, Eric Dumazet wrote: > > On 06/15/2018 06:27 AM, Eric Dumazet wrote: > > > > > > > > On 06/15/2018 05:29 AM, David Woodhouse wrote: > > > > > > On Fri, 2017-06-30 at 13:08 +0300, Elena Reshetova wrote: > &

Re: [PATCH 07/17] net: convert sock.sk_wmem_alloc from atomic_t to refcount_t

On Fri, 2017-06-30 at 13:08 +0300, Elena Reshetova wrote: > diff --git a/include/linux/atmdev.h b/include/linux/atmdev.h > index c1da539..4d97a89 100644 > --- a/include/linux/atmdev.h > +++ b/include/linux/atmdev.h > @@ -254,7 +254,7 @@ static inline void atm_return(struct atm_vcc *vcc,int >

Re: XDP performance regression due to CONFIG_RETPOLINE Spectre V2

On Fri, 2018-04-13 at 19:26 +0200, Christoph Hellwig wrote: > On Fri, Apr 13, 2018 at 10:12:41AM -0700, Tushar Dave wrote: > > I guess there is nothing we need to do! > > > > On x86, in case of no intel iommu or iommu is disabled, you end up in > > swiotlb for DMA API calls when system has 4G

Re: [pci PATCH v5 3/4] ena: Migrate over to unmanaged SR-IOV support

On Tue, 2018-03-13 at 07:51 -0700, Alexander Duyck wrote: > Actually the suggestion I had from Don Dutile was that we should be > looking at creating a pci-stub like driver specifically for those type > of devices, but without the ability to arbitrarily assign devices. > Basically we have to

Re: [pci PATCH v5 3/4] ena: Migrate over to unmanaged SR-IOV support

On Tue, 2018-03-13 at 09:54 +0100, Christoph Hellwig wrote: > On Tue, Mar 13, 2018 at 08:45:19AM +0000, David Woodhouse wrote: > Because binding to pci-stub means that you'd now enable the simple > SR-IOV for any device bound to PCI stub.  Which often might be the wrong > thing.

Re: [pci PATCH v5 3/4] ena: Migrate over to unmanaged SR-IOV support

On Tue, 2018-03-13 at 09:16 +0100, Christoph Hellwig wrote: > On Tue, Mar 13, 2018 at 08:12:52AM +0000, David Woodhouse wrote: > > > > I'd also *really* like to see a way to enable this for PFs which don't > > have (and don't need) a driver. We seem to have lost that along

Re: [pci PATCH v5 3/4] ena: Migrate over to unmanaged SR-IOV support

On Mon, 2018-03-12 at 10:23 -0700, Alexander Duyck wrote: > > -   .sriov_configure = ena_sriov_configure, > +#ifdef CONFIG_PCI_IOV > +   .sriov_configure = pci_sriov_configure_simple, > +#endif >  }; I'd like to see that ifdef go away, as discussed. I agree that just #define

Re: [RFC PATCH v2] bridge: make it possible for packets to traverse the bridge without hitting netfilter

On Fri, 2018-03-09 at 10:57 -0500, David Miller wrote: > From: David Woodhouse <dw...@infradead.org> > Date: Fri, 09 Mar 2018 15:31:15 + > > > Eschewing a 15% speedup on the basis that "well, even though we've had > > three of these already for a decade, we

Re: [RFC PATCH v2] bridge: make it possible for packets to traverse the bridge without hitting netfilter

On Fri, 2015-03-06 at 17:37 +0100, Florian Westphal wrote: > > > > I did performance measurements in the following way: > > >  > > > Removed those pieces of the packet pipeline that I don't necessarily > > > need one-by-one.  Then measured their effect on small packet > > > performance. > > > 

Re: [PATCH v3 bpf] bpf: introduce BPF_JIT_ALWAYS_ON config

On Tue, 2018-01-09 at 22:39 +0100, Daniel Borkmann wrote: > On 01/09/2018 07:04 PM, Alexei Starovoitov wrote: > > > > The BPF interpreter has been used as part of the spectre 2 attack > > CVE-2017-5715. > > > > A quote from goolge project zero blog: > > "At this point, it would normally be

Re: [PATCH v2 0/2] enable hires timer to timeout datagram socket

On Fri, 2017-09-08 at 10:16 -0700, David Miller wrote: > From: Eduardo Valentin > Date: Fri, 8 Sep 2017 10:04:09 -0700 > > > > > However, this is a clear, the system call, from the net subsystem, > > has changed in behavior across kernel versions. From application / > >

Re: [PATCH net-next v3 2/7] netvsc: fix warnings reported by lockdep

On Fri, 2017-07-28 at 08:59 -0700, Stephen Hemminger wrote: > This includes a bunch of fixups for issues reported by > lockdep. >    * ethtool routines can assume RTNL >    * send is done with RCU lock (and BH disable) >    * avoid refetching internal device struct (netvsc) >  instead pass it

Re: [PATCH v2 0/3] uapi glibc compat: fix musl libc compatibility

On Fri, 2017-04-21 at 15:14 +0200, Hauke Mehrtens wrote: > > On 04/20/2017 10:36 PM, David Miller wrote: > > > > From: David Woodhouse <dw...@infradead.org> > > Date: Thu, 20 Apr 2017 21:14:37 +0100 > > > > > > > > I agree, except I don'

Re: [PATCH v2 0/3] uapi glibc compat: fix musl libc compatibility

On Thu, 2017-04-20 at 16:07 -0400, David Miller wrote: > > I think I have to put the brakes on this patch series, after much > consideration. > > It does not scale if we continually add a hodge-podge of different > ifdef tests to the UAPI headers in order to prevent mutliple > definitions. > >

Re: [PATCH 3/4] uapi glibc compat: Do not check for __USE_MISC

On Sun, 2017-03-12 at 23:00 +0100, Hauke Mehrtens wrote: > __USE_MISC is glibc specific and not available in musl libc. Only do > this check when glibc is used. This fixes a problem with musl libc. > ... > -/* Coordinate with glibc net/if.h header. */ > -#if defined(_NET_IF_H) &&

Re: TCP performance problems - GSO/TSO, MSS, 8139cp related

On Fri, 2016-11-11 at 21:05 +, Russell King - ARM Linux wrote: > > 18:59:38.782818 IP (tos 0x0, ttl 52, id 35619, offset 0, flags [DF], proto > TCP (6), length 60) >     84.xx.xxx.196.61236 > 195.92.253.2.http: Flags [S], cksum 0x88db > (correct), seq 158975430, win 29200, options [mss

Re: [PATCH 1/7] 8139cp: Improve accuracy of cp_interrupt() return, to survive IRQ storms

On Wed, 2015-09-23 at 10:58 -0700, David Miller wrote: > From: David Woodhouse <dw...@infradead.org> > Date: Wed, 23 Sep 2015 09:14:09 +0100 > > > But sure, for now I'll drop this from the series and I can try to > > convince you separately. > > Yes, let's discu

Re: [PATCH RFC 0/3] net: Add driver helper function to determine if checksum is offloadable

On Mon, 2015-10-05 at 16:39 -0700, Tom Herbert wrote: > This patch defines a helper function that drivers can call to check > if it is able to offload the checksum for a particular packet. It occurs to me that by itself, this doesn't actually fix the problem. We'd then need to go over all

Re: [PATCH 2/2] Convert smsc911x to use ACPI as well as DT

On Mon, 2015-10-05 at 17:20 -0700, Charles Garcia-Tobin wrote: > it in ACPI circles > unless we had wider agreement among OSs to use it. AFAIK PRP1 has not > actually been approved yet in the specification forum, and that it in > itself is more of a concern for me,as the code has been pushed

Re: [RFC PATCH] Fix false positives in can_checksum_protocol()

an implementation which is grubbing around in the packet then at least *I* don't have to feel dirty for it... :) -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature

Re: [RFC PATCH] Fix false positives in can_checksum_protocol()

elves; we want the pre-filter. Mainly because we *definitely* don't want drivers calling gso_skb_segment() for themselves in the same situation — see the comment I posted on Friday about the r8169 instance of that. ('Re: [PATCH net-next 3/3] r8169: support IPv6'). -- David

Re: [PATCH net-next 3/3] r8169: support IPv6

> Support the IPv6 hw checksum for RTL8111C and later chips. Note > that the hw has the limitation for the transport offset. The > checksum must be calculated by sw, when the transport offset is > out of the range which the hw accepts. It would be better to implement this check in a

Re: [RFC PATCH] Fix false positives in can_checksum_protocol()

On Mon, 2015-09-28 at 12:37 -0700, Tom Herbert wrote: > I think it's easier to just call skb_checksum_help from the driver > when the packet is actually sent to the device (should be no cost for > late binding). That's true for checksum. Not for things like TSO though, and I wonder if it's worth

Re: [RFC PATCH] Fix false positives in can_checksum_protocol()

IPV6_CSUM device, regardless of whether they're *actually* TCP or UDP packets. That's the problem I'm trying to solve. And then we *can* make full use of the generic checksum offload (I had it working for ICMPv6 at one point: http://lists.openwall.net/netdev/2013/01/14/38 ). -- David Woodhouse

Re: [RFC PATCH] Fix false positives in can_checksum_protocol()

t a bit which says it's *actually* TCP or UDP, not just 'seeded with a pseudo-header'. That's the important distinction for NETIF_F_IP_CSUM vs. NETIF_F_HW_CSUM. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com I

Re: [RFC PATCH] Fix false positives in can_checksum_protocol()

TCP sockets, cleared by encapsulation, also set if appropriate by skb_partial_csum_set(). And then the check in can_checksum_protocol() is trivial and clearly correct. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature

Re: [PATCH v2 RFC] 8139cp: Fix GSO MSS handling

IP instead of only TCP and UDP. I originally couldn't see how to deal with this except by looking at the contents of the packet, which sucked. But I think I've found a somewhat more acceptable approach now: http://lists.openwall.net/netdev/2015/09/25/85 -- David Woodhouse

Re: [PATCH 2/2] Convert smsc911x to use ACPI as well as DT

On Fri, 2015-09-25 at 16:28 +0100, Catalin Marinas wrote: > > This only works as long as they target an existing driver with prior DT > support (usually with reviewed bindings). If they have a new driver and > only ACPI in mind, I'm pretty sure we'll end up with new insane things. > That's why we

[RFC PATCH] Fix false positives in can_checksum_protocol()

check in can_checksum_protocol() would just check for that bit. Signed-off-by: David Woodhouse <david.woodho...@intel.com> --- Since can_checksum_protocol is inline, the compiler ought to know that it doesn't even need to dereference skb->sk in the case where the device has the NETIF_F_GEN_C

Re: [PATCH v2] Fix AF_PACKET ABI breakage in 4.2

e with me. If I'm going to define my own accessors, I'd probably just make them use (__force __virtio16). But TBH none of the options seemed particularly pretty to me. I can live with what we have. -- David WoodhouseOpen Source Technology Centre d

[PATCH v2 RFC] 8139cp: Fix GSO MSS handling

are. Then we can stop the masking in cp_start_xmit(), and just WARN if the maximum is exceeded, which should now never happen. Finally, Francois Romieu noticed that we didn't even have the right value for MSSMask anyway; it should be 0x7ff (11 bits) not 0xfff. Signed-off-by: David Woodhouse <david.

Re: [PATCH 2/2] Convert smsc911x to use ACPI as well as DT

Hi Catalin, I understand your concerns, but I'm still not convinced of your conclusion. On Thu, 2015-09-24 at 11:31 +0100, Catalin Marinas wrote: > PRP0001 opens the door to any DT-like properties in ACPI and, knowing > how the ARM ecosystem works, I'm pretty sure we'll soon lose control (if >

[PATCH WTF] 8139cp: Fix GSO MSS handling

rst place. Finally, Francois Romieu noticed that we didn't even have the right value for MSSMask anyway; it should be 0x7ff (11 bits) not 0xfff. Signed-off-by: David Woodhouse <david.woodho...@intel.com> --- Nice and simple and obvious, right? So why does it stop TSO from happening at all

Re: [PATCH 2/2] Convert smsc911x to use ACPI as well as DT

On Wed, 2015-09-23 at 16:56 -0700, Hanjun Guo wrote: > > It really depends on the people who writing the ASL code (DSDT), > I'm not sure if Windows will use _DSD and how to use it, but > firmware guys may just use the device ID to make the firmware > to be usable both by Linux and Windows, and

Re: [PATCH v2 RFC] 8139cp: Fix GSO MSS handling

On Thu, 2015-09-24 at 05:05 -0700, Eric Dumazet wrote: > > Right, netif_skb_features() only has the following checks : > > if (gso_segs > dev->gso_max_segs || gso_segs < dev->gso_min_segs) > features &= ~NETIF_F_GSO_MASK; > > But now we have .ndo_features_check() we could remove this

Re: [PATCH 2/2] Convert smsc911x to use ACPI as well as DT

On Thu, 2015-09-24 at 15:01 +0100, Lorenzo Pieralisi wrote: > On Thu, Sep 24, 2015 at 12:52:38PM +0100, David Woodhouse wrote: > > [...] > > > And think about it... we *really* don't want a given peripheral device > > to have *different* bindings depending on

Re: [PATCH 2/2] Convert smsc911x to use ACPI as well as DT

On Thu, 2015-09-24 at 16:15 +0100, Catalin Marinas wrote: > With "PRP0001", they can skip the _DSD properties review process (not > that they bother much currently) as long as the existing DT support > covers their needs. So no change there then. I take it the smsc911x bindings didn't go through

[PATCH] Fix AF_PACKET ABI breakage in 4.2

ro and use that throughout the code instead of the hard-coded 'false' for little-endian. This restores the ABI to match 4.1 and earlier kernels, and makes my test program work again. Signed-off-by: David Woodhouse <david.woodho...@intel.com> --- Or perhaps we should just use (__force u

Re: [RFC PATCH 1/3] Avoid making inappropriate requests of NETIF_F_V[46]_CSUM devices

On Mon, 2015-09-21 at 17:29 +0100, David Woodhouse wrote: > > Did we ever resolve this? AFAICT from inspecting the code the > virtio_net device still advertises hardware csum capabilities to the > guest. And accepts packets which need checksumming, calling > skb_partial_csum_set()

[PATCH v2] Fix AF_PACKET ABI breakage in 4.2

ro and use that throughout the code instead of the hard-coded 'false' for little-endian. This restores the ABI to match 4.1 and earlier kernels, and makes my test program work again. Signed-off-by: David Woodhouse <david.woodho...@intel.com> --- On Wed, 2015-09-23 at 11:09 -0700, Da

Re: [PATCH 2/2] Convert smsc911x to use ACPI as well as DT

On Wed, 2015-08-12 at 17:06 -0500, Jeremy Linton wrote: > > > +static const struct acpi_device_id smsc911x_acpi_match[] = { > + { "ARMH9118", 0 }, > + { } > +}; > +MODULE_DEVICE_TABLE(acpi, smsc911x_acpi_match); > + > static struct platform_driver smsc911x_driver = { >

[PATCH 3/7] 8139cp: Fix TSO/scatter-gather descriptor setup

From: David Woodhouse <david.woodho...@intel.com> When sending a TSO frame in multiple buffers, we were neglecting to set the first descriptor up in TSO mode. Signed-off-by: David Woodhouse <david.woodho...@intel.com> --- drivers/net/ethernet/realtek/8139cp.c | 22 ++

[PATCH 1/7] 8139cp: Do not re-enable RX interrupts in cp_tx_timeout()

From: David Woodhouse <david.woodho...@intel.com> If an RX interrupt was already received but NAPI has not yet run when the RX timeout happens, we end up in cp_tx_timeout() with RX interrupts already disabled. Blindly re-enabling them will cause an IRQ storm. (This is made particularly

[PATCH 4/7] 8139cp: Reduce duplicate csum/tso code in cp_start_xmit()

From: David Woodhouse <david.woodho...@intel.com> We calculate the value of the opts1 descriptor field in three different places. With two different behaviours when given an invalid packet to be checksummed — none of them correct. Sort that out. Signed-off-by: David Woodhouse <dav

[PATCH 5/7] 8139cp: Fix DMA unmapping of transmitted buffers

From: David Woodhouse <david.woodho...@intel.com> The low 16 bits of the 'opts1' field in the TX descriptor are supposed to still contain the buffer length when the descriptor is handed back to us. In practice, at least on my hardware, they don't. So stash the original value of the opts1

[PATCH 7/7] 8139cp: Enable offload features by default

From: David Woodhouse <david.woodho...@intel.com> I fixed TSO. Hardware checksum and scatter/gather also appear to be working correctly both on real hardware and in QEMU's emulation. Let's enable them by default and see if anyone screams... Signed-off-by: David Woodhouse <dav

[PATCH 6/7] 8139cp: Dump contents of descriptor ring on TX timeout

From: David Woodhouse <david.woodho...@intel.com> We are seeing unexplained TX timeouts under heavy load. Let's try to get a better idea of what's going on. Signed-off-by: David Woodhouse <david.woodho...@intel.com> --- drivers/net/ethernet/realtek/8139cp.c | 14 +- 1

[PATCH 2/7] 8139cp: Fix tx_queued debug message to print correct slot numbers

From: David Woodhouse <david.woodho...@intel.com> After a certain amount of staring at the debug output of this driver, I realised it was lying to me. Signed-off-by: David Woodhouse <david.woodho...@intel.com> --- drivers/net/ethernet/realtek/8139cp.c | 15 --- 1 fil

Re: [PATCH 1/7] 8139cp: Improve accuracy of cp_interrupt() return, to survive IRQ storms

On Tue, 2015-09-22 at 16:45 -0700, David Miller wrote: > And if we are getting Rx* interrupts with napi_schedule_prep() > returning false, that's a serious problem. It can mean that the TX > timeout handler's resetting of the chip is either miscoded or is > racing with either NAPI polling or this

Re: [PATCH 1/7] 8139cp: Improve accuracy of cp_interrupt() return, to survive IRQ storms

On Wed, 2015-09-23 at 10:58 -0700, David Miller wrote: > From: David Woodhouse <dw...@infradead.org> > Date: Wed, 23 Sep 2015 09:14:09 +0100 > > > But sure, for now I'll drop this from the series and I can try to > > convince you separately. > > Yes, let's discu

[PATCH] 8139cp: Set GSO max size and enforce it

() so it shouldn't happen in the first place. Signed-off-by: David Woodhouse <david.woodho...@intel.com> --- drivers/net/ethernet/realtek/8139cp.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/realtek/8139cp.c b/drivers/net/ethernet/r

Re: [PATCH 1/7] 8139cp: Improve accuracy of cp_interrupt() return, to survive IRQ storms

re can handle, and never telling the net stack that that's our maximum, doesn't seem like such a good idea... I think I really am going to stop looking now :) -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com

Re: [PATCH 2/2] Convert smsc911x to use ACPI as well as DT

On Wed, 2015-09-23 at 22:51 +0200, Rafael J. Wysocki wrote: > > But if the device ID is assigned already, why would it hurt to > actually use it? It doesn't hurt at all, as long as we understand that there was no need to assign it a device ID at all, at least for Linux's benefit. And as long as

Re: [PATCH 1/7] 8139cp: Improve accuracy of cp_interrupt() return, to survive IRQ storms

On Thu, 2015-09-24 at 00:44 +0200, Francois Romieu wrote: > David Woodhouse <dw...@infradead.org> : > [...] > > I can shuffle things around if you disagree, but assuming Francois > > concurs I'd suggest merging patches 1-6 (or just pulling from > > git://git.i

Re: [PATCH 1/7] 8139cp: Improve accuracy of cp_interrupt() return, to survive IRQ storms

On Thu, 2015-09-24 at 00:44 +0200, Francois Romieu wrote: > David Woodhouse <dw...@infradead.org> : > [...] > > But sure, for now I'll drop this from the series and I can try to > > convince you separately. > > You may as well change the IRQ storm avoidance logic

[PATCH 2/7] 8139cp: Do not re-enable RX interrupts in cp_tx_timeout()

From: David Woodhouse <david.woodho...@intel.com> If an RX interrupt was already received but NAPI has not yet run when the RX timeout happens, we end up in cp_tx_timeout() with RX interrupts already disabled. Blindly re-enabling them will cause an IRQ storm. This is somewhat less painfu

[PATCH 1/7] 8139cp: Improve accuracy of cp_interrupt() return, to survive IRQ storms

From: David Woodhouse <david.woodho...@intel.com> The TX timeout handling has been observed to trigger RX IRQ storms. And since cp_interrupt() just keeps saying that it handled the interrupt, the machine then dies. Fix the return value from cp_interrupt(), and the offending IRQ gets di

Re: [PATCH 2/2] 8139cp: Call __cp_set_rx_mode() from cp_tx_timeout()

On Sun, 2015-09-20 at 22:24 -0700, David Miller wrote: > From: David Woodhouse <dw...@infradead.org> > Date: Fri, 18 Sep 2015 00:21:54 +0100 > > > Unless we reset the RX config, on real hardware I don't seem to > receive > > any packets after a TX timeout. > >

Re: [RFC PATCH 1/3] Avoid making inappropriate requests of NETIF_F_V[46]_CSUM devices

On Wed, 2013-01-16 at 18:00 -0500, David Miller wrote: > From: David Woodhouse <dw...@infradead.org> > Date: Wed, 16 Jan 2013 22:34:18 + > > > On Wed, 2013-01-16 at 15:54 -0500, David Miller wrote: > >> > >> My opinion on this is that t

Re: [PATCH 2/2] 8139cp: Call __cp_set_rx_mode() from cp_tx_timeout()

On Mon, 2015-09-21 at 14:59 +0100, David Woodhouse wrote: > After which, I think we might be able to turn on TX checksumming by > default and I also have a way to implement early detection of the TX > stall I've been seeing. This is a patch I've been playing with to catch the TX sta

[PATCH 7/7] 8139cp: Avoid gratuitous writes to TxPoll register when already running

From: David Woodhouse <david.woodho...@intel.com> This is a minor optimisation, but as a side-effect it means we can know precisely which descriptors were already in the ring when we last prodded it to run. This will give us a better chance to catch the case where we get a TxEmpty interrup

[PATCH 6/7] 8139cp: Dump contents of descriptor ring on TX timeout

From: David Woodhouse <david.woodho...@intel.com> We are seeing unexplained TX timeouts under heavy load. Let's try to get a better idea of what's going on. Signed-off-by: David Woodhouse <david.woodho...@intel.com> --- drivers/net/ethernet/realtek/8139cp.c | 14 +- 1

[PATCH 3/7] 8139cp: Fix tx_queued debug message to print correct slot numbers

From: David Woodhouse <david.woodho...@intel.com> After a certain amount of staring at the debug output of this driver, I realised it was lying to me. Signed-off-by: David Woodhouse <david.woodho...@intel.com> --- drivers/net/ethernet/realtek/8139cp.c | 15 --- 1 fil

[PATCH 4/7] 8139cp: Fix TSO/scatter-gather descriptor setup

From: David Woodhouse <david.woodho...@intel.com> When sending a TSO frame in multiple buffers, we were neglecting to set the first descriptor up in TSO mode. Signed-off-by: David Woodhouse <david.woodho...@intel.com> --- drivers/net/ethernet/realtek/8139cp.c | 23 +++---

Re: [PATCH 1/7] 8139cp: Improve accuracy of cp_interrupt() return, to survive IRQ storms

On Mon, 2015-09-21 at 22:25 +0200, Francois Romieu wrote: > David Woodhouse <dw...@infradead.org> : > > From: David Woodhouse <david.woodho...@intel.com> > > > > The TX timeout handling has been observed to trigger RX IRQ storms. And > > since cp_interr

Re: [PATCH 7/7] 8139cp: Avoid gratuitous writes to TxPoll register when already running

On Mon, 2015-09-21 at 22:54 +0200, Francois Romieu wrote: > David Woodhouse <dw...@infradead.org> : > [...] > > I'm actually having second thoughts about this one since realising that > > QEMU doesn't implement it correctly. The workaround isn't *that* horrid > >

Re: [PATCH 4/7] 8139cp: Fix TSO/scatter-gather descriptor setup

On Mon, 2015-09-21 at 23:01 +0200, Francois Romieu wrote: > Can you pile a patch to replace BUG with WARN_ON_ONCE(1) ? OK. I can probably contrive a userspace program using AF_PACKET and PACKET_VNET_HDR to trigger it, too¹ :) -- dwmw2 ¹ http://comments.gmane.org/gmane.linux.network/254981

Re: [PATCH 4/7] 8139cp: Fix TSO/scatter-gather descriptor setup

viours when given an invalid packet to be checksummed — none of them correct. Sort that out. Signed-off-by: David Woodhouse <david.woodho...@intel.com> --- drivers/net/ethernet/realtek/8139cp.c | 61 --- 1 file changed, 20 insertions(+), 41 deletions(-) diff --g

Re: [PATCH net 2/2] 8139cp: reset BQL when ring tx ring cleared

On Fri, 2015-09-18 at 02:04 +0100, David Woodhouse wrote: > On Fri, 2015-09-18 at 01:44 +0200, Francois Romieu wrote: > > The TxDmaOkLowDesc register may tell if the Tx dma part is still > > making any progress. I have added a TxPoll request. See below. > > I've just added t

Re: [PATCH net 2/2] 8139cp: reset BQL when ring tx ring cleared

On Fri, 2015-09-18 at 01:44 +0200, Francois Romieu wrote: > The TxDmaOkLowDesc register may tell if the Tx dma part is still > making any progress. I have added a TxPoll request. See below. It isn't making any progress. And TxPoll doesn't help. The only thing I've found that restarts it is to

[PATCH 4/2] 8139cp: Do not re-enable RX interrupts in cp_tx_timeout()

value from cp_interrupt(), but still suboptimal. Unconditionally leave RX interrupts disabled after the reset, and schedule NAPI to check the receive ring and re-enable them. Signed-off-by: David Woodhouse <david.woodho...@intel.com> --- It might seem a little odd to deliberately schedule NAP

[PATCH 3/2] 8139cp: Improve accuracy of cp_interrupt() return, to survive IRQ storms

dev_completed_queue(cp->dev, pkts_compl, bytes_compl); if (TX_BUFFS_AVAIL(cp) > (MAX_SKB_FRAGS + 1)) netif_wake_queue(cp->dev); + + return handled; } static inline u32 cp_tx_vlan_tag(struct sk_buff *skb) -- 2.4.3 -- David Woodhouse

Re: [PATCH net 2/2] 8139cp: reset BQL when ring tx ring cleared

fused that it dies on *unlock*. _raw_spin_lock_irqrestore+0xa is the instruction after a 'popf', which makes me wonder if it dies in an IRQ storm. Although then *some* of the NMI watchdog invocations would surely show an IRQ on the stack, but they don't; they're all right on the same instruction.

Re: [PATCH net 2/2] 8139cp: reset BQL when ring tx ring cleared

92.130412] [] ? common_interrupt+0x29/0x30 [ 292.130412] [] ? remove_waiter+0x11b/0x120 [ 292.130412] [] ? _raw_spin_unlock_irqrestore+0xa/0x10 [ 292.130412] [] ? cp_tx_timeout+0x1a5/0x1c0 [8139cp] -- David

Re: [PATCH net] ipv6: ip6_fragment: fix headroom tests and skb leak

On Wed, 2015-09-16 at 17:26 +0200, Florian Westphal wrote: > I tested this e1000 driver hacked to not allocate additional headroom > (we end up in slowpath, since LL_RESERVED_SPACE is 16). And it works on the originally-offending setup too; thanks. Tested-by: David Woodhouse <dav

Re: [PATCH net 2/2] 8139cp: reset BQL when ring tx ring cleared

On Thu, 2015-09-17 at 12:36 +0100, David Woodhouse wrote: > > Thanks; I'll try that. In fact since updating to 4.2 the problem has > got worse — now the whole machine dies: There is something very strange going on here. I've found two ways to make it stop crashing when cp_tx_timeo

Re: [PATCH net 2/2] 8139cp: reset BQL when ring tx ring cleared

On Thu, 2015-09-17 at 22:44 +0200, Francois Romieu wrote: > David Woodhouse <dw...@infradead.org> : > > On Thu, 2015-09-17 at 12:36 +0100, David Woodhouse wrote: > > > > > > Thanks; I'll try that. In fact since updating to 4.2 the problem has > > &

Re: [PATCH net 2/2] 8139cp: reset BQL when ring tx ring cleared

On Fri, 2015-09-18 at 01:44 +0200, Francois Romieu wrote: > The TxDmaOkLowDesc register may tell if the Tx dma part is still > making any progress. I have added a TxPoll request. See below. I've just added that into the original TX timeout handler, since that doesn't seem to be crashing the box

[PATCH 1/2] 8139cp: Use dev_kfree_skb_any() instead of dev_kfree_skb() in cp_clean_rings()

This can be called from cp_tx_timeout() with interrupts disabled. Spotted by Francois Romieu <rom...@fr.zoreil.com> Signed-off-by: David Woodhouse <david.woodho...@intel.com> --- drivers/net/ethernet/realtek/8139cp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --g

[PATCH 2/2] 8139cp: Call __cp_set_rx_mode() from cp_tx_timeout()

Unless we reset the RX config, on real hardware I don't seem to receive any packets after a TX timeout. Signed-off-by: David Woodhouse <david.woodho...@intel.com> --- Now it does actually recover from the TX timeout, lots of the time. Sometimes it still hits that IRQ storm, which pr

Re: [PATCH] solos-pci: Increase headroom on received packets

On Wed, 2015-09-16 at 03:53 -0700, Eric Dumazet wrote: > You should use netdev_alloc_skb() : This helper is better for rx skbs, > as it allows for better packing of frames in GRO or TCP stack. OK, thanks. I don't have a netdev (this is an ATM device) but I can use dev_alloc_skb(). > Also

Re: IPv6 routing/fragmentation panic

ags to indicate *what* kind of torture is permissible in certain locations). And see what breaks... -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature

[PATCH] solos-pci: Increase headroom on received packets

— it means that *every* incoming packet is going to be need to be reallocated. So let's fix that. Signed-off-by: David Woodhouse <david.woodho...@intel.com> --- Tested in the DMA code path; I don't believe the DMA-capable devices can still be used in MMIO mode. Simon, Guy, would you be able t

[PATCH v2] solos-pci: Increase headroom on received packets

— it means that *every* incoming packet is going to be need to be reallocated. So let's fix that. Signed-off-by: David Woodhouse <david.woodho...@intel.com> --- diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c index 74e18b0..3d7fb65 100644 --- a/drivers/atm/solos-pci.c +++ b/drivers/atm

Re: IPv6 routing/fragmentation panic

On Wed, 2015-09-16 at 15:27 +0200, Florian Westphal wrote: > @@ -599,7 +600,7 @@ int ip6_fragment(struct sock *sk, struct sk_buff > *skb, > /* Correct geometry. */ > if (frag->len > mtu || > ((frag->len & 7) && frag->next)

Re: IPv6 routing/fragmentation panic

On Wed, 2015-09-16 at 15:27 +0200, Florian Westphal wrote: > > David, could you test this? I'd do an official patch submission > then. Compiles. Doesn't fix the problem. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature

Re: [PATCH RFC] solos-pci: Fix BUG() with shared skb

On Wed, 2013-09-04 at 21:41 +0100, David Woodhouse wrote: > On Wed, 2013-09-04 at 14:30 -0400, David Miller wrote: > > skb_realloc_headroom() should do everything you need. > > Great, thanks! Something like this then... ? > > diff --git a/drivers/atm/solos-pci.c b/drivers/at

IPv6 routing/fragmentation panic

re are they documented? Or is this a bug in the IPv6 fragmentation code, to make such assumptions? I'm not entirely sure how to interpret the above stack trace. Is the incoming IPv6 packet being reassembled for netfilter's benefit, then re -fragmented for transmission? -- David Woodhous

Re: [PATCH net 2/2] 8139cp: reset BQL when ring tx ring cleared

On Mon, 2013-05-20 at 17:27 -0700, Stephen Hemminger wrote: > On Mon, 20 May 2013 23:37:28 +0200 > Francois Romieu wrote: > > > cp_stop_hw includes netdev_reset_queue. > > > > You have imho exhibited a start_xmit after cp_stop_hw race - not sure if > > it happens in

  1   2   >