On Tue, Jan 26, 2021 at 10:49:11AM -0800, Linus Torvalds wrote:
> On Mon, Jan 25, 2021 at 10:07 PM Al Viro wrote:
> >
> > On Sun, Jan 24, 2021 at 11:11:42AM -0800, Linus Torvalds wrote:
> > >
> > > I agree that it would be better fixed by just having sendfile()
> > > basically turn into splice() f
On Mon, Jan 25, 2021 at 10:07 PM Al Viro wrote:
>
> On Sun, Jan 24, 2021 at 11:11:42AM -0800, Linus Torvalds wrote:
> >
> > I agree that it would be better fixed by just having sendfile()
> > basically turn into splice() for the pipe target case, but I haven't
> > seen any patches from you, so I a
On Sun, Jan 24, 2021 at 11:11:42AM -0800, Linus Torvalds wrote:
> Al,
> coming back to this because rc5 is imminent..
>
> On Mon, Jan 18, 2021 at 11:45 AM Al Viro wrote:
> >
> > do_splice_direct() does something that do_splice() won't - it
> > handles non-pipe to non-pipe case. Which is how sen
Al,
coming back to this because rc5 is imminent..
On Mon, Jan 18, 2021 at 11:45 AM Al Viro wrote:
>
> do_splice_direct() does something that do_splice() won't - it
> handles non-pipe to non-pipe case. Which is how sendfile(2) is
> normally used, of course.
>
> I'll look into that in more detail
On Thu, Jan 21, 2021 at 9:03 AM Robert Karszniewicz
wrote:
>
> I confirm that the 4 patches, as well as the 4+2 patches, fix the regression I
> noticed with cat failing on sendfile() to ttymxc0.
Thanks. Now we just need to find somebody with HDLC use cases and
we'll actually have this series prop
On Thu, Jan 21, 2021 at 12:58 AM Jiri Slaby wrote:
>
> Which is weird as you Cced me. Let me check what is wrong with my e-mail
> setup.
Yeah, I think you were cc'd on not just the patches, but on all the
discussion that preceded them.
But better late than never. I was actually much more nervous
On 1/20/21 5:44 AM, Linus Torvalds wrote:
> On Tue, Jan 19, 2021 at 5:29 PM Oliver Giles wrote:
>>
>> Writing this from a kernel with those patches in; happily splice()ing
>> to and from a pty.
>
> Ok, good.
>
> I have a couple of improvement patches on top of those, that I'm attaching
> here.
From: Linus Torvalds
> Sent: 21 January 2021 01:04
> On Wed, Jan 20, 2021 at 4:38 PM Al Viro wrote:
> >
> > OK... I wonder how many debugfs writable files allow pwrite() with
> > BS results...
>
> I hope some of them check for "pos == 0" when they start parsing integers.
>
> But honestly, I don
On Thu, Jan 21, 2021 at 09:50:39AM +0100, Jiri Slaby wrote:
> On 21. 01. 21, 2:18, Linus Torvalds wrote:
> > On Tue, Jan 19, 2021 at 8:44 PM Linus Torvalds
> > wrote:
> > >
> > > I'll come back to this tomorrow and do the line-buffered icanon case
> > > too (unless pull requests pile up), and the
On 21. 01. 21, 9:50, Jiri Slaby wrote:
Hm, I would like to review this first. I noticed the changes only
because a new branch appeared when I grabbed your tree and the branch
has "tty" in its name.
Which is weird as you Cced me. Let me check what is wrong with my e-mail
setup.
thanks,
--
js
On 21. 01. 21, 2:18, Linus Torvalds wrote:
On Tue, Jan 19, 2021 at 8:44 PM Linus Torvalds
wrote:
I'll come back to this tomorrow and do the line-buffered icanon case
too (unless pull requests pile up), and then I'll be happy with the
tty changes, and I think I can submit this series for real t
On Wed, Jan 20, 2021 at 05:18:36PM -0800, Linus Torvalds wrote:
> On Tue, Jan 19, 2021 at 8:44 PM Linus Torvalds
> wrote:
> >
> > I'll come back to this tomorrow and do the line-buffered icanon case
> > too (unless pull requests pile up), and then I'll be happy with the
> > tty changes, and I thin
On Thu, 2021-01-21 at 07:05 +0100, Willy Tarreau wrote:
> I think that most users of splice() on sockets got used to falling back
> to recv/send on splice failure due to various cases not being supported
> historically (UNIX family sockets immediately come to my mind but I seem
> to remember other
On Wed, Jan 20, 2021 at 3:14 PM Al Viro wrote:
>
> Umm... Why do we clear FMODE_PWRITE there [seq_open - ed], anyway?
I think it's pointless and historical, and comes from "several /proc
files supported the simple single-write model, nothing ever supported
moving around and writing".
The seq_fi
On Wed, Jan 20, 2021 at 07:38:38PM -0800, Linus Torvalds wrote:
> On Wed, Jan 20, 2021 at 5:45 PM Al Viro wrote:
> >
> > splice() triggers an error for seekable destination with O_APPEND and
> > with NULL off_out.
>
> Ok, that's just broken.
>
> > Same for splice() to socket with
> > fcn
On Wed, Jan 20, 2021 at 5:45 PM Al Viro wrote:
>
> splice() triggers an error for seekable destination with O_APPEND and
> with NULL off_out.
Ok, that's just broken.
> Same for splice() to socket with
> fcntl(sock_fd, F_SETFL, O_APPEND);
> done first.
Same.
As long as you don't pass a
On Wed, Jan 20, 2021 at 05:04:17PM -0800, Linus Torvalds wrote:
> The whole point of O_APPEND is that the position shouldn't matter.
>
> And the whole point of "pwrite()" is that you specify a position.
>
> So the two just do not go together - although we may have legacy
> issues, of course.
Ou
On Tue, Jan 19, 2021 at 8:44 PM Linus Torvalds
wrote:
>
> I'll come back to this tomorrow and do the line-buffered icanon case
> too (unless pull requests pile up), and then I'll be happy with the
> tty changes, and I think I can submit this series for real to Greg.
Greg, I don't know how you wan
On Wed, Jan 20, 2021 at 4:38 PM Al Viro wrote:
>
> OK... I wonder how many debugfs writable files allow pwrite() with
> BS results...
I hope some of them check for "pos == 0" when they start parsing integers.
But honestly, I don't think it's a big deal. We've had these things
that just basicall
On Wed, Jan 20, 2021 at 03:40:29PM -0800, Linus Torvalds wrote:
> On Wed, Jan 20, 2021 at 3:14 PM Al Viro wrote:
> >
> > Umm... Why do we clear FMODE_PWRITE there [seq_open - ed], anyway?
>
> I think it's pointless and historical, and comes from "several /proc
> files supported the simple single
On Wed, Jan 20, 2021 at 10:25:56PM +, David Laight wrote:
> I also wonder if pread/pwrite with offset == 0 should be valid
> on things where the offset makes no sense.
>
> I'm rather surprised the offset isn't just silently ignored
> for devices where seeking is non-sensical.
> You might want
On Wed, Jan 20, 2021 at 11:27:26AM -0800, Linus Torvalds wrote:
> On Wed, Jan 20, 2021 at 11:11 AM Al Viro wrote:
> >
> > Why do we care about O_APPEND on anything without FMODE_PWRITE (including
> > pipes), anyway? All writes there ignore position, after all...
>
> We shouldn't care.
>
> Also,
From: Linus Torvalds
> Sent: 20 January 2021 19:27
> On Wed, Jan 20, 2021 at 11:11 AM Al Viro wrote:
> >
> > Why do we care about O_APPEND on anything without FMODE_PWRITE (including
> > pipes), anyway? All writes there ignore position, after all...
>
> We shouldn't care.
>
> Also, I think we s
On Wed, Jan 20, 2021 at 11:11 AM Al Viro wrote:
>
> Why do we care about O_APPEND on anything without FMODE_PWRITE (including
> pipes), anyway? All writes there ignore position, after all...
We shouldn't care.
Also, I think we should try to move away from FMODE_PWRITE/PREAD
entirely, and use FM
On Wed, Jan 20, 2021 at 04:26:08PM +, Al Viro wrote:
> [1] yes, it is possible to have O_APPEND opened pipes - open a FIFO with
> O_APPEND and you've got it. We are not quite consistent in handling
> those - sendfile() to such is rejected, splice() is not.
BTW, according to manpages of splic
On Mon, Jan 18, 2021 at 07:54:00PM +, Al Viro wrote:
> On Mon, Jan 18, 2021 at 11:46:42AM -0800, Linus Torvalds wrote:
> > On Mon, Jan 18, 2021 at 11:35 AM Al Viro wrote:
> > >
> > > I'd rather have sendfile(2) do what splice(2) does and handle pipes
> > > directly. Let me take a look,,,
> >
On Wed Jan 20, 2021 at 5:44 PM NZDT, Linus Torvalds wrote:
>
> But in the meantime, here's two more patches to try on top of the
> previous four. They shouldn't matter, other than making the non-icanon
> throughput a lot better. But the more coverage they get, the happier
> I'll be.
>
I tried thes
On Tue, Jan 19, 2021 at 5:29 PM Oliver Giles wrote:
>
> Writing this from a kernel with those patches in; happily splice()ing
> to and from a pty.
Ok, good.
I have a couple of improvement patches on top of those, that I'm attaching here.
The first four patches worked fine for me (and apparently
On Wed Jan 20, 2021 at 9:24 AM NZDT, Linus Torvalds wrote:
> Anyway, anybody willing to test these tty/pipe patches on the loads
> that failed? Oliver?
Writing this from a kernel with those patches in; happily splice()ing
to and from a pty.
On Wed Jan 20, 2021 at 5:56 AM NZDT, Robert Karszniewicz wrote:
>
> I have bisected this issue down to this commit:
> 4d03e3cc5982 ("fs: don't allow kernel reads and writes without iter
> ops")
>
> Another case I've also noticed is writing to a serial connection:
> kernel write not supported for fi
On Tue, Jan 19, 2021 at 12:24:22PM -0800, Linus Torvalds wrote:
> But that sysfs binary file case really isn't interesting, and just
> more of a "Christoph broke it, I think he should just fix it".
> Christoph?
I'll give it a spin tomorrow. Should be simple enough.
On Tue, Jan 19, 2021 at 3:54 AM Greg Kroah-Hartman
wrote:
>
> This looks sane, but I'm still missing what the goal of this is here.
> It's nice from a "don't make the ldisc do the userspace copy", point of
> view, but what is the next step in order to tie that into splice?
Ok, so here's a series
On Tue, Jan 19, 2021 at 3:54 AM Greg Kroah-Hartman
wrote:
>
> This looks sane, but I'm still missing what the goal of this is here.
> It's nice from a "don't make the ldisc do the userspace copy", point of
> view, but what is the next step in order to tie that into splice?
I'll cook something up.
On 1/19/21 12:53 PM, Greg Kroah-Hartman wrote:
> This looks sane, but I'm still missing what the goal of this is here.
> It's nice from a "don't make the ldisc do the userspace copy", point of
> view, but what is the next step in order to tie that into splice?
>
> I ask as I also have reports that
On 1/19/21 5:56 PM, Robert Karszniewicz wrote:
> Another case I've also noticed is writing to a serial connection:
> kernel write not supported for file /ttymxc0 (pid: 252 comm: cat)
Which is actually a TTY and I just failed to see the forest for all the trees...
Cheers.
On Mon, Jan 18, 2021 at 05:38:55PM -0800, Linus Torvalds wrote:
> On Mon, Jan 18, 2021 at 2:20 PM Linus Torvalds
> wrote:
> >
> > So it's not a "real" patch, but with improved buffer handling in
> > tty_read(), I think this is actually quite close.
>
> Hmm.
>
> I somehow ended up working on this
On Mon, Jan 18, 2021 at 01:35:15PM -0800, Linus Torvalds wrote:
> On Mon, Jan 18, 2021 at 12:24 PM Linus Torvalds
> wrote:
> >
> > Anybody want to play with this? I'd suggest keeping that "dummy"
> > parameter around for a while - I did an allmodconfig build with this,
> > but if there are any arc
On Mon, Jan 18, 2021 at 2:20 PM Linus Torvalds
wrote:
>
> So it's not a "real" patch, but with improved buffer handling in
> tty_read(), I think this is actually quite close.
Hmm.
I somehow ended up working on this all because it's a Monday, and I
don't see a lot of pull requests early in the we
On Mon, Jan 18, 2021 at 2:03 PM Linus Torvalds
wrote:
>
> I'll have a third patch in a moment, but while it's ready I want to
> actually reboot and confirm it first.
Here. This is an actually usable and tested starting point for this all.
Again - it doesn't handle HDLC correctly, because it will
On Mon, Jan 18, 2021 at 1:54 PM Linus Torvalds
wrote:
>
> But it might well be some other conversion bug of mine even if I tried
> to keep it fairly minimal and straight-forward.
Duh. I completely forgot to handle the canon_copy_from_read_buf()
case. So ICANON mode was entirely scrogged and would
On Mon, Jan 18, 2021 at 1:35 PM Linus Torvalds
wrote:
>
> So here's a slightly updated version of that patch, but apart from
> slightly better coverage - even if it's a driver that is disabled
> anyway - I'd like to point out that all my previous caveats still
> apply.
I have now booted that vers
On Mon, Jan 18, 2021 at 12:24 PM Linus Torvalds
wrote:
>
> Anybody want to play with this? I'd suggest keeping that "dummy"
> parameter around for a while - I did an allmodconfig build with this,
> but if there are any architecture-specific non-x86-64 cases I wouldn't
> have seen them.
Not archit
On Mon, Jan 18, 2021 at 09:53:11AM +0100, Christoph Hellwig wrote:
> On Sat, Jan 16, 2021 at 05:46:33PM +0100, Johannes Berg wrote:
> > > For my case, I attempted to instead implement splice_write and
> > > splice_read in tty_fops; I managed to get splice_write working calling
> > > ld->ops->write,
On Mon, Jan 18, 2021 at 11:36 AM Linus Torvalds
wrote:
>
> Of course, it probably would be really nice to try to convert
> tty_read() to use the same model that we have for tty_write(), and
> then make the ld->ops->read() function actually take a kernel buffer
> instead.
>
> I wonder how painful t
On Mon, Jan 18, 2021 at 11:49:53AM -0800, Linus Torvalds wrote:
> On Mon, Jan 18, 2021 at 11:45 AM Al Viro wrote:
> >
> > do_splice_direct() does something that do_splice() won't - it
> > handles non-pipe to non-pipe case. Which is how sendfile(2) is
> > normally used, of course.
>
> Yeah, I agr
On Mon, Jan 18, 2021 at 11:46:42AM -0800, Linus Torvalds wrote:
> On Mon, Jan 18, 2021 at 11:35 AM Al Viro wrote:
> >
> > I'd rather have sendfile(2) do what splice(2) does and handle pipes
> > directly. Let me take a look,,,
>
> It's not technically just the sendfile() thing. Some things do
> s
On Mon, Jan 18, 2021 at 11:45 AM Al Viro wrote:
>
> do_splice_direct() does something that do_splice() won't - it
> handles non-pipe to non-pipe case. Which is how sendfile(2) is
> normally used, of course.
Yeah, I agree, it's better if we do the pipe case specially, but if
it's too painful for
On Mon, Jan 18, 2021 at 11:26:00AM -0800, Linus Torvalds wrote:
> On Mon, Jan 18, 2021 at 12:58 AM Johannes Berg
> wrote:
> >
> > > I think just wiring up iter_file_splice_write would work. Al?
> >
> > Seems to work for the simple test case that I had, at least:
>
> Mind sending me a signed-off
On Mon, Jan 18, 2021 at 11:35 AM Al Viro wrote:
>
> I'd rather have sendfile(2) do what splice(2) does and handle pipes
> directly. Let me take a look,,,
It's not technically just the sendfile() thing. Some things do
sendfile "internally" (ie they use do_splice_direct()).
Although maybe they al
On Mon, Jan 18, 2021 at 12:16 AM Christoph Hellwig wrote:
>
> On Sat, Jan 16, 2021 at 08:35:41PM +1300, Oliver Giles wrote:
> > For my case, I attempted to instead implement splice_write and splice_read
> > in tty_fops; I managed to get splice_write working calling ld->ops->write,
> > but splice
On Mon, Jan 18, 2021 at 12:58 AM Johannes Berg
wrote:
>
> > I think just wiring up iter_file_splice_write would work. Al?
>
> Seems to work for the simple test case that I had, at least:
Mind sending me a signed-off patch for this?
Yeah, I know it's a trivial one-liner, but I much prefer having
On Mon, 2021-01-18 at 09:53 +0100, Christoph Hellwig wrote:
> On Sat, Jan 16, 2021 at 05:46:33PM +0100, Johannes Berg wrote:
> > > For my case, I attempted to instead implement splice_write and
> > > splice_read in tty_fops; I managed to get splice_write working calling
> > > ld->ops->write, but sp
On Sat, Jan 16, 2021 at 05:46:33PM +0100, Johannes Berg wrote:
> > For my case, I attempted to instead implement splice_write and
> > splice_read in tty_fops; I managed to get splice_write working calling
> > ld->ops->write, but splice_read is not so simple because the
> > tty_ldisc_ops read method
On Sat, Jan 16, 2021 at 08:35:41PM +1300, Oliver Giles wrote:
> Commit 36e2c7421f02 (fs: don't allow splice read/write without explicit ops)
> broke my userspace application which talks to an SSL VPN by splice()ing
> between "openssl s_client" and "pppd". The latter operates over a pty, and
> si
On Sun Jan 17, 2021 at 5:46 AM NZDT, Johannes Berg wrote:
> On Sat, 2021-01-16 at 20:35 +1300, Oliver Giles wrote:
> > Commit 36e2c7421f02 (fs: don't allow splice read/write without
> > explicit ops) broke my userspace application which talks to an SSL VPN
> > by splice()ing between "openssl s_clie
On Sat, 2021-01-16 at 20:35 +1300, Oliver Giles wrote:
> Commit 36e2c7421f02 (fs: don't allow splice read/write without
> explicit ops) broke my userspace application which talks to an SSL VPN
> by splice()ing between "openssl s_client" and "pppd". The latter
> operates over a pty, and since that c
Commit 36e2c7421f02 (fs: don't allow splice read/write without explicit ops)
broke my userspace application which talks to an SSL VPN by splice()ing between
"openssl s_client" and "pppd". The latter operates over a pty, and since that
commit there is no fallback for splice()ing between a pipe an
57 matches
Mail list logo
