arch/x86/kernel/cpu/cacheinfo.c | 6 ++ arch/x86/kernel/smpboot.c | 4 - include/linux/cpumask.h | 108 +++++++------------------ lib/Kconfig.debug | 9 +++ lib/Makefile | 4 +- lib/cpumask.c | 2 + lib/test_cpumask.c | 138 ++++++++++++++++++++++++++++++++ 7 files changed, 184 insertions(+), 87 deletions(-) create mode 100644 lib/test_cpumask.c
On uniprocessor builds, it is currently assumed that any cpumask will contain the single CPU: cpu0. This assumption is used to provide optimised implementations. The current assumption also appears to be wrong, by ignoring the fact that users can provide empty cpumask-s. This can result in bugs as explained in [1]. This series introduces some basic tests, and updates the optimisations for uniprocessor builds. The x86 patch was written after the kernel test robot [2] ran into a failed build. I have tried to list the files potentially affected by the changes to cpumask.h, in an attempt to find any other cases that fail on !SMP. I've gone through some of the files manually, and ran a few cross builds, but nothing else popped up. I (build) checked about half of the potientally affected files, but I do not have the resources to do them all. I hope we can fix other issues if/when they pop up later. [1] https://lore.kernel.org/all/20220530082552.46113-1-sander@svanheule.net/ [2] https://lore.kernel.org/all/202206060858.wA0FOzRy-lkp@intel.com/ Changes since v3: Link: https://lore.kernel.org/all/cover.1654410109.git.sander@svanheule.net/ - Guard againts CPU hotpluggin while testing cpu online/present masks - Add fix for cpu_llc_shared_map on x86 Changes since v2: Link: https://lore.kernel.org/all/cover.1654362935.git.sander@svanheule.net/ - Put new tests after patch fixes - Update for_each_* macros Changes since v1: Link: https://lore.kernel.org/all/cover.1654201862.git.sander@svanheule.net/ - Place tests in lib/test_cpumask.c - Drop the modified UP code in favor of the generic SMP implementation - Update declaration of cpumask_next_wrap() Sander Vanheule (5): x86/cacheinfo: move shared cache map definitions cpumask: Fix invalid uniprocessor mask assumption lib/test: Introduce cpumask KUnit test suite cpumask: Add UP optimised for_each_*_cpu versions cpumask: Update cpumask_next_wrap() signature arch/x86/kernel/cpu/cacheinfo.c | 6 ++ arch/x86/kernel/smpboot.c | 4 - include/linux/cpumask.h | 108 +++++++------------------ lib/Kconfig.debug | 9 +++ lib/Makefile | 4 +- lib/cpumask.c | 2 + lib/test_cpumask.c | 138 ++++++++++++++++++++++++++++++++ 7 files changed, 184 insertions(+), 87 deletions(-) create mode 100644 lib/test_cpumask.c -- 2.36.1
On Sat, 2 Jul 2022 18:08:23 +0200 Sander Vanheule <sander@svanheule.net> wrote: > On uniprocessor builds, it is currently assumed that any cpumask will > contain the single CPU: cpu0. This assumption is used to provide > optimised implementations. > > The current assumption also appears to be wrong, by ignoring the fact > that users can provide empty cpumask-s. This can result in bugs as > explained in [1]. It's a little unkind to send people off to some link to explain the very core issue which this patchset addresses! So I enhanced this paragraph: : The current assumption also appears to be wrong, by ignoring the fact that : users can provide empty cpumasks. This can result in bugs as explained in : [1] - for_each_cpu() will run one iteration of the loop even when passed : an empty cpumask. > This series introduces some basic tests, and updates the optimisations > for uniprocessor builds. > > The x86 patch was written after the kernel test robot [2] ran into a > failed build. I have tried to list the files potentially affected by the > changes to cpumask.h, in an attempt to find any other cases that fail on > !SMP. I've gone through some of the files manually, and ran a few cross > builds, but nothing else popped up. I (build) checked about half of the > potientally affected files, but I do not have the resources to do them > all. I hope we can fix other issues if/when they pop up later. > > [1] https://lore.kernel.org/all/20220530082552.46113-1-sander@svanheule.net/ > [2] https://lore.kernel.org/all/202206060858.wA0FOzRy-lkp@intel.com/
On Sat, 2022-07-02 at 13:38 -0700, Andrew Morton wrote: > On Sat, 2 Jul 2022 18:08:23 +0200 Sander Vanheule <sander@svanheule.net> wrote: > > > On uniprocessor builds, it is currently assumed that any cpumask will > > contain the single CPU: cpu0. This assumption is used to provide > > optimised implementations. > > > > The current assumption also appears to be wrong, by ignoring the fact > > that users can provide empty cpumask-s. This can result in bugs as > > explained in [1]. > > It's a little unkind to send people off to some link to explain the > very core issue which this patchset addresses! So I enhanced this > paragraph: > > : The current assumption also appears to be wrong, by ignoring the fact that > : users can provide empty cpumasks. This can result in bugs as explained in > : [1] - for_each_cpu() will run one iteration of the loop even when passed > : an empty cpumask. Makes sense to add this, sorry for the inconvenience. Just to make sure, since I'm not familiar with the process for patches going through the mm tree, can I still send a v5 to move the last patch forward in the series, and to include Yury's tags? Best, Sander > > This series introduces some basic tests, and updates the optimisations > > for uniprocessor builds. > > > > The x86 patch was written after the kernel test robot [2] ran into a > > failed build. I have tried to list the files potentially affected by the > > changes to cpumask.h, in an attempt to find any other cases that fail on > > !SMP. I've gone through some of the files manually, and ran a few cross > > builds, but nothing else popped up. I (build) checked about half of the > > potientally affected files, but I do not have the resources to do them > > all. I hope we can fix other issues if/when they pop up later. > > > > [1] https://lore.kernel.org/all/20220530082552.46113-1-sander@svanheule.net/ > > [2] https://lore.kernel.org/all/202206060858.wA0FOzRy-lkp@intel.com/ >
On Sun, 03 Jul 2022 09:50:51 +0200 Sander Vanheule <sander@svanheule.net> wrote: > On Sat, 2022-07-02 at 13:38 -0700, Andrew Morton wrote: > > On Sat, 2 Jul 2022 18:08:23 +0200 Sander Vanheule <sander@svanheule.net> wrote: > > > > > On uniprocessor builds, it is currently assumed that any cpumask will > > > contain the single CPU: cpu0. This assumption is used to provide > > > optimised implementations. > > > > > > The current assumption also appears to be wrong, by ignoring the fact > > > that users can provide empty cpumask-s. This can result in bugs as > > > explained in [1]. > > > > It's a little unkind to send people off to some link to explain the > > very core issue which this patchset addresses! So I enhanced this > > paragraph: > > > > : The current assumption also appears to be wrong, by ignoring the fact that > > : users can provide empty cpumasks. This can result in bugs as explained in > > : [1] - for_each_cpu() will run one iteration of the loop even when passed > > : an empty cpumask. > > Makes sense to add this, sorry for the inconvenience. > > Just to make sure, since I'm not familiar with the process for patches going through the mm tree, Patches enter -mm in quilt form and are published in the (rebasing) mm-unstable branch git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm. Once they have stopped changing and have been stabilized, I move them into the non-rebasing mm-stable branch. > can I still send a v5 to move the last patch forward in the series, and to include Yury's tags? I already added Yury's ack. Please tell me the specific patch ordering and I'll take care of that.
Hi Andrew, On Sun, 2022-07-03 at 13:39 -0700, Andrew Morton wrote: > On Sun, 03 Jul 2022 09:50:51 +0200 Sander Vanheule <sander@svanheule.net> > wrote: > > > On Sat, 2022-07-02 at 13:38 -0700, Andrew Morton wrote: > > > On Sat, 2 Jul 2022 18:08:23 +0200 Sander Vanheule <sander@svanheule.net> > > > wrote: > > > > > > > On uniprocessor builds, it is currently assumed that any cpumask will > > > > contain the single CPU: cpu0. This assumption is used to provide > > > > optimised implementations. > > > > > > > > The current assumption also appears to be wrong, by ignoring the fact > > > > that users can provide empty cpumask-s. This can result in bugs as > > > > explained in [1]. > > > > > > It's a little unkind to send people off to some link to explain the > > > very core issue which this patchset addresses! So I enhanced this > > > paragraph: > > > > > > : The current assumption also appears to be wrong, by ignoring the fact > > > that > > > : users can provide empty cpumasks. This can result in bugs as explained > > > in > > > : [1] - for_each_cpu() will run one iteration of the loop even when passed > > > : an empty cpumask. > > > > Makes sense to add this, sorry for the inconvenience. > > > > Just to make sure, since I'm not familiar with the process for patches going > > through the mm tree, > > Patches enter -mm in quilt form and are published in the (rebasing) > mm-unstable branch > git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm. Once they have > stopped changing and have been stabilized, I move them into the > non-rebasing mm-stable branch. > > > can I still send a v5 to move the last patch forward in the series, and to > > include Yury's tags? > > I already added Yury's ack. Please tell me the specific patch ordering > and I'll take care of that. > The updated patch order should be: x86/cacheinfo: move shared cache map definitions cpumask: add UP optimised for_each_*_cpu versions cpumask: fix invalid uniprocessor mask assumption lib/test: introduce cpumask KUnit test suite cpumask: update cpumask_next_wrap() signature Reordering the patches on my tree didn't produce any conflicts. Best, Sander
On Sun, 10 Jul 2022 08:51:08 +0200 Sander Vanheule <sander@svanheule.net> wrote: > > > can I still send a v5 to move the last patch forward in the series, and to > > > include Yury's tags? > > > > I already added Yury's ack. Please tell me the specific patch ordering > > and I'll take care of that. > > > > The updated patch order should be: > x86/cacheinfo: move shared cache map definitions > cpumask: add UP optimised for_each_*_cpu versions > cpumask: fix invalid uniprocessor mask assumption > lib/test: introduce cpumask KUnit test suite > cpumask: update cpumask_next_wrap() signature > > Reordering the patches on my tree didn't produce any conflicts. Got it, thanks.
© 2016 - 2026 Red Hat, Inc.