Re: [PATCH] arp_queue: serializing unlink + kfree_skb

[Werner Almesberger]

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@xxxxxxxxxxxxxxx /
/_http://www.almesberger.net/____________________________________________/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/