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 5CE47C38145 for ; Wed, 7 Sep 2022 23:07:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229770AbiIGXHJ (ORCPT ); Wed, 7 Sep 2022 19:07:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39824 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229498AbiIGXHH (ORCPT ); Wed, 7 Sep 2022 19:07:07 -0400 Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BA8FFC3F53 for ; Wed, 7 Sep 2022 16:07:05 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id i9so5714530qka.0 for ; Wed, 07 Sep 2022 16:07:05 -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=Y6pRZpUk+zqaAgkCeIzS94fxs7LngDZcMEpib2+hGHU=; b=XCUZAaiRUr0RkAx/wyAOWDoxJGpoaofe4IUIO/Z4Oj23HH/8Urq1SfH3RW3VimcAP5 IOTaBqpNj8onlQC3ycH4M0G0A4WmAc1fT0FEeWGmMat1xZzbccHl8J4HnZYU/aknykxv tRd4/RckrstTOXlmLCrRpfC5iEPklCqhMK6zyPVQUlpEFYEr6HSfvArSgh71TLa391za rDDJABnJcSSOQnCQA1lgy8iDR3JABCqHo9GsZFYp6FRlXfyac/6rhXAwER6RNXhVkegu ORCJhcreg7IMOa/nzMPQCFubSlyUpUI/QniDJb8ekn3YwPl1WozkLuyMLSVXRMO+Uhbv 8Z/A== 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=Y6pRZpUk+zqaAgkCeIzS94fxs7LngDZcMEpib2+hGHU=; b=oyBpoIzZ6WUxNRWHXjxQkgl2Q0tJmwuTDKqiAap/HM8PUz456TZOOBokbwM37iYmkl m3iIzKI0ljhJlEGHmwAl/3T8CHkavyGdxrKL/ctf1KGS/MTfjIyA7v/XY5pmcxMwiG1h qE8hxaoio4XhEDPbqrMDinoHDz+2JGy+JNBMR6m3dW4qIPQek/m36Tgibpg2JNFYkRyX R97BarZJoFVZH13Jqy7oNrCTkiIa45ahJ9t7AV/BLaN4otV8atWwN5vawmhWrZE4YAH8 +0g7kVLsWFWwTrzLPcB/cOJhtQwn0OGeCmBIGHoo/73ZxJGrLYjz4FeI+8CywERXlvFh tcHw== X-Gm-Message-State: ACgBeo273FCEoqUcYlP5gtEx8tsTVGCSBFKTbs+uGzzBok5eSFMngeC/ u3OhVeYgdQp9OI4PkAFG9ytbsQ== X-Google-Smtp-Source: AA6agR46JVb2VgdODErJDQ3TfpF3Ib1qSU9Zudl8rH41hD23soYZBVWx17Pt9oLzp9F++lek2CxVTw== X-Received: by 2002:a05:620a:2805:b0:6bc:5d4a:9618 with SMTP id f5-20020a05620a280500b006bc5d4a9618mr4640301qkp.116.1662592024471; Wed, 07 Sep 2022 16:07:04 -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 bq30-20020a05620a469e00b006b95b0a714esm15301930qkb.17.2022.09.07.16.07.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Sep 2022 16:07:03 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.95) (envelope-from ) id 1oW48M-008nme-E3; Wed, 07 Sep 2022 20:07:02 -0300 Date: Wed, 7 Sep 2022 20:07:02 -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: <20220907095552.336c8f34.alex.williamson@redhat.com> <20220907125627.0579e592.alex.williamson@redhat.com> <20220907142416.4badb879.alex.williamson@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220907142416.4badb879.alex.williamson@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 07, 2022 at 02:24:16PM -0600, Alex Williamson wrote: > Also, I want to clarify, is this a recommendation relative to the > stable patch proposed here, or only once we get rid of shared zero page > pinning? We can't simply do accounting on the shared zero page since a > single user can overflow the refcount. Yes, here I would account properly in a way that keeps working for future GUP changes because if something goes wrong with this simple patch it has a simple fix. Trialing it will get some good data to inform what David's patch should do. Overall have the feeling that a small group of people might grumble that their limits break, but with a limit adjustment they can probably trivially move on. It would be very interesting to see if someone feels like the issue is important enough to try and get something changed. You could also fix it by just using FOLL_FORCE (like RDMA/io_uring does), which fixes the larger issue Kevin noted that the ROM doesn't become visible to DMA. Jason