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.
Thanks,
Miklos
--
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
