linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Aditya Kali <adityakali@google.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	overlayfs <linux-unionfs@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH] overlayfs: fix warning in ovl_iterate
Date: Tue, 17 Jul 2018 17:42:13 +0300	[thread overview]
Message-ID: <CAOQ4uxhi_xfzKgOs2L0ratzUG1wTcJDrxPGUR=4LV_gj6XbJfA@mail.gmail.com> (raw)
In-Reply-To: <CAGr1F2EKAQ-_2BZnBMfiS=b5=R_0G0Ka6LNRZ6nRHsoQtyTFOQ@mail.gmail.com>

On Mon, Jul 16, 2018 at 11:14 PM, Aditya Kali <adityakali@google.com> wrote:
> Hi Amir,
>
> On Fri, Jul 13, 2018 at 6:09 AM Amir Goldstein <amir73il@gmail.com> wrote:
>>
>> On Fri, Jul 13, 2018 at 12:32 AM, Aditya Kali <adityakali@google.com> wrote:
>> > From: Aditya Kali <adityakali@google.com>
>> >
>> > In ovl_iterate() funciton, we were calling ovl_cache_get() on dentries
>> > marked OVL_IMPURE which are not refcounted. This results in triggering
>> > WARN_ON(cache->refcount <= 0).
>>
>> Aditya,
>>
>> Thanks for the report, but I am afraid your analysis is inaccurate and
>> the fix is flat out wrong, so let's try to better understand what is going on.
>>
>> First of all, the WARNING triggered by your test in WARN_ON(!cache->refcount)
>> at line 415 of  ovl_cache_get() and not the warning in ovl_cache_put().
>>
>> Your statement that dir marked OVL_IMPURE have non refcounted
>> dir cache is not accurate.
>> This statement is only true for dirs that are !ovl_dir_is_real() AND
>> marked OVL_IMPURE, in which case od->cache should be NULL
>> and therefore ovl_cache_put() is not concerned.
>>
> I completely missed that.
>
>> Since your test case hits the WARN_ON in ovl_cache_get() it suggests
>> that the dir was ovl_dir_is_real(), got a dir cache initialized with
>> ovl_cache_get_impure() and then later became !ovl_dir_is_real()
>> and got passed into  ovl_cache_get() with an unexpected type
>> of dir cache.
>>
>> Directory can only become !ovl_dir_is_real() on copy up and if dir
>> was not upper prior to copy up, it could not have been OVL_IMPURE
>> either. However, if ovl_iterate() is called with non zero ctx->pos,
>> od->is_real will not be updated, but OVL_IMPURE is checked again.
>> Meaning that if chown -R iterates on a bunch of files, chowns them
>> and then continues to iterate on more files, directory will become
>> OVL_IMPURE, so second ovl_iterate() call with non zero ctx->pos
>> will initialize an impure dir cache and then on following ls -l we will
>> hit the WARNING.
>>
>> It will be nice if you can add traces in the relevant functions to prove
>> this is what's happening in your test case.
>>
>
> Thanks for that explanation. I will admit that my knowledge about
> overlayfs is very limited.
> My initial hypothesis was based on some tracing I had added that would trigger a
>     WARN_ON(ovl_test_flag(OVL_IMPURE, d_inode(dentry))
> in ovl_cache_get() and also in ovl_cache_put().
>
> But your explanation for the root cause makes sense.
>
>> > It can be reproduced by running the following command (on system with
>> > docker using overlay2 graph driver):
>> >
>> >   docker run --rm drupal:8.5.4-fpm-alpine \
>> >     sh -c 'cd /var/www/html/vendor/symfony && chown -R www-data:www-data . && ls -l .'
>>
>> It's nice to have a one liner reproducer, but if you can come up with
>> a simple script reproducer that does not include docker that would be
>> even nicer.
>> If you write an xfstest for the reproducer you really get the praises ;-)
>>
>
> Will try to convert it to xfstests.
>

Great.
Note that I am not sure you can rely on behavior of chown -R installed on
testing host, you may need to write a dedicated C helper, like
src/t_dir_offset*.c src/t_dir_type.c
which reads a few dentries, makes sure dir is copied up and continues
to read more dentries (with non zero offset)

[...]

>
> I tested the patch and it seems to address the issue. It would be
> great if you can send the patch with clearer explanation for the root
> cause.
> You can add
> Tested-by: Aditya Kali <adityakali@google.com>
>
> Would that be ok?
>

Done.

Thanks,
Amir.

      reply	other threads:[~2018-07-17 15:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-12 21:32 [PATCH] overlayfs: fix warning in ovl_iterate Aditya Kali
2018-07-13 13:09 ` Amir Goldstein
2018-07-16 20:14   ` Aditya Kali
2018-07-17 14:42     ` Amir Goldstein [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOQ4uxhi_xfzKgOs2L0ratzUG1wTcJDrxPGUR=4LV_gj6XbJfA@mail.gmail.com' \
    --to=amir73il@gmail.com \
    --cc=adityakali@google.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).