On Tue, Nov 18, 2014 at 06:31:38AM +0000, Kweh, Hock Leong wrote: > > -----Original Message----- > > From: Matt Fleming [mailto:matt@xxxxxxxxxxxxxxxxx] > > Sent: Monday, November 17, 2014 11:12 PM > > > > > > - Only doing module unload is required to be aware of this synchronization > > > -> Ensuring the call back does not fall into unloaded code which may > > cause > > > undefined behavior. > > > -> Ensuring the put_device() & module_put() code have finished in > > firmware_class.c > > > function request_firmware_work_func() before the device is > > unregistered > > > and module unloaded happen. > > > > Shouldn't the existing module_{put,get}() and {put,get}_device() calls > > provide all the necessary synchronisation? > > > > Module unload should not be possible while other code is using the > > module (and the module refcnt has been incremented accordindly). > > > > Right? > > > > -- > > Matt Fleming, Intel Open Source Technology Center > > Hi Matt, > > Yes, you are right. If the module refcount is not zero, you will get error > message and returned while you do "rmmod". But I strongly believe if we > have the capability in our code to take care of it by doing synchronization, > we should take care of it in case people are doing "rmmod -f". Don't > you think so? If you do 'rmmod -f' you get to keep all of the broken pieces of your kernel, no need to try to help out with crazy things like that. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
