On Tue, 2006-06-27 at 16:24 +0100, Keir Fraser wrote:
> On 27 Jun 2006, at 16:06, Hollis Blanchard wrote:
>
> > In the couple cases so far, we know that even though the field is only
> > one or two bytes, it's actually safe to do a four-byte load/store to it
> > because the containing structure is large enough.
> >
> > I'm not really comfortable with making that a blanket assumption. I'd
> > really like to know exactly what we're overwriting when performing
> > these
> > hacks^Woperations.
>
> You won't be overwriting anything else since you'll be performing an
> atomic read-modify-write that does not change any of the bits outside
> the subword of interest. More precisely, you may overwrite those bits
> outside the subword, but it's guaranteed to be with the current
> contents so there'll be no externally visible change and you won't
> clobber anything.
Right, I'm not worried about clobbering data. I am a little worried
about false conflicts in the reservations. Atomics on PPC, and many
other processors, are implemented as "load with reservation; conditional
store", where conditional store fails if another processor conflicted
with the reservation. I think typically a processor only has a single
reservation. Practically speaking this probably isn't likely to hit us,
but the whole thing is really making me uncomfortable.
> Since you'll do an aligned longword operation you
> can't end up straddling a page boundary or anything nasty like that.
OK, that's a good point.
In general I'm skeptical of blindly performing these operations on
unknown data. I think it's pretty clear that is not a good interface,
and what you're suggesting is codifying this behavior in the interface.
More practically speaking, I would be shocked if the Linux maintainers
would accept that sort of change to their atomic interfaces.
--
Hollis Blanchard
IBM Linux Technology Center
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home