Re: [PATCH v5] printk: Userspace format enumeration support

2021-04-19 Thread Petr Mladek
On Mon 2021-04-19 09:27:43, Rasmus Villemoes wrote: > On 16/04/2021 15.56, Chris Down wrote: > > Hey Petr, Rasmus, > > >> This is great point! There are many other subsystem specific wrappers, > >> e,g, ata_dev_printk(), netdev_printk(), snd_printk(), dprintk(). > >> We should make it easy to

Re: [PATCH v4 05/13] module: Add printk formats to add module build ID to stacktraces

2021-04-15 Thread Petr Mladek
On Tue 2021-04-13 15:57:49, Stephen Boyd wrote: > Quoting Petr Mladek (2021-04-13 08:01:14) > > On Fri 2021-04-09 18:52:52, Stephen Boyd wrote: > > > Let's make kernel stacktraces easier to identify by including the build > > > ID[1] of a module if the stacktrace is prin

Re: How to handle concurrent access to /dev/ttyprintk ?

2021-04-14 Thread Petr Mladek
On Tue 2021-04-13 17:22:46, Samo Pogačnik wrote: > Dne 13.04.2021 (tor) ob 16:32 +0200 je Petr Mladek napisal(a): > > On Tue 2021-04-13 13:10:50, Samo Pogačnik wrote: > > > Dne 13.04.2021 (tor) ob 11:41 +0200 je Petr Mladek napisal(a): > > > > On Mon 2021-04-12

Re: [PATCH v4 05/13] module: Add printk formats to add module build ID to stacktraces

2021-04-13 Thread Petr Mladek
On Tue 2021-04-13 13:56:31, Andy Shevchenko wrote: > On Mon, Apr 12, 2021 at 12:29:05PM -0700, Stephen Boyd wrote: > > Quoting Andy Shevchenko (2021-04-12 04:58:02) > > > On Fri, Apr 09, 2021 at 06:52:52PM -0700, Stephen Boyd wrote: > > > > Let's make kernel stacktraces easier to identify by

Re: [PATCH v4 05/13] module: Add printk formats to add module build ID to stacktraces

2021-04-13 Thread Petr Mladek
On Fri 2021-04-09 18:52:52, Stephen Boyd wrote: > Let's make kernel stacktraces easier to identify by including the build > ID[1] of a module if the stacktrace is printing a symbol from a module. > This makes it simpler for developers to locate a kernel module's full > debuginfo for a particular

Re: [PATCH v4 04/13] dump_stack: Add vmlinux build ID to stack traces

2021-04-13 Thread Petr Mladek
c229de205662d5a9e0d4c580f19a1 is the build ID, > following the kernel version number. Put it all behind a config option, > STACKTRACE_BUILD_ID, so that kernel developers can remove this > information if they decide it is too much. > > Cc: Jiri Olsa > Cc: Alexei Starovoitov >

Re: [PATCH v4 01/13] buildid: Only consider GNU notes for build ID parsing

2021-04-13 Thread Petr Mladek
Data size Description > Xen0x0008 Unknown note type: (0x0003) description data: 00 00 > 00 ff80 > > Let's make sure that it is a GNU note when parsing the build ID so that > we can use this function to parse a vmlinux's build ID

Re: How to handle concurrent access to /dev/ttyprintk ?

2021-04-13 Thread Petr Mladek
On Tue 2021-04-13 13:10:50, Samo Pogačnik wrote: > Dne 13.04.2021 (tor) ob 11:41 +0200 je Petr Mladek napisal(a): > > On Mon 2021-04-12 14:41:27, Samo Pogačnik wrote: > > > Dne 12.04.2021 (pon) ob 19:39 +0900 je Tetsuo Handa napisal(a): > > > > What is the in

Re: How to handle concurrent access to /dev/ttyprintk ?

2021-04-13 Thread Petr Mladek
On Mon 2021-04-12 14:41:27, Samo Pogačnik wrote: > Dne 12.04.2021 (pon) ob 19:39 +0900 je Tetsuo Handa napisal(a): > > What is the intended usage of /dev/ttyprintk ? > > > > The intended use of 'ttyprintk' is to redirect console to /dev/ttyprintk > via the TIOCCONS ioctl. After successfull

Re: [PATCH] iommu/amd: Fix extended features logging

2021-04-12 Thread Petr Mladek
On Sun 2021-04-11 14:08:14, Joe Perches wrote: > On Sun, 2021-04-11 at 21:52 +0200, John Ogness wrote: > > I'd rather fix dev_info callers to allow pr_cont and then fix any code > > that is using this workaround. > > Assuming you mean all dev_() uses, me too. > > > And if the print maintainers

Re: [PATCH] iommu/amd: Fix extended features logging

2021-04-12 Thread Petr Mladek
On Sun 2021-04-11 21:52:59, John Ogness wrote: > On 2021-04-11, Alexander Monakov wrote: > >>> The second line is emitted via 'pr_cont', which causes it to have a > >>> different ('warn') loglevel compared to the previous line ('info'). > >>> > >>> Commit 9a295ff0ffc9 attempted to rectify this

Re: [PATCH v3 03/12] dump_stack: Add vmlinux build ID to stack traces

2021-04-09 Thread Petr Mladek
On Thu 2021-04-08 12:52:27, Stephen Boyd wrote: > Quoting Petr Mladek (2021-04-08 03:13:20) > > It helped with the vmlinux buildid. I see the following: > > > > [ 551.435942][ T1803] test_printf: loaded. > > [ 551.436667][ T1803] [ cut here ]---

