[PATCH net] net: usbnet: fix potential deadlock on 32bit hosts

From: Eric Dumazet <eduma...@google.com> Marek reported a LOCKDEP issue occurring on 32bit host, that we tracked down to the fact that usbnet could either run from soft or hard irqs. This patch adds u64_stats_update_begin_irqsave() and u64_stats_update_end_irqrestore() helpers to solve thi

Re: inconsistent lock state with usbnet/asix usb ethernet and xhci

On Mon, 2018-03-05 at 12:46 +0100, Oliver Neukum wrote: > On Mon, 2018-03-05 at 08:45 +0100, Marek Szyprowski wrote: > > Hi Oliver, > > > > On 2018-02-27 17:07, Oliver Neukum wrote: > > > Am Dienstag, den 27.02.2018, 07:13 -0800 schrieb Eric Dumazet: > > &

Re: inconsistent lock state with usbnet/asix usb ethernet and xhci

On Tue, 2018-02-27 at 07:09 -0800, Eric Dumazet wrote: > > Note that for this one, it seems we also could perform stats updates in > BH context, since skb is queued via defer_bh() > > But simplicity wins I guess. Thinking more about this, I am not sure we have any guarantee tha

Re: inconsistent lock state with usbnet/asix usb ethernet and xhci

On Tue, 2018-02-27 at 15:42 +0100, Marek Szyprowski wrote: > Hi Eric, > > On 2018-02-27 15:07, Eric Dumazet wrote: > > On Tue, 2018-02-27 at 08:26 +0100, Marek Szyprowski wrote: > > > I've noticed that USBnet/ASIX AX88772B USB driver produces deplock kernel > > >

Re: inconsistent lock state with usbnet/asix usb ethernet and xhci

On Tue, 2018-02-27 at 08:26 +0100, Marek Szyprowski wrote: > Hi > > I've noticed that USBnet/ASIX AX88772B USB driver produces deplock kernel > warning ("inconsistent lock state") on Chromebook2 Peach-PIT board. No > special activity is needed to reproduce this issue, it happens almost > on every

Re: dvb usb issues since kernel 4.9

On Fri, 2018-01-12 at 19:13 -0200, Mauro Carvalho Chehab wrote: > > > The .config file used to build the Kernel is at: > https://pastebin.com/wpZghann > Hi Mauro Any chance you can try CONFIG_HZ_1000=y, CONFIG_HZ=1000 ? Thanks. -- To unsubscribe from this list: send the line

Re: Re: dvb usb issues since kernel 4.9

On Tue, Jan 9, 2018 at 10:58 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Tue, Jan 9, 2018 at 9:57 AM, Eric Dumazet <eduma...@google.com> wrote: >> >> Your patch considers TASKLET_SOFTIRQ being a candidate for 'immediate >> handling', but TCP

Re: Re: dvb usb issues since kernel 4.9

On Tue, Jan 9, 2018 at 9:48 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Tue, Jan 9, 2018 at 9:27 AM, Eric Dumazet <eduma...@google.com> wrote: >> >> So yes, commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job") has >> show

Re: Re: dvb usb issues since kernel 4.9

