All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: kernel test robot <lkp@intel.com>,
	Andy Lutomirski <luto@kernel.org>,
	kbuild-all@lists.01.org, Borislav Petkov <bp@suse.de>,
	x86@kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] x86/entry: Fix noinstr violation
Date: Thu, 8 Jul 2021 21:02:16 +0200	[thread overview]
Message-ID: <YOdLuAL6rRDzMPDX@kroah.com> (raw)
In-Reply-To: <87y2agodn9.ffs@nanos.tec.linutronix.de>

On Thu, Jul 08, 2021 at 08:37:30PM +0200, Thomas Gleixner wrote:
> On Thu, Jul 08 2021 at 15:37, Thomas Gleixner wrote:
> > The recent commit which fixed the entry/exit mismatch on failed 32-bit
> > syscalls got the ordering vs. instrumentation_end() wrong, which makes
> > objtool complain about tracer invocation in an instrumentation disabled
> > region.
> >
> > Stick the offending local_irq_disable() into the instrumentation enabled
> > region so objtool stops complaining.
> >
> > Fixes: 5d5675df792f ("x86/entry: Fix entry/exit mismatch on failed fast 32-bit syscalls")
> 
> Bah. I looked at the wrong branch. It's fixed already in Linus tree:
> 
> commit 240001d4e3041832e8a2654adc3ccf1683132b92
> Author: Peter Zijlstra <peterz@infradead.org>
> Date:   Mon Jun 21 13:12:34 2021 +0200
> 
>     x86/entry: Fix noinstr fail in __do_fast_syscall_32()
> 
> Though that lacks a CC: stable tag, which would have been appropriate
> because 5d5675df792f ("x86/entry: Fix entry/exit mismatch on failed fast
> 32-bit syscalls") has been backported.
> 
> Can the stable folks pick this up please?

It's already in 5.10.47 and 5.12.14.  Does it need to go further back to
older kernels?

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: kbuild-all@lists.01.org
Subject: Re: [PATCH] x86/entry: Fix noinstr violation
Date: Thu, 08 Jul 2021 21:02:16 +0200	[thread overview]
Message-ID: <YOdLuAL6rRDzMPDX@kroah.com> (raw)
In-Reply-To: <87y2agodn9.ffs@nanos.tec.linutronix.de>

[-- Attachment #1: Type: text/plain, Size: 1233 bytes --]

On Thu, Jul 08, 2021 at 08:37:30PM +0200, Thomas Gleixner wrote:
> On Thu, Jul 08 2021 at 15:37, Thomas Gleixner wrote:
> > The recent commit which fixed the entry/exit mismatch on failed 32-bit
> > syscalls got the ordering vs. instrumentation_end() wrong, which makes
> > objtool complain about tracer invocation in an instrumentation disabled
> > region.
> >
> > Stick the offending local_irq_disable() into the instrumentation enabled
> > region so objtool stops complaining.
> >
> > Fixes: 5d5675df792f ("x86/entry: Fix entry/exit mismatch on failed fast 32-bit syscalls")
> 
> Bah. I looked at the wrong branch. It's fixed already in Linus tree:
> 
> commit 240001d4e3041832e8a2654adc3ccf1683132b92
> Author: Peter Zijlstra <peterz@infradead.org>
> Date:   Mon Jun 21 13:12:34 2021 +0200
> 
>     x86/entry: Fix noinstr fail in __do_fast_syscall_32()
> 
> Though that lacks a CC: stable tag, which would have been appropriate
> because 5d5675df792f ("x86/entry: Fix entry/exit mismatch on failed fast
> 32-bit syscalls") has been backported.
> 
> Can the stable folks pick this up please?

It's already in 5.10.47 and 5.12.14.  Does it need to go further back to
older kernels?

thanks,

greg k-h

  reply	other threads:[~2021-07-08 19:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-29  5:05 [stable:linux-5.10.y 3202/6129] vmlinux.o: warning: objtool: __do_fast_syscall_32()+0x98: call to trace_hardirqs_off() leaves .noinstr.text section kernel test robot
2021-07-08 13:37 ` [PATCH] x86/entry: Fix noinstr violation Thomas Gleixner
2021-07-08 18:37   ` Thomas Gleixner
2021-07-08 18:37     ` Thomas Gleixner
2021-07-08 19:02     ` Greg Kroah-Hartman [this message]
2021-07-08 19:02       ` Greg Kroah-Hartman
2021-07-08 19:17       ` Thomas Gleixner
2021-07-08 19:17         ` Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YOdLuAL6rRDzMPDX@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=bp@suse.de \
    --cc=kbuild-all@lists.01.org \
    --cc=lkp@intel.com \
    --cc=luto@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.