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

Stefan Bader stefan.bader at canonical.com
Tue Aug 2 13:07:20 UTC 2022


On 02.08.22 14:22, Andrea Righi wrote:
> On Tue, Aug 02, 2022 at 11:42:55AM +0300, Alexander Mikhalitsyn wrote:
>>>>> 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.
> 
> So, IIUC we need the chunk of code from AUFS to introduce vm_prfile,
> then this fix needs to be changed to use vm_prfile (like we do in focal)
> even without AUFS.
> 
> Basically this is what you've done with hwe-5.17, right?
> 
>>
>>>
>>>>
>>>>> 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.
> 
> Yes, I mean focal/hwe-5.15 (that is derived from jammy/linux) and ok, no
> rush to have the focal patch, I was just pointing out that we need to
> fix also this kernel to make everything aligned/consistent.
> 
>>
>>>
>>> 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 ;)
> 
> Hm... not sure why you're experiencing this problem, I'll ask around. :)

You get moderated because you are not subscribed to the mailing list. You can be 
added as an exception but you could as well subscribe for now and unsubscribe 
later. Would have the advantage that you see replies even if people forget to 
reply to all. ;)

-Stefan

> 
> Thanks,
> -Andrea

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20220802/e67af5dc/attachment.sig>


More information about the kernel-team mailing list