eads and user
> mode threads")
The change makes sense to me. Well, I could not test it easily.
Anyway, feel free to use:
Reviewed-by: Petr Mladek
Best Regards,
Petr
On Wed 2023-08-30 17:47:35, Joe Lawrence wrote:
> On 8/30/23 02:37, Michael Ellerman wrote:
> > Michael Ellerman writes:
> >> Joe Lawrence writes:
> >>> Hi ppc-dev list,
> >>>
> >>> We noticed that our kpatch integration tests started failing on ppc64le
> >>> when targeting the upstream v6.4
")
> Signed-off-by: Douglas Anderson
Thanks for the patch:
Reviewed-by: Petr Mladek
Best Regards,
Petr
; Closes: https://lore.kernel.org/r/871qi5otdh.fsf@mail.lhotse
> Signed-off-by: Douglas Anderson
Looks like a reasonable solution:
Reviewed-by: Petr Mladek
Thanks a lot for fixing the regression.
Best Regards,
Petr
On Fri 2023-06-16 09:48:06, Doug Anderson wrote:
> Hi,
>
> On Fri, Jun 16, 2023 at 8:07 AM Petr Mladek wrote:
> >
> > There are several hardlockup detector implementations and several Kconfig
> > values which allow selection and build of the pr
On Fri 2023-06-16 17:06:12, Petr Mladek wrote:
> Hi,
>
> this patchset is supposed to replace the last patch in the patchset cleaning
> up after introducing the buddy detector, see
> https://lore.kernel.org/r/20230526184139.10.I821fe7609e57608913fe05abd8f35b343e7a9aae@change
and HAVE_HARDLOCKUP_DETECTOR_PERF definitions for powerpc.
As a result HAVE_HARDLOCKUP_DETECTOR_PERF has the same dependencies
on arm, x86, powerpc architectures.
Signed-off-by: Petr Mladek
Reviewed-by: Douglas Anderson
---
arch/powerpc/Kconfig | 5 ++---
include/linux/nmi.h | 2 +-
lib
CTOR_BUDDY=y
CONFIG_HAVE_HARDLOCKUP_DETECTOR_SPARC64=y
CONFIG_HARDLOCKUP_DETECTOR_SPARC64=y
Signed-off-by: Petr Mladek
Reviewed-by: Douglas Anderson
---
arch/sparc/Kconfig.debug | 7 ++-
include/linux/nmi.h | 4 ++--
kernel/watchdog.c| 2 +-
lib/Kconfig.debug| 2 +-
4 f
CTOR
and it is not longer enabled when HAVE_NMI_WATCHDOG is set.
Signed-off-by: Petr Mladek
watchdog/sparc64: Rename HAVE_NMI_WATCHDOG to HAVE_HARDLOCKUP_WATCHDOG_SPARC64
The configuration variable HAVE_NMI_WATCHDOG has a generic name but
it is selected only for SPARC64.
It should _not_ be used
HAVE_NMI_WATCHDOG related
checks.
The change should not change the existing behavior.
Signed-off-by: Petr Mladek
Reviewed-by: Douglas Anderson
---
arch/powerpc/include/asm/nmi.h | 2 --
arch/sparc/include/asm/nmi.h | 1 -
include/linux/nmi.h| 13 ++---
3 files changed, 10
value is not preserved when the global switch is disabled.
The user has to make the decision again when it gets re-enabled.
Signed-off-by: Petr Mladek
---
arch/Kconfig | 23 +-
lib/Kconfig.debug | 62 +++
2 files changed, 53
behavior.
Signed-off-by: Petr Mladek
---
lib/Kconfig.debug | 112 +++---
1 file changed, 56 insertions(+), 56 deletions(-)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index ed7b01c4bd41..3e91fa33c7a0 100644
--- a/lib/Kconfig.debug
+++ b/lib
at it from
a bad side.
+ Removed superfluous "default n"
+ Fixed typos.
Petr Mladek (6):
watchdog/hardlockup: Sort hardlockup detector related config values a
logical way
watchdog/hardlockup: Make the config checks more straightforward
watchdog/hardlockup: Declare arc
On Thu 2023-06-08 06:55:23, Doug Anderson wrote:
> Hi,
>
> On Thu, Jun 8, 2023 at 4:02 AM Petr Mladek wrote:
> >
> > > > config HARDLOCKUP_DETECTOR
> > > > bool "Detect Hard Lockups"
> > > >
On Wed 2023-06-07 16:37:10, Doug Anderson wrote:
> Hi,
>
> On Wed, Jun 7, 2023 at 8:26 AM Petr Mladek wrote:
> >
> > @@ -1102,6 +1103,14 @@ config HARDLOCKUP_DETECTOR_BUDDY
> > depends on !HAVE_HARDLOCKUP_DETECTOR_ARCH
> > select HARDLOCKUP_DETECT
On Wed 2023-06-07 16:36:35, Doug Anderson wrote:
> Hi,
>
> On Wed, Jun 7, 2023 at 8:25 AM Petr Mladek wrote:
> >
> > diff --git a/arch/Kconfig b/arch/Kconfig
> > index 13c6e596cf9e..57f15babe188 100644
> > --- a/arch/Kconfig
> > +++ b/arch/
On Wed 2023-06-07 16:35:19, Doug Anderson wrote:
> Hi,
>
> On Wed, Jun 7, 2023 at 8:25 AM Petr Mladek wrote:
> >
> > arch_touch_nmi_watchdog() needs a different implementation for various
> > hardlockup detector implementations. And it does nothing when
> > any
On Wed 2023-06-07 16:35:09, Doug Anderson wrote:
> Hi,
>
> On Wed, Jun 7, 2023 at 8:25 AM Petr Mladek wrote:
> >
> > diff --git a/arch/Kconfig b/arch/Kconfig
> > index 422f0ffa269e..13c6e596cf9e 100644
> > --- a/arch/Kconfig
> > +++ b/arch/K
On Wed 2023-06-07 16:34:20, Doug Anderson wrote:
> Hi,
>
> On Wed, Jun 7, 2023 at 8:25 AM Petr Mladek wrote:
> > Only one hardlockup detector can be compiled in. The selection is done
> > using quite complex dependencies between several CONFIG variables.
> > The
and HAVE_HARDLOCKUP_DETECTOR_PERF definitions for powerpc.
As a result HAVE_HARDLOCKUP_DETECTOR_PERF has the same dependencies
on arm, x86, powerpc architectures.
Signed-off-by: Petr Mladek
---
arch/powerpc/Kconfig | 5 ++---
include/linux/nmi.h | 2 +-
lib/Kconfig.debug| 9 +
3 files
CTOR_BUDDY=y
CONFIG_HAVE_HARDLOCKUP_DETECTOR_SPARC64=y
CONFIG_HARDLOCKUP_DETECTOR_SPARC64=y
Signed-off-by: Petr Mladek
---
arch/sparc/Kconfig.debug | 10 +-
include/linux/nmi.h | 4 ++--
kernel/watchdog.c| 2 +-
lib/Kconfig.debug| 2 +-
4 files changed, 13 inse
arch/sparc/Kconfig.debug.
Signed-off-by: Petr Mladek
---
arch/Kconfig | 12
arch/sparc/Kconfig | 2 +-
arch/sparc/Kconfig.debug | 12
include/linux/nmi.h | 4 ++--
kernel/watchdog.c| 2 +-
lib/Kconfig.debug| 5 +
6 files changed, 17
ux/nmi.h.
Signed-off-by: Petr Mladek
---
arch/Kconfig| 7 +--
include/linux/nmi.h | 5 ++---
lib/Kconfig.debug | 16 +++-
3 files changed, 10 insertions(+), 18 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index 13c6e596cf9e..57f15babe188 100644
--- a/arch
CONFIG_HAVE_NMI_WATCHDOG is defined.
+ The change synchronizes the checks in lib/Kconfig.debug and
in the generic code.
+ It is a step that will help cleaning HAVE_NMI_WATCHDOG related
checks.
The change should not change the existing behavior.
Signed-off-by: Petr Mladek
value is not preserved when the global switch is disabled.
The user has to make the decision when it is enabled again.
Signed-off-by: Petr Mladek
---
arch/Kconfig | 22 -
lib/Kconfig.debug | 63 ---
2 files changed, 53 inserti
in the end.
5. HAVE_HARDLOCKUP_DETECTOR_NON_ARCH and HARDLOCKUP_DETECTOR_NON_ARCH
are temporary variables that are going to be removed in
a followup patch.
The patch just shuffles the definitions. It should not change the existing
behavior.
Signed-off-by: Petr Mladek
---
lib
checked the generated
.config after using sparc_defconfig, sparc64_defconfig, ppc64_defconfig,
and ppc40x_defconfig.
Best Regards,
Petr
Petr Mladek (7):
watchdog/hardlockup: Sort hardlockup detector related config values a
logical way
watchdog/hardlockup: Make the config checks more straigh
On Fri 2023-05-26 18:41:40, Douglas Anderson wrote:
> HAVE_HARDLOCKUP_DETECTOR_NON_ARCH is a mouthful and
> confusing. HAVE_HARDLOCKUP_DETECTOR_PERF_OR_BUDDY is even more of a
> mouthful, but probably less confusing. Rename the Kconfig names.
It is better. But I have an idea that might be even
mments about why they're needed.
>
> Suggested-by: Petr Mladek
> Signed-off-by: Douglas Anderson
Reviewed-by: Petr Mladek
Best Regards,
Petr
those two config items.
>
> Suggested-by: Petr Mladek
> Signed-off-by: Douglas Anderson
Reviewed-by: Petr Mladek
Best Regards,
Petr
On Fri 2023-05-26 18:41:37, Douglas Anderson wrote:
> There's no reason to make a copy of the "watchdog_cpus" locally in
> watchdog_next_cpu(). Making a copy wouldn't make things any more race
> free and we're just reading the value so there's no need for a copy.
>
>
ockup_check()") the count was changed to "atomic_t"
> which is backed by an int, so we should match types.
>
> Suggested-by: Petr Mladek
> Signed-off-by: Douglas Anderson
The change looks fine:
Reviewed-by: Petr Mladek
That said, I would prefer to squash it into the
ove it.
>
> Suggested-by: Petr Mladek
> Signed-off-by: Douglas Anderson
Reviewed-by: Petr Mladek
Best Regards,
Petr
cpumask_copy() than to just copy the structure directly. Fix this.
>
> Suggested-by: Petr Mladek
> Signed-off-by: Douglas Anderson
Reviewed-by: Petr Mladek
Best Regards,
Petr
On Fri 2023-05-26 18:41:33, Douglas Anderson wrote:
> In the patch ("watchdog/hardlockup: add a "cpu" param to
> watchdog_hardlockup_check()") there was no reason to use
> raw_cpu_ptr(). Using this_cpu_ptr() works fine.
>
> Suggested-by: Petr Mladek
> Sign
" watchdog_hardlockup_probe() and we'll
> fallback to looking at CONFIG_HAVE_NMI_WATCHDOG.
>
> Suggested-by: Petr Mladek
> Signed-off-by: Douglas Anderson
Looks good:
Reviewed-by: Petr Mladek
> ---
> Though this does fix a minor bug, I didn't mark this as "Fixes&quo
ually probed.
>
> Fixes: a994a3147e4c ("watchdog/hardlockup/perf: Implement init time detection
> of perf")
> Reported-by: Petr Mladek
> Closes: https://lore.kernel.org/r/ZHCn4hNxFpY5-9Ki@alley
> Signed-off-by: Douglas Anderson
Looks good to me:
Reviewed-by: Petr Mladek
Best Regards,
Petr
395 ("kallsyms: increase maximum kernel symbol length to 512")
> Co-developed-by: Onkarnath
> Signed-off-by: Onkarnath
> Signed-off-by: Maninder Singh
With the updated commit hash:
Reviewed-by: Petr Mladek
Best Regards,
Petr
On Mon 2023-05-29 16:50:45, Miguel Ojeda wrote:
> On Mon, May 29, 2023 at 1:08 PM Maninder Singh
> wrote:
> >
> > I Will add co-developed-by` tag.
> > because this change was identified while we were working on kallsyms some
> > time back.
> >
On Wed 2023-05-24 12:38:49, Doug Anderson wrote:
> Hi,
>
> On Wed, May 24, 2023 at 6:59 AM Petr Mladek wrote:
> >
> > On Fri 2023-05-19 10:18:37, Douglas Anderson wrote:
> > > The fact that there watchdog_hardlockup_enable(),
> > > watchdog_hardlockup_d
On Fri 2023-05-19 10:18:39, Douglas Anderson wrote:
> On arm64, NMI support needs to be detected at runtime. Add a weak
> function to the perf hardlockup detector so that an architecture can
> implement it to detect whether NMIs are available.
>
> Signed-off-by: Douglas Anderson
> ---
> While I
On Thu 2023-05-25 13:08:04, Doug Anderson wrote:
> Hi,
>
> On Thu, May 25, 2023 at 9:27 AM Petr Mladek wrote:
> >
> > On Fri 2023-05-19 10:18:38, Douglas Anderson wrote:
> > > Implement a hardlockup detector that doesn't doesn't need any extra
> > > arch-
On Fri 2023-05-19 10:18:38, Douglas Anderson wrote:
> Implement a hardlockup detector that doesn't doesn't need any extra
> arch-specific support code to detect lockups. Instead of using
> something arch-specific we will use the buddy system, where each CPU
> watches out for another one.
On Fri 2023-05-19 10:18:37, Douglas Anderson wrote:
> The fact that there watchdog_hardlockup_enable(),
> watchdog_hardlockup_disable(), and watchdog_hardlockup_probe() are
> declared __weak means that the configured hardlockup detector can
> define non-weak versions of those functions if it needs
ed' are variables that are only used as an
* 'interface' between the parameters in /proc/sys/kernel and the internal
* state bits in 'watchdog_enabled'. The 'watchdog_thresh' variable is
* handled differently because its value is not boolean, and the lockup
Reviewed-by: Petr Mladek
Even better might
silly. However, a future patch will change this.
>
> Signed-off-by: Douglas Anderson
Reviewed-by: Petr Mladek
Best Regards,
Petr
On Tue 2023-05-23 09:34:37, Doug Anderson wrote:
> Hi,
>
> On Tue, May 23, 2023 at 9:02 AM Petr Mladek wrote:
> >
> > On Fri 2023-05-19 10:18:34, Douglas Anderson wrote:
> > > In preparation for the buddy hardlockup detector where the CPU
> > > checkin
On Fri 2023-05-19 10:18:34, Douglas Anderson wrote:
> In preparation for the buddy hardlockup detector where the CPU
> checking for lockup might not be the currently running CPU, add a
> "cpu" parameter to watchdog_hardlockup_check().
>
> As part of this change, make hrtimer_interrupts an
ardlockup detector wasn't configured. We didn't need to
> do that, so move all the "hrtimer_interrupts" counting to only be
> there if the perf hardlockup detector is configured as well.
>
> This change is expected to be a no-op.
>
> Signed-off-by: Douglas Anderson
Reviewed-by: Petr Mladek
Best Regards,
Petr
ouching the hardlock detector implcitily pets the
> + * softlockup detector too
> + */
s/implcitily/implicitly/
That said, I would remove this comment completely. It describes what
is clear from the code.
A more useful information would be why it is done. But it is probably
clear as well. CPU could not schedule when interrupts are disabled.
> touch_softlockup_watchdog();
> }
With the removed comment above touch_softlockup_watchdog():
Reviewed-by: Petr Mladek
Best Regards,
Petr
t;buddy" hardlockup detector.
>
> Fixes: 7edaeb6841df ("kernel/watchdog: Prevent false positives with turbo
> modes")
> Signed-off-by: Douglas Anderson
Reviewed-by: Petr Mladek
Best Regards,
Petr
>
> Signed-off-by: Douglas Anderson
I like this change:
Reviewed-by: Petr Mladek
See a comment below.
> --- a/kernel/watchdog_perf.c
> +++ b/kernel/watchdog_perf.c
> @@ -147,12 +151,16 @@ void hardlockup_detector_perf_enable(void)
> }
>
> /**
> - * hardlockup_detector_
On Fri 2023-05-05 13:06:41, Nicholas Piggin wrote:
> On Fri May 5, 2023 at 8:13 AM AEST, Douglas Anderson wrote:
> > Do a search and replace of:
> > - NMI_WATCHDOG_ENABLED => HARD_WATCHDOG_ENABLED
> > - watchdog_nmi_ => watchdog_hardlockup_
>
> These are just making prefixes inconsistent again.
On Thu 2023-05-04 15:13:42, Douglas Anderson wrote:
> In preparation for the buddy hardlockup detector, which wants the same
> petting logic as the current perf hardlockup detector, move the code
> to watchdog.c. While doing this, rename the global variable to match
> others nearby. The
On Thu 2023-05-04 15:13:41, Douglas Anderson wrote:
> In preparation for the buddy hardlockup detector where the CPU
> checking for lockup might not be the currently running CPU, add a
> "cpu" parameter to watchdog_hardlockup_check().
>
> --- a/kernel/watchdog.c
> +++ b/kernel/watchdog.c
> @@
d or _processed look good to me.
> > allcpu_dumped is better
> > than dumped_stacks though because the all-CPUs-dump is a particular
> > thing.
>
> OK, I can undo this and leave it as "allcpu_dumped".
I do not have strong opinion. Well, "allcpu" is another i
On Fri 2023-05-05 09:37:50, Doug Anderson wrote:
> Hi,
>
> On Thu, May 4, 2023 at 7:58 PM Nicholas Piggin wrote:
> >
> > On Fri May 5, 2023 at 8:13 AM AEST, Douglas Anderson wrote:
> > > The perf hardlockup detector works by looking at interrupt counts and
> > > seeing if they change from run to
and it's nice not
> to have names that are too convoluted.
>
> Signed-off-by: Douglas Anderson
Looks good:
Reviewed-by: Petr Mladek
Best Regards,
Petr
On Fri 2023-05-05 09:37:35, Doug Anderson wrote:
> Hi,
>
> On Thu, May 4, 2023 at 7:51 PM Nicholas Piggin wrote:
> >
> > On Fri May 5, 2023 at 8:13 AM AEST, Douglas Anderson wrote:
> > > In preparation for the buddy hardlockup detector, rename
> > > touch_nmi_watchdog() to
fixed path:
Reviewed-by: Petr Mladek
> > CONFIG_HARDLOCKUP_DETECTOR_PERF and the function is defined in that
> > file if CONFIG_HARDLOCKUP_CHECK_TIMESTAMP.
> >
> > The dummy version of the function in "nmi.h" didn't get that quite
> > right. W
kip the warning and the instruction write.
>
> Signed-off-by: Josh Poimboeuf
It seems that the function does what it says. And it seems to be the
only location where an instruction is checked before it is modified.
I am fine with this approach.
Reviewed-by: Petr Mladek
Best Regards,
Petr
On Tue 2023-01-24 19:38:04, Josh Poimboeuf wrote:
> restore_r2() returns 1 on success, which is surprising for a non-boolean
> function. Change it to return 0 on success and -errno on error to match
> kernel coding convention.
>
> Signed-off-by: Josh Poimboeuf
Looks good:
Re
On Thu 2023-01-12 10:24:43, Luis Chamberlain wrote:
> On Thu, Jan 12, 2023 at 08:54:26PM +1000, Nicholas Piggin wrote:
> > kallsyms_on_each* may schedule so must not be called with interrupts
> > disabled. The iteration function could disable interrupts, but this
> > also changes lookup_symbol()
On Tue 2022-12-13 00:28:34, Song Liu wrote:
> On Fri, Dec 9, 2022 at 4:55 AM Miroslav Benes wrote:
> >
> > Hi,
> >
> > first thank you for taking over and I also appologize for not replying
> > much sooner.
> >
> > On Thu, 1 Sep 2022, Song Liu wrote:
> >
> > > From: Miroslav Benes
> > >
> > >
On Tue 2022-12-13 00:13:46, Song Liu wrote:
> )() ()On Mon, Dec 12, 2022 at 9:12 AM Petr Mladek wrote:
> >
> > On Fri 2022-12-09 11:59:35, Song Liu wrote:
> > > On Fri, Dec 9, 2022 at 3:41 AM Petr Mladek wrote:
> > > > On Mon 2022-11-28 17:57:06, Song Liu w
On Fri 2022-12-09 11:59:35, Song Liu wrote:
> On Fri, Dec 9, 2022 at 3:41 AM Petr Mladek wrote:
> > On Mon 2022-11-28 17:57:06, Song Liu wrote:
> > > On Fri, Nov 18, 2022 at 8:24 AM Petr Mladek wrote:
> > > >
> > > > > --- a/arch/powerpc/kernel/mo
On Fri 2022-12-09 14:54:10, Petr Mladek wrote:
> On Mon 2022-11-28 17:57:06, Song Liu wrote:
> > On Fri, Nov 18, 2022 at 8:24 AM Petr Mladek wrote:
> > > > --- a/kernel/livepatch/core.c
> > > > +++ b/kernel/livepatch/core.c
> I see that you removed also:
>
On Mon 2022-11-28 17:57:06, Song Liu wrote:
> On Fri, Nov 18, 2022 at 8:24 AM Petr Mladek wrote:
> > > --- a/kernel/livepatch/core.c
> > > +++ b/kernel/livepatch/core.c
> > > @@ -316,6 +316,45 @@ int klp_apply_section_relocs(struct module *pmod,
> > >
On Mon 2022-11-28 17:57:06, Song Liu wrote:
> On Fri, Nov 18, 2022 at 8:24 AM Petr Mladek wrote:
> --- a/arch/x86/kernel/module.c
> +++ b/arch/x86/kernel/module.c
> > This duplicates a lot of code. Please, rename apply_relocate_add() the
> > same way as __apply_clear_r
Nov 18, 2022 at 8:24 AM Petr Mladek wrote:
> >
> > > --- a/arch/powerpc/kernel/module_64.c
> > > +++ b/arch/powerpc/kernel/module_64.c
I put back the name of the modified file so that it is easier
to know what changes we are talking about.
[...]
> > > +#ifdef C
On Thu 2022-09-01 10:12:52, Song Liu wrote:
> From: Miroslav Benes
>
> Josh reported a bug:
>
> When the object to be patched is a module, and that module is
> rmmod'ed and reloaded, it fails to load with:
>
> module: x86/modules: Skipping invalid relocation target, existing value is
>
On Fri 2022-11-18 12:22:58, Petr Mladek wrote:
> On Wed 2022-11-16 17:27:12, John Ogness wrote:
> > This is v5 of a series to prepare for threaded/atomic
> > printing. v4 is here [0]. This series focuses on reducing the
> > scope of the BKL console_lock. It achieves this by
On Wed 2022-11-16 17:27:12, John Ogness wrote:
> This is v5 of a series to prepare for threaded/atomic
> printing. v4 is here [0]. This series focuses on reducing the
> scope of the BKL console_lock. It achieves this by switching to
> SRCU and a dedicated mutex for console list iteration and
>
On Mon 2022-11-07 15:22:24, John Ogness wrote:
> It is not reliable to check for CON_ENABLED in order to identify if a
> console is registered. Use console_is_registered() instead.
>
> Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
Best Regards,
Petr
be nice to fix this. But it might be done later.
Feel free to use:
Reviewed-by: Petr Mladek
>
> /* If this index is what the user requested, then register
Best Regards,
Petr
On Mon 2021-10-18 22:02:03, Steven Rostedt wrote:
> On Mon, 18 Oct 2021 12:19:20 +0200
> Petr Mladek wrote:
>
> > > -
> > > bit = trace_get_context_bit() + start;
> > > if (unlikely(val & (1 << bit))) {
> > > /*
> > >
On Mon 2021-10-18 09:50:27, Steven Rostedt wrote:
> On Mon, 18 Oct 2021 12:19:20 +0200
> Petr Mladek wrote:
>
> > On Fri 2021-10-15 11:00:35, Steven Rostedt wrote:
> > > From: "Steven Rostedt (VMware)"
> > >
> > > While writing an e
On Fri 2021-10-15 11:00:35, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)"
>
> While writing an email explaining the "bit = 0" logic for a discussion on
> making ftrace_test_recursion_trylock() disable preemption, I discovered a
> path that makes the "not do the logic if bit is zero"
On Fri 2021-10-15 11:13:08, 王贇 wrote:
>
>
> On 2021/10/14 下午11:14, Petr Mladek wrote:
> [snip]
> >> - return trace_test_and_set_recursion(ip, parent_ip, TRACE_FTRACE_START,
> >> TRACE_FTRACE_MAX);
> >> + int bit;
> >> +
> >
> + if (bit)
This is not symetric with trylock(). It should be:
if (bit > 0)
Anyway, trace_clear_recursion() quiently ignores bit != 0
> + preempt_enable_notrace();
> trace_clear_recursion(bit);
> }
Below is my proposed patch that tries to better explain the recursion
check:
>
On Tue 2021-08-03 15:18:51, John Ogness wrote:
> Hi,
>
> This is the next part of our printk-rework effort (points 3 and
> 4 of the LPC 2019 summary [0]).
>
> Here the concept of "atomic consoles" is introduced through a
> new (optional) write_atomic() callback for console drivers. This
>
On Tue 2021-08-03 17:36:32, John Ogness wrote:
> On 2021-08-03, Daniel Thompson wrote:
> > On Tue, Aug 03, 2021 at 03:18:54PM +0206, John Ogness wrote:
> >> kgdb makes use of its own cpulock (@dbg_master_lock, @kgdb_active)
> >> during cpu roundup. This will conflict with the printk cpulock.
> >
On Wed 2021-08-04 12:31:59, Daniel Thompson wrote:
> On Tue, Aug 03, 2021 at 05:36:32PM +0206, John Ogness wrote:
> > On 2021-08-03, Daniel Thompson wrote:
> > > On Tue, Aug 03, 2021 at 03:18:54PM +0206, John Ogness wrote:
> > >> kgdb makes use of its own cpulock (@dbg_master_lock, @kgdb_active)
On Thu 2021-07-15 21:39:53, John Ogness wrote:
> Hi,
>
> Here is v4 of a series to remove the safe buffers. v3 can be
> found here [0]. The safe buffers are no longer needed because
> messages can be stored directly into the log buffer from any
> context.
>
> However, the safe buffers also
On Wed 2021-07-21 14:52:15, John Ogness wrote:
> On 2021-07-21, Petr Mladek wrote:
> >> --- a/kernel/trace/trace.c
> >> +++ b/kernel/trace/trace.c
> >> @@ -9647,7 +9647,7 @@ void ftrace_dump(enum ftrace_dump_mode
> >> oops_dump_mode)
> >>tr
On Thu 2021-07-15 21:39:57, John Ogness wrote:
> All NMI contexts are handled the same as the safe context: store the
> message and defer printing. There is no need to have special NMI
> context tracking for this. Using in_nmi() is enough.
>
> There are several parts of the kernel that are
for most of printk is not needed. Remove it. Only safe context
> tracking relating to the console and console_owner locks is left
> in place. This is because the console and console_owner locks are
> needed for the actual printing.
>
> Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
Best Regards,
Petr
On Thu 2021-06-24 17:41:56, John Ogness wrote:
> I would prefer a v4 with these fixes:
>
> - wrap @console_owner_lock with printk_safe usage
>
> - remove unnecessary printk_safe usage from printk_safe.c
>
> - update commit message to say that safe context tracking is left in
> place for both
On Thu 2021-06-24 13:17:46, John Ogness wrote:
> All NMI contexts are handled the same as the safe context: store the
> message and defer printing. There is no need to have special NMI
> context tracking for this. Using in_nmi() is enough.
>
> Signed-off-by: John Ogness
>
for most of printk is not needed. Remove it. Only safe context
> tracking relating to the console lock is left in place. This is
> because the console lock is needed for the actual printing.
Feel free to use:
Reviewed-by: Petr Mladek
There are some comments below.
> --- a/kernel/prin
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 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: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 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-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 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
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
1 - 100 of 285 matches
Mail list logo
