| Message ID | 20220310015306.445359-2-ammarfaizi2@gnuweeb.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Two x86 fixes | expand |
On Thu, Mar 10, 2022 at 08:53:05AM +0700, Ammar Faizi wrote: > The asm constraint does not reflect that the asm statement can modify > the value of @loops. But the asm statement in delay_loop() does modify > the @loops. > > Specifiying the wrong constraint may lead to undefined behavior, it may > clobber random stuff (e.g. local variable, important temporary value in > regs, etc.). This is especially dangerous when the compiler decides to inline the function and since it doesn't know that the value gets modified, it might decide to use it from a register directly without reloading it. Add that to the commit message pls. > Fix this by changing the constraint from "a" (as an input) to "+a" (as > an input and output). > > Cc: David Laight <David.Laight@ACULAB.COM> > Cc: Thomas Gleixner <tglx@linutronix.de> > Cc: Ingo Molnar <mingo@redhat.com> > Cc: Borislav Petkov <bp@alien8.de> > Cc: Dave Hansen <dave.hansen@linux.intel.com> > Cc: "H. Peter Anvin" <hpa@zytor.com> > Cc: Jiri Hladky <hladky.jiri@googlemail.com> All those Ccs in the commit message are not really needed - get_maintainers.pl gives the correct list already. > Cc: stable@vger.kernel.org # v2.6.27+ I don't see the need for the stable Cc. Or do you have a case where a corruption really does happen? > Fixes: e01b70ef3eb ("x86: fix bug in arch/i386/lib/delay.c file, delay_loop function") Commit sha1 (e01b70ef3eb) needs to be at least 12 chars long: e01b70ef3eb3 ("x86: fix bug in arch/i386/lib/delay.c file, delay_loop function") This is best fixed by doing: [core] abbrev = 12 in your .git/config > Signed-off-by: Ammar Faizi <ammarfaizi2@gnuweeb.org> > --- > arch/x86/lib/delay.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/lib/delay.c b/arch/x86/lib/delay.c > index 65d15df6212d..0e65d00e2339 100644 > --- a/arch/x86/lib/delay.c > +++ b/arch/x86/lib/delay.c > @@ -54,8 +54,8 @@ static void delay_loop(u64 __loops) > " jnz 2b \n" > "3: dec %0 \n" > > - : /* we don't need output */ > - :"a" (loops) > + : "+a" (loops) > + : > ); Thx.
On 3/28/22 4:38 AM, Borislav Petkov wrote: > All those Ccs in the commit message are not really needed - > get_maintainers.pl gives the correct list already. > >> Cc: stable@vger.kernel.org # v2.6.27+ > > I don't see the need for the stable Cc. Or do you have a case where > a corruption really does happen? > >> Fixes: e01b70ef3eb ("x86: fix bug in arch/i386/lib/delay.c file, delay_loop function") > > Commit sha1 (e01b70ef3eb) needs to be at least 12 chars long: > > e01b70ef3eb3 ("x86: fix bug in arch/i386/lib/delay.c file, delay_loop function") > > This is best fixed by doing: > > [core] > abbrev = 12 > > in your .git/config Will fix that in the v6.
On 3/28/22 4:38 AM, Borislav Petkov wrote: > On Thu, Mar 10, 2022 at 08:53:05AM +0700, Ammar Faizi wrote: >> The asm constraint does not reflect that the asm statement can modify >> the value of @loops. But the asm statement in delay_loop() does modify >> the @loops. >> >> Specifiying the wrong constraint may lead to undefined behavior, it may >> clobber random stuff (e.g. local variable, important temporary value in >> regs, etc.). > > This is especially dangerous when the compiler decides to inline the > function and since it doesn't know that the value gets modified, it > might decide to use it from a register directly without reloading it. > > Add that to the commit message pls. Will add that in the v6. >> Cc: stable@vger.kernel.org # v2.6.27+ > > I don't see the need for the stable Cc. Or do you have a case where > a corruption really does happen? I don't find any visible issue on this. But that's undefined behavior, different compiler may yield different result (e.g. there is no guarantee newer compilers will produce the appropriate result due to UB). So it's not something we should rely on. ============ Side note for inline: Even if it is not inlined, it's still dangerous, because if the compiler is able to see that the function to be called doesn't clobber some call-clobbered regs, the compiler can assume the call-clobbered regs are not clobbered and it reuses the value without reloading. See the example from Alviro here: https://lore.kernel.org/lkml/CAOG64qPgTv5tQNknuG9d-=oL2EPQQ1ys7xu2FoBpNLyzv1qYzA@mail.gmail.com/
On Mon, Mar 28, 2022 at 11:29:26AM +0700, Ammar Faizi wrote: > See the example from Alviro here: > > https://lore.kernel.org/lkml/CAOG64qPgTv5tQNknuG9d-=oL2EPQQ1ys7xu2FoBpNLyzv1qYzA@mail.gmail.com/ Not the same thing - see David's reply there.
diff --git a/arch/x86/lib/delay.c b/arch/x86/lib/delay.c index 65d15df6212d..0e65d00e2339 100644 --- a/arch/x86/lib/delay.c +++ b/arch/x86/lib/delay.c @@ -54,8 +54,8 @@ static void delay_loop(u64 __loops) " jnz 2b \n" "3: dec %0 \n" - : /* we don't need output */ - :"a" (loops) + : "+a" (loops) + : ); }
The asm constraint does not reflect that the asm statement can modify the value of @loops. But the asm statement in delay_loop() does modify the @loops. Specifiying the wrong constraint may lead to undefined behavior, it may clobber random stuff (e.g. local variable, important temporary value in regs, etc.). Fix this by changing the constraint from "a" (as an input) to "+a" (as an input and output). Cc: David Laight <David.Laight@ACULAB.COM> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Jiri Hladky <hladky.jiri@googlemail.com> Cc: stable@vger.kernel.org # v2.6.27+ Fixes: e01b70ef3eb ("x86: fix bug in arch/i386/lib/delay.c file, delay_loop function") Signed-off-by: Ammar Faizi <ammarfaizi2@gnuweeb.org> --- arch/x86/lib/delay.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)