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  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]
Date:   Mon, 26 Nov 2018 11:54:06 +0900
From:   Eiichi Tsukata <>
To:     Alexander Viro <>
Cc:, Chris Mason <>,
        Josef Bacik <>,
        David Sterba <>,
        "Theodore Ts'o" <>,
        Andreas Dilger <>,
        Jaegeuk Kim <>, Chao Yu <>,
        Miklos Szeredi <>,
        Bob Peterson <>,
        Andreas Gruenbacher <>,,,,,,
Subject: Re: [PATCH v1 0/4] fs: fix race between llseek SEEK_END and write

2018年11月22日(木) 16:06 Al Viro <>:
> 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:
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

> 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.

Powered by blists - more mailing lists