Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 29 Jun 2022 13:40:52 +0200
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
To:     Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <toke@redhat.com>
Cc:     Herbert Xu <herbert@gondor.apana.org.au>,
        linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
        Gregory Erwin <gregerwin256@gmail.com>,
        Kalle Valo <kvalo@kernel.org>,
        Rui Salvaterra <rsalvaterra@gmail.com>, stable@vger.kernel.org
Subject: Re: [PATCH v7] ath9k: let sleep be interrupted when unregistering
 hwrng
Message-ID: <Yrw6RDvSly6Zstb8@zx2c4.com>
References: <20220628151840.867592-1-Jason@zx2c4.com>
 <87pmirakke.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <87pmirakke.fsf@toke.dk>
Precedence: bulk

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