* [regression 4.2-rc3] loop: xfstests xfs/073 deadlocked in low memory conditions
@ 2015-07-21 1:59 ` Dave Chinner
0 siblings, 0 replies; 20+ messages in thread
From: Dave Chinner @ 2015-07-21 1:59 UTC (permalink / raw)
To: Ming Lei; +Cc: Michal Hocko, linux-kernel, linux-mm, xfs
Hi Ming,
With the recent merge of the loop device changes, I'm now seeing
XFS deadlock on my single CPU, 1GB RAM VM running xfs/073.
The deadlocked is as follows:
kloopd1: loop_queue_read_work
xfs_file_iter_read
lock XFS inode XFS_IOLOCK_SHARED (on image file)
page cache read (GFP_KERNEL)
radix tree alloc
memory reclaim
reclaim XFS inodes
log force to unpin inodes
<wait for log IO completion>
xfs-cil/loop1: <does log force IO work>
xlog_cil_push
xlog_write
<loop issuing log writes>
xlog_state_get_iclog_space()
<blocks due to all log buffers under write io>
<waits for IO completion>
kloopd1: loop_queue_write_work
xfs_file_write_iter
lock XFS inode XFS_IOLOCK_EXCL (on image file)
<wait for inode to be unlocked>
[The full stack traces are below].
i.e. the kloopd, with it's split read and write work queues, has
introduced a dependency through memory reclaim. i.e. that writes
need to be able to progress for reads make progress.
The problem, fundamentally, is that mpage_readpages() does a
GFP_KERNEL allocation, rather than paying attention to the inode's
mapping gfp mask, which is set to GFP_NOFS.
The didn't used to happen, because the loop device used to issue
reads through the splice path and that does:
error = add_to_page_cache_lru(page, mapping, index,
GFP_KERNEL & mapping_gfp_mask(mapping));
i.e. it pays attention to the allocation context placed on the
inode and so is doing GFP_NOFS allocations here and avoiding the
recursion problem.
[ CC'd Michal Hocko and the mm list because it's a clear exaple of
why ignoring the mapping gfp mask on any page cache allocation is
a landmine waiting to be tripped over. ]
Cheers,
Dave.
[81248.855166] kworker/u3:0 D ffff88003a8fadc8 11304 930 2 0x00000000
[81248.855166] Workqueue: kloopd1 loop_queue_read_work
[81248.855166] ffff88003a8fadc8 ffff880003e48000 ffff8800332fdd00 ffff88003a8fadb8
[81248.855166] ffff88003a8fc000 ffff88003a8faf18 ffff8800332fdd00 ffff88003a8faf10
[81248.855166] ffffffffffffffff ffff88003a8fade8 ffffffff81db608e ffff88003fc153c0
[81248.855166] Call Trace:
[81248.855166] [<ffffffff81db608e>] schedule+0x3e/0x90
[81248.855166] [<ffffffff81dba38f>] schedule_timeout+0x1cf/0x240
[81248.855166] [<ffffffff810cce16>] ? try_to_wake_up+0x1f6/0x330
[81248.855166] [<ffffffff81db7534>] wait_for_completion+0xb4/0x120
[81248.855166] [<ffffffff810cd010>] ? wake_up_q+0x70/0x70
[81248.855166] [<ffffffff810bc2d9>] flush_work+0xf9/0x170
[81248.855166] [<ffffffff810ba0d0>] ? destroy_worker+0x90/0x90
[81248.855166] [<ffffffff81513a2c>] xlog_cil_force_lsn+0xcc/0x250
[81248.855166] [<ffffffff815126f2>] _xfs_log_force_lsn+0x82/0x2f0
[81248.855166] [<ffffffff8151298e>] xfs_log_force_lsn+0x2e/0xa0
[81248.855166] [<ffffffff81501e49>] ? xfs_iunpin_wait+0x19/0x20
[81248.855166] [<ffffffff814fe686>] __xfs_iunpin_wait+0xb6/0x170
[81248.855166] [<ffffffff810e0f90>] ? autoremove_wake_function+0x40/0x40
[81248.855166] [<ffffffff81501e49>] xfs_iunpin_wait+0x19/0x20
[81248.855166] [<ffffffff814f6df2>] xfs_reclaim_inode+0x72/0x350
[81248.855166] [<ffffffff814f72e2>] xfs_reclaim_inodes_ag+0x212/0x350
[81248.855166] [<ffffffff81dbb07e>] ? _raw_spin_unlock+0xe/0x20
[81248.855166] [<ffffffff81dbb07e>] ? _raw_spin_unlock+0xe/0x20
[81248.855166] [<ffffffff814f74b3>] xfs_reclaim_inodes_nr+0x33/0x40
[81248.855166] [<ffffffff81507f19>] xfs_fs_free_cached_objects+0x19/0x20
[81248.855166] [<ffffffff811cf791>] super_cache_scan+0x191/0x1a0
[81248.855166] [<ffffffff811912d4>] shrink_slab.part.62.constprop.80+0x1b4/0x380
[81248.855166] [<ffffffff81194720>] shrink_zone+0x90/0xa0
[81248.855166] [<ffffffff811948b0>] do_try_to_free_pages+0x180/0x2c0
[81248.855166] [<ffffffff81194aaa>] try_to_free_pages+0xba/0x160
[81248.855166] [<ffffffff81189509>] __alloc_pages_nodemask+0x499/0x840
[81248.855166] [<ffffffff811c3d2f>] new_slab+0x6f/0x2c0
[81248.855166] [<ffffffff811c5baa>] __slab_alloc.constprop.75+0x3fa/0x580
[81248.855166] [<ffffffff817be438>] ? __radix_tree_preload+0x48/0xc0
[81248.855166] [<ffffffff817be438>] ? __radix_tree_preload+0x48/0xc0
[81248.855166] [<ffffffff811c620e>] kmem_cache_alloc+0x12e/0x160
[81248.855166] [<ffffffff817be438>] __radix_tree_preload+0x48/0xc0
[81248.855166] [<ffffffff817be519>] radix_tree_maybe_preload+0x19/0x20
[81248.855166] [<ffffffff81181b69>] __add_to_page_cache_locked+0x39/0x1f0
[81248.855166] [<ffffffff81181d68>] add_to_page_cache_lru+0x28/0x80
[81248.855166] [<ffffffff81209fc9>] mpage_readpages+0xb9/0x130
[81248.855166] [<ffffffff814e68e0>] ? __xfs_get_blocks+0x840/0x840
[81248.855166] [<ffffffff814e68e0>] ? __xfs_get_blocks+0x840/0x840
[81248.855166] [<ffffffff814e409d>] xfs_vm_readpages+0x1d/0x20
[81248.855166] [<ffffffff8118cfc9>] __do_page_cache_readahead+0x1b9/0x250
[81248.855166] [<ffffffff8118d13f>] ondemand_readahead+0xdf/0x270
[81248.855166] [<ffffffff81180fc6>] ? find_get_entry+0x66/0xb0
[81248.855166] [<ffffffff8118d362>] page_cache_async_readahead+0x92/0xc0
[81248.855166] [<ffffffff81182c3c>] generic_file_read_iter+0x41c/0x650
[81248.855166] [<ffffffff81db9664>] ? down_read+0x24/0x40
[81248.855166] [<ffffffff814f1d66>] xfs_file_read_iter+0xe6/0x2d0
[81248.855166] [<ffffffff811cba22>] vfs_iter_read+0x62/0xa0
[81248.855166] [<ffffffff81a98fcd>] loop_handle_cmd.isra.28+0x6dd/0xaa0
[81248.855166] [<ffffffff810cce16>] ? try_to_wake_up+0x1f6/0x330
[81248.855166] [<ffffffff81a99472>] loop_queue_read_work+0x12/0x20
[81248.855166] [<ffffffff810bd02e>] process_one_work+0x14e/0x410
[81248.855166] [<ffffffff810bd63e>] worker_thread+0x4e/0x460
[81248.855166] [<ffffffff810bd5f0>] ? rescuer_thread+0x300/0x300
[81248.855166] [<ffffffff810c288c>] kthread+0xec/0x110
[81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
[81248.855166] [<ffffffff81dbba5f>] ret_from_fork+0x3f/0x70
[81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
[81248.855166] kworker/0:0 D ffff88002ed8bb88 13896 948 2 0x00000000
[81248.855166] Workqueue: xfs-cil/loop1 xlog_cil_push_work
[81248.855166] ffff88002ed8bb88 ffffffff82368540 ffff880003e4be00 ffff88001a467cf0
[81248.855166] ffff88002ed8c000 ffff880005123cf8 ffff88001a467cf0 ffff880003e4be00
[81248.855166] ffff880005123cc0 ffff88002ed8bba8 ffffffff81db608e ffff88002ed8bba8
[81248.855166] Call Trace:
[81248.855166] [<ffffffff81db608e>] schedule+0x3e/0x90
[81248.855166] [<ffffffff81511266>] xlog_state_get_iclog_space+0xe6/0x330
[81248.855166] [<ffffffff810cd010>] ? wake_up_q+0x70/0x70
[81248.855166] [<ffffffff81511666>] xlog_write+0x1b6/0x870
[81248.855166] [<ffffffff8151316d>] xlog_cil_push+0x24d/0x400
[81248.855166] [<ffffffff81513335>] xlog_cil_push_work+0x15/0x20
[81248.855166] [<ffffffff810bd02e>] process_one_work+0x14e/0x410
[81248.855166] [<ffffffff810bd63e>] worker_thread+0x4e/0x460
[81248.855166] [<ffffffff810bd5f0>] ? rescuer_thread+0x300/0x300
[81248.855166] [<ffffffff810bd5f0>] ? rescuer_thread+0x300/0x300
[81248.855166] [<ffffffff810c288c>] kthread+0xec/0x110
[81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
[81248.855166] [<ffffffff81dbba5f>] ret_from_fork+0x3f/0x70
[81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
[81248.855166] kworker/u3:4 D ffff8800290439f8 12456 1066 2 0x00000000
[81248.855166] Workqueue: kloopd1 loop_queue_write_work
[81248.855166] ffff8800290439f8 ffffffff82368540 ffff8800332f9f00 ffff8800290439e8
[81248.855166] ffff880029044000 ffffffff00000000 ffff88001366cfd8 ffffffff00000002
[81248.855166] ffff8800332f9f00 ffff880029043a18 ffffffff81db608e ffff880029043a18
[81248.855166] Call Trace:
[81248.855166] [<ffffffff81db608e>] schedule+0x3e/0x90
[81248.855166] [<ffffffff81db9f3d>] rwsem_down_write_failed+0x13d/0x340
[81248.855166] [<ffffffff810cce16>] ? try_to_wake_up+0x1f6/0x330
[81248.855166] [<ffffffff814f2e46>] ? xfs_file_buffered_aio_write+0x66/0x250
[81248.855166] [<ffffffff817c76a3>] call_rwsem_down_write_failed+0x13/0x20
[81248.855166] [<ffffffff81db96bf>] ? down_write+0x3f/0x60
[81248.855166] [<ffffffff814fdea4>] xfs_ilock+0x154/0x1d0
[81248.855166] [<ffffffff814f2e46>] xfs_file_buffered_aio_write+0x66/0x250
[81248.855166] [<ffffffff8179264d>] ? kblockd_schedule_work+0x1d/0x30
[81248.855166] [<ffffffff8179dbc5>] ? blk_mq_kick_requeue_list+0x15/0x20
[81248.855166] [<ffffffff814f3136>] xfs_file_write_iter+0x106/0x120
[81248.855166] [<ffffffff811cbac3>] vfs_iter_write+0x63/0xa0
[81248.855166] [<ffffffff81a97828>] lo_write_bvec+0x58/0x100
[81248.855166] [<ffffffff81a99248>] loop_handle_cmd.isra.28+0x958/0xaa0
[81248.855166] [<ffffffff81a9941f>] loop_queue_write_work+0x8f/0xd0
[81248.855166] [<ffffffff810bd02e>] process_one_work+0x14e/0x410
[81248.855166] [<ffffffff810bd63e>] worker_thread+0x4e/0x460
[81248.855166] [<ffffffff810bd5f0>] ? rescuer_thread+0x300/0x300
[81248.855166] [<ffffffff810c288c>] kthread+0xec/0x110
[81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
[81248.855166] [<ffffffff81dbba5f>] ret_from_fork+0x3f/0x70
[81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* [regression 4.2-rc3] loop: xfstests xfs/073 deadlocked in low memory conditions
@ 2015-07-21 1:59 ` Dave Chinner
0 siblings, 0 replies; 20+ messages in thread
From: Dave Chinner @ 2015-07-21 1:59 UTC (permalink / raw)
To: Ming Lei; +Cc: Michal Hocko, linux-mm, linux-kernel, xfs
Hi Ming,
With the recent merge of the loop device changes, I'm now seeing
XFS deadlock on my single CPU, 1GB RAM VM running xfs/073.
The deadlocked is as follows:
kloopd1: loop_queue_read_work
xfs_file_iter_read
lock XFS inode XFS_IOLOCK_SHARED (on image file)
page cache read (GFP_KERNEL)
radix tree alloc
memory reclaim
reclaim XFS inodes
log force to unpin inodes
<wait for log IO completion>
xfs-cil/loop1: <does log force IO work>
xlog_cil_push
xlog_write
<loop issuing log writes>
xlog_state_get_iclog_space()
<blocks due to all log buffers under write io>
<waits for IO completion>
kloopd1: loop_queue_write_work
xfs_file_write_iter
lock XFS inode XFS_IOLOCK_EXCL (on image file)
<wait for inode to be unlocked>
[The full stack traces are below].
i.e. the kloopd, with it's split read and write work queues, has
introduced a dependency through memory reclaim. i.e. that writes
need to be able to progress for reads make progress.
The problem, fundamentally, is that mpage_readpages() does a
GFP_KERNEL allocation, rather than paying attention to the inode's
mapping gfp mask, which is set to GFP_NOFS.
The didn't used to happen, because the loop device used to issue
reads through the splice path and that does:
error = add_to_page_cache_lru(page, mapping, index,
GFP_KERNEL & mapping_gfp_mask(mapping));
i.e. it pays attention to the allocation context placed on the
inode and so is doing GFP_NOFS allocations here and avoiding the
recursion problem.
[ CC'd Michal Hocko and the mm list because it's a clear exaple of
why ignoring the mapping gfp mask on any page cache allocation is
a landmine waiting to be tripped over. ]
Cheers,
Dave.
[81248.855166] kworker/u3:0 D ffff88003a8fadc8 11304 930 2 0x00000000
[81248.855166] Workqueue: kloopd1 loop_queue_read_work
[81248.855166] ffff88003a8fadc8 ffff880003e48000 ffff8800332fdd00 ffff88003a8fadb8
[81248.855166] ffff88003a8fc000 ffff88003a8faf18 ffff8800332fdd00 ffff88003a8faf10
[81248.855166] ffffffffffffffff ffff88003a8fade8 ffffffff81db608e ffff88003fc153c0
[81248.855166] Call Trace:
[81248.855166] [<ffffffff81db608e>] schedule+0x3e/0x90
[81248.855166] [<ffffffff81dba38f>] schedule_timeout+0x1cf/0x240
[81248.855166] [<ffffffff810cce16>] ? try_to_wake_up+0x1f6/0x330
[81248.855166] [<ffffffff81db7534>] wait_for_completion+0xb4/0x120
[81248.855166] [<ffffffff810cd010>] ? wake_up_q+0x70/0x70
[81248.855166] [<ffffffff810bc2d9>] flush_work+0xf9/0x170
[81248.855166] [<ffffffff810ba0d0>] ? destroy_worker+0x90/0x90
[81248.855166] [<ffffffff81513a2c>] xlog_cil_force_lsn+0xcc/0x250
[81248.855166] [<ffffffff815126f2>] _xfs_log_force_lsn+0x82/0x2f0
[81248.855166] [<ffffffff8151298e>] xfs_log_force_lsn+0x2e/0xa0
[81248.855166] [<ffffffff81501e49>] ? xfs_iunpin_wait+0x19/0x20
[81248.855166] [<ffffffff814fe686>] __xfs_iunpin_wait+0xb6/0x170
[81248.855166] [<ffffffff810e0f90>] ? autoremove_wake_function+0x40/0x40
[81248.855166] [<ffffffff81501e49>] xfs_iunpin_wait+0x19/0x20
[81248.855166] [<ffffffff814f6df2>] xfs_reclaim_inode+0x72/0x350
[81248.855166] [<ffffffff814f72e2>] xfs_reclaim_inodes_ag+0x212/0x350
[81248.855166] [<ffffffff81dbb07e>] ? _raw_spin_unlock+0xe/0x20
[81248.855166] [<ffffffff81dbb07e>] ? _raw_spin_unlock+0xe/0x20
[81248.855166] [<ffffffff814f74b3>] xfs_reclaim_inodes_nr+0x33/0x40
[81248.855166] [<ffffffff81507f19>] xfs_fs_free_cached_objects+0x19/0x20
[81248.855166] [<ffffffff811cf791>] super_cache_scan+0x191/0x1a0
[81248.855166] [<ffffffff811912d4>] shrink_slab.part.62.constprop.80+0x1b4/0x380
[81248.855166] [<ffffffff81194720>] shrink_zone+0x90/0xa0
[81248.855166] [<ffffffff811948b0>] do_try_to_free_pages+0x180/0x2c0
[81248.855166] [<ffffffff81194aaa>] try_to_free_pages+0xba/0x160
[81248.855166] [<ffffffff81189509>] __alloc_pages_nodemask+0x499/0x840
[81248.855166] [<ffffffff811c3d2f>] new_slab+0x6f/0x2c0
[81248.855166] [<ffffffff811c5baa>] __slab_alloc.constprop.75+0x3fa/0x580
[81248.855166] [<ffffffff817be438>] ? __radix_tree_preload+0x48/0xc0
[81248.855166] [<ffffffff817be438>] ? __radix_tree_preload+0x48/0xc0
[81248.855166] [<ffffffff811c620e>] kmem_cache_alloc+0x12e/0x160
[81248.855166] [<ffffffff817be438>] __radix_tree_preload+0x48/0xc0
[81248.855166] [<ffffffff817be519>] radix_tree_maybe_preload+0x19/0x20
[81248.855166] [<ffffffff81181b69>] __add_to_page_cache_locked+0x39/0x1f0
[81248.855166] [<ffffffff81181d68>] add_to_page_cache_lru+0x28/0x80
[81248.855166] [<ffffffff81209fc9>] mpage_readpages+0xb9/0x130
[81248.855166] [<ffffffff814e68e0>] ? __xfs_get_blocks+0x840/0x840
[81248.855166] [<ffffffff814e68e0>] ? __xfs_get_blocks+0x840/0x840
[81248.855166] [<ffffffff814e409d>] xfs_vm_readpages+0x1d/0x20
[81248.855166] [<ffffffff8118cfc9>] __do_page_cache_readahead+0x1b9/0x250
[81248.855166] [<ffffffff8118d13f>] ondemand_readahead+0xdf/0x270
[81248.855166] [<ffffffff81180fc6>] ? find_get_entry+0x66/0xb0
[81248.855166] [<ffffffff8118d362>] page_cache_async_readahead+0x92/0xc0
[81248.855166] [<ffffffff81182c3c>] generic_file_read_iter+0x41c/0x650
[81248.855166] [<ffffffff81db9664>] ? down_read+0x24/0x40
[81248.855166] [<ffffffff814f1d66>] xfs_file_read_iter+0xe6/0x2d0
[81248.855166] [<ffffffff811cba22>] vfs_iter_read+0x62/0xa0
[81248.855166] [<ffffffff81a98fcd>] loop_handle_cmd.isra.28+0x6dd/0xaa0
[81248.855166] [<ffffffff810cce16>] ? try_to_wake_up+0x1f6/0x330
[81248.855166] [<ffffffff81a99472>] loop_queue_read_work+0x12/0x20
[81248.855166] [<ffffffff810bd02e>] process_one_work+0x14e/0x410
[81248.855166] [<ffffffff810bd63e>] worker_thread+0x4e/0x460
[81248.855166] [<ffffffff810bd5f0>] ? rescuer_thread+0x300/0x300
[81248.855166] [<ffffffff810c288c>] kthread+0xec/0x110
[81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
[81248.855166] [<ffffffff81dbba5f>] ret_from_fork+0x3f/0x70
[81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
[81248.855166] kworker/0:0 D ffff88002ed8bb88 13896 948 2 0x00000000
[81248.855166] Workqueue: xfs-cil/loop1 xlog_cil_push_work
[81248.855166] ffff88002ed8bb88 ffffffff82368540 ffff880003e4be00 ffff88001a467cf0
[81248.855166] ffff88002ed8c000 ffff880005123cf8 ffff88001a467cf0 ffff880003e4be00
[81248.855166] ffff880005123cc0 ffff88002ed8bba8 ffffffff81db608e ffff88002ed8bba8
[81248.855166] Call Trace:
[81248.855166] [<ffffffff81db608e>] schedule+0x3e/0x90
[81248.855166] [<ffffffff81511266>] xlog_state_get_iclog_space+0xe6/0x330
[81248.855166] [<ffffffff810cd010>] ? wake_up_q+0x70/0x70
[81248.855166] [<ffffffff81511666>] xlog_write+0x1b6/0x870
[81248.855166] [<ffffffff8151316d>] xlog_cil_push+0x24d/0x400
[81248.855166] [<ffffffff81513335>] xlog_cil_push_work+0x15/0x20
[81248.855166] [<ffffffff810bd02e>] process_one_work+0x14e/0x410
[81248.855166] [<ffffffff810bd63e>] worker_thread+0x4e/0x460
[81248.855166] [<ffffffff810bd5f0>] ? rescuer_thread+0x300/0x300
[81248.855166] [<ffffffff810bd5f0>] ? rescuer_thread+0x300/0x300
[81248.855166] [<ffffffff810c288c>] kthread+0xec/0x110
[81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
[81248.855166] [<ffffffff81dbba5f>] ret_from_fork+0x3f/0x70
[81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
[81248.855166] kworker/u3:4 D ffff8800290439f8 12456 1066 2 0x00000000
[81248.855166] Workqueue: kloopd1 loop_queue_write_work
[81248.855166] ffff8800290439f8 ffffffff82368540 ffff8800332f9f00 ffff8800290439e8
[81248.855166] ffff880029044000 ffffffff00000000 ffff88001366cfd8 ffffffff00000002
[81248.855166] ffff8800332f9f00 ffff880029043a18 ffffffff81db608e ffff880029043a18
[81248.855166] Call Trace:
[81248.855166] [<ffffffff81db608e>] schedule+0x3e/0x90
[81248.855166] [<ffffffff81db9f3d>] rwsem_down_write_failed+0x13d/0x340
[81248.855166] [<ffffffff810cce16>] ? try_to_wake_up+0x1f6/0x330
[81248.855166] [<ffffffff814f2e46>] ? xfs_file_buffered_aio_write+0x66/0x250
[81248.855166] [<ffffffff817c76a3>] call_rwsem_down_write_failed+0x13/0x20
[81248.855166] [<ffffffff81db96bf>] ? down_write+0x3f/0x60
[81248.855166] [<ffffffff814fdea4>] xfs_ilock+0x154/0x1d0
[81248.855166] [<ffffffff814f2e46>] xfs_file_buffered_aio_write+0x66/0x250
[81248.855166] [<ffffffff8179264d>] ? kblockd_schedule_work+0x1d/0x30
[81248.855166] [<ffffffff8179dbc5>] ? blk_mq_kick_requeue_list+0x15/0x20
[81248.855166] [<ffffffff814f3136>] xfs_file_write_iter+0x106/0x120
[81248.855166] [<ffffffff811cbac3>] vfs_iter_write+0x63/0xa0
[81248.855166] [<ffffffff81a97828>] lo_write_bvec+0x58/0x100
[81248.855166] [<ffffffff81a99248>] loop_handle_cmd.isra.28+0x958/0xaa0
[81248.855166] [<ffffffff81a9941f>] loop_queue_write_work+0x8f/0xd0
[81248.855166] [<ffffffff810bd02e>] process_one_work+0x14e/0x410
[81248.855166] [<ffffffff810bd63e>] worker_thread+0x4e/0x460
[81248.855166] [<ffffffff810bd5f0>] ? rescuer_thread+0x300/0x300
[81248.855166] [<ffffffff810c288c>] kthread+0xec/0x110
[81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
[81248.855166] [<ffffffff81dbba5f>] ret_from_fork+0x3f/0x70
[81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 20+ messages in thread
* [regression 4.2-rc3] loop: xfstests xfs/073 deadlocked in low memory conditions
@ 2015-07-21 1:59 ` Dave Chinner
0 siblings, 0 replies; 20+ messages in thread
From: Dave Chinner @ 2015-07-21 1:59 UTC (permalink / raw)
To: Ming Lei; +Cc: Michal Hocko, linux-kernel, linux-mm, xfs
Hi Ming,
With the recent merge of the loop device changes, I'm now seeing
XFS deadlock on my single CPU, 1GB RAM VM running xfs/073.
The deadlocked is as follows:
kloopd1: loop_queue_read_work
xfs_file_iter_read
lock XFS inode XFS_IOLOCK_SHARED (on image file)
page cache read (GFP_KERNEL)
radix tree alloc
memory reclaim
reclaim XFS inodes
log force to unpin inodes
<wait for log IO completion>
xfs-cil/loop1: <does log force IO work>
xlog_cil_push
xlog_write
<loop issuing log writes>
xlog_state_get_iclog_space()
<blocks due to all log buffers under write io>
<waits for IO completion>
kloopd1: loop_queue_write_work
xfs_file_write_iter
lock XFS inode XFS_IOLOCK_EXCL (on image file)
<wait for inode to be unlocked>
[The full stack traces are below].
i.e. the kloopd, with it's split read and write work queues, has
introduced a dependency through memory reclaim. i.e. that writes
need to be able to progress for reads make progress.
The problem, fundamentally, is that mpage_readpages() does a
GFP_KERNEL allocation, rather than paying attention to the inode's
mapping gfp mask, which is set to GFP_NOFS.
The didn't used to happen, because the loop device used to issue
reads through the splice path and that does:
error = add_to_page_cache_lru(page, mapping, index,
GFP_KERNEL & mapping_gfp_mask(mapping));
i.e. it pays attention to the allocation context placed on the
inode and so is doing GFP_NOFS allocations here and avoiding the
recursion problem.
[ CC'd Michal Hocko and the mm list because it's a clear exaple of
why ignoring the mapping gfp mask on any page cache allocation is
a landmine waiting to be tripped over. ]
Cheers,
Dave.
[81248.855166] kworker/u3:0 D ffff88003a8fadc8 11304 930 2 0x00000000
[81248.855166] Workqueue: kloopd1 loop_queue_read_work
[81248.855166] ffff88003a8fadc8 ffff880003e48000 ffff8800332fdd00 ffff88003a8fadb8
[81248.855166] ffff88003a8fc000 ffff88003a8faf18 ffff8800332fdd00 ffff88003a8faf10
[81248.855166] ffffffffffffffff ffff88003a8fade8 ffffffff81db608e ffff88003fc153c0
[81248.855166] Call Trace:
[81248.855166] [<ffffffff81db608e>] schedule+0x3e/0x90
[81248.855166] [<ffffffff81dba38f>] schedule_timeout+0x1cf/0x240
[81248.855166] [<ffffffff810cce16>] ? try_to_wake_up+0x1f6/0x330
[81248.855166] [<ffffffff81db7534>] wait_for_completion+0xb4/0x120
[81248.855166] [<ffffffff810cd010>] ? wake_up_q+0x70/0x70
[81248.855166] [<ffffffff810bc2d9>] flush_work+0xf9/0x170
[81248.855166] [<ffffffff810ba0d0>] ? destroy_worker+0x90/0x90
[81248.855166] [<ffffffff81513a2c>] xlog_cil_force_lsn+0xcc/0x250
[81248.855166] [<ffffffff815126f2>] _xfs_log_force_lsn+0x82/0x2f0
[81248.855166] [<ffffffff8151298e>] xfs_log_force_lsn+0x2e/0xa0
[81248.855166] [<ffffffff81501e49>] ? xfs_iunpin_wait+0x19/0x20
[81248.855166] [<ffffffff814fe686>] __xfs_iunpin_wait+0xb6/0x170
[81248.855166] [<ffffffff810e0f90>] ? autoremove_wake_function+0x40/0x40
[81248.855166] [<ffffffff81501e49>] xfs_iunpin_wait+0x19/0x20
[81248.855166] [<ffffffff814f6df2>] xfs_reclaim_inode+0x72/0x350
[81248.855166] [<ffffffff814f72e2>] xfs_reclaim_inodes_ag+0x212/0x350
[81248.855166] [<ffffffff81dbb07e>] ? _raw_spin_unlock+0xe/0x20
[81248.855166] [<ffffffff81dbb07e>] ? _raw_spin_unlock+0xe/0x20
[81248.855166] [<ffffffff814f74b3>] xfs_reclaim_inodes_nr+0x33/0x40
[81248.855166] [<ffffffff81507f19>] xfs_fs_free_cached_objects+0x19/0x20
[81248.855166] [<ffffffff811cf791>] super_cache_scan+0x191/0x1a0
[81248.855166] [<ffffffff811912d4>] shrink_slab.part.62.constprop.80+0x1b4/0x380
[81248.855166] [<ffffffff81194720>] shrink_zone+0x90/0xa0
[81248.855166] [<ffffffff811948b0>] do_try_to_free_pages+0x180/0x2c0
[81248.855166] [<ffffffff81194aaa>] try_to_free_pages+0xba/0x160
[81248.855166] [<ffffffff81189509>] __alloc_pages_nodemask+0x499/0x840
[81248.855166] [<ffffffff811c3d2f>] new_slab+0x6f/0x2c0
[81248.855166] [<ffffffff811c5baa>] __slab_alloc.constprop.75+0x3fa/0x580
[81248.855166] [<ffffffff817be438>] ? __radix_tree_preload+0x48/0xc0
[81248.855166] [<ffffffff817be438>] ? __radix_tree_preload+0x48/0xc0
[81248.855166] [<ffffffff811c620e>] kmem_cache_alloc+0x12e/0x160
[81248.855166] [<ffffffff817be438>] __radix_tree_preload+0x48/0xc0
[81248.855166] [<ffffffff817be519>] radix_tree_maybe_preload+0x19/0x20
[81248.855166] [<ffffffff81181b69>] __add_to_page_cache_locked+0x39/0x1f0
[81248.855166] [<ffffffff81181d68>] add_to_page_cache_lru+0x28/0x80
[81248.855166] [<ffffffff81209fc9>] mpage_readpages+0xb9/0x130
[81248.855166] [<ffffffff814e68e0>] ? __xfs_get_blocks+0x840/0x840
[81248.855166] [<ffffffff814e68e0>] ? __xfs_get_blocks+0x840/0x840
[81248.855166] [<ffffffff814e409d>] xfs_vm_readpages+0x1d/0x20
[81248.855166] [<ffffffff8118cfc9>] __do_page_cache_readahead+0x1b9/0x250
[81248.855166] [<ffffffff8118d13f>] ondemand_readahead+0xdf/0x270
[81248.855166] [<ffffffff81180fc6>] ? find_get_entry+0x66/0xb0
[81248.855166] [<ffffffff8118d362>] page_cache_async_readahead+0x92/0xc0
[81248.855166] [<ffffffff81182c3c>] generic_file_read_iter+0x41c/0x650
[81248.855166] [<ffffffff81db9664>] ? down_read+0x24/0x40
[81248.855166] [<ffffffff814f1d66>] xfs_file_read_iter+0xe6/0x2d0
[81248.855166] [<ffffffff811cba22>] vfs_iter_read+0x62/0xa0
[81248.855166] [<ffffffff81a98fcd>] loop_handle_cmd.isra.28+0x6dd/0xaa0
[81248.855166] [<ffffffff810cce16>] ? try_to_wake_up+0x1f6/0x330
[81248.855166] [<ffffffff81a99472>] loop_queue_read_work+0x12/0x20
[81248.855166] [<ffffffff810bd02e>] process_one_work+0x14e/0x410
[81248.855166] [<ffffffff810bd63e>] worker_thread+0x4e/0x460
[81248.855166] [<ffffffff810bd5f0>] ? rescuer_thread+0x300/0x300
[81248.855166] [<ffffffff810c288c>] kthread+0xec/0x110
[81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
[81248.855166] [<ffffffff81dbba5f>] ret_from_fork+0x3f/0x70
[81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
[81248.855166] kworker/0:0 D ffff88002ed8bb88 13896 948 2 0x00000000
[81248.855166] Workqueue: xfs-cil/loop1 xlog_cil_push_work
[81248.855166] ffff88002ed8bb88 ffffffff82368540 ffff880003e4be00 ffff88001a467cf0
[81248.855166] ffff88002ed8c000 ffff880005123cf8 ffff88001a467cf0 ffff880003e4be00
[81248.855166] ffff880005123cc0 ffff88002ed8bba8 ffffffff81db608e ffff88002ed8bba8
[81248.855166] Call Trace:
[81248.855166] [<ffffffff81db608e>] schedule+0x3e/0x90
[81248.855166] [<ffffffff81511266>] xlog_state_get_iclog_space+0xe6/0x330
[81248.855166] [<ffffffff810cd010>] ? wake_up_q+0x70/0x70
[81248.855166] [<ffffffff81511666>] xlog_write+0x1b6/0x870
[81248.855166] [<ffffffff8151316d>] xlog_cil_push+0x24d/0x400
[81248.855166] [<ffffffff81513335>] xlog_cil_push_work+0x15/0x20
[81248.855166] [<ffffffff810bd02e>] process_one_work+0x14e/0x410
[81248.855166] [<ffffffff810bd63e>] worker_thread+0x4e/0x460
[81248.855166] [<ffffffff810bd5f0>] ? rescuer_thread+0x300/0x300
[81248.855166] [<ffffffff810bd5f0>] ? rescuer_thread+0x300/0x300
[81248.855166] [<ffffffff810c288c>] kthread+0xec/0x110
[81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
[81248.855166] [<ffffffff81dbba5f>] ret_from_fork+0x3f/0x70
[81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
[81248.855166] kworker/u3:4 D ffff8800290439f8 12456 1066 2 0x00000000
[81248.855166] Workqueue: kloopd1 loop_queue_write_work
[81248.855166] ffff8800290439f8 ffffffff82368540 ffff8800332f9f00 ffff8800290439e8
[81248.855166] ffff880029044000 ffffffff00000000 ffff88001366cfd8 ffffffff00000002
[81248.855166] ffff8800332f9f00 ffff880029043a18 ffffffff81db608e ffff880029043a18
[81248.855166] Call Trace:
[81248.855166] [<ffffffff81db608e>] schedule+0x3e/0x90
[81248.855166] [<ffffffff81db9f3d>] rwsem_down_write_failed+0x13d/0x340
[81248.855166] [<ffffffff810cce16>] ? try_to_wake_up+0x1f6/0x330
[81248.855166] [<ffffffff814f2e46>] ? xfs_file_buffered_aio_write+0x66/0x250
[81248.855166] [<ffffffff817c76a3>] call_rwsem_down_write_failed+0x13/0x20
[81248.855166] [<ffffffff81db96bf>] ? down_write+0x3f/0x60
[81248.855166] [<ffffffff814fdea4>] xfs_ilock+0x154/0x1d0
[81248.855166] [<ffffffff814f2e46>] xfs_file_buffered_aio_write+0x66/0x250
[81248.855166] [<ffffffff8179264d>] ? kblockd_schedule_work+0x1d/0x30
[81248.855166] [<ffffffff8179dbc5>] ? blk_mq_kick_requeue_list+0x15/0x20
[81248.855166] [<ffffffff814f3136>] xfs_file_write_iter+0x106/0x120
[81248.855166] [<ffffffff811cbac3>] vfs_iter_write+0x63/0xa0
[81248.855166] [<ffffffff81a97828>] lo_write_bvec+0x58/0x100
[81248.855166] [<ffffffff81a99248>] loop_handle_cmd.isra.28+0x958/0xaa0
[81248.855166] [<ffffffff81a9941f>] loop_queue_write_work+0x8f/0xd0
[81248.855166] [<ffffffff810bd02e>] process_one_work+0x14e/0x410
[81248.855166] [<ffffffff810bd63e>] worker_thread+0x4e/0x460
[81248.855166] [<ffffffff810bd5f0>] ? rescuer_thread+0x300/0x300
[81248.855166] [<ffffffff810c288c>] kthread+0xec/0x110
[81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
[81248.855166] [<ffffffff81dbba5f>] ret_from_fork+0x3f/0x70
[81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
--
Dave Chinner
david@fromorbit.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [regression 4.2-rc3] loop: xfstests xfs/073 deadlocked in low memory conditions
2015-07-21 1:59 ` Dave Chinner
(?)
@ 2015-07-21 4:05 ` Ming Lei
-1 siblings, 0 replies; 20+ messages in thread
From: Ming Lei @ 2015-07-21 4:05 UTC (permalink / raw)
To: Dave Chinner; +Cc: Michal Hocko, Linux Kernel Mailing List, linux-mm, xfs
On Mon, Jul 20, 2015 at 9:59 PM, Dave Chinner <david@fromorbit.com> wrote:
> Hi Ming,
>
> With the recent merge of the loop device changes, I'm now seeing
> XFS deadlock on my single CPU, 1GB RAM VM running xfs/073.
>
> The deadlocked is as follows:
>
> kloopd1: loop_queue_read_work
> xfs_file_iter_read
> lock XFS inode XFS_IOLOCK_SHARED (on image file)
> page cache read (GFP_KERNEL)
> radix tree alloc
> memory reclaim
> reclaim XFS inodes
> log force to unpin inodes
> <wait for log IO completion>
>
> xfs-cil/loop1: <does log force IO work>
> xlog_cil_push
> xlog_write
> <loop issuing log writes>
> xlog_state_get_iclog_space()
> <blocks due to all log buffers under write io>
> <waits for IO completion>
>
> kloopd1: loop_queue_write_work
> xfs_file_write_iter
> lock XFS inode XFS_IOLOCK_EXCL (on image file)
> <wait for inode to be unlocked>
>
> [The full stack traces are below].
>
> i.e. the kloopd, with it's split read and write work queues, has
> introduced a dependency through memory reclaim. i.e. that writes
> need to be able to progress for reads make progress.
This kind of change just makes READ vs READ OR WRITE submitted
to fs concurrently, and the use case should have been simulated from
user space on one regular XFS file too?
>
> The problem, fundamentally, is that mpage_readpages() does a
> GFP_KERNEL allocation, rather than paying attention to the inode's
> mapping gfp mask, which is set to GFP_NOFS.
That looks the root cause, and I guess the issue is just triggered
after commit aa4d86163e4(block: loop: switch to VFS ITER_BVEC)
which changes splice to bvec iterator.
>
> The didn't used to happen, because the loop device used to issue
> reads through the splice path and that does:
>
> error = add_to_page_cache_lru(page, mapping, index,
> GFP_KERNEL & mapping_gfp_mask(mapping));
>
> i.e. it pays attention to the allocation context placed on the
> inode and so is doing GFP_NOFS allocations here and avoiding the
> recursion problem.
>
> [ CC'd Michal Hocko and the mm list because it's a clear exaple of
> why ignoring the mapping gfp mask on any page cache allocation is
> a landmine waiting to be tripped over. ]
>
> Cheers,
>
> Dave.
>
> [81248.855166] kworker/u3:0 D ffff88003a8fadc8 11304 930 2 0x00000000
> [81248.855166] Workqueue: kloopd1 loop_queue_read_work
> [81248.855166] ffff88003a8fadc8 ffff880003e48000 ffff8800332fdd00 ffff88003a8fadb8
> [81248.855166] ffff88003a8fc000 ffff88003a8faf18 ffff8800332fdd00 ffff88003a8faf10
> [81248.855166] ffffffffffffffff ffff88003a8fade8 ffffffff81db608e ffff88003fc153c0
> [81248.855166] Call Trace:
> [81248.855166] [<ffffffff81db608e>] schedule+0x3e/0x90
> [81248.855166] [<ffffffff81dba38f>] schedule_timeout+0x1cf/0x240
> [81248.855166] [<ffffffff810cce16>] ? try_to_wake_up+0x1f6/0x330
> [81248.855166] [<ffffffff81db7534>] wait_for_completion+0xb4/0x120
> [81248.855166] [<ffffffff810cd010>] ? wake_up_q+0x70/0x70
> [81248.855166] [<ffffffff810bc2d9>] flush_work+0xf9/0x170
> [81248.855166] [<ffffffff810ba0d0>] ? destroy_worker+0x90/0x90
> [81248.855166] [<ffffffff81513a2c>] xlog_cil_force_lsn+0xcc/0x250
> [81248.855166] [<ffffffff815126f2>] _xfs_log_force_lsn+0x82/0x2f0
> [81248.855166] [<ffffffff8151298e>] xfs_log_force_lsn+0x2e/0xa0
> [81248.855166] [<ffffffff81501e49>] ? xfs_iunpin_wait+0x19/0x20
> [81248.855166] [<ffffffff814fe686>] __xfs_iunpin_wait+0xb6/0x170
> [81248.855166] [<ffffffff810e0f90>] ? autoremove_wake_function+0x40/0x40
> [81248.855166] [<ffffffff81501e49>] xfs_iunpin_wait+0x19/0x20
> [81248.855166] [<ffffffff814f6df2>] xfs_reclaim_inode+0x72/0x350
> [81248.855166] [<ffffffff814f72e2>] xfs_reclaim_inodes_ag+0x212/0x350
> [81248.855166] [<ffffffff81dbb07e>] ? _raw_spin_unlock+0xe/0x20
> [81248.855166] [<ffffffff81dbb07e>] ? _raw_spin_unlock+0xe/0x20
> [81248.855166] [<ffffffff814f74b3>] xfs_reclaim_inodes_nr+0x33/0x40
> [81248.855166] [<ffffffff81507f19>] xfs_fs_free_cached_objects+0x19/0x20
> [81248.855166] [<ffffffff811cf791>] super_cache_scan+0x191/0x1a0
> [81248.855166] [<ffffffff811912d4>] shrink_slab.part.62.constprop.80+0x1b4/0x380
> [81248.855166] [<ffffffff81194720>] shrink_zone+0x90/0xa0
> [81248.855166] [<ffffffff811948b0>] do_try_to_free_pages+0x180/0x2c0
> [81248.855166] [<ffffffff81194aaa>] try_to_free_pages+0xba/0x160
> [81248.855166] [<ffffffff81189509>] __alloc_pages_nodemask+0x499/0x840
> [81248.855166] [<ffffffff811c3d2f>] new_slab+0x6f/0x2c0
> [81248.855166] [<ffffffff811c5baa>] __slab_alloc.constprop.75+0x3fa/0x580
> [81248.855166] [<ffffffff817be438>] ? __radix_tree_preload+0x48/0xc0
> [81248.855166] [<ffffffff817be438>] ? __radix_tree_preload+0x48/0xc0
> [81248.855166] [<ffffffff811c620e>] kmem_cache_alloc+0x12e/0x160
> [81248.855166] [<ffffffff817be438>] __radix_tree_preload+0x48/0xc0
> [81248.855166] [<ffffffff817be519>] radix_tree_maybe_preload+0x19/0x20
> [81248.855166] [<ffffffff81181b69>] __add_to_page_cache_locked+0x39/0x1f0
> [81248.855166] [<ffffffff81181d68>] add_to_page_cache_lru+0x28/0x80
> [81248.855166] [<ffffffff81209fc9>] mpage_readpages+0xb9/0x130
> [81248.855166] [<ffffffff814e68e0>] ? __xfs_get_blocks+0x840/0x840
> [81248.855166] [<ffffffff814e68e0>] ? __xfs_get_blocks+0x840/0x840
> [81248.855166] [<ffffffff814e409d>] xfs_vm_readpages+0x1d/0x20
> [81248.855166] [<ffffffff8118cfc9>] __do_page_cache_readahead+0x1b9/0x250
> [81248.855166] [<ffffffff8118d13f>] ondemand_readahead+0xdf/0x270
> [81248.855166] [<ffffffff81180fc6>] ? find_get_entry+0x66/0xb0
> [81248.855166] [<ffffffff8118d362>] page_cache_async_readahead+0x92/0xc0
> [81248.855166] [<ffffffff81182c3c>] generic_file_read_iter+0x41c/0x650
> [81248.855166] [<ffffffff81db9664>] ? down_read+0x24/0x40
> [81248.855166] [<ffffffff814f1d66>] xfs_file_read_iter+0xe6/0x2d0
> [81248.855166] [<ffffffff811cba22>] vfs_iter_read+0x62/0xa0
> [81248.855166] [<ffffffff81a98fcd>] loop_handle_cmd.isra.28+0x6dd/0xaa0
> [81248.855166] [<ffffffff810cce16>] ? try_to_wake_up+0x1f6/0x330
> [81248.855166] [<ffffffff81a99472>] loop_queue_read_work+0x12/0x20
> [81248.855166] [<ffffffff810bd02e>] process_one_work+0x14e/0x410
> [81248.855166] [<ffffffff810bd63e>] worker_thread+0x4e/0x460
> [81248.855166] [<ffffffff810bd5f0>] ? rescuer_thread+0x300/0x300
> [81248.855166] [<ffffffff810c288c>] kthread+0xec/0x110
> [81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
> [81248.855166] [<ffffffff81dbba5f>] ret_from_fork+0x3f/0x70
> [81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
>
> [81248.855166] kworker/0:0 D ffff88002ed8bb88 13896 948 2 0x00000000
> [81248.855166] Workqueue: xfs-cil/loop1 xlog_cil_push_work
> [81248.855166] ffff88002ed8bb88 ffffffff82368540 ffff880003e4be00 ffff88001a467cf0
> [81248.855166] ffff88002ed8c000 ffff880005123cf8 ffff88001a467cf0 ffff880003e4be00
> [81248.855166] ffff880005123cc0 ffff88002ed8bba8 ffffffff81db608e ffff88002ed8bba8
> [81248.855166] Call Trace:
> [81248.855166] [<ffffffff81db608e>] schedule+0x3e/0x90
> [81248.855166] [<ffffffff81511266>] xlog_state_get_iclog_space+0xe6/0x330
> [81248.855166] [<ffffffff810cd010>] ? wake_up_q+0x70/0x70
> [81248.855166] [<ffffffff81511666>] xlog_write+0x1b6/0x870
> [81248.855166] [<ffffffff8151316d>] xlog_cil_push+0x24d/0x400
> [81248.855166] [<ffffffff81513335>] xlog_cil_push_work+0x15/0x20
> [81248.855166] [<ffffffff810bd02e>] process_one_work+0x14e/0x410
> [81248.855166] [<ffffffff810bd63e>] worker_thread+0x4e/0x460
> [81248.855166] [<ffffffff810bd5f0>] ? rescuer_thread+0x300/0x300
> [81248.855166] [<ffffffff810bd5f0>] ? rescuer_thread+0x300/0x300
> [81248.855166] [<ffffffff810c288c>] kthread+0xec/0x110
> [81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
> [81248.855166] [<ffffffff81dbba5f>] ret_from_fork+0x3f/0x70
> [81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
>
> [81248.855166] kworker/u3:4 D ffff8800290439f8 12456 1066 2 0x00000000
> [81248.855166] Workqueue: kloopd1 loop_queue_write_work
> [81248.855166] ffff8800290439f8 ffffffff82368540 ffff8800332f9f00 ffff8800290439e8
> [81248.855166] ffff880029044000 ffffffff00000000 ffff88001366cfd8 ffffffff00000002
> [81248.855166] ffff8800332f9f00 ffff880029043a18 ffffffff81db608e ffff880029043a18
> [81248.855166] Call Trace:
> [81248.855166] [<ffffffff81db608e>] schedule+0x3e/0x90
> [81248.855166] [<ffffffff81db9f3d>] rwsem_down_write_failed+0x13d/0x340
> [81248.855166] [<ffffffff810cce16>] ? try_to_wake_up+0x1f6/0x330
> [81248.855166] [<ffffffff814f2e46>] ? xfs_file_buffered_aio_write+0x66/0x250
> [81248.855166] [<ffffffff817c76a3>] call_rwsem_down_write_failed+0x13/0x20
> [81248.855166] [<ffffffff81db96bf>] ? down_write+0x3f/0x60
> [81248.855166] [<ffffffff814fdea4>] xfs_ilock+0x154/0x1d0
> [81248.855166] [<ffffffff814f2e46>] xfs_file_buffered_aio_write+0x66/0x250
> [81248.855166] [<ffffffff8179264d>] ? kblockd_schedule_work+0x1d/0x30
> [81248.855166] [<ffffffff8179dbc5>] ? blk_mq_kick_requeue_list+0x15/0x20
> [81248.855166] [<ffffffff814f3136>] xfs_file_write_iter+0x106/0x120
> [81248.855166] [<ffffffff811cbac3>] vfs_iter_write+0x63/0xa0
> [81248.855166] [<ffffffff81a97828>] lo_write_bvec+0x58/0x100
> [81248.855166] [<ffffffff81a99248>] loop_handle_cmd.isra.28+0x958/0xaa0
> [81248.855166] [<ffffffff81a9941f>] loop_queue_write_work+0x8f/0xd0
> [81248.855166] [<ffffffff810bd02e>] process_one_work+0x14e/0x410
> [81248.855166] [<ffffffff810bd63e>] worker_thread+0x4e/0x460
> [81248.855166] [<ffffffff810bd5f0>] ? rescuer_thread+0x300/0x300
> [81248.855166] [<ffffffff810c288c>] kthread+0xec/0x110
> [81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
> [81248.855166] [<ffffffff81dbba5f>] ret_from_fork+0x3f/0x70
> [81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
> --
> Dave Chinner
> david@fromorbit.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [regression 4.2-rc3] loop: xfstests xfs/073 deadlocked in low memory conditions
@ 2015-07-21 4:05 ` Ming Lei
0 siblings, 0 replies; 20+ messages in thread
From: Ming Lei @ 2015-07-21 4:05 UTC (permalink / raw)
To: Dave Chinner; +Cc: Michal Hocko, linux-mm, Linux Kernel Mailing List, xfs
On Mon, Jul 20, 2015 at 9:59 PM, Dave Chinner <david@fromorbit.com> wrote:
> Hi Ming,
>
> With the recent merge of the loop device changes, I'm now seeing
> XFS deadlock on my single CPU, 1GB RAM VM running xfs/073.
>
> The deadlocked is as follows:
>
> kloopd1: loop_queue_read_work
> xfs_file_iter_read
> lock XFS inode XFS_IOLOCK_SHARED (on image file)
> page cache read (GFP_KERNEL)
> radix tree alloc
> memory reclaim
> reclaim XFS inodes
> log force to unpin inodes
> <wait for log IO completion>
>
> xfs-cil/loop1: <does log force IO work>
> xlog_cil_push
> xlog_write
> <loop issuing log writes>
> xlog_state_get_iclog_space()
> <blocks due to all log buffers under write io>
> <waits for IO completion>
>
> kloopd1: loop_queue_write_work
> xfs_file_write_iter
> lock XFS inode XFS_IOLOCK_EXCL (on image file)
> <wait for inode to be unlocked>
>
> [The full stack traces are below].
>
> i.e. the kloopd, with it's split read and write work queues, has
> introduced a dependency through memory reclaim. i.e. that writes
> need to be able to progress for reads make progress.
This kind of change just makes READ vs READ OR WRITE submitted
to fs concurrently, and the use case should have been simulated from
user space on one regular XFS file too?
>
> The problem, fundamentally, is that mpage_readpages() does a
> GFP_KERNEL allocation, rather than paying attention to the inode's
> mapping gfp mask, which is set to GFP_NOFS.
That looks the root cause, and I guess the issue is just triggered
after commit aa4d86163e4(block: loop: switch to VFS ITER_BVEC)
which changes splice to bvec iterator.
>
> The didn't used to happen, because the loop device used to issue
> reads through the splice path and that does:
>
> error = add_to_page_cache_lru(page, mapping, index,
> GFP_KERNEL & mapping_gfp_mask(mapping));
>
> i.e. it pays attention to the allocation context placed on the
> inode and so is doing GFP_NOFS allocations here and avoiding the
> recursion problem.
>
> [ CC'd Michal Hocko and the mm list because it's a clear exaple of
> why ignoring the mapping gfp mask on any page cache allocation is
> a landmine waiting to be tripped over. ]
>
> Cheers,
>
> Dave.
>
> [81248.855166] kworker/u3:0 D ffff88003a8fadc8 11304 930 2 0x00000000
> [81248.855166] Workqueue: kloopd1 loop_queue_read_work
> [81248.855166] ffff88003a8fadc8 ffff880003e48000 ffff8800332fdd00 ffff88003a8fadb8
> [81248.855166] ffff88003a8fc000 ffff88003a8faf18 ffff8800332fdd00 ffff88003a8faf10
> [81248.855166] ffffffffffffffff ffff88003a8fade8 ffffffff81db608e ffff88003fc153c0
> [81248.855166] Call Trace:
> [81248.855166] [<ffffffff81db608e>] schedule+0x3e/0x90
> [81248.855166] [<ffffffff81dba38f>] schedule_timeout+0x1cf/0x240
> [81248.855166] [<ffffffff810cce16>] ? try_to_wake_up+0x1f6/0x330
> [81248.855166] [<ffffffff81db7534>] wait_for_completion+0xb4/0x120
> [81248.855166] [<ffffffff810cd010>] ? wake_up_q+0x70/0x70
> [81248.855166] [<ffffffff810bc2d9>] flush_work+0xf9/0x170
> [81248.855166] [<ffffffff810ba0d0>] ? destroy_worker+0x90/0x90
> [81248.855166] [<ffffffff81513a2c>] xlog_cil_force_lsn+0xcc/0x250
> [81248.855166] [<ffffffff815126f2>] _xfs_log_force_lsn+0x82/0x2f0
> [81248.855166] [<ffffffff8151298e>] xfs_log_force_lsn+0x2e/0xa0
> [81248.855166] [<ffffffff81501e49>] ? xfs_iunpin_wait+0x19/0x20
> [81248.855166] [<ffffffff814fe686>] __xfs_iunpin_wait+0xb6/0x170
> [81248.855166] [<ffffffff810e0f90>] ? autoremove_wake_function+0x40/0x40
> [81248.855166] [<ffffffff81501e49>] xfs_iunpin_wait+0x19/0x20
> [81248.855166] [<ffffffff814f6df2>] xfs_reclaim_inode+0x72/0x350
> [81248.855166] [<ffffffff814f72e2>] xfs_reclaim_inodes_ag+0x212/0x350
> [81248.855166] [<ffffffff81dbb07e>] ? _raw_spin_unlock+0xe/0x20
> [81248.855166] [<ffffffff81dbb07e>] ? _raw_spin_unlock+0xe/0x20
> [81248.855166] [<ffffffff814f74b3>] xfs_reclaim_inodes_nr+0x33/0x40
> [81248.855166] [<ffffffff81507f19>] xfs_fs_free_cached_objects+0x19/0x20
> [81248.855166] [<ffffffff811cf791>] super_cache_scan+0x191/0x1a0
> [81248.855166] [<ffffffff811912d4>] shrink_slab.part.62.constprop.80+0x1b4/0x380
> [81248.855166] [<ffffffff81194720>] shrink_zone+0x90/0xa0
> [81248.855166] [<ffffffff811948b0>] do_try_to_free_pages+0x180/0x2c0
> [81248.855166] [<ffffffff81194aaa>] try_to_free_pages+0xba/0x160
> [81248.855166] [<ffffffff81189509>] __alloc_pages_nodemask+0x499/0x840
> [81248.855166] [<ffffffff811c3d2f>] new_slab+0x6f/0x2c0
> [81248.855166] [<ffffffff811c5baa>] __slab_alloc.constprop.75+0x3fa/0x580
> [81248.855166] [<ffffffff817be438>] ? __radix_tree_preload+0x48/0xc0
> [81248.855166] [<ffffffff817be438>] ? __radix_tree_preload+0x48/0xc0
> [81248.855166] [<ffffffff811c620e>] kmem_cache_alloc+0x12e/0x160
> [81248.855166] [<ffffffff817be438>] __radix_tree_preload+0x48/0xc0
> [81248.855166] [<ffffffff817be519>] radix_tree_maybe_preload+0x19/0x20
> [81248.855166] [<ffffffff81181b69>] __add_to_page_cache_locked+0x39/0x1f0
> [81248.855166] [<ffffffff81181d68>] add_to_page_cache_lru+0x28/0x80
> [81248.855166] [<ffffffff81209fc9>] mpage_readpages+0xb9/0x130
> [81248.855166] [<ffffffff814e68e0>] ? __xfs_get_blocks+0x840/0x840
> [81248.855166] [<ffffffff814e68e0>] ? __xfs_get_blocks+0x840/0x840
> [81248.855166] [<ffffffff814e409d>] xfs_vm_readpages+0x1d/0x20
> [81248.855166] [<ffffffff8118cfc9>] __do_page_cache_readahead+0x1b9/0x250
> [81248.855166] [<ffffffff8118d13f>] ondemand_readahead+0xdf/0x270
> [81248.855166] [<ffffffff81180fc6>] ? find_get_entry+0x66/0xb0
> [81248.855166] [<ffffffff8118d362>] page_cache_async_readahead+0x92/0xc0
> [81248.855166] [<ffffffff81182c3c>] generic_file_read_iter+0x41c/0x650
> [81248.855166] [<ffffffff81db9664>] ? down_read+0x24/0x40
> [81248.855166] [<ffffffff814f1d66>] xfs_file_read_iter+0xe6/0x2d0
> [81248.855166] [<ffffffff811cba22>] vfs_iter_read+0x62/0xa0
> [81248.855166] [<ffffffff81a98fcd>] loop_handle_cmd.isra.28+0x6dd/0xaa0
> [81248.855166] [<ffffffff810cce16>] ? try_to_wake_up+0x1f6/0x330
> [81248.855166] [<ffffffff81a99472>] loop_queue_read_work+0x12/0x20
> [81248.855166] [<ffffffff810bd02e>] process_one_work+0x14e/0x410
> [81248.855166] [<ffffffff810bd63e>] worker_thread+0x4e/0x460
> [81248.855166] [<ffffffff810bd5f0>] ? rescuer_thread+0x300/0x300
> [81248.855166] [<ffffffff810c288c>] kthread+0xec/0x110
> [81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
> [81248.855166] [<ffffffff81dbba5f>] ret_from_fork+0x3f/0x70
> [81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
>
> [81248.855166] kworker/0:0 D ffff88002ed8bb88 13896 948 2 0x00000000
> [81248.855166] Workqueue: xfs-cil/loop1 xlog_cil_push_work
> [81248.855166] ffff88002ed8bb88 ffffffff82368540 ffff880003e4be00 ffff88001a467cf0
> [81248.855166] ffff88002ed8c000 ffff880005123cf8 ffff88001a467cf0 ffff880003e4be00
> [81248.855166] ffff880005123cc0 ffff88002ed8bba8 ffffffff81db608e ffff88002ed8bba8
> [81248.855166] Call Trace:
> [81248.855166] [<ffffffff81db608e>] schedule+0x3e/0x90
> [81248.855166] [<ffffffff81511266>] xlog_state_get_iclog_space+0xe6/0x330
> [81248.855166] [<ffffffff810cd010>] ? wake_up_q+0x70/0x70
> [81248.855166] [<ffffffff81511666>] xlog_write+0x1b6/0x870
> [81248.855166] [<ffffffff8151316d>] xlog_cil_push+0x24d/0x400
> [81248.855166] [<ffffffff81513335>] xlog_cil_push_work+0x15/0x20
> [81248.855166] [<ffffffff810bd02e>] process_one_work+0x14e/0x410
> [81248.855166] [<ffffffff810bd63e>] worker_thread+0x4e/0x460
> [81248.855166] [<ffffffff810bd5f0>] ? rescuer_thread+0x300/0x300
> [81248.855166] [<ffffffff810bd5f0>] ? rescuer_thread+0x300/0x300
> [81248.855166] [<ffffffff810c288c>] kthread+0xec/0x110
> [81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
> [81248.855166] [<ffffffff81dbba5f>] ret_from_fork+0x3f/0x70
> [81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
>
> [81248.855166] kworker/u3:4 D ffff8800290439f8 12456 1066 2 0x00000000
> [81248.855166] Workqueue: kloopd1 loop_queue_write_work
> [81248.855166] ffff8800290439f8 ffffffff82368540 ffff8800332f9f00 ffff8800290439e8
> [81248.855166] ffff880029044000 ffffffff00000000 ffff88001366cfd8 ffffffff00000002
> [81248.855166] ffff8800332f9f00 ffff880029043a18 ffffffff81db608e ffff880029043a18
> [81248.855166] Call Trace:
> [81248.855166] [<ffffffff81db608e>] schedule+0x3e/0x90
> [81248.855166] [<ffffffff81db9f3d>] rwsem_down_write_failed+0x13d/0x340
> [81248.855166] [<ffffffff810cce16>] ? try_to_wake_up+0x1f6/0x330
> [81248.855166] [<ffffffff814f2e46>] ? xfs_file_buffered_aio_write+0x66/0x250
> [81248.855166] [<ffffffff817c76a3>] call_rwsem_down_write_failed+0x13/0x20
> [81248.855166] [<ffffffff81db96bf>] ? down_write+0x3f/0x60
> [81248.855166] [<ffffffff814fdea4>] xfs_ilock+0x154/0x1d0
> [81248.855166] [<ffffffff814f2e46>] xfs_file_buffered_aio_write+0x66/0x250
> [81248.855166] [<ffffffff8179264d>] ? kblockd_schedule_work+0x1d/0x30
> [81248.855166] [<ffffffff8179dbc5>] ? blk_mq_kick_requeue_list+0x15/0x20
> [81248.855166] [<ffffffff814f3136>] xfs_file_write_iter+0x106/0x120
> [81248.855166] [<ffffffff811cbac3>] vfs_iter_write+0x63/0xa0
> [81248.855166] [<ffffffff81a97828>] lo_write_bvec+0x58/0x100
> [81248.855166] [<ffffffff81a99248>] loop_handle_cmd.isra.28+0x958/0xaa0
> [81248.855166] [<ffffffff81a9941f>] loop_queue_write_work+0x8f/0xd0
> [81248.855166] [<ffffffff810bd02e>] process_one_work+0x14e/0x410
> [81248.855166] [<ffffffff810bd63e>] worker_thread+0x4e/0x460
> [81248.855166] [<ffffffff810bd5f0>] ? rescuer_thread+0x300/0x300
> [81248.855166] [<ffffffff810c288c>] kthread+0xec/0x110
> [81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
> [81248.855166] [<ffffffff81dbba5f>] ret_from_fork+0x3f/0x70
> [81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
> --
> Dave Chinner
> david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [regression 4.2-rc3] loop: xfstests xfs/073 deadlocked in low memory conditions
@ 2015-07-21 4:05 ` Ming Lei
0 siblings, 0 replies; 20+ messages in thread
From: Ming Lei @ 2015-07-21 4:05 UTC (permalink / raw)
To: Dave Chinner; +Cc: Michal Hocko, Linux Kernel Mailing List, linux-mm, xfs
On Mon, Jul 20, 2015 at 9:59 PM, Dave Chinner <david@fromorbit.com> wrote:
> Hi Ming,
>
> With the recent merge of the loop device changes, I'm now seeing
> XFS deadlock on my single CPU, 1GB RAM VM running xfs/073.
>
> The deadlocked is as follows:
>
> kloopd1: loop_queue_read_work
> xfs_file_iter_read
> lock XFS inode XFS_IOLOCK_SHARED (on image file)
> page cache read (GFP_KERNEL)
> radix tree alloc
> memory reclaim
> reclaim XFS inodes
> log force to unpin inodes
> <wait for log IO completion>
>
> xfs-cil/loop1: <does log force IO work>
> xlog_cil_push
> xlog_write
> <loop issuing log writes>
> xlog_state_get_iclog_space()
> <blocks due to all log buffers under write io>
> <waits for IO completion>
>
> kloopd1: loop_queue_write_work
> xfs_file_write_iter
> lock XFS inode XFS_IOLOCK_EXCL (on image file)
> <wait for inode to be unlocked>
>
> [The full stack traces are below].
>
> i.e. the kloopd, with it's split read and write work queues, has
> introduced a dependency through memory reclaim. i.e. that writes
> need to be able to progress for reads make progress.
This kind of change just makes READ vs READ OR WRITE submitted
to fs concurrently, and the use case should have been simulated from
user space on one regular XFS file too?
>
> The problem, fundamentally, is that mpage_readpages() does a
> GFP_KERNEL allocation, rather than paying attention to the inode's
> mapping gfp mask, which is set to GFP_NOFS.
That looks the root cause, and I guess the issue is just triggered
after commit aa4d86163e4(block: loop: switch to VFS ITER_BVEC)
which changes splice to bvec iterator.
>
> The didn't used to happen, because the loop device used to issue
> reads through the splice path and that does:
>
> error = add_to_page_cache_lru(page, mapping, index,
> GFP_KERNEL & mapping_gfp_mask(mapping));
>
> i.e. it pays attention to the allocation context placed on the
> inode and so is doing GFP_NOFS allocations here and avoiding the
> recursion problem.
>
> [ CC'd Michal Hocko and the mm list because it's a clear exaple of
> why ignoring the mapping gfp mask on any page cache allocation is
> a landmine waiting to be tripped over. ]
>
> Cheers,
>
> Dave.
>
> [81248.855166] kworker/u3:0 D ffff88003a8fadc8 11304 930 2 0x00000000
> [81248.855166] Workqueue: kloopd1 loop_queue_read_work
> [81248.855166] ffff88003a8fadc8 ffff880003e48000 ffff8800332fdd00 ffff88003a8fadb8
> [81248.855166] ffff88003a8fc000 ffff88003a8faf18 ffff8800332fdd00 ffff88003a8faf10
> [81248.855166] ffffffffffffffff ffff88003a8fade8 ffffffff81db608e ffff88003fc153c0
> [81248.855166] Call Trace:
> [81248.855166] [<ffffffff81db608e>] schedule+0x3e/0x90
> [81248.855166] [<ffffffff81dba38f>] schedule_timeout+0x1cf/0x240
> [81248.855166] [<ffffffff810cce16>] ? try_to_wake_up+0x1f6/0x330
> [81248.855166] [<ffffffff81db7534>] wait_for_completion+0xb4/0x120
> [81248.855166] [<ffffffff810cd010>] ? wake_up_q+0x70/0x70
> [81248.855166] [<ffffffff810bc2d9>] flush_work+0xf9/0x170
> [81248.855166] [<ffffffff810ba0d0>] ? destroy_worker+0x90/0x90
> [81248.855166] [<ffffffff81513a2c>] xlog_cil_force_lsn+0xcc/0x250
> [81248.855166] [<ffffffff815126f2>] _xfs_log_force_lsn+0x82/0x2f0
> [81248.855166] [<ffffffff8151298e>] xfs_log_force_lsn+0x2e/0xa0
> [81248.855166] [<ffffffff81501e49>] ? xfs_iunpin_wait+0x19/0x20
> [81248.855166] [<ffffffff814fe686>] __xfs_iunpin_wait+0xb6/0x170
> [81248.855166] [<ffffffff810e0f90>] ? autoremove_wake_function+0x40/0x40
> [81248.855166] [<ffffffff81501e49>] xfs_iunpin_wait+0x19/0x20
> [81248.855166] [<ffffffff814f6df2>] xfs_reclaim_inode+0x72/0x350
> [81248.855166] [<ffffffff814f72e2>] xfs_reclaim_inodes_ag+0x212/0x350
> [81248.855166] [<ffffffff81dbb07e>] ? _raw_spin_unlock+0xe/0x20
> [81248.855166] [<ffffffff81dbb07e>] ? _raw_spin_unlock+0xe/0x20
> [81248.855166] [<ffffffff814f74b3>] xfs_reclaim_inodes_nr+0x33/0x40
> [81248.855166] [<ffffffff81507f19>] xfs_fs_free_cached_objects+0x19/0x20
> [81248.855166] [<ffffffff811cf791>] super_cache_scan+0x191/0x1a0
> [81248.855166] [<ffffffff811912d4>] shrink_slab.part.62.constprop.80+0x1b4/0x380
> [81248.855166] [<ffffffff81194720>] shrink_zone+0x90/0xa0
> [81248.855166] [<ffffffff811948b0>] do_try_to_free_pages+0x180/0x2c0
> [81248.855166] [<ffffffff81194aaa>] try_to_free_pages+0xba/0x160
> [81248.855166] [<ffffffff81189509>] __alloc_pages_nodemask+0x499/0x840
> [81248.855166] [<ffffffff811c3d2f>] new_slab+0x6f/0x2c0
> [81248.855166] [<ffffffff811c5baa>] __slab_alloc.constprop.75+0x3fa/0x580
> [81248.855166] [<ffffffff817be438>] ? __radix_tree_preload+0x48/0xc0
> [81248.855166] [<ffffffff817be438>] ? __radix_tree_preload+0x48/0xc0
> [81248.855166] [<ffffffff811c620e>] kmem_cache_alloc+0x12e/0x160
> [81248.855166] [<ffffffff817be438>] __radix_tree_preload+0x48/0xc0
> [81248.855166] [<ffffffff817be519>] radix_tree_maybe_preload+0x19/0x20
> [81248.855166] [<ffffffff81181b69>] __add_to_page_cache_locked+0x39/0x1f0
> [81248.855166] [<ffffffff81181d68>] add_to_page_cache_lru+0x28/0x80
> [81248.855166] [<ffffffff81209fc9>] mpage_readpages+0xb9/0x130
> [81248.855166] [<ffffffff814e68e0>] ? __xfs_get_blocks+0x840/0x840
> [81248.855166] [<ffffffff814e68e0>] ? __xfs_get_blocks+0x840/0x840
> [81248.855166] [<ffffffff814e409d>] xfs_vm_readpages+0x1d/0x20
> [81248.855166] [<ffffffff8118cfc9>] __do_page_cache_readahead+0x1b9/0x250
> [81248.855166] [<ffffffff8118d13f>] ondemand_readahead+0xdf/0x270
> [81248.855166] [<ffffffff81180fc6>] ? find_get_entry+0x66/0xb0
> [81248.855166] [<ffffffff8118d362>] page_cache_async_readahead+0x92/0xc0
> [81248.855166] [<ffffffff81182c3c>] generic_file_read_iter+0x41c/0x650
> [81248.855166] [<ffffffff81db9664>] ? down_read+0x24/0x40
> [81248.855166] [<ffffffff814f1d66>] xfs_file_read_iter+0xe6/0x2d0
> [81248.855166] [<ffffffff811cba22>] vfs_iter_read+0x62/0xa0
> [81248.855166] [<ffffffff81a98fcd>] loop_handle_cmd.isra.28+0x6dd/0xaa0
> [81248.855166] [<ffffffff810cce16>] ? try_to_wake_up+0x1f6/0x330
> [81248.855166] [<ffffffff81a99472>] loop_queue_read_work+0x12/0x20
> [81248.855166] [<ffffffff810bd02e>] process_one_work+0x14e/0x410
> [81248.855166] [<ffffffff810bd63e>] worker_thread+0x4e/0x460
> [81248.855166] [<ffffffff810bd5f0>] ? rescuer_thread+0x300/0x300
> [81248.855166] [<ffffffff810c288c>] kthread+0xec/0x110
> [81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
> [81248.855166] [<ffffffff81dbba5f>] ret_from_fork+0x3f/0x70
> [81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
>
> [81248.855166] kworker/0:0 D ffff88002ed8bb88 13896 948 2 0x00000000
> [81248.855166] Workqueue: xfs-cil/loop1 xlog_cil_push_work
> [81248.855166] ffff88002ed8bb88 ffffffff82368540 ffff880003e4be00 ffff88001a467cf0
> [81248.855166] ffff88002ed8c000 ffff880005123cf8 ffff88001a467cf0 ffff880003e4be00
> [81248.855166] ffff880005123cc0 ffff88002ed8bba8 ffffffff81db608e ffff88002ed8bba8
> [81248.855166] Call Trace:
> [81248.855166] [<ffffffff81db608e>] schedule+0x3e/0x90
> [81248.855166] [<ffffffff81511266>] xlog_state_get_iclog_space+0xe6/0x330
> [81248.855166] [<ffffffff810cd010>] ? wake_up_q+0x70/0x70
> [81248.855166] [<ffffffff81511666>] xlog_write+0x1b6/0x870
> [81248.855166] [<ffffffff8151316d>] xlog_cil_push+0x24d/0x400
> [81248.855166] [<ffffffff81513335>] xlog_cil_push_work+0x15/0x20
> [81248.855166] [<ffffffff810bd02e>] process_one_work+0x14e/0x410
> [81248.855166] [<ffffffff810bd63e>] worker_thread+0x4e/0x460
> [81248.855166] [<ffffffff810bd5f0>] ? rescuer_thread+0x300/0x300
> [81248.855166] [<ffffffff810bd5f0>] ? rescuer_thread+0x300/0x300
> [81248.855166] [<ffffffff810c288c>] kthread+0xec/0x110
> [81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
> [81248.855166] [<ffffffff81dbba5f>] ret_from_fork+0x3f/0x70
> [81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
>
> [81248.855166] kworker/u3:4 D ffff8800290439f8 12456 1066 2 0x00000000
> [81248.855166] Workqueue: kloopd1 loop_queue_write_work
> [81248.855166] ffff8800290439f8 ffffffff82368540 ffff8800332f9f00 ffff8800290439e8
> [81248.855166] ffff880029044000 ffffffff00000000 ffff88001366cfd8 ffffffff00000002
> [81248.855166] ffff8800332f9f00 ffff880029043a18 ffffffff81db608e ffff880029043a18
> [81248.855166] Call Trace:
> [81248.855166] [<ffffffff81db608e>] schedule+0x3e/0x90
> [81248.855166] [<ffffffff81db9f3d>] rwsem_down_write_failed+0x13d/0x340
> [81248.855166] [<ffffffff810cce16>] ? try_to_wake_up+0x1f6/0x330
> [81248.855166] [<ffffffff814f2e46>] ? xfs_file_buffered_aio_write+0x66/0x250
> [81248.855166] [<ffffffff817c76a3>] call_rwsem_down_write_failed+0x13/0x20
> [81248.855166] [<ffffffff81db96bf>] ? down_write+0x3f/0x60
> [81248.855166] [<ffffffff814fdea4>] xfs_ilock+0x154/0x1d0
> [81248.855166] [<ffffffff814f2e46>] xfs_file_buffered_aio_write+0x66/0x250
> [81248.855166] [<ffffffff8179264d>] ? kblockd_schedule_work+0x1d/0x30
> [81248.855166] [<ffffffff8179dbc5>] ? blk_mq_kick_requeue_list+0x15/0x20
> [81248.855166] [<ffffffff814f3136>] xfs_file_write_iter+0x106/0x120
> [81248.855166] [<ffffffff811cbac3>] vfs_iter_write+0x63/0xa0
> [81248.855166] [<ffffffff81a97828>] lo_write_bvec+0x58/0x100
> [81248.855166] [<ffffffff81a99248>] loop_handle_cmd.isra.28+0x958/0xaa0
> [81248.855166] [<ffffffff81a9941f>] loop_queue_write_work+0x8f/0xd0
> [81248.855166] [<ffffffff810bd02e>] process_one_work+0x14e/0x410
> [81248.855166] [<ffffffff810bd63e>] worker_thread+0x4e/0x460
> [81248.855166] [<ffffffff810bd5f0>] ? rescuer_thread+0x300/0x300
> [81248.855166] [<ffffffff810c288c>] kthread+0xec/0x110
> [81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
> [81248.855166] [<ffffffff81dbba5f>] ret_from_fork+0x3f/0x70
> [81248.855166] [<ffffffff810c27a0>] ? kthread_create_on_node+0x1b0/0x1b0
> --
> Dave Chinner
> david@fromorbit.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [regression 4.2-rc3] loop: xfstests xfs/073 deadlocked in low memory conditions
2015-07-21 4:05 ` Ming Lei
(?)
@ 2015-07-21 5:46 ` Dave Chinner
-1 siblings, 0 replies; 20+ messages in thread
From: Dave Chinner @ 2015-07-21 5:46 UTC (permalink / raw)
To: Ming Lei; +Cc: Michal Hocko, Linux Kernel Mailing List, linux-mm, xfs
On Tue, Jul 21, 2015 at 12:05:56AM -0400, Ming Lei wrote:
> On Mon, Jul 20, 2015 at 9:59 PM, Dave Chinner <david@fromorbit.com> wrote:
> > Hi Ming,
> >
> > With the recent merge of the loop device changes, I'm now seeing
> > XFS deadlock on my single CPU, 1GB RAM VM running xfs/073.
> >
> > The deadlocked is as follows:
> >
> > kloopd1: loop_queue_read_work
> > xfs_file_iter_read
> > lock XFS inode XFS_IOLOCK_SHARED (on image file)
> > page cache read (GFP_KERNEL)
> > radix tree alloc
> > memory reclaim
> > reclaim XFS inodes
> > log force to unpin inodes
> > <wait for log IO completion>
> >
> > xfs-cil/loop1: <does log force IO work>
> > xlog_cil_push
> > xlog_write
> > <loop issuing log writes>
> > xlog_state_get_iclog_space()
> > <blocks due to all log buffers under write io>
> > <waits for IO completion>
> >
> > kloopd1: loop_queue_write_work
> > xfs_file_write_iter
> > lock XFS inode XFS_IOLOCK_EXCL (on image file)
> > <wait for inode to be unlocked>
> >
> > [The full stack traces are below].
> >
> > i.e. the kloopd, with it's split read and write work queues, has
> > introduced a dependency through memory reclaim. i.e. that writes
> > need to be able to progress for reads make progress.
>
> This kind of change just makes READ vs READ OR WRITE submitted
> to fs concurrently, and the use case should have been simulated from
> user space on one regular XFS file too?
Assuming the "regular XFS file" is on a normal block device (i.e.
not a loop device) then this will not deadlock as there is not
dependency on vfs level locking for log writes.
i.e. normal userspace IO path is:
userspace read
vfs_read
xfs_read
page cache alloc (GFP_KERNEL)
direct reclaim
xfs_inode reclaim
log force
CIL push
<workqueue>
xlog_write
submit_bio
-> hardware.
And then the log IO completes, and everything continues onward.
What the loop device used to do:
userspace read
vfs_read
xfs_read
page cache alloc (GFP_KERNEL)
submit_bio
loop device
splice_read (on image file)
xfs_splice_read
page cache alloc (GFP_NOFS)
direct reclaim
<skip filesystem reclaim>
submit_bio
-> hardware.
And when the read Io completes, everything moves onwards.
What the loop device now does:
userspace read
vfs_read
xfs_read
page cache alloc (GFP_KERNEL)
submit_bio
loop device
<workqueue>
vfs_read (on image file)
xfs_read
page cache alloc (GFP_KERNEL)
direct reclaim
xfs_inode reclaim
log force
CIL push
<workqueue>
xlog_write
submit_bio
loop device
<workqueue>
vfs_write (on image file)
xfs_write
<deadlock on image file lock>
> > The problem, fundamentally, is that mpage_readpages() does a
> > GFP_KERNEL allocation, rather than paying attention to the inode's
> > mapping gfp mask, which is set to GFP_NOFS.
>
> That looks the root cause, and I guess the issue is just triggered
> after commit aa4d86163e4(block: loop: switch to VFS ITER_BVEC)
> which changes splice to bvec iterator.
Yup - you are the unfortunate person who has wandered into the
minefield I'd been telling people about for quite some time. :(
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [regression 4.2-rc3] loop: xfstests xfs/073 deadlocked in low memory conditions
@ 2015-07-21 5:46 ` Dave Chinner
0 siblings, 0 replies; 20+ messages in thread
From: Dave Chinner @ 2015-07-21 5:46 UTC (permalink / raw)
To: Ming Lei; +Cc: Michal Hocko, linux-mm, Linux Kernel Mailing List, xfs
On Tue, Jul 21, 2015 at 12:05:56AM -0400, Ming Lei wrote:
> On Mon, Jul 20, 2015 at 9:59 PM, Dave Chinner <david@fromorbit.com> wrote:
> > Hi Ming,
> >
> > With the recent merge of the loop device changes, I'm now seeing
> > XFS deadlock on my single CPU, 1GB RAM VM running xfs/073.
> >
> > The deadlocked is as follows:
> >
> > kloopd1: loop_queue_read_work
> > xfs_file_iter_read
> > lock XFS inode XFS_IOLOCK_SHARED (on image file)
> > page cache read (GFP_KERNEL)
> > radix tree alloc
> > memory reclaim
> > reclaim XFS inodes
> > log force to unpin inodes
> > <wait for log IO completion>
> >
> > xfs-cil/loop1: <does log force IO work>
> > xlog_cil_push
> > xlog_write
> > <loop issuing log writes>
> > xlog_state_get_iclog_space()
> > <blocks due to all log buffers under write io>
> > <waits for IO completion>
> >
> > kloopd1: loop_queue_write_work
> > xfs_file_write_iter
> > lock XFS inode XFS_IOLOCK_EXCL (on image file)
> > <wait for inode to be unlocked>
> >
> > [The full stack traces are below].
> >
> > i.e. the kloopd, with it's split read and write work queues, has
> > introduced a dependency through memory reclaim. i.e. that writes
> > need to be able to progress for reads make progress.
>
> This kind of change just makes READ vs READ OR WRITE submitted
> to fs concurrently, and the use case should have been simulated from
> user space on one regular XFS file too?
Assuming the "regular XFS file" is on a normal block device (i.e.
not a loop device) then this will not deadlock as there is not
dependency on vfs level locking for log writes.
i.e. normal userspace IO path is:
userspace read
vfs_read
xfs_read
page cache alloc (GFP_KERNEL)
direct reclaim
xfs_inode reclaim
log force
CIL push
<workqueue>
xlog_write
submit_bio
-> hardware.
And then the log IO completes, and everything continues onward.
What the loop device used to do:
userspace read
vfs_read
xfs_read
page cache alloc (GFP_KERNEL)
submit_bio
loop device
splice_read (on image file)
xfs_splice_read
page cache alloc (GFP_NOFS)
direct reclaim
<skip filesystem reclaim>
submit_bio
-> hardware.
And when the read Io completes, everything moves onwards.
What the loop device now does:
userspace read
vfs_read
xfs_read
page cache alloc (GFP_KERNEL)
submit_bio
loop device
<workqueue>
vfs_read (on image file)
xfs_read
page cache alloc (GFP_KERNEL)
direct reclaim
xfs_inode reclaim
log force
CIL push
<workqueue>
xlog_write
submit_bio
loop device
<workqueue>
vfs_write (on image file)
xfs_write
<deadlock on image file lock>
> > The problem, fundamentally, is that mpage_readpages() does a
> > GFP_KERNEL allocation, rather than paying attention to the inode's
> > mapping gfp mask, which is set to GFP_NOFS.
>
> That looks the root cause, and I guess the issue is just triggered
> after commit aa4d86163e4(block: loop: switch to VFS ITER_BVEC)
> which changes splice to bvec iterator.
Yup - you are the unfortunate person who has wandered into the
minefield I'd been telling people about for quite some time. :(
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [regression 4.2-rc3] loop: xfstests xfs/073 deadlocked in low memory conditions
@ 2015-07-21 5:46 ` Dave Chinner
0 siblings, 0 replies; 20+ messages in thread
From: Dave Chinner @ 2015-07-21 5:46 UTC (permalink / raw)
To: Ming Lei; +Cc: Michal Hocko, Linux Kernel Mailing List, linux-mm, xfs
On Tue, Jul 21, 2015 at 12:05:56AM -0400, Ming Lei wrote:
> On Mon, Jul 20, 2015 at 9:59 PM, Dave Chinner <david@fromorbit.com> wrote:
> > Hi Ming,
> >
> > With the recent merge of the loop device changes, I'm now seeing
> > XFS deadlock on my single CPU, 1GB RAM VM running xfs/073.
> >
> > The deadlocked is as follows:
> >
> > kloopd1: loop_queue_read_work
> > xfs_file_iter_read
> > lock XFS inode XFS_IOLOCK_SHARED (on image file)
> > page cache read (GFP_KERNEL)
> > radix tree alloc
> > memory reclaim
> > reclaim XFS inodes
> > log force to unpin inodes
> > <wait for log IO completion>
> >
> > xfs-cil/loop1: <does log force IO work>
> > xlog_cil_push
> > xlog_write
> > <loop issuing log writes>
> > xlog_state_get_iclog_space()
> > <blocks due to all log buffers under write io>
> > <waits for IO completion>
> >
> > kloopd1: loop_queue_write_work
> > xfs_file_write_iter
> > lock XFS inode XFS_IOLOCK_EXCL (on image file)
> > <wait for inode to be unlocked>
> >
> > [The full stack traces are below].
> >
> > i.e. the kloopd, with it's split read and write work queues, has
> > introduced a dependency through memory reclaim. i.e. that writes
> > need to be able to progress for reads make progress.
>
> This kind of change just makes READ vs READ OR WRITE submitted
> to fs concurrently, and the use case should have been simulated from
> user space on one regular XFS file too?
Assuming the "regular XFS file" is on a normal block device (i.e.
not a loop device) then this will not deadlock as there is not
dependency on vfs level locking for log writes.
i.e. normal userspace IO path is:
userspace read
vfs_read
xfs_read
page cache alloc (GFP_KERNEL)
direct reclaim
xfs_inode reclaim
log force
CIL push
<workqueue>
xlog_write
submit_bio
-> hardware.
And then the log IO completes, and everything continues onward.
What the loop device used to do:
userspace read
vfs_read
xfs_read
page cache alloc (GFP_KERNEL)
submit_bio
loop device
splice_read (on image file)
xfs_splice_read
page cache alloc (GFP_NOFS)
direct reclaim
<skip filesystem reclaim>
submit_bio
-> hardware.
And when the read Io completes, everything moves onwards.
What the loop device now does:
userspace read
vfs_read
xfs_read
page cache alloc (GFP_KERNEL)
submit_bio
loop device
<workqueue>
vfs_read (on image file)
xfs_read
page cache alloc (GFP_KERNEL)
direct reclaim
xfs_inode reclaim
log force
CIL push
<workqueue>
xlog_write
submit_bio
loop device
<workqueue>
vfs_write (on image file)
xfs_write
<deadlock on image file lock>
> > The problem, fundamentally, is that mpage_readpages() does a
> > GFP_KERNEL allocation, rather than paying attention to the inode's
> > mapping gfp mask, which is set to GFP_NOFS.
>
> That looks the root cause, and I guess the issue is just triggered
> after commit aa4d86163e4(block: loop: switch to VFS ITER_BVEC)
> which changes splice to bvec iterator.
Yup - you are the unfortunate person who has wandered into the
minefield I'd been telling people about for quite some time. :(
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [regression 4.2-rc3] loop: xfstests xfs/073 deadlocked in low memory conditions
2015-07-21 1:59 ` Dave Chinner
(?)
(?)
@ 2015-07-21 8:58 ` Michal Hocko
-1 siblings, 0 replies; 20+ messages in thread
From: Michal Hocko @ 2015-07-21 8:58 UTC (permalink / raw)
To: Dave Chinner
Cc: Ming Lei, Andrew Morton, Theodore Ts'o, Andreas Dilger,
Oleg Drokin, Alexander Viro, Christoph Hellwig, linux-kernel,
linux-mm, xfs, linux-nfs, linux-cifs
[CCing more people from a potentially affected fs - the reference to the
email thread is: http://marc.info/?l=linux-mm&m=143744398020147&w=2]
On Tue 21-07-15 11:59:34, Dave Chinner wrote:
> Hi Ming,
>
> With the recent merge of the loop device changes, I'm now seeing
> XFS deadlock on my single CPU, 1GB RAM VM running xfs/073.
>
> The deadlocked is as follows:
>
> kloopd1: loop_queue_read_work
> xfs_file_iter_read
> lock XFS inode XFS_IOLOCK_SHARED (on image file)
> page cache read (GFP_KERNEL)
> radix tree alloc
> memory reclaim
> reclaim XFS inodes
> log force to unpin inodes
> <wait for log IO completion>
>
> xfs-cil/loop1: <does log force IO work>
> xlog_cil_push
> xlog_write
> <loop issuing log writes>
> xlog_state_get_iclog_space()
> <blocks due to all log buffers under write io>
> <waits for IO completion>
>
> kloopd1: loop_queue_write_work
> xfs_file_write_iter
> lock XFS inode XFS_IOLOCK_EXCL (on image file)
> <wait for inode to be unlocked>
>
> [The full stack traces are below].
>
> i.e. the kloopd, with it's split read and write work queues, has
> introduced a dependency through memory reclaim. i.e. that writes
> need to be able to progress for reads make progress.
>
> The problem, fundamentally, is that mpage_readpages() does a
> GFP_KERNEL allocation, rather than paying attention to the inode's
> mapping gfp mask, which is set to GFP_NOFS.
>
> The didn't used to happen, because the loop device used to issue
> reads through the splice path and that does:
>
> error = add_to_page_cache_lru(page, mapping, index,
> GFP_KERNEL & mapping_gfp_mask(mapping));
>
> i.e. it pays attention to the allocation context placed on the
> inode and so is doing GFP_NOFS allocations here and avoiding the
> recursion problem.
>
> [ CC'd Michal Hocko and the mm list because it's a clear exaple of
> why ignoring the mapping gfp mask on any page cache allocation is
> a landmine waiting to be tripped over. ]
Thank you for CCing me. I haven't noticed this one when checking for
other similar hardcoded GFP_KERNEL users (6afdb859b710 ("mm: do not
ignore mapping_gfp_mask in page cache allocation paths")). And there
seem to be more of them now that I am looking closer.
I am not sure what to do about fs/nfs/dir.c:nfs_symlink which doesn't
require GFP_NOFS or mapping gfp mask for other allocations in the same
context.
What do you think about this preliminary (and untested) patch? I cannot
say I would be happy about sprinkling mapping_gfp_mask all over the place
and it sounds like we should drop gfp_mask argument altogether and
use it internally in __add_to_page_cache_locked that would require all
the filesystems to use mapping gfp consistently which I am not sure is
the case here. From a quick glance it seems that some file system use
it all the time while others are selective.
---
>From 72e13282dfb117432332416b60bc4e4d2dad9153 Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko@suse.com>
Date: Tue, 21 Jul 2015 10:06:13 +0200
Subject: [PATCH] mm, fs: Obey gfp_mapping for add_to_page_cache
6afdb859b710 ("mm: do not ignore mapping_gfp_mask in page cache
allocation paths) has caught some users of hardcoded GFP_KERNEL
used in the page cache allocation paths. This, however, wasn't complete
and there were others which went unnoticed.
Dave Chinner has reported the following deadlock for xfs on loop device:
: With the recent merge of the loop device changes, I'm now seeing
: XFS deadlock on my single CPU, 1GB RAM VM running xfs/073.
:
: The deadlocked is as follows:
:
: kloopd1: loop_queue_read_work
: xfs_file_iter_read
: lock XFS inode XFS_IOLOCK_SHARED (on image file)
: page cache read (GFP_KERNEL)
: radix tree alloc
: memory reclaim
: reclaim XFS inodes
: log force to unpin inodes
: <wait for log IO completion>
:
: xfs-cil/loop1: <does log force IO work>
: xlog_cil_push
: xlog_write
: <loop issuing log writes>
: xlog_state_get_iclog_space()
: <blocks due to all log buffers under write io>
: <waits for IO completion>
:
: kloopd1: loop_queue_write_work
: xfs_file_write_iter
: lock XFS inode XFS_IOLOCK_EXCL (on image file)
: <wait for inode to be unlocked>
:
: i.e. the kloopd, with it's split read and write work queues, has
: introduced a dependency through memory reclaim. i.e. that writes
: need to be able to progress for reads make progress.
:
: The problem, fundamentally, is that mpage_readpages() does a
: GFP_KERNEL allocation, rather than paying attention to the inode's
: mapping gfp mask, which is set to GFP_NOFS.
:
: The didn't used to happen, because the loop device used to issue
: reads through the splice path and that does:
:
: error = add_to_page_cache_lru(page, mapping, index,
: GFP_KERNEL & mapping_gfp_mask(mapping));
This has changed by aa4d86163e4 (block: loop: switch to VFS ITER_BVEC).
This patch changes mpage_readpage{s} to follow gfp mask set for the
mapping. There are, however, other places which are doing basically the
same.
lustre:ll_dir_filler is doing GFP_KERNEL from the function which
apparently uses GFP_NOFS for other allocations so let's make this
consistent.
cifs:readpages_get_pages is called from cifs_readpages and
__cifs_readpages_from_fscache called from the same path obeys mapping
gfp.
ramfs_nommu_expand_for_mapping is hardcoding GFP_KERNEL as well
regardless it uses mapping_gfp_mask for the page allocation.
ext4_mpage_readpages is the called from the page cache allocation path
same as read_pages and read_cache_pages
Reported-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
drivers/staging/lustre/lustre/llite/dir.c | 2 +-
fs/cifs/file.c | 5 +++--
fs/ext4/readpage.c | 3 ++-
fs/mpage.c | 14 +++++++++-----
fs/ramfs/file-nommu.c | 5 +++--
mm/readahead.c | 6 ++++--
6 files changed, 22 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/dir.c b/drivers/staging/lustre/lustre/llite/dir.c
index a5bc694dcb64..0a643b8b6deb 100644
--- a/drivers/staging/lustre/lustre/llite/dir.c
+++ b/drivers/staging/lustre/lustre/llite/dir.c
@@ -225,7 +225,7 @@ static int ll_dir_filler(void *_hash, struct page *page0)
prefetchw(&page->flags);
ret = add_to_page_cache_lru(page, inode->i_mapping, offset,
- GFP_KERNEL);
+ GFP_NOFS);
if (ret == 0) {
unlock_page(page);
if (ll_pagevec_add(&lru_pvec, page) == 0)
diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index 2ac2d8471393..72c162a1d56d 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -3380,6 +3380,7 @@ readpages_get_pages(struct address_space *mapping, struct list_head *page_list,
struct page *page, *tpage;
unsigned int expected_index;
int rc;
+ gfp_t gfp = GFP_KERNEL & mapping_gfp_mask(mapping);
INIT_LIST_HEAD(tmplist);
@@ -3392,7 +3393,7 @@ readpages_get_pages(struct address_space *mapping, struct list_head *page_list,
*/
__SetPageLocked(page);
rc = add_to_page_cache_locked(page, mapping,
- page->index, GFP_KERNEL);
+ page->index, gfp);
/* give up if we can't stick it in the cache */
if (rc) {
@@ -3419,7 +3420,7 @@ readpages_get_pages(struct address_space *mapping, struct list_head *page_list,
__SetPageLocked(page);
if (add_to_page_cache_locked(page, mapping, page->index,
- GFP_KERNEL)) {
+ gfp)) {
__ClearPageLocked(page);
break;
}
diff --git a/fs/ext4/readpage.c b/fs/ext4/readpage.c
index 171b9ac4b45e..92eb970655bd 100644
--- a/fs/ext4/readpage.c
+++ b/fs/ext4/readpage.c
@@ -166,7 +166,8 @@ int ext4_mpage_readpages(struct address_space *mapping,
page = list_entry(pages->prev, struct page, lru);
list_del(&page->lru);
if (add_to_page_cache_lru(page, mapping,
- page->index, GFP_KERNEL))
+ page->index,
+ GFP_KERNEL & mapping_gfp_mask(mapping)))
goto next_page;
}
diff --git a/fs/mpage.c b/fs/mpage.c
index dde689d0759d..4a54bd13c9bd 100644
--- a/fs/mpage.c
+++ b/fs/mpage.c
@@ -139,7 +139,8 @@ map_buffer_to_page(struct page *page, struct buffer_head *bh, int page_block)
static struct bio *
do_mpage_readpage(struct bio *bio, struct page *page, unsigned nr_pages,
sector_t *last_block_in_bio, struct buffer_head *map_bh,
- unsigned long *first_logical_block, get_block_t get_block)
+ unsigned long *first_logical_block, get_block_t get_block,
+ gfp_t gfp)
{
struct inode *inode = page->mapping->host;
const unsigned blkbits = inode->i_blkbits;
@@ -278,7 +279,7 @@ do_mpage_readpage(struct bio *bio, struct page *page, unsigned nr_pages,
}
bio = mpage_alloc(bdev, blocks[0] << (blkbits - 9),
min_t(int, nr_pages, bio_get_nr_vecs(bdev)),
- GFP_KERNEL);
+ gfp);
if (bio == NULL)
goto confused;
}
@@ -361,6 +362,7 @@ mpage_readpages(struct address_space *mapping, struct list_head *pages,
sector_t last_block_in_bio = 0;
struct buffer_head map_bh;
unsigned long first_logical_block = 0;
+ gfp_t gfp = GFP_KERNEL & mapping_gfp_mask(mapping);
map_bh.b_state = 0;
map_bh.b_size = 0;
@@ -370,12 +372,13 @@ mpage_readpages(struct address_space *mapping, struct list_head *pages,
prefetchw(&page->flags);
list_del(&page->lru);
if (!add_to_page_cache_lru(page, mapping,
- page->index, GFP_KERNEL)) {
+ page->index,
+ gfp)) {
bio = do_mpage_readpage(bio, page,
nr_pages - page_idx,
&last_block_in_bio, &map_bh,
&first_logical_block,
- get_block);
+ get_block, gfp);
}
page_cache_release(page);
}
@@ -395,11 +398,12 @@ int mpage_readpage(struct page *page, get_block_t get_block)
sector_t last_block_in_bio = 0;
struct buffer_head map_bh;
unsigned long first_logical_block = 0;
+ gfp_t gfp = mapping_gfp_mask(page->mapping);
map_bh.b_state = 0;
map_bh.b_size = 0;
bio = do_mpage_readpage(bio, page, 1, &last_block_in_bio,
- &map_bh, &first_logical_block, get_block);
+ &map_bh, &first_logical_block, get_block, gfp);
if (bio)
mpage_bio_submit(READ, bio);
return 0;
diff --git a/fs/ramfs/file-nommu.c b/fs/ramfs/file-nommu.c
index ba1323a94924..a586467f6ff6 100644
--- a/fs/ramfs/file-nommu.c
+++ b/fs/ramfs/file-nommu.c
@@ -70,6 +70,7 @@ int ramfs_nommu_expand_for_mapping(struct inode *inode, size_t newsize)
unsigned order;
void *data;
int ret;
+ gfp_t gfp = mapping_gfp_mask(inode->i_mapping);
/* make various checks */
order = get_order(newsize);
@@ -84,7 +85,7 @@ int ramfs_nommu_expand_for_mapping(struct inode *inode, size_t newsize)
/* allocate enough contiguous pages to be able to satisfy the
* request */
- pages = alloc_pages(mapping_gfp_mask(inode->i_mapping), order);
+ pages = alloc_pages(gfp, order);
if (!pages)
return -ENOMEM;
@@ -108,7 +109,7 @@ int ramfs_nommu_expand_for_mapping(struct inode *inode, size_t newsize)
struct page *page = pages + loop;
ret = add_to_page_cache_lru(page, inode->i_mapping, loop,
- GFP_KERNEL);
+ gfp);
if (ret < 0)
goto add_error;
diff --git a/mm/readahead.c b/mm/readahead.c
index 60cd846a9a44..b9b99597dc77 100644
--- a/mm/readahead.c
+++ b/mm/readahead.c
@@ -90,7 +90,8 @@ int read_cache_pages(struct address_space *mapping, struct list_head *pages,
page = list_to_page(pages);
list_del(&page->lru);
if (add_to_page_cache_lru(page, mapping,
- page->index, GFP_KERNEL)) {
+ page->index,
+ GFP_KERNEL & mapping_gfp_mask(mapping))) {
read_cache_pages_invalidate_page(mapping, page);
continue;
}
@@ -128,7 +129,8 @@ static int read_pages(struct address_space *mapping, struct file *filp,
struct page *page = list_to_page(pages);
list_del(&page->lru);
if (!add_to_page_cache_lru(page, mapping,
- page->index, GFP_KERNEL)) {
+ page->index,
+ GFP_KERNEL & mapping_gfp_mask(mapping))) {
mapping->a_ops->readpage(filp, page);
}
page_cache_release(page);
--
2.1.4
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [regression 4.2-rc3] loop: xfstests xfs/073 deadlocked in low memory conditions
@ 2015-07-21 8:58 ` Michal Hocko
0 siblings, 0 replies; 20+ messages in thread
From: Michal Hocko @ 2015-07-21 8:58 UTC (permalink / raw)
To: Dave Chinner
Cc: Ming Lei, Andrew Morton, Theodore Ts'o, Andreas Dilger,
Oleg Drokin, Alexander Viro, Christoph Hellwig, linux-kernel,
linux-mm, xfs, linux-nfs, linux-cifs
[CCing more people from a potentially affected fs - the reference to the
email thread is: http://marc.info/?l=linux-mm&m=143744398020147&w=2]
On Tue 21-07-15 11:59:34, Dave Chinner wrote:
> Hi Ming,
>
> With the recent merge of the loop device changes, I'm now seeing
> XFS deadlock on my single CPU, 1GB RAM VM running xfs/073.
>
> The deadlocked is as follows:
>
> kloopd1: loop_queue_read_work
> xfs_file_iter_read
> lock XFS inode XFS_IOLOCK_SHARED (on image file)
> page cache read (GFP_KERNEL)
> radix tree alloc
> memory reclaim
> reclaim XFS inodes
> log force to unpin inodes
> <wait for log IO completion>
>
> xfs-cil/loop1: <does log force IO work>
> xlog_cil_push
> xlog_write
> <loop issuing log writes>
> xlog_state_get_iclog_space()
> <blocks due to all log buffers under write io>
> <waits for IO completion>
>
> kloopd1: loop_queue_write_work
> xfs_file_write_iter
> lock XFS inode XFS_IOLOCK_EXCL (on image file)
> <wait for inode to be unlocked>
>
> [The full stack traces are below].
>
> i.e. the kloopd, with it's split read and write work queues, has
> introduced a dependency through memory reclaim. i.e. that writes
> need to be able to progress for reads make progress.
>
> The problem, fundamentally, is that mpage_readpages() does a
> GFP_KERNEL allocation, rather than paying attention to the inode's
> mapping gfp mask, which is set to GFP_NOFS.
>
> The didn't used to happen, because the loop device used to issue
> reads through the splice path and that does:
>
> error = add_to_page_cache_lru(page, mapping, index,
> GFP_KERNEL & mapping_gfp_mask(mapping));
>
> i.e. it pays attention to the allocation context placed on the
> inode and so is doing GFP_NOFS allocations here and avoiding the
> recursion problem.
>
> [ CC'd Michal Hocko and the mm list because it's a clear exaple of
> why ignoring the mapping gfp mask on any page cache allocation is
> a landmine waiting to be tripped over. ]
Thank you for CCing me. I haven't noticed this one when checking for
other similar hardcoded GFP_KERNEL users (6afdb859b710 ("mm: do not
ignore mapping_gfp_mask in page cache allocation paths")). And there
seem to be more of them now that I am looking closer.
I am not sure what to do about fs/nfs/dir.c:nfs_symlink which doesn't
require GFP_NOFS or mapping gfp mask for other allocations in the same
context.
What do you think about this preliminary (and untested) patch? I cannot
say I would be happy about sprinkling mapping_gfp_mask all over the place
and it sounds like we should drop gfp_mask argument altogether and
use it internally in __add_to_page_cache_locked that would require all
the filesystems to use mapping gfp consistently which I am not sure is
the case here. From a quick glance it seems that some file system use
it all the time while others are selective.
---
>From 72e13282dfb117432332416b60bc4e4d2dad9153 Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko@suse.com>
Date: Tue, 21 Jul 2015 10:06:13 +0200
Subject: [PATCH] mm, fs: Obey gfp_mapping for add_to_page_cache
6afdb859b710 ("mm: do not ignore mapping_gfp_mask in page cache
allocation paths) has caught some users of hardcoded GFP_KERNEL
used in the page cache allocation paths. This, however, wasn't complete
and there were others which went unnoticed.
Dave Chinner has reported the following deadlock for xfs on loop device:
: With the recent merge of the loop device changes, I'm now seeing
: XFS deadlock on my single CPU, 1GB RAM VM running xfs/073.
:
: The deadlocked is as follows:
:
: kloopd1: loop_queue_read_work
: xfs_file_iter_read
: lock XFS inode XFS_IOLOCK_SHARED (on image file)
: page cache read (GFP_KERNEL)
: radix tree alloc
: memory reclaim
: reclaim XFS inodes
: log force to unpin inodes
: <wait for log IO completion>
:
: xfs-cil/loop1: <does log force IO work>
: xlog_cil_push
: xlog_write
: <loop issuing log writes>
: xlog_state_get_iclog_space()
: <blocks due to all log buffers under write io>
: <waits for IO completion>
:
: kloopd1: loop_queue_write_work
: xfs_file_write_iter
: lock XFS inode XFS_IOLOCK_EXCL (on image file)
: <wait for inode to be unlocked>
:
: i.e. the kloopd, with it's split read and write work queues, has
: introduced a dependency through memory reclaim. i.e. that writes
: need to be able to progress for reads make progress.
:
: The problem, fundamentally, is that mpage_readpages() does a
: GFP_KERNEL allocation, rather than paying attention to the inode's
: mapping gfp mask, which is set to GFP_NOFS.
:
: The didn't used to happen, because the loop device used to issue
: reads through the splice path and that does:
:
: error = add_to_page_cache_lru(page, mapping, index,
: GFP_KERNEL & mapping_gfp_mask(mapping));
This has changed by aa4d86163e4 (block: loop: switch to VFS ITER_BVEC).
This patch changes mpage_readpage{s} to follow gfp mask set for the
mapping. There are, however, other places which are doing basically the
same.
lustre:ll_dir_filler is doing GFP_KERNEL from the function which
apparently uses GFP_NOFS for other allocations so let's make this
consistent.
cifs:readpages_get_pages is called from cifs_readpages and
__cifs_readpages_from_fscache called from the same path obeys mapping
gfp.
ramfs_nommu_expand_for_mapping is hardcoding GFP_KERNEL as well
regardless it uses mapping_gfp_mask for the page allocation.
ext4_mpage_readpages is the called from the page cache allocation path
same as read_pages and read_cache_pages
Reported-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
drivers/staging/lustre/lustre/llite/dir.c | 2 +-
fs/cifs/file.c | 5 +++--
fs/ext4/readpage.c | 3 ++-
fs/mpage.c | 14 +++++++++-----
fs/ramfs/file-nommu.c | 5 +++--
mm/readahead.c | 6 ++++--
6 files changed, 22 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/dir.c b/drivers/staging/lustre/lustre/llite/dir.c
index a5bc694dcb64..0a643b8b6deb 100644
--- a/drivers/staging/lustre/lustre/llite/dir.c
+++ b/drivers/staging/lustre/lustre/llite/dir.c
@@ -225,7 +225,7 @@ static int ll_dir_filler(void *_hash, struct page *page0)
prefetchw(&page->flags);
ret = add_to_page_cache_lru(page, inode->i_mapping, offset,
- GFP_KERNEL);
+ GFP_NOFS);
if (ret == 0) {
unlock_page(page);
if (ll_pagevec_add(&lru_pvec, page) == 0)
diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index 2ac2d8471393..72c162a1d56d 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -3380,6 +3380,7 @@ readpages_get_pages(struct address_space *mapping, struct list_head *page_list,
struct page *page, *tpage;
unsigned int expected_index;
int rc;
+ gfp_t gfp = GFP_KERNEL & mapping_gfp_mask(mapping);
INIT_LIST_HEAD(tmplist);
@@ -3392,7 +3393,7 @@ readpages_get_pages(struct address_space *mapping, struct list_head *page_list,
*/
__SetPageLocked(page);
rc = add_to_page_cache_locked(page, mapping,
- page->index, GFP_KERNEL);
+ page->index, gfp);
/* give up if we can't stick it in the cache */
if (rc) {
@@ -3419,7 +3420,7 @@ readpages_get_pages(struct address_space *mapping, struct list_head *page_list,
__SetPageLocked(page);
if (add_to_page_cache_locked(page, mapping, page->index,
- GFP_KERNEL)) {
+ gfp)) {
__ClearPageLocked(page);
break;
}
diff --git a/fs/ext4/readpage.c b/fs/ext4/readpage.c
index 171b9ac4b45e..92eb970655bd 100644
--- a/fs/ext4/readpage.c
+++ b/fs/ext4/readpage.c
@@ -166,7 +166,8 @@ int ext4_mpage_readpages(struct address_space *mapping,
page = list_entry(pages->prev, struct page, lru);
list_del(&page->lru);
if (add_to_page_cache_lru(page, mapping,
- page->index, GFP_KERNEL))
+ page->index,
+ GFP_KERNEL & mapping_gfp_mask(mapping)))
goto next_page;
}
diff --git a/fs/mpage.c b/fs/mpage.c
index dde689d0759d..4a54bd13c9bd 100644
--- a/fs/mpage.c
+++ b/fs/mpage.c
@@ -139,7 +139,8 @@ map_buffer_to_page(struct page *page, struct buffer_head *bh, int page_block)
static struct bio *
do_mpage_readpage(struct bio *bio, struct page *page, unsigned nr_pages,
sector_t *last_block_in_bio, struct buffer_head *map_bh,
- unsigned long *first_logical_block, get_block_t get_block)
+ unsigned long *first_logical_block, get_block_t get_block,
+ gfp_t gfp)
{
struct inode *inode = page->mapping->host;
const unsigned blkbits = inode->i_blkbits;
@@ -278,7 +279,7 @@ do_mpage_readpage(struct bio *bio, struct page *page, unsigned nr_pages,
}
bio = mpage_alloc(bdev, blocks[0] << (blkbits - 9),
min_t(int, nr_pages, bio_get_nr_vecs(bdev)),
- GFP_KERNEL);
+ gfp);
if (bio == NULL)
goto confused;
}
@@ -361,6 +362,7 @@ mpage_readpages(struct address_space *mapping, struct list_head *pages,
sector_t last_block_in_bio = 0;
struct buffer_head map_bh;
unsigned long first_logical_block = 0;
+ gfp_t gfp = GFP_KERNEL & mapping_gfp_mask(mapping);
map_bh.b_state = 0;
map_bh.b_size = 0;
@@ -370,12 +372,13 @@ mpage_readpages(struct address_space *mapping, struct list_head *pages,
prefetchw(&page->flags);
list_del(&page->lru);
if (!add_to_page_cache_lru(page, mapping,
- page->index, GFP_KERNEL)) {
+ page->index,
+ gfp)) {
bio = do_mpage_readpage(bio, page,
nr_pages - page_idx,
&last_block_in_bio, &map_bh,
&first_logical_block,
- get_block);
+ get_block, gfp);
}
page_cache_release(page);
}
@@ -395,11 +398,12 @@ int mpage_readpage(struct page *page, get_block_t get_block)
sector_t last_block_in_bio = 0;
struct buffer_head map_bh;
unsigned long first_logical_block = 0;
+ gfp_t gfp = mapping_gfp_mask(page->mapping);
map_bh.b_state = 0;
map_bh.b_size = 0;
bio = do_mpage_readpage(bio, page, 1, &last_block_in_bio,
- &map_bh, &first_logical_block, get_block);
+ &map_bh, &first_logical_block, get_block, gfp);
if (bio)
mpage_bio_submit(READ, bio);
return 0;
diff --git a/fs/ramfs/file-nommu.c b/fs/ramfs/file-nommu.c
index ba1323a94924..a586467f6ff6 100644
--- a/fs/ramfs/file-nommu.c
+++ b/fs/ramfs/file-nommu.c
@@ -70,6 +70,7 @@ int ramfs_nommu_expand_for_mapping(struct inode *inode, size_t newsize)
unsigned order;
void *data;
int ret;
+ gfp_t gfp = mapping_gfp_mask(inode->i_mapping);
/* make various checks */
order = get_order(newsize);
@@ -84,7 +85,7 @@ int ramfs_nommu_expand_for_mapping(struct inode *inode, size_t newsize)
/* allocate enough contiguous pages to be able to satisfy the
* request */
- pages = alloc_pages(mapping_gfp_mask(inode->i_mapping), order);
+ pages = alloc_pages(gfp, order);
if (!pages)
return -ENOMEM;
@@ -108,7 +109,7 @@ int ramfs_nommu_expand_for_mapping(struct inode *inode, size_t newsize)
struct page *page = pages + loop;
ret = add_to_page_cache_lru(page, inode->i_mapping, loop,
- GFP_KERNEL);
+ gfp);
if (ret < 0)
goto add_error;
diff --git a/mm/readahead.c b/mm/readahead.c
index 60cd846a9a44..b9b99597dc77 100644
--- a/mm/readahead.c
+++ b/mm/readahead.c
@@ -90,7 +90,8 @@ int read_cache_pages(struct address_space *mapping, struct list_head *pages,
page = list_to_page(pages);
list_del(&page->lru);
if (add_to_page_cache_lru(page, mapping,
- page->index, GFP_KERNEL)) {
+ page->index,
+ GFP_KERNEL & mapping_gfp_mask(mapping))) {
read_cache_pages_invalidate_page(mapping, page);
continue;
}
@@ -128,7 +129,8 @@ static int read_pages(struct address_space *mapping, struct file *filp,
struct page *page = list_to_page(pages);
list_del(&page->lru);
if (!add_to_page_cache_lru(page, mapping,
- page->index, GFP_KERNEL)) {
+ page->index,
+ GFP_KERNEL & mapping_gfp_mask(mapping))) {
mapping->a_ops->readpage(filp, page);
}
page_cache_release(page);
--
2.1.4
--
Michal Hocko
SUSE Labs
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [regression 4.2-rc3] loop: xfstests xfs/073 deadlocked in low memory conditions
@ 2015-07-21 8:58 ` Michal Hocko
0 siblings, 0 replies; 20+ messages in thread
From: Michal Hocko @ 2015-07-21 8:58 UTC (permalink / raw)
To: Dave Chinner
Cc: linux-cifs, linux-nfs, Andreas Dilger, Ming Lei, linux-kernel,
xfs, Oleg Drokin, linux-mm, Alexander Viro, Theodore Ts'o,
Andrew Morton, Christoph Hellwig
[CCing more people from a potentially affected fs - the reference to the
email thread is: http://marc.info/?l=linux-mm&m=143744398020147&w=2]
On Tue 21-07-15 11:59:34, Dave Chinner wrote:
> Hi Ming,
>
> With the recent merge of the loop device changes, I'm now seeing
> XFS deadlock on my single CPU, 1GB RAM VM running xfs/073.
>
> The deadlocked is as follows:
>
> kloopd1: loop_queue_read_work
> xfs_file_iter_read
> lock XFS inode XFS_IOLOCK_SHARED (on image file)
> page cache read (GFP_KERNEL)
> radix tree alloc
> memory reclaim
> reclaim XFS inodes
> log force to unpin inodes
> <wait for log IO completion>
>
> xfs-cil/loop1: <does log force IO work>
> xlog_cil_push
> xlog_write
> <loop issuing log writes>
> xlog_state_get_iclog_space()
> <blocks due to all log buffers under write io>
> <waits for IO completion>
>
> kloopd1: loop_queue_write_work
> xfs_file_write_iter
> lock XFS inode XFS_IOLOCK_EXCL (on image file)
> <wait for inode to be unlocked>
>
> [The full stack traces are below].
>
> i.e. the kloopd, with it's split read and write work queues, has
> introduced a dependency through memory reclaim. i.e. that writes
> need to be able to progress for reads make progress.
>
> The problem, fundamentally, is that mpage_readpages() does a
> GFP_KERNEL allocation, rather than paying attention to the inode's
> mapping gfp mask, which is set to GFP_NOFS.
>
> The didn't used to happen, because the loop device used to issue
> reads through the splice path and that does:
>
> error = add_to_page_cache_lru(page, mapping, index,
> GFP_KERNEL & mapping_gfp_mask(mapping));
>
> i.e. it pays attention to the allocation context placed on the
> inode and so is doing GFP_NOFS allocations here and avoiding the
> recursion problem.
>
> [ CC'd Michal Hocko and the mm list because it's a clear exaple of
> why ignoring the mapping gfp mask on any page cache allocation is
> a landmine waiting to be tripped over. ]
Thank you for CCing me. I haven't noticed this one when checking for
other similar hardcoded GFP_KERNEL users (6afdb859b710 ("mm: do not
ignore mapping_gfp_mask in page cache allocation paths")). And there
seem to be more of them now that I am looking closer.
I am not sure what to do about fs/nfs/dir.c:nfs_symlink which doesn't
require GFP_NOFS or mapping gfp mask for other allocations in the same
context.
What do you think about this preliminary (and untested) patch? I cannot
say I would be happy about sprinkling mapping_gfp_mask all over the place
and it sounds like we should drop gfp_mask argument altogether and
use it internally in __add_to_page_cache_locked that would require all
the filesystems to use mapping gfp consistently which I am not sure is
the case here. From a quick glance it seems that some file system use
it all the time while others are selective.
---
>From 72e13282dfb117432332416b60bc4e4d2dad9153 Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko@suse.com>
Date: Tue, 21 Jul 2015 10:06:13 +0200
Subject: [PATCH] mm, fs: Obey gfp_mapping for add_to_page_cache
6afdb859b710 ("mm: do not ignore mapping_gfp_mask in page cache
allocation paths) has caught some users of hardcoded GFP_KERNEL
used in the page cache allocation paths. This, however, wasn't complete
and there were others which went unnoticed.
Dave Chinner has reported the following deadlock for xfs on loop device:
: With the recent merge of the loop device changes, I'm now seeing
: XFS deadlock on my single CPU, 1GB RAM VM running xfs/073.
:
: The deadlocked is as follows:
:
: kloopd1: loop_queue_read_work
: xfs_file_iter_read
: lock XFS inode XFS_IOLOCK_SHARED (on image file)
: page cache read (GFP_KERNEL)
: radix tree alloc
: memory reclaim
: reclaim XFS inodes
: log force to unpin inodes
: <wait for log IO completion>
:
: xfs-cil/loop1: <does log force IO work>
: xlog_cil_push
: xlog_write
: <loop issuing log writes>
: xlog_state_get_iclog_space()
: <blocks due to all log buffers under write io>
: <waits for IO completion>
:
: kloopd1: loop_queue_write_work
: xfs_file_write_iter
: lock XFS inode XFS_IOLOCK_EXCL (on image file)
: <wait for inode to be unlocked>
:
: i.e. the kloopd, with it's split read and write work queues, has
: introduced a dependency through memory reclaim. i.e. that writes
: need to be able to progress for reads make progress.
:
: The problem, fundamentally, is that mpage_readpages() does a
: GFP_KERNEL allocation, rather than paying attention to the inode's
: mapping gfp mask, which is set to GFP_NOFS.
:
: The didn't used to happen, because the loop device used to issue
: reads through the splice path and that does:
:
: error = add_to_page_cache_lru(page, mapping, index,
: GFP_KERNEL & mapping_gfp_mask(mapping));
This has changed by aa4d86163e4 (block: loop: switch to VFS ITER_BVEC).
This patch changes mpage_readpage{s} to follow gfp mask set for the
mapping. There are, however, other places which are doing basically the
same.
lustre:ll_dir_filler is doing GFP_KERNEL from the function which
apparently uses GFP_NOFS for other allocations so let's make this
consistent.
cifs:readpages_get_pages is called from cifs_readpages and
__cifs_readpages_from_fscache called from the same path obeys mapping
gfp.
ramfs_nommu_expand_for_mapping is hardcoding GFP_KERNEL as well
regardless it uses mapping_gfp_mask for the page allocation.
ext4_mpage_readpages is the called from the page cache allocation path
same as read_pages and read_cache_pages
Reported-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
drivers/staging/lustre/lustre/llite/dir.c | 2 +-
fs/cifs/file.c | 5 +++--
fs/ext4/readpage.c | 3 ++-
fs/mpage.c | 14 +++++++++-----
fs/ramfs/file-nommu.c | 5 +++--
mm/readahead.c | 6 ++++--
6 files changed, 22 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/dir.c b/drivers/staging/lustre/lustre/llite/dir.c
index a5bc694dcb64..0a643b8b6deb 100644
--- a/drivers/staging/lustre/lustre/llite/dir.c
+++ b/drivers/staging/lustre/lustre/llite/dir.c
@@ -225,7 +225,7 @@ static int ll_dir_filler(void *_hash, struct page *page0)
prefetchw(&page->flags);
ret = add_to_page_cache_lru(page, inode->i_mapping, offset,
- GFP_KERNEL);
+ GFP_NOFS);
if (ret == 0) {
unlock_page(page);
if (ll_pagevec_add(&lru_pvec, page) == 0)
diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index 2ac2d8471393..72c162a1d56d 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -3380,6 +3380,7 @@ readpages_get_pages(struct address_space *mapping, struct list_head *page_list,
struct page *page, *tpage;
unsigned int expected_index;
int rc;
+ gfp_t gfp = GFP_KERNEL & mapping_gfp_mask(mapping);
INIT_LIST_HEAD(tmplist);
@@ -3392,7 +3393,7 @@ readpages_get_pages(struct address_space *mapping, struct list_head *page_list,
*/
__SetPageLocked(page);
rc = add_to_page_cache_locked(page, mapping,
- page->index, GFP_KERNEL);
+ page->index, gfp);
/* give up if we can't stick it in the cache */
if (rc) {
@@ -3419,7 +3420,7 @@ readpages_get_pages(struct address_space *mapping, struct list_head *page_list,
__SetPageLocked(page);
if (add_to_page_cache_locked(page, mapping, page->index,
- GFP_KERNEL)) {
+ gfp)) {
__ClearPageLocked(page);
break;
}
diff --git a/fs/ext4/readpage.c b/fs/ext4/readpage.c
index 171b9ac4b45e..92eb970655bd 100644
--- a/fs/ext4/readpage.c
+++ b/fs/ext4/readpage.c
@@ -166,7 +166,8 @@ int ext4_mpage_readpages(struct address_space *mapping,
page = list_entry(pages->prev, struct page, lru);
list_del(&page->lru);
if (add_to_page_cache_lru(page, mapping,
- page->index, GFP_KERNEL))
+ page->index,
+ GFP_KERNEL & mapping_gfp_mask(mapping)))
goto next_page;
}
diff --git a/fs/mpage.c b/fs/mpage.c
index dde689d0759d..4a54bd13c9bd 100644
--- a/fs/mpage.c
+++ b/fs/mpage.c
@@ -139,7 +139,8 @@ map_buffer_to_page(struct page *page, struct buffer_head *bh, int page_block)
static struct bio *
do_mpage_readpage(struct bio *bio, struct page *page, unsigned nr_pages,
sector_t *last_block_in_bio, struct buffer_head *map_bh,
- unsigned long *first_logical_block, get_block_t get_block)
+ unsigned long *first_logical_block, get_block_t get_block,
+ gfp_t gfp)
{
struct inode *inode = page->mapping->host;
const unsigned blkbits = inode->i_blkbits;
@@ -278,7 +279,7 @@ do_mpage_readpage(struct bio *bio, struct page *page, unsigned nr_pages,
}
bio = mpage_alloc(bdev, blocks[0] << (blkbits - 9),
min_t(int, nr_pages, bio_get_nr_vecs(bdev)),
- GFP_KERNEL);
+ gfp);
if (bio == NULL)
goto confused;
}
@@ -361,6 +362,7 @@ mpage_readpages(struct address_space *mapping, struct list_head *pages,
sector_t last_block_in_bio = 0;
struct buffer_head map_bh;
unsigned long first_logical_block = 0;
+ gfp_t gfp = GFP_KERNEL & mapping_gfp_mask(mapping);
map_bh.b_state = 0;
map_bh.b_size = 0;
@@ -370,12 +372,13 @@ mpage_readpages(struct address_space *mapping, struct list_head *pages,
prefetchw(&page->flags);
list_del(&page->lru);
if (!add_to_page_cache_lru(page, mapping,
- page->index, GFP_KERNEL)) {
+ page->index,
+ gfp)) {
bio = do_mpage_readpage(bio, page,
nr_pages - page_idx,
&last_block_in_bio, &map_bh,
&first_logical_block,
- get_block);
+ get_block, gfp);
}
page_cache_release(page);
}
@@ -395,11 +398,12 @@ int mpage_readpage(struct page *page, get_block_t get_block)
sector_t last_block_in_bio = 0;
struct buffer_head map_bh;
unsigned long first_logical_block = 0;
+ gfp_t gfp = mapping_gfp_mask(page->mapping);
map_bh.b_state = 0;
map_bh.b_size = 0;
bio = do_mpage_readpage(bio, page, 1, &last_block_in_bio,
- &map_bh, &first_logical_block, get_block);
+ &map_bh, &first_logical_block, get_block, gfp);
if (bio)
mpage_bio_submit(READ, bio);
return 0;
diff --git a/fs/ramfs/file-nommu.c b/fs/ramfs/file-nommu.c
index ba1323a94924..a586467f6ff6 100644
--- a/fs/ramfs/file-nommu.c
+++ b/fs/ramfs/file-nommu.c
@@ -70,6 +70,7 @@ int ramfs_nommu_expand_for_mapping(struct inode *inode, size_t newsize)
unsigned order;
void *data;
int ret;
+ gfp_t gfp = mapping_gfp_mask(inode->i_mapping);
/* make various checks */
order = get_order(newsize);
@@ -84,7 +85,7 @@ int ramfs_nommu_expand_for_mapping(struct inode *inode, size_t newsize)
/* allocate enough contiguous pages to be able to satisfy the
* request */
- pages = alloc_pages(mapping_gfp_mask(inode->i_mapping), order);
+ pages = alloc_pages(gfp, order);
if (!pages)
return -ENOMEM;
@@ -108,7 +109,7 @@ int ramfs_nommu_expand_for_mapping(struct inode *inode, size_t newsize)
struct page *page = pages + loop;
ret = add_to_page_cache_lru(page, inode->i_mapping, loop,
- GFP_KERNEL);
+ gfp);
if (ret < 0)
goto add_error;
diff --git a/mm/readahead.c b/mm/readahead.c
index 60cd846a9a44..b9b99597dc77 100644
--- a/mm/readahead.c
+++ b/mm/readahead.c
@@ -90,7 +90,8 @@ int read_cache_pages(struct address_space *mapping, struct list_head *pages,
page = list_to_page(pages);
list_del(&page->lru);
if (add_to_page_cache_lru(page, mapping,
- page->index, GFP_KERNEL)) {
+ page->index,
+ GFP_KERNEL & mapping_gfp_mask(mapping))) {
read_cache_pages_invalidate_page(mapping, page);
continue;
}
@@ -128,7 +129,8 @@ static int read_pages(struct address_space *mapping, struct file *filp,
struct page *page = list_to_page(pages);
list_del(&page->lru);
if (!add_to_page_cache_lru(page, mapping,
- page->index, GFP_KERNEL)) {
+ page->index,
+ GFP_KERNEL & mapping_gfp_mask(mapping))) {
mapping->a_ops->readpage(filp, page);
}
page_cache_release(page);
--
2.1.4
--
Michal Hocko
SUSE Labs
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [regression 4.2-rc3] loop: xfstests xfs/073 deadlocked in low memory conditions
@ 2015-07-21 8:58 ` Michal Hocko
0 siblings, 0 replies; 20+ messages in thread
From: Michal Hocko @ 2015-07-21 8:58 UTC (permalink / raw)
To: Dave Chinner
Cc: Ming Lei, Andrew Morton, Theodore Ts'o, Andreas Dilger,
Oleg Drokin, Alexander Viro, Christoph Hellwig, linux-kernel,
linux-mm, xfs, linux-nfs, linux-cifs
[CCing more people from a potentially affected fs - the reference to the
email thread is: http://marc.info/?l=linux-mm&m=143744398020147&w=2]
On Tue 21-07-15 11:59:34, Dave Chinner wrote:
> Hi Ming,
>
> With the recent merge of the loop device changes, I'm now seeing
> XFS deadlock on my single CPU, 1GB RAM VM running xfs/073.
>
> The deadlocked is as follows:
>
> kloopd1: loop_queue_read_work
> xfs_file_iter_read
> lock XFS inode XFS_IOLOCK_SHARED (on image file)
> page cache read (GFP_KERNEL)
> radix tree alloc
> memory reclaim
> reclaim XFS inodes
> log force to unpin inodes
> <wait for log IO completion>
>
> xfs-cil/loop1: <does log force IO work>
> xlog_cil_push
> xlog_write
> <loop issuing log writes>
> xlog_state_get_iclog_space()
> <blocks due to all log buffers under write io>
> <waits for IO completion>
>
> kloopd1: loop_queue_write_work
> xfs_file_write_iter
> lock XFS inode XFS_IOLOCK_EXCL (on image file)
> <wait for inode to be unlocked>
>
> [The full stack traces are below].
>
> i.e. the kloopd, with it's split read and write work queues, has
> introduced a dependency through memory reclaim. i.e. that writes
> need to be able to progress for reads make progress.
>
> The problem, fundamentally, is that mpage_readpages() does a
> GFP_KERNEL allocation, rather than paying attention to the inode's
> mapping gfp mask, which is set to GFP_NOFS.
>
> The didn't used to happen, because the loop device used to issue
> reads through the splice path and that does:
>
> error = add_to_page_cache_lru(page, mapping, index,
> GFP_KERNEL & mapping_gfp_mask(mapping));
>
> i.e. it pays attention to the allocation context placed on the
> inode and so is doing GFP_NOFS allocations here and avoiding the
> recursion problem.
>
> [ CC'd Michal Hocko and the mm list because it's a clear exaple of
> why ignoring the mapping gfp mask on any page cache allocation is
> a landmine waiting to be tripped over. ]
Thank you for CCing me. I haven't noticed this one when checking for
other similar hardcoded GFP_KERNEL users (6afdb859b710 ("mm: do not
ignore mapping_gfp_mask in page cache allocation paths")). And there
seem to be more of them now that I am looking closer.
I am not sure what to do about fs/nfs/dir.c:nfs_symlink which doesn't
require GFP_NOFS or mapping gfp mask for other allocations in the same
context.
What do you think about this preliminary (and untested) patch? I cannot
say I would be happy about sprinkling mapping_gfp_mask all over the place
and it sounds like we should drop gfp_mask argument altogether and
use it internally in __add_to_page_cache_locked that would require all
the filesystems to use mapping gfp consistently which I am not sure is
the case here. From a quick glance it seems that some file system use
it all the time while others are selective.
---
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [regression 4.2-rc3] loop: xfstests xfs/073 deadlocked in low memory conditions
2015-07-21 8:58 ` Michal Hocko
(?)
@ 2015-07-29 11:54 ` Michal Hocko
-1 siblings, 0 replies; 20+ messages in thread
From: Michal Hocko @ 2015-07-29 11:54 UTC (permalink / raw)
To: Dave Chinner
Cc: Ming Lei, Andrew Morton, Theodore Ts'o, Andreas Dilger,
Oleg Drokin, Alexander Viro, Christoph Hellwig, linux-kernel,
linux-mm, xfs, linux-nfs, linux-cifs
On Tue 21-07-15 10:58:59, Michal Hocko wrote:
> [CCing more people from a potentially affected fs - the reference to the
> email thread is: http://marc.info/?l=linux-mm&m=143744398020147&w=2]
>
> On Tue 21-07-15 11:59:34, Dave Chinner wrote:
> > Hi Ming,
> >
> > With the recent merge of the loop device changes, I'm now seeing
> > XFS deadlock on my single CPU, 1GB RAM VM running xfs/073.
> >
> > The deadlocked is as follows:
> >
> > kloopd1: loop_queue_read_work
> > xfs_file_iter_read
> > lock XFS inode XFS_IOLOCK_SHARED (on image file)
> > page cache read (GFP_KERNEL)
> > radix tree alloc
> > memory reclaim
> > reclaim XFS inodes
> > log force to unpin inodes
> > <wait for log IO completion>
> >
> > xfs-cil/loop1: <does log force IO work>
> > xlog_cil_push
> > xlog_write
> > <loop issuing log writes>
> > xlog_state_get_iclog_space()
> > <blocks due to all log buffers under write io>
> > <waits for IO completion>
> >
> > kloopd1: loop_queue_write_work
> > xfs_file_write_iter
> > lock XFS inode XFS_IOLOCK_EXCL (on image file)
> > <wait for inode to be unlocked>
> >
> > [The full stack traces are below].
> >
> > i.e. the kloopd, with it's split read and write work queues, has
> > introduced a dependency through memory reclaim. i.e. that writes
> > need to be able to progress for reads make progress.
> >
> > The problem, fundamentally, is that mpage_readpages() does a
> > GFP_KERNEL allocation, rather than paying attention to the inode's
> > mapping gfp mask, which is set to GFP_NOFS.
> >
> > The didn't used to happen, because the loop device used to issue
> > reads through the splice path and that does:
> >
> > error = add_to_page_cache_lru(page, mapping, index,
> > GFP_KERNEL & mapping_gfp_mask(mapping));
> >
> > i.e. it pays attention to the allocation context placed on the
> > inode and so is doing GFP_NOFS allocations here and avoiding the
> > recursion problem.
> >
> > [ CC'd Michal Hocko and the mm list because it's a clear exaple of
> > why ignoring the mapping gfp mask on any page cache allocation is
> > a landmine waiting to be tripped over. ]
>
> Thank you for CCing me. I haven't noticed this one when checking for
> other similar hardcoded GFP_KERNEL users (6afdb859b710 ("mm: do not
> ignore mapping_gfp_mask in page cache allocation paths")). And there
> seem to be more of them now that I am looking closer.
>
> I am not sure what to do about fs/nfs/dir.c:nfs_symlink which doesn't
> require GFP_NOFS or mapping gfp mask for other allocations in the same
> context.
>
> What do you think about this preliminary (and untested) patch?
Dave, did you have chance to test the patch in your environment? Is the
patch good to go or we want a larger refactoring?
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [regression 4.2-rc3] loop: xfstests xfs/073 deadlocked in low memory conditions
@ 2015-07-29 11:54 ` Michal Hocko
0 siblings, 0 replies; 20+ messages in thread
From: Michal Hocko @ 2015-07-29 11:54 UTC (permalink / raw)
To: Dave Chinner
Cc: Ming Lei, Andrew Morton, Theodore Ts'o, Andreas Dilger,
Oleg Drokin, Alexander Viro, Christoph Hellwig, linux-kernel,
linux-mm, xfs, linux-nfs, linux-cifs
On Tue 21-07-15 10:58:59, Michal Hocko wrote:
> [CCing more people from a potentially affected fs - the reference to the
> email thread is: http://marc.info/?l=linux-mm&m=143744398020147&w=2]
>
> On Tue 21-07-15 11:59:34, Dave Chinner wrote:
> > Hi Ming,
> >
> > With the recent merge of the loop device changes, I'm now seeing
> > XFS deadlock on my single CPU, 1GB RAM VM running xfs/073.
> >
> > The deadlocked is as follows:
> >
> > kloopd1: loop_queue_read_work
> > xfs_file_iter_read
> > lock XFS inode XFS_IOLOCK_SHARED (on image file)
> > page cache read (GFP_KERNEL)
> > radix tree alloc
> > memory reclaim
> > reclaim XFS inodes
> > log force to unpin inodes
> > <wait for log IO completion>
> >
> > xfs-cil/loop1: <does log force IO work>
> > xlog_cil_push
> > xlog_write
> > <loop issuing log writes>
> > xlog_state_get_iclog_space()
> > <blocks due to all log buffers under write io>
> > <waits for IO completion>
> >
> > kloopd1: loop_queue_write_work
> > xfs_file_write_iter
> > lock XFS inode XFS_IOLOCK_EXCL (on image file)
> > <wait for inode to be unlocked>
> >
> > [The full stack traces are below].
> >
> > i.e. the kloopd, with it's split read and write work queues, has
> > introduced a dependency through memory reclaim. i.e. that writes
> > need to be able to progress for reads make progress.
> >
> > The problem, fundamentally, is that mpage_readpages() does a
> > GFP_KERNEL allocation, rather than paying attention to the inode's
> > mapping gfp mask, which is set to GFP_NOFS.
> >
> > The didn't used to happen, because the loop device used to issue
> > reads through the splice path and that does:
> >
> > error = add_to_page_cache_lru(page, mapping, index,
> > GFP_KERNEL & mapping_gfp_mask(mapping));
> >
> > i.e. it pays attention to the allocation context placed on the
> > inode and so is doing GFP_NOFS allocations here and avoiding the
> > recursion problem.
> >
> > [ CC'd Michal Hocko and the mm list because it's a clear exaple of
> > why ignoring the mapping gfp mask on any page cache allocation is
> > a landmine waiting to be tripped over. ]
>
> Thank you for CCing me. I haven't noticed this one when checking for
> other similar hardcoded GFP_KERNEL users (6afdb859b710 ("mm: do not
> ignore mapping_gfp_mask in page cache allocation paths")). And there
> seem to be more of them now that I am looking closer.
>
> I am not sure what to do about fs/nfs/dir.c:nfs_symlink which doesn't
> require GFP_NOFS or mapping gfp mask for other allocations in the same
> context.
>
> What do you think about this preliminary (and untested) patch?
Dave, did you have chance to test the patch in your environment? Is the
patch good to go or we want a larger refactoring?
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [regression 4.2-rc3] loop: xfstests xfs/073 deadlocked in low memory conditions
@ 2015-07-29 11:54 ` Michal Hocko
0 siblings, 0 replies; 20+ messages in thread
From: Michal Hocko @ 2015-07-29 11:54 UTC (permalink / raw)
To: Dave Chinner
Cc: linux-cifs, linux-nfs, Andreas Dilger, Ming Lei, linux-kernel,
xfs, Oleg Drokin, linux-mm, Alexander Viro, Theodore Ts'o,
Andrew Morton, Christoph Hellwig
On Tue 21-07-15 10:58:59, Michal Hocko wrote:
> [CCing more people from a potentially affected fs - the reference to the
> email thread is: http://marc.info/?l=linux-mm&m=143744398020147&w=2]
>
> On Tue 21-07-15 11:59:34, Dave Chinner wrote:
> > Hi Ming,
> >
> > With the recent merge of the loop device changes, I'm now seeing
> > XFS deadlock on my single CPU, 1GB RAM VM running xfs/073.
> >
> > The deadlocked is as follows:
> >
> > kloopd1: loop_queue_read_work
> > xfs_file_iter_read
> > lock XFS inode XFS_IOLOCK_SHARED (on image file)
> > page cache read (GFP_KERNEL)
> > radix tree alloc
> > memory reclaim
> > reclaim XFS inodes
> > log force to unpin inodes
> > <wait for log IO completion>
> >
> > xfs-cil/loop1: <does log force IO work>
> > xlog_cil_push
> > xlog_write
> > <loop issuing log writes>
> > xlog_state_get_iclog_space()
> > <blocks due to all log buffers under write io>
> > <waits for IO completion>
> >
> > kloopd1: loop_queue_write_work
> > xfs_file_write_iter
> > lock XFS inode XFS_IOLOCK_EXCL (on image file)
> > <wait for inode to be unlocked>
> >
> > [The full stack traces are below].
> >
> > i.e. the kloopd, with it's split read and write work queues, has
> > introduced a dependency through memory reclaim. i.e. that writes
> > need to be able to progress for reads make progress.
> >
> > The problem, fundamentally, is that mpage_readpages() does a
> > GFP_KERNEL allocation, rather than paying attention to the inode's
> > mapping gfp mask, which is set to GFP_NOFS.
> >
> > The didn't used to happen, because the loop device used to issue
> > reads through the splice path and that does:
> >
> > error = add_to_page_cache_lru(page, mapping, index,
> > GFP_KERNEL & mapping_gfp_mask(mapping));
> >
> > i.e. it pays attention to the allocation context placed on the
> > inode and so is doing GFP_NOFS allocations here and avoiding the
> > recursion problem.
> >
> > [ CC'd Michal Hocko and the mm list because it's a clear exaple of
> > why ignoring the mapping gfp mask on any page cache allocation is
> > a landmine waiting to be tripped over. ]
>
> Thank you for CCing me. I haven't noticed this one when checking for
> other similar hardcoded GFP_KERNEL users (6afdb859b710 ("mm: do not
> ignore mapping_gfp_mask in page cache allocation paths")). And there
> seem to be more of them now that I am looking closer.
>
> I am not sure what to do about fs/nfs/dir.c:nfs_symlink which doesn't
> require GFP_NOFS or mapping gfp mask for other allocations in the same
> context.
>
> What do you think about this preliminary (and untested) patch?
Dave, did you have chance to test the patch in your environment? Is the
patch good to go or we want a larger refactoring?
--
Michal Hocko
SUSE Labs
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [regression 4.2-rc3] loop: xfstests xfs/073 deadlocked in low memory conditions
2015-07-29 11:54 ` Michal Hocko
(?)
(?)
@ 2015-07-29 22:13 ` Dave Chinner
-1 siblings, 0 replies; 20+ messages in thread
From: Dave Chinner @ 2015-07-29 22:13 UTC (permalink / raw)
To: Michal Hocko
Cc: Ming Lei, Andrew Morton, Theodore Ts'o, Andreas Dilger,
Oleg Drokin, Alexander Viro, Christoph Hellwig,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg, xfs-VZNHf3L845pBDgjK7y7TUQ,
linux-nfs-u79uwXL29TY76Z2rM5mHXA,
linux-cifs-u79uwXL29TY76Z2rM5mHXA
On Wed, Jul 29, 2015 at 01:54:12PM +0200, Michal Hocko wrote:
> On Tue 21-07-15 10:58:59, Michal Hocko wrote:
> > [CCing more people from a potentially affected fs - the reference to the
> > email thread is: http://marc.info/?l=linux-mm&m=143744398020147&w=2]
...
> > > The didn't used to happen, because the loop device used to issue
> > > reads through the splice path and that does:
> > >
> > > error = add_to_page_cache_lru(page, mapping, index,
> > > GFP_KERNEL & mapping_gfp_mask(mapping));
> > >
> > > i.e. it pays attention to the allocation context placed on the
> > > inode and so is doing GFP_NOFS allocations here and avoiding the
> > > recursion problem.
> > >
> > > [ CC'd Michal Hocko and the mm list because it's a clear exaple of
> > > why ignoring the mapping gfp mask on any page cache allocation is
> > > a landmine waiting to be tripped over. ]
> >
> > Thank you for CCing me. I haven't noticed this one when checking for
> > other similar hardcoded GFP_KERNEL users (6afdb859b710 ("mm: do not
> > ignore mapping_gfp_mask in page cache allocation paths")). And there
> > seem to be more of them now that I am looking closer.
> >
> > I am not sure what to do about fs/nfs/dir.c:nfs_symlink which doesn't
> > require GFP_NOFS or mapping gfp mask for other allocations in the same
> > context.
> >
> > What do you think about this preliminary (and untested) patch?
>
> Dave, did you have chance to test the patch in your environment? Is the
> patch good to go or we want a larger refactoring?
No, I haven't had a chance to test it yet. I'll try to get somethign
done by the end of the week, but I'm not able to reliably
reproduce the hang I saw (i.e. the analysis I did was from the first
deadlock and I've only seen it once since) so testing is likely to
be inconclusive, anyway....
Cheers,
Dave.
--
Dave Chinner
david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [regression 4.2-rc3] loop: xfstests xfs/073 deadlocked in low memory conditions
@ 2015-07-29 22:13 ` Dave Chinner
0 siblings, 0 replies; 20+ messages in thread
From: Dave Chinner @ 2015-07-29 22:13 UTC (permalink / raw)
To: Michal Hocko
Cc: Ming Lei, Andrew Morton, Theodore Ts'o, Andreas Dilger,
Oleg Drokin, Alexander Viro, Christoph Hellwig, linux-kernel,
linux-mm, xfs, linux-nfs, linux-cifs
On Wed, Jul 29, 2015 at 01:54:12PM +0200, Michal Hocko wrote:
> On Tue 21-07-15 10:58:59, Michal Hocko wrote:
> > [CCing more people from a potentially affected fs - the reference to the
> > email thread is: http://marc.info/?l=linux-mm&m=143744398020147&w=2]
...
> > > The didn't used to happen, because the loop device used to issue
> > > reads through the splice path and that does:
> > >
> > > error = add_to_page_cache_lru(page, mapping, index,
> > > GFP_KERNEL & mapping_gfp_mask(mapping));
> > >
> > > i.e. it pays attention to the allocation context placed on the
> > > inode and so is doing GFP_NOFS allocations here and avoiding the
> > > recursion problem.
> > >
> > > [ CC'd Michal Hocko and the mm list because it's a clear exaple of
> > > why ignoring the mapping gfp mask on any page cache allocation is
> > > a landmine waiting to be tripped over. ]
> >
> > Thank you for CCing me. I haven't noticed this one when checking for
> > other similar hardcoded GFP_KERNEL users (6afdb859b710 ("mm: do not
> > ignore mapping_gfp_mask in page cache allocation paths")). And there
> > seem to be more of them now that I am looking closer.
> >
> > I am not sure what to do about fs/nfs/dir.c:nfs_symlink which doesn't
> > require GFP_NOFS or mapping gfp mask for other allocations in the same
> > context.
> >
> > What do you think about this preliminary (and untested) patch?
>
> Dave, did you have chance to test the patch in your environment? Is the
> patch good to go or we want a larger refactoring?
No, I haven't had a chance to test it yet. I'll try to get somethign
done by the end of the week, but I'm not able to reliably
reproduce the hang I saw (i.e. the analysis I did was from the first
deadlock and I've only seen it once since) so testing is likely to
be inconclusive, anyway....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [regression 4.2-rc3] loop: xfstests xfs/073 deadlocked in low memory conditions
@ 2015-07-29 22:13 ` Dave Chinner
0 siblings, 0 replies; 20+ messages in thread
From: Dave Chinner @ 2015-07-29 22:13 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-cifs, linux-nfs, Andreas Dilger, Ming Lei, linux-kernel,
xfs, Oleg Drokin, linux-mm, Alexander Viro, Theodore Ts'o,
Andrew Morton, Christoph Hellwig
On Wed, Jul 29, 2015 at 01:54:12PM +0200, Michal Hocko wrote:
> On Tue 21-07-15 10:58:59, Michal Hocko wrote:
> > [CCing more people from a potentially affected fs - the reference to the
> > email thread is: http://marc.info/?l=linux-mm&m=143744398020147&w=2]
...
> > > The didn't used to happen, because the loop device used to issue
> > > reads through the splice path and that does:
> > >
> > > error = add_to_page_cache_lru(page, mapping, index,
> > > GFP_KERNEL & mapping_gfp_mask(mapping));
> > >
> > > i.e. it pays attention to the allocation context placed on the
> > > inode and so is doing GFP_NOFS allocations here and avoiding the
> > > recursion problem.
> > >
> > > [ CC'd Michal Hocko and the mm list because it's a clear exaple of
> > > why ignoring the mapping gfp mask on any page cache allocation is
> > > a landmine waiting to be tripped over. ]
> >
> > Thank you for CCing me. I haven't noticed this one when checking for
> > other similar hardcoded GFP_KERNEL users (6afdb859b710 ("mm: do not
> > ignore mapping_gfp_mask in page cache allocation paths")). And there
> > seem to be more of them now that I am looking closer.
> >
> > I am not sure what to do about fs/nfs/dir.c:nfs_symlink which doesn't
> > require GFP_NOFS or mapping gfp mask for other allocations in the same
> > context.
> >
> > What do you think about this preliminary (and untested) patch?
>
> Dave, did you have chance to test the patch in your environment? Is the
> patch good to go or we want a larger refactoring?
No, I haven't had a chance to test it yet. I'll try to get somethign
done by the end of the week, but I'm not able to reliably
reproduce the hang I saw (i.e. the analysis I did was from the first
deadlock and I've only seen it once since) so testing is likely to
be inconclusive, anyway....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [regression 4.2-rc3] loop: xfstests xfs/073 deadlocked in low memory conditions
@ 2015-07-29 22:13 ` Dave Chinner
0 siblings, 0 replies; 20+ messages in thread
From: Dave Chinner @ 2015-07-29 22:13 UTC (permalink / raw)
To: Michal Hocko
Cc: Ming Lei, Andrew Morton, Theodore Ts'o, Andreas Dilger,
Oleg Drokin, Alexander Viro, Christoph Hellwig, linux-kernel,
linux-mm, xfs, linux-nfs, linux-cifs
On Wed, Jul 29, 2015 at 01:54:12PM +0200, Michal Hocko wrote:
> On Tue 21-07-15 10:58:59, Michal Hocko wrote:
> > [CCing more people from a potentially affected fs - the reference to the
> > email thread is: http://marc.info/?l=linux-mm&m=143744398020147&w=2]
...
> > > The didn't used to happen, because the loop device used to issue
> > > reads through the splice path and that does:
> > >
> > > error = add_to_page_cache_lru(page, mapping, index,
> > > GFP_KERNEL & mapping_gfp_mask(mapping));
> > >
> > > i.e. it pays attention to the allocation context placed on the
> > > inode and so is doing GFP_NOFS allocations here and avoiding the
> > > recursion problem.
> > >
> > > [ CC'd Michal Hocko and the mm list because it's a clear exaple of
> > > why ignoring the mapping gfp mask on any page cache allocation is
> > > a landmine waiting to be tripped over. ]
> >
> > Thank you for CCing me. I haven't noticed this one when checking for
> > other similar hardcoded GFP_KERNEL users (6afdb859b710 ("mm: do not
> > ignore mapping_gfp_mask in page cache allocation paths")). And there
> > seem to be more of them now that I am looking closer.
> >
> > I am not sure what to do about fs/nfs/dir.c:nfs_symlink which doesn't
> > require GFP_NOFS or mapping gfp mask for other allocations in the same
> > context.
> >
> > What do you think about this preliminary (and untested) patch?
>
> Dave, did you have chance to test the patch in your environment? Is the
> patch good to go or we want a larger refactoring?
No, I haven't had a chance to test it yet. I'll try to get somethign
done by the end of the week, but I'm not able to reliably
reproduce the hang I saw (i.e. the analysis I did was from the first
deadlock and I've only seen it once since) so testing is likely to
be inconclusive, anyway....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2015-07-29 22:14 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-21 1:59 [regression 4.2-rc3] loop: xfstests xfs/073 deadlocked in low memory conditions Dave Chinner
2015-07-21 1:59 ` Dave Chinner
2015-07-21 1:59 ` Dave Chinner
2015-07-21 4:05 ` Ming Lei
2015-07-21 4:05 ` Ming Lei
2015-07-21 4:05 ` Ming Lei
2015-07-21 5:46 ` Dave Chinner
2015-07-21 5:46 ` Dave Chinner
2015-07-21 5:46 ` Dave Chinner
2015-07-21 8:58 ` Michal Hocko
2015-07-21 8:58 ` Michal Hocko
2015-07-21 8:58 ` Michal Hocko
2015-07-21 8:58 ` Michal Hocko
2015-07-29 11:54 ` Michal Hocko
2015-07-29 11:54 ` Michal Hocko
2015-07-29 11:54 ` Michal Hocko
[not found] ` <20150729115411.GF15801-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2015-07-29 22:13 ` Dave Chinner
2015-07-29 22:13 ` Dave Chinner
2015-07-29 22:13 ` Dave Chinner
2015-07-29 22:13 ` Dave Chinner
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.