Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp454607rwd; Tue, 16 May 2023 03:32:23 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7CeXvjPNwCx/qlmA1m3o3ec/IOyZMf9eIntWTgzoWH/fc6nc0TihagOmRyj/5TQY1wIsj+ X-Received: by 2002:a17:902:e852:b0:1a9:433e:41e7 with SMTP id t18-20020a170902e85200b001a9433e41e7mr39676437plg.43.1684233143543; Tue, 16 May 2023 03:32:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684233143; cv=none; d=google.com; s=arc-20160816; b=cqA89RjKzuUmke0izVi5Eb/uJLCOdTqJhFIfy6uUce01HcQdYeMOchCkHmy6gWjCZV gXCiy3tMZ1CBUHZ3NmqSzDrDSlcJM9//Xm9q35UgMPX0nr3so0zFuKX5TEgm1cJtt+7N fn7LfD9tRs4jNzZwtn9p0hxSCBam8jJu6gphBUGNRfk8XQW85fmHEPNKlyI6MIlo7IGU YueerpUPCRuToNBRQBD6N824p7ubyEwXUsEW3PO4d5w2EMNMjPE1VFueDgUS6vEDQSKF NoZqMUOKDTjbA581/IaUww5xkcxGCMTbqvXRdPqFO6dF1EJ/gQFGbmI9yjdU0sOAavgN 7heQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:subject :organization:from:references:cc:to:content-language:user-agent :mime-version:date:message-id:dkim-signature; bh=DdwZekQhQhJYfD71ineBvZDWMF1v7qroVT5L1UXxv4Y=; b=dNabpm+Mb6ZIErO4es1x07fdfBmy2eEAOkOoev6sckchU7aQIKhawbPjci/UNx3GlE RXHXZksm0KayUCOdCbNy+2cXF0L9SofNiETRaP+NGuSXmJnEoQ56S508qMhvUBfzePcO 7PAJXUd958IGTQM9vZwXTT+41BYy1nWMVQeistP2+OcLx6PWXRDVDIKwqzAiOxw/BELj AykFyN0VM/MY1GdpGf4gL11eQaih4TWAp2xIgS+ni3OKFzfZn2wMoL5ak7xb1xzta/jI I6gMcmaNC+REhVxSDOcUmyCd+jA43e+q2fIAPQaWALvWLof1Nad8id1LFcHLcHVEDblE 6Ogg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="BJLmKJH/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bd2-20020a170902830200b001a804319df8si17324858plb.391.2023.05.16.03.32.09; Tue, 16 May 2023 03:32:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="BJLmKJH/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232315AbjEPKW6 (ORCPT + 99 others); Tue, 16 May 2023 06:22:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50380 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232252AbjEPKWp (ORCPT ); Tue, 16 May 2023 06:22:45 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5C5ED2738 for ; Tue, 16 May 2023 03:21:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1684232516; 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=DdwZekQhQhJYfD71ineBvZDWMF1v7qroVT5L1UXxv4Y=; b=BJLmKJH/+DqLPoaghhFc3uDuMNe1iWdl6Z5VnoOsIyjD7ypWzdGOFt/lYPDua3+5sc3G2Y uGl4QbTUvj0zM3bIhaVLwwLKip7EZvNQdI3CA49SOjkDWsZF1EViw1qIqNcpUpEh2je6KS aRAH03hFn/6QNuCRQ/Y+PmQmHn9s2es= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-447-YnCaYPAoPP2jcxw6BwBWIg-1; Tue, 16 May 2023 06:21:55 -0400 X-MC-Unique: YnCaYPAoPP2jcxw6BwBWIg-1 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-3078b9943d6so4099306f8f.1 for ; Tue, 16 May 2023 03:21:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684232514; x=1686824514; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=DdwZekQhQhJYfD71ineBvZDWMF1v7qroVT5L1UXxv4Y=; b=NMkt/Rzvos/NnHsNKTZzBs5CjXTdXwgKhBxPNdVMMBl6FRPtjh5rwbxsWtrx91+efL PxTKgxLxXo++FGrO8UDht6LIibn3ZMIvD3dO2tinOPzMFJtu2zB0EaAfPvsBY5mkuyXM DPOOamE0qVAWZT4b9IL5KcIs9VW0DvoYWzPmgO2gc7wF+eO5hN+0S4TEEEubxFMwoRAc l9QJwXIeHESdAVjalRMdh3uTS0jiwOuZnhCfz2JCzxaH915FB3DvC6ps0SXjml20TDS+ tCf2t+UBmQex4A4NZOJm5D5bbhrMyZuo4HtzH2uYJSeQPPrSSILjhnzlB4fa+q5lfAy4 wmFw== X-Gm-Message-State: AC+VfDzbEiUt/mvUpWmgRBRDKCgK0PkxEX3WobHHKHIyGWnBBJcyjfMb hTTCVGZVrWJ6qp3lMldPcAfQtex3Y9KuEA81sUwjvFrzenABRxHo423J1OYvbXuENnaDH9qcBMi HE+1762yNapKj+pJsxnDl7kxN X-Received: by 2002:a5d:6ad2:0:b0:306:3b39:9a3d with SMTP id u18-20020a5d6ad2000000b003063b399a3dmr28037432wrw.15.1684232513857; Tue, 16 May 2023 03:21:53 -0700 (PDT) X-Received: by 2002:a5d:6ad2:0:b0:306:3b39:9a3d with SMTP id u18-20020a5d6ad2000000b003063b399a3dmr28037403wrw.15.1684232513432; Tue, 16 May 2023 03:21:53 -0700 (PDT) Received: from ?IPV6:2003:cb:c74f:2500:1e3a:9ee0:5180:cc13? (p200300cbc74f25001e3a9ee05180cc13.dip0.t-ipconnect.de. [2003:cb:c74f:2500:1e3a:9ee0:5180:cc13]) by smtp.gmail.com with ESMTPSA id t1-20020a5d5341000000b002ff2c39d072sm2092106wrv.104.2023.05.16.03.21.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 May 2023 03:21:52 -0700 (PDT) Message-ID: Date: Tue, 16 May 2023 12:21:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US To: Sean Christopherson , Lorenzo Stoakes Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Matthew Wilcox , x86@kernel.org, linux-sgx@vger.kernel.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, kvm@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Jarkko Sakkinen , "H . Peter Anvin" , Xinhui Pan , David Airlie , Daniel Vetter , Dimitri Sivanich , Arnd Bergmann , Greg Kroah-Hartman , Paolo Bonzini , Jens Axboe , Pavel Begunkov , Jason Gunthorpe , John Hubbard , Christian Konig , Jason Gunthorpe References: From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v5 1/6] mm/gup: remove unused vmas parameter from get_user_pages() In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15.05.23 21:07, Sean Christopherson wrote: > On Sun, May 14, 2023, Lorenzo Stoakes wrote: >> No invocation of get_user_pages() use the vmas parameter, so remove it. >> >> The GUP API is confusing and caveated. Recent changes have done much to >> improve that, however there is more we can do. Exporting vmas is a prime >> target as the caller has to be extremely careful to preclude their use >> after the mmap_lock has expired or otherwise be left with dangling >> pointers. >> >> Removing the vmas parameter focuses the GUP functions upon their primary >> purpose - pinning (and outputting) pages as well as performing the actions >> implied by the input flags. >> >> This is part of a patch series aiming to remove the vmas parameter >> altogether. >> >> Suggested-by: Matthew Wilcox (Oracle) >> Acked-by: Greg Kroah-Hartman >> Acked-by: David Hildenbrand >> Reviewed-by: Jason Gunthorpe >> Acked-by: Christian K�nig (for radeon parts) >> Acked-by: Jarkko Sakkinen >> Signed-off-by: Lorenzo Stoakes >> --- >> arch/x86/kernel/cpu/sgx/ioctl.c | 2 +- >> drivers/gpu/drm/radeon/radeon_ttm.c | 2 +- >> drivers/misc/sgi-gru/grufault.c | 2 +- >> include/linux/mm.h | 3 +-- >> mm/gup.c | 9 +++------ >> mm/gup_test.c | 5 ++--- >> virt/kvm/kvm_main.c | 2 +- >> 7 files changed, 10 insertions(+), 15 deletions(-) > > Acked-by: Sean Christopherson (KVM) > >> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c >> index cb5c13eee193..eaa5bb8dbadc 100644 >> --- a/virt/kvm/kvm_main.c >> +++ b/virt/kvm/kvm_main.c >> @@ -2477,7 +2477,7 @@ static inline int check_user_page_hwpoison(unsigned long addr) >> { >> int rc, flags = FOLL_HWPOISON | FOLL_WRITE; >> >> - rc = get_user_pages(addr, 1, flags, NULL, NULL); >> + rc = get_user_pages(addr, 1, flags, NULL); >> return rc == -EHWPOISON; > > Unrelated to this patch, I think there's a pre-existing bug here. If gup() returns > a valid page, KVM will leak the refcount and unintentionally pin the page. That's When passing NULL as "pages" to get_user_pages(), __get_user_pages_locked() won't set FOLL_GET. As FOLL_PIN is also not set, we won't be messing with the mapcount of the page. So even if get_user_pages() returns "1", we should be fine. Or am I misunderstanding your concern? At least hva_to_pfn_slow() most certainly didn't return "1" if we end up calling check_user_page_hwpoison(), so nothing would have been pinned there as well. -- Thanks, David / dhildenb