On Tue, Jan 9, 2018 at 8:51 AM, Josef Griebichler wrote: > Hi Linus, > > your patch works very good for me and others (please see > https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=77006#post77006). > No errors in recordings

Re: [PATCHv2] net: usbnet: support 64bit stats in qmi_wwan driver

On Fri, 2017-03-24 at 15:42 +1000, Greg Ungerer wrote: > The usbnet core is used by a number of drivers. This patch only > updates the qmi-wwan driver to use stats64. If you remove the > dev->stats.rx_* updates all those other driver users will have > no counts. I see. Then I guess the u64 stuff

Re: [PATCHv2] net: usbnet: support 64bit stats in qmi_wwan driver

On Fri, 2017-03-24 at 11:27 +1000, Greg Ungerer wrote: > Add support for the net stats64 counters to the usbnet core and then to > the qmi_wwan driver. > > This is a strait forward addition of 64bit counters for RX and TX packets > and byte counts. It is done in the same style as for the other

Re: [PATCH] r8152: Allocate interrupt buffer as part of struct r8152

On Tue, 2017-01-31 at 11:06 -0800, Guenter Roeck wrote: > When unloading the r8152 driver using the 'unbind' sysfs attribute > in a system with KASAN enabled, the following error message is seen > on a regular basis. > > static int alloc_all_mem(struct r8152 *tp) > @@ -1423,10 +1420,6 @@

Re: NAPI on USB network drivers

On Wed, 2017-01-25 at 09:39 +, Hayes Wang wrote: > Oliver Neukum [mailto:oneu...@suse.com] > > Sent: Wednesday, January 25, 2017 5:35 PM > [...] > > looking at r8152 I noticed that it uses NAPI. I never considered > > this for the generic USB networking code as you cannot disable > >

Re: [PATCH net v2 3/4] r8152: re-schedule napi for tx

On Wed, 2017-01-25 at 16:13 +0800, Hayes Wang wrote: > Re-schedule napi after napi_complete() for tx, if it is necessay. > > In r8152_poll(), if the tx is completed after tx_bottom() and before > napi_complete(), the scheduling of napi would be lost. Then, no > one handles the next tx until the

Re: [PATCH v3 5/5] net: asix: autoneg will set WRITE_MEDIUM reg

On Thu, 2016-09-01 at 12:47 -0400, Robert Foss wrote: > I'm not quite sure how the first From line was added, it > should not have been. > Grant Grundler is most definitely the author. > > Would you like me to resubmit in v++ and make sure that it has been > corrected? This is too late,

Re: [PATCH v3 5/5] net: asix: autoneg will set WRITE_MEDIUM reg

On Mon, 2016-08-29 at 09:32 -0400, robert.f...@collabora.com wrote: > From: Robert Foss > > From: Grant Grundler > > The miii_nway_restart() causes a PHY link change activity and > ax88772_link_reset will be called. link_reset will set >

Re: [PATCH] lan78xx: Protect runtime_auto check by #ifdef CONFIG_PM

On Sun, 2016-03-20 at 11:43 +0100, Geert Uytterhoeven wrote: > If CONFIG_PM=n: > > drivers/net/usb/lan78xx.c: In function ‘lan78xx_get_stats64’: > drivers/net/usb/lan78xx.c:3274: error: ‘struct dev_pm_info’ has no member > named ‘runtime_auto’ > > If PM is disabled, the runtime_auto

Re: [PATCH net] r8152: drop the tx packet with invalid length

On Fri, 2014-12-19 at 06:42 +, Hayes Wang wrote: Excuse me. I try to implement ndo_gso_check() with kernel 3.18. However, I still get packets with gso and their skb lengths are more than the acceptable one. Do I miss something? +static bool rtl8152_gso_check(struct sk_buff *skb, struct

Re: [PATCH net] r8152: drop the tx packet with invalid length

On Fri, 2014-12-19 at 09:36 -0800, Eric Dumazet wrote: On Fri, 2014-12-19 at 06:42 +, Hayes Wang wrote: Excuse me. I try to implement ndo_gso_check() with kernel 3.18. However, I still get packets with gso and their skb lengths are more than the acceptable one. Do I miss something

Re: [PATCH net-next] r8152: reduce memory copy for rx

On Wed, 2014-12-03 at 13:14 +0800, Hayes Wang wrote: If the data size is more than half of the AGG_BUG_SZ, allocate a new rx buffer and use skb_clone() to avoid the memory copy. The original method is that allocate the memory and copy data for each packet in a rx buffer. The new one is that

Re: [PATCH net-next] r8152: reduce memory copy for rx

On Wed, 2014-12-03 at 07:05 +, Hayes Wang wrote: Eric Dumazet [mailto:eric.duma...@gmail.com] Sent: Wednesday, December 03, 2014 2:08 PM [...] Better performance for what workload exactly ? I test it by using Chariot with 4 Tx and 4 Rx. It has about 4% improvement. Have you tried

Re: [PATCH net] r8152: drop the tx packet with invalid length

On Wed, 2014-11-26 at 17:56 +0800, Hayes Wang wrote: Drop the tx packet which is more than the size of agg_buf_sz. When creating a bridge with the device, we may get the tx packet with TSO and the length is more than the gso_max_size which is set by the driver through netif_set_gso_max_size().

Re: [PATCH net] r8152: drop the tx packet with invalid length

On Wed, 2014-11-26 at 12:06 -0500, David Miller wrote: From: Eric Dumazet eric.duma...@gmail.com Date: Wed, 26 Nov 2014 08:52:28 -0800 On Wed, 2014-11-26 at 17:56 +0800, Hayes Wang wrote: Drop the tx packet which is more than the size of agg_buf_sz. When creating a bridge with the device

Re: [PATCH v1 3/3] usb: gadget: NCM: Stop RX TCP Bursts getting dropped.

was infact ~32KB, which is really insane indeed. After your patch, its back to ~2KB Acked-by: Eric Dumazet eduma...@google.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org

Re: skbuff truesize incorrect.

On Fri, 2014-05-23 at 12:13 +0100, Jim Baxter wrote: What are the side effects of changing the truesize, if the original uncloned skb has the full truesize then isn't the potential memory usage still counted for the avoidance of OOM? Nope. This can be disastrous. A malicious remote peer can

Re: skbuff truesize incorrect.

is already a huge win for a 21Mbps device. Acked-by: Eric Dumazet eduma...@google.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

RE: skbuff truesize incorrect.

On Fri, 2014-05-23 at 15:30 +, David Laight wrote: From: Eric Dumazet ... TCP stack uses fast clones, and current stack gives them a truesize of 2048 + sizeof(sk_buff), while it really should be 2048 + 2*sizeof(sk_buff) Luckily, GSO/TSO tends to reduce the error, as skbs overhead

Re: skbuff truesize incorrect.

On Fri, 2014-05-23 at 08:44 -0700, Rick Jones wrote: If you are measuring performance with the likes of netperf, you should be able to get an idea of the performance effect from the change in service demand (CPU consumed per unit of work) even if the maximum throughput remains capped.

Re: skbuff truesize incorrect.

On Thu, 2014-05-22 at 20:39 +0100, Jim Baxter wrote: I now think that the correct solution here is to create a new smaller skb and copy the data from the sub packets into it. For low speed devices, this is indeed the best way. (this is called copybreak in some nic drivers) -- To

Re: skbuff truesize incorrect.

On Thu, 2014-05-22 at 21:21 +0100, Jim Baxter wrote: OK, so it is the value of the memory that has been allocated for the SKB. If there are multiple clones for an skb all pointing at the same data, will that distort the memory used when they all have the same truesize? Its always better to

Re: skbuff truesize incorrect.

On Thu, 2014-05-22 at 20:07 +0100, Jim Baxter wrote: I have been investigating a network issue with bursts of network traffic over USB CDC-NCM, the issue is that the kernel is dropping packets because sk_rcvqueues_full() returns true due to skb2-truesize is always 32960 instead of

Re: skbuff truesize incorrect.

On Thu, 2014-05-22 at 13:58 -0700, Eric Dumazet wrote: I would set rx_max (rx_urb_size) to SKB_MAX_HEAD(0) so that you do not use high order allocations. Correction, that would need SKB_MAX_HEAD(NET_SKB_PAD + NET_IP_ALIGN), because drivers/net/usb/usbnet.c calls __netdev_alloc_skb_ip_align

Re: [PATCH net,stable] net: cdc_mbim: __vlan_find_dev_deep need rcu_read_lock

On Fri, 2014-05-02 at 23:28 +0200, Bjørn Mork wrote: Fixes this warning introduced by commit 5b8f15f78e6f (net: cdc_mbim: handle IPv6 Neigbor Solicitations): === [ INFO: suspicious RCU usage. ] 3.15.0-rc3 #213 Tainted: GW O

RE: [PATCH net-next 08/12] r8152: support TSO

On Tue, 2014-03-04 at 14:35 +, David Laight wrote: Does that mean you are splitting the 64k 'ethernet packet' from TCP is software? I've looked at the ax88179 where the hardware can do it. Is there really a gain doing segmentation here if you have to do the extra data copy? There is no

Re: [PATCH net-next 08/12] r8152: support TSO

On Tue, 2014-03-04 at 20:01 +0800, Hayes Wang wrote: +static u32 r8152_xmit_frags(struct r8152 *tp, struct sk_buff *skb, u8 *data) +{ + struct skb_shared_info *info = skb_shinfo(skb); + unsigned int cur_frag; + u32 total = skb_headlen(skb); + + memcpy(data, skb-data,

Re: [PATCH net-next 08/12] r8152: support TSO

On Tue, 2014-03-04 at 20:01 +0800, Hayes Wang wrote: Support scatter gather and TSO. - netdev-features |= NETIF_F_RXCSUM | NETIF_F_IP_CSUM; - netdev-hw_features = NETIF_F_RXCSUM | NETIF_F_IP_CSUM; + netdev-features |= NETIF_F_RXCSUM | NETIF_F_IP_CSUM | NETIF_F_SG | +

Re: [PATCH net-next 09/12] r8152: support IPv6

On Tue, 2014-03-04 at 20:01 +0800, Hayes Wang wrote: Support hw IPv6 checksum for TCP and UDP packets. +/* + * r8152_csum_workaround() + * The hw limites the value the transport offset. When the offset is out of the + * range, calculate the checksum by sw. + */ +static void

Re: [PATCH] net: sk == 0xffffffff fix - not for commit

On Thu, 2014-01-16 at 16:21 +0100, Andrzej Pietrasiewicz wrote: W dniu 10.12.2013 15:25, Eric Dumazet pisze: On Tue, 2013-12-10 at 07:55 +0100, Andrzej Pietrasiewicz wrote: W dniu 09.12.2013 16:31, Eric Dumazet pisze: On Mon, 2013-12-09 at 12:47 +0100, Andrzej Pietrasiewicz wrote

Re: [PATCH] net: sk == 0xffffffff fix - not for commit

On Tue, 2013-12-10 at 07:55 +0100, Andrzej Pietrasiewicz wrote: W dniu 09.12.2013 16:31, Eric Dumazet pisze: On Mon, 2013-12-09 at 12:47 +0100, Andrzej Pietrasiewicz wrote: NOT FOR COMMITTING TO MAINLINE. With g_ether loaded the sk occasionally becomes 0x. It happens usually

Re: [PATCH] net: sk == 0xffffffff fix - not for commit

On Mon, 2013-12-09 at 12:47 +0100, Andrzej Pietrasiewicz wrote: NOT FOR COMMITTING TO MAINLINE. With g_ether loaded the sk occasionally becomes 0x. It happens usually after transferring few hundreds of kilobytes to few tens of megabytes. If sk is 0x then dereferencing it

RE: [PATCH] usb: xhci: Link TRB must not occur with a USB payload burst.

On Wed, 2013-11-20 at 09:36 +, David Laight wrote: Ben said the largest number of fragments from the current network stack will be 17, and that none of them will cross 32k boundaries. So the network stack won't send down long SG lists. Please note that skb-head itself _might_ cross a 32K

Re: [PATCH 2/2] net: asix: Move declaration of ax88172a_info to shared header

On Fri, 2013-08-09 at 10:40 -0700, Stephen Hemminger wrote: On Fri, 9 Aug 2013 14:39:06 -0300 Fabio Estevam feste...@gmail.com wrote: On Fri, Aug 9, 2013 at 2:31 PM, Mark Brown broo...@kernel.org wrote: From: Mark Brown broo...@linaro.org Ensure that the definition of ax88172a_info

Re: [PATCH v4 4/4] USBNET: ax88179_178a: enable tso if usb host supports sg dma

urb-sg directly. With the patch, system CPU utilization decreased ~50% and throughput increased by ~10% when doing iperf client test on one ARM A15 dual core board. Cc: Eric Dumazet eric.duma...@gmail.com Cc: Ben Hutchings bhutchi...@solarflare.com Cc: Grant Grundler grund...@google.com

Re: [PATCH v4 3/4] USBNET: support DMA SG

can_dma_sg:1; We try to use unsigned int instead of plain unsigned, but its a minor point and should not block your patches. Apart from this : Reviewed-by: Eric Dumazet eduma...@google.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord

Re: [PATCH v3 4/4] USBNET: ax88179_178a: enable tso if usb host supports sg dma

On Tue, 2013-08-06 at 08:52 +0800, Ming Lei wrote: This patch enables 'can_dma_sg' flag for ax88179_178a device if the attached host controller supports building packet from discontinuous buffers(DMA SG is possible), so TSO can be enabled and skb fragment buffers can be passed to usb stack via

Re: [PATCH 4/4] USBNET: ax88179_178a: enable tso if host supports sg dma

On Thu, 2013-08-01 at 16:10 +0800, Ming Lei wrote: On Thu, Aug 1, 2013 at 1:04 PM, Eric Dumazet eric.duma...@gmail.com wrote: On Thu, 2013-08-01 at 12:41 +0800, Ming Lei wrote: From my trace result, lots of linear SKBs are cloned or header-cloned, so it needs skb copy too

[PATCH net-next] ax88179_178a: avoid copy of tx tcp packets

From: Eric Dumazet eduma...@google.com ax88179_tx_fixup() has quite complex code trying to push 8 bytes of control data (len/mss), but fails to do it properly for TCP packets, incurring an extra copy and point of memory allocation failure. Lets use the simple and approved way. dev

Re: [PATCH net-next] ax88179_178a: avoid copy of tx tcp packets

On Thu, 2013-08-01 at 06:49 -0700, Eric Dumazet wrote: From: Eric Dumazet eduma...@google.com ax88179_tx_fixup() has quite complex code trying to push 8 bytes of control data (len/mss), but fails to do it properly for TCP packets, incurring an extra copy and point of memory allocation

Re: [PATCH 4/4] USBNET: ax88179_178a: enable tso if host supports sg dma

On Thu, 2013-08-01 at 08:30 -0700, Grant Grundler wrote: http://lxr.free-electrons.com/source/include/linux/byteorder/generic.h#L111 http://lxr.free-electrons.com/ident?i=__cpu_to_le32s IIRC, cpu_to_leXX() macros return the endian corrected value. In other words, they need to be assigned to

Re: [PATCH 4/4] USBNET: ax88179_178a: enable tso if host supports sg dma

On Wed, 2013-07-31 at 16:02 +0200, Oliver Neukum wrote: On Wed, 2013-07-31 at 21:50 +0800, Ming Lei wrote: In the usbnet case, the driver already supports non-sg well. Actually, all current drivers should support non-sg well because urb-sg wasn't introduced for very long time. We can

Re: [PATCH 0/4] USB USBNET: loose DMA SG check and support usbnet DMA SG

On Wed, 2013-07-31 at 18:51 +0800, Ming Lei wrote: Hi, This patchset allows drivers to pass sg buffers which size can't be divided by max packet size of endpoint if the host controllers support this kind of sg buffers. Previously we add check[1] on the situation and don't allow these sg

Re: [PATCH 1/1] TX throttling bug-fixing patch of AX88179_178A

On Thu, 2013-07-25 at 13:25 +0800, Ming Lei wrote: On Thu, Jul 25, 2013 at 1:10 PM, Eric Dumazet eric.duma...@gmail.com wrote: On Thu, 2013-07-25 at 10:28 +0800, Ming Lei wrote: It depends if size of sg buffer(except for last one) in the sg list can be divided by usb endpoint's max

Re: [PATCH 1/1] TX throttling bug-fixing patch of AX88179_178A

On Thu, 2013-07-25 at 22:52 +0800, Ming Lei wrote: Maybe need to try it with TSO enabled, in my test on ax88179_178a NIC after applying your disabling TSO patch, tx throughput is less than 600Mbps, but rx is close to 900Mbps. It looks like TCP stack could for this case allocate linear skbs

Re: [PATCH 1/1] TX throttling bug-fixing patch of AX88179_178A

On Thu, 2013-07-25 at 10:28 +0800, Ming Lei wrote: It depends if size of sg buffer(except for last one) in the sg list can be divided by usb endpoint's max packet size(512 or 1024), at least there is the constraint:

Re: [PATCH 1/1] TX throttling bug-fixing patch of AX88179_178A

On Mon, 2013-07-22 at 20:47 +0100, Ben Hutchings wrote: On Mon, 2013-07-22 at 11:47 -0700, Eric Dumazet wrote: On Mon, 2013-07-22 at 19:38 +0100, Ben Hutchings wrote: On Mon, 2013-07-22 at 11:29 -0700, Grant Grundler wrote: On Mon, Jul 22, 2013 at 10:07 AM, Eric Dumazet eric.duma

Re: [PATCH 1/1] TX throttling bug-fixing patch of AX88179_178A

On Tue, 2013-07-23 at 16:46 -0700, David Miller wrote: From: Eric Dumazet eric.duma...@gmail.com Date: Mon, 22 Jul 2013 23:10:27 -0700 On Mon, 2013-07-22 at 20:47 +0100, Ben Hutchings wrote: The real solution would be for someone to add SG support to the usbnet core. Trying to support

Re: [PATCH 1/1] TX throttling bug-fixing patch of AX88179_178A

On Tue, 2013-07-23 at 16:56 -0700, Eric Dumazet wrote: A quick scan shows that smsc75xx, smsc95xx, and ax88179_178a all have this problem. Instead of the patch starting this thread, I'd like to see one that hits all three drivers and removes all SG and TSO features bits from both

[PATCH] usbnet: do not pretend to support SG/TSO

From: Eric Dumazet eduma...@google.com usbnet doesn't support yet SG, so drivers should not advertise SG or TSO capabilities, as they allow TCP stack to build large TSO packets that need to be linearized and might use order-5 pages. This adds an extra copy overhead and possible allocation

Re: [PATCH 1/1] TX throttling bug-fixing patch of AX88179_178A

On Sat, 2013-07-20 at 17:16 +0800, fre...@asix.com.tw wrote: From: Freddy Xin fre...@asix.com.tw Disable TSO and SG network features in reset() and bind() functions, and check the return value of skb_linearize() in tx_fixup() to prevent TX throttling. Signed-off-by: Freddy Xin

Re: [PATCH 1/1] TX throttling bug-fixing patch of AX88179_178A

On Mon, 2013-07-22 at 19:38 +0100, Ben Hutchings wrote: On Mon, 2013-07-22 at 11:29 -0700, Grant Grundler wrote: On Mon, Jul 22, 2013 at 10:07 AM, Eric Dumazet eric.duma...@gmail.com wrote: ... I guess that if a driver does not advertise NETIF_F_SG, this skb_linearize() call

Re: changing usbnet's API to better deal with cdc-ncm

On Thu, 2012-09-06 at 10:50 +0200, Oliver Neukum wrote: On Thursday 06 September 2012 10:13:01 Alexey ORISHKO wrote: Rx path: 4. IP packets are cloned to separate skb and length of actual data set to eth packet size, while skb size is still the same as skb containing full NTB frame. This

Re: changing usbnet's API to better deal with cdc-ncm

On Thu, 2012-09-06 at 11:11 +0200, Eric Dumazet wrote: Really skb_clone() use should be removed from cdc_ncm_rx_fixup() Unless you expect 10Gbit speed from this driver, skb_clone() is the worst possible strategy. Allocating fresh skbs of the right size permits better memory use