All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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, 08 Jul 2021 21:17:12 +0200	[thread overview]
Message-ID: <87r1g8obt3.ffs@nanos.tec.linutronix.de> (raw)
In-Reply-To: <YOdLuAL6rRDzMPDX@kroah.com>

On Thu, Jul 08 2021 at 21:02, Greg Kroah-Hartman wrote:
> 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?

I was reacting on the syzbot report which was against 5.10.y and
completely missed that it had checked out exactly the offending commit.

So if it's already backported, nothing to see. The original commit which
got fixed by 5d5675df792f is 0b085e68f407 and that was introduced in 5.9
which is EOL.

Sorry for the noise.

Thanks,

        tglx


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

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

On Thu, Jul 08 2021 at 21:02, Greg Kroah-Hartman wrote:
> 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?

I was reacting on the syzbot report which was against 5.10.y and
completely missed that it had checked out exactly the offending commit.

So if it's already backported, nothing to see. The original commit which
got fixed by 5d5675df792f is 0b085e68f407 and that was introduced in 5.9
which is EOL.

Sorry for the noise.

Thanks,

        tglx

  reply	other threads:[~2021-07-08 19:17 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
2021-07-08 19:02       ` Greg Kroah-Hartman
2021-07-08 19:17       ` Thomas Gleixner [this message]
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=87r1g8obt3.ffs@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=bp@suse.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=kbuild-all@lists.01.org \
    --cc=lkp@intel.com \
    --cc=luto@kernel.org \
    --cc=stable@vger.kernel.org \
    --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.