From: "David S. Miller" <davem@davemloft.net>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: anton@samba.org, okir@suse.de, netdev@oss.sgi.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arp_queue: serializing unlink + kfree_skb
Date: Thu, 3 Feb 2005 14:19:01 -0800 [thread overview]
Message-ID: <20050203141901.5ce04c92.davem@davemloft.net> (raw)
In-Reply-To: <20050203203010.GA7081@gondor.apana.org.au>
On Fri, 4 Feb 2005 07:30:10 +1100
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Fri, Feb 04, 2005 at 01:27:05AM +1100, Anton Blanchard wrote:
> >
> > Architectures should guarantee that any of the atomics and bitops that
> > return values order in both directions. So you dont need the
> > smp_mb__before_atomic_dec here.
>
> I wasn't aware of this requirement before. However, if this is so,
> why don't we get rid of the smp_mb__* macros?
They are for cases where you want strict ordering even for the
non-return-value-giving atomic_t ops.
Actually.... Herbert has a point. By Anton's specification, several
uses in 2.6.x I see of these smp_mb__*() routines are bogus. Case
in point, look at mm/filemap.c:
void fastcall unlock_page(struct page *page)
{
smp_mb__before_clear_bit();
if (!TestClearPageLocked(page))
BUG();
smp_mb__after_clear_bit();
wake_up_page(page, PG_locked);
}
TestClearPageLocked() uses one of the bitops returning a value, so
must be providing the explicit memory barriers in it's implementation.
void end_page_writeback(struct page *page)
{
if (!TestClearPageReclaim(page) || rotate_reclaimable_page(page)) {
if (!test_clear_page_writeback(page))
BUG();
}
smp_mb__after_clear_bit();
wake_up_page(page, PG_writeback);
}
Same thing there.
Looking at include/linux/sunrpc/sched.h, those uses are legitimate,
correct, and needed. As is the put_bh() use in include/linux/buffer_head.h
There are several other correct and necessary uses in:
include/linux/interrupt.h
include/linux/netdevice.h
include/linux/nfs_page.h
include/linux/spinlock.h
net/core/dev.c
net/sunrpc/sched.c
sound/pci/bt87x.c
fs/buffer.c
fs/nfs/pagelist.c
drivers/block/ll_rw_blk.c
arch/ppc64/kernel/smp.c
arch/i386/kernel/smp.c
arch/i386/mach-voyager/smp.c
I'm working on a rough but rather complete draft Anton said needs
to be written to explicitly spell out the atomic_t and bitops
stuff.
next prev parent reply other threads:[~2005-02-03 22:19 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-31 10:29 [PATCH] arp_queue: serializing unlink + kfree_skb Olaf Kirch
2005-01-31 11:33 ` Herbert Xu
2005-02-03 0:20 ` David S. Miller
2005-02-03 11:12 ` Herbert Xu
2005-02-04 0:34 ` David S. Miller
2005-02-03 14:27 ` Anton Blanchard
2005-02-03 18:14 ` David S. Miller
2005-02-03 20:30 ` Herbert Xu
2005-02-03 22:19 ` David S. Miller [this message]
2005-02-03 23:50 ` Herbert Xu
2005-02-04 0:49 ` David S. Miller
2005-02-04 1:20 ` Herbert Xu
2005-02-04 1:23 ` David S. Miller
2005-02-04 1:55 ` Herbert Xu
2005-02-04 11:16 ` Olaf Kirch
2005-02-06 1:14 ` David S. Miller
2005-02-03 23:08 ` David S. Miller
2005-02-04 11:33 ` Herbert Xu
2005-02-04 23:48 ` David S. Miller
2005-02-05 6:24 ` David S. Miller
2005-02-05 6:50 ` Herbert Xu
2005-02-10 4:23 ` Werner Almesberger
2005-02-10 4:56 ` Herbert Xu
2005-02-11 3:46 ` David S. Miller
2005-02-11 3:50 ` David S. Miller
2005-02-11 4:27 ` Werner Almesberger
2005-02-11 5:04 ` Dmitry Torokhov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050203141901.5ce04c92.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=anton@samba.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@oss.sgi.com \
--cc=okir@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).