>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 14.03.08 12:59 >>>
>On 14/3/08 11:55, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> 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.
>>
>> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home