On Mon, 2021-01-04 at 18:57 +0000, Al Viro wrote: > On Mon, Jan 04, 2021 at 01:43:47PM -0500, Jeff Layton wrote: > > @@ -172,7 +172,12 @@ SYSCALL_DEFINE1(syncfs, int, fd) > > ret = sync_filesystem(sb); > > up_read(&sb->s_umount); > > > > > > - ret2 = errseq_check_and_advance(&sb->s_wb_err, &f.file->f_sb_err); > > + if (errseq_check(&sb->s_wb_err, f.file->f_sb_err)) { > > + /* Something changed, must use slow path */ > > + spin_lock(&f.file->f_lock); > > + ret2 = errseq_check_and_advance(&sb->s_wb_err, &f.file->f_sb_err); > > + spin_unlock(&f.file->f_lock); > > + } > > Is there any point bothering with the fastpath here? > I mean, look at the up_read() immediately prior to that thing... It is a micro-optimization, but the vastly common case is that we will avoid the spinlock there. That said, I'm fine with dropping the fastpath if you prefer. -- Jeff Layton <jlayton@xxxxxxxxxx>