lkml.org 
[lkml]   [2022]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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(&current_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(&current_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

\
 
 \ /
  Last update: 2022-06-29 13:41    [W:0.172 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site