ACK: [PATCH 1/1] UBUNTU: SAUCE: Enable upstream config option "CONFIG_CPUSETS_V1"

Edoardo Canepa edoardo.canepa at canonical.com
Thu Dec 18 09:27:38 UTC 2025


Acked-by: Edoardo Canepa <edoardo.canepa at canonical.com>

On 12/18/25 09:51, Mehmet Basaran wrote:
> BugLink: https://bugs.launchpad.net/bugs/2128722
>
> For noble , some of the applied upstream commits are using "CONFIG_CPUSETS_V1"
> to enable/disable some code paths. This changes the behaviour of cpusets and
> currently noble is neither V1 nor V2. Because of this, "cpuset_inherit" and
> "cpuset_hotplug" test cases are failing in ubuntu_ltp_controllers test suite.
> For noble, since this is an LTS release we should continue behave like V1.
>
> Added "CONFIG_CPUSETS_V1" kernel config option. This was added to upstream
> via the following commit:
>
>      commit 1abab1ba0775036bb67c6c57945c637be644c04f
>      cgroup/cpuset: guard cpuset-v1 code under CONFIG_CPUSETS_V1
>
> I have chosen to go with a SAUCE patch since, the commit above depends on
> other commits. And in the future, we can revert this one and apply the
> dependent commits if we want to follow cpusets follow from 6.12 versions so
> that there are less conflicts between upstream stable and noble sources.
>
> The other solution is to remove the use of "CONFIG_CPUSETS_V1" macro from
> sources. However this will also cause noble and upstream stable sources to
> diverge and make it difficult to backport patches.
>
> Signed-off-by: Mehmet Basaran <mehmet.basaran at canonical.com>
> ---
>   debian.master/config/annotations |  1 +
>   init/Kconfig                     | 13 +++++++++++++
>   2 files changed, 14 insertions(+)
>
> diff --git a/debian.master/config/annotations b/debian.master/config/annotations
> index 9ebb2a92ba55..3f3150b3aa99 100644
> --- a/debian.master/config/annotations
> +++ b/debian.master/config/annotations
> @@ -3293,6 +3293,7 @@ CONFIG_CPU5_WDT                                 policy<{'amd64': 'm'}>
>   CONFIG_CPUFREQ_DT_PLATDEV                       policy<{'arm64': 'y', 'armhf': 'y', 'ppc64el': 'y', 'riscv64': 'y'}>
>   CONFIG_CPUMASK_OFFSTACK                         policy<{'amd64': 'y'}>
>   CONFIG_CPUSETS                                  policy<{'amd64': 'y', 'arm64': 'y', 'armhf': 'y', 'ppc64el': 'y', 'riscv64': 'y', 's390x': 'y'}>
> +CONFIG_CPUSETS_V1                               policy<{'amd64': 'y', 'arm64': 'y', 'armhf': 'y', 'ppc64el': 'y', 'riscv64': 'y', 's390x': 'y'}>
>   CONFIG_CPU_32v6K                                policy<{'armhf': 'y'}>
>   CONFIG_CPU_32v7                                 policy<{'armhf': 'y'}>
>   CONFIG_CPU_ABRT_EV7                             policy<{'armhf': 'y'}>
> diff --git a/init/Kconfig b/init/Kconfig
> index 426c2464f653..3b728ed594cc 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1143,6 +1143,19 @@ config CPUSETS
>   
>   	  Say N if unsure.
>   
> +config CPUSETS_V1
> +       bool "Legacy cgroup v1 cpusets controller"
> +       depends on CPUSETS
> +       default n
> +       help
> +         Legacy cgroup v1 cpusets controller which has been deprecated by
> +         cgroup v2 implementation. The v1 is there for legacy applications
> +         which haven't migrated to the new cgroup v2 interface yet. If you
> +         do not have any such application then you are completely fine leaving
> +         this option disabled.
> +
> +         Say N if unsure.
> +
>   config PROC_PID_CPUSET
>   	bool "Include legacy /proc/<pid>/cpuset file"
>   	depends on CPUSETS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x20F88172E14F6784.asc
Type: application/pgp-keys
Size: 3167 bytes
Desc: OpenPGP public key
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20251218/54323461/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20251218/54323461/attachment-0001.sig>


More information about the kernel-team mailing list