From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH] x86: fix variable_test_bit() asmconstraints Date: Fri, 14 Mar 2008 13:46:49 +0000 Message-ID: <47DA8FD9.76E4.0078.0@novell.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 14.03.08 12:59 >>> >On 14/3/08 11:55, "Keir Fraser" wrote: > >>> Further, using 'void *' for the 'addr' parameter appears dangerous, >>> since bt{,c,r,s} access the full 32 bits (if 'unsigned long' was used >>> properly here, 64 bits for x86-64) pointed at, so invalid uses like >>> referencing a 'char' array cannot currently be caught. >>=20 >> Sure, but those invalid uses do exist, in x86-specific Xen code we = inherited >> from Linux (perhaps older versions of Linux though). I don't want a = huge patch >> that casts a large number of callers! > >I see what you mean though: what if one of these bogus users' fields is >adjacent to a legitimate byte-sized atomic variable (e.g., a bool_t)? >Perhaps we do need to fix this, and properly without casts. Correct. Or consider mis-aligned fields close to a page boundary. The intention I'm having here (and likewise on Linux, if I get signs back that this is going to be accepted) is to convert these to macros that this way allow knowing the original type. Based on the alignment of the type, different strategies will then need to be used (e.g. 1-byte aligned fields cannot be accessed with bt?, and 2-byte aligned fields can only be if the bit index is small enough, so and/or/xor will be preferable for the cases where no old bit status needs to be returned, and tweaking of the base address will need to be used in the other cases to make using bt? safe). Jan