mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Andy Lutomirski <luto@kernel.org>,
	dave.hansen@linux.intel.com, LKML <linux-kernel@vger.kernel.org>,
	x86@kernel.org, Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: x86/pti: smp_processor_id() called while preemptible in resume-from-sleep
Date: Sat, 30 Dec 2017 19:20:04 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1712301916020.1899@nanos> (raw)
In-Reply-To: <20171230153054.GA1604@light.dominikbrodowski.net>

On Sat, 30 Dec 2017, Dominik Brodowski wrote:

> On Sat, Dec 30, 2017 at 04:03:07PM +0100, Thomas Gleixner wrote:
> > On Sat, 30 Dec 2017, Dominik Brodowski wrote:
> > > resume-from-sleep (mem/S3) on v4.15-rc5-149-g5aa90a845892 triggers the
> > > following bug. If I boot with "pti=off", the kernel does not show this
> > > issue, and neither did kernels before pti was merged:
> > > 
> > > [   39.951703] ACPI: Low-level resume complete
> > > [   39.951832] ACPI: EC: EC started
> > > [   39.951840] PM: Restoring platform NVS memory
> > > [   39.954648] Enabling non-boot CPUs ...
> > > [   39.954792] x86: Booting SMP configuration:
> > > [   39.954800] smpboot: Booting Node 0 Processor 1 APIC 0x2
> > > [   39.954834] BUG: using smp_processor_id() in preemptible [00000000] code: sh/465
> > > [   39.954841] caller is native_cpu_up+0x2f0/0xa30
> > 
> > I can't reproduce at the moment and I can't find a possible reason for this
> > by code inspection.
> 
> Thanks for taking a look at it!
> 
> > Can you please provide your .config file
> 
> See attached.
> 
> > and perhaps decode the two offending call sites with
> > 
> >   scripts/faddr2line vmlinux native_cpu_up+0x2f0/0xa30 native_cpu_up+0x447/0xa30
> 
> native_cpu_up+0x2f0/0xa30:
> invalidate_user_asid at arch/x86/include/asm/tlbflush.h:343

Ah, that makes sense. Missed that in the maze.

What makes less sense is that tlbflush itself. I'm surely missing something
subtle, but from a first look that tlbflush is pointless.

>  (inlined by) __native_flush_tlb at arch/x86/include/asm/tlbflush.h:351
>  (inlined by) smpboot_setup_warm_reset_vector at arch/x86/kernel/smpboot.c:129
>  (inlined by) do_boot_cpu at arch/x86/kernel/smpboot.c:950
>  (inlined by) native_cpu_up at arch/x86/kernel/smpboot.c:1070
> 
> native_cpu_up+0x447/0xa30:
> kern_pcid at arch/x86/include/asm/tlbflush.h:105
>  (inlined by) invalidate_user_asid at arch/x86/include/asm/tlbflush.h:342
>  (inlined by) __native_flush_tlb at arch/x86/include/asm/tlbflush.h:351
>  (inlined by) smpboot_restore_warm_reset_vector at arch/x86/kernel/smpboot.c:146

This one even more so as the stale comment suggests, that there was some
page table fiddling at some point in the past.

>  (inlined by) do_boot_cpu at arch/x86/kernel/smpboot.c:1022
>  (inlined by) native_cpu_up at arch/x86/kernel/smpboot.c:1070

Let me think about it and do some archaeological research.

Thanks,

	tglx

  parent reply	other threads:[~2017-12-30 18:20 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-30 13:29 Dominik Brodowski
2017-12-30 15:03 ` Thomas Gleixner
2017-12-30 15:30   ` Dominik Brodowski
2017-12-30 17:51     ` Dave Hansen
2017-12-30 18:21       ` Thomas Gleixner
2017-12-30 18:20     ` Thomas Gleixner [this message]
2017-12-30 18:40       ` Linus Torvalds
2017-12-30 19:03         ` Dave Hansen
2017-12-30 19:15           ` Linus Torvalds
2017-12-30 19:32             ` Andy Lutomirski
2017-12-30 19:41         ` Thomas Gleixner
2017-12-30 20:00           ` Linus Torvalds
2017-12-30 20:28         ` Thomas Gleixner
2017-12-30 20:45           ` Linus Torvalds
2017-12-30 20:47           ` Thomas Gleixner
2017-12-30 20:49             ` Linus Torvalds

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=alpine.DEB.2.20.1712301916020.1899@nanos \
    --to=tglx@linutronix.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --cc=luto@kernel.org \
    --cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®