Re: [PATCH] arp_queue: serializing unlink + kfree_skb

David S. Miller wrote:

	This document is intended to serve as a guide to Linux port
maintainers on how to implement atomic counter and bitops operations
properly.

Finally, some light is shed into one of the most arcane areas of
the kernel ;-) Thanks !

Unlike the above routines, it is required that explicit memory
barriers are performed before and after the operation.  It must
be done such that all memory operations before and after the
atomic operation calls are strongly ordered with respect to the
atomic operation itself.

Hmm, given that this description will not only be read by implementers
of atomic functions, but also by users, the "explicit memory barriers"
may be confusing. Who does them, the atomic_* function, or the user ?
In fact, I would call them "implicit", because they're hidden in the
atomic_foo functions :-)

	void smb_mb__before_atomic_dec(void);
	void smb_mb__after_atomic_dec(void);
	void smb_mb__before_atomic_inc(void);
	void smb_mb__after_atomic_dec(void);

s/smb_/smp/ :-)

Do they also work for atomic_add and atomic_sub, or do we have to
fall back to smb_mb or atomic_add_return (see below) there ?

With the memory barrier semantics required of the atomic_t
operations which return values, the above sequence of memory
visibility can never happen.

What happens if the operation could return a value, but the user
ignores it ? E.g. if I don't like smp_mb__*, could I just use

	atomic_inc_and_test(foo);

instead of

	smp_mb__before_atomic_inc();
	atomic_inc(foo);
	smp_mb__after_atomic_dec();

? If yes, is this a good idea ?

These routines, like the atomic_t counter operations returning
values, require explicit memory barrier semantics around their
execution.

Very confusing: the barriers aren't around the routines (that
is something the user would be doing), but around whatever does
the atomic stuff inside them.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/