From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756527AbbHFWV5 (ORCPT ); Thu, 6 Aug 2015 18:21:57 -0400 Received: from lb2-smtp-cloud6.xs4all.net ([194.109.24.28]:52655 "EHLO lb2-smtp-cloud6.xs4all.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756500AbbHFWV4 (ORCPT ); Thu, 6 Aug 2015 18:21:56 -0400 Message-ID: <1438899707.25241.29.camel@tiscali.nl> Subject: Re: windfarm: decrement client count when unregistering From: Paul Bolle To: Michael Ellerman Cc: Benjamin Herrenschmidt , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Date: Fri, 07 Aug 2015 00:21:47 +0200 In-Reply-To: <20150805041611.ACBD6140324@ozlabs.org> References: <20150805041611.ACBD6140324@ozlabs.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.4 (3.16.4-2.fc22) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On wo, 2015-08-05 at 14:16 +1000, Michael Ellerman wrote: > On Fri, 2015-31-07 at 12:08:58 UTC, Paul Bolle wrote: > > windfarm_corex_exit() contains: > > BUG_ON(wf_client_count != 0); > > > > I wonder why that, apparently. never triggered. > > Hmm interesting. > > A quick test here on an iMacG5 shows that we get into a state where we can't > remove windfarm_core: > > $ lsmod > Module Size Used by > windfarm_smu_sensors 7549 2 > windfarm_core 15391 1 windfarm_smu_sensors > > > Which means we can't trigger windfarm_core_exit() and the BUG_ON(). Perhaps this is what, roughly, happens: smu_sensors_init() smu_ads_create() /* Let's assume this happens ... */ ads->sens.ops = &smu_cpuamp_ops ads->sens.name = "cpu-current" smu_ads_create() /* ditto ... */ ads->sens.ops = &smu_cpuvolt_ops ads->sens.name = "cpu-voltage" /* ... so this would then be true */ if (volt_sensor && curr_sensor) /* and we do this */ smu_cpu_power_create(&volt_sensor->sens, &curr_sensor->sens) wf_get_sensor(&volt_sensor->sens) try_module_get(volt_sensor->sens->ops->owner /* THIS_MODULE */) wf_get_sensor(&curr_sensor->sens) try_module_get(curr_sensor->sens->ops->owner /* THIS_MODULE */) The cleanup would have happened here: smu_sensors_exit() while (!list_empty(&smu_ads) wf_unregister_sensor(&ads->sens) wf_put_sensor() /* would this also be done for sensors that never * triggered a call to module_get()? */ module_put(ads->sens->ops->owner /* THIS MODULE */) But, whatever it is that smu_sensors_exit() wants to do, it will never be called since there are these two references to this module that smu_sensors_init() created itself, preventing the unloading of this module. Does the above look plausible? Note that this was only cobbled together by staring at the code for far too long. If I had some powerpc machine at hand I could have actually tested this with a few strategically placed printk()'s. > I also get an oops when removing windfarm_lm75_sensor, so I suspect there are > gremlins in the module ref counting for windfarm. (This I haven't (yet) looked into.) > I'll merge this as probably correct. Hope this helps, Paul Bolle