We're not yet sure this needs fixing in RHEL-4.  Chris Lalancette says:

From my quick perusal, it doesn't look like we need it.
But I'm not 100% sure.
As far as I can tell, evtchn_read() only gets called when a userland process is "read()" the /dev/evtchn device.
Which I don't think any userland process inside domU will.
So this whole thing is probably a dom0 only patch.

Just to be clear here; after a brief look, it looks like this is probably a dom0 only patch.  From what I can tell, this patch adds barriers and locks to evtchn_upcall (which domU's do not make) and evtchn_read (which only gets called when a userland process attempts to read the /dev/evtchn device, which I believe only happens in dom0).  Finally, this bug was only ever seen on ia64, which we don't have support for in RHEL-4 domU.  Nevertheless, we opened this bug so that we could track this and make absolutely sure we don't need the fix.  I'll take another look at it later on to be certain.

Chris Lalancette

After further review, I'm going to close this as WONTFIX, since I'm almost 100% sure this doesn't apply to RHEL-4.  Not only do I believe that this is a dom0 side fix only, it also should only concern ia64 because ia64 can re-order writes (whereas x86 cannot).  And since we don't have RHEL-4 PV ia64 port, this doesn't apply.

Chris Lalancette