Messages in this thread | | | Date | Sun, 3 Jul 2022 13:39:21 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH v4 0/5] cpumask: Fix invalid uniprocessor assumptions |
| |
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.
| |