The test generic/645 is failing on (at least) 6.6, 6.1, 5.15 LTS kernels.
This fix is apparently commit dacfd001eaf2 ("fs/mnt_idmapping.c: Return -EINVAL when no map is written"), but in order to take this patch, it looks like we need to backport the 4 patch series "mnt_idmapping: decouple from namespaces"[1] (and possibly others; I haven't tried yet).
[1] https://lore.kernel.org/all/20231122-vfs-mnt_idmap-v1-0-dae4abdde5bd@kernel....
This looks fairly involved so the questions I have are:
(1) Should we request this patch series plus commit dacfd001eaf2 into the stable kernels --- or should I just add a versioned excludes[2] and just skip generic/645 from all kernels older than Linux 6.9 if we think it's too involved and/or risky to backport these id mapping changes?
(2) How much do we care that generic/645 is failing on LTS kernels? Are user/applications going to notice or care?
Thanks,
- Ted
[2] Like this:
diff --git a/test-appliance/files/root/fs/global_exclude b/test-appliance/files/root/fs/global_exclude index d7acf89f..42902152 100644 --- a/test-appliance/files/root/fs/global_exclude +++ b/test-appliance/files/root/fs/global_exclude @@ -30,6 +30,14 @@ generic/484 generic/554 #endif
+#if LINUX_VERSION_CODE < KERNEL_VERSION(6,9,0) +// This test failure is fixed by commit dacfd001eaf2 +// ("fs/mnt_idmapping.c: Return -EINVAL when no map is written"), +// but it's too involved to backport it and its dependencies to +// the LTS kernels. +generic/645 +#endif + #ifndef IS_DAX_CONFIG // Unless we are testing the dax config, we can exclude all dax tests -g dax
On Sun, Nov 10, 2024 at 01:05:33PM -0500, Theodore Ts'o wrote:
The test generic/645 is failing on (at least) 6.6, 6.1, 5.15 LTS kernels.
This fix is apparently commit dacfd001eaf2 ("fs/mnt_idmapping.c: Return -EINVAL when no map is written"), but in order to take this patch, it looks like we need to backport the 4 patch series "mnt_idmapping: decouple from namespaces"[1] (and possibly others; I haven't tried yet).
[1] https://lore.kernel.org/all/20231122-vfs-mnt_idmap-v1-0-dae4abdde5bd@kernel....
This looks fairly involved so the questions I have are:
(1) Should we request this patch series plus commit dacfd001eaf2 into the stable kernels --- or should I just add a versioned excludes[2] and just skip generic/645 from all kernels older than Linux 6.9 if we think it's too involved and/or risky to backport these id mapping changes?
(2) How much do we care that generic/645 is failing on LTS kernels? Are user/applications going to notice or care?
No userspace used an empty idmapping and it was unclear whether the behavior would be well-specified so the patch changed that quite some time ago.
Backporting this to older LTS kernels isn't difficult. We just need custom patches for the LTS kernels but they should all be very simple.
Alternatively, you can just ignore the test on older kernels.
On Mon, Nov 11, 2024 at 09:52:07AM +0100, Christian Brauner wrote:
behavior would be well-specified so the patch changed that quite some time ago.
Backporting this to older LTS kernels isn't difficult. We just need custom patches for the LTS kernels but they should all be very simple.
Alternatively, you can just ignore the test on older kernels.
Well, what the custom patch to look like wasn't obvious to me, but that's because I'm not sufficiently familiar with the id mapping code.
So I'll just ignore the test on older kernels. If someone wants to create the custom patch, I'll revert the versioned exclude for {kvm,gce}-xfsteests.
Thanks,
- Ted
On Fri, Nov 15, 2024 at 08:34:07AM -0500, Theodore Ts'o wrote:
On Mon, Nov 11, 2024 at 09:52:07AM +0100, Christian Brauner wrote:
behavior would be well-specified so the patch changed that quite some time ago.
Backporting this to older LTS kernels isn't difficult. We just need custom patches for the LTS kernels but they should all be very simple.
Alternatively, you can just ignore the test on older kernels.
Well, what the custom patch to look like wasn't obvious to me, but that's because I'm not sufficiently familiar with the id mapping code.
So I'll just ignore the test on older kernels. If someone wants to create the custom patch, I'll revert the versioned exclude for {kvm,gce}-xfsteests.
Thanks,
- Ted
Hi,
We did notice this as well during our internal testing. I'm unfamiliar with the code but after spending some time I came up with the following patch that did fix it for us (it's a rough patch, might not apply cleanly to any stable kernel). Again, I'm not 100% sure if this is the right place to patch it but if it looks good to peopel more familiar with the area then I can try to send the backports to the stable.
--- fs/namespace.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/fs/namespace.c b/fs/namespace.c index 7906c5327f4f..368a60e48861 100644 --- a/fs/namespace.c +++ b/fs/namespace.c @@ -3995,6 +3995,12 @@ static int can_idmap_mount(const struct mount_kattr *kattr, struct mount *mnt) if (!kattr->mnt_idmap) return 0;
+ /* Don't allow idmaps with no mapping defined */ + if (kattr->mnt_userns->uid_map.nr_extents == 0 || + kattr->mnt_userns->gid_map.nr_extents == 0) + return -EINVAL; + + /* * Creating an idmapped mount with the filesystem wide idmapping * doesn't make sense so block that. We don't allow mushy semantics.
linux-stable-mirror@lists.linaro.org
-
Christian Brauner -
Matthew Wilcox -
Ojaswin Mujoo -
Theodore Ts'o