mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "André Almeida" <andrealmeid@igalia.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Christian Brauner <brauner@kernel.org>,
	Miklos Szeredi <miklos@szeredi.hu>,
	linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernel-dev@igalia.com, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] ovl: Allow mount options to be parsed on remount
Date: Thu, 22 May 2025 11:30:48 -0300	[thread overview]
Message-ID: <35eded72-c2a0-4bec-9b7f-a4e39f20030a@igalia.com> (raw)
In-Reply-To: <CAOQ4uxg6RCJf6OBzKgaWbOKn3JhtgWhD6t=yOfufHuJ7jwxKmw@mail.gmail.com>

Em 22/05/2025 06:52, Amir Goldstein escreveu:
> On Thu, May 22, 2025 at 8:20 AM André Almeida <andrealmeid@igalia.com> wrote:
>>
>> Hi Christian, Amir,
>>
>> Thanks for the feedback :)
>>
>> Em 21/05/2025 08:20, Christian Brauner escreveu:
>>> On Wed, May 21, 2025 at 12:35:57PM +0200, Amir Goldstein wrote:
>>>> On Wed, May 21, 2025 at 8:45 AM André Almeida <andrealmeid@igalia.com> wrote:
>>>>>
>>
>> [...]
>>
>>>>
>>>> I see the test generic/623 failure - this test needs to be fixed for overlay
>>>> or not run on overlayfs.
>>>>
>>>> I do not see those other 5 failures although before running the test I did:
>>>> export LIBMOUNT_FORCE_MOUNT2=always
>>>>
>>>> Not sure what I am doing differently.
>>>>
>>
>> I have created a smaller reproducer for this, have a look:
>>
>>    mkdir -p ovl/lower ovl/upper ovl/merge ovl/work ovl/mnt
>>    sudo mount -t overlay overlay -o lowerdir=ovl/lower,upperdir=ovl/
>> upper,workdir=ovl/work ovl/mnt
>>    sudo mount ovl/mnt -o remount,ro
>>
> 
> Why would you use this command?
> Why would you want to re-specify the lower/upperdir when remounting ro?
> And more specifically, fstests does not use this command in the tests
> that you mention that they fail, so what am I missing?
> 

I've added "set -x" to tests/generic/294 to see exactly which mount 
parameters were being used and I got this from the output:

+ _try_scratch_mount -o remount,ro
+ local mount_ret
+ '[' overlay == overlay ']'
+ _overlay_scratch_mount -o remount,ro
+ echo '-o remount,ro'
+ grep -q remount
+ /usr/bin/mount /tmp/dir2/ovl-mnt -o remount,ro
mount: /tmp/dir2/ovl-mnt: fsconfig() failed: ...

So, from what I can see, fstests is using this command. Not sure if I 
did something wrong when setting up fstests.

>> And this returns:
>>
>>    mount: /tmp/ovl/mnt: fsconfig() failed: overlay: No changes allowed in
>>    reconfigure.
>>          dmesg(1) may have more information after failed mount system call.
>>
>> However, when I use mount like this:
>>
>>    sudo mount -t overlay overlay -o remount,ro ovl/mnt
>>
>> mount succeeds. Having a look at strace, I found out that the first
>> mount command tries to set lowerdir to "ovl/lower" again, which will to
>> return -EINVAL from ovl_parse_param():
>>
>>      fspick(3, "", FSPICK_NO_AUTOMOUNT|FSPICK_EMPTY_PATH) = 4
>>      fsconfig(4, FSCONFIG_SET_STRING, "lowerdir", "/tmp/ovl/lower", 0) =
>> -1 EINVAL (Invalid argument)
>>
>> Now, the second mount command sets just the "ro" flag, which will return
>> after vfs_parse_sb_flag(), before getting to ovl_parse_param():
>>
>>      fspick(3, "", FSPICK_NO_AUTOMOUNT|FSPICK_EMPTY_PATH) = 4
>>      fsconfig(4, FSCONFIG_SET_FLAG, "ro", NULL, 0) = 0
>>
>> After applying my patch and running the first mount command again, we
>> can set that this flag is set only after setting all the strings:
>>
>>      fsconfig(4, FSCONFIG_SET_STRING, "lowerdir", "/tmp/ovl/lower", 0) = 0
>>      fsconfig(4, FSCONFIG_SET_STRING, "upperdir", "/tmp/ovl/upper", 0) = 0
>>      fsconfig(4, FSCONFIG_SET_STRING, "workdir", "/tmp/ovl/work", 0) = 0
>>      fsconfig(4, FSCONFIG_SET_STRING, "uuid", "on", 0) = 0
>>      fsconfig(4, FSCONFIG_SET_FLAG, "ro", NULL, 0) = 0
>>
>> I understood that the patch that I proposed is wrong, and now I wonder
>> if the kernel needs to be fixed at all, or if the bug is how mount is
>> using fsconfig() in the first mount command?
> 
> Maybe I am not reading your report correctly, but as this commands works:
> 
> mount -t overlay overlay -o remount,ro ovl/mnt
> 
> and the fstests that call _scratch_remount() work
> I don't think there is anything to fix and I do not understand
> what is the complaint.
> 
> Thanks,
> Amir.


  reply	other threads:[~2025-05-22 14:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-21  6:42 André Almeida
2025-05-21 10:35 ` Amir Goldstein
2025-05-21 11:20   ` Christian Brauner
2025-05-22  6:20     ` André Almeida
2025-05-22  9:52       ` Amir Goldstein
2025-05-22 14:30         ` André Almeida [this message]
2025-05-22 15:13           ` Amir Goldstein
2025-05-22 15:22             ` André Almeida
2025-05-25 10:39               ` 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=35eded72-c2a0-4bec-9b7f-a4e39f20030a@igalia.com \
    --to=andrealmeid@igalia.com \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=kernel-dev@igalia.com \
    --cc=linux-fsdevel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®