From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34F53C636D4 for ; Mon, 13 Feb 2023 16:54:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 70DD36B0073; Mon, 13 Feb 2023 11:54:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6BE216B0074; Mon, 13 Feb 2023 11:54:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 585FB6B0075; Mon, 13 Feb 2023 11:54:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 493BA6B0073 for ; Mon, 13 Feb 2023 11:54:50 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 12A60160B33 for ; Mon, 13 Feb 2023 16:54:50 +0000 (UTC) X-FDA: 80462867940.09.667B925 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf10.hostedemail.com (Postfix) with ESMTP id 8C146C000E for ; Mon, 13 Feb 2023 16:54:46 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Zn7kNb+z; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf10.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676307287; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=m63A0UYMrPfeTx3fTqBjhgB5JqyruQ1Co1X3bBWcTX8=; b=Zs+eL/O3NfWG5ZFtSWnD45TAZPsji+5cEOF6ci5mZl8gi9355urqXSY6OEyviX0u5zpCF5 gkBELjVzG1GkSZ6h9nvw/l15xr16A0q6c37bPYvne2rjMBsZPtKVmb6+k/UYxzKNHBoob6 W6Nda7ple52pUV8DAw5GBo5K3TS6yGk= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Zn7kNb+z; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf10.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676307287; a=rsa-sha256; cv=none; b=cvyaaVDpzxopl/W4jTf6oSyvx+iiD4aspEO0C17R5bjiQUNSn4r41tXco12tVjr/5X4lGU Sf8hrHOT9gmUIx39E2a02Dm4HAz367+WnvI0IG7bI3mxHkJ7wK/I5fZT/Y9wCBA+30jFKX ZiMY29451JHJ2g69IBJV7PJCH/msI1c= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676307285; 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=m63A0UYMrPfeTx3fTqBjhgB5JqyruQ1Co1X3bBWcTX8=; b=Zn7kNb+zZeVzKpPcX4FMaMSzaQkRiW8LWOjQvCJeGeWBUwqcOuVD78t/2TTwuvjZMMjmab kjNhYUqzqPqPiM3krujI2Stgo7qp4aBuyN21OwJNt/6okinCZPal5+macvz4hv2AjHQekm VjLvNffBavahhhuwmLlnzJrqnpVUYjY= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-171-38-hBoQaNjCC_HR3taEyig-1; Mon, 13 Feb 2023 11:54:44 -0500 X-MC-Unique: 38-hBoQaNjCC_HR3taEyig-1 Received: by mail-qv1-f69.google.com with SMTP id pv24-20020ad45498000000b0056ea549d728so2617128qvb.10 for ; Mon, 13 Feb 2023 08:54:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1676307284; 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=m63A0UYMrPfeTx3fTqBjhgB5JqyruQ1Co1X3bBWcTX8=; b=NFHLLpIaOsLjgMkBIgYY88+goTqQfU7Edyj2/Pm2cFpk5TESoBtc2nkm/52A5UmQmu tG4Oy5Fw5Kz9qD33ItYHGpZeqCdOL7y4OSuZ0FaVnNoiMuEOVKuMX7JQ8/O1Ec5hwyMu 2F0HuTIfZR+YBSe7xUw527oOL9g2WBQiTf9K8ZpFpc/ClPR1NYJyh+WhSH4AabNnkLPH 0Luq+j19r53YesjrOYbIfzcnacK/cByXW3dTLpSv4BkjqRwF2QBDkWMDBVHXdfAe3arz fGEPU+88UOGMYT9qzOxgY1+KaHrnhvUZxhBHXwwMBiCf4zYJ+n8Ii7e3/d4pPZQhGvey fFQg== X-Gm-Message-State: AO0yUKUjgEcmzHdbGrsGs12nEmUjwIsXR5Ai++j68kxk9ZdcdRNK/mNP dfnJnjaTjo0lMJXPTcobvqus6I9nq54zajdNLqw7rO6vsAxKV1yvaCq+8j0acDOIOOZuJz2pV0e 08tbTDZ2drPA= X-Received: by 2002:a05:622a:1744:b0:3b8:5dfe:c3dc with SMTP id l4-20020a05622a174400b003b85dfec3dcmr51622280qtk.3.1676307283967; Mon, 13 Feb 2023 08:54:43 -0800 (PST) X-Google-Smtp-Source: AK7set/bZK0fGlLrzcqnZmqrkUdMTLY5whSyLkUFhgWouOol/Vo4g6Zjd7Y3hifjs/aebgHexEqazg== X-Received: by 2002:a05:622a:1744:b0:3b8:5dfe:c3dc with SMTP id l4-20020a05622a174400b003b85dfec3dcmr51622245qtk.3.1676307283683; Mon, 13 Feb 2023 08:54:43 -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 m127-20020a37bc85000000b00720750365b9sm10096783qkf.129.2023.02.13.08.54.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Feb 2023 08:54:43 -0800 (PST) Date: Mon, 13 Feb 2023 11:54:42 -0500 From: Peter Xu To: Muhammad Usama Anjum Cc: david@redhat.com, Andrew Morton , kernel@collabora.com, Paul Gofman , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/2] mm/userfaultfd: Support WP on multiple VMAs Message-ID: References: <20230213163124.2850816-1-usama.anjum@collabora.com> MIME-Version: 1.0 In-Reply-To: <20230213163124.2850816-1-usama.anjum@collabora.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 8C146C000E X-Stat-Signature: h3xcwkt88icd94iaikjp8198wt3ykjnb X-HE-Tag: 1676307286-16033 X-HE-Meta: U2FsdGVkX19zVaL1PeZEuZOkwbcsn7XFmsIo4N5FWULz//iuNFaj2O6AGGJdpDCXXCuqnxqH+e+yaTTH0N87IPpC/R0UGKQ5/F24YNb2/DseZSpAKTHbM4f/vDGZiK+74kbHLrjw11um3dKlCZi9UcwKF0sl8+4bgNyY7+kvRsNuErxSQVI/jD39ohrjvjQ0+IyDOjZNOofJl10Zhz71DPBLKyFSGcOPuCAMuweeOt5bXP/vCvzOx4+LoBdi9oDyGeliRKLWMEYpKu1/MrQ376AQiyTG+aOtpBN4Qx06vqDBGKBM9lLfamdcoaaQFieftL/MOHASLQaAnEhXAumeqlNQ6NRVP0YbwDry84KANlOeqSi1SgqQwoko39rdRYQ9W/Z68MRzKdwZKG+jfboNtK3Rqc3KJmRjDMQT9QjFEiNDiKU0tEeCwU82dZUd7lgrp1EA7wMJ5wEFPhEvC3Evz8y9LWxaRFSm+fFKHUMUoa32XQoYTUjKyO/ECkD7ysEC7+ZY8u1e4zNA5aKLx4BmTOJFKMDeK3bvL9F7Lx0oPiA74A97XEo6UJGzvvb6gfqBtPbkSxN/g3WlHJZ7d53ZFxY9i5118VcuK1DjSteYTpHPheGHFgWRpW3zF8X99FXJvmwBKvwpCfOVcNgRJWgD8rPJKCZKG7Ov1HMk85CsIdTSkvuYy3meLNubadY/iCzGRRDPAbQt5R+CMnOjXHXYo1CekEyVf+XZBJahR+6truzvWAJiouRS4JIrQ3tOkzIQDMwUxb4fi1ngh4HjGhCOTlRJHFJ7YSQLkyX2VLOspA2bPrqGFzZSSSEh5ZwVL6aUh1osJGfRngGzQFvJ59p/H/XkT6Qj733df35cgbBpItJ9qT4n9RPj+CfCq+QCKxDDcLORCMAs0zdtAyGYLDCp6S2FpvEhffc15ppl2gMsjJ1fd2JzNvJ431JSmmA3h4yiCntEd8bWUpTMsAnWcfC E5rM5/Lo xSXplcLsxcaWY/zHR6Vg8Oove7+vQFcLyzPReNsfAKy50ZkSAHA5H0nrZHTq4Ugv/MpN+gaEiMGSr4UZ0fORKwzE/923dJV9nGNT3ue4JEDkvcVfXJF/lj0kDtTrGXOCqNRE/UWa7QNo1iRf14olmBvX0+p01F2Fkba2xTuw9vLXghZHVnPMmmxfLTrTnWklnIoW8PPN5S7jc95u9qXsC52qnDFMWqHmTpi1mhpUQrmvMRsMhwwK3+MZ0JEQ8yt26+aVkiEOMnx/kSkcsW0CEZrwfPdb+CJdO0x8FYdjFZtbn86u8e8aYm1/YX551jVskX9dV52zdQ+UXTIMeEbLXc+KQMPk/lIwqDMGZq+t3NMZuxgTldkK3eAAWJwuWiT7yObRW0/t291nP2nnCDhwqg5dF1bXZnQDl3osJaYN/9Fp9UPTdtDmqcGempap1EpSIABiQRBitNvLjCrEe54kWq30GgeXpXZcCz1gwdtx/SCHg+1i2ZwkyrzPvpg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Feb 13, 2023 at 09:31:23PM +0500, Muhammad Usama Anjum wrote: > mwriteprotect_range() errors out if [start, end) doesn't fall in one > VMA. We are facing a use case where multiple VMAs are present in one > range of interest. For example, the following pseudocode reproduces the > error which we are trying to fix: > > - Allocate memory of size 16 pages with PROT_NONE with mmap > - Register userfaultfd > - Change protection of the first half (1 to 8 pages) of memory to > PROT_READ | PROT_WRITE. This breaks the memory area in two VMAs. > - Now UFFDIO_WRITEPROTECT_MODE_WP on the whole memory of 16 pages errors > out. > > This is a simple use case where user may or may not know if the memory > area has been divided into multiple VMAs. > > Reported-by: Paul Gofman > Signed-off-by: Muhammad Usama Anjum > --- > Changes since v1: > - Correct the start and ending values passed to uffd_wp_range() > --- > mm/userfaultfd.c | 38 ++++++++++++++++++++++---------------- > 1 file changed, 22 insertions(+), 16 deletions(-) > > diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c > index 65ad172add27..bccea08005a8 100644 > --- a/mm/userfaultfd.c > +++ b/mm/userfaultfd.c > @@ -738,9 +738,12 @@ int mwriteprotect_range(struct mm_struct *dst_mm, unsigned long start, > unsigned long len, bool enable_wp, > atomic_t *mmap_changing) > { > + unsigned long end = start + len; > + unsigned long _start, _end; > struct vm_area_struct *dst_vma; > unsigned long page_mask; > int err; I think this needs to be initialized or it can return anything when range not mapped. > + VMA_ITERATOR(vmi, dst_mm, start); > > /* > * Sanitize the command parameters: > @@ -762,26 +765,29 @@ int mwriteprotect_range(struct mm_struct *dst_mm, unsigned long start, > if (mmap_changing && atomic_read(mmap_changing)) > goto out_unlock; > > - err = -ENOENT; > - dst_vma = find_dst_vma(dst_mm, start, len); > + for_each_vma_range(vmi, dst_vma, end) { > + err = -ENOENT; > > - if (!dst_vma) > - goto out_unlock; > - if (!userfaultfd_wp(dst_vma)) > - goto out_unlock; > - if (!vma_can_userfault(dst_vma, dst_vma->vm_flags)) > - goto out_unlock; > + if (!dst_vma->vm_userfaultfd_ctx.ctx) > + break; > + if (!userfaultfd_wp(dst_vma)) > + break; > + if (!vma_can_userfault(dst_vma, dst_vma->vm_flags)) > + break; > > - if (is_vm_hugetlb_page(dst_vma)) { > - err = -EINVAL; > - page_mask = vma_kernel_pagesize(dst_vma) - 1; > - if ((start & page_mask) || (len & page_mask)) > - goto out_unlock; > - } > + if (is_vm_hugetlb_page(dst_vma)) { > + err = -EINVAL; > + page_mask = vma_kernel_pagesize(dst_vma) - 1; > + if ((start & page_mask) || (len & page_mask)) > + break; > + } > > - uffd_wp_range(dst_mm, dst_vma, start, len, enable_wp); > + _start = (dst_vma->vm_start > start) ? dst_vma->vm_start : start; > + _end = (dst_vma->vm_end < end) ? dst_vma->vm_end : end; > > - err = 0; > + uffd_wp_range(dst_mm, dst_vma, _start, _end - _start, enable_wp); > + err = 0; > + } > out_unlock: > mmap_read_unlock(dst_mm); > return err; This whole patch also changes the abi, so I'm worried whether there can be app that relies on the existing behavior. Is this for the new pagemap effort? Can this just be done in the new interface rather than changing the old? Side note: in your other pagemap series, you can optimize "WP_ENGAGE && !GET" to not do generic pgtable walk at all, but use what it does in this patch for the initial round or wr-protect. Thanks, -- Peter Xu