[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151008085916.GG3604@twins.programming.kicks-ass.net>
Date: Thu, 8 Oct 2015 10:59:16 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: luto@...nel.org, hpa@...or.com, bp@...en8.de, mingo@...nel.org,
brgerst@...il.com, luto@...capital.net,
torvalds@...ux-foundation.org, dvlasenk@...hat.com,
linux-kernel@...r.kernel.org, tglx@...utronix.de
Cc: linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/asm] x86/entry, locking/lockdep: Move
lockdep_sys_exit() to prepare_exit_to_usermode()
On Wed, Oct 07, 2015 at 09:17:44AM -0700, tip-bot for Andy Lutomirski wrote:
> Commit-ID: 72f924783b8a87e4454516520ffb5f35e4930371
> Gitweb: http://git.kernel.org/tip/72f924783b8a87e4454516520ffb5f35e4930371
> Author: Andy Lutomirski <luto@...nel.org>
> AuthorDate: Mon, 5 Oct 2015 17:47:54 -0700
> Committer: Ingo Molnar <mingo@...nel.org>
> CommitDate: Wed, 7 Oct 2015 11:34:07 +0200
>
> x86/entry, locking/lockdep: Move lockdep_sys_exit() to prepare_exit_to_usermode()
>
> Rather than worrying about exactly where LOCKDEP_SYS_EXIT should
> go in the asm code, add it to prepare_exit_from_usermode() and
> remove all of the asm calls that are followed by
> prepare_exit_to_usermode().
>
> LOCKDEP_SYS_EXIT now appears only in the syscall fast paths.
Does that not pose a risk that something that always takes the slow path
(signals? tracing?) will leak a lock to userspace?
--
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