Skip to content

Commit

Permalink
UBIFS: nuke pdflush from comments
Browse files Browse the repository at this point in the history
The pdflush thread is long gone, so this patch removes references to pdflush
from UBIFS comments.

Signed-off-by: Artem Bityutskiy <[email protected]>
Signed-off-by: Al Viro <[email protected]>
  • Loading branch information
dedekind authored and Al Viro committed Aug 4, 2012
1 parent e76e0ec commit 5c57f20
Show file tree
Hide file tree
Showing 2 changed files with 6 additions and 6 deletions.
10 changes: 5 additions & 5 deletions fs/ubifs/file.c
Original file line number Diff line number Diff line change
Expand Up @@ -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 ->
Expand Down
2 changes: 1 addition & 1 deletion fs/ubifs/super.c
Original file line number Diff line number Diff line change
Expand Up @@ -303,7 +303,7 @@ static int ubifs_write_inode(struct inode *inode, struct writeback_control *wbc)
mutex_lock(&ui->ui_mutex);
/*
* Due to races between write-back forced by budgeting
* (see 'sync_some_inodes()') and pdflush write-back, the inode may
* (see 'sync_some_inodes()') and background write-back, the inode may
* have already been synchronized, do not do this again. This might
* also happen if it was synchronized in an VFS operation, e.g.
* 'ubifs_link()'.
Expand Down

0 comments on commit 5c57f20

Please sign in to comment.