summaryrefslogtreecommitdiffstats
path: root/fs/ubifs/file.c
diff options
context:
space:
mode:
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>2012-08-27 07:08:39 -0700
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2012-08-27 07:08:39 -0700
commit9db48aaf18d675ac41f550c9384154e0c00de2ef (patch)
tree70a19b9164c103e5f52dddff609e01672f8ef616 /fs/ubifs/file.c
parent0592969e73ae50ce6852d1aff3d222a335289094 (diff)
parentfea7a08acb13524b47711625eebea40a0ede69a0 (diff)
Merge 3.6-rc3 into driver-core-next
This picks up the printk fixes in 3.6-rc3 that are needed in this branch. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'fs/ubifs/file.c')
-rw-r--r--fs/ubifs/file.c10
1 files changed, 5 insertions, 5 deletions
diff --git a/fs/ubifs/file.c b/fs/ubifs/file.c
index 35389ca2d26..7bd6e72afd1 100644
--- a/fs/ubifs/file.c
+++ b/fs/ubifs/file.c
@@ -37,11 +37,11 @@
*
* A thing to keep in mind: inode @i_mutex is locked in most VFS operations we
* implement. However, this is not true for 'ubifs_writepage()', which may be
- * called with @i_mutex unlocked. For example, when pdflush is doing background
- * write-back, it calls 'ubifs_writepage()' with unlocked @i_mutex. At "normal"
- * work-paths the @i_mutex is locked in 'ubifs_writepage()', e.g. in the
- * "sys_write -> alloc_pages -> direct reclaim path". So, in 'ubifs_writepage()'
- * we are only guaranteed that the page is locked.
+ * called with @i_mutex unlocked. For example, when flusher thread is doing
+ * background write-back, it calls 'ubifs_writepage()' with unlocked @i_mutex.
+ * At "normal" work-paths the @i_mutex is locked in 'ubifs_writepage()', e.g.
+ * in the "sys_write -> alloc_pages -> direct reclaim path". So, in
+ * 'ubifs_writepage()' we are only guaranteed that the page is locked.
*
* Similarly, @i_mutex is not always locked in 'ubifs_readpage()', e.g., the
* read-ahead path does not lock it ("sys_read -> generic_file_aio_read ->