linux-kernel - Re: windfarm: decrement client count when unregistering

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 for Android: free password hash cracker in your pocket

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

Message-ID: <1438899707.25241.29.camel@tiscali.nl>
Date:	Fri, 07 Aug 2015 00:21:47 +0200
From:	Paul Bolle <pebolle@...cali.nl>
To:	Michael Ellerman <mpe@...erman.id.au>
Cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: windfarm: decrement client count when unregistering

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
--
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/