On Wed 2024-09-11 09:20:05, Josh Poimboeuf wrote:
> Hi Petr,
>
> Thank you for trying it out and doing the research to compare it with
> kpatch-build.
>
> On Wed, Sep 11, 2024 at 03:27:27PM +0200, Petr Mladek wrote:
> > Without -ffunction-sections -fdata-sections:
>
Hi Linus,
please pull the latest changes for the kernel livepatching from
git://git.kernel.org/pub/scm/linux/kernel/git/livepatching/livepatching.git
tags/livepatching-for-6.12
===
- Small documentation improvement.
---
On Mon 2024-09-02 20:59:43, Josh Poimboeuf wrote:
> Hi,
>
> Here's a new way to build livepatch modules called klp-build.
>
> I started working on it when I realized that objtool already does 99% of
> the work needed for detecting function changes.
>
> This is similar in concept to kpatch-build,
On Sun 2024-09-08 10:51:14, zhang warden wrote:
>
> Hi, Petr
> >
> > The 1st patch adds the pointer to struct klp_ops into struct
> > klp_func. We might check the state a similar way as klp_ftrace_handler().
> >
> > I had something like this in mind when I suggested to move the pointer:
> >
> >
On Fri 2024-09-06 17:39:46, zhang warden wrote:
> Hi, John & Miroslav
>
> >>
> >> Would it be possible to just use klp_transition_patch and implement the
> >> logic just in using_show()?
> >
> > Yes, containing the logic to the sysfs file sounds a lot better.
>
> Maybe I can try to use the sta
On Thu 2024-09-05 12:23:20, Miroslav Benes wrote:
> Hi,
>
> On Wed, 28 Aug 2024, Wardenjohn wrote:
>
> > One system may contains more than one livepatch module. We can see
> > which patch is enabled. If some patches applied to one system
> > modifing the same function, livepatch will use the func
Hi Linus,
please pull a regression fix in livepatching selftests from
git://git.kernel.org/pub/scm/linux/kernel/git/livepatching/livepatching
tags/livepatching-for-6.11-rc6
===
- Fix a regression in a livepatching selftest.
---
On Thu 2024-07-25 16:40:20, Nicolai Stange wrote:
> Miroslav Benes writes:
>
> >
> > Do we still need klp_state->data member? Now that it can be easily coupled
> > with shadow variables, is there a reason to preserve it?
Good point. I have actually forgot the pointer completely.
> I would say
On Thu 2024-07-25 13:48:06, Miroslav Benes wrote:
> Hi,
>
> On Fri, 10 Nov 2023, Petr Mladek wrote:
>
> > Recent changes in the livepatch core have allowed to connect states,
> > shadow variables, and callbacks. Use these new features in
> > the state tests.
> &
On Thu 2024-07-25 16:16:44, Miroslav Benes wrote:
> On Fri, 10 Nov 2023, Petr Mladek wrote:
>
> > The livepatch state API was added to help with maintaining:
> >
> >+ changes done by livepatch callbasks
> >+ lifetime of shadow variables
> >
> &
On Thu 2024-07-25 13:31:40, Miroslav Benes wrote:
> > diff --git a/kernel/livepatch/state.c b/kernel/livepatch/state.c
> > index 6693d808106b..4ec65afe3a43 100644
> > --- a/kernel/livepatch/state.c
> > +++ b/kernel/livepatch/state.c
> > @@ -198,11 +198,17 @@ void klp_release_states(struct klp_patch
On Thu 2024-07-25 16:19:30, Miroslav Benes wrote:
> On Fri, 10 Nov 2023, Josh Poimboeuf wrote:
>
> > On Fri, Nov 10, 2023 at 06:04:21PM +0100, Petr Mladek wrote:
> > > This POC is a material for the discussion "Simplify Livepatch Callbacks,
> > > Shadow Variable
On Wed 2024-08-14 22:23:21, zhang warden wrote:
>
>
> > On Aug 14, 2024, at 00:05, Petr Mladek wrote:
> >
> > Alternative solution would be to store the pointer of struct klp_ops
> > *ops into struct klp_func. Then using_show() could just check if
> > the
yms, such as livepatch, have to match
> symbols exactly.
>
> Address this by sorting full symbols at build time, and let kallsyms
> lookup APIs to match the symbols exactly.
The changes look good from the livepatching POV. For both patches,
feel free to use:
Acked-by: Petr Mladek
I
On Mon 2024-08-05 14:46:56, zhangyongde.zyd wrote:
> From: Wardenjohn
>
> One system may contains more than one livepatch module. We can see
> which patch is enabled. If some patches applied to one system
> modifing the same function, livepatch will use the function enabled
> on top of the functi
On Thu 2024-08-08 15:20:26, Song Liu wrote:
>
>
> > On Aug 8, 2024, at 2:59 AM, Petr Mladek wrote:
> >
> > On Wed 2024-08-07 20:48:48, Song Liu wrote:
> >>
> >>
> >>> On Aug 7, 2024, at 8:33 AM, Sami Tolvanen wrote:
> >>
On Fri 2024-08-02 14:08:34, Song Liu wrote:
> With CONFIG_LTO_CLANG=y, the compiler may add suffix to function names
> to avoid duplication. This causes confusion with users of kallsyms.
> On one hand, users like livepatch are required to match the symbols
> exactly. On the other hand, users like k
On Wed 2024-08-07 20:48:48, Song Liu wrote:
>
>
> > On Aug 7, 2024, at 8:33 AM, Sami Tolvanen wrote:
> >
> > Hi,
> >
> > On Wed, Aug 7, 2024 at 3:08 AM Masami Hiramatsu wrote:
> >>
> >> On Wed, 7 Aug 2024 00:19:20 +
> >> Song Liu wrote:
> >>
> >>> Do you mean we do not want patch 3/3,
On Wed 2024-08-07 19:46:31, Song Liu wrote:
>
>
> > On Aug 7, 2024, at 7:58 AM, zhang warden wrote:
> >
> >
> >> In my GCC built, we have suffixes like ".constprop.0", ".part.0",
> >> ".isra.0",
> >> and ".isra.0.cold".
> >
> > A fresher's eye, I met sometime when try to build a livepatch m
On Wed 2024-07-31 01:00:34, Song Liu wrote:
> Hi Masami,
>
> > On Jul 30, 2024, at 6:03 AM, Masami Hiramatsu wrote:
> >
> > On Mon, 29 Jul 2024 17:54:32 -0700
> > Song Liu wrote:
> >
> >> With CONFIG_LTO_CLANG=y, the compiler may add suffix to function names
> >> to avoid duplication. This ca
On Sat 2024-07-20 13:56:56, zhang warden wrote:
>
> > is this always correct though? See the logic in klp_ftrace_handler(). If
> > there is a transition running, it is a little bit more complicated.
> >
> > Miroslav
>
> Hi! Miroslav.
>
> In reality, we often encounter such situation that serva
sts.
Marcos Paulo de Souza (1):
selftests: livepatch: Test atomic replace against multiple modules
Petr Mladek (1):
Merge branch 'for-6.11/sysfs-patch-replace' into for-linus
Ryan Sullivan (1):
selfte
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:
> > >
'\(tainting\|taints\) kernel' | \
> - 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
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 implem
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 ke
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 pa
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 undefi
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 @@
[...]
> +/*
> + * Format
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 implem
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
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
dow variables 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/inc
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
mentation 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 objectiv
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 reprodu
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
JFY
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 a/include/
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 gic_mask_irq@_drivers_irqchip_irq-gic_c_
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 inde
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
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 includ
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 st
a23f7a1231c229de205662d5a9e0d4c580f19a1 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 Starovoi
t;
> Owner 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
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 redire
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 ag
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 by
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
> Cc
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 st
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 st
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 devel
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 devel
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 n
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 6d4995a5f318.
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 mak
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 tra
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 vprintk_func
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/
> >>
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
%esi,%eiz,1),%esi
> 33a: 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 spec
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
> lkdtm_WARNING+0x28/0x3
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
freezing(current))
> 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(&printk_rb_static)) {
> >>pr_err("drop
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 us
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. This
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
1 - 100 of 1217 matches
Mail list logo
