is too strong. User space processes are safely migrated
> even when entering or leaving the kernel. Kthreads transition would
> need to get forced. But it is safe when:
>
>+ The livepatch does not change the semantic of the code.
>+ Callbacks do not depend on a safely finished trans
On Tue, Apr 09, 2019 at 02:52:38PM +0100, Raphael Gault wrote:
> The jump destination and relocation offset used previously are only reliable
> on x86_64 architecture. We abstract these computations by calling
> arch-dependant
"dependent"
> implementation.
>
> The control flow information and r
+#define X86_FEATURE_POPCNT (4*32+23)
> diff --git a/tools/objtool/arch/arm64/include/asm/orc_types.h
> b/tools/objtool/arch/arm64/include/asm/orc_types.h
> new file mode 100644
> index ..46f516dd80ce
> --- /dev/null
> +++ b/tools/objtool/arch/arm64/include/asm/orc_ty
On Tue, Apr 09, 2019 at 02:52:40PM +0100, Raphael Gault wrote:
> Since the way the initial stack frame when entering a function is different
> that what is done
> in the x86_64 architecture, we need to add some more check to support the
> different cases.
> As opposed as for x86_64, the return ad
In $SUBJECT, s/supsend/suspend/.
On Tue, Apr 09, 2019 at 02:52:42PM +0100, Raphael Gault wrote:
> Annotate cpu_resume and _cpu_resume to silence objtool warning
> about non-standard stack frame.
>
> Signed-off-by: Raphael Gault
> ---
> arch/arm64/kernel/sleep.S | 4
> 1 file changed, 4 ins
On Tue, Apr 09, 2019 at 02:52:37PM +0100, Raphael Gault wrote:
> Hi,
>
> As of now, objtool only supports the x86_64 architecture but the
> groundwork has already been done in order to add support for other
> architecture without too much effort.
>
> This series of patches adds support for the ar
Adding Thomas because this might slightly conflict with some of the
stacktrace.c improvements he's working on.
On Wed, Apr 24, 2019 at 10:55:49AM +0200, Petr Mladek wrote:
> WARN_ONCE() in the generic save_stack_trace_tsk_reliable() is superfluous.
> The only current user klp_check_stack() writes
is too strong. User space processes are safely migrated
> even when entering or leaving the kernel. Kthreads transition would
> need to get forced. But it is safe when:
>
>+ The livepatch does not change the semantic of the code.
>+ Callbacks do not depend on a safely finished trans
ck_trace_tsk_reliable(struct task_struct *tsk,
> struct stack_trace *trace)
> {
> - WARN_ONCE(1, KERN_INFO "save_stack_tsk_reliable() not implemented
> yet.\n");
> return -ENOSYS;
> }
> --
> 2.16.4
>
Acked-by: Josh Poimboeuf
--
Josh
On Wed, Apr 24, 2019 at 10:55:50AM +0200, Petr Mladek wrote:
> WARN_ON_ONCE() could not be called safely under rq lock because
> of console deadlock issues. Fortunately, simple printk_deferred()
> is enough because the warning is printed from a well defined
> location and context.
>
> Also klp_try
On Wed, Apr 17, 2019 at 08:41:34AM -0700, Randy Dunlap wrote:
> On 4/17/19 12:31 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > News: there will be no linux-next release on Friday, Monday or Thursday
> > April 25.
> >
> > Changes since 20190416:
> >
>
> on x86_64:
>
> CC drivers/gpu/dr
On Wed, Apr 24, 2019 at 04:08:15PM +, Raphael Gault wrote:
> > For the next version, please base it on the -tip tree, as that's where
> > all the latest objtool changes are. Peter refactored some code which
> > has some minor conflicts with yours.
> >
>
> Thanks for letting me know about this
On Wed, Apr 24, 2019 at 04:11:57PM +, Raphael Gault wrote:
> On 4/23/19 9:13 PM, Josh Poimboeuf wrote:
> > arch_dest_rela_addend_offset() might be a more descriptive name. Also
> > it might be simpler to just make it an arch-specific macro which is 0 on
> &g
On Wed, Apr 24, 2019 at 04:16:26PM +, Raphael Gault wrote:
> On 4/23/19 9:18 PM, Josh Poimboeuf wrote:
> > On Tue, Apr 09, 2019 at 02:52:39PM +0100, Raphael Gault wrote:
> >> Provide implementation for the arch-dependent functions that are called by
> >> the
On Wed, Apr 24, 2019 at 04:32:44PM +, Raphael Gault wrote:
> >> diff --git a/tools/objtool/arch/arm64/decode.c
> >> b/tools/objtool/arch/arm64/decode.c
> >> index 0feb3ae3af5d..8b293eae2b38 100644
> >> --- a/tools/objtool/arch/arm64/decode.c
> >> +++ b/tools/objtool/arch/arm64/decode.c
> >> @@
On Wed, Apr 24, 2019 at 04:13:59PM -0300, Joao Moreira wrote:
> > > Future Work
> > > ---
> > >
> > > I don't see an easy way to support multiple homonym
> > > symbols with unique values in the current livepatch module
> > > Elf format. The only solutions that come to mind right now inc
Hi all,
On IRC, Peter expressed some concern about -flive-patching, specifically
that the flag isn't compatible with LTO.
The upstream kernel currently doesn't support LTO, but Android is using
it with LLVM:
https://source.android.com/devices/tech/debug/kcfi
And there seems to be progress bei
On Thu, Apr 25, 2019 at 08:12:24AM +, Raphael Gault wrote:
> Hi Josh,
>
> On 4/24/19 5:56 PM, Josh Poimboeuf wrote:
> > On Wed, Apr 24, 2019 at 04:32:44PM +, Raphael Gault wrote:
> >>>> diff --git a/tools/objtool/arch/arm64/decode.c
> >>>> b/t
On Thu, Apr 25, 2019 at 02:22:23PM -0400, Joe Lawrence wrote:
> On 4/25/19 11:26 AM, Josh Poimboeuf wrote:
> > Hi all,
> >
> > On IRC, Peter expressed some concern about -flive-patching, specifically
> > that the flag isn't compatible with LTO.
> >
>
ments")
Reported-by: Vassili Karpov
Signed-off-by: Josh Poimboeuf
---
tools/objtool/check.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 0414a0d52262..91c4799192e1 100644
--- a/tools/objtool/check.c
+++ b/tools/objto
On Thu, Mar 14, 2019 at 06:31:37PM +0300, moos...@gmail.com wrote:
> Josh Poimboeuf writes:
>
> > Objtool uses over 512k of stack, thanks to the hash table embedded in
> > the objtool_file struct. This causes an unnecessarily large stack
> > allocation and breaks use
On Tue, Feb 05, 2019 at 03:33:28AM +0900, Alice Ferrazzi wrote:
> From: Alice Ferrazzi
>
> As a result of an unsupported operation is better to use EOPNOTSUPP
> as error code.
> ENOSYS is only used for 'invalid syscall nr' and nothing else.
>
> Signed-off-by:
On Tue, Feb 05, 2019 at 01:38:21PM -0500, Steven Rostedt wrote:
> Just a FYI.
>
> After a recent upgrade in debian testing, I was not able to build the
> kernel. I have a custom build of gcc, so I thought it was strange that
> I was getting something like this (took this from the web, as I don't
>
> Changes against v1:
>
> + Added Joe's patch that fixed ptr_id() error code [Joe]
> + Did proper error handling in the shadow variable sefttest [All]
> + Removed the controversial patch that was removing patch->enabled flag
> [All].
> + Fixed few typo&#
On Thu, Jan 24, 2019 at 04:57:13PM +0100, Igor Mammedov wrote:
> In case guest is booted with one CPU present and then later
> a sibling CPU is hotplugged [1], it stays offline since SMT
> is disabled.
>
> Bisects to
> 73d5e2b47264 ("cpu/hotplug: detect SMT disabled by BIOS")
> which used __max_s
On Fri, Jan 25, 2019 at 10:36:57AM -0600, Josh Poimboeuf wrote:
> How about this patch? It's just a revert of 73d5e2b47264 and
> bc2d8d262cba, plus the 1-line vmx_vm_init() change. If it looks ok to
> you, I can clean it up and submit an official version.
This one actually comp
On Sun, Jan 27, 2019 at 10:45:03PM -0500, valdis.kletni...@vt.edu wrote:
> Seen in a build:
>
> CC arch/x86/kernel/dumpstack.o
> arch/x86/kernel/dumpstack.o: warning: objtool: oops_begin()+0x9: undefined
> stack state
> arch/x86/kernel/dumpstack.o: warning: objtool: oops_begin()+0x0: stack
On Mon, Jan 28, 2019 at 11:13:04AM +0100, Igor Mammedov wrote:
> On Fri, 25 Jan 2019 11:02:03 -0600
> Josh Poimboeuf wrote:
>
> > On Fri, Jan 25, 2019 at 10:36:57AM -0600, Josh Poimboeuf wrote:
> > > How about this patch? It's just a revert of 73d5e2b47264 and
&
On Sun, Jan 27, 2019 at 11:40:10PM -0500, valdis.kletni...@vt.edu wrote:
> On Sun, 27 Jan 2019 22:18:25 -0600, Josh Poimboeuf said:
> > On Sun, Jan 27, 2019 at 10:45:03PM -0500, valdis.kletni...@vt.edu wrote:
> > > Seen in a build:
> > >
> > > CC arch/x
bc2d8d262cba ("cpu/hotplug: Fix SMT supported evaluation")
and
b) changing vmx_vm_init() to query the actual current SMT state --
instead of the sysfs control value -- to determine whether the L1TF
warning is needed.
Fixes: 73d5e2b47264 ("cpu/hotplug: detect SMT disabl
On Sun, Mar 24, 2019 at 09:13:18PM +0100, Thomas Gleixner wrote:
> On Fri, 1 Mar 2019, Josh Poimboeuf wrote:
> > Make the /sys/devices/system/cpu/smt/* files available on all arches, so
> > user space has a consistent way to detect whether SMT is enabled.
> >
> > T
From: Rolf Eike Beer
If it is not in the default location, compilation would fail at several
points.
Signed-off-by: Rolf Eike Beer
Signed-off-by: Josh Poimboeuf
---
Makefile | 4 +++-
tools/objtool/Makefile | 7 +--
2 files changed, 8 insertions(+), 3 deletions(-)
diff
On Tue, Mar 26, 2019 at 02:53:04PM +0100, Thomas Gleixner wrote:
> On Tue, 26 Mar 2019, Josh Poimboeuf wrote:
> > On Sun, Mar 24, 2019 at 09:13:18PM +0100, Thomas Gleixner wrote:
> > > Second thoughts. I'm not really convinced that changing the meaning of
> > > nots
Make the /sys/devices/system/cpu/smt/* files available on all arches, so
user space has a consistent way to detect whether SMT is enabled.
The 'control' file now shows 'notimplemented' for architectures which
don't yet have CONFIG_HOTPLUG_SMT.
Signed-off-by: Jo
On Tue, Apr 02, 2019 at 03:40:06AM -0700, tip-bot for Josh Poimboeuf wrote:
> Commit-ID: de7b77e5bb9451417ca57f1b6501da654587c048
> Gitweb:
> https://git.kernel.org/tip/de7b77e5bb9451417ca57f1b6501da654587c048
> Author: Josh Poimboeuf
> AuthorDate: Wed, 27 Mar 2019
On Tue, Apr 02, 2019 at 12:19:46PM +0200, Thomas Gleixner wrote:
> The current implementation of in_exception_stack() iterates over the
> exception stacks array. Most of the time this is an useless exercise, but
> even for the actual use cases (perf and ftrace) it takes at least 2
> iterations to g
On Tue, Apr 02, 2019 at 05:48:56PM +0200, Thomas Gleixner wrote:
> > With the above "(stk <= begin || stk >= end)" check, removing the loop
> > becomes not all that important since exception stack dumps are quite
> > rare and not performance sensitive. With all the macros this code
> > becomes a l
On Tue, Apr 02, 2019 at 10:51:49AM -0500, Josh Poimboeuf wrote:
> On Tue, Apr 02, 2019 at 05:48:56PM +0200, Thomas Gleixner wrote:
> > > With the above "(stk <= begin || stk >= end)" check, removing the loop
> > > becomes not all that important since exception
On Wed, Apr 03, 2019 at 10:10:41AM +0200, Peter Zijlstra wrote:
> On Wed, Apr 03, 2019 at 10:08:28AM +0200, Peter Zijlstra wrote:
> > On Tue, Apr 02, 2019 at 10:51:49AM -0500, Josh Poimboeuf wrote:
> > > On Tue, Apr 02, 2019 at 05:48:56PM +0200, Thomas Gleixner wrote:
> &
On Wed, Apr 03, 2019 at 08:02:43AM -0700, Randy Dunlap wrote:
> On 4/3/19 1:24 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20190402:
> >
>
> on x86_64:
>
> arch/x86/entry/entry_64.o: warning: objtool: .entry.text+0x909: unreachable
> instruction
Your .o file looks odd. I ca
On Thu, Apr 04, 2019 at 01:43:05AM +0800, kbuild test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> core/objtool
> head: 64604d54d3115fee89598bfb6d8d2252f8a2d114
> commit: 37686b1353cfc30e127cef811959cdbcd0495d98 [2/25] tracing: Improve "if"
> macro code g
On Mon, Apr 08, 2019 at 09:13:58AM +0300, Elena Reshetova wrote:
> diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
> index 7bc105f47d21..38ddc213a5e9 100644
> --- a/arch/x86/entry/common.c
> +++ b/arch/x86/entry/common.c
> @@ -35,6 +35,12 @@
> #define CREATE_TRACE_POINTS
> #include
On Mon, Apr 08, 2019 at 09:20:50AM +, David Laight wrote:
> From: Josh Poimboeuf
> > Sent: 05 April 2019 18:23
> > On Fri, Apr 05, 2019 at 05:17:15PM +, David Laight wrote:
> > > > Hm, I don't see that in cmd_objtool, or any commits from you i
On Mon, Apr 08, 2019 at 09:18:00AM -0700, Andy Lutomirski wrote:
> On Sun, Apr 7, 2019 at 11:46 PM Thomas Gleixner wrote:
> >
> > On Sun, 7 Apr 2019, Andy Lutomirski wrote:
> > > On Sun, Apr 7, 2019 at 3:44 PM Thomas Gleixner wrote:
> > > > Actually we have: save_stack_trace()
> > > >
> > >
> > >
On Tue, Apr 09, 2019 at 02:52:37PM +0100, Raphael Gault wrote:
> Hi,
>
> As of now, objtool only supports the x86_64 architecture but the
> groundwork has already been done in order to add support for other
> architecture without too much effort.
Hi Raphael,
This was a pleasant surprise in my in
On Tue, Apr 09, 2019 at 10:43:18AM -0700, Ard Biesheuvel wrote:
> On Tue, 9 Apr 2019 at 06:53, Raphael Gault wrote:
> >
> > Hi,
> >
> > As of now, objtool only supports the x86_64 architecture but the
> > groundwork has already been done in order to add support for other
> > architecture without t
On Wed, Apr 10, 2019 at 12:28:10PM +0200, Thomas Gleixner wrote:
> No architecture terminates the stack trace with ULONG_MAX anymore. As the
> code checks the number of entries stored anyway there is no point in
> keeping all that ULONG_MAX magic around.
>
> The histogram code zeroes the storage b
On Wed, Apr 10, 2019 at 12:28:14PM +0200, Thomas Gleixner wrote:
> Replace the indirection through struct stack_trace by using the storage
> array based interfaces.
>
> Signed-off-by: Thomas Gleixner
> ---
> kernel/backtracetest.c | 11 +++
> 1 file changed, 3 insertions(+), 8 deletion
On Wed, Apr 10, 2019 at 12:28:19PM +0200, Thomas Gleixner wrote:
> Replace the indirection through struct stack_trace by using the storage
> array based interfaces.
>
> Signed-off-by: Thomas Gleixner
> Cc: Andrey Ryabinin
> Cc: Alexander Potapenko
> Cc: Dmitry Vyukov
> Cc: kasan-...@googlegrou
On Wed, Apr 10, 2019 at 12:28:34PM +0200, Thomas Gleixner wrote:
> No more users of the struct stack_trace based interfaces. Remove them.
>
> Remove the macro stubs for !CONFIG_STACKTRACE as well as they are pointless
> because the storage on the call sites is conditional on CONFIG_STACKTRACE
> al
On Wed, Apr 10, 2019 at 10:33:20PM -0500, Josh Poimboeuf wrote:
> > -#ifdef CONFIG_USER_STACKTRACE_SUPPORT
> > +extern void save_stack_trace(struct stack_trace *trace);
> > +extern void save_stack_trace_regs(struct pt_regs *regs,
> > + s
On Thu, Apr 11, 2019 at 10:30:45AM -0400, Joe Lawrence wrote:
> On 4/10/19 8:32 PM, Masahiro Yamada wrote:
> > On Thu, Apr 11, 2019 at 12:52 AM Joe Lawrence
> > wrote:
> > >
> > > From: Josh Poimboeuf
> > >
> > > Define klp prefixes
On Mon, Feb 25, 2019 at 01:43:34PM +0100, Peter Zijlstra wrote:
> Replace the existing STACK_FRAME_NON_STANDARD annotation with a
> 'better' scheme.
>
> The old annotation works by taking the address of a function; this
> is visible to the compiler and might affect code generation (the
> function
On Mon, Feb 25, 2019 at 05:17:22PM +0100, Peter Zijlstra wrote:
> > Including the file creates the section, which is a bit nasty. Instead
> > just change STACK_FRAME_NON_STANDARD to prefix every string with a \0?
>
> That would get us \0\0 between every string, which I suppose is in-spec,
> but w
On Mon, Feb 25, 2019 at 06:15:31PM +0100, Peter Zijlstra wrote:
> Also, I think at the time we didn't use it because backporting efforts.
This part may have been my fault. I spread a vicious rumor (based on
reading docs instead of code) that old versions of GCC don't support
'%='. But it's actua
allmodconfig using
> GCC10), but older versions have seen some robot exposure and other compilers.
>
> v2:
> - actually Cc'ed LKML :/
Acked-by: Josh Poimboeuf
--
Josh
he `const` label.
>
> Signed-off-by: Jason Gerecke
> Cc: Steven Rostedt
> Cc: Ard Biesheuvel
> ---
> Marked RFC since I'm not familiar with this subsystem or the asm blocks that
> are impacted. Extra-close inspection would be appreciated.
Acked-by: Josh Poimboeuf
--
Josh
On Fri, Feb 12, 2021 at 04:30:49PM +0100, Greg Kroah-Hartman wrote:
> On Thu, Feb 11, 2021 at 10:46:05AM -0800, Nick Desaulniers wrote:
> > On Thu, Feb 11, 2021 at 5:55 AM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Thu, Feb 11, 2021 at 09:32:03PM +0800, Xi Ruoyao wrote:
> > > > Hi all,
> > > >
>
On Thu, Feb 11, 2021 at 05:16:56PM +, Ken Moffat wrote:
> Hi,
>
> in 5.10 kernels up to and including 5.10.15 when trying to build the
> kernel for an x86_64 skylake using binutils-2.36.1, gcc-10.2 and
> glibic-2.33 I get a segfault in objtool if the orc unwinder is
> enabled.
>
> This has al
On Sat, Feb 13, 2021 at 09:13:04AM -0500, Steven Rostedt wrote:
> On Sat, 13 Feb 2021 15:09:02 +0100
> Greg Kroah-Hartman wrote:
>
> > Thanks for the patch, but no, still fails with:
> >
> > Cannot find symbol for section 8: .text.unlikely.
> > kernel/kexec_file.o: failed
> > make[1]: *** [scrip
On Tue, Feb 23, 2021 at 04:36:19PM +0900, Masami Hiramatsu wrote:
> On Tue, 23 Feb 2021 10:23:31 +0900
> Masami Hiramatsu wrote:
>
> > On Mon, 22 Feb 2021 11:51:50 -0600
> > Josh Poimboeuf wrote:
> >
> > > On Tue, Feb 23, 2021 at 12:05:08AM +0900, Masami
On Wed, Feb 24, 2021 at 03:52:01PM +0100, Peter Zijlstra wrote:
> On Fri, Feb 05, 2021 at 08:24:03AM -0600, Josh Poimboeuf wrote:
> > The ORC unwinder attempts to fall back to frame pointers when ORC data
> > is missing for a given instruction. It sets state->error, but then
Standardize the crypto asm to make it resemble compiler-generated code,
so that objtool can understand it.
This magically enables ORC unwinding from crypto code. It also fixes
the last known remaining objtool warnings on vmlinux.o, for LTO and
more.
Josh Poimboeuf (13):
objtool: Support asm
Use a more standard prologue for saving the stack pointer before
realigning the stack.
This enables ORC unwinding by allowing objtool to understand the stack
realignment.
Signed-off-by: Josh Poimboeuf
---
arch/x86/crypto/sha512-avx-asm.S | 41 +++-
1 file changed
Use a more standard prologue for saving the stack pointer before
realigning the stack.
This enables ORC unwinding by allowing objtool to understand the stack
realignment.
Signed-off-by: Josh Poimboeuf
---
arch/x86/crypto/sha1_ni_asm.S | 8
1 file changed, 4 insertions(+), 4 deletions
These macros are no longer used; remove them.
Signed-off-by: Josh Poimboeuf
---
arch/x86/crypto/aesni-intel_avx-x86_64.S | 8
1 file changed, 8 deletions(-)
diff --git a/arch/x86/crypto/aesni-intel_avx-x86_64.S
b/arch/x86/crypto/aesni-intel_avx-x86_64.S
index 2cf8e94d986a
ction has a jump table.
Signed-off-by: Josh Poimboeuf
---
tools/objtool/check.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 080a3d6cbd75..f95e406296f5 100644
--- a/tools/objtool/check.c
+++ b/tools/ob
Simplify the jump table code so that it resembles a compiler-generated
table.
This enables ORC unwinding by allowing objtool to follow all the
potential code paths.
Signed-off-by: Josh Poimboeuf
---
arch/x86/crypto/crc32c-pcl-intel-asm_64.S | 7 ++-
1 file changed, 2 insertions(+), 5
Use a more standard prologue for saving the stack pointer before
realigning the stack.
This enables ORC unwinding by allowing objtool to understand the stack
realignment.
Signed-off-by: Josh Poimboeuf
---
arch/x86/crypto/sha512-avx2-asm.S | 42 +++
1 file changed
Use RBP instead of R14 for saving the old stack pointer before
realignment. This resembles what compilers normally do.
This enables ORC unwinding by allowing objtool to understand the stack
realignment.
Signed-off-by: Josh Poimboeuf
---
arch/x86/crypto/aesni-intel_avx-x86_64.S | 10
Now that all the stack alignment prologues have been cleaned up in the
crypto code, enable objtool. Among other benefits, this will allow ORC
unwinding to work.
Signed-off-by: Josh Poimboeuf
---
arch/x86/crypto/Makefile | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/crypto
Fix register usage comments to match reality.
Signed-off-by: Josh Poimboeuf
---
arch/x86/crypto/aesni-intel_avx-x86_64.S | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/x86/crypto/aesni-intel_avx-x86_64.S
b/arch/x86/crypto/aesni-intel_avx-x86_64.S
index
Use a more standard prologue for saving the stack pointer before
realigning the stack.
This enables ORC unwinding by allowing objtool to understand the stack
realignment.
Signed-off-by: Josh Poimboeuf
---
arch/x86/crypto/sha256-avx2-asm.S | 13 ++---
1 file changed, 6 insertions(+), 7
A conditional stack allocation violates traditional unwinding
requirements when a single instruction can have differing stack layouts.
There's no benefit in allocating the stack buffer conditionally. Just
do it unconditionally.
Signed-off-by: Josh Poimboeuf
---
arch/x86/crypto/camellia-
Use a more standard prologue for saving the stack pointer before
realigning the stack.
This enables ORC unwinding by allowing objtool to understand the stack
realignment.
Signed-off-by: Josh Poimboeuf
---
arch/x86/crypto/sha512-ssse3-asm.S | 41 ++
1 file changed
Use a more standard prologue for saving the stack pointer before
realigning the stack.
This enables ORC unwinding by allowing objtool to understand the stack
realignment.
Signed-off-by: Josh Poimboeuf
---
arch/x86/crypto/sha1_avx2_x86_64_asm.S | 8
1 file changed, 4 insertions(+), 4
On Wed, Feb 24, 2021 at 07:07:31PM +0100, Peter Zijlstra wrote:
> On Wed, Feb 24, 2021 at 09:18:05AM -0600, Josh Poimboeuf wrote:
> > On Wed, Feb 24, 2021 at 03:52:01PM +0100, Peter Zijlstra wrote:
> > > On Fri, Feb 05, 2021 at 08:24:03AM -0600, Josh Poimboeuf wrote:
> &
On Wed, Feb 10, 2021 at 09:39:53AM +0100, Peter Zijlstra wrote:
>
>
> Given all the ENDBR fun we recently had, do we want the below? Until
> someone comes and fixes up kprobes/ftrace/livepatch etc.. having them is
> a giant pain and we'd better warn about it.
Meh...
Is there a point in doing th
() instead of unreachable().
Fixes the following objtool warning:
drivers/input/touchscreen/elants_i2c.o: warning: objtool:
elants_i2c_initialize() falls through to next function elants_i2c_resume()
Reported-by: Randy Dunlap
Acked-by: Randy Dunlap
Signed-off-by: Josh Poimboeuf
---
drivers
; Therefore, have "mov %[tos], %rsp" act like a PUSH (it sorta is
> anyway) to balance the things out. We're not too concerned with the
> actual stack_size for frame-pointer builds, since we don't generate
> ORC data for them anyway.
>
> Fixes: aafeb14e9da2 (&qu
On Thu, Feb 18, 2021 at 08:09:17PM +0300, Evgenii Shatokhin wrote:
> Is there a way to allow probing of functions in .text. ?
>
> Of course, one could place probes using absolute addresses of the functions
> but that would be less convenient.
>
> This also affects many livepatch modules where the
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:
> > >
> >
On Tue, Feb 02, 2021 at 03:01:22PM -0800, Nick Desaulniers wrote:
> > >> Thus far we've been able to successfully reverse engineer it on x86,
> > >> though it hasn't been easy.
> > >>
> > >> There were some particulars for arm64 which made doing so impossible.
> > >> (I don't remember the details.)
On Wed, Feb 03, 2021 at 01:02:23PM +0100, Peter Zijlstra wrote:
> Currently REG_SP_INDIRECT is unused but means (%rsp + offset),
> change it to mean (%rsp) + offset.
>
> This is somewhat unfortunate, since REG_BP_INDIRECT is used (by DRAP)
> and thus needs to retain the current (%rbp + offset).
O
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),
> > &
help. Do I
> need to apply the whole series 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
op
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.
&
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:
> > >
> > > * https://github.com/bobrik/linux/tree/ivan/static-cal
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
nd there are all sorts of issues
> > being 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 usi
es
> >> being 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?
> >>>
> >>
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
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
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
On Thu, Jan 28, 2021 at 01:23:11PM -0800, Linus Torvalds wrote:
> On Thu, Jan 28, 2021 at 1:03 PM Linus Torvalds
> wrote:
> >
> > I really think the whole compiler version check is purely voodoo
> > programming.
>
> .. but there are obviously potentially things we - in the kernel - do
> that may
x27;t 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/Makef
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 we
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 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 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.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=201891
901 - 1000 of 4576 matches
Mail list logo
