From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Eric Dumazet <dada1@cosmosbay.com>
Cc: Andrew Morton <akpm@osdl.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@elte.hu>, Jens Axboe <jens.axboe@oracle.com>
Subject: Re: [PATCH] splice : two smp_mb() can be omitted
Date: Tue, 31 Oct 2006 20:40:21 +1100 [thread overview]
Message-ID: <45471A05.20205@yahoo.com.au> (raw)
In-Reply-To: <4546FA81.1020804@cosmosbay.com>
Eric Dumazet wrote:
> This patch deletes two calls to smp_mb() that were done after
> mutex_unlock() that contains an implicit memory barrier.
Uh, there is nothing that says mutex_unlock or any unlock
functions contain an implicit smp_mb(). What is given is that the
lock and unlock obey aquire and release memory ordering,
respectively.
a = x;
xxx_unlock
b = y;
In this situation, the load of y can be executed before that of x.
And some architectures will even do so (i386 can, because the
unlock is an unprefixed store; ia64 can, because it uses a release
barrier in the unlock).
Whenever you rely on orderings of things *outside* locks (even
partially outside), you do need to be very careful about barriers
and can't rely on locks to do the right thing for you.
>
> The first one in splice_to_pipe(), where 'do_wakeup' is set to true only
> if pipe->inode is set (and in this case the
> if (pipe->inode)
> mutex_unlock(&pipe->inode->i_mutex);
> is done too)
>
> The second one in link_pipe(), following inode_double_unlock() that
> contains calls to mutex_unlock() too.
It *may* be the case that these can be removed, but not by virtue
of the fact that the smp_mb is redundant.
>
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
>
>
> ------------------------------------------------------------------------
>
> --- linux/fs/splice.c 2006-10-31 07:49:52.000000000 +0100
> +++ linux-ed/fs/splice.c 2006-10-31 08:04:58.000000000 +0100
> @@ -248,7 +248,6 @@
> mutex_unlock(&pipe->inode->i_mutex);
>
> if (do_wakeup) {
> - smp_mb();
> if (waitqueue_active(&pipe->wait))
> wake_up_interruptible(&pipe->wait);
> kill_fasync(&pipe->fasync_readers, SIGIO, POLL_IN);
> @@ -1518,7 +1517,6 @@
> * If we put data in the output pipe, wakeup any potential readers.
> */
> if (ret > 0) {
> - smp_mb();
> if (waitqueue_active(&opipe->wait))
> wake_up_interruptible(&opipe->wait);
> kill_fasync(&opipe->fasync_readers, SIGIO, POLL_IN);
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
next prev parent reply other threads:[~2006-10-31 9:40 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-30 9:03 [PATCH 1/2] lockdep: spin_lock_irqsave_nested() Peter Zijlstra
2006-10-30 9:06 ` [PATCH 2/2] lockdep: annotate bcsp driver Peter Zijlstra
2006-10-30 9:06 ` Ingo Molnar
2006-10-30 9:30 ` Marcel Holtmann
2006-10-30 9:31 ` [PATCH 2/2] lockdep: annotate bcsp driver - v2 Peter Zijlstra
2006-10-30 9:07 ` [PATCH 1/2] lockdep: spin_lock_irqsave_nested() Ingo Molnar
2006-10-30 13:12 ` Jarek Poplawski
2006-10-30 13:27 ` Jarek Poplawski
2006-10-30 13:40 ` [PATCH 1/2] lockdep: spin_lock_irqsave_nested() -v2 Peter Zijlstra
2006-10-30 14:12 ` Jarek Poplawski
2006-10-31 6:48 ` [PATCH 1/2] lockdep: spin_lock_irqsave_nested() Andrew Morton
2006-10-31 7:25 ` [PATCH] splice : two smp_mb() can be omitted Eric Dumazet
2006-10-31 7:32 ` Jens Axboe
2006-10-31 7:41 ` Eric Dumazet
2006-10-31 7:46 ` Jens Axboe
2006-10-31 9:40 ` Nick Piggin [this message]
2006-10-31 9:49 ` Jens Axboe
2006-10-31 10:51 ` Eric Dumazet
2006-10-31 22:16 ` Nick Piggin
2006-10-31 23:08 ` Eric Dumazet
2006-10-31 23:45 ` Nick Piggin
2006-11-02 17:02 ` [PATCH] splice : Must fully check for fifos Eric Dumazet
2006-11-02 17:05 ` Eric Dumazet
2006-11-02 19:07 ` Jens Axboe
2006-11-03 8:50 ` Jens Axboe
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=45471A05.20205@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=dada1@cosmosbay.com \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.