tmpfs time granularity fix from Hugh

diff --git a/queue-2.6.16/series b/queue-2.6.16/series
index 6a88389349331b501124f2fc4a64dec463104e9c..3e9419c7cb552246284c59339ca97b93d6fd7456 100644 (file)
--- a/queue-2.6.16/series
+++ b/queue-2.6.16/series
@@ -3,3 +3,4 @@ sparc64-fix-d-cache-corruption-in-mremap.patch
 sparc64-respect-gfp_t-argument-to-dma_alloc_coherent.patch
 sparc64-fix-missing-fold-at-end-of-checksums.patch
 missed-error-checking-for-intent-s-filp-in-open_namei.patch
+tmpfs-time-granularity-fix-for-time-going-backwards.patch

diff --git a/queue-2.6.16/tmpfs-time-granularity-fix-for-time-going-backwards.patch b/queue-2.6.16/tmpfs-time-granularity-fix-for-time-going-backwards.patch
new file mode 100644 (file)
index 0000000..67b21dc
--- /dev/null
+++ b/queue-2.6.16/tmpfs-time-granularity-fix-for-time-going-backwards.patch
@@ -0,0 +1,44 @@
+From hugh_dickins@symantec.com  Tue Jun 13 10:08:40 2006
+Date: Tue, 13 Jun 2006 18:06:11 +0100 (BST)
+From: Hugh Dickins <hugh@veritas.com>
+To: Chris Wright <chrisw@sous-sol.org>
+cc: "Robin H. Johnson" <robbat2@gentoo.org>, Andi Kleen <ak@suse.de>,         stable@kernel.org
+Subject: tmpfs: time granularity fix for [acm]time going backwards
+
+From: Robin H. Johnson <robbat2@gentoo.org>
+
+I noticed a strange behavior in a tmpfs file system the other day, while
+building packages - occasionally, and seemingly at random, make decided to
+rebuild a target. However, only on tmpfs.
+
+A file would be created, and if checked, it had a sub-second timestamp.
+However, after an utimes related call where sub-seconds should be set, they
+were zeroed instead. In the case that a file was created, and utimes(...,NULL)
+was used on it in the same second, the timestamp on the file moved backwards.
+
+After some digging, I found that this was being caused by tmpfs not having a
+time granularity set, thus inheriting the default 1 second granularity.
+
+Hugh adds: yes, we missed tmpfs when the s_time_gran mods went into 2.6.11.
+Unfortunately, the granularity of CURRENT_TIME, often used in filesystems,
+does not match the default granularity set by alloc_super.  A few more such
+discrepancies have been found, but this is the most important to fix now.
+
+Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
+Acked-by: Andi Kleen <ak@suse.de>
+Signed-off-by: Hugh Dickins <hugh@veritas.com>
+Signed-off-by: Chris Wright <chrisw@sous-sol.org>
+---
+ mm/shmem.c |    1 +
+ 1 file changed, 1 insertion(+)
+
+--- linux-2.6.16.20.orig/mm/shmem.c
++++ linux-2.6.16.20/mm/shmem.c
+@@ -2100,6 +2100,7 @@ static int shmem_fill_super(struct super
+       sb->s_blocksize_bits = PAGE_CACHE_SHIFT;
+       sb->s_magic = TMPFS_MAGIC;
+       sb->s_op = &shmem_ops;
++      sb->s_time_gran = 1;
+ 
+       inode = shmem_get_inode(sb, S_IFDIR | mode, 0);
+       if (!inode)