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 S1751546AbbJ3Xup (ORCPT <rfc822;w@1wt.eu>);
	Fri, 30 Oct 2015 19:50:45 -0400
Received: from mail-ob0-f170.google.com ([209.85.214.170]:34240 "EHLO
	mail-ob0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751003AbbJ3Xun convert rfc822-to-8bit (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 30 Oct 2015 19:50:43 -0400
MIME-Version: 1.0
In-Reply-To: <562F84AE.1030500@list.ru>
References: <cover.1445822498.git.luto@kernel.org> <562E126E.6030300@list.ru>
 <CALCETrViit0LaXEcSOZHF99gdEbFDPGwLoO6q6aCfq2okToC7Q@mail.gmail.com> <562F84AE.1030500@list.ru>
From: Andy Lutomirski <luto@amacapital.net>
Date: Fri, 30 Oct 2015 16:50:23 -0700
Message-ID: <CALCETrWT70uUu=KMDC=8Apdbfhpw=3ByKjBAHceHuQA9sFxZWg@mail.gmail.com>
Subject: Re: [PATCH v2 0/4] x86: sigcontext fixes, again
To: Stas Sergeev <stsp@list.ru>
Cc: Andy Lutomirski <luto@kernel.org>, X86 ML <x86@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Brian Gerst <brgerst@gmail.com>, Denys Vlasenko <dvlasenk@redhat.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Borislav Petkov <bp@alien8.de>,
        Stas Sergeev <stsp@users.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Oct 27, 2015 at 7:05 AM, Stas Sergeev <stsp@list.ru> wrote:
> 27.10.2015 03:52, Andy Lutomirski пишет:
>> On Mon, Oct 26, 2015 at 4:45 AM, Stas Sergeev <stsp@list.ru> wrote:
>>> 26.10.2015 04:25, Andy Lutomirski пишет:
>>>> This is take 2 at fixing x86 64-bit signals wrt SS.  After a lot of
>>>> thought, this is not controlled by any flags -- I would much prefer
>>>> to avoid opt-in behavior.  Instead, it just tries hard to avoid
>>>> triggering the cases that break DOSEMU.
>>>>
>>>> Stas, this now seems to pass the test you sent me.  It works with
>>>> stock dosemu2 (I haven't tested classic dosemu because I can't get it
>>>> to work regardless).
>>> I'll test it myself then.
>>> But this will have to wait till a week-end I am afraid.
>>> In a mean time you can test vm86() - last time I tried,
>>> I got oops and hard lockup.
>>
>> Can you tell me exactly what kernel version (release by Linus or
>> commit hash) oopses and, if it's easy, post a screenshot or log?
> I archived my config and git hash.
> I can't easily post an Oops: under X it doesn't even appear -
> machine freezes immediately, and under non-KMS console it is
> possible to get one, but difficult to screen-shot (using bare
> metal, not VM). Also the Oops was seemingly unrelated.
> And if you run "dosemu -s" under non-KMS console, you'll also
> reproduce this one:
> https://bugzilla.kernel.org/show_bug.cgi?id=97321

Like this?

[  288.221786] BUG: unable to handle kernel paging request at ffffffb9
[  288.222475] IP: [<c169bf48>] snd_seq_delete_port+0x48/0xd0
[  288.222743] *pde = 01c8c067 *pte = 00000000
[  288.222743] Oops: 0000 [#1] SMP
[  288.222743] Modules linked in:
[  288.222743] CPU: 0 PID: 5480 Comm: dosemu.bin Not tainted 4.3.0-rc7+ #345
[  288.222743] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
[  288.222743] task: c7006b40 ti: c7bb4000 task.ti: c7bb4000
[  288.222743] EIP: 0060:[<c169bf48>] EFLAGS: 00010082 CPU: 0
[  288.222743] EIP is at snd_seq_delete_port+0x48/0xd0
[  288.222743] EAX: 00000000 EBX: ffffffb8 ECX: c707c67c EDX: 00000001
[  288.222743] ESI: c707c600 EDI: c707c684 EBP: c7bb5d60 ESP: c7bb5d48
[  288.222743]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[  288.222743] CR0: 80050033 CR2: ffffffb9 CR3: 07b00000 CR4: 000406d0
[  288.222743] Stack:
[  288.222743]  00000001 00000246 c707c68c c707c600 40a45321 c7bb5ee0
c7bb5e14 c16965cb
[  288.222743]  0000010f 00000000 00000000 00000000 00000000 00000000
00000000 00000000
[  288.222743]  00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
[  288.222743] Call Trace:
[  288.222743]  [<c16965cb>] snd_seq_ioctl_delete_port+0x3b/0x90
[  288.222743]  [<c1696c65>] snd_seq_do_ioctl+0x85/0x90
[  288.222743]  [<c1696ca3>] snd_seq_kernel_client_ctl+0x33/0x50
[  288.222743]  [<c169b78b>] snd_seq_event_port_detach+0x3b/0x50
[  288.222743]  [<c169d6a2>] delete_port+0x12/0x30
[  288.222743]  [<c169dbc1>] snd_seq_oss_release+0x41/0x50
[  288.222743]  [<c169d406>] odev_release+0x26/0x40
[  288.222743]  [<c11a46a3>] __fput+0xc3/0x1d0
[  288.222743]  [<c11a47e8>] ____fput+0x8/0x10
[  288.222743]  [<c10b924f>] task_work_run+0x6f/0x90
[  288.222743]  [<c10017e5>] prepare_exit_to_usermode+0xd5/0x100
[  288.222743]  [<c1001841>] syscall_return_slowpath+0x31/0x120
[  288.222743]  [<c11bd094>] ? __close_fd+0x54/0x70
[  288.222743]  [<c188b372>] syscall_exit_work+0x7/0xc
[  288.222743] Code: 5f d0 1e 00 89 f8 e8 68 f0 1e 00 89 45 ec 8b 46
7c 8d 4e 7c 39 c1 74 25 8d 58 b8 0f b6 40 b9 8b 55 e8 39 d0 75 0d eb
3b 8d 76 00 <0f> b6 40 b9 39 d0 74 30 8b 43 48 39 c1 8d 58 b8 75 ee 8b
55 ec
[  288.222743] EIP: [<c169bf48>] snd_seq_delete_port+0x48/0xd0 SS:ESP
0068:c7bb5d48
[  288.222743] CR2: 00000000ffffffb9
[  288.222743] ---[ end trace f216bf40eb9b39d6 ]---

I'll try to narrow that down a little bit and email the appropriate maintainer.

--Andy