From patchwork Thu Apr 11 16:14:40 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Hildenbrand X-Patchwork-Id: 13626355 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 C47B9C001CC for ; Thu, 11 Apr 2024 16:15:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 524DD6B00C5; Thu, 11 Apr 2024 12:15:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 504F16B00C7; Thu, 11 Apr 2024 12:15:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 34D9E6B00C6; Thu, 11 Apr 2024 12:15:09 -0400 (EDT) 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 0FA426B00C4 for ; Thu, 11 Apr 2024 12:15:09 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B86E1C06B1 for ; Thu, 11 Apr 2024 16:15:08 +0000 (UTC) X-FDA: 81997750296.24.7E6E36F Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf08.hostedemail.com (Postfix) with ESMTP id C8C7816000A for ; Thu, 11 Apr 2024 16:14:59 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=FHfkfsmz; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf08.hostedemail.com: domain of david@redhat.com designates 170.10.129.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=1712852099; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=5Gc5EzQD4KCJRDKgqgJn1MWb8b3Qcq3MV0Fega+6Dww=; b=1+mZYKcbu4PBTliMX+PrwxhcdMtP2f8V1FYLziA2FtA3sbVwl72melx0JoEdjXwq3BDe+P O+AqjTXp2iBAMtszeoGBpxzaZVaBncSD3L2li3baAD0bMle6L0HVHP/EE8dNRpz270leFQ ePW6UtyapJY8Tt7iC0NzHOT9kkKr2eE= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=FHfkfsmz; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf08.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712852099; a=rsa-sha256; cv=none; b=ygwravx1EmNwB42PZyo9jx/YEWX4xs5PeAgDqI4f6ckpVONq8vVObZhCml4Q6i70zbuqiy fIJOnqaV00fRWdiBKwmN42XvF+30EEzPHEcwLKLniF2zHIzSFvBKHDoCiBU/KZQw+YKqc/ SY73mN94nrCtAS9hv4shlIEAL/FfGBI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712852099; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5Gc5EzQD4KCJRDKgqgJn1MWb8b3Qcq3MV0Fega+6Dww=; b=FHfkfsmzS0hbwOF2gisSKHiG24SKQ7/oCfaUGNsSg6j1inBgEXaaDM1NnvQwQN2g12soL5 8sSY1zhl/Ce7QXHhEtC3TjpPRs6WDIeyDcQayCvLtGIf+HRE2Op1L0D60mW9UKrD0RUkqx yM9fi+2zRpwAl2jRIHiusvwqf7b7wb4= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-237-AyIYVHnbPImCEUVwQUyQAA-1; Thu, 11 Apr 2024 12:14:55 -0400 X-MC-Unique: AyIYVHnbPImCEUVwQUyQAA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 926B71887313; Thu, 11 Apr 2024 16:14:54 +0000 (UTC) Received: from t14s.redhat.com (unknown [10.39.194.173]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8FC1D1074E; Thu, 11 Apr 2024 16:14:50 +0000 (UTC) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, David Hildenbrand , Christian Borntraeger , Janosch Frank , Claudio Imbrenda , Heiko Carstens , Vasily Gorbik , Andrew Morton , Peter Xu , Alexander Gordeev , Sven Schnelle , Gerald Schaefer , Andrea Arcangeli , kvm@vger.kernel.org, linux-s390@vger.kernel.org Subject: [PATCH v3 1/2] mm/userfaultfd: don't place zeropages when zeropages are disallowed Date: Thu, 11 Apr 2024 18:14:40 +0200 Message-ID: <20240411161441.910170-2-david@redhat.com> In-Reply-To: <20240411161441.910170-1-david@redhat.com> References: <20240411161441.910170-1-david@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.5 X-Rspamd-Queue-Id: C8C7816000A X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 8ywosn4zqqh7jho5y864y7zuus3zjszk X-HE-Tag: 1712852099-648569 X-HE-Meta: U2FsdGVkX18oHnNbY5EcvIIU899mYP+AEVGfkO5j5MggJLDz1frBmi9BjhDZ9IcBcsnqGlxIeWBz7lNc4E4XiYGHMdHk0Ghx1kygDpWS7qY5UNryTJsIJ0V8LVa48OgLsFp4t2RaCcksDOkQaJq3fmg2g5TcSjbSabdEih5ujUcQ3UYhDQjI4OdknsQXEGD4TwWpbPgNDIhFmnTlyp1GD26YMryYium/C9iXooWSFbMFgPRLuwusILCua+xIb5PQ59ozd6OW8okFqXASboI3lROq7Z0QMDBrGCaKJi3u16ljcZPP5XfQ9LonnRnNYZRfi+Q7YJ9AQ4TKq38TVDpTttaXZjUTDzbvPVtXgYYCQitv561FS/xQihNPWceBL8YPjGMmycidgqCRizVOQXbfEnBwTEX8mMobM8Z7Oj8LCpqltgBGAwa9AkoFno0Y1IfYDQZl8iXdqhSpEmWJSO47mZLj8HpgoEYimwGefI6bi0SFMW6uYeVFzJfUXyr6dcUeV4mlE/zdYTuQ9GFx3Hs1Ldm8FVAe9ZrMmo1LA7T2qh8ye50R01MIsOw89yhUsGDM2HRPtvVPYJb5kjQfARlJv0fKRRqHRIjUKn/bX3RS6lNgQBLxLpTU9ec1HVi3XiYp4sqKbpw6w6QhUq2d+91L1VomjvGzu6s5Z5evBAQOztZFmjsg0cO2sOBhHtFlMynss7aRiADO7K3kdqtOIUef7LgvYXTkcQGin7fM9AsotIvBhgI9fAWZYYSDgbsZSWf/BGZdmkdFQEEwOrXuratCQsS2G8mJoimkd/rj6E/7HO1CRdycoQJaercY0TDKdhlLX8lZCt0S+pSZso6UUS01iqSjQIyzPpNtigFu8LLg9PDNbc60wfQZDY7sEYx9OH7X7uah6/IhbmQ8hHeHLoPprWAxwHQupAtumt5TPnVWsjq71V8YIak1vxaetW3VOB0doRF2d74jAEOlM0Ydy4R MKAvL7Qy Zpgc/gMKOxCHRbpRR34u0Ts1ndXtyJHIQ4d5iY+c/hrp9HVDZ2Mr0aaDE3fepm8TW5/xpHp1SONxBVfHmd/CQzKiI98JtjJaf+Ak+tQknlufCkWgv5V71Hir4HFriZmRvDK50wHl4yJ2ozRiB5vZSZh0xd9XlC4KaRB7Y1rXB0PnX8fg= 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: List-Subscribe: List-Unsubscribe: s390x must disable shared zeropages for processes running VMs, because the VMs could end up making use of "storage keys" or protected virtualization, which are incompatible with shared zeropages. Yet, with userfaultfd it is possible to insert shared zeropages into such processes. Let's fallback to simply allocating a fresh zeroed anonymous folio and insert that instead. mm_forbids_zeropage() was introduced in commit 593befa6ab74 ("mm: introduce mm_forbids_zeropage function"), briefly before userfaultfd went upstream. Note that we don't want to fail the UFFDIO_ZEROPAGE request like we do for hugetlb, it would be rather unexpected. Further, we also cannot really indicated "not supported" to user space ahead of time: it could be that the MM disallows zeropages after userfaultfd was already registered. Fixes: c1a4de99fada ("userfaultfd: mcopy_atomic|mfill_zeropage: UFFDIO_COPY|UFFDIO_ZEROPAGE preparation") Reviewed-by: Peter Xu Signed-off-by: David Hildenbrand --- mm/userfaultfd.c | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c index 3c3539c573e7..7eb3dd0f8a49 100644 --- a/mm/userfaultfd.c +++ b/mm/userfaultfd.c @@ -316,6 +316,37 @@ static int mfill_atomic_pte_copy(pmd_t *dst_pmd, goto out; } +static int mfill_atomic_pte_zeroed_folio(pmd_t *dst_pmd, + struct vm_area_struct *dst_vma, unsigned long dst_addr) +{ + struct folio *folio; + int ret = -ENOMEM; + + folio = vma_alloc_zeroed_movable_folio(dst_vma, dst_addr); + if (!folio) + return ret; + + if (mem_cgroup_charge(folio, dst_vma->vm_mm, GFP_KERNEL)) + goto out_put; + + /* + * The memory barrier inside __folio_mark_uptodate makes sure that + * zeroing out the folio become visible before mapping the page + * using set_pte_at(). See do_anonymous_page(). + */ + __folio_mark_uptodate(folio); + + ret = mfill_atomic_install_pte(dst_pmd, dst_vma, dst_addr, + &folio->page, true, 0); + if (ret) + goto out_put; + + return 0; +out_put: + folio_put(folio); + return ret; +} + static int mfill_atomic_pte_zeropage(pmd_t *dst_pmd, struct vm_area_struct *dst_vma, unsigned long dst_addr) @@ -324,6 +355,9 @@ static int mfill_atomic_pte_zeropage(pmd_t *dst_pmd, spinlock_t *ptl; int ret; + if (mm_forbids_zeropage(dst_vma->vm_mm)) + return mfill_atomic_pte_zeroed_folio(dst_pmd, dst_vma, dst_addr); + _dst_pte = pte_mkspecial(pfn_pte(my_zero_pfn(dst_addr), dst_vma->vm_page_prot)); ret = -EAGAIN;