On Fri, 18 Dec 2020 10:25:19 -0300
Marcelo Henrique Cerri wrote:
> Hi, Ted and Jason.
>
> Any updates on that?
>
> I don't believe Torsten's concerns are simply about *applying* patches
> but more about these long periods of radio silence. That kills
Exactly. I could live with replies in the s
Hi Linus!
AFAIK it's legit to bother you directly with issues like this one?
I see certifications as the mere messengers here which tell us that
our /dev/random is technologically outdated. Input entropy amounts are
guesstimated in advance, obviously much too conservatively, compiled in
and never
On Mon, Nov 02, 2020 at 02:44:35PM +0100, Torsten Duwe wrote:
>
> Ted, if you don't have the time any more to take care of /dev/random,
> it's not a shame to hand over maintainership, especially given your
> long history of Linux contributions.
>
> Please do seriously
On Wed, 28 Oct 2020 19:07:28 +0100
Greg Kroah-Hartman wrote:
> On Wed, Oct 28, 2020 at 06:51:17PM +0100, Torsten Duwe wrote:
> > On Mon, 19 Oct 2020 21:28:50 +0200
> > Stephan Müller wrote:
> > [...]
> > > * Sole use of crypto for data processing:
> > [...]
On Mon, 19 Oct 2020 21:28:50 +0200
Stephan Müller wrote:
[...]
> * Sole use of crypto for data processing:
[...]
> - The LRNG uses only properly defined and implemented cryptographic
>algorithms unlike the use of the SHA-1 transformation in the
> existing /dev/random implementation.
>
> - H
On Fri, Oct 02, 2020 at 03:56:28PM +0200, Stephan Mueller wrote:
> Am Freitag, 2. Oktober 2020, 15:15:55 CEST schrieb Willy Tarreau:
>
> Hi Willy,
>
> > > And this is all ???
> >
> > Possibly a lot of people got used to seeing the numerous versions
> > and are less attentive to new series, it's
On Fri, Oct 02, 2020 at 03:33:58PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Oct 02, 2020 at 03:15:55PM +0200, Willy Tarreau wrote:
> > On Fri, Oct 02, 2020 at 02:38:36PM +0200, Torsten Duwe wrote:
> > > Almost two weeks passed and these are the "relevant" replies:
&
Almost two weeks passed and these are the "relevant" replies:
Jason personally does not like FIPS, and is afraid of
"subpar crypto". Albeit this patch set strictly isn't about
crypto at all; the crypto subsystem is in the unlucky position
to just depend on a good entropy source.
Greg claims that
On Tue, 22 Sep 2020 18:21:52 +0200
Greg Kroah-Hartman wrote:
> On Tue, Sep 22, 2020 at 03:23:44PM +0200, Torsten Duwe wrote:
> > On Mon, Sep 21, 2020 at 10:40:37AM +0200, Stephan Mueller wrote:
> > > Am Montag, 21. September 2020, 09:58:16 CEST schrieb Ni
On Mon, Sep 21, 2020 at 10:40:37AM +0200, Stephan Mueller wrote:
> Am Montag, 21. September 2020, 09:58:16 CEST schrieb Nicolai Stange:
>
> > - people dislike the approach of having two competing implementations for
> > what is basically the same functionality in the kernel.
>
> Is this really
Hi Arnd, Mark and others,
this may not be worth arguing but I'm currently fighting excessive
workarounds in another area and so this triggers me, so I have to make
a remark ;-)
On Tue, 5 May 2020 15:25:56 +0100
Mark Rutland wrote:
> On Tue, May 05, 2020 at 04:12:36PM +0200, Arnd Bergmann wrote:
Hi Mark!
On Fri, 18 Oct 2019 18:41:02 +0100 Mark Rutland
wrote:
> In the process of reworking this I spotted some issues that will get
> in the way of livepatching. Notably:
>
> * When modules can be loaded far away from the kernel, we'll
> potentially need a PLT for each function within a modu
Hi all,
left over from my previous Teres-I device tree series, here comes
the revised anx6345 node for the Teres-I, along with the driver.
The innolux panel attached to it is already known; pinebooks can be
enabled on top of this series, once their panels are introduced.
Changes from the respecti
On Thu, May 16, 2019 at 09:06:41AM -0700, Vasily Khoruzhick wrote:
>
> Driver can talk to the panel over AUX channel only after t1+t3, t1 is
> up to 10ms, t3 is up to 200ms.
This is after power-on. The boot loader needs to deal with this.
> It works with older version of driver
> that keeps pane
Hi all,
based on Maxime's sunxi-dt64-for-5.2, here is what I found so far
still missing in the device tree. Those bits and pieces have already
been submitted but were not yet applied. Currently I also have the
uart1 for bluetooth here, but I'm unsure about the bindings for the
in-kernel btuart.
s changed)
> On Fri, Jan 18, 2019 at 05:39:08PM +0100, Torsten Duwe wrote:
> > --- a/arch/arm64/include/asm/ftrace.h
> > +++ b/arch/arm64/include/asm/ftrace.h
> > @@ -14,9 +14,24 @@
> > #include
> >
> > #define HAVE_FUNCTION_GRAPH_FP_TEST
> > -#def
gt; + if (!strncmp(comm, list[i], strlen(list[i])))
> + return -EPERM;
^^^
should be -ECONNRESET.
Also, I'm missing a sysfs parameter file to add more bad guys dynamically.
> if (fd)
> return fd;
> --
> 2.16.4
But for a start, this is OK.
In any case, as already mentioned, big player Cisco has shown us that this is
definitely the way to go!
Rviewed-by: Torsten Duwe
On Mon, Mar 11, 2019 at 12:18:05PM +, Mark Rutland wrote:
> Hi Torsten,
>
> On Mon, Mar 11, 2019 at 12:49:46PM +0100, Torsten Duwe wrote:
> > On Wed, Feb 13, 2019 at 11:11:04AM +, Julien Thierry wrote:
> > > Hi Torsten,
> > >
> > > On 08/02/201
On Wed, Feb 13, 2019 at 11:11:04AM +, Julien Thierry wrote:
> Hi Torsten,
>
> On 08/02/2019 15:08, Torsten Duwe wrote:
> > Patch series v8, as discussed.
> > The whole series applies cleanly on 5.0-rc5
So what's the status now? Besides debatable minor style
Hi!
Documentation/devicetree/bindings/mfd/axp20x.txt nicely describes the
capabilities of the X-powers PMICs; however, it seems polyphasing is
left to comments only.
May I suggest to add a property "poly-phased", just to get the discussion
started? It could be a simple property in the current cas
Test whether gcc supports -fpatchable-function-entry and use it to promote
DYNAMIC_FTRACE to DYNAMIC_FTRACE_WITH_REGS. Amend support for the new
object section that holds the locations (__patchable_function_entries) and
define a proper "notrace" attribute to switch it off.
Signed-off-b
In preparation for arm64 supporting ftrace built on other compiler
options, let's have makefiles remove the $(CC_FLAGS_FTRACE)
flags, whatever these may be, rather than assuming '-pg'.
There should be no functional change as a result of this patch.
Signed-off-by: Torsten
t of this patch.
Signed-off-by: Torsten Duwe
---
drivers/firmware/efi/libstub/Makefile |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -16,9 +16,9 @@ cflags-$(CONFIG_X86) += -m$(BITS) -
, right
after ftrace_trampoline in an ftrace_trampolines[2] array, and double
the size of the corresponding special section.
Signed-off-by: Torsten Duwe
---
arch/arm64/include/asm/ftrace.h | 16
arch/arm64/include/asm/module.h |3
arch/arm64/kernel/entry-ftrace.S | 125
In preparation for arm64 supporting ftrace built on other compiler
options, let's have the arm64 makefiles remove the $(CC_FLAGS_FTRACE)
flags, whatever these may be, rather than assuming '-pg'.
There should be no functional change as a result of this patch.
Signed-off-b
Patch series v8, as discussed.
The whole series applies cleanly on 5.0-rc5
---
arch/arm64/Kconfig|4 +
arch/arm64/Makefile | 10 ++
arch/arm64/include/asm/ftrace.h | 16
arch/arm64/include/asm/module.h |3
arch/arm64/kernel/Makef
On Thu, Feb 07, 2019 at 09:51:57AM -0500, Steven Rostedt wrote:
> On Thu, 7 Feb 2019 10:33:50 +
> Julien Thierry wrote:
>
> > I don't see really much documentation on that function. As far as I can
> > tell it is only called once for each site (and if it didn't, we'd always
> > be placing the
On Thu, Feb 07, 2019 at 10:33:50AM +, Julien Thierry wrote:
>
>
> On 06/02/2019 15:05, Torsten Duwe wrote:
> > On Wed, Feb 06, 2019 at 08:59:44AM +, Julien Thierry wrote:
> >> Hi Torsten,
> >>
> >> On 18/01/2019 16:39, Torsten Duwe wrote:
&
On Wed, Feb 06, 2019 at 08:59:44AM +, Julien Thierry wrote:
> Hi Torsten,
>
> On 18/01/2019 16:39, Torsten Duwe wrote:
>
> > --- a/arch/arm64/kernel/ftrace.c
> > +++ b/arch/arm64/kernel/ftrace.c
> > @@ -133,17 +163,45 @@ int ftrace_make_call(stru
First thing that struck me is that the chip's reset is actually low active
reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
(please correct this in patches 11 and 12)
Consequently, you're using inverted values here in the driver:
> +static voi
On Thu, Oct 18, 2018 at 03:33:18PM +0800, Icenowy Zheng wrote:
> This patchset brings the support for Analogix ANX6345 RGB-(e)DP bridge,
> which is used by some Allwinner A64 laptops, such as Pinebook and Olimex
> TERES-I.
>
So what's the status here? I'm working on the Teres-I and I find myself
On Tue, Jan 22, 2019 at 02:55:12PM +0100, Ard Biesheuvel wrote:
> On Tue, 22 Jan 2019 at 14:28, Torsten Duwe wrote:
> >
> > On Tue, Jan 22, 2019 at 10:18:17AM +, Julien Thierry wrote:
> > > Hi Torsten,
> > >
> > > A few suggestions below.
> > &
On Tue, Jan 22, 2019 at 10:18:17AM +, Julien Thierry wrote:
> Hi Torsten,
>
> A few suggestions below.
>
> > +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
> > +#define ARCH_SUPPORTS_FTRACE_OPS 1
> > +#define REC_IP_BRANCH_OFFSET AARCH64_INSN_SIZE
> > +/* All we need is some magic value. Simply use
Hi Balbir!
On Tue, Jan 22, 2019 at 02:39:32PM +1300, Singh, Balbir wrote:
>
> On 1/19/19 5:39 AM, Torsten Duwe wrote:
> > + */
> > +ftrace_common_return:
> > + /* restore function args */
> > + ldp x0, x1, [sp]
> > + ldp x2, x3, [sp, #S_X2
Ftrace instrumentation might also be introduced by
-fpatchable-function-entry, not only -pg. Ensure the Makefiles are
flexible to filter out the respective flags in "notrace" directories.
Signed-off-by: Torsten Duwe
---
arch/arm64/kernel/Makefile|6 +++---
drivers/fi
: Torsten Duwe
---
Mark, if you see your ftrace entry macro code being represented correctly
here, please add your sign-off, As I've initially copied it from your mail.
---
arch/arm64/include/asm/ftrace.h | 17 -
arch/arm64/include/asm/module.h |3
arch/arm64/kernel/entry-ftr
Test whether gcc supports -fpatchable-function-entry and use it to promote
DYNAMIC_FTRACE to DYNAMIC_FTRACE_WITH_REGS. Amend support for the new object
section that holds the locations (__patchable_function_entries) and define
a proper "notrace" attribute to switch it off.
Signed-off-b
So here's v7 of ftrace with regs only. I've split out the CC_FLAGS_FTRACE
cleanup and the gcc activation into separate patches, respectively. The set
should include all of Mark's requested changes. Most notably, it now patches
in the first insn "mov x9, lr" right at startup, to avoid the races we
d
On Wed, Jan 16, 2019 at 09:57:39AM +, Julien Thierry wrote:
>
> I wanted to test this patch (and try to benchmark having the "mov x9,
> x30" always present in function prelude vs having two nops), but I
> cannot get this patch to apply (despite having a version including both
> commits below).
On Sun, 13 Jan 2019 23:33:56 +1100
Balbir Singh wrote:
> On Sat, Jan 12, 2019 at 02:45:41AM -0600, Segher Boessenkool wrote:
> > On Sat, Jan 12, 2019 at 12:09:14PM +1100, Balbir Singh wrote:
> > > Could you please define interesting frame on top a bit more?
> > > Usually the topmost return addres
On Fri, Jan 04, 2019 at 11:41:45PM +0100, Torsten Duwe wrote:
> On Fri, Jan 04, 2019 at 01:06:48PM -0500, Steven Rostedt wrote:
> > On Fri, 4 Jan 2019 17:50:18 +
> > Mark Rutland wrote:
> >
> > > At Linux Plumbers, I had a conversation with Steve Rostedt, and w
On Fri, Jan 04, 2019 at 01:06:48PM -0500, Steven Rostedt wrote:
> On Fri, 4 Jan 2019 17:50:18 +
> Mark Rutland wrote:
>
> > At Linux Plumbers, I had a conversation with Steve Rostedt, and we came
> > to the conclusion that (withut heavyweight synchronization) patching two
> > NOPs at runtime
On Mon, Dec 17, 2018 at 09:52:04AM +0530, Amit Daniel Kachhap wrote:
> There is no error message or crash but no useful output like below,
>
> /sys/kernel/tracing # echo wake_up_process > set_graph_function
> /sys/kernel/tracing # echo function_graph > current_tracer
> /sys/kernel/tracing # cat tr
special section.
Signed-off-by: Torsten Duwe
---
This patch applies on 4.20 with the additional changes
bdb85cd1d20669dfae813555dddb745ad09323ba
(arm64/module: switch to ADRP/ADD sequences for PLT entries)
and
7dc48bf96aa0fc8aa5b38cc3e5c36ac03171e680
(arm64: ftrace: always pass instrumented pc in
On Mon, Dec 17, 2018 at 09:52:04AM +0530, Amit Daniel Kachhap wrote:
> There is no error message or crash but no useful output like below,
>
> /sys/kernel/tracing # echo wake_up_process > set_graph_function
> /sys/kernel/tracing # echo function_graph > current_tracer
> /sys/kernel/tracing # cat tr
On Fri, 14 Dec 2018 21:45:03 +0530
Amit Daniel Kachhap wrote:
> Sorry I didn't mention my environment. I am using 4.20-rc3 and it has
> all the above 8 extra patches
> mentioned by you.
So that should be fine.
> I read your change description in v3 patchset. You had mentioned there
> that graph
On Thu, Dec 13, 2018 at 11:01:38PM +0530, Amit Daniel Kachhap wrote:
> On Fri, Nov 30, 2018 at 9:53 PM Torsten Duwe wrote:
>
> Hi Torsten,
>
> I was testing your patch and it seems to work fine for function trace. However
> function graph trace seems broken. Is it work in
special section
if .text.ftrace_trampoline is present in the module.
Signed-off-by: Torsten Duwe
---
As reliable stack traces are still being discussed, here is
dynamic ftrace with regs only, which has a value of its own.
I can see Mark has broken down an earlier version into smaller
patches
On Thu, Nov 08, 2018 at 01:12:42PM +0100, Ard Biesheuvel wrote:
>
> On 26 October 2018 at 16:21, Torsten Duwe wrote:
> > @@ -162,6 +165,114 @@ ftrace_graph_call://
> > ftrace_graph_cal
> >
> > mcount_exit
> >
On Thu, Nov 08, 2018 at 01:42:35PM +0100, Ard Biesheuvel wrote:
> On 26 October 2018 at 16:21, Torsten Duwe wrote:
> > /* The program counter just after the ftrace call site */
> > str lr, [x9, #S_PC]
> > +
> > /* The stack pointer as it
On Wed, 31 Oct 2018 14:18:19 +
Mark Rutland wrote:
> On Wed, Oct 31, 2018 at 02:19:07PM +0100, Jiri Kosina wrote:
> > Other architectures do rely on that. That's exactly for example why
> > on x86 we use '-pg -mfentry', to make sure we hook the function
> > *before* prologue.
>
> Ah, I'd
special section
if .text.ftrace_trampoline is present in the module.
Signed-off-by: Torsten Duwe
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -110,6 +110,8 @@ config ARM64
select HAVE_DEBUG_KMEMLEAK
select HAVE_DMA_CONTIGUOUS
select HAVE_DYNAMIC_FTRACE
+ select
nge the return address.
Make sure the graph tracer call hook is only called on the final function
entry in case regs->pc gets modified after an interception.
Signed-off-by: Torsten Duwe
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -120,6 +120,7 @@ config ARM64
;
save_stack_trace_tsk_reliable() can now trivially be implemented.
Modify arch/arm64/kernel/time.c as the only external caller so far
to recognise the new semantics.
I had to introduce a marker symbol kthread_return_to_user to tell
the normal origin of a kernel thread.
Signed-off-by: Torsten Duwe
--- a/arch/arm64/Kconfig
Hi again!
V4 should include all your requested changes. Since only Julien
commented "OK" on the reliable stacktrace part, I finished it on my
own. This set now passes the relevant tests in Libor's test suite, so
livepatching the kernel proper does work.
Remember to apply Jessica's addendum in ord
On Mon, Oct 22, 2018 at 02:53:10PM +0200, Miroslav Benes wrote:
> On Sat, 20 Oct 2018, Ard Biesheuvel wrote:
> > So I suppose this could get interesting in cases where modules are far
> > away from the kernel (i.e., more than -/+ 128 MB). Fortunately, the
> > modules themselves are always placed in
On Fri, Oct 19, 2018 at 01:59:01PM +0200, Miroslav Benes wrote:
>
> Torsten, could you include the outcome to your patch set once we settle on
> it? Thanks.
Absolutely! Whether as patch 4/4 or on its own and I refer to it -- we'll
figure it out.
Torsten
Hi Mark,
thank you for your very detailed feedback, I'll incorporate it
all into the next version, besides one issue:
On Tue, Oct 02, 2018 at 12:27:41PM +0100, Mark Rutland wrote:
>
> Please use the insn framework, as we do to generate all the other
> instruction sequences in ftrace.
>
> MOV (r
On Mon, Oct 01, 2018 at 05:57:52PM +0200, Ard Biesheuvel wrote:
> > --- a/arch/arm64/include/asm/ftrace.h
> > +++ b/arch/arm64/include/asm/ftrace.h
> > @@ -16,6 +16,17 @@
> > #define MCOUNT_ADDR((unsigned long)_mcount)
> > #define MCOUNT_INSN_SIZE AARCH64_INSN_SIZE
> >
> > +/* D
On Mon, Oct 01, 2018 at 05:06:06PM +0200, Ard Biesheuvel wrote:
> On 1 October 2018 at 17:03, Torsten Duwe wrote:
> > On Mon, Oct 01, 2018 at 04:52:27PM +0200, Ard Biesheuvel wrote:
> >>
> >> I guess we now have Kbuild/Kconfig support for this, no? I mean, we
>
On Mon, Oct 01, 2018 at 04:52:27PM +0200, Ard Biesheuvel wrote:
>
> I guess we now have Kbuild/Kconfig support for this, no? I mean, we
> can now show/hide options depending on the capabilities of the
> toolchain.
Config options depending on flags availability?
> I am not saying it would be a be
new semantics.
Signed-off-by: Torsten Duwe
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -127,8 +127,9 @@ config ARM64
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
- select HAVE_REGS_AND_STACK_ACCESS_API
select
Based on ftrace with regs, do the usual thing. Also allocate a
task flag for whatever consistency handling will be used.
Watch out for interactions with the graph tracer.
Signed-off-by: Torsten Duwe
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -119,6 +119,7 @@ config ARM64
for module PLTs.
Signed-off-by: Torsten Duwe
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -110,6 +110,7 @@ config ARM64
select HAVE_DEBUG_KMEMLEAK
select HAVE_DMA_CONTIGUOUS
select HAVE_DYNAMIC_FTRACE
+ select HAVE_DYNAMIC_FTRACE_WITH_REGS
select
: Torsten Duwe
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -508,9 +508,15 @@ config DYNAMIC_FTRACE
otherwise has native performance as long as no tracing is active.
config DYNAMIC_FTRACE_WITH_REGS
- def_bool y
+ bool "Include register content tracking in dy
Hi all!
Some substantial changes were requested, so I had to shuffle a few
things around. All the bigger changes are in now.
[Changes from v2]:
* ifeq($(CONFIG_DYNAMIC_FTRACE_WITH_REGS),y) instead of ifdef
* "fix" commit 06aeaaeabf69da4. (new patch 1)
Made DYNAMIC_FTRACE_WITH_REGS a real choi
eople here...
Signed-off-by: Torsten Duwe
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -127,8 +127,9 @@ config ARM64
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
- select HAVE_REGS_AND_STACK_ACCESS_API
handle LR in x9, as well as an
ftrace_regs_caller that additionally writes out a set of pt_regs
for inspection.
Signed-off-by: Torsten Duwe
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -110,6 +110,7 @@ config ARM64
select HAVE_DEBUG_KMEMLEAK
select HAVE_DMA_CONTIGUOUS
Based on ftrace with regs, do the usual thing. Also allocate a
task flag for whatever consistency handling will be used.
Watch out for interactions with the graph tracer.
Signed-off-by: Torsten Duwe
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -119,6 +119,7 @@ config ARM64
Hi all!
Here's v2; I hope I have incorporated all feedback properly.
Julien: #S_X28 + 8 is in, but ftrace_modify_call() is referenced
from generic code: kernel/trace/ftrace.c __ftrace_replace_code()
And I'd *really* like some feedback from ARM/Linaro/... on the stack
unwinder!
[Changes from v1]:
[working on V2 with your feedback]
On Tue, Aug 14, 2018 at 12:04:33PM -0400, Steven Rostedt wrote:
> On Tue, 14 Aug 2018 09:33:52 +0100
> Julien Thierry wrote:
> > >> Shouldn't this be an error? The option -fpatchable-function-entry has
> > >> been added to the CC_FLAGS_FTRACE, so any call to the
maybe save_stack_trace_tsk_reliable() will need its own callback.
Any comments welcome.
Signed-off-by: Torsten Duwe
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -127,8 +127,9 @@ config ARM64
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK
Based on ftrace with regs, do the usual thing. Also allocate a
task flag for whatever consistency handling is implemented.
Watch out for interactions with the graph tracer.
This code has been compile-tested, but has not yet seen any
heavy livepatching.
Signed-off-by: Torsten Duwe
diff --git a
in x9.
This code has successfully passed the FTRACE_STARTUP_TEST.
Signed-off-by: Torsten Duwe
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -110,6 +110,7 @@ config ARM64
select HAVE_DEBUG_KMEMLEAK
select HAVE_DMA_CONTIGUOUS
select HAVE_DYNAMIC_FTRACE
+ select
Hi all,
with gcc-8 now being out which includes the patchable-function-entries feature,
I can now propose the live patching framework based on it. The series consists
of 3 parts:
1st: Implement ftrace with regs -- uses gcc-8's nop insertions to patch in
ftrace calls.
2nd: "Classic" live pat
On Wed, May 09, 2018 at 11:41:09AM +1000, Michael Ellerman wrote:
> Josh Poimboeuf writes:
>
> > Generally we refer to it as "the consistency model".
[...]
>
> We use "powerpc" as the prefix.
>
> So I've used:
>
> powerpc/livepatch: Implement reliable stack tracing for the consistency
> mod
On Mon, 7 May 2018 10:42:08 -0500
Josh Poimboeuf wrote:
> The subject doesn't actively describe what the patch does, maybe
> change it to something like:
>
> powerpc: Add support for HAVE_RELIABLE_STACKTRACE
>
> or maybe
>
> powerpc: Add support for livepatch consistency model
Maybe $SUBJ
c64le
that checks for the above conditions, where possible.
Signed-off-by: Torsten Duwe
Signed-off-by: Nicolai Stange
---
v3:
* big bunch of fixes, credits go to Nicolai Stange:
- get the correct return address from the graph tracer,
should it be active.
IMO this should be mov
On Thu, 8 Mar 2018 10:26:16 -0600
Josh Poimboeuf wrote:
> This doesn't seem to address some of my previous concerns:
You're right. That discussion quickly headed towards objtool
and I forgot about this one paragraph with the remarks.
> - Bailing on interrupt/exception frames
That is a good que
On Fri, 9 Mar 2018 08:43:33 +1100
Balbir Singh wrote:
> On Tue, 27 Feb 2018 17:09:24 +0100
> Torsten Duwe wrote:
> > +save_stack_trace_tsk_reliable(struct task_struct *tsk,
> > + struct stack_trace *trace)
>
> Just double checking
tch may be unneccessarily limited to ppc64le, but OTOH the only
user of this flag so far is livepatching, which is only implemented on
PPCs with 64-LE, a.k.a. ELF ABI v2.
This change also implements save_stack_trace_tsk_reliable() for ppc64
that checks for the above conditions, where possible.
Signed-off-by:
e successful
exit stricter, i.e. hit the initial stack value exactly instead of just
a window. Also, the check for kernel code looks clumsy IMHO. IOW:
Comments more than welcome!
Most of it is Copy&Waste, nonetheless:
Signed-off-by: Torsten Duwe
diff --git a/arch/powerpc/kernel/stacktrace.c
On Mon, Dec 18, 2017 at 12:56:22PM -0600, Josh Poimboeuf wrote:
> On Mon, Dec 18, 2017 at 03:33:34PM +1000, Nicholas Piggin wrote:
> > On Sun, 17 Dec 2017 20:58:54 -0600
> > Josh Poimboeuf wrote:
> >
> > > On Fri, Dec 15, 2017 at 07:40:09PM +1000, Nicholas Piggin wrote:
> > > > On Tue, 12 Dec 201
On Tue, Dec 12, 2017 at 01:12:37PM +0100, Miroslav Benes wrote:
>
> I think that this is not enough. You need to also implement
> save_stack_trace_tsk_reliable() for powerpc defined as __weak in
> kernel/stacktrace.c. See arch/x86/kernel/stacktrace.c for reference, but I
> think it would be muc
tch may be unneccessarily limited to ppc64le, but OTOH the only
user of this flag so far is livepatching, which is only implemented on
PPCs with 64-LE, a.k.a. ELF ABI v2.
Signed-off-by: Torsten Duwe
---
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c51e6ce42e7a..3e3a6ab2e089 100644
On Fri, Oct 20, 2017 at 08:24:32AM -0500, Josh Poimboeuf wrote:
> On Fri, Oct 20, 2017 at 02:44:32PM +0200, Torsten Duwe wrote:
> > On Thu, Oct 19, 2017 at 06:00:54PM +0200, Miroslav Benes wrote:
> > > On Thu, 19 Oct 2017, Josh Poimboeuf wrote:
> > > >
> > &
On Thu, Oct 19, 2017 at 06:00:54PM +0200, Miroslav Benes wrote:
> On Thu, 19 Oct 2017, Josh Poimboeuf wrote:
> >
> > Sounds nice, though I wonder what the obstacles are?
>
> Those GCC optimizations you mentioned below and which I didn't connect to
> klp-convert itself.
I have a bad feeling abou
On Tue, Oct 17, 2017 at 03:44:21PM +0300, Ruslan Bilovol wrote:
> On 10/13/2017 04:18 PM, Torsten Duwe wrote:
> >
> > I also have the coresponding kernel patch(es) here. IIRC I already sent
> > tham to LKML. I'll re-send them once there are more gcc's with
on to the livepatch community[1] and gcc
> > community (mfentry feature on aarch64)[2]. And then, there were an another
> > gcc solution from linaro [3], which proposes to implement a new option
> > -fprolog-pad=N that generate a pad of N nops at the beginning of each
> > fun
On Tue, Jun 20, 2017 at 10:21:17PM +0800, Sean Wang wrote:
> Hi Herbert,
>
> thanks for effort reviewing on those patches.
>
> By the way, also loop in Torsten
>
> Could you kindly guide me how to determine appropriate
> rng->ops.quality value used by the driver?
>
> I have tested with rngtest
On Fri, Feb 03, 2017 at 01:05:48PM +0100, Torsten Duwe wrote:
>
> If Herbert does not have a better idea, I suggest to back out this change and
> fix
> dynamically allocated key structures for the individual algorithms instead,
> for
> the older branches.
So, the solution
On Wed, Feb 01, 2017 at 01:13:05PM +0100, Torsten Duwe wrote:
> Hi Herbert,
>
> you sent a backport of 6de62f15b581f920ade22d758f4c338311c2f0d4 to be included
> in the 3.12 branch (as b2a0707817d3dec83652bb460a7775613058ae), but this
> leaves
> af_alg broken for unke
Hi Herbert,
you sent a backport of 6de62f15b581f920ade22d758f4c338311c2f0d4 to be included
in the 3.12 branch (as b2a0707817d3dec83652bb460a7775613058ae), but this leaves
af_alg broken for unkeyed hash functions:
f382cd5ac26674877143fa7d9c0ea23c6640e706 (3.12 just before your commit) :
socket(PF
On Mon, Jul 11, 2016 at 04:03:08PM +0200, Miroslav Benes wrote:
> On Mon, 27 Jun 2016, Torsten Duwe wrote:
> > +
> > +#ifdef CONFIG_LIVEPATCH
>
> A nit but we removed such guards in the other header files.
I just notice this has fallen between the cracks :-/
Torsten
00080a08c0
fc00081335f8 stp x29, x30, [sp,#-48]!
fc00081335fc mov x29, sp
as well as an ftrace_caller that can handle these call sites.
Now ARCH_SUPPORTS_FTRACE_OPS as a benefit, and the graph caller
still works, too.
Signed-off-by: Li Bin
Signed-off-by: Torsten Duwe
---
arch/arm
straightforward on top of FTRACE_WITH_REGS.
Signed-off-by: Torsten Duwe
---
arch/arm64/Kconfig | 3 +++
arch/arm64/include/asm/livepatch.h | 37 +
arch/arm64/kernel/entry-ftrace.S | 13 +
3 files changed, 53 insertions
h caller if the addresses are _not_ equal!
Changes since v1:
* instead of a comment "should be CC_USING_PROLOG_PAD":
do it. CC_FLAGS_FTRACE holds it now, and the IPA
disabler has become a separate issue (see above).
Torsten Duwe (2):
arm64: implement FTRACE_WITH_REGS
arm64
On Fri, Jul 08, 2016 at 05:08:08PM -0400, Steven Rostedt wrote:
> On Fri, 8 Jul 2016 22:24:55 +0200
> Torsten Duwe wrote:
>
> > On Fri, Jul 08, 2016 at 11:57:10AM -0400, Steven Rostedt wrote:
> > > On Fri, 8 Jul 2016 10:48:24 -0500
> > > Josh Poimboeuf wro
On Fri, Jul 08, 2016 at 11:57:10AM -0400, Steven Rostedt wrote:
> On Fri, 8 Jul 2016 10:48:24 -0500
> Josh Poimboeuf wrote:
> >
> > Here, with -fprolog-pad, it's already a nop, so no change is needed.
> >
Yes, exactly.
> That's what I was thinking. But as I stated in another email (probably
>
On Fri, Jul 08, 2016 at 04:58:00PM +0200, Petr Mladek wrote:
> On Mon 2016-06-27 17:17:17, Torsten Duwe wrote:
> > Once gcc is enhanced to optionally generate NOPs at the beginning
> > of each function, like the concept proven in
> > https://gcc.gnu.org/ml/gcc-patches/
1 - 100 of 336 matches
Mail list logo
