Re: [PATCH] overlayfs: fix warning in ovl_iterate

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

 



On Mon, Jul 16, 2018 at 11:14 PM, Aditya Kali <adityakali@xxxxxxxxxx> wrote:
> Hi Amir,
>
> On Fri, Jul 13, 2018 at 6:09 AM Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>>
>> On Fri, Jul 13, 2018 at 12:32 AM, Aditya Kali <adityakali@xxxxxxxxxx> wrote:
>> > From: Aditya Kali <adityakali@xxxxxxxxxx>
>> >
>> > 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@xxxxxxxxxx>
>
> Would that be ok?
>

Done.

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