From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S933764AbcBZRMt (ORCPT <rfc822;w@1wt.eu>);
	Fri, 26 Feb 2016 12:12:49 -0500
Received: from mail-io0-f175.google.com ([209.85.223.175]:36407 "EHLO
	mail-io0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1754257AbcBZRMr (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 26 Feb 2016 12:12:47 -0500
MIME-Version: 1.0
In-Reply-To: <56D01331.5030401@suse.cz>
References: <20160217203730.GA14820@kroah.com>
	<56CED373.9060603@suse.cz>
	<56CF4A83.3040408@hurleysoftware.com>
	<CA+55aFyeVmnNuk5pPoH05uPKZRSXt1hv_0PWuvndptqBSfPrbA@mail.gmail.com>
	<56CF64C9.8050705@hurleysoftware.com>
	<CA+55aFx306jsTaUkm_c4nJtEo=A3vdDFYqqpLJj1zKUh=wLxog@mail.gmail.com>
	<56CF72EA.9040009@suse.cz>
	<CA+55aFzQzCKhX73bUYwNMK8Dd9ECtmav8u7ds2aXKjEo7DV3Gg@mail.gmail.com>
	<56D01331.5030401@suse.cz>
Date: Fri, 26 Feb 2016 09:12:46 -0800
X-Google-Sender-Auth: 24B3TaAGiGr--Wv1UAQhKFvXblE
Message-ID: <CA+55aFwp-qCtV1dRggHotRDTNAmRZWVjm-khkB1q1z8+_0xQKg@mail.gmail.com>
Subject: Re: BUG: unable to handle kernel paging request from pty_write [was:
 Linux 4.4.2]
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Jiri Slaby <jslaby@suse.cz>
Cc: Peter Hurley <peter@hurleysoftware.com>,
        Greg KH <gregkh@linuxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        stable <stable@vger.kernel.org>, lwn@lwn.net,
        Steven Rostedt <rostedt@goodmis.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Feb 26, 2016 at 12:56 AM, Jiri Slaby <jslaby@suse.cz> wrote:
>
> Sure, both vmlinux w/ its separated .debuginfo sections vmlinux.debug
> are at:
> http://labs.suse.cz/jslaby/bug-968218/

I'm not seeing anything odd there.

It does feel like CPU state corruption - either due to a qemu bug, or
due to some odd trap/interrupt handling bug of ours.

Or possibly a CPU/microcode bug. You wouldn't happen to run this on an
AMD Piledriver-based CPU with the 0x06000832 microcode?

Because we do have a pending qemu-related bug-report that turned out
to be a AMD microcode problem with NMI delivery. Looking at that bug
report, it actually looks rather similar - also due to a confused RIP.

                   Linus