Received: by 2002:ac0:a679:0:0:0:0:0 with SMTP id p54csp63663imp; Wed, 20 Feb 2019 14:20:20 -0800 (PST) X-Google-Smtp-Source: AHgI3IY27YsHJkODMQQFUu+YKmvp0KPCJythfIpsWeP0kn52r+5SqfDJOTqlBHd1cfx7byEaPWjW X-Received: by 2002:a63:20e:: with SMTP id 14mr31256307pgc.161.1550701220092; Wed, 20 Feb 2019 14:20:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550701220; cv=none; d=google.com; s=arc-20160816; b=brtnKwbEwRoL/CTnrPZ03oq71C40Au1tNoJ6phOT/s3dC8B9h8oWeoEjczu0eZe9gg /ShNrxNbYVJolQF2iM0rMsceyjDDeB+oG4EEj9xGOeBwPX0wU+XnkWmDzWK/BMGO33Hx dKyj7HtYrKBzsdcvmLb8N/rhwwpNe9LmJxgc08nXLcTN/ABdXxenWsLylu07VvGFnbVV vxD9s92y8v2Z/eV/buVHoCYpFY3sa/BF3/wry9JQIwMBLrKSXaEL19VV/tnRRZK27Uia Juhb0aglENxbo4ZCzZpLh5H+UnmvnVxhiDotr5P0E12C0pO2OLsKGuWghJdWSVamelYZ tAow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=Wy/mL2VQEulOHFfA+mQr9/7a6/AAOegXi2ilgUD+yWw=; b=OWLgYv1VxeOTqrSnKwdo9WUfG0FlUtV1mTVmF6jw10zealj/wqMh4skfB0EXcREMnH W+aABIYujJDLP0BXHlllJRG2wCsnnO8Wx7ijxppd8J4u051idAGdV3b78S9B0QZZYTJH ngGQLEA8NCHwgAo5e80pYpmFiJBrS6OlkKfmA4DD0d0t3mH4IK/WxOWG0LFmBsohEBUT jyb8k+KITwaDYVe5iiR8d6nysiTvv13vPLF8PSX0ysEr+YUxEPQ0MNK0oErNpW9Tzut+ l0Nit33o916fk19+NqMFIzqF4B00GO8izNkyT2YeF+U53mc/b4+j0+1ZxYMYCz6xtKws TBlQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l94si20841355plb.209.2019.02.20.14.20.04; Wed, 20 Feb 2019 14:20:20 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726224AbfBTWTh (ORCPT + 99 others); Wed, 20 Feb 2019 17:19:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34932 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725804AbfBTWTh (ORCPT ); Wed, 20 Feb 2019 17:19:37 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4210D8552A; Wed, 20 Feb 2019 22:19:36 +0000 (UTC) Received: from redhat.com (ovpn-121-220.rdu2.redhat.com [10.10.121.220]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8256F5D9D2; Wed, 20 Feb 2019 22:19:35 +0000 (UTC) Date: Wed, 20 Feb 2019 17:19:33 -0500 From: Jerome Glisse To: John Hubbard Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Ralph Campbell Subject: Re: [PATCH 10/10] mm/hmm: add helpers for driver to safely take the mmap_sem Message-ID: <20190220221933.GB29398@redhat.com> References: <20190129165428.3931-1-jglisse@redhat.com> <20190129165428.3931-11-jglisse@redhat.com> <16e62992-c937-6b05-ae37-a287294c0005@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <16e62992-c937-6b05-ae37-a287294c0005@nvidia.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Wed, 20 Feb 2019 22:19:36 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 20, 2019 at 01:59:13PM -0800, John Hubbard wrote: > On 1/29/19 8:54 AM, jglisse@redhat.com wrote: > > From: J?r?me Glisse > > > > The device driver context which holds reference to mirror and thus to > > core hmm struct might outlive the mm against which it was created. To > > avoid every driver to check for that case provide an helper that check > > if mm is still alive and take the mmap_sem in read mode if so. If the > > mm have been destroy (mmu_notifier release call back did happen) then > > we return -EINVAL so that calling code knows that it is trying to do > > something against a mm that is no longer valid. > > > > Signed-off-by: J?r?me Glisse > > Cc: Andrew Morton > > Cc: Ralph Campbell > > Cc: John Hubbard > > --- > > include/linux/hmm.h | 50 ++++++++++++++++++++++++++++++++++++++++++--- > > 1 file changed, 47 insertions(+), 3 deletions(-) > > > > diff --git a/include/linux/hmm.h b/include/linux/hmm.h > > index b3850297352f..4a1454e3efba 100644 > > --- a/include/linux/hmm.h > > +++ b/include/linux/hmm.h > > @@ -438,6 +438,50 @@ struct hmm_mirror { > > int hmm_mirror_register(struct hmm_mirror *mirror, struct mm_struct *mm); > > void hmm_mirror_unregister(struct hmm_mirror *mirror); > > +/* > > + * hmm_mirror_mm_down_read() - lock the mmap_sem in read mode > > + * @mirror: the HMM mm mirror for which we want to lock the mmap_sem > > + * Returns: -EINVAL if the mm is dead, 0 otherwise (lock taken). > > + * > > + * The device driver context which holds reference to mirror and thus to core > > + * hmm struct might outlive the mm against which it was created. To avoid every > > + * driver to check for that case provide an helper that check if mm is still > > + * alive and take the mmap_sem in read mode if so. If the mm have been destroy > > + * (mmu_notifier release call back did happen) then we return -EINVAL so that > > + * calling code knows that it is trying to do something against a mm that is > > + * no longer valid. > > + */ > > Hi Jerome, > > Are you thinking that, throughout the HMM API, there is a problem that > the mm may have gone away, and so driver code needs to be littered with > checks to ensure that mm is non-NULL? If so, why doesn't HMM take a > reference on mm->count? > > This solution here cannot work. I think you'd need refcounting in order > to avoid this kind of problem. Just doing a check will always be open to > races (see below). > > > > +static inline int hmm_mirror_mm_down_read(struct hmm_mirror *mirror) > > +{ > > + struct mm_struct *mm; > > + > > + /* Sanity check ... */ > > + if (!mirror || !mirror->hmm) > > + return -EINVAL; > > + /* > > + * Before trying to take the mmap_sem make sure the mm is still > > + * alive as device driver context might outlive the mm lifetime. > > + * > > + * FIXME: should we also check for mm that outlive its owning > > + * task ? > > + */ > > + mm = READ_ONCE(mirror->hmm->mm); > > + if (mirror->hmm->dead || !mm) > > + return -EINVAL; > > + > > Nothing really prevents mirror->hmm->mm from changing to NULL right here. This is really just to catch driver mistake, if driver does not call hmm_mirror_unregister() then the !mm will never be true ie the mirror->hmm->mm can not go NULL until the last reference to hmm_mirror is gone. > > > + down_read(&mm->mmap_sem); > > + return 0; > > +} > > + > > ...maybe better to just drop this patch from the series, until we see a > pattern of uses in the calling code. It use by nouveau now. Cheers, J?r?me