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 782A2C7EE39 for ; Thu, 2 Mar 2023 09:37:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E0F576B0071; Thu, 2 Mar 2023 04:37:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D989E6B0073; Thu, 2 Mar 2023 04:37:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C13406B0074; Thu, 2 Mar 2023 04:37:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B009D6B0071 for ; Thu, 2 Mar 2023 04:37:51 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 8477DA07B9 for ; Thu, 2 Mar 2023 09:37:51 +0000 (UTC) X-FDA: 80523456342.04.92B3BBF Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf16.hostedemail.com (Postfix) with ESMTP id 47A3D180004 for ; Thu, 2 Mar 2023 09:37:49 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=bCE1lrMZ; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf16.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677749869; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=xCyIOQlAHowOBFpFZNERppk5qbkMBHYYddRv3uQrzRM=; b=m47T9k5vS632+hG5CQVYClpKHt63xeTmkaRnyI7OiMuRZqJFa3Ap7LVu5XCgbvpW7hcKwe gvLJNmIMrIMqI0GVYm7FL6/3Kg49dq+vFDU+SIIknW+Rr88g/kscDtb2Kt8oP9dU55xoau 8RRZVqDCKbBuigmwNaiFYpgQfGIlv74= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=bCE1lrMZ; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf16.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677749869; a=rsa-sha256; cv=none; b=iCjMQbwcKZg5LtYbGiXpXhaO4VFQvYhAPI6HbFuhFTO2B+KYhXBWcp028L35/5XUymJDae CC/tW3xGDwxBwevNUQRxAIWFskGH9MuuUT7yNmI63lrqDRYv4JDAQy7nRypqTQPT7Fg0fP TWX1ZPtYe1ca86Ip49CshzQLvH9Bjg8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677749868; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xCyIOQlAHowOBFpFZNERppk5qbkMBHYYddRv3uQrzRM=; b=bCE1lrMZdTHVG1bELtpZFIKPiAZYYQpZbY+6aXUnnqWpO349zS3fI3/6cAnSTTWuBEjV5q kaK3eNkB4DZRLzDbaIqICGixHrN7C1Lsny2yiqYe0SPI9z4e9tVdzAeYHZ7EMGQBTM+jCk N+sEnla4Uvls2+Vc0ieH10S6ZEWdjYY= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-440-YptImJqhMBehVIJBuYLe_Q-1; Thu, 02 Mar 2023 04:37:47 -0500 X-MC-Unique: YptImJqhMBehVIJBuYLe_Q-1 Received: by mail-wm1-f72.google.com with SMTP id x18-20020a1c7c12000000b003e1e7d3cf9fso1015191wmc.3 for ; Thu, 02 Mar 2023 01:37:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xCyIOQlAHowOBFpFZNERppk5qbkMBHYYddRv3uQrzRM=; b=FYwo9pugy220yfUkMaK5Z/di9ezvdxtVYs6Zttts8oiepAfLvI2xt9o8BkJnqjXNgg F6awDdlSqATkIb7qKWp9Ze282okUk0DPgpjlY4jN1LaZuZjMxRmkSaQbqaJ7vU3efb/1 6CKT9/bOYnM7t+tfVg+7mO8rZb6pYwbNofPcpe+hocDKj3d/KIrXc1+4kug9TF5a4nI1 eJV0okCdNVc6lF3EtCbVCVHgdxTrMgYMVW2aZ3a0zSWz+nufgq7yU3qMw2tKdPMbic5f 2YYuek5tis9Jhb0CZWHzgtIHQvy6UyvUraKlJRAMtmgdrTWMBv/EeMHfQcNaYOxDOSrk 7+tQ== X-Gm-Message-State: AO0yUKWxESFOddl4Zjv03Q8bSPSVBPiWKqTdfcQriWwx5ivpsVhUpWre YBKmMBBg1Yj1C4rh1llQLYdLjjqn1G9vPMrrAyR7++4lKsqcyDN0EpRJJRPjqAsId81OofyRE87 Doljh/EeirIQ= X-Received: by 2002:a05:600c:4a9f:b0:3eb:3908:8541 with SMTP id b31-20020a05600c4a9f00b003eb39088541mr6751778wmp.2.1677749865950; Thu, 02 Mar 2023 01:37:45 -0800 (PST) X-Google-Smtp-Source: AK7set+yT0q8Eak3+0dGOMRr28r+W5fBZL7HrHJk+MpwmXUwrgNdDscuWuYDwQQDggZrOjJhQ5saSQ== X-Received: by 2002:a05:600c:4a9f:b0:3eb:3908:8541 with SMTP id b31-20020a05600c4a9f00b003eb39088541mr6751763wmp.2.1677749865583; Thu, 02 Mar 2023 01:37:45 -0800 (PST) Received: from ?IPV6:2003:cb:c70e:4f00:87ba:e9e9:3821:677b? (p200300cbc70e4f0087bae9e93821677b.dip0.t-ipconnect.de. [2003:cb:c70e:4f00:87ba:e9e9:3821:677b]) by smtp.gmail.com with ESMTPSA id p20-20020a05600c205400b003e8dcc67bdesm2192666wmg.30.2023.03.02.01.37.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Mar 2023 01:37:45 -0800 (PST) Message-ID: <8783f47e-76ea-cd24-e373-f2156884cd05@redhat.com> Date: Thu, 2 Mar 2023 10:37:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH v2] mm/uffd: UFFD_FEATURE_WP_UNPOPULATED To: Muhammad Usama Anjum , Peter Xu Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrea Arcangeli , Andrew Morton , Mike Rapoport , Axel Rasmussen , Nadav Amit , "kernel@collabora.com" References: <20230227230044.1596744-1-peterx@redhat.com> <640319be-ddb6-d74f-b731-eee5ceab3d01@collabora.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 47A3D180004 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: ey8m3ii8iqff5t63dubx4yd8ggw7dcue X-HE-Tag: 1677749869-644555 X-HE-Meta: U2FsdGVkX189JS4ym875K5EC8aMsm1+S5fHQ69M6LYJ56ytHSuhYOX5or6OubWaTrVPxgYkmo2x+eKDyTx9PgJdudZM1Ln7kW7yIZhZNjSCfukYiVBzH+R5DieCtkiFw46Eq9XGASGJ6FEiBaw5kgG5UDt+T2g1qfsmr6CHKY/7KHu2zlMUQuL37h1TGRnTe+QBCxMnSiiWPoQUXOlgi35yi11+wMvTb5CG5eoFOlkVYTcss8KO58eb2rHsCK1g7Vcs4jIbId2hUGhNcQi1gDgEA9EbZ4ZPee+/CT6HUOWLeiIHBs8P9qR3+hUKL3wmSF5gd5eUEorZfcLM7+Eg8mIvAbEYkx6MwRSCyqNvLjt2hb5Mr2m5v8UXUsKUIOYNr0abBfIZCPDOQ7pqq/Cn5Y47boXXazKiApz7NKLkRCp4uNZu1wTAAgzQTNchkviQ9iCsaIXEvc29j9ZJRrNhJCSknaAv4NifQHxot6NqKdzi/uA/yKcB1QCWE80J6ex5URpleGeKCCMZrLNnemGJiEKCJFPRYZb18DyHQ4FRkWykLovl5rrYfI0xpl1yZamfgIeLeB/2G0UqGsLgsmycD3eIaPOR5kS7xYDv4IHC0mANcFpftk1CVs5dsdfD0qO2F9BYIlT0pXxt8oPAJq9TpC0LMCa0U6X5lWGwMBaXD4p2gXIL/rbdOQRrHqKScvn6qFzsDjz/6lJI/wLFGjCXs2vzHTnb/doiPEA/qZ5QmqTp9iWpOO0lreaKpxyplFN5pcU2n3VvBSYfECY2/4HtH+NHivBeANzBX61OtXWAIiws7mKyj4mBHXBZyBUyam7Dsjb2CiNEetnIqzrpMIgQGUjCp/RfEx64xYv1Uw1O+zPwa9Q6e+YDda73VRR8l/hkWpcNavpWfoQs4mgQ6OXnP8PbMJS7KTa5XQTzShCx77Eu1IR89d2lCffO4kfdUaNz9KMIlD5e5HMO57mcfwnS OAx8ugQC 3rRMeCqqTXDqqAPtWje5gw8g+ZAPneMpADtnocvCuZvIs7lnvXPh9DFA4TFJ5GcLQ//KWOlDRral5HxyxLJUA6s+czPiX25c7d8jypRmG0T4cJ4VQCU/mLCvO18HFmq+RvM0QOO91BuOaKfSWyqqu4wv67Nl/V7tLcCTngYp7HmfKmryDpqtlM1ufZwjrDhJQNs2/o8MwD7NOVBXvKfpA+osT+W4g5SsPikeq7G08NswnWNFaP17NOydJtxhn4wSYWiKb44ur0SPjhMe0zyHw2yZIL11MbM86s81L3V9r2ExvZzcUHLJ5tDAnk7/lQ+4GrYOQZXa+3kCTyNvQ/EA0nb/YLWNeLjtHttblmfJsQ2Ra5shpgiUcvt7hI0RKOZGluUFrOZ2WU/9cUfeluvwgjMfjJtzOTp+Al8HqcEfc9TQm7EFQdQfQiq/m5FwWdNCpEIomoOdwWJMT5aBAaPTk1fydaHlmw608rT7aKJSBEPUedDOQZ+XwYY11bJzq/8jZkAogccb0dyzlRW4QtW7Tc6S+pz2hKjegojKFYG+6piMVzRvuAIql5NzefQ== 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 01.03.23 18:13, Muhammad Usama Anjum wrote: > On 3/1/23 8:19 PM, Peter Xu wrote: >> On Wed, Mar 01, 2023 at 12:55:51PM +0500, Muhammad Usama Anjum wrote: >>> Hi Peter, >> >> Hi, Muhammad, >> >>> While using WP_UNPOPULATED, we get stuck if newly allocated memory is read >>> without initialization. This can be reproduced by either of the following >>> statements: >>> printf("%c", buffer[0]); >>> buffer[0]++; >>> >>> This bug has start to appear on this patch. How are you handling reading >>> newly allocated memory when WP_UNPOPULATED is defined? >> >> Yes it's a bug, thanks for the reproducer. You're right I missed a trivial >> but important detail. Could you try apply below on top? >> >> ---8<--- >> diff --git a/mm/memory.c b/mm/memory.c >> index 46934133bd0b..2f4b3892948b 100644 >> --- a/mm/memory.c >> +++ b/mm/memory.c >> @@ -4062,7 +4062,7 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf) >> vma->vm_page_prot)); >> vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, >> vmf->address, &vmf->ptl); >> - if (!pte_none(*vmf->pte)) { >> + if (vmf_pte_changed(vmf)) { >> update_mmu_tlb(vma, vmf->address, vmf->pte); >> goto unlock; >> } >> ---8<--- > This patch works. Thank you so much! > >> >> I can send a new version after you confirmed it at least works on your >> side. I'll also add some more test to cover that in the next version. >> >> The current smoke test within this patch is really light; I somehow rely on >> you on this patch on the testing side, and thanks for that. >> >>> Running my pagemap_ioctl selftest as benchmark in a VM: >>> without zeropage / wp_unpopulated (decide from pte_none() if page is dirty >>> or not, buggy and wrong implementation, just for reference) >>> 26.608 seconds >>> with zeropage >>> 39.203 seconds >>> with wp_unpopulated >>> 62.907 seconds >>> >>> 136% worse performance overall >>> 60% worse performance of unpopulated than zeropage >> >> Yes this is unfortunate, because we're protecting more things than before >> when with WP_ZEROPAGE / WP_UNPOPULATED but that's what it is for (when we >> want to make sure that accuracy on the holes). >> >> I didn't look closer to your whole test suite yet, but my pure test on >> protection above should mean that it's still much better for such a use >> case than either (1) pre-read or (2) MADV_POPULATE_READ. > Ohh... I should stop comparing UNPOPULATE with buggy implementation and > compare with pre-read. I've compared apples with oranges. Note that I think there are ways to avoid that overhead (as raised in reply to Peter's reply), so IMHO it's still valuable to know which benefit we could have without allocating pagetables and placing the shared zeropages. > > I'll do better benchmark for the comparison sake. I'll let you know if the > performance is becoming an issue. Overall we need pagemap_ioctl + UFFD to > correctly emulate Windows syscall. Secondly we also need good performance > (more the better). I'm curious, are you eventually applying UFFD to possibly large (sparse) VMAs, that are eventually even only PROT_READ or PROT_WRITE? Especially for such large sparse VMAs, the current way of allocating pagetables to place markers/zeropages is far from optimal. -- Thanks, David / dhildenb