From: William Lee Irwin III <wli@holomorphy.com>
To: Stephen Hemminger <shemminger@osdl.org>
Cc: Andrew Morton <akpm@digeo.com>,
green@namesys.com,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
hch@lst.de, jack@suse.cz, mason@suse.com
Subject: Re: ext2 FS corruption with 2.5.59.
Date: Mon, 27 Jan 2003 15:59:39 -0800 [thread overview]
Message-ID: <20030127235939.GC780@holomorphy.com> (raw)
In-Reply-To: <1043708361.10153.151.camel@dell_ss3.pdx.osdl.net>
William Lee Irwin III <wli@holomorphy.com> wrote:
>>>>> Ticket locks need atomic fetch and increment. These don't look right.
On Mon, Jan 27, 2003 at 02:59:21PM -0800, Stephen Hemminger wrote:
> Atomic fetch/increment is not necessary since it is assumed that
> only a single writer is doing the increment at a time, either with a
> lock or a semaphore. The fr_write_lock primitive incorporates the
> spinlock and the sequence number.
Ticket locks still need atomic fetch and increment. You don't because
not only are you not implementing a ticket lock, you've got an outright
spinlock around the fetch and increment.
William Lee Irwin III <wli@holomorphy.com> wrote:
>>> (1) increment ->pre_sequence
>>> (2) wmb()
>>> (3) get inode->i_size
>>> (4) wmb()
>>> (5) increment ->post_sequence
>>> (6) wmb()
>>> Supposing the overall scheme is sound, one of the wmb()'s is unnecessary;
On Mon, Jan 27, 2003 at 02:59:21PM -0800, Stephen Hemminger wrote:
> Each wmb() has a purpose. (2) is to make sure the first increment
> happens before the update. (4) makes sure the update happens before the
> second increment.
> The last wmb is unnecessary. Also on many architectures, the wmb()
> disappears since writes are never reordered.
This is apparently based on some misunderstanding wrt. thinking the
sequence of events above described a read. Obviously converting (3)
to "modify inode->i_size" makes the (4) wmb() necessary.
-- wli
next prev parent reply other threads:[~2003-01-27 23:51 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-23 12:38 ext2 FS corruption with 2.5.59 Oleg Drokin
2003-01-23 14:09 ` Hugh Dickins
2003-01-23 14:26 ` Oleg Drokin
2003-01-23 14:39 ` Oleg Drokin
2003-01-24 10:32 ` Andrew Morton
2003-01-24 12:39 ` Oleg Drokin
2003-01-25 6:53 ` Andrew Morton
2003-01-25 12:36 ` Oleg Drokin
2003-01-25 23:13 ` Andrew Morton
2003-01-26 9:25 ` Oleg Drokin
2003-01-26 3:04 ` Andrew Morton
2003-01-26 3:28 ` William Lee Irwin III
2003-01-26 3:46 ` Andrew Morton
2003-01-26 4:14 ` William Lee Irwin III
2003-01-26 5:10 ` Andrew Morton
2003-01-27 22:59 ` Stephen Hemminger
2003-01-27 23:59 ` William Lee Irwin III [this message]
2003-01-26 11:11 ` Anton Blanchard
2003-01-26 11:23 ` Andrew Morton
2003-01-28 13:50 ` Christoph Hellwig
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=20030127235939.GC780@holomorphy.com \
--to=wli@holomorphy.com \
--cc=akpm@digeo.com \
--cc=green@namesys.com \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=mason@suse.com \
--cc=shemminger@osdl.org \
/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