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 32729C433EF for ; Thu, 23 Jun 2022 18:07:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A7D878E0172; Thu, 23 Jun 2022 14:07:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A2CCF8E0144; Thu, 23 Jun 2022 14:07:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8D0268E0172; Thu, 23 Jun 2022 14:07:19 -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 774978E0144 for ; Thu, 23 Jun 2022 14:07:19 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 4DF86694 for ; Thu, 23 Jun 2022 18:07:19 +0000 (UTC) X-FDA: 79610282598.12.293A70E Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf17.hostedemail.com (Postfix) with ESMTP id C7B2F4001C for ; Thu, 23 Jun 2022 18:07:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1656007638; 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=Fcy1Q3vZZLDhsnG6KdBWdg+6I5F1iLma0wO2j1hoD9c=; b=glLvaMctamQV2BzonT7qOkKdbbYagcxDj1qNoYTWAvr42JPQzJOAXzftQZlNG/j19GtLr6 99AwyV/gYqLNVsqBYEBNDhvqKPPokfBfxa3zAdkynvvkInsDrz6R4HVLQ0h3eY27CC3Y28 ed9C+WPX6ekx9tZI1IyP7Grwc+UkUe0= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-424-5BkCT_z2M3OHK8RO-6bbhw-1; Thu, 23 Jun 2022 14:07:17 -0400 X-MC-Unique: 5BkCT_z2M3OHK8RO-6bbhw-1 Received: by mail-wm1-f69.google.com with SMTP id ay28-20020a05600c1e1c00b0039c5cbe76c1so1757422wmb.1 for ; Thu, 23 Jun 2022 11:07:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=Fcy1Q3vZZLDhsnG6KdBWdg+6I5F1iLma0wO2j1hoD9c=; b=TC9nSkCJJc2T/iTasSgu9L4JdvUZQXK0AfoELpKaMAtxzCjXRuZqtmTmNzHP2tJZSb 5o6Cp09e1ksseB7FkV+xi2pS3zN+v0uihix2XfCn2M/ELDzqiK7LBcwe2kNb7o0HXzNF nn8Acryw3GCQGWddMkfMSKndDQ/aNm7pSh4/cE0q3GZE8IxN8ieOO/AmqP5vBKinDBRC hvyzsPAkSOk9FfdFR1pxebVAard1FhO2PwJIWWDFuvIsp7EGJH7kuSpjfVgrVasnC2B9 g23l/Y/iHzfgjR+Ady09yVxz6EPQNjXJND83qT2aowZ1U0mecHNH0BEFvHDk4w5dXS24 0WYw== X-Gm-Message-State: AJIora+JMC37tyhAYTKXUMSHpjbB+VPX/ypbF5aaqSksP/U2ThC72fG2 0R6sA4uBPFFMyiB09lWSovS8Cwg8Cg5CaeIKXNbR75LSpwuiuxeTzWOtr7DKYmR8b6toPjzTwQ8 hRqR3OdP+TW0= X-Received: by 2002:a05:6000:1f87:b0:21b:970b:e88c with SMTP id bw7-20020a0560001f8700b0021b970be88cmr9595590wrb.320.1656007635869; Thu, 23 Jun 2022 11:07:15 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tbTbYL8XeaDCd4moOYGgY+zKqfgCzDvLfPAFyx+vQt+Z7MS+QQ3dZipJa7LzvlXGFa+V6pug== X-Received: by 2002:a05:6000:1f87:b0:21b:970b:e88c with SMTP id bw7-20020a0560001f8700b0021b970be88cmr9595562wrb.320.1656007635576; Thu, 23 Jun 2022 11:07:15 -0700 (PDT) Received: from ?IPV6:2003:cb:c704:b100:7694:f34e:d0dd:95e7? (p200300cbc704b1007694f34ed0dd95e7.dip0.t-ipconnect.de. [2003:cb:c704:b100:7694:f34e:d0dd:95e7]) by smtp.gmail.com with ESMTPSA id r127-20020a1c4485000000b0039c4ba160absm11819520wma.2.2022.06.23.11.07.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Jun 2022 11:07:15 -0700 (PDT) Message-ID: Date: Thu, 23 Jun 2022 20:07:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 To: Jason Gunthorpe Cc: Alex Williamson , akpm@linux-foundation.org, minchan@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, paulmck@kernel.org, jhubbard@nvidia.com, joaodias@google.com References: <165490039431.944052.12458624139225785964.stgit@omen> <20220615155659.GA7684@nvidia.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH] mm: Re-allow pinning of zero pfns In-Reply-To: <20220615155659.GA7684@nvidia.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=glLvaMct; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf17.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656007638; a=rsa-sha256; cv=none; b=yJDzMjCO7yEhkskFb+LnYVyI+nHW1VpMqVcWlScZrT9OL0fvEF35u2PiTnOuQ5apc+YIe9 v/BZoFUCNu7CQQKjKwBK/KSgtGstSZ9+JAwXQIYZ+T1/CksqNeOU2mOGn1xRWjCAAaJ5D7 TlJgG22hOYemslZDj2FP9TczvmWdW64= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656007638; 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=Fcy1Q3vZZLDhsnG6KdBWdg+6I5F1iLma0wO2j1hoD9c=; b=WIsuvuwegWNPi24BL7BAZQiwE8DcE3B5clsI42mxp/Thzj6N/7Z4GkOJCdL6rfmZjwp4Nh EyN67CrFGjC3Jufly1tcbQTsw2+tXfMG7vaVvovdJ4pFzkKVq/jpbyunBl5FtqHu1HHl9I 2liRELJJTHuqsk9z5wEDmS+DlDmIGj4= X-Stat-Signature: jx79w3fa6mtr6p6qstpe6x4zsyff5rtp X-Rspamd-Server: rspam08 X-Rspam-User: X-Rspamd-Queue-Id: C7B2F4001C Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=glLvaMct; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf17.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com X-HE-Tag: 1656007638-168136 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 15.06.22 17:56, Jason Gunthorpe wrote: > On Sat, Jun 11, 2022 at 08:29:47PM +0200, David Hildenbrand wrote: >> On 11.06.22 00:35, Alex Williamson wrote: >>> The commit referenced below subtly and inadvertently changed the logic >>> to disallow pinning of zero pfns. This breaks device assignment with >>> vfio and potentially various other users of gup. Exclude the zero page >>> test from the negation. >> >> I wonder which setups can reliably work with a long-term pin on a shared >> zeropage. In a MAP_PRIVATE mapping, any write access via the page tables >> will end up replacing the shared zeropage with an anonymous page. >> Something similar should apply in MAP_SHARED mappings, when lazily >> allocating disk blocks. ^ correction, shared zeropage is never user in MAP_SHARED mappings (fortunally). >> >> In the future, we might trigger unsharing when taking a R/O pin for the >> shared zeropage, just like we do as of now upstream for shared anonymous >> pages (!PageAnonExclusive). And something similar could then be done >> when finding a !anon page in a MAP_SHARED mapping. > > I'm also confused how qemu is hitting this and it isn't already a bug? > I assume it's just some random thingy mapped into the guest physical address space (by the bios? R/O?), that actually never ends up getting used by a device. So vfio simply only needs this to keep working ... but weon't actually ever user that data. But this is just my best guess after thinking about it. > It is arising because vfio doesn't use FOLL_FORCE|FOLL_WRITE to move > away the zero page in most cases. > > And why does Yishai say it causes an infinite loop in the kernel? Good question. Maybe $something keeps retying if pinning fails, either in the kernel (which would be bad) or in user space. At least QEMU seems to just fail if pinning fails, but maybe it's a different user space? -- Thanks, David / dhildenb