Messages in this thread | | | From | Linus Torvalds <> | Date | Wed, 20 Jan 2021 17:04:17 -0800 | Subject | Re: Splicing to/from a tty |
| |
On Wed, Jan 20, 2021 at 4:38 PM Al Viro <viro@zeniv.linux.org.uk> 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 basically assume that whenever you write, the offset just doesn't matter at all, and as long as some number comes in one single write call, we accept it.
Because even if you end up doing something like just
echo $SOMETHING > /sys/xyz/abc
and that "$SOMETHING" could be done multiple writes, in practice it all works out just fine and it never really is. You almost have to try to screw up with something like
(echo -n 3; echo -n 4) > /sys/xyz/abc
to actually see two writes of "3" and "4" instead of one write with "34". And honestly, if somebody does something like that, do we really care? They might get 3, they might get 4, and they might get 34. They get what they deserve.
> Anyway, possibly more interesting question is why do we care about > O_APPEND at all - why not treat it the same way we do in write()?
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.
In contrast, the whole point of just a plain "write()" is that the position is the "current file position", with O_APPEND is just a special rule for what the current position for a write is.
Now, splice() is able to do *both* write() and pwrite(), because unlike pwrite() it doesn't take a "pos" argument, it takes a _pointer_ to pos. So with a NULL pointer, it's like read/write, and with a non-NULL pointer it is like pread/pwrite.
So I do think that "splice with non-NULL off_out and O_APPEND" should cause an error in general.
That said, we probabyl have legacy behavior with splice and pipes in particular, and that legacy behavior would override any "this is conceptually the sane model".
> So... why do we ban O_APPEND on destination for splice() or for sendfile()?
sendfile() shouldn't be an issue. The offset pointer for sendfile is for the _source_, not the destination.
For splice(), I do think that O_APPEND and a position pointer don't make sense as a combination, although if we do allow it for regular file pwrite() (I didn't check), maybe we could allow it for splice() too just to be erqually inconsistent.
Honestly, I don't think it's a huge deal. O_APPEND isn't that interesting, but I do hope that if we allow O_APPEND and a file position, then O_APPEND always overrides it.
Linus
| |