Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751779AbeAHRUX (ORCPT + 1 other); Mon, 8 Jan 2018 12:20:23 -0500 Received: from mga01.intel.com ([192.55.52.88]:18088 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751654AbeAHRUW (ORCPT ); Mon, 8 Jan 2018 12:20:22 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,330,1511856000"; d="scan'208";a="18430552" Subject: Re: [PATCH RFC 4/4] x86/entry/pti: don't switch PGD on tasks holding flag TIF_NOPTI To: Willy Tarreau , linux-kernel@vger.kernel.org, x86@kernel.org References: <1515427939-10999-1-git-send-email-w@1wt.eu> <1515427939-10999-5-git-send-email-w@1wt.eu> Cc: tglx@linutronix.de, gnomes@lxorguk.ukuu.org.uk, torvalds@linux-foundation.org, Andy Lutomirski From: Dave Hansen Message-ID: <9d6917dc-1a6c-a8d4-95fe-f767495f99d3@intel.com> Date: Mon, 8 Jan 2018 09:20:08 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1515427939-10999-5-git-send-email-w@1wt.eu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: Please cc Andy on this stuff. I can't imagine patching entry_64.S at this point without cc'ing him. *Surely* you didn't even bother to run get_maintainer.pl on this. > @@ -214,6 +215,11 @@ > .macro SWITCH_TO_KERNEL_CR3 scratch_reg:req > ALTERNATIVE "jmp .Lend_\@", "", X86_FEATURE_PTI > mov %cr3, \scratch_reg > + > + /* if we're already on the kernel PGD, we don't switch */ > + testq $(PTI_SWITCH_PGTABLES_MASK), \scratch_reg > + jz .Lend_\@ > + > ADJUST_KERNEL_CR3 \scratch_reg > mov \scratch_reg, %cr3 > .Lend_\@: This is an optimization that we can do generally without your feature. Actually, it would be a welcome bit of benchmarking if you could see if just this hunk helps your workload. You touched on it in the description, but this is a *very* clever way to do what you need without needing to look at the task flag at user->kernel entry which also happens to be a place you don't have task_struct mapped. It *greatly* simplifies what this would have to do otherwise. That needs calling out specifically though.