Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp898955ybl; Fri, 9 Aug 2019 16:00:19 -0700 (PDT) X-Google-Smtp-Source: APXvYqzxY3LzsOM2L7oAxDhU+ZlyHYn5Iw3ZigSURFE6CpyVisZoa+pvuP47748qqvOyf0sc9yvs X-Received: by 2002:a17:90a:2244:: with SMTP id c62mr12004469pje.29.1565391619455; Fri, 09 Aug 2019 16:00:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565391619; cv=none; d=google.com; s=arc-20160816; b=0HrIacf7cpiMIwkRqMJcn3WOfn7cb/mg1CeEFErtrrSxZteDB4uYmR+aV9Er5klUD+ auSBd+j5M+nev/5AKFa/ptDZ/33hOKKhsxEE/fgOxRTrN1Wy38iril1mmcrYIk2riLHK ZaWOy94jIWrCSYC1qavkcBSRNVEaTZssz6UTHdH2/pfZsI1TSOvCSHY15aLtuceRNauc uXRuxzqSpOffaTEfkgZQeEeNdN1isTsBS6VGytfU8mRm0Y5m+XDCoTOUgwPcrxMUoIhl 51W+3DVSkUySjJCzf1AFebOyGM3aTp1+ppyAxo0ZFNf0RD+3Yvi0qPGjOWMrc5yQFkBX eKLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=YBf7bCSsZFTvPoM1NYxMaQl2NfTT88MOelJjIEo0m6Y=; b=Dl7UTba3H9FhJmH8I51QxNYFqJw6em2bjI48QjEe5W6F13tVnVWLS2rGrXPBb6rVvT cS8ceyooxNtmWeGZ0hRTW0E000qWHjXBIj5e6UT91nfgS6tFSbf08woNviJsAoy9/hCJ j6Ygj9WzBXLUKrfLxDUDMFn8lO3Xzld9sfyrZu5D26egj/NwVrnJfnSQBTV8ah9moRyX vuw1KM7U4lwAe+QqXkuOsPYLWGskxlyjV0VgH3nBr9Tt77Ry702LtHTMkpqjjaPl4wf1 GuFPYuSBhtHQpoCMNBMKxR3uoFXvyQc2aGAj+LPs1zCQ6XveryuA2BmX5jWdxwxa1ZUN MLWw== 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v12si20710255pgl.102.2019.08.09.16.00.03; Fri, 09 Aug 2019 16:00:19 -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; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726890AbfHIW7P (ORCPT + 99 others); Fri, 9 Aug 2019 18:59:15 -0400 Received: from mga11.intel.com ([192.55.52.93]:23377 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730647AbfHIW7F (ORCPT ); Fri, 9 Aug 2019 18:59:05 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Aug 2019 15:59:05 -0700 X-IronPort-AV: E=Sophos;i="5.64,367,1559545200"; d="scan'208";a="176932450" Received: from iweiny-desk2.sc.intel.com (HELO localhost) ([10.3.52.157]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Aug 2019 15:59:04 -0700 From: ira.weiny@intel.com To: Andrew Morton Cc: Jason Gunthorpe , Dan Williams , Matthew Wilcox , Jan Kara , "Theodore Ts'o" , John Hubbard , Michal Hocko , Dave Chinner , linux-xfs@vger.kernel.org, linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nvdimm@lists.01.org, linux-ext4@vger.kernel.org, linux-mm@kvack.org, Ira Weiny Subject: [RFC PATCH v2 15/19] mm/gup: Introduce vaddr_pin_pages() Date: Fri, 9 Aug 2019 15:58:29 -0700 Message-Id: <20190809225833.6657-16-ira.weiny@intel.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190809225833.6657-1-ira.weiny@intel.com> References: <20190809225833.6657-1-ira.weiny@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Ira Weiny The addition of FOLL_LONGTERM has taken on additional meaning for CMA pages. In addition subsystems such as RDMA require new information to be passed to the GUP interface to track file owning information. As such a simple FOLL_LONGTERM flag is no longer sufficient for these users to pin pages. Introduce a new GUP like call which takes the newly introduced vaddr_pin information. Failure to pass the vaddr_pin object back to a vaddr_put* call will result in a failure if pins were created on files during the pin operation. Signed-off-by: Ira Weiny --- Changes from list: Change to vaddr_put_pages_dirty_lock Change to vaddr_unpin_pages_dirty_lock include/linux/mm.h | 5 ++++ mm/gup.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 64 insertions(+) diff --git a/include/linux/mm.h b/include/linux/mm.h index 657c947bda49..90c5802866df 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -1603,6 +1603,11 @@ int account_locked_vm(struct mm_struct *mm, unsigned long pages, bool inc); int __account_locked_vm(struct mm_struct *mm, unsigned long pages, bool inc, struct task_struct *task, bool bypass_rlim); +long vaddr_pin_pages(unsigned long addr, unsigned long nr_pages, + unsigned int gup_flags, struct page **pages, + struct vaddr_pin *vaddr_pin); +void vaddr_unpin_pages_dirty_lock(struct page **pages, unsigned long nr_pages, + struct vaddr_pin *vaddr_pin, bool make_dirty); bool mapping_inode_has_layout(struct vaddr_pin *vaddr_pin, struct page *page); /* Container for pinned pfns / pages */ diff --git a/mm/gup.c b/mm/gup.c index eeaa0ddd08a6..6d23f70d7847 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -2536,3 +2536,62 @@ int get_user_pages_fast(unsigned long start, int nr_pages, return ret; } EXPORT_SYMBOL_GPL(get_user_pages_fast); + +/** + * vaddr_pin_pages pin pages by virtual address and return the pages to the + * user. + * + * @addr, start address + * @nr_pages, number of pages to pin + * @gup_flags, flags to use for the pin + * @pages, array of pages returned + * @vaddr_pin, initalized meta information this pin is to be associated + * with. + * + * NOTE regarding vaddr_pin: + * + * Some callers can share pins via file descriptors to other processes. + * Callers such as this should use the f_owner field of vaddr_pin to indicate + * the file the fd points to. All other callers should use the mm this pin is + * being made against. Usually "current->mm". + * + * Expects mmap_sem to be read locked. + */ +long vaddr_pin_pages(unsigned long addr, unsigned long nr_pages, + unsigned int gup_flags, struct page **pages, + struct vaddr_pin *vaddr_pin) +{ + long ret; + + gup_flags |= FOLL_LONGTERM; + + if (!vaddr_pin || (!vaddr_pin->mm && !vaddr_pin->f_owner)) + return -EINVAL; + + ret = __gup_longterm_locked(current, + vaddr_pin->mm, + addr, nr_pages, + pages, NULL, gup_flags, + vaddr_pin); + return ret; +} +EXPORT_SYMBOL(vaddr_pin_pages); + +/** + * vaddr_unpin_pages_dirty_lock - counterpart to vaddr_pin_pages + * + * @pages, array of pages returned + * @nr_pages, number of pages in pages + * @vaddr_pin, same information passed to vaddr_pin_pages + * @make_dirty: whether to mark the pages dirty + * + * The semantics are similar to put_user_pages_dirty_lock but a vaddr_pin used + * in vaddr_pin_pages should be passed back into this call for propper + * tracking. + */ +void vaddr_unpin_pages_dirty_lock(struct page **pages, unsigned long nr_pages, + struct vaddr_pin *vaddr_pin, bool make_dirty) +{ + __put_user_pages_dirty_lock(vaddr_pin, pages, nr_pages, make_dirty); +} +EXPORT_SYMBOL(vaddr_unpin_pages_dirty_lock); -- 2.20.1