From: Andrea Righi <andrea.righi@canonical.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-tip-commits@vger.kernel.org,
Borislav Petkov <bp@alien8.de>,
x86@kernel.org
Subject: Re: [tip: x86/entry] x86/entry: Build thunk_$(BITS) only if CONFIG_PREEMPTION=y
Date: Thu, 21 Jan 2021 11:15:44 +0100 [thread overview]
Message-ID: <YAlUUBs2qPIqLgCt@xps-13-7390> (raw)
In-Reply-To: <YAlAr1Gs+Jm4r5o7@xps-13-7390>
On Thu, Jan 21, 2021 at 09:52:01AM +0100, Andrea Righi wrote:
> On Thu, Jan 21, 2021 at 08:49:28AM +0100, Ingo Molnar wrote:
> >
> > * tip-bot2 for Andrea Righi <tip-bot2@linutronix.de> wrote:
> >
> > > The following commit has been merged into the x86/entry branch of tip:
> > >
> > > Commit-ID: e6d92b6680371ae1aeeb6c5eb2387fdc5d9a2c89
> > > Gitweb: https://git.kernel.org/tip/e6d92b6680371ae1aeeb6c5eb2387fdc5d9a2c89
> > > Author: Andrea Righi <andrea.righi@canonical.com>
> > > AuthorDate: Thu, 14 Jan 2021 12:48:35 +01:00
> > > Committer: Ingo Molnar <mingo@kernel.org>
> > > CommitterDate: Thu, 21 Jan 2021 08:11:52 +01:00
> > >
> > > x86/entry: Build thunk_$(BITS) only if CONFIG_PREEMPTION=y
> > >
> > > With CONFIG_PREEMPTION disabled, arch/x86/entry/thunk_64.o is just an
> > > empty object file.
> > >
> > > With the newer binutils (tested with 2.35.90.20210113-1ubuntu1) the GNU
> > > assembler doesn't generate a symbol table for empty object files and
> > > objtool fails with the following error when a valid symbol table cannot
> > > be found:
> > >
> > > arch/x86/entry/thunk_64.o: warning: objtool: missing symbol table
> > >
> > > To prevent this from happening, build thunk_$(BITS).o only if
> > > CONFIG_PREEMPTION is enabled.
> > >
> > > BugLink: https://bugs.launchpad.net/bugs/1911359
> > >
> > > Fixes: 320100a5ffe5 ("x86/entry: Remove the TRACE_IRQS cruft")
> > > Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
> > > Signed-off-by: Ingo Molnar <mingo@kernel.org>
> > > Cc: Borislav Petkov <bp@alien8.de>
> > > Link: https://lore.kernel.org/r/YAAvk0UQelq0Ae7+@xps-13-7390
> >
> > Hm, this fails to build on UML defconfig:
> >
> > /home/mingo/gcc/cross/lib/gcc/x86_64-linux/9.3.1/../../../../x86_64-linux/bin/ld: arch/x86/um/../entry/thunk_64.o: in function `preempt_schedule_thunk':
> > /home/mingo/tip.cross/arch/x86/um/../entry/thunk_64.S:34: undefined reference to `preempt_schedule'
> > /home/mingo/gcc/cross/lib/gcc/x86_64-linux/9.3.1/../../../../x86_64-linux/bin/ld: arch/x86/um/../entry/thunk_64.o: in function `preempt_schedule_notrace_thunk':
> > /home/mingo/tip.cross/arch/x86/um/../entry/thunk_64.S:35: undefined reference to `preempt_schedule_notrace'
> >
> > Thanks,
> >
> > Ingo
>
> I've been able to reproduce it, I'm looking at this right now. Thanks!
I see, basically UML selects ARCH_NO_PREEMPT, but in
arch/x86/um/Makefile it explicitly includes thunk_$(BITS).o regardless.
Considering that thunk_$(BITS) only contains preemption code now, we can
probably drop it from the Makefile, or, to be more consistent with the
x86 change, we could include it only if CONFIG_PREEMPTION is enabled
(even if it would never be, because UML has ARCH_NO_PREEMPT).
If it's unlikely that preemption will be enabled in UML one day I'd
probably go with the former, otherwise I'd go with the latter, because
it looks more consistent.
Opinions?
Thanks,
-Andrea
prev parent reply other threads:[~2021-01-21 10:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-14 11:48 [PATCH] x86/entry: build thunk_$(BITS) only if CONFIG_PREEMPTION=y Andrea Righi
2021-01-21 7:14 ` [tip: x86/entry] x86/entry: Build " tip-bot2 for Andrea Righi
2021-01-21 7:49 ` Ingo Molnar
2021-01-21 8:51 ` Andrea Righi
2021-01-21 10:15 ` Andrea Righi [this message]
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=YAlUUBs2qPIqLgCt@xps-13-7390 \
--to=andrea.righi@canonical.com \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@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.