Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp1671835ybn; Wed, 2 Oct 2019 21:18:28 -0700 (PDT) X-Google-Smtp-Source: APXvYqyNUF2ELYpkTP+5fpBa+6bsfsreN6ZZhwn3yS7DxTQKYFl+/mfK3DI5p26QiQzZT+jAw5Yp X-Received: by 2002:a17:906:4e57:: with SMTP id g23mr5955680ejw.264.1570076308552; Wed, 02 Oct 2019 21:18:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570076308; cv=none; d=google.com; s=arc-20160816; b=yuHaFpnlofA6HDI+1NuRDTUGhzjx0UaU2PsBiBQHmxpcgwjzmoLPWsAREuVILtw5u8 i+La3yS0PWhK14ieqqB7HOqNxSc05me0D1NIWLtguE/dhu9WJXtvNYMciryp4kc91i0C BvJocvqYMKS++V78KKp4YtKvPBkEMg1Ty2eAq+oSPBMFshK8VAFo4OB1B52tUwwO7fod ZusMcXxgX0J+0d6+Sin2Ovb/z3QolxeE5imorDaAgRTOcbQiJea4crkMWcv4ZtiFPspt 1p6Y7q+mAqe9YgkOU6docu6+hnetRjbz87ACzlf3Ff4aq86v7QM+JrAooRIHUs0wfkCi FRrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=ixEEhA30qR+z7Hx1TS/lcJ1tWN2sGRDGfNK1Rpmlfj4=; b=kELmLT0RKSY9AoAH5xQEfRJoHcboq8oZ+fb+u2NrSZGan6xVzOosvmjmSIW5RvZ52k fXKuj0J8PrTWrX3la5EpHZYv2ww2Kjqurw7p3qAavmwHGjtv+KG4flgN7qfIk0kUVEdW p3TtCABVyunUmmQnMApKIuBJe0V1D6v+RXGn8rguELARj2jMr5aFpjkqXNo6cG8DtAwH j+3CieX8VEBIyWjc0M/Fn7LDG9FZ4pmy43J3qJellfE3s4iewxFntcOufxyuiD7x1yZv Q3DIMXF4IwSN25f/htRFmdTDK6GMx3EXToLMX8lUowq3LPBx67TcLvC5q9Oqh9whpRuS cdOA== 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 n14si650956edv.377.2019.10.02.21.18.04; Wed, 02 Oct 2019 21:18:28 -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 S1728716AbfJCDtt (ORCPT + 99 others); Wed, 2 Oct 2019 23:49:49 -0400 Received: from out30-54.freemail.mail.aliyun.com ([115.124.30.54]:53530 "EHLO out30-54.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728693AbfJCDtt (ORCPT ); Wed, 2 Oct 2019 23:49:49 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R731e4;CH=green;DM=||false|;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04426;MF=luoben@linux.alibaba.com;NM=1;PH=DS;RN=3;SR=0;TI=SMTPD_---0Te-tQQX_1570074582; Received: from localhost(mailfrom:luoben@linux.alibaba.com fp:SMTPD_---0Te-tQQX_1570074582) by smtp.aliyun-inc.com(127.0.0.1); Thu, 03 Oct 2019 11:49:46 +0800 From: Ben Luo To: alex.williamson@redhat.com, aarcange@redhat.com Cc: linux-kernel@vger.kernel.org Subject: [PATCH] vfio/type1: remove hugepage checks in is_invalid_reserved_pfn() Date: Thu, 3 Oct 2019 11:49:42 +0800 Message-Id: <1d6b7e1c40783f2db4c6cb15bf679a94222ec6a3.1570073993.git.luoben@linux.alibaba.com> X-Mailer: git-send-email 1.8.3.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 --- 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