From: "Stephen C. Tweedie" <sct@redhat.com>
To: Marcelo Tosatti <marcelo@conectiva.com.br>
Cc: Linus Torvalds <torvalds@transmeta.com>,
"Stephen C. Tweedie" <sct@redhat.com>,
Alexander Viro <viro@math.psu.edu>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: generic_osync_inode/ext2_fsync_inode still not safe
Date: Tue, 17 Apr 2001 14:09:28 +0100 [thread overview]
Message-ID: <20010417140928.C2505@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.21.0104140632300.1615-100000@freak.distro.conectiva>
In-Reply-To: <Pine.LNX.4.21.0104140632300.1615-100000@freak.distro.conectiva>; from marcelo@conectiva.com.br on Sat, Apr 14, 2001 at 07:24:42AM -0300
Hi,
On Sat, Apr 14, 2001 at 07:24:42AM -0300, Marcelo Tosatti wrote:
>
> As described earlier, code which wants to write an inode cannot rely on
> the I_DIRTY bits (on inode->i_state) being clean to guarantee that the
> inode and its dirty pages, if any, are safely synced on disk.
Indeed --- for all such structures, including pages, buffer_heads and
inodes, you can only assume that the object is safely on disk if you
have checked both the dirty bit AND the locked bit. If you find it
locked but clean, then a writeout may be in progress, so you need to
do a wait_on_* to be really sure that the write has completed.
> The reason for that is sync_one() --- it cleans the I_DIRTY bits of an
> inode, sets the I_LOCK and starts a writeout.
As long as it is setting the I_LOCK bit, then that's fine.
> The easy and safe fix is to simply remove the I_DIRTY_* checks from
> generic_osync_inode and ext2_fsync_inode. Easy but slow. Another fix would
> be to make sync_one() unconditionally synchronous... slow.
Just make the *sync functions look for the locked bit and do a wait on
the inode if it is locked.
Cheers,
Stephen
next prev parent reply other threads:[~2001-04-17 13:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-14 10:24 generic_osync_inode/ext2_fsync_inode still not safe Marcelo Tosatti
2001-04-17 13:09 ` Stephen C. Tweedie [this message]
2001-04-18 9:45 ` Marcelo Tosatti
2001-04-20 20:27 ` Stephen C. Tweedie
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=20010417140928.C2505@redhat.com \
--to=sct@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
--cc=torvalds@transmeta.com \
--cc=viro@math.psu.edu \
/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