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

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

Message-ID: <95529e8f-ac4d-4530-94fa-488372489100@gmail.com>
Date: Thu, 13 Mar 2025 13:15:50 +0000
From: Pavel Begunkov <asml.silence@...il.com>
To: Sidong Yang <sidong.yang@...iosa.ai>
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 3/13/25 10:44, Sidong Yang wrote:
> 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.

Sure, you can just base on top of that branch, hashes might be
different but it's identical to the base it should be on. Your
v2 didn't have some more recent merged patches.

-- 
Pavel Begunkov