linux-kernel - Re: [PATCH v2 1/2] USB: core: add a memory pool to urb for 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: <8c963ad0-a38f-4627-be11-80ccb669d006@rowland.harvard.edu>
Date: Tue, 13 May 2025 10:25:50 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: David Wang <00107082@....com>
Cc: mathias.nyman@...el.com, gregkh@...uxfoundation.org, oneukum@...e.com,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] USB: core: add a memory pool to urb for
 host-controller private data

On Tue, May 13, 2025 at 07:38:17PM +0800, David Wang wrote:
> ---
> Changes:
> 1. Use caller's mem_flags if a larger memory is needed.
> Thanks to Oliver Neukum <oneukum@...e.com>'s review.
> ---
> URB objects have long lifecycle, an urb can be reused between
> enqueue-dequeue 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, several
> minutes of usage of webcam/keyboard/mouse have memory alloc counts:
>   drivers/usb/core/urb.c:75 [usbcore] func:usb_alloc_urb 661
>   drivers/usb/host/xhci.c:1555 [xhci_hcd] func:xhci_urb_enqueue 424863
> Memory allocation frequency for host-controller private data can reach
> ~1k/s and above.
> 
> 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.
> 
> Signed-off-by: David Wang <00107082@....com>

It should be possible to do what you want without touching the USB core 
code at all, changing only xhci-hcd.  That's what Mathias is suggesting.

Instead of having an URB keep ownership of its extra memory after it 
completes, xhci-hcd can put the memory area onto a free list.  Then 
memory areas on the free list can be reused with almost no overhead when 
URBs are enqueued later on.

This idea can become more elaborate if you maintain separate free lists 
for different devices, or even for different endpoints, or sort the free 
list by the size of the memory areas.  But the basic idea is always the 
same: Don't change usbcore (including struct urb), and make getting and 
releasing the extra memory areas have extremely low overhead.

Alan Stern