generic_osync_inode/ext2_fsync_inode still not safe

• Next message: Stefan Traby: "Re: bizarre TCP behavior"
• Previous message: vivid_liou@dlink.com.tw: "why can't include /sys/types and /linux/fs.h in the same file"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi,

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.

The reason for that is sync_one() --- it cleans the I_DIRTY bits of an
inode, sets the I_LOCK and starts a writeout.

If sync_one() is called to write an inode _asynchronously_, there is no
guarantee that an inode will have its data fully synced on disk even if
the inode gets unlocked, which means the previous fix to
generic_osync_inode() is not safe.

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.

Any suggestion for a fast, safe, but simple fix to this bug?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

• Next message: Stefan Traby: "Re: bizarre TCP behavior"
• Previous message: vivid_liou@dlink.com.tw: "why can't include /sys/types and /linux/fs.h in the same file"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

This archive was generated by hypermail 2b29 : Sun Apr 15 2001 - 21:00:22 EST