linux-kernel - Re: [PATCH v3 0/3] nvme_map_user

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] [day] [month] [year] [list]

Message-ID: <Z-N439fyHEyweXq0@kbusch-mbp>
Date: Tue, 25 Mar 2025 23:47:43 -0400
From: Keith Busch <kbusch@...nel.org>
To: Caleb Sander Mateos <csander@...estorage.com>
Cc: Jens Axboe <axboe@...nel.dk>, Christoph Hellwig <hch@....de>,
	Sagi Grimberg <sagi@...mberg.me>,
	Pavel Begunkov <asml.silence@...il.com>,
	Xinyu Zhang <xizhang@...estorage.com>,
	linux-nvme@...ts.infradead.org, io-uring@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/3] nvme_map_user_request() cleanup

On Mon, Mar 24, 2025 at 02:05:37PM -0600, Caleb Sander Mateos wrote:
> The first commit removes a WARN_ON_ONCE() checking userspace values.
> The last 2 move code out of nvme_map_user_request() that belongs better
> in its callers, and move the fixed buffer import before going async.
> As discussed in [1], this allows an NVMe passthru operation submitted at
> the same time as a ublk zero-copy buffer unregister operation to succeed
> even if the initial issue goes async. This can improve performance of
> userspace applications submitting the operations together like this with
> a slow fallback path on failure. This is an alternate approach to [2],
> which moved the fixed buffer import to the io_uring layer.
> 
> There will likely be conflicts with the parameter cleanup series Keith
> posted last month in [3].
> 
> The series is based on block/for-6.15/io_uring, with commit 00817f0f1c45
> ("nvme-ioctl: fix leaked requests on mapping error") cherry-picked.

Thanks, I've queued these up internally for 6.15; the next nvme pull
request will need to rebase once the upstream branches sync with the
existing outstanding pulls, so this series will be included in the next
one for this merge window after that happens.