linux-kernel - Re: [GIT PULL] pipe: nonblocking rw for io

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: <22265532-595f-0477-45a7-f920115b3771@kernel.dk>
Date:   Mon, 24 Apr 2023 16:05:00 -0600
From:   Jens Axboe <axboe@...nel.dk>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Christian Brauner <brauner@...nel.org>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] pipe: nonblocking rw for io_uring

On 4/24/23 4:00?PM, Linus Torvalds wrote:
> On Mon, Apr 24, 2023 at 2:55?PM Jens Axboe <axboe@...nel.dk> wrote:
>>
>> I took another look at this, and the main issue is in fact splice
>> confirming buffers. So I do think that we can make this work by simply
>> having the non-block nature of it being passed down the ->confirm()
>> callback as that's the one that'll be waiting for IO. If we have that,
>> then we can disregard the pipe locking as we won't be holding it over
>> IO.
> 
> Ok, that part looks fine to me.
> 
> The pipe_buf_confirm() part of the series I don't find problematic,
> it's really conditional locking that I absolutely detest and has
> always been a sign of problems elsewhere.

Agree, the conditional locking is the ugly bit for sure. I'll reply to
your other email as my followup to my message discovered that this isn't
enough due to mixed splice/non-splice usage.

-- 
Jens Axboe