| Message ID | 20171108004354.40308-1-shakeelb@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Nov 07, 2017 at 04:43:54PM -0800, Shakeel Butt wrote: > Commit 7994e6f72543 ("vfs: Move waiting for inode writeback from > end_writeback() to evict_inode()") removed inode_sync_wait() from > end_writeback() and commit dbd5768f87ff ("vfs: Rename end_writeback() > to clear_inode()") renamed end_writeback() to clear_inode(). After > these patches there is no sleeping operation in clear_inode(). So, > remove might_sleep() from it. Point, but... this is far from the worst annoyance in clear_inode(). Starting with "BUG_ON() under spin_lock_irq() is antisocial and not in a good way", of course, but that's not all - the whole cycling of ->tree_lock has already been done back in truncate_inode_pages_final() and we'd better have called that in all cases when ->i_data might have ever contained anything. The whole thing looks bogus these days... I wonder if we should simply move the remaining paranoia into destroy_inode() and get rid of the I_CLEAR completely...
diff --git a/fs/inode.c b/fs/inode.c index d1e35b53bb23..528f3159b928 100644 --- a/fs/inode.c +++ b/fs/inode.c @@ -497,7 +497,6 @@ EXPORT_SYMBOL(__remove_inode_hash); void clear_inode(struct inode *inode) { - might_sleep(); /* * We have to cycle tree_lock here because reclaim can be still in the * process of removing the last page (in __delete_from_page_cache())
Commit 7994e6f72543 ("vfs: Move waiting for inode writeback from end_writeback() to evict_inode()") removed inode_sync_wait() from end_writeback() and commit dbd5768f87ff ("vfs: Rename end_writeback() to clear_inode()") renamed end_writeback() to clear_inode(). After these patches there is no sleeping operation in clear_inode(). So, remove might_sleep() from it. Signed-off-by: Shakeel Butt <shakeelb@google.com> --- fs/inode.c | 1 - 1 file changed, 1 deletion(-)