From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1758782AbXELQ6p@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1758782AbXELQ6p (ORCPT <rfc822;w@1wt.eu>);
	Sat, 12 May 2007 12:58:45 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755306AbXELQ6g
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sat, 12 May 2007 12:58:36 -0400
Received: from www.osadl.org ([213.239.205.134]:59284 "EHLO mail.tglx.de"
	rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP
	id S1754352AbXELQ6f (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Sat, 12 May 2007 12:58:35 -0400
Subject: Re: [patch 3/3] clockevents: Fix resume logic - updated version
From: Thomas Gleixner <tglx@linutronix.de>
Reply-To: tglx@linutronix.de
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Ingo Molnar <mingo@elte.hu>,
       LKML <linux-kernel@vger.kernel.org>, John Stultz <johnstul@us.ibm.com>,
       linux-acpi@vger.kernel.org
In-Reply-To: <20070512095145.0cf58a57.akpm@linux-foundation.org>
References: <20070430102837.748238000@linutronix.de>
	 <20070511132846.5ebf4437.akpm@linux-foundation.org>
	 <200705112302.47726.rjw@sisk.pl> <200705112309.15996.rjw@sisk.pl>
	 <20070511235607.83ad0eb5.akpm@linux-foundation.org>
	 <1178959563.22481.126.camel@localhost.localdomain>
	 <20070512020056.a24cf472.akpm@linux-foundation.org>
	 <1178961489.22481.133.camel@localhost.localdomain>
	 <20070512030754.90488f79.akpm@linux-foundation.org>
	 <1178970253.22481.143.camel@localhost.localdomain>
	 <20070512095145.0cf58a57.akpm@linux-foundation.org>
Content-Type: text/plain
Date: Sat, 12 May 2007 19:01:41 +0200
Message-Id: <1178989302.22481.185.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.6.1 
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

On Sat, 2007-05-12 at 09:51 -0700, Andrew Morton wrote:
> The locking in clocksource_resume_watchdog looks pretty pointless anyway.
> Can't we just delete it?
> 
> The only thing it can race against is, conceivably,
> 
>         resumed = watchdog_resumed;
>         if (unlikely(resumed))
>                 watchdog_resumed = 0;
> 
> which could be solved by using test_and_clear_bit().

True. I'll redo it.

> Does anyone have any theories about my lockdep warning?

Can you upload a snapshot of your current queue ?

	tglx