linux-unionfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Fabian <godi.beat@gmx.net>
Cc: overlayfs <linux-unionfs@vger.kernel.org>
Subject: Re: overlayfs: issue with a replaced lower squashfs with export-table
Date: Mon, 6 Jul 2020 17:29:51 +0300	[thread overview]
Message-ID: <CAOQ4uxjm7i+uO4o4470ACctsft1m18EiUpxBfCeT-Wyqf1FAYg@mail.gmail.com> (raw)
In-Reply-To: <32532923.JtPX5UtSzP@fgdesktop>

[-- Attachment #1: Type: text/plain, Size: 2440 bytes --]

Hi Fabian,

On Mon, Jul 6, 2020 at 4:28 PM Fabian <godi.beat@gmx.net> wrote:
>
> Hope this is the right list for asking overlayfs <-> squashfs related issues.

Yes.

> Else please let me know where to ask.
>
> We are seeing problems using an read-writeable overlayfs (upper) on a readonly
> squashfs (lower). The squashfs gets an update from time to time while we keep
> the upper overlayfs.
>

It gets updated while the overlay is offline (not mounted) correct?

> On replaced files we then see -ESTALE ("overlayfs: failed to get inode (-116)")
> messages if the lower squashfs was created _without_ using the "-no-exports"
> switch.
> The -ESTALE comes from ovl_get_inode() which in turn calls ovl_verify_inode()
> and returns on the line where the upperdentry inode gets compared
> ( if (upperdentry && ovl_inode_upper(inode) != d_inode(upperdentry)) ).
>
> A little debugging shows, that the upper files dentry name does not fit to the
> dentry name of the new lower dentry as it seems to look for the inode on the
> squashfs "export"-lookup-table which has changed as we replaced the lower fs.
>
> Building the lower squashfs with the "-no-exports"-mksquashfs option, so
> without the export-lookup-table, seems to work, but it might be no longer
> exportable using nfs (which is ok and we can keep with it).
>
> As we didn't find any other information regarding this behaviour or anyone who
> also had this problem before we just want to know if this is the right way to
> use the rw overlayfs on a (replaceable) ro squashfs filesystem.
>
> Is this a known issue? Is it really needed to disable the export feature when
> using overlayfs on a squashfs if we later need to replace squashfs during an
> update? Any hints we can have a look on if this should work and we might have
> done wrong during squashfs or overlayfs creation?
>

This sounds like an unintentional outcome of:
9df085f3c9a2 ovl: relax requirement for non null uuid of lower fs

Which enabled nfs_export for overlay with lower squashfs.

If you do not need to export overlayfs to NFS, then you can check if the
attached patch solves your problem.

If you do need to export overlayfs to NFS or to export squashfs to NFS
for that matter, you will have a problem, because when re-creating
squashfs (I suppose) all file handles are re-assigned randomly to new
files, so they have no meaning in the context of NFS file handles exported
in the old squashfs.

Thanks,
Amir.

[-- Attachment #2: ovl-fix-regression-with-re-formatted-lower-squashfs.patch.txt --]
[-- Type: text/plain, Size: 1484 bytes --]

From 8e9f532ce419ae72ba47b49582342377780a32db Mon Sep 17 00:00:00 2001
From: Amir Goldstein <amir73il@gmail.com>
Date: Mon, 6 Jul 2020 17:21:21 +0300
Subject: [PATCH] ovl: fix regression with re-formatted lower squashfs

Relax the requirement for non null uuid only if user opts-in to
index=on or nfs_export=on to avoid regressions with overlay that
is migrated to a newly formatted lower squashfs.

Reported-by: Fabian <godi.beat@gmx.net>
Fixes: 9df085f3c9a2 ("ovl: relax requirement for non null uuid...")
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---
 fs/overlayfs/super.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c
index 15939ab39c1c..af95f83e3a70 100644
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -1402,6 +1402,16 @@ static bool ovl_lower_uuid_ok(struct ovl_fs *ofs, const uuid_t *uuid)
 	if (!ofs->config.nfs_export && !ovl_upper_mnt(ofs))
 		return true;
 
+	/*
+	 * We allow using single lower with null uuid for index and nfs_export
+	 * for example to support those features with single lower squashfs.
+	 * To avoid regressions setups of overlay with re-formatted lower
+	 * squashfs do not allow decoding origin with lower null uuid unless
+	 * index or nfs_export are explicitly enabled.
+	 */
+	if (!ofs->config.index && uuid_is_null(uuid))
+		return false;
+
 	for (i = 0; i < ofs->numfs; i++) {
 		/*
 		 * We use uuid to associate an overlay lower file handle with a
-- 
2.17.1


  reply	other threads:[~2020-07-06 14:30 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-06 13:27 overlayfs: issue with a replaced lower squashfs with export-table Fabian
2020-07-06 14:29 ` Amir Goldstein [this message]
2020-07-06 15:14   ` Fabian
2020-07-06 15:33     ` Amir Goldstein
2020-07-06 16:10       ` Fabian
2020-07-06 17:14         ` Amir Goldstein
2020-07-16 13:29           ` Fabian Godehardt
2020-07-07  5:51     ` Amir Goldstein
2020-07-07 15:51       ` Vivek Goyal
2020-07-07 17:41         ` Amir Goldstein
2020-07-07 21:53           ` Vivek Goyal
2020-07-08  6:55             ` Amir Goldstein
2020-07-08  8:00               ` Miklos Szeredi
2020-07-08  8:31                 ` Amir Goldstein
2020-07-08  8:37                   ` Miklos Szeredi
2020-07-08  8:50                     ` Amir Goldstein
2020-07-08 14:23                       ` Vivek Goyal
2020-07-08 14:26                         ` Vivek Goyal
2020-07-08 17:26                           ` Amir Goldstein
2020-07-08 17:36                             ` Vivek Goyal

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=CAOQ4uxjm7i+uO4o4470ACctsft1m18EiUpxBfCeT-Wyqf1FAYg@mail.gmail.com \
    --to=amir73il@gmail.com \
    --cc=godi.beat@gmx.net \
    --cc=linux-unionfs@vger.kernel.org \
    /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).