Question: input_ff_create_memless synchronization

From: Job Noorman <job@noorman.info>
Date: 2022-07-29 12:00:29

Hi all,

While creating a driver for a haptics device, I started looking at
existing consumers of `input_ff_create_memless` to learn how this API is
typically used. All drivers in drivers/input/misc that use this API
follow the same structure (code heavily simplified):
probe() {
    input_ff_create_memless(play);
    INIT_WORK(work);
}

play(data, effect) {
    data->strength = calc_strength(effect);
    schedule_work(work);
}

work(data) {
    do_device_io(data->strength);
}
My question is about the lack of synchronization on `data` between
`play` and `work` (none of the drivers I found use any kind of
synchronization).

As far as I understand, `play` is called in the context of a timer
softirq and `work` on a workqueue. So it seems possible that `play` is
executed while a previously scheduled `work` is still running or hasn't
even started yet. I see two potential problems when this would happen:

1. A race on `data->strength`;
2. Missed effect updates: if `work` hasn't finished yet when `play` is
   called again, `schedule_work` will not schedule it. In the worst
   case, we could miss the disabling of an effect.

Is this analysis correct? If not, what am I missing? If so, what would
be the correct way to synchronize? (1. seems easy enough but 2. might
need to involve `flush_work` to implement properly and I'm not sure if
it's ok to call that from a softirq context.)

Best,
Job
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help