linux-kernel - Re: [PATCH v3 1/2] USB: core: add a memory pool to urb caching host-controller private data

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]

Message-ID: <e6f782db-5818-4d6c-99e0-bcf300fc5b4f@intel.com>
Date: Wed, 21 May 2025 15:28:17 +0300
From: Mathias Nyman <mathias.nyman@...el.com>
To: David Wang <00107082@....com>, gregkh@...uxfoundation.org
Cc: oneukum@...e.com, stern@...land.harvard.edu, linux-usb@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/2] USB: core: add a memory pool to urb caching
 host-controller private data

On 17.5.2025 11.38, David Wang wrote:
> ---
> Changes since v2:
> 1. activat the pool only when the urb object is created via
> usb_alloc_urb()
> Thanks to Oliver Neukum <oneukum@...e.com>'s review.
> ---
> URB objects have long lifecycle, an urb can be reused between
> submit loops; The private data needed by some host controller
> has very short lifecycle, the memory is alloced when enqueue, and
> released when dequeue. For example, on a system with xhci, in
> xhci_urb_enqueue:
> Using a USB webcam would have ~250/s memory allocation;
> Using a USB mic would have ~1K/s memory allocation;
> 
> High frequent allocations for host-controller private data can be
> avoided if urb take over the ownership of memory, the memory then shares
> the longer lifecycle with urb objects.
> 
> Add a mempool to urb for hcpriv usage, the mempool only holds one block
> of memory and grows when larger size is requested.
> 
> The mempool is activated only when the URB object is created via
> usb_alloc_urb() in case some drivers create a URB object by other
> means and manage it lifecycle without corresponding usb_free_urb.

Won't this still allocate a lot of unnecessary memory for the roothub urbs?
i.e. the ones queued with rh_urb_enqueue(hcd, urb).
The host drivers don't use the urb->hcpriv of those URBs.

This would be the roothub status URB, and every hub request sent
during device enumeration for devices connected to the roothub.

Is this whole URB hcpriv mempool addition an actual issue that needs fixing?

If yes then I still think it's better to do it in the host driver like I
described earlier. I don't think it will be too complex

Thanks
-Mathias