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 X-Spam-Level: X-Spam-Status: No, score=-11.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DD685C433DB for ; Fri, 5 Feb 2021 18:14:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 45C0264FCB for ; Fri, 5 Feb 2021 18:14:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 45C0264FCB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 950056B0070; Fri, 5 Feb 2021 13:14:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8D7546B0071; Fri, 5 Feb 2021 13:14:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7C71F6B0073; Fri, 5 Feb 2021 13:14:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0148.hostedemail.com [216.40.44.148]) by kanga.kvack.org (Postfix) with ESMTP id 668156B0070 for ; Fri, 5 Feb 2021 13:14:19 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 2BC38181AC9CB for ; Fri, 5 Feb 2021 18:14:19 +0000 (UTC) X-FDA: 77785013838.26.sun99_140a6b9275e6 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id E0B9B1804B66B for ; Fri, 5 Feb 2021 18:14:18 +0000 (UTC) X-HE-Tag: sun99_140a6b9275e6 X-Filterd-Recvd-Size: 5718 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf11.hostedemail.com (Postfix) with ESMTP for ; Fri, 5 Feb 2021 18:14:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612548857; 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=b+b6OD3StrUZhviTTkgah8uKJMjMpGgyYUl7CSN7rcs=; b=KLwHxzO1K9pDiAeWk+fiuy5Xb9zVKDMzhtzexhYZZ1/MZt6v+2zEFxAxdmFywAhFxe30IK O0jQpV1MxlmBXj/DtoBePIRhZz8wGMRalJgw8IQZLlmhU4RbrgZrbGeI53gnteIMiwGrAz TtGI0KhYTXxohxEW8dcyJS5mI2Uqd+Q= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-603-nATqH6TkNUq3Rd_dHcz8tg-1; Fri, 05 Feb 2021 13:14:14 -0500 X-MC-Unique: nATqH6TkNUq3Rd_dHcz8tg-1 Received: by mail-qv1-f69.google.com with SMTP id l3so5622406qvz.12 for ; Fri, 05 Feb 2021 10:14:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=b+b6OD3StrUZhviTTkgah8uKJMjMpGgyYUl7CSN7rcs=; b=eIEwwVjOrXCh8mSmYhksvLCqtA2Fu6ya+myYfoXTu0N+lk8ZJtDFZfcK0+rmwVO/j5 +XWEKu7gGpIcwXf/MMqu1Mqd2KasUq/8oukcSt7Oys52IsJmOqjcoqxxGZlfyd1n8N/K Qx9VPHE5H4vCkvbHsjNIRQ6xUurSuSY8EVTIig4fFJg9jmcEaBRrss3wcqCBVDSs6Oe1 4TiKQTbrHqhdHS8dqJDT3LeDGEHsN/HZHwvfIOu18va/gF6JR8Wg+IOdOvknYcs7+E8X BAmUrqmfSBGFIvxMkKwIKQe8QJolRGA60/cMFOyXyAXma/SjaHyINyzAFVPJYLjOB9VO cP+Q== X-Gm-Message-State: AOAM532IbmQ9wyGphaWz8W87cE/s1aQI9E7RW37sf2EnS2j4rKo8MwGq XyfvLu31Glj6Zc8pLgPn68X6XbRDOHELJPwHfErf/S1PMH3J8b3C9/TShNfek7i3ZMOFQ5DjikC ZMaBXASwW9pk= X-Received: by 2002:a05:620a:530:: with SMTP id h16mr5623533qkh.136.1612548853768; Fri, 05 Feb 2021 10:14:13 -0800 (PST) X-Google-Smtp-Source: ABdhPJw2dxqnZovOeKuwXlYA9ZoMH6h3WcLq3ydNuPij1rSRR/WcmyfdGA897c3rYVPJ5YdnoImrSg== X-Received: by 2002:a05:620a:530:: with SMTP id h16mr5623516qkh.136.1612548853537; Fri, 05 Feb 2021 10:14:13 -0800 (PST) Received: from xz-x1 (bras-vprn-toroon474qw-lp130-20-174-93-89-182.dsl.bell.ca. [174.93.89.182]) by smtp.gmail.com with ESMTPSA id i65sm9921618qkf.105.2021.02.05.10.14.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Feb 2021 10:14:12 -0800 (PST) Date: Fri, 5 Feb 2021 13:14:11 -0500 From: Peter Xu To: Paolo Bonzini Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, jgg@ziepe.ca, linux-mm@kvack.org, Andrew Morton , dan.j.williams@intel.com Subject: Re: [PATCH 0/2] KVM: do not assume PTE is writable after follow_pfn Message-ID: <20210205181411.GB3195@xz-x1> References: <20210205103259.42866-1-pbonzini@redhat.com> MIME-Version: 1.0 In-Reply-To: <20210205103259.42866-1-pbonzini@redhat.com> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=peterx@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline 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 Fri, Feb 05, 2021 at 05:32:57AM -0500, Paolo Bonzini wrote: > This series is the first step towards fixing KVM's usage of follow_pfn. > The immediate fix here is that KVM is not checking the writability of > the PFN, which actually dates back to way before the introduction of > follow_pfn in commit add6a0cd1c5b ("KVM: MMU: try to fix up page faults > before giving up", 2016-07-05). There are more changes needed to > invalidate gfn-to-pfn caches from MMU notifiers, but this issue will > be tackled later. > > A more fundamental issue however is that the follow_pfn function is > basically impossible to use correctly. Almost all users for example > are assuming that the page is writable; KVM was not alone in this > mistake. follow_pte, despite not being exported for modules, is a > far saner API. Therefore, patch 1 simplifies follow_pte a bit and > makes it available to modules. > > Please review and possibly ack for inclusion in the KVM tree, > thanks! FWIW, the patches look correct to me (if with patch 2 report fixed): Reviewed-by: Peter Xu But I do have a question on why dax as the only user needs to pass in the notifier to follow_pte() for initialization. Indeed there're a difference on start/end init of the notifier depending on whether it's a huge pmd but since there's the pmdp passed over too so I assume the caller should know how to init the notifier anyways. The thing is at least in current code we could send meaningless notifiers, e.g., in follow_pte(): if (range) { mmu_notifier_range_init(range, MMU_NOTIFY_CLEAR, 0, NULL, mm, address & PAGE_MASK, (address & PAGE_MASK) + PAGE_SIZE); mmu_notifier_invalidate_range_start(range); } ptep = pte_offset_map_lock(mm, pmd, address, ptlp); if (!pte_present(*ptep)) goto unlock; *ptepp = ptep; return 0; unlock: pte_unmap_unlock(ptep, *ptlp); if (range) mmu_notifier_invalidate_range_end(range); The notify could be meaningless if we do the "goto unlock" path. Ideally it seems we can move the notifier code to caller (as what most mmu notifier users do) and we can also avoid doing that if follow_pte returned -EINVAL. Thanks, -- Peter Xu