Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751269AbdCQR5b (ORCPT ); Fri, 17 Mar 2017 13:57:31 -0400 Received: from mail-it0-f68.google.com ([209.85.214.68]:36582 "EHLO mail-it0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751031AbdCQR5a (ORCPT ); Fri, 17 Mar 2017 13:57:30 -0400 MIME-Version: 1.0 In-Reply-To: <20170317115924.GA82960@inn.lkp.intel.com> References: <20170317115924.GA82960@inn.lkp.intel.com> From: Linus Torvalds Date: Fri, 17 Mar 2017 10:49:47 -0700 X-Google-Sender-Auth: SoqWnxb1vR05f69x1Nmm23Ynzfo Message-ID: Subject: Re: [x86] 45fc8757d1: BUG:unable_to_handle_kernel To: kernel test robot Cc: Thomas Garnier , Ingo Molnar , Alexander Potapenko , Andrew Morton , Andrey Ryabinin , Andy Lutomirski , Ard Biesheuvel , Boris Ostrovsky , Borislav Petkov , Chris Wilson , Christian Borntraeger , Dmitry Vyukov , Frederic Weisbecker , Jiri Kosina , Joerg Roedel , Jonathan Corbet , Josh Poimboeuf , Juergen Gross , Kees Cook , Len Brown , Lorenzo Stoakes , "Luis R . Rodriguez" , Matt Fleming , Michal Hocko , Paolo Bonzini , Paul Gortmaker , Pavel Machek , Peter Zijlstra , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , "Rafael J . Wysocki" , Rusty Russell , Stanislaw Gruszka , Thomas Gleixner , Tim Chen , Vitaly Kuznetsov , zijun_hu , LKML , "H. Peter Anvin" , tipbuild@zytor.com, LKP Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1283 Lines: 33 On Fri, Mar 17, 2017 at 4:59 AM, kernel test robot wrote: > > FYI, we noticed the following commit: > > commit: 45fc8757d1d2128e342b4e7ef39adedf7752faac ("x86: Make the GDT remapping read-only on 64-bit") > https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git x86/mm > > in testcase: boot > > [ 4.347219] BUG: unable to handle kernel paging request at ffffffffff577060 > [ 4.360480] Oops: 0003 [#1] SMP > [ 4.373550] RIP: 0023:0xf77e91ed > [ 4.375284] RSP: 002b:00000000ffed034c EFLAGS: 00010246 Heh. That's actually in user space, but the error code (0003) means "protection fault on a write, not a user access". So it's almost certainly something that tries to access a segment descriptor in the GDT, but that segment was marked as "not accessed", and the CPU was trying to set the accessed bit. I *thought* we always maked everything accessed when we initialize it, but something clearly is not. That's why there's no kernel call trace or anything like that: it is a system page fault, but it's triggered directly from user mode. The linear address can be used to look up which entry it is. I assume the GDT starts at ffffffffff577000, and that this is at offset 0x60 from that. Whatever descriptor that would be.. Linus