From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754741AbbESISo (ORCPT ); Tue, 19 May 2015 04:18:44 -0400 Received: from www.linutronix.de ([62.245.132.108]:53163 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753469AbbESISl (ORCPT ); Tue, 19 May 2015 04:18:41 -0400 Date: Tue, 19 May 2015 10:18:51 +0200 (CEST) From: Thomas Gleixner To: Dave Hansen cc: linux-kernel@vger.kernel.org, x86@kernel.org, dave.hansen@linux.intel.com Subject: Re: [PATCH 15/19] x86, mpx: do 32-bit-only cmpxchg for 32-bit apps In-Reply-To: <20150519062534.56F53A63@viggo.jf.intel.com> Message-ID: References: <20150519062528.E2D5DDFF@viggo.jf.intel.com> <20150519062534.56F53A63@viggo.jf.intel.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001,URIBL_BLOCKED=0.001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 18 May 2015, Dave Hansen wrote: > From: Dave Hansen > > user_atomic_cmpxchg_inatomic() actually looks at sizeof(*ptr) to > figure out how many bytes to copy. If we run it on a 64-bit > kernel with a 64-bit pointer, it will copy a 64-bit bounds > directory entry. That's fine, except when we have 32-bit > programs with 32-bit bounds directory entries and we only *want* > 32-bits. > > This patch breaks the cmpxchg operation out in to its own > function and performs the 32-bit type swizzling in there. > > Note, the "64-bit" version of this code _would_ work on a > 32-bit-only kernel. The issue this patch addresses is only for > when the kernel's 'long' is mismatched from the size of the > bounds directory entry of the process we are working on. > > The new helper modifies 'actual_old_val' or returns an error. > But gcc doesn't know this, so it warns about 'actual_old_val' > being unused. Shut it up with an uninitialized_var(). > > Signed-off-by: Dave Hansen Reviewed-by: Thomas Gleixner