Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp194515ybm; Mon, 20 May 2019 14:27:56 -0700 (PDT) X-Google-Smtp-Source: APXvYqyZOYz2TjIStRNMHlu+15Ri+KuG67xmrgcQPIB7qe3POXy8Vgip23zp6KeZsAb/38kWzkVQ X-Received: by 2002:a17:902:4203:: with SMTP id g3mr59886253pld.288.1558387676680; Mon, 20 May 2019 14:27:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558387676; cv=none; d=google.com; s=arc-20160816; b=wOf5Njt7+j16IEPwCEf3OUmgp0UaGQPdU+csglAsuRWxGZxhzKlFybDe0Y66avJ4CT OQl9ohIU5nsyF25UtxDTawerqKsn27g+euYaYy48yGtNDjNGquktOBcnqsAtnO6qI1NZ X6t4Z4pvm4+0rQeNWW/dHOXUw1c38V6xZ842fmyDcrB2+0N8mZrrjtnHwCVgJCSHa1Dc 3pdt0iCzzUhCv9oyL0uhmyZBRjViVyWJSI56IwoAs9DckNoUL9Re+MdjxrF6behJhNg6 XncWMN97DcfK+9QV4oYR/biuN4mJG5XDU6GrNzV89+4PSSuSjvM/9KjzCp+IVkHW/0n6 19Mw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature; bh=4baXS4Zs8d273Gy9o882X9zO8lduTnF92DlMmytV05M=; b=06qVHza+MicUt+YboNMsMue6wc8mgCWzAmzE96uyghD58m4jK2LCFCdAAGaxjvQqUH NM5GjhUof21AWU/pN9/xsI1sHyVm+rTD+bmLHvlP1IbEIQNCPZydgcqBBX3MLOOfpt8W 245Gj5aWCvUsmiiVoRMynDg1xlen3V5ZymGb60R+1/H2HN1jTa4FZ+HbqIxusXKwO27X be+mUzJBx6/rbYzKE5exvxtHQOr5LJ5g3nbpz+kPCVZD05EW4hNpOYFoq848AnMF4Xvf h7g8ukAg6wG/H8pdeDgb4w2zX2lvjxkpCfFqLaYPVFvhE0nVJCGcxJVuB3r2YsKJ8ucN jLaw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=hxUvmxG7; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 11si20347056pfn.80.2019.05.20.14.27.41; Mon, 20 May 2019 14:27:56 -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; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=hxUvmxG7; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726899AbfETVZY (ORCPT + 99 others); Mon, 20 May 2019 17:25:24 -0400 Received: from mail-pl1-f193.google.com ([209.85.214.193]:33523 "EHLO mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726357AbfETVZY (ORCPT ); Mon, 20 May 2019 17:25:24 -0400 Received: by mail-pl1-f193.google.com with SMTP id y3so7329037plp.0 for ; Mon, 20 May 2019 14:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4baXS4Zs8d273Gy9o882X9zO8lduTnF92DlMmytV05M=; b=hxUvmxG7ptkvVdHSpo2ElaBiNspTHcKC2JYgBrAVrG5y2EurML2f6nPrNKhA3NCeET 3Scsw7YYNXr9eL9Ca8ZCXuXSmefL1R3JtQEXbmOebdWIpphXM6nB+6J6N5ERaFt+V4pz XO1xDbC7HMcby+Vu7irR6zLKUHyBSWjTp30sFNmSfremzHtJFg8/ZC0q9CgsDQ1uXeG6 N+/hkHT9IIo99Z2PBwFnT6uOC+9lP8zJ4Q+z7WWXapY3F6DMOpY9ZTENw8KWiRuRZtRu qE/JhUJO2LMKhhRceIMpKfqFzg2P6lMF3lnqFRAMUrUJ9CPp4LFxeCPslwMPAqnnQjpq kGlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4baXS4Zs8d273Gy9o882X9zO8lduTnF92DlMmytV05M=; b=ZflXCk42jS7daGB/3NhA9nK6KnNdQtTe8BFAE/Imgdit+EPu1UVqIdCJKv8bRWcEfo oQBoEjpYHoCGhC7zXK65n0PSis1vfoQtGt/Op7KUsWgxOkKvWDlgSulKYHfImYULNVit xG+wPrDrtJ60JaNkVIw4pNPYTFI0M3iyilBTgb6up/fjWfrg8fai8GO7ds07/k1owk4m 45QqRVS1HwhVkTGr4h7EGg7kpi0PoXwYSLTZW2A/1XQchBOaHGb9Fi7njh3s8lOjGFNs N9sFAk589qLsaXpVk0ZUkXU2/4YhaOZnlItIp1N4HadNmbHEakRVt31zQrogWlcWLfys wfzg== X-Gm-Message-State: APjAAAV3hT+uaC4v5iI0A68+eEdbr6nkIa5Xi4eV8c/0PTc3dX8I+I0s +ZV+a8x68HarZFO76kQSt7xU7Q== X-Received: by 2002:a17:902:9007:: with SMTP id a7mr77181691plp.221.1558387523416; Mon, 20 May 2019 14:25:23 -0700 (PDT) Received: from ?IPv6:2601:646:c200:1ef2:1155:4a00:3a05:ac06? ([2601:646:c200:1ef2:1155:4a00:3a05:ac06]) by smtp.gmail.com with ESMTPSA id o6sm14811379pfo.164.2019.05.20.14.25.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 May 2019 14:25:21 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: [PATCH v2] vmalloc: Fix issues with flush flag From: Andy Lutomirski X-Mailer: iPhone Mail (16E227) In-Reply-To: <20190520200703.15997-1-rick.p.edgecombe@intel.com> Date: Mon, 20 May 2019 14:25:21 -0700 Cc: linux-kernel@vger.kernel.org, peterz@infradead.org, sparclinux@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org, dave.hansen@intel.com, namit@vmware.com, Meelis Roos , "David S. Miller" , Borislav Petkov , Andy Lutomirski , Ingo Molnar Content-Transfer-Encoding: quoted-printable Message-Id: <28F28A46-C57B-483A-A5CB-8BEA06AF15F8@amacapital.net> References: <20190520200703.15997-1-rick.p.edgecombe@intel.com> To: Rick Edgecombe Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On May 20, 2019, at 1:07 PM, Rick Edgecombe w= rote: >=20 > 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. >=20 > Meelis Roos reported issues with the new VM_FLUSH_RESET_PERMS flag on a > sparc machine. On investigation some issues were noticed: >=20 Can you split this into a few (3?) patches, each fixing one issue? > 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. >=20 > 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. >=20 > 3. page_address() can have locking on some configurations, so skip calling= > this when possible to further speed this up. >=20 > Fixes: 868b104d7379 ("mm/vmalloc: Add flag for freeing of special permsiss= ions") > 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 > --- >=20 > Changes since v1: > - Update commit message with more detail > - Fix flush end range on !CONFIG_ARCH_HAS_SET_DIRECT_MAP case >=20 > mm/vmalloc.c | 23 +++++++++++++---------- > 1 file changed, 13 insertions(+), 10 deletions(-) >=20 > 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_page= s) > { > + const bool has_set_direct =3D IS_ENABLED(CONFIG_ARCH_HAS_SET_DIRECT_M= AP); > + const bool flush_reset =3D area->flags & VM_FLUSH_RESET_PERMS; > unsigned long addr =3D (unsigned long)area->addr; > - unsigned long start =3D ULONG_MAX, end =3D 0; > - int flush_reset =3D area->flags & VM_FLUSH_RESET_PERMS; > + unsigned long start =3D addr, end =3D addr + area->size; > int i; >=20 > /* > @@ -2133,7 +2134,7 @@ static void vm_remove_mappings(struct vm_struct *are= a, 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 *a= rea, int deallocate_pages) >=20 > /* > * 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; > } >=20 > /* > * 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 sur= e > - * the vm_unmap_aliases() flush includes the direct map. > + * the flush_tlb_kernel_range() includes the direct map. > */ > for (i =3D 0; i < area->nr_pages; i++) { > - if (page_address(area->pages[i])) { > + addr =3D (unsigned long)page_address(area->pages[i]); > + if (addr) { > start =3D min(addr, start); > - end =3D max(addr, end); > + end =3D max(addr + PAGE_SIZE, end); > } > } >=20 > @@ -2171,7 +2174,7 @@ static void vm_remove_mappings(struct vm_struct *are= a, 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); > } >=20 > --=20 > 2.20.1 >=20