<div dir="ltr">Hi all,<div><br></div><div>Apologies - my screw-up.</div><div><br></div><div>The aim is to have a 2 patch series for both Xenial and Zesty.</div><div><br></div><div>I will resubmit both with the correct headers and will look for ways to tighten up my personal processes so as not to be so confusing in future.</div><div><br></div><div>Regards,</div><div>Daniel</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 15, 2017 at 9:51 PM, Stefan Bader <span dir="ltr"><<a href="mailto:stefan.bader@canonical.com" target="_blank">stefan.bader@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 15.11.2017 11:43, Kleber Souza wrote:<br>
> A v2 of this patchset has been sent to the mailing list.<br>
><br>
> On 10/30/17 07:56, Daniel Axtens wrote:<br>
>> [SRU Justification]<br>
>><br>
>> [Impact]<br>
>><br>
>> A user is seeing failures from extracting tar archives on overlay<br>
>> filesystems on the 4.4 kernel in constrained environments. The error<br>
>> presents as:<br>
>><br>
>> `tar: ./deps/0/bin: Directory renamed before its status could be extracted`<br>
>><br>
>> Following this thread<br>
>> (<a href="https://www.spinics.net/lists/linux-unionfs/msg00856.html" rel="noreferrer" target="_blank">https://www.spinics.net/<wbr>lists/linux-unionfs/msg00856.<wbr>html</a>), it appears<br>
>> that this occurs when entries in the kernel's inode cache are<br>
>> reclaimed, and subsequent lookups return new inode numbers.<br>
>><br>
>> Further testing showed that when setting<br>
>> `/proc/sys/vm/vfs_cache_<wbr>pressure` to 0 (don't allow the kernel to<br>
>> reclaim inode cache entries due to memory pressure) the error does not<br>
>> recur, supporting the hypothesis that cache entries are being<br>
>> evicted. However, this setting may lead to a kernel OOM so is not a<br>
>> reasonable workaround even temporarily.<br>
>><br>
>> The error cannot be reproduced on a 4.13 kernel, due to the series at<br>
>> <a href="https://www.spinics.net/lists/linux-fsdevel/msg110235.html" rel="noreferrer" target="_blank">https://www.spinics.net/lists/<wbr>linux-fsdevel/msg110235.html</a>. The<br>
>> particular relevant commit is<br>
>> b7a807dc2010334e62e0afd89d6f7a<wbr>8913eb14ff, which needs a couple of<br>
>> dependencies.<br>
>><br>
>> [Fix]<br>
>> For Zesty, backport the entire series.<br>
>> For Xenial, where a full backport is not feasible, backport the key<br>
>> commit and the short list of dependencies.<br>
>><br>
>> [Testcase]<br>
>><br>
>> # Testing this bug<br>
>><br>
>> The testcase for this particular bug is simple - create an overlay<br>
>> filesystem with all layers on the same underlying file system, and<br>
>> then see if the inode of a directory is constant across dropping the<br>
>> caches:<br>
>><br>
>> mkdir -p /upper/upper /upper/work /lower<br>
>> mount -t overlay none /mnt -o lowerdir=/lower,upperdir=/<wbr>upper/upper,workdir=/upper/<wbr>work<br>
>> cd /mnt<br>
>> mkdir a<br>
>> stat a # observe inode number<br>
>> echo 2 > /proc/sys/vm/drop_caches<br>
>> stat a # compare inode number<br>
>><br>
>> If the inode number is the same, the fix is successful.<br>
>><br>
>> # Regression testing<br>
>><br>
>> I have run the unionmount test suite from<br>
>> <a href="https://git.infradead.org/users/dhowells/unionmount-testsuite.git" rel="noreferrer" target="_blank">https://git.infradead.org/<wbr>users/dhowells/unionmount-<wbr>testsuite.git</a> in<br>
>> overlay mode (./run --ov), and verified that it still passes.<br>
>><br>
>> (The series cover letter mentions a fork of the test suite at<br>
>> <a href="https://github.com/amir73il/unionmount-testsuite/commits/overlayfs-devel" rel="noreferrer" target="_blank">https://github.com/amir73il/<wbr>unionmount-testsuite/commits/<wbr>overlayfs-devel</a>. I<br>
>> have *not* attempted to get this running: it assumes a range of<br>
>> changes that are not present in our kernels.)<br>
>><br>
>> [Regression Potential]<br>
>><br>
>> As this changes overlayfs, there is potential for regression in the<br>
>> form of unexpected breakages to overlaysfs behaviour.<br>
>><br>
>> I think this is adequately addressed by the regression testing.<br>
>><br>
>> One option to reduce the regression potential on Zesty is to reduce<br>
>> the set of patches applied - rather than including the whole series we<br>
>> could include just the patches to solve this bug, which are much<br>
>> easier to inspect for correctness.<br>
>><br>
>> Amir Goldstein (2):<br>
>>   ovl: check if all layers are on the same fs<br>
>>   ovl: persistent inode number for directories<br>
>><br>
>>  fs/overlayfs/dir.c       | 29 ++++++++++++++++++++++++++++-<br>
>>  fs/overlayfs/overlayfs.h |  1 +<br>
>>  fs/overlayfs/super.c     | 17 +++++++++++++++++<br>
>>  3 files changed, 46 insertions(+), 1 deletion(-)<br>
>><br>
><br>
</div></div>Not sure the v2 was really Xenial but agreed its confusing...<br>
<br>
</blockquote></div><br></div>