All of lore.kernel.org
 help / color / mirror / Atom feed
From: Colin Ian King <colin.king@canonical.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	overlayfs <linux-unionfs@vger.kernel.org>,
	kernel-janitors@vger.kernel.org,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ovl: create UUIDs for file systems that do not set the superblock UUID
Date: Thu, 7 Nov 2019 09:43:59 +0000	[thread overview]
Message-ID: <bba96a64-a9f7-cd03-e00b-8ee369520ae7@canonical.com> (raw)
In-Reply-To: <f88a4ef7-3e2a-9e17-1573-3594288091cd@canonical.com>

On 07/11/2019 09:12, Colin Ian King wrote:
> On 07/11/2019 08:45, Colin Ian King wrote:
>> On 07/11/2019 07:08, Amir Goldstein wrote:
>>> On Thu, Nov 7, 2019 at 1:43 AM Colin King <colin.king@canonical.com> wrote:
>>>>
>>>> From: Colin Ian King <colin.king@canonical.com>
>>>>
>>>> Some file systems such as squashfs do not set the UUID in the
>>>> superblock resulting in a zero'd UUID.  In cases were two or more
>>>> of these file systems are overlayed on the lower layer we can hit
>>>> overlay corruption issues because identical zero'd overlayfs UUIDs
>>>> are impossible to differentiate between.  This can be fixed by
>>>> creating an overlayfs UUID based on the file system from the
>>>> superblock s_magic and s_dev fields.  (This currently seems like
>>>> enough information to be able create a UUID, but the could be
>>>> scope to use other super block fields such as the pointer s_fs_info
>>>> but may need some obfuscation).
>>>>
>>>
>>> The fix is incorrent. uuid stored in xattr needs to have persistent properties.
>>> In the use case that you describe, the origin file handle should simply be
>>> ignored.
>>>
>>> Please test attached patch.
>>
>> Thanks for the patch. Tested, and the error still occurs:
>>
>> [  163.959633] overlayfs: invalid origin (etc/.pwd.lock, ftype=8000,
>> origin ftype=4000).
> 
> Added debug, seems like nouuid is not being set to true, nouuid is false
> on the layers 0 and 1.

So nouuid is not being set in ovl_lower_uuid_ok() because the code is
returning early because of the following statement:

if (!ofs->config.nfs_export && !(ofs->config.index && ofs->upper_mnt))
	return true;

..and not getting to the following for-loop.

> 
>>
>> Colin
>>
>>>
>>> Thanks,
>>> Amir.
>>>
>>
> 

WARNING: multiple messages have this Message-ID (diff)
From: Colin Ian King <colin.king@canonical.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	overlayfs <linux-unionfs@vger.kernel.org>,
	kernel-janitors@vger.kernel.org,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ovl: create UUIDs for file systems that do not set the superblock UUID
Date: Thu, 07 Nov 2019 09:43:59 +0000	[thread overview]
Message-ID: <bba96a64-a9f7-cd03-e00b-8ee369520ae7@canonical.com> (raw)
In-Reply-To: <f88a4ef7-3e2a-9e17-1573-3594288091cd@canonical.com>

On 07/11/2019 09:12, Colin Ian King wrote:
> On 07/11/2019 08:45, Colin Ian King wrote:
>> On 07/11/2019 07:08, Amir Goldstein wrote:
>>> On Thu, Nov 7, 2019 at 1:43 AM Colin King <colin.king@canonical.com> wrote:
>>>>
>>>> From: Colin Ian King <colin.king@canonical.com>
>>>>
>>>> Some file systems such as squashfs do not set the UUID in the
>>>> superblock resulting in a zero'd UUID.  In cases were two or more
>>>> of these file systems are overlayed on the lower layer we can hit
>>>> overlay corruption issues because identical zero'd overlayfs UUIDs
>>>> are impossible to differentiate between.  This can be fixed by
>>>> creating an overlayfs UUID based on the file system from the
>>>> superblock s_magic and s_dev fields.  (This currently seems like
>>>> enough information to be able create a UUID, but the could be
>>>> scope to use other super block fields such as the pointer s_fs_info
>>>> but may need some obfuscation).
>>>>
>>>
>>> The fix is incorrent. uuid stored in xattr needs to have persistent properties.
>>> In the use case that you describe, the origin file handle should simply be
>>> ignored.
>>>
>>> Please test attached patch.
>>
>> Thanks for the patch. Tested, and the error still occurs:
>>
>> [  163.959633] overlayfs: invalid origin (etc/.pwd.lock, ftype€00,
>> origin ftype@00).
> 
> Added debug, seems like nouuid is not being set to true, nouuid is false
> on the layers 0 and 1.

So nouuid is not being set in ovl_lower_uuid_ok() because the code is
returning early because of the following statement:

if (!ofs->config.nfs_export && !(ofs->config.index && ofs->upper_mnt))
	return true;

..and not getting to the following for-loop.

> 
>>
>> Colin
>>
>>>
>>> Thanks,
>>> Amir.
>>>
>>
> 

  reply	other threads:[~2019-11-07  9:43 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-06 23:43 [PATCH] ovl: create UUIDs for file systems that do not set the superblock UUID Colin King
2019-11-06 23:43 ` Colin King
2019-11-07  7:08 ` Amir Goldstein
2019-11-07  7:08   ` Amir Goldstein
2019-11-07  7:18   ` Dan Carpenter
2019-11-07  7:18     ` Dan Carpenter
2019-11-07  8:45   ` Colin Ian King
2019-11-07  8:45     ` Colin Ian King
2019-11-07  9:12     ` Colin Ian King
2019-11-07  9:12       ` Colin Ian King
2019-11-07  9:43       ` Colin Ian King [this message]
2019-11-07  9:43         ` Colin Ian King
2019-11-07  9:56         ` Amir Goldstein
2019-11-07  9:56           ` Amir Goldstein

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=bba96a64-a9f7-cd03-e00b-8ee369520ae7@canonical.com \
    --to=colin.king@canonical.com \
    --cc=amir73il@gmail.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.