Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp336138yba; Wed, 8 May 2019 21:44:14 -0700 (PDT) X-Google-Smtp-Source: APXvYqwWklTCWHEtta/u/D7qSoDExiCKgZPomdelPuExryxGOyJQITabtG3DKtkbB3ahnI1qEHVa X-Received: by 2002:aa7:8c12:: with SMTP id c18mr2311992pfd.194.1557377054842; Wed, 08 May 2019 21:44:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557377054; cv=none; d=google.com; s=arc-20160816; b=GE6R71rRdHZXpfX9DSPbvCFyOHqQ+sPvZueDSNgogN5ToKlbdHY+Q2NGm+Z1FGX4sk 5ug0gfdxaJ3g1ucwxPWO5bSTncQQAlhbAssE0ArHRoxS9OYgJB9n1fI/H285vTJeDwPw ud0HQY0usO4k7KnVU6wKqzff5utnmYS1CVBjcDxwQjkTfXwT0aXtDeczZdc8pOuIObXU Gy9K7RgrKw93tlRElmPkgOcWnkqqwDtBSUBPcz27U0Fa2ft/jwkrdLpMb0LOuN/nnVXS Og9kSUFqXDZy6Qd0C8m192tIFLsupCdBNhPKLLDynHz6CtOjO2P01+zSz1z5zF0DhPze 5ggQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=e3NuoyA6DsdN8vS1rlRQd+bW+avLSVguOFGnQl9Uq1o=; b=ivmWdPM1SnsqbQXaFLLTb3Ume9/viLfqZRvhpR12ThQzQi96M/zgQhts8hOI4TRdsz WZkR/vKofpG68QLGRokBnM4P9gvfX/nSnHCCwT7RNSJ2oiK77D2y/MZjI9/PVJSLEemP lyZaXBMwXrzPU1aD9yjxyOXcW4TBZcEIMC59pVm6vvZmZ6PPwFRHeFWLJz6Rp5OWL3dk IKqUtIVO0o6HAdvaQbQrl5xEi81HbjzoI7D+AKC1/w7UtAw4qRyS+ubWg2TerGjb6O45 IBSiLttGLvMOqSMMJjdtQSDBfHATeLZ0FvfJEqSPjYTjc2UZkeWbH+hjdAJlDgOeMmd6 V9HQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="Lt/DTI5w"; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e192si1471741pgc.222.2019.05.08.21.43.57; Wed, 08 May 2019 21:44:14 -0700 (PDT) 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; dkim=pass header.i=@gmail.com header.s=20161025 header.b="Lt/DTI5w"; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726108AbfEIEnH (ORCPT + 99 others); Thu, 9 May 2019 00:43:07 -0400 Received: from mail-lj1-f195.google.com ([209.85.208.195]:34900 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725869AbfEIEnH (ORCPT ); Thu, 9 May 2019 00:43:07 -0400 Received: by mail-lj1-f195.google.com with SMTP id m20so823520lji.2 for ; Wed, 08 May 2019 21:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e3NuoyA6DsdN8vS1rlRQd+bW+avLSVguOFGnQl9Uq1o=; b=Lt/DTI5wNAIhQ/6m6siviyT/JhbAp3rvLyUD63xEOH2IAg2pMCbMTS5GVTmn+YjFEr pnlVWawZ4nlMIvBOt171hzqJoikbtkxHGB0/mAiy4+T0Rw2CoC2QP83rkkwOknkyTrVW IRuOvLBwGlgkRwVCBqoWuPwWjarfOB15lA5TfomCotP/1mkZgzE2vDNTJwjtVgAPyFrS MJpWxa//z66mbSVrM03P8D5yOr826PzQmL+znaT8rF9P0GSt8GxB25i3hV1aFx4c6bFG 01Sw6nLVbznCBMk4a/bLRUHhV8ZEFJoUM3gjiFpUeSDeboJ9cpOKY0J2miFZ1Gf+wdk2 AoeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e3NuoyA6DsdN8vS1rlRQd+bW+avLSVguOFGnQl9Uq1o=; b=VXzrC60QzQETd/xZa9afqlwZ/Q2Z13OduUxfHHA9frnxzzbahA9GY9M3QvZSlbvPsz Aewt9IyPBGzen1BJ6+urj+/bkUg0ubDDByiND+aY3+IYkR83U4g+y9nUjicHnM8O2gCN E6b28jE25O+ZR30oRjwEARbqDZQHJTcUcTDqesKLyEqsP9Co6kdyuDYheMZY/wt1KbLD kDGFixGiFAEIvjlOkCIDXRi0xUP5+Mmguc5fIKrFCDZHXtktnmEL4//JjNEsaJVfAWAJ TPNFXEqCxa+a5zHtJDVuUACu+zmRE/XmyrgUzpXGx3rDBF12I0ZZZSqaXaEhQOL0+CEa E5Kw== X-Gm-Message-State: APjAAAUyS4D0ll6z9qRM26mRPKBd92sEtFdu92rj7nhoJ/MR8gegwYXC FwY2m4R3kDIJjXuSZv6vNNcslEBjo90nPV+ftSo= X-Received: by 2002:a2e:7e0a:: with SMTP id z10mr855035ljc.9.1557376985164; Wed, 08 May 2019 21:43:05 -0700 (PDT) MIME-Version: 1.0 References: <20190506232942.12623-1-rcampbell@nvidia.com> <20190506232942.12623-5-rcampbell@nvidia.com> In-Reply-To: From: Souptick Joarder Date: Thu, 9 May 2019 10:12:52 +0530 Message-ID: Subject: Re: [PATCH 4/5] mm/hmm: hmm_vma_fault() doesn't always call hmm_range_unregister() To: Ralph Campbell Cc: Linux-MM , linux-kernel@vger.kernel.org, John Hubbard , Ira Weiny , Dan Williams , Arnd Bergmann , Balbir Singh , Dan Carpenter , Matthew Wilcox , Andrew Morton Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 7, 2019 at 11:42 PM Ralph Campbell wrote: > > > On 5/7/19 6:15 AM, Souptick Joarder wrote: > > On Tue, May 7, 2019 at 5:00 AM wrote: > >> > >> From: Ralph Campbell > >> > >> The helper function hmm_vma_fault() calls hmm_range_register() but is > >> missing a call to hmm_range_unregister() in one of the error paths. > >> This leads to a reference count leak and ultimately a memory leak on > >> struct hmm. > >> > >> Always call hmm_range_unregister() if hmm_range_register() succeeded. > > > > How about * Call hmm_range_unregister() in error path if > > hmm_range_register() succeeded* ? > > Sure, sounds good. > I'll include that in v2. Thanks. > > >> > >> Signed-off-by: Ralph Campbell > >> Cc: John Hubbard > >> Cc: Ira Weiny > >> Cc: Dan Williams > >> Cc: Arnd Bergmann > >> Cc: Balbir Singh > >> Cc: Dan Carpenter > >> Cc: Matthew Wilcox > >> Cc: Souptick Joarder > >> Cc: Andrew Morton > >> --- > >> include/linux/hmm.h | 3 ++- > >> 1 file changed, 2 insertions(+), 1 deletion(-) > >> > >> diff --git a/include/linux/hmm.h b/include/linux/hmm.h > >> index 35a429621e1e..fa0671d67269 100644 > >> --- a/include/linux/hmm.h > >> +++ b/include/linux/hmm.h > >> @@ -559,6 +559,7 @@ static inline int hmm_vma_fault(struct hmm_range *range, bool block) > >> return (int)ret; > >> > >> if (!hmm_range_wait_until_valid(range, HMM_RANGE_DEFAULT_TIMEOUT)) { > >> + hmm_range_unregister(range); > >> /* > >> * The mmap_sem was taken by driver we release it here and > >> * returns -EAGAIN which correspond to mmap_sem have been > >> @@ -570,13 +571,13 @@ static inline int hmm_vma_fault(struct hmm_range *range, bool block) > >> > >> ret = hmm_range_fault(range, block); > >> if (ret <= 0) { > >> + hmm_range_unregister(range); > > > > what is the reason to moved it up ? > > I moved it up because the normal calling pattern is: > down_read(&mm->mmap_sem) > hmm_vma_fault() > hmm_range_register() > hmm_range_fault() > hmm_range_unregister() > up_read(&mm->mmap_sem) > > I don't think it is a bug to unlock mmap_sem and then unregister, > it is just more consistent nesting. Ok. I think, adding it in change log will be helpful :) > > >> if (ret == -EBUSY || !ret) { > >> /* Same as above, drop mmap_sem to match old API. */ > >> up_read(&range->vma->vm_mm->mmap_sem); > >> ret = -EBUSY; > >> } else if (ret == -EAGAIN) > >> ret = -EBUSY; > >> - hmm_range_unregister(range); > >> return ret; > >> } > >> return 0; > >> -- > >> 2.20.1 > >>