Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp126853ybm; Mon, 20 May 2019 13:09:07 -0700 (PDT) X-Google-Smtp-Source: APXvYqzmTSIw3H8MEpEWDwmDhPsg3Sk99FKyxzInVyDGMHE04P7ZHhlTD/f3LborqHOkEYwLEKSm X-Received: by 2002:a63:4852:: with SMTP id x18mr63980772pgk.14.1558382947239; Mon, 20 May 2019 13:09:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558382947; cv=none; d=google.com; s=arc-20160816; b=lKp984ProcZRFvj4e6a0dpduvWEneV6w5plqdPL6mk+QSCIbydJUmJp/7C+2iUOsKG oY+08qCUx9YK8U4FKV702vOqU4FAnNIkOPaVdqxkZ2RFPoZWUm46sJX0clKWcE98HIWA 1jwFVx+jwxbF8QvAEgXehN1NSI/k7d2SirIJkRqgBFYtWTAbQXAF6jAuKgUj1hXY+e2W G/o+RAk7L0FbzQrzifgcRFFdO62PyAALn1NIUMlgJODvA0I+IwBHHjNGM+ot9WMSzxug s/mmApLVLB309UpD7ts/Rc2t5NoxI6VEWGH01KMBeSRs73R6u0+AHKishldC0HFUySfy gsJw== 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:mime-version :message-id:date:subject:cc:to:from; bh=qowZ2i4k4nLKiOpM66jf6dGGC4HkFcJRHZmVLzfMaho=; b=J3Kq53DZ7k9/fZh66espNRoQLy+2rlaD0HKZ14qB3mKHtC4ihKFb529/17BJNuVQ7q nfV5jN96qnYByTwVxVQ31SexXioWwPX0FrUZWCpAYmm9/lZQ/7TyLuS4rbxv/WG2+xa7 cDEAuX6IV7Y9CxrHpVAZLXpdMS0GrCfVpLeFIUOIJEBOm1oOn/Zv14rJdBLabMwDnDOw VdglNYq+y1FIelabv6iNa778KAwQuYfUz17yfeH76LccOQnDWjZ4Be2t+RB1m0xIfsLU DhINk4JxHoown4eVS4TMKAffQISuLaep0rRll9FpBT5YssBxzYDBQoiL3BIBmHmdegLK 53hg== 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z19si18955696pfa.260.2019.05.20.13.08.52; Mon, 20 May 2019 13:09:07 -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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726088AbfETUHu (ORCPT + 99 others); Mon, 20 May 2019 16:07:50 -0400 Received: from mga11.intel.com ([192.55.52.93]:5053 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725372AbfETUHt (ORCPT ); Mon, 20 May 2019 16:07:49 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 May 2019 13:07:49 -0700 X-ExtLoop1: 1 Received: from cavannie-mobl1.amr.corp.intel.com (HELO localhost.intel.com) ([10.254.114.95]) by fmsmga007.fm.intel.com with ESMTP; 20 May 2019 13:07:48 -0700 From: Rick Edgecombe To: linux-kernel@vger.kernel.org, peterz@infradead.org, sparclinux@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org Cc: dave.hansen@intel.com, namit@vmware.com, Rick Edgecombe , Meelis Roos , "David S. Miller" , Borislav Petkov , Andy Lutomirski , Ingo Molnar Subject: [PATCH v2] vmalloc: Fix issues with flush flag Date: Mon, 20 May 2019 13:07:03 -0700 Message-Id: <20190520200703.15997-1-rick.p.edgecombe@intel.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Switch VM_FLUSH_RESET_PERMS to use a regular TLB flush intead of vm_unmap_aliases() and fix calculation of the direct map for the CONFIG_ARCH_HAS_SET_DIRECT_MAP case. Meelis Roos reported issues with the new VM_FLUSH_RESET_PERMS flag on a sparc machine. On investigation some issues were noticed: 1. The calculation of the direct map address range to flush was wrong. This could cause problems on x86 if a RO direct map alias ever got loaded into the TLB. This shouldn't normally happen, but it could cause the permissions to remain RO on the direct map alias, and then the page would return from the page allocator to some other component as RO and cause a crash. 2. Calling vm_unmap_alias() on vfree could potentially be a lot of work to do on a free operation. Simply flushing the TLB instead of the whole vm_unmap_alias() operation makes the frees faster and pushes the heavy work to happen on allocation where it would be more expected. In addition to the extra work, vm_unmap_alias() takes some locks including a long hold of vmap_purge_lock, which will make all other VM_FLUSH_RESET_PERMS vfrees wait while the purge operation happens. 3. page_address() can have locking on some configurations, so skip calling this when possible to further speed this up. Fixes: 868b104d7379 ("mm/vmalloc: Add flag for freeing of special permsissions") Reported-by: Meelis Roos Cc: Meelis Roos Cc: Peter Zijlstra Cc: "David S. Miller" Cc: Dave Hansen Cc: Borislav Petkov Cc: Andy Lutomirski Cc: Ingo Molnar Cc: Nadav Amit Signed-off-by: Rick Edgecombe --- Changes since v1: - Update commit message with more detail - Fix flush end range on !CONFIG_ARCH_HAS_SET_DIRECT_MAP case mm/vmalloc.c | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index c42872ed82ac..8d03427626dc 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2122,9 +2122,10 @@ static inline void set_area_direct_map(const struct vm_struct *area, /* Handle removing and resetting vm mappings related to the vm_struct. */ static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages) { + const bool has_set_direct = IS_ENABLED(CONFIG_ARCH_HAS_SET_DIRECT_MAP); + const bool flush_reset = area->flags & VM_FLUSH_RESET_PERMS; unsigned long addr = (unsigned long)area->addr; - unsigned long start = ULONG_MAX, end = 0; - int flush_reset = area->flags & VM_FLUSH_RESET_PERMS; + unsigned long start = addr, end = addr + area->size; int i; /* @@ -2133,7 +2134,7 @@ static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages) * This is concerned with resetting the direct map any an vm alias with * execute permissions, without leaving a RW+X window. */ - if (flush_reset && !IS_ENABLED(CONFIG_ARCH_HAS_SET_DIRECT_MAP)) { + if (flush_reset && !has_set_direct) { set_memory_nx(addr, area->nr_pages); set_memory_rw(addr, area->nr_pages); } @@ -2146,22 +2147,24 @@ static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages) /* * If not deallocating pages, just do the flush of the VM area and - * return. + * return. If the arch doesn't have set_direct_map_(), also skip the + * below work. */ - if (!deallocate_pages) { - vm_unmap_aliases(); + if (!deallocate_pages || !has_set_direct) { + flush_tlb_kernel_range(start, end); return; } /* * If execution gets here, flush the vm mapping and reset the direct * map. Find the start and end range of the direct mappings to make sure - * the vm_unmap_aliases() flush includes the direct map. + * the flush_tlb_kernel_range() includes the direct map. */ for (i = 0; i < area->nr_pages; i++) { - if (page_address(area->pages[i])) { + addr = (unsigned long)page_address(area->pages[i]); + if (addr) { start = min(addr, start); - end = max(addr, end); + end = max(addr + PAGE_SIZE, end); } } @@ -2171,7 +2174,7 @@ static void vm_remove_mappings(struct vm_struct *area, int deallocate_pages) * reset the direct map permissions to the default. */ set_area_direct_map(area, set_direct_map_invalid_noflush); - _vm_unmap_aliases(start, end, 1); + flush_tlb_kernel_range(start, end); set_area_direct_map(area, set_direct_map_default_noflush); } -- 2.20.1