On Wed 2018-02-28 11:23:34, Petr Mladek wrote:
> On Sat 2018-02-24 13:34:05, kernel test robot wrote:
> > TO: Petr Mladek
> > CC: Cong Wang , Dave Hansen
> > , Johannes Weiner , Mel Gorman
> > , Michal Hocko , Vlastimil Babka
> > , Peter Zijlstra , Linus T
.
Petr Mladek (1):
printk: Wake klogd when passing console_lock owner
kernel/printk/printk.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
On Thu 2018-02-22 22:00:28, Miroslav Benes wrote:
> On Wed, 21 Feb 2018, Petr Mladek wrote:
> > This patch allows the late initialization.
> >
> > diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> > index ad508a86b2f9..da1438d47d83 100644
> > --- a/
On Thu 2018-03-29 09:01:02, syzbot wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> bcfc1f4554662d8f2429ac8bd96064a59c149754 (Sat Mar 24 16:50:12 2018 +)
> Merge tag 'pinctrl-v4.16-3' of
> git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
> syzbot dashbo
On Tue 2018-04-03 10:50:02, Petr Mladek wrote:
> On Thu 2018-03-29 09:01:02, syzbot wrote:
> > Hello,
> >
> > syzbot hit the following crash on upstream commit
> > bcfc1f4554662d8f2429ac8bd96064a59c149754 (Sat Mar 24 16:50:12 2018 +)
> > Merge tag 'pinctr
On Mon 2018-04-02 17:18:12, Andy Shevchenko wrote:
> On Sun, 2018-04-01 at 10:56 +0200, Richard Weinberger wrote:
> > Add a new format string to print in cowsay format.
> >
>
> Apparently NAK b/c missed test cases!
This is really sad. I'll miss the cows.
Moo,
Petr
On Tue 2018-04-03 11:13:33, Peter Zijlstra wrote:
> On Tue, Apr 03, 2018 at 10:50:03AM +0200, Petr Mladek wrote:
> > raw_spin_lock() succeeded here. Therefore lockdep was still working
> > at this stage.
>
> What does the success of raw_spin_lock() have to do with lockdep
On Mon 2018-04-02 17:15:23, Andy Shevchenko wrote:
> On Thu, 2018-03-29 at 16:53 +0200, Petr Mladek wrote:
> > On Fri 2018-03-16 20:19:35, Andy Shevchenko wrote:
> > > On Thu, 2018-03-15 at 16:26 +0100, Petr Mladek wrote:
> > > > On Thu 2018-03-15 15:09:03, Andy Sh
On Tue 2018-04-03 10:12:37, Sergey Senozhatsky wrote:
> On (04/02/18 17:15), Andy Shevchenko wrote:
> > >
> > > Hmm, I have never seen the error code in this form.
> >
> > We have limited space to print it and error numbers currently can be up
> > to 0xfff (4095). So, I have no better idea how to
On Tue 2018-04-03 14:54:18, Andy Shevchenko wrote:
> On Tue, 2018-04-03 at 13:46 +0200, Petr Mladek wrote:
> > On Mon 2018-04-02 17:15:23, Andy Shevchenko wrote:
> > > On Thu, 2018-03-29 at 16:53 +0200, Petr Mladek wrote:
> > > > On Fri 2018-03-16 20:19:35, Andy Shev
On Tue 2018-04-03 16:40:58, Andy Shevchenko wrote:
> On Tue, 2018-04-03 at 15:13 +0200, Petr Mladek wrote:
> > On Tue 2018-04-03 14:54:18, Andy Shevchenko wrote:
> > > On Tue, 2018-04-03 at 13:46 +0200, Petr Mladek wrote:
> > > > On Mon 2018-04-02 17:15:23, Andy She
recursive printk(). But it is safe
now because vscnprintf() is called in printk_safe context from
vprintk_emit().
Signed-off-by: Petr Mladek
---
lib/vsprintf.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index dd
This patch just moves ptr_to_id() implementation up in the source
file. We will want to call it earlier.
This patch does not change the existing behavior.
Signed-off-by: Petr Mladek
---
lib/vsprintf.c | 134 -
1 file changed, 67
ity reasons. In fact, the real
address can be seen only by %px or eventually %pK.
Signed-off-by: Petr Mladek
---
Documentation/core-api/printk-formats.rst | 7 ++
lib/test_printf.c | 37 ++--
lib/vsprintf.c| 137 ++-
more clear commit message
+ Documentation/core-api/printk-formats.rst update.
+ Add check into lib/test_printf.c.
Changes against v1:
+ Do not check access for plain %p.
+ More clear commit message.
Petr Mladek (9):
vsprintf: Shuffle ptr_to_id() code
vsprintf:
ned-off-by: Petr Mladek
Cc: Linus Torvalds
Cc: Tobin Harding
Cc: Kees Cook
---
lib/vsprintf.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index f20eaa3f0092..3551b7957d9e 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
going wrong. They expect the IP address and not a pointer anyway
in this situation.
Signed-off-by: Petr Mladek
---
lib/vsprintf.c | 54 --
1 file changed, 32 insertions(+), 22 deletions(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index
te error code description
"(einval)".
Signed-off-by: Petr Mladek
---
Documentation/core-api/printk-formats.rst | 1 +
lib/vsprintf.c| 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/core-api/printk-formats.rst
b/Documentatio
Move the code from the long pointer() function. We are going to add a check
for the access to the address that will make it even more complicated.
This patch does not change the existing behavior.
Signed-off-by: Petr Mladek
---
lib/vsprintf.c | 23 ++-
1 file changed, 14
variables.
This patch does not change the existing behavior.
Signed-off-by: Petr Mladek
---
lib/vsprintf.c | 79 --
1 file changed, 43 insertions(+), 36 deletions(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 9ade2c4f21ba
ng")
Cc: Linus Torvalds
Cc: Tobin Harding
Cc: Kees Cook
Signed-off-by: Petr Mladek
---
lib/vsprintf.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index c0c677c6a833..9ade2c4f21ba 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.
suspending consoles in KERN_INFO log level
Dave Young (2):
print kdump kernel loaded status in stack dump
printk: move dump stack related code to lib/dump_stack.c
Petr Mladek (1):
Merge branch 'for-4.17'
On Wed 2018-03-14 14:44:36, Josh Poimboeuf wrote:
> On Wed, Mar 14, 2018 at 03:27:02PM -0400, Joe Lawrence wrote:
> > On Tue, Mar 13, 2018 at 04:54:47PM +0100, Petr Mladek wrote:
> > > The existing API allows to pass a sample data to initialize the shadow
> > > data.
ctor/dtor
+ Misc update of comments and commit messages
+ Fix sizeof() in the sample code in shadow-vars.txt
Petr Mladek (2):
livepatch: Initialize shadow variables safely by a custom callback
livepatch: Allow to call a custom callback when freeing shadow
variables
Documentation
().
Signed-off-by: Petr Mladek
---
Documentation/livepatch/shadow-vars.txt | 10 +++---
include/linux/livepatch.h | 5 +++--
kernel/livepatch/shadow.c | 26 ++
samples/livepatch/livepatch-shadow-fix1.c | 25
n one hand, this adds a risk of ABBA
deadlocks. On the other hand, it allows to do some operations safely.
For example, we could add the new structure into an existing list.
This must be done only once when the structure is allocated.
Reported-by: Nicolai Stange
Signed-off-by: Petr Mladek
---
On Thu 2018-04-05 08:35:11, Sergey Senozhatsky wrote:
> On (04/04/18 10:58), Petr Mladek wrote:
> > static noinline_for_stack
> > +char *kobject_string(char *buf, char *end, void *ptr,
> > +struct printf_spec spec, const char *fmt)
> > +{
> > +
On Thu 2018-04-05 08:58:16, Sergey Senozhatsky wrote:
> On (04/04/18 10:58), Petr Mladek wrote:
> >
> > Also it is better to warn about unknown specifier instead of falling
> > back to the %p behavior. It will help people to understand what is
> > going wrong. They expe
On Thu 2018-04-05 08:10:14, Sergey Senozhatsky wrote:
> On (04/04/18 10:58), Petr Mladek wrote:
> >
> > restricted_pointer() pretends that it prints the address when kptr_restrict
> > is set to zero. But it is never called in this situation. Instead,
> > pointer() fa
On Thu 2018-04-05 16:04:45, Andy Shevchenko wrote:
> On Wed, 2018-04-04 at 10:58 +0200, Petr Mladek wrote:
> > restricted_pointer() pretends that it prints the address when
> > kptr_restrict
> > is set to zero. But it is never called in this situation. Instead,
> &
On Fri 2018-03-16 20:19:35, Andy Shevchenko wrote:
> On Thu, 2018-03-15 at 16:26 +0100, Petr Mladek wrote:
> > On Thu 2018-03-15 15:09:03, Andy Shevchenko wrote:
> > > On Wed, 2018-03-14 at 15:09 +0100, Petr Mladek wrote:
> > > > We already prevent crash when deref
On Fri 2018-03-02 16:17:34, Andy Shevchenko wrote:
> On Fri, 2018-03-02 at 13:53 +0100, Petr Mladek wrote:
> > %p has many modifiers where the pointer is dereferenced. An invalid
> > pointer might cause kernel to crash silently.
> >
> > Note that printk() formats the st
On Thu 2018-04-26 10:28:05, Sergey Senozhatsky wrote:
> On (04/25/18 13:12), Petr Mladek wrote:
> [..]
> > /*
> >* This is not a fool-proof test. 99% of the time that this will fault is
> >* due to a bad pointer, not one that crosses into bad memory. Just te
On Wed 2018-04-25 18:10:54, Andy Shevchenko wrote:
> On Wed, 2018-04-25 at 13:12 +0200, Petr Mladek wrote:
> > We already prevent crash when dereferencing some obviously broken
> > pointers. But the handling is not consistent. Sometimes we print
> > "(null)"
On Wed 2018-04-25 13:12:40, Petr Mladek wrote:
> Crash in vsprintf() might be silent when it happens under logbuf_lock
> in vprintk_emit(). This patch set prevents most of the crashes by probing
> the address. The check is done only by %s and some %p* specifiers that need
> to der
On Wed 2018-05-23 11:01:07, Sergey Senozhatsky wrote:
> On (05/22/18 17:43), Steven Rostedt wrote:
> > > CPU0 CPU1CPU2
> > >
> > > printk()
> > > vprintk_emit()
> > > spin_lock(&logbuf_lock)
> > >
> > > trigg
: bcm2835: Stop using printk format %pCr
serial: sh-sci: Stop using printk format %pCr
lib/vsprintf: Remove atomic-unsafe support for %pCr
Petr Mladek (2):
Merge branch 'for-4.18-vsprintf-cleanup' into for-4.18
Merge branch 'for-4.18-vsprintf-pcr-removal' i
On Thu 2018-05-17 16:39:03, Petr Mladek wrote:
> The commit 719f6a7040f1bdaf96fcc ("printk: Use the main logbuf in NMI when
> logbuf_lock is available") tried to detect when logbuf_lock was taken
> on another CPU. Then it looked safe to wait for the lock even in NMI.
>
>
On Mon 2018-06-04 17:33:42, Steven Rostedt wrote:
> On Thu, 31 May 2018 14:16:33 +0200
> Petr Mladek wrote:
>
> > > enum log_flags {
> > > - LOG_NOCONS = 1,/* already flushed, do not print to console */
> > > - LOG_NEWLINE = 2,/* text ended
On Thu 2018-05-31 08:12:23, Joe Perches wrote:
> On Thu, 2018-05-31 at 14:16 +0200, Petr Mladek wrote:
> > On Thu 2018-05-31 15:47:51, Maninder Singh wrote:
> > > This patch removes unused flag LOG_NOCONS for printk.
> > > usage of this flag is removed long back with
On Wed 2018-06-06 14:10:29, Sergey Senozhatsky wrote:
> On (06/05/18 14:47), Petr Mladek wrote:
> [..]
> > Grr, the ABBA deadlock is still there. NMIs are not sent to the other
> > CPUs atomically. Even if we detect that logbuf_lock is available
> > in printk_nmi_enter(
On Thu 2018-06-07 14:10:19, Sergey Senozhatsky wrote:
> Cc-ing more people
> Link: lkml.kernel.org/r/87008b056df8f...@google.com
>
> On (06/06/18 06:17), syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:af6c5d5e01ad Merge branch 'for-4.18'
On Mon 2018-06-04 13:37:08, Thierry Escande wrote:
> If the test_printf module is loaded before the crng is initialized, the
> plain 'p' tests will fail because the printed address will not be hashed
> and the buffer will contain '(ptrval)' instead.
> This patch adds a call to wait_for_random_bytes
vsprintf() must not change any data that parameters point to.
Let's add the missing const qualifier to ptr_to_id().
This patch does not change the existing behavior.
Signed-off-by: Petr Mladek
---
lib/vsprintf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
te error code description
"(einval)".
Signed-off-by: Petr Mladek
---
Documentation/core-api/printk-formats.rst | 1 +
lib/vsprintf.c| 3 +--
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/core-api/printk-formats.rst
b/Documentatio
variables.
This patch does not change the existing behavior.
Signed-off-by: Petr Mladek
---
lib/vsprintf.c | 83 --
1 file changed, 46 insertions(+), 37 deletions(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 2678dfe61d73
ity reasons. In fact, the real
address can be seen only by %px or eventually %pK.
Signed-off-by: Petr Mladek
---
Documentation/core-api/printk-formats.rst | 7 ++
lib/test_printf.c | 37 +++--
lib/vsprintf.c| 128 +++
the string.
+ Even more clear commit message
+ Documentation/core-api/printk-formats.rst update.
+ Add check into lib/test_printf.c.
Changes against v1:
+ Do not check access for plain %p.
+ More clear commit message.
Petr Mladek (11):
vsprintf: Shuffle misc
own format specifier
into the original string with a question mark, for example (%pC?).
It should be self-explaining enough. Note that it is in brackets
to follow the (null) style.
Signed-off-by: Petr Mladek
---
lib/vsprintf.c | 26 ++
1 file changed, 14 insertions(+), 12
log.
Signed-off-by: Petr Mladek
---
Documentation/core-api/printk-formats.rst | 3 +++
lib/test_printf.c | 7 +++
lib/vsprintf.c| 9 -
3 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/Documentation/core-api/printk-formats.
ned-off-by: Petr Mladek
Cc: Linus Torvalds
Cc: Tobin Harding
Cc: Kees Cook
---
lib/vsprintf.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index e58436ef9f7f..3536796c483c 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
going wrong. They expect the IP address and not a pointer anyway
in this situation.
Signed-off-by: Petr Mladek
---
lib/vsprintf.c | 57 ++---
1 file changed, 34 insertions(+), 23 deletions(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index
Move the code from the long pointer() function. We are going to add a check
for the access to the address that will make it even more complicated.
This patch does not change the existing behavior.
Signed-off-by: Petr Mladek
---
lib/vsprintf.c | 22 +-
1 file changed, 13
uot;)
Cc: Linus Torvalds
Cc: Tobin Harding
Cc: Kees Cook
Signed-off-by: Petr Mladek
---
lib/vsprintf.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index eef9f725e9ff..2678dfe61d73 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprint
This is just a preparation step for further changes.
The patch does not change the code.
Signed-off-by: Petr Mladek
---
lib/vsprintf.c | 244 -
1 file changed, 122 insertions(+), 122 deletions(-)
diff --git a/lib/vsprintf.c b/lib
On Fri 2018-04-20 10:52:21, Sergey Senozhatsky wrote:
> On (04/19/18 12:02), Petr Mladek wrote:
> > On Thu 2018-04-19 10:42:50, Sergey Senozhatsky wrote:
> > > We wake up klogd very late - only when current console_sem owner
> > > is done pushing pending kernel messages
On Tue 2018-04-24 10:51:04, Steven Rostedt wrote:
> On Tue, 24 Apr 2018 11:28:02 +0900
> Sergey Senozhatsky wrote:
>
> > Calling console drivers from printk_safe() context does not really
> > make call_console_drivers() any safer, because printk_safe() has
> > nothing to do with console drivers o
On Wed 2018-04-25 14:31:46, Sergey Senozhatsky wrote:
> On (04/23/18 14:45), Petr Mladek wrote:
> [..]
> > I am not sure how slow are the slowest consoles. If I take that
> > everything should be faster than 1200 bauds. Then 10 minutes
> > should be enough for 1000 lines an
On Tue 2018-04-24 10:33:36, Sergey Senozhatsky wrote:
> Yes, Tetsuo, we use a bunch of "printk prefix" extensions at Samsung.
> For instance, we prefix printk messages with the CPU number: messages
> sometimes mix up, we also see partial pr_cont flushes, and so on.
> Grep-ping serial logs by CPU nu
On Thu 2019-02-28 11:53:15, Geert Uytterhoeven wrote:
> Support for "%pCr" was removed, but a reference in a comment was
> forgotten.
>
> Fixes: 666902e42fd8344b ("lib/vsprintf: Remove atomic-unsafe support for
> %pCr")
> Signed-off-by: Geert Uytterhoeven
I have commited it into printk.git, bra
On Fri 2019-03-01 12:11:31, Feng Tang wrote:
> Hi Andrew,
>
> Thanks for the review!
>
> On Thu, Feb 28, 2019 at 12:00:14PM -0800, Andrew Morton wrote:
> > On Fri, 22 Feb 2019 14:09:59 +0800 Feng Tang wrote:
> >
> > > When kernel panic happens, it will first print the panic call stack,
> > > th
will confuse some users, as I have seen many bug
> reporters posted the noisy message into bugzilla, instead of the real panic
> call stack and context.
>
> Adding a flag "suppress_printk" which gets set in panic() to avoid those
> noisy messages, without changing curre
On Fri 2019-03-01 19:31:59, Tetsuo Handa wrote:
> Can this patch go to Linux 5.1?
I am going to look at it the following week. I do not think that
it is necessary to hurry a clean up of old stuff up into 5.1.
I believe that it is correct. But it is not a typo fix. For example,
I want to double ch
ocuments. Is it by intention?
I am happy even for the conversion, so:
Reviewed-by: Petr Mladek
Best Regards,
Petr
> > > new printk msg only with console_flush_on_panic().
> > >
> > > Add an option for users to configure the "panic_print" to see
> > > all dmesg in buffer, some of which they may have never seen due
> > > to the loglevel setting, which will help de
Move the non-trivial code from the long pointer() function. We are going
to improve error handling that will make it even more complicated.
This patch does not change the existing behavior.
Signed-off-by: Petr Mladek
---
lib/vsprintf.c | 52
This is just a preparation step for further changes.
The patch does not change the code.
Signed-off-by: Petr Mladek
Reviewed-by: Andy Shevchenko
---
lib/vsprintf.c | 98 +-
1 file changed, 49 insertions(+), 49 deletions(-)
diff --git a
Move code from the long pointer() function. We are going to improve
error handling that will make it even more complicated.
This patch does not change the existing behavior.
Signed-off-by: Petr Mladek
Cc: Linus Torvalds
Cc: Tobin Harding
Cc: Kees Cook
---
lib/vsprintf.c | 17
variables.
This patch does not change the existing behavior.
Signed-off-by: Petr Mladek
Reviewed-by: Andy Shevchenko
---
lib/vsprintf.c | 81 +++---
1 file changed, 44 insertions(+), 37 deletions(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
+ More clear commit message.
Petr Mladek (10):
vsprintf: Shuffle restricted_pointer()
vsprintf: Consistent %pK handling for kptr_restrict == 0
vsprintf: Do not check address of well-known strings
vsprintf: Factor out %p[iI] handler as ip_addr_string()
vsprintf: Factor out %pV handler a
ity reasons. In fact, the real
address can be seen only by %px or eventually %pK.
Signed-off-by: Petr Mladek
---
Documentation/core-api/printk-formats.rst | 7 ++
lib/test_printf.c | 22 -
lib/vsprintf.c| 136 ++-
Move the code from the long pointer() function. We are going to improve
error handling that will make it more complicated.
This patch does not change the existing behavior.
Signed-off-by: Petr Mladek
---
lib/vsprintf.c | 21 -
1 file changed, 12 insertions(+), 9 deletions
te error code description
"(einval)".
Signed-off-by: Petr Mladek
---
Documentation/core-api/printk-formats.rst | 1 +
lib/vsprintf.c| 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/core-api/printk-formats.rst
b/Documentatio
that it is in brackets
to follow the (null) style.
Note that it introduces a warning about that test_hashed() function
is unused. It is going to be used again by a later patch.
Signed-off-by: Petr Mladek
---
lib/test_printf.c | 3 +--
lib/vsprintf.c| 28 +---
2 files
: Petr Mladek
---
lib/vsprintf.c | 39 +++
1 file changed, 27 insertions(+), 12 deletions(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 4e5666035b74..1f367f3a7e2b 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -612,6 +612,21 @@ static char
uot;)
Cc: Linus Torvalds
Cc: Tobin Harding
Cc: Kees Cook
Signed-off-by: Petr Mladek
Reviewed-by: Andy Shevchenko
---
lib/vsprintf.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index eb7b4a06e1f0..2af48948a973 100644
--- a/lib/vsp
On Wed 2019-04-17 19:50:10, Sergey Senozhatsky wrote:
> On (04/17/19 18:46), Sergey Senozhatsky wrote:
> >
> > Does not look too complex/ugly.
>
> Looks simpler than adding one more global state to the
> console_unlock() printing loop.
>
> // Not tested at all //
>
> diff --git a/kernel/panic.c
On Thu 2019-04-18 09:00:14, Sergey Senozhatsky wrote:
> I think that PANIC_PRINT_ALL_PRINTK_MSG is a debugging option; a quite
> specific one. So people who ask the kernel to PANIC_PRINT_ALL_PRINTK_MSG
> they know what they are doing, and we probably will not cofuse anyone.
> After all, we don't pr
On Thu 2019-04-18 17:00:44, Feng Tang wrote:
> Hi Petr,
>
> On Thu, Apr 18, 2019 at 09:45:52AM +0200, Petr Mladek wrote:
> > On Thu 2019-04-18 09:00:14, Sergey Senozhatsky wrote:
> > > I think that PANIC_PRINT_ALL_PRINTK_MSG is a debugging option; a quite
> > > sp
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 transition.
Suggested-by: Josh Poimboeuf
Signed-off-by: Petr Mladek
---
kernel/livepatch/core.c | 5 ++---
1 fi
I ended with three patches in the end. The first one is the same
as before [1]. Then I added two patches for handling of the stacktrace
error messages.
[1] https://lkml.kernel.org/r/20190418112936.13295-1-pmla...@suse.com
Petr Mladek (3):
livepatch: Convert error about unsupported reliable
WARN_ONCE() in the generic save_stack_trace_tsk_reliable() is superfluous.
The only current user klp_check_stack() writes its own warning when
-ENOSYS is returned.
Signed-off-by: Petr Mladek
---
kernel/stacktrace.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/stacktrace.c b/kernel
debug messages could be static.
Signed-off-by: Petr Mladek
---
kernel/livepatch/transition.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/kernel/livepatch/transition.c b/kernel/livepatch/transition.c
index 9c89ae8b337a..e8183d18227f 100644
--- a/kernel
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 transition.
Suggested-by: Josh Poimboeuf
Signed-off-by: Petr Mladek
---
kernel/livepatch/core.c | 5 ++---
1 fi
On Wed 2019-04-24 10:55:49, Petr Mladek wrote:
> WARN_ONCE() in the generic save_stack_trace_tsk_reliable() is superfluous.
> The only current user klp_check_stack() writes its own warning when
> -ENOSYS is returned.
Suggested-by: Josh Poimboeuf
> Signed-off-by: Petr Mladek
Best Regards,
Petr
On Wed 2019-04-24 12:41:00, Jiri Kosina wrote:
> On Wed, 24 Apr 2019, 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 pri
On Fri 2019-04-19 10:51:12, Sergey Senozhatsky wrote:
> On (04/17/19 13:53), Petr Mladek wrote:
> > Crash in vsprintf() might be silent when it happens under logbuf_lock
> > in vprintk_emit(). This patch set prevents most of the crashes by probing
> > the address. The check i
* sure we print everything out, before we unregister them.
>*/
I wondered if moving the console locking could break the above
statement.
It seems that the comment has been invalid since the commit
8259cf4342029aad37660e ("printk: Ensure tha
On Tue 2019-04-23 15:25:11, Sergey Senozhatsky wrote:
> We need to take console_sem lock when we iterate console
> drivers list. Otherwise, another CPU can concurrently
> modify console drivers list or console drivers.
>
> Signed-off-by: Sergey Senozhatsky
> ---
> kernel/printk/printk.c | 19 +++
On Thu 2019-04-25 12:52:33, Sergey Senozhatsky wrote:
> On (04/24/19 16:49), Petr Mladek wrote:
> > > + if (bcon && (newcon->flags & (CON_CONSDEV|CON_BOOT)) == CON_CONSDEV) {
> > > + console_lock();
> > > + /*
> > > + *
On Thu 2019-04-25 14:19:44, Sergey Senozhatsky wrote:
> On (04/24/19 17:13), Petr Mladek wrote:
> > > /*
> > >* before we register a new CON_BOOT console, make sure we don't
> > > @@ -2691,6 +2696,7 @@ void register_console(struct console *newcon)
> &
On Thu 2019-04-25 15:43:21, Sergey Senozhatsky wrote:
> On (04/25/19 12:52), Sergey Senozhatsky wrote:
> > > Could we remove it in this patch? It touches it indirectly anyway.
> >
> > Sure we can.
> >
> > We also can take extra care of pr_info("%sconsole [%s%d] enabled\n".
> > Right now we do
> >
On Wed 2019-04-24 16:51:12, Feng Tang wrote:
> Currently on panic, kernel will lower the loglevel and print out
> pending printk msg only with console_flush_on_panic().
>
> Add an option for users to configure the "panic_print" to replay
> all dmesg in buffer, some of which they may have never see
On Thu 2019-04-25 23:30:49, Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
> e43bb4d0feb8 ("vsprintf: Consistent %pK handling for kptr_restrict == 0")
>
> Fixes tag
>
> Fixes: commit ef0010a30935de4e0211 ("vsprintf: don't use
> 'restricted_pointer()' when not restricting")
>
> has thes
ve missed it yesterday.
Anyway, with the above locking, feel free to add:
Reviewed-by: Petr Mladek
Best Regards,
Petr
ole_flush_on_panic();
> pr_emerg("---[ end Kernel panic - not syncing:")
>
> panic_print_sys_info();
> /* the rest */
> /* panic_timeout handling */
>
> Signed-off-by: Sergey Senozhatsky
Makes sense to me:
Reviewed-by: Petr Mladek
Best Regards,
Petr
On Mon 2019-03-11 21:49:05, Sergey Senozhatsky wrote:
> On (03/10/19 21:03), Ahmed S. Darwish wrote:
> > The 'registered' flag is internally used by kmsg_dump_register()
> > and kmsg_dump_unregister() to track multiple registrations of the
> > same dumper.
> >
> > It's protected by printk's intern
On Mon 2019-03-11 09:18:26, Sebastian Andrzej Siewior wrote:
> On 2019-03-11 11:46:00 [+0900], Sergey Senozhatsky wrote:
> > On (03/08/19 15:02), Sebastian Andrzej Siewior wrote:
> > > On 2019-02-12 15:30:03 [+0100], John Ogness wrote:
> > >
> > > you removed the whole `irq_work' thing. You can al
On Mon 2019-03-11 11:51:49, John Ogness wrote:
> On 2019-03-07, Sergey Senozhatsky wrote:
> > I don't really understand the role of loglevel anymore.
>
> "what the kernel considers" is a configuration option of the
> administrator. The administrator can increase the verbocity of the
> console (lo
On Mon 2019-03-11 19:54:11, Sergey Senozhatsky wrote:
> On (03/07/19 10:53), John Ogness wrote:
> > Since all current console drivers are already irq safe, I'm
> > wondering if using irq_work to handle the emergency printing for console
> > drivers without write_atomic() would help. (If the printk
601 - 700 of 3147 matches
Mail list logo
