linux-kernel - Re: [PATCH 3/4] kgdb,clocksource: Prevent kernel hang in kernel debugger

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 25 Jan 2010 20:37:06 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Jason Wessel <jason.wessel@...driver.com>
Cc:	linux-kernel@...r.kernel.org, kgdb-bugreport@...ts.sourceforge.net,
	mingo@...e.hu, Thomas Gleixner <tglx@...utronix.de>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	John Stultz <johnstul@...ibm.com>,
	Magnus Damm <damm@...l.co.jp>
Subject: Re: [PATCH 3/4] kgdb,clocksource: Prevent kernel hang in kernel
 debugger

On Mon, 25 Jan 2010 22:26:39 -0600 Jason Wessel <jason.wessel@...driver.com> wrote:

> This is a regression fix against: 0f8e8ef7c204988246da5a42d576b7fa5277a8e4

It's conventional to quote the patch title as well as the hash.  ie:

0f8e8ef7c204988246da5a42d576b7fa5277a8e4 ("clocksource: Simplify
clocksource watchdog resume logic")

> Spin locks were added to the clocksource_resume_watchdog() which cause
> the kernel debugger to deadlock on an SMP system frequently.

Please fully describe the deadlock.  Without that analysis, the only
way we can work it out is by guessing.  This makes it hard for others to
suggest alternative fixes.

> The kernel debugger can try for the lock, but if it fails it should
> continue to touch the clocksource watchdog anyway, else it will trip
> if the general kernel execution has been paused for too long.
> 
> This introduces an possible race condition where the kernel debugger
> might not process the list correctly if a clocksource is being added
> or removed at the time of this call.  This race is sufficiently rare vs
> having the kernel debugger hang the kernel

A trylock is a pretty ugly "solution" to a locking bug.

> CC: Thomas Gleixner <tglx@...utronix.de>
> CC: Martin Schwidefsky <schwidefsky@...ibm.com>
> CC: John Stultz <johnstul@...ibm.com>
> CC: Andrew Morton <akpm@...ux-foundation.org>
> CC: Magnus Damm <damm@...l.co.jp>
> Signed-off-by: Jason Wessel <jason.wessel@...driver.com>
> ---
>  kernel/time/clocksource.c |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
> index e85c234..74f9ba6 100644
> --- a/kernel/time/clocksource.c
> +++ b/kernel/time/clocksource.c
> @@ -463,7 +463,12 @@ void clocksource_resume(void)
>   */
>  void clocksource_touch_watchdog(void)
>  {
> -	clocksource_resume_watchdog();
> +	unsigned long flags;
> +
> +	int got_lock = spin_trylock_irqsave(&watchdog_lock, flags);
> +	clocksource_reset_watchdog();
> +	if (got_lock)
> +		spin_unlock_irqrestore(&watchdog_lock, flags);
>  }

If we're going to do this then clocksource_reset_watchdog() should be
uninlined.  It shouldn't have been inlined in the first place.

This trylock should be accompanied with an explanation which fully
describes the reasons for its presence.  Without that, how can the
code reader work this out?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/