[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.11.1510091054230.6097@nanos>
Date: Fri, 9 Oct 2015 11:25:09 +0100 (IST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Hans Zuidam <h.zuidam@...puter.org>
cc: Jaccon Bastiaansen <jaccon.bastiaansen@...il.com>, x86@...nel.org,
mingo@...hat.com, "H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
stable@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC]: Possible race condition in kernel futex code
Hans,
On Fri, 9 Oct 2015, Hans Zuidam wrote:
> On 9 okt. 2015, at 11:06, Thomas Gleixner <tglx@...utronix.de> wrote:
> > You cannot use an explicit 32bit read. We need an access which
> > handles the fault gracefully.
>
> The reason for the explicit read suggestion is to avoid the
> _builtin_constant_p() in __copy_from_user_nocheck(). The GCC manual
> says that there may be situations where it returns 0 even though the
> argument is a constant.
That's insane at best.
> Although none of the compiler/kernel combinations we have tried
> showed this happening, we think it is probably better to be safe
> than sorry.
So we would need something like:
futex_copy_from_user()
which can be mapped to __copy_from_user_inatomic() first. Then go
through all architectures and the asm-generic stuff and provide the
specific variants which are guaranteed to use a 32bit access.
I really prefer that we don't have to do that and the compiler people
get their act together and fix that _builtin_constant_p() thingy.
Thanks,
tglx
--
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