Re: [RFC][PATCH 1/2] ovl: store path type in dentry

Amir Goldstein
2017-03-28T17:00:10Z

On Tue, Mar 28, 2017 at 10:03 AM, Miklos Szeredi <miklos@szeredi.hu> wrote:
> On Tue, Mar 21, 2017 at 5:16 PM, Amir Goldstein <amir73il@gmail.com> wrote:
>> ovl_path_type() is called quite often (e.g.: on every file open)
>> to calculate the path type flags of overlay dentry. Those flags
>> are rarely changed after dentry instantiation and when changed,
>> flags can only be added. (e.g.: on copyup, rename and create).
>>
>> Store the type value in ovl_entry and update the flags when
>> needed, so ovl_path_type() just returns the stored value.
>
> Since accessing __upperdentry is lockless we need to be careful with
> memory ordering issues.
>
> For example in the new version of ovl_dentry_update() we first store
> oe->__upperdentry then oe->type. In a concurrent ovl_path_real() we
> first read oe->type and then based on the OVL_TYPE_UPPER flag read
> oe->__upperdentry. Without any barriers the above could very easily
> result in NULL upperdentry being read. The compiler or the CPU could
> reorder the stores in ovl_dentry_update(), etc...
>

Right.. thanks for pointing that out. I'll take better care.

FYI, I am just in the midst of adding oe->__tempdentry and
OVL_TYPE_RO_UPPER for copy up on O_RDONLY.
I started by trying to "upgrade" oe->__upperdentry from tmpfile
to linked file, but that was real messy.

> For the gory details see Documentation/memory-barriers.txt
>

I know about them, but still easy for me to get them wrong...
Hopefully will have something for you to review by tomorrow.

Thanks,
Amir.