On 23 June 2014 13:51, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote:
> Hi,
>
>> [worker]
>> complete_all()
>> device_release_driver()
>> dev_lock()
>> {already held, yield}
>> [syscall]
>> free(internal structures)
>> dev_unlock()
>> return
>> [worker]
>> {woken up, but dev->driver == NULL so no callbacks}
>> dev_unlock()
>> return
>>
>> The driver code section may not be reachable anymore upon worker
>> returning from the device_release_driver() call, right? Also since
>> ath10k uses an internal worker it also means the work_struct would be
>> already freed by the syscall flow (i.e. worker would run after driver
>> has supposedly been cleaned up..). Even if ath10k was to use
>> request_firmware_nowait(), which allocates a temporary work_struct,
>> the unreachable code section still remains a problem.
>>
>> Or maybe this isn't really a problem and/or I'm missing something?
>
> Yeah, hmm, this looks like a problem. I guess we didn't really consider
> module unload in such detail ...
>
> I guess this would crash upon return from device_release_driver()? I
> guess if that's the last thing then maybe we'd actually get a tail-call
> optimisation, but we don't want to rely on that of course!
>
> Seems like to fix it we just need to get a module reference though? Can
> a module put() itself though? Hmmm.
It seems some drivers use module_put(THIS_MODULE) and
__module_get(THIS_MODULE), e.g. tun/tap driver.
But does this bump up the module refcount in such a way that an
in-progress rmmod will wait/block until the refcount reaches 0?
Michał
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
