On Fri, Jun 06, 2025 at 12:58:24PM +0200, Amir Goldstein wrote: > On Fri, Jun 6, 2025 at 12:35 PM Zorro Lang <zlang@xxxxxxxxxx> wrote: > > > > On Fri, Jun 06, 2025 at 09:35:36AM +0200, Amir Goldstein wrote: > > > On Fri, Jun 6, 2025 at 3:12 AM Zorro Lang <zlang@xxxxxxxxxx> wrote: > > > > > > > > On Thu, Jun 05, 2025 at 08:30:53PM +0200, Amir Goldstein wrote: > > > > > On Thu, Jun 5, 2025 at 7:51 PM Zorro Lang <zlang@xxxxxxxxxx> wrote: > > > > > > > > > > > > On Tue, Jun 03, 2025 at 12:07:40PM +0200, Amir Goldstein wrote: > > > > > > > libmount >= v1.39 calls several unneeded fsconfig() calls to reconfigure > > > > > > > lowerdir/upperdir when user requests only -o remount,ro. > > > > > > > > > > > > > > Those calls fail because overlayfs does not allow making any config > > > > > > > changes with new mount api, besides MS_RDONLY. > > > > > > > > > > > > > > We workaround this problem with --options-mode ignore. > > > > > > > > > > > > > > Reported-by: André Almeida <andrealmeid@xxxxxxxxxx> > > > > > > > Suggested-by: Karel Zak <kzak@xxxxxxxxxx> > > > > > > > Link: https://lore.kernel.org/linux-fsdevel/20250521-ovl_ro-v1-1-2350b1493d94@xxxxxxxxxx/ > > > > > > > Link: https://lore.kernel.org/fstests/CAJfpegtJ3SDKmC80B4AfWiC3JmtWdW2+78fRZVtsuhe-wSRPvg@xxxxxxxxxxxxxx/ > > > > > > > Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx> > > > > > > > --- > > > > > > > > > > > > > > Changes since v1 [1]: > > > > > > > - Change workaround from LIBMOUNT_FORCE_MOUNT2 to --options-mode=ignore > > > > > > > > > > > > > > [1] https://lore.kernel.org/fstests/20250526143500.1520660-1-amir73il@xxxxxxxxx/ > > > > > > > > > > > > I'm not sure if I understand clearly. Does overlay list are fixing this issue > > > > > > on kernel side, then providing a workaround to fstests to avoid the issue be > > > > > > triggered too? > > > > > > > > > > > > > > > > Noone agreed to fix it on the kernel side. > > > > > At least not yet. > > > > > > > > If so, I have two questions:) > > > > 1) Will overlay fix it on kernel or mount util side? > > > > > > This is not known at this time. > > > > Oh, I thought it's getting fix :-D > > > > > > > > > 2) Do you plan to keep this workaround until the issue be fixed in one day? > > > > Then revert this workaround? > > > > > > Maybe, but keep in mind that the workaround is simply > > > telling the library what we want to do. > > > > > > We want to remount overlay ro and nothing else and that is exactly > > > what "--options-mode ignore" tells the library to do. > > > > > > I could have just as well written a test helper src/remount_rdonly.c > > > and not have to deal with the question of which libmount version > > > the test machine is using. > > > > > > Note that the tests in question are not intended to test the remount,ro > > > functionality itself, they are intended to test the behavior of fs in > > > some scenarios involving a rdonly mount. > > > > > > I do not want to lose important test coverage of these scenarios > > > because of regressions in the kernel/libmount API. > > > > > > We can add a new test that ONLY tests remount,ro and let that > > > test fail on overlayfs to keep us reminded of the real regresion that > > > needs to be fixed, but the "workaround" or as I prefer to call it > > > "using the right tool for the test case" has to stay for those other tests. > > > > OK, I just tried to figure out if "hide this error output on new mount APIs" > > is what overlay list wants. If overlay list (or vfs) acks this patch, and > > will track this issue. I'm good to merge this workaround for testing :) > > > > This workaround in v2 was suggested by libmount maintainer > and approved by overlayfs maintainer: > > "> So, you do not need LIBMOUNT_FORCE_MOUNT2= workaround, use > > "--options-mode ignore" or source and target ;-) > > Yeah, that's definitely a better workaround. > > I wouldn't call it a fix, since "mount -oremount,ro /overlay" still > doesn't work the way it is supposed to, and the thought of adding code > to the kernel to work around the current libmount behavior makes me go > bleah." OK, just to make sure overlay/vfs folks know why these failures gone :) Reviewed-by: Zorro Lang <zlang@xxxxxxxxxx> With this patch, I've merged 5 patches of this patchset. Now only 4/6 still need more reviewing (I've provided my suggestion about that). If patch 4/6 can't catch up the release of this week, don't worry, I'll push these 5 patches at first, feel free to send patch 4/6 singly later :) Thanks, Zorro > > Thanks, > Amir. > > [1] https://lore.kernel.org/linux-unionfs/CAJfpegtJ3SDKmC80B4AfWiC3JmtWdW2+78fRZVtsuhe-wSRPvg@xxxxxxxxxxxxxx/ >
