...@gmail.com
Reviewed-by: Petr Mladek pmla...@suse.cz
Makes perfect sense and builds now :-)
Best Regards,
Petr
CC: Michael Ellerman m...@ellerman.id.au
---
include/linux/printk.h | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/include/linux/printk.h b
On Fri 2014-11-21 05:25:30, Masami Hiramatsu wrote:
Set FTRACE_OPS_FL_IPMODIFY flag only for the probes which can change
regs-ip, which has kprobe-break_handler.
Currently we can not put jprobe and another ftrace handler which
changes regs-ip on the same function because all kprobes have
character
It did not make much sense and debugging pointed to the bug
described above.
Signed-off-by: Petr Mladek pmla...@suse.cz
---
arch/x86/kernel/kprobes/core.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes
On Mon 2015-02-02 17:40:10, Masami Hiramatsu wrote:
(2015/01/31 0:45), Petr Mladek wrote:
can_probe() checks if the given address points to the beginning of
an instruction. It analyzes all the instructions from the beginning
of the function until the given address. The code might
On Tue 2015-02-03 16:41:39, Masami Hiramatsu wrote:
(2015/02/03 2:48), Petr Mladek wrote:
can_probe() checks if the given address points to the beginning of
an instruction. It analyzes all the instructions from the beginning
of the function until the given address. The code might
-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Signed-off-by: Petr Mladek pmla...@suse.cz
---
arch/x86/kernel/kprobes/core.c | 6 ++
1 file changed, 6 insertions(+)
This is follow up for the patch ([PATCH v2] kprobes/x86: Use 5-byte NOP
when the code might be modified by ftrace) based
On Tue 2015-02-03 12:38:28, Petr Mladek wrote:
On Tue 2015-02-03 16:41:39, Masami Hiramatsu wrote:
(2015/02/03 2:48), Petr Mladek wrote:
can_probe() checks if the given address points to the beginning of
an instruction. It analyzes all the instructions from the beginning
On Mon 2015-02-02 15:57:20, Petr Mladek wrote:
On Mon 2015-02-02 17:40:10, Masami Hiramatsu wrote:
(2015/01/31 0:45), Petr Mladek wrote:
can_probe() checks if the given address points to the beginning of
an instruction. It analyzes all the instructions from the beginning
much sense and debugging pointed to the bug
described above.
Signed-off-by: Petr Mladek pmla...@suse.cz
---
arch/x86/kernel/kprobes/core.c | 42 --
1 file changed, 28 insertions(+), 14 deletions(-)
Changes against v1:
+ always use 5-byte NOP for ftrace
On Tue 2015-01-20 18:51:49, Pranith Kumar wrote:
There are missing dummy routines for log_buf_addr_get() and log_buf_len_get()
for when CONFIG_PRINTK is not set causing build failures.
This patch adds these dummy routines at the appropriate location.
Signed-off-by: Pranith Kumar
func-new_func has been accessed after rcu_read_unlock() in klp_ftrace_handler()
and therefore the access was not protected.
Signed-off-by: Petr Mladek pmla...@suse.cz
---
kernel/livepatch/core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/livepatch/core.c b
...
Yup, it looks good to me.
Reviewed-by: Petr Mladek pmla...@suse.cz
Miroslav
---
kernel/livepatch/core.c | 67
+
1 file changed, 17 insertions(+), 50 deletions(-)
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
On Wed 2015-02-18 22:22:05, Ingo Molnar wrote:
* Petr Mladek pmla...@suse.cz wrote:
On Tue 2015-02-03 16:41:39, Masami Hiramatsu wrote:
(2015/02/03 2:48), Petr Mladek wrote:
can_probe() checks if the given address points to the beginning of
an instruction. It analyzes all
-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Signed-off-by: Petr Mladek pmla...@suse.cz
Acked-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
---
arch/x86/kernel/kprobes/core.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel
pointed to the bug
described above.
Signed-off-by: Petr Mladek pmla...@suse.cz
Acked-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
---
arch/x86/kernel/kprobes/core.c | 42 --
1 file changed, 28 insertions(+), 14 deletions(-)
diff --git a/arch/x86
On Fri 2015-02-20 13:52:23, Ingo Molnar wrote:
* Masami Hiramatsu masami.hiramatsu...@hitachi.com wrote:
(2015/02/20 19:26), Ingo Molnar wrote:
* Petr Mladek pmla...@suse.cz wrote:
can_probe() checks if the given address points to the
beginning of an instruction
pointed to the bug
described above.
Signed-off-by: Petr Mladek pmla...@suse.cz
Acked-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
---
arch/x86/kernel/kprobes/core.c | 42 --
1 file changed, 28 insertions(+), 14 deletions(-)
diff --git a/arch/x86
+ fix indentation of the touched comment
Petr Mladek (2):
kprobes/x86: Use 5-byte NOP when the code might be modified by ftrace
kprobes/x86: Check for invalid ftrace location in
__recover_probed_insn()
arch/x86/kernel/kprobes/core.c | 54 +++---
arch
code can not
get recovered.
Suggested-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Signed-off-by: Petr Mladek pmla...@suse.cz
---
arch/x86/kernel/kprobes/core.c | 12
arch/x86/kernel/kprobes/opt.c | 2 ++
2 files changed, 14 insertions(+)
diff --git a/arch/x86/kernel/kprobes
/1419108071-11607-1-git-send-email...@linux.com
Signed-off-by: Christoph Jaeger c...@linux.com
Reviewed-by: Petr Mladek pmla...@suse.cz
Thanks for the patch.
Best Regards,
Petr
---
kernel/livepatch/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel
of an aggregated probe.
It would be enough to disable only the new one but we do not know which one it
was. They should be in sync anyway.
Signed-off-by: Petr Mladek pmla...@suse.cz
Acked-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
---
Hi,
I resend this patch separately and have just added the acked
of an aggregated probe.
It would be enough to disable only the new one but we do not know which one it
was. They should be in sync anyway.
Signed-off-by: Petr Mladek pmla...@suse.cz
Acked-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
---
Changes in v3:
+ added brackets for complex if-statement
might get wrong.
[jpoim...@redhat.com: use one boolean instead of two]
Signed-off-by: Petr Mladek pmla...@suse.cz
---
Changes in v3:
+ reverted back to v1:
+ cannot handle coming modules in UNFORMED module state because
kallsyms are not ready = need to use the boolean again
+ neither
On Sat 2015-03-07 11:34:36, Rusty Russell wrote:
Petr Mladek pmla...@suse.cz writes:
Existing live patches are removed from going modules using a notify handler.
There are two problems with the current implementation.
First, new patch could still see the module in the GOING state even
On Tue 2015-03-10 12:53:21, Rusty Russell wrote:
Petr Mladek pmla...@suse.cz writes:
On Sat 2015-03-07 11:34:36, Rusty Russell wrote:
I don't think you should handle going modules at all. Rarely happens,
and it should happen fast.
I would like to handle it correctly. It would be pity
On Mon 2015-03-09 09:40:55, Josh Poimboeuf wrote:
On Mon, Mar 09, 2015 at 02:25:28PM +0100, Petr Mladek wrote:
There is a notifier that handles live patches for coming and going modules.
It takes klp_mutex lock to avoid races with coming and going patches but
it does not keep the lock all
On Tue 2015-03-10 09:22:04, Josh Poimboeuf wrote:
On Tue, Mar 10, 2015 at 01:01:07PM +0100, Petr Mladek wrote:
On Mon 2015-03-09 09:40:55, Josh Poimboeuf wrote:
On Mon, Mar 09, 2015 at 02:25:28PM +0100, Petr Mladek wrote:
diff --git a/kernel/module.c b/kernel/module.c
index
On Fri 2015-03-06 08:54:23, Josh Poimboeuf wrote:
On Fri, Mar 06, 2015 at 03:00:13PM +0100, Petr Mladek wrote:
This brings me back to the original idea with that boolean that
marks the state before and after the coming notifier (module_init).
We could use a bitfield instead of the two
On Fri 2015-03-06 20:37:26, Masami Hiramatsu wrote:
(2015/03/06 19:51), Petr Mladek wrote:
On Fri 2015-03-06 10:24:27, Masami Hiramatsu wrote:
(2015/03/05 23:18), Josh Poimboeuf wrote:
On Thu, Mar 05, 2015 at 09:52:41AM +0900, Masami Hiramatsu wrote:
(2015/03/04 22:17), Petr Mladek wrote
On Fri 2015-03-06 11:20:32, Petr Mladek wrote:
On Thu 2015-03-05 13:34:33, Josh Poimboeuf wrote:
On Thu, Mar 05, 2015 at 04:45:13PM +0100, Petr Mladek wrote:
Existing live patches are applied to loaded modules using a notify
handler.
There are two problems with this approach
On Thu 2015-03-05 13:34:33, Josh Poimboeuf wrote:
On Thu, Mar 05, 2015 at 04:45:13PM +0100, Petr Mladek wrote:
Existing live patches are applied to loaded modules using a notify handler.
There are two problems with this approach.
First, errors from module notifiers are ignored and could
On Fri 2015-03-06 10:24:27, Masami Hiramatsu wrote:
(2015/03/05 23:18), Josh Poimboeuf wrote:
On Thu, Mar 05, 2015 at 09:52:41AM +0900, Masami Hiramatsu wrote:
(2015/03/04 22:17), Petr Mladek wrote:
On Tue 2015-03-03 17:02:22, Josh Poimboeuf wrote:
It's possible for klp_register_patch
On Tue 2015-03-10 09:47:01, Josh Poimboeuf wrote:
On Tue, Mar 10, 2015 at 03:36:17PM +0100, Petr Mladek wrote:
On Tue 2015-03-10 09:22:04, Josh Poimboeuf wrote:
On Tue, Mar 10, 2015 at 01:01:07PM +0100, Petr Mladek wrote:
On Mon 2015-03-09 09:40:55, Josh Poimboeuf wrote:
On Mon, Mar
On Tue 2015-03-10 17:58:02, Petr Mladek wrote:
On Tue 2015-03-10 09:47:01, Josh Poimboeuf wrote:
On Tue, Mar 10, 2015 at 03:36:17PM +0100, Petr Mladek wrote:
On Tue 2015-03-10 09:22:04, Josh Poimboeuf wrote:
On Tue, Mar 10, 2015 at 01:01:07PM +0100, Petr Mladek wrote:
On Mon 2015-03
Hi Masami,
On Fri 2015-02-27 16:32:01, Masami Hiramatsu wrote:
Hi Petr,
(2015/02/27 1:13), Petr Mladek wrote:
arm_kprobe_ftrace() could fail, especially after introducing ftrace IPMODIFY
flag and LifePatching. This patch set adds the error handling and also some
related fixes.
Hmm
...@redhat.com: use one boolean instead of two]
Signed-off-by: Petr Mladek pmla...@suse.cz
---
Changes in v4:
+ remove unnecessary check for MODULE_STATE_UNFORMED
+ remove unnecessary mod-klp_alive initialization
Changes in v3:
+ reverted back to v1:
+ cannot handle coming modules in UNFORMED
On Mon 2015-03-23 11:33:27, Ingo Molnar wrote:
* Petr Mladek pmla...@suse.cz wrote:
On Mon 2015-03-23 09:54:26, Ingo Molnar wrote:
* Petr Mladek pmla...@suse.cz wrote:
arm_kprobe_ftrace() could fail, especially after introducing ftrace
IPMODIFY flag and LifePatching
On Tue 2015-03-03 08:55:17, Josh Poimboeuf wrote:
Hi Petr,
Good find. Some comments below.
On Tue, Mar 03, 2015 at 12:38:29PM +0100, Petr Mladek wrote:
There is a notifier that handles live patches for coming and going modules.
It takes klp_mutex lock to avoid races with coming
On Mon 2015-03-02 22:25:01, Wang Nan wrote:
Makes ftrace calls init_kprobes_on_ftrace() when ftrace_init()
finished. Before this call, marks kprobes on ftrace with
'KPROBE_FLAG_FTRACE_EARLY' instead of 'KPROBE_FLAG_FTRACE' to make
kprobe not to kprobe treats these kprobes as ftrace kprobes.
On Tue 2015-03-03 13:09:05, Wang Nan wrote:
Before ftrace convertin instruction to nop, if an early kprobe is
registered then unregistered, without this patch its first bytes will
be replaced by head of NOP, which may confuse ftrace.
Actually, since we have a patch which convert ftrace entry
.
The moment you release the RCU-sched read lock, the object can be dead
and gone.
Cc: Seth Jennings sjenn...@redhat.com
Cc: Josh Poimboeuf jpoim...@redhat.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Cc: Miroslav Benes mbe...@suse.cz
Cc: Petr Mladek pmla
On Wed 2015-03-04 09:34:15, Josh Poimboeuf wrote:
On Wed, Mar 04, 2015 at 02:17:52PM +0100, Petr Mladek wrote:
On Tue 2015-03-03 17:02:22, Josh Poimboeuf wrote:
It's possible for klp_register_patch() to see a module before the COMING
notifier is called, or after the GOING notifier
-by: Petr Mladek pmla...@suse.cz
---
include/linux/livepatch.h | 10 +
kernel/livepatch/core.c | 94 +++
kernel/module.c | 9 +
3 files changed, 89 insertions(+), 24 deletions(-)
diff --git a/include/linux/livepatch.h b/include/linux
solution
of coming modules.
Changes in v2:
+ split fix for coming and going modules
+ call klp_module_init() directly instead of using a handler
+ check if mod is not NULL when checking the module state
+ use the boolean flag only for going handler
Petr Mladek (2):
livepatch/module: Apply
and things might get wrong.
Signed-off-by: Petr Mladek pmla...@suse.cz
---
include/linux/module.h | 4
kernel/livepatch/core.c | 30 ++
2 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index
-by: Josh Poimboeuf jpoim...@redhat.com
Reviewed-by: Petr Mladek pmla...@suse.cz
Yup, the call is redundant.
Best Regards,
Petr
---
kernel/livepatch/core.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 01ca088..a74e4e8 100644
Ah, I have missed the comments in the code in the first reply.
On Tue 2015-03-03 08:55:17, Josh Poimboeuf wrote:
Hi Petr,
Good find. Some comments below.
On Tue, Mar 03, 2015 at 12:38:29PM +0100, Petr Mladek wrote:
There is a notifier that handles live patches for coming and going
.
Reported-by: Petr Mladek pmla...@suse.cz
Signed-off-by: Josh Poimboeuf jpoim...@redhat.com
---
kernel/livepatch/core.c | 53
+
1 file changed, 49 insertions(+), 4 deletions(-)
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index
On Wed 2015-03-04 14:17:52, Petr Mladek wrote:
On Tue 2015-03-03 17:02:22, Josh Poimboeuf wrote:
It's possible for klp_register_patch() to see a module before the COMING
notifier is called, or after the GOING notifier is called.
That can cause all kinds of ugly races. As Pter Mladek
On Thu 2015-03-05 09:52:41, Masami Hiramatsu wrote:
(2015/03/04 22:17), Petr Mladek wrote:
On Tue 2015-03-03 17:02:22, Josh Poimboeuf wrote:
It's possible for klp_register_patch() to see a module before the COMING
notifier is called, or after the GOING notifier is called.
That can cause
first, whether the normal disable_patch() or
the module notifier. There is nothing to do once the patch is disabled.
Signed-off-by: Petr Mladek pmla...@suse.cz
---
include/linux/module.h | 5 +
kernel/livepatch/core.c | 20 +++-
kernel/module.c | 6 +-
3 files
On Tue 2015-02-24 16:38:18, Masami Hiramatsu wrote:
Hi Petr,
Sorry I missed this mail.
Thanks a lot for answering it with many valuable information.
(2015/01/27 1:14), Petr Mladek wrote: On Fri 2014-11-21 05:25:30, Masami
Hiramatsu wrote:
Set FTRACE_OPS_FL_IPMODIFY flag only
On Tue 2015-02-24 11:23:29, Ingo Molnar wrote:
What gradual improvements in live upgrade latency am I
talking about?
- For example the majority of pure user-space process
pages in RAM could be saved from the old kernel over
into the new kernel - i.e. they'd stay in place in RAM,
On Tue 2015-02-24 20:47:06, Masami Hiramatsu wrote:
(2015/02/24 17:52), Petr Mladek wrote:
On Tue 2015-02-24 16:38:18, Masami Hiramatsu wrote:
Hi Petr,
Sorry I missed this mail.
Thanks a lot for answering it with many valuable information.
(2015/01/27 1:14), Petr Mladek wrote
. kprobes_all_disarmed is always cleared and
the message about finished action is always printed. There is going to be
a separate patch that will improve the behavior.
Signed-off-by: Petr Mladek pmla...@suse.cz
---
kernel/kprobes.c | 47 ---
1 file changed, 32 insertions
this separately.
This patch fixes __disable_kprobe(), so that it does not disarm
when the Kprobe is not armed.
Note that I reverted the condition if (kprobe_disabled(p)) and used goto
out there. It helped to keep the code nesting on a reasonable level.
Signed-off-by: Petr Mladek pmla...@suse.cz
---
kernel
effort. It tries to disable as many
Kprobes as possible. It always reports success. It returns the last error
code. There is going to be separate patch that will improve this behavior.
Signed-off-by: Petr Mladek pmla...@suse.cz
---
kernel/kprobes.c | 77
to restore the
original state.
The kprobes_all_disarmed flag is modified only when all Kprobes were
successfully switched.
In case of error, we call wait_for_kprobe_optimizer() also in
arm_all_kprobes() to be on the safe side.
Signed-off-by: Petr Mladek pmla...@suse.cz
---
kernel/kprobes.c | 124
the Kprobes documentation.
Signed-off-by: Petr Mladek pmla...@suse.cz
---
Documentation/kprobes.txt | 5 +++--
kernel/kprobes.c | 4 +++-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
index 4227ec2e3ab2..8de83af9cccb
The global kprobes_all_disarmed flag says that all Kprobes are disarmed
even when they are marked as enabled. Therefore the flag should get
checked by kprobe_disarmed().
Signed-off-by: Petr Mladek pmla...@suse.cz
---
kernel/kprobes.c | 13 -
1 file changed, 12 insertions(+), 1
to get it working. I wonder if there is any other scenario that
I have missed.
Of course, I also wait for feedback how to make things better.
Petr Mladek (7):
kprobes: Disable Kprobe when ftrace arming fails
kprobes: Propagate error from arm_kprobe_ftrace()
kprobes: Propagate error from
of an aggregated probe.
It would be enough to disable only the new one but we do not know which one it
was. They should be in sync anyway.
Signed-off-by: Petr Mladek pmla...@suse.cz
---
kernel/kprobes.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/kernel
On Mon 2015-03-23 23:36:00, Jiri Kosina wrote:
On Mon, 23 Mar 2015, Ingo Molnar wrote:
wth is a 'universe' in this context?
We use the term universe to define whether the system or task uses
original or patched functions. It is especially important for patches
that modify
On Mon 2015-03-23 09:58:53, Steven Rostedt wrote:
On Mon, 23 Mar 2015 14:53:06 +0100
Ingo Molnar mi...@kernel.org wrote:
I think it has to do with their RCU like patching functionality,
where some tasks are still executing the old function and others are
executing the new
On Mon 2015-03-23 09:54:26, Ingo Molnar wrote:
* Petr Mladek pmla...@suse.cz wrote:
arm_kprobe_ftrace() could fail, especially after introducing ftrace
IPMODIFY flag and LifePatching. But this situation is not properly
handled.
s/LifePatching/LivePatching?
Great catch
and accounting for the buffer
size properly isn't that complicated.
This patch defines CONSOLE_EXT_LOG_MAX as 8192 and updates
devkmsg_read() so that it limits output accordingly.
Signed-off-by: Tejun Heo t...@kernel.org
Reviewed-by: Petr Mladek pmla...@suse.cz
It is just a refactoring and does
On Mon 2015-04-20 14:11:36, Petr Mladek wrote:
On Thu 2015-04-16 19:03:38, Tejun Heo wrote:
devkmsg_read() uses 8k buffer and assumes that the formatted output
message won't overrun which seems safe given LOG_LINE_MAX, the current
use of dict and the escaping method being used; however
Reviewed-by: Petr Mladek pmla...@suse.cz
I like the split of the long function.
Best Regards,
Petr
Cc: Kay Sievers k...@vrfy.org
Cc: Petr Mladek pmla...@suse.cz
---
kernel/printk/printk.c | 157
++---
1 file changed, 85 insertions(+), 72
.
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Kay Sievers k...@vrfy.org
Cc: Petr Mladek pmla...@suse.cz
---
kernel/printk/printk.c | 46 --
1 file changed, 24 insertions(+), 22 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk
On Mon 2015-04-20 17:43:07, Petr Mladek wrote:
On Thu 2015-04-16 19:03:41, Tejun Heo wrote:
printk log_buf keeps various metadata for each message including its
sequence number and timestamp. The metadata is currently available
only through /dev/kmsg and stripped out before passed onto
with verbatim terms.
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Kay Sievers k...@vrfy.org
Cc: Petr Mladek pmla...@suse.cz
---
include/linux/console.h | 1 +
kernel/printk/printk.c | 141
+---
2 files changed, 123 insertions(+), 19 deletions
On Tue 2015-04-28 10:10:14, Tejun Heo wrote:
Hello, Petr.
On Tue, Apr 28, 2015 at 11:42:44AM +0200, Petr Mladek wrote:
Note that cont buffer is only a memory optimization. You could put
every text snippet into the ring buffer and console immediately.
You need to set LOG_CONT instead
On Mon 2015-04-27 08:56:27, Josh Poimboeuf wrote:
Frame pointer based stack traces aren't always reliable. One big reason
is that most asm functions don't set up the frame pointer.
Fix that by enforcing that all asm functions honor CONFIG_FRAME_POINTER.
This is done with a new stackvalidate
On Mon 2015-04-27 17:09:22, Tejun Heo wrote:
Hello, Petr.
Sorry about the delay.
np
On Mon, Apr 20, 2015 at 05:43:07PM +0200, Petr Mladek wrote:
I was afraid that there might be a potential buffer overflow because
the user-provided dict need not be limited by '\0'. But LOG_DICT_META
-by: Petr Mladek pmla...@suse.cz
It is much easier than the previous approach and pretty
straightforward. If there are any bugs in the LOG_CONT flag usage,
it will make them more visible but they should get fixed anyway.
Best Regards,
Petr
Cc: Kay Sievers k...@vrfy.org
Cc: Petr Mladek pmla
and accounting for the buffer
size properly isn't that complicated.
This patch defines CONSOLE_EXT_LOG_MAX as 8192 and updates
devkmsg_read() so that it limits output accordingly.
Signed-off-by: Tejun Heo t...@kernel.org
Reviewed-by: Petr Mladek pmla...@suse.cz
It is more secure now.
Best
Reviewed-by: Petr Mladek pmla...@suse.cz
I like the split of the long function.
Best Regards,
Petr
Cc: Kay Sievers k...@vrfy.org
Cc: Petr Mladek pmla...@suse.cz
---
kernel/printk/printk.c | 146
+++--
1 file changed, 80 insertions(+), 66
...@linux.vnet.ibm.com
Reviewed-by: Petr Mladek pmla...@suse.cz
[wanglong: backport to 3.10 stable
- adjust context
]
Signed-off-by: Wang Long long.wangl...@huawei.com
Signed-off-by: Steven Rostedt rost...@goodmis.org
---
arch/x86/kernel/apic/hw_nmi.c | 86
+--
1
On Mon 2015-05-18 21:00:57, Minfei Huang wrote:
On 05/18/15 at 02:08pm, Petr Mladek wrote:
On Wed 2015-05-13 09:14:15, Josh Poimboeuf wrote:
On Tue, May 12, 2015 at 10:04:44PM +0800, Minfei Huang wrote:
@@ -883,7 +883,7 @@ int klp_register_patch(struct klp_patch *patch
On Wed 2015-05-13 09:14:15, Josh Poimboeuf wrote:
On Tue, May 12, 2015 at 10:04:44PM +0800, Minfei Huang wrote:
@@ -883,7 +883,7 @@ int klp_register_patch(struct klp_patch *patch)
}
EXPORT_SYMBOL_GPL(klp_register_patch);
-static void klp_module_notify_coming(struct klp_patch *patch,
Kosina jkos...@suse.cz
Acked-by: Jiri Kosina jkos...@suse.cz
Acked-by: Paul E. McKenney paul...@linux.vnet.ibm.com
Reviewed-by: Petr Mladek pmla...@suse.cz
[wanglong: backport to 3.10 stable
- adjust context
]
Signed-off-by: Wang Long long.wangl...@huawei.com
Signed-off-by: Steven Rostedt
On Mon 2015-05-18 10:22:21, Josh Poimboeuf wrote:
On Mon, May 18, 2015 at 02:08:06PM +0200, Petr Mladek wrote:
On Wed 2015-05-13 09:14:15, Josh Poimboeuf wrote:
On Tue, May 12, 2015 at 10:04:44PM +0800, Minfei Huang wrote:
@@ -930,6 +932,7 @@ disabled:
static int klp_module_notify
On Tue 2015-04-14 23:55:36, Minfei Huang wrote:
On 04/14/15 at 10:11P, Josh Poimboeuf wrote:
On Tue, Apr 14, 2015 at 01:45:49PM +0800, Minfei Huang wrote:
On 04/14/15 at 12:32P, Josh Poimboeuf wrote:
On Tue, Apr 14, 2015 at 01:29:50PM +0800, Minfei Huang wrote:
For end user,
On Sun 2015-04-12 21:15:54, Minfei Huang wrote:
For now, the kallsyms will only store the first (KSYM_NAME_LEN-1). The
kallsyms name is same for the function which first (KSYM_NAME_LEN-1) is
same, but the rest is not.
Then function will never be patched, although function name and address
On Sun 2015-04-12 21:15:53, Minfei Huang wrote:
In order to restrict the patch, we can verify the provided function
address and name match. Now we have can only verify the vmlinux function
name and address.
Add a new function to verify extra module function name and address. The
patch would
On Mon 2015-04-13 17:50:23, Minfei Huang wrote:
On 04/13/15 at 11:41P, Petr Mladek wrote:
On Mon 2015-04-13 17:11:19, Minfei Huang wrote:
On 04/13/15 at 10:37P, Petr Mladek wrote:
On Sun 2015-04-12 21:15:53, Minfei Huang wrote:
In order to restrict the patch, we can verify
On Mon 2015-04-13 17:11:19, Minfei Huang wrote:
On 04/13/15 at 10:37P, Petr Mladek wrote:
On Sun 2015-04-12 21:15:53, Minfei Huang wrote:
In order to restrict the patch, we can verify the provided function
address and name match. Now we have can only verify the vmlinux function
name
On Wed 2015-04-15 01:01:39, Minfei Huang wrote:
On 04/14/15 at 06:27pm, Petr Mladek wrote:
On Tue 2015-04-14 23:55:36, Minfei Huang wrote:
On 04/14/15 at 10:11P, Josh Poimboeuf wrote:
On Tue, Apr 14, 2015 at 01:45:49PM +0800, Minfei Huang wrote:
On 04/14/15 at 12:32P, Josh Poimboeuf
On Tue 2015-05-19 09:08:45, Wang Long wrote:
This is my backport patch series to Fix the problem(backport to 3.10):
When trigger_all_cpu_backtrace() is called on x86, it will trigger an
NMI on each CPU and call show_regs(). But this can lead to a hard lock
up if the NMI comes in on another
On Wed 2015-05-20 12:59:48, Marcin Niesluchowski wrote:
Reading message with dict may cause user buffer overflow due to
no limits of written dict and hardcoded user read buffer size.
As limits of dict are not clear, it may be possible in extreme
use case to trigger it (e.g. by driver passing
On Tue 2015-05-19 14:57:46, Petr Mladek wrote:
On Tue 2015-05-19 09:08:45, Wang Long wrote:
This is my backport patch series to Fix the problem(backport to 3.10):
When trigger_all_cpu_backtrace() is called on x86, it will trigger an
NMI on each CPU and call show_regs(). But this can lead
On Mon 2015-06-01 08:50:24, Joe Perches wrote:
On Mon, 2015-06-01 at 16:25 +0200, Petr Mladek wrote:
I always have troubles to parse checkpatch.pl output when I check
the whole patchset. It is hard to say which messages belongs to
what patch.
This patch does few small changes to make
On Mon 2015-06-01 11:02:42, Joe Perches wrote:
On Mon, 2015-06-01 at 16:25 +0200, Petr Mladek wrote:
I always have troubles to parse checkpatch.pl output when I check
the whole patchset. It is hard to say which messages belongs to
what patch.
This patch does few small changes to make
On Fri 2015-06-05 18:10:21, Peter Zijlstra wrote:
On Fri, Jun 05, 2015 at 05:01:08PM +0200, Petr Mladek wrote:
Many kthreads go into an interruptible sleep when there is nothing
to do. They should check if anyone did not requested the kthread
to terminate, freeze, or park in the meantime
On Sat 2015-06-06 23:58:16, Oleg Nesterov wrote:
On 06/05, Petr Mladek wrote:
The main question is how much it should follow POSIX and the signal
handling of user space processes. On one hand, we want to be as close
as possible.
Why? Let the kthread decide what it should if it gets
On Mon 2015-06-08 13:39:55, Peter Zijlstra wrote:
On Mon, 2015-06-08 at 12:01 +0200, Petr Mladek wrote:
Just to be sure. Do you suggest to use TASK_IDLE everywhere in
kthreads or only when the uninterruptible sleep is really needed?
Always, only use INTERRUPTIBLE when you're actually
On Tue 2015-06-09 16:20:03, Tejun Heo wrote:
Hello, Petr.
On Fri, Jun 05, 2015 at 05:01:06PM +0200, Petr Mladek wrote:
Many kthreads already calls set_freezable() before they enter the main
cycle. One of the reasons for creating iterant kthreads is to create
a safe point for freezing
On Wed 2015-06-10 14:55:09, Peter Zijlstra wrote:
Hi,
I just stumbled upon:
a9edc8809328 (x86/nmi: Perform a safe NMI stack trace on all CPUs)
Which is not dissimilar to what I've proposed in the past. Except its
squirreled away in some far and dark corner of one arch.
Lets fix
On Wed 2015-06-10 16:31:55, Petr Mladek wrote:
On Wed 2015-06-10 14:55:09, Peter Zijlstra wrote:
Hi,
I just stumbled upon:
a9edc8809328 (x86/nmi: Perform a safe NMI stack trace on all CPUs)
Which is not dissimilar to what I've proposed in the past. Except its
squirreled
/patch a bit easier to parse.
Move the perl version and false positive messages after
all the files have been scanned so that they are emitted
only once.
Standardize the NOTE: ... form to always emit a blank
line before the NOTE and always use print EOM style.
Suggested-by: Petr Mladek pmla
1 - 100 of 5062 matches
Mail list logo
