netdev - Re: [PATCH net-next 0/7] Polling be gone on LAN95xx

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 2 May 2022 22:33:06 +0200
From:   Ferry Toth <fntoth@...il.com>
To:     Lukas Wunner <lukas@...ner.de>,
        Steve Glendinning <steve.glendinning@...well.net>,
        UNGLinuxDriver@...rochip.com, Oliver Neukum <oneukum@...e.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>
Cc:     netdev@...r.kernel.org, linux-usb@...r.kernel.org,
        Andre Edich <andre.edich@...rochip.com>,
        Oleksij Rempel <o.rempel@...gutronix.de>,
        Martyn Welch <martyn.welch@...labora.com>,
        Gabriel Hojda <ghojda@...urs.ro>,
        Christoph Fritz <chf.fritz@...glemail.com>,
        Lino Sanfilippo <LinoSanfilippo@....de>,
        Philipp Rosenberger <p.rosenberger@...bus.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        Russell King <linux@...linux.org.uk>
Subject: Re: [PATCH net-next 0/7] Polling be gone on LAN95xx


Hi,
Op 27-04-2022 om 07:48 schreef Lukas Wunner:
> Do away with link status polling on LAN95XX USB Ethernet
> and rely on interrupts instead, thereby reducing bus traffic,
> CPU overhead and improving interface bringup latency.
> 
> The meat of the series is in patch [5/7].  The preceding and
> following patches are various cleanups to prepare for and
> adjust to interrupt-driven link state detection.
> 
> Please review and test.  Thanks!
> 
> Lukas Wunner (7):
>    usbnet: Run unregister_netdev() before unbind() again
>    usbnet: smsc95xx: Don't clear read-only PHY interrupt
>    usbnet: smsc95xx: Don't reset PHY behind PHY driver's back
>    usbnet: smsc95xx: Avoid link settings race on interrupt reception
>    usbnet: smsc95xx: Forward PHY interrupts to PHY driver to avoid
>      polling
>    net: phy: smsc: Cache interrupt mask
>    net: phy: smsc: Cope with hot-removal in interrupt handler
> 
>   drivers/net/phy/smsc.c         |  28 +++---
>   drivers/net/usb/asix_devices.c |   6 +-
>   drivers/net/usb/smsc95xx.c     | 155 ++++++++++++++++-----------------
>   drivers/net/usb/usbnet.c       |   6 +-
>   4 files changed, 91 insertions(+), 104 deletions(-)
> 

Tested-by: Ferry Toth <fntoth@...il.com> (Intel Edison-Arduino)

(linux v5.17 + the series + usbnet: smsc95xx: Fix deadlock on runtime 
resume)

While testing I noted another problem. I have "DMA-API: debugging 
enabled by kernel config" and this (I guess) shows me before and after 
the patches:

------------[ cut here ]------------
DMA-API: xhci-hcd xhci-hcd.1.auto: cacheline tracking EEXIST, 
overlapping mappings aren't supported
WARNING: CPU: 0 PID: 24 at kernel/dma/debug.c:570 add_dma_entry+0x1d9/0x270
Modules linked in: mmc_block extcon_intel_mrfld sdhci_pci cqhci sdhci 
led_class mmc_core intel_soc_pmic_mrfld btrfs libcrc32c xor zlib_deflate 
raid6_pq zstd_c>
CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 5.17.0-edison-acpi-standard #1
Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 
2015.01.21:18.19.48
Workqueue: usb_hub_wq hub_event
RIP: 0010:add_dma_entry+0x1d9/0x270
Code: ff 0f 84 97 00 00 00 4c 8b 67 50 4d 85 e4 75 03 4c 8b 27 e8 29 a4 
52 00 48 89 c6 4c 89 e2 48 c7 c7 78 9d 7e 98 e8 b3 f7 b6 00 <0f> 0b 48 
85 ed 0f 85 d3 >
RSP: 0018:ffffb2ce000d7ad0 EFLAGS: 00010286
RAX: 0000000000000000 RBX: 00000000ffffffff RCX: 0000000000000000
RDX: 0000000000000001 RSI: 00000000ffffffea RDI: 00000000ffffffff
RBP: ffff9dea81239a00 R08: ffffffff98b356c8 R09: 00000000ffffdfff
R10: ffffffff98a556e0 R11: ffffffff98a556e0 R12: ffff9dea87397180
R13: 0000000000000001 R14: 0000000000000206 R15: 0000000000046c59
FS:  0000000000000000(0000) GS:ffff9deabe200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005595807522e0 CR3: 0000000006be2000 CR4: 00000000001006f0
Call Trace:
  <TASK>
  dma_map_page_attrs+0xfc/0x240
  ? usb_hcd_link_urb_to_ep+0x6e/0xa0
  ? preempt_count_add+0x63/0x90
  usb_hcd_map_urb_for_dma+0x3f3/0x580
  usb_hcd_submit_urb+0x93/0xb90
  ? _raw_spin_lock+0xe/0x30
  ? _raw_spin_unlock+0xd/0x20
  ? usb_hcd_link_urb_to_ep+0x6e/0xa0
  ? prepare_transfer+0xff/0x140
  usb_start_wait_urb+0x60/0x160
  usb_control_msg+0xdc/0x140
  hub_ext_port_status+0x82/0x100
  hub_event+0x1b2/0x1880
  ? hub_activate+0x59c/0x880
  process_one_work+0x1d3/0x3a0
  worker_thread+0x48/0x3c0
  ? rescuer_thread+0x380/0x380
  kthread+0xe2/0x110
  ? kthread_complete_and_exit+0x20/0x20
  ret_from_fork+0x22/0x30
  </TASK>
---[ end trace 0000000000000000 ]---
DMA-API: Mapped at:
  debug_dma_map_page+0x60/0xf0
  dma_map_page_attrs+0xfc/0x240
  usb_hcd_map_urb_for_dma+0x3f3/0x580
  usb_hcd_submit_urb+0x93/0xb90
  usb_start_wait_urb+0x60/0x160
usb 1-1.1: new high-speed USB device number 3 using xhci-hcd
usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00, 
bcdDevice= 2.00
usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1.1: Product: LAN9514
usb 1-1.1: Manufacturer: SMSC
usb 1-1.1: SerialNumber: 00951d0d

Any ideas on this?