On Wed 2024-07-03 08:30:33, Luis Chamberlain wrote:
> On Tue, Jul 02, 2024 at 10:56:41PM -0700, Josh Poimboeuf wrote:
> > On Mon, Jul 01, 2024 at 03:13:23PM +0200, Petr Mladek wrote:
> > > So, you suggest to search the symbols by a hash. Do I get it correctly?
>
> I meant
On Fri 2024-06-28 10:36:45, Luis Chamberlain wrote:
> On Fri, Jun 28, 2024 at 02:23:49PM +0200, Miroslav Benes wrote:
> > On Fri, 7 Jun 2024, Song Liu wrote:
> >
> > > Hi Miroslav,
> > >
> > > Thanks for reviewing the patch!
> > >
> > > On Fri, Jun 7, 2024 at 6:06 AM Miroslav Benes wrote:
> >
| \
> - sed 's/^\[[ 0-9.]*\] //')
> + sed 's/^\[[ 0-9.]*\] //' | sed 's/^test_klp_log: //')
The prefix "test_klp_log:" is not used anywhere. It seems that this
change is not needed in the final version.
>
> if [[ "$expect" == "$res
it is annotated with
> KLP_RELOC_SYMBOL macro.
>
> The livepatch sample updates the function cmdline_proc_show to print the
> string referenced by the symbol saved_command_line appended by the
> string "livepatch=1".
>
> Signed-off-by: Josh Poimboeuf
> Signed
On Thu 2024-05-16 15:30:05, Lukas Hruska wrote:
> Livepatches need to access external symbols which can't be handled
> by the normal relocation mechanism. It is needed for two types
> of symbols:
>
> + Symbols which can be local for the original livepatched function.
> The alternative
On Tue 2024-05-21 08:34:46, Miroslav Benes wrote:
> Hello,
>
> On Mon, 20 May 2024, zhang warden wrote:
>
> >
> >
> > > On May 20, 2024, at 14:46, Miroslav Benes wrote:
> > >
> > > Hi,
> > >
> > > On Mon, 20 May 2024, Wardenjohn wrote:
> > >
> > >> Livepatch module usually used to modify
Hi Linus,
please pull the latest changes for the kernel livepatching from
git://git.kernel.org/pub/scm/linux/kernel/git/livepatching/livepatching
tags/livepatching-for-6.10
==
- Use more informative names for the livepatch transition states.
On Tue 2024-05-07 13:01:11, zhangwar...@gmail.com wrote:
> From: Wardenjohn
>
> The original macros of KLP_* is about the state of the transition.
> Rename macros of KLP_* to KLP_TRANSITION_* to fix the confusing
> description of klp transition state.
>
> Signed-off-by: Wardenjohn
JFYI, the
rdenjohn
Looks good to me:
Reviewed-by: Petr Mladek
Tested-by: Petr Mladek
Best Regards,
Petr
On Mon 2024-05-06 10:04:26, zhang warden wrote:
>
>
> > On May 6, 2024, at 05:00, Josh Poimboeuf wrote:
> >
> > On Mon, Apr 29, 2024 at 03:26:28PM +0800, zhangwar...@gmail.com wrote:
> >> From: Wardenjohn
> >>
> >> livepatch.h use KLP_UNDEFINED\KLP_UNPATCHED\KLP_PATCHED for klp transition
>
On Tue 2024-04-02 09:52:31, Joe Lawrence wrote:
> On Tue, Apr 02, 2024 at 11:09:54AM +0800, zhangwar...@gmail.com wrote:
> > From: Wardenjohn
> >
> > In livepatch, using KLP_UNDEFINED is seems to be confused.
> > When kernel is ready, livepatch is ready too, which state is
> > idle but not
On Mon 2023-11-06 17:25:10, Lukas Hruska wrote:
> Livepatches need to access external symbols which can't be handled
> by the normal relocation mechanism. It is needed for two types
> of symbols:
>
> --- /dev/null
> +++ b/scripts/livepatch/klp-convert.c
> @@ -0,0 +1,283 @@
[...]
> +/*
> + *
On Mon 2023-11-06 17:25:13, Lukas Hruska wrote:
> Add a section to Documentation/livepatch/module-elf-format.rst
> describing how klp-convert works for fixing relocations.
>
> Signed-off-by: Lukas Hruska
Looks good to me:
Reviewed-by: Petr Mladek
Best Regards,
Petr
suggest to livepatch a symbol from another test module so that
it does not modify the running system and the result is predictable.
Otherwise it looks good. With a better module name:
Reviewed-by: Petr Mladek
Best Regards,
Petr
resolved by
klp-convert.
> Signed-off-by: Josh Poimboeuf
> Signed-off-by: Lukas Hruska
Otherwise the code looks good. With the updated commit message:
Reviewed-by: Petr Mladek
Best Regards,
Petr
On Mon 2023-11-06 17:25:10, Lukas Hruska wrote:
> Livepatches need to access external symbols which can't be handled
> by the normal relocation mechanism. It is needed for two types
> of symbols:
>
> + Symbols which can be local for the original livepatched function.
> The alternative
On Mon 2023-11-06 17:25:09, Lukas Hruska wrote:
> From: Josh Poimboeuf
>
> Define klp prefixes in include/uapi/linux/livepatch.h, and use them for
> replacing hard-coded values in kernel/livepatch/core.c.
>
> Signed-off-by: Josh Poimboeuf
> Signed-off-by: Lukas Hrusk
-off-by: Petr Mladek
---
include/linux/livepatch.h | 7 +-
kernel/livepatch/core.c | 17 ++-
kernel/livepatch/state.c | 27 +++--
kernel/livepatch/state.h | 1 +
lib/livepatch/test_klp_state.c
postponed until the approach has been approved
in the POC stage.
Signed-off-by: Petr Mladek
---
Documentation/livepatch/callbacks.rst | 133
Documentation/livepatch/index.rst | 1 -
include/linux/livepatch.h | 25 ---
kernel/livepatch/core.c
ils.
- Better organize the tests. test-module.sh combines
tests of various aspects which might better be suited
somewhere else.
As a first step, test-callbacks.sh has been renamed
to test-modules.sh. But there still might be a better name.
- Split this huge patch. Add the
ctionality
which might be used in more tests. It would allow to create tests
focusing on some particular feature with an easier output.
Signed-off-by: Petr Mladek
---
lib/livepatch/Makefile| 2 +
lib/livepatch/test_klp_speaker.c | 34 +
lib
per-state.
+ Remove callbacks needed to transfer the pointer between
states.
+ Keep the versioning of the state to prevent downgrade.
The problem is artificial because no callbacks are
needed to transfer or free the shadow variable anymore.
Signed-off-by: Petr Mladek
---
lib/livepa
ariables using
state->callbacks.shadow_dtor callback when provided.
Signed-off-by: Petr Mladek
---
include/linux/livepatch.h | 15 ++-
kernel/livepatch/state.c | 14 ++
2 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/include/linux/livepatch.h b/include/
rred.
The per-object callbacks were called after the barrier. They were
using and already existing for-cycle. And nobody did mind about
the ordering.
Signed-off-by: Petr Mladek
---
include/linux/livepatch.h | 28
kernel/livepatch/core.c
tion is not updated.
+ More selftest might be needed [**]
[*] There is some mystery in a selftest when the migration gets
blocked, see the comments in the 5th patch.
[**] In fact, many selftests would deserve some cleanup and
better split into categories.
Petr Mladek (
Hi Linus,
please pull a fix for livepatching from
git://git.kernel.org/pub/scm/linux/kernel/git/livepatching/livepatching
tags/livepatching-for-6.7
===
- Add missing newline character to avoid waiting for a continuous message.
On Mon 2023-10-09 15:14:28, Alessandro Carminati wrote:
> Hello Kris,
>
> Thank you for your contribution and for having your thought shared with me.
>
> Allow me to begin this conversation by explaining what came to mind when
> I decided to propose a patch that creates aliases.
>
> The
Adding live-patching list into Cc.
On Fri 2023-08-25 15:19:10, Leizhen (ThunderTown) wrote:
> On 2023/8/25 11:46, Yonghong Song wrote:
> > Kernel test robot reported a kallsyms_test failure when clang lto is
> > enabled (thin or full) and CONFIG_KALLSYMS_SELFTEST is also enabled.
> > I can
On Thu 2023-09-14 15:26:44, Zheng Yejian wrote:
> Without the newline character, the log may not be printed immediately
> after the error occurs.
>
> Fixes: ca376a937486 ("livepatch: Prevent module-specific KLP rela sections
> from referencing vmlinux symbols")
> Signed-off-by: Zheng Yejian
Signed-off-by: Zheng Yejian
Reviewed-by: Petr Mladek
Best Regards,
Petr
On Fri 2023-09-15 11:53:13, Greg KH wrote:
> On Fri, Sep 15, 2023 at 04:46:02PM +0800, Enlin Mu wrote:
> > John Ogness 于2023年9月15日周五 16:34写道：
> > >
> > > On 2023-09-15, Enlin Mu wrote:
> > > > Sometimes we want to print cpu id of printk() messages to consoles
> > > >
> > > > diff --git
On Tue 2023-09-12 16:18:00, Alessandro Carminati wrote:
> ha scritto:
> > From: Alessandro Carminati (Red Hat)
> > > sample from new v3
> > >
> > > ~ # cat /proc/kallsyms | grep gic_mask_irq
> > > d0b03c04dae4 t gic_mask_irq
> > > d0b03c04dae4 t
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
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
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
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
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
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
>
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
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
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
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
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
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 ]---
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
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
>
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
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
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
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
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
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
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
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
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
s another great win!
Reviewed-by: Petr Mladek
Best Regards,
Petr
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
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
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
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
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
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
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
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
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
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
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
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
>
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
>
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
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
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
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
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
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/
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.
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
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
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
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
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();
> > >>
> > >> +
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
> ---
>
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
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
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
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
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
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:
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.
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
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
> >
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
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
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.
> > > +
>
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
, 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
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
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
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
]
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
1 - 100 of 5072 matches
Mail list logo
