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: <2c2d065e.8320.196c8d8f9c0.Coremail.00107082@163.com>
Date: Tue, 13 May 2025 16:53:05 +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:46:39, "Oliver Neukum" <oneukum@...e.com> wrote:
>On 13.05.25 10:23, David Wang wrote:
>
>Hi,
>  > Thanks for reviewing this.  The memory flag thing do raise concern.
>> I think I can make adjustment:  realloc the memory if flag changed.
>
>I am sorry. I have been unclear. Here comes a detailed explanation:
>
>What we call "gfp_t" is a combination of flags. They describe
>
>A - the type of memory (always valid)
>B - the way the memory can be allocated (valid only at a specific time)
>
>The URB is a generic data structure to be processed by the CPU, _not_
>the HC. It is always generic kernel memory. Flags of type A make no sense
>to pass.
>In fact you may not know for which device an URB will be used when you
>allocate it. The only valid mem_flags you can pass to usb_alloc_urb()
>are GFP_KERNEL, GFP_NOIO or GFP_ATOMIC.
>
>If you need to reallocate memory for private data you _must_ use
>the flags passed with usb_submit_urb(). A HCD can modify them by adding
>flags of type A, but you cannot change flags of type B.
>For example, if usb_alloc_urb() used GFP_KERNEL to allocate the URB,
>but uses GFP_ATOMIC in usb_submit_urb(), you will deadlock if you save
>and reuse the GFP_KERNEL.
>
>	HTH
>		Oliver
>  
Thanks for explaining this.   I will adjust code to handle mem_flags changes,
and update soon after I made some tests.

David