From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752705AbdLESjE (ORCPT ); Tue, 5 Dec 2017 13:39:04 -0500 Received: from bombadil.infradead.org ([65.50.211.133]:56029 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752065AbdLESjB (ORCPT ); Tue, 5 Dec 2017 13:39:01 -0500 Date: Tue, 5 Dec 2017 19:38:45 +0100 From: Peter Zijlstra To: Borislav Petkov Cc: Thomas Gleixner , qiaowei.ren@intel.com, luto@kernel.org, adam.buchbinder@gmail.com, mst@redhat.com, mhiramat@kernel.org, dave.hansen@linux.intel.com, mingo@kernel.org, linux-kernel@vger.kernel.org, colin.king@canonical.com, jslaby@suse.cz, pbonzini@redhat.com, cmetcalf@mellanox.com, akpm@linux-foundation.org, vbabka@suse.cz, acme@redhat.com, brgerst@gmail.com, shuah@kernel.org, paul.gortmaker@windriver.com, lstoakes@gmail.com, hpa@zytor.com, thgarnie@google.com, keescook@chromium.org, adrian.hunter@intel.com, ricardo.neri-calderon@linux.intel.com, ray.huang@amd.com, dvyukov@google.com, ravi.v.shankar@intel.com, slaoub@gmail.com, corbet@lwn.net, linux-tip-commits@vger.kernel.org Subject: Re: [tip:x86/mpx] x86/insn-eval: Add utility function to get segment descriptor Message-ID: <20171205183845.GO3165@worktop.lehotels.local> References: <1509135945-13762-15-git-send-email-ricardo.neri-calderon@linux.intel.com> <20171205174844.GM3165@worktop.lehotels.local> <20171205181456.akycirziiuhb7crw@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171205181456.akycirziiuhb7crw@pd.tnic> User-Agent: Mutt/1.5.22.1 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 05, 2017 at 07:14:56PM +0100, Borislav Petkov wrote: > On Tue, Dec 05, 2017 at 06:48:44PM +0100, Peter Zijlstra wrote: > > This is broken right? You unlock and then return @desc, which afaict can > > at that point get freed by free_ldt_struct(). > > > > Something like the below ought to cure; although its not entirely > > pretty either. > > Right. > > Or, instead of introducing all the locking, we could also not do > anything because all that code runs inside fixup_umip_exception() so the > desc will be valid there. Sorry what? So either this code is broken because it has IRQs enabled, or its broken because its trying to acquire a mutex with IRQs disabled. Which is it?