On Fri, Oct 20, 2017 at 4:23 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> On Fri, Oct 20, 2017 at 1:01 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>> Fixes: 359f392ca53e ("ovl: lookup index entry for copy up origin")
>> Cc: <stable@xxxxxxxxxxxxxxx> # v4.13
>> Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx>
>> ---
>> fs/overlayfs/namei.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> Miklos,
>>
>> This is a complimentary/fixup patch to the patch currently at the tip of
>> overlayfs-next. I did not run into ENOENT in my tests, but it seems that
>> all other places in overlayfs that call lookup_one_len_unlocked() check
>> the ENOENT return value and treat it the same as negative dentry.
>>
>> I suppose this could be expected from some file systems?
>
> I haven't done the research, but I suppose it's possible. Nobody is
> forcing filesystems to cache negative dentries, although not doing so
> might be stupid.
>
> However, the patch seems to be wrong, since it does not treat -ENOENT
> quite the same way as a negative index (no warning for hard links).
>
> Btw you can use "--suppress-cc=bodycc" to not spam stable@vger with
> review patches.
>
OK, but Greg didn't seem annoyed by getting CC'ed - on the contrary..
Anyway, sent fixed v2 and CC'ed stable, since there was already a
discussion on v1
Amir.