netdev
[Top] [All Lists]

Re: [PATCH] arp_queue: serializing unlink + kfree_skb

To: "David S. Miller" <davem@xxxxxxxxxxxxx>
Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb
From: Dmitry Torokhov <dtor_core@xxxxxxxxxxxxx>
Date: Fri, 11 Feb 2005 00:04:11 -0500
Cc: Werner Almesberger <wa@xxxxxxxxxxxxxxx>, herbert@xxxxxxxxxxxxxxxxxxx, anton@xxxxxxxxx, okir@xxxxxxx, netdev@xxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx
In-reply-to: <20050210195026.09b507e7.davem@xxxxxxxxxxxxx>
References: <20050131102920.GC4170@xxxxxxx> <20050210012304.E25338@xxxxxxxxxxxxxxx> <20050210195026.09b507e7.davem@xxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: KMail/1.7.2
On Thursday 10 February 2005 22:50, David S. Miller wrote:
> > > 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.
> 
> Absolutely, I agree.  My fingers even itched as I typed those lines
> in.  I didn't change the wording because I couldn't come up with
> anything better.

What about the following:

Unlike the routines above, these functions should always perform memory
barriers before and after the operation in question so that all memory
accesses before and after the atomic operation are strongly ordered with
respect to the atomic operation itself.

-- 
Dmitry


<Prev in Thread] Current Thread [Next in Thread>