Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 5c57f20b authored by Artem Bityutskiy's avatar Artem Bityutskiy Committed by Al Viro
Browse files

UBIFS: nuke pdflush from comments 



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

Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
parent e76e0ec9

fs/ubifs/file.c

+5 −5
Original line number Diff line number Diff line
@@ -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 ->

fs/ubifs/super.c

+1 −1
Original line number Diff line number Diff line
@@ -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()'.