Re: [PATCH] HID: Separate struct hid_device's driver_lock into two locks.

On Mon, 26 Nov 2012, David Herrmann wrote:

The fix you are proposing actually looks pretty nice, although it puts
the burden of locking to the hid-driver instead of the hid-core. So
every .probe function must go sure that the lock is held when
returning. This means if you unlock the input-lock, you need to lock
it before calling return so hid-core can unlock it again. This opens a
small race-condition where the hid-core might drop important
input-events as input-lock is held during "return". Any ideas here?

But why should we care deeply?

The lost events wouldn't be the ones that are needed for initialization of 
the device, as all the probing as been finished already.

So they would be 'regular' events sent by the device. And as the 
initialization hasn't been finished yet, it really can't be predicted 
which events make it and which don't.

Thanks,

-- 
Jiri Kosina
SUSE Labs