Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <a5b3bc76d48acb8fde00aa95c6a572d7922c050c.camel@svanheule.net>
Subject: Re: [PATCH v5 0/5] cpumask: fix invalid uniprocessor assumptions
From:   Sander Vanheule <sander@svanheule.net>
To:     Yury Norov <yury.norov@gmail.com>,
        Andrew Morton <akpm@linux-foundation.org>
Cc:     linux-kernel@vger.kernel.org,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Brendan Higgins <brendanhiggins@google.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        David Gow <davidgow@google.com>,
        Borislav Petkov <bp@alien8.de>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "H . Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
        =?ISO-8859-1?Q?Ma=EDra?= Canal <mairacanal@riseup.net>,
        Marco Elver <elver@google.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Valentin Schneider <vschneid@redhat.com>
Date:   Sun, 31 Jul 2022 15:02:55 +0200
In-Reply-To: <YuV1J7Zt+NzkrWeV@yury-laptop>
References: <cover.1659077534.git.sander@svanheule.net>
         <YuV1J7Zt+NzkrWeV@yury-laptop>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.3 (3.44.3-1.fc36) 
MIME-Version: 1.0
Precedence: bulk

On Sat, 2022-07-30 at 11:15 -0700, Yury Norov wrote:
> On Fri, Jul 29, 2022 at 09:01:17AM +0200, Sander Vanheule 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.
> >=20
> > 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.
> >=20
> > This series introduces some basic tests, and updates the optimisations
> > for uniprocessor builds.
> >=20
> > 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 th=
e
> > changes to cpumask.h, in an attempt to find any other cases that fail o=
n
> > !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.
> >=20
> > [1] https://lore.kernel.org/all/20220530082552.46113-1-sander@svanheule=
.net/
> > [2] https://lore.kernel.org/all/202206060858.wA0FOzRy-lkp@intel.com/
> =C2=A0
> Hi Sander,
>=20
> I tried to apply it on top of bitmap-for next, and there are many conflic=
ts
> with already pulled patches. There's nothing really scary, just functions
> changed their prototypes and locations. Can you try your series on top of
> bitmap-for-next from git@github.com:/norov/linux.git (or just -next)?=20
>=20
> I'm asking you to do it instead of doing myself because I don't want to
> screwup your code accidentally and because many cpumask functions in -nex=
t
> are moved to the header, and it would be probably possible to avoid build=
ing=20
> cpumask.o in UP case.
>=20
> Briefly looking into the -next code, cpumask.c hosts=C2=A0 only cpumask_n=
ext_wrap()
> that is not overwritten by UP code, and in UP case it can be simplified.

Sure. I've rebased my patches and added a UP-version for cpumask_next_wrap(=
), so
cpumask.o doesn't have to be built anymore in that case.

How would you like to proceed with these patches? It's fine by me if you ta=
ke
them through your tree to avoid more merge conflicts with your changes, but=
 then
Andrew woud have to drop the series from mm-nonmm-stable.

Best,
Sander