On Tue, Apr 28, 2020 at 11:10:44AM -0500, Josh Poimboeuf wrote:
> > ==> build/x86/0xE0F2ACFF_defconfig/log <==
> > kernel/time/posix-stubs.o: warning: objtool: __x64_sys_timer_create()+0x23:
> > sibling call from callable instruction with modified stack frame
This one is
-by: Peter Zijlstra
Signed-off-by: Josh Poimboeuf
Acked-by: Miroslav Benes
Acked-by: Joe Lawrence
---
kernel/livepatch/core.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index c3512e7e0801..40cfac8156fd 100644
--- a/kernel/livepatch/core.c
state to determine whether
memcpy() can be used. Implement text_poke() for UML. ]
Cc: x...@kernel.org
Suggested-by: Josh Poimboeuf
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Josh Poimboeuf
Acked-by: Peter Zijlstra (Intel)
Acked-by: Joe Lawrence
Acked-by: Miroslav Benes
s390_kernel_write()'s function type is almost identical to memcpy().
Change its return type to "void *" so they can be used interchangeably.
Cc: linux-s...@vger.kernel.org
Cc: heiko.carst...@de.ibm.com
Signed-off-by: Josh Poimboeuf
Acked-by: Joe Lawrence
Acked-by: Miroslav Benes
---
state to determine whether
memcpy() can be used. Test and add fixes. ]
Cc: linux-s...@vger.kernel.org
Cc: Heiko Carstens
Cc: Gerald Schaefer
Cc: Christian Borntraeger
Suggested-by: Josh Poimboeuf
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Josh Poimboeuf
Acked-by: Peter
Prevent module-specific KLP rela sections from referencing vmlinux
symbols. This helps prevent ordering issues with module special section
initializations. Presumably such symbols are exported and normal relas
can be used instead.
Suggested-by: Peter Zijlstra
Signed-off-by: Josh Poimboeuf
With arch_klp_init_object_loaded() gone, and apply_relocate_add() now
using text_poke(), livepatch no longer needs to use module_disable_ro().
Signed-off-by: Josh Poimboeuf
Acked-by: Peter Zijlstra (Intel)
Acked-by: Joe Lawrence
Acked-by: Miroslav Benes
---
kernel/livepatch/core.c | 2 --
1
module_disable_ro().
[ jpoimboe: Rewrote patch description. Tweaked klp_init_object_loaded()
error path. ]
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Josh Poimboeuf
Acked-by: Peter Zijlstra (Intel)
Acked-by: Joe Lawrence
Acked-by: Miroslav Benes
---
Documentation/livepatch
still need .klp.arch. Or do we? Stay
tuned.
Suggested-by: Peter Zijlstra
Signed-off-by: Josh Poimboeuf
Acked-by: Peter Zijlstra (Intel)
Acked-by: Joe Lawrence
Acked-by: Miroslav Benes
---
include/linux/livepatch.h | 14
kernel/livepatch/core.c | 137 ---
module_disable_ro() has no more users. Remove it.
Signed-off-by: Josh Poimboeuf
Acked-by: Peter Zijlstra (Intel)
Acked-by: Joe Lawrence
Acked-by: Miroslav Benes
---
include/linux/module.h | 2 --
kernel/module.c| 13 -
2 files changed, 15 deletions(-)
diff --git
task.
Signed-off-by: Josh Poimboeuf
Acked-by: Joe Lawrence
Acked-by: Miroslav Benes
---
arch/x86/kernel/module.c | 9 +++--
kernel/livepatch/core.c | 6 --
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
index 7614f478fd7a
Now that module_enable_ro() has no more external users, make it static
again.
Suggested-by: Jessica Yu
Signed-off-by: Josh Poimboeuf
---
include/linux/module.h | 6 --
kernel/module.c| 4 ++--
2 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/include/linux/module.h b
g/r/20191021135312.jbbxsuipxldocdjk@treble
This has been tested with kpatch-build integration tests and klp-convert
selftests.
Josh Poimboeuf (8):
livepatch: Disallow vmlinux.ko
livepatch: Apply vmlinux-specific KLP relocations early
livepatch: Prevent module-specific KLP rela sections from referenc
t; call to __stack_chk_fail() with UACCESS enabled
>
> Full randconfig file is attached.
Peter, I think should __stack_chk_fail() be on the safe list?
--
Josh
On Tue, Apr 28, 2020 at 05:48:38PM -0500, Josh Poimboeuf wrote:
> On Wed, Apr 29, 2020 at 12:33:27AM +0200, Peter Zijlstra wrote:
> > On Tue, Apr 28, 2020 at 05:03:53PM -0500, Josh Poimboeuf wrote:
> > > On Tue, Apr 28, 2020 at 11:55:54PM +0200, Peter Zijlstra wrote:
> >
On Wed, Apr 29, 2020 at 12:33:27AM +0200, Peter Zijlstra wrote:
> On Tue, Apr 28, 2020 at 05:03:53PM -0500, Josh Poimboeuf wrote:
> > On Tue, Apr 28, 2020 at 11:55:54PM +0200, Peter Zijlstra wrote:
>
> > > binutils.git/gas/configure/tc-i386.c:i386_generate_nops
> > >
On Tue, Apr 28, 2020 at 11:55:54PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 28, 2020 at 03:38:55PM -0500, Josh Poimboeuf wrote:
> > This one makes no sense to me. It looks like the assembler is inserting
> > a jump as part of the alignment padding??? WTH.
> >
it
didn't recognize the boundary between the two functions.
Fix that with a new prev_insn_same_sym() helper, which doesn't cross
subfunction boundaries.
Reported-by: Kristen Carlson Accardi
Signed-off-by: Josh Poimboeuf
---
tools/objtool/check.c | 15 +--
1 file changed, 13 insert
= __start_orc_unwind_ip;
> +static struct orc_entry *cur_orc_table = __start_orc_unwind;
>
> static void orc_sort_swap(void *_a, void *_b, int size)
> {
> --
> 2.26.0
>
--
Josh
On Tue, Apr 28, 2020 at 10:19:46PM +0200, Arnd Bergmann wrote:
> On Tue, Apr 28, 2020 at 6:10 PM Josh Poimboeuf wrote:
> > On Tue, Apr 28, 2020 at 04:49:15PM +0200, Arnd Bergmann wrote:
> > > ==> build/x86/0xFD7B7323_defconfig/log <==
> > > arch/x86/entry/entry_64
unwind information for them, which
> in turn means we can now unwind through a retpoline.
>
> New since last time:
>
> - 1-3, alternatives vs ORC unwind
> - 7-9: implement some suggestions from Julien
> - addressed feedback
For patches 2-14:
Acked-by: Josh Poimboeuf
I
ffmovq $0x,0x78(%rsp)
> f61: ff ff
> f63: e8 00 00 00 00 callq f68
> f68: e9 73 02 00 00 jmpq 11e0
> ###sp:(und) bp:(und) type:call end:0
> f6d: 0f 1f 00nopl (%rax)
&
ktrace)
> BT_FUNC("<=== (sym)", insn);
> return ret;
> --- a/tools/objtool/check.h
> +++ b/tools/objtool/check.h
> @@ -30,12 +30,13 @@ struct instruction {
> unsigned int len;
> enum insn_type type;
> unsigned long immediate;
> - bool alt_group, dead_end, ignore, ignore_alts;
> + bool dead_end, ignore, ignore_alts;
> bool hint;
> bool retpoline_safe;
> s8 instr;
> u8 visited;
> u8 ret_offset;
> + int alt_group;
> struct symbol *call_dest;
> struct instruction *jump_dest;
> struct instruction *first_jump_src;
>
>
--
Josh
On Tue, Apr 28, 2020 at 06:41:55PM +0200, Jessica Yu wrote:
> +++ Josh Poimboeuf [28/04/20 11:36 -0500]:
> > On Tue, Apr 28, 2020 at 06:25:05PM +0200, Jessica Yu wrote:
> > > +++ Josh Poimboeuf [25/04/20 06:07 -0500]:
> > > > module_disable_r
he hack is done before the validate
> > code, so validate_branch() itself is simpler.
>
> But it doesn't handle the case where the alternatives themselves have
> unreachable holes in them, if that happens we'll generate spurious ORC
> entries for them.
Ah, I see what you mean.
I need to think about it...
--
Josh
On Tue, Apr 28, 2020 at 06:25:05PM +0200, Jessica Yu wrote:
> +++ Josh Poimboeuf [25/04/20 06:07 -0500]:
> > module_disable_ro() has no more users. Remove it.
> >
> > Signed-off-by: Josh Poimboeuf
> > Acked-by: Peter Zijlstra (Intel)
>
> Hm, I gu
On Tue, Apr 28, 2020 at 09:25:51AM -0700, Sean Christopherson wrote:
> On Tue, Apr 28, 2020 at 10:54:13AM -0500, Josh Poimboeuf wrote:
> > On Tue, Apr 28, 2020 at 10:49:09AM -0500, Josh Poimboeuf wrote:
> > > On Tue, Apr 28, 2020 at 05:25:52PM +0200, Peter Zijlstra wrote:
>
> ==> build/x86/0x500B1B82_defconfig/log <==
> kernel/bpf/core.o: warning: objtool: ___bpf_prog_run()+0x1269: call
> without frame pointer save/setup
I'll look into these.
--
Josh
On Tue, Apr 28, 2020 at 10:49:09AM -0500, Josh Poimboeuf wrote:
> On Tue, Apr 28, 2020 at 05:25:52PM +0200, Peter Zijlstra wrote:
> > On Tue, Apr 28, 2020 at 09:31:57AM -0500, Josh Poimboeuf wrote:
> > > That's quite the monstrosity, and I still don't see the point. I
> &
On Tue, Apr 28, 2020 at 05:25:52PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 28, 2020 at 09:31:57AM -0500, Josh Poimboeuf wrote:
> > That's quite the monstrosity, and I still don't see the point. I
> > thought we decided to just disallow CFI changes in alternatives anyway?
>
h another
revision.
--
Josh
On Tue, Apr 28, 2020 at 04:16:14PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 28, 2020 at 02:46:27PM +0200, Peter Zijlstra wrote:
> > On Tue, Apr 28, 2020 at 02:04:50AM -0500, Josh Poimboeuf wrote:
>
> > > I'm thinking something like this should fix it. Peter, do
ry.
> So rather than hacking around this issue, should we not make
> create_orc() smarter?
Maybe, though I don't see how that logic belongs in create_orc(). It
might be tricky distinguishing between normal undefined and "undefined
because of a skip_orig". Right now create_orc() is blissfully ignorant.
--
Josh
On Tue, Apr 28, 2020 at 02:16:43AM -0500, Josh Poimboeuf wrote:
> Fix the following warnings seen with !CONFIG_MODULE:
s/MODULE/MODULES/ here and $SUBJECT.
--
Josh
n Rothwell
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/unwind_orc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c
index 0ebc11a8bb45..5b0bd8581fe6 100644
--- a/arch/x86/kernel/unwind_orc.c
+++ b/arch/
On Mon, Mar 02, 2020 at 09:52:40AM -0600, Josh Poimboeuf wrote:
> On Mon, Mar 02, 2020 at 09:18:29AM -0600, Josh Poimboeuf wrote:
> > > So I think on machines without X86_FEATURE_SMAP, trying to unwind from
> > > the two NOPs at f41 and f42 will cause the unwinder to report an
exception_stack base
> address and bailing out if it is zero.
>
> Fixes: afcd21dad88b ("x86/dumpstack/64: Use cpu_entry_area instead of
> orig_ist")
> Reported-by: Cyrill Gorcunov
> Signed-off-by: Thomas Gleixner
> Tested-by: Cyrill Gorcunov
> Cc: sta...@vger.kernel.org
Acked-by: Josh Poimboeuf
--
Josh
+
This isn't quite true, we also use .klp.rela sections to access
unexported vmlinux symbols.
--
Josh
ernel.
>
> Then for 3) we only have alternatives left, and I _think_ it unlikely to
> be the case, but I'll have to have a hard look at that.
I'm not sure about alternatives, but maybe we can enforce such
limitations with tooling and/or kernel checks.
--
Josh
atch-per-module idea, so I view that as a bad sign.
--
Josh
ed, 9 insertions(+), 14 deletions(-)
Applied and pushed out.
josh
sense to me.
>
> Well, I wonder if it is really any better from what we have now.
AFAICT, this would still have a lot of the same problems we have today.
It has a lot of complexity. It needs arch-specific livepatch code and
sections, and introduces special cases in the module code.
I'd much prefer the proposal from LPC to have per-module live patches.
It's simpler and has less things that can go wrong IMO.
--
Josh
lly allow us to drop this flag.
But regardless, I wonder if we enabled this flag prematurely. We still
don't have a reasonable way to use it for creating source-based live
patches upstream, and it should really be optional for CONFIG_LIVEPATCH,
since kpatch-build doesn't need it.
--
Josh
able_ro()
...
module_enable_ro()
which is done right before the above patch does module_enable_ro().
We could remove the disable-RO from that case, though we'd still need it
for another case (late module patching).
--
Josh
e
> KLP module.
Hm... for kpatch-build I assume we may need a GCC plugin to convert
local calls to global somehow?
--
Josh
On 10/3/19 3:03 AM, Jiri Olsa wrote:
On Thu, Oct 03, 2019 at 12:54:09AM -0700, Josh Hunt wrote:
The following commit is breaking dwarf unwinding on 4.19 kernels:
how?
When doing something like:
perf record -p $(cat /var/run/app.pid) -g --call-graph dwarf -F 999 --
sleep 3
with 4.19.75
Josh
*' value. And therefore
> usage from within structures isn't allowed.
Is that something we need? At least we were able to work around this
limitation with tracepoints' usage of static calls. But I could see how
it could be useful.
One way to solve that would be a completely different implementation:
have a global trampoline which detects the call site of the caller,
associates it with the given key, schedules some work to patch the call
site later, and then jumps to key->func. So the first call would
trigger the patching.
Then we might not even need objtool :-) But it might be tricky to pull
off.
--
Josh
On Thu, Sep 05, 2019 at 02:45:12PM +0200, Miroslav Benes wrote:
> Josh reported a bug:
>
> When the object to be patched is a module, and that module is
> rmmod'ed and reloaded, it fails to load with:
>
> module: x86/modules: Skipping invalid relocation target, existing v
tint_user
I don't think this UNWIND_HINT_REGS needs to be moved?
--
Josh
On Mon, Sep 23, 2019 at 03:33:52PM +0200, Peter Zijlstra wrote:
> On Mon, Sep 23, 2019 at 07:49:01AM -0500, Josh Poimboeuf wrote:
> > On Mon, Sep 23, 2019 at 11:20:24AM +0200, Peter Zijlstra wrote:
> > > On Wed, Sep 18, 2019 at 09:04:21PM -0700, Randy Dunlap wrote:
> > >
exec2_list[i].offset,
_exec_list[i].offset,
end_user);
}
end_user:
user_access_end();
--
Josh
):
> parent function name exceeds maximum length of 128 characters
Hm, since when do we have mangled symbols in the kernel?
--
Josh
On Thu, Sep 19, 2019 at 12:21:46PM -0700, Randy Dunlap wrote:
> On 9/19/19 9:51 AM, Josh Poimboeuf wrote:
> > On Wed, Sep 18, 2019 at 09:04:21PM -0700, Randy Dunlap wrote:
> >> On 9/18/19 3:10 PM, Mark Brown wrote:
> >>> Hi all,
> >>>
> >>
= [47]."
*/
#define GEN8_HIGH_ADDRESS_BIT 47
-static inline u64 gen8_canonical_addr(u64 address)
+static __always_inline u64 gen8_canonical_addr(u64 address)
{
return sign_extend64(address, GEN8_HIGH_ADDRESS_BIT);
}
--
Josh
;
>
> return dest;
> }
I think this also needs ASM_CALL_CONSTRAINT.
Doesn't this break on older non-ERMS CPUs when the memset() is done
early, before alternative patching?
Could it instead do this?
ALTERNATIVE_2("call memset_orig",
"call memset_rep",X86_FEATURE_REP_GOOD,
"rep; stosb", X86_FEATURE_ERMS)
Then the "reverse alternatives" feature wouldn't be needed anyway.
--
Josh
ot;<]\(asm/\)*inat.h[\">]"'
> check arch/x86/lib/inat.c '-I "^#include
> [\"<]\(../include/\)*asm/insn.h[\">]"'
> check arch/x86/lib/insn.c '-I "^#include
> [\"<]\(../include/\)*asm/in\(at\|sn\).h[\">]"'
>
> -cd -
> +cd - > /dev/null
> --
> 2.20.0
>
Arnaldo, do you want to pick this one up?
Acked-by: Josh Poimboeuf
--
Josh
On Sat, Sep 14, 2019 at 02:43:28PM +0200, Borislav Petkov wrote:
> Hey Josh,
>
> I'm seeing
>
> arch/x86/kernel/cpu/mce/core.o: warning: objtool: mce_panic()+0x11b:
> unreachable instruction
>
> on a brand new debian install here with gcc9: gcc (Debian 9.
The following commit has been merged into the core/objtool branch of tip:
Commit-ID: f73b3cc39c84220e6dccd463b5c8279b03514646
Gitweb:
https://git.kernel.org/tip/f73b3cc39c84220e6dccd463b5c8279b03514646
Author:Josh Poimboeuf
AuthorDate:Thu, 29 Aug 2019 18:28:49 -05:00
upport with LP. It could be solved with srcversion, but it
> complicates things a lot. "blue sky" idea could extend the issue to all
> modules given the above is real.
I'm having trouble understanding what this issue is and how "blue sky"
would extend it.
--
Josh
/\)*asm/in\(at\|sn\).h[\">]"'
> +check arch/x86/lib/insn.c '-I "^#include
> [\"<]\(../include/\)*asm/in\(at\|sn\).h[\">]" -I "^#include
> [\"<]\(../include/\)*asm/xen/prefix.h[\">]"'
Unfortunately perf also has a similar sync check script:
tools/perf/check-headers.sh. So you'll also need to add the above
changes there.
Otherwise
Acked-by: Josh Poimboeuf
--
Josh
On Thu, Sep 05, 2019 at 03:52:59PM +0200, Petr Mladek wrote:
> On Thu 2019-09-05 08:15:02, Josh Poimboeuf wrote:
> > On Thu, Sep 05, 2019 at 08:08:32AM -0500, Josh Poimboeuf wrote:
> > > On Thu, Sep 05, 2019 at 01:09:55PM +0200, Petr Mladek wrote:
> > > > > I d
On Thu, Sep 05, 2019 at 03:31:56PM +0200, Jiri Kosina wrote:
> On Thu, 5 Sep 2019, Josh Poimboeuf wrote:
>
> > > All the indirect jumps are turned into alternatives when retpolines
> > > are in place.
> >
> > Actually in C code those are
y via some macros or inlined functions?
>
> All the indirect jumps are turned into alternatives when retpolines are in
> place.
Actually in C code those are done by the compiler as calls/jumps to
__x86_indirect_thunk_*.
But there are still a bunch of paravirt patched instructions and
alternatives used throughout the kernel.
--
Josh
On Thu, Sep 05, 2019 at 08:08:32AM -0500, Josh Poimboeuf wrote:
> On Thu, Sep 05, 2019 at 01:09:55PM +0200, Petr Mladek wrote:
> > > I don't have a number, but it's very common to patch a function which
> > > uses jump labels or alternatives.
> >
> > R
gt; alternatives and jump_labels that were added long time ago.
Jump labels have been around for many years, but we somehow missed
implementing klp.arch for them. As I said this resulted in panics.
There may be other similar cases lurking, both in x86 and other arches.
It's not a comforting thought!
And each case requires special klp code in addition to the real code.
--
Josh
ing problem,
> because you never know which version of the module is loaded in the
> system. The state space grows rather rapidly there.
What exactly are your concerns?
Either the old version of the module is loaded, and it's livepatched; or
the new version of the module is loaded, and it's not livepatched.
Anyway that could be reported to the user somehow, e.g. report
srcversion in sysfs.
--
Josh
ing notifiers which have
> > also been an additional source of complexity.
>
> True, but I think we (me and Petr) do not consider it as much of a problem
> as you.
It's less of an issue than .klp.arch and all the related code which can
be removed.
--
Josh
ther architectures we support.
> > > >
> > > > So it is in itself reason enough to do something about late module
> > > > patching.
> > > >
> > >
> > > Hi Miroslav,
> > >
> > > I was tinkering with the "blue
others me a lot. Even x86 "port" is not feature complete in
> > > this regard (jump labels, alternatives,...) and who knows what lurks in
> > > the corners of the other architectures we support.
> > >
> > > So it is in itself reason enough to do something ab
fault.txt
>
>
> The following changes since commit 7307a29961ad2765ebcad162da699d2497c5c3f8:
>
> brcm: Add 43455 based AP6255 NVRAM for the Minix Neo Z83-4 Mini PC
> (2019-08-27 08:04:55 -0400)
>
> are available in the git repository at
The following commit has been merged into the perf/core branch of tip:
Commit-ID: 58993fb2c5115e93c52058e25f9b2ff289374870
Gitweb:
https://git.kernel.org/tip/58993fb2c5115e93c52058e25f9b2ff289374870
Author:Josh Poimboeuf
AuthorDate:Thu, 29 Aug 2019 17:41:19 -05:00
The following commit has been merged into the perf/core branch of tip:
Commit-ID: f1da0a6c136542b9571b30af27bc1e84254f7a47
Gitweb:
https://git.kernel.org/tip/f1da0a6c136542b9571b30af27bc1e84254f7a47
Author:Josh Poimboeuf
AuthorDate:Thu, 29 Aug 2019 17:41:20 -05:00
The following commit has been merged into the perf/core branch of tip:
Commit-ID: 00a263902ac3da886cf275663a938f503a853f68
Gitweb:
https://git.kernel.org/tip/00a263902ac3da886cf275663a938f503a853f68
Author:Josh Poimboeuf
AuthorDate:Thu, 29 Aug 2019 17:41:21 -05:00
The following commit has been merged into the perf/urgent branch of tip:
Commit-ID: 44d3bbb6f5e501b873218142fe08cdf62a4ac1f3
Gitweb:
https://git.kernel.org/tip/44d3bbb6f5e501b873218142fe08cdf62a4ac1f3
Author:Josh Hunt
AuthorDate:Mon, 19 Aug 2019 19:13:31 -04:00
Committer
code-map.txt
> +inat_tables_script = $(srctree)/tools/arch/x86/tools/gen-insn-attr-x86.awk
> +inat_tables_maps = $(srctree)/tools/arch/x86/lib/x86-opcode-map.txt
>
> $(OUTPUT)util/intel-pt-decoder/inat-tables.c: $(inat_tables_script)
> $(inat_tables_maps)
> $(call rule_mkdir)
Looks good to me. Thanks for fixing these!
--
Josh
etween the headers, but if
that's unavoidable then I guess we can just use the same 'diff -I' trick
we were using before in the check script(s).
--
Josh
On Fri, Aug 30, 2019 at 08:48:49AM -0700, Linus Torvalds wrote:
> On Fri, Aug 30, 2019 at 8:02 AM Josh Poimboeuf wrote:
> >
> > For KASAN, the Clang threshold for inserting memset() is *2* consecutive
> > writes instead of 17. Isn't that likely to cause tearing-
On Fri, Aug 30, 2019 at 12:44:24PM +0200, Arnd Bergmann wrote:
> On Fri, Aug 30, 2019 at 1:24 AM Josh Poimboeuf wrote:
> > On Wed, Aug 28, 2019 at 05:40:01PM +0200, Arnd Bergmann wrote:
> > > diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
> > > index
production, but we don't want
tearing-related bugs showing up there because somebody's going to end up
having to debug them regardless.
--
Josh
On Thu, Aug 29, 2019 at 10:24:45AM +0200, Peter Zijlstra wrote:
> On Wed, Aug 28, 2019 at 03:01:34PM -0500, Josh Poimboeuf wrote:
> > On Wed, Aug 28, 2019 at 10:56:25AM -0700, Randy Dunlap wrote:
> > > >> drivers/xen/gntdev.o: warning: objtool: g
If the build user has the CFLAGS variable set in their environment,
objtool blindly appends to it, which can cause unexpected behavior.
Clobber CFLAGS to ensure consistent objtool compilation behavior.
Reported-by: Valdis Kletnieks
Tested-by: Valdis Kletnieks
Signed-off-by: Josh Poimboeuf
On Wed, Aug 28, 2019 at 05:40:01PM +0200, Arnd Bergmann wrote:
> On Wed, Aug 28, 2019 at 5:28 PM Arnd Bergmann wrote:
> > On Wed, Aug 28, 2019 at 5:22 PM Josh Poimboeuf wrote:
> > > On Wed, Aug 28, 2019 at 05:13:59PM +0200, Arnd Bergmann wrote:
> > > >
> >
Now that there's a common version of the decoder for all tools, use it
instead of the local copy.
Also use perf's check-headers.sh script to diff the decoder files to
make sure they remain in sync with the kernel version. Objtool has a
similar check.
Signed-off-by: Josh Poimboeuf
---
tools
intel-pt-insn-decoder.c includes inat.c directly, so it already has an
implicit dependency on inat.c. The Build file dependency is redundant.
Signed-off-by: Josh Poimboeuf
---
tools/perf/util/intel-pt-decoder/Build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf
After a "make tools/perf", git reports the following untracked files:
tools/perf/feature/
tools/perf/fixdep
tools/perf/libtraceevent-dynamic-list
Add these generated files to perf's .gitignore file.
Signed-off-by: Josh Poimboeuf
---
tools/perf/.gitignore | 3 +++
1 file
It's kind of silly that we have *three* identical copies of the x86 insn
decoder in the kernel tree. Make it approximately 50% less silly by
reducing that number to two.
Josh Poimboeuf (4):
objtool: Move x86 insn decoder to a common location
perf: Update .gitignore file
perf intel-pt
, we don't need *two* of them.
Move objtool's copy of the decoder to a shared location, so that perf
will also be able to use it.
Signed-off-by: Josh Poimboeuf
---
tools/{objtool => }/arch/x86/include/asm/inat.h | 0
.../{objtool => }/arch/x86/include/asm/inat_types.h | 0
tools/{o
On Thu, Aug 29, 2019 at 10:53:56AM +0900, Masami Hiramatsu wrote:
> Hi Josh,
>
> On Wed, 28 Aug 2019 11:34:33 -0500
> Josh Poimboeuf wrote:
>
> > On Wed, Aug 28, 2019 at 11:13:31AM -0500, Josh Poimboeuf wrote:
> > > Turns out this patch does break somethin
On Wed, Aug 28, 2019 at 05:28:50PM +0200, Arnd Bergmann wrote:
> On Wed, Aug 28, 2019 at 5:22 PM Josh Poimboeuf wrote:
> > On Wed, Aug 28, 2019 at 05:13:59PM +0200, Arnd Bergmann wrote:
> > > On Wed, Aug 28, 2019 at 11:00 AM Arnd Bergmann wrote:
> > > > On Tue,
On Wed, Aug 28, 2019 at 03:13:21PM -0700, Nick Desaulniers wrote:
> On Tue, Aug 27, 2019 at 12:22 PM Josh Poimboeuf wrote:
> >
> > On Tue, Aug 27, 2019 at 09:00:52PM +0200, Arnd Bergmann wrote:
> > > On Tue, Aug 27, 2019 at 5:00 PM Ilie Halip wrote:
> > > >
&g
>
>
> then I get this one:
>
> lib/ubsan.o: warning: objtool: __ubsan_handle_out_of_bounds()+0x5d: call to
> ubsan_prologue() with UACCESS enabled
And of course I jinxed it by calling it easy.
Peter, how do you want to handle this?
Should we just disable UACCESS checking in lib/ubsan.c?
--
Josh
On Wed, Aug 28, 2019 at 03:30:00PM -0400, Valdis Klētnieks wrote:
> On Wed, 28 Aug 2019 10:10:04 -0500, Josh Poimboeuf said:
>
> > But I don't see how those warnings could get enabled: -Wsign-compare
> > -Wunused-parameter.
> >
> > Can you "make clean"
On Wed, Aug 28, 2019 at 05:29:39PM +0200, Arnd Bergmann wrote:
> On Wed, Aug 28, 2019 at 4:51 PM Josh Poimboeuf wrote:
> > On Wed, Aug 28, 2019 at 11:00:04AM +0200, Arnd Bergmann wrote:
> > > On Tue, Aug 27, 2019 at 11:22 PM 'Nick Desaulniers' via Clang Built
> > > L
On Wed, Aug 28, 2019 at 09:58:37AM -0700, Randy Dunlap wrote:
> On 8/27/19 8:40 PM, a...@linux-foundation.org wrote:
> > The mm-of-the-moment snapshot 2019-08-27-20-39 has been uploaded to
> >
> >http://www.ozlabs.org/~akpm/mmotm/
> >
> > mmotm-readme.txt says
> >
> > README for
On Wed, Aug 28, 2019 at 11:13:31AM -0500, Josh Poimboeuf wrote:
> Turns out this patch does break something:
>
> arch/x86/xen/enlighten_pv.o: warning: objtool: xen_cpuid()+0x25: can't find
> jump dest instruction at .text+0x9c
>
> I'll need to figure out a bette
On Wed, Aug 28, 2019 at 09:05:18AM -0700, Randy Dunlap wrote:
> On 8/28/19 8:51 AM, Josh Poimboeuf wrote:
> > On Tue, Aug 27, 2019 at 12:05:42PM -0700, Randy Dunlap wrote:
> >> On 8/27/19 8:59 AM, Josh Poimboeuf wrote:
> >>> On Tue, Aug 27, 2019 at 08:40:07AM -0700, R
On Tue, Aug 27, 2019 at 12:05:42PM -0700, Randy Dunlap wrote:
> On 8/27/19 8:59 AM, Josh Poimboeuf wrote:
> > On Tue, Aug 27, 2019 at 08:40:07AM -0700, Randy Dunlap wrote:
> >> On 8/27/19 2:05 AM, Stephen Rothwell wrote:
> >>> Hi all,
> >>>
> >>
sas_ss_flags = SS_DISABLE;
> }
>
> and that is called from save_altstack_ex(). Adding a barrier() after
> the sas_ss_sp() works around the issue, but is certainly not the
> best solution. Any other ideas?
Wow, is the compiler allowed to insert memset calls like that? Seems a
bit overbearing, at least in a kernel context. I don't recall GCC ever
doing it.
--
Josh
asonable though, maybe we should fix
them regardless and explicitly enable the warnings.
--
Josh
701 - 800 of 13971 matches
Mail list logo
