On Thu, 2009-04-30 at 11:11 -0300, Henrique de Moraes Holschuh wrote: > > > Also, due to races, it is _impossible_ to assure the backend driver > > > that the set_block hook will never be called when the radio is > > > hard-blocked. Best to change the description of that hook to make it > > > clear that it could happen, but that the rfkill core will try to > > > optimize away such changes. Here's the race: > > > > > > A B > > > rfkill_set_block > > > saves state in "prev" > > > ... rfkill_set_hw_state(true) > > > call set_block hook > > > but radio IS hard-blocked > > > and the core WAS informed > > > of this > > > > Good point. I wonder what's more important -- it would be almost trivial > > to change this by using a spinlock instead of atomic bit operations. > > Yeah, as long as it is a spinlock variant that can be used safely in any > context, it should work fine, as contention would be quite rare (unless > there is a pathological case in one driver that makes it always call some > set_foo just when the core is going to call it back...) Heh, that would be strange. > > * rfkill_set_block can set a flag "I'm in an update" > > * a concurrent rfkill_set_sw_state will check that flag, and update the > > "prev" variable instead of the real variable > > * on errors, rfkill_set_block will then revert to whatever the last > > set_sw_state said > > That could work. It is still required to make it clear that the set_block > hook can be called with a hardware block active, even if it normally won't > be, so that backend drivers are aware of the possibility. Right, it could still happen, if the driver has just called set_hw_state when something decided to change the sw state. Should be relatively rare though. The other race can also happen, but the driver needs to take care of the return value of set_hw_state() so it doesn't matter. I'll see if I can implement this. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
