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 for Android: free password hash cracker in your pocket

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

Message-ID: <110b763e-30c3-4e2a-b06c-339e086a48fd@rowland.harvard.edu>
Date: Tue, 13 May 2025 15:46:41 -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 Wed, May 14, 2025 at 02:48:21AM +0800, David Wang wrote:
> It is not an "extra" memory area,  the memory is needed by HC anyway, the memory pool just cache it.
> And about not freeing memory until URB released,  you seems forgot that we are talking 
> about "memory pool" .  A URB only used once could be considered a memory pool never used.
> 
> If your memory pool approach would not  "waste" memory, I would  rather happy to learn.

Here's a simple example to illustrate the point.  Suppose a driver uses 
two URBs, call them A and B, but it never has more than one URB active 
at a time.  Thus, when A completes B is submitted, and when B completes 
A is submitted.

With your approach A and B each have their own memory area.  With my 
approach, a single memory area is shared between A and B.  Therefore my 
approach uses less total memory.

Now, I admit this pattern is probably not at all common.  Usually if a 
driver is going to reuse an URB, it resubmits the URB as soon as the URB 
completes rather than waiting for some other URB to complete.  Drivers 
generally don't keep many unused URBs just sitting around -- although 
there may be exceptions, like a driver for a media device when the 
device isn't running.

> I want to mention the purpose of this patch again:  
> A lot of "private data" allocation could be avoided if  we use a "mempool" to cache and reuse those memory.
> And use URB as the holder is a very simple way to implement this,. 
> 
> And to add , base on my memory profiling, URB usage is very efficient. I think it is a very good candidate to hold
> private data cache for HCs.

All right.  I withdraw any objection to your patches.

Alan Stern