Messages in this thread | | | From | Linus Torvalds <> | Date | Fri, 28 Oct 2011 05:40:53 -0700 | Subject | Re: >Re: [RFC] should VM_BUG_ON(cond) really evaluate cond |
| |
On Fri, Oct 28, 2011 at 5:19 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > "Sane interfaces" are important. Insane interfaces lead to bugs.
Qutie frankly, if I do "atomic_read()", I do expect to get a single value. If I don't get a single value, but some mixture of two values, I'd personally go
wtf, what does that "atomic" mean in "atomic_read()"?
and I think that's a reasonable wtf to ask.
That said, as mentioned, I don't know of any way to tell gcc "at most once".
Hmm.
Except perhaps using inline asm. Something like this might work:
static inline int atomic_read(const atomic_t *v) { int val; asm("":"=r" (val):"0" (v->value)); return val; }
(totally untested, but you get the idea: use a non-volatile asm to make sure that gcc doesn't think it can re-load the value).
That's the trick we use in asmlinkage_protect() and a couple of other places. It *should* make gcc able to optimize the value away entirely if it isn't used, but will stop gcc from doing the reload magic.
Does that work for the test-case with VM_BUG_ON()?
Linus
| |