Re: [PATCH v3 03/12] dump_stack: Add vmlinux build ID to stack traces

2021-04-08 Thread Petr Mladek
On Wed 2021-04-07 23:20:32, Stephen Boyd wrote: > Quoting Petr Mladek (2021-04-07 07:03:19) > > # readelf -Wn vmlinux-5.12.0-rc6-default+ > > > > Displaying notes found in: .notes > > Owner Data size Description > > Xen

Re: [PATCH v3 12/12] kdump: Use vmlinux_build_id to simplify

2021-04-07 Thread Petr Mladek
On Tue 2021-03-30 20:05:20, Stephen Boyd wrote: > We can use the vmlinux_build_id array here now instead of open coding > it. This mostly consolidates code. > > Cc: Jiri Olsa > Cc: Alexei Starovoitov > Cc: Jessica Yu > Cc: Evan Green > Cc: Hsin-Yi Wang > Cc: Dave Young > Cc: Baoquan He >

Re: [PATCH v3 04/12] module: Add printk format to add module build ID to stacktraces

2021-04-07 Thread Petr Mladek
On Tue 2021-03-30 20:05:12, Stephen Boyd wrote: > Let's make kernel stacktraces easier to identify by including the build > ID[1] of a module if the stacktrace is printing a symbol from a module. > This makes it simpler for developers to locate a kernel module's full > debuginfo for a particular

Re: [PATCH v3 04/12] module: Add printk format to add module build ID to stacktraces

2021-04-07 Thread Petr Mladek
On Tue 2021-03-30 20:05:12, Stephen Boyd wrote: > Let's make kernel stacktraces easier to identify by including the build > ID[1] of a module if the stacktrace is printing a symbol from a module. > This makes it simpler for developers to locate a kernel module's full > debuginfo for a particular

Re: [PATCH v3 03/12] dump_stack: Add vmlinux build ID to stack traces

2021-04-07 Thread Petr Mladek
On Tue 2021-03-30 20:05:11, Stephen Boyd wrote: > Add the running kernel's build ID[1] to the stacktrace information > header. This makes it simpler for developers to locate the vmlinux with > full debuginfo for a particular kernel stacktrace. Combined with > scripts/decode_stracktrace.sh, a

Re: [PATCH v3 03/12] dump_stack: Add vmlinux build ID to stack traces

2021-04-07 Thread Petr Mladek
On Tue 2021-03-30 20:05:11, Stephen Boyd wrote: > Add the running kernel's build ID[1] to the stacktrace information > header. This makes it simpler for developers to locate the vmlinux with > full debuginfo for a particular kernel stacktrace. Combined with > scripts/decode_stracktrace.sh, a

Re: [PATCH] printk: clarify the documentation for plain pointer printing

