[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171211121302.bdjkhnfv2ncclrht@hirez.programming.kicks-ass.net>
Date: Mon, 11 Dec 2017 13:13:02 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...uxfoundation.org>, x86@...nel.org,
Andy Lutomirski <luto@...nel.org>,
Borislav Petkov <bp@...en8.de>,
Brian Gerst <brgerst@...il.com>,
David Laight <David.Laight@...lab.com>,
Kees Cook <keescook@...omium.org>
Subject: Re: [patch V2 2/2] x86/ldt: Prevent ldt inheritance on exec
On Sat, Dec 09, 2017 at 07:24:35PM +0100, Thomas Gleixner wrote:
> On Fri, 8 Dec 2017, Thomas Gleixner wrote:
> > +int ldt_dup_context(struct mm_struct *old_mm, struct mm_struct *mm)
> > {
> > struct ldt_struct *new_ldt;
> > - struct mm_struct *old_mm;
> > int retval = 0;
> >
> > - mutex_init(&mm->context.lock);
> > - old_mm = current->mm;
> > - if (!old_mm) {
> > - mm->context.ldt = NULL;
> > + if (!old_mm)
> > return 0;
> > - }
> >
> > mutex_lock(&old_mm->context.lock);
>
> Bah. That's broken. It now nests into old_mm->mmap_sem which is the reverse
> lock order than in ldt_write. Will fix.
But read_ldt() will still nest mmap_sem inside context.lock, no? Lockdep
doesn't care about old_mm vs new_mm.
Powered by blists - more mailing lists