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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 31 May 2019 20:22:06 +0300 From: Amir Goldstein <amir73il@...il.com> To: "Theodore Ts'o" <tytso@....edu> Cc: Jan Kara <jack@...e.cz>, "Darrick J . Wong" <darrick.wong@...cle.com>, Dave Chinner <david@...morbit.com>, Chris Mason <clm@...com>, Al Viro <viro@...iv.linux.org.uk>, linux-fsdevel <linux-fsdevel@...r.kernel.org>, linux-xfs <linux-xfs@...r.kernel.org>, Ext4 <linux-ext4@...r.kernel.org>, Linux Btrfs <linux-btrfs@...r.kernel.org>, Linux API <linux-api@...r.kernel.org> Subject: Re: [RFC][PATCH] link.2: AT_ATOMIC_DATA and AT_ATOMIC_METADATA On Fri, May 31, 2019 at 7:41 PM Theodore Ts'o <tytso@....edu> wrote: > > On Fri, May 31, 2019 at 06:21:45PM +0300, Amir Goldstein wrote: > > What do you think of: > > > > "AT_ATOMIC_DATA (since Linux 5.x) > > A filesystem which accepts this flag will guarantee that if the linked file > > name exists after a system crash, then all of the data written to the file > > and all of the file's metadata at the time of the linkat(2) call will be > > visible. > > ".... will be visible after the the file system is remounted". (Never > hurts to be explicit.) > > > The way to achieve this guarantee on old kernels is to call fsync (2) > > before linking the file, but doing so will also results in flushing of > > volatile disk caches. > > > > A filesystem which accepts this flag does NOT > > guarantee that any of the file hardlinks will exist after a system crash, > > nor that the last observed value of st_nlink (see stat (2)) will persist." > > > > This is I think more precise: > > This guarantee can be achieved by calling fsync(2) before linking > the file, but there may be more performant ways to provide these > semantics. In particular, note that the use of the AT_ATOMIC_DATA > flag does *not* guarantee that the new link created by linkat(2) > will be persisted after a crash. OK. Just to be clear, mentioning hardlinks and st_link is not needed in your opinion? > > We should also document that a file system which does not implement > this flag MUST return EINVAL if it is passed this flag to linkat(2). > OK. I think this part can be documented as possible reason for EINVAL As in renameat(2) man page: EINVAL The filesystem does not support one of the flags in flags. Thanks, Amir.
Powered by blists - more mailing lists