Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2228913imm; Fri, 7 Sep 2018 12:52:59 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZY3iMCJJTUtGmlECU/Rz+GR0CbnO4sTlWwpf9K9EujaAxmQFjrDG/RhBvCzHF5N+CeUDQM X-Received: by 2002:a62:5302:: with SMTP id h2-v6mr10453983pfb.183.1536349979377; Fri, 07 Sep 2018 12:52:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536349979; cv=none; d=google.com; s=arc-20160816; b=caspL6Xlcit8Vab+zAcQoH/yIHQBXaXIGIouJGZcg1QexoUCbH5xak8sLoess1rjdm csT8abhxC/sk10kcxOJGDzepR08x5pFKFaFUJBU36wcv0jD89/WoM0MYmgAcZZMeQ9An BZC21oViD0fAgVjXzyFJRFZBq1Z35NO0Ss7NAaBCPSUBBk/j8uvwIvgN/QEhTjeBlQsf wvNk+XNyTjQ53OtwZfD+2I0BxDDqJQ3/wVkz/4UNs0CYqjdLmPQ302rCpb4eyqYKKaUk GigCr+HxvVLjuVRHAjgoeU6JOkUuxbVcTFMf0fNklPDEsoRSwXTitStieASMMe6tVg7/ rQLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:in-reply-to:references:date :from:cc:to:subject; bh=cOW98/hy+DKE1wSzylNzQ+m7uxGFB8+GpQzioq+SXBs=; b=Qb8S0IaN3avu8CkGmitHl7PWxqKRusCv7OCt3Zoz4+fncelc+mpdFhh5sEv6dkKKnk JMXln8ZXqrcjI0SYMd/O8CT5Z6dHXdiktGe94sPGEa5JKCf/yjwRq5nNPlU9cw7CP4B0 PmyQwG0KqMCaaxohMmEAdr1wQYeKG/4cInZ7nBzMnlyTmZeIrTcubA8gBUVQ6BRmHHDa Bj0U1waE4p73ru2HYjnykvx4zpJlYTqhPgwnGtXrq0NphDCSYpzY19MV9hpmBy2gIyqD i9yw+lU7y0rsrWGBbxKH05Lx3mSbCQ59gLMuA1SMjaX/Qkl24jhJBWJt1oBiyuTLbsiq SN8w== 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 o6-v6si8687504pgp.631.2018.09.07.12.52.43; Fri, 07 Sep 2018 12:52:59 -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 S1727282AbeIHAeA (ORCPT + 99 others); Fri, 7 Sep 2018 20:34:00 -0400 Received: from mga14.intel.com ([192.55.52.115]:31262 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726187AbeIHAeA (ORCPT ); Fri, 7 Sep 2018 20:34:00 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Sep 2018 12:51:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,343,1531810800"; d="scan'208";a="89881383" Received: from viggo.jf.intel.com (HELO localhost.localdomain) ([10.54.77.144]) by orsmga002.jf.intel.com with ESMTP; 07 Sep 2018 12:51:31 -0700 Subject: [RFC][PATCH 5/8] x86/mm: fix exception table comments To: linux-kernel@vger.kernel.org Cc: Dave Hansen , sean.j.christopherson@intel.com, peterz@infradead.org, tglx@linutronix.de, x86@kernel.org, luto@kernel.org From: Dave Hansen Date: Fri, 07 Sep 2018 12:49:00 -0700 References: <20180907194852.3C351B82@viggo.jf.intel.com> In-Reply-To: <20180907194852.3C351B82@viggo.jf.intel.com> Message-Id: <20180907194900.DF3B41C0@viggo.jf.intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Dave Hansen The comments here are wrong. They are too absolute about where faults can occur when running in the kernel. The comments are also a bit hard to match up with the code. Trim down the comments, and make them more precise. Also add a comment explaining why we are doing the bad_area_nosemaphore() path here. Signed-off-by: Dave Hansen Cc: Sean Christopherson Cc: "Peter Zijlstra (Intel)" Cc: Thomas Gleixner Cc: x86@kernel.org Cc: Andy Lutomirski --- b/arch/x86/mm/fault.c | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff -puN arch/x86/mm/fault.c~pkeys-fault-warnings-03 arch/x86/mm/fault.c --- a/arch/x86/mm/fault.c~pkeys-fault-warnings-03 2018-09-07 11:21:47.696751898 -0700 +++ b/arch/x86/mm/fault.c 2018-09-07 11:21:47.700751898 -0700 @@ -1349,24 +1349,25 @@ void do_user_addr_space_fault(struct pt_ flags |= FAULT_FLAG_INSTRUCTION; /* - * When running in the kernel we expect faults to occur only to - * addresses in user space. All other faults represent errors in - * the kernel and should generate an OOPS. Unfortunately, in the - * case of an erroneous fault occurring in a code path which already - * holds mmap_sem we will deadlock attempting to validate the fault - * against the address space. Luckily the kernel only validly - * references user space from well defined areas of code, which are - * listed in the exceptions table. + * Kernel-mode access to the user address space should only occur + * inside well-defined areas of code listed in the exception + * tables. But, an erroneous kernel fault occurring outside one of + * those areas which also holds mmap_sem might deadlock attempting + * to validate the fault against the address space. * - * As the vast majority of faults will be valid we will only perform - * the source reference check when there is a possibility of a - * deadlock. Attempt to lock the address space, if we cannot we then - * validate the source. If this is invalid we can skip the address - * space check, thus avoiding the deadlock: + * Only do the expensive exception table search when we might be at + * risk of a deadlock: + * 1. We failed to acquire mmap_sem, and + * 2. The access was an explicit kernel-mode access + * (X86_PF_USER=0). */ if (unlikely(!down_read_trylock(&mm->mmap_sem))) { if (!(sw_error_code & X86_PF_USER) && !search_exception_tables(regs->ip)) { + /* + * Fault from code in kernel from + * which we do not expect faults. + */ bad_area_nosemaphore(regs, sw_error_code, address, NULL); return; } _