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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 076B5C38145 for ; Wed, 7 Sep 2022 16:41:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229902AbiIGQk7 (ORCPT ); Wed, 7 Sep 2022 12:40:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43592 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229540AbiIGQk4 (ORCPT ); Wed, 7 Sep 2022 12:40:56 -0400 Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 082E56EF36 for ; Wed, 7 Sep 2022 09:40:55 -0700 (PDT) Received: by mail-qv1-xf35.google.com with SMTP id q8so11101607qvr.9 for ; Wed, 07 Sep 2022 09:40:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=oOtsIfLgo+dpW6bJd1WimKnWJ8hG0+yd1C7QnZJgzys=; b=NLEjy+firPpiQwLoDTWKF2YlJU06b7+MpQCjV9boLFcGlndFOsSeLn4xVITIO7j1VY 3oYDGu/QrFrJp0lH7j5JnP43Q0ozPiidOwZiERCRViBoXL+ySmscfO84ZNklVxkzSstF 3z1XYaEmSgAWcdrqm0P9e/9I87jTUM2Ktdxc8OihgL204wniUGX9uooTHatLhmYtFYp6 NdGaE88tHGNEt514DJNVD55o6v3qLlrVmnRGTkVhWmLW5LzRlZds9toqv82dmQh5FHDv 65GriHVlpGkKAWAWHDojF8N+ad5NPHupswjGtn0ujB3Ap3k3VVTv6S+XsBCh1TD43pdA uq/g== 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; bh=oOtsIfLgo+dpW6bJd1WimKnWJ8hG0+yd1C7QnZJgzys=; b=dN3KAlyR60JTL5azlrjsDeLWw+kV6YfNPgdooOySQjG7X5icf3rPoVUPKDQB2PbBSt m1hx4hG5D0S1d6Fd1uUOj77qRQBVeR0r1wE7sPVI1ZIVFckjgpR6TAWaG2ND3RLNef+/ WTBeIxdnVaVumxskWRxvhE+hcqpC2qdNnimuC9xeApkwro3pWW8F9pJkJl+1OUeA4mpw KNFhFn2rfocQMD8v5ffLLTV3SmhuvcELbwON6ohCw8N3HoKaScOKxnF0rvu/RERSG2zk KvjU8AmX7OeVc27ahZNv8Moeofai9VAl6XtSR3lpmOrlAKnNkGixP7AYc61kJkFvEiuj smug== X-Gm-Message-State: ACgBeo2cSd0QMbBI1p9rwoIOawDoVWhnFlsW30tVZRE6PHVMVmf6Csoo 4jiZsDusl9CYL1JmCDzxmUlnv27C1DInUQ== X-Google-Smtp-Source: AA6agR5aqyqDQj8p4rDj/DRP4aqjwXj4zv8D3N4lHGDYenpdWlbkDHCrOsWAlxztCdbeU0pA3oV2wQ== X-Received: by 2002:a05:6214:27e4:b0:476:be6a:91c1 with SMTP id jt4-20020a05621427e400b00476be6a91c1mr3810500qvb.39.1662568854158; Wed, 07 Sep 2022 09:40:54 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-142-162-113-129.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.113.129]) by smtp.gmail.com with ESMTPSA id x11-20020ac87ecb000000b0031ee918e9f9sm12833581qtj.39.2022.09.07.09.40.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Sep 2022 09:40:53 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.95) (envelope-from ) id 1oVy6e-008gbP-Tw; Wed, 07 Sep 2022 13:40:52 -0300 Date: Wed, 7 Sep 2022 13:40:52 -0300 From: Jason Gunthorpe To: Alex Williamson Cc: David Hildenbrand , "Tian, Kevin" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "lpivarc@redhat.com" , "Liu, Jingqi" , "Lu, Baolu" Subject: Re: [PATCH] vfio/type1: Unpin zero pages Message-ID: References: <166182871735.3518559.8884121293045337358.stgit@omen> <20220907095552.336c8f34.alex.williamson@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220907095552.336c8f34.alex.williamson@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 07, 2022 at 09:55:52AM -0600, Alex Williamson wrote: > > So, if we go back far enough in the git history we will find a case > > where PUP is returning something for the zero page, and that something > > caused is_invalid_reserved_pfn() == false since VFIO did work at some > > point. > > Can we assume that? It takes a while for a refcount leak on the zero > page to cause an overflow. My assumption is that it's never worked, we > pin zero pages, don't account them against the locked memory limits > because our is_invalid_reserved_pfn() test returns true, and therefore > we don't unpin them. Oh, you think it has been buggy forever? That is not great.. > > IHMO we should simply go back to the historical behavior - make > > is_invalid_reserved_pfn() check for the zero_pfn and return > > false. Meaning that PUP returned it. > > We've never explicitly tested for zero_pfn and as David notes, > accounting the zero page against the user's locked memory limits has > user visible consequences. VMs that worked with a specific locked > memory limit may no longer work. Yes, but the question is if that is a strict ABI we have to preserve, because if you take that view it also means because VFIO has this historical bug that David can't fix the FOLL_FORCE issue either. If the view holds for memlock then it should hold for cgroups also. This means the kernel can never change anything about GFP_KERNEL_ACCOUNT allocations because it might impact userspace having set a tight limit there. It means we can't fix the bug that VFIO is using the wrong storage for memlock. It means qemu can't change anything about how it sets up this memory, ie Kevin's idea to change the ordering. On the other hand the "abi break" we are talking about is that a user might have to increase a configured limit in a config file after a kernel upgrade. IDK what consensus exists here, I've never heard of anyone saying these limits are a strict ABI like this.. I think at least for cgroup that would be so invasive as to immediately be off the table. Jason