Messages in this thread | | | Date | Wed, 29 Jun 2022 13:40:52 +0200 | From | "Jason A. Donenfeld" <> | Subject | Re: [PATCH v7] ath9k: let sleep be interrupted when unregistering hwrng |
| |
Hi Toke,
On Wed, Jun 29, 2022 at 11:24:49AM +0200, Toke Høiland-Jørgensen wrote: > > + wait = !(filp->f_flags & O_NONBLOCK); > > + if (wait && cmpxchg(¤t_waiting_reader, NULL, current) != NULL) { > > + err = -EINTR; > > + goto out_unlock_reading; > > + } > > bytes_read = rng_get_data(rng, rng_buffer, > > - rng_buffer_size(), > > - !(filp->f_flags & O_NONBLOCK)); > > + rng_buffer_size(), wait); > > + if (wait && cmpxchg(¤t_waiting_reader, current, NULL) != current) > > + synchronize_rcu(); > > So this synchronize_rcu() is to ensure the hwrng_unregister() thread has > exited the rcu_read_lock() section below? Isn't that a bit... creative... > use of RCU? :)
It's to handle the extreeeeemely unlikely race in which hwrng_unregister() does its xchg, and then the thread calling rng_dev_read() entirely exits. In practice, the only way I'm able to trigger this race is by synthetically adding `msleep()` in the right spot. But anyway, for that reason, it's only synchronized if that second cmpxchg indicates that indeed the value was changed out from under us.
> Also, synchronize_rcu() can potentially take a while on a busy system, > is it OK to call it while holding the mutex?
The reading mutex won't be usable by anything anyway at this point, so I don't think it matters.
Jason
| |