apfs/linux-apfs
0
0
Fork 0
mirror of https://github.com/linux-apfs/linux-apfs.git synced 2026-05-01 15:00:59 -07:00
Code Issues Packages Projects Releases Wiki Activity

UBIFS: nuke pdflush from comments

Browse Source 
The pdflush thread is long gone, so this patch removes references to pdflush
from UBIFS comments.

Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
This commit is contained in:
Artem Bityutskiy
2012-07-25 18:12:14 +03:00
committed by Al Viro
parent e76e0ec984
commit 5c57f20b82
2 changed files with 6 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
fs/ubifs/file.c
+5 -5
View File
@@ -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 ->