linux-kernel - Re: [RFC PATCH v2 0/2] introduce io_uring_cmd_import_fixed

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: <Z9K2-mU3lrlRiV6s@sidongui-MacBookPro.local>
Date: Thu, 13 Mar 2025 19:44:10 +0900
From: Sidong Yang <sidong.yang@...iosa.ai>
To: Pavel Begunkov <asml.silence@...il.com>
Cc: Josef Bacik <josef@...icpanda.com>, David Sterba <dsterba@...e.com>,
	Jens Axboe <axboe@...nel.dk>, linux-btrfs@...r.kernel.org,
	linux-kernel@...r.kernel.org, io-uring@...r.kernel.org
Subject: Re: [RFC PATCH v2 0/2] introduce io_uring_cmd_import_fixed_vec

On Thu, Mar 13, 2025 at 08:57:45AM +0000, Pavel Begunkov wrote:
> On 3/12/25 14:23, Sidong Yang wrote:
> > This patche series introduce io_uring_cmd_import_vec. With this function,
> > Multiple fixed buffer could be used in uring cmd. It's vectored version
> > for io_uring_cmd_import_fixed(). Also this patch series includes a usage
> > for new api for encoded read in btrfs by using uring cmd.
> 
> Pretty much same thing, we're still left with 2 allocations in the
> hot path. What I think we can do here is to add caching on the
> io_uring side as we do with rw / net, but that would be invisible
> for cmd drivers. And that cache can be reused for normal iovec imports.
> 
> https://github.com/isilence/linux.git regvec-import-cmd
> (link for convenience)
> https://github.com/isilence/linux/tree/regvec-import-cmd
> 
> Not really target tested, no btrfs, not any other user, just an idea.
> There are 4 patches, but the top 3 are of interest.

Thanks, I justed checked the commits now. I think cache is good to resolve
this without allocation if cache hit. Let me reimpl this idea and test it
for btrfs.

> 
> Another way would be to cache in btrfs, but then btrfs would need to
> care about locking for the cache and some other bits, and we wouldn't
> be able to reuse it for other drivers.

Agreed, it could be better to reuse it for other driver.

Thanks,
Sidong
> 
> -- 
> Pavel Begunkov
>