linux-kernel - Re: [PATCH 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: <4006cec4.794d.196c8be2fd1.Coremail.00107082@163.com>
Date: Tue, 13 May 2025 16:23:49 +0800 (CST)
From: "David Wang" <00107082@....com>
To: "Oliver Neukum" <oneukum@...e.com>
Cc: mathias.nyman@...el.com, gregkh@...uxfoundation.org,
	stern@...land.harvard.edu, surenb@...gle.com,
	kent.overstreet@...ux.dev, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] USB: core: add a memory pool to urb for
 host-controller private data



At 2025-05-13 16:11:20, "Oliver Neukum" <oneukum@...e.com> wrote:
>Hi,
>
>On 13.05.25 07:54, David Wang wrote:
>> 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.
>
>First of all, thank you for trying to tackle this long running issue.
>
>> @@ -77,6 +78,7 @@ struct urb *usb_alloc_urb(int iso_packets, gfp_t mem_flags)
>>   	if (!urb)
>>   		return NULL;
>>   	usb_init_urb(urb);
>> +	urb->hcpriv_mempool_flags = mem_flags;
>
>No. You cannot do this. The flags you pass to usb_alloc_urb()
>depend on the context you call it in. For example, if you are
>allocating it while holding a spinlock, ou need to use GFP_ATOMIC
>
>But that may or may not be the same context you submit the URB in.
>Recording mem_flags here makes no sense.
>
>	Regards
>		Oliver

Thanks for reviewing this.  The memory flag thing do raise concern. 
I think I can make adjustment:  realloc the memory if flag changed.


Thanks
David