2021-04-07 Thread Petr Mladek
On Thu 2021-02-25 17:46:39, Vlastimil Babka wrote: > We have several modifiers for plain pointers (%p, %px and %pK) and now also > the no_hash_pointers boot parameter. The documentation should help to choose > which variant to use. Importantly, we should discourage %px in favour of %p > (with the

Re: [PATCH V2 0/4] kernel/watchdog: Modify the explanation and doc related to watchdog thread

2021-04-07 Thread Petr Mladek
hdog: Modify the explanation related to watchdog thread > doc: watchdog: Delete the explanation about "watchdog/%u". > doc: watchdog: Modify the explanation related to watchdog thread > doc: watchdog: Modify the doc related to "watchdog/%u" All four patches make sense to me: Reviewed-by: Petr Mladek Best Regards, Petr

Re: [PATCH] tty: use printk_safe context at tty_msg()

2021-04-07 Thread Petr Mladek
On Tue 2021-04-06 21:10:48, Greg Kroah-Hartman wrote: > On Wed, Apr 07, 2021 at 01:22:34AM +0900, Tetsuo Handa wrote: > > On 2021/04/07 0:10, Petr Mladek wrote: > > >> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c > > >> index

Re: [PATCH] tty: use printk_safe context at tty_msg()

2021-04-06 Thread Petr Mladek
On Sat 2021-04-03 13:14:44, Tetsuo Handa wrote: > syzbot is reporting circular locking dependency due to calling printk() > with port lock held [1]. When this problem was reported, we worried Could you please include the lockdep report into the commit message? External links are not guaranteed to

Re: [PATCH printk v2 2/5] printk: remove safe buffers

2021-04-06 Thread Petr Mladek
On Fri 2021-04-02 11:14:18, Sergey Senozhatsky wrote: > On (21/04/01 16:17), Petr Mladek wrote: > > > For the long term, we should introduce a printk-context API that allows > > > callers to perfectly pack their multi-line output into a single > > > entry. We discus

Re: [PATCH printk v2 3/5] printk: remove NMI tracking

2021-04-01 Thread Petr Mladek
s another great win! Reviewed-by: Petr Mladek Best Regards, Petr

Re: [PATCH printk v2 2/5] printk: remove safe buffers

2021-04-01 Thread Petr Mladek
On Tue 2021-03-30 17:35:09, John Ogness wrote: > With @logbuf_lock removed, the high level printk functions for > storing messages are lockless. Messages can be stored from any > context, so there is no need for the NMI and safe buffers anymore. > Remove the NMI and safe buffers. > > Although the

Re: [PATCH printk v2 2/5] printk: remove safe buffers

2021-04-01 Thread Petr Mladek
On Thu 2021-04-01 15:19:52, John Ogness wrote: > On 2021-04-01, Petr Mladek wrote: > >> --- a/kernel/printk/printk.c > >> +++ b/kernel/printk/printk.c > >> @@ -1142,24 +1128,37 @@ void __init setup_log_buf(int early) > >> new_descs, ilog2(new_d

Re: [PATCH printk v2 4/5] printk: convert @syslog_lock to mutex

2021-04-01 Thread Petr Mladek
On Tue 2021-03-30 17:35:11, John Ogness wrote: > @syslog_lock was a raw_spin_lock to simplify the transition of > removing @logbuf_lock and the safe buffers. With that transition > complete, and since all uses of @syslog_lock are within sleepable > contexts, @syslog_lock can become a mutex. It

Re: [PATCH printk v2 1/5] printk: track/limit recursion

2021-04-01 Thread Petr Mladek
explicit recursion protection. Recursion is limited to 3 levels > per-CPU and per-context. > > Signed-off-by: John Ogness Reviewed-by: Petr Mladek Best Regards, Petr

Re: [PATCH 2/3] tracing: Use pr_crit() instead of long fancy messages

2021-04-01 Thread Petr Mladek
On Wed 2021-03-31 09:40:07, Steven Rostedt wrote: > On Wed, 31 Mar 2021 11:31:03 +0200 > Geert Uytterhoeven wrote: > > > This reduces kernel size by ca. 0.5 KiB. > > If you are worried about size, disable tracing and it will go away > entirely. 0.5KiB is a drop in the bucket compared to what

Re: [PATCH] printk: rename vprintk_func to vprintk

2021-03-30 Thread Petr Mladek
On Tue 2021-03-30 14:59:31, John Ogness wrote: > On 2021-03-30, Petr Mladek wrote: > > On Tue 2021-03-23 15:42:01, Rasmus Villemoes wrote: > >> The printk code is already hard enough to understand. Remove an > >> unnecessary indirection by renaming vpri

Re: [PATCH] kernel/printk.c: Fixed mundane typos

2021-03-30 Thread Petr Mladek
On Tue 2021-03-30 14:53:52, John Ogness wrote: > On 2021-03-30, Petr Mladek wrote: > > On Sun 2021-03-28 10:09:32, Bhaskar Chowdhury wrote: > >> > >> s/sempahore/semaphore/ > >> s/exacly/exactly/ > >> s/unregistred/unregistered/ > >&g

Re: [PATCH] kernel/printk.c: Fixed mundane typos

2021-03-30 Thread Petr Mladek
On Sun 2021-03-28 10:09:32, Bhaskar Chowdhury wrote: > > s/sempahore/semaphore/ > s/exacly/exactly/ > s/unregistred/unregistered/ > s/interation/iteration/ > > > Signed-off-by: Bhaskar Chowdhury Reviewed-by: Petr Mladek John, it conflicts with the patchset removi

Re: [PATCH] printk: rename vprintk_func to vprintk

2021-03-30 Thread Petr Mladek
3a: 8d b6 00 00 00 00 lea0x0(%esi),%esi > > Signed-off-by: Rasmus Villemoes Nice clean up! Reviewed-by: Petr Mladek John, it conflicts with the patchset removing printk safe buffers[1]. Would you prefer to queue this into the patchset? Or should I push it into printk/linux.git, printk-rework and you would base v2 on top of it? Best Regards, Petr

Re: [PATCH v2 00/12] Add build ID to stacktraces

2021-03-30 Thread Petr Mladek
On Thu 2021-03-25 16:21:46, Stephen Boyd wrote: > Quoting peter enderborg (2021-03-25 04:06:17) > > On 3/24/21 9:55 AM, Christoph Hellwig wrote: > > > On Tue, Mar 23, 2021 at 07:04:31PM -0700, Stephen Boyd wrote: > > >> x5 : x4 : 0001 > > >> x3 : 0008 x2

Re: [PATCH v2 04/12] module: Add printk format to add module build ID to stacktraces

2021-03-30 Thread Petr Mladek
On Wed 2021-03-24 15:28:43, Stephen Boyd wrote: > Quoting Rasmus Villemoes (2021-03-24 15:21:34) > > On 24/03/2021 20.11, Stephen Boyd wrote: > > > Quoting Rasmus Villemoes (2021-03-24 02:57:13) > > > > >> > > >> Is there any reason you didn't just make b an optional flag that could > > >> be

Re: [PATCH v2 04/12] module: Add printk format to add module build ID to stacktraces

2021-03-30 Thread Petr Mladek
On Tue 2021-03-23 19:04:35, Stephen Boyd wrote: > Let's make kernel stacktraces easier to identify by including the build > ID[1] of a module if the stacktrace is printing a symbol from a module. > > Example: > > WARNING: CPU: 3 PID: 3373 at drivers/misc/lkdtm/bugs.c:83 >

Re: [PATCH v2] x86/apic/vector: Move pr_warn() out of vector_lock

2021-03-30 Thread Petr Mladek
On Sun 2021-03-28 20:52:36, Waiman Long wrote: > It was found that the following circular locking dependency warning > could happen in some systems: > > [ 218.097878] == > [ 218.097879] WARNING: possible circular locking dependency detected >

Re: [PATCH] Modify the explanation and documentation related to watchdog thread

2021-03-29 Thread Petr Mladek
U-kthreads.rst | 20 > > kernel/watchdog.c| 12 It would be nice to update also Documentation/admin-guide/sysctl/kernel.rst Documentation/admin-guide/lockup-watchdogs.rst Anyway, the changes in this patch looks good. Fe

Re: [PATCH] livepatch: Replace the fake signal sending with TIF_NOTIFY_SIGNAL infrastructure

2021-03-29 Thread Petr Mladek
clear_thread_flag(TIF_SIGPENDING); > > } The original commit 43347d56c8d9dd732cee2 ("livepatch: send a fake signal to all blocking tasks") did also: --- a/kernel/signal.c +++ b/kernel/signal.c @@ -40,6 +40,7 @@ #include #include #include +#include #define CREATE_TRACE_POINTS #include We could/should remove the include now. Otherwise, it looks good to me. Well, I do not feel to be expert in this are. Anyway, feel free to add: Reviewed-by: Petr Mladek Best Regards, Petr

Re: [PATCH V3] workqueue/watchdog: Make unbound workqueues aware of

2021-03-29 Thread Petr Mladek
gt; > V3: > - Modify the commit message clearly according to Petr's suggestion. > > Signed-off-by: Wang Qing The patch fixes a real problem: Reviewed-by: Petr Mladek Best Regards, Petr

Re: [PATCH next v1 2/3] printk: remove safe buffers

2021-03-29 Thread Petr Mladek
On Fri 2021-03-26 12:12:37, John Ogness wrote: > On 2021-03-23, Petr Mladek wrote: > >> --- a/kernel/printk/printk.c > >> +++ b/kernel/printk/printk.c > >> - > >>if (seq != prb_next_seq(_rb_static)) { > >>pr_err("dropped

Re: Re: Re: [PATCH V2] workqueue: watchdog: update wq_watchdog_touched for unbound lockup checking

2021-03-24 Thread Petr Mladek
On Wed 2021-03-24 10:16:46, 王擎 wrote: > > >On Tue 2021-03-23 20:37:35, 王擎 wrote: > >> > >> >On Fri 2021-03-19 16:00:36, Wang Qing wrote: > >> >> When touch_softlockup_watchdog() is called, only > >> >> wq_watchdog_touched_cpu > >> >> updated, while the unbound worker_pool running on its core

Re: [PATCH next v1 1/3] printk: track/limit recursion

2021-03-24 Thread Petr Mladek
On Tue 2021-03-23 22:32:00, John Ogness wrote: > On 2021-03-22, Petr Mladek wrote: > > On Wed 2021-03-17 00:33:24, John Ogness wrote: > >> Track printk() recursion and limit it to 3 levels per-CPU and per-context. > > > >> diff --git a/kernel/printk/printk.c b/

Re: Re: [PATCH V2] workqueue: watchdog: update wq_watchdog_touched for unbound lockup checking

2021-03-23 Thread Petr Mladek
On Tue 2021-03-23 20:37:35, 王擎 wrote: > > >On Fri 2021-03-19 16:00:36, Wang Qing wrote: > >> When touch_softlockup_watchdog() is called, only wq_watchdog_touched_cpu > >> updated, while the unbound worker_pool running on its core uses > >> wq_watchdog_touched to determine whether locked up.

Re: [PATCH next v1 3/3] printk: convert @syslog_lock to spin_lock

2021-03-23 Thread Petr Mladek
On Wed 2021-03-17 00:33:26, John Ogness wrote: > @syslog_log was a raw_spin_lock to simplify the transition of s/syslog_log/syslog_lock/ Same problem is also below. > removing @logbuf_lock and the safe buffers. With that transition > complete, @syslog_log can become a spin_lock. I know that we

Re: [PATCH next v1 2/3] printk: remove safe buffers

2021-03-23 Thread Petr Mladek
On Wed 2021-03-17 00:33:25, John Ogness wrote: > With @logbuf_lock removed, the high level printk functions for > storing messages are lockless. Messages can be stored from any > context, so there is no need for the NMI and safe buffers anymore. > Remove the NMI and safe buffers. > > Although the

Re: [PATCH next v1 2/3] printk: remove safe buffers

2021-03-23 Thread Petr Mladek
On Mon 2021-03-22 22:58:47, John Ogness wrote: > On 2021-03-22, Petr Mladek wrote: > > On Mon 2021-03-22 12:16:15, John Ogness wrote: > >> On 2021-03-21, Sergey Senozhatsky wrote: > >> >> @@ -369,7 +70,10 @@ __printf(1, 0) int vprintk_func(const

Re: [PATCH next v1 2/3] printk: remove safe buffers

2021-03-22 Thread Petr Mladek
On Mon 2021-03-22 12:16:15, John Ogness wrote: > On 2021-03-21, Sergey Senozhatsky wrote: > >> @@ -369,7 +70,10 @@ __printf(1, 0) int vprintk_func(const char *fmt, > >> va_list args) > >> * Use the main logbuf even in NMI. But avoid calling console > >> * drivers that might have their

Re: [PATCH next v1 1/3] printk: track/limit recursion

2021-03-22 Thread Petr Mladek
On Mon 2021-03-22 20:13:51, Sergey Senozhatsky wrote: > On (21/03/22 11:53), John Ogness wrote: > > On 2021-03-21, Sergey Senozhatsky wrote: > > >> @@ -2055,6 +2122,9 @@ int vprintk_store(int facility, int level, > > >> */ > > >> ts_nsec = local_clock(); > > >> > > >> +

Re: [PATCH next v1 1/3] printk: track/limit recursion

2021-03-22 Thread Petr Mladek
On Wed 2021-03-17 00:33:24, John Ogness wrote: > Track printk() recursion and limit it to 3 levels per-CPU and per-context. Please, explain why it is added. I mean that it will allow remove printk_safe that provides recursion protection at the moment. > Signed-off-by: John Ogness > --- >

Re: [PATCH V2] workqueue: watchdog: update wq_watchdog_touched for unbound lockup checking

2021-03-22 Thread Petr Mladek
On Fri 2021-03-19 16:00:36, Wang Qing wrote: > When touch_softlockup_watchdog() is called, only wq_watchdog_touched_cpu > updated, while the unbound worker_pool running on its core uses > wq_watchdog_touched to determine whether locked up. This may be mischecked. By other words, unbound

Re: [PATCH v6 resend 0/3] mm, vsprintf: dump full information of page flags in pGp

2021-03-19 Thread Petr Mladek
On Fri 2021-03-19 18:12:43, Yafang Shao wrote: > The existed pGp shows the names of page flags only, rather than the full > information including section, node, zone, last cpuipid and kasan tag. > While it is not easy to parse these information manually because there > are so many flavors. We'd

Re: [PATCH v6 resend 3/3] vsprintf: dump full information of page flags in pGp

2021-03-19 Thread Petr Mladek
tf: all 388 tests passed > [68599.830367] test_printf: unloaded. > > [l...@intel.com: reported issues in the prev version in test_printf.c] > > Signed-off-by: Yafang Shao Reviewed-by: Petr Mladek It looks good. And it seems that the selftest should not longer have that problems on various architectures and configurations. I am going to push it. Best Regards, Petr

Re: [PATCH v6 resend 0/3] mm, vsprintf: dump full information of page flags in pGp

2021-03-19 Thread Petr Mladek
On Fri 2021-03-19 18:15:19, Yafang Shao wrote: > On Fri, Mar 19, 2021 at 6:13 PM Yafang Shao wrote: > Hi Petr, > > Any comments on this version ? I have been busy this week with some other work. I am going to review the original v6 either later today or the following week. Best Regards, Petr

Re: [PATCH v5] printk: Userspace format enumeration support

2021-03-19 Thread Petr Mladek
On Thu 2021-03-18 12:31:44, Rasmus Villemoes wrote: > On 18/03/2021 11.46, Petr Mladek wrote: > > > BTW: Is the trick with int (printk)(const char *s, ...) documented > > somewhere? Is it portable? > > It is completely standard and portable C, explicitly spelled out in

Re: [PATCH] MAINTAINERS: update Senozhatsky email address

2021-03-19 Thread Petr Mladek
RS b/MAINTAINERS > index b2baeb5e4a68..01b000cd5774 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -14433,7 +14433,7 @@ F:kernel/sched/psi.c > > PRINTK > M: Petr Mladek > -M: Sergey Senozhatsky > +M: Sergey Senozhatsky > R: Steven Rostedt > R:

Re: [PATCH 1/2] lib/vsprintf: do not show no_hash_pointers message multiple times

2021-03-19 Thread Petr Mladek
On Wed 2021-03-17 20:34:43, Marco Elver wrote: > On Mon, 8 Mar 2021 at 11:01, Petr Mladek wrote: > > On Fri 2021-03-05 20:42:05, Marco Elver wrote: > > > Do not show no_hash_pointers message multiple times if the option was > > > passed more than once (e.g.

Re: [PATCH v5] printk: Userspace format enumeration support

2021-03-18 Thread Petr Mladek
On Wed 2021-03-17 11:03:20, Rasmus Villemoes wrote: > On 17/03/2021 09.40, Petr Mladek wrote: > > On Tue 2021-03-16 14:28:12, Chris Down wrote: > >> Rasmus Villemoes writes: > >>> I think it's pointless renaming the symbol to _printk, with all the > >>> c

Re: [PATCH v5] printk: Userspace format enumeration support

2021-03-17 Thread Petr Mladek
On Tue 2021-03-16 14:28:12, Chris Down wrote: > Rasmus Villemoes writes: > > I think it's pointless renaming the symbol to _printk, with all the > > churn and reduced readability that involves (especially when reading > > assembly "why are we calling _printk and not printk here?"). There's > >

Re: c928e9b143: BUG:soft_lockup-CPU##stuck_for#s![perf:#]

2021-03-16 Thread Petr Mladek
On Mon 2021-03-15 22:04:41, kernel test robot wrote: > > > Greeting, > > FYI, we noticed the following commit (built with gcc-9): > > commit: c928e9b1439de4d74b942abd30d5c838a40af777 ("[PATCH v2 7/7] Test > softlockup") > url: > https://github.com/0d

Re: [PATCH v5] printk: Userspace format enumeration support

2021-03-16 Thread Petr Mladek
On Mon 2021-03-15 12:20:59, Chris Down wrote: > Petr Mladek writes: > > > I don't feel strongly that this is more clear though, so maybe you > > > mean something else? > > > > I was pretty tired when reviewing the patch. It was not easy for me > > to crea

Re: [PATCH v5] printk: Userspace format enumeration support

2021-03-15 Thread Petr Mladek
On Fri 2021-03-12 13:53:20, Chris Down wrote: > Ack to all unmentioned suggestions. :-) > > Petr Mladek writes: > > > + changed or no longer present. > > > + > > > + There is no additional runtime cost to printk with this enabled. > > > + >

Re: [PATCH v5] printk: Userspace format enumeration support

2021-03-12 Thread Petr Mladek
On Wed 2021-03-10 02:30:31, Chris Down wrote: > We have a number of systems industry-wide that have a subset of their > functionality that works as follows: > > 1. Receive a message from local kmsg, serial console, or netconsole; > 2. Apply a set of rules to classify the message; > 3. Do

[PATCH v2 2/7] watchdog: Explicitly update timestamp when reporting softlockup

2021-03-11 Thread Petr Mladek
, in printk_stack_address(). Make the behavior clear and predictable by explicitly updating the timestamp in watchdog_timer_fn() when the report gets printed. Signed-off-by: Petr Mladek --- kernel/watchdog.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/watchdog.c b/kernel/watchdog.c index

[PATCH v2 7/7] Test softlockup

2021-03-11 Thread Petr Mladek
Trigger busy loop by: $> cat /proc/version Stop the busy loop by: $> cat /proc/consoles The code also shows the first touch*watchdog() function that hides softlockup on a "well known" location. Signed-off-by: Petr Mladek --- fs/proc/consoles.c | 5 + fs/proc/version.c

[PATCH v2 4/7] watchdog/softlockup: Remove logic that tried to prevent repeated reports

2021-03-11 Thread Petr Mladek
ns that the watchdog timestamp gets updated after each report. Solution: Simply remove the logic. People want the periodic report anyway. Signed-off-by: Petr Mladek --- kernel/watchdog.c | 14 ++ 1 file changed, 2 insertions(+), 12 deletions(-) diff --git a/kernel/watchd

[PATCH v2 1/7] watchdog: Rename __touch_watchdog() to a better descriptive name

2021-03-11 Thread Petr Mladek
will help to distinguish which timestamp is being updated. Signed-off-by: Petr Mladek --- kernel/watchdog.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/kernel/watchdog.c b/kernel/watchdog.c index 71109065bd8e..c58244064de8 100644 --- a/kernel/watchdog.c +++ b

[PATCH v2 3/7] watchdog/softlockup: Report the overall time of softlockups

2021-03-11 Thread Petr Mladek
] For the better output, add an additional timestamp of the last report. Only this timestamp is reset when the watchdog is intentionally touched from slow code paths or when printing the report. Signed-off-by: Petr Mladek --- kernel/watchdog.c | 40 1 file

[PATCH v2 6/7] watchdog: Cleanup handling of false positives

2021-03-11 Thread Petr Mladek
allback. Signed-off-by: Petr Mladek --- kernel/watchdog.c | 20 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/kernel/watchdog.c b/kernel/watchdog.c index 6dc1f79e36aa..c050323fcd33 100644 --- a/kernel/watchdog.c +++ b/kernel/watchdog.c @@ -375,7 +3

[PATCH v2 5/7] watchdog: Fix barriers when printing backtraces from all CPUs

2021-03-11 Thread Petr Mladek
mixing two reports. Signed-off-by: Petr Mladek --- kernel/watchdog.c | 24 +++- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/kernel/watchdog.c b/kernel/watchdog.c index dc8a0bf943f5..6dc1f79e36aa 100644 --- a/kernel/watchdog.c +++ b/kernel/watchdog.c @@ -409,12

[PATCH v2 0/7] watchdog/softlockup: Report overall time and some cleanup

2021-03-11 Thread Petr Mladek
and I am pretty confident with the changes. [1] v2: https://lore.kernel.org/r/20201210160038.31441-1-pmla...@suse.com [2] v1: https://lore.kernel.org/r/20191024114928.15377-1-pmla...@suse.com Petr Mladek (7): watchdog: Rename __touch_watchdog() to a better descriptive name watchdog: Explicitly

Re: [PATCH v5] printk: Userspace format enumeration support

2021-03-11 Thread Petr Mladek
On Wed 2021-03-10 13:16:43, Greg Kroah-Hartman wrote: > On Wed, Mar 10, 2021 at 12:12:57PM +, Chris Down wrote: > > Greg Kroah-Hartman writes: > > > On Wed, Mar 10, 2021 at 02:30:31AM +, Chris Down wrote: > > > > + ps->file = debugfs_create_file(pi_get_module_name(mod), 0444, > > >

Re: [PATCH v5] printk: Userspace format enumeration support

2021-03-11 Thread Petr Mladek
On Wed 2021-03-10 12:17:51, Chris Down wrote: > Hey Petr, > > Chris Down writes: > >$ head -1 vmlinux; shuf -n 5 vmlinux > ># filename:line function "format" > ><5> block/blk-settings.c:661 disk_stack_limits "%s: Warning: Device %s > > is misaligned\n" > ><4>

Re: linux-next: Tree for Mar 10 (lib/test_printf.c)

2021-03-10 Thread Petr Mladek
On Tue 2021-03-09 21:57:48, Randy Dunlap wrote: > On 3/9/21 8:02 PM, Stephen Rothwell wrote: > > Hi all, > > > > on i386 (at least): > > ../lib/test_printf.c: In function 'page_flags_test': > ../lib/test_printf.c:595:17: error: 'sec' undeclared (first use in this > function); did you mean

Re: [PATCH 1/1] vsprintf: dump full information of page flags in pGp fix

2021-03-09 Thread Petr Mladek
On Tue 2021-02-23 13:51:24, Yafang Shao wrote: > The name of the flag should be printed using default_str_spec. > There's no difference in the output after this change because the string is > printed as-is with both default_dec_spec and default_flag_spec. > > This patch is a followup of the

Re: [PATCH v5 3/3] vsprintf: dump full information of page flags in pGp

2021-03-09 Thread Petr Mladek
On Wed 2021-03-03 16:43:25, Petr Mladek wrote: > On Mon 2021-02-22 13:39:56, Matthew Wilcox wrote: > > On Mon, Feb 22, 2021 at 01:38:17PM +0100, Petr Mladek wrote: > > > Another question where to push this change. It is pity the we > > > finalized it in the middle

Re: [PATCH 2/2] lib/vsprintf: reduce space taken by no_hash_pointers warning

2021-03-08 Thread Petr Mladek
On Mon 2021-03-08 13:22:40, Geert Uytterhoeven wrote: > Hi Petr, > > On Mon, Mar 8, 2021 at 11:16 AM Petr Mladek wrote: > > On Fri 2021-03-05 20:42:06, Marco Elver wrote: > > > Move the no_hash_pointers warning string into __initconst section, so > > > that i

Re: [PATCH next v4 00/15] printk: remove logbuf_lock

2021-03-08 Thread Petr Mladek
On Wed 2021-03-03 16:34:19, Petr Mladek wrote: > On Wed 2021-03-03 11:15:13, John Ogness wrote: > > Hello, > > > > Here is v4 of a series to remove @logbuf_lock, exposing the > > ringbuffer locklessly to both readers and writers. v3 is > > here [0]. > > Th

Re: [PATCH V2] docs: livepatch: Fix a typo and remove the unnecessary gaps in a sentence

2021-03-08 Thread Petr Mladek
y with v2 as is or a v3 if you want to > update s/shadow variables to only/shadow variables for only/ but knowing > me, I probably repeated the same phrasing elsewhere. Up to you, thanks. I could fix these when pushing unless anyone is against it. > Acked-by: Joe Lawrence Acked-by: Petr Mladek Best Regards, Petr

Re: [PATCH 2/2] lib/vsprintf: reduce space taken by no_hash_pointers warning

2021-03-08 Thread Petr Mladek
On Fri 2021-03-05 20:42:06, Marco Elver wrote: > Move the no_hash_pointers warning string into __initconst section, so > that it is discarded after init. Remove common start/end characters. > Also remove repeated lines from the array, since the compiler can't > remove duplicate strings for us

Re: [PATCH 1/2] lib/vsprintf: do not show no_hash_pointers message multiple times

2021-03-08 Thread Petr Mladek
On Fri 2021-03-05 20:42:05, Marco Elver wrote: > Do not show no_hash_pointers message multiple times if the option was > passed more than once (e.g. via generated command line). > > Signed-off-by: Marco Elver Reviewed-by: Petr Mladek Best Regards, Petr

Re: [PATCH] docs: livepatch: Fix a typo in the file shadow-vars.rst

2021-03-05 Thread Petr Mladek
p_shadow_get_or_alloc() call can be used to attach > shadow variables to parents already in-flight. It might make sense to move the "In" to the next line. It sticks out even more now. Eitherway: Reviewed-by: Petr Mladek Best Regards, Petr

Re: [PATCH v5 3/3] vsprintf: dump full information of page flags in pGp

2021-03-03 Thread Petr Mladek
On Mon 2021-02-22 13:39:56, Matthew Wilcox wrote: > On Mon, Feb 22, 2021 at 01:38:17PM +0100, Petr Mladek wrote: > > Another question where to push this change. It is pity the we > > finalized it in the middle of the merge window. It has to spend > > at least few days in l

Re: [PATCH next v4 00/15] printk: remove logbuf_lock

2021-03-03 Thread Petr Mladek
On Wed 2021-03-03 11:15:13, John Ogness wrote: > Hello, > > Here is v4 of a series to remove @logbuf_lock, exposing the > ringbuffer locklessly to both readers and writers. v3 is > here [0]. The series look ready. I am going to push it into printk/linux.git the following week unless anyone

Re: drm/ttm: ttm_bo_release called without lock

2021-03-03 Thread Petr Mladek
On Wed 2021-03-03 15:34:09, Petr Mladek wrote: > Hi, > > the following warning is filling my kernel log buffer > with 5.12-rc1+ kernels: > > [ 941.070598] WARNING: CPU: 0 PID: 11 at drivers/gpu/drm/ttm/ttm_bo.c:139 > ttm_bo_move_to_lru_tail+0x1ba/0x210 > [ 94

drm/ttm: ttm_bo_release called without lock

2021-03-03 Thread Petr Mladek
Hi, the following warning is filling my kernel log buffer with 5.12-rc1+ kernels: [ 941.070598] WARNING: CPU: 0 PID: 11 at drivers/gpu/drm/ttm/ttm_bo.c:139 ttm_bo_move_to_lru_tail+0x1ba/0x210 [ 941.070601] Modules linked in: [ 941.070603] CPU: 0 PID: 11 Comm: kworker/0:1 Kdump: loaded

Re: [PATCH next v4 12/15] printk: introduce a kmsg_dump iterator

2021-03-03 Thread Petr Mladek
oval of @logbuf_lock. > > Signed-off-by: John Ogness > Reviewed-by: Kees Cook # pstore Reviewed-by: Petr Mladek Best Regards, Petr

Re: [PATCH next v4 07/15] printk: introduce CONSOLE_LOG_MAX

2021-03-03 Thread Petr Mladek
y: John Ogness Reviewed-by: Petr Mladek Best Regards, Petr

lkml delivery: was: Re: [PATCH next v4 00/15] printk: remove logbuf_lock

2021-03-03 Thread Petr Mladek
Hi John, On Wed 2021-03-03 11:15:13, John Ogness wrote: > Hello, > > Here is v4 of a series to remove @logbuf_lock, exposing the > ringbuffer locklessly to both readers and writers. v3 is > here [0]. Have you got some reply from lkml that it has not delivered there, please? I am not able to

Re: [PATCH 5/7] printk: Make %pS and friends print module build ID

2021-03-03 Thread Petr Mladek
On Mon 2021-03-01 09:47:47, Stephen Boyd wrote: > The %pS printk format (among some others) is used to print kernel > addresses symbolically. When the kernel prints an address inside of a > module, the kernel prints the addresses' symbol name along with the > module's name that contains the

Re: [PATCH 3/3] [v4] lib/vsprintf: no_hash_pointers prints all addresses as unhashed

2021-03-02 Thread Petr Mladek
On Tue 2021-03-02 14:49:42, Geert Uytterhoeven wrote: > Hi Vlastimil, Petr, > > On Tue, Mar 2, 2021 at 2:37 PM Vlastimil Babka wrote: > > On 3/2/21 2:29 PM, Petr Mladek wrote: > > > On Tue 2021-03-02 13:51:35, Geert Uytterhoeven wrote: > > >> > > >

Re: [PATCH next v3 12/15] printk: introduce a kmsg_dump iterator

2021-03-02 Thread Petr Mladek
On Tue 2021-03-02 14:20:51, John Ogness wrote: > On 2021-03-01, Petr Mladek wrote: > >> diff --git a/arch/powerpc/kernel/nvram_64.c > >> b/arch/powerpc/kernel/nvram_64.c > >> index 532f22637783..5a64b24a91c2 100644 > >> --- a/arch/powerpc/kernel/nvram_64.c

Re: [PATCH 3/3] [v4] lib/vsprintf: no_hash_pointers prints all addresses as unhashed

2021-03-02 Thread Petr Mladek
On Tue 2021-03-02 13:51:35, Geert Uytterhoeven wrote: > Hi Marco, > > On Tue, Mar 2, 2021 at 1:45 PM Marco Elver wrote: > > On Tue, 2 Mar 2021 at 12:51, Geert Uytterhoeven > > wrote: > > > On Sun, Feb 14, 2021 at 5:17 PM Timur Tabi wrote: > > > > If the no_hash_pointers command line parameter

Re: [PATCH next v3 02/15] mtd: mtdoops: synchronize kmsg_dumper

2021-03-02 Thread Petr Mladek
On Tue 2021-03-02 11:45:27, John Ogness wrote: > On 2021-03-01, Petr Mladek wrote: > >> The kmsg_dumper can be called from any context and CPU, possibly > >> from multiple CPUs simultaneously. Since the writing of the buffer > >> can occur from a later scheduled wo

Re: [PATCH next v3 13/15] printk: remove logbuf_lock

2021-03-02 Thread Petr Mladek
d-off-by: John Ogness Reviewed-by: Petr Mladek Best Regards, Petr

Re: [PATCH next v3 01/15] um: synchronize kmsg_dumper

2021-03-02 Thread Petr Mladek
On Tue 2021-03-02 09:06:07, John Ogness wrote: > On 2021-03-01, Petr Mladek wrote: > >> > diff --git a/arch/um/kernel/kmsg_dump.c b/arch/um/kernel/kmsg_dump.c > >> > index 6516ef1f8274..4869e2cc787c 100644 > >> > --- a/arch/um/kernel/kmsg_dump.c

Re: [PATCH next v3 12/15] printk: introduce a kmsg_dump iterator

2021-03-01 Thread Petr Mladek
On Thu 2021-02-25 21:24:35, John Ogness wrote: > Rather than storing the iterator information in the registered > kmsg_dumper structure, create a separate iterator structure. The > kmsg_dump_iter structure can reside on the stack of the caller, thus > allowing lockless use of the kmsg_dump

Re: [PATCH next v3 11/15] printk: kmsg_dumper: remove @active field

2021-03-01 Thread Petr Mladek
- arch/powerpc/xmon/xmon.c > - kernel/debug/kdb/kdb_main.c Great summary! > Therefore, @active can be removed. > > Signed-off-by: John Ogness Reviewed-by: Petr Mladek Best Regards, Petr

Re: [PATCH next v3 10/15] printk: add syslog_lock

2021-03-01 Thread Petr Mladek
@syslog_lock for this > purpose. > > @syslog_lock is a raw_spin_lock for now. This simplifies the > transition to removing @logbuf_lock. Once @logbuf_lock and the > safe buffers are removed, @syslog_lock can change to spin_lock. > > Signed-off-by: John Ogness Reviewed-by: Petr Mladek Best Regards, Petr

Re: [PATCH next v3 01/15] um: synchronize kmsg_dumper

2021-03-01 Thread Petr Mladek
On Mon 2021-03-01 17:16:35, Petr Mladek wrote: > On Thu 2021-02-25 21:24:24, John Ogness wrote: > > The kmsg_dumper can be called from any context and CPU, possibly > > from multiple CPUs simultaneously. Since a static buffer is used > > to retrieve the kernel logs, this buf

  1   2   3   4   5   6   7   8   9   10   >