[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrWUmL5bPyxR0gvchtn433hdnSqOuRdBjFsqJqa_xbtBnw@mail.gmail.com>
Date: Fri, 30 Oct 2015 22:43:30 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Stas Sergeev <stsp@...t.ru>, Brian Gerst <brgerst@...il.com>
Cc: Andy Lutomirski <luto@...nel.org>, X86 ML <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Denys Vlasenko <dvlasenk@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Borislav Petkov <bp@...en8.de>,
Stas Sergeev <stsp@...rs.sourceforge.net>
Subject: Re: 4.3 regression: task_work corruption in vm86 mode?
On Fri, Oct 30, 2015 at 6:44 PM, Andy Lutomirski <luto@...capital.net> wrote:
> Hi all-
>
> In 4.3-rc7, running dosemu2 (https://github.com/stsp/dosemu2/) oopses
> the system very quickly, as long as CONFIG_VM86=y. It blows up
> because snd_seq_delete_port walks ports_list_head, finds two valid
> ports, and then starts finding obviously invalid pointers in the list.
>
> git bisect blames:
>
> commit 5ed92a8ab71f8865ba07811429c988c72299b315
> Author: Brian Gerst <brgerst@...il.com>
> Date: Wed Jul 29 01:41:19 2015 -0400
>
> x86/vm86: Use the normal pt_regs area for vm86
>
> I haven't spotted the problem yet. It seems to happen when
> task_work_run fires in get_signal, which happens before
> save_v86_state. I'm not entirely sure what causes task work to be
> scheduled at all while in v86 land. Could we somehow be processing
> task_work later than we should?
>
Nope, the bug has nothing to do with task_work. Patches sent.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists