Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp100727rwb; Wed, 18 Jan 2023 14:48:27 -0800 (PST) X-Google-Smtp-Source: AMrXdXtk6dJd1vFefGU3s/a+DvYGS3IGLbHtEBMp/Bdjw5pWuwqmzeWXcLzfngExXRWHeTH4aHvm X-Received: by 2002:a17:906:d0c8:b0:7c1:10b8:e6a4 with SMTP id bq8-20020a170906d0c800b007c110b8e6a4mr8682609ejb.19.1674082106847; Wed, 18 Jan 2023 14:48:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674082106; cv=none; d=google.com; s=arc-20160816; b=No9orF9hHiZV/Tcvpbb20Sh/ZybV0khcSQueqa+DzRvH4Z0RazCjoQhX4STdyskPku z7/mYDidenlHLaoAoXbQshBfBnWKercHuMhBzdxqrSu2CDLR8sNht34iixIRA9ac3V/w Fd/fpefoq9nrXHKJnHo35+lSzHQFXrWha7JimS7VWA0drnlbh3L/1rTHtEoMYgbOKBda zhFWv9ZhSR5zd16pJ6MYO3BSpoRnTdU71rPIuNGv9ogkYynfo4WXnq5eJN57VFtaFpJL KXhT05IjeshuIb1Mh/V4BGicse0s8MGeqfq4Px1AyYze0S7BKy83eNN0d3+X9TToMWVf vs5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=xZdbxU7U6Cq2n8pjRxmWipD5AezhqaGVZdCMLeOSIq0=; b=TFYVCzcTwGw12bNBfTYS3JJY6+7hiLNkEEKzD3hTmSLY5Owz+d9oVIppLGp4rOBjBc GDZSvF3VU0yD2dMm/B/oy6jBxzXJCF0pTecc5pMtRq//7bG+QMNJw9zPtvNgJBXBfDzB Hc3KAQy5dNs4Y16btX6gBbcSSaVVSM1NdF9F6+l6bIAe1vNuSDM600A4HXPbalj5zT+0 H14hGKXSRZyd2ySx6g5TeeC6t4fyvVvCMgQDeFTrXde2Ic1WbL6zk99dL57cRlFBjxTY PT5DqHVYqec/bpxmKrSXVjH6I6zZzN8OVE0Vl0SvTngVXudCzCTHPFZXdxmI82mL73gc 1Fmw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=EKO8XnNL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id be5-20020a1709070a4500b0084cb7291b22si37658038ejc.847.2023.01.18.14.48.15; Wed, 18 Jan 2023 14:48:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=EKO8XnNL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229748AbjARWac (ORCPT + 44 others); Wed, 18 Jan 2023 17:30:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37458 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230282AbjARW3o (ORCPT ); Wed, 18 Jan 2023 17:29:44 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2119648588 for ; Wed, 18 Jan 2023 14:29:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1674080944; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xZdbxU7U6Cq2n8pjRxmWipD5AezhqaGVZdCMLeOSIq0=; b=EKO8XnNLP5SlzcIaqKJIGPNeVqvJgf6ZlIolszKjQ88PzDQX57LicmYXoqEi/34WQE8ab7 B3F7Xl4MmJzoXhs0cAeJ402aXn8bItZebH3JOdCtCdVOkjMQI4E2nBPupApw4+drxFQptB +IeGmvpBn8l4MCo5/Ou4vvKfoFV1CoY= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-518-OxO37VCWMwq3KyzrKjjR-g-1; Wed, 18 Jan 2023 17:29:03 -0500 X-MC-Unique: OxO37VCWMwq3KyzrKjjR-g-1 Received: by mail-qk1-f197.google.com with SMTP id bl3-20020a05620a1a8300b0070240ff36a0so302858qkb.19 for ; Wed, 18 Jan 2023 14:29:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=xZdbxU7U6Cq2n8pjRxmWipD5AezhqaGVZdCMLeOSIq0=; b=hH3O3JGFCsS7V/b1u0lkGXVdI7/fiQCCmtpdM8GzGtTxiAP2Xibsqvja+N52BSlNze cbKmOcjn07DZEKzLsnntlulkPowBAWhuDs1qM+qwhTunILobz+RntjLClt0GxgrUM2ir HY2bEr0bs9vsFRI8S/o8CB8AT8eKY0KW0fHtz8s9R6TOx0WoTYjB1UFmYgTNDE96vKDL Jte7Fsk1IjjoptexOlNNsdUVabZ/1v/95oZYDTOWO2eSZ4CKRJuyJVgcLRNh0riFWpof UGvf1IojTUNA7TKtxfPi0sQN2lR+zxG0x4O/2l/9hXwd4/EskPkkDYQBKIg4yC5kNuPJ XnQA== X-Gm-Message-State: AFqh2krNA4Mr/yicf14+nKDbR6TbLuNMJ2WppgiVd2OPBKM+8BXkRM0i FGcchBFxkghNMKr7/gcsRWrDfpbBc7U2fbn+uzp1YF8Olt7CjqWvWw+1qtnnYgBAaPWkM7h2UQC f40WFqxZDcutdTuqVolq92kax X-Received: by 2002:a05:622a:6027:b0:3a5:264c:5f38 with SMTP id he39-20020a05622a602700b003a5264c5f38mr41792371qtb.63.1674080942321; Wed, 18 Jan 2023 14:29:02 -0800 (PST) X-Received: by 2002:a05:622a:6027:b0:3a5:264c:5f38 with SMTP id he39-20020a05622a602700b003a5264c5f38mr41792335qtb.63.1674080941983; Wed, 18 Jan 2023 14:29:01 -0800 (PST) Received: from x1n (bras-base-aurron9127w-grc-56-70-30-145-63.dsl.bell.ca. [70.30.145.63]) by smtp.gmail.com with ESMTPSA id j9-20020ac806c9000000b003ab5d6cd6c5sm18027439qth.16.2023.01.18.14.28.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Jan 2023 14:29:01 -0800 (PST) Date: Wed, 18 Jan 2023 17:28:58 -0500 From: Peter Xu To: Muhammad Usama Anjum Cc: David Hildenbrand , Andrew Morton , =?utf-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= , Andrei Vagin , Danylo Mocherniuk , Paul Gofman , Cyrill Gorcunov , Alexander Viro , Shuah Khan , Christian Brauner , Yang Shi , Vlastimil Babka , "Liam R . Howlett" , Yun Zhou , Suren Baghdasaryan , Alex Sierra , Matthew Wilcox , Pasha Tatashin , Mike Rapoport , Nadav Amit , Axel Rasmussen , "Gustavo A . R . Silva" , Dan Williams , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, Greg KH , kernel@collabora.com Subject: Re: [PATCH v7 3/4] fs/proc/task_mmu: Implement IOCTL to get and/or the clear info about PTEs Message-ID: References: <20230109064519.3555250-1-usama.anjum@collabora.com> <20230109064519.3555250-4-usama.anjum@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20230109064519.3555250-4-usama.anjum@collabora.com> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 09, 2023 at 11:45:18AM +0500, Muhammad Usama Anjum wrote: > This IOCTL, PAGEMAP_SCAN on pagemap file can be used to get and/or clear > the info about page table entries. The following operations are supported > in this ioctl: > - Get the information if the pages have been written-to (PAGE_IS_Wt), > file mapped (PAGE_IS_FILE), present (PAGE_IS_PRESENT) or swapped > (PAGE_IS_SWAPPED). > - Write-protect the pages (PAGEMAP_WP_ENGAGE) to start finding which > pages have been written-to. > - Find pages which have been written-to and write protect the pages > (atomic PAGE_IS_NOT_WP + PAGEMAP_WP_ENGAGE) > > The uffd should have been registered on the memory range before performing > any WP/WT (Write Protect/Writtern-To) related operations with the IOCTL. > > struct pagemap_scan_args is used as the argument of the IOCTL. In this > struct: > - The range is specified through start and len. > - The output buffer and size is specified as vec and vec_len. > - The optional maximum requested pages are specified in the max_pages. > - The flags can be specified in the flags field. The PAGEMAP_WP_ENGAGE > is the only added flag at this time. > - The masks are specified in required_mask, anyof_mask, excluded_ mask > and return_mask. > > This IOCTL can be extended to get information about more PTE bits. This > patch has evolved from a basic patch from Gabriel Krisman Bertazi. > > Signed-off-by: Muhammad Usama Anjum > --- > Changes in v7: > - Rebase on top of latest next > - Fix some corner cases > - Base soft-dirty on the uffd wp async > - Update the terminologies > - Optimize the memory usage inside the ioctl > > Changes in v6: > - Rename variables and update comments > - Make IOCTL independent of soft_dirty config > - Change masks and bitmap type to _u64 > - Improve code quality > > Changes in v5: > - Remove tlb flushing even for clear operation > > Changes in v4: > - Update the interface and implementation > > Changes in v3: > - Tighten the user-kernel interface by using explicit types and add more > error checking > > Changes in v2: > - Convert the interface from syscall to ioctl > - Remove pidfd support as it doesn't make sense in ioctl > --- > fs/proc/task_mmu.c | 300 ++++++++++++++++++++++++++++++++++ > include/uapi/linux/fs.h | 50 ++++++ > tools/include/uapi/linux/fs.h | 50 ++++++ > 3 files changed, 400 insertions(+) > > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c > index e35a0398db63..ba70faadf403 100644 > --- a/fs/proc/task_mmu.c > +++ b/fs/proc/task_mmu.c > @@ -19,6 +19,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -1135,6 +1136,22 @@ static inline void clear_soft_dirty(struct vm_area_struct *vma, > } > #endif > > +static inline bool is_pte_uffd_wp(pte_t pte) > +{ > + if ((pte_present(pte) && pte_uffd_wp(pte)) || > + (is_swap_pte(pte) && pte_swp_uffd_wp(pte))) > + return true; This is an interesting way to detect whether the page is written.. I would have thought you would reuse soft-dirty bit. For swap case, you missed the pte markers (which can exist for !anon memory). You can have a look at pte_swp_uffd_wp_any(). > + return false; > +} > + > +static inline bool is_pmd_uffd_wp(pmd_t pmd) > +{ > + if ((pmd_present(pmd) && pmd_uffd_wp(pmd)) || > + (is_swap_pmd(pmd) && pmd_swp_uffd_wp(pmd))) > + return true; > + return false; > +} > + > #if defined(CONFIG_MEM_SOFT_DIRTY) && defined(CONFIG_TRANSPARENT_HUGEPAGE) > static inline void clear_soft_dirty_pmd(struct vm_area_struct *vma, > unsigned long addr, pmd_t *pmdp) > @@ -1763,11 +1780,294 @@ static int pagemap_release(struct inode *inode, struct file *file) > return 0; > } > > +#define PAGEMAP_OP_MASK (PAGE_IS_WT | PAGE_IS_FILE | \ > + PAGE_IS_PRESENT | PAGE_IS_SWAPPED) > +#define PAGEMAP_NONWT_OP_MASK (PAGE_IS_FILE | PAGE_IS_PRESENT | PAGE_IS_SWAPPED) > +#define IS_WP_ENGAGE_OP(a) (a->flags & PAGEMAP_WP_ENGAGE) > +#define IS_GET_OP(a) (a->vec) > +#define PAGEMAP_SCAN_BITMAP(wt, file, present, swap) \ > + (wt | file << 1 | present << 2 | swap << 3) > +#define IS_WT_REQUIRED(a) \ > + ((a->required_mask & PAGE_IS_WT) || \ > + (a->anyof_mask & PAGE_IS_WT)) > + > +struct pagemap_scan_private { > + struct page_region *vec; > + struct page_region prev; > + unsigned long vec_len, vec_index; > + unsigned int max_pages, found_pages, flags; > + unsigned long required_mask, anyof_mask, excluded_mask, return_mask; > +}; > + > +static int pagemap_scan_test_walk(unsigned long start, unsigned long end, struct mm_walk *walk) > +{ > + struct pagemap_scan_private *p = walk->private; > + struct vm_area_struct *vma = walk->vma; > + > + if (IS_WT_REQUIRED(p) && !vma_can_userfault(vma, vma->vm_flags)) > + return -EPERM; vma_can_userfault() is too coarse. Maybe what you wanted to check is userfaultfd_wp(vma)? > + if (IS_GET_OP(p) && p->max_pages && (p->found_pages == p->max_pages)) > + return -ENOSPC; This is the function to test "whether the walker should walk the vma specified". This check should IIUC be meaningless because found_pages doesn't boost during vma switching, while OTOH your pmd walker fn should do proper check when increasing found_pages and return -ENOSPC properly when the same condition met. That should be enough, IMHO. I saw it already a few times in this patch, I think maybe you want a helper for this one taking *p as argument. > + if (vma->vm_flags & VM_PFNMAP) > + return 1; > + return 0; > +} > + > +static inline int add_to_out(bool wt, bool file, bool pres, bool swap, > + struct pagemap_scan_private *p, unsigned long addr, unsigned int len) > +{ > + unsigned long bitmap, cur = PAGEMAP_SCAN_BITMAP(wt, file, pres, swap); > + bool cpy = true; > + struct page_region *prev = &p->prev; > + > + if (p->required_mask) > + cpy = ((p->required_mask & cur) == p->required_mask); > + if (cpy && p->anyof_mask) > + cpy = (p->anyof_mask & cur); > + if (cpy && p->excluded_mask) > + cpy = !(p->excluded_mask & cur); > + bitmap = cur & p->return_mask; > + if (cpy && bitmap) { > + if ((prev->len) && (prev->bitmap == bitmap) && > + (prev->start + prev->len * PAGE_SIZE == addr)) { > + prev->len += len; > + p->found_pages += len; > + } else if (p->vec_index < p->vec_len) { > + if (prev->len) { > + memcpy(&p->vec[p->vec_index], prev, sizeof(struct page_region)); > + p->vec_index++; > + } > + prev->start = addr; > + prev->len = len; > + prev->bitmap = bitmap; > + p->found_pages += len; > + } else { > + return -ENOSPC; > + } [1] > + } > + return 0; > +} > + > +static inline int export_prev_to_out(struct pagemap_scan_private *p, struct page_region __user *vec, > + unsigned long *vec_index) > +{ > + struct page_region *prev = &p->prev; > + > + if (prev->len) { > + if (copy_to_user(&vec[*vec_index], prev, sizeof(struct page_region))) > + return -EFAULT; > + p->vec_index++; > + (*vec_index)++; > + prev->len = 0; > + } > + return 0; > +} I'd rather not have this helper; it doesn't really help a lot. > + > +static inline int pagemap_scan_pmd_entry(pmd_t *pmd, unsigned long addr, > + unsigned long end, struct mm_walk *walk) > +{ > + struct pagemap_scan_private *p = walk->private; > + struct vm_area_struct *vma = walk->vma; > + unsigned long start = addr; > + unsigned int len; > + spinlock_t *ptl; > + int ret = 0; > + pte_t *pte; > + bool pmd_wt; > + > + if ((walk->vma->vm_end < addr) || (p->max_pages && p->found_pages == p->max_pages)) > + return 0; > + end = min(end, walk->vma->vm_end); None of the check above is needed, I think.. vma ranges are checked before pmd_entry() called. found_pages should be checked when increased (I think it's [1] above). > + > +#ifdef CONFIG_TRANSPARENT_HUGEPAGE > + ptl = pmd_trans_huge_lock(pmd, vma); > + if (ptl) { > + pmd_wt = !is_pmd_uffd_wp(*pmd); > + /* > + * Break huge page into small pages if operation needs to be performed is > + * on a portion of the huge page or the return buffer cannot store complete > + * data. > + */ > + if (pmd_wt && (IS_WP_ENGAGE_OP(p) && (end - addr < HPAGE_SIZE))) { > + spin_unlock(ptl); > + split_huge_pmd(vma, pmd, addr); > + goto process_smaller_pages; > + } > + if (IS_GET_OP(p)) { > + len = (end - addr)/PAGE_SIZE; > + if (p->max_pages && p->found_pages + len > p->max_pages) > + len = p->max_pages - p->found_pages; > + > + ret = add_to_out(pmd_wt, vma->vm_file, pmd_present(*pmd), > + is_swap_pmd(*pmd), p, addr, len); > + if (ret) { > + spin_unlock(ptl); > + return ret; > + } > + } > + spin_unlock(ptl); > + if (IS_WP_ENGAGE_OP(p) && pmd_wt) { > + BUG_ON(start & ~HPAGE_MASK); > + > + ret = wp_range_async(vma, addr, HPAGE_SIZE); > + } > + return ret; > + } > +process_smaller_pages: > + if (pmd_trans_unstable(pmd)) > + return 0; > +#endif /* CONFIG_TRANSPARENT_HUGEPAGE */ > + > + pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl); > + for (; addr < end && !ret && (!p->max_pages || (p->found_pages < p->max_pages)) > + ; pte++, addr += PAGE_SIZE) { > + if (IS_GET_OP(p)) { This 'if' should be out - skip loop if not needed. > + ret = add_to_out(!is_pte_uffd_wp(*pte), vma->vm_file, pte_present(*pte), > + is_swap_pte(*pte), p, addr, 1); > + if (ret) > + break; > + } > + } > + pte_unmap_unlock(pte - 1, ptl); > + if (IS_WP_ENGAGE_OP(p)) { > + BUG_ON(start & ~PAGE_MASK); > + ret = wp_range_async(vma, start, addr - start); > + } > + > + cond_resched(); > + return ret; > +} > + > +static int pagemap_scan_pte_hole(unsigned long addr, unsigned long end, int depth, > + struct mm_walk *walk) > +{ > + struct pagemap_scan_private *p = walk->private; > + struct vm_area_struct *vma = walk->vma; > + unsigned int len; > + int ret = 0; > + > + if (vma) { > + len = (end - addr)/PAGE_SIZE; > + if (p->max_pages && p->found_pages + len > p->max_pages) > + len = p->max_pages - p->found_pages; > + ret = add_to_out(false, vma->vm_file, false, false, p, addr, len); > + } > + > + return ret; > +} > + > +static const struct mm_walk_ops pagemap_scan_ops = { > + .test_walk = pagemap_scan_test_walk, > + .pmd_entry = pagemap_scan_pmd_entry, Do we care about hugetlb at all? So far it seems you don't. It's fine, then if you decided to go the uffd-wp way you can explicit declare no support on hugetlb, as uffd-wp sync supports it so it should be by default supported otherwise. > + .pte_hole = pagemap_scan_pte_hole, > +}; -- Peter Xu