Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756511AbYBOPxK (ORCPT ); Fri, 15 Feb 2008 10:53:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755352AbYBOPwx (ORCPT ); Fri, 15 Feb 2008 10:52:53 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:41367 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1755277AbYBOPww (ORCPT ); Fri, 15 Feb 2008 10:52:52 -0500 Date: Fri, 15 Feb 2008 10:52:51 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Yi Yang cc: akpm@linux-foundation.org, , , , , , , , Subject: Re: [linux-pm] [PATCH 2.6.25-rc1] cpufreq: fix cpufreq policy refcount imbalance In-Reply-To: <1203032921.3897.10.camel@yangyi-dev.bj.intel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1554 Lines: 39 On Fri, 15 Feb 2008, Yi Yang wrote: > This patch adds kobject_put to balance refcount. I noticed Greg suggests > it will fix a power-off issue to remove kobject_get statement block, but i > think that isn't the best way because those code block has existed very long > and it is helpful because the successive statements are invoking relevant > data. Are you referring to this section of code (before the region affected by your patch)? if (!kobject_get(&data->kobj)) { spin_unlock_irqrestore(&cpufreq_driver_lock, flags); cpufreq_debug_enable_ratelimit(); unlock_policy_rwsem_write(cpu); return -EFAULT; } Greg is correct that the kobject_get() here is useless and should be removed. kobject_get() never returns NULL unless its argument is NULL. Since &data->kobj can never be NULL, the "if" test will never fail. Hence there's no point in making the test at all. The fact that a section of code has existed for a long time doesn't mean that it is right. :-) Furthermore, there's no reason to do the kobject_get(). Holding 2 references to a kobject is no better than holding just 1 reference. Assuming you know that the kobject is still registered, then you also know that there is already a reference to it. So you have no reason to take an additional reference. Alan Stern -- 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/