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 <[email protected]>

Reply via email to