Hi,
On Sun, Dec 22, 2024 at 10:32 PM wzs wrote:
>
> Hello,
> when fuzzing the Linux kernel,
> I triggered many "watch: BUG: soft lockup" warnings.
> I am not sure whether this is an issue with the kernel or with the
> fuzzing program I ran.
> (The same fuzzing program, when tested on kernel versi
Hi,
On Mon, Mar 25, 2024 at 2:48 AM Bitao Hu wrote:
>
> Hi, Thomas
>
> On 2024/3/24 04:43, Thomas Gleixner wrote:
> > On Wed, Mar 06 2024 at 20:52, Bitao Hu wrote:
> >> +if (__this_cpu_read(snapshot_taken)) {
> >> +for_each_active_irq(i) {
> >> +count = kstat_g
Hi,
On Tue, Feb 27, 2024 at 11:22 PM Bitao Hu wrote:
>
> When the watchdog determines that the current soft lockup is due
> to an interrupt storm based on CPU utilization, reporting the
> most frequent interrupts could be good enough for further
> troubleshooting.
>
> Below is an example of inter
Hi,
On Tue, Feb 27, 2024 at 11:22 PM Bitao Hu wrote:
>
> show_interrupts() unconditionally accumulates the per CPU interrupt
> statistics to determine whether an interrupt was ever raised.
>
> This can be avoided for all interrupts which are not strictly per CPU
> and not of type NMI because thos
Hi,
On Tue, Feb 27, 2024 at 11:22 PM Bitao Hu wrote:
>
> The soft lockup detector lacks a mechanism to identify interrupt storms
> as root cause of a lockup. To enable this the detector needs a
> mechanism to snapshot the interrupt count statistics on a CPU when the
> detector observes a potentia
Hi,
On Fri, Aug 4, 2023 at 8:02 AM Michal Hocko wrote:
>
> > > It would have been slightly safer to modify arch_trigger_cpumask_backtrace
> > > by switching arguments so that some leftovers are captured easier.
> >
> > I'm not sure I understand. Oh, you're saying make the prototype of
> > arch_tr
Hi,
On Fri, Aug 4, 2023 at 12:50 AM Michal Hocko wrote:
>
> On Thu 03-08-23 16:07:57, Douglas Anderson wrote:
> > The APIs that allow backtracing across CPUs have always had a way to
> > exclude the current CPU. This convenience means callers didn't need to
> > find a place to allocate a CPU mask
Hi,
On Sat, Jul 1, 2023 at 7:40 AM Guenter Roeck wrote:
>
> On Fri, Jun 16, 2023 at 05:06:18PM +0200, Petr Mladek wrote:
> > The HAVE_ prefix means that the code could be enabled. Add another
> > variable for HAVE_HARDLOCKUP_DETECTOR_ARCH without this prefix.
> > It will be set when it should be
Hi,
On Wed, Jun 21, 2023 at 6:08 AM Michael Ellerman wrote:
>
> Petr Mladek writes:
> > The HAVE_ prefix means that the code could be enabled. Add another
> > variable for HAVE_HARDLOCKUP_DETECTOR_ARCH without this prefix.
> > It will be set when it should be built. It will make it compatible
>
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 preferred one.
>
> CONFIG_HARDLOCKUP_DETECTOR was introduced by the commit 23637d477c1f53acb
> ("lockup_detector: In
Hi,
On Fri, Jun 16, 2023 at 8:07 AM Petr Mladek wrote:
>
> There are four possible variants of hardlockup detectors:
>
> + buddy: available when SMP is set.
>
> + perf: available when HAVE_HARDLOCKUP_DETECTOR_PERF is set.
>
> + arch-specific: available when HAVE_HARDLOCKUP_DETECTOR_ARCH is
Hi,
On Fri, Jun 16, 2023 at 8:06 AM Petr Mladek wrote:
>
> There are four possible variants of hardlockup detectors:
>
> + buddy: available when SMP is set.
>
> + perf: available when HAVE_HARDLOCKUP_DETECTOR_PERF is set.
>
> + arch-specific: available when HAVE_HARDLOCKUP_DETECTOR_ARCH is
Hi,
On Wed, Jun 14, 2023 at 3:29 AM Petr Mladek wrote:
>
> It seems that we have entered into a bike shedding mode.
> The following questions come to my mind:
>
>1. Does this patchset improve the current state?
>
>2. Maybe, it is not black&white. Is it possible to summarize
> what e
Mark,
On Mon, Jun 12, 2023 at 3:33 AM Mark Rutland wrote:
>
> On Fri, May 19, 2023 at 10:18:39AM -0700, 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
Hi,
On Thu, Jun 8, 2023 at 4:02 AM Petr Mladek wrote:
>
> > > config HARDLOCKUP_DETECTOR
> > > bool "Detect Hard Lockups"
> > > depends on DEBUG_KERNEL && !S390
> > > - depends on HAVE_HARDLOCKUP_DETECTOR_NON_ARCH ||
> > > HAVE_HARDLOCKUP_DETECTOR_ARCH
> > > + depend
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/Kconfig
> @@ -404,10 +404,9 @@ config HAVE_NMI_WATCHDOG
> depends on HAVE_NMI
> bool
> help
> -
Hi,
On Wed, Jun 7, 2023 at 8:26 AM Petr Mladek wrote:
>
> The HAVE_ prefix means that the code could be enabled. Add another
> variable for HAVE_HARDLOCKUP_DETECTOR_SPARC64 without this prefix.
> It will be set when it should be built. It will make it compatible
> with the other hardlockup detect
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 hardlockup detector is not build at all.
s/build/built/
> arch_touch_nmi_watchdog() has to be d
Hi,
On Wed, Jun 7, 2023 at 8:25 AM 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@changeid
I will le
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_DETECTOR_COUNTS_HRTIMER
>
> +config HARDLOCKUP_DETECTOR_ARCH
> + bool
> + depends on HARDLO
Hi,
On Wed, Jun 7, 2023 at 8:25 AM Petr Mladek wrote:
>
> The configuration variable HAVE_NMI_WATCHDOG has a generic name but
> it is selected only for SPARC64.
>
> It should _not_ be used in general because it is not integrated with
> the other hardlockup detectors. Namely, it does not support t
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/Kconfig
> @@ -404,17 +404,27 @@ config HAVE_NMI_WATCHDOG
> depends on HAVE_NMI
> bool
> help
> -
Hi,
On Wed, Jun 7, 2023 at 8:25 AM Petr Mladek wrote:
>
> There are four possible variants of hardlockup detectors:
>
> + buddy: available when SMP is set.
>
> + perf: available when HAVE_HARDLOCKUP_DETECTOR_PERF is set.
>
> + arch-specific: available when HAVE_HARDLOCKUP_DETECTOR_ARCH is s
Hi,
On Wed, May 10, 2023 at 9:42 AM Doug Anderson wrote:
>
> Hi,
>
> On Wed, May 10, 2023 at 9:30 AM Mark Rutland wrote:
> >
> > On Wed, May 10, 2023 at 08:28:17AM -0700, Doug Anderson wrote:
> > > Hi,
> >
> > Hi Doug,
> >
> > > On
Hi,
On Wed, May 24, 2023 at 6:38 AM Petr Mladek wrote:
>
> On Fri 2023-05-19 10:18:36, Douglas Anderson wrote:
> > Do a search and replace of:
> > - NMI_WATCHDOG_ENABLED => WATCHDOG_HARDLOCKUP_ENABLED
> > - SOFT_WATCHDOG_ENABLED => WATCHDOG_SOFTOCKUP_ENABLED
> > - watchdog_nmi_ => watchdog_hardlo
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-specific support code to detect lockups. Instead of using
> > something arch-specific we will use the bud
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_disable(), and watchdog_hardlockup_probe() are
> > declared __weak means that the configured hardlockup dete
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
> > checking for lockup might not be the currently running CPU, add a
> > "cpu" parameter to watchdog_hardlockup_check(
Hi,
On Mon, May 8, 2023 at 8:52 AM Doug Anderson wrote:
>
> Hmmm, but I don't think you really need "all-to-all" checking to get
> the stacktraces you want, do you? Each CPU can be "watching" exactly
> one other CPU, but then when we actually lock up we coul
Hi,
On Thu, May 11, 2023 at 8:46 AM Petr Mladek wrote:
>
> > @@ -111,6 +125,11 @@ static void watchdog_hardlockup_interrupt_count(void)
> >
> > void watchdog_hardlockup_check(unsigned int cpu, struct pt_regs *regs)
> > {
> > + if (__this_cpu_read(watchdog_hardlockup_touch)) {
> > +
Hi,
On Thu, May 11, 2023 at 7:14 AM Petr Mladek wrote:
>
> 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(
Hi,
On Wed, May 10, 2023 at 9:30 AM Mark Rutland wrote:
>
> On Wed, May 10, 2023 at 08:28:17AM -0700, Doug Anderson wrote:
> > Hi,
>
> Hi Doug,
>
> > On Wed, Apr 19, 2023 at 3:57 PM Douglas Anderson
> > wrote:
> > > This is an attempt to r
Hi,
On Wed, Apr 19, 2023 at 3:57 PM Douglas Anderson wrote:
>
> This is an attempt to resurrect Sumit's old patch series [1] that
> allowed us to use the arm64 pseudo-NMI to get backtraces of CPUs and
> also to round up CPUs in kdb/kgdb. The last post from Sumit that I
> could find was v7, so I c
Hi,
On Sun, May 7, 2023 at 6:35 PM Nicholas Piggin wrote:
>
> On Sat May 6, 2023 at 2:37 AM AEST, 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 Ande
Hi,
On Sun, May 7, 2023 at 6:05 PM Nicholas Piggin wrote:
>
> > No, I wasn't aware of it. Interesting, it seems to basically enable
> > both types of hardlockup detectors together. If that really catches
> > more lockups, it seems like we could do the same thing for the buddy
> > system.
>
> It d
Hi,
On Thu, May 4, 2023 at 8:07 PM 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
Hi,
On Thu, May 4, 2023 at 8:02 PM Nicholas Piggin wrote:
>
> On Fri May 5, 2023 at 8:13 AM AEST, Douglas Anderson wrote:
> > These are tiny style changes:
> > - Add a blank line before a "return".
> > - Renames two globals to use the "watchdog_hld" prefix.
>
> Particularly static ones don't real
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 run. The interrupt counts are
> > managed by the common watchdo
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 touch_hardlockup_watchdog() to make it clear
> > that it will touch whatever hardlocku
Hi,
On Thu, May 4, 2023 at 7:36 PM Nicholas Piggin wrote:
>
> On Fri May 5, 2023 at 8:13 AM AEST, Douglas Anderson wrote:
> > From: Colin Cross
> >
> > Implement a hardlockup detector that doesn't doesn't need any extra
> > arch-specific support code to detect lockups. Instead of using
> > somet
Hi,
On Mon, Jan 24, 2022 at 1:22 AM Christophe Leroy
wrote:
>
> --- a/kernel/debug/kdb/kdb_main.c
> +++ b/kernel/debug/kdb/kdb_main.c
> @@ -2022,8 +2022,11 @@ static int kdb_lsmod(int argc, const char **argv)
> if (mod->state == MODULE_STATE_UNFORMED)
> con
Hi,
On Tue, Jul 7, 2020 at 11:05 AM Randy Dunlap wrote:
>
> Drop the doubled word "driver".
>
> Signed-off-by: Randy Dunlap
> Cc: Jonathan Corbet
> Cc: linux-...@vger.kernel.org
> Cc: Jason Wessel
> Cc: Daniel Thompson
> Cc: Douglas Anderson
> Cc: kgdb-bugrep...@lists.sourceforge.net
> ---
>
Hi,
On Fri, Dec 7, 2018 at 9:42 AM Catalin Marinas wrote:
>
> On Tue, Dec 04, 2018 at 07:38:24PM -0800, Douglas Anderson wrote:
> > Douglas Anderson (4):
> > kgdb: Remove irq flags from roundup
> > kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function()
> > kgdb: Don't round u
Hi,
On Mon, Dec 3, 2018 at 7:57 AM Daniel Thompson
wrote:
>
> On Tue, Nov 27, 2018 at 09:38:37AM -0800, Douglas Anderson wrote:
> > When I had lockdep turned on and dropped into kgdb I got a nice splat
> > on my system. Specifically it hit:
> > DEBUG_LOCKS_WARN_ON(current->hardirq_context)
> >
Hi,
On Mon, Nov 26, 2018 at 9:39 PM kbuild test robot wrote:
>
> Hi Douglas,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on kgdb/kgdb-next]
> [also build test ERROR on v4.20-rc4 next-20181126]
> [if your patch is applied to the wrong git tree, please drop us
Hi,
On Wed, Nov 14, 2018 at 2:07 PM Will Deacon wrote:
>
> > +void __weak kgdb_call_nmi_hook(void *ignored)
> > +{
> > + kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
> > +}
>
> I suppose you could pass the cpu as an argument, but it doesn't really
> matter.
I probably won't chan
Hi,
On Sat, Nov 3, 2018 at 3:45 AM Daniel Thompson
wrote:
>
> On Wed, Oct 31, 2018 at 02:41:14PM -0700, Doug Anderson wrote:
> > > As mentioned in another part of the thread we can also add robustness
> > > by skipping a cpu where csd->flags != 0 (and adding an approp
Hi,
On Wed, Oct 31, 2018 at 11:40 AM Daniel Thompson
wrote:
>
> On Tue, Oct 30, 2018 at 03:18:43PM -0700, Douglas Anderson wrote:
> > diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
> > index f3cadda45f07..9a3f952de6ed 100644
> > --- a/kernel/debug/debug_core.c
> > +++ b/kernel
Hi,
On Tue, Oct 30, 2018 at 4:56 AM Daniel Thompson
wrote:
>
> On Mon, Oct 29, 2018 at 11:07:00AM -0700, Douglas Anderson wrote:
> > Looking back, this is pretty much two series squashed that could be
> > treated indepdently. The first is a serial series and the second is a
> > kgdb series.
>
>
Hi,
On Tue, Oct 30, 2018 at 4:46 AM Daniel Thompson
wrote:
>
> On Mon, Oct 29, 2018 at 11:07:07AM -0700, Douglas Anderson wrote:
> > The function kgdb_roundup_cpus() was passed a parameter that was
> > documented as:
> >
> > > the flags that will be used when restoring the interrupts. There is
>
Daniel,
On Tue, Oct 30, 2018 at 2:42 AM Daniel Thompson
wrote:
>
> On Mon, Oct 29, 2018 at 11:07:06AM -0700, Douglas Anderson wrote:
> > In kgdb_roundup_cpus() we've got code that looks like:
> > local_irq_enable();
> > smp_call_function(kgdb_call_nmi_hook, NULL, 0);
> > local_irq_disable()
Hi,
On Sun, Dec 17, 2017 at 2:54 AM, Mathieu Malaterre wrote:
> On Fri, Dec 15, 2017 at 10:01 PM, Mathieu Malaterre wrote:
>> On Fri, Dec 15, 2017 at 9:52 PM, Mathieu Malaterre wrote:
>>> On Fri, Dec 15, 2017 at 8:50 PM, Mathieu Malaterre wrote:
Hi there,
Does anyone has working
emove from the i2c subsystem.
Reported-by: Wolfram Sang
Reported-by: Stephen Warren
Signed-off-by: Doug Anderson
---
drivers/i2c/busses/i2c-au1550.c | 1 -
drivers/i2c/busses/i2c-bfin-twi.c | 2 --
drivers/i2c/busses/i2c-cpm.c| 2 --
drivers/i2c/busse
I know this is a long-dead thread, but I was a little curious about
the motivation here.
I'm looking at trying to support CONFIG_CMDLINE_EXTEND (an ARM
Kconfig) in this function and don't know in which cases I should look
at the CONFIG_CMDLINE and in which cases I should use whatever
happened to b
54 matches
Mail list logo
