Re: [PATCH v2 01/11] ovl: store path type in dentry

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Apr 24, 2017 at 4:36 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote:
> On Mon, Apr 24, 2017 at 04:10:30PM +0300, Amir Goldstein wrote:
>> On Mon, Apr 24, 2017 at 3:59 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote:
>> >
>> > On Mon, Apr 24, 2017 at 12:14:06PM +0300, Amir Goldstein wrote:
>> >
>> > [..]
>> > > diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
>> > > index c072a0c..671bac0 100644
>> > > --- a/fs/overlayfs/super.c
>> > > +++ b/fs/overlayfs/super.c
>> > > @@ -961,6 +961,7 @@ static int ovl_fill_super(struct super_block *sb, void *data, int silent)
>> > >       kfree(stack);
>> > >
>> > >       root_dentry->d_fsdata = oe;
>> > > +     ovl_update_type(root_dentry, true);
>> > >
>> > >       realinode = d_inode(ovl_dentry_real(root_dentry));
>> > >       ovl_inode_init(d_inode(root_dentry), realinode, !!upperpath.dentry);
>> > > diff --git a/fs/overlayfs/util.c b/fs/overlayfs/util.c
>> > > index 1953986..6a857fb 100644
>> > > --- a/fs/overlayfs/util.c
>> > > +++ b/fs/overlayfs/util.c
>> > > @@ -70,21 +70,38 @@ bool ovl_dentry_weird(struct dentry *dentry)
>> > >  enum ovl_path_type ovl_path_type(struct dentry *dentry)
>> > >  {
>> > >       struct ovl_entry *oe = dentry->d_fsdata;
>> > > -     enum ovl_path_type type = 0;
>> > > +     enum ovl_path_type type = oe->__type;
>> > >
>> > > -     if (oe->__upperdentry) {
>> > > -             type = __OVL_PATH_UPPER;
>> > > +     /* Matches smp_wmb() in ovl_update_type() */
>> > > +     smp_rmb();
>> > > +     return type;
>> >
>> > Hi Amir,
>> >
>> > I never manage to understand barriers so I will ask. Why this barrier is
>> > required and what can go wrong if we don't use this barrier.
>> >
>>
>> Hi Vivek,
>>
>> Miklos was kind enough to answer that question for me when he made
>> the comment about missing memmory barrier on v1 of the patch:
>> http://www.spinics.net/lists/linux-unionfs/msg01687.html
>>
>> Whether or not I got it right, we shall see shortly ;-)
>
> Hi Amir,
>
> Thanks. Ok, so we are making sure if other cpu sees updated ->type, then
> it is guaranteed that it isses updated ->upperdentry as well.
>
> I feel it is worth to put a shortened version of explanation from miklos
> in the comments. It will help to recall why did we put it. But it is just
> me. May be it is obvious to others.
>

I recon memory barriers are obvious to few.
However, I think the documentation I left is quite standard practice:
- smp_rmb() has a comment to point to the matching smp_wmb()
- smp_wmb() has a comment to explain what the barrier protects:
 * Make sure type is consistent with __upperdentry before making it
 * visible to ovl_path_type()
(i.e. to lockless readers of oe->__type)

Amir.
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux