On Tue, Dec 22, 2020 at 04:20:27PM +0000, Matthew Wilcox wrote:
> On Mon, Dec 21, 2020 at 02:50:55PM -0500, Vivek Goyal wrote:
> > +static int ovl_errseq_check_advance(struct super_block *sb, struct file *file)
> > +{
> > + struct ovl_fs *ofs = sb->s_fs_info;
> > + struct super_block *upper_sb;
> > + int ret;
> > +
> > + if (!ovl_upper_mnt(ofs))
> > + return 0;
> > +
> > + upper_sb = ovl_upper_mnt(ofs)->mnt_sb;
> > +
> > + if (!errseq_check(&upper_sb->s_wb_err, file->f_sb_err))
> > + return 0;
> > +
> > + /* Something changed, must use slow path */
> > + spin_lock(&file->f_lock);
> > + ret = errseq_check_and_advance(&upper_sb->s_wb_err, &file->f_sb_err);
> > + spin_unlock(&file->f_lock);
>
> Why are you microoptimising syncfs()? Are there really applications which
> call syncfs() in a massively parallel manner on the same file descriptor?
This is atleast theoritical race. I am not aware which application can
trigger this race. So to me it makes sense to fix the race.
Jeff Layton also posted a fix for syncfs().
https://lore.kernel.org/linux-fsdevel/20201219134804.20034-1-jlayton@xxxxxxxxxx/
To me it makes sense to fix the race irrespective of the fact if somebody
hit it or not. People end up copying code in other parts of kernel and
and they will atleast copy race free code.
Vivek
