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 0DADDC636D6 for ; Fri, 17 Feb 2023 17:36:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E96696B0071; Fri, 17 Feb 2023 12:36:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E46516B0072; Fri, 17 Feb 2023 12:36:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CE6ED6B0073; Fri, 17 Feb 2023 12:36:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id BE09B6B0071 for ; Fri, 17 Feb 2023 12:36:11 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 941681202D6 for ; Fri, 17 Feb 2023 17:36:11 +0000 (UTC) X-FDA: 80477487342.16.2332D03 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf22.hostedemail.com (Postfix) with ESMTP id F11D6C0014 for ; Fri, 17 Feb 2023 17:36:08 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=YCL+ZlD2; spf=pass (imf22.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676655369; 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=QtVPzPhu4Ul2QiH4Cq+Qr2IaY2er2+POQw31zFIVv4E=; b=LPxbv6pReoYImDioTgk2/uJwfM9jPCrATLY+d0/g8vKm7ZpIY++YZTljmPpPQv5193uvOZ UN9iINa58nLO4Wf1rANXx+b57klJ7Pvgw5iIMm7ma+zJ2di2lGyD2Z6563PkXzVV/AQ5lo t4D1omazhg9f/YJDVMX41QQ0RLftuZY= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=YCL+ZlD2; spf=pass (imf22.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676655369; a=rsa-sha256; cv=none; b=Z/Mu9czlX8MA8nwLDbSjiKlj5Zx/r1hWQ4y4pja+cFGXjuNKro8ghctIXBoj14esdA9+LO amMiKe6BuiGeAyHB08epMgPuI5zCkMk3UOtU21pnTwg6kPiFZbVVp6sBelub8hYRt8lkMR mM7lAAgDaJU4+jhobK0OUUKQolbrsVY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676655368; 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=QtVPzPhu4Ul2QiH4Cq+Qr2IaY2er2+POQw31zFIVv4E=; b=YCL+ZlD2aBjGNrhCO2i7ixLS56LnclvH9tJxILImZvtOqQh9Ghdq1E9smdYjD6gDf3za+q 2gIhF+VCmaIc6hNP8pRelrh6gFGpfPh1zc4PFGVqIvo4lRZbDXqGv+IuksYUWKItXA8G23 eo6KRpzW/mIx1FMll0fWhixl3Gzjirs= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-330-ydLu3jdvMZimucYVHDLkYQ-1; Fri, 17 Feb 2023 12:36:02 -0500 X-MC-Unique: ydLu3jdvMZimucYVHDLkYQ-1 Received: by mail-qt1-f198.google.com with SMTP id n10-20020ac8674a000000b003bd1c0f74cfso1105385qtp.20 for ; Fri, 17 Feb 2023 09:36:00 -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=QtVPzPhu4Ul2QiH4Cq+Qr2IaY2er2+POQw31zFIVv4E=; b=bNwIYpQ+V3t2npn3YFWerYD+u+sZKkqnOXmtmajnZQqhbwQUH6D1qXc82miqrBJmD7 wUuZGz/+L9rS5nrsBaB8sL+t7jwi6RQgylCTpA0/JPiaZujIaHQSOh/R6aAILLuLuptj KxmUPMXT4wVCgVcpql90VSfvnC/TEx1bYMv0I6h+mTgj+SYZ6osDCRJz6nwmCJQx62fU v5FQWujcavZqbnecZoQQSks+NrYWNEyyanDdpCk0snT+wd19TbFZ0PhwSG/0+3qxqtF9 SuEVrvMIShmXj1pd/bucoa12mteUKWuoM07bPq1h7SFerSEK8DkLT/bXEQ/lZReu0YFU 1e0w== X-Gm-Message-State: AO0yUKXj7+Y7WeE6AOq7jCe9bdilYiCK/B5Mgr8Zpa/U/nReyQD2NJhp Unmwwv32VUbxie3+A9NogqqNyfWcAXr3DSENqVqknc/ix6qno0H8J4213H7pOrTUvYHpdZxAaJn FKZKPjCFYS+Y= X-Received: by 2002:a0c:dd81:0:b0:56b:e73e:e925 with SMTP id v1-20020a0cdd81000000b0056be73ee925mr2673034qvk.0.1676655360381; Fri, 17 Feb 2023 09:36:00 -0800 (PST) X-Google-Smtp-Source: AK7set/8nf/4lX6QnE7xuq1ZCx56boZT4qEUHUTefLAuAgsOwvYJ74D42p4knfb8q7SabnCSSWtEaQ== X-Received: by 2002:a0c:dd81:0:b0:56b:e73e:e925 with SMTP id v1-20020a0cdd81000000b0056be73ee925mr2673002qvk.0.1676655359990; Fri, 17 Feb 2023 09:35:59 -0800 (PST) Received: from x1n ([70.30.145.63]) by smtp.gmail.com with ESMTPSA id o62-20020a374141000000b0073b676274e7sm3618630qka.94.2023.02.17.09.35.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Feb 2023 09:35:59 -0800 (PST) Date: Fri, 17 Feb 2023 12:35:54 -0500 From: Peter Xu To: David Hildenbrand Cc: Muhammad Usama Anjum , Andrew Morton , kernel@collabora.com, Paul Gofman , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 1/2] mm/userfaultfd: Support WP on multiple VMAs Message-ID: References: <20230216091656.2045471-1-usama.anjum@collabora.com> <53dc6054-07eb-f97b-7b2f-558f02d1b90a@redhat.com> MIME-Version: 1.0 In-Reply-To: <53dc6054-07eb-f97b-7b2f-558f02d1b90a@redhat.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: rspam03 X-Stat-Signature: ey1c99ae6fn9189ou568ue94o15xiswn X-Rspamd-Queue-Id: F11D6C0014 X-HE-Tag: 1676655368-193804 X-HE-Meta: U2FsdGVkX1/1qP1T6pMC4yrs5DRyCLejgJxhvfXOiCYJsWF4WVo5pzM5wx4/oQu/eT+on9KTzZOPDjEE4q+e4JVmBt1WOkAOe0nEiQcyKhhewSItcco/eCfEv6oXiv4o2lmiT9KW0uUl4L46rYwXd6S8yAi1hPvQJsUBQuAHbkgenmGiomH2FG45dP3VwakBh3EN+kyDvvhT4h7KIebGZMGt7qeU5X/M+g07d9WMSd2HKHmbhlyhE3qW7MIdWMMPScOKRaiNiukCbkSWn9PDhr6g2wkB2Zlia5LU5KCHtmELaWyXN1FdO/TzTkIbyxGqo5zccNoPYEOXXH1xlKLx2/XOYxpFj0yNzL5KMxMEvEqqsrqrs2aPkCXtS+6NMWNz6NdRZ0xtI5G/YA42vBELw/irYSHNtc6SV4UrNwU1Y4vk6rNQKsoYC+8iDb3ASOdMLioARUikkdEVu4g0b2aBf8HEclVCHW1firZoD/WwmUg1PqATgdejPbVIG3hkFuJrGoixnxMFGF9+8ESqvDSN+i/dwO8EdzWnFdJNoT+pDKm1dZyoid/w3DYG+bfaujjs0rHKjjmHpbd3dIcqJIBBiq3taQScZS/tgR2+QZDpsRCrKXUFcXbJFYdvjaZYhnHX6H+PdmcPdzXSt/xN7+3FyjQrDolidtCaRjdc3KT9u6t87CnsZld5dH1xi5bTekkbkNH4pTwwaCZ/WScszUbEIXXSHyPR0qAuZ3Lvks65+2zpGDb3vVplwYrXo7WtaYIZjc7joudTcE9Tgm8RU5zBviobwZXOVzcIECRCEdJziMbetzr5tm6pptpmdq73rTVkN0lbentJb8xomlb35s7S8Uzzo+o9MnOi1Kr1cIsuUH+xVfWwmlDV2/HjzpbKd+VIlW/TlDxBFhIZ9Ecwgryme7yYr4aDSEthVNj4elzx5gISV9JMRq0EZGivR5CxnHuIonbJbXlFcfPxxsn36vY AiD0+5sf 5LmOfS3+nAYTD38bC7gRtiVBlgz0IUlq9L2LVVPinHdmZyTgxV+/OSe/oDLM+7bqJrdawuq6WqvA5TeIpUbA5STwn5Yw3wN4YGUsqp5t1KCzDyZGBLpMrToGqRdja5r3NQvwIqxX1McYP+azWKJoQ0YgVaOHQJfBG2EJgee2RUcAK7vS988QzH3LAybZrE0ZFidasWuqAWh3utubQrjLLN4pTdFi0fQwGRnFlLrmsMIvIgD+kGr8MBN7SiMGqyLzKSXCFZwsdD236L/JMCyuOvv0rPlRPDF+DndoDFVxjyBIwNxRE3bT1Wh2CitmGrl14+I60krGxsKK5HTusvJ42SNF0kyLd9l1ss+twkLNFizSkJ4cCZvBSTvVD/tQ+XLw/a4jg 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 Fri, Feb 17, 2023 at 09:53:47AM +0100, David Hildenbrand wrote: > On 16.02.23 21:25, Peter Xu wrote: > > On Thu, Feb 16, 2023 at 10:37:36AM +0100, David Hildenbrand wrote: > > > On 16.02.23 10:16, 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. > > > > > > I think, in QEMU, with partial madvise()/mmap(MAP_FIXED) while handling > > > memory remapping during reboot to discard pages with memory errors, it would > > > be possible that we get multiple VMAs and could not enable uffd-wp for > > > background snapshots anymore. So this change makes sense to me. > > > > Any pointer for this one? > > In qemu, softmmu/physmem.c:qemu_ram_remap() is instructed on reboot to remap > VMAs due to MCE pages. We apply QEMU_MADV_MERGEABLE (if configured for the > machine) and QEMU_MADV_DONTDUMP (if configured for the machine), so the > kernel could merge the VMAs again. > > (a) From experiments (~2 years ago), I recall that some VMAs won't get > merged again ever. I faintly remember that this was the case for hugetlb. It > might have changed in the meantime, haven't tried it again. But looking at > is_mergeable_vma(), we refuse to merge with vma->vm_ops->close. I think that > might be set for hugetlb (hugetlb_vm_op_close). > > (b) We don't consider memory-backend overrides, like toggling a backend > QEMU_MADV_MERGEABLE or QEMU_MADV_DONTDUMP from backends/hostmem.c, resulting > in multiple unmergable VMAs. > > (c) We don't consider memory-backend mbind() we don't re-apply the mbind() > policy, resulting in unmergable VMAs. > > > The correct way to handle (b) and (c) would be to notify the memory backend, > to let it reapply the correct flags, and to reapply the mbind() policy (I > once had patches for that, have to look them up again). Makes sense. There should be a single entry for reloading a RAM with the specified properties rather than randomly applying when we noticed. > > So in these rare setups with MCEs, we would be getting more VMAs and while > the uffd-wp registration would succeed, uffd-wp protection would fail. > > Not that this is purely theoretical, people don't heavily use background > snapshots yet, so I am not aware of any reports. Further, I consider it only > to happen very rarely (MCE+reboot+a/b/c). > > So it's more of a "the app doesn't necessarily keep track of the exact > VMAs". Agree. > > [I am not sure sure how helpful remapping !anon memory really is, we should > be getting the same messed-up MCE pages from the fd again, but that's a > different discussion I guess] Yes it sounds like a bug to me. I'm afraid what it really wanted here is actually not remap but truncation in strict semantics. I think the hwpoison code in QEMU is just slightly buggy all around - e.g. I found that qemu_ram_remap() probably wants to use host psize not the guest. But let's not pollute the mailing lists anymore; thanks for the context! -- Peter Xu