Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp594200imu; Thu, 22 Nov 2018 02:24:20 -0800 (PST) X-Google-Smtp-Source: AFSGD/UBoKKXjJ5SYnnDvKecV1zDRcDpfmJ6LT9JvtlEwM3Awz7g+rlHJL0XLjjqb3Qv+Plm7u2i X-Received: by 2002:a17:902:59c8:: with SMTP id d8mr10661304plj.116.1542882260693; Thu, 22 Nov 2018 02:24:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542882260; cv=none; d=google.com; s=arc-20160816; b=FHpJ1xIJXX9XEjEdqLo5TupzrJh7y08De0zQyQUDyrnoUASaNgR/bqnGf3bKY10e8/ x1AhhaWSP6aX9YDA7s+JP7wk3bu6iVwZxEduN1fm2yXnjIX1o6mKP84VZZCvJ219/0+0 7PLjSE5OV/O+THg1NTBsUo9gUBUN5pE8MaOtGKzEbyUf9XX2G1ylJqwo1jBa+GYXGkom CIkqMnZh0Io/fV0kVMFoDWMGAYwlIMtqirDQ0LOQZ/eJiaujasRR0qZmEQJAwOt255ql FfgS/epZdCZtrm/3oVMTK1fhT4+3FxYvRL+ht7kYxt0/6jWMJhA2/lYEgpIaTVBFWQuU VF1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:references :in-reply-to:message-id:date:subject:cc:to:from:dkim-signature; bh=LGQ3wk5bQtNGY/OuJRc+vGVkp9N0azMEJk0Z8YhP1OI=; b=istDVwudRo4tbyGs75d33o3FLZsHjtKiq0PZNFRjaG3gykabdKOMetIjuFr3HJ30rv uokx9iS9wCvCDWC08aSKZZeJgWnrFtD2rl8T5DbvDCbpQ54Y8OaR0qaHsPdfBKKiuZXu p10HLnpkDZNoux+6AwIQFMsO3AZEbO9lgJ0bTaEKvLAbsHm033z56ve+DIcgGX5y9iQZ 4YHg4xE7PLJlrO3EHeJRAUqI5Uli9b5mzce615i0CT5UIP/oPqFniKMcj4pY8i/fG/dM fFR1s8UxEcWov5czM/20PNiS6CuSNFn++pW6o627DbxfEo0c2d0vCa2hjHqPebNGm/hC VWLA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=0E+TkrU8; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n185-v6si51458518pfn.83.2018.11.22.02.24.05; Thu, 22 Nov 2018 02:24:20 -0800 (PST) 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=@kernel.org header.s=default header.b=0E+TkrU8; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390473AbeKVJsB (ORCPT + 99 others); Thu, 22 Nov 2018 04:48:01 -0500 Received: from mail.kernel.org ([198.145.29.99]:38664 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387822AbeKVJr7 (ORCPT ); Thu, 22 Nov 2018 04:47:59 -0500 Received: from localhost (c-71-205-112-160.hsd1.co.comcast.net [71.205.112.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 39D3D20821; Wed, 21 Nov 2018 23:11:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1542841890; bh=CnVJfgBt26DDx5WO4GE01u+TDImPxcrgIzHCq6bSnoQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:In-Reply-To: References:From; b=0E+TkrU8YnH7Iwolsp6TbjG3C1nuRS1MOA4k0aHaPhSY9byAXsoo2cfG/Rq4cMXlT RhkQxN7K5qcDzuNR9xxgOrO+Il+8B+ezxYx+JMmjghAE7C/ieCsFz39K8oiQHztD40 yci92TUhfcf5q7TnEnyO4q+KyMCdmC59ACM1jyIw= From: Andy Lutomirski To: x86@kernel.org Cc: LKML , Yu-cheng Yu , Dave Hansen , Peter Zijlstra , Borislav Petkov , Andy Lutomirski Subject: [PATCH v2 1/5] x86/fault: Remove sw_error_code Date: Wed, 21 Nov 2018 15:11:22 -0800 Message-Id: <078f5b8ae6e8c79ff8ee7345b5c476c45003e5ac.1542841400.git.luto@kernel.org> X-Mailer: git-send-email 2.17.2 In-Reply-To: References: In-Reply-To: References: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org All of the fault handling code now corrently checks user_mode(regs) as needed, and nothing depends on the X86_PF_USER bit being munged. Get rid of the sw_error code and use hw_error_code everywhere. Signed-off-by: Andy Lutomirski --- arch/x86/mm/fault.c | 50 ++++++++++----------------------------------- 1 file changed, 11 insertions(+), 39 deletions(-) diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c index b898a38093a3..82881bc5feef 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -1217,7 +1217,6 @@ void do_user_addr_fault(struct pt_regs *regs, unsigned long hw_error_code, unsigned long address) { - unsigned long sw_error_code; struct vm_area_struct *vma; struct task_struct *tsk; struct mm_struct *mm; @@ -1262,13 +1261,6 @@ void do_user_addr_fault(struct pt_regs *regs, return; } - /* - * hw_error_code is literally the "page fault error code" passed to - * the kernel directly from the hardware. But, we will shortly be - * modifying it in software, so give it a new name. - */ - sw_error_code = hw_error_code; - /* * It's safe to allow irq's after cr2 has been saved and the * vmalloc fault has been handled. @@ -1278,26 +1270,6 @@ void do_user_addr_fault(struct pt_regs *regs, */ if (user_mode(regs)) { local_irq_enable(); - /* - * Up to this point, X86_PF_USER set in hw_error_code - * indicated a user-mode access. But, after this, - * X86_PF_USER in sw_error_code will indicate either - * that, *or* an implicit kernel(supervisor)-mode access - * which originated from user mode. - */ - if (!(hw_error_code & X86_PF_USER)) { - /* - * The CPU was in user mode, but the CPU says - * the fault was not a user-mode access. - * Must be an implicit kernel-mode access, - * which we do not expect to happen in the - * user address space. - */ - pr_warn_once("kernel-mode error from user-mode: %lx\n", - hw_error_code); - - sw_error_code |= X86_PF_USER; - } flags |= FAULT_FLAG_USER; } else { if (regs->flags & X86_EFLAGS_IF) @@ -1306,9 +1278,9 @@ void do_user_addr_fault(struct pt_regs *regs, perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address); - if (sw_error_code & X86_PF_WRITE) + if (hw_error_code & X86_PF_WRITE) flags |= FAULT_FLAG_WRITE; - if (sw_error_code & X86_PF_INSTR) + if (hw_error_code & X86_PF_INSTR) flags |= FAULT_FLAG_INSTRUCTION; #ifdef CONFIG_X86_64 @@ -1321,7 +1293,7 @@ void do_user_addr_fault(struct pt_regs *regs, * The vsyscall page does not have a "real" VMA, so do this * emulation before we go searching for VMAs. */ - if ((sw_error_code & X86_PF_INSTR) && is_vsyscall_vaddr(address)) { + if ((hw_error_code & X86_PF_INSTR) && is_vsyscall_vaddr(address)) { if (emulate_vsyscall(regs, address)) return; } @@ -1345,7 +1317,7 @@ void do_user_addr_fault(struct pt_regs *regs, * Fault from code in kernel from * which we do not expect faults. */ - bad_area_nosemaphore(regs, sw_error_code, address); + bad_area_nosemaphore(regs, hw_error_code, address); return; } retry: @@ -1361,17 +1333,17 @@ void do_user_addr_fault(struct pt_regs *regs, vma = find_vma(mm, address); if (unlikely(!vma)) { - bad_area(regs, sw_error_code, address); + bad_area(regs, hw_error_code, address); return; } if (likely(vma->vm_start <= address)) goto good_area; if (unlikely(!(vma->vm_flags & VM_GROWSDOWN))) { - bad_area(regs, sw_error_code, address); + bad_area(regs, hw_error_code, address); return; } if (unlikely(expand_stack(vma, address))) { - bad_area(regs, sw_error_code, address); + bad_area(regs, hw_error_code, address); return; } @@ -1380,8 +1352,8 @@ void do_user_addr_fault(struct pt_regs *regs, * we can handle it.. */ good_area: - if (unlikely(access_error(sw_error_code, vma))) { - bad_area_access_error(regs, sw_error_code, address, vma); + if (unlikely(access_error(hw_error_code, vma))) { + bad_area_access_error(regs, hw_error_code, address, vma); return; } @@ -1420,13 +1392,13 @@ void do_user_addr_fault(struct pt_regs *regs, return; /* Not returning to user mode? Handle exceptions or die: */ - no_context(regs, sw_error_code, address, SIGBUS, BUS_ADRERR); + no_context(regs, hw_error_code, address, SIGBUS, BUS_ADRERR); return; } up_read(&mm->mmap_sem); if (unlikely(fault & VM_FAULT_ERROR)) { - mm_fault_error(regs, sw_error_code, address, fault); + mm_fault_error(regs, hw_error_code, address, fault); return; } -- 2.17.2