On Thu, Feb 4, 2021 at 6:36 AM Peter Zijlstra wrote:
>
> refcount_dec_and_lock() avoids that complication.
There isn't currently an interface for raw_spin_locks. Certainly could
add a new interface in a separate patch as part of this series, but
doesn't seem that bad to do the locking inline.
On Thu, Feb 4, 2021 at 6:02 AM Peter Zijlstra wrote:
>
> On Fri, Jan 22, 2021 at 08:17:01PM -0500, Joel Fernandes (Google) wrote:
>
> > +#ifdef CONFIG_SCHED_DEBUG
> > + /* Read the group cookie. */
> > + {
> > + .name = "core_group_cookie",
> > + .flags =
On Thu, Feb 4, 2021 at 5:54 AM Peter Zijlstra wrote:
>
> On Fri, Jan 22, 2021 at 08:17:01PM -0500, Joel Fernandes (Google) wrote:
> > From: Peter Zijlstra
>
> I'm thinking this is too much credit, I didn't write much of this.
>
> > Marks all tasks in a cgroup as matching for core-scheduling.
> >
tch fixed the unwinder failure mode to be the above
(harmless) unwinder warning, instead of a disruptive KASAN failure.
This patch fixes the specific underlying crypto unwinding metadata
issue.
I'll definitely be sending both fixes. The improved failure mode patch
will come first because it's more urgent and lower risk.
--
Josh
On Wed, Feb 03, 2021 at 09:44:48PM -0500, Steven Rostedt wrote:
> > > [ 128.441287][C0] RIP: 0010:skcipher_walk_next
> > > (crypto/skcipher.c:322 crypto/skcipher.c:384)
>
> Why do we have an RIP in skcipher_walk_next, if its the unwinder that
> had a bug? Or are they related?
>
> Or did
mit a fix for decode_stacktrace.sh).
> I cannot reproduce this one, and it took 2 days of uptime for it to
> happen. Is there anything I can do to help diagnose it?
Can you run with the same unwind_debug patch+cmdline when you try to
recreate this one? In the meantime I'll look at the available data.
--
Josh
On Wed, Feb 03, 2021 at 03:30:35PM -0800, Ivan Babrou wrote:
> > > > Can you recreate with this patch, and add "unwind_debug" to the cmdline?
> > > > It will spit out a bunch of stack data.
> > >
> > > Here's the three I'm building:
> > >
> > > *
On Wed, Feb 03, 2021 at 02:41:53PM -0800, Ivan Babrou wrote:
> On Wed, Feb 3, 2021 at 11:05 AM Josh Poimboeuf wrote:
> >
> > On Wed, Feb 03, 2021 at 09:46:55AM -0800, Ivan Babrou wrote:
> > > > Can you pretty please not line-wrap console output? It's unreadable.
>
s or something else?
Can you recreate with this patch, and add "unwind_debug" to the cmdline?
It will spit out a bunch of stack data.
From: Josh Poimboeuf
Subject: [PATCH] Subject: [PATCH] x86/unwind: Add 'unwind_debug' cmdline
option
Sometimes the one-line ORC unwinder warnings aren
On Wed, Feb 03, 2021 at 03:49:02PM +0100, Peter Zijlstra wrote:
> On Wed, Feb 03, 2021 at 08:42:15AM -0600, Josh Poimboeuf wrote:
> > On Wed, Feb 03, 2021 at 01:02:23PM +0100, Peter Zijlstra wrote:
> > > Currently REG_SP_INDIRECT is unused but means (%rsp + offset),
> > &
(%rbp + offset).
Offset is going to be zero, should it not work either way?
--
Josh
y as hard as possible (beyond turning objtool into a full emulator)
to avoid doing that kind of thing because objtool isn't supposed to
dictate kernel optimizations. Otherwise we would have disabled jump
tables (even for non-retpolines) a long time ago, because that's been a
serious PITA.
You might not like the plugin -- I don't like it either -- but the goal
was to avoid penalizing the kernel with "objtool-friendly"
optimizations.
That said, jump tables are such a pain for objtool (and currently
impossible to deal with for arm64) that I'm completely open to just
disabling them if they're shown to have negligible benefit for the
kernel.
--
Josh
On Tue, Feb 02, 2021 at 02:33:38PM -0800, Nick Desaulniers wrote:
> On Mon, Feb 1, 2021 at 4:02 PM Josh Poimboeuf wrote:
> >
> > On Mon, Feb 01, 2021 at 03:17:40PM -0800, Nick Desaulniers wrote:
> > > On the earlier thread, Julien writes:
> > >
> &
e to work on it.
> > > FWIW, I think the approach taken by -mstack-protector-guard-reg= is a
> > > useful case study. It was prototyped as a GCC extension, then added
> > > to GCC proper, then added to LLVM (currently only x86, but most of the
> > > machinery is in place in the compiler to get it running on arm64). My
> > > recommendation is to skip the plugin part and work on a standard
> > > interface for compilers to implement, with input from compiler
> > > developers.
> >
> > I like the idea. Is there a recommended forum for such discussions?
> > Just an email to GCC/Clang development lists?
>
> linux-toolcha...@vger.kernel.org is probably a good start.
Thanks, I'll write something up (maybe a more specific proposal) and
post it.
--
Josh
On Fri, Jan 29, 2021 at 10:10:01AM -0800, Nick Desaulniers wrote:
> On Wed, Jan 27, 2021 at 3:27 PM Josh Poimboeuf wrote:
> >
> > On Wed, Jan 27, 2021 at 02:15:57PM -0800, Nick Desaulniers wrote:
> > > > From: Raphael Gault
> > > >
> > > >
On Fri, Jan 29, 2021 at 08:17:51AM +0900, Masahiro Yamada wrote:
> [3]
> Peterz already pointed out asm-goto as an example of ABI mismatch.
>
> I remember a trouble reported in the past due
> to the mismatch of -mstack-protector-guard-offset.
>
>
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 20bf2b378729c4a0366a53e2018a0b70ace94bcd
Gitweb:
https://git.kernel.org/tip/20bf2b378729c4a0366a53e2018a0b70ace94bcd
Author:Josh Poimboeuf
AuthorDate:Thu, 28 Jan 2021 15:52:19 -06:00
On Fri, Jan 29, 2021 at 06:54:08PM +0200, Nikolay Borisov wrote:
>
>
> On 29.01.21 г. 18:49 ч., Josh Poimboeuf wrote:
> > Agreed, stable is a good idea. I think Nikolay saw it with GCC 9.
>
>
> Yes I did, with the default Ubuntu compiler as well as the default gcc-10
On Fri, Jan 29, 2021 at 05:30:48PM +0100, Borislav Petkov wrote:
> On Fri, Jan 29, 2021 at 09:10:34AM -0600, Josh Poimboeuf wrote:
> > Maybe eventually. But the enablement (actually enabling CET/CFI/etc)
> > happens in the arch code anyway, right? So it could be a per-ar
On Thu, Jan 28, 2021 at 01:45:51PM -0800, Linus Torvalds wrote:
> On Thu, Jan 28, 2021 at 1:34 PM Josh Poimboeuf wrote:
> >
> > On Thu, Jan 28, 2021 at 01:23:11PM -0800, Linus Torvalds wrote:
> > > THAT workaround is long gone, but I didn't check what other ones
currently necessary in the kernel, as CET is
only supported in user space. Disable it unconditionally.
Reported-by: Nikolay Borisov
Signed-off-by: Josh Poimboeuf
---
Makefile | 6 --
arch/x86/Makefile | 3 +++
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/Makefile b
gcc version checks we _do_ have are not
> necessarily about major versions at all (ie I trivially found checks
> for 4.9, 4.9.2, 5.1, 7.2 and 9.1).
Then maybe the check should be same major.minor?
And convert it to a strongly worded warning/disclaimer?
--
Josh
On Thu, Jan 28, 2021 at 12:24:45PM -0800, Linus Torvalds wrote:
> On Thu, Jan 28, 2021 at 12:08 PM Josh Poimboeuf wrote:
> >
> > Add a check for compiler mismatch, but only check the major version.
>
> I think this is wrong for multiple reasons.
>
> The most fund
to be built with a slightly different version of GCC
than the kernel.
A minor version mismatch should be ok. User space does it all the time.
New compiler features aren't added within a major version.
Add a check for compiler mismatch, but only check the major version.
Signed-off-by: Josh Poimboeuf
On Thu, Jan 28, 2021 at 06:45:56PM +0200, Nikolay Borisov wrote:
> On 28.01.21 г. 18:12 ч., Nikolay Borisov wrote:
> > On 28.01.21 г. 5:38 ч., Masami Hiramatsu wrote:
> >> Hi,
> >
> >
> >>
> >> Alexei, could you tell me what is the concerning situation for bpf?
> >
> > Another data point masami
yond my knowledge to
> >> assess if this build error is related to any of them.
> >>
> >> I'll stick with binutils-2.35.1 for the time being.
> >>
> >>> And what exact gcc version are you using?
> >>>
> >>
> >> It's built from the 10-20210123 snaps
eing reported, but it's beyond my knowledge to
> > assess if this build error is related to any of them.
> >
> > I'll stick with binutils-2.35.1 for the time being.
> >
> >> And what exact gcc version are you using?
> >>
> >
> > It's built fro
On Thu, Jan 28, 2021 at 02:29:52PM +, Christoph Hellwig wrote:
> On Wed, Jan 27, 2021 at 12:51:13PM -0600, Josh Poimboeuf wrote:
> > Is this a joke? I've never met anybody who builds OOT modules as a
> > development aid...
>
> I'm pretty sure you've met me before.
Ye
ow.
> Distributions (like Android, CrOS) wont be able to use such a feature as
> is.
Would a Clang plugin be out of the question?
--
Josh
On Wed, Jan 27, 2021 at 01:02:18PM -0600, Josh Poimboeuf wrote:
> On Wed, Jan 27, 2021 at 01:00:07PM -0600, Josh Poimboeuf wrote:
> > On Wed, Jan 27, 2021 at 07:44:01PM +0100, Peter Zijlstra wrote:
> > > On Wed, Jan 27, 2021 at 10:33:08AM -0600, Josh Poimboeuf wrote:
> >
On Wed, Jan 27, 2021 at 01:00:07PM -0600, Josh Poimboeuf wrote:
> On Wed, Jan 27, 2021 at 07:44:01PM +0100, Peter Zijlstra wrote:
> > On Wed, Jan 27, 2021 at 10:33:08AM -0600, Josh Poimboeuf wrote:
> >
> > > What did you think about .static_call_tramp_key? I could whi
On Wed, Jan 27, 2021 at 07:44:01PM +0100, Peter Zijlstra wrote:
> On Wed, Jan 27, 2021 at 10:33:08AM -0600, Josh Poimboeuf wrote:
>
> > What did you think about .static_call_tramp_key? I could whip up a
> > patch later unless you beat me to it.
>
> Yeah, I'm not sure.. w
On Wed, Jan 27, 2021 at 06:43:27PM +, Christoph Hellwig wrote:
> On Wed, Jan 27, 2021 at 12:38:56PM -0600, Josh Poimboeuf wrote:
> > On Wed, Jan 27, 2021 at 06:02:15PM +, Christoph Hellwig wrote:
> > > Please don't add all this garbage. We only add infrastructure t
building
out-of-tree modules. It's widely used. Are you suggesting we remove
it? Good luck with that...
Either it should be supported, or not. Make the case either way. But I
can't understand why people are advocating to leave it half-broken.
--
Josh
On Wed, Jan 27, 2021 at 05:19:02PM +0100, Peter Zijlstra wrote:
> On Wed, Jan 27, 2021 at 09:59:14AM -0600, Josh Poimboeuf wrote:
> > On Wed, Jan 27, 2021 at 12:27:09PM +0100, Peter Zijlstra wrote:
> > > On Wed, Jan 27, 2021 at 10:13:47AM +0100, Peter Zijlstra wrote:
> >
On Wed, Jan 27, 2021 at 12:27:09PM +0100, Peter Zijlstra wrote:
> On Wed, Jan 27, 2021 at 10:13:47AM +0100, Peter Zijlstra wrote:
> > On Tue, Jan 26, 2021 at 05:57:30PM -0600, Josh Poimboeuf wrote:
>
> > > Well, I hate it, but I'm not sure I have any better ideas. It sho
ad of the rb-tree/register nonsense. Not
sure about the performance impact though. Might be a good reason to
speed up kallsyms!
Also I do have some naming suggestions ;-)
--
Josh
On Tue, Jan 26, 2021 at 02:59:57PM -0800, Kees Cook wrote:
> On Tue, Jan 26, 2021 at 12:43:16PM -0600, Josh Poimboeuf wrote:
> > On Tue, Jan 26, 2021 at 09:56:10AM -0800, Kees Cook wrote:
> > > On Mon, Jan 25, 2021 at 04:19:53PM -0600, Josh Poimboeuf wrote:
> > > >
On Tue, Jan 26, 2021 at 09:56:10AM -0800, Kees Cook wrote:
> On Mon, Jan 25, 2021 at 04:19:53PM -0600, Josh Poimboeuf wrote:
> > On Mon, Jan 25, 2021 at 02:03:07PM -0800, Kees Cook wrote:
> > > On Mon, Jan 25, 2021 at 02:42:10PM -0600, Josh Poimboeuf wrote:
> > > &g
On Tue, Jan 26, 2021 at 10:15:52AM -0600, Justin Forbes wrote:
> On Tue, Jan 26, 2021 at 10:05 AM Peter Zijlstra wrote:
> >
> > On Tue, Jan 26, 2021 at 09:46:51AM -0600, Josh Poimboeuf wrote:
> > > On Tue, Jan 26, 2021 at 04:15:37PM +0100, Peter Zijlstra wrote:
> >
On Tue, Jan 26, 2021 at 04:15:37PM +0100, Peter Zijlstra wrote:
> On Tue, Jan 26, 2021 at 08:51:55AM -0600, Josh Poimboeuf wrote:
> > User space mixes compiler versions all the time. The C ABI is stable.
> >
> > What specifically is the harder issue you're referring to?
>
On Tue, Jan 26, 2021 at 02:51:29PM +0100, Greg KH wrote:
> On Tue, Jan 26, 2021 at 06:44:44AM -0600, Justin Forbes wrote:
> > On Tue, Jan 26, 2021 at 2:21 AM Greg KH wrote:
> > >
> > > On Mon, Jan 25, 2021 at 04:07:57PM -0600, Josh Poimboeuf wrote:
> > > > O
On Tue, Jan 26, 2021 at 06:16:01AM +0900, Masahiro Yamada wrote:
> On Tue, Jan 26, 2021 at 5:42 AM Josh Poimboeuf wrote:
> >
> > When building out-of-tree kernel modules, the build system doesn't
> > require the GCC version to match the version used to build the origina
ine the key. Enforce it in __static_call_update() with a call to
__builtin_return_address(0). WARN when the caller's text isn't in the
kernel proper and the flag isn't set.
Hm?
--
Josh
On Mon, Jan 25, 2021 at 02:03:07PM -0800, Kees Cook wrote:
> On Mon, Jan 25, 2021 at 02:42:10PM -0600, Josh Poimboeuf wrote:
> > When a GCC version mismatch is detected, print a warning and disable the
> > plugin. The only exception is the RANDSTRUCT plugin which needs all
ow do you propose we solve the other problem, where a missing
optional library (gcc-plugin-devel) causes the OOT module build to
silently disable the plugin? This is related to my earlier complaint
about the dangers of toolchain-dependent kconfig options.
--
Josh
On Fri, Jan 22, 2021 at 10:43:09PM +0100, Ard Biesheuvel wrote:
> On Fri, 22 Jan 2021 at 22:15, Madhavan T. Venkataraman
> wrote:
> > On 1/22/21 11:43 AM, Mark Brown wrote:
> > > On Thu, Jan 21, 2021 at 12:54:52PM -0600, Josh Poimboeuf wrote:
> > >
> >
certain libraries are missing. This is a separate problem which
also needs to be addressed.
Reported-by: Ondrej Mosnacek
Signed-off-by: Josh Poimboeuf
---
scripts/Makefile.gcc-plugins | 19 +++
scripts/Makefile.kcov| 11 +++
2 files changed, 30 insertions
On Sat, Jan 23, 2021 at 02:59:28PM -0800, Fangrui Song wrote:
> On 2020-08-28, Josh Poimboeuf wrote:
> > On Fri, Aug 28, 2020 at 12:21:13PM +0200, Miroslav Benes wrote:
> > > > Hi there! I was trying to find a super easy way to address this, so I
> > >
On Sat, Jan 23, 2021 at 03:31:20AM +0100, Sedat Dilek wrote:
> On Sat, Jan 23, 2021 at 3:26 AM Josh Poimboeuf wrote:
> >
> > On Fri, Jan 22, 2021 at 05:32:43PM -0800, Nick Desaulniers wrote:
> > > > In this specific case, find_func_by_offset returns NULL for
> &
uning from the assembler.
It's fine though. I just need to rewrite the CFI support a bit.
But that can come later. For now I'll just drop the two CFI-related
patches from this set so I can merge the others next week.
--
Josh
On Thu, Jan 21, 2021 at 11:38:54PM +0100, Sedat Dilek wrote:
> On Thu, Jan 21, 2021 at 10:29 PM Josh Poimboeuf wrote:
> >
> > v2:
> > - fix commit description for why xen hypervisor page contents don't
> > matter [Juergen]
> > - annotate indirect jumps a
The following commit has been merged into the objtool/urgent branch of tip:
Commit-ID: 655cf86548a3938538642a6df27dd359e13c86bd
Gitweb:
https://git.kernel.org/tip/655cf86548a3938538642a6df27dd359e13c86bd
Author:Josh Poimboeuf
AuthorDate:Thu, 14 Jan 2021 16:32:42 -06:00
The following commit has been merged into the objtool/urgent branch of tip:
Commit-ID: 1d489151e9f9d1647110277ff77282fe4d96d09b
Gitweb:
https://git.kernel.org/tip/1d489151e9f9d1647110277ff77282fe4d96d09b
Author:Josh Poimboeuf
AuthorDate:Thu, 14 Jan 2021 16:14:01 -06:00
ially important for patches that
> + * modify semantic of the functions.
> + */
> + obj->mod = find_klp_module(obj->name);
These comments don't make sense in this context, they should be kept
with the code in find_klp_module().
--
Josh
xen_start_kernel() doesn't return. Annotate it as such so objtool can
follow the code flow.
Signed-off-by: Josh Poimboeuf
---
tools/objtool/check.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index f88f20327bf2..5f056ddab4fa 100644
.
Cc: "Rafael J. Wysocki"
Cc: Pavel Machek
Signed-off-by: Josh Poimboeuf
---
arch/x86/power/Makefile | 1 -
arch/x86/power/hibernate_asm_64.S | 8
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/x86/power/Makefile b/arch/x86/power/Makefile
index 69
04415113f /tmp/hibernate_asm_64.before.o
524 0 0 524 20c /tmp/hibernate_asm_64.after.o
Cc: "Rafael J. Wysocki"
Cc: Pavel Machek
Signed-off-by: Josh Poimboeuf
---
arch/x86/power/hibernate_asm_64.S | 92 +++
1 file c
These indirect jumps are harmless; annotate them to make objtool's
retpoline validation happy.
Cc: "Rafael J. Wysocki"
Cc: Pavel Machek
Signed-off-by: Josh Poimboeuf
---
arch/x86/power/hibernate_asm_64.S | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/power/hibernat
Brown
Cc: Pavel Machek
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/acpi/Makefile| 1 -
arch/x86/kernel/acpi/wakeup_64.S | 2 ++
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/acpi/Makefile b/arch/x86/kernel/acpi/Makefile
index f1bb57b0e41e..cf340d859
The OBJECT_FILES_NON_STANDARD annotation is used to tell objtool to
ignore a file. File-level ignores won't work when validating vmlinux.o.
Tweak the ELF metadata and unwind hints to allow objtool to follow the
code.
Cc: Juergen Gross
Reviewed-by: Boris Ostrovsky
Signed-off-by: Josh Poimboeuf
it more palatable to
objtool by making each hypervisor function a true empty function, with
nops and a return.
Cc: Juergen Gross
Reviewed-by: Boris Ostrovsky
Signed-off-by: Josh Poimboeuf
---
arch/x86/xen/xen-head.S | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch
To be used for adding asm functions to the ignore list. The "aw" is
needed to help the ELF section metadata match GCC-created sections.
Otherwise the linker creates duplicate sections instead of combining
them.
Signed-off-by: Josh Poimboeuf
---
include/linux/objtool.h | 8 +
it as a normal function.
Acked-by: Steven Rostedt (VMware)
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/ftrace_64.S | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/ftrace_64.S b/arch/x86/kernel/ftrace_64.S
index 1bf568d901b1..7c273846c687 100644
--- a/arch
This indirect jump is harmless; annotate it to keep objtool's retpoline
validation happy.
Cc: Boris Ostrovsky
Cc: Juergen Gross
Signed-off-by: Josh Poimboeuf
---
arch/x86/platform/pvh/head.S | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/platform/pvh/head.S b/arch/x86/platform
This indirect jump is harmless; annotate it to keep objtool's retpoline
validation happy.
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Cc: Pavel Machek
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/acpi/wakeup_64.S | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/k
This logic will also be needed for the CONFIG_CFI_CLANG support.
Signed-off-by: Josh Poimboeuf
---
tools/objtool/elf.c | 60 -
1 file changed, 37 insertions(+), 23 deletions(-)
diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index 43714ecd09f7
' symbol references back to their
original non-jump-table versions. Note this doesn't change the actual
relocations in the object itself, it just changes objtool's view of
them.
Reported-by: Sedat Dilek
Signed-off-by: Josh Poimboeuf
---
tools/objtool/elf.c | 28
should be able to support it pretty easily with the addition
of a custom 'sp_offset' in UNWIND_HINT_FUNC.
Signed-off-by: Josh Poimboeuf
---
arch/x86/include/asm/unwind_hints.h | 13 ++
arch/x86/kernel/ftrace_64.S | 2 +-
arch/x86/lib/retpoline.S | 2 +-
include/linux
call.
This can cause some inconsistencies between per-object and vmlinux.o
validation.
Instead, assume only ELF functions can do sibling calls. This generally
matches existing reality, and makes sibling call validation consistent
between vmlinux.o and per-object.
Signed-off-by: Josh Poimboeuf
Prevent an unreachable objtool warning after the sibling call detection
gets improved. ftrace_stub() is basically a function, annotate it as
such.
Acked-by: Steven Rostedt (VMware)
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/ftrace_64.S | 1 +
1 file changed, 1 insertion(+)
diff --git
gets a chance.
Rearrange the checks: check for a retpoline jump before checking for an
intra-object jump.
Signed-off-by: Josh Poimboeuf
---
tools/objtool/check.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index
: 39b735332cb8 ("objtool: Detect jumps to retpoline thunks")
Signed-off-by: Josh Poimboeuf
---
tools/objtool/arch/x86/special.c | 2 +-
tools/objtool/check.c | 3 ++-
tools/objtool/include/objtool/check.h | 11 +++
3 files changed, 14 insertions(+), 2 deletion
at
git://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git
objtool-vmlinux
And for more testing it can be combined with Sami's x86 LTO patches:
https://github.com/samitolvanen/linux clang-lto
Josh Poimboeuf (20):
objtool: Fix error handling for STD/CLD warnings
objtool: Fix
vmlinux.o validation.
Fixes: 54262aa28301 ("objtool: Fix sibling call detection")
Signed-off-by: Josh Poimboeuf
---
tools/objtool/check.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 081572170f6b..c964cd56b557 100644
Actually return an error (and display a backtrace, if requested) for
directional bit warnings.
Fixes: 2f0f9e9ad7b3 ("objtool: Add Direction Flag validation")
Signed-off-by: Josh Poimboeuf
---
tools/objtool/check.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --g
ic to me. Also this
doesn't *at all* prevent Clang from being used for live patching. If
anybody actually tries running Julien's patches on a Clang-built kernel,
it might just work. But if not, and the switch tables turn out to be
unparseable like on GCC, we could have a Clang plugin. As I mentioned,
we'll probably end up having one anyway for x86.
--
Josh
YM_CODE_END(.Lbad_get_user_8_clac)
> > arch/x86/lib/putuser.S:SYM_CODE_START_LOCAL(.Lbad_put_user_clac)
> > arch/x86/lib/putuser.S:SYM_CODE_END(.Lbad_put_user_clac)
> > arch/x86/realmode/rm/wakeup_asm.S:SYM_DATA_START_LOCAL(.Lwakeup_idt)
> > arch/x86/realmode/rm/wakeup_a
oid imcr_apic_to_pic(void)
*/
static int force_enable_local_apic __initdata;
+static int __init foo(void)
+{
+ if (force_enable_local_apic)
+ return 1;
+ return 0;
+}
+
+int bar(void)
+{
+ return foo();
+}
+
/*
* APIC command line parameters
*/
--
Josh
On Tue, Jan 19, 2021 at 01:29:16PM -0800, Nick Desaulniers wrote:
> On Mon, Jan 18, 2021 at 9:23 AM Josh Poimboeuf wrote:
> >
> > On Thu, Jan 14, 2021 at 04:41:28PM -0800, Sami Tolvanen wrote:
> > > I can confirm that all the warnings I previously saw are now fixed,
> &
The following commit has been merged into the objtool/core branch of tip:
Commit-ID: ab4e0744e99b87e1a223e89fc3c9ae44f727c9a6
Gitweb:
https://git.kernel.org/tip/ab4e0744e99b87e1a223e89fc3c9ae44f727c9a6
Author:Josh Poimboeuf
AuthorDate:Thu, 17 Dec 2020 15:02:42 -06:00
The following commit has been merged into the objtool/core branch of tip:
Commit-ID: c9c324dc22aab1687da37001b321b6dfa93a0699
Gitweb:
https://git.kernel.org/tip/c9c324dc22aab1687da37001b321b6dfa93a0699
Author:Josh Poimboeuf
AuthorDate:Fri, 18 Dec 2020 14:26:21 -06:00
The following commit has been merged into the objtool/core branch of tip:
Commit-ID: b23cc71c62747f2e4c3e56138872cf47e1294f8a
Gitweb:
https://git.kernel.org/tip/b23cc71c62747f2e4c3e56138872cf47e1294f8a
Author:Josh Poimboeuf
AuthorDate:Fri, 18 Dec 2020 14:19:32 -06:00
On Thu, Jan 14, 2021 at 02:09:28PM +0300, Andrey Ryabinin wrote:
>
>
> On 1/14/21 1:59 PM, Peter Zijlstra wrote:
> > On Mon, Jan 04, 2021 at 04:13:17PM +0100, Peter Zijlstra wrote:
> >> On Tue, Dec 22, 2020 at 11:04:54PM -0600, Josh Poimboeuf wrote:
> >>&g
; - Renumber table of contents
> v3:
> - Incorporated objtool section from Mark.
> - Deleted confusing notes about using annotations.
>
> Mark Brown (1):
> Documentation: livepatch: Convert to automatically generated contents
>
> Mark Rutland (1):
> Documentation: li
__ubsan_handle_add_overflow() with UACCESS enabled
> fs/select.o: warning: objtool: do_sys_poll()+0x669: call to
> __ubsan_handle_sub_overflow() with UACCESS enabled
Under discussion:
https://lkml.kernel.org/r/590998aa9cc50f431343f76cae72b2abf8ac1fdd.1608699683.git.jpoim...@redhat.com
--
Josh
compiler issue. It generates obviously dead code which
jumps off the end of the function:
f7: b0 01 mov$0x1,%al
f9: 84 c0 test %al,%al
fb: 0f 84 79 05 00 00 je 67a
https://paste.centos.org/view/a1887ae3
--
Josh
gt; >
> > I've tried to give rationale for all the recommendations/requirements,
> > since that makes it easier to spot nearby issues, or when a check
> > happens to catch a few things at once.
>
> The above looks enough for the commit message. Well, Josh, typicall
gt; Thanks, I'm able to reproduce these. Will take a look.
> >
>
> AFAICS, that misses the v2 diff (see attachment) you sent me when
> dealing with objtool-vmlinux and clang-cfi.
> It does not cleanly apply with the combination of your objtool-vmlinux
> Git and clang-cfi Git.
Patches 11 and 12 should in theory have the same functionality as that
diff. I just refactored the code a bit before posting.
--
Josh
On Thu, Jan 14, 2021 at 04:41:28PM -0800, Sami Tolvanen wrote:
> Hi Josh,
>
> On Thu, Jan 14, 2021 at 11:40 AM Josh Poimboeuf wrote:
> >
> > Add support for proper vmlinux.o validation, which will be needed for
> > Sami's upcoming x86 LTO set. (And vmlin
On Fri, Jan 15, 2021 at 06:17:25AM +0100, Jürgen Groß wrote:
> On 14.01.21 20:40, Josh Poimboeuf wrote:
> > The Xen hypercall page is filled with zeros, causing objtool to fall
> > through all the empty hypercall functions until it reaches a real
> > function, resulting in a
selfmade LLVM-11.1.0-rc1 (to see if it's
> > broken).
> >
>
> Good, my selfmade LLVM-11.1.0-rc1 is not broken with clang-lto.
>
> + info OBJTOOL vmlinux.o
> + [ != silent_ ]
> + printf %-7s %s\n OBJTOOL vmlinux.o
> OBJTOOL vmlinux.o
> + tools/objtool/
On Fri, Jan 15, 2021 at 12:31:26PM +0100, Miroslav Benes wrote:
> On Thu, 14 Jan 2021, Josh Poimboeuf wrote:
>
> > Thanks to a recent binutils change which doesn't generate unused
> > symbols, it's now possible for thunk_64.o be completely empty with
> > CONFIG_PREE
have
> the correct order.
>
> Signed-off-by: Mark Rutland
> Cc: Jiri Kosina
> Cc: Joe Lawrence
> Cc: Jonathan Corbet
> Cc: Josh Poimboeuf
> Cc: Mark Brown
> Cc: Miroslav Benes
> Cc: Petr Mladek
> Cc: linux-...@vgert.kernel.org
> Cc: live-patch...@vge
On Fri, Jan 15, 2021 at 06:24:10AM +0100, Jürgen Groß wrote:
> On 14.01.21 20:40, Josh Poimboeuf wrote:
> > It's kernel policy to not have (unannotated) indirect jumps because of
> > Spectre v2. This one's probably harmless, but better safe than sorry.
> > Convert it to a r
On Thu, Jan 14, 2021 at 06:10:13PM +, Mark Rutland wrote:
> On Wed, Jan 13, 2021 at 04:25:41PM -0600, Josh Poimboeuf wrote:
> > On Wed, Jan 13, 2021 at 08:23:15PM +, Mark Brown wrote:
> > > On Wed, Jan 13, 2021 at 01:33:13PM -0600, Josh Poimboeuf wrote:
> > >
working with you.
>
> Madhavan
>
> P.S.:
>
> Julien,
>
> Could you send me a link to your latest RFC submission? Thanks!
--
Josh
On Thu, Jan 14, 2021 at 10:59:39PM +, Andrew Cooper wrote:
> On 14/01/2021 19:40, Josh Poimboeuf wrote:
> > It's kernel policy to not have (unannotated) indirect jumps because of
> > Spectre v2. This one's probably harmless, but better safe than sorry.
> > Conv
Suggested-by: Nick Desaulniers
Signed-off-by: Josh Poimboeuf
---
tools/objtool/check.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 5f8d3eed78a1..4bd30315eb62 100644
--- a/tools/objtool/check.c
+++ b/tools/objto
confusion
if/when the thunks end up getting used by some other code again.
Just ignore it and move on.
Reported-by: Nathan Chancellor
Signed-off-by: Josh Poimboeuf
---
tools/objtool/elf.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/tools/objtool/elf.c b/tools
201 - 300 of 13979 matches
Mail list logo
