Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp1353107ybg; Fri, 18 Oct 2019 16:33:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqwYPLETcXIjqGAnjeqYzHxIzfR3KWPV4VMLcmmk7Vw970M3HPU9QBNTgm1gHQ91Ct6VbHS+ X-Received: by 2002:a50:f701:: with SMTP id g1mr12430259edn.62.1571441595834; Fri, 18 Oct 2019 16:33:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571441595; cv=none; d=google.com; s=arc-20160816; b=K+KQRM8yOBFrWV2vSRoZdVC6XzlPtwFxlrE5hOF3c8rRpCY0Qn4bFkYcFj4b4r7kEB axTS+WkIsekz3UaI1tBeokopfEwtVBCq03/TRbmfs35B5fEVcyafBybN/RMZKGKU6c7N bcNwlpdxkQH6BxivFACYlXnyWjCu/eX4KzyG7UTHyIAUmhbqSKQqgAshSfsno9L88c3+ 7ryt7lNyYqFaRX15E3Ev4CqslXC74y21MwIfDdhvUA/+zAsdvOpMoyKpzVwbsWh3bCYH Ze+CjA9R2FW4avG55t7lQ1RJpUL3djK9QQ28GBMFWK+QPlsP77/c7JSKFpokoJoGo8Yj aTFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=68TuUk720iz5VgClytk4RHXNy74rGF4fefVvtRkLtn4=; b=EddZaXAvAeO/M5sFhRtis+BW6JvxswtzUrgf6G979kx/YnPXqianjwVrW9Lwq+R041 a1FVIlpueiHQpe1UoWAwzxz806H0dQdrqujckQjXy1uZamIiPv8NbeZD24C8pZo16hIP n5OzVzUQEafGMWBsDrPTRgfQlfuTQVbaWcmNpCFWhDiPIcC5d73l5Futr8UlaloMD4HO 4izNT5ykatGMcMVQCNojwpHAoVY9kK2WOEJZKqcVKUglFsv06qnYveHy1U1IDYHzdmDv Rmgqkkk4A+SPsyXQUUb6lpyZeYB0s8EZB3JkNEJESl0m+l0WneQz67Gr4ABSaVLXsfFC qn7w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id gl26si4450395ejb.17.2019.10.18.16.32.52; Fri, 18 Oct 2019 16:33:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2504410AbfJRGmf (ORCPT + 99 others); Fri, 18 Oct 2019 02:42:35 -0400 Received: from out30-130.freemail.mail.aliyun.com ([115.124.30.130]:42106 "EHLO out30-130.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730508AbfJRGmf (ORCPT ); Fri, 18 Oct 2019 02:42:35 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R121e4;CH=green;DM=||false|;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04394;MF=luoben@linux.alibaba.com;NM=1;PH=DS;RN=3;SR=0;TI=SMTPD_---0TfNs02I_1571380952; Received: from bn0418deMacBook-Pro.local(mailfrom:luoben@linux.alibaba.com fp:SMTPD_---0TfNs02I_1571380952) by smtp.aliyun-inc.com(127.0.0.1); Fri, 18 Oct 2019 14:42:33 +0800 Subject: Re: [PATCH] vfio/type1: remove hugepage checks in is_invalid_reserved_pfn() To: alex.williamson@redhat.com Cc: aarcange@redhat.com, linux-kernel@vger.kernel.org References: <1d6b7e1c40783f2db4c6cb15bf679a94222ec6a3.1570073993.git.luoben@linux.alibaba.com> <20191003164133.GG13922@redhat.com> From: Ben Luo Message-ID: Date: Fri, 18 Oct 2019 14:42:32 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20191003164133.GG13922@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org A friendly reminder :) Thanks,     Ben 在 2019/10/4 上午12:41, Andrea Arcangeli 写道: > On Thu, Oct 03, 2019 at 11:49:42AM +0800, Ben Luo wrote: >> Currently, no hugepage split code can transfer the reserved bit >> from head to tail during the split, so checking the head can't make >> a difference in a racing condition with hugepage spliting. >> >> The buddy wouldn't allow a driver to allocate an hugepage if any >> subpage is reserved in the e820 map at boot, if any driver sets the >> reserved bit of head page before mapping the hugepage in userland, >> it needs to set the reserved bit in all subpages to be safe. >> >> Signed-off-by: Ben Luo > Reviewed-by: Andrea Arcangeli > > >> --- >> drivers/vfio/vfio_iommu_type1.c | 26 ++++---------------------- >> 1 file changed, 4 insertions(+), 22 deletions(-) >> >> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c >> index 054391f..e2019ba 100644 >> --- a/drivers/vfio/vfio_iommu_type1.c >> +++ b/drivers/vfio/vfio_iommu_type1.c >> @@ -287,31 +287,13 @@ static int vfio_lock_acct(struct vfio_dma *dma, long npage, bool async) >> * Some mappings aren't backed by a struct page, for example an mmap'd >> * MMIO range for our own or another device. These use a different >> * pfn conversion and shouldn't be tracked as locked pages. >> + * For compound pages, any driver that sets the reserved bit in head >> + * page needs to set the reserved bit in all subpages to be safe. >> */ >> static bool is_invalid_reserved_pfn(unsigned long pfn) >> { >> - if (pfn_valid(pfn)) { >> - bool reserved; >> - struct page *tail = pfn_to_page(pfn); >> - struct page *head = compound_head(tail); >> - reserved = !!(PageReserved(head)); >> - if (head != tail) { >> - /* >> - * "head" is not a dangling pointer >> - * (compound_head takes care of that) >> - * but the hugepage may have been split >> - * from under us (and we may not hold a >> - * reference count on the head page so it can >> - * be reused before we run PageReferenced), so >> - * we've to check PageTail before returning >> - * what we just read. >> - */ >> - smp_rmb(); >> - if (PageTail(tail)) >> - return reserved; >> - } >> - return PageReserved(tail); >> - } >> + if (pfn_valid(pfn)) >> + return PageReserved(pfn_to_page(pfn)); >> >> return true; >> } >> -- >> 1.8.3.1 >>