NACK: [SRU][J][master-next][PATCH] UBUNTU: SAUCE: overlayfs: remove CONFIG_AUFS_FS dependency

[Alexander Mikhalitsyn]

On Tue, 2 Aug 2022 10:12:55 +0200
Andrea Righi <andrea.righi at canonical.com> wrote:

> On Tue, Aug 02, 2022 at 11:04:23AM +0300, Alexander Mikhalitsyn wrote:
> > On Tue, 2 Aug 2022 09:05:31 +0200
> > Andrea Righi <andrea.righi at canonical.com> wrote:
> > 
> > > On Tue, Aug 02, 2022 at 12:50:43AM +0300, Alexander Mikhalitsyn wrote:
> > > > BugLink: https://bugs.launchpad.net/bugs/1967924
> > > > BugLink: https://bugs.launchpad.net/bugs/1857257
> > > > 
> > > > BugLink: https://bugs.launchpad.net/bugs/1967924
> > > > 
> > > > Right now we have a fix:
> > > > b07bc17b ("UBUNTU: SAUCE: overlayfs: fix incorrect mnt_id of files opened from map_files")
> > > > in master branch of Jammy kernel, but only formaly. Because these kernels compiled without
> > > > CONFIG_AUFS_FS set, so this fix just disabled. There is no need to make it dependent on
> > > > CONFIG_AUFS_FS option, because in all cases we have mm/prfile.c compiled-in.
> > > > 
> > > > Cc: Andrei Vagin <avagin at gmail.com>
> > > > Cc: Adrian Reber <areber at redhat.com>
> > > > Cc: Stefan Bader <stefan.bader at canonical.com>
> > > > Cc: Kleber Sacilotto de Souza <kleber.souza at canonical.com>
> > > > Cc: Krzysztof Kozlowski <krzysztof.kozlowski at canonical.com>
> > > > Cc: Andrea Righi <andrea.righi at canonical.com>
> > > > 
> > > > Fixes: b07bc17b ("UBUNTU: SAUCE: overlayfs: fix incorrect mnt_id of files opened from map_files")
> > > > Signed-off-by: Alexander Mikhalitsyn <alexander.mikhalitsyn at virtuozzo.com>
> > 
> > Hi Andrea,
> > 
> > > 
> > > It's true that we don't need this in Jammy, but we need it in focal for
> > > the hwe kernels, where we still need to support AUFS. So, we decided to
> > 
> > I'm sorry, but I don't understand your point.
> > 
> > This patch *completely* independent of CONFIG_AUFS_FS it only relies on
> > the *one* small piece of code from aufs:
> > https://github.com/sfjro/aufs5-linux/commit/f8a27912904bdc40a27f434a9b6d19f56e7fb3b6
> > which is present in the master-next branch.
> > 
> > And this code is always compiled-in regardless of the CONFIG_AUFS_FS kernel.
> > 
> > But for this branch we need to remove this check because it makes this fix totally useless and users are still facing issues with overlayfs.
> 
> Does it mean that this fix isn't really fixing the issue with overlayfs?

Yes, because Ubuntu Jammy kernels was built without CONFIG_AUFS_FS, so this patch is just no-op.
Example:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1967924/comments/21
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1967924/comments/24

> In this case we should definitely drop it, but in this case I would
> rephrase the commit description, mentioning that the fix is not correct.

I believe that we just need to apply this fixup patch to the original one and squash it to one commit.

> 
> > 
> > > keep it also in Jammy, even if, as you correctly mentioned, it's just
> > > formal change, since this patch is a no-op with AUFS disabled, but it
> > > helps to maintain the code especially when we need to release new hwe
> > > kernels.
> > 
> > I've prepared corresponding separate (!) patches for hwe-5.17 branch. Please take a look.
> 
> Oh, I see now that you sent a patch set against hwe-5.17. We may also
> want to fix this properly in hwe-5.15 as well. Do you have a patch for
> 5.15 already?

I can't see hwe-5.15 branch for jammy here:
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy/

Or you mean hwe-5.15 focal? Of course, I'm ready to send patches for focal too. I've just started working on Jammy. After getting review I'm ready to send follow up patches for focal branches too.

> 
> Thanks for the clarification,
> -Andrea

Thanks for your attention to this bug! It's a real pain for CRIU users ;-)

offtop: for some reason my emails getting posted on
https://lists.ubuntu.com/archives/kernel-team/2022-August/thread.html
very slowly. Should I ask lists admins about that? Or possibly, the problem is that
each my email should be checked manually by list admin because of spam?
I wonder If my email can be added to trusted senders, I've no plan to send marketing to this lists right now ;)

Regards,
Alex