mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <jstultz@google.com>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	Stephen Boyd <sboyd@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	x86@kernel.org
Subject: Re: [PATCH] clocksource: disable irq when holding watchdog_lock.
Date: Mon, 16 Oct 2023 16:03:47 -0700	[thread overview]
Message-ID: <ae4e5836-bc42-42fa-bd41-2a2fd483acb5@paulmck-laptop> (raw)
In-Reply-To: <878r826xys.ffs@tglx>

On Mon, Oct 16, 2023 at 11:47:55PM +0200, Thomas Gleixner wrote:
> On Mon, Oct 16 2023 at 10:46, John Stultz wrote:
> > On Fri, Oct 13, 2023 at 7:51 AM Tetsuo Handa
> > <penguin-kernel@i-love.sakura.ne.jp> wrote:
> >>
> >> Lockdep found that spin_lock(&watchdog_lock) from call_timer_fn()
> >> is not safe. Use spin_lock_irqsave(&watchdog_lock, flags) instead.
> >>
> >> [    0.378387] TSC synchronization [CPU#0 -> CPU#1]:
> >> [    0.378387] Measured 55060 cycles TSC warp between CPUs, turning off TSC clock.

[ . . . ]

> Something like the uncompiled/untested below should cure it for real. It
> really does not matter whether the TSC unstable event happens a bit
> later. The system is unhappy no matter what.

This does pass my acceptance tests:

Tested-by: Paul E. McKenney <paulmck@kernel.org>

> That said, this whole clocksource watchdog mess wants a proper
> overhaul. It has become a pile of warts and duct tape by now and after
> staring at it long enough there is no real reason to run it in a timer
> callback anymore. It just can move into delayed work and the whole
> locking problem can be reduced to the clocksource_mutex and some well
> thought out atomic operations to handle the mark unstable case. But
> that's a different story and not relevant for curing the problem at
> hand.

Moving the code to delayed work seems quite reasonable.

But Thomas, you do understand that the way things have been going for
the clocksource watchdog, pushing it out to delayed work will no doubt
add yet more hair on large busy systems, right?  Yeah, yeah, I know,
delayed work shouldn't be any worse than ksoftirqd.  The key word of
course being "shouldn't".  ;-)

							Thanx, Paul

> Thanks,
> 
>         tglx
> ---
> --- a/arch/x86/kernel/tsc_sync.c
> +++ b/arch/x86/kernel/tsc_sync.c
> @@ -15,6 +15,7 @@
>   * ( The serial nature of the boot logic and the CPU hotplug lock
>   *   protects against more than 2 CPUs entering this code. )
>   */
> +#include <linux/workqueue.h>
>  #include <linux/topology.h>
>  #include <linux/spinlock.h>
>  #include <linux/kernel.h>
> @@ -342,6 +343,13 @@ static inline unsigned int loop_timeout(
>  	return (cpumask_weight(topology_core_cpumask(cpu)) > 1) ? 2 : 20;
>  }
>  
> +static void tsc_sync_mark_tsc_unstable(struct work_struct *work)
> +{
> +	mark_tsc_unstable("check_tsc_sync_source failed");
> +}
> +
> +static DECLARE_WORK(tsc_sync_work, tsc_sync_mark_tsc_unstable);
> +
>  /*
>   * The freshly booted CPU initiates this via an async SMP function call.
>   */
> @@ -395,7 +403,7 @@ static void check_tsc_sync_source(void *
>  			"turning off TSC clock.\n", max_warp);
>  		if (random_warps)
>  			pr_warn("TSC warped randomly between CPUs\n");
> -		mark_tsc_unstable("check_tsc_sync_source failed");
> +		schedule_work(&tsc_sync_work);
>  	}
>  
>  	/*

  reply	other threads:[~2023-10-16 23:03 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-13 14:51 Tetsuo Handa
2023-10-16 17:46 ` John Stultz
2023-10-16 21:47   ` Thomas Gleixner
2023-10-16 23:03     ` Paul E. McKenney [this message]
2023-10-17  6:49       ` Thomas Gleixner
2023-10-17 14:11         ` Paul E. McKenney
2023-10-17 10:37     ` Tetsuo Handa
2023-10-17 14:10       ` Paul E. McKenney
2023-10-19  9:30         ` Tetsuo Handa
2023-10-19 12:14           ` Thomas Gleixner
2023-10-19 14:26             ` Tetsuo Handa
2023-10-20  3:30               ` Paul E. McKenney
2023-10-20 12:50                 ` Tetsuo Handa
2023-10-20 13:40                   ` Paul E. McKenney
2023-10-24 13:00               ` Thomas Gleixner
2023-10-24 14:52                 ` Tetsuo Handa
2023-10-25 21:28                   ` Thomas Gleixner
2023-10-25 21:31       ` [PATCH] x86/tsc: Defer marking TSC unstable to a worker Thomas Gleixner
2023-10-26  9:39         ` [tip: x86/urgent] " tip-bot2 for Thomas Gleixner
2023-10-27 18:46         ` tip-bot2 for Thomas Gleixner
2023-10-20  9:02     ` [PATCH] clocksource: disable irq when holding watchdog_lock Sebastian Andrzej Siewior
2023-10-26  2:33 ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ae4e5836-bc42-42fa-bd41-2a2fd483acb5@paulmck-laptop \
    --to=paulmck@kernel.org \
    --cc=bigeasy@linutronix.de \
    --cc=jstultz@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=sboyd@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®