From patchwork Thu Mar 21 21:59:53 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Hildenbrand X-Patchwork-Id: 13599394 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 2E17AC54E58 for ; Thu, 21 Mar 2024 22:00:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A5B496B0088; Thu, 21 Mar 2024 18:00:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A0A4A6B0089; Thu, 21 Mar 2024 18:00:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8AC346B008A; Thu, 21 Mar 2024 18:00:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 777D96B0088 for ; Thu, 21 Mar 2024 18:00:21 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 3AD7C40BBC for ; Thu, 21 Mar 2024 22:00:21 +0000 (UTC) X-FDA: 81922415442.28.A123FF4 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf29.hostedemail.com (Postfix) with ESMTP id 74C2512002C for ; Thu, 21 Mar 2024 22:00:19 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=gDa9OqjW; spf=pass (imf29.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@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=1711058419; 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=I/TUj8l6v7W+3WhwmC9vyikgxzfujRZI8v2Khs5cepE=; b=yy2VAWYF57+mEF35RZUuDZBz14nn5h9rPW76ZJiZA0o5/WLVRwN/Zi6j4kjTVT3VghgjBA yM9ZytFe8VHbxPVPKh5Gyg49cBvLoaTzQ9Z3mD9lKSD5qdTJSF2Hc7O0ZtLfEZc5tJu4Yf SctUd2kQH0swZFdZzIjGvser2VArILw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711058419; a=rsa-sha256; cv=none; b=W55kL+cCvadqYd1z6AJCuq5gXDezNAQq9ugYXi4MoqxQSvQCk2udy+Zf5LzKi8krfCsO2z jqo8YqNbEfsMoZwKMloWl1NCGXG0uAhonZFcX5QrE5xp4zm5FbjnpbAErTFhPg9/mEJibd HmMYuzDWR4UCAdJvoQgdA1ox9aNdXss= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=gDa9OqjW; spf=pass (imf29.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1711058418; 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=I/TUj8l6v7W+3WhwmC9vyikgxzfujRZI8v2Khs5cepE=; b=gDa9OqjWjwH75xMtonOuQPCfMci4I7p4VKlGkpkRBU/VDS8FmypJu5AsYo21NK6rLlA2WH jp/GwEKkO6/5e3AoqFUXwJRlJ8KdKMj6a/EXjmCQqKeN6yv44RrT77mmnOY5dUt2q//Pkl 5M+rxGxBimlTY+k9bUugkE7MB5VvMEs= 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-524-jcbu2gX6Mr6wqRm3UnAAQA-1; Thu, 21 Mar 2024 18:00:15 -0400 X-MC-Unique: jcbu2gX6Mr6wqRm3UnAAQA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (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 32BB3803F6A; Thu, 21 Mar 2024 22:00:14 +0000 (UTC) Received: from t14s.redhat.com (unknown [10.39.192.95]) by smtp.corp.redhat.com (Postfix) with ESMTP id 887341C060CE; Thu, 21 Mar 2024 22:00:06 +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 v1 1/2] mm/userfaultfd: don't place zeropages when zeropages are disallowed Date: Thu, 21 Mar 2024 22:59:53 +0100 Message-ID: <20240321215954.177730-2-david@redhat.com> In-Reply-To: <20240321215954.177730-1-david@redhat.com> References: <20240321215954.177730-1-david@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 X-Rspamd-Queue-Id: 74C2512002C X-Rspam-User: X-Stat-Signature: x58sprcetwqwqh5o7jzh7xfcnhicgy4r X-Rspamd-Server: rspam03 X-HE-Tag: 1711058419-311914 X-HE-Meta: U2FsdGVkX18HY0mmGmGeRBI0B6LPfyX61Dl304oYtEbg+pA9JkwP8fQeluzgMGM0j/KvearKaHEZ4SSR97BHB0lZAXBSybL6C67oucI2/3tzdRPpkz5pJd2th3gxGKzS+Ge0KtKKjzZapObxT4Fo29WwIbL/XCsi3MsiXnSdYBHApRhrxtM9+CBZA8FoPxfTsXiwYHXGdgh8kDkYi6G8YaUiRfs80W8hINzjDcHDW3C/ey0j/QDnCP5395pPGEtcWR1rsfZBuUQCzhTEkKAMJRCDzdpGcuCZQu2JgxuOW4iZoRvs4CseSbslECU1jgj7+rDsi1Gr0LiDHxgmodvQqxXf2DzUc2QiTgHjrYasvMlIVHHV7SswkvjFKycLTeVf3SP3dqcwVTvsxxStaLhPY4G8gOcVM9XCkQNva73fouBV3xmi1IfIrUWTUb0lBucBmYoEJik7/lEei+PppyOMvXmLnDs7dgelzYkq2NoQnA2qiU6eVRAE2Vr2nNtn8UBAZcLHX+YPIFJtCw6PEKBXmlvV+duSH68tj5Hd07uG8n65Wv1OKOls6s7sbH6Qf8FQ3k+3GYXZQzecmon++MzrSZ5mpc9O+FaHL/sGVcocsTmTSv21f6vZOD4wA9PSD52u/Ky6nido+31XpNl2aqK7ylWA/uYkBHB7zypP/0JZpCTy0RflteeH9LqU91scHCOj1MPyR3z7I/0lm4nymi6iT9Ojl5En7+BLKBOtHhTycHVY30EzdaySOljujwZeP47Org77O5TuU8tXj/4P8lflJObvxfE+Klw7jlAq+6NH/xyCEXNIPBTfGHocv9dn4DPCbQl5uL0sW2I/4gm0VAaAoyIrqsYzuVie5TakmU9GX8bM8QkqEXPA8afCtyF5ctQJ32hkCVEVKs4zG43wBnn25eA9jnztVzhVu6F1T/m/vXFx8ZkKfBCpXm8uaPd/1ilxvUJANIVKHDu6+be048I 3cqpw/S+ 6iy4jNQmiIBbyTUZuT500C9vxGHrh/0j/xJe+9/wdf086w4Wcz//mxe42uBdrbpgIieX/2xhleDpVK/HjAiVgDhflb0droImP78RaB0VsiAk3s52HqjNd/u6quDStx8+w8x6bFXRvV6B2OjJuEih77jz+tT38NXSquGi6SZVM3zkarcg= 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") Signed-off-by: David Hildenbrand Reviewed-by: Peter Xu --- mm/userfaultfd.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c index 712160cd41eca..1d1061ccd1dea 100644 --- a/mm/userfaultfd.c +++ b/mm/userfaultfd.c @@ -316,6 +316,38 @@ 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; + + folio = vma_alloc_zeroed_movable_folio(dst_vma, dst_addr); + if (!folio) + return -ENOMEM; + + ret = -ENOMEM; + if (mem_cgroup_charge(folio, dst_vma->vm_mm, GFP_KERNEL)) + goto out_put; + + /* + * The memory barrier inside __folio_mark_uptodate makes sure that + * preceding stores to the page contents become visible before + * the set_pte_at() write. + */ + __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 +356,9 @@ static int mfill_atomic_pte_zeropage(pmd_t *dst_pmd, spinlock_t *ptl; int ret; + if (mm_forbids_zeropage(dst_vma->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;