From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751955AbcBYVnS (ORCPT ); Thu, 25 Feb 2016 16:43:18 -0500 Received: from mail-pf0-f169.google.com ([209.85.192.169]:34017 "EHLO mail-pf0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751181AbcBYVnQ (ORCPT ); Thu, 25 Feb 2016 16:43:16 -0500 Subject: Re: BUG: unable to handle kernel paging request from pty_write [was: Linux 4.4.2] To: Linus Torvalds References: <20160217203730.GA14820@kroah.com> <56CED373.9060603@suse.cz> <56CF4A83.3040408@hurleysoftware.com> <56CF64C9.8050705@hurleysoftware.com> Cc: Jiri Slaby , Greg KH , Linux Kernel Mailing List , Andrew Morton , stable , lwn@lwn.net, Steven Rostedt From: Peter Hurley Message-ID: <56CF756E.5000704@hurleysoftware.com> Date: Thu, 25 Feb 2016 13:43:10 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/25/2016 12:51 PM, Linus Torvalds wrote: > On Thu, Feb 25, 2016 at 12:32 PM, Peter Hurley wrote: >>> But yes, the call trace looks accurate and makes sense, we haveL >>> >>> tty_flip_buffer_push -> >>> (queue_work is inline) -> >>> queue_work_on -> >>> __queue_work -> >>> insert_work -> >>> (wake_up_worker is inlined) >>> wake_up_process -> >> >> try_to_wake_up -> >> >>> *insane non-code address* > > The thing is, we don't actually have that try_to_wake_up() on the > stack in the oops report. I know, but last execution prior to things going sideways was definitely in try_to_wake_up(). > There are other thigns on the stack, but the > first stack entry that is dumped that is a text address is that > "ffffffff810a5585" which is wake_up_process. > > That's why I said it might be stack corruption: we might be returning > from try_to_wake_up(), but with a corrupt stack entry, and returning > to garbage. > > If it was one of the calls _in_ try_to_wake_up() that called to insane > code, I would have expected to see try_to_wake_up on the stack. Agreed, how execution got from try_to_wake_up() to mysterious percpu address without call is the question. > That's particularly true on modern machines, where things like the > percpu area is nopefully marked NX, so that we shouldn't be executing > random instructions. Which is the fault that actually triggers > ("kernel tried to execute NX-protected page"), so the "we corrupted > the stack by running random code at the original target of the jump" > scenario sounds much less likely. > > So the whole oops looks odd. If it really was one of the calls from > try_to_wake_up(), why isn't that return address on the stack? I don't think it's anything from code flow. > Since this is under qemu, I'm wondering if this is a qemu bug, where > the NX fault processing of a call instruction happens before the stack > is pushed, but when the instruction pointer already points to the new > address. Or any fault processing really; an iret to the bogus address would then trigger NX fault without leaving a trace of the broken exception handling. > Another alternative *might* be that gcc has turned an indirect > tail-call call into a "jmp *", but I certainly don't see that when I > compile the file myself. I've seen it in the past in some (very > unusual) cases, so it's possible - gcc definitely knows about > tail-call jmp conversion (even if it makes debugging sometimes a > pain). > > Jiri, can you check your try_to_wake_up() disassembly for some > indirect "jmp" instructions? > > Linus >