Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753493AbYHLV3s (ORCPT ); Tue, 12 Aug 2008 17:29:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751457AbYHLV3k (ORCPT ); Tue, 12 Aug 2008 17:29:40 -0400 Received: from saeurebad.de ([85.214.36.134]:38147 "EHLO saeurebad.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751305AbYHLV3k (ORCPT ); Tue, 12 Aug 2008 17:29:40 -0400 From: Johannes Weiner To: Nageswara R Sastry Cc: Peter Zijlstra , linux-kernel@vger.kernel.org, balbir@linux.vnet.ibm.com, ego@linux.vnet.ibm.com, svaidy@linux.vnet.ibm.com, davej@codemonkey.org.uk, Venkatesh Pallipadi , Alexey Starikovskiy Subject: Re: [BUG] While changing the cpufreq governor, kernel hits a bug in workqueue.c References: <485F8028.1070302@linux.vnet.ibm.com> <87y74w41fp.fsf@skyscraper.fehenstaub.lan> <4860BB8E.2070505@linux.vnet.ibm.com> <87tzfh2t5l.fsf@skyscraper.fehenstaub.lan> <48638906.4090308@linux.vnet.ibm.com> <87y74l4scd.fsf@skyscraper.fehenstaub.lan> <87fxqp7nye.fsf@skyscraper.fehenstaub.lan> <4871E657.3040403@linux.vnet.ibm.com> <87d4lqq7ec.fsf@saeurebad.de> <487300B1.4040300@linux.vnet.ibm.com> <877ibukn8k.fsf@saeurebad.de> <1216215897.1652.24.camel@lappy.programming.kicks-ass.net> <48A145FA.2030803@linux.vnet.ibm.com> Date: Tue, 12 Aug 2008 23:29:15 +0200 In-Reply-To: <48A145FA.2030803@linux.vnet.ibm.com> (Nageswara R. Sastry's message of "Tue, 12 Aug 2008 13:42:42 +0530") Message-ID: <8763q53ot0.fsf@skyscraper.fehenstaub.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1294 Lines: 50 Hi Nageswara, Nageswara R Sastry writes: > Any updates on this bug. Sorry. I was just looking into it again and still see no resolution. Added Venkatesh and Alexey to CC. To summarize again: The problem we have is that cpufreq_ondemand has a self-rearming worker function which we should but can not cancel synchroneously with the current code. The locking order is like this: store() policy_rwsem write cpufreq_governor_dbs() dbs_mutex work lock do_dbs_timer() policy_rwsem write which gives a locking hierarchy of: work lock policy_rwsem dbs_mutex Now, we _should_ cancel the worker synchroneously, but that won't fly since when cpufreq_governor_dbs() is called, we already hold policy_rwsem and grabbing the work lock is illegal. I will continue to read code and see if I can come up with a solution, but any help is really appreciated. I have not yet looked at cpufreq_conservative... > Thanks and Regards > R.Nageswara Sastry Thanks for your patience and insistence, Hannes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/