[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.2308072124320.38537@angie.orcam.me.uk>
Date: Mon, 7 Aug 2023 21:37:00 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Borislav Petkov <bp@...en8.de>
cc: Arnd Bergmann <arnd@...db.de>, Arnd Bergmann <arnd@...nel.org>,
linux-kernel@...r.kernel.org, x86@...nel.org,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH 2/5] [RESEND] x86: avoid unneeded __div64_32 function
definition
On Wed, 2 Aug 2023, Borislav Petkov wrote:
> > --- a/arch/x86/include/asm/div64.h
> > +++ b/arch/x86/include/asm/div64.h
> > @@ -71,6 +71,11 @@ static inline u64 mul_u32_u32(u32 a, u32 b)
> > }
> > #define mul_u32_u32 mul_u32_u32
> >
> > +/*
> > + * __div64_32() is never called on x86, so prevent the
> > + * generic definition from getting built.
> > + */
> > +#define __div64_32
> >
> > #else
> > # include <asm-generic/div64.h>
>
> Yap.
Hmm, shouldn't this be something like:
#define __div64_32(n, base) BUILD_BUG()
instead?
Otherwise you risk `__div64_32(n, base)' getting expanded to `(n, base)',
if the macro does get called mistakenly for some reason, and the expansion
is a valid expression which may not produce a warning even, depending on
usage.
Maciej
Powered by blists - more mailing lists