linux-kernel - Re: [RFC] splice/tee: len=0 fast path after validity check

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: <549f9a26-041b-6b2c-f21d-4cf8733323a4@gmail.com>
Date:   Sat, 9 May 2020 19:03:03 +0300
From:   Pavel Begunkov <asml.silence@...il.com>
To:     Jens Axboe <axboe@...nel.dk>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        io-uring@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC] splice/tee: len=0 fast path after validity check

On 09/05/2020 17:42, Jens Axboe wrote:
> On 5/9/20 2:46 AM, Pavel Begunkov wrote:
>> When len=0, splice() and tee() return 0 even if specified fds are
>> invalid, hiding errors from users. Move len=0 optimisation later after
>> basic validity checks.
>>
>> before:
>> splice(len=0, fd_in=-1, ...) == 0;
>>
>> after:
>> splice(len=0, fd_in=-1, ...) == -EBADF;
> 
> I'm not sure what the purpose of this would be. It probably should have
> been done that way from the beginning, but it wasn't.  While there's
> very little risk of breaking any applications due to this change, it
> also seems like a pointless exercise at this point.
> 
> So my suggestion would be to just leave it alone.

Ok

-- 
Pavel Begunkov