summaryrefslogtreecommitdiff
path: root/drivers/char/random.c
diff options
context:
space:
mode:
authorMatt Mackall <mpm@selenic.com>2010-01-29 21:50:36 +1300
committerGreg Kroah-Hartman <gregkh@suse.de>2010-02-09 04:50:58 -0800
commit8857a1abeb4572aa5237d0461165e983e01da707 (patch)
tree2301cf3b7efa990329229e9c3bc32a6e7fa6a932 /drivers/char/random.c
parent94af44b66b66bf9c848f11dc12fcd1558e55f995 (diff)
random: drop weird m_time/a_time manipulation
commit a996996dd75a9086b12d1cb4010f26e1748993f0 upstream. No other driver does anything remotely like this that I know of except for the tty drivers, and I can't see any reason for random/urandom to do it. In fact, it's a (trivial, harmless) timing information leak. And obviously, it generates power- and flash-cycle wasting I/O, especially if combined with something like hwrngd. Also, it breaks ubifs's expectations. Signed-off-by: Matt Mackall <mpm@selenic.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'drivers/char/random.c')
-rw-r--r--drivers/char/random.c8
1 files changed, 0 insertions, 8 deletions
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 04b505e5a5e2..53058de44a7f 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1051,12 +1051,6 @@ random_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
/* like a named pipe */
}
- /*
- * If we gave the user some bytes, update the access time.
- */
- if (count)
- file_accessed(file);
-
return (count ? count : retval);
}
@@ -1116,8 +1110,6 @@ static ssize_t random_write(struct file *file, const char __user *buffer,
if (ret)
return ret;
- inode->i_mtime = current_fs_time(inode->i_sb);
- mark_inode_dirty(inode);
return (ssize_t)count;
}