linux-kernel - Re: [PATCH 0/3] fs/sysv: stop using write_supers and s

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1342538038.1813.1.camel@koala>
Date:	Tue, 17 Jul 2012 18:13:58 +0300
From:	Artem Bityutskiy <dedekind1@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Al Viro <viro@...IV.linux.org.uk>,
	Linux Kernel Maling List <linux-kernel@...r.kernel.org>,
	Linux FS Maling List <linux-fsdevel@...r.kernel.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH 0/3] fs/sysv: stop using write_supers and s_dirt

From: Artem Bityutskiy <artem.bityutskiy@...ux.intel.com>
Date: Tue, 3 Jul 2012 15:47:44 +0300
Subject: [PATCH] fs/sysv: stop using write_super and s_dirt

It does not look like sysv FS needs 'write_super()' at all, because all it
does is a timestamp update. I cannot test this patch, because this
file-system is so old and probably has not been used by anyone for years,
so there are no tools to create it in Linux.

In sysv FS marking the superblock as dirty is basically marking the superblock
buffers as drity and then setting the s_dirt flag. And when 'write_super()' is
executed to handle the s_dirt flag, we just update the timestamp and again mark
the superblock buffer as dirty. The reason for this strange behavior is
probably that the Linux sysv implementation is trying to do what sysv itself
was doing:

"It's the way sysv itself does stuff. The timestamp on v7/sys3/sys5
reflects the clock on the box. A lot of ancient boxes with no decent
hardware clocks used to reset the system time off the root fs superblock
on a loss of power" (Alan Cox).

However, the Linux sysv FS implementation is very unlikely of much help for
clock-less systems anyway, because it updates the superblock time-stamp _only_
if there was write activity, therwise it does not.

Thus, we can update the timestamp more opprtunistically - on unmount or remount
of sync, and nothing should change. So this patch removes 'sysv_write_super()'
and 's_dirt'.

Signed-off-by: Artem Bityutskiy <artem.bityutskiy@...ux.intel.com>
---

Updated the changelog, nothing else.

 fs/sysv/inode.c |   10 ----------
 fs/sysv/sysv.h  |    1 -
 2 files changed, 0 insertions(+), 11 deletions(-)

diff --git a/fs/sysv/inode.c b/fs/sysv/inode.c
index f20ffe3..80e1e2b 100644
--- a/fs/sysv/inode.c
+++ b/fs/sysv/inode.c
@@ -43,7 +43,6 @@ static int sysv_sync_fs(struct super_block *sb, int wait)
 	 * then attach current time stamp.
 	 * But if the filesystem was marked clean, keep it clean.
 	 */
-	sb->s_dirt = 0;
 	old_time = fs32_to_cpu(sbi, *sbi->s_sb_time);
 	if (sbi->s_type == FSTYPE_SYSV4) {
 		if (*sbi->s_sb_state == cpu_to_fs32(sbi, 0x7c269d38 - old_time))
@@ -57,14 +56,6 @@ static int sysv_sync_fs(struct super_block *sb, int wait)
 	return 0;
 }

-static void sysv_write_super(struct super_block *sb)
-{
-	if (!(sb->s_flags & MS_RDONLY))
-		sysv_sync_fs(sb, 1);
-	else
-		sb->s_dirt = 0;
-}
-
 static int sysv_remount(struct super_block *sb, int *flags, char *data)
 {
 	struct sysv_sb_info *sbi = SYSV_SB(sb);
@@ -351,7 +342,6 @@ const struct super_operations sysv_sops = {
 	.write_inode	= sysv_write_inode,
 	.evict_inode	= sysv_evict_inode,
 	.put_super	= sysv_put_super,
-	.write_super	= sysv_write_super,
 	.sync_fs	= sysv_sync_fs,
 	.remount_fs	= sysv_remount,
 	.statfs		= sysv_statfs,
diff --git a/fs/sysv/sysv.h b/fs/sysv/sysv.h
index 11b0767..0bc35fd 100644
--- a/fs/sysv/sysv.h
+++ b/fs/sysv/sysv.h
@@ -117,7 +117,6 @@ static inline void dirty_sb(struct super_block *sb)
 	mark_buffer_dirty(sbi->s_bh1);
 	if (sbi->s_bh1 != sbi->s_bh2)
 		mark_buffer_dirty(sbi->s_bh2);
-	sb->s_dirt = 1;
 }

-- 
1.7.7.6

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)