[PATCH v2 hmm 05/11] mm/hmm: Remove duplicate condition test before wait_event_timeout
Jason Gunthorpe
jgg at ziepe.ca
Fri Jun 7 12:47:36 UTC 2019
On Thu, Jun 06, 2019 at 08:06:52PM -0700, John Hubbard wrote:
> On 6/6/19 11:44 AM, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe <jgg at mellanox.com>
> >
> > The wait_event_timeout macro already tests the condition as its first
> > action, so there is no reason to open code another version of this, all
> > that does is skip the might_sleep() debugging in common cases, which is
> > not helpful.
> >
> > Further, based on prior patches, we can no simplify the required condition
>
> "now simplify"
>
> > test:
> > - If range is valid memory then so is range->hmm
> > - If hmm_release() has run then range->valid is set to false
> > at the same time as dead, so no reason to check both.
> > - A valid hmm has a valid hmm->mm.
> >
> > Also, add the READ_ONCE for range->valid as there is no lock held here.
> >
> > Signed-off-by: Jason Gunthorpe <jgg at mellanox.com>
> > Reviewed-by: Jérôme Glisse <jglisse at redhat.com>
> > include/linux/hmm.h | 12 ++----------
> > 1 file changed, 2 insertions(+), 10 deletions(-)
> >
> > diff --git a/include/linux/hmm.h b/include/linux/hmm.h
> > index 4ee3acabe5ed22..2ab35b40992b24 100644
> > +++ b/include/linux/hmm.h
> > @@ -218,17 +218,9 @@ static inline unsigned long hmm_range_page_size(const struct hmm_range *range)
> > static inline bool hmm_range_wait_until_valid(struct hmm_range *range,
> > unsigned long timeout)
> > {
> > - /* Check if mm is dead ? */
> > - if (range->hmm == NULL || range->hmm->dead || range->hmm->mm == NULL) {
> > - range->valid = false;
> > - return false;
> > - }
> > - if (range->valid)
> > - return true;
> > - wait_event_timeout(range->hmm->wq, range->valid || range->hmm->dead,
> > + wait_event_timeout(range->hmm->wq, range->valid,
> > msecs_to_jiffies(timeout));
> > - /* Return current valid status just in case we get lucky */
> > - return range->valid;
> > + return READ_ONCE(range->valid);
>
> Just to ensure that I actually understand the model: I'm assuming that the
> READ_ONCE is there solely to ensure that range->valid is read *after* the
> wait_event_timeout() returns. Is that correct?
No, wait_event_timout already has internal barriers that make sure
things don't leak across it.
The READ_ONCE is required any time a thread is reading a value that
another thread can be concurrently changing - ie in this case there is
no lock protecting range->valid so the write side could be running.
Without the READ_ONCE the compiler is allowed to read the value twice
and assume it gets the same result, which may not be true with a
parallel writer, and thus may compromise the control flow in some
unknown way.
It is also good documentation for the locking scheme in use as it
marks shared data that is not being locked.
However, now that dead is gone we can just write the above more simply
as:
static inline bool hmm_range_wait_until_valid(struct hmm_range *range,
unsigned long timeout)
{
return wait_event_timeout(range->hmm->wq, range->valid,
msecs_to_jiffies(timeout)) != 0;
}
Which relies on the internal barriers of wait_event_timeout, I'll fix
it up..
Thanks,
Jason
More information about the amd-gfx
mailing list