linux-kernel - Re: [git pull] sendfile fixes

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: <CAHk-=wiyaja6TKL1+HGXMXNE2EkqfjjKV6oQAOKfTTacc=mq5Q@mail.gmail.com>
Date:   Sun, 14 Feb 2021 11:35:36 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [git pull] sendfile fixes

On Sun, Feb 14, 2021 at 7:19 AM Al Viro <viro@...iv.linux.org.uk> wrote:
>
>         Making sendfile() to pipe destination do the right thing, should
> make "fs/pipe: allow sendfile() to pipe again" redundant.  Sat in -next
> for 3 weeks...

Just to clarify: this says "fixes", but I get the feeling that you
meant for me to pull tomorrow in the 5.12 merge window?

I like the patches, but they don't seem to be anything hugely urgent.
They should make "sendfile to pipe" more efficient, but the current
hack is _workable_ (and not any worse than what we historically did)
even if it's not optimal.

Right?

Oh, and it looks like the first line of the commit message of
313d64a35d36 ("do_splice_to(): move the logics for limiting the read
length in") got truncated somehow..

          Linus