Prev: ext2: return -ENODATA for NULL i_file_acl in ext2_xattr_list
Next: Yama: turn process ancestry check into function
From: H. Peter Anvin on 13 Jul 2010 20:10 I believe that's how it is actually implemented though, and I believe we'd have failures all over if that was not true. "Jeremy Fitzhardinge" <jeremy(a)goop.org> wrote: >On 07/13/2010 03:14 PM, H. Peter Anvin wrote: >> Actually, I believe volatile operations (including asm volatile) are >> strictly ordered *with respect to other volatile operations*. > >The documentation makes no reference to that property; in fact it >suggests it is outright not true: > > Note that even a volatile `asm' instruction can be moved relative to > other > code, including across jump instructions. For example, on many targets > there is a system register which can be set to control the rounding > mode of floating point operations. You might try setting it with a > volatile `asm', like this PowerPC example: > > asm volatile("mtfsf 255,%0" : : "f" (fpenv)); > sum = x + y; > > This will not work reliably, as the compiler may move the addition > back before the volatile `asm'. To make it work you need to add an > artificial dependency to the `asm' referencing a variable in the > code you don't want moved, for example: > > asm volatile ("mtfsf 255,%1" : "=X"(sum): "f"(fpenv)); > sum = x + y; > > Similarly, you can't expect a sequence of volatile `asm' > instructions to remain perfectly consecutive. > [...] > An `asm' instruction without any output operands will be treated > identically to a volatile `asm' instruction. > >> As such I >> would think we'd want to keep the "memory" clobber here, to make it >> strictly ordered with regards to *all* memory operations. >> > >That would keep its overall effect consistent. > > J -- Sent from my mobile phone. Please pardon any lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |