Pete Zaitcev (zaitcev) wrote,
Pete Zaitcev

The mb() and programming smarts

Roland writes:

However, I still think that using a spinlock around an assignment that’s atomic anyway is at best pretty silly. If you just need a memory barrier, then put an explicit mb() (or wmb() or rmb()) there, along with a fat comment about why you need to mess with memory barriers anyway.


In theory, it's possible to program in Linux kernel by using nothing but mb(). In practice, expirience teaches us that every use of mb() in drivers is a bug. I'm not kidding here. For some reason, even competent and experienced hackers cannot get it right.

I have no idea why it is so, and I don't want to go into the ESR's territory of speculation, "curse of the gifted", and such. I just want anyone who writes drivers to burn it into their minds that memory barriers are off limits (there are some very specific exceptions for mailboxes on 10GE cards and things like that, but nonetheless).

Keeping people from writing code which blows up when Red Hat ships it and customers run it on bigger boxes than the developer's laptop is an old hobby of mine. For example, my article about the dangers of read-write locks and spin_lock_bh was written back in 2002, when I blogged at Advogato [link]. But this barrier business is worse, because it affects more than just novices.

Tags: linux

  • Today's WTF

    Linux kernel development discussion at God, why?

  • Tytso has gone mad

    Requesting all applications to add fsync() before close() is madness [*]. Especially fabulous is how, in the same breath, he proposes disabling…

  • ツンデレ★りなっくす

    「 ツンデレ★りなっくす」がほしいです。 Maybe I should add it to some kind of wishlist? Too bad it doesn't work across countries.

  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded