Re: [PATCH v1 0/4] fs: fix race between llseek SEEK_END and write

Eiichi Tsukata
2018-11-26T02:54:06Z

2018年11月22日(木) 16:06 Al Viro <viro@zeniv.linux.org.uk>:
>
> Can you show me where does POSIX/SuS/whatever it's called these days promise
> that kind of atomicity?

No. I couldn't found it.
That's why I previously posted RFC Patch:
https://marc.info/?t=154237277900001&r=1&w=2
I wasn't sure this is a bug in the kernel or not.

> that kind of atomicity? TBH, I would be very surprised if any Unix promised
> to have file size updated no more than once per write(2). Any userland code
> that relies on such property is, as minimum, non-portable and I would argue
> that it is outright broken.

Thanks. Now It's clear. It is not a bug in the kernel, but in
userspace if `tail` assumes such
atomicity.

> Note, BTW, that your example depends upon rather non-obvious details of echo
> implementation, starting with the bufferization logics used by particular
> shell. And AFAICS ash(1) ends up with possibility of more than one write(2)

I've never imagined such a difference in echo implementation, thanks.