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 0243BC54E58 for ; Thu, 21 Mar 2024 22:20:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 90F726B00AE; Thu, 21 Mar 2024 18:20:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8BFDE6B00AF; Thu, 21 Mar 2024 18:20:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 787846B00B0; Thu, 21 Mar 2024 18:20:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 668DE6B00AE for ; Thu, 21 Mar 2024 18:20:26 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 2F2551406E9 for ; Thu, 21 Mar 2024 22:20:26 +0000 (UTC) X-FDA: 81922466052.22.49A6DB1 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 EECABC001C for ; Thu, 21 Mar 2024 22:20:23 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=BTvHcJKP; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf22.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.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=1711059624; 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=sCyRimbdU2wwu1d7eDel2TgdYhJ1/JYW04ucq+z++Uk=; b=ptjve6e38wWJ+F4VfBEXZlCDuvgRlQuSmfuTu/eCK406tOtKnXv7GeVaxLlnqELBaLDA8A OVFgcW1eKOjdgIvOozubdseZ8N3P0FvzMyALt5YfgeB0uxCG9FJgevwUNyLJAypOHH2ceU /xhruVJmbp8/ECtpPJ/KeUodai/KKi8= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=BTvHcJKP; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf22.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711059624; a=rsa-sha256; cv=none; b=XFdvl0TJTLQUYG+Uo4u+t4Oh4Nn6yGkpihmv+sZ+Ngu+d2gNTZiIFcTlvhCLHoxp/P4mod WtSH195zaxy/oZvwwpuSjsWJxlC/HuoNf2JeTBKL7nwzaDrVeBfKCZcMDTcj4zXYJNbLNC e2D+kB1Km+/PqH0TOx1wsXTbL6q2TpU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1711059623; 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=sCyRimbdU2wwu1d7eDel2TgdYhJ1/JYW04ucq+z++Uk=; b=BTvHcJKPCd0u0V2jqVYXylFbhD6ZMiQAqSlz/K1nmj2YnMzSnJUW1Sql2BRJuttX0C3oB9 02leonjoyNEuRRvUFdbbVaagl8TCZbQrGVYERXfxknc0tzGVc+f6WHw//AHaBe30uZwxPb 4cdu/K/WyUShghL6jsP/j7grtkRL8mw= Received: from mail-oa1-f71.google.com (mail-oa1-f71.google.com [209.85.160.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-152-YvyfIom2Pza2JmULwSmwow-1; Thu, 21 Mar 2024 18:20:21 -0400 X-MC-Unique: YvyfIom2Pza2JmULwSmwow-1 Received: by mail-oa1-f71.google.com with SMTP id 586e51a60fabf-21e4604101bso415574fac.0 for ; Thu, 21 Mar 2024 15:20:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711059621; x=1711664421; 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=sCyRimbdU2wwu1d7eDel2TgdYhJ1/JYW04ucq+z++Uk=; b=pWvA27sSOOk4fZKTIxaVPs+Xs51BX2VqPb9OMiz2Gs5Pfh8H2Bc39fLocc0wpCZKy3 FgJv5arYreW/+MlNyvbeDeuSr6HkQgSHWNlT0Ff0xK7gyMKCADOHrkkYKmuSIc4uCYcX 6Iyhx0MkM9U40CHOADid2HUdMYMIzIET4PiMhv4tP60YheVotW+SGTOnmLjVc5OfzpQn HKMLJ9lWZ82h+wHwPLLqzlS/BZUiAeLW/LFXGFEv6FLGBH39jOB6JtOQi2nZNylS5VOJ ZW6BjiPa7J4rzOXnpZOHOhg2xC3TeMMzd+t92bV5oRy9H+6cUBFlx6snhw6UA6zf/Orc gJog== X-Forwarded-Encrypted: i=1; AJvYcCVxhRE2LfpP9sGyD3X/QQ/NfNZ2VkYX2zAS8L+4NUQ/hELjpyWdaF3tTDHCtuoAu9rm4DT2MobMhQhUeCd0TpMPTCw= X-Gm-Message-State: AOJu0YyB8rF/ySlocbM+cyqHFiZh8fnRT2IzFjosqfrjf/XuZFHGWAxt TqdYBZGm58xrtkbZrw+N9bf8JeDz+LoiRQShVoVd3PGBMK7ENzaqdv0G0mQJI3zAB1vwXT0yk9y YbbJNUBJRyxcgFOHdAZPDvgRkT4SESB91gUU00QDxkoKHiz11 X-Received: by 2002:a05:6870:f80f:b0:229:e46d:763a with SMTP id fr15-20020a056870f80f00b00229e46d763amr219192oab.0.1711059620831; Thu, 21 Mar 2024 15:20:20 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFAsJ1BNGnICQuxlCUIGt0YZ8AO8lhg+b2h4UmNz9/iXMpHRYabaisHPwVf7UL0HBtNAl4TZQ== X-Received: by 2002:a05:6870:f80f:b0:229:e46d:763a with SMTP id fr15-20020a056870f80f00b00229e46d763amr219170oab.0.1711059620305; Thu, 21 Mar 2024 15:20:20 -0700 (PDT) Received: from x1n ([99.254.121.117]) by smtp.gmail.com with ESMTPSA id pt19-20020a056214049300b00690f23c8605sm374850qvb.23.2024.03.21.15.20.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Mar 2024 15:20:20 -0700 (PDT) Date: Thu, 21 Mar 2024 18:20:17 -0400 From: Peter Xu To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Christian Borntraeger , Janosch Frank , Claudio Imbrenda , Heiko Carstens , Vasily Gorbik , Andrew Morton , Alexander Gordeev , Sven Schnelle , Gerald Schaefer , Andrea Arcangeli , kvm@vger.kernel.org, linux-s390@vger.kernel.org Subject: Re: [PATCH v1 1/2] mm/userfaultfd: don't place zeropages when zeropages are disallowed Message-ID: References: <20240321215954.177730-1-david@redhat.com> <20240321215954.177730-2-david@redhat.com> MIME-Version: 1.0 In-Reply-To: <20240321215954.177730-2-david@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Queue-Id: EECABC001C X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: pq19z34poo5grns63ex5yox885au1ctz X-HE-Tag: 1711059623-783923 X-HE-Meta: U2FsdGVkX19rqMzg3Hpw/1ga9eGL7eUYoGbYe5VeL/K+JZA/8yskU8TGBNbbWaZwan4/rljatcPZ6rSJnoRjJ/Io1Yi2IxR58gP/tym8/j9fmsYAovvkUpFhPsqtFiQMFLxSvvGa9EftIKMzgqmw6uE2TAQB4BRV2zH0wBMwLXLvBDmtlFuBa6HX/Ifkt5I5r64zpMk/K0UZUaCrFeYUGUr6O5Lu2qDD1qjKcQDQ1BgyKPuSRQ/BcyqYtA2zOcDJ4xJAXcp1dmabrZdtovjSwYFiaKJ/0A8nF+lsDXpeJelK6kvi/+4MmajnXU16FqrTY8O2kz1CdGP5UU2kKTn3zUMxu+GZwrMOzRNOIFdfphJNHmWUu4o5qB3oT5A6CqjYLzKHoEn0PUtu7poBUi7NuhUafCFWJjzfTEnSWLKouh6l+l9APa1BTPgiU4Y1m4x6HeSt53JgEBQalqAsLa3wsmALJhjxhdzrIl+SmiSALEn5MBM03uo0NFMhrGxsCCpmysa2jTMmh44eiWJAac4ScRIQA7KD8jxvdLCuTViulJGDEQDe/kHAKrBg2U18Gs5pIYIKPbhEN8dRIBznSZcTFa8XM3GrPVc84GJ0wXdBx6oOGzeQxKMI+vMLWwI5RNtEqlKst6gPawiuhaL/t4UY6/IJr4jKskRCmitHGT9bOV61FD0q7WBxv24/ZVnz/qgF/wTjCmeqbibeEhGQBFAGxco3B/lGRZicrODOnsA6l+ndZrhdQ2izKkg2R9V30m2L9SVEsxaqzj75PlIeueitb1sj9Eaz2DuZAVMDY8GJ+U9Q75RwUnzSf3hDwudPOrFhugYbBG9UKqDNfaqlqcIYT9cU2ImghSW512PJYpjvNO/Bz4/Gn+V3zuudMc8vJTAXOuhFVe2aBPJPUOG8bcHaris6b4A9mTLHvtbIQ33Qd6XcU1dtTgRjzPLz7PAlflN8UVRbfiWEmhEerABCP3h KxebG8w4 h2fQAyXnIj68N+HF4UjJl2ihyjS/kbb0W51Zxq6FjcKNUzF7jt5lUSAj3Kq3ucEbkgwwwbxVftb4kQw3g9y+EkjfLXJeP9MUfWEYSDc5DVDz8FSeD6CAKYsQIUfDtncJocn+hK2lF94b2Ftcop0GpMx1YoWLgMpcbBBYsyFbk01Q5YLMzHlnq5gCcBcI0lPdWIaw6Dl0QDHeLAjzdkBIyqLeKoT/Is+PGoPkb9Dlw07cWxdwa0CPxoOqanz3H0wAHN4ccp7UB/8koUqUjKBiNVg6zvKOeY4ykTdqFR5oIScxi05fVy0y+FCrqbaTB48qg4tccTkDYWGmOpT7lQ6o7docwwA4Dy5TqLLOiCQhZBotViyXhiccL8sWkFEC+6FLW8w7E 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: On Thu, Mar 21, 2024 at 10:59:53PM +0100, David Hildenbrand wrote: > 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 Still, a few comments below. > --- > 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; nitpick: we can set -ENOMEM here, then > + > + folio = vma_alloc_zeroed_movable_folio(dst_vma, dst_addr); > + if (!folio) > + return -ENOMEM; return ret; > + > + ret = -ENOMEM; drop. > + 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. > + */ This comment doesn't apply. We can drop it. Thanks, > + __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; > -- > 2.43.2 > -- Peter Xu