* 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-11 17:27 ` Dave Jones
0 siblings, 0 replies; 132+ messages in thread
From: Dave Jones @ 2014-02-11 17:27 UTC (permalink / raw)
To: Linux Kernel; +Cc: xfs
BUG: sleeping function called from invalid context at mm/mempool.c:203
in_atomic(): 0, irqs_disabled(): 1, pid: 27511, name: trinity-c3
5 locks held by trinity-c3/27511:
#0: (sb_writers#9){......}, at: [<ffffffff831df3b4>] mnt_want_write+0x24/0x50
#1: (&type->i_mutex_dir_key#3){......}, at: [<ffffffff831cced4>] do_last.isra.51+0x294/0x11f0
#2: (sb_internal#2){......}, at: [<ffffffffc03225c4>] xfs_trans_alloc+0x24/0x40 [xfs]
#3: (&(&ip->i_lock)->mr_lock/1){......}, at: [<ffffffffc036447f>] xfs_ilock+0x16f/0x1b0 [xfs]
#4: (&(&ip->i_lock)->mr_lock){......}, at: [<ffffffffc03646d4>] xfs_ilock_nowait+0x184/0x200 [xfs]
CPU: 3 PID: 27511 Comm: trinity-c3 Not tainted 3.14.0-rc2+ #111
ffffffff83a3fd56 0000000045a3849a ffff88009f368f60 ffffffff8372afea
0000000000000000 ffff88009f368f88 ffffffff8309ddb5 0000000000000010
ffff880243566288 0000000000000008 ffff88009f369008 ffffffff831534d3
Call Trace:
[<ffffffff8372afea>] dump_stack+0x4e/0x7a
[<ffffffff8309ddb5>] __might_sleep+0x105/0x150
[<ffffffff831534d3>] mempool_alloc+0xa3/0x170
[<ffffffff831a955a>] ? deactivate_slab+0x51a/0x590
[<ffffffff831f8fd6>] bio_alloc_bioset+0x156/0x210
[<ffffffffc0308231>] _xfs_buf_ioapply+0x1c1/0x3c0 [xfs]
[<ffffffffc03798f2>] ? xlog_bdstrat+0x22/0x60 [xfs]
[<ffffffffc030849b>] xfs_buf_iorequest+0x6b/0xf0 [xfs]
[<ffffffffc03798f2>] xlog_bdstrat+0x22/0x60 [xfs]
[<ffffffffc037ba87>] xlog_sync+0x3a7/0x5b0 [xfs]
[<ffffffffc037bd9f>] xlog_state_release_iclog+0x10f/0x120 [xfs]
[<ffffffffc037c840>] xlog_write+0x6f0/0x800 [xfs]
[<ffffffffc037e061>] xlog_cil_push+0x2f1/0x410 [xfs]
[<ffffffffc037e948>] xlog_cil_force_lsn+0x1d8/0x210 [xfs]
[<ffffffffc03428a8>] ? xfs_bmbt_get_all+0x18/0x20 [xfs]
[<ffffffffc037cc40>] _xfs_log_force+0x70/0x290 [xfs]
[<ffffffff830a4edd>] ? get_parent_ip+0xd/0x50
[<ffffffffc037ce86>] xfs_log_force+0x26/0xb0 [xfs]
[<ffffffffc03076e6>] ? _xfs_buf_find+0x1f6/0x3c0 [xfs]
[<ffffffffc03074e3>] xfs_buf_lock+0x133/0x140 [xfs]
[<ffffffffc03076e6>] _xfs_buf_find+0x1f6/0x3c0 [xfs]
[<ffffffffc030796a>] xfs_buf_get_map+0x2a/0x1b0 [xfs]
[<ffffffffc0383c61>] xfs_trans_get_buf_map+0x1a1/0x240 [xfs]
[<ffffffffc034e03d>] xfs_da_get_buf+0xbd/0x100 [xfs]
[<ffffffffc0356869>] xfs_dir3_data_init+0x59/0x1d0 [xfs]
[<ffffffffc03526db>] ? xfs_dir2_grow_inode+0x13b/0x150 [xfs]
[<ffffffffc0354ede>] xfs_dir2_sf_to_block+0x17e/0x7b0 [xfs]
[<ffffffffc0351f5a>] ? xfs_dir2_sfe_get_ino+0x1a/0x20 [xfs]
[<ffffffffc035e9b4>] ? xfs_dir2_sf_check.isra.7+0x114/0x1b0 [xfs]
[<ffffffffc034c24f>] ? xfs_da_compname+0x1f/0x30 [xfs]
[<ffffffffc035f503>] ? xfs_dir2_sf_lookup+0x303/0x310 [xfs]
[<ffffffffc035f858>] xfs_dir2_sf_addname+0x348/0x6d0 [xfs]
[<ffffffffc031970d>] ? xfs_setup_inode+0x1cd/0x320 [xfs]
[<ffffffffc03529a4>] xfs_dir_createname+0x184/0x1e0 [xfs]
[<ffffffffc03663d9>] xfs_create+0x469/0x580 [xfs]
[<ffffffffc0318864>] xfs_vn_mknod+0xc4/0x1e0 [xfs]
[<ffffffffc0318993>] xfs_vn_create+0x13/0x20 [xfs]
[<ffffffff831ccc15>] vfs_create+0x95/0xc0
[<ffffffff831cd638>] do_last.isra.51+0x9f8/0x11f0
[<ffffffff831c9e11>] ? link_path_walk+0x81/0x870
[<ffffffff831cdef9>] path_openat+0xc9/0x620
[<ffffffff8331cc02>] ? put_dec+0x72/0x90
[<ffffffff831ceb6d>] do_filp_open+0x4d/0xb0
[<ffffffff831bc4ae>] file_open_name+0xfe/0x160
[<ffffffff831bc554>] filp_open+0x44/0x60
[<ffffffff83221862>] do_coredump+0x602/0xf60
[<ffffffff83081358>] get_signal_to_deliver+0x2b8/0x6b0
[<ffffffff830024d7>] do_signal+0x57/0x9d0
[<ffffffff8311115e>] ? __acct_update_integrals+0x8e/0x120
[<ffffffff83730000>] ? __schedule+0x60/0x850
[<ffffffff8373a1db>] ? preempt_count_sub+0x6b/0xf0
[<ffffffff83735a31>] ? _raw_spin_unlock+0x31/0x50
[<ffffffff830ab671>] ? vtime_account_user+0x91/0xa0
[<ffffffff8314f57b>] ? context_tracking_user_exit+0x9b/0x100
[<ffffffff83002eac>] do_notify_resume+0x5c/0xa0
[<ffffffff83736746>] retint_signal+0x46/0x90
------------[ cut here ]------------
WARNING: CPU: 3 PID: 27511 at block/blk.h:227 generic_make_request_checks+0x33f/0x460()
Modules linked in: bridge stp tun snd_seq_dummy fuse hidp bnep rfcomm nf_conntrack_netlink nf_conntrack scsi_transport_iscsi nfnetlink can_raw nfc pn_pep caif_socket caif af_802154 phonet af_rxrpc can_bcm can llc2 pppoe pppox ppp_generic slhc irda crc_ccitt rds ipt_ULOG af_key rose x25 atm netrom appletalk ipx p8023 psnap p8022 llc ax25 cfg80211 xfs libcrc32c coretemp hwmon x86_pkg_temp_thermal kvm_intel kvm crct10dif_pclmul crc32c_intel ghash_clmulni_intel snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic serio_raw microcode pcspkr snd_hda_intel snd_hda_codec usb_debug btusb snd_hwdep snd_seq snd_seq_device bluetooth 6lowpan_iphc rfkill snd_pcm snd_timer snd soundcore e1000e ptp shpchp pps_core
CPU: 3 PID: 27511 Comm: trinity-c3 Not tainted 3.14.0-rc2+ #111
0000000000000009 0000000045a3849a ffff88009f368f10 ffffffff8372afea
0000000000000000 ffff88009f368f48 ffffffff8306d0cd ffff88023933ed00
00000000ffffffff 00000000197f7510 0000000000800005 ffff880240913740
Call Trace:
[<ffffffff8372afea>] dump_stack+0x4e/0x7a
[<ffffffff8306d0cd>] warn_slowpath_common+0x7d/0xa0
[<ffffffff8306d1fa>] warn_slowpath_null+0x1a/0x20
[<ffffffff832e81bf>] generic_make_request_checks+0x33f/0x460
[<ffffffff832e8307>] generic_make_request+0x27/0x130
[<ffffffff832e8488>] submit_bio+0x78/0x160
[<ffffffff831f9000>] ? bio_alloc_bioset+0x180/0x210
[<ffffffffc030832b>] _xfs_buf_ioapply+0x2bb/0x3c0 [xfs]
[<ffffffffc03798f2>] ? xlog_bdstrat+0x22/0x60 [xfs]
[<ffffffffc030849b>] xfs_buf_iorequest+0x6b/0xf0 [xfs]
[<ffffffffc03798f2>] xlog_bdstrat+0x22/0x60 [xfs]
[<ffffffffc037ba87>] xlog_sync+0x3a7/0x5b0 [xfs]
[<ffffffffc037bd9f>] xlog_state_release_iclog+0x10f/0x120 [xfs]
[<ffffffffc037c840>] xlog_write+0x6f0/0x800 [xfs]
[<ffffffffc037e061>] xlog_cil_push+0x2f1/0x410 [xfs]
[<ffffffffc037e948>] xlog_cil_force_lsn+0x1d8/0x210 [xfs]
[<ffffffffc03428a8>] ? xfs_bmbt_get_all+0x18/0x20 [xfs]
[<ffffffffc037cc40>] _xfs_log_force+0x70/0x290 [xfs]
[<ffffffff830a4edd>] ? get_parent_ip+0xd/0x50
[<ffffffffc037ce86>] xfs_log_force+0x26/0xb0 [xfs]
[<ffffffffc03076e6>] ? _xfs_buf_find+0x1f6/0x3c0 [xfs]
[<ffffffffc03074e3>] xfs_buf_lock+0x133/0x140 [xfs]
[<ffffffffc03076e6>] _xfs_buf_find+0x1f6/0x3c0 [xfs]
[<ffffffffc030796a>] xfs_buf_get_map+0x2a/0x1b0 [xfs]
[<ffffffffc0383c61>] xfs_trans_get_buf_map+0x1a1/0x240 [xfs]
[<ffffffffc034e03d>] xfs_da_get_buf+0xbd/0x100 [xfs]
[<ffffffffc0356869>] xfs_dir3_data_init+0x59/0x1d0 [xfs]
[<ffffffffc03526db>] ? xfs_dir2_grow_inode+0x13b/0x150 [xfs]
[<ffffffffc0354ede>] xfs_dir2_sf_to_block+0x17e/0x7b0 [xfs]
[<ffffffffc0351f5a>] ? xfs_dir2_sfe_get_ino+0x1a/0x20 [xfs]
[<ffffffffc035e9b4>] ? xfs_dir2_sf_check.isra.7+0x114/0x1b0 [xfs]
[<ffffffffc034c24f>] ? xfs_da_compname+0x1f/0x30 [xfs]
[<ffffffffc035f503>] ? xfs_dir2_sf_lookup+0x303/0x310 [xfs]
[<ffffffffc035f858>] xfs_dir2_sf_addname+0x348/0x6d0 [xfs]
[<ffffffffc031970d>] ? xfs_setup_inode+0x1cd/0x320 [xfs]
[<ffffffffc03529a4>] xfs_dir_createname+0x184/0x1e0 [xfs]
[<ffffffffc03663d9>] xfs_create+0x469/0x580 [xfs]
[<ffffffffc0318864>] xfs_vn_mknod+0xc4/0x1e0 [xfs]
[<ffffffffc0318993>] xfs_vn_create+0x13/0x20 [xfs]
[<ffffffff831ccc15>] vfs_create+0x95/0xc0
[<ffffffff831cd638>] do_last.isra.51+0x9f8/0x11f0
[<ffffffff831c9e11>] ? link_path_walk+0x81/0x870
[<ffffffff831cdef9>] path_openat+0xc9/0x620
[<ffffffff8331cc02>] ? put_dec+0x72/0x90
[<ffffffff831ceb6d>] do_filp_open+0x4d/0xb0
[<ffffffff831bc4ae>] file_open_name+0xfe/0x160
[<ffffffff831bc554>] filp_open+0x44/0x60
[<ffffffff83221862>] do_coredump+0x602/0xf60
[<ffffffff83081358>] get_signal_to_deliver+0x2b8/0x6b0
[<ffffffff830024d7>] do_signal+0x57/0x9d0
[<ffffffff8311115e>] ? __acct_update_integrals+0x8e/0x120
[<ffffffff83730000>] ? __schedule+0x60/0x850
[<ffffffff8373a1db>] ? preempt_count_sub+0x6b/0xf0
[<ffffffff83735a31>] ? _raw_spin_unlock+0x31/0x50
[<ffffffff830ab671>] ? vtime_account_user+0x91/0xa0
[<ffffffff8314f57b>] ? context_tracking_user_exit+0x9b/0x100
[<ffffffff83002eac>] do_notify_resume+0x5c/0xa0
[<ffffffff83736746>] retint_signal+0x46/0x90
---[ end trace e6e48f6461c98e81 ]---
^ permalink raw reply [flat|nested] 132+ messages in thread
* 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-11 17:27 ` Dave Jones
0 siblings, 0 replies; 132+ messages in thread
From: Dave Jones @ 2014-02-11 17:27 UTC (permalink / raw)
To: Linux Kernel; +Cc: xfs
BUG: sleeping function called from invalid context at mm/mempool.c:203
in_atomic(): 0, irqs_disabled(): 1, pid: 27511, name: trinity-c3
5 locks held by trinity-c3/27511:
#0: (sb_writers#9){......}, at: [<ffffffff831df3b4>] mnt_want_write+0x24/0x50
#1: (&type->i_mutex_dir_key#3){......}, at: [<ffffffff831cced4>] do_last.isra.51+0x294/0x11f0
#2: (sb_internal#2){......}, at: [<ffffffffc03225c4>] xfs_trans_alloc+0x24/0x40 [xfs]
#3: (&(&ip->i_lock)->mr_lock/1){......}, at: [<ffffffffc036447f>] xfs_ilock+0x16f/0x1b0 [xfs]
#4: (&(&ip->i_lock)->mr_lock){......}, at: [<ffffffffc03646d4>] xfs_ilock_nowait+0x184/0x200 [xfs]
CPU: 3 PID: 27511 Comm: trinity-c3 Not tainted 3.14.0-rc2+ #111
ffffffff83a3fd56 0000000045a3849a ffff88009f368f60 ffffffff8372afea
0000000000000000 ffff88009f368f88 ffffffff8309ddb5 0000000000000010
ffff880243566288 0000000000000008 ffff88009f369008 ffffffff831534d3
Call Trace:
[<ffffffff8372afea>] dump_stack+0x4e/0x7a
[<ffffffff8309ddb5>] __might_sleep+0x105/0x150
[<ffffffff831534d3>] mempool_alloc+0xa3/0x170
[<ffffffff831a955a>] ? deactivate_slab+0x51a/0x590
[<ffffffff831f8fd6>] bio_alloc_bioset+0x156/0x210
[<ffffffffc0308231>] _xfs_buf_ioapply+0x1c1/0x3c0 [xfs]
[<ffffffffc03798f2>] ? xlog_bdstrat+0x22/0x60 [xfs]
[<ffffffffc030849b>] xfs_buf_iorequest+0x6b/0xf0 [xfs]
[<ffffffffc03798f2>] xlog_bdstrat+0x22/0x60 [xfs]
[<ffffffffc037ba87>] xlog_sync+0x3a7/0x5b0 [xfs]
[<ffffffffc037bd9f>] xlog_state_release_iclog+0x10f/0x120 [xfs]
[<ffffffffc037c840>] xlog_write+0x6f0/0x800 [xfs]
[<ffffffffc037e061>] xlog_cil_push+0x2f1/0x410 [xfs]
[<ffffffffc037e948>] xlog_cil_force_lsn+0x1d8/0x210 [xfs]
[<ffffffffc03428a8>] ? xfs_bmbt_get_all+0x18/0x20 [xfs]
[<ffffffffc037cc40>] _xfs_log_force+0x70/0x290 [xfs]
[<ffffffff830a4edd>] ? get_parent_ip+0xd/0x50
[<ffffffffc037ce86>] xfs_log_force+0x26/0xb0 [xfs]
[<ffffffffc03076e6>] ? _xfs_buf_find+0x1f6/0x3c0 [xfs]
[<ffffffffc03074e3>] xfs_buf_lock+0x133/0x140 [xfs]
[<ffffffffc03076e6>] _xfs_buf_find+0x1f6/0x3c0 [xfs]
[<ffffffffc030796a>] xfs_buf_get_map+0x2a/0x1b0 [xfs]
[<ffffffffc0383c61>] xfs_trans_get_buf_map+0x1a1/0x240 [xfs]
[<ffffffffc034e03d>] xfs_da_get_buf+0xbd/0x100 [xfs]
[<ffffffffc0356869>] xfs_dir3_data_init+0x59/0x1d0 [xfs]
[<ffffffffc03526db>] ? xfs_dir2_grow_inode+0x13b/0x150 [xfs]
[<ffffffffc0354ede>] xfs_dir2_sf_to_block+0x17e/0x7b0 [xfs]
[<ffffffffc0351f5a>] ? xfs_dir2_sfe_get_ino+0x1a/0x20 [xfs]
[<ffffffffc035e9b4>] ? xfs_dir2_sf_check.isra.7+0x114/0x1b0 [xfs]
[<ffffffffc034c24f>] ? xfs_da_compname+0x1f/0x30 [xfs]
[<ffffffffc035f503>] ? xfs_dir2_sf_lookup+0x303/0x310 [xfs]
[<ffffffffc035f858>] xfs_dir2_sf_addname+0x348/0x6d0 [xfs]
[<ffffffffc031970d>] ? xfs_setup_inode+0x1cd/0x320 [xfs]
[<ffffffffc03529a4>] xfs_dir_createname+0x184/0x1e0 [xfs]
[<ffffffffc03663d9>] xfs_create+0x469/0x580 [xfs]
[<ffffffffc0318864>] xfs_vn_mknod+0xc4/0x1e0 [xfs]
[<ffffffffc0318993>] xfs_vn_create+0x13/0x20 [xfs]
[<ffffffff831ccc15>] vfs_create+0x95/0xc0
[<ffffffff831cd638>] do_last.isra.51+0x9f8/0x11f0
[<ffffffff831c9e11>] ? link_path_walk+0x81/0x870
[<ffffffff831cdef9>] path_openat+0xc9/0x620
[<ffffffff8331cc02>] ? put_dec+0x72/0x90
[<ffffffff831ceb6d>] do_filp_open+0x4d/0xb0
[<ffffffff831bc4ae>] file_open_name+0xfe/0x160
[<ffffffff831bc554>] filp_open+0x44/0x60
[<ffffffff83221862>] do_coredump+0x602/0xf60
[<ffffffff83081358>] get_signal_to_deliver+0x2b8/0x6b0
[<ffffffff830024d7>] do_signal+0x57/0x9d0
[<ffffffff8311115e>] ? __acct_update_integrals+0x8e/0x120
[<ffffffff83730000>] ? __schedule+0x60/0x850
[<ffffffff8373a1db>] ? preempt_count_sub+0x6b/0xf0
[<ffffffff83735a31>] ? _raw_spin_unlock+0x31/0x50
[<ffffffff830ab671>] ? vtime_account_user+0x91/0xa0
[<ffffffff8314f57b>] ? context_tracking_user_exit+0x9b/0x100
[<ffffffff83002eac>] do_notify_resume+0x5c/0xa0
[<ffffffff83736746>] retint_signal+0x46/0x90
------------[ cut here ]------------
WARNING: CPU: 3 PID: 27511 at block/blk.h:227 generic_make_request_checks+0x33f/0x460()
Modules linked in: bridge stp tun snd_seq_dummy fuse hidp bnep rfcomm nf_conntrack_netlink nf_conntrack scsi_transport_iscsi nfnetlink can_raw nfc pn_pep caif_socket caif af_802154 phonet af_rxrpc can_bcm can llc2 pppoe pppox ppp_generic slhc irda crc_ccitt rds ipt_ULOG af_key rose x25 atm netrom appletalk ipx p8023 psnap p8022 llc ax25 cfg80211 xfs libcrc32c coretemp hwmon x86_pkg_temp_thermal kvm_intel kvm crct10dif_pclmul crc32c_intel ghash_clmulni_intel snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic serio_raw microcode pcspkr snd_hda_intel snd_hda_codec usb_debug btusb snd_hwdep snd_seq snd_seq_device bluetooth 6lowpan_iphc rfkill snd_pcm snd_timer snd soundcore e1000e ptp shpchp pps_core
CPU: 3 PID: 27511 Comm: trinity-c3 Not tainted 3.14.0-rc2+ #111
0000000000000009 0000000045a3849a ffff88009f368f10 ffffffff8372afea
0000000000000000 ffff88009f368f48 ffffffff8306d0cd ffff88023933ed00
00000000ffffffff 00000000197f7510 0000000000800005 ffff880240913740
Call Trace:
[<ffffffff8372afea>] dump_stack+0x4e/0x7a
[<ffffffff8306d0cd>] warn_slowpath_common+0x7d/0xa0
[<ffffffff8306d1fa>] warn_slowpath_null+0x1a/0x20
[<ffffffff832e81bf>] generic_make_request_checks+0x33f/0x460
[<ffffffff832e8307>] generic_make_request+0x27/0x130
[<ffffffff832e8488>] submit_bio+0x78/0x160
[<ffffffff831f9000>] ? bio_alloc_bioset+0x180/0x210
[<ffffffffc030832b>] _xfs_buf_ioapply+0x2bb/0x3c0 [xfs]
[<ffffffffc03798f2>] ? xlog_bdstrat+0x22/0x60 [xfs]
[<ffffffffc030849b>] xfs_buf_iorequest+0x6b/0xf0 [xfs]
[<ffffffffc03798f2>] xlog_bdstrat+0x22/0x60 [xfs]
[<ffffffffc037ba87>] xlog_sync+0x3a7/0x5b0 [xfs]
[<ffffffffc037bd9f>] xlog_state_release_iclog+0x10f/0x120 [xfs]
[<ffffffffc037c840>] xlog_write+0x6f0/0x800 [xfs]
[<ffffffffc037e061>] xlog_cil_push+0x2f1/0x410 [xfs]
[<ffffffffc037e948>] xlog_cil_force_lsn+0x1d8/0x210 [xfs]
[<ffffffffc03428a8>] ? xfs_bmbt_get_all+0x18/0x20 [xfs]
[<ffffffffc037cc40>] _xfs_log_force+0x70/0x290 [xfs]
[<ffffffff830a4edd>] ? get_parent_ip+0xd/0x50
[<ffffffffc037ce86>] xfs_log_force+0x26/0xb0 [xfs]
[<ffffffffc03076e6>] ? _xfs_buf_find+0x1f6/0x3c0 [xfs]
[<ffffffffc03074e3>] xfs_buf_lock+0x133/0x140 [xfs]
[<ffffffffc03076e6>] _xfs_buf_find+0x1f6/0x3c0 [xfs]
[<ffffffffc030796a>] xfs_buf_get_map+0x2a/0x1b0 [xfs]
[<ffffffffc0383c61>] xfs_trans_get_buf_map+0x1a1/0x240 [xfs]
[<ffffffffc034e03d>] xfs_da_get_buf+0xbd/0x100 [xfs]
[<ffffffffc0356869>] xfs_dir3_data_init+0x59/0x1d0 [xfs]
[<ffffffffc03526db>] ? xfs_dir2_grow_inode+0x13b/0x150 [xfs]
[<ffffffffc0354ede>] xfs_dir2_sf_to_block+0x17e/0x7b0 [xfs]
[<ffffffffc0351f5a>] ? xfs_dir2_sfe_get_ino+0x1a/0x20 [xfs]
[<ffffffffc035e9b4>] ? xfs_dir2_sf_check.isra.7+0x114/0x1b0 [xfs]
[<ffffffffc034c24f>] ? xfs_da_compname+0x1f/0x30 [xfs]
[<ffffffffc035f503>] ? xfs_dir2_sf_lookup+0x303/0x310 [xfs]
[<ffffffffc035f858>] xfs_dir2_sf_addname+0x348/0x6d0 [xfs]
[<ffffffffc031970d>] ? xfs_setup_inode+0x1cd/0x320 [xfs]
[<ffffffffc03529a4>] xfs_dir_createname+0x184/0x1e0 [xfs]
[<ffffffffc03663d9>] xfs_create+0x469/0x580 [xfs]
[<ffffffffc0318864>] xfs_vn_mknod+0xc4/0x1e0 [xfs]
[<ffffffffc0318993>] xfs_vn_create+0x13/0x20 [xfs]
[<ffffffff831ccc15>] vfs_create+0x95/0xc0
[<ffffffff831cd638>] do_last.isra.51+0x9f8/0x11f0
[<ffffffff831c9e11>] ? link_path_walk+0x81/0x870
[<ffffffff831cdef9>] path_openat+0xc9/0x620
[<ffffffff8331cc02>] ? put_dec+0x72/0x90
[<ffffffff831ceb6d>] do_filp_open+0x4d/0xb0
[<ffffffff831bc4ae>] file_open_name+0xfe/0x160
[<ffffffff831bc554>] filp_open+0x44/0x60
[<ffffffff83221862>] do_coredump+0x602/0xf60
[<ffffffff83081358>] get_signal_to_deliver+0x2b8/0x6b0
[<ffffffff830024d7>] do_signal+0x57/0x9d0
[<ffffffff8311115e>] ? __acct_update_integrals+0x8e/0x120
[<ffffffff83730000>] ? __schedule+0x60/0x850
[<ffffffff8373a1db>] ? preempt_count_sub+0x6b/0xf0
[<ffffffff83735a31>] ? _raw_spin_unlock+0x31/0x50
[<ffffffff830ab671>] ? vtime_account_user+0x91/0xa0
[<ffffffff8314f57b>] ? context_tracking_user_exit+0x9b/0x100
[<ffffffff83002eac>] do_notify_resume+0x5c/0xa0
[<ffffffff83736746>] retint_signal+0x46/0x90
---[ end trace e6e48f6461c98e81 ]---
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-11 17:27 ` Dave Jones
@ 2014-02-11 21:08 ` Dave Chinner
-1 siblings, 0 replies; 132+ messages in thread
From: Dave Chinner @ 2014-02-11 21:08 UTC (permalink / raw)
To: Dave Jones, Linux Kernel, xfs
On Tue, Feb 11, 2014 at 12:27:07PM -0500, Dave Jones wrote:
> BUG: sleeping function called from invalid context at mm/mempool.c:203
> in_atomic(): 0, irqs_disabled(): 1, pid: 27511, name: trinity-c3
> 5 locks held by trinity-c3/27511:
> #0: (sb_writers#9){......}, at: [<ffffffff831df3b4>] mnt_want_write+0x24/0x50
> #1: (&type->i_mutex_dir_key#3){......}, at: [<ffffffff831cced4>] do_last.isra.51+0x294/0x11f0
> #2: (sb_internal#2){......}, at: [<ffffffffc03225c4>] xfs_trans_alloc+0x24/0x40 [xfs]
> #3: (&(&ip->i_lock)->mr_lock/1){......}, at: [<ffffffffc036447f>] xfs_ilock+0x16f/0x1b0 [xfs]
> #4: (&(&ip->i_lock)->mr_lock){......}, at: [<ffffffffc03646d4>] xfs_ilock_nowait+0x184/0x200 [xfs]
> CPU: 3 PID: 27511 Comm: trinity-c3 Not tainted 3.14.0-rc2+ #111
> ffffffff83a3fd56 0000000045a3849a ffff88009f368f60 ffffffff8372afea
> 0000000000000000 ffff88009f368f88 ffffffff8309ddb5 0000000000000010
> ffff880243566288 0000000000000008 ffff88009f369008 ffffffff831534d3
> Call Trace:
> [<ffffffff8372afea>] dump_stack+0x4e/0x7a
> [<ffffffff8309ddb5>] __might_sleep+0x105/0x150
> [<ffffffff831534d3>] mempool_alloc+0xa3/0x170
> [<ffffffff831a955a>] ? deactivate_slab+0x51a/0x590
> [<ffffffff831f8fd6>] bio_alloc_bioset+0x156/0x210
> [<ffffffffc0308231>] _xfs_buf_ioapply+0x1c1/0x3c0 [xfs]
> [<ffffffffc03798f2>] ? xlog_bdstrat+0x22/0x60 [xfs]
> [<ffffffffc030849b>] xfs_buf_iorequest+0x6b/0xf0 [xfs]
> [<ffffffffc03798f2>] xlog_bdstrat+0x22/0x60 [xfs]
> [<ffffffffc037ba87>] xlog_sync+0x3a7/0x5b0 [xfs]
> [<ffffffffc037bd9f>] xlog_state_release_iclog+0x10f/0x120 [xfs]
> [<ffffffffc037c840>] xlog_write+0x6f0/0x800 [xfs]
> [<ffffffffc037e061>] xlog_cil_push+0x2f1/0x410 [xfs]
> [<ffffffffc037e948>] xlog_cil_force_lsn+0x1d8/0x210 [xfs]
> [<ffffffffc03428a8>] ? xfs_bmbt_get_all+0x18/0x20 [xfs]
> [<ffffffffc037cc40>] _xfs_log_force+0x70/0x290 [xfs]
> [<ffffffff830a4edd>] ? get_parent_ip+0xd/0x50
> [<ffffffffc037ce86>] xfs_log_force+0x26/0xb0 [xfs]
> [<ffffffffc03076e6>] ? _xfs_buf_find+0x1f6/0x3c0 [xfs]
> [<ffffffffc03074e3>] xfs_buf_lock+0x133/0x140 [xfs]
> [<ffffffffc03076e6>] _xfs_buf_find+0x1f6/0x3c0 [xfs]
> [<ffffffffc030796a>] xfs_buf_get_map+0x2a/0x1b0 [xfs]
> [<ffffffffc0383c61>] xfs_trans_get_buf_map+0x1a1/0x240 [xfs]
> [<ffffffffc034e03d>] xfs_da_get_buf+0xbd/0x100 [xfs]
> [<ffffffffc0356869>] xfs_dir3_data_init+0x59/0x1d0 [xfs]
> [<ffffffffc03526db>] ? xfs_dir2_grow_inode+0x13b/0x150 [xfs]
> [<ffffffffc0354ede>] xfs_dir2_sf_to_block+0x17e/0x7b0 [xfs]
> [<ffffffffc0351f5a>] ? xfs_dir2_sfe_get_ino+0x1a/0x20 [xfs]
> [<ffffffffc035e9b4>] ? xfs_dir2_sf_check.isra.7+0x114/0x1b0 [xfs]
> [<ffffffffc034c24f>] ? xfs_da_compname+0x1f/0x30 [xfs]
> [<ffffffffc035f503>] ? xfs_dir2_sf_lookup+0x303/0x310 [xfs]
> [<ffffffffc035f858>] xfs_dir2_sf_addname+0x348/0x6d0 [xfs]
> [<ffffffffc031970d>] ? xfs_setup_inode+0x1cd/0x320 [xfs]
> [<ffffffffc03529a4>] xfs_dir_createname+0x184/0x1e0 [xfs]
> [<ffffffffc03663d9>] xfs_create+0x469/0x580 [xfs]
> [<ffffffffc0318864>] xfs_vn_mknod+0xc4/0x1e0 [xfs]
> [<ffffffffc0318993>] xfs_vn_create+0x13/0x20 [xfs]
> [<ffffffff831ccc15>] vfs_create+0x95/0xc0
> [<ffffffff831cd638>] do_last.isra.51+0x9f8/0x11f0
> [<ffffffff831c9e11>] ? link_path_walk+0x81/0x870
> [<ffffffff831cdef9>] path_openat+0xc9/0x620
> [<ffffffff8331cc02>] ? put_dec+0x72/0x90
> [<ffffffff831ceb6d>] do_filp_open+0x4d/0xb0
> [<ffffffff831bc4ae>] file_open_name+0xfe/0x160
> [<ffffffff831bc554>] filp_open+0x44/0x60
> [<ffffffff83221862>] do_coredump+0x602/0xf60
> [<ffffffff83081358>] get_signal_to_deliver+0x2b8/0x6b0
> [<ffffffff830024d7>] do_signal+0x57/0x9d0
> [<ffffffff8311115e>] ? __acct_update_integrals+0x8e/0x120
> [<ffffffff83730000>] ? __schedule+0x60/0x850
> [<ffffffff8373a1db>] ? preempt_count_sub+0x6b/0xf0
> [<ffffffff83735a31>] ? _raw_spin_unlock+0x31/0x50
> [<ffffffff830ab671>] ? vtime_account_user+0x91/0xa0
> [<ffffffff8314f57b>] ? context_tracking_user_exit+0x9b/0x100
> [<ffffffff83002eac>] do_notify_resume+0x5c/0xa0
> [<ffffffff83736746>] retint_signal+0x46/0x90
There's nowhere in this XFS stack that disables interrupts, so I
thinks it's either above or below XFS that is causing this problem.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-11 21:08 ` Dave Chinner
0 siblings, 0 replies; 132+ messages in thread
From: Dave Chinner @ 2014-02-11 21:08 UTC (permalink / raw)
To: Dave Jones, Linux Kernel, xfs
On Tue, Feb 11, 2014 at 12:27:07PM -0500, Dave Jones wrote:
> BUG: sleeping function called from invalid context at mm/mempool.c:203
> in_atomic(): 0, irqs_disabled(): 1, pid: 27511, name: trinity-c3
> 5 locks held by trinity-c3/27511:
> #0: (sb_writers#9){......}, at: [<ffffffff831df3b4>] mnt_want_write+0x24/0x50
> #1: (&type->i_mutex_dir_key#3){......}, at: [<ffffffff831cced4>] do_last.isra.51+0x294/0x11f0
> #2: (sb_internal#2){......}, at: [<ffffffffc03225c4>] xfs_trans_alloc+0x24/0x40 [xfs]
> #3: (&(&ip->i_lock)->mr_lock/1){......}, at: [<ffffffffc036447f>] xfs_ilock+0x16f/0x1b0 [xfs]
> #4: (&(&ip->i_lock)->mr_lock){......}, at: [<ffffffffc03646d4>] xfs_ilock_nowait+0x184/0x200 [xfs]
> CPU: 3 PID: 27511 Comm: trinity-c3 Not tainted 3.14.0-rc2+ #111
> ffffffff83a3fd56 0000000045a3849a ffff88009f368f60 ffffffff8372afea
> 0000000000000000 ffff88009f368f88 ffffffff8309ddb5 0000000000000010
> ffff880243566288 0000000000000008 ffff88009f369008 ffffffff831534d3
> Call Trace:
> [<ffffffff8372afea>] dump_stack+0x4e/0x7a
> [<ffffffff8309ddb5>] __might_sleep+0x105/0x150
> [<ffffffff831534d3>] mempool_alloc+0xa3/0x170
> [<ffffffff831a955a>] ? deactivate_slab+0x51a/0x590
> [<ffffffff831f8fd6>] bio_alloc_bioset+0x156/0x210
> [<ffffffffc0308231>] _xfs_buf_ioapply+0x1c1/0x3c0 [xfs]
> [<ffffffffc03798f2>] ? xlog_bdstrat+0x22/0x60 [xfs]
> [<ffffffffc030849b>] xfs_buf_iorequest+0x6b/0xf0 [xfs]
> [<ffffffffc03798f2>] xlog_bdstrat+0x22/0x60 [xfs]
> [<ffffffffc037ba87>] xlog_sync+0x3a7/0x5b0 [xfs]
> [<ffffffffc037bd9f>] xlog_state_release_iclog+0x10f/0x120 [xfs]
> [<ffffffffc037c840>] xlog_write+0x6f0/0x800 [xfs]
> [<ffffffffc037e061>] xlog_cil_push+0x2f1/0x410 [xfs]
> [<ffffffffc037e948>] xlog_cil_force_lsn+0x1d8/0x210 [xfs]
> [<ffffffffc03428a8>] ? xfs_bmbt_get_all+0x18/0x20 [xfs]
> [<ffffffffc037cc40>] _xfs_log_force+0x70/0x290 [xfs]
> [<ffffffff830a4edd>] ? get_parent_ip+0xd/0x50
> [<ffffffffc037ce86>] xfs_log_force+0x26/0xb0 [xfs]
> [<ffffffffc03076e6>] ? _xfs_buf_find+0x1f6/0x3c0 [xfs]
> [<ffffffffc03074e3>] xfs_buf_lock+0x133/0x140 [xfs]
> [<ffffffffc03076e6>] _xfs_buf_find+0x1f6/0x3c0 [xfs]
> [<ffffffffc030796a>] xfs_buf_get_map+0x2a/0x1b0 [xfs]
> [<ffffffffc0383c61>] xfs_trans_get_buf_map+0x1a1/0x240 [xfs]
> [<ffffffffc034e03d>] xfs_da_get_buf+0xbd/0x100 [xfs]
> [<ffffffffc0356869>] xfs_dir3_data_init+0x59/0x1d0 [xfs]
> [<ffffffffc03526db>] ? xfs_dir2_grow_inode+0x13b/0x150 [xfs]
> [<ffffffffc0354ede>] xfs_dir2_sf_to_block+0x17e/0x7b0 [xfs]
> [<ffffffffc0351f5a>] ? xfs_dir2_sfe_get_ino+0x1a/0x20 [xfs]
> [<ffffffffc035e9b4>] ? xfs_dir2_sf_check.isra.7+0x114/0x1b0 [xfs]
> [<ffffffffc034c24f>] ? xfs_da_compname+0x1f/0x30 [xfs]
> [<ffffffffc035f503>] ? xfs_dir2_sf_lookup+0x303/0x310 [xfs]
> [<ffffffffc035f858>] xfs_dir2_sf_addname+0x348/0x6d0 [xfs]
> [<ffffffffc031970d>] ? xfs_setup_inode+0x1cd/0x320 [xfs]
> [<ffffffffc03529a4>] xfs_dir_createname+0x184/0x1e0 [xfs]
> [<ffffffffc03663d9>] xfs_create+0x469/0x580 [xfs]
> [<ffffffffc0318864>] xfs_vn_mknod+0xc4/0x1e0 [xfs]
> [<ffffffffc0318993>] xfs_vn_create+0x13/0x20 [xfs]
> [<ffffffff831ccc15>] vfs_create+0x95/0xc0
> [<ffffffff831cd638>] do_last.isra.51+0x9f8/0x11f0
> [<ffffffff831c9e11>] ? link_path_walk+0x81/0x870
> [<ffffffff831cdef9>] path_openat+0xc9/0x620
> [<ffffffff8331cc02>] ? put_dec+0x72/0x90
> [<ffffffff831ceb6d>] do_filp_open+0x4d/0xb0
> [<ffffffff831bc4ae>] file_open_name+0xfe/0x160
> [<ffffffff831bc554>] filp_open+0x44/0x60
> [<ffffffff83221862>] do_coredump+0x602/0xf60
> [<ffffffff83081358>] get_signal_to_deliver+0x2b8/0x6b0
> [<ffffffff830024d7>] do_signal+0x57/0x9d0
> [<ffffffff8311115e>] ? __acct_update_integrals+0x8e/0x120
> [<ffffffff83730000>] ? __schedule+0x60/0x850
> [<ffffffff8373a1db>] ? preempt_count_sub+0x6b/0xf0
> [<ffffffff83735a31>] ? _raw_spin_unlock+0x31/0x50
> [<ffffffff830ab671>] ? vtime_account_user+0x91/0xa0
> [<ffffffff8314f57b>] ? context_tracking_user_exit+0x9b/0x100
> [<ffffffff83002eac>] do_notify_resume+0x5c/0xa0
> [<ffffffff83736746>] retint_signal+0x46/0x90
There's nowhere in this XFS stack that disables interrupts, so I
thinks it's either above or below XFS that is causing this problem.
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] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-11 21:08 ` Dave Chinner
@ 2014-02-11 21:49 ` Eric Sandeen
-1 siblings, 0 replies; 132+ messages in thread
From: Eric Sandeen @ 2014-02-11 21:49 UTC (permalink / raw)
To: Dave Chinner, Dave Jones, Linux Kernel, xfs
On 2/11/14, 3:08 PM, Dave Chinner wrote:
> On Tue, Feb 11, 2014 at 12:27:07PM -0500, Dave Jones wrote:
>> BUG: sleeping function called from invalid context at mm/mempool.c:203
>> in_atomic(): 0, irqs_disabled(): 1, pid: 27511, name: trinity-c3
>> 5 locks held by trinity-c3/27511:
>> #0: (sb_writers#9){......}, at: [<ffffffff831df3b4>] mnt_want_write+0x24/0x50
>> #1: (&type->i_mutex_dir_key#3){......}, at: [<ffffffff831cced4>] do_last.isra.51+0x294/0x11f0
>> #2: (sb_internal#2){......}, at: [<ffffffffc03225c4>] xfs_trans_alloc+0x24/0x40 [xfs]
>> #3: (&(&ip->i_lock)->mr_lock/1){......}, at: [<ffffffffc036447f>] xfs_ilock+0x16f/0x1b0 [xfs]
>> #4: (&(&ip->i_lock)->mr_lock){......}, at: [<ffffffffc03646d4>] xfs_ilock_nowait+0x184/0x200 [xfs]
>> CPU: 3 PID: 27511 Comm: trinity-c3 Not tainted 3.14.0-rc2+ #111
>> ffffffff83a3fd56 0000000045a3849a ffff88009f368f60 ffffffff8372afea
>> 0000000000000000 ffff88009f368f88 ffffffff8309ddb5 0000000000000010
>> ffff880243566288 0000000000000008 ffff88009f369008 ffffffff831534d3
>> Call Trace:
>> [<ffffffff8372afea>] dump_stack+0x4e/0x7a
>> [<ffffffff8309ddb5>] __might_sleep+0x105/0x150
>> [<ffffffff831534d3>] mempool_alloc+0xa3/0x170
>> [<ffffffff831a955a>] ? deactivate_slab+0x51a/0x590
>> [<ffffffff831f8fd6>] bio_alloc_bioset+0x156/0x210
>> [<ffffffffc0308231>] _xfs_buf_ioapply+0x1c1/0x3c0 [xfs]
>> [<ffffffffc03798f2>] ? xlog_bdstrat+0x22/0x60 [xfs]
>> [<ffffffffc030849b>] xfs_buf_iorequest+0x6b/0xf0 [xfs]
>> [<ffffffffc03798f2>] xlog_bdstrat+0x22/0x60 [xfs]
>> [<ffffffffc037ba87>] xlog_sync+0x3a7/0x5b0 [xfs]
>> [<ffffffffc037bd9f>] xlog_state_release_iclog+0x10f/0x120 [xfs]
>> [<ffffffffc037c840>] xlog_write+0x6f0/0x800 [xfs]
>> [<ffffffffc037e061>] xlog_cil_push+0x2f1/0x410 [xfs]
>> [<ffffffffc037e948>] xlog_cil_force_lsn+0x1d8/0x210 [xfs]
>> [<ffffffffc03428a8>] ? xfs_bmbt_get_all+0x18/0x20 [xfs]
>> [<ffffffffc037cc40>] _xfs_log_force+0x70/0x290 [xfs]
>> [<ffffffff830a4edd>] ? get_parent_ip+0xd/0x50
>> [<ffffffffc037ce86>] xfs_log_force+0x26/0xb0 [xfs]
>> [<ffffffffc03076e6>] ? _xfs_buf_find+0x1f6/0x3c0 [xfs]
>> [<ffffffffc03074e3>] xfs_buf_lock+0x133/0x140 [xfs]
>> [<ffffffffc03076e6>] _xfs_buf_find+0x1f6/0x3c0 [xfs]
>> [<ffffffffc030796a>] xfs_buf_get_map+0x2a/0x1b0 [xfs]
>> [<ffffffffc0383c61>] xfs_trans_get_buf_map+0x1a1/0x240 [xfs]
>> [<ffffffffc034e03d>] xfs_da_get_buf+0xbd/0x100 [xfs]
>> [<ffffffffc0356869>] xfs_dir3_data_init+0x59/0x1d0 [xfs]
>> [<ffffffffc03526db>] ? xfs_dir2_grow_inode+0x13b/0x150 [xfs]
>> [<ffffffffc0354ede>] xfs_dir2_sf_to_block+0x17e/0x7b0 [xfs]
>> [<ffffffffc0351f5a>] ? xfs_dir2_sfe_get_ino+0x1a/0x20 [xfs]
>> [<ffffffffc035e9b4>] ? xfs_dir2_sf_check.isra.7+0x114/0x1b0 [xfs]
>> [<ffffffffc034c24f>] ? xfs_da_compname+0x1f/0x30 [xfs]
>> [<ffffffffc035f503>] ? xfs_dir2_sf_lookup+0x303/0x310 [xfs]
>> [<ffffffffc035f858>] xfs_dir2_sf_addname+0x348/0x6d0 [xfs]
>> [<ffffffffc031970d>] ? xfs_setup_inode+0x1cd/0x320 [xfs]
>> [<ffffffffc03529a4>] xfs_dir_createname+0x184/0x1e0 [xfs]
>> [<ffffffffc03663d9>] xfs_create+0x469/0x580 [xfs]
>> [<ffffffffc0318864>] xfs_vn_mknod+0xc4/0x1e0 [xfs]
>> [<ffffffffc0318993>] xfs_vn_create+0x13/0x20 [xfs]
>> [<ffffffff831ccc15>] vfs_create+0x95/0xc0
>> [<ffffffff831cd638>] do_last.isra.51+0x9f8/0x11f0
>> [<ffffffff831c9e11>] ? link_path_walk+0x81/0x870
>> [<ffffffff831cdef9>] path_openat+0xc9/0x620
>> [<ffffffff8331cc02>] ? put_dec+0x72/0x90
>> [<ffffffff831ceb6d>] do_filp_open+0x4d/0xb0
>> [<ffffffff831bc4ae>] file_open_name+0xfe/0x160
>> [<ffffffff831bc554>] filp_open+0x44/0x60
>> [<ffffffff83221862>] do_coredump+0x602/0xf60
>> [<ffffffff83081358>] get_signal_to_deliver+0x2b8/0x6b0
>> [<ffffffff830024d7>] do_signal+0x57/0x9d0
>> [<ffffffff8311115e>] ? __acct_update_integrals+0x8e/0x120
>> [<ffffffff83730000>] ? __schedule+0x60/0x850
>> [<ffffffff8373a1db>] ? preempt_count_sub+0x6b/0xf0
>> [<ffffffff83735a31>] ? _raw_spin_unlock+0x31/0x50
>> [<ffffffff830ab671>] ? vtime_account_user+0x91/0xa0
>> [<ffffffff8314f57b>] ? context_tracking_user_exit+0x9b/0x100
>> [<ffffffff83002eac>] do_notify_resume+0x5c/0xa0
>> [<ffffffff83736746>] retint_signal+0x46/0x90
>
> There's nowhere in this XFS stack that disables interrupts, so I
> thinks it's either above or below XFS that is causing this problem.
any chance the stack got blown & corrupted things such that it
only _looks_ like irqs are disabled?
-Eric
> Cheers,
>
> Dave.
>
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-11 21:49 ` Eric Sandeen
0 siblings, 0 replies; 132+ messages in thread
From: Eric Sandeen @ 2014-02-11 21:49 UTC (permalink / raw)
To: Dave Chinner, Dave Jones, Linux Kernel, xfs
On 2/11/14, 3:08 PM, Dave Chinner wrote:
> On Tue, Feb 11, 2014 at 12:27:07PM -0500, Dave Jones wrote:
>> BUG: sleeping function called from invalid context at mm/mempool.c:203
>> in_atomic(): 0, irqs_disabled(): 1, pid: 27511, name: trinity-c3
>> 5 locks held by trinity-c3/27511:
>> #0: (sb_writers#9){......}, at: [<ffffffff831df3b4>] mnt_want_write+0x24/0x50
>> #1: (&type->i_mutex_dir_key#3){......}, at: [<ffffffff831cced4>] do_last.isra.51+0x294/0x11f0
>> #2: (sb_internal#2){......}, at: [<ffffffffc03225c4>] xfs_trans_alloc+0x24/0x40 [xfs]
>> #3: (&(&ip->i_lock)->mr_lock/1){......}, at: [<ffffffffc036447f>] xfs_ilock+0x16f/0x1b0 [xfs]
>> #4: (&(&ip->i_lock)->mr_lock){......}, at: [<ffffffffc03646d4>] xfs_ilock_nowait+0x184/0x200 [xfs]
>> CPU: 3 PID: 27511 Comm: trinity-c3 Not tainted 3.14.0-rc2+ #111
>> ffffffff83a3fd56 0000000045a3849a ffff88009f368f60 ffffffff8372afea
>> 0000000000000000 ffff88009f368f88 ffffffff8309ddb5 0000000000000010
>> ffff880243566288 0000000000000008 ffff88009f369008 ffffffff831534d3
>> Call Trace:
>> [<ffffffff8372afea>] dump_stack+0x4e/0x7a
>> [<ffffffff8309ddb5>] __might_sleep+0x105/0x150
>> [<ffffffff831534d3>] mempool_alloc+0xa3/0x170
>> [<ffffffff831a955a>] ? deactivate_slab+0x51a/0x590
>> [<ffffffff831f8fd6>] bio_alloc_bioset+0x156/0x210
>> [<ffffffffc0308231>] _xfs_buf_ioapply+0x1c1/0x3c0 [xfs]
>> [<ffffffffc03798f2>] ? xlog_bdstrat+0x22/0x60 [xfs]
>> [<ffffffffc030849b>] xfs_buf_iorequest+0x6b/0xf0 [xfs]
>> [<ffffffffc03798f2>] xlog_bdstrat+0x22/0x60 [xfs]
>> [<ffffffffc037ba87>] xlog_sync+0x3a7/0x5b0 [xfs]
>> [<ffffffffc037bd9f>] xlog_state_release_iclog+0x10f/0x120 [xfs]
>> [<ffffffffc037c840>] xlog_write+0x6f0/0x800 [xfs]
>> [<ffffffffc037e061>] xlog_cil_push+0x2f1/0x410 [xfs]
>> [<ffffffffc037e948>] xlog_cil_force_lsn+0x1d8/0x210 [xfs]
>> [<ffffffffc03428a8>] ? xfs_bmbt_get_all+0x18/0x20 [xfs]
>> [<ffffffffc037cc40>] _xfs_log_force+0x70/0x290 [xfs]
>> [<ffffffff830a4edd>] ? get_parent_ip+0xd/0x50
>> [<ffffffffc037ce86>] xfs_log_force+0x26/0xb0 [xfs]
>> [<ffffffffc03076e6>] ? _xfs_buf_find+0x1f6/0x3c0 [xfs]
>> [<ffffffffc03074e3>] xfs_buf_lock+0x133/0x140 [xfs]
>> [<ffffffffc03076e6>] _xfs_buf_find+0x1f6/0x3c0 [xfs]
>> [<ffffffffc030796a>] xfs_buf_get_map+0x2a/0x1b0 [xfs]
>> [<ffffffffc0383c61>] xfs_trans_get_buf_map+0x1a1/0x240 [xfs]
>> [<ffffffffc034e03d>] xfs_da_get_buf+0xbd/0x100 [xfs]
>> [<ffffffffc0356869>] xfs_dir3_data_init+0x59/0x1d0 [xfs]
>> [<ffffffffc03526db>] ? xfs_dir2_grow_inode+0x13b/0x150 [xfs]
>> [<ffffffffc0354ede>] xfs_dir2_sf_to_block+0x17e/0x7b0 [xfs]
>> [<ffffffffc0351f5a>] ? xfs_dir2_sfe_get_ino+0x1a/0x20 [xfs]
>> [<ffffffffc035e9b4>] ? xfs_dir2_sf_check.isra.7+0x114/0x1b0 [xfs]
>> [<ffffffffc034c24f>] ? xfs_da_compname+0x1f/0x30 [xfs]
>> [<ffffffffc035f503>] ? xfs_dir2_sf_lookup+0x303/0x310 [xfs]
>> [<ffffffffc035f858>] xfs_dir2_sf_addname+0x348/0x6d0 [xfs]
>> [<ffffffffc031970d>] ? xfs_setup_inode+0x1cd/0x320 [xfs]
>> [<ffffffffc03529a4>] xfs_dir_createname+0x184/0x1e0 [xfs]
>> [<ffffffffc03663d9>] xfs_create+0x469/0x580 [xfs]
>> [<ffffffffc0318864>] xfs_vn_mknod+0xc4/0x1e0 [xfs]
>> [<ffffffffc0318993>] xfs_vn_create+0x13/0x20 [xfs]
>> [<ffffffff831ccc15>] vfs_create+0x95/0xc0
>> [<ffffffff831cd638>] do_last.isra.51+0x9f8/0x11f0
>> [<ffffffff831c9e11>] ? link_path_walk+0x81/0x870
>> [<ffffffff831cdef9>] path_openat+0xc9/0x620
>> [<ffffffff8331cc02>] ? put_dec+0x72/0x90
>> [<ffffffff831ceb6d>] do_filp_open+0x4d/0xb0
>> [<ffffffff831bc4ae>] file_open_name+0xfe/0x160
>> [<ffffffff831bc554>] filp_open+0x44/0x60
>> [<ffffffff83221862>] do_coredump+0x602/0xf60
>> [<ffffffff83081358>] get_signal_to_deliver+0x2b8/0x6b0
>> [<ffffffff830024d7>] do_signal+0x57/0x9d0
>> [<ffffffff8311115e>] ? __acct_update_integrals+0x8e/0x120
>> [<ffffffff83730000>] ? __schedule+0x60/0x850
>> [<ffffffff8373a1db>] ? preempt_count_sub+0x6b/0xf0
>> [<ffffffff83735a31>] ? _raw_spin_unlock+0x31/0x50
>> [<ffffffff830ab671>] ? vtime_account_user+0x91/0xa0
>> [<ffffffff8314f57b>] ? context_tracking_user_exit+0x9b/0x100
>> [<ffffffff83002eac>] do_notify_resume+0x5c/0xa0
>> [<ffffffff83736746>] retint_signal+0x46/0x90
>
> There's nowhere in this XFS stack that disables interrupts, so I
> thinks it's either above or below XFS that is causing this problem.
any chance the stack got blown & corrupted things such that it
only _looks_ like irqs are disabled?
-Eric
> Cheers,
>
> Dave.
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-11 21:49 ` Eric Sandeen
@ 2014-02-12 0:44 ` Dave Jones
-1 siblings, 0 replies; 132+ messages in thread
From: Dave Jones @ 2014-02-12 0:44 UTC (permalink / raw)
To: Eric Sandeen; +Cc: Dave Chinner, Linux Kernel, xfs, Al Viro, Linus Torvalds
On Tue, Feb 11, 2014 at 03:49:14PM -0600, Eric Sandeen wrote:
> On 2/11/14, 3:08 PM, Dave Chinner wrote:
> > On Tue, Feb 11, 2014 at 12:27:07PM -0500, Dave Jones wrote:
> >> BUG: sleeping function called from invalid context at mm/mempool.c:203
> >> in_atomic(): 0, irqs_disabled(): 1, pid: 27511, name: trinity-c3
> >> 5 locks held by trinity-c3/27511:
> >> #0: (sb_writers#9){......}, at: [<ffffffff831df3b4>] mnt_want_write+0x24/0x50
> >> #1: (&type->i_mutex_dir_key#3){......}, at: [<ffffffff831cced4>] do_last.isra.51+0x294/0x11f0
> >> #2: (sb_internal#2){......}, at: [<ffffffffc03225c4>] xfs_trans_alloc+0x24/0x40 [xfs]
> >> #3: (&(&ip->i_lock)->mr_lock/1){......}, at: [<ffffffffc036447f>] xfs_ilock+0x16f/0x1b0 [xfs]
> >> #4: (&(&ip->i_lock)->mr_lock){......}, at: [<ffffffffc03646d4>] xfs_ilock_nowait+0x184/0x200 [xfs]
> >> CPU: 3 PID: 27511 Comm: trinity-c3 Not tainted 3.14.0-rc2+ #111
> >> ffffffff83a3fd56 0000000045a3849a ffff88009f368f60 ffffffff8372afea
> >> 0000000000000000 ffff88009f368f88 ffffffff8309ddb5 0000000000000010
> >> ffff880243566288 0000000000000008 ffff88009f369008 ffffffff831534d3
> >> Call Trace:
> >> [<ffffffff8372afea>] dump_stack+0x4e/0x7a
> >> [<ffffffff8309ddb5>] __might_sleep+0x105/0x150
> >> [<ffffffff831534d3>] mempool_alloc+0xa3/0x170
> >> [<ffffffff831a955a>] ? deactivate_slab+0x51a/0x590
> >> [<ffffffff831f8fd6>] bio_alloc_bioset+0x156/0x210
> >> [<ffffffffc0308231>] _xfs_buf_ioapply+0x1c1/0x3c0 [xfs]
> >> [<ffffffffc03798f2>] ? xlog_bdstrat+0x22/0x60 [xfs]
> >> [<ffffffffc030849b>] xfs_buf_iorequest+0x6b/0xf0 [xfs]
> >> [<ffffffffc03798f2>] xlog_bdstrat+0x22/0x60 [xfs]
> >> [<ffffffffc037ba87>] xlog_sync+0x3a7/0x5b0 [xfs]
> >> [<ffffffffc037bd9f>] xlog_state_release_iclog+0x10f/0x120 [xfs]
> >> [<ffffffffc037c840>] xlog_write+0x6f0/0x800 [xfs]
> >> [<ffffffffc037e061>] xlog_cil_push+0x2f1/0x410 [xfs]
> >> [<ffffffffc037e948>] xlog_cil_force_lsn+0x1d8/0x210 [xfs]
> >> [<ffffffffc03428a8>] ? xfs_bmbt_get_all+0x18/0x20 [xfs]
> >> [<ffffffffc037cc40>] _xfs_log_force+0x70/0x290 [xfs]
> >> [<ffffffff830a4edd>] ? get_parent_ip+0xd/0x50
> >> [<ffffffffc037ce86>] xfs_log_force+0x26/0xb0 [xfs]
> >> [<ffffffffc03076e6>] ? _xfs_buf_find+0x1f6/0x3c0 [xfs]
> >> [<ffffffffc03074e3>] xfs_buf_lock+0x133/0x140 [xfs]
> >> [<ffffffffc03076e6>] _xfs_buf_find+0x1f6/0x3c0 [xfs]
> >> [<ffffffffc030796a>] xfs_buf_get_map+0x2a/0x1b0 [xfs]
> >> [<ffffffffc0383c61>] xfs_trans_get_buf_map+0x1a1/0x240 [xfs]
> >> [<ffffffffc034e03d>] xfs_da_get_buf+0xbd/0x100 [xfs]
> >> [<ffffffffc0356869>] xfs_dir3_data_init+0x59/0x1d0 [xfs]
> >> [<ffffffffc03526db>] ? xfs_dir2_grow_inode+0x13b/0x150 [xfs]
> >> [<ffffffffc0354ede>] xfs_dir2_sf_to_block+0x17e/0x7b0 [xfs]
> >> [<ffffffffc0351f5a>] ? xfs_dir2_sfe_get_ino+0x1a/0x20 [xfs]
> >> [<ffffffffc035e9b4>] ? xfs_dir2_sf_check.isra.7+0x114/0x1b0 [xfs]
> >> [<ffffffffc034c24f>] ? xfs_da_compname+0x1f/0x30 [xfs]
> >> [<ffffffffc035f503>] ? xfs_dir2_sf_lookup+0x303/0x310 [xfs]
> >> [<ffffffffc035f858>] xfs_dir2_sf_addname+0x348/0x6d0 [xfs]
> >> [<ffffffffc031970d>] ? xfs_setup_inode+0x1cd/0x320 [xfs]
> >> [<ffffffffc03529a4>] xfs_dir_createname+0x184/0x1e0 [xfs]
> >> [<ffffffffc03663d9>] xfs_create+0x469/0x580 [xfs]
> >> [<ffffffffc0318864>] xfs_vn_mknod+0xc4/0x1e0 [xfs]
> >> [<ffffffffc0318993>] xfs_vn_create+0x13/0x20 [xfs]
> >> [<ffffffff831ccc15>] vfs_create+0x95/0xc0
> >> [<ffffffff831cd638>] do_last.isra.51+0x9f8/0x11f0
> >> [<ffffffff831c9e11>] ? link_path_walk+0x81/0x870
> >> [<ffffffff831cdef9>] path_openat+0xc9/0x620
> >> [<ffffffff8331cc02>] ? put_dec+0x72/0x90
> >> [<ffffffff831ceb6d>] do_filp_open+0x4d/0xb0
> >> [<ffffffff831bc4ae>] file_open_name+0xfe/0x160
> >> [<ffffffff831bc554>] filp_open+0x44/0x60
> >> [<ffffffff83221862>] do_coredump+0x602/0xf60
> >> [<ffffffff83081358>] get_signal_to_deliver+0x2b8/0x6b0
> >> [<ffffffff830024d7>] do_signal+0x57/0x9d0
> >> [<ffffffff8311115e>] ? __acct_update_integrals+0x8e/0x120
> >> [<ffffffff83730000>] ? __schedule+0x60/0x850
> >> [<ffffffff8373a1db>] ? preempt_count_sub+0x6b/0xf0
> >> [<ffffffff83735a31>] ? _raw_spin_unlock+0x31/0x50
> >> [<ffffffff830ab671>] ? vtime_account_user+0x91/0xa0
> >> [<ffffffff8314f57b>] ? context_tracking_user_exit+0x9b/0x100
> >> [<ffffffff83002eac>] do_notify_resume+0x5c/0xa0
> >> [<ffffffff83736746>] retint_signal+0x46/0x90
> >
> > There's nowhere in this XFS stack that disables interrupts, so I
> > thinks it's either above or below XFS that is causing this problem.
>
> any chance the stack got blown & corrupted things such that it
> only _looks_ like irqs are disabled?
The 'good' news is I seem to be able to reproduce it fairly quickly.
I've seen it 3-4 times this afternoon. (Always from the coredump path)
I was on vacation last week, but I wasn't hitting this before then, so it's a
fairly recent change that's introduced this.
Al ?
Dave
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-12 0:44 ` Dave Jones
0 siblings, 0 replies; 132+ messages in thread
From: Dave Jones @ 2014-02-12 0:44 UTC (permalink / raw)
To: Eric Sandeen; +Cc: Linus Torvalds, Linux Kernel, Al Viro, xfs
On Tue, Feb 11, 2014 at 03:49:14PM -0600, Eric Sandeen wrote:
> On 2/11/14, 3:08 PM, Dave Chinner wrote:
> > On Tue, Feb 11, 2014 at 12:27:07PM -0500, Dave Jones wrote:
> >> BUG: sleeping function called from invalid context at mm/mempool.c:203
> >> in_atomic(): 0, irqs_disabled(): 1, pid: 27511, name: trinity-c3
> >> 5 locks held by trinity-c3/27511:
> >> #0: (sb_writers#9){......}, at: [<ffffffff831df3b4>] mnt_want_write+0x24/0x50
> >> #1: (&type->i_mutex_dir_key#3){......}, at: [<ffffffff831cced4>] do_last.isra.51+0x294/0x11f0
> >> #2: (sb_internal#2){......}, at: [<ffffffffc03225c4>] xfs_trans_alloc+0x24/0x40 [xfs]
> >> #3: (&(&ip->i_lock)->mr_lock/1){......}, at: [<ffffffffc036447f>] xfs_ilock+0x16f/0x1b0 [xfs]
> >> #4: (&(&ip->i_lock)->mr_lock){......}, at: [<ffffffffc03646d4>] xfs_ilock_nowait+0x184/0x200 [xfs]
> >> CPU: 3 PID: 27511 Comm: trinity-c3 Not tainted 3.14.0-rc2+ #111
> >> ffffffff83a3fd56 0000000045a3849a ffff88009f368f60 ffffffff8372afea
> >> 0000000000000000 ffff88009f368f88 ffffffff8309ddb5 0000000000000010
> >> ffff880243566288 0000000000000008 ffff88009f369008 ffffffff831534d3
> >> Call Trace:
> >> [<ffffffff8372afea>] dump_stack+0x4e/0x7a
> >> [<ffffffff8309ddb5>] __might_sleep+0x105/0x150
> >> [<ffffffff831534d3>] mempool_alloc+0xa3/0x170
> >> [<ffffffff831a955a>] ? deactivate_slab+0x51a/0x590
> >> [<ffffffff831f8fd6>] bio_alloc_bioset+0x156/0x210
> >> [<ffffffffc0308231>] _xfs_buf_ioapply+0x1c1/0x3c0 [xfs]
> >> [<ffffffffc03798f2>] ? xlog_bdstrat+0x22/0x60 [xfs]
> >> [<ffffffffc030849b>] xfs_buf_iorequest+0x6b/0xf0 [xfs]
> >> [<ffffffffc03798f2>] xlog_bdstrat+0x22/0x60 [xfs]
> >> [<ffffffffc037ba87>] xlog_sync+0x3a7/0x5b0 [xfs]
> >> [<ffffffffc037bd9f>] xlog_state_release_iclog+0x10f/0x120 [xfs]
> >> [<ffffffffc037c840>] xlog_write+0x6f0/0x800 [xfs]
> >> [<ffffffffc037e061>] xlog_cil_push+0x2f1/0x410 [xfs]
> >> [<ffffffffc037e948>] xlog_cil_force_lsn+0x1d8/0x210 [xfs]
> >> [<ffffffffc03428a8>] ? xfs_bmbt_get_all+0x18/0x20 [xfs]
> >> [<ffffffffc037cc40>] _xfs_log_force+0x70/0x290 [xfs]
> >> [<ffffffff830a4edd>] ? get_parent_ip+0xd/0x50
> >> [<ffffffffc037ce86>] xfs_log_force+0x26/0xb0 [xfs]
> >> [<ffffffffc03076e6>] ? _xfs_buf_find+0x1f6/0x3c0 [xfs]
> >> [<ffffffffc03074e3>] xfs_buf_lock+0x133/0x140 [xfs]
> >> [<ffffffffc03076e6>] _xfs_buf_find+0x1f6/0x3c0 [xfs]
> >> [<ffffffffc030796a>] xfs_buf_get_map+0x2a/0x1b0 [xfs]
> >> [<ffffffffc0383c61>] xfs_trans_get_buf_map+0x1a1/0x240 [xfs]
> >> [<ffffffffc034e03d>] xfs_da_get_buf+0xbd/0x100 [xfs]
> >> [<ffffffffc0356869>] xfs_dir3_data_init+0x59/0x1d0 [xfs]
> >> [<ffffffffc03526db>] ? xfs_dir2_grow_inode+0x13b/0x150 [xfs]
> >> [<ffffffffc0354ede>] xfs_dir2_sf_to_block+0x17e/0x7b0 [xfs]
> >> [<ffffffffc0351f5a>] ? xfs_dir2_sfe_get_ino+0x1a/0x20 [xfs]
> >> [<ffffffffc035e9b4>] ? xfs_dir2_sf_check.isra.7+0x114/0x1b0 [xfs]
> >> [<ffffffffc034c24f>] ? xfs_da_compname+0x1f/0x30 [xfs]
> >> [<ffffffffc035f503>] ? xfs_dir2_sf_lookup+0x303/0x310 [xfs]
> >> [<ffffffffc035f858>] xfs_dir2_sf_addname+0x348/0x6d0 [xfs]
> >> [<ffffffffc031970d>] ? xfs_setup_inode+0x1cd/0x320 [xfs]
> >> [<ffffffffc03529a4>] xfs_dir_createname+0x184/0x1e0 [xfs]
> >> [<ffffffffc03663d9>] xfs_create+0x469/0x580 [xfs]
> >> [<ffffffffc0318864>] xfs_vn_mknod+0xc4/0x1e0 [xfs]
> >> [<ffffffffc0318993>] xfs_vn_create+0x13/0x20 [xfs]
> >> [<ffffffff831ccc15>] vfs_create+0x95/0xc0
> >> [<ffffffff831cd638>] do_last.isra.51+0x9f8/0x11f0
> >> [<ffffffff831c9e11>] ? link_path_walk+0x81/0x870
> >> [<ffffffff831cdef9>] path_openat+0xc9/0x620
> >> [<ffffffff8331cc02>] ? put_dec+0x72/0x90
> >> [<ffffffff831ceb6d>] do_filp_open+0x4d/0xb0
> >> [<ffffffff831bc4ae>] file_open_name+0xfe/0x160
> >> [<ffffffff831bc554>] filp_open+0x44/0x60
> >> [<ffffffff83221862>] do_coredump+0x602/0xf60
> >> [<ffffffff83081358>] get_signal_to_deliver+0x2b8/0x6b0
> >> [<ffffffff830024d7>] do_signal+0x57/0x9d0
> >> [<ffffffff8311115e>] ? __acct_update_integrals+0x8e/0x120
> >> [<ffffffff83730000>] ? __schedule+0x60/0x850
> >> [<ffffffff8373a1db>] ? preempt_count_sub+0x6b/0xf0
> >> [<ffffffff83735a31>] ? _raw_spin_unlock+0x31/0x50
> >> [<ffffffff830ab671>] ? vtime_account_user+0x91/0xa0
> >> [<ffffffff8314f57b>] ? context_tracking_user_exit+0x9b/0x100
> >> [<ffffffff83002eac>] do_notify_resume+0x5c/0xa0
> >> [<ffffffff83736746>] retint_signal+0x46/0x90
> >
> > There's nowhere in this XFS stack that disables interrupts, so I
> > thinks it's either above or below XFS that is causing this problem.
>
> any chance the stack got blown & corrupted things such that it
> only _looks_ like irqs are disabled?
The 'good' news is I seem to be able to reproduce it fairly quickly.
I've seen it 3-4 times this afternoon. (Always from the coredump path)
I was on vacation last week, but I wasn't hitting this before then, so it's a
fairly recent change that's introduced this.
Al ?
Dave
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 0:44 ` Dave Jones
@ 2014-02-12 1:09 ` Al Viro
-1 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-12 1:09 UTC (permalink / raw)
To: Dave Jones, Eric Sandeen, Dave Chinner, Linux Kernel, xfs,
Linus Torvalds
On Tue, Feb 11, 2014 at 07:44:03PM -0500, Dave Jones wrote:
> The 'good' news is I seem to be able to reproduce it fairly quickly.
> I've seen it 3-4 times this afternoon. (Always from the coredump path)
>
> I was on vacation last week, but I wasn't hitting this before then, so it's a
> fairly recent change that's introduced this.
Slap the check in vfs_create(), see if interrupts had been disabled by it or
by something in ->create(). Since it's reproducible...
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-12 1:09 ` Al Viro
0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-12 1:09 UTC (permalink / raw)
To: Dave Jones, Eric Sandeen, Dave Chinner, Linux Kernel, xfs,
Linus Torvalds
On Tue, Feb 11, 2014 at 07:44:03PM -0500, Dave Jones wrote:
> The 'good' news is I seem to be able to reproduce it fairly quickly.
> I've seen it 3-4 times this afternoon. (Always from the coredump path)
>
> I was on vacation last week, but I wasn't hitting this before then, so it's a
> fairly recent change that's introduced this.
Slap the check in vfs_create(), see if interrupts had been disabled by it or
by something in ->create(). Since it's reproducible...
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 1:09 ` Al Viro
@ 2014-02-12 2:52 ` Linus Torvalds
-1 siblings, 0 replies; 132+ messages in thread
From: Linus Torvalds @ 2014-02-12 2:52 UTC (permalink / raw)
To: Al Viro; +Cc: Dave Jones, Eric Sandeen, Dave Chinner, Linux Kernel, xfs
On Tue, Feb 11, 2014 at 5:09 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> Slap the check in vfs_create(), see if interrupts had been disabled by it or
> by something in ->create(). Since it's reproducible...
path_openat() starts off with a get_empty_filp(), which allocates a
file pointer with GFP_KERNEL. So that should have triggered the
might_sleep warning if irq's were already disabled at that point.
So it's not before that - in particular, it's not in the signal
handling or do_coredump() paths.
Also, at least xfs_buf_lock() - which is much deeper in that chain -
does a down(&bp->b_sema). I'm disguested that that doesn't have a
might_sleep() in it.
Dave, mind adding a "might_sleep()" to the top of
"down[_interruptible]()". It's silly to not have coverage of semaphore
use in bad contexts.
Linus
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-12 2:52 ` Linus Torvalds
0 siblings, 0 replies; 132+ messages in thread
From: Linus Torvalds @ 2014-02-12 2:52 UTC (permalink / raw)
To: Al Viro; +Cc: Dave Jones, Eric Sandeen, Linux Kernel, xfs
On Tue, Feb 11, 2014 at 5:09 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> Slap the check in vfs_create(), see if interrupts had been disabled by it or
> by something in ->create(). Since it's reproducible...
path_openat() starts off with a get_empty_filp(), which allocates a
file pointer with GFP_KERNEL. So that should have triggered the
might_sleep warning if irq's were already disabled at that point.
So it's not before that - in particular, it's not in the signal
handling or do_coredump() paths.
Also, at least xfs_buf_lock() - which is much deeper in that chain -
does a down(&bp->b_sema). I'm disguested that that doesn't have a
might_sleep() in it.
Dave, mind adding a "might_sleep()" to the top of
"down[_interruptible]()". It's silly to not have coverage of semaphore
use in bad contexts.
Linus
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 2:52 ` Linus Torvalds
@ 2014-02-12 4:03 ` Dave Jones
-1 siblings, 0 replies; 132+ messages in thread
From: Dave Jones @ 2014-02-12 4:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Al Viro, Eric Sandeen, Dave Chinner, Linux Kernel, xfs
On Tue, Feb 11, 2014 at 06:52:19PM -0800, Linus Torvalds wrote:
> On Tue, Feb 11, 2014 at 5:09 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > Slap the check in vfs_create(), see if interrupts had been disabled by it or
> > by something in ->create(). Since it's reproducible...
>
> path_openat() starts off with a get_empty_filp(), which allocates a
> file pointer with GFP_KERNEL. So that should have triggered the
> might_sleep warning if irq's were already disabled at that point.
>
> So it's not before that - in particular, it's not in the signal
> handling or do_coredump() paths.
>
> Also, at least xfs_buf_lock() - which is much deeper in that chain -
> does a down(&bp->b_sema). I'm disguested that that doesn't have a
> might_sleep() in it.
>
> Dave, mind adding a "might_sleep()" to the top of
> "down[_interruptible]()". It's silly to not have coverage of semaphore
> use in bad contexts.
Added those, didn't trigger. Neither did Al's suggestion.
Slightly different trace, but still from the coredump path.
Dave
[ 3111.403822] BUG: sleeping function called from invalid context at mm/mempool.c:203
[ 3111.404414] in_atomic(): 0, irqs_disabled(): 1, pid: 19213, name: trinity-c46
[ 3111.404884] 5 locks held by trinity-c46/19213:
[ 3111.405354] #0: (sb_writers#9){......}, at: [<ffffffff8d2220c5>] do_coredump+0xe05/0xf60
[ 3111.405862] #1: (shrinker_rwsem){......}, at: [<ffffffff8d1644af>] shrink_slab+0x3f/0x180
[ 3111.406374] #2: (&type->s_umount_key#30){......}, at: [<ffffffff8d1c0db4>] grab_super_passive+0x44/0x90
[ 3111.406905] #3: (&pag->pag_ici_reclaim_lock){......}, at: [<ffffffffc031eb1a>] xfs_reclaim_inodes_ag+0x31a/0x430 [xfs]
[ 3111.407466] #4: (&(&ip->i_lock)->mr_lock){......}, at: [<ffffffffc037047f>] xfs_ilock+0x16f/0x1b0 [xfs]
[ 3111.408039] CPU: 0 PID: 19213 Comm: trinity-c46 Not tainted 3.14.0-rc2+ #113
[ 3111.409779] ffffffff8da3fde6 000000004f998871 ffff88023715cce0 ffffffff8d72b091
[ 3111.410396] 0000000000000000 ffff88023715cd08 ffffffff8d09ddb5 0000000000000010
[ 3111.411021] ffff880243566288 0000000000000008 ffff88023715cd88 ffffffff8d1534f3
[ 3111.411656] Call Trace:
[ 3111.412283] [<ffffffff8d72b091>] dump_stack+0x4e/0x7a
[ 3111.412922] [<ffffffff8d09ddb5>] __might_sleep+0x105/0x150
[ 3111.413562] [<ffffffff8d1534f3>] mempool_alloc+0xa3/0x170
[ 3111.414202] [<ffffffff8d1f9036>] bio_alloc_bioset+0x156/0x210
[ 3111.414855] [<ffffffffc0314231>] _xfs_buf_ioapply+0x1c1/0x3c0 [xfs]
[ 3111.415517] [<ffffffffc03858f2>] ? xlog_bdstrat+0x22/0x60 [xfs]
[ 3111.416175] [<ffffffffc031449b>] xfs_buf_iorequest+0x6b/0xf0 [xfs]
[ 3111.416843] [<ffffffffc03858f2>] xlog_bdstrat+0x22/0x60 [xfs]
[ 3111.417509] [<ffffffffc0387a87>] xlog_sync+0x3a7/0x5b0 [xfs]
[ 3111.418175] [<ffffffffc0387d9f>] xlog_state_release_iclog+0x10f/0x120 [xfs]
[ 3111.418846] [<ffffffffc0388840>] xlog_write+0x6f0/0x800 [xfs]
[ 3111.419518] [<ffffffffc038a061>] xlog_cil_push+0x2f1/0x410 [xfs]
[ 3111.420195] [<ffffffffc038a948>] xlog_cil_force_lsn+0x1d8/0x210 [xfs]
[ 3111.420865] [<ffffffff8d1a6cd9>] ? __bit_spin_unlock.constprop.66+0x19/0x40
[ 3111.421551] [<ffffffffc0389413>] _xfs_log_force_lsn+0x93/0x340 [xfs]
[ 3111.422239] [<ffffffffc03896ee>] xfs_log_force_lsn+0x2e/0xb0 [xfs]
[ 3111.422932] [<ffffffffc0374209>] ? xfs_iunpin_wait+0x19/0x20 [xfs]
[ 3111.423625] [<ffffffffc0370b50>] __xfs_iunpin_wait+0xd0/0x1a0 [xfs]
[ 3111.424310] [<ffffffff8d0b9dc0>] ? autoremove_wake_function+0x40/0x40
[ 3111.425008] [<ffffffffc0374209>] xfs_iunpin_wait+0x19/0x20 [xfs]
[ 3111.425705] [<ffffffffc031e50c>] xfs_reclaim_inode+0x8c/0x380 [xfs]
[ 3111.426405] [<ffffffffc031ea7b>] xfs_reclaim_inodes_ag+0x27b/0x430 [xfs]
[ 3111.427104] [<ffffffffc031e900>] ? xfs_reclaim_inodes_ag+0x100/0x430 [xfs]
[ 3111.427797] [<ffffffffc031ed13>] xfs_reclaim_inodes_nr+0x33/0x40 [xfs]
[ 3111.428481] [<ffffffffc032afa5>] xfs_fs_free_cached_objects+0x15/0x20 [xfs]
[ 3111.429150] [<ffffffff8d1c107c>] super_cache_scan+0x16c/0x180
[ 3111.429824] [<ffffffff8d16225b>] shrink_slab_node+0x14b/0x2e0
[ 3111.430489] [<ffffffff8d1644af>] ? shrink_slab+0x3f/0x180
[ 3111.431146] [<ffffffff8d1644fe>] shrink_slab+0x8e/0x180
[ 3111.431796] [<ffffffff8d1677c6>] try_to_free_pages+0x516/0x970
[ 3111.432436] [<ffffffff8d1f2c57>] ? __set_page_dirty+0x27/0xc0
[ 3111.433065] [<ffffffff8d15af19>] __alloc_pages_nodemask+0x7a9/0xb00
[ 3111.433689] [<ffffffff8d19e806>] alloc_pages_current+0x106/0x1f0
[ 3111.434304] [<ffffffff8d040cb7>] ? pte_alloc_one+0x17/0x80
[ 3111.434911] [<ffffffff8d040cb7>] pte_alloc_one+0x17/0x80
[ 3111.435510] [<ffffffff8d17b4a7>] __pte_alloc+0x27/0x130
[ 3111.436098] [<ffffffff8d17effc>] handle_mm_fault+0xafc/0xbb0
[ 3111.436681] [<ffffffff8d17f27e>] __get_user_pages+0x1ce/0x620
[ 3111.437254] [<ffffffff8d17f984>] get_dump_page+0x54/0x80
[ 3111.437810] [<ffffffff8d219da9>] elf_core_dump+0x12d9/0x1420
[ 3111.438356] [<ffffffff8d219330>] ? elf_core_dump+0x860/0x1420
[ 3111.438884] [<ffffffff8d221ec2>] do_coredump+0xc02/0xf60
[ 3111.439398] [<ffffffff8d081358>] get_signal_to_deliver+0x2b8/0x6b0
[ 3111.439898] [<ffffffff8d0024d7>] do_signal+0x57/0x9d0
[ 3111.440386] [<ffffffff8d11117e>] ? __acct_update_integrals+0x8e/0x120
[ 3111.440873] [<ffffffff8d73a29b>] ? preempt_count_sub+0x6b/0xf0
[ 3111.441357] [<ffffffff8d735ae1>] ? _raw_spin_unlock+0x31/0x50
[ 3111.441833] [<ffffffff8d0ab671>] ? vtime_account_user+0x91/0xa0
[ 3111.442307] [<ffffffff8d14f59b>] ? context_tracking_user_exit+0x9b/0x100
[ 3111.442783] [<ffffffff8d002eac>] do_notify_resume+0x5c/0xa0
[ 3111.443260] [<ffffffff8d736806>] retint_signal+0x46/0x90
[ 3111.443773] ------------[ cut here ]------------
[ 3111.444248] WARNING: CPU: 0 PID: 19213 at block/blk.h:227 generic_make_request_checks+0x33f/0x460()
[ 3111.444742] Modules linked in: fuse can_bcm can_raw scsi_transport_iscsi ipt_ULOG nfnetlink nfc caif_socket caif af_802154 phonet af_rxrpc can pppoe pppox ppp_generic slhc irda crc_ccitt rds rose x25 atm netrom appletalk ipx p8023 psnap p8022 llc ax25 cfg80211 xfs libcrc32c coretemp hwmon x86_pkg_temp_thermal kvm_intel kvm crct10dif_pclmul crc32c_intel ghash_clmulni_intel snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic microcode serio_raw pcspkr btusb bluetooth 6lowpan_iphc rfkill usb_debug snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm e1000e ptp pps_core shpchp snd_timer snd soundcore
[ 3111.447600] CPU: 0 PID: 19213 Comm: trinity-c46 Not tainted 3.14.0-rc2+ #113
[ 3111.449427] 0000000000000009 000000004f998871 ffff88023715cc90 ffffffff8d72b091
[ 3111.450062] 0000000000000000 ffff88023715ccc8 ffffffff8d06d0cd ffff8801ef3a1440
[ 3111.450697] 00000000ffffffff 00000000197e5088 0000000000800005 ffff88024091b740
[ 3111.451339] Call Trace:
[ 3111.451968] [<ffffffff8d72b091>] dump_stack+0x4e/0x7a
[ 3111.452608] [<ffffffff8d06d0cd>] warn_slowpath_common+0x7d/0xa0
[ 3111.453247] [<ffffffff8d06d1fa>] warn_slowpath_null+0x1a/0x20
[ 3111.453882] [<ffffffff8d2e821f>] generic_make_request_checks+0x33f/0x460
[ 3111.454523] [<ffffffff8d2e8367>] generic_make_request+0x27/0x130
[ 3111.455159] [<ffffffff8d2e84e8>] submit_bio+0x78/0x160
[ 3111.455790] [<ffffffff8d1f9060>] ? bio_alloc_bioset+0x180/0x210
[ 3111.456432] [<ffffffffc031432b>] _xfs_buf_ioapply+0x2bb/0x3c0 [xfs]
[ 3111.457179] [<ffffffffc03858f2>] ? xlog_bdstrat+0x22/0x60 [xfs]
[ 3111.457825] [<ffffffffc031449b>] xfs_buf_iorequest+0x6b/0xf0 [xfs]
[ 3111.458472] [<ffffffffc03858f2>] xlog_bdstrat+0x22/0x60 [xfs]
[ 3111.459120] [<ffffffffc0387a87>] xlog_sync+0x3a7/0x5b0 [xfs]
[ 3111.459768] [<ffffffffc0387d9f>] xlog_state_release_iclog+0x10f/0x120 [xfs]
[ 3111.460422] [<ffffffffc0388840>] xlog_write+0x6f0/0x800 [xfs]
[ 3111.461069] [<ffffffffc038a061>] xlog_cil_push+0x2f1/0x410 [xfs]
[ 3111.461714] [<ffffffffc038a948>] xlog_cil_force_lsn+0x1d8/0x210 [xfs]
[ 3111.462349] [<ffffffff8d1a6cd9>] ? __bit_spin_unlock.constprop.66+0x19/0x40
[ 3111.463001] [<ffffffffc0389413>] _xfs_log_force_lsn+0x93/0x340 [xfs]
[ 3111.463654] [<ffffffffc03896ee>] xfs_log_force_lsn+0x2e/0xb0 [xfs]
[ 3111.464311] [<ffffffffc0374209>] ? xfs_iunpin_wait+0x19/0x20 [xfs]
[ 3111.464966] [<ffffffffc0370b50>] __xfs_iunpin_wait+0xd0/0x1a0 [xfs]
[ 3111.465609] [<ffffffff8d0b9dc0>] ? autoremove_wake_function+0x40/0x40
[ 3111.466266] [<ffffffffc0374209>] xfs_iunpin_wait+0x19/0x20 [xfs]
[ 3111.466920] [<ffffffffc031e50c>] xfs_reclaim_inode+0x8c/0x380 [xfs]
[ 3111.467573] [<ffffffffc031ea7b>] xfs_reclaim_inodes_ag+0x27b/0x430 [xfs]
[ 3111.468226] [<ffffffffc031e900>] ? xfs_reclaim_inodes_ag+0x100/0x430 [xfs]
[ 3111.468881] [<ffffffffc031ed13>] xfs_reclaim_inodes_nr+0x33/0x40 [xfs]
[ 3111.469535] [<ffffffffc032afa5>] xfs_fs_free_cached_objects+0x15/0x20 [xfs]
[ 3111.470182] [<ffffffff8d1c107c>] super_cache_scan+0x16c/0x180
[ 3111.470831] [<ffffffff8d16225b>] shrink_slab_node+0x14b/0x2e0
[ 3111.471478] [<ffffffff8d1644af>] ? shrink_slab+0x3f/0x180
[ 3111.472121] [<ffffffff8d1644fe>] shrink_slab+0x8e/0x180
[ 3111.472761] [<ffffffff8d1677c6>] try_to_free_pages+0x516/0x970
[ 3111.473401] [<ffffffff8d1f2c57>] ? __set_page_dirty+0x27/0xc0
[ 3111.474040] [<ffffffff8d15af19>] __alloc_pages_nodemask+0x7a9/0xb00
[ 3111.474670] [<ffffffff8d19e806>] alloc_pages_current+0x106/0x1f0
[ 3111.475285] [<ffffffff8d040cb7>] ? pte_alloc_one+0x17/0x80
[ 3111.475879] [<ffffffff8d040cb7>] pte_alloc_one+0x17/0x80
[ 3111.476455] [<ffffffff8d17b4a7>] __pte_alloc+0x27/0x130
[ 3111.477012] [<ffffffff8d17effc>] handle_mm_fault+0xafc/0xbb0
[ 3111.477549] [<ffffffff8d17f27e>] __get_user_pages+0x1ce/0x620
[ 3111.478072] [<ffffffff8d17f984>] get_dump_page+0x54/0x80
[ 3111.478576] [<ffffffff8d219da9>] elf_core_dump+0x12d9/0x1420
[ 3111.479065] [<ffffffff8d219330>] ? elf_core_dump+0x860/0x1420
[ 3111.479546] [<ffffffff8d221ec2>] do_coredump+0xc02/0xf60
[ 3111.480021] [<ffffffff8d081358>] get_signal_to_deliver+0x2b8/0x6b0
[ 3111.480498] [<ffffffff8d0024d7>] do_signal+0x57/0x9d0
[ 3111.480964] [<ffffffff8d11117e>] ? __acct_update_integrals+0x8e/0x120
[ 3111.481435] [<ffffffff8d73a29b>] ? preempt_count_sub+0x6b/0xf0
[ 3111.481906] [<ffffffff8d735ae1>] ? _raw_spin_unlock+0x31/0x50
[ 3111.482377] [<ffffffff8d0ab671>] ? vtime_account_user+0x91/0xa0
[ 3111.482847] [<ffffffff8d14f59b>] ? context_tracking_user_exit+0x9b/0x100
[ 3111.483324] [<ffffffff8d002eac>] do_notify_resume+0x5c/0xa0
[ 3111.483800] [<ffffffff8d736806>] retint_signal+0x46/0x90
[ 3111.484274] ---[ end trace 8cc272739908f779 ]---
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-12 4:03 ` Dave Jones
0 siblings, 0 replies; 132+ messages in thread
From: Dave Jones @ 2014-02-12 4:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: xfs, Eric Sandeen, Al Viro, Linux Kernel
On Tue, Feb 11, 2014 at 06:52:19PM -0800, Linus Torvalds wrote:
> On Tue, Feb 11, 2014 at 5:09 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > Slap the check in vfs_create(), see if interrupts had been disabled by it or
> > by something in ->create(). Since it's reproducible...
>
> path_openat() starts off with a get_empty_filp(), which allocates a
> file pointer with GFP_KERNEL. So that should have triggered the
> might_sleep warning if irq's were already disabled at that point.
>
> So it's not before that - in particular, it's not in the signal
> handling or do_coredump() paths.
>
> Also, at least xfs_buf_lock() - which is much deeper in that chain -
> does a down(&bp->b_sema). I'm disguested that that doesn't have a
> might_sleep() in it.
>
> Dave, mind adding a "might_sleep()" to the top of
> "down[_interruptible]()". It's silly to not have coverage of semaphore
> use in bad contexts.
Added those, didn't trigger. Neither did Al's suggestion.
Slightly different trace, but still from the coredump path.
Dave
[ 3111.403822] BUG: sleeping function called from invalid context at mm/mempool.c:203
[ 3111.404414] in_atomic(): 0, irqs_disabled(): 1, pid: 19213, name: trinity-c46
[ 3111.404884] 5 locks held by trinity-c46/19213:
[ 3111.405354] #0: (sb_writers#9){......}, at: [<ffffffff8d2220c5>] do_coredump+0xe05/0xf60
[ 3111.405862] #1: (shrinker_rwsem){......}, at: [<ffffffff8d1644af>] shrink_slab+0x3f/0x180
[ 3111.406374] #2: (&type->s_umount_key#30){......}, at: [<ffffffff8d1c0db4>] grab_super_passive+0x44/0x90
[ 3111.406905] #3: (&pag->pag_ici_reclaim_lock){......}, at: [<ffffffffc031eb1a>] xfs_reclaim_inodes_ag+0x31a/0x430 [xfs]
[ 3111.407466] #4: (&(&ip->i_lock)->mr_lock){......}, at: [<ffffffffc037047f>] xfs_ilock+0x16f/0x1b0 [xfs]
[ 3111.408039] CPU: 0 PID: 19213 Comm: trinity-c46 Not tainted 3.14.0-rc2+ #113
[ 3111.409779] ffffffff8da3fde6 000000004f998871 ffff88023715cce0 ffffffff8d72b091
[ 3111.410396] 0000000000000000 ffff88023715cd08 ffffffff8d09ddb5 0000000000000010
[ 3111.411021] ffff880243566288 0000000000000008 ffff88023715cd88 ffffffff8d1534f3
[ 3111.411656] Call Trace:
[ 3111.412283] [<ffffffff8d72b091>] dump_stack+0x4e/0x7a
[ 3111.412922] [<ffffffff8d09ddb5>] __might_sleep+0x105/0x150
[ 3111.413562] [<ffffffff8d1534f3>] mempool_alloc+0xa3/0x170
[ 3111.414202] [<ffffffff8d1f9036>] bio_alloc_bioset+0x156/0x210
[ 3111.414855] [<ffffffffc0314231>] _xfs_buf_ioapply+0x1c1/0x3c0 [xfs]
[ 3111.415517] [<ffffffffc03858f2>] ? xlog_bdstrat+0x22/0x60 [xfs]
[ 3111.416175] [<ffffffffc031449b>] xfs_buf_iorequest+0x6b/0xf0 [xfs]
[ 3111.416843] [<ffffffffc03858f2>] xlog_bdstrat+0x22/0x60 [xfs]
[ 3111.417509] [<ffffffffc0387a87>] xlog_sync+0x3a7/0x5b0 [xfs]
[ 3111.418175] [<ffffffffc0387d9f>] xlog_state_release_iclog+0x10f/0x120 [xfs]
[ 3111.418846] [<ffffffffc0388840>] xlog_write+0x6f0/0x800 [xfs]
[ 3111.419518] [<ffffffffc038a061>] xlog_cil_push+0x2f1/0x410 [xfs]
[ 3111.420195] [<ffffffffc038a948>] xlog_cil_force_lsn+0x1d8/0x210 [xfs]
[ 3111.420865] [<ffffffff8d1a6cd9>] ? __bit_spin_unlock.constprop.66+0x19/0x40
[ 3111.421551] [<ffffffffc0389413>] _xfs_log_force_lsn+0x93/0x340 [xfs]
[ 3111.422239] [<ffffffffc03896ee>] xfs_log_force_lsn+0x2e/0xb0 [xfs]
[ 3111.422932] [<ffffffffc0374209>] ? xfs_iunpin_wait+0x19/0x20 [xfs]
[ 3111.423625] [<ffffffffc0370b50>] __xfs_iunpin_wait+0xd0/0x1a0 [xfs]
[ 3111.424310] [<ffffffff8d0b9dc0>] ? autoremove_wake_function+0x40/0x40
[ 3111.425008] [<ffffffffc0374209>] xfs_iunpin_wait+0x19/0x20 [xfs]
[ 3111.425705] [<ffffffffc031e50c>] xfs_reclaim_inode+0x8c/0x380 [xfs]
[ 3111.426405] [<ffffffffc031ea7b>] xfs_reclaim_inodes_ag+0x27b/0x430 [xfs]
[ 3111.427104] [<ffffffffc031e900>] ? xfs_reclaim_inodes_ag+0x100/0x430 [xfs]
[ 3111.427797] [<ffffffffc031ed13>] xfs_reclaim_inodes_nr+0x33/0x40 [xfs]
[ 3111.428481] [<ffffffffc032afa5>] xfs_fs_free_cached_objects+0x15/0x20 [xfs]
[ 3111.429150] [<ffffffff8d1c107c>] super_cache_scan+0x16c/0x180
[ 3111.429824] [<ffffffff8d16225b>] shrink_slab_node+0x14b/0x2e0
[ 3111.430489] [<ffffffff8d1644af>] ? shrink_slab+0x3f/0x180
[ 3111.431146] [<ffffffff8d1644fe>] shrink_slab+0x8e/0x180
[ 3111.431796] [<ffffffff8d1677c6>] try_to_free_pages+0x516/0x970
[ 3111.432436] [<ffffffff8d1f2c57>] ? __set_page_dirty+0x27/0xc0
[ 3111.433065] [<ffffffff8d15af19>] __alloc_pages_nodemask+0x7a9/0xb00
[ 3111.433689] [<ffffffff8d19e806>] alloc_pages_current+0x106/0x1f0
[ 3111.434304] [<ffffffff8d040cb7>] ? pte_alloc_one+0x17/0x80
[ 3111.434911] [<ffffffff8d040cb7>] pte_alloc_one+0x17/0x80
[ 3111.435510] [<ffffffff8d17b4a7>] __pte_alloc+0x27/0x130
[ 3111.436098] [<ffffffff8d17effc>] handle_mm_fault+0xafc/0xbb0
[ 3111.436681] [<ffffffff8d17f27e>] __get_user_pages+0x1ce/0x620
[ 3111.437254] [<ffffffff8d17f984>] get_dump_page+0x54/0x80
[ 3111.437810] [<ffffffff8d219da9>] elf_core_dump+0x12d9/0x1420
[ 3111.438356] [<ffffffff8d219330>] ? elf_core_dump+0x860/0x1420
[ 3111.438884] [<ffffffff8d221ec2>] do_coredump+0xc02/0xf60
[ 3111.439398] [<ffffffff8d081358>] get_signal_to_deliver+0x2b8/0x6b0
[ 3111.439898] [<ffffffff8d0024d7>] do_signal+0x57/0x9d0
[ 3111.440386] [<ffffffff8d11117e>] ? __acct_update_integrals+0x8e/0x120
[ 3111.440873] [<ffffffff8d73a29b>] ? preempt_count_sub+0x6b/0xf0
[ 3111.441357] [<ffffffff8d735ae1>] ? _raw_spin_unlock+0x31/0x50
[ 3111.441833] [<ffffffff8d0ab671>] ? vtime_account_user+0x91/0xa0
[ 3111.442307] [<ffffffff8d14f59b>] ? context_tracking_user_exit+0x9b/0x100
[ 3111.442783] [<ffffffff8d002eac>] do_notify_resume+0x5c/0xa0
[ 3111.443260] [<ffffffff8d736806>] retint_signal+0x46/0x90
[ 3111.443773] ------------[ cut here ]------------
[ 3111.444248] WARNING: CPU: 0 PID: 19213 at block/blk.h:227 generic_make_request_checks+0x33f/0x460()
[ 3111.444742] Modules linked in: fuse can_bcm can_raw scsi_transport_iscsi ipt_ULOG nfnetlink nfc caif_socket caif af_802154 phonet af_rxrpc can pppoe pppox ppp_generic slhc irda crc_ccitt rds rose x25 atm netrom appletalk ipx p8023 psnap p8022 llc ax25 cfg80211 xfs libcrc32c coretemp hwmon x86_pkg_temp_thermal kvm_intel kvm crct10dif_pclmul crc32c_intel ghash_clmulni_intel snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic microcode serio_raw pcspkr btusb bluetooth 6lowpan_iphc rfkill usb_debug snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm e1000e ptp pps_core shpchp snd_timer snd soundcore
[ 3111.447600] CPU: 0 PID: 19213 Comm: trinity-c46 Not tainted 3.14.0-rc2+ #113
[ 3111.449427] 0000000000000009 000000004f998871 ffff88023715cc90 ffffffff8d72b091
[ 3111.450062] 0000000000000000 ffff88023715ccc8 ffffffff8d06d0cd ffff8801ef3a1440
[ 3111.450697] 00000000ffffffff 00000000197e5088 0000000000800005 ffff88024091b740
[ 3111.451339] Call Trace:
[ 3111.451968] [<ffffffff8d72b091>] dump_stack+0x4e/0x7a
[ 3111.452608] [<ffffffff8d06d0cd>] warn_slowpath_common+0x7d/0xa0
[ 3111.453247] [<ffffffff8d06d1fa>] warn_slowpath_null+0x1a/0x20
[ 3111.453882] [<ffffffff8d2e821f>] generic_make_request_checks+0x33f/0x460
[ 3111.454523] [<ffffffff8d2e8367>] generic_make_request+0x27/0x130
[ 3111.455159] [<ffffffff8d2e84e8>] submit_bio+0x78/0x160
[ 3111.455790] [<ffffffff8d1f9060>] ? bio_alloc_bioset+0x180/0x210
[ 3111.456432] [<ffffffffc031432b>] _xfs_buf_ioapply+0x2bb/0x3c0 [xfs]
[ 3111.457179] [<ffffffffc03858f2>] ? xlog_bdstrat+0x22/0x60 [xfs]
[ 3111.457825] [<ffffffffc031449b>] xfs_buf_iorequest+0x6b/0xf0 [xfs]
[ 3111.458472] [<ffffffffc03858f2>] xlog_bdstrat+0x22/0x60 [xfs]
[ 3111.459120] [<ffffffffc0387a87>] xlog_sync+0x3a7/0x5b0 [xfs]
[ 3111.459768] [<ffffffffc0387d9f>] xlog_state_release_iclog+0x10f/0x120 [xfs]
[ 3111.460422] [<ffffffffc0388840>] xlog_write+0x6f0/0x800 [xfs]
[ 3111.461069] [<ffffffffc038a061>] xlog_cil_push+0x2f1/0x410 [xfs]
[ 3111.461714] [<ffffffffc038a948>] xlog_cil_force_lsn+0x1d8/0x210 [xfs]
[ 3111.462349] [<ffffffff8d1a6cd9>] ? __bit_spin_unlock.constprop.66+0x19/0x40
[ 3111.463001] [<ffffffffc0389413>] _xfs_log_force_lsn+0x93/0x340 [xfs]
[ 3111.463654] [<ffffffffc03896ee>] xfs_log_force_lsn+0x2e/0xb0 [xfs]
[ 3111.464311] [<ffffffffc0374209>] ? xfs_iunpin_wait+0x19/0x20 [xfs]
[ 3111.464966] [<ffffffffc0370b50>] __xfs_iunpin_wait+0xd0/0x1a0 [xfs]
[ 3111.465609] [<ffffffff8d0b9dc0>] ? autoremove_wake_function+0x40/0x40
[ 3111.466266] [<ffffffffc0374209>] xfs_iunpin_wait+0x19/0x20 [xfs]
[ 3111.466920] [<ffffffffc031e50c>] xfs_reclaim_inode+0x8c/0x380 [xfs]
[ 3111.467573] [<ffffffffc031ea7b>] xfs_reclaim_inodes_ag+0x27b/0x430 [xfs]
[ 3111.468226] [<ffffffffc031e900>] ? xfs_reclaim_inodes_ag+0x100/0x430 [xfs]
[ 3111.468881] [<ffffffffc031ed13>] xfs_reclaim_inodes_nr+0x33/0x40 [xfs]
[ 3111.469535] [<ffffffffc032afa5>] xfs_fs_free_cached_objects+0x15/0x20 [xfs]
[ 3111.470182] [<ffffffff8d1c107c>] super_cache_scan+0x16c/0x180
[ 3111.470831] [<ffffffff8d16225b>] shrink_slab_node+0x14b/0x2e0
[ 3111.471478] [<ffffffff8d1644af>] ? shrink_slab+0x3f/0x180
[ 3111.472121] [<ffffffff8d1644fe>] shrink_slab+0x8e/0x180
[ 3111.472761] [<ffffffff8d1677c6>] try_to_free_pages+0x516/0x970
[ 3111.473401] [<ffffffff8d1f2c57>] ? __set_page_dirty+0x27/0xc0
[ 3111.474040] [<ffffffff8d15af19>] __alloc_pages_nodemask+0x7a9/0xb00
[ 3111.474670] [<ffffffff8d19e806>] alloc_pages_current+0x106/0x1f0
[ 3111.475285] [<ffffffff8d040cb7>] ? pte_alloc_one+0x17/0x80
[ 3111.475879] [<ffffffff8d040cb7>] pte_alloc_one+0x17/0x80
[ 3111.476455] [<ffffffff8d17b4a7>] __pte_alloc+0x27/0x130
[ 3111.477012] [<ffffffff8d17effc>] handle_mm_fault+0xafc/0xbb0
[ 3111.477549] [<ffffffff8d17f27e>] __get_user_pages+0x1ce/0x620
[ 3111.478072] [<ffffffff8d17f984>] get_dump_page+0x54/0x80
[ 3111.478576] [<ffffffff8d219da9>] elf_core_dump+0x12d9/0x1420
[ 3111.479065] [<ffffffff8d219330>] ? elf_core_dump+0x860/0x1420
[ 3111.479546] [<ffffffff8d221ec2>] do_coredump+0xc02/0xf60
[ 3111.480021] [<ffffffff8d081358>] get_signal_to_deliver+0x2b8/0x6b0
[ 3111.480498] [<ffffffff8d0024d7>] do_signal+0x57/0x9d0
[ 3111.480964] [<ffffffff8d11117e>] ? __acct_update_integrals+0x8e/0x120
[ 3111.481435] [<ffffffff8d73a29b>] ? preempt_count_sub+0x6b/0xf0
[ 3111.481906] [<ffffffff8d735ae1>] ? _raw_spin_unlock+0x31/0x50
[ 3111.482377] [<ffffffff8d0ab671>] ? vtime_account_user+0x91/0xa0
[ 3111.482847] [<ffffffff8d14f59b>] ? context_tracking_user_exit+0x9b/0x100
[ 3111.483324] [<ffffffff8d002eac>] do_notify_resume+0x5c/0xa0
[ 3111.483800] [<ffffffff8d736806>] retint_signal+0x46/0x90
[ 3111.484274] ---[ end trace 8cc272739908f779 ]---
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 4:03 ` Dave Jones
@ 2014-02-12 4:22 ` Al Viro
-1 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-12 4:22 UTC (permalink / raw)
To: Dave Jones, Linus Torvalds, Eric Sandeen, Dave Chinner,
Linux Kernel, xfs
On Tue, Feb 11, 2014 at 11:03:58PM -0500, Dave Jones wrote:
> [ 3111.414202] [<ffffffff8d1f9036>] bio_alloc_bioset+0x156/0x210
> [ 3111.414855] [<ffffffffc0314231>] _xfs_buf_ioapply+0x1c1/0x3c0 [xfs]
> [ 3111.415517] [<ffffffffc03858f2>] ? xlog_bdstrat+0x22/0x60 [xfs]
> [ 3111.416175] [<ffffffffc031449b>] xfs_buf_iorequest+0x6b/0xf0 [xfs]
> [ 3111.416843] [<ffffffffc03858f2>] xlog_bdstrat+0x22/0x60 [xfs]
> [ 3111.417509] [<ffffffffc0387a87>] xlog_sync+0x3a7/0x5b0 [xfs]
> [ 3111.418175] [<ffffffffc0387d9f>] xlog_state_release_iclog+0x10f/0x120 [xfs]
> [ 3111.418846] [<ffffffffc0388840>] xlog_write+0x6f0/0x800 [xfs]
> [ 3111.419518] [<ffffffffc038a061>] xlog_cil_push+0x2f1/0x410 [xfs]
Very interesting. The first thing xlog_cil_push() is doing is blocking
kmalloc(). So at that point it still hadn't been atomic. I'd probably
slap may_sleep() in the beginning of xlog_sync() and see if that triggers...
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-12 4:22 ` Al Viro
0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-12 4:22 UTC (permalink / raw)
To: Dave Jones, Linus Torvalds, Eric Sandeen, Dave Chinner,
Linux Kernel, xfs
On Tue, Feb 11, 2014 at 11:03:58PM -0500, Dave Jones wrote:
> [ 3111.414202] [<ffffffff8d1f9036>] bio_alloc_bioset+0x156/0x210
> [ 3111.414855] [<ffffffffc0314231>] _xfs_buf_ioapply+0x1c1/0x3c0 [xfs]
> [ 3111.415517] [<ffffffffc03858f2>] ? xlog_bdstrat+0x22/0x60 [xfs]
> [ 3111.416175] [<ffffffffc031449b>] xfs_buf_iorequest+0x6b/0xf0 [xfs]
> [ 3111.416843] [<ffffffffc03858f2>] xlog_bdstrat+0x22/0x60 [xfs]
> [ 3111.417509] [<ffffffffc0387a87>] xlog_sync+0x3a7/0x5b0 [xfs]
> [ 3111.418175] [<ffffffffc0387d9f>] xlog_state_release_iclog+0x10f/0x120 [xfs]
> [ 3111.418846] [<ffffffffc0388840>] xlog_write+0x6f0/0x800 [xfs]
> [ 3111.419518] [<ffffffffc038a061>] xlog_cil_push+0x2f1/0x410 [xfs]
Very interesting. The first thing xlog_cil_push() is doing is blocking
kmalloc(). So at that point it still hadn't been atomic. I'd probably
slap may_sleep() in the beginning of xlog_sync() and see if that triggers...
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 4:22 ` Al Viro
@ 2014-02-12 5:40 ` Dave Chinner
-1 siblings, 0 replies; 132+ messages in thread
From: Dave Chinner @ 2014-02-12 5:40 UTC (permalink / raw)
To: Al Viro; +Cc: Dave Jones, Linus Torvalds, Eric Sandeen, Linux Kernel, xfs
On Wed, Feb 12, 2014 at 04:22:15AM +0000, Al Viro wrote:
> On Tue, Feb 11, 2014 at 11:03:58PM -0500, Dave Jones wrote:
> > [ 3111.414202] [<ffffffff8d1f9036>] bio_alloc_bioset+0x156/0x210
> > [ 3111.414855] [<ffffffffc0314231>] _xfs_buf_ioapply+0x1c1/0x3c0 [xfs]
> > [ 3111.415517] [<ffffffffc03858f2>] ? xlog_bdstrat+0x22/0x60 [xfs]
> > [ 3111.416175] [<ffffffffc031449b>] xfs_buf_iorequest+0x6b/0xf0 [xfs]
> > [ 3111.416843] [<ffffffffc03858f2>] xlog_bdstrat+0x22/0x60 [xfs]
> > [ 3111.417509] [<ffffffffc0387a87>] xlog_sync+0x3a7/0x5b0 [xfs]
> > [ 3111.418175] [<ffffffffc0387d9f>] xlog_state_release_iclog+0x10f/0x120 [xfs]
> > [ 3111.418846] [<ffffffffc0388840>] xlog_write+0x6f0/0x800 [xfs]
> > [ 3111.419518] [<ffffffffc038a061>] xlog_cil_push+0x2f1/0x410 [xfs]
>
> Very interesting. The first thing xlog_cil_push() is doing is blocking
> kmalloc(). So at that point it still hadn't been atomic. I'd probably
> slap may_sleep() in the beginning of xlog_sync() and see if that triggers...
None of the XFS code disables interrupts in that path, not does is
call outside XFS except to dispatch IO. The stack is pretty deep at
this point and I know that the standard (non stacked) IO stack can
consume >3kb of stack space when it gets down to having to do memory
reclaim during GFP_NOIO allocation at the lowest level of SCSI
drivers. Stack overruns typically show up with symptoms like we are
seeing.
Simple example with memory allocation follows. keep in mind that
memory reclaim uses a whole lot more stack if it is needed, and that
scheduling at this point requires about 1k of stack to be free for
the scheduler footprint, too.
FWIW, the blk-mq stuff seems to hae added 200-300 bytes of new stack
usage to the IO path....
$ sudo cat /sys/kernel/debug/tracing/stack_trace
Depth Size Location (45 entries)
----- ---- --------
0) 5944 40 zone_statistics+0xbd/0xc0
1) 5904 256 get_page_from_freelist+0x3a8/0x8a0
2) 5648 256 __alloc_pages_nodemask+0x143/0x8e0
3) 5392 80 alloc_pages_current+0xb2/0x170
4) 5312 64 new_slab+0x265/0x2e0
5) 5248 240 __slab_alloc+0x2fb/0x4c4
6) 5008 80 __kmalloc+0x133/0x180
7) 4928 112 virtqueue_add_sgs+0x2fe/0x520
8) 4816 288 __virtblk_add_req+0xd5/0x180
9) 4528 96 virtio_queue_rq+0xdd/0x1d0
10) 4432 112 __blk_mq_run_hw_queue+0x1c3/0x3c0
11) 4320 16 blk_mq_run_hw_queue+0x35/0x40
12) 4304 80 blk_mq_insert_requests+0xc5/0x120
13) 4224 96 blk_mq_flush_plug_list+0x129/0x140
14) 4128 112 blk_flush_plug_list+0xe7/0x240
15) 4016 32 blk_finish_plug+0x18/0x50
16) 3984 192 _xfs_buf_ioapply+0x30f/0x3b0
17) 3792 48 xfs_buf_iorequest+0x6f/0xc0
....
37) 928 16 xfs_vn_create+0x13/0x20
38) 912 64 vfs_create+0xb5/0xf0
39) 848 208 do_last.isra.53+0x6e0/0xd00
40) 640 176 path_openat+0xbe/0x620
41) 464 208 do_filp_open+0x43/0xa0
42) 256 112 do_sys_open+0x13c/0x230
43) 144 16 SyS_open+0x22/0x30
44) 128 128 system_call_fastpath+0x16/0x1b
Dave, before chasing ghosts, can you (like Eric originally asked)
turn on stack overrun detection?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-12 5:40 ` Dave Chinner
0 siblings, 0 replies; 132+ messages in thread
From: Dave Chinner @ 2014-02-12 5:40 UTC (permalink / raw)
To: Al Viro; +Cc: Dave Jones, Eric Sandeen, Linus Torvalds, Linux Kernel, xfs
On Wed, Feb 12, 2014 at 04:22:15AM +0000, Al Viro wrote:
> On Tue, Feb 11, 2014 at 11:03:58PM -0500, Dave Jones wrote:
> > [ 3111.414202] [<ffffffff8d1f9036>] bio_alloc_bioset+0x156/0x210
> > [ 3111.414855] [<ffffffffc0314231>] _xfs_buf_ioapply+0x1c1/0x3c0 [xfs]
> > [ 3111.415517] [<ffffffffc03858f2>] ? xlog_bdstrat+0x22/0x60 [xfs]
> > [ 3111.416175] [<ffffffffc031449b>] xfs_buf_iorequest+0x6b/0xf0 [xfs]
> > [ 3111.416843] [<ffffffffc03858f2>] xlog_bdstrat+0x22/0x60 [xfs]
> > [ 3111.417509] [<ffffffffc0387a87>] xlog_sync+0x3a7/0x5b0 [xfs]
> > [ 3111.418175] [<ffffffffc0387d9f>] xlog_state_release_iclog+0x10f/0x120 [xfs]
> > [ 3111.418846] [<ffffffffc0388840>] xlog_write+0x6f0/0x800 [xfs]
> > [ 3111.419518] [<ffffffffc038a061>] xlog_cil_push+0x2f1/0x410 [xfs]
>
> Very interesting. The first thing xlog_cil_push() is doing is blocking
> kmalloc(). So at that point it still hadn't been atomic. I'd probably
> slap may_sleep() in the beginning of xlog_sync() and see if that triggers...
None of the XFS code disables interrupts in that path, not does is
call outside XFS except to dispatch IO. The stack is pretty deep at
this point and I know that the standard (non stacked) IO stack can
consume >3kb of stack space when it gets down to having to do memory
reclaim during GFP_NOIO allocation at the lowest level of SCSI
drivers. Stack overruns typically show up with symptoms like we are
seeing.
Simple example with memory allocation follows. keep in mind that
memory reclaim uses a whole lot more stack if it is needed, and that
scheduling at this point requires about 1k of stack to be free for
the scheduler footprint, too.
FWIW, the blk-mq stuff seems to hae added 200-300 bytes of new stack
usage to the IO path....
$ sudo cat /sys/kernel/debug/tracing/stack_trace
Depth Size Location (45 entries)
----- ---- --------
0) 5944 40 zone_statistics+0xbd/0xc0
1) 5904 256 get_page_from_freelist+0x3a8/0x8a0
2) 5648 256 __alloc_pages_nodemask+0x143/0x8e0
3) 5392 80 alloc_pages_current+0xb2/0x170
4) 5312 64 new_slab+0x265/0x2e0
5) 5248 240 __slab_alloc+0x2fb/0x4c4
6) 5008 80 __kmalloc+0x133/0x180
7) 4928 112 virtqueue_add_sgs+0x2fe/0x520
8) 4816 288 __virtblk_add_req+0xd5/0x180
9) 4528 96 virtio_queue_rq+0xdd/0x1d0
10) 4432 112 __blk_mq_run_hw_queue+0x1c3/0x3c0
11) 4320 16 blk_mq_run_hw_queue+0x35/0x40
12) 4304 80 blk_mq_insert_requests+0xc5/0x120
13) 4224 96 blk_mq_flush_plug_list+0x129/0x140
14) 4128 112 blk_flush_plug_list+0xe7/0x240
15) 4016 32 blk_finish_plug+0x18/0x50
16) 3984 192 _xfs_buf_ioapply+0x30f/0x3b0
17) 3792 48 xfs_buf_iorequest+0x6f/0xc0
....
37) 928 16 xfs_vn_create+0x13/0x20
38) 912 64 vfs_create+0xb5/0xf0
39) 848 208 do_last.isra.53+0x6e0/0xd00
40) 640 176 path_openat+0xbe/0x620
41) 464 208 do_filp_open+0x43/0xa0
42) 256 112 do_sys_open+0x13c/0x230
43) 144 16 SyS_open+0x22/0x30
44) 128 128 system_call_fastpath+0x16/0x1b
Dave, before chasing ghosts, can you (like Eric originally asked)
turn on stack overrun detection?
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] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 5:40 ` Dave Chinner
@ 2014-02-12 5:50 ` Dave Jones
-1 siblings, 0 replies; 132+ messages in thread
From: Dave Jones @ 2014-02-12 5:50 UTC (permalink / raw)
To: Dave Chinner; +Cc: Al Viro, Linus Torvalds, Eric Sandeen, Linux Kernel, xfs
On Wed, Feb 12, 2014 at 04:40:43PM +1100, Dave Chinner wrote:
> None of the XFS code disables interrupts in that path, not does is
> call outside XFS except to dispatch IO. The stack is pretty deep at
> this point and I know that the standard (non stacked) IO stack can
> consume >3kb of stack space when it gets down to having to do memory
> reclaim during GFP_NOIO allocation at the lowest level of SCSI
> drivers. Stack overruns typically show up with symptoms like we are
> seeing.
> ..
>
> Dave, before chasing ghosts, can you (like Eric originally asked)
> turn on stack overrun detection?
CONFIG_DEBUG_STACKOVERFLOW ? Already turned on.
Dave
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-12 5:50 ` Dave Jones
0 siblings, 0 replies; 132+ messages in thread
From: Dave Jones @ 2014-02-12 5:50 UTC (permalink / raw)
To: Dave Chinner; +Cc: Eric Sandeen, xfs, Linus Torvalds, Al Viro, Linux Kernel
On Wed, Feb 12, 2014 at 04:40:43PM +1100, Dave Chinner wrote:
> None of the XFS code disables interrupts in that path, not does is
> call outside XFS except to dispatch IO. The stack is pretty deep at
> this point and I know that the standard (non stacked) IO stack can
> consume >3kb of stack space when it gets down to having to do memory
> reclaim during GFP_NOIO allocation at the lowest level of SCSI
> drivers. Stack overruns typically show up with symptoms like we are
> seeing.
> ..
>
> Dave, before chasing ghosts, can you (like Eric originally asked)
> turn on stack overrun detection?
CONFIG_DEBUG_STACKOVERFLOW ? Already turned on.
Dave
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 5:50 ` Dave Jones
@ 2014-02-12 6:10 ` Dave Chinner
-1 siblings, 0 replies; 132+ messages in thread
From: Dave Chinner @ 2014-02-12 6:10 UTC (permalink / raw)
To: Dave Jones, Al Viro, Linus Torvalds, Eric Sandeen, Linux Kernel, xfs
On Wed, Feb 12, 2014 at 12:50:27AM -0500, Dave Jones wrote:
> On Wed, Feb 12, 2014 at 04:40:43PM +1100, Dave Chinner wrote:
>
> > None of the XFS code disables interrupts in that path, not does is
> > call outside XFS except to dispatch IO. The stack is pretty deep at
> > this point and I know that the standard (non stacked) IO stack can
> > consume >3kb of stack space when it gets down to having to do memory
> > reclaim during GFP_NOIO allocation at the lowest level of SCSI
> > drivers. Stack overruns typically show up with symptoms like we are
> > seeing.
> > ..
> >
> > Dave, before chasing ghosts, can you (like Eric originally asked)
> > turn on stack overrun detection?
>
> CONFIG_DEBUG_STACKOVERFLOW ? Already turned on.
That only checks stack usage when an interrupt is taken. If no
interrupts are taken when stack usage is within 128 bytes of
overflow, then it doesn't catch it.
I tend to use CONFIG_DEBUG_STACK_USAGE=y as it records the maximum
stack usage of a process via canary overwrites and it records it in
do_exit(). I also use the stack tracer to record the largest stack
usage seen so I know exactly what code paths are approaching stack
overruns...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-12 6:10 ` Dave Chinner
0 siblings, 0 replies; 132+ messages in thread
From: Dave Chinner @ 2014-02-12 6:10 UTC (permalink / raw)
To: Dave Jones, Al Viro, Linus Torvalds, Eric Sandeen, Linux Kernel, xfs
On Wed, Feb 12, 2014 at 12:50:27AM -0500, Dave Jones wrote:
> On Wed, Feb 12, 2014 at 04:40:43PM +1100, Dave Chinner wrote:
>
> > None of the XFS code disables interrupts in that path, not does is
> > call outside XFS except to dispatch IO. The stack is pretty deep at
> > this point and I know that the standard (non stacked) IO stack can
> > consume >3kb of stack space when it gets down to having to do memory
> > reclaim during GFP_NOIO allocation at the lowest level of SCSI
> > drivers. Stack overruns typically show up with symptoms like we are
> > seeing.
> > ..
> >
> > Dave, before chasing ghosts, can you (like Eric originally asked)
> > turn on stack overrun detection?
>
> CONFIG_DEBUG_STACKOVERFLOW ? Already turned on.
That only checks stack usage when an interrupt is taken. If no
interrupts are taken when stack usage is within 128 bytes of
overflow, then it doesn't catch it.
I tend to use CONFIG_DEBUG_STACK_USAGE=y as it records the maximum
stack usage of a process via canary overwrites and it records it in
do_exit(). I also use the stack tracer to record the largest stack
usage seen so I know exactly what code paths are approaching stack
overruns...
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] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 5:40 ` Dave Chinner
@ 2014-02-12 6:28 ` Linus Torvalds
-1 siblings, 0 replies; 132+ messages in thread
From: Linus Torvalds @ 2014-02-12 6:28 UTC (permalink / raw)
To: Dave Chinner; +Cc: Al Viro, Dave Jones, Eric Sandeen, Linux Kernel, xfs
On Tue, Feb 11, 2014 at 9:40 PM, Dave Chinner <david@fromorbit.com> wrote:
>
> None of the XFS code disables interrupts in that path, not does is
> call outside XFS except to dispatch IO. The stack is pretty deep at
> this point and I know that the standard (non stacked) IO stack can
> consume >3kb of stack space when it gets down to having to do memory
> reclaim during GFP_NOIO allocation at the lowest level of SCSI
> drivers. Stack overruns typically show up with symptoms like we are
> seeing.
That would also explain why it shows up for do_coredump(), even though
clearly interrupts are not disabled at that point. It's just because
do_coredump() opens a filename at a deeper point in the stack than the
more normal system call paths do.
It looks like just "do_signal()" has a stack frame that is about 230
bytes even under normal circumstancs (largely due to "struct ksignal"
- which in turn is largely due to the insane 128-byte padding in
siginfo_t). Add a few other frames in there, and I guess that if it
was close before, the coredump path just makes it go off.
And some of the debug options that I'm sure DaveJ has enabled tend to
make the stack usage worse (simply because they make a lot of data
structures bigger).
Linus
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-12 6:28 ` Linus Torvalds
0 siblings, 0 replies; 132+ messages in thread
From: Linus Torvalds @ 2014-02-12 6:28 UTC (permalink / raw)
To: Dave Chinner; +Cc: Dave Jones, xfs, Eric Sandeen, Al Viro, Linux Kernel
On Tue, Feb 11, 2014 at 9:40 PM, Dave Chinner <david@fromorbit.com> wrote:
>
> None of the XFS code disables interrupts in that path, not does is
> call outside XFS except to dispatch IO. The stack is pretty deep at
> this point and I know that the standard (non stacked) IO stack can
> consume >3kb of stack space when it gets down to having to do memory
> reclaim during GFP_NOIO allocation at the lowest level of SCSI
> drivers. Stack overruns typically show up with symptoms like we are
> seeing.
That would also explain why it shows up for do_coredump(), even though
clearly interrupts are not disabled at that point. It's just because
do_coredump() opens a filename at a deeper point in the stack than the
more normal system call paths do.
It looks like just "do_signal()" has a stack frame that is about 230
bytes even under normal circumstancs (largely due to "struct ksignal"
- which in turn is largely due to the insane 128-byte padding in
siginfo_t). Add a few other frames in there, and I guess that if it
was close before, the coredump path just makes it go off.
And some of the debug options that I'm sure DaveJ has enabled tend to
make the stack usage worse (simply because they make a lot of data
structures bigger).
Linus
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 6:10 ` Dave Chinner
@ 2014-02-12 6:31 ` Dave Chinner
-1 siblings, 0 replies; 132+ messages in thread
From: Dave Chinner @ 2014-02-12 6:31 UTC (permalink / raw)
To: Dave Jones, Al Viro, Linus Torvalds, Eric Sandeen, Linux Kernel, xfs
On Wed, Feb 12, 2014 at 05:10:38PM +1100, Dave Chinner wrote:
> On Wed, Feb 12, 2014 at 12:50:27AM -0500, Dave Jones wrote:
> > On Wed, Feb 12, 2014 at 04:40:43PM +1100, Dave Chinner wrote:
> >
> > > None of the XFS code disables interrupts in that path, not does is
> > > call outside XFS except to dispatch IO. The stack is pretty deep at
> > > this point and I know that the standard (non stacked) IO stack can
> > > consume >3kb of stack space when it gets down to having to do memory
> > > reclaim during GFP_NOIO allocation at the lowest level of SCSI
> > > drivers. Stack overruns typically show up with symptoms like we are
> > > seeing.
> > > ..
> > >
> > > Dave, before chasing ghosts, can you (like Eric originally asked)
> > > turn on stack overrun detection?
> >
> > CONFIG_DEBUG_STACKOVERFLOW ? Already turned on.
>
> That only checks stack usage when an interrupt is taken. If no
> interrupts are taken when stack usage is within 128 bytes of
> overflow, then it doesn't catch it.
>
> I tend to use CONFIG_DEBUG_STACK_USAGE=y as it records the maximum
> stack usage of a process via canary overwrites and it records it in
> do_exit(). I also use the stack tracer to record the largest stack
> usage seen so I know exactly what code paths are approaching stack
> overruns...
FYI, just creating lots of files with open(O_CREAT):
[ 348.718357] fs_mark (4828) used greatest stack depth: 2968 bytes left
[ 348.769846] fs_mark (4814) used greatest stack depth: 2312 bytes left
[ 349.777717] fs_mark (4826) used greatest stack depth: 2280 bytes left
[ 418.139415] fs_mark (4928) used greatest stack depth: 1936 bytes left
[ 460.492282] fs_mark (4993) used greatest stack depth: 1336 bytes left
[ 544.825418] fs_mark (5104) used greatest stack depth: 1112 bytes left
[ 689.503970] fs_mark (5265) used greatest stack depth: 1000 bytes left
We've got absolutely no spare stack space anymore in the IO path.
And the IO path can't get much simpler than filesystem -> virtio
block device.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-12 6:31 ` Dave Chinner
0 siblings, 0 replies; 132+ messages in thread
From: Dave Chinner @ 2014-02-12 6:31 UTC (permalink / raw)
To: Dave Jones, Al Viro, Linus Torvalds, Eric Sandeen, Linux Kernel, xfs
On Wed, Feb 12, 2014 at 05:10:38PM +1100, Dave Chinner wrote:
> On Wed, Feb 12, 2014 at 12:50:27AM -0500, Dave Jones wrote:
> > On Wed, Feb 12, 2014 at 04:40:43PM +1100, Dave Chinner wrote:
> >
> > > None of the XFS code disables interrupts in that path, not does is
> > > call outside XFS except to dispatch IO. The stack is pretty deep at
> > > this point and I know that the standard (non stacked) IO stack can
> > > consume >3kb of stack space when it gets down to having to do memory
> > > reclaim during GFP_NOIO allocation at the lowest level of SCSI
> > > drivers. Stack overruns typically show up with symptoms like we are
> > > seeing.
> > > ..
> > >
> > > Dave, before chasing ghosts, can you (like Eric originally asked)
> > > turn on stack overrun detection?
> >
> > CONFIG_DEBUG_STACKOVERFLOW ? Already turned on.
>
> That only checks stack usage when an interrupt is taken. If no
> interrupts are taken when stack usage is within 128 bytes of
> overflow, then it doesn't catch it.
>
> I tend to use CONFIG_DEBUG_STACK_USAGE=y as it records the maximum
> stack usage of a process via canary overwrites and it records it in
> do_exit(). I also use the stack tracer to record the largest stack
> usage seen so I know exactly what code paths are approaching stack
> overruns...
FYI, just creating lots of files with open(O_CREAT):
[ 348.718357] fs_mark (4828) used greatest stack depth: 2968 bytes left
[ 348.769846] fs_mark (4814) used greatest stack depth: 2312 bytes left
[ 349.777717] fs_mark (4826) used greatest stack depth: 2280 bytes left
[ 418.139415] fs_mark (4928) used greatest stack depth: 1936 bytes left
[ 460.492282] fs_mark (4993) used greatest stack depth: 1336 bytes left
[ 544.825418] fs_mark (5104) used greatest stack depth: 1112 bytes left
[ 689.503970] fs_mark (5265) used greatest stack depth: 1000 bytes left
We've got absolutely no spare stack space anymore in the IO path.
And the IO path can't get much simpler than filesystem -> virtio
block device.
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] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 6:31 ` Dave Chinner
@ 2014-02-12 6:59 ` Linus Torvalds
-1 siblings, 0 replies; 132+ messages in thread
From: Linus Torvalds @ 2014-02-12 6:59 UTC (permalink / raw)
To: Dave Chinner, Jens Axboe, Tejun Heo, Steven Rostedt
Cc: Dave Jones, Al Viro, Eric Sandeen, Linux Kernel, xfs
On Tue, Feb 11, 2014 at 10:31 PM, Dave Chinner <david@fromorbit.com> wrote:
>
> FYI, just creating lots of files with open(O_CREAT):
>
> [ 348.718357] fs_mark (4828) used greatest stack depth: 2968 bytes left
> [ 348.769846] fs_mark (4814) used greatest stack depth: 2312 bytes left
> [ 349.777717] fs_mark (4826) used greatest stack depth: 2280 bytes left
> [ 418.139415] fs_mark (4928) used greatest stack depth: 1936 bytes left
> [ 460.492282] fs_mark (4993) used greatest stack depth: 1336 bytes left
> [ 544.825418] fs_mark (5104) used greatest stack depth: 1112 bytes left
> [ 689.503970] fs_mark (5265) used greatest stack depth: 1000 bytes left
>
> We've got absolutely no spare stack space anymore in the IO path.
> And the IO path can't get much simpler than filesystem -> virtio
> block device.
Ugh, that's bad. A thousand bytes of stack space is much too close to
any limits.
Do you have the stack traces for these things so that we can look at
worst offenders?
If the new block-mq code is to blame, it needs to be fixed.
__virtblk_add_req() has a 300-byte stack frame, it seems. Looking
elsewhere, blkdev_issue_discard() has 350 bytes of stack frame, but is
hopefully not in any normal path - online discard is moronic, and I'm
assuming XFS doesn't do that.
There's a lot of 200+ byte stack frames in block/blk-core.s, and they
all seem to be of the type perf_trace_block_buffer() - things created
with DECLARE_EVENT_CLASS(), afaik. Why they all have 200+ bytes of
frame, I have no idea. That sounds like a potential disaster too,
although hopefully it's mostly leaf functions - but leaf functions
*deep* in the callchain. Tejun? Steven, why _do_ they end up with such
huge frames?
And if the stack use comes from the VFS layer, we can probably work on
that too. But I don't think that has really changed much lately..
Linus
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-12 6:59 ` Linus Torvalds
0 siblings, 0 replies; 132+ messages in thread
From: Linus Torvalds @ 2014-02-12 6:59 UTC (permalink / raw)
To: Dave Chinner, Jens Axboe, Tejun Heo, Steven Rostedt
Cc: Dave Jones, xfs, Eric Sandeen, Al Viro, Linux Kernel
On Tue, Feb 11, 2014 at 10:31 PM, Dave Chinner <david@fromorbit.com> wrote:
>
> FYI, just creating lots of files with open(O_CREAT):
>
> [ 348.718357] fs_mark (4828) used greatest stack depth: 2968 bytes left
> [ 348.769846] fs_mark (4814) used greatest stack depth: 2312 bytes left
> [ 349.777717] fs_mark (4826) used greatest stack depth: 2280 bytes left
> [ 418.139415] fs_mark (4928) used greatest stack depth: 1936 bytes left
> [ 460.492282] fs_mark (4993) used greatest stack depth: 1336 bytes left
> [ 544.825418] fs_mark (5104) used greatest stack depth: 1112 bytes left
> [ 689.503970] fs_mark (5265) used greatest stack depth: 1000 bytes left
>
> We've got absolutely no spare stack space anymore in the IO path.
> And the IO path can't get much simpler than filesystem -> virtio
> block device.
Ugh, that's bad. A thousand bytes of stack space is much too close to
any limits.
Do you have the stack traces for these things so that we can look at
worst offenders?
If the new block-mq code is to blame, it needs to be fixed.
__virtblk_add_req() has a 300-byte stack frame, it seems. Looking
elsewhere, blkdev_issue_discard() has 350 bytes of stack frame, but is
hopefully not in any normal path - online discard is moronic, and I'm
assuming XFS doesn't do that.
There's a lot of 200+ byte stack frames in block/blk-core.s, and they
all seem to be of the type perf_trace_block_buffer() - things created
with DECLARE_EVENT_CLASS(), afaik. Why they all have 200+ bytes of
frame, I have no idea. That sounds like a potential disaster too,
although hopefully it's mostly leaf functions - but leaf functions
*deep* in the callchain. Tejun? Steven, why _do_ they end up with such
huge frames?
And if the stack use comes from the VFS layer, we can probably work on
that too. But I don't think that has really changed much lately..
Linus
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 6:28 ` Linus Torvalds
@ 2014-02-12 7:18 ` Dave Chinner
-1 siblings, 0 replies; 132+ messages in thread
From: Dave Chinner @ 2014-02-12 7:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Al Viro, Dave Jones, Eric Sandeen, Linux Kernel, xfs
On Tue, Feb 11, 2014 at 10:28:12PM -0800, Linus Torvalds wrote:
> On Tue, Feb 11, 2014 at 9:40 PM, Dave Chinner <david@fromorbit.com> wrote:
> >
> > None of the XFS code disables interrupts in that path, not does is
> > call outside XFS except to dispatch IO. The stack is pretty deep at
> > this point and I know that the standard (non stacked) IO stack can
> > consume >3kb of stack space when it gets down to having to do memory
> > reclaim during GFP_NOIO allocation at the lowest level of SCSI
> > drivers. Stack overruns typically show up with symptoms like we are
> > seeing.
>
> That would also explain why it shows up for do_coredump(), even though
> clearly interrupts are not disabled at that point. It's just because
> do_coredump() opens a filename at a deeper point in the stack than the
> more normal system call paths do.
Right, it's exactly the same problem we have when knfsd is making
the VFS calls.
> It looks like just "do_signal()" has a stack frame that is about 230
> bytes even under normal circumstancs (largely due to "struct ksignal"
> - which in turn is largely due to the insane 128-byte padding in
> siginfo_t). Add a few other frames in there, and I guess that if it
> was close before, the coredump path just makes it go off.
Yup. But it's when you see this sort of thing you realise that
almost no GFP_KERNEL memory allocation is really safe from stack
overruns, though:
0) 6064 64 update_group_power+0x2c/0x270
1) 6000 384 find_busiest_group+0x10a/0x8b0
2) 5616 288 load_balance+0x165/0x870
3) 5328 96 idle_balance+0x106/0x1b0
4) 5232 112 __schedule+0x7b6/0x7e0
5) 5120 16 schedule+0x29/0x70
6) 5104 176 percpu_ida_alloc+0x1b3/0x3d0
7) 4928 32 blk_mq_wait_for_tags+0x1f/0x40
8) 4896 80 blk_mq_alloc_request_pinned+0x4e/0x110
9) 4816 128 blk_mq_make_request+0x42b/0x510
10) 4688 48 generic_make_request+0xc0/0x110
11) 4640 96 submit_bio+0x71/0x120
12) 4544 192 _xfs_buf_ioapply+0x2cc/0x3b0
13) 4352 48 xfs_buf_iorequest+0x6f/0xc0
14) 4304 32 xlog_bdstrat+0x23/0x60
15) 4272 96 xlog_sync+0x3a4/0x5c0
16) 4176 48 xlog_state_release_iclog+0x121/0x130
17) 4128 192 xlog_write+0x700/0x7c0
18) 3936 192 xlog_cil_push+0x2ae/0x3d0
19) 3744 128 xlog_cil_force_lsn+0x1b8/0x1e0
20) 3616 144 _xfs_log_force_lsn+0x7c/0x300
21) 3472 48 xfs_log_force_lsn+0x3b/0xa0
22) 3424 112 xfs_iunpin_wait+0xd7/0x160
23) 3312 80 xfs_reclaim_inode+0xd0/0x350
24) 3232 432 xfs_reclaim_inodes_ag+0x277/0x3d0
25) 2800 48 xfs_reclaim_inodes_nr+0x33/0x40
26) 2752 16 xfs_fs_free_cached_objects+0x15/0x20
27) 2736 80 super_cache_scan+0x169/0x170
28) 2656 160 shrink_slab_node+0x133/0x290
29) 2496 80 shrink_slab+0x122/0x160
30) 2416 112 do_try_to_free_pages+0x1de/0x360
31) 2304 192 try_to_free_pages+0x110/0x190
32) 2112 256 __alloc_pages_nodemask+0x5a2/0x8e0
33) 1856 80 alloc_pages_current+0xb2/0x170
34) 1776 64 new_slab+0x265/0x2e0
35) 1712 240 __slab_alloc+0x2fb/0x4c4
36) 1472 80 kmem_cache_alloc+0x10b/0x140
That's almost 4700 bytes of stack usage from the
kmem_cache_alloc(GFP_KERNEL) call because it entered the IO path.
Yes, it's an extreme case, but if you're looking for a smoking
gun.... :/
I can fix this one easily - we already have a workqueue for doing
async log pushes (will split the stack between xlog_cil_force_lsn
and xlog_cil_push), but the reason we haven't used it for synchronous
log forces is that screws up fsync performance on CFQ. We don't
recommend CFQ with XFS anyway, so I think I'll make this change
anyway.
> And some of the debug options that I'm sure DaveJ has enabled tend to
> make the stack usage worse (simply because they make a lot of data
> structures bigger).
True - CONFIG_XFS_DEBUG tends to add about 5% to the stack usage of
XFS, but realistically 5% is not significant especially as we've
been hitting stack overflows with XFS on production systems
regularly enough on x86-64 over the past 2-3 years that we know what
"typical symptoms" of such overflows are...
The problem we have now is that everything outside XFS continues to
grow in stack usage, so the only choice that remains for us to avoid
overruns is to add performance impacting stack switches into the
middle of common XFS paths. We also have to do it unconditionally
because we don't know ahead of time if any specific operation is
going to require all the stack we can give it because - for example
- we can't predict when the IO path is going to require memory
allocation...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-12 7:18 ` Dave Chinner
0 siblings, 0 replies; 132+ messages in thread
From: Dave Chinner @ 2014-02-12 7:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dave Jones, xfs, Eric Sandeen, Al Viro, Linux Kernel
On Tue, Feb 11, 2014 at 10:28:12PM -0800, Linus Torvalds wrote:
> On Tue, Feb 11, 2014 at 9:40 PM, Dave Chinner <david@fromorbit.com> wrote:
> >
> > None of the XFS code disables interrupts in that path, not does is
> > call outside XFS except to dispatch IO. The stack is pretty deep at
> > this point and I know that the standard (non stacked) IO stack can
> > consume >3kb of stack space when it gets down to having to do memory
> > reclaim during GFP_NOIO allocation at the lowest level of SCSI
> > drivers. Stack overruns typically show up with symptoms like we are
> > seeing.
>
> That would also explain why it shows up for do_coredump(), even though
> clearly interrupts are not disabled at that point. It's just because
> do_coredump() opens a filename at a deeper point in the stack than the
> more normal system call paths do.
Right, it's exactly the same problem we have when knfsd is making
the VFS calls.
> It looks like just "do_signal()" has a stack frame that is about 230
> bytes even under normal circumstancs (largely due to "struct ksignal"
> - which in turn is largely due to the insane 128-byte padding in
> siginfo_t). Add a few other frames in there, and I guess that if it
> was close before, the coredump path just makes it go off.
Yup. But it's when you see this sort of thing you realise that
almost no GFP_KERNEL memory allocation is really safe from stack
overruns, though:
0) 6064 64 update_group_power+0x2c/0x270
1) 6000 384 find_busiest_group+0x10a/0x8b0
2) 5616 288 load_balance+0x165/0x870
3) 5328 96 idle_balance+0x106/0x1b0
4) 5232 112 __schedule+0x7b6/0x7e0
5) 5120 16 schedule+0x29/0x70
6) 5104 176 percpu_ida_alloc+0x1b3/0x3d0
7) 4928 32 blk_mq_wait_for_tags+0x1f/0x40
8) 4896 80 blk_mq_alloc_request_pinned+0x4e/0x110
9) 4816 128 blk_mq_make_request+0x42b/0x510
10) 4688 48 generic_make_request+0xc0/0x110
11) 4640 96 submit_bio+0x71/0x120
12) 4544 192 _xfs_buf_ioapply+0x2cc/0x3b0
13) 4352 48 xfs_buf_iorequest+0x6f/0xc0
14) 4304 32 xlog_bdstrat+0x23/0x60
15) 4272 96 xlog_sync+0x3a4/0x5c0
16) 4176 48 xlog_state_release_iclog+0x121/0x130
17) 4128 192 xlog_write+0x700/0x7c0
18) 3936 192 xlog_cil_push+0x2ae/0x3d0
19) 3744 128 xlog_cil_force_lsn+0x1b8/0x1e0
20) 3616 144 _xfs_log_force_lsn+0x7c/0x300
21) 3472 48 xfs_log_force_lsn+0x3b/0xa0
22) 3424 112 xfs_iunpin_wait+0xd7/0x160
23) 3312 80 xfs_reclaim_inode+0xd0/0x350
24) 3232 432 xfs_reclaim_inodes_ag+0x277/0x3d0
25) 2800 48 xfs_reclaim_inodes_nr+0x33/0x40
26) 2752 16 xfs_fs_free_cached_objects+0x15/0x20
27) 2736 80 super_cache_scan+0x169/0x170
28) 2656 160 shrink_slab_node+0x133/0x290
29) 2496 80 shrink_slab+0x122/0x160
30) 2416 112 do_try_to_free_pages+0x1de/0x360
31) 2304 192 try_to_free_pages+0x110/0x190
32) 2112 256 __alloc_pages_nodemask+0x5a2/0x8e0
33) 1856 80 alloc_pages_current+0xb2/0x170
34) 1776 64 new_slab+0x265/0x2e0
35) 1712 240 __slab_alloc+0x2fb/0x4c4
36) 1472 80 kmem_cache_alloc+0x10b/0x140
That's almost 4700 bytes of stack usage from the
kmem_cache_alloc(GFP_KERNEL) call because it entered the IO path.
Yes, it's an extreme case, but if you're looking for a smoking
gun.... :/
I can fix this one easily - we already have a workqueue for doing
async log pushes (will split the stack between xlog_cil_force_lsn
and xlog_cil_push), but the reason we haven't used it for synchronous
log forces is that screws up fsync performance on CFQ. We don't
recommend CFQ with XFS anyway, so I think I'll make this change
anyway.
> And some of the debug options that I'm sure DaveJ has enabled tend to
> make the stack usage worse (simply because they make a lot of data
> structures bigger).
True - CONFIG_XFS_DEBUG tends to add about 5% to the stack usage of
XFS, but realistically 5% is not significant especially as we've
been hitting stack overflows with XFS on production systems
regularly enough on x86-64 over the past 2-3 years that we know what
"typical symptoms" of such overflows are...
The problem we have now is that everything outside XFS continues to
grow in stack usage, so the only choice that remains for us to avoid
overruns is to add performance impacting stack switches into the
middle of common XFS paths. We also have to do it unconditionally
because we don't know ahead of time if any specific operation is
going to require all the stack we can give it because - for example
- we can't predict when the IO path is going to require memory
allocation...
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] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 6:59 ` Linus Torvalds
@ 2014-02-12 8:13 ` Tejun Heo
-1 siblings, 0 replies; 132+ messages in thread
From: Tejun Heo @ 2014-02-12 8:13 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Chinner, Jens Axboe, Steven Rostedt, Dave Jones, Al Viro,
Eric Sandeen, Linux Kernel, xfs
On Tue, Feb 11, 2014 at 10:59:58PM -0800, Linus Torvalds wrote:
> There's a lot of 200+ byte stack frames in block/blk-core.s, and they
> all seem to be of the type perf_trace_block_buffer() - things created
> with DECLARE_EVENT_CLASS(), afaik. Why they all have 200+ bytes of
> frame, I have no idea. That sounds like a potential disaster too,
> although hopefully it's mostly leaf functions - but leaf functions
> *deep* in the callchain. Tejun? Steven, why _do_ they end up with such
> huge frames?
It looks like they're essentially the same for all the automatically
generated trace functions. I'm seeing 232 byte stack frame in most of
them. If I'm not completely confused by these macros, these are
generated by DECLARE_EVENT_CLASS() in include/trace/ftrace.h and
contains struct pt_regs in the stack frame which is already 168 bytes,
so that seems like the culprit. No idea whether this is something
avoidable. At least they shouldn't nest in any way. Steven?
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-12 8:13 ` Tejun Heo
0 siblings, 0 replies; 132+ messages in thread
From: Tejun Heo @ 2014-02-12 8:13 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jens Axboe, Eric Sandeen, Linux Kernel, Steven Rostedt, xfs,
Al Viro, Dave Jones
On Tue, Feb 11, 2014 at 10:59:58PM -0800, Linus Torvalds wrote:
> There's a lot of 200+ byte stack frames in block/blk-core.s, and they
> all seem to be of the type perf_trace_block_buffer() - things created
> with DECLARE_EVENT_CLASS(), afaik. Why they all have 200+ bytes of
> frame, I have no idea. That sounds like a potential disaster too,
> although hopefully it's mostly leaf functions - but leaf functions
> *deep* in the callchain. Tejun? Steven, why _do_ they end up with such
> huge frames?
It looks like they're essentially the same for all the automatically
generated trace functions. I'm seeing 232 byte stack frame in most of
them. If I'm not completely confused by these macros, these are
generated by DECLARE_EVENT_CLASS() in include/trace/ftrace.h and
contains struct pt_regs in the stack frame which is already 168 bytes,
so that seems like the culprit. No idea whether this is something
avoidable. At least they shouldn't nest in any way. Steven?
Thanks.
--
tejun
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 6:59 ` Linus Torvalds
@ 2014-02-12 8:35 ` Dave Chinner
-1 siblings, 0 replies; 132+ messages in thread
From: Dave Chinner @ 2014-02-12 8:35 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jens Axboe, Tejun Heo, Steven Rostedt, Dave Jones, Al Viro,
Eric Sandeen, Linux Kernel, xfs
On Tue, Feb 11, 2014 at 10:59:58PM -0800, Linus Torvalds wrote:
> On Tue, Feb 11, 2014 at 10:31 PM, Dave Chinner <david@fromorbit.com> wrote:
> >
> > FYI, just creating lots of files with open(O_CREAT):
> >
> > [ 348.718357] fs_mark (4828) used greatest stack depth: 2968 bytes left
> > [ 348.769846] fs_mark (4814) used greatest stack depth: 2312 bytes left
> > [ 349.777717] fs_mark (4826) used greatest stack depth: 2280 bytes left
> > [ 418.139415] fs_mark (4928) used greatest stack depth: 1936 bytes left
> > [ 460.492282] fs_mark (4993) used greatest stack depth: 1336 bytes left
> > [ 544.825418] fs_mark (5104) used greatest stack depth: 1112 bytes left
> > [ 689.503970] fs_mark (5265) used greatest stack depth: 1000 bytes left
> >
> > We've got absolutely no spare stack space anymore in the IO path.
> > And the IO path can't get much simpler than filesystem -> virtio
> > block device.
>
> Ugh, that's bad. A thousand bytes of stack space is much too close to
> any limits.
>
> Do you have the stack traces for these things so that we can look at
> worst offenders?
Sure. It's almost through the XFS block allocation path where we do
metadata reads or log writes. That's always been the worst case
stack usage path for XFS. The worst path is about 4800 bytes - it
was a double btree split (inode extent map tree split, followed by a
freespace btree split when allocating a block for the extent map
btree split), triggering a reallocation of a btree block that was
pinned and STALE, which triggered a log force, which then made it's
way into the block layer.
I don't have a stack trace of that because I can't create the
initial conditions required to trigger it on demand. I've only ever
seen it in the wild once. More common, though, is the situation we
see here - somewhere around 3-4k of stack usage from a single extent
btree update operation.
We've already got a stack switch in the data allocation path - we
had to add it to stop the bdi-flusher from busting the stack with
alarming regularity in production systems. I initially made the
metadata allocation paths use it as well, but that part got reverted
(aa29284 xfs: don't defer metadata allocation to the workqueue)
because Mel Gorman demonstrated several workloads that regressed
significantly as a result of making that change.
So now we are stuck betweeen a rock and a hard place - those
metadata block allocation paths are triggering the stack overflows,
but switching stacks in the allocation path to avoid stack overflows
causes massive performance regressions....
The thing is, the XFS stack usage has not changed significantly over
the past 5 years - we keep a pretty close eye on it. The issue is
that everything around XFS has slowly been growing and I can't
point you at one stack trace that demonstrates the worst case. What
I can point you to function calls that consume a lot of stack space
and hence limit what is available to callers.
So here's a few stack fragements I've generated in teh past few
minutes on a couple of XFS filesystems inside a 16p/16GB VM by
running:
$ dd if=/dev/zero of=/mnt/test/foo bs=1024k &
which writes at about 600MB/s to a 18TB RAID array. That runs in
parallel with a multithreaded inode creation/walk/remove workload on
a different filesystem (creates 50 million inodes ~250k inode
creates/s, walks them removes them at around 170k removes/s) which
is hosted on a dm RAID0 stripe of 2 samsung 840 EVO SSDs.
mutex_lock() requires at least 1.2k of stack because of the
scheduler overhead.:
$ sudo cat /sys/kernel/debug/tracing/stack_trace
Depth Size Location (39 entries)
----- ---- --------
0) 4368 64 update_group_power+0x2c/0x270
1) 4304 384 find_busiest_group+0x10a/0x8b0
2) 3920 288 load_balance+0x165/0x870
3) 3632 96 idle_balance+0x106/0x1b0
4) 3536 112 __schedule+0x7b6/0x7e0
5) 3424 16 schedule+0x29/0x70
6) 3408 16 schedule_preempt_disabled+0xe/0x10
7) 3392 112 __mutex_lock_slowpath+0x11a/0x400
8) 3280 32 mutex_lock+0x1e/0x32
i.e. any function that is going to schedule needs at least 1k of
stack, and some of the lead in infrastructure (like
wait_for_completion) can require a total of up to 1.5k...
Basic memory allocation can easily >1k of stack without
entering reclaim:
----- ---- --------
0) 4920 40 zone_statistics+0xbd/0xc0
1) 4880 256 get_page_from_freelist+0x3a8/0x8a0
2) 4624 256 __alloc_pages_nodemask+0x143/0x8e0
3) 4368 80 alloc_pages_current+0xb2/0x170
4) 4288 64 new_slab+0x265/0x2e0
5) 4224 240 __slab_alloc+0x2fb/0x4c4
6) 3984 80 kmem_cache_alloc+0x10b/0x140
7) 3904 48 kmem_zone_alloc+0x77/0x100
If it enters reclaim and we are allowed to IO? Well, you saw the
stack I posted in the other thread - 4700 bytes from
kmem_cache_alloc() to the top of the stack. Another bad case is
the swap path (using a scsi device rather than virtio for the
root/swap devices):
Depth Size Location (44 entries)
----- ---- --------
0) 4496 16 mempool_alloc_slab+0x15/0x20
1) 4480 128 mempool_alloc+0x66/0x170
2) 4352 16 scsi_sg_alloc+0x4e/0x60
3) 4336 112 __sg_alloc_table+0x68/0x130
4) 4224 32 scsi_init_sgtable+0x34/0x90
5) 4192 48 scsi_init_io+0x34/0xd0
6) 4144 32 scsi_setup_fs_cmnd+0x66/0xa0
7) 4112 112 sd_prep_fn+0x2a0/0xce0
8) 4000 48 blk_peek_request+0x13c/0x260
9) 3952 112 scsi_request_fn+0x4b/0x490
10) 3840 32 __blk_run_queue+0x37/0x50
11) 3808 64 queue_unplugged+0x39/0xb0
12) 3744 112 blk_flush_plug_list+0x20b/0x240
13) 3632 80 blk_queue_bio+0x1ca/0x310
14) 3552 48 generic_make_request+0xc0/0x110
15) 3504 96 submit_bio+0x71/0x120
16) 3408 160 __swap_writepage+0x184/0x220
17) 3248 32 swap_writepage+0x42/0x90
18) 3216 304 shrink_page_list+0x6fd/0xa20
19) 2912 208 shrink_inactive_list+0x243/0x480
20) 2704 288 shrink_lruvec+0x371/0x670
21) 2416 112 do_try_to_free_pages+0x11a/0x360
22) 2304 192 try_to_free_pages+0x110/0x190
23) 2112 256 __alloc_pages_nodemask+0x5a2/0x8e0
24) 1856 80 alloc_pages_current+0xb2/0x170
25) 1776 64 new_slab+0x265/0x2e0
26) 1712 240 __slab_alloc+0x2fb/0x4c4
27) 1472 80 kmem_cache_alloc+0x10b/0x140
28) 1392 48 kmem_zone_alloc+0x77/0x100
There's over 3k in the stack from kmem_zone_alloc(GFP_KERNEL) and
that's got nothing XFS in it at all - it's just memory allocation,
reclaim and Io path. And it also demonstrates that the scsi layer
has significant stack usage.
here's 2.5k from submit_bio() on virtio block device:
Depth Size Location (44 entries)
----- ---- --------
0) 4512 64 update_curr+0x8b/0x160
1) 4448 96 enqueue_task_fair+0x39d/0xd50
2) 4352 48 enqueue_task+0x50/0x60
3) 4304 16 activate_task+0x23/0x30
4) 4288 32 ttwu_do_activate.constprop.84+0x3c/0x70
5) 4256 96 try_to_wake_up+0x1b4/0x2c0
6) 4160 16 default_wake_function+0x12/0x20
7) 4144 32 autoremove_wake_function+0x16/0x40
8) 4112 80 __wake_up_common+0x55/0x90
9) 4032 64 __wake_up+0x48/0x70
10) 3968 80 wakeup_kswapd+0xe7/0x130
11) 3888 256 __alloc_pages_nodemask+0x371/0x8e0
12) 3632 80 alloc_pages_current+0xb2/0x170
13) 3552 64 new_slab+0x265/0x2e0
14) 3488 240 __slab_alloc+0x2fb/0x4c4
15) 3248 80 __kmalloc+0x133/0x180
16) 3168 112 virtqueue_add_sgs+0x2fe/0x520
17) 3056 288 __virtblk_add_req+0xd5/0x180
18) 2768 96 virtio_queue_rq+0xdd/0x1d0
19) 2672 112 __blk_mq_run_hw_queue+0x1c3/0x3c0
20) 2560 16 blk_mq_run_hw_queue+0x35/0x40
21) 2544 80 blk_mq_insert_requests+0xc5/0x120
22) 2464 96 blk_mq_flush_plug_list+0x129/0x140
23) 2368 112 blk_flush_plug_list+0xe7/0x240
24) 2256 128 blk_mq_make_request+0x3ca/0x510
25) 2128 48 generic_make_request+0xc0/0x110
26) 2080 96 submit_bio+0x71/0x120
You can also see the difference in stack usage that the blk_mq layer
adds compared to the previous trace that went through the old
code to get to the SCSI stack.
And you saw the memory reclaim via shrinker path taht I posted in
another email - that was 4700 bytes from kmem_cache_alloc() to teh
top of the stack (can be reduced to about 2000 bytes by having XFS
chop it in half).
> If the new block-mq code is to blame, it needs to be fixed.
It's a symptom of the pattern of gradual growth in just about every
core subsystem. Each individual change is not significant, but when
you put the whole stack together the canary is well and truly dead.
> __virtblk_add_req() has a 300-byte stack frame, it seems. Looking
> elsewhere, blkdev_issue_discard() has 350 bytes of stack frame, but is
> hopefully not in any normal path - online discard is moronic, and I'm
> assuming XFS doesn't do that.
We *support* it, but we don't *recommend* it. So, no, that's not the
problem path. ;)
> There's a lot of 200+ byte stack frames in block/blk-core.s, and they
> all seem to be of the type perf_trace_block_buffer() - things created
> with DECLARE_EVENT_CLASS(), afaik. Why they all have 200+ bytes of
> frame, I have no idea. That sounds like a potential disaster too,
> although hopefully it's mostly leaf functions - but leaf functions
> *deep* in the callchain. Tejun? Steven, why _do_ they end up with such
> huge frames?
And it's leaf functions that the CONFIG_STACK_TRACER doesn't catch
on x86-64 (at least, according to the documentation).
CONFIG_DEBUG_STACK_USAGE output is showing up to 800 bytes more
stack usage than the tracer. As such, I also think that
CONFIG_DEBUG_STACK_USAGE output is a more reliable iindication of
stack usage because it is canary based and so captures the very
worst case usage of the process's stack...
It really seems to me that we have got to the point where it is not
safe to do anything like submit IO or try to do memory allocation
with any more than half the stack space consumed....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-12 8:35 ` Dave Chinner
0 siblings, 0 replies; 132+ messages in thread
From: Dave Chinner @ 2014-02-12 8:35 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jens Axboe, Eric Sandeen, Linux Kernel, Steven Rostedt, xfs,
Al Viro, Tejun Heo, Dave Jones
On Tue, Feb 11, 2014 at 10:59:58PM -0800, Linus Torvalds wrote:
> On Tue, Feb 11, 2014 at 10:31 PM, Dave Chinner <david@fromorbit.com> wrote:
> >
> > FYI, just creating lots of files with open(O_CREAT):
> >
> > [ 348.718357] fs_mark (4828) used greatest stack depth: 2968 bytes left
> > [ 348.769846] fs_mark (4814) used greatest stack depth: 2312 bytes left
> > [ 349.777717] fs_mark (4826) used greatest stack depth: 2280 bytes left
> > [ 418.139415] fs_mark (4928) used greatest stack depth: 1936 bytes left
> > [ 460.492282] fs_mark (4993) used greatest stack depth: 1336 bytes left
> > [ 544.825418] fs_mark (5104) used greatest stack depth: 1112 bytes left
> > [ 689.503970] fs_mark (5265) used greatest stack depth: 1000 bytes left
> >
> > We've got absolutely no spare stack space anymore in the IO path.
> > And the IO path can't get much simpler than filesystem -> virtio
> > block device.
>
> Ugh, that's bad. A thousand bytes of stack space is much too close to
> any limits.
>
> Do you have the stack traces for these things so that we can look at
> worst offenders?
Sure. It's almost through the XFS block allocation path where we do
metadata reads or log writes. That's always been the worst case
stack usage path for XFS. The worst path is about 4800 bytes - it
was a double btree split (inode extent map tree split, followed by a
freespace btree split when allocating a block for the extent map
btree split), triggering a reallocation of a btree block that was
pinned and STALE, which triggered a log force, which then made it's
way into the block layer.
I don't have a stack trace of that because I can't create the
initial conditions required to trigger it on demand. I've only ever
seen it in the wild once. More common, though, is the situation we
see here - somewhere around 3-4k of stack usage from a single extent
btree update operation.
We've already got a stack switch in the data allocation path - we
had to add it to stop the bdi-flusher from busting the stack with
alarming regularity in production systems. I initially made the
metadata allocation paths use it as well, but that part got reverted
(aa29284 xfs: don't defer metadata allocation to the workqueue)
because Mel Gorman demonstrated several workloads that regressed
significantly as a result of making that change.
So now we are stuck betweeen a rock and a hard place - those
metadata block allocation paths are triggering the stack overflows,
but switching stacks in the allocation path to avoid stack overflows
causes massive performance regressions....
The thing is, the XFS stack usage has not changed significantly over
the past 5 years - we keep a pretty close eye on it. The issue is
that everything around XFS has slowly been growing and I can't
point you at one stack trace that demonstrates the worst case. What
I can point you to function calls that consume a lot of stack space
and hence limit what is available to callers.
So here's a few stack fragements I've generated in teh past few
minutes on a couple of XFS filesystems inside a 16p/16GB VM by
running:
$ dd if=/dev/zero of=/mnt/test/foo bs=1024k &
which writes at about 600MB/s to a 18TB RAID array. That runs in
parallel with a multithreaded inode creation/walk/remove workload on
a different filesystem (creates 50 million inodes ~250k inode
creates/s, walks them removes them at around 170k removes/s) which
is hosted on a dm RAID0 stripe of 2 samsung 840 EVO SSDs.
mutex_lock() requires at least 1.2k of stack because of the
scheduler overhead.:
$ sudo cat /sys/kernel/debug/tracing/stack_trace
Depth Size Location (39 entries)
----- ---- --------
0) 4368 64 update_group_power+0x2c/0x270
1) 4304 384 find_busiest_group+0x10a/0x8b0
2) 3920 288 load_balance+0x165/0x870
3) 3632 96 idle_balance+0x106/0x1b0
4) 3536 112 __schedule+0x7b6/0x7e0
5) 3424 16 schedule+0x29/0x70
6) 3408 16 schedule_preempt_disabled+0xe/0x10
7) 3392 112 __mutex_lock_slowpath+0x11a/0x400
8) 3280 32 mutex_lock+0x1e/0x32
i.e. any function that is going to schedule needs at least 1k of
stack, and some of the lead in infrastructure (like
wait_for_completion) can require a total of up to 1.5k...
Basic memory allocation can easily >1k of stack without
entering reclaim:
----- ---- --------
0) 4920 40 zone_statistics+0xbd/0xc0
1) 4880 256 get_page_from_freelist+0x3a8/0x8a0
2) 4624 256 __alloc_pages_nodemask+0x143/0x8e0
3) 4368 80 alloc_pages_current+0xb2/0x170
4) 4288 64 new_slab+0x265/0x2e0
5) 4224 240 __slab_alloc+0x2fb/0x4c4
6) 3984 80 kmem_cache_alloc+0x10b/0x140
7) 3904 48 kmem_zone_alloc+0x77/0x100
If it enters reclaim and we are allowed to IO? Well, you saw the
stack I posted in the other thread - 4700 bytes from
kmem_cache_alloc() to the top of the stack. Another bad case is
the swap path (using a scsi device rather than virtio for the
root/swap devices):
Depth Size Location (44 entries)
----- ---- --------
0) 4496 16 mempool_alloc_slab+0x15/0x20
1) 4480 128 mempool_alloc+0x66/0x170
2) 4352 16 scsi_sg_alloc+0x4e/0x60
3) 4336 112 __sg_alloc_table+0x68/0x130
4) 4224 32 scsi_init_sgtable+0x34/0x90
5) 4192 48 scsi_init_io+0x34/0xd0
6) 4144 32 scsi_setup_fs_cmnd+0x66/0xa0
7) 4112 112 sd_prep_fn+0x2a0/0xce0
8) 4000 48 blk_peek_request+0x13c/0x260
9) 3952 112 scsi_request_fn+0x4b/0x490
10) 3840 32 __blk_run_queue+0x37/0x50
11) 3808 64 queue_unplugged+0x39/0xb0
12) 3744 112 blk_flush_plug_list+0x20b/0x240
13) 3632 80 blk_queue_bio+0x1ca/0x310
14) 3552 48 generic_make_request+0xc0/0x110
15) 3504 96 submit_bio+0x71/0x120
16) 3408 160 __swap_writepage+0x184/0x220
17) 3248 32 swap_writepage+0x42/0x90
18) 3216 304 shrink_page_list+0x6fd/0xa20
19) 2912 208 shrink_inactive_list+0x243/0x480
20) 2704 288 shrink_lruvec+0x371/0x670
21) 2416 112 do_try_to_free_pages+0x11a/0x360
22) 2304 192 try_to_free_pages+0x110/0x190
23) 2112 256 __alloc_pages_nodemask+0x5a2/0x8e0
24) 1856 80 alloc_pages_current+0xb2/0x170
25) 1776 64 new_slab+0x265/0x2e0
26) 1712 240 __slab_alloc+0x2fb/0x4c4
27) 1472 80 kmem_cache_alloc+0x10b/0x140
28) 1392 48 kmem_zone_alloc+0x77/0x100
There's over 3k in the stack from kmem_zone_alloc(GFP_KERNEL) and
that's got nothing XFS in it at all - it's just memory allocation,
reclaim and Io path. And it also demonstrates that the scsi layer
has significant stack usage.
here's 2.5k from submit_bio() on virtio block device:
Depth Size Location (44 entries)
----- ---- --------
0) 4512 64 update_curr+0x8b/0x160
1) 4448 96 enqueue_task_fair+0x39d/0xd50
2) 4352 48 enqueue_task+0x50/0x60
3) 4304 16 activate_task+0x23/0x30
4) 4288 32 ttwu_do_activate.constprop.84+0x3c/0x70
5) 4256 96 try_to_wake_up+0x1b4/0x2c0
6) 4160 16 default_wake_function+0x12/0x20
7) 4144 32 autoremove_wake_function+0x16/0x40
8) 4112 80 __wake_up_common+0x55/0x90
9) 4032 64 __wake_up+0x48/0x70
10) 3968 80 wakeup_kswapd+0xe7/0x130
11) 3888 256 __alloc_pages_nodemask+0x371/0x8e0
12) 3632 80 alloc_pages_current+0xb2/0x170
13) 3552 64 new_slab+0x265/0x2e0
14) 3488 240 __slab_alloc+0x2fb/0x4c4
15) 3248 80 __kmalloc+0x133/0x180
16) 3168 112 virtqueue_add_sgs+0x2fe/0x520
17) 3056 288 __virtblk_add_req+0xd5/0x180
18) 2768 96 virtio_queue_rq+0xdd/0x1d0
19) 2672 112 __blk_mq_run_hw_queue+0x1c3/0x3c0
20) 2560 16 blk_mq_run_hw_queue+0x35/0x40
21) 2544 80 blk_mq_insert_requests+0xc5/0x120
22) 2464 96 blk_mq_flush_plug_list+0x129/0x140
23) 2368 112 blk_flush_plug_list+0xe7/0x240
24) 2256 128 blk_mq_make_request+0x3ca/0x510
25) 2128 48 generic_make_request+0xc0/0x110
26) 2080 96 submit_bio+0x71/0x120
You can also see the difference in stack usage that the blk_mq layer
adds compared to the previous trace that went through the old
code to get to the SCSI stack.
And you saw the memory reclaim via shrinker path taht I posted in
another email - that was 4700 bytes from kmem_cache_alloc() to teh
top of the stack (can be reduced to about 2000 bytes by having XFS
chop it in half).
> If the new block-mq code is to blame, it needs to be fixed.
It's a symptom of the pattern of gradual growth in just about every
core subsystem. Each individual change is not significant, but when
you put the whole stack together the canary is well and truly dead.
> __virtblk_add_req() has a 300-byte stack frame, it seems. Looking
> elsewhere, blkdev_issue_discard() has 350 bytes of stack frame, but is
> hopefully not in any normal path - online discard is moronic, and I'm
> assuming XFS doesn't do that.
We *support* it, but we don't *recommend* it. So, no, that's not the
problem path. ;)
> There's a lot of 200+ byte stack frames in block/blk-core.s, and they
> all seem to be of the type perf_trace_block_buffer() - things created
> with DECLARE_EVENT_CLASS(), afaik. Why they all have 200+ bytes of
> frame, I have no idea. That sounds like a potential disaster too,
> although hopefully it's mostly leaf functions - but leaf functions
> *deep* in the callchain. Tejun? Steven, why _do_ they end up with such
> huge frames?
And it's leaf functions that the CONFIG_STACK_TRACER doesn't catch
on x86-64 (at least, according to the documentation).
CONFIG_DEBUG_STACK_USAGE output is showing up to 800 bytes more
stack usage than the tracer. As such, I also think that
CONFIG_DEBUG_STACK_USAGE output is a more reliable iindication of
stack usage because it is canary based and so captures the very
worst case usage of the process's stack...
It really seems to me that we have got to the point where it is not
safe to do anything like submit IO or try to do memory allocation
with any more than half the stack space consumed....
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] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 6:28 ` Linus Torvalds
@ 2014-02-12 11:39 ` Al Viro
-1 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-12 11:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dave Chinner, Dave Jones, Eric Sandeen, Linux Kernel, xfs
On Tue, Feb 11, 2014 at 10:28:12PM -0800, Linus Torvalds wrote:
> It looks like just "do_signal()" has a stack frame that is about 230
> bytes even under normal circumstancs (largely due to "struct ksignal"
> - which in turn is largely due to the insane 128-byte padding in
> siginfo_t). Add a few other frames in there, and I guess that if it
> was close before, the coredump path just makes it go off.
We could, in principle, put it into task_struct and make get_signal()
return its address - do_signal() is called only in the code that does
assorted returns to userland...
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-12 11:39 ` Al Viro
0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-12 11:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dave Jones, Eric Sandeen, Linux Kernel, xfs
On Tue, Feb 11, 2014 at 10:28:12PM -0800, Linus Torvalds wrote:
> It looks like just "do_signal()" has a stack frame that is about 230
> bytes even under normal circumstancs (largely due to "struct ksignal"
> - which in turn is largely due to the insane 128-byte padding in
> siginfo_t). Add a few other frames in there, and I guess that if it
> was close before, the coredump path just makes it go off.
We could, in principle, put it into task_struct and make get_signal()
return its address - do_signal() is called only in the code that does
assorted returns to userland...
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 6:59 ` Linus Torvalds
@ 2014-02-12 12:40 ` Steven Rostedt
-1 siblings, 0 replies; 132+ messages in thread
From: Steven Rostedt @ 2014-02-12 12:40 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Chinner, Jens Axboe, Tejun Heo, Dave Jones, Al Viro,
Eric Sandeen, Linux Kernel, xfs, Ingo Molnar, Peter Zijlstra,
Frederic Weisbecker
[ Added the perf tracepoint maintainers ]
On Tue, 11 Feb 2014 22:59:58 -0800
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Tue, Feb 11, 2014 at 10:31 PM, Dave Chinner <david@fromorbit.com> wrote:
> >
> > FYI, just creating lots of files with open(O_CREAT):
> >
> > [ 348.718357] fs_mark (4828) used greatest stack depth: 2968 bytes left
> > [ 348.769846] fs_mark (4814) used greatest stack depth: 2312 bytes left
> > [ 349.777717] fs_mark (4826) used greatest stack depth: 2280 bytes left
> > [ 418.139415] fs_mark (4928) used greatest stack depth: 1936 bytes left
> > [ 460.492282] fs_mark (4993) used greatest stack depth: 1336 bytes left
> > [ 544.825418] fs_mark (5104) used greatest stack depth: 1112 bytes left
> > [ 689.503970] fs_mark (5265) used greatest stack depth: 1000 bytes left
> >
> > We've got absolutely no spare stack space anymore in the IO path.
> > And the IO path can't get much simpler than filesystem -> virtio
> > block device.
>
> Ugh, that's bad. A thousand bytes of stack space is much too close to
> any limits.
>
> Do you have the stack traces for these things so that we can look at
> worst offenders?
>
> If the new block-mq code is to blame, it needs to be fixed.
> __virtblk_add_req() has a 300-byte stack frame, it seems. Looking
> elsewhere, blkdev_issue_discard() has 350 bytes of stack frame, but is
> hopefully not in any normal path - online discard is moronic, and I'm
> assuming XFS doesn't do that.
>
> There's a lot of 200+ byte stack frames in block/blk-core.s, and they
> all seem to be of the type perf_trace_block_buffer() - things created
> with DECLARE_EVENT_CLASS(), afaik. Why they all have 200+ bytes of
> frame, I have no idea. That sounds like a potential disaster too,
> although hopefully it's mostly leaf functions - but leaf functions
> *deep* in the callchain. Tejun? Steven, why _do_ they end up with such
> huge frames?
The perf_trace_##event is defined in include/trace/ftrace.h.
There we have this:
perf_trace_##call(void *__data, proto) \
{ \
struct ftrace_event_call *event_call = __data; \
struct ftrace_data_offsets_##call __maybe_unused __data_offsets;\
struct ftrace_raw_##call *entry; \
struct pt_regs __regs; \
u64 __addr = 0, __count = 1; \
struct task_struct *__task = NULL; \
struct hlist_head *head; \
int __entry_size; \
int __data_size; \
int rctx; \
\
Mostly pointers except for two structures. The __data_offests, is
dynamically defined, and only consists of values from the tracepoint
entry_structure that defines dynamic arrays. But the other structure on
the stack looks a bit harrier. The pt_regs structure.
That's what? 21 unsigned longs? 21 * 8 = 168. I think that's the
culprit here.
Peter and Frederic, is there a way not to store that on the stack?
-- Steve
>
> And if the stack use comes from the VFS layer, we can probably work on
> that too. But I don't think that has really changed much lately..
>
> Linus
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-12 12:40 ` Steven Rostedt
0 siblings, 0 replies; 132+ messages in thread
From: Steven Rostedt @ 2014-02-12 12:40 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jens Axboe, Peter Zijlstra, Eric Sandeen, Linux Kernel, xfs,
Al Viro, Frederic Weisbecker, Tejun Heo, Dave Jones, Ingo Molnar
[ Added the perf tracepoint maintainers ]
On Tue, 11 Feb 2014 22:59:58 -0800
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Tue, Feb 11, 2014 at 10:31 PM, Dave Chinner <david@fromorbit.com> wrote:
> >
> > FYI, just creating lots of files with open(O_CREAT):
> >
> > [ 348.718357] fs_mark (4828) used greatest stack depth: 2968 bytes left
> > [ 348.769846] fs_mark (4814) used greatest stack depth: 2312 bytes left
> > [ 349.777717] fs_mark (4826) used greatest stack depth: 2280 bytes left
> > [ 418.139415] fs_mark (4928) used greatest stack depth: 1936 bytes left
> > [ 460.492282] fs_mark (4993) used greatest stack depth: 1336 bytes left
> > [ 544.825418] fs_mark (5104) used greatest stack depth: 1112 bytes left
> > [ 689.503970] fs_mark (5265) used greatest stack depth: 1000 bytes left
> >
> > We've got absolutely no spare stack space anymore in the IO path.
> > And the IO path can't get much simpler than filesystem -> virtio
> > block device.
>
> Ugh, that's bad. A thousand bytes of stack space is much too close to
> any limits.
>
> Do you have the stack traces for these things so that we can look at
> worst offenders?
>
> If the new block-mq code is to blame, it needs to be fixed.
> __virtblk_add_req() has a 300-byte stack frame, it seems. Looking
> elsewhere, blkdev_issue_discard() has 350 bytes of stack frame, but is
> hopefully not in any normal path - online discard is moronic, and I'm
> assuming XFS doesn't do that.
>
> There's a lot of 200+ byte stack frames in block/blk-core.s, and they
> all seem to be of the type perf_trace_block_buffer() - things created
> with DECLARE_EVENT_CLASS(), afaik. Why they all have 200+ bytes of
> frame, I have no idea. That sounds like a potential disaster too,
> although hopefully it's mostly leaf functions - but leaf functions
> *deep* in the callchain. Tejun? Steven, why _do_ they end up with such
> huge frames?
The perf_trace_##event is defined in include/trace/ftrace.h.
There we have this:
perf_trace_##call(void *__data, proto) \
{ \
struct ftrace_event_call *event_call = __data; \
struct ftrace_data_offsets_##call __maybe_unused __data_offsets;\
struct ftrace_raw_##call *entry; \
struct pt_regs __regs; \
u64 __addr = 0, __count = 1; \
struct task_struct *__task = NULL; \
struct hlist_head *head; \
int __entry_size; \
int __data_size; \
int rctx; \
\
Mostly pointers except for two structures. The __data_offests, is
dynamically defined, and only consists of values from the tracepoint
entry_structure that defines dynamic arrays. But the other structure on
the stack looks a bit harrier. The pt_regs structure.
That's what? 21 unsigned longs? 21 * 8 = 168. I think that's the
culprit here.
Peter and Frederic, is there a way not to store that on the stack?
-- Steve
>
> And if the stack use comes from the VFS layer, we can probably work on
> that too. But I don't think that has really changed much lately..
>
> Linus
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 8:13 ` Tejun Heo
@ 2014-02-12 12:44 ` Steven Rostedt
-1 siblings, 0 replies; 132+ messages in thread
From: Steven Rostedt @ 2014-02-12 12:44 UTC (permalink / raw)
To: Tejun Heo
Cc: Linus Torvalds, Dave Chinner, Jens Axboe, Dave Jones, Al Viro,
Eric Sandeen, Linux Kernel, xfs, Ingo Molnar, Peter Zijlstra,
Frederic Weisbecker
On Wed, 12 Feb 2014 03:13:33 -0500
Tejun Heo <tj@kernel.org> wrote:
> On Tue, Feb 11, 2014 at 10:59:58PM -0800, Linus Torvalds wrote:
> > There's a lot of 200+ byte stack frames in block/blk-core.s, and they
> > all seem to be of the type perf_trace_block_buffer() - things created
> > with DECLARE_EVENT_CLASS(), afaik. Why they all have 200+ bytes of
> > frame, I have no idea. That sounds like a potential disaster too,
> > although hopefully it's mostly leaf functions - but leaf functions
> > *deep* in the callchain. Tejun? Steven, why _do_ they end up with such
> > huge frames?
>
> It looks like they're essentially the same for all the automatically
> generated trace functions. I'm seeing 232 byte stack frame in most of
> them. If I'm not completely confused by these macros, these are
> generated by DECLARE_EVENT_CLASS() in include/trace/ftrace.h and
> contains struct pt_regs in the stack frame which is already 168 bytes,
> so that seems like the culprit. No idea whether this is something
> avoidable. At least they shouldn't nest in any way. Steven?
They shouldn't nest. But if the perf tracepoint is active, I don't know
how much more of the stack is used in the functions that tracepoint
calls.
-- Steve
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-12 12:44 ` Steven Rostedt
0 siblings, 0 replies; 132+ messages in thread
From: Steven Rostedt @ 2014-02-12 12:44 UTC (permalink / raw)
To: Tejun Heo
Cc: Jens Axboe, Peter Zijlstra, Eric Sandeen, Linux Kernel, xfs,
Al Viro, Frederic Weisbecker, Dave Jones, Linus Torvalds,
Ingo Molnar
On Wed, 12 Feb 2014 03:13:33 -0500
Tejun Heo <tj@kernel.org> wrote:
> On Tue, Feb 11, 2014 at 10:59:58PM -0800, Linus Torvalds wrote:
> > There's a lot of 200+ byte stack frames in block/blk-core.s, and they
> > all seem to be of the type perf_trace_block_buffer() - things created
> > with DECLARE_EVENT_CLASS(), afaik. Why they all have 200+ bytes of
> > frame, I have no idea. That sounds like a potential disaster too,
> > although hopefully it's mostly leaf functions - but leaf functions
> > *deep* in the callchain. Tejun? Steven, why _do_ they end up with such
> > huge frames?
>
> It looks like they're essentially the same for all the automatically
> generated trace functions. I'm seeing 232 byte stack frame in most of
> them. If I'm not completely confused by these macros, these are
> generated by DECLARE_EVENT_CLASS() in include/trace/ftrace.h and
> contains struct pt_regs in the stack frame which is already 168 bytes,
> so that seems like the culprit. No idea whether this is something
> avoidable. At least they shouldn't nest in any way. Steven?
They shouldn't nest. But if the perf tracepoint is active, I don't know
how much more of the stack is used in the functions that tracepoint
calls.
-- Steve
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 8:35 ` Dave Chinner
@ 2014-02-12 12:50 ` Steven Rostedt
-1 siblings, 0 replies; 132+ messages in thread
From: Steven Rostedt @ 2014-02-12 12:50 UTC (permalink / raw)
To: Dave Chinner
Cc: Linus Torvalds, Jens Axboe, Tejun Heo, Dave Jones, Al Viro,
Eric Sandeen, Linux Kernel, xfs
On Wed, 12 Feb 2014 19:35:13 +1100
Dave Chinner <david@fromorbit.com> wrote:
> And it's leaf functions that the CONFIG_STACK_TRACER doesn't catch
> on x86-64 (at least, according to the documentation).
> CONFIG_DEBUG_STACK_USAGE output is showing up to 800 bytes more
> stack usage than the tracer. As such, I also think that
> CONFIG_DEBUG_STACK_USAGE output is a more reliable iindication of
> stack usage because it is canary based and so captures the very
> worst case usage of the process's stack...
Yeah, with the new fentry (adding the mcount call before setting up the
stack frame), the function tracer can not catch leaf functions, as it
is called before the leaf function's frame is set up.
Hmm, I wonder if I should add a config to disable fentry and go back to
the old mcount that gets called after setting up the stack frame. This
will lead to better stack tracing, but you lose out on all the benefits
of fentry.
-- Steve
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-12 12:50 ` Steven Rostedt
0 siblings, 0 replies; 132+ messages in thread
From: Steven Rostedt @ 2014-02-12 12:50 UTC (permalink / raw)
To: Dave Chinner
Cc: Jens Axboe, Eric Sandeen, Linux Kernel, xfs, Al Viro, Tejun Heo,
Dave Jones, Linus Torvalds
On Wed, 12 Feb 2014 19:35:13 +1100
Dave Chinner <david@fromorbit.com> wrote:
> And it's leaf functions that the CONFIG_STACK_TRACER doesn't catch
> on x86-64 (at least, according to the documentation).
> CONFIG_DEBUG_STACK_USAGE output is showing up to 800 bytes more
> stack usage than the tracer. As such, I also think that
> CONFIG_DEBUG_STACK_USAGE output is a more reliable iindication of
> stack usage because it is canary based and so captures the very
> worst case usage of the process's stack...
Yeah, with the new fentry (adding the mcount call before setting up the
stack frame), the function tracer can not catch leaf functions, as it
is called before the leaf function's frame is set up.
Hmm, I wonder if I should add a config to disable fentry and go back to
the old mcount that gets called after setting up the stack frame. This
will lead to better stack tracing, but you lose out on all the benefits
of fentry.
-- Steve
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 12:40 ` Steven Rostedt
@ 2014-02-12 13:29 ` Peter Zijlstra
-1 siblings, 0 replies; 132+ messages in thread
From: Peter Zijlstra @ 2014-02-12 13:29 UTC (permalink / raw)
To: Steven Rostedt
Cc: Linus Torvalds, Dave Chinner, Jens Axboe, Tejun Heo, Dave Jones,
Al Viro, Eric Sandeen, Linux Kernel, xfs, Ingo Molnar,
Frederic Weisbecker
On Wed, Feb 12, 2014 at 07:40:36AM -0500, Steven Rostedt wrote:
> The pt_regs structure.
>
> That's what? 21 unsigned longs? 21 * 8 = 168. I think that's the
> culprit here.
>
> Peter and Frederic, is there a way not to store that on the stack?
Something like so?
---
include/trace/ftrace.h | 7 ++++---
kernel/trace/trace_event_perf.c | 5 ++++-
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index 1a8b28db3775..87ae3ef1d278 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -678,7 +678,7 @@ perf_trace_##call(void *__data, proto) \
struct ftrace_event_call *event_call = __data; \
struct ftrace_data_offsets_##call __maybe_unused __data_offsets;\
struct ftrace_raw_##call *entry; \
- struct pt_regs __regs; \
+ struct pt_regs *__regs; \
u64 __addr = 0, __count = 1; \
struct task_struct *__task = NULL; \
struct hlist_head *head; \
@@ -697,18 +697,19 @@ perf_trace_##call(void *__data, proto) \
sizeof(u64)); \
__entry_size -= sizeof(u32); \
\
- perf_fetch_caller_regs(&__regs); \
entry = perf_trace_buf_prepare(__entry_size, \
event_call->event.type, &__regs, &rctx); \
if (!entry) \
return; \
\
+ perf_fetch_caller_regs(__regs); \
+ \
tstruct \
\
{ assign; } \
\
perf_trace_buf_submit(entry, __entry_size, rctx, __addr, \
- __count, &__regs, head, __task); \
+ __count, __regs, head, __task); \
}
/*
diff --git a/kernel/trace/trace_event_perf.c b/kernel/trace/trace_event_perf.c
index e854f420e033..1885f4aac109 100644
--- a/kernel/trace/trace_event_perf.c
+++ b/kernel/trace/trace_event_perf.c
@@ -232,8 +232,10 @@ void perf_trace_del(struct perf_event *p_event, int flags)
tp_event->class->reg(tp_event, TRACE_REG_PERF_DEL, p_event);
}
+static DEFINE_PER_CPU(struct pt_regs, tp_regs[4]);
+
__kprobes void *perf_trace_buf_prepare(int size, unsigned short type,
- struct pt_regs *regs, int *rctxp)
+ struct pt_regs **regs, int *rctxp)
{
struct trace_entry *entry;
unsigned long flags;
@@ -252,6 +254,7 @@ __kprobes void *perf_trace_buf_prepare(int size, unsigned short type,
if (*rctxp < 0)
return NULL;
+ *regs = this_cpu_ptr(&tp_regs[*rctxp]);
raw_data = this_cpu_ptr(perf_trace_buf[*rctxp]);
/* zero the dead bytes from align to not leak stack to user */
^ permalink raw reply related [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-12 13:29 ` Peter Zijlstra
0 siblings, 0 replies; 132+ messages in thread
From: Peter Zijlstra @ 2014-02-12 13:29 UTC (permalink / raw)
To: Steven Rostedt
Cc: Jens Axboe, Eric Sandeen, Linux Kernel, xfs, Al Viro,
Frederic Weisbecker, Tejun Heo, Dave Jones, Linus Torvalds,
Ingo Molnar
On Wed, Feb 12, 2014 at 07:40:36AM -0500, Steven Rostedt wrote:
> The pt_regs structure.
>
> That's what? 21 unsigned longs? 21 * 8 = 168. I think that's the
> culprit here.
>
> Peter and Frederic, is there a way not to store that on the stack?
Something like so?
---
include/trace/ftrace.h | 7 ++++---
kernel/trace/trace_event_perf.c | 5 ++++-
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index 1a8b28db3775..87ae3ef1d278 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -678,7 +678,7 @@ perf_trace_##call(void *__data, proto) \
struct ftrace_event_call *event_call = __data; \
struct ftrace_data_offsets_##call __maybe_unused __data_offsets;\
struct ftrace_raw_##call *entry; \
- struct pt_regs __regs; \
+ struct pt_regs *__regs; \
u64 __addr = 0, __count = 1; \
struct task_struct *__task = NULL; \
struct hlist_head *head; \
@@ -697,18 +697,19 @@ perf_trace_##call(void *__data, proto) \
sizeof(u64)); \
__entry_size -= sizeof(u32); \
\
- perf_fetch_caller_regs(&__regs); \
entry = perf_trace_buf_prepare(__entry_size, \
event_call->event.type, &__regs, &rctx); \
if (!entry) \
return; \
\
+ perf_fetch_caller_regs(__regs); \
+ \
tstruct \
\
{ assign; } \
\
perf_trace_buf_submit(entry, __entry_size, rctx, __addr, \
- __count, &__regs, head, __task); \
+ __count, __regs, head, __task); \
}
/*
diff --git a/kernel/trace/trace_event_perf.c b/kernel/trace/trace_event_perf.c
index e854f420e033..1885f4aac109 100644
--- a/kernel/trace/trace_event_perf.c
+++ b/kernel/trace/trace_event_perf.c
@@ -232,8 +232,10 @@ void perf_trace_del(struct perf_event *p_event, int flags)
tp_event->class->reg(tp_event, TRACE_REG_PERF_DEL, p_event);
}
+static DEFINE_PER_CPU(struct pt_regs, tp_regs[4]);
+
__kprobes void *perf_trace_buf_prepare(int size, unsigned short type,
- struct pt_regs *regs, int *rctxp)
+ struct pt_regs **regs, int *rctxp)
{
struct trace_entry *entry;
unsigned long flags;
@@ -252,6 +254,7 @@ __kprobes void *perf_trace_buf_prepare(int size, unsigned short type,
if (*rctxp < 0)
return NULL;
+ *regs = this_cpu_ptr(&tp_regs[*rctxp]);
raw_data = this_cpu_ptr(perf_trace_buf[*rctxp]);
/* zero the dead bytes from align to not leak stack to user */
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply related [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 6:10 ` Dave Chinner
@ 2014-02-12 14:25 ` Dave Jones
-1 siblings, 0 replies; 132+ messages in thread
From: Dave Jones @ 2014-02-12 14:25 UTC (permalink / raw)
To: Dave Chinner; +Cc: Al Viro, Linus Torvalds, Eric Sandeen, Linux Kernel, xfs
On Wed, Feb 12, 2014 at 05:10:38PM +1100, Dave Chinner wrote:
> On Wed, Feb 12, 2014 at 12:50:27AM -0500, Dave Jones wrote:
> > On Wed, Feb 12, 2014 at 04:40:43PM +1100, Dave Chinner wrote:
> >
> > > None of the XFS code disables interrupts in that path, not does is
> > > call outside XFS except to dispatch IO. The stack is pretty deep at
> > > this point and I know that the standard (non stacked) IO stack can
> > > consume >3kb of stack space when it gets down to having to do memory
> > > reclaim during GFP_NOIO allocation at the lowest level of SCSI
> > > drivers. Stack overruns typically show up with symptoms like we are
> > > seeing.
> > > ..
> > >
> > > Dave, before chasing ghosts, can you (like Eric originally asked)
> > > turn on stack overrun detection?
> >
> > CONFIG_DEBUG_STACKOVERFLOW ? Already turned on.
>
> That only checks stack usage when an interrupt is taken. If no
> interrupts are taken when stack usage is within 128 bytes of
> overflow, then it doesn't catch it.
>
> I tend to use CONFIG_DEBUG_STACK_USAGE=y as it records the maximum
> stack usage of a process via canary overwrites and it records it in
> do_exit().
I had that on too. The only message from it came from quite a while
before the trace that happened overnight..
[ 3415.655125] trinity-c0 (4383) used greatest stack depth: 992 bytes left
[12900.804230] BUG: sleeping function called from invalid context at mm/mempool.c:203
> I also use the stack tracer to record the largest stack
> usage seen so I know exactly what code paths are approaching stack
> overruns...
I can give that a try later.
Dave
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-12 14:25 ` Dave Jones
0 siblings, 0 replies; 132+ messages in thread
From: Dave Jones @ 2014-02-12 14:25 UTC (permalink / raw)
To: Dave Chinner; +Cc: Eric Sandeen, xfs, Linus Torvalds, Al Viro, Linux Kernel
On Wed, Feb 12, 2014 at 05:10:38PM +1100, Dave Chinner wrote:
> On Wed, Feb 12, 2014 at 12:50:27AM -0500, Dave Jones wrote:
> > On Wed, Feb 12, 2014 at 04:40:43PM +1100, Dave Chinner wrote:
> >
> > > None of the XFS code disables interrupts in that path, not does is
> > > call outside XFS except to dispatch IO. The stack is pretty deep at
> > > this point and I know that the standard (non stacked) IO stack can
> > > consume >3kb of stack space when it gets down to having to do memory
> > > reclaim during GFP_NOIO allocation at the lowest level of SCSI
> > > drivers. Stack overruns typically show up with symptoms like we are
> > > seeing.
> > > ..
> > >
> > > Dave, before chasing ghosts, can you (like Eric originally asked)
> > > turn on stack overrun detection?
> >
> > CONFIG_DEBUG_STACKOVERFLOW ? Already turned on.
>
> That only checks stack usage when an interrupt is taken. If no
> interrupts are taken when stack usage is within 128 bytes of
> overflow, then it doesn't catch it.
>
> I tend to use CONFIG_DEBUG_STACK_USAGE=y as it records the maximum
> stack usage of a process via canary overwrites and it records it in
> do_exit().
I had that on too. The only message from it came from quite a while
before the trace that happened overnight..
[ 3415.655125] trinity-c0 (4383) used greatest stack depth: 992 bytes left
[12900.804230] BUG: sleeping function called from invalid context at mm/mempool.c:203
> I also use the stack tracer to record the largest stack
> usage seen so I know exactly what code paths are approaching stack
> overruns...
I can give that a try later.
Dave
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 6:10 ` Dave Chinner
@ 2014-02-12 15:57 ` Eric Sandeen
-1 siblings, 0 replies; 132+ messages in thread
From: Eric Sandeen @ 2014-02-12 15:57 UTC (permalink / raw)
To: Dave Chinner, Dave Jones, Al Viro, Linus Torvalds, Linux Kernel, xfs
On 2/12/14, 12:10 AM, Dave Chinner wrote:
> On Wed, Feb 12, 2014 at 12:50:27AM -0500, Dave Jones wrote:
>> On Wed, Feb 12, 2014 at 04:40:43PM +1100, Dave Chinner wrote:
>>
>> > None of the XFS code disables interrupts in that path, not does is
>> > call outside XFS except to dispatch IO. The stack is pretty deep at
>> > this point and I know that the standard (non stacked) IO stack can
>> > consume >3kb of stack space when it gets down to having to do memory
>> > reclaim during GFP_NOIO allocation at the lowest level of SCSI
>> > drivers. Stack overruns typically show up with symptoms like we are
>> > seeing.
>> > ..
>> >
>> > Dave, before chasing ghosts, can you (like Eric originally asked)
>> > turn on stack overrun detection?
>>
>> CONFIG_DEBUG_STACKOVERFLOW ? Already turned on.
>
> That only checks stack usage when an interrupt is taken. If no
> interrupts are taken when stack usage is within 128 bytes of
> overflow, then it doesn't catch it.
>
> I tend to use CONFIG_DEBUG_STACK_USAGE=y as it records the maximum
> stack usage of a process via canary overwrites and it records it in
> do_exit(). I also use the stack tracer to record the largest stack
> usage seen so I know exactly what code paths are approaching stack
> overruns...
>
> Cheers,
>
> Dave.
>
I'm not sure if I'm off base here, but maybe this would make sense: check
for a corrupted stack in __might_sleep. Compile tested only,
possibly inelegant, and/or completely wrong, but:
From: Eric Sandeen <sandeen@redhat.com>
sched: Test for corrupted task_struct in __might_sleep
If a thread overruns the stack, it may corrupt the task_struct,
leading to false positives on tests like irqs_disabled().
Warn if this seems to be the case.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
---
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index b46131e..6920c3c 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6934,6 +6934,8 @@ static inline int preempt_count_equals(int preempt_offset)
void __might_sleep(const char *file, int line, int preempt_offset)
{
+ struct task_struct *tsk = current;
+ unsigned long *stackend;
static unsigned long prev_jiffy; /* ratelimiting */
rcu_sleep_check(); /* WARN_ON_ONCE() by default, no rate limit reqd. */
@@ -6952,6 +6954,11 @@ void __might_sleep(const char *file, int line, int preempt_offset)
in_atomic(), irqs_disabled(),
current->pid, current->comm);
+ /* A corrupted stack can cause a false positive on irqs_disabled etc */
+ stackend = end_of_stack(tsk);
+ if (tsk != &init_task && *stackend != STACK_END_MAGIC)
+ printk(KERN_EMERG "Thread overran stack, or stack corrupted\n");
+
debug_show_held_locks(current);
if (irqs_disabled())
print_irqtrace_events(current);
^ permalink raw reply related [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-12 15:57 ` Eric Sandeen
0 siblings, 0 replies; 132+ messages in thread
From: Eric Sandeen @ 2014-02-12 15:57 UTC (permalink / raw)
To: Dave Chinner, Dave Jones, Al Viro, Linus Torvalds, Linux Kernel, xfs
On 2/12/14, 12:10 AM, Dave Chinner wrote:
> On Wed, Feb 12, 2014 at 12:50:27AM -0500, Dave Jones wrote:
>> On Wed, Feb 12, 2014 at 04:40:43PM +1100, Dave Chinner wrote:
>>
>> > None of the XFS code disables interrupts in that path, not does is
>> > call outside XFS except to dispatch IO. The stack is pretty deep at
>> > this point and I know that the standard (non stacked) IO stack can
>> > consume >3kb of stack space when it gets down to having to do memory
>> > reclaim during GFP_NOIO allocation at the lowest level of SCSI
>> > drivers. Stack overruns typically show up with symptoms like we are
>> > seeing.
>> > ..
>> >
>> > Dave, before chasing ghosts, can you (like Eric originally asked)
>> > turn on stack overrun detection?
>>
>> CONFIG_DEBUG_STACKOVERFLOW ? Already turned on.
>
> That only checks stack usage when an interrupt is taken. If no
> interrupts are taken when stack usage is within 128 bytes of
> overflow, then it doesn't catch it.
>
> I tend to use CONFIG_DEBUG_STACK_USAGE=y as it records the maximum
> stack usage of a process via canary overwrites and it records it in
> do_exit(). I also use the stack tracer to record the largest stack
> usage seen so I know exactly what code paths are approaching stack
> overruns...
>
> Cheers,
>
> Dave.
>
I'm not sure if I'm off base here, but maybe this would make sense: check
for a corrupted stack in __might_sleep. Compile tested only,
possibly inelegant, and/or completely wrong, but:
From: Eric Sandeen <sandeen@redhat.com>
sched: Test for corrupted task_struct in __might_sleep
If a thread overruns the stack, it may corrupt the task_struct,
leading to false positives on tests like irqs_disabled().
Warn if this seems to be the case.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
---
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index b46131e..6920c3c 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6934,6 +6934,8 @@ static inline int preempt_count_equals(int preempt_offset)
void __might_sleep(const char *file, int line, int preempt_offset)
{
+ struct task_struct *tsk = current;
+ unsigned long *stackend;
static unsigned long prev_jiffy; /* ratelimiting */
rcu_sleep_check(); /* WARN_ON_ONCE() by default, no rate limit reqd. */
@@ -6952,6 +6954,11 @@ void __might_sleep(const char *file, int line, int preempt_offset)
in_atomic(), irqs_disabled(),
current->pid, current->comm);
+ /* A corrupted stack can cause a false positive on irqs_disabled etc */
+ stackend = end_of_stack(tsk);
+ if (tsk != &init_task && *stackend != STACK_END_MAGIC)
+ printk(KERN_EMERG "Thread overran stack, or stack corrupted\n");
+
debug_show_held_locks(current);
if (irqs_disabled())
print_irqtrace_events(current);
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply related [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 11:39 ` Al Viro
@ 2014-02-12 20:13 ` Linus Torvalds
-1 siblings, 0 replies; 132+ messages in thread
From: Linus Torvalds @ 2014-02-12 20:13 UTC (permalink / raw)
To: Al Viro; +Cc: Dave Chinner, Dave Jones, Eric Sandeen, Linux Kernel, xfs
On Wed, Feb 12, 2014 at 3:39 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Tue, Feb 11, 2014 at 10:28:12PM -0800, Linus Torvalds wrote:
>
>> It looks like just "do_signal()" has a stack frame that is about 230
>> bytes even under normal circumstancs (largely due to "struct ksignal"
>> - which in turn is largely due to the insane 128-byte padding in
>> siginfo_t). Add a few other frames in there, and I guess that if it
>> was close before, the coredump path just makes it go off.
>
> We could, in principle, put it into task_struct and make get_signal()
> return its address - do_signal() is called only in the code that does
> assorted returns to userland...
We have better uses for random buffers in "struct task_struct", I'd
hate to put a siginfo_t there.
The thing is, siginfo_t has that idiotic 128-byte area, but it's all
"for future expansion". I think it's some damn glibc disease - we've
seen these kinds of insane paddings before.
The actual *useful* part of siginfo_t is on the order of 32 bytes. If that.
Sad.
Linus
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-12 20:13 ` Linus Torvalds
0 siblings, 0 replies; 132+ messages in thread
From: Linus Torvalds @ 2014-02-12 20:13 UTC (permalink / raw)
To: Al Viro; +Cc: Dave Jones, Eric Sandeen, Linux Kernel, xfs
On Wed, Feb 12, 2014 at 3:39 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Tue, Feb 11, 2014 at 10:28:12PM -0800, Linus Torvalds wrote:
>
>> It looks like just "do_signal()" has a stack frame that is about 230
>> bytes even under normal circumstancs (largely due to "struct ksignal"
>> - which in turn is largely due to the insane 128-byte padding in
>> siginfo_t). Add a few other frames in there, and I guess that if it
>> was close before, the coredump path just makes it go off.
>
> We could, in principle, put it into task_struct and make get_signal()
> return its address - do_signal() is called only in the code that does
> assorted returns to userland...
We have better uses for random buffers in "struct task_struct", I'd
hate to put a siginfo_t there.
The thing is, siginfo_t has that idiotic 128-byte area, but it's all
"for future expansion". I think it's some damn glibc disease - we've
seen these kinds of insane paddings before.
The actual *useful* part of siginfo_t is on the order of 32 bytes. If that.
Sad.
Linus
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 20:13 ` Linus Torvalds
@ 2014-02-12 21:14 ` Al Viro
-1 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-12 21:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dave Chinner, Dave Jones, Eric Sandeen, Linux Kernel, xfs
On Wed, Feb 12, 2014 at 12:13:19PM -0800, Linus Torvalds wrote:
> On Wed, Feb 12, 2014 at 3:39 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> > On Tue, Feb 11, 2014 at 10:28:12PM -0800, Linus Torvalds wrote:
> >
> >> It looks like just "do_signal()" has a stack frame that is about 230
> >> bytes even under normal circumstancs (largely due to "struct ksignal"
> >> - which in turn is largely due to the insane 128-byte padding in
> >> siginfo_t). Add a few other frames in there, and I guess that if it
> >> was close before, the coredump path just makes it go off.
> >
> > We could, in principle, put it into task_struct and make get_signal()
> > return its address - do_signal() is called only in the code that does
> > assorted returns to userland...
>
> We have better uses for random buffers in "struct task_struct", I'd
> hate to put a siginfo_t there.
*nod*
> The thing is, siginfo_t has that idiotic 128-byte area, but it's all
> "for future expansion". I think it's some damn glibc disease - we've
> seen these kinds of insane paddings before.
>
> The actual *useful* part of siginfo_t is on the order of 32 bytes. If that.
>
> Sad.
Umm... What if we delay __sigqueue_free()? After all, that's where the
fat sucker normally comes from. That way we might get away with much
smaller structure on stack...
Just introduce a small structure that would contain signr, uid, pid and
pointer to struct sigqueue. And pass a pointer to _that_ all the way down
to collect_signal(). Pointer's NULL == it's SI_USER with signr/uid/pid
from the small struct and all other fields are zero. Pointer isn't NULL -
use &small_struct->p->info. And have struct sigqueue actually freed
via task_work_add() in that case.
Do you see any fundamental problems with that? Looks like it would be
faster as well - less copying involved...
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-12 21:14 ` Al Viro
0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-12 21:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dave Jones, Eric Sandeen, Linux Kernel, xfs
On Wed, Feb 12, 2014 at 12:13:19PM -0800, Linus Torvalds wrote:
> On Wed, Feb 12, 2014 at 3:39 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> > On Tue, Feb 11, 2014 at 10:28:12PM -0800, Linus Torvalds wrote:
> >
> >> It looks like just "do_signal()" has a stack frame that is about 230
> >> bytes even under normal circumstancs (largely due to "struct ksignal"
> >> - which in turn is largely due to the insane 128-byte padding in
> >> siginfo_t). Add a few other frames in there, and I guess that if it
> >> was close before, the coredump path just makes it go off.
> >
> > We could, in principle, put it into task_struct and make get_signal()
> > return its address - do_signal() is called only in the code that does
> > assorted returns to userland...
>
> We have better uses for random buffers in "struct task_struct", I'd
> hate to put a siginfo_t there.
*nod*
> The thing is, siginfo_t has that idiotic 128-byte area, but it's all
> "for future expansion". I think it's some damn glibc disease - we've
> seen these kinds of insane paddings before.
>
> The actual *useful* part of siginfo_t is on the order of 32 bytes. If that.
>
> Sad.
Umm... What if we delay __sigqueue_free()? After all, that's where the
fat sucker normally comes from. That way we might get away with much
smaller structure on stack...
Just introduce a small structure that would contain signr, uid, pid and
pointer to struct sigqueue. And pass a pointer to _that_ all the way down
to collect_signal(). Pointer's NULL == it's SI_USER with signr/uid/pid
from the small struct and all other fields are zero. Pointer isn't NULL -
use &small_struct->p->info. And have struct sigqueue actually freed
via task_work_add() in that case.
Do you see any fundamental problems with that? Looks like it would be
faster as well - less copying involved...
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 14:25 ` Dave Jones
@ 2014-02-12 21:14 ` Dave Chinner
-1 siblings, 0 replies; 132+ messages in thread
From: Dave Chinner @ 2014-02-12 21:14 UTC (permalink / raw)
To: Dave Jones, Al Viro, Linus Torvalds, Eric Sandeen, Linux Kernel, xfs
On Wed, Feb 12, 2014 at 09:25:38AM -0500, Dave Jones wrote:
> On Wed, Feb 12, 2014 at 05:10:38PM +1100, Dave Chinner wrote:
> > On Wed, Feb 12, 2014 at 12:50:27AM -0500, Dave Jones wrote:
> > > On Wed, Feb 12, 2014 at 04:40:43PM +1100, Dave Chinner wrote:
> > >
> > > > None of the XFS code disables interrupts in that path, not does is
> > > > call outside XFS except to dispatch IO. The stack is pretty deep at
> > > > this point and I know that the standard (non stacked) IO stack can
> > > > consume >3kb of stack space when it gets down to having to do memory
> > > > reclaim during GFP_NOIO allocation at the lowest level of SCSI
> > > > drivers. Stack overruns typically show up with symptoms like we are
> > > > seeing.
> > > > ..
> > > >
> > > > Dave, before chasing ghosts, can you (like Eric originally asked)
> > > > turn on stack overrun detection?
> > >
> > > CONFIG_DEBUG_STACKOVERFLOW ? Already turned on.
> >
> > That only checks stack usage when an interrupt is taken. If no
> > interrupts are taken when stack usage is within 128 bytes of
> > overflow, then it doesn't catch it.
> >
> > I tend to use CONFIG_DEBUG_STACK_USAGE=y as it records the maximum
> > stack usage of a process via canary overwrites and it records it in
> > do_exit().
>
> I had that on too. The only message from it came from quite a while
> before the trace that happened overnight..
Right, it won't capture an overrun at the point in time an overrun
occurs, either, because it only checks when the process exits. But
it does tell you what stack usage is being seen, as this:
> [ 3415.655125] trinity-c0 (4383) used greatest stack depth: 992 bytes left
> [12900.804230] BUG: sleeping function called from invalid context at mm/mempool.c:203
is a pretty a good indication that trinity is at risk of stack
overuns...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-12 21:14 ` Dave Chinner
0 siblings, 0 replies; 132+ messages in thread
From: Dave Chinner @ 2014-02-12 21:14 UTC (permalink / raw)
To: Dave Jones, Al Viro, Linus Torvalds, Eric Sandeen, Linux Kernel, xfs
On Wed, Feb 12, 2014 at 09:25:38AM -0500, Dave Jones wrote:
> On Wed, Feb 12, 2014 at 05:10:38PM +1100, Dave Chinner wrote:
> > On Wed, Feb 12, 2014 at 12:50:27AM -0500, Dave Jones wrote:
> > > On Wed, Feb 12, 2014 at 04:40:43PM +1100, Dave Chinner wrote:
> > >
> > > > None of the XFS code disables interrupts in that path, not does is
> > > > call outside XFS except to dispatch IO. The stack is pretty deep at
> > > > this point and I know that the standard (non stacked) IO stack can
> > > > consume >3kb of stack space when it gets down to having to do memory
> > > > reclaim during GFP_NOIO allocation at the lowest level of SCSI
> > > > drivers. Stack overruns typically show up with symptoms like we are
> > > > seeing.
> > > > ..
> > > >
> > > > Dave, before chasing ghosts, can you (like Eric originally asked)
> > > > turn on stack overrun detection?
> > >
> > > CONFIG_DEBUG_STACKOVERFLOW ? Already turned on.
> >
> > That only checks stack usage when an interrupt is taken. If no
> > interrupts are taken when stack usage is within 128 bytes of
> > overflow, then it doesn't catch it.
> >
> > I tend to use CONFIG_DEBUG_STACK_USAGE=y as it records the maximum
> > stack usage of a process via canary overwrites and it records it in
> > do_exit().
>
> I had that on too. The only message from it came from quite a while
> before the trace that happened overnight..
Right, it won't capture an overrun at the point in time an overrun
occurs, either, because it only checks when the process exits. But
it does tell you what stack usage is being seen, as this:
> [ 3415.655125] trinity-c0 (4383) used greatest stack depth: 992 bytes left
> [12900.804230] BUG: sleeping function called from invalid context at mm/mempool.c:203
is a pretty a good indication that trinity is at risk of stack
overuns...
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] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 21:14 ` Al Viro
@ 2014-02-12 21:32 ` Linus Torvalds
-1 siblings, 0 replies; 132+ messages in thread
From: Linus Torvalds @ 2014-02-12 21:32 UTC (permalink / raw)
To: Al Viro, Oleg Nesterov
Cc: Dave Chinner, Dave Jones, Eric Sandeen, Linux Kernel, xfs
On Wed, Feb 12, 2014 at 1:14 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> Umm... What if we delay __sigqueue_free()? After all, that's where the
> fat sucker normally comes from. That way we might get away with much
> smaller structure on stack...
Sounds like the RightThing(tm) to do to me, and I don't see why it
wouldn't work.
We'd have to teach each user of "dequeue_signal()" to free the siginfo
thing. Which shouldn't be too bad - I think we've collected all of
that into generic code, and there isn't the mass or architecture code
that knows about these things any more. But there are a few odd
drivers etc and signalfd. I didn't look at what the lifetimes were.
Adding Oleg to the cc, since any time we touch any of that code, he
should be involved. Oleg - the issue is the biggish size of 'struct
ksignal' on stack, brought on by the silly "put a whole siginfo_t in
it".
Linus
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-12 21:32 ` Linus Torvalds
0 siblings, 0 replies; 132+ messages in thread
From: Linus Torvalds @ 2014-02-12 21:32 UTC (permalink / raw)
To: Al Viro, Oleg Nesterov; +Cc: Dave Jones, Eric Sandeen, Linux Kernel, xfs
On Wed, Feb 12, 2014 at 1:14 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> Umm... What if we delay __sigqueue_free()? After all, that's where the
> fat sucker normally comes from. That way we might get away with much
> smaller structure on stack...
Sounds like the RightThing(tm) to do to me, and I don't see why it
wouldn't work.
We'd have to teach each user of "dequeue_signal()" to free the siginfo
thing. Which shouldn't be too bad - I think we've collected all of
that into generic code, and there isn't the mass or architecture code
that knows about these things any more. But there are a few odd
drivers etc and signalfd. I didn't look at what the lifetimes were.
Adding Oleg to the cc, since any time we touch any of that code, he
should be involved. Oleg - the issue is the biggish size of 'struct
ksignal' on stack, brought on by the silly "put a whole siginfo_t in
it".
Linus
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 21:32 ` Linus Torvalds
@ 2014-02-12 21:44 ` Al Viro
-1 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-12 21:44 UTC (permalink / raw)
To: Linus Torvalds
Cc: Oleg Nesterov, Dave Chinner, Dave Jones, Eric Sandeen, Linux Kernel, xfs
On Wed, Feb 12, 2014 at 01:32:55PM -0800, Linus Torvalds wrote:
> On Wed, Feb 12, 2014 at 1:14 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > Umm... What if we delay __sigqueue_free()? After all, that's where the
> > fat sucker normally comes from. That way we might get away with much
> > smaller structure on stack...
>
> Sounds like the RightThing(tm) to do to me, and I don't see why it
> wouldn't work.
>
> We'd have to teach each user of "dequeue_signal()" to free the siginfo
> thing. Which shouldn't be too bad - I think we've collected all of
> that into generic code, and there isn't the mass or architecture code
> that knows about these things any more. But there are a few odd
> drivers etc and signalfd. I didn't look at what the lifetimes were.
Only signalfd, AFAICS. And there we'd want to use the same small structure -
it's used in
do {
ret = signalfd_dequeue(ctx, &info, nonblock);
if (unlikely(ret <= 0))
break;
ret = signalfd_copyinfo(siginfo, &info);
if (ret < 0)
break;
siginfo++;
total += ret;
nonblock = 1;
} while (--count);
and using a smaller struct would actually speed the things up - skips one
copying. sigqueue would be freed as soon as we'd done signalfd_copyinfo()
(if not by signalfd_copyinfo() itself).
I'll try to put something along those lines together, if you or Oleg don't
do it first.
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-12 21:44 ` Al Viro
0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-12 21:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Eric Sandeen, Oleg Nesterov, xfs, Dave Jones, Linux Kernel
On Wed, Feb 12, 2014 at 01:32:55PM -0800, Linus Torvalds wrote:
> On Wed, Feb 12, 2014 at 1:14 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > Umm... What if we delay __sigqueue_free()? After all, that's where the
> > fat sucker normally comes from. That way we might get away with much
> > smaller structure on stack...
>
> Sounds like the RightThing(tm) to do to me, and I don't see why it
> wouldn't work.
>
> We'd have to teach each user of "dequeue_signal()" to free the siginfo
> thing. Which shouldn't be too bad - I think we've collected all of
> that into generic code, and there isn't the mass or architecture code
> that knows about these things any more. But there are a few odd
> drivers etc and signalfd. I didn't look at what the lifetimes were.
Only signalfd, AFAICS. And there we'd want to use the same small structure -
it's used in
do {
ret = signalfd_dequeue(ctx, &info, nonblock);
if (unlikely(ret <= 0))
break;
ret = signalfd_copyinfo(siginfo, &info);
if (ret < 0)
break;
siginfo++;
total += ret;
nonblock = 1;
} while (--count);
and using a smaller struct would actually speed the things up - skips one
copying. sigqueue would be freed as soon as we'd done signalfd_copyinfo()
(if not by signalfd_copyinfo() itself).
I'll try to put something along those lines together, if you or Oleg don't
do it first.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 21:32 ` Linus Torvalds
@ 2014-02-13 17:40 ` Oleg Nesterov
-1 siblings, 0 replies; 132+ messages in thread
From: Oleg Nesterov @ 2014-02-13 17:40 UTC (permalink / raw)
To: Linus Torvalds
Cc: Al Viro, Dave Chinner, Dave Jones, Eric Sandeen, Linux Kernel, xfs
On 02/12, Linus Torvalds wrote:
>
> On Wed, Feb 12, 2014 at 1:14 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > Umm... What if we delay __sigqueue_free()? After all, that's where the
> > fat sucker normally comes from. That way we might get away with much
> > smaller structure on stack...
>
> Sounds like the RightThing(tm) to do to me, and I don't see why it
> wouldn't work.
Probably... I'll try to reply tomorrow.
> We'd have to teach each user of "dequeue_signal()" to free the siginfo
> thing.
And we should be careful with SIGQUEUE_PREALLOC, at least
collect_signal() should not do list_del_init()... Plus we need to
handle the SEND_SIG_FORCED-like case.
Oleg.
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-13 17:40 ` Oleg Nesterov
0 siblings, 0 replies; 132+ messages in thread
From: Oleg Nesterov @ 2014-02-13 17:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Eric Sandeen, Linux Kernel, xfs, Al Viro, Dave Jones
On 02/12, Linus Torvalds wrote:
>
> On Wed, Feb 12, 2014 at 1:14 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > Umm... What if we delay __sigqueue_free()? After all, that's where the
> > fat sucker normally comes from. That way we might get away with much
> > smaller structure on stack...
>
> Sounds like the RightThing(tm) to do to me, and I don't see why it
> wouldn't work.
Probably... I'll try to reply tomorrow.
> We'd have to teach each user of "dequeue_signal()" to free the siginfo
> thing.
And we should be careful with SIGQUEUE_PREALLOC, at least
collect_signal() should not do list_del_init()... Plus we need to
handle the SEND_SIG_FORCED-like case.
Oleg.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-13 17:40 ` Oleg Nesterov
@ 2014-02-13 17:58 ` Linus Torvalds
-1 siblings, 0 replies; 132+ messages in thread
From: Linus Torvalds @ 2014-02-13 17:58 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Al Viro, Dave Chinner, Dave Jones, Eric Sandeen, Linux Kernel, xfs
On Thu, Feb 13, 2014 at 9:40 AM, Oleg Nesterov <oleg@redhat.com> wrote:
>
> And we should be careful with SIGQUEUE_PREALLOC, at least
> collect_signal() should not do list_del_init()... Plus we need to
> handle the SEND_SIG_FORCED-like case.
I don't think the users need to care. They'd just call
"sigqueue_free()" not knowing about our preallocations etc. That kind
of detail should be confined to inside signal.c.
But there really aren't that many users. There's a couple of
"dequeue_signal_lock()" users, but they don't actually *want* the
siginfo at all (they're kernel threads), so we can just make that
function free the siginfo immediately (and get rid of the totally
unnecessay kernel stack allocation). And outside of signal.c only
signalfd uses "dequeue_signal()" itself, and that would be the only
one that would need to be taught to use (in signalfd_copyinfo()) and
then free the sigqueue entry.
So it really looks like the right thing to do, and fairly
straightforward. But I'm leaving the coding proof to Al, since he
already offered ;)
Linus
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-13 17:58 ` Linus Torvalds
0 siblings, 0 replies; 132+ messages in thread
From: Linus Torvalds @ 2014-02-13 17:58 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: Eric Sandeen, Linux Kernel, xfs, Al Viro, Dave Jones
On Thu, Feb 13, 2014 at 9:40 AM, Oleg Nesterov <oleg@redhat.com> wrote:
>
> And we should be careful with SIGQUEUE_PREALLOC, at least
> collect_signal() should not do list_del_init()... Plus we need to
> handle the SEND_SIG_FORCED-like case.
I don't think the users need to care. They'd just call
"sigqueue_free()" not knowing about our preallocations etc. That kind
of detail should be confined to inside signal.c.
But there really aren't that many users. There's a couple of
"dequeue_signal_lock()" users, but they don't actually *want* the
siginfo at all (they're kernel threads), so we can just make that
function free the siginfo immediately (and get rid of the totally
unnecessay kernel stack allocation). And outside of signal.c only
signalfd uses "dequeue_signal()" itself, and that would be the only
one that would need to be taught to use (in signalfd_copyinfo()) and
then free the sigqueue entry.
So it really looks like the right thing to do, and fairly
straightforward. But I'm leaving the coding proof to Al, since he
already offered ;)
Linus
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-13 17:58 ` Linus Torvalds
@ 2014-02-13 18:10 ` Oleg Nesterov
-1 siblings, 0 replies; 132+ messages in thread
From: Oleg Nesterov @ 2014-02-13 18:10 UTC (permalink / raw)
To: Linus Torvalds
Cc: Al Viro, Dave Chinner, Dave Jones, Eric Sandeen, Linux Kernel, xfs
On 02/13, Linus Torvalds wrote:
>
> On Thu, Feb 13, 2014 at 9:40 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > And we should be careful with SIGQUEUE_PREALLOC, at least
> > collect_signal() should not do list_del_init()... Plus we need to
> > handle the SEND_SIG_FORCED-like case.
>
> I don't think the users need to care. They'd just call
> "sigqueue_free()" not knowing about our preallocations etc.
Yes, but we need to be careful to avoid the races with
release_posix_timer().
> That kind
> of detail should be confined to inside signal.c.
Yes, sure.
> But there really aren't that many users. There's a couple of
> "dequeue_signal_lock()" users, but they don't actually *want* the
> siginfo at all (they're kernel threads), so we can just make that
> function free the siginfo immediately (and get rid of the totally
> unnecessay kernel stack allocation).
Yes. Perhaps this helper should be changed/renamed. And perhaps we
can even change __send_signal() to avoid __sigqueue_alloc() if
PF_KTHREAD. Or sig == SIGKILL.
Oleg.
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-13 18:10 ` Oleg Nesterov
0 siblings, 0 replies; 132+ messages in thread
From: Oleg Nesterov @ 2014-02-13 18:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Eric Sandeen, Linux Kernel, xfs, Al Viro, Dave Jones
On 02/13, Linus Torvalds wrote:
>
> On Thu, Feb 13, 2014 at 9:40 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > And we should be careful with SIGQUEUE_PREALLOC, at least
> > collect_signal() should not do list_del_init()... Plus we need to
> > handle the SEND_SIG_FORCED-like case.
>
> I don't think the users need to care. They'd just call
> "sigqueue_free()" not knowing about our preallocations etc.
Yes, but we need to be careful to avoid the races with
release_posix_timer().
> That kind
> of detail should be confined to inside signal.c.
Yes, sure.
> But there really aren't that many users. There's a couple of
> "dequeue_signal_lock()" users, but they don't actually *want* the
> siginfo at all (they're kernel threads), so we can just make that
> function free the siginfo immediately (and get rid of the totally
> unnecessay kernel stack allocation).
Yes. Perhaps this helper should be changed/renamed. And perhaps we
can even change __send_signal() to avoid __sigqueue_alloc() if
PF_KTHREAD. Or sig == SIGKILL.
Oleg.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-13 18:10 ` Oleg Nesterov
@ 2014-02-13 18:37 ` Oleg Nesterov
-1 siblings, 0 replies; 132+ messages in thread
From: Oleg Nesterov @ 2014-02-13 18:37 UTC (permalink / raw)
To: Linus Torvalds
Cc: Al Viro, Dave Chinner, Dave Jones, Eric Sandeen, Linux Kernel, xfs
On 02/13, Oleg Nesterov wrote:
>
> On 02/13, Linus Torvalds wrote:
> >
> > On Thu, Feb 13, 2014 at 9:40 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> > >
> > > And we should be careful with SIGQUEUE_PREALLOC, at least
> > > collect_signal() should not do list_del_init()... Plus we need to
> > > handle the SEND_SIG_FORCED-like case.
> >
> > I don't think the users need to care. They'd just call
> > "sigqueue_free()" not knowing about our preallocations etc.
>
> Yes, but we need to be careful to avoid the races with
> release_posix_timer().
Plus we need to delay do_schedule_next_timer() as well. But this
is probably good because we can avoid unlock/lock(siglock) in
dequeue_signal().
Oleg.
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-13 18:37 ` Oleg Nesterov
0 siblings, 0 replies; 132+ messages in thread
From: Oleg Nesterov @ 2014-02-13 18:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Eric Sandeen, Linux Kernel, xfs, Al Viro, Dave Jones
On 02/13, Oleg Nesterov wrote:
>
> On 02/13, Linus Torvalds wrote:
> >
> > On Thu, Feb 13, 2014 at 9:40 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> > >
> > > And we should be careful with SIGQUEUE_PREALLOC, at least
> > > collect_signal() should not do list_del_init()... Plus we need to
> > > handle the SEND_SIG_FORCED-like case.
> >
> > I don't think the users need to care. They'd just call
> > "sigqueue_free()" not knowing about our preallocations etc.
>
> Yes, but we need to be careful to avoid the races with
> release_posix_timer().
Plus we need to delay do_schedule_next_timer() as well. But this
is probably good because we can avoid unlock/lock(siglock) in
dequeue_signal().
Oleg.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 21:44 ` Al Viro
@ 2014-02-13 20:51 ` Al Viro
-1 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-13 20:51 UTC (permalink / raw)
To: Linus Torvalds
Cc: Oleg Nesterov, Dave Chinner, Dave Jones, Eric Sandeen, Linux Kernel, xfs
On Wed, Feb 12, 2014 at 09:44:11PM +0000, Al Viro wrote:
> I'll try to put something along those lines together, if you or Oleg don't
> do it first.
OK, having looked at that stuff...
1) things become much more compact if we finish conversion to get_signal()
first. Callers of get_signal_to_deliver() have k_sigaction and siginfo in
pair of local variables; switching to ksignal will be neutral wrt stack
footprint (it just gathers those two in one struct) *and* we are getting
rid of passing struct siginfo * around. With that done, we can change
struct ksignal ->info with zero impact on the code in arch/*, and conversion
makes sense on its own. In the mainline we have it done for alpha, arm,
openrisc, sparc and x86. I've just put together preliminary (and completely
untested) patches for arm64, m68k and um; doing the rest won't take long, but
they'll obviously need to be tested. It's a fairly safe conversion;
I'd expect the worst bugs to be typos.
2) struct small_siginfo ought to go into linux/signal.h. Contains signal
number, si_code (usually 0), uid, pid and (often NULL) pointer to
struct sigqueue. Overall: 20 or 24 bytes. In struct coredump_params we
should replace ->siginfo with pointer to struct small_siginfo. Ditto for
task_struct ->last_siginfo. In struct ksignal ->info becomes
struct small_siginfo.
copy_siginfo_to_user{,32}() gets switched to struct small_siginfo *, so does
do_coredump(), ptrace_signal(), ptrace_stop(), ptrace_getsiginfo(),
ptrace_setsiginfo(), collect_signal(), __dequeue_signal(), dequeue_signal(),
signalfd_dequeue() and do_sigtimedwait().
New primitive: assign_sigqueue(small_info, sigqueue). Frees
small_info->q and assigns a new value to it.
When ptrace_setsiginfo() is given a non-plain siginfo (si_code != SI_USER,
that is), it should a allocate struct sigqueue, copy the sucker there and
give it to assign_sigqueue(). Plain ones just get uid/pid/signo copied
and NULL passed to assign_sigqueue().
code in ptrace_signal() under if (signr != info->si_signo) should
start with assign_sigqueue(info, NULL).
specific_send_sig_info() in ptrace_signal() is rather clumsy to handle; not
sure what's the best way to deal with that. In any case, ptrace_signal()
deciding to return 0 should take care of info->q - either copy and free the
original, or actually try to reuse the sucker. Either way, info->q should
become NULL.
get_signal_to_deliver() should do assign_sigqueue(info, NULL) before
the call of do_group_exit().
arch_ptrace_stop_needed() can be left as-is; it's a macro and none of the
instances look at the info argument at all. The same goes for
arch_ptrace_stop().
signalfd_read() should do assign_sigqueue(&info, NULL) right after
signalfd_copyinfo().
rt_sigtimedwait(2) and its compat variant should do the same right after
copy_siginfo_to_user{,32}().
TP'ed stuff is a mess, as usual. AFAICS, TP_STORE_SIGINFO() needs to
be split into a variant taking siginfo (on trace_signal_generate side)
and one taking small_siginfo (for trace_signal_deliver).
get_signal() should do assign_sigqueue(&ksig->info, NULL) if it returns
false and use task_work_add() to schedule info->q for freeing otherwise.
Overall, aside of the need to complete arch/* conversion, the only unfinished
part is this:
/* If the (new) signal is now blocked, requeue it. */
if (sigismember(¤t->blocked, signr)) {
specific_send_sig_info(signr, info, current);
signr = 0;
}
in the end of ptrace_signal(). Sure, we can add a local struct siginfo
in that if, fill it if needed and pass its address or &info->q->info
to specific_send_sig_info(), but that feels kludgy... Hell knows, I'll
look a bit more into that.
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-13 20:51 ` Al Viro
0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-13 20:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Eric Sandeen, Oleg Nesterov, xfs, Dave Jones, Linux Kernel
On Wed, Feb 12, 2014 at 09:44:11PM +0000, Al Viro wrote:
> I'll try to put something along those lines together, if you or Oleg don't
> do it first.
OK, having looked at that stuff...
1) things become much more compact if we finish conversion to get_signal()
first. Callers of get_signal_to_deliver() have k_sigaction and siginfo in
pair of local variables; switching to ksignal will be neutral wrt stack
footprint (it just gathers those two in one struct) *and* we are getting
rid of passing struct siginfo * around. With that done, we can change
struct ksignal ->info with zero impact on the code in arch/*, and conversion
makes sense on its own. In the mainline we have it done for alpha, arm,
openrisc, sparc and x86. I've just put together preliminary (and completely
untested) patches for arm64, m68k and um; doing the rest won't take long, but
they'll obviously need to be tested. It's a fairly safe conversion;
I'd expect the worst bugs to be typos.
2) struct small_siginfo ought to go into linux/signal.h. Contains signal
number, si_code (usually 0), uid, pid and (often NULL) pointer to
struct sigqueue. Overall: 20 or 24 bytes. In struct coredump_params we
should replace ->siginfo with pointer to struct small_siginfo. Ditto for
task_struct ->last_siginfo. In struct ksignal ->info becomes
struct small_siginfo.
copy_siginfo_to_user{,32}() gets switched to struct small_siginfo *, so does
do_coredump(), ptrace_signal(), ptrace_stop(), ptrace_getsiginfo(),
ptrace_setsiginfo(), collect_signal(), __dequeue_signal(), dequeue_signal(),
signalfd_dequeue() and do_sigtimedwait().
New primitive: assign_sigqueue(small_info, sigqueue). Frees
small_info->q and assigns a new value to it.
When ptrace_setsiginfo() is given a non-plain siginfo (si_code != SI_USER,
that is), it should a allocate struct sigqueue, copy the sucker there and
give it to assign_sigqueue(). Plain ones just get uid/pid/signo copied
and NULL passed to assign_sigqueue().
code in ptrace_signal() under if (signr != info->si_signo) should
start with assign_sigqueue(info, NULL).
specific_send_sig_info() in ptrace_signal() is rather clumsy to handle; not
sure what's the best way to deal with that. In any case, ptrace_signal()
deciding to return 0 should take care of info->q - either copy and free the
original, or actually try to reuse the sucker. Either way, info->q should
become NULL.
get_signal_to_deliver() should do assign_sigqueue(info, NULL) before
the call of do_group_exit().
arch_ptrace_stop_needed() can be left as-is; it's a macro and none of the
instances look at the info argument at all. The same goes for
arch_ptrace_stop().
signalfd_read() should do assign_sigqueue(&info, NULL) right after
signalfd_copyinfo().
rt_sigtimedwait(2) and its compat variant should do the same right after
copy_siginfo_to_user{,32}().
TP'ed stuff is a mess, as usual. AFAICS, TP_STORE_SIGINFO() needs to
be split into a variant taking siginfo (on trace_signal_generate side)
and one taking small_siginfo (for trace_signal_deliver).
get_signal() should do assign_sigqueue(&ksig->info, NULL) if it returns
false and use task_work_add() to schedule info->q for freeing otherwise.
Overall, aside of the need to complete arch/* conversion, the only unfinished
part is this:
/* If the (new) signal is now blocked, requeue it. */
if (sigismember(¤t->blocked, signr)) {
specific_send_sig_info(signr, info, current);
signr = 0;
}
in the end of ptrace_signal(). Sure, we can add a local struct siginfo
in that if, fill it if needed and pass its address or &info->q->info
to specific_send_sig_info(), but that feels kludgy... Hell knows, I'll
look a bit more into that.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-13 20:51 ` Al Viro
@ 2014-02-14 0:09 ` Al Viro
-1 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-14 0:09 UTC (permalink / raw)
To: Linus Torvalds
Cc: Oleg Nesterov, Dave Chinner, Dave Jones, Eric Sandeen, Linux Kernel, xfs
On Thu, Feb 13, 2014 at 08:51:46PM +0000, Al Viro wrote:
> On Wed, Feb 12, 2014 at 09:44:11PM +0000, Al Viro wrote:
>
> > I'll try to put something along those lines together, if you or Oleg don't
> > do it first.
>
> OK, having looked at that stuff...
>
> 1) things become much more compact if we finish conversion to get_signal()
> first. Callers of get_signal_to_deliver() have k_sigaction and siginfo in
> pair of local variables; switching to ksignal will be neutral wrt stack
> footprint (it just gathers those two in one struct) *and* we are getting
> rid of passing struct siginfo * around. With that done, we can change
> struct ksignal ->info with zero impact on the code in arch/*, and conversion
> makes sense on its own. In the mainline we have it done for alpha, arm,
> openrisc, sparc and x86. I've just put together preliminary (and completely
> untested) patches for arm64, m68k and um; doing the rest won't take long, but
> they'll obviously need to be tested. It's a fairly safe conversion;
> I'd expect the worst bugs to be typos.
OK, there's a couple of tricks that allow to reorder that. First of all,
temporary config symbol (ARCH_USES_KSIGNAL) selecting that stuff; if it's
not selected, we just have #define small_siginfo siginfo and
#define assign_sigqueue(info, q) WARN_ON((q) != NULL)
and that's it - most of the changes in core kernel consist of s/siginfo/small_&/
and non-trivial ones are under ifdef CONFIG_ARCH_USES_KSIGNAL for the time
being. Small ifdefs, at that...
Once all architectures get converted, we'll just kill that config symbol and
make ifdefs unconditional.
Another is that we don't need to bother with task_work_add() at all; on
converted architectures we have signal_setup_done(..., ksig, ...) called after
each successful get_signal() (the first argument of signal_setup_done() is
"has sigframe setup failed" flag; we get there regardless of success or
failure of setup_...frame()). So we can just have that sucker do
assign_sigqueue(&ksig->info, NULL) and be done with that - all this delayed
freeing is explicit now (and we don't get locking overhead, etc. of
task_work_add()).
If what I've got survives the local beating, I'll put it into signal.git,
throw the arch conversions I could test in there and ask on linux-arch for
help with the missing ones. With any luck we'll get the full set by the
next merge window, at which point we'll be able to kill ifdefs.
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-14 0:09 ` Al Viro
0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-14 0:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Eric Sandeen, Oleg Nesterov, xfs, Dave Jones, Linux Kernel
On Thu, Feb 13, 2014 at 08:51:46PM +0000, Al Viro wrote:
> On Wed, Feb 12, 2014 at 09:44:11PM +0000, Al Viro wrote:
>
> > I'll try to put something along those lines together, if you or Oleg don't
> > do it first.
>
> OK, having looked at that stuff...
>
> 1) things become much more compact if we finish conversion to get_signal()
> first. Callers of get_signal_to_deliver() have k_sigaction and siginfo in
> pair of local variables; switching to ksignal will be neutral wrt stack
> footprint (it just gathers those two in one struct) *and* we are getting
> rid of passing struct siginfo * around. With that done, we can change
> struct ksignal ->info with zero impact on the code in arch/*, and conversion
> makes sense on its own. In the mainline we have it done for alpha, arm,
> openrisc, sparc and x86. I've just put together preliminary (and completely
> untested) patches for arm64, m68k and um; doing the rest won't take long, but
> they'll obviously need to be tested. It's a fairly safe conversion;
> I'd expect the worst bugs to be typos.
OK, there's a couple of tricks that allow to reorder that. First of all,
temporary config symbol (ARCH_USES_KSIGNAL) selecting that stuff; if it's
not selected, we just have #define small_siginfo siginfo and
#define assign_sigqueue(info, q) WARN_ON((q) != NULL)
and that's it - most of the changes in core kernel consist of s/siginfo/small_&/
and non-trivial ones are under ifdef CONFIG_ARCH_USES_KSIGNAL for the time
being. Small ifdefs, at that...
Once all architectures get converted, we'll just kill that config symbol and
make ifdefs unconditional.
Another is that we don't need to bother with task_work_add() at all; on
converted architectures we have signal_setup_done(..., ksig, ...) called after
each successful get_signal() (the first argument of signal_setup_done() is
"has sigframe setup failed" flag; we get there regardless of success or
failure of setup_...frame()). So we can just have that sucker do
assign_sigqueue(&ksig->info, NULL) and be done with that - all this delayed
freeing is explicit now (and we don't get locking overhead, etc. of
task_work_add()).
If what I've got survives the local beating, I'll put it into signal.git,
throw the arch conversions I could test in there and ask on linux-arch for
help with the missing ones. With any luck we'll get the full set by the
next merge window, at which point we'll be able to kill ifdefs.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 7:18 ` Dave Chinner
@ 2014-02-14 0:24 ` Dave Chinner
-1 siblings, 0 replies; 132+ messages in thread
From: Dave Chinner @ 2014-02-14 0:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Al Viro, Dave Jones, Eric Sandeen, Linux Kernel, xfs
On Wed, Feb 12, 2014 at 06:18:29PM +1100, Dave Chinner wrote:
> > It looks like just "do_signal()" has a stack frame that is about 230
> > bytes even under normal circumstancs (largely due to "struct ksignal"
> > - which in turn is largely due to the insane 128-byte padding in
> > siginfo_t). Add a few other frames in there, and I guess that if it
> > was close before, the coredump path just makes it go off.
>
> Yup. But it's when you see this sort of thing you realise that
> almost no GFP_KERNEL memory allocation is really safe from stack
> overruns, though:
>
> 0) 6064 64 update_group_power+0x2c/0x270
> 1) 6000 384 find_busiest_group+0x10a/0x8b0
> 2) 5616 288 load_balance+0x165/0x870
> 3) 5328 96 idle_balance+0x106/0x1b0
> 4) 5232 112 __schedule+0x7b6/0x7e0
> 5) 5120 16 schedule+0x29/0x70
> 6) 5104 176 percpu_ida_alloc+0x1b3/0x3d0
> 7) 4928 32 blk_mq_wait_for_tags+0x1f/0x40
> 8) 4896 80 blk_mq_alloc_request_pinned+0x4e/0x110
> 9) 4816 128 blk_mq_make_request+0x42b/0x510
> 10) 4688 48 generic_make_request+0xc0/0x110
> 11) 4640 96 submit_bio+0x71/0x120
> 12) 4544 192 _xfs_buf_ioapply+0x2cc/0x3b0
> 13) 4352 48 xfs_buf_iorequest+0x6f/0xc0
> 14) 4304 32 xlog_bdstrat+0x23/0x60
> 15) 4272 96 xlog_sync+0x3a4/0x5c0
> 16) 4176 48 xlog_state_release_iclog+0x121/0x130
> 17) 4128 192 xlog_write+0x700/0x7c0
> 18) 3936 192 xlog_cil_push+0x2ae/0x3d0
> 19) 3744 128 xlog_cil_force_lsn+0x1b8/0x1e0
> 20) 3616 144 _xfs_log_force_lsn+0x7c/0x300
> 21) 3472 48 xfs_log_force_lsn+0x3b/0xa0
> 22) 3424 112 xfs_iunpin_wait+0xd7/0x160
> 23) 3312 80 xfs_reclaim_inode+0xd0/0x350
> 24) 3232 432 xfs_reclaim_inodes_ag+0x277/0x3d0
> 25) 2800 48 xfs_reclaim_inodes_nr+0x33/0x40
> 26) 2752 16 xfs_fs_free_cached_objects+0x15/0x20
> 27) 2736 80 super_cache_scan+0x169/0x170
> 28) 2656 160 shrink_slab_node+0x133/0x290
> 29) 2496 80 shrink_slab+0x122/0x160
> 30) 2416 112 do_try_to_free_pages+0x1de/0x360
> 31) 2304 192 try_to_free_pages+0x110/0x190
> 32) 2112 256 __alloc_pages_nodemask+0x5a2/0x8e0
> 33) 1856 80 alloc_pages_current+0xb2/0x170
> 34) 1776 64 new_slab+0x265/0x2e0
> 35) 1712 240 __slab_alloc+0x2fb/0x4c4
> 36) 1472 80 kmem_cache_alloc+0x10b/0x140
>
> That's almost 4700 bytes of stack usage from the
> kmem_cache_alloc(GFP_KERNEL) call because it entered the IO path.
> Yes, it's an extreme case, but if you're looking for a smoking
> gun.... :/
>
> I can fix this one easily - we already have a workqueue for doing
> async log pushes (will split the stack between xlog_cil_force_lsn
> and xlog_cil_push), but the reason we haven't used it for synchronous
> log forces is that screws up fsync performance on CFQ. We don't
> recommend CFQ with XFS anyway, so I think I'll make this change
> anyway.
Dave, the patch below should chop off the stack usage from
xfs_log_force_lsn() issuing IO by deferring it to the CIL workqueue.
Can you given this a run?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
xfs: always do log forces via the workqueue
From: Dave Chinner <dchinner@redhat.com>
Log forces can occur deep in the call chain when we have relatively
little stack free. Log forces can also happen at close to the call
chain leaves (e.g. xfs_buf_lock()) and hence we can trigger IO from
places where we really don't want to add more stack overhead.
This stack overhead occurs because log forces do foreground CIL
pushes (xlog_cil_push_foreground()) rather than waking the
background push wq and waiting for the for the push to complete.
This foreground push was done to avoid confusing the CFQ Io
scheduler when fsync()s were issued, as it has trouble dealing with
dependent IOs being issued from different process contexts.
Avoiding blowing the stack is much more critical than performance
optimisations for CFQ, especially as we've been recommending against
the use of CFQ for XFS since 3.2 kernels were release because of
it's problems with multi-threaded IO workloads.
Hence convert xlog_cil_push_foreground() to move the push work
to the CIL workqueue. We already do the waiting for the push to
complete in xlog_cil_force_lsn(), so there's nothing else we need to
modify to make this work.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
---
fs/xfs/xfs_log_cil.c | 52 +++++++++++++++++++++++++++++++++++++++-------------
1 file changed, 39 insertions(+), 13 deletions(-)
diff --git a/fs/xfs/xfs_log_cil.c b/fs/xfs/xfs_log_cil.c
index b57a8e0..7e54553 100644
--- a/fs/xfs/xfs_log_cil.c
+++ b/fs/xfs/xfs_log_cil.c
@@ -499,13 +499,6 @@ xlog_cil_push(
cil->xc_ctx = new_ctx;
/*
- * mirror the new sequence into the cil structure so that we can do
- * unlocked checks against the current sequence in log forces without
- * risking deferencing a freed context pointer.
- */
- cil->xc_current_sequence = new_ctx->sequence;
-
- /*
* The switch is now done, so we can drop the context lock and move out
* of a shared context. We can't just go straight to the commit record,
* though - we need to synchronise with previous and future commits so
@@ -523,8 +516,15 @@ xlog_cil_push(
* Hence we need to add this context to the committing context list so
* that higher sequences will wait for us to write out a commit record
* before they do.
+ *
+ * xfs_log_force_lsn requires us to mirror the new sequence into the cil
+ * structure atomically with the addition of this sequence to the
+ * committing list. This also ensures that we can do unlocked checks
+ * against the current sequence in log forces without risking
+ * deferencing a freed context pointer.
*/
spin_lock(&cil->xc_push_lock);
+ cil->xc_current_sequence = new_ctx->sequence;
list_add(&ctx->committing, &cil->xc_committing);
spin_unlock(&cil->xc_push_lock);
up_write(&cil->xc_ctx_lock);
@@ -662,8 +662,14 @@ xlog_cil_push_background(
}
+/*
+ * xlog_cil_push_now() is used to trigger an immediate CIL push to the sequence
+ * number that is passed. When it returns, the work will be queued for
+ * @push_seq, but it won't be completed. The caller is expected to do any
+ * waiting for push_seq to complete if it is required.
+ */
static void
-xlog_cil_push_foreground(
+xlog_cil_push_now(
struct xlog *log,
xfs_lsn_t push_seq)
{
@@ -688,10 +694,8 @@ xlog_cil_push_foreground(
}
cil->xc_push_seq = push_seq;
+ queue_work(log->l_mp->m_cil_workqueue, &cil->xc_push_work);
spin_unlock(&cil->xc_push_lock);
-
- /* do the push now */
- xlog_cil_push(log);
}
bool
@@ -795,7 +799,8 @@ xlog_cil_force_lsn(
* xlog_cil_push() handles racing pushes for the same sequence,
* so no need to deal with it here.
*/
- xlog_cil_push_foreground(log, sequence);
+restart:
+ xlog_cil_push_now(log, sequence);
/*
* See if we can find a previous sequence still committing.
@@ -803,7 +808,6 @@ xlog_cil_force_lsn(
* before allowing the force of push_seq to go ahead. Hence block
* on commits for those as well.
*/
-restart:
spin_lock(&cil->xc_push_lock);
list_for_each_entry(ctx, &cil->xc_committing, committing) {
if (ctx->sequence > sequence)
@@ -821,6 +825,28 @@ restart:
/* found it! */
commit_lsn = ctx->commit_lsn;
}
+
+ /*
+ * The call to xlog_cil_push_now() executes the push in the background.
+ * Hence by the time we have got here it our sequence may not have been
+ * pushed yet. This is true if the current sequence still matches the
+ * push sequence after the above wait loop and the CIL still contains
+ * dirty objects.
+ *
+ * When the push occurs, it will empty the CIL and
+ * atomically increment the currect sequence past the push sequence and
+ * move it into the committing list. Of course, if the CIL is clean at
+ * the time of the push, it won't have pushed the CIL at all, so in that
+ * case we should try the push for this sequence again from the start
+ * just in case.
+ */
+
+ if (sequence == cil->xc_current_sequence &&
+ !list_empty(&cil->xc_cil)) {
+ spin_unlock(&cil->xc_push_lock);
+ goto restart;
+ }
+
spin_unlock(&cil->xc_push_lock);
return commit_lsn;
}
^ permalink raw reply related [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-14 0:24 ` Dave Chinner
0 siblings, 0 replies; 132+ messages in thread
From: Dave Chinner @ 2014-02-14 0:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dave Jones, xfs, Eric Sandeen, Al Viro, Linux Kernel
On Wed, Feb 12, 2014 at 06:18:29PM +1100, Dave Chinner wrote:
> > It looks like just "do_signal()" has a stack frame that is about 230
> > bytes even under normal circumstancs (largely due to "struct ksignal"
> > - which in turn is largely due to the insane 128-byte padding in
> > siginfo_t). Add a few other frames in there, and I guess that if it
> > was close before, the coredump path just makes it go off.
>
> Yup. But it's when you see this sort of thing you realise that
> almost no GFP_KERNEL memory allocation is really safe from stack
> overruns, though:
>
> 0) 6064 64 update_group_power+0x2c/0x270
> 1) 6000 384 find_busiest_group+0x10a/0x8b0
> 2) 5616 288 load_balance+0x165/0x870
> 3) 5328 96 idle_balance+0x106/0x1b0
> 4) 5232 112 __schedule+0x7b6/0x7e0
> 5) 5120 16 schedule+0x29/0x70
> 6) 5104 176 percpu_ida_alloc+0x1b3/0x3d0
> 7) 4928 32 blk_mq_wait_for_tags+0x1f/0x40
> 8) 4896 80 blk_mq_alloc_request_pinned+0x4e/0x110
> 9) 4816 128 blk_mq_make_request+0x42b/0x510
> 10) 4688 48 generic_make_request+0xc0/0x110
> 11) 4640 96 submit_bio+0x71/0x120
> 12) 4544 192 _xfs_buf_ioapply+0x2cc/0x3b0
> 13) 4352 48 xfs_buf_iorequest+0x6f/0xc0
> 14) 4304 32 xlog_bdstrat+0x23/0x60
> 15) 4272 96 xlog_sync+0x3a4/0x5c0
> 16) 4176 48 xlog_state_release_iclog+0x121/0x130
> 17) 4128 192 xlog_write+0x700/0x7c0
> 18) 3936 192 xlog_cil_push+0x2ae/0x3d0
> 19) 3744 128 xlog_cil_force_lsn+0x1b8/0x1e0
> 20) 3616 144 _xfs_log_force_lsn+0x7c/0x300
> 21) 3472 48 xfs_log_force_lsn+0x3b/0xa0
> 22) 3424 112 xfs_iunpin_wait+0xd7/0x160
> 23) 3312 80 xfs_reclaim_inode+0xd0/0x350
> 24) 3232 432 xfs_reclaim_inodes_ag+0x277/0x3d0
> 25) 2800 48 xfs_reclaim_inodes_nr+0x33/0x40
> 26) 2752 16 xfs_fs_free_cached_objects+0x15/0x20
> 27) 2736 80 super_cache_scan+0x169/0x170
> 28) 2656 160 shrink_slab_node+0x133/0x290
> 29) 2496 80 shrink_slab+0x122/0x160
> 30) 2416 112 do_try_to_free_pages+0x1de/0x360
> 31) 2304 192 try_to_free_pages+0x110/0x190
> 32) 2112 256 __alloc_pages_nodemask+0x5a2/0x8e0
> 33) 1856 80 alloc_pages_current+0xb2/0x170
> 34) 1776 64 new_slab+0x265/0x2e0
> 35) 1712 240 __slab_alloc+0x2fb/0x4c4
> 36) 1472 80 kmem_cache_alloc+0x10b/0x140
>
> That's almost 4700 bytes of stack usage from the
> kmem_cache_alloc(GFP_KERNEL) call because it entered the IO path.
> Yes, it's an extreme case, but if you're looking for a smoking
> gun.... :/
>
> I can fix this one easily - we already have a workqueue for doing
> async log pushes (will split the stack between xlog_cil_force_lsn
> and xlog_cil_push), but the reason we haven't used it for synchronous
> log forces is that screws up fsync performance on CFQ. We don't
> recommend CFQ with XFS anyway, so I think I'll make this change
> anyway.
Dave, the patch below should chop off the stack usage from
xfs_log_force_lsn() issuing IO by deferring it to the CIL workqueue.
Can you given this a run?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
xfs: always do log forces via the workqueue
From: Dave Chinner <dchinner@redhat.com>
Log forces can occur deep in the call chain when we have relatively
little stack free. Log forces can also happen at close to the call
chain leaves (e.g. xfs_buf_lock()) and hence we can trigger IO from
places where we really don't want to add more stack overhead.
This stack overhead occurs because log forces do foreground CIL
pushes (xlog_cil_push_foreground()) rather than waking the
background push wq and waiting for the for the push to complete.
This foreground push was done to avoid confusing the CFQ Io
scheduler when fsync()s were issued, as it has trouble dealing with
dependent IOs being issued from different process contexts.
Avoiding blowing the stack is much more critical than performance
optimisations for CFQ, especially as we've been recommending against
the use of CFQ for XFS since 3.2 kernels were release because of
it's problems with multi-threaded IO workloads.
Hence convert xlog_cil_push_foreground() to move the push work
to the CIL workqueue. We already do the waiting for the push to
complete in xlog_cil_force_lsn(), so there's nothing else we need to
modify to make this work.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
---
fs/xfs/xfs_log_cil.c | 52 +++++++++++++++++++++++++++++++++++++++-------------
1 file changed, 39 insertions(+), 13 deletions(-)
diff --git a/fs/xfs/xfs_log_cil.c b/fs/xfs/xfs_log_cil.c
index b57a8e0..7e54553 100644
--- a/fs/xfs/xfs_log_cil.c
+++ b/fs/xfs/xfs_log_cil.c
@@ -499,13 +499,6 @@ xlog_cil_push(
cil->xc_ctx = new_ctx;
/*
- * mirror the new sequence into the cil structure so that we can do
- * unlocked checks against the current sequence in log forces without
- * risking deferencing a freed context pointer.
- */
- cil->xc_current_sequence = new_ctx->sequence;
-
- /*
* The switch is now done, so we can drop the context lock and move out
* of a shared context. We can't just go straight to the commit record,
* though - we need to synchronise with previous and future commits so
@@ -523,8 +516,15 @@ xlog_cil_push(
* Hence we need to add this context to the committing context list so
* that higher sequences will wait for us to write out a commit record
* before they do.
+ *
+ * xfs_log_force_lsn requires us to mirror the new sequence into the cil
+ * structure atomically with the addition of this sequence to the
+ * committing list. This also ensures that we can do unlocked checks
+ * against the current sequence in log forces without risking
+ * deferencing a freed context pointer.
*/
spin_lock(&cil->xc_push_lock);
+ cil->xc_current_sequence = new_ctx->sequence;
list_add(&ctx->committing, &cil->xc_committing);
spin_unlock(&cil->xc_push_lock);
up_write(&cil->xc_ctx_lock);
@@ -662,8 +662,14 @@ xlog_cil_push_background(
}
+/*
+ * xlog_cil_push_now() is used to trigger an immediate CIL push to the sequence
+ * number that is passed. When it returns, the work will be queued for
+ * @push_seq, but it won't be completed. The caller is expected to do any
+ * waiting for push_seq to complete if it is required.
+ */
static void
-xlog_cil_push_foreground(
+xlog_cil_push_now(
struct xlog *log,
xfs_lsn_t push_seq)
{
@@ -688,10 +694,8 @@ xlog_cil_push_foreground(
}
cil->xc_push_seq = push_seq;
+ queue_work(log->l_mp->m_cil_workqueue, &cil->xc_push_work);
spin_unlock(&cil->xc_push_lock);
-
- /* do the push now */
- xlog_cil_push(log);
}
bool
@@ -795,7 +799,8 @@ xlog_cil_force_lsn(
* xlog_cil_push() handles racing pushes for the same sequence,
* so no need to deal with it here.
*/
- xlog_cil_push_foreground(log, sequence);
+restart:
+ xlog_cil_push_now(log, sequence);
/*
* See if we can find a previous sequence still committing.
@@ -803,7 +808,6 @@ xlog_cil_force_lsn(
* before allowing the force of push_seq to go ahead. Hence block
* on commits for those as well.
*/
-restart:
spin_lock(&cil->xc_push_lock);
list_for_each_entry(ctx, &cil->xc_committing, committing) {
if (ctx->sequence > sequence)
@@ -821,6 +825,28 @@ restart:
/* found it! */
commit_lsn = ctx->commit_lsn;
}
+
+ /*
+ * The call to xlog_cil_push_now() executes the push in the background.
+ * Hence by the time we have got here it our sequence may not have been
+ * pushed yet. This is true if the current sequence still matches the
+ * push sequence after the above wait loop and the CIL still contains
+ * dirty objects.
+ *
+ * When the push occurs, it will empty the CIL and
+ * atomically increment the currect sequence past the push sequence and
+ * move it into the committing list. Of course, if the CIL is clean at
+ * the time of the push, it won't have pushed the CIL at all, so in that
+ * case we should try the push for this sequence again from the start
+ * just in case.
+ */
+
+ if (sequence == cil->xc_current_sequence &&
+ !list_empty(&cil->xc_cil)) {
+ spin_unlock(&cil->xc_push_lock);
+ goto restart;
+ }
+
spin_unlock(&cil->xc_push_lock);
return commit_lsn;
}
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply related [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-13 20:51 ` Al Viro
@ 2014-02-14 13:25 ` Christoph Hellwig
-1 siblings, 0 replies; 132+ messages in thread
From: Christoph Hellwig @ 2014-02-14 13:25 UTC (permalink / raw)
To: Al Viro
Cc: Linus Torvalds, Oleg Nesterov, Dave Chinner, Dave Jones,
Eric Sandeen, Linux Kernel, xfs, Richard Weinberger
On Thu, Feb 13, 2014 at 08:51:46PM +0000, Al Viro wrote:
> On Wed, Feb 12, 2014 at 09:44:11PM +0000, Al Viro wrote:
>
> > I'll try to put something along those lines together, if you or Oleg don't
> > do it first.
>
> OK, having looked at that stuff...
>
> 1) things become much more compact if we finish conversion to get_signal()
> first.
I have vague memories that Richard sent out a series to convert over all
architectures a while ago. Hopefully he has better memory than I do.
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-14 13:25 ` Christoph Hellwig
0 siblings, 0 replies; 132+ messages in thread
From: Christoph Hellwig @ 2014-02-14 13:25 UTC (permalink / raw)
To: Al Viro
Cc: Eric Sandeen, Oleg Nesterov, Linux Kernel, Richard Weinberger,
Dave Jones, xfs, Linus Torvalds
On Thu, Feb 13, 2014 at 08:51:46PM +0000, Al Viro wrote:
> On Wed, Feb 12, 2014 at 09:44:11PM +0000, Al Viro wrote:
>
> > I'll try to put something along those lines together, if you or Oleg don't
> > do it first.
>
> OK, having looked at that stuff...
>
> 1) things become much more compact if we finish conversion to get_signal()
> first.
I have vague memories that Richard sent out a series to convert over all
architectures a while ago. Hopefully he has better memory than I do.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-14 13:25 ` Christoph Hellwig
@ 2014-02-14 13:29 ` Richard Weinberger
-1 siblings, 0 replies; 132+ messages in thread
From: Richard Weinberger @ 2014-02-14 13:29 UTC (permalink / raw)
To: Christoph Hellwig, Al Viro
Cc: Linus Torvalds, Oleg Nesterov, Dave Chinner, Dave Jones,
Eric Sandeen, Linux Kernel, xfs
Am 14.02.2014 14:25, schrieb Christoph Hellwig:
> On Thu, Feb 13, 2014 at 08:51:46PM +0000, Al Viro wrote:
>> On Wed, Feb 12, 2014 at 09:44:11PM +0000, Al Viro wrote:
>>
>>> I'll try to put something along those lines together, if you or Oleg don't
>>> do it first.
>>
>> OK, having looked at that stuff...
>>
>> 1) things become much more compact if we finish conversion to get_signal()
>> first.
>
> I have vague memories that Richard sent out a series to convert over all
> architectures a while ago. Hopefully he has better memory than I do.
Yeah. Sending v2 of that series is on my overflowing TODO list. :-\
I think this is a good reason for me to start working on that series again.
Stay tuned.
Thanks,
//richard
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-14 13:29 ` Richard Weinberger
0 siblings, 0 replies; 132+ messages in thread
From: Richard Weinberger @ 2014-02-14 13:29 UTC (permalink / raw)
To: Christoph Hellwig, Al Viro
Cc: Eric Sandeen, Oleg Nesterov, Linux Kernel, Dave Jones, xfs,
Linus Torvalds
Am 14.02.2014 14:25, schrieb Christoph Hellwig:
> On Thu, Feb 13, 2014 at 08:51:46PM +0000, Al Viro wrote:
>> On Wed, Feb 12, 2014 at 09:44:11PM +0000, Al Viro wrote:
>>
>>> I'll try to put something along those lines together, if you or Oleg don't
>>> do it first.
>>
>> OK, having looked at that stuff...
>>
>> 1) things become much more compact if we finish conversion to get_signal()
>> first.
>
> I have vague memories that Richard sent out a series to convert over all
> architectures a while ago. Hopefully he has better memory than I do.
Yeah. Sending v2 of that series is on my overflowing TODO list. :-\
I think this is a good reason for me to start working on that series again.
Stay tuned.
Thanks,
//richard
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-14 13:29 ` Richard Weinberger
@ 2014-02-14 15:20 ` Al Viro
-1 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-14 15:20 UTC (permalink / raw)
To: Richard Weinberger
Cc: Christoph Hellwig, Linus Torvalds, Oleg Nesterov, Dave Chinner,
Dave Jones, Eric Sandeen, Linux Kernel, xfs
On Fri, Feb 14, 2014 at 02:29:30PM +0100, Richard Weinberger wrote:
> Am 14.02.2014 14:25, schrieb Christoph Hellwig:
> > On Thu, Feb 13, 2014 at 08:51:46PM +0000, Al Viro wrote:
> >> On Wed, Feb 12, 2014 at 09:44:11PM +0000, Al Viro wrote:
> >>
> >>> I'll try to put something along those lines together, if you or Oleg don't
> >>> do it first.
> >>
> >> OK, having looked at that stuff...
> >>
> >> 1) things become much more compact if we finish conversion to get_signal()
> >> first.
> >
> > I have vague memories that Richard sent out a series to convert over all
> > architectures a while ago. Hopefully he has better memory than I do.
>
> Yeah. Sending v2 of that series is on my overflowing TODO list. :-\
> I think this is a good reason for me to start working on that series again.
> Stay tuned.
Would be great. I have several done here, but I'll be glad to replace them
with something tested...
BTW, Oleg, could you explain why does PTRACE_PEEK_SIGINFO copy ->si_code
separately? IOW, why do we want the upper 16 bits of ->si_code exposed?
It used to be a strictly internal thing IIRC (it's been what, 2.3.late?)
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-14 15:20 ` Al Viro
0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-14 15:20 UTC (permalink / raw)
To: Richard Weinberger
Cc: Eric Sandeen, Oleg Nesterov, Linux Kernel, Christoph Hellwig,
Dave Jones, xfs, Linus Torvalds
On Fri, Feb 14, 2014 at 02:29:30PM +0100, Richard Weinberger wrote:
> Am 14.02.2014 14:25, schrieb Christoph Hellwig:
> > On Thu, Feb 13, 2014 at 08:51:46PM +0000, Al Viro wrote:
> >> On Wed, Feb 12, 2014 at 09:44:11PM +0000, Al Viro wrote:
> >>
> >>> I'll try to put something along those lines together, if you or Oleg don't
> >>> do it first.
> >>
> >> OK, having looked at that stuff...
> >>
> >> 1) things become much more compact if we finish conversion to get_signal()
> >> first.
> >
> > I have vague memories that Richard sent out a series to convert over all
> > architectures a while ago. Hopefully he has better memory than I do.
>
> Yeah. Sending v2 of that series is on my overflowing TODO list. :-\
> I think this is a good reason for me to start working on that series again.
> Stay tuned.
Would be great. I have several done here, but I'll be glad to replace them
with something tested...
BTW, Oleg, could you explain why does PTRACE_PEEK_SIGINFO copy ->si_code
separately? IOW, why do we want the upper 16 bits of ->si_code exposed?
It used to be a strictly internal thing IIRC (it's been what, 2.3.late?)
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-14 0:24 ` Dave Chinner
@ 2014-02-14 16:01 ` Dave Jones
-1 siblings, 0 replies; 132+ messages in thread
From: Dave Jones @ 2014-02-14 16:01 UTC (permalink / raw)
To: Dave Chinner; +Cc: Linus Torvalds, Al Viro, Eric Sandeen, Linux Kernel, xfs
On Fri, Feb 14, 2014 at 11:24:27AM +1100, Dave Chinner wrote:
> > I can fix this one easily - we already have a workqueue for doing
> > async log pushes (will split the stack between xlog_cil_force_lsn
> > and xlog_cil_push), but the reason we haven't used it for synchronous
> > log forces is that screws up fsync performance on CFQ. We don't
> > recommend CFQ with XFS anyway, so I think I'll make this change
> > anyway.
>
> Dave, the patch below should chop off the stack usage from
> xfs_log_force_lsn() issuing IO by deferring it to the CIL workqueue.
> Can you given this a run?
Looks like it's survived an overnight run..
Dave
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-14 16:01 ` Dave Jones
0 siblings, 0 replies; 132+ messages in thread
From: Dave Jones @ 2014-02-14 16:01 UTC (permalink / raw)
To: Dave Chinner; +Cc: Eric Sandeen, xfs, Linus Torvalds, Al Viro, Linux Kernel
On Fri, Feb 14, 2014 at 11:24:27AM +1100, Dave Chinner wrote:
> > I can fix this one easily - we already have a workqueue for doing
> > async log pushes (will split the stack between xlog_cil_force_lsn
> > and xlog_cil_push), but the reason we haven't used it for synchronous
> > log forces is that screws up fsync performance on CFQ. We don't
> > recommend CFQ with XFS anyway, so I think I'll make this change
> > anyway.
>
> Dave, the patch below should chop off the stack usage from
> xfs_log_force_lsn() issuing IO by deferring it to the CIL workqueue.
> Can you given this a run?
Looks like it's survived an overnight run..
Dave
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-14 15:20 ` Al Viro
@ 2014-02-14 16:08 ` Oleg Nesterov
-1 siblings, 0 replies; 132+ messages in thread
From: Oleg Nesterov @ 2014-02-14 16:08 UTC (permalink / raw)
To: Al Viro, Andrey Vagin
Cc: Richard Weinberger, Christoph Hellwig, Linus Torvalds,
Dave Chinner, Dave Jones, Eric Sandeen, Linux Kernel, xfs
On 02/14, Al Viro wrote:
>
> BTW, Oleg, could you explain why does PTRACE_PEEK_SIGINFO copy ->si_code
> separately? IOW, why do we want the upper 16 bits of ->si_code exposed?
> It used to be a strictly internal thing IIRC (it's been what, 2.3.late?)
Yes, but checkpoint/restart tools want to dump/restore the internal part
of ->si_code too.
See also the "task_pid_vnr(current) == pid" hack in do_rt_sigqueueinfo(),
this allows to queue a SI_FROMKERNEL() siginfo.
Oleg.
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-14 16:08 ` Oleg Nesterov
0 siblings, 0 replies; 132+ messages in thread
From: Oleg Nesterov @ 2014-02-14 16:08 UTC (permalink / raw)
To: Al Viro, Andrey Vagin
Cc: Eric Sandeen, Richard Weinberger, Linux Kernel, xfs,
Christoph Hellwig, Dave Jones, Linus Torvalds
On 02/14, Al Viro wrote:
>
> BTW, Oleg, could you explain why does PTRACE_PEEK_SIGINFO copy ->si_code
> separately? IOW, why do we want the upper 16 bits of ->si_code exposed?
> It used to be a strictly internal thing IIRC (it's been what, 2.3.late?)
Yes, but checkpoint/restart tools want to dump/restore the internal part
of ->si_code too.
See also the "task_pid_vnr(current) == pid" hack in do_rt_sigqueueinfo(),
this allows to queue a SI_FROMKERNEL() siginfo.
Oleg.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-12 21:32 ` Linus Torvalds
@ 2014-02-14 16:13 ` Christoph Hellwig
-1 siblings, 0 replies; 132+ messages in thread
From: Christoph Hellwig @ 2014-02-14 16:13 UTC (permalink / raw)
To: Linus Torvalds
Cc: Al Viro, Oleg Nesterov, Dave Jones, Eric Sandeen, Linux Kernel, xfs
On Wed, Feb 12, 2014 at 01:32:55PM -0800, Linus Torvalds wrote:
> We'd have to teach each user of "dequeue_signal()" to free the siginfo
> thing. Which shouldn't be too bad - I think we've collected all of
> that into generic code, and there isn't the mass or architecture code
> that knows about these things any more. But there are a few odd
> drivers etc and signalfd.
The few odd drivers are nbd, jffs2 and the usb mass storage gadget.
All of these have in common that they try to handle signals in a kernel
thread (which we don't even allow by default), and that they ignore the
siginfo. I think they could mostly be replaced by an addition to the
kthread API to allow a kthread to be killed by signals for legacy
reasons.
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-14 16:13 ` Christoph Hellwig
0 siblings, 0 replies; 132+ messages in thread
From: Christoph Hellwig @ 2014-02-14 16:13 UTC (permalink / raw)
To: Linus Torvalds
Cc: Eric Sandeen, Linux Kernel, xfs, Al Viro, Oleg Nesterov, Dave Jones
On Wed, Feb 12, 2014 at 01:32:55PM -0800, Linus Torvalds wrote:
> We'd have to teach each user of "dequeue_signal()" to free the siginfo
> thing. Which shouldn't be too bad - I think we've collected all of
> that into generic code, and there isn't the mass or architecture code
> that knows about these things any more. But there are a few odd
> drivers etc and signalfd.
The few odd drivers are nbd, jffs2 and the usb mass storage gadget.
All of these have in common that they try to handle signals in a kernel
thread (which we don't even allow by default), and that they ignore the
siginfo. I think they could mostly be replaced by an addition to the
kthread API to allow a kthread to be killed by signals for legacy
reasons.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-14 16:13 ` Christoph Hellwig
@ 2014-02-14 16:16 ` Al Viro
-1 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-14 16:16 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Linus Torvalds, Oleg Nesterov, Dave Jones, Eric Sandeen,
Linux Kernel, xfs
On Fri, Feb 14, 2014 at 08:13:02AM -0800, Christoph Hellwig wrote:
> On Wed, Feb 12, 2014 at 01:32:55PM -0800, Linus Torvalds wrote:
> > We'd have to teach each user of "dequeue_signal()" to free the siginfo
> > thing. Which shouldn't be too bad - I think we've collected all of
> > that into generic code, and there isn't the mass or architecture code
> > that knows about these things any more. But there are a few odd
> > drivers etc and signalfd.
>
> The few odd drivers are nbd, jffs2 and the usb mass storage gadget.
> All of these have in common that they try to handle signals in a kernel
> thread (which we don't even allow by default), and that they ignore the
> siginfo. I think they could mostly be replaced by an addition to the
> kthread API to allow a kthread to be killed by signals for legacy
> reasons.
FWIW, there's a funny situation - all users of dequeue_signal_lock()
actually ignore info completely. I'm not saying that we ought to
stop returning it, but e.g. jbd part of that patch is simply
diff --git a/fs/jffs2/background.c b/fs/jffs2/background.c
index 2b60ce1..aefdff2 100644
--- a/fs/jffs2/background.c
+++ b/fs/jffs2/background.c
@@ -119,13 +119,14 @@ static int jffs2_garbage_collect_thread(void *_c)
/* Put_super will send a SIGKILL and then wait on the sem.
*/
while (signal_pending(current) || freezing(current)) {
- siginfo_t info;
+ ksiginfo_t info;
unsigned long signr;
if (try_to_freeze())
goto again;
signr = dequeue_signal_lock(current, ¤t->blocked, &info);
+ dismiss_siginfo(&info);
switch(signr) {
case SIGSTOP:
Not complicated at all. Where it does get complicated is ->last_siginfo and
PTRACE_SETSIGINFO - getting that reasonably clean is what I'm still fighting
right now...
^ permalink raw reply related [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-14 16:16 ` Al Viro
0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-14 16:16 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Linux Kernel, Eric Sandeen, Oleg Nesterov, xfs, Dave Jones,
Linus Torvalds
On Fri, Feb 14, 2014 at 08:13:02AM -0800, Christoph Hellwig wrote:
> On Wed, Feb 12, 2014 at 01:32:55PM -0800, Linus Torvalds wrote:
> > We'd have to teach each user of "dequeue_signal()" to free the siginfo
> > thing. Which shouldn't be too bad - I think we've collected all of
> > that into generic code, and there isn't the mass or architecture code
> > that knows about these things any more. But there are a few odd
> > drivers etc and signalfd.
>
> The few odd drivers are nbd, jffs2 and the usb mass storage gadget.
> All of these have in common that they try to handle signals in a kernel
> thread (which we don't even allow by default), and that they ignore the
> siginfo. I think they could mostly be replaced by an addition to the
> kthread API to allow a kthread to be killed by signals for legacy
> reasons.
FWIW, there's a funny situation - all users of dequeue_signal_lock()
actually ignore info completely. I'm not saying that we ought to
stop returning it, but e.g. jbd part of that patch is simply
diff --git a/fs/jffs2/background.c b/fs/jffs2/background.c
index 2b60ce1..aefdff2 100644
--- a/fs/jffs2/background.c
+++ b/fs/jffs2/background.c
@@ -119,13 +119,14 @@ static int jffs2_garbage_collect_thread(void *_c)
/* Put_super will send a SIGKILL and then wait on the sem.
*/
while (signal_pending(current) || freezing(current)) {
- siginfo_t info;
+ ksiginfo_t info;
unsigned long signr;
if (try_to_freeze())
goto again;
signr = dequeue_signal_lock(current, ¤t->blocked, &info);
+ dismiss_siginfo(&info);
switch(signr) {
case SIGSTOP:
Not complicated at all. Where it does get complicated is ->last_siginfo and
PTRACE_SETSIGINFO - getting that reasonably clean is what I'm still fighting
right now...
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply related [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-14 16:16 ` Al Viro
@ 2014-02-14 16:18 ` Al Viro
-1 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-14 16:18 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Linus Torvalds, Oleg Nesterov, Dave Jones, Eric Sandeen,
Linux Kernel, xfs
On Fri, Feb 14, 2014 at 04:16:24PM +0000, Al Viro wrote:
> FWIW, there's a funny situation - all users of dequeue_signal_lock()
> actually ignore info completely. I'm not saying that we ought to
> stop returning it, but e.g. jbd part of that patch is simply
s/jbd/jffs2/, obviously. Sorry... And yes, nbd and usb_storage are the
same story.
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-14 16:18 ` Al Viro
0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-14 16:18 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Linux Kernel, Eric Sandeen, Oleg Nesterov, xfs, Dave Jones,
Linus Torvalds
On Fri, Feb 14, 2014 at 04:16:24PM +0000, Al Viro wrote:
> FWIW, there's a funny situation - all users of dequeue_signal_lock()
> actually ignore info completely. I'm not saying that we ought to
> stop returning it, but e.g. jbd part of that patch is simply
s/jbd/jffs2/, obviously. Sorry... And yes, nbd and usb_storage are the
same story.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-14 16:16 ` Al Viro
@ 2014-02-14 16:19 ` Christoph Hellwig
-1 siblings, 0 replies; 132+ messages in thread
From: Christoph Hellwig @ 2014-02-14 16:19 UTC (permalink / raw)
To: Al Viro
Cc: Christoph Hellwig, Linus Torvalds, Oleg Nesterov, Dave Jones,
Eric Sandeen, Linux Kernel, xfs
On Fri, Feb 14, 2014 at 04:16:24PM +0000, Al Viro wrote:
> > All of these have in common that they try to handle signals in a kernel
> > thread (which we don't even allow by default), and that they ignore the
> > siginfo. I think they could mostly be replaced by an addition to the
> > kthread API to allow a kthread to be killed by signals for legacy
> > reasons.
>
> FWIW, there's a funny situation - all users of dequeue_signal_lock()
> actually ignore info completely. I'm not saying that we ought to
> stop returning it, but e.g. jbd part of that patch is simply
Might aswell stick the discmiss into what was dequeue_signal_lock().
Which at that point should get a saner name (maybe thread_dequeue_signal ?)
and lose all argument except maybe task_struct - not that it's
nessecary, but it would mirror the other functions usually used around
it.
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-14 16:19 ` Christoph Hellwig
0 siblings, 0 replies; 132+ messages in thread
From: Christoph Hellwig @ 2014-02-14 16:19 UTC (permalink / raw)
To: Al Viro
Cc: Eric Sandeen, Oleg Nesterov, Linux Kernel, Christoph Hellwig,
Dave Jones, xfs, Linus Torvalds
On Fri, Feb 14, 2014 at 04:16:24PM +0000, Al Viro wrote:
> > All of these have in common that they try to handle signals in a kernel
> > thread (which we don't even allow by default), and that they ignore the
> > siginfo. I think they could mostly be replaced by an addition to the
> > kthread API to allow a kthread to be killed by signals for legacy
> > reasons.
>
> FWIW, there's a funny situation - all users of dequeue_signal_lock()
> actually ignore info completely. I'm not saying that we ought to
> stop returning it, but e.g. jbd part of that patch is simply
Might aswell stick the discmiss into what was dequeue_signal_lock().
Which at that point should get a saner name (maybe thread_dequeue_signal ?)
and lose all argument except maybe task_struct - not that it's
nessecary, but it would mirror the other functions usually used around
it.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-13 17:58 ` Linus Torvalds
@ 2014-02-15 5:25 ` Al Viro
-1 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-15 5:25 UTC (permalink / raw)
To: Linus Torvalds
Cc: Oleg Nesterov, Dave Chinner, Dave Jones, Eric Sandeen, Linux Kernel, xfs
On Thu, Feb 13, 2014 at 09:58:47AM -0800, Linus Torvalds wrote:
> On Thu, Feb 13, 2014 at 9:40 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > And we should be careful with SIGQUEUE_PREALLOC, at least
> > collect_signal() should not do list_del_init()... Plus we need to
> > handle the SEND_SIG_FORCED-like case.
>
> I don't think the users need to care. They'd just call
> "sigqueue_free()" not knowing about our preallocations etc. That kind
> of detail should be confined to inside signal.c.
>
> But there really aren't that many users. There's a couple of
> "dequeue_signal_lock()" users, but they don't actually *want* the
> siginfo at all (they're kernel threads), so we can just make that
> function free the siginfo immediately (and get rid of the totally
> unnecessay kernel stack allocation). And outside of signal.c only
> signalfd uses "dequeue_signal()" itself, and that would be the only
> one that would need to be taught to use (in signalfd_copyinfo()) and
> then free the sigqueue entry.
>
> So it really looks like the right thing to do, and fairly
> straightforward. But I'm leaving the coding proof to Al, since he
> already offered ;)
OK, _very_ preliminary patch follows. It's uglier than it has to and it's
not in the form I would consider suitable for merge. It doesn't depend
on conversions of architectures to use of ksignal as prereqs; instead of
that it has config symbol (ARCH_USES_KSIGNAL) that can be selected on
architectures already through that conversion (in this patch - just on
x86, since that was all I could test on at the moment; e.g. alpha and
arm could also get such selects right now). If it isn't selected, everything
builds as usual. With large siginfo on stack for signal path, as before.
We get ksiginfo_t as an alias for siginfo_t in that case, dismiss_siginfo()
is a no-op, etc. If it _is_ selected, ksiginfo_t is much smaller than
siginfo_t.
Of course, we pay for that with ifdefs in places that need to understand
[k]siginfo_t guts; signalfd_copyinfo(), copy_siginfo_from_user{,32}() and
copy_ksiginfo_to_user{,32}(), tracepoint for deliver_signal(), collect_signal(),
trivial ones in dequeue_signal() and an ugly bugger in ptrace_signal().
No way around that until all architectures are converted. Other places
get away with some siginfo_t replaced with ksiginfo_t and dismiss_siginfo()
added in some places. arch/x86/ia32/ia32_signal.c needed a bit of change
(we probably ought to unify copy_siginfo_from_user32() on all architectures
that have it, actually).
The sucker survived LTP syscall tests and hasn't died on xfstests yet either
(== doesn't seem to leak horribly). Consider it a proof-of-concept and no
more than that. One thing I'm really not satisfied with is signal sending
pathway - it would probably make a lot of sense to use ksiginfo there as
well, and have insertion into queue simply steal info->q instead of allocating
and copying. Another is that ifdefs like that are tolerable only if we
plan to convert everything during this cycle; I believe it to be doable,
actually. Having that sucker go before the conversions would make for
simpler logistics wrt architecture trees, but it may be better to get
all conversions merged first. Not sure... Anyway, here is it; comments
are welcome.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
diff --git a/arch/Kconfig b/arch/Kconfig
index 80bbb8c..f753561 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -522,4 +522,7 @@ config OLD_SIGACTION
config COMPAT_OLD_SIGACTION
bool
+config ARCH_USES_KSIGNAL
+ bool
+
source "kernel/gcov/Kconfig"
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 0af5250..4ec468d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -127,6 +127,7 @@ config X86
select HAVE_DEBUG_STACKOVERFLOW
select HAVE_IRQ_EXIT_ON_IRQ_STACK if X86_64
select HAVE_CC_STACKPROTECTOR
+ select ARCH_USES_KSIGNAL
config INSTRUCTION_DECODER
def_bool y
diff --git a/arch/x86/ia32/ia32_signal.c b/arch/x86/ia32/ia32_signal.c
index 2206757..611a03e 100644
--- a/arch/x86/ia32/ia32_signal.c
+++ b/arch/x86/ia32/ia32_signal.c
@@ -34,7 +34,7 @@
#include <asm/sys_ia32.h>
#include <asm/smap.h>
-int copy_siginfo_to_user32(compat_siginfo_t __user *to, const siginfo_t *from)
+int __copy_siginfo_to_user32(compat_siginfo_t __user *to, const siginfo_t *from)
{
int err = 0;
bool ia32 = test_thread_flag(TIF_IA32);
@@ -105,6 +105,25 @@ int copy_siginfo_to_user32(compat_siginfo_t __user *to, const siginfo_t *from)
return err;
}
+int copy_siginfo_to_user32(compat_siginfo_t __user *to, const ksiginfo_t *from)
+{
+ int err = 0;
+ if (!from->q) {
+ if (!access_ok(VERIFY_WRITE, to, sizeof(compat_siginfo_t)))
+ return -EFAULT;
+ put_user_try {
+ /* fast case */
+ put_user_ex(from->si_signo, &to->si_signo);
+ put_user_ex(0, &to->si_errno);
+ put_user_ex((short)from->si_code, &to->si_code);
+ put_user_ex(from->si_pid, &to->si_pid);
+ put_user_ex(from->si_uid, &to->si_uid);
+ } put_user_catch(err);
+ return err;
+ }
+ return __copy_siginfo_to_user32(to, &from->q->info);
+}
+
int copy_siginfo_from_user32(siginfo_t *to, compat_siginfo_t __user *from)
{
int err = 0;
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 55298db..673ab73 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -201,10 +201,11 @@ static int sock_xmit(struct nbd_device *nbd, int send, void *buf, int size,
msg.msg_flags);
if (signal_pending(current)) {
- siginfo_t info;
+ ksiginfo_t info;
printk(KERN_WARNING "nbd (pid %d: %s) got signal %d\n",
task_pid_nr(current), current->comm,
dequeue_signal_lock(current, ¤t->blocked, &info));
+ dismiss_siginfo(&info);
result = -EINTR;
sock_shutdown(nbd, !send);
break;
diff --git a/drivers/usb/gadget/f_mass_storage.c b/drivers/usb/gadget/f_mass_storage.c
index b963939..ecacac5 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -2337,7 +2337,7 @@ static void fsg_disable(struct usb_function *f)
static void handle_exception(struct fsg_common *common)
{
- siginfo_t info;
+ ksiginfo_t info;
int i;
struct fsg_buffhd *bh;
enum fsg_state old_state;
@@ -2351,6 +2351,7 @@ static void handle_exception(struct fsg_common *common)
for (;;) {
int sig =
dequeue_signal_lock(current, ¤t->blocked, &info);
+ dismiss_siginfo(&info);
if (!sig)
break;
if (sig != SIGUSR1) {
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 67be295..e79a23e 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1371,7 +1371,7 @@ static void fill_auxv_note(struct memelfnote *note, struct mm_struct *mm)
}
static void fill_siginfo_note(struct memelfnote *note, user_siginfo_t *csigdata,
- const siginfo_t *siginfo)
+ const ksiginfo_t *siginfo)
{
mm_segment_t old_fs = get_fs();
set_fs(KERNEL_DS);
@@ -1578,7 +1578,7 @@ static int fill_thread_core_info(struct elf_thread_core_info *t,
static int fill_note_info(struct elfhdr *elf, int phdrs,
struct elf_note_info *info,
- const siginfo_t *siginfo, struct pt_regs *regs)
+ const ksiginfo_t *siginfo, struct pt_regs *regs)
{
struct task_struct *dump_task = current;
const struct user_regset_view *view = task_user_regset_view(dump_task);
@@ -1827,7 +1827,7 @@ static int elf_note_info_init(struct elf_note_info *info)
static int fill_note_info(struct elfhdr *elf, int phdrs,
struct elf_note_info *info,
- const siginfo_t *siginfo, struct pt_regs *regs)
+ const ksiginfo_t *siginfo, struct pt_regs *regs)
{
struct list_head *t;
struct core_thread *ct;
diff --git a/fs/coredump.c b/fs/coredump.c
index e3ad709..44ff98d 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -484,7 +484,7 @@ static int umh_pipe_setup(struct subprocess_info *info, struct cred *new)
return err;
}
-void do_coredump(const siginfo_t *siginfo)
+void do_coredump(const ksiginfo_t *siginfo)
{
struct core_state core_state;
struct core_name cn;
diff --git a/fs/jffs2/background.c b/fs/jffs2/background.c
index 2b60ce1..aefdff2 100644
--- a/fs/jffs2/background.c
+++ b/fs/jffs2/background.c
@@ -119,13 +119,14 @@ static int jffs2_garbage_collect_thread(void *_c)
/* Put_super will send a SIGKILL and then wait on the sem.
*/
while (signal_pending(current) || freezing(current)) {
- siginfo_t info;
+ ksiginfo_t info;
unsigned long signr;
if (try_to_freeze())
goto again;
signr = dequeue_signal_lock(current, ¤t->blocked, &info);
+ dismiss_siginfo(&info);
switch(signr) {
case SIGSTOP:
diff --git a/fs/signalfd.c b/fs/signalfd.c
index 424b7b6..d6f3c47 100644
--- a/fs/signalfd.c
+++ b/fs/signalfd.c
@@ -78,8 +78,9 @@ static unsigned int signalfd_poll(struct file *file, poll_table *wait)
* Copied from copy_siginfo_to_user() in kernel/signal.c
*/
static int signalfd_copyinfo(struct signalfd_siginfo __user *uinfo,
- siginfo_t const *kinfo)
+ const ksiginfo_t *from)
{
+ const siginfo_t *kinfo;
long err;
BUILD_BUG_ON(sizeof(struct signalfd_siginfo) != 128);
@@ -89,6 +90,19 @@ static int signalfd_copyinfo(struct signalfd_siginfo __user *uinfo,
*/
err = __clear_user(uinfo, sizeof(*uinfo));
+#ifdef CONFIG_ARCH_USES_KSIGNAL
+ if (!from->q) {
+ err |= __put_user(from->si_signo, &uinfo->ssi_signo);
+ err |= __put_user(0, &uinfo->ssi_errno);
+ err |= __put_user((short) from->si_code, &uinfo->ssi_code);
+ err |= __put_user(from->si_pid, &uinfo->ssi_pid);
+ err |= __put_user(from->si_uid, &uinfo->ssi_uid);
+ goto out;
+ }
+ kinfo = &from->q->info;
+#else
+ kinfo = from;
+#endif
/*
* If you change siginfo_t structure, please be sure
* this code is fixed accordingly.
@@ -152,10 +166,11 @@ static int signalfd_copyinfo(struct signalfd_siginfo __user *uinfo,
break;
}
+out:
return err ? -EFAULT: sizeof(*uinfo);
}
-static ssize_t signalfd_dequeue(struct signalfd_ctx *ctx, siginfo_t *info,
+static ssize_t signalfd_dequeue(struct signalfd_ctx *ctx, ksiginfo_t *info,
int nonblock)
{
ssize_t ret;
@@ -207,7 +222,7 @@ static ssize_t signalfd_read(struct file *file, char __user *buf, size_t count,
struct signalfd_siginfo __user *siginfo;
int nonblock = file->f_flags & O_NONBLOCK;
ssize_t ret, total = 0;
- siginfo_t info;
+ ksiginfo_t info;
count /= sizeof(struct signalfd_siginfo);
if (!count)
@@ -219,6 +234,7 @@ static ssize_t signalfd_read(struct file *file, char __user *buf, size_t count,
if (unlikely(ret <= 0))
break;
ret = signalfd_copyinfo(siginfo, &info);
+ dismiss_siginfo(&info);
if (ret < 0)
break;
siginfo++;
diff --git a/include/asm-generic/siginfo.h b/include/asm-generic/siginfo.h
index 3d1a3af..43a6895 100644
--- a/include/asm-generic/siginfo.h
+++ b/include/asm-generic/siginfo.h
@@ -15,6 +15,11 @@
#define __SI_CODE(T,N) ((T) | ((N) & 0xffff))
struct siginfo;
+#ifndef CONFIG_ARCH_USES_KSIGNAL
+#define small_siginfo siginfo
+#else
+struct small_siginfo;
+#endif
void do_schedule_next_timer(struct siginfo *info);
#ifndef HAVE_ARCH_COPY_SIGINFO
@@ -32,6 +37,8 @@ static inline void copy_siginfo(struct siginfo *to, struct siginfo *from)
#endif
-extern int copy_siginfo_to_user(struct siginfo __user *to, const struct siginfo *from);
+extern int copy_ksiginfo_from_user(struct small_siginfo *to, const struct siginfo __user *from);
+extern int copy_siginfo_to_user(struct siginfo __user *to, const struct small_siginfo *from);
+extern int __copy_siginfo_to_user(struct siginfo __user *to, const struct siginfo *from);
#endif
diff --git a/include/linux/binfmts.h b/include/linux/binfmts.h
index b4a745d..912d8d4 100644
--- a/include/linux/binfmts.h
+++ b/include/linux/binfmts.h
@@ -56,7 +56,7 @@ struct linux_binprm {
/* Function parameter for binfmt->coredump */
struct coredump_params {
- const siginfo_t *siginfo;
+ const ksiginfo_t *siginfo;
struct pt_regs *regs;
struct file *file;
unsigned long limit;
diff --git a/include/linux/compat.h b/include/linux/compat.h
index 3f448c6..9ab31c9 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -362,7 +362,9 @@ long compat_get_bitmap(unsigned long *mask, const compat_ulong_t __user *umask,
long compat_put_bitmap(compat_ulong_t __user *umask, unsigned long *mask,
unsigned long bitmap_size);
int copy_siginfo_from_user32(siginfo_t *to, struct compat_siginfo __user *from);
-int copy_siginfo_to_user32(struct compat_siginfo __user *to, const siginfo_t *from);
+int copy_ksiginfo_from_user32(ksiginfo_t *to, struct compat_siginfo __user *from);
+int copy_siginfo_to_user32(struct compat_siginfo __user *to, const ksiginfo_t *from);
+int __copy_siginfo_to_user32(struct compat_siginfo __user *to, const siginfo_t *from);
int get_compat_sigevent(struct sigevent *event,
const struct compat_sigevent __user *u_event);
long compat_sys_rt_tgsigqueueinfo(compat_pid_t tgid, compat_pid_t pid, int sig,
diff --git a/include/linux/coredump.h b/include/linux/coredump.h
index d016a12..3c9f79c 100644
--- a/include/linux/coredump.h
+++ b/include/linux/coredump.h
@@ -15,9 +15,9 @@ extern int dump_skip(struct coredump_params *cprm, size_t nr);
extern int dump_emit(struct coredump_params *cprm, const void *addr, int nr);
extern int dump_align(struct coredump_params *cprm, int align);
#ifdef CONFIG_COREDUMP
-extern void do_coredump(const siginfo_t *siginfo);
+extern void do_coredump(const ksiginfo_t *siginfo);
#else
-static inline void do_coredump(const siginfo_t *siginfo) {}
+static inline void do_coredump(const ksiginfo_t *siginfo) {}
#endif
#endif /* _LINUX_COREDUMP_H */
diff --git a/include/linux/sched.h b/include/linux/sched.h
index a781dec..60834bf 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1428,7 +1428,7 @@ struct task_struct {
struct io_context *io_context;
unsigned long ptrace_message;
- siginfo_t *last_siginfo; /* For ptrace use. */
+ ksiginfo_t *last_siginfo; /* For ptrace use. */
struct task_io_accounting ioac;
#if defined(CONFIG_TASK_XACCT)
u64 acct_rss_mem1; /* accumulated rss usage */
@@ -2177,9 +2177,9 @@ extern void flush_signals(struct task_struct *);
extern void __flush_signals(struct task_struct *);
extern void ignore_signals(struct task_struct *);
extern void flush_signal_handlers(struct task_struct *, int force_default);
-extern int dequeue_signal(struct task_struct *tsk, sigset_t *mask, siginfo_t *info);
+extern int dequeue_signal(struct task_struct *tsk, sigset_t *mask, ksiginfo_t *info);
-static inline int dequeue_signal_lock(struct task_struct *tsk, sigset_t *mask, siginfo_t *info)
+static inline int dequeue_signal_lock(struct task_struct *tsk, sigset_t *mask, ksiginfo_t *info)
{
unsigned long flags;
int ret;
@@ -2204,7 +2204,6 @@ extern int kill_pid_info_as_cred(int, struct siginfo *, struct pid *,
const struct cred *, u32);
extern int kill_pgrp(struct pid *pid, int sig, int priv);
extern int kill_pid(struct pid *pid, int sig, int priv);
-extern int kill_proc_info(int, struct siginfo *, pid_t);
extern __must_check bool do_notify_parent(struct task_struct *, int);
extern void __wake_up_parent(struct task_struct *p, struct task_struct *parent);
extern void force_sig(int, struct task_struct *);
diff --git a/include/linux/signal.h b/include/linux/signal.h
index 2ac423b..c999b4a 100644
--- a/include/linux/signal.h
+++ b/include/linux/signal.h
@@ -236,12 +236,29 @@ static inline int valid_signal(unsigned long sig)
struct timespec;
struct pt_regs;
+#ifdef CONFIG_ARCH_USES_KSIGNAL
+typedef struct small_siginfo {
+ int si_signo;
+ int si_code;
+ union { struct { /* yecch... */
+ __kernel_pid_t _pid;
+ __ARCH_SI_UID_T _uid;
+ } _kill; } _sifields;
+ struct sigqueue *q;
+} ksiginfo_t;
+extern void dismiss_siginfo(ksiginfo_t *);
+#else
+#define small_siginfo siginfo
+#define ksiginfo_t siginfo_t
+#define dismiss_siginfo(info) ((void)0)
+#endif
+
extern int next_signal(struct sigpending *pending, sigset_t *mask);
extern int do_send_sig_info(int sig, struct siginfo *info,
struct task_struct *p, bool group);
extern int group_send_sig_info(int sig, struct siginfo *info, struct task_struct *p);
extern int __group_send_sig_info(int, struct siginfo *, struct task_struct *);
-extern int do_sigtimedwait(const sigset_t *, siginfo_t *,
+extern int do_sigtimedwait(const sigset_t *, ksiginfo_t *,
const struct timespec *);
extern int sigprocmask(int, sigset_t *, sigset_t *);
extern void set_current_blocked(sigset_t *);
@@ -281,13 +298,13 @@ struct old_sigaction {
struct ksignal {
struct k_sigaction ka;
- siginfo_t info;
+ ksiginfo_t info;
int sig;
};
-extern int get_signal_to_deliver(siginfo_t *info, struct k_sigaction *return_ka, struct pt_regs *regs, void *cookie);
+extern int get_signal_to_deliver(ksiginfo_t *info, struct k_sigaction *return_ka, struct pt_regs *regs, void *cookie);
extern void signal_setup_done(int failed, struct ksignal *ksig, int stepping);
-extern void signal_delivered(int sig, siginfo_t *info, struct k_sigaction *ka, struct pt_regs *regs, int stepping);
+extern void signal_delivered(int sig, ksiginfo_t *info, struct k_sigaction *ka, struct pt_regs *regs, int stepping);
extern void exit_signals(struct task_struct *tsk);
/*
diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h
index 1e98b55..c9e7a0e 100644
--- a/include/linux/tracehook.h
+++ b/include/linux/tracehook.h
@@ -146,7 +146,7 @@ static inline void tracehook_report_syscall_exit(struct pt_regs *regs, int step)
* Called without locks, shortly before returning to user mode
* (or handling more signals).
*/
-static inline void tracehook_signal_handler(int sig, siginfo_t *info,
+static inline void tracehook_signal_handler(int sig, ksiginfo_t *info,
const struct k_sigaction *ka,
struct pt_regs *regs, int stepping)
{
diff --git a/include/trace/events/signal.h b/include/trace/events/signal.h
index 39a8a43..1494a3e 100644
--- a/include/trace/events/signal.h
+++ b/include/trace/events/signal.h
@@ -23,6 +23,27 @@
} \
} while (0)
+#ifndef CONFIG_ARCH_USES_KSIGNAL
+#define TP_SI_ERRNO(info) info->si_errno
+#else
+#define TP_SI_ERRNO(info) info->q ? info->q->info.si_errno : 0
+#endif
+
+#define TP_STORE_KSIGINFO(__entry, info) \
+ do { \
+ if (info == (ksiginfo_t *)SEND_SIG_NOINFO || \
+ info == (ksiginfo_t *)SEND_SIG_FORCED) { \
+ __entry->errno = 0; \
+ __entry->code = SI_USER; \
+ } else if (info == (ksiginfo_t *)SEND_SIG_PRIV) {\
+ __entry->errno = 0; \
+ __entry->code = SI_KERNEL; \
+ } else { \
+ __entry->errno = TP_SI_ERRNO(info); \
+ __entry->code = info->si_code; \
+ } \
+ } while (0)
+
#ifndef TRACE_HEADER_MULTI_READ
enum {
TRACE_SIGNAL_DELIVERED,
@@ -95,7 +116,7 @@ TRACE_EVENT(signal_generate,
*/
TRACE_EVENT(signal_deliver,
- TP_PROTO(int sig, struct siginfo *info, struct k_sigaction *ka),
+ TP_PROTO(int sig, ksiginfo_t *info, struct k_sigaction *ka),
TP_ARGS(sig, info, ka),
@@ -109,7 +130,7 @@ TRACE_EVENT(signal_deliver,
TP_fast_assign(
__entry->sig = sig;
- TP_STORE_SIGINFO(__entry, info);
+ TP_STORE_KSIGINFO(__entry, info);
__entry->sa_handler = (unsigned long)ka->sa.sa_handler;
__entry->sa_flags = ka->sa.sa_flags;
),
diff --git a/kernel/compat.c b/kernel/compat.c
index 0a09e48..82084b4 100644
--- a/kernel/compat.c
+++ b/kernel/compat.c
@@ -579,7 +579,7 @@ COMPAT_SYSCALL_DEFINE5(waitid,
BUG_ON(info.si_code & __SI_MASK);
info.si_code |= __SI_CHLD;
- return copy_siginfo_to_user32(uinfo, &info);
+ return __copy_siginfo_to_user32(uinfo, &info);
}
static int compat_get_user_cpu_mask(compat_ulong_t __user *user_mask_ptr,
@@ -981,7 +981,7 @@ COMPAT_SYSCALL_DEFINE4(rt_sigtimedwait, compat_sigset_t __user *, uthese,
compat_sigset_t s32;
sigset_t s;
struct timespec t;
- siginfo_t info;
+ ksiginfo_t info;
long ret;
if (sigsetsize != sizeof(sigset_t))
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 1f4bcb3..11223d4 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -589,7 +589,7 @@ static int ptrace_setoptions(struct task_struct *child, unsigned long data)
return 0;
}
-static int ptrace_getsiginfo(struct task_struct *child, siginfo_t *info)
+static int ptrace_getsiginfo(struct task_struct *child, ksiginfo_t *info)
{
unsigned long flags;
int error = -ESRCH;
@@ -605,7 +605,7 @@ static int ptrace_getsiginfo(struct task_struct *child, siginfo_t *info)
return error;
}
-static int ptrace_setsiginfo(struct task_struct *child, const siginfo_t *info)
+static int ptrace_setsiginfo(struct task_struct *child, ksiginfo_t *info)
{
unsigned long flags;
int error = -ESRCH;
@@ -613,11 +613,14 @@ static int ptrace_setsiginfo(struct task_struct *child, const siginfo_t *info)
if (lock_task_sighand(child, &flags)) {
error = -EINVAL;
if (likely(child->last_siginfo != NULL)) {
+ dismiss_siginfo(child->last_siginfo);
*child->last_siginfo = *info;
error = 0;
}
unlock_task_sighand(child, &flags);
}
+ if (error)
+ dismiss_siginfo(info);
return error;
}
@@ -666,7 +669,7 @@ static int ptrace_peek_siginfo(struct task_struct *child,
if (unlikely(is_compat_task())) {
compat_siginfo_t __user *uinfo = compat_ptr(data);
- if (copy_siginfo_to_user32(uinfo, &info) ||
+ if (__copy_siginfo_to_user32(uinfo, &info) ||
__put_user(info.si_code, &uinfo->si_code)) {
ret = -EFAULT;
break;
@@ -677,7 +680,7 @@ static int ptrace_peek_siginfo(struct task_struct *child,
{
siginfo_t __user *uinfo = (siginfo_t __user *) data;
- if (copy_siginfo_to_user(uinfo, &info) ||
+ if (__copy_siginfo_to_user(uinfo, &info) ||
__put_user(info.si_code, &uinfo->si_code)) {
ret = -EFAULT;
break;
@@ -805,7 +808,7 @@ int ptrace_request(struct task_struct *child, long request,
{
bool seized = child->ptrace & PT_SEIZED;
int ret = -EIO;
- siginfo_t siginfo, *si;
+ ksiginfo_t siginfo, *si;
void __user *datavp = (void __user *) data;
unsigned long __user *datalp = datavp;
unsigned long flags;
@@ -839,9 +842,8 @@ int ptrace_request(struct task_struct *child, long request,
break;
case PTRACE_SETSIGINFO:
- if (copy_from_user(&siginfo, datavp, sizeof siginfo))
- ret = -EFAULT;
- else
+ ret = copy_ksiginfo_from_user(&siginfo, datavp);
+ if (!ret)
ret = ptrace_setsiginfo(child, &siginfo);
break;
@@ -1107,7 +1109,7 @@ int compat_ptrace_request(struct task_struct *child, compat_long_t request,
{
compat_ulong_t __user *datap = compat_ptr(data);
compat_ulong_t word;
- siginfo_t siginfo;
+ ksiginfo_t siginfo;
int ret;
switch (request) {
@@ -1139,8 +1141,7 @@ int compat_ptrace_request(struct task_struct *child, compat_long_t request,
break;
case PTRACE_SETSIGINFO:
- memset(&siginfo, 0, sizeof siginfo);
- if (copy_siginfo_from_user32(
+ if (copy_ksiginfo_from_user32(
&siginfo, (struct compat_siginfo __user *) datap))
ret = -EFAULT;
else
diff --git a/kernel/signal.c b/kernel/signal.c
index 48cf9fc..2b641aa 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -540,7 +540,18 @@ unblock_all_signals(void)
spin_unlock_irqrestore(¤t->sighand->siglock, flags);
}
-static void collect_signal(int sig, struct sigpending *list, siginfo_t *info)
+#ifdef CONFIG_ARCH_USES_KSIGNAL
+void dismiss_siginfo(ksiginfo_t *info)
+{
+ if (info->q)
+ __sigqueue_free(info->q);
+ info->q = NULL;
+}
+EXPORT_SYMBOL(dismiss_siginfo);
+#endif
+
+static void collect_signal(int sig, struct sigpending *list,
+ ksiginfo_t *info)
{
struct sigqueue *q, *first = NULL;
@@ -561,8 +572,14 @@ static void collect_signal(int sig, struct sigpending *list, siginfo_t *info)
if (first) {
still_pending:
list_del_init(&first->list);
+#ifndef CONFIG_ARCH_USES_KSIGNAL
copy_siginfo(info, &first->info);
__sigqueue_free(first);
+#else
+ info->si_signo = sig;
+ info->si_code = first->info.si_code;
+ info->q = first;
+#endif
} else {
/*
* Ok, it wasn't in the queue. This must be
@@ -570,15 +587,19 @@ still_pending:
* out of queue space. So zero out the info.
*/
info->si_signo = sig;
- info->si_errno = 0;
info->si_code = SI_USER;
info->si_pid = 0;
info->si_uid = 0;
+#ifndef CONFIG_ARCH_USES_KSIGNAL
+ info->si_errno = 0;
+#else
+ info->q = NULL;
+#endif
}
}
static int __dequeue_signal(struct sigpending *pending, sigset_t *mask,
- siginfo_t *info)
+ ksiginfo_t *info)
{
int sig = next_signal(pending, mask);
@@ -604,7 +625,7 @@ static int __dequeue_signal(struct sigpending *pending, sigset_t *mask,
*
* All callers have to hold the siglock.
*/
-int dequeue_signal(struct task_struct *tsk, sigset_t *mask, siginfo_t *info)
+int dequeue_signal(struct task_struct *tsk, sigset_t *mask, ksiginfo_t *info)
{
int signr;
@@ -659,7 +680,12 @@ int dequeue_signal(struct task_struct *tsk, sigset_t *mask, siginfo_t *info)
*/
current->jobctl |= JOBCTL_STOP_DEQUEUED;
}
+#ifndef CONFIG_ARCH_USES_KSIGNAL
if ((info->si_code & __SI_MASK) == __SI_TIMER && info->si_sys_private) {
+#else
+ if ((info->si_code & __SI_MASK) == __SI_TIMER &&
+ info->q->info.si_sys_private) {
+#endif
/*
* Release the siglock to ensure proper locking order
* of timer locks outside of siglocks. Note, we leave
@@ -667,7 +693,11 @@ int dequeue_signal(struct task_struct *tsk, sigset_t *mask, siginfo_t *info)
* about to disable them again anyway.
*/
spin_unlock(&tsk->sighand->siglock);
+#ifndef CONFIG_ARCH_USES_KSIGNAL
do_schedule_next_timer(info);
+#else
+ do_schedule_next_timer(&info->q->info);
+#endif
spin_lock(&tsk->sighand->siglock);
}
return signr;
@@ -1836,7 +1866,8 @@ static int sigkill_pending(struct task_struct *tsk)
* If we actually decide not to stop at all because the tracer
* is gone, we keep current->exit_code unless clear_code.
*/
-static void ptrace_stop(int exit_code, int why, int clear_code, siginfo_t *info)
+static void ptrace_stop(int exit_code, int why, int clear_code,
+ ksiginfo_t *info)
__releases(¤t->sighand->siglock)
__acquires(¤t->sighand->siglock)
{
@@ -1960,16 +1991,17 @@ static void ptrace_stop(int exit_code, int why, int clear_code, siginfo_t *info)
static void ptrace_do_notify(int signr, int exit_code, int why)
{
- siginfo_t info;
+ ksiginfo_t info;
- memset(&info, 0, sizeof info);
info.si_signo = signr;
info.si_code = exit_code;
info.si_pid = task_pid_vnr(current);
info.si_uid = from_kuid_munged(current_user_ns(), current_uid());
+ info.q = NULL;
/* Let the debugger run. */
ptrace_stop(exit_code, why, 1, &info);
+ dismiss_siginfo(&info);
}
void ptrace_notify(int exit_code)
@@ -2141,7 +2173,7 @@ static void do_jobctl_trap(void)
}
}
-static int ptrace_signal(int signr, siginfo_t *info)
+static int ptrace_signal(int signr, ksiginfo_t *info)
{
ptrace_signal_deliver();
/*
@@ -2170,8 +2202,11 @@ static int ptrace_signal(int signr, siginfo_t *info)
* have updated *info via PTRACE_SETSIGINFO.
*/
if (signr != info->si_signo) {
+ dismiss_siginfo(info);
info->si_signo = signr;
+#ifndef CONFIG_ARCH_USES_KSIGNAL
info->si_errno = 0;
+#endif
info->si_code = SI_USER;
rcu_read_lock();
info->si_pid = task_pid_vnr(current->parent);
@@ -2182,14 +2217,25 @@ static int ptrace_signal(int signr, siginfo_t *info)
/* If the (new) signal is now blocked, requeue it. */
if (sigismember(¤t->blocked, signr)) {
+#ifndef CONFIG_ARCH_USES_KSIGNAL
specific_send_sig_info(signr, info, current);
+#else
+ if (!info->q) {
+ struct siginfo s = {.si_code = info->si_code,
+ .si_signo = signr,
+ .si_pid = info->si_pid,
+ .si_uid = info->si_uid};
+ specific_send_sig_info(signr, &s, current);
+ } else
+ specific_send_sig_info(signr, &info->q->info, current);
+#endif
signr = 0;
}
return signr;
}
-int get_signal_to_deliver(siginfo_t *info, struct k_sigaction *return_ka,
+int get_signal_to_deliver(ksiginfo_t *info, struct k_sigaction *return_ka,
struct pt_regs *regs, void *cookie)
{
struct sighand_struct *sighand = current->sighand;
@@ -2363,6 +2409,7 @@ relock:
*/
do_coredump(info);
}
+ dismiss_siginfo(info);
/*
* Death signals, no core dump.
@@ -2377,7 +2424,7 @@ relock:
/**
* signal_delivered -
* @sig: number of signal being delivered
- * @info: siginfo_t of signal being delivered
+ * @info: ksiginfo_t of signal being delivered
* @ka: sigaction setting that chose the handler
* @regs: user register state
* @stepping: nonzero if debugger single-step or block-step in use
@@ -2387,7 +2434,7 @@ relock:
* is always blocked, and the signal itself is blocked unless %SA_NODEFER
* is set in @ka->sa.sa_flags. Tracing is notified.
*/
-void signal_delivered(int sig, siginfo_t *info, struct k_sigaction *ka,
+void signal_delivered(int sig, ksiginfo_t *info, struct k_sigaction *ka,
struct pt_regs *regs, int stepping)
{
sigset_t blocked;
@@ -2412,6 +2459,7 @@ void signal_setup_done(int failed, struct ksignal *ksig, int stepping)
else
signal_delivered(ksig->sig, &ksig->info, &ksig->ka,
signal_pt_regs(), stepping);
+ dismiss_siginfo(&ksig->info);
}
/*
@@ -2721,7 +2769,7 @@ COMPAT_SYSCALL_DEFINE2(rt_sigpending, compat_sigset_t __user *, uset,
}
#endif
-int copy_siginfo_to_user(siginfo_t __user *to, const siginfo_t *from)
+int __copy_siginfo_to_user(siginfo_t __user *to, const siginfo_t *from)
{
int err;
@@ -2804,13 +2852,35 @@ int copy_siginfo_to_user(siginfo_t __user *to, const siginfo_t *from)
return err;
}
+int copy_siginfo_to_user(siginfo_t __user *to, const ksiginfo_t *from)
+{
+ const siginfo_t *info;
+#ifdef CONFIG_ARCH_USES_KSIGNAL
+ if (!from->q) {
+ int err;
+ if (!access_ok (VERIFY_WRITE, to, sizeof(siginfo_t)))
+ return -EFAULT;
+ err = __put_user(from->si_signo, &to->si_signo);
+ err |= __put_user(0, &to->si_errno);
+ err |= __put_user((short) from->si_code, &to->si_code);
+ err |= __put_user(from->si_pid, &to->si_pid);
+ err |= __put_user(from->si_uid, &to->si_uid);
+ return err;
+ }
+ info = &from->q->info;
+#else
+ info = from;
+#endif
+ return __copy_siginfo_to_user(to, info);
+}
+
/**
* do_sigtimedwait - wait for queued signals specified in @which
* @which: queued signals to wait for
* @info: if non-null, the signal's siginfo is returned here
* @ts: upper bound on process time suspension
*/
-int do_sigtimedwait(const sigset_t *which, siginfo_t *info,
+int do_sigtimedwait(const sigset_t *which, ksiginfo_t *info,
const struct timespec *ts)
{
struct task_struct *tsk = current;
@@ -2878,7 +2948,7 @@ SYSCALL_DEFINE4(rt_sigtimedwait, const sigset_t __user *, uthese,
{
sigset_t these;
struct timespec ts;
- siginfo_t info;
+ ksiginfo_t info;
int ret;
/* XXX: Don't preclude handling different sized sigset_t's. */
@@ -2999,6 +3069,73 @@ SYSCALL_DEFINE2(tkill, pid_t, pid, int, sig)
return do_tkill(0, pid, sig);
}
+int copy_ksiginfo_from_user(ksiginfo_t *to, const siginfo_t __user *from)
+{
+#ifndef CONFIG_ARCH_USES_KSIGNAL
+ return copy_from_user(to, from, sizeof(siginfo_t)) ? -EFAULT : 0;
+#else
+ struct sigqueue *q;
+ if (!access_ok(VERIFY_READ, from, sizeof(siginfo_t)))
+ return -EFAULT;
+ if (__get_user(to->si_code, &from->si_code))
+ return -EFAULT;
+ if (to->si_code == SI_USER) {
+ if (__get_user(to->si_signo, &from->si_signo) ||
+ __get_user(to->si_uid, &from->si_uid) ||
+ __get_user(to->si_pid, &from->si_pid))
+ return -EFAULT;
+ to->q = NULL;
+ return 0;
+ }
+ q = __sigqueue_alloc(-1, current, GFP_KERNEL, 0);
+ if (!q)
+ return -ENOMEM;
+ if (copy_from_user(&q->info, from, sizeof(siginfo_t))) {
+ __sigqueue_free(q);
+ return -EFAULT;
+ }
+ to->q = q;
+ to->si_code = q->info.si_code;
+ to->si_signo = q->info.si_signo;
+ return 0;
+#endif
+}
+
+#ifdef CONFIG_COMPAT
+
+int copy_ksiginfo_from_user32(ksiginfo_t *to, compat_siginfo_t __user *from)
+{
+#ifndef CONFIG_ARCH_USES_KSIGNAL
+ return copy_siginfo_from_user32(to, from);
+#else
+ struct sigqueue *q;
+ if (!access_ok(VERIFY_READ, from, sizeof(compat_siginfo_t)))
+ return -EFAULT;
+ if (__get_user(to->si_code, &from->si_code))
+ return -EFAULT;
+ if (to->si_code == SI_USER) {
+ if (__get_user(to->si_signo, &from->si_signo) ||
+ __get_user(to->si_uid, &from->si_uid) ||
+ __get_user(to->si_pid, &from->si_pid))
+ return -EFAULT;
+ to->q = NULL;
+ return 0;
+ }
+ q = __sigqueue_alloc(-1, current, GFP_KERNEL, 0);
+ if (!q)
+ return -ENOMEM;
+ if (copy_siginfo_from_user32(&q->info, from)) {
+ __sigqueue_free(q);
+ return -EFAULT;
+ }
+ to->q = q;
+ to->si_code = q->info.si_code;
+ to->si_signo = q->info.si_signo;
+ return 0;
+#endif
+}
+#endif
+
static int do_rt_sigqueueinfo(pid_t pid, int sig, siginfo_t *info)
{
/* Not even root can pretend to send signals from the kernel.
^ permalink raw reply related [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-15 5:25 ` Al Viro
0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-15 5:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Eric Sandeen, Oleg Nesterov, xfs, Dave Jones, Linux Kernel
On Thu, Feb 13, 2014 at 09:58:47AM -0800, Linus Torvalds wrote:
> On Thu, Feb 13, 2014 at 9:40 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > And we should be careful with SIGQUEUE_PREALLOC, at least
> > collect_signal() should not do list_del_init()... Plus we need to
> > handle the SEND_SIG_FORCED-like case.
>
> I don't think the users need to care. They'd just call
> "sigqueue_free()" not knowing about our preallocations etc. That kind
> of detail should be confined to inside signal.c.
>
> But there really aren't that many users. There's a couple of
> "dequeue_signal_lock()" users, but they don't actually *want* the
> siginfo at all (they're kernel threads), so we can just make that
> function free the siginfo immediately (and get rid of the totally
> unnecessay kernel stack allocation). And outside of signal.c only
> signalfd uses "dequeue_signal()" itself, and that would be the only
> one that would need to be taught to use (in signalfd_copyinfo()) and
> then free the sigqueue entry.
>
> So it really looks like the right thing to do, and fairly
> straightforward. But I'm leaving the coding proof to Al, since he
> already offered ;)
OK, _very_ preliminary patch follows. It's uglier than it has to and it's
not in the form I would consider suitable for merge. It doesn't depend
on conversions of architectures to use of ksignal as prereqs; instead of
that it has config symbol (ARCH_USES_KSIGNAL) that can be selected on
architectures already through that conversion (in this patch - just on
x86, since that was all I could test on at the moment; e.g. alpha and
arm could also get such selects right now). If it isn't selected, everything
builds as usual. With large siginfo on stack for signal path, as before.
We get ksiginfo_t as an alias for siginfo_t in that case, dismiss_siginfo()
is a no-op, etc. If it _is_ selected, ksiginfo_t is much smaller than
siginfo_t.
Of course, we pay for that with ifdefs in places that need to understand
[k]siginfo_t guts; signalfd_copyinfo(), copy_siginfo_from_user{,32}() and
copy_ksiginfo_to_user{,32}(), tracepoint for deliver_signal(), collect_signal(),
trivial ones in dequeue_signal() and an ugly bugger in ptrace_signal().
No way around that until all architectures are converted. Other places
get away with some siginfo_t replaced with ksiginfo_t and dismiss_siginfo()
added in some places. arch/x86/ia32/ia32_signal.c needed a bit of change
(we probably ought to unify copy_siginfo_from_user32() on all architectures
that have it, actually).
The sucker survived LTP syscall tests and hasn't died on xfstests yet either
(== doesn't seem to leak horribly). Consider it a proof-of-concept and no
more than that. One thing I'm really not satisfied with is signal sending
pathway - it would probably make a lot of sense to use ksiginfo there as
well, and have insertion into queue simply steal info->q instead of allocating
and copying. Another is that ifdefs like that are tolerable only if we
plan to convert everything during this cycle; I believe it to be doable,
actually. Having that sucker go before the conversions would make for
simpler logistics wrt architecture trees, but it may be better to get
all conversions merged first. Not sure... Anyway, here is it; comments
are welcome.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
diff --git a/arch/Kconfig b/arch/Kconfig
index 80bbb8c..f753561 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -522,4 +522,7 @@ config OLD_SIGACTION
config COMPAT_OLD_SIGACTION
bool
+config ARCH_USES_KSIGNAL
+ bool
+
source "kernel/gcov/Kconfig"
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 0af5250..4ec468d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -127,6 +127,7 @@ config X86
select HAVE_DEBUG_STACKOVERFLOW
select HAVE_IRQ_EXIT_ON_IRQ_STACK if X86_64
select HAVE_CC_STACKPROTECTOR
+ select ARCH_USES_KSIGNAL
config INSTRUCTION_DECODER
def_bool y
diff --git a/arch/x86/ia32/ia32_signal.c b/arch/x86/ia32/ia32_signal.c
index 2206757..611a03e 100644
--- a/arch/x86/ia32/ia32_signal.c
+++ b/arch/x86/ia32/ia32_signal.c
@@ -34,7 +34,7 @@
#include <asm/sys_ia32.h>
#include <asm/smap.h>
-int copy_siginfo_to_user32(compat_siginfo_t __user *to, const siginfo_t *from)
+int __copy_siginfo_to_user32(compat_siginfo_t __user *to, const siginfo_t *from)
{
int err = 0;
bool ia32 = test_thread_flag(TIF_IA32);
@@ -105,6 +105,25 @@ int copy_siginfo_to_user32(compat_siginfo_t __user *to, const siginfo_t *from)
return err;
}
+int copy_siginfo_to_user32(compat_siginfo_t __user *to, const ksiginfo_t *from)
+{
+ int err = 0;
+ if (!from->q) {
+ if (!access_ok(VERIFY_WRITE, to, sizeof(compat_siginfo_t)))
+ return -EFAULT;
+ put_user_try {
+ /* fast case */
+ put_user_ex(from->si_signo, &to->si_signo);
+ put_user_ex(0, &to->si_errno);
+ put_user_ex((short)from->si_code, &to->si_code);
+ put_user_ex(from->si_pid, &to->si_pid);
+ put_user_ex(from->si_uid, &to->si_uid);
+ } put_user_catch(err);
+ return err;
+ }
+ return __copy_siginfo_to_user32(to, &from->q->info);
+}
+
int copy_siginfo_from_user32(siginfo_t *to, compat_siginfo_t __user *from)
{
int err = 0;
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 55298db..673ab73 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -201,10 +201,11 @@ static int sock_xmit(struct nbd_device *nbd, int send, void *buf, int size,
msg.msg_flags);
if (signal_pending(current)) {
- siginfo_t info;
+ ksiginfo_t info;
printk(KERN_WARNING "nbd (pid %d: %s) got signal %d\n",
task_pid_nr(current), current->comm,
dequeue_signal_lock(current, ¤t->blocked, &info));
+ dismiss_siginfo(&info);
result = -EINTR;
sock_shutdown(nbd, !send);
break;
diff --git a/drivers/usb/gadget/f_mass_storage.c b/drivers/usb/gadget/f_mass_storage.c
index b963939..ecacac5 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -2337,7 +2337,7 @@ static void fsg_disable(struct usb_function *f)
static void handle_exception(struct fsg_common *common)
{
- siginfo_t info;
+ ksiginfo_t info;
int i;
struct fsg_buffhd *bh;
enum fsg_state old_state;
@@ -2351,6 +2351,7 @@ static void handle_exception(struct fsg_common *common)
for (;;) {
int sig =
dequeue_signal_lock(current, ¤t->blocked, &info);
+ dismiss_siginfo(&info);
if (!sig)
break;
if (sig != SIGUSR1) {
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 67be295..e79a23e 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1371,7 +1371,7 @@ static void fill_auxv_note(struct memelfnote *note, struct mm_struct *mm)
}
static void fill_siginfo_note(struct memelfnote *note, user_siginfo_t *csigdata,
- const siginfo_t *siginfo)
+ const ksiginfo_t *siginfo)
{
mm_segment_t old_fs = get_fs();
set_fs(KERNEL_DS);
@@ -1578,7 +1578,7 @@ static int fill_thread_core_info(struct elf_thread_core_info *t,
static int fill_note_info(struct elfhdr *elf, int phdrs,
struct elf_note_info *info,
- const siginfo_t *siginfo, struct pt_regs *regs)
+ const ksiginfo_t *siginfo, struct pt_regs *regs)
{
struct task_struct *dump_task = current;
const struct user_regset_view *view = task_user_regset_view(dump_task);
@@ -1827,7 +1827,7 @@ static int elf_note_info_init(struct elf_note_info *info)
static int fill_note_info(struct elfhdr *elf, int phdrs,
struct elf_note_info *info,
- const siginfo_t *siginfo, struct pt_regs *regs)
+ const ksiginfo_t *siginfo, struct pt_regs *regs)
{
struct list_head *t;
struct core_thread *ct;
diff --git a/fs/coredump.c b/fs/coredump.c
index e3ad709..44ff98d 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -484,7 +484,7 @@ static int umh_pipe_setup(struct subprocess_info *info, struct cred *new)
return err;
}
-void do_coredump(const siginfo_t *siginfo)
+void do_coredump(const ksiginfo_t *siginfo)
{
struct core_state core_state;
struct core_name cn;
diff --git a/fs/jffs2/background.c b/fs/jffs2/background.c
index 2b60ce1..aefdff2 100644
--- a/fs/jffs2/background.c
+++ b/fs/jffs2/background.c
@@ -119,13 +119,14 @@ static int jffs2_garbage_collect_thread(void *_c)
/* Put_super will send a SIGKILL and then wait on the sem.
*/
while (signal_pending(current) || freezing(current)) {
- siginfo_t info;
+ ksiginfo_t info;
unsigned long signr;
if (try_to_freeze())
goto again;
signr = dequeue_signal_lock(current, ¤t->blocked, &info);
+ dismiss_siginfo(&info);
switch(signr) {
case SIGSTOP:
diff --git a/fs/signalfd.c b/fs/signalfd.c
index 424b7b6..d6f3c47 100644
--- a/fs/signalfd.c
+++ b/fs/signalfd.c
@@ -78,8 +78,9 @@ static unsigned int signalfd_poll(struct file *file, poll_table *wait)
* Copied from copy_siginfo_to_user() in kernel/signal.c
*/
static int signalfd_copyinfo(struct signalfd_siginfo __user *uinfo,
- siginfo_t const *kinfo)
+ const ksiginfo_t *from)
{
+ const siginfo_t *kinfo;
long err;
BUILD_BUG_ON(sizeof(struct signalfd_siginfo) != 128);
@@ -89,6 +90,19 @@ static int signalfd_copyinfo(struct signalfd_siginfo __user *uinfo,
*/
err = __clear_user(uinfo, sizeof(*uinfo));
+#ifdef CONFIG_ARCH_USES_KSIGNAL
+ if (!from->q) {
+ err |= __put_user(from->si_signo, &uinfo->ssi_signo);
+ err |= __put_user(0, &uinfo->ssi_errno);
+ err |= __put_user((short) from->si_code, &uinfo->ssi_code);
+ err |= __put_user(from->si_pid, &uinfo->ssi_pid);
+ err |= __put_user(from->si_uid, &uinfo->ssi_uid);
+ goto out;
+ }
+ kinfo = &from->q->info;
+#else
+ kinfo = from;
+#endif
/*
* If you change siginfo_t structure, please be sure
* this code is fixed accordingly.
@@ -152,10 +166,11 @@ static int signalfd_copyinfo(struct signalfd_siginfo __user *uinfo,
break;
}
+out:
return err ? -EFAULT: sizeof(*uinfo);
}
-static ssize_t signalfd_dequeue(struct signalfd_ctx *ctx, siginfo_t *info,
+static ssize_t signalfd_dequeue(struct signalfd_ctx *ctx, ksiginfo_t *info,
int nonblock)
{
ssize_t ret;
@@ -207,7 +222,7 @@ static ssize_t signalfd_read(struct file *file, char __user *buf, size_t count,
struct signalfd_siginfo __user *siginfo;
int nonblock = file->f_flags & O_NONBLOCK;
ssize_t ret, total = 0;
- siginfo_t info;
+ ksiginfo_t info;
count /= sizeof(struct signalfd_siginfo);
if (!count)
@@ -219,6 +234,7 @@ static ssize_t signalfd_read(struct file *file, char __user *buf, size_t count,
if (unlikely(ret <= 0))
break;
ret = signalfd_copyinfo(siginfo, &info);
+ dismiss_siginfo(&info);
if (ret < 0)
break;
siginfo++;
diff --git a/include/asm-generic/siginfo.h b/include/asm-generic/siginfo.h
index 3d1a3af..43a6895 100644
--- a/include/asm-generic/siginfo.h
+++ b/include/asm-generic/siginfo.h
@@ -15,6 +15,11 @@
#define __SI_CODE(T,N) ((T) | ((N) & 0xffff))
struct siginfo;
+#ifndef CONFIG_ARCH_USES_KSIGNAL
+#define small_siginfo siginfo
+#else
+struct small_siginfo;
+#endif
void do_schedule_next_timer(struct siginfo *info);
#ifndef HAVE_ARCH_COPY_SIGINFO
@@ -32,6 +37,8 @@ static inline void copy_siginfo(struct siginfo *to, struct siginfo *from)
#endif
-extern int copy_siginfo_to_user(struct siginfo __user *to, const struct siginfo *from);
+extern int copy_ksiginfo_from_user(struct small_siginfo *to, const struct siginfo __user *from);
+extern int copy_siginfo_to_user(struct siginfo __user *to, const struct small_siginfo *from);
+extern int __copy_siginfo_to_user(struct siginfo __user *to, const struct siginfo *from);
#endif
diff --git a/include/linux/binfmts.h b/include/linux/binfmts.h
index b4a745d..912d8d4 100644
--- a/include/linux/binfmts.h
+++ b/include/linux/binfmts.h
@@ -56,7 +56,7 @@ struct linux_binprm {
/* Function parameter for binfmt->coredump */
struct coredump_params {
- const siginfo_t *siginfo;
+ const ksiginfo_t *siginfo;
struct pt_regs *regs;
struct file *file;
unsigned long limit;
diff --git a/include/linux/compat.h b/include/linux/compat.h
index 3f448c6..9ab31c9 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -362,7 +362,9 @@ long compat_get_bitmap(unsigned long *mask, const compat_ulong_t __user *umask,
long compat_put_bitmap(compat_ulong_t __user *umask, unsigned long *mask,
unsigned long bitmap_size);
int copy_siginfo_from_user32(siginfo_t *to, struct compat_siginfo __user *from);
-int copy_siginfo_to_user32(struct compat_siginfo __user *to, const siginfo_t *from);
+int copy_ksiginfo_from_user32(ksiginfo_t *to, struct compat_siginfo __user *from);
+int copy_siginfo_to_user32(struct compat_siginfo __user *to, const ksiginfo_t *from);
+int __copy_siginfo_to_user32(struct compat_siginfo __user *to, const siginfo_t *from);
int get_compat_sigevent(struct sigevent *event,
const struct compat_sigevent __user *u_event);
long compat_sys_rt_tgsigqueueinfo(compat_pid_t tgid, compat_pid_t pid, int sig,
diff --git a/include/linux/coredump.h b/include/linux/coredump.h
index d016a12..3c9f79c 100644
--- a/include/linux/coredump.h
+++ b/include/linux/coredump.h
@@ -15,9 +15,9 @@ extern int dump_skip(struct coredump_params *cprm, size_t nr);
extern int dump_emit(struct coredump_params *cprm, const void *addr, int nr);
extern int dump_align(struct coredump_params *cprm, int align);
#ifdef CONFIG_COREDUMP
-extern void do_coredump(const siginfo_t *siginfo);
+extern void do_coredump(const ksiginfo_t *siginfo);
#else
-static inline void do_coredump(const siginfo_t *siginfo) {}
+static inline void do_coredump(const ksiginfo_t *siginfo) {}
#endif
#endif /* _LINUX_COREDUMP_H */
diff --git a/include/linux/sched.h b/include/linux/sched.h
index a781dec..60834bf 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1428,7 +1428,7 @@ struct task_struct {
struct io_context *io_context;
unsigned long ptrace_message;
- siginfo_t *last_siginfo; /* For ptrace use. */
+ ksiginfo_t *last_siginfo; /* For ptrace use. */
struct task_io_accounting ioac;
#if defined(CONFIG_TASK_XACCT)
u64 acct_rss_mem1; /* accumulated rss usage */
@@ -2177,9 +2177,9 @@ extern void flush_signals(struct task_struct *);
extern void __flush_signals(struct task_struct *);
extern void ignore_signals(struct task_struct *);
extern void flush_signal_handlers(struct task_struct *, int force_default);
-extern int dequeue_signal(struct task_struct *tsk, sigset_t *mask, siginfo_t *info);
+extern int dequeue_signal(struct task_struct *tsk, sigset_t *mask, ksiginfo_t *info);
-static inline int dequeue_signal_lock(struct task_struct *tsk, sigset_t *mask, siginfo_t *info)
+static inline int dequeue_signal_lock(struct task_struct *tsk, sigset_t *mask, ksiginfo_t *info)
{
unsigned long flags;
int ret;
@@ -2204,7 +2204,6 @@ extern int kill_pid_info_as_cred(int, struct siginfo *, struct pid *,
const struct cred *, u32);
extern int kill_pgrp(struct pid *pid, int sig, int priv);
extern int kill_pid(struct pid *pid, int sig, int priv);
-extern int kill_proc_info(int, struct siginfo *, pid_t);
extern __must_check bool do_notify_parent(struct task_struct *, int);
extern void __wake_up_parent(struct task_struct *p, struct task_struct *parent);
extern void force_sig(int, struct task_struct *);
diff --git a/include/linux/signal.h b/include/linux/signal.h
index 2ac423b..c999b4a 100644
--- a/include/linux/signal.h
+++ b/include/linux/signal.h
@@ -236,12 +236,29 @@ static inline int valid_signal(unsigned long sig)
struct timespec;
struct pt_regs;
+#ifdef CONFIG_ARCH_USES_KSIGNAL
+typedef struct small_siginfo {
+ int si_signo;
+ int si_code;
+ union { struct { /* yecch... */
+ __kernel_pid_t _pid;
+ __ARCH_SI_UID_T _uid;
+ } _kill; } _sifields;
+ struct sigqueue *q;
+} ksiginfo_t;
+extern void dismiss_siginfo(ksiginfo_t *);
+#else
+#define small_siginfo siginfo
+#define ksiginfo_t siginfo_t
+#define dismiss_siginfo(info) ((void)0)
+#endif
+
extern int next_signal(struct sigpending *pending, sigset_t *mask);
extern int do_send_sig_info(int sig, struct siginfo *info,
struct task_struct *p, bool group);
extern int group_send_sig_info(int sig, struct siginfo *info, struct task_struct *p);
extern int __group_send_sig_info(int, struct siginfo *, struct task_struct *);
-extern int do_sigtimedwait(const sigset_t *, siginfo_t *,
+extern int do_sigtimedwait(const sigset_t *, ksiginfo_t *,
const struct timespec *);
extern int sigprocmask(int, sigset_t *, sigset_t *);
extern void set_current_blocked(sigset_t *);
@@ -281,13 +298,13 @@ struct old_sigaction {
struct ksignal {
struct k_sigaction ka;
- siginfo_t info;
+ ksiginfo_t info;
int sig;
};
-extern int get_signal_to_deliver(siginfo_t *info, struct k_sigaction *return_ka, struct pt_regs *regs, void *cookie);
+extern int get_signal_to_deliver(ksiginfo_t *info, struct k_sigaction *return_ka, struct pt_regs *regs, void *cookie);
extern void signal_setup_done(int failed, struct ksignal *ksig, int stepping);
-extern void signal_delivered(int sig, siginfo_t *info, struct k_sigaction *ka, struct pt_regs *regs, int stepping);
+extern void signal_delivered(int sig, ksiginfo_t *info, struct k_sigaction *ka, struct pt_regs *regs, int stepping);
extern void exit_signals(struct task_struct *tsk);
/*
diff --git a/include/linux/tracehook.h b/include/linux/tracehook.h
index 1e98b55..c9e7a0e 100644
--- a/include/linux/tracehook.h
+++ b/include/linux/tracehook.h
@@ -146,7 +146,7 @@ static inline void tracehook_report_syscall_exit(struct pt_regs *regs, int step)
* Called without locks, shortly before returning to user mode
* (or handling more signals).
*/
-static inline void tracehook_signal_handler(int sig, siginfo_t *info,
+static inline void tracehook_signal_handler(int sig, ksiginfo_t *info,
const struct k_sigaction *ka,
struct pt_regs *regs, int stepping)
{
diff --git a/include/trace/events/signal.h b/include/trace/events/signal.h
index 39a8a43..1494a3e 100644
--- a/include/trace/events/signal.h
+++ b/include/trace/events/signal.h
@@ -23,6 +23,27 @@
} \
} while (0)
+#ifndef CONFIG_ARCH_USES_KSIGNAL
+#define TP_SI_ERRNO(info) info->si_errno
+#else
+#define TP_SI_ERRNO(info) info->q ? info->q->info.si_errno : 0
+#endif
+
+#define TP_STORE_KSIGINFO(__entry, info) \
+ do { \
+ if (info == (ksiginfo_t *)SEND_SIG_NOINFO || \
+ info == (ksiginfo_t *)SEND_SIG_FORCED) { \
+ __entry->errno = 0; \
+ __entry->code = SI_USER; \
+ } else if (info == (ksiginfo_t *)SEND_SIG_PRIV) {\
+ __entry->errno = 0; \
+ __entry->code = SI_KERNEL; \
+ } else { \
+ __entry->errno = TP_SI_ERRNO(info); \
+ __entry->code = info->si_code; \
+ } \
+ } while (0)
+
#ifndef TRACE_HEADER_MULTI_READ
enum {
TRACE_SIGNAL_DELIVERED,
@@ -95,7 +116,7 @@ TRACE_EVENT(signal_generate,
*/
TRACE_EVENT(signal_deliver,
- TP_PROTO(int sig, struct siginfo *info, struct k_sigaction *ka),
+ TP_PROTO(int sig, ksiginfo_t *info, struct k_sigaction *ka),
TP_ARGS(sig, info, ka),
@@ -109,7 +130,7 @@ TRACE_EVENT(signal_deliver,
TP_fast_assign(
__entry->sig = sig;
- TP_STORE_SIGINFO(__entry, info);
+ TP_STORE_KSIGINFO(__entry, info);
__entry->sa_handler = (unsigned long)ka->sa.sa_handler;
__entry->sa_flags = ka->sa.sa_flags;
),
diff --git a/kernel/compat.c b/kernel/compat.c
index 0a09e48..82084b4 100644
--- a/kernel/compat.c
+++ b/kernel/compat.c
@@ -579,7 +579,7 @@ COMPAT_SYSCALL_DEFINE5(waitid,
BUG_ON(info.si_code & __SI_MASK);
info.si_code |= __SI_CHLD;
- return copy_siginfo_to_user32(uinfo, &info);
+ return __copy_siginfo_to_user32(uinfo, &info);
}
static int compat_get_user_cpu_mask(compat_ulong_t __user *user_mask_ptr,
@@ -981,7 +981,7 @@ COMPAT_SYSCALL_DEFINE4(rt_sigtimedwait, compat_sigset_t __user *, uthese,
compat_sigset_t s32;
sigset_t s;
struct timespec t;
- siginfo_t info;
+ ksiginfo_t info;
long ret;
if (sigsetsize != sizeof(sigset_t))
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 1f4bcb3..11223d4 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -589,7 +589,7 @@ static int ptrace_setoptions(struct task_struct *child, unsigned long data)
return 0;
}
-static int ptrace_getsiginfo(struct task_struct *child, siginfo_t *info)
+static int ptrace_getsiginfo(struct task_struct *child, ksiginfo_t *info)
{
unsigned long flags;
int error = -ESRCH;
@@ -605,7 +605,7 @@ static int ptrace_getsiginfo(struct task_struct *child, siginfo_t *info)
return error;
}
-static int ptrace_setsiginfo(struct task_struct *child, const siginfo_t *info)
+static int ptrace_setsiginfo(struct task_struct *child, ksiginfo_t *info)
{
unsigned long flags;
int error = -ESRCH;
@@ -613,11 +613,14 @@ static int ptrace_setsiginfo(struct task_struct *child, const siginfo_t *info)
if (lock_task_sighand(child, &flags)) {
error = -EINVAL;
if (likely(child->last_siginfo != NULL)) {
+ dismiss_siginfo(child->last_siginfo);
*child->last_siginfo = *info;
error = 0;
}
unlock_task_sighand(child, &flags);
}
+ if (error)
+ dismiss_siginfo(info);
return error;
}
@@ -666,7 +669,7 @@ static int ptrace_peek_siginfo(struct task_struct *child,
if (unlikely(is_compat_task())) {
compat_siginfo_t __user *uinfo = compat_ptr(data);
- if (copy_siginfo_to_user32(uinfo, &info) ||
+ if (__copy_siginfo_to_user32(uinfo, &info) ||
__put_user(info.si_code, &uinfo->si_code)) {
ret = -EFAULT;
break;
@@ -677,7 +680,7 @@ static int ptrace_peek_siginfo(struct task_struct *child,
{
siginfo_t __user *uinfo = (siginfo_t __user *) data;
- if (copy_siginfo_to_user(uinfo, &info) ||
+ if (__copy_siginfo_to_user(uinfo, &info) ||
__put_user(info.si_code, &uinfo->si_code)) {
ret = -EFAULT;
break;
@@ -805,7 +808,7 @@ int ptrace_request(struct task_struct *child, long request,
{
bool seized = child->ptrace & PT_SEIZED;
int ret = -EIO;
- siginfo_t siginfo, *si;
+ ksiginfo_t siginfo, *si;
void __user *datavp = (void __user *) data;
unsigned long __user *datalp = datavp;
unsigned long flags;
@@ -839,9 +842,8 @@ int ptrace_request(struct task_struct *child, long request,
break;
case PTRACE_SETSIGINFO:
- if (copy_from_user(&siginfo, datavp, sizeof siginfo))
- ret = -EFAULT;
- else
+ ret = copy_ksiginfo_from_user(&siginfo, datavp);
+ if (!ret)
ret = ptrace_setsiginfo(child, &siginfo);
break;
@@ -1107,7 +1109,7 @@ int compat_ptrace_request(struct task_struct *child, compat_long_t request,
{
compat_ulong_t __user *datap = compat_ptr(data);
compat_ulong_t word;
- siginfo_t siginfo;
+ ksiginfo_t siginfo;
int ret;
switch (request) {
@@ -1139,8 +1141,7 @@ int compat_ptrace_request(struct task_struct *child, compat_long_t request,
break;
case PTRACE_SETSIGINFO:
- memset(&siginfo, 0, sizeof siginfo);
- if (copy_siginfo_from_user32(
+ if (copy_ksiginfo_from_user32(
&siginfo, (struct compat_siginfo __user *) datap))
ret = -EFAULT;
else
diff --git a/kernel/signal.c b/kernel/signal.c
index 48cf9fc..2b641aa 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -540,7 +540,18 @@ unblock_all_signals(void)
spin_unlock_irqrestore(¤t->sighand->siglock, flags);
}
-static void collect_signal(int sig, struct sigpending *list, siginfo_t *info)
+#ifdef CONFIG_ARCH_USES_KSIGNAL
+void dismiss_siginfo(ksiginfo_t *info)
+{
+ if (info->q)
+ __sigqueue_free(info->q);
+ info->q = NULL;
+}
+EXPORT_SYMBOL(dismiss_siginfo);
+#endif
+
+static void collect_signal(int sig, struct sigpending *list,
+ ksiginfo_t *info)
{
struct sigqueue *q, *first = NULL;
@@ -561,8 +572,14 @@ static void collect_signal(int sig, struct sigpending *list, siginfo_t *info)
if (first) {
still_pending:
list_del_init(&first->list);
+#ifndef CONFIG_ARCH_USES_KSIGNAL
copy_siginfo(info, &first->info);
__sigqueue_free(first);
+#else
+ info->si_signo = sig;
+ info->si_code = first->info.si_code;
+ info->q = first;
+#endif
} else {
/*
* Ok, it wasn't in the queue. This must be
@@ -570,15 +587,19 @@ still_pending:
* out of queue space. So zero out the info.
*/
info->si_signo = sig;
- info->si_errno = 0;
info->si_code = SI_USER;
info->si_pid = 0;
info->si_uid = 0;
+#ifndef CONFIG_ARCH_USES_KSIGNAL
+ info->si_errno = 0;
+#else
+ info->q = NULL;
+#endif
}
}
static int __dequeue_signal(struct sigpending *pending, sigset_t *mask,
- siginfo_t *info)
+ ksiginfo_t *info)
{
int sig = next_signal(pending, mask);
@@ -604,7 +625,7 @@ static int __dequeue_signal(struct sigpending *pending, sigset_t *mask,
*
* All callers have to hold the siglock.
*/
-int dequeue_signal(struct task_struct *tsk, sigset_t *mask, siginfo_t *info)
+int dequeue_signal(struct task_struct *tsk, sigset_t *mask, ksiginfo_t *info)
{
int signr;
@@ -659,7 +680,12 @@ int dequeue_signal(struct task_struct *tsk, sigset_t *mask, siginfo_t *info)
*/
current->jobctl |= JOBCTL_STOP_DEQUEUED;
}
+#ifndef CONFIG_ARCH_USES_KSIGNAL
if ((info->si_code & __SI_MASK) == __SI_TIMER && info->si_sys_private) {
+#else
+ if ((info->si_code & __SI_MASK) == __SI_TIMER &&
+ info->q->info.si_sys_private) {
+#endif
/*
* Release the siglock to ensure proper locking order
* of timer locks outside of siglocks. Note, we leave
@@ -667,7 +693,11 @@ int dequeue_signal(struct task_struct *tsk, sigset_t *mask, siginfo_t *info)
* about to disable them again anyway.
*/
spin_unlock(&tsk->sighand->siglock);
+#ifndef CONFIG_ARCH_USES_KSIGNAL
do_schedule_next_timer(info);
+#else
+ do_schedule_next_timer(&info->q->info);
+#endif
spin_lock(&tsk->sighand->siglock);
}
return signr;
@@ -1836,7 +1866,8 @@ static int sigkill_pending(struct task_struct *tsk)
* If we actually decide not to stop at all because the tracer
* is gone, we keep current->exit_code unless clear_code.
*/
-static void ptrace_stop(int exit_code, int why, int clear_code, siginfo_t *info)
+static void ptrace_stop(int exit_code, int why, int clear_code,
+ ksiginfo_t *info)
__releases(¤t->sighand->siglock)
__acquires(¤t->sighand->siglock)
{
@@ -1960,16 +1991,17 @@ static void ptrace_stop(int exit_code, int why, int clear_code, siginfo_t *info)
static void ptrace_do_notify(int signr, int exit_code, int why)
{
- siginfo_t info;
+ ksiginfo_t info;
- memset(&info, 0, sizeof info);
info.si_signo = signr;
info.si_code = exit_code;
info.si_pid = task_pid_vnr(current);
info.si_uid = from_kuid_munged(current_user_ns(), current_uid());
+ info.q = NULL;
/* Let the debugger run. */
ptrace_stop(exit_code, why, 1, &info);
+ dismiss_siginfo(&info);
}
void ptrace_notify(int exit_code)
@@ -2141,7 +2173,7 @@ static void do_jobctl_trap(void)
}
}
-static int ptrace_signal(int signr, siginfo_t *info)
+static int ptrace_signal(int signr, ksiginfo_t *info)
{
ptrace_signal_deliver();
/*
@@ -2170,8 +2202,11 @@ static int ptrace_signal(int signr, siginfo_t *info)
* have updated *info via PTRACE_SETSIGINFO.
*/
if (signr != info->si_signo) {
+ dismiss_siginfo(info);
info->si_signo = signr;
+#ifndef CONFIG_ARCH_USES_KSIGNAL
info->si_errno = 0;
+#endif
info->si_code = SI_USER;
rcu_read_lock();
info->si_pid = task_pid_vnr(current->parent);
@@ -2182,14 +2217,25 @@ static int ptrace_signal(int signr, siginfo_t *info)
/* If the (new) signal is now blocked, requeue it. */
if (sigismember(¤t->blocked, signr)) {
+#ifndef CONFIG_ARCH_USES_KSIGNAL
specific_send_sig_info(signr, info, current);
+#else
+ if (!info->q) {
+ struct siginfo s = {.si_code = info->si_code,
+ .si_signo = signr,
+ .si_pid = info->si_pid,
+ .si_uid = info->si_uid};
+ specific_send_sig_info(signr, &s, current);
+ } else
+ specific_send_sig_info(signr, &info->q->info, current);
+#endif
signr = 0;
}
return signr;
}
-int get_signal_to_deliver(siginfo_t *info, struct k_sigaction *return_ka,
+int get_signal_to_deliver(ksiginfo_t *info, struct k_sigaction *return_ka,
struct pt_regs *regs, void *cookie)
{
struct sighand_struct *sighand = current->sighand;
@@ -2363,6 +2409,7 @@ relock:
*/
do_coredump(info);
}
+ dismiss_siginfo(info);
/*
* Death signals, no core dump.
@@ -2377,7 +2424,7 @@ relock:
/**
* signal_delivered -
* @sig: number of signal being delivered
- * @info: siginfo_t of signal being delivered
+ * @info: ksiginfo_t of signal being delivered
* @ka: sigaction setting that chose the handler
* @regs: user register state
* @stepping: nonzero if debugger single-step or block-step in use
@@ -2387,7 +2434,7 @@ relock:
* is always blocked, and the signal itself is blocked unless %SA_NODEFER
* is set in @ka->sa.sa_flags. Tracing is notified.
*/
-void signal_delivered(int sig, siginfo_t *info, struct k_sigaction *ka,
+void signal_delivered(int sig, ksiginfo_t *info, struct k_sigaction *ka,
struct pt_regs *regs, int stepping)
{
sigset_t blocked;
@@ -2412,6 +2459,7 @@ void signal_setup_done(int failed, struct ksignal *ksig, int stepping)
else
signal_delivered(ksig->sig, &ksig->info, &ksig->ka,
signal_pt_regs(), stepping);
+ dismiss_siginfo(&ksig->info);
}
/*
@@ -2721,7 +2769,7 @@ COMPAT_SYSCALL_DEFINE2(rt_sigpending, compat_sigset_t __user *, uset,
}
#endif
-int copy_siginfo_to_user(siginfo_t __user *to, const siginfo_t *from)
+int __copy_siginfo_to_user(siginfo_t __user *to, const siginfo_t *from)
{
int err;
@@ -2804,13 +2852,35 @@ int copy_siginfo_to_user(siginfo_t __user *to, const siginfo_t *from)
return err;
}
+int copy_siginfo_to_user(siginfo_t __user *to, const ksiginfo_t *from)
+{
+ const siginfo_t *info;
+#ifdef CONFIG_ARCH_USES_KSIGNAL
+ if (!from->q) {
+ int err;
+ if (!access_ok (VERIFY_WRITE, to, sizeof(siginfo_t)))
+ return -EFAULT;
+ err = __put_user(from->si_signo, &to->si_signo);
+ err |= __put_user(0, &to->si_errno);
+ err |= __put_user((short) from->si_code, &to->si_code);
+ err |= __put_user(from->si_pid, &to->si_pid);
+ err |= __put_user(from->si_uid, &to->si_uid);
+ return err;
+ }
+ info = &from->q->info;
+#else
+ info = from;
+#endif
+ return __copy_siginfo_to_user(to, info);
+}
+
/**
* do_sigtimedwait - wait for queued signals specified in @which
* @which: queued signals to wait for
* @info: if non-null, the signal's siginfo is returned here
* @ts: upper bound on process time suspension
*/
-int do_sigtimedwait(const sigset_t *which, siginfo_t *info,
+int do_sigtimedwait(const sigset_t *which, ksiginfo_t *info,
const struct timespec *ts)
{
struct task_struct *tsk = current;
@@ -2878,7 +2948,7 @@ SYSCALL_DEFINE4(rt_sigtimedwait, const sigset_t __user *, uthese,
{
sigset_t these;
struct timespec ts;
- siginfo_t info;
+ ksiginfo_t info;
int ret;
/* XXX: Don't preclude handling different sized sigset_t's. */
@@ -2999,6 +3069,73 @@ SYSCALL_DEFINE2(tkill, pid_t, pid, int, sig)
return do_tkill(0, pid, sig);
}
+int copy_ksiginfo_from_user(ksiginfo_t *to, const siginfo_t __user *from)
+{
+#ifndef CONFIG_ARCH_USES_KSIGNAL
+ return copy_from_user(to, from, sizeof(siginfo_t)) ? -EFAULT : 0;
+#else
+ struct sigqueue *q;
+ if (!access_ok(VERIFY_READ, from, sizeof(siginfo_t)))
+ return -EFAULT;
+ if (__get_user(to->si_code, &from->si_code))
+ return -EFAULT;
+ if (to->si_code == SI_USER) {
+ if (__get_user(to->si_signo, &from->si_signo) ||
+ __get_user(to->si_uid, &from->si_uid) ||
+ __get_user(to->si_pid, &from->si_pid))
+ return -EFAULT;
+ to->q = NULL;
+ return 0;
+ }
+ q = __sigqueue_alloc(-1, current, GFP_KERNEL, 0);
+ if (!q)
+ return -ENOMEM;
+ if (copy_from_user(&q->info, from, sizeof(siginfo_t))) {
+ __sigqueue_free(q);
+ return -EFAULT;
+ }
+ to->q = q;
+ to->si_code = q->info.si_code;
+ to->si_signo = q->info.si_signo;
+ return 0;
+#endif
+}
+
+#ifdef CONFIG_COMPAT
+
+int copy_ksiginfo_from_user32(ksiginfo_t *to, compat_siginfo_t __user *from)
+{
+#ifndef CONFIG_ARCH_USES_KSIGNAL
+ return copy_siginfo_from_user32(to, from);
+#else
+ struct sigqueue *q;
+ if (!access_ok(VERIFY_READ, from, sizeof(compat_siginfo_t)))
+ return -EFAULT;
+ if (__get_user(to->si_code, &from->si_code))
+ return -EFAULT;
+ if (to->si_code == SI_USER) {
+ if (__get_user(to->si_signo, &from->si_signo) ||
+ __get_user(to->si_uid, &from->si_uid) ||
+ __get_user(to->si_pid, &from->si_pid))
+ return -EFAULT;
+ to->q = NULL;
+ return 0;
+ }
+ q = __sigqueue_alloc(-1, current, GFP_KERNEL, 0);
+ if (!q)
+ return -ENOMEM;
+ if (copy_siginfo_from_user32(&q->info, from)) {
+ __sigqueue_free(q);
+ return -EFAULT;
+ }
+ to->q = q;
+ to->si_code = q->info.si_code;
+ to->si_signo = q->info.si_signo;
+ return 0;
+#endif
+}
+#endif
+
static int do_rt_sigqueueinfo(pid_t pid, int sig, siginfo_t *info)
{
/* Not even root can pretend to send signals from the kernel.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply related [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-15 5:25 ` Al Viro
@ 2014-02-15 14:27 ` Oleg Nesterov
-1 siblings, 0 replies; 132+ messages in thread
From: Oleg Nesterov @ 2014-02-15 14:27 UTC (permalink / raw)
To: Al Viro
Cc: Linus Torvalds, Dave Chinner, Dave Jones, Eric Sandeen,
Linux Kernel, xfs
On 02/15, Al Viro wrote:
>
> OK, _very_ preliminary patch follows. It's uglier than it has to
And I'm afraid it needs more uglifications...
> +void dismiss_siginfo(ksiginfo_t *info)
> +{
> + if (info->q)
> + __sigqueue_free(info->q);
> + info->q = NULL;
> +}
1. info->q can be already freed if SIGQUEUE_PREALLOC.
Once get_signal_to_deliver() or any other caller drops ->siglock
another thread can do sys_timer_delete()->sigqueue_free().
2. We need to move do_schedule_next_timer() from dequeue_signal()
here.
Otherwise ->q can be reused/overwritten by the next send_sigqueue()
right affter ->siglock is dropped.
Oleg.
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-15 14:27 ` Oleg Nesterov
0 siblings, 0 replies; 132+ messages in thread
From: Oleg Nesterov @ 2014-02-15 14:27 UTC (permalink / raw)
To: Al Viro; +Cc: Eric Sandeen, Linux Kernel, xfs, Dave Jones, Linus Torvalds
On 02/15, Al Viro wrote:
>
> OK, _very_ preliminary patch follows. It's uglier than it has to
And I'm afraid it needs more uglifications...
> +void dismiss_siginfo(ksiginfo_t *info)
> +{
> + if (info->q)
> + __sigqueue_free(info->q);
> + info->q = NULL;
> +}
1. info->q can be already freed if SIGQUEUE_PREALLOC.
Once get_signal_to_deliver() or any other caller drops ->siglock
another thread can do sys_timer_delete()->sigqueue_free().
2. We need to move do_schedule_next_timer() from dequeue_signal()
here.
Otherwise ->q can be reused/overwritten by the next send_sigqueue()
right affter ->siglock is dropped.
Oleg.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-14 16:19 ` Christoph Hellwig
@ 2014-02-15 14:46 ` Oleg Nesterov
-1 siblings, 0 replies; 132+ messages in thread
From: Oleg Nesterov @ 2014-02-15 14:46 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Al Viro, Linus Torvalds, Dave Jones, Eric Sandeen, Linux Kernel, xfs
On 02/14, Christoph Hellwig wrote:
>
> Might aswell stick the discmiss into what was dequeue_signal_lock().
> Which at that point should get a saner name (maybe thread_dequeue_signal ?)
> and lose all argument except maybe task_struct
No, task_struct argument should die, I think. It is misleading.
spin_lock(tsk->sighand->siglock) is simply wrong unless tsk == current.
And dequeue_signal() assumes that tsk == current too, otherwise
recalc_sigpending() is wrong.
Oleg.
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-15 14:46 ` Oleg Nesterov
0 siblings, 0 replies; 132+ messages in thread
From: Oleg Nesterov @ 2014-02-15 14:46 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Eric Sandeen, Linux Kernel, xfs, Al Viro, Dave Jones, Linus Torvalds
On 02/14, Christoph Hellwig wrote:
>
> Might aswell stick the discmiss into what was dequeue_signal_lock().
> Which at that point should get a saner name (maybe thread_dequeue_signal ?)
> and lose all argument except maybe task_struct
No, task_struct argument should die, I think. It is misleading.
spin_lock(tsk->sighand->siglock) is simply wrong unless tsk == current.
And dequeue_signal() assumes that tsk == current too, otherwise
recalc_sigpending() is wrong.
Oleg.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-15 14:27 ` Oleg Nesterov
@ 2014-02-15 15:22 ` Al Viro
-1 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-15 15:22 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Linus Torvalds, Dave Chinner, Dave Jones, Eric Sandeen,
Linux Kernel, xfs
On Sat, Feb 15, 2014 at 03:27:00PM +0100, Oleg Nesterov wrote:
> 1. info->q can be already freed if SIGQUEUE_PREALLOC.
>
> Once get_signal_to_deliver() or any other caller drops ->siglock
> another thread can do sys_timer_delete()->sigqueue_free().
How the devil would it find the sucker? It's off the list already.
> 2. We need to move do_schedule_next_timer() from dequeue_signal()
> here.
>
> Otherwise ->q can be reused/overwritten by the next send_sigqueue()
> right affter ->siglock is dropped.
Ditto. We rip them out of queue on collect_signal(); the only thing we do
not do is actual __sigqueue_free().
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-15 15:22 ` Al Viro
0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-15 15:22 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: Eric Sandeen, Linux Kernel, xfs, Dave Jones, Linus Torvalds
On Sat, Feb 15, 2014 at 03:27:00PM +0100, Oleg Nesterov wrote:
> 1. info->q can be already freed if SIGQUEUE_PREALLOC.
>
> Once get_signal_to_deliver() or any other caller drops ->siglock
> another thread can do sys_timer_delete()->sigqueue_free().
How the devil would it find the sucker? It's off the list already.
> 2. We need to move do_schedule_next_timer() from dequeue_signal()
> here.
>
> Otherwise ->q can be reused/overwritten by the next send_sigqueue()
> right affter ->siglock is dropped.
Ditto. We rip them out of queue on collect_signal(); the only thing we do
not do is actual __sigqueue_free().
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-15 15:22 ` Al Viro
@ 2014-02-15 15:33 ` Oleg Nesterov
-1 siblings, 0 replies; 132+ messages in thread
From: Oleg Nesterov @ 2014-02-15 15:33 UTC (permalink / raw)
To: Al Viro
Cc: Linus Torvalds, Dave Chinner, Dave Jones, Eric Sandeen,
Linux Kernel, xfs
On 02/15, Al Viro wrote:
>
> On Sat, Feb 15, 2014 at 03:27:00PM +0100, Oleg Nesterov wrote:
>
> > 1. info->q can be already freed if SIGQUEUE_PREALLOC.
> >
> > Once get_signal_to_deliver() or any other caller drops ->siglock
> > another thread can do sys_timer_delete()->sigqueue_free().
>
> How the devil would it find the sucker?
It simply frees the SIGQUEUE_PREALLOC sigqueue, k_itimer->sigq.
> It's off the list already.
Exactly, list_empty(q->list) == T. So release_posix_timer()->sigqueue_free()
assumes we can safely free it.
> > 2. We need to move do_schedule_next_timer() from dequeue_signal()
> > here.
> >
> > Otherwise ->q can be reused/overwritten by the next send_sigqueue()
> > right affter ->siglock is dropped.
>
> Ditto. We rip them out of queue on collect_signal();
Yes, and dequeue_signal()->do_schedule_next_timer() can trigger another
send_sigqueue() which uses the same SIGQUEUE_PREALLOC sigqueue once we
drop ->siglock.
This is not that bad, but at least ->si_overrun can be overwritten
before __setup_rt_frame()->copy_siginfo_to_user().
Oleg.
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-15 15:33 ` Oleg Nesterov
0 siblings, 0 replies; 132+ messages in thread
From: Oleg Nesterov @ 2014-02-15 15:33 UTC (permalink / raw)
To: Al Viro; +Cc: Eric Sandeen, Linux Kernel, xfs, Dave Jones, Linus Torvalds
On 02/15, Al Viro wrote:
>
> On Sat, Feb 15, 2014 at 03:27:00PM +0100, Oleg Nesterov wrote:
>
> > 1. info->q can be already freed if SIGQUEUE_PREALLOC.
> >
> > Once get_signal_to_deliver() or any other caller drops ->siglock
> > another thread can do sys_timer_delete()->sigqueue_free().
>
> How the devil would it find the sucker?
It simply frees the SIGQUEUE_PREALLOC sigqueue, k_itimer->sigq.
> It's off the list already.
Exactly, list_empty(q->list) == T. So release_posix_timer()->sigqueue_free()
assumes we can safely free it.
> > 2. We need to move do_schedule_next_timer() from dequeue_signal()
> > here.
> >
> > Otherwise ->q can be reused/overwritten by the next send_sigqueue()
> > right affter ->siglock is dropped.
>
> Ditto. We rip them out of queue on collect_signal();
Yes, and dequeue_signal()->do_schedule_next_timer() can trigger another
send_sigqueue() which uses the same SIGQUEUE_PREALLOC sigqueue once we
drop ->siglock.
This is not that bad, but at least ->si_overrun can be overwritten
before __setup_rt_frame()->copy_siginfo_to_user().
Oleg.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-15 15:22 ` Al Viro
@ 2014-02-15 15:36 ` Al Viro
-1 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-15 15:36 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Linus Torvalds, Dave Chinner, Dave Jones, Eric Sandeen,
Linux Kernel, xfs
On Sat, Feb 15, 2014 at 03:22:51PM +0000, Al Viro wrote:
> On Sat, Feb 15, 2014 at 03:27:00PM +0100, Oleg Nesterov wrote:
>
> > 1. info->q can be already freed if SIGQUEUE_PREALLOC.
> >
> > Once get_signal_to_deliver() or any other caller drops ->siglock
> > another thread can do sys_timer_delete()->sigqueue_free().
>
> How the devil would it find the sucker? It's off the list already.
Ouch... I think I see what you mean. Let me see if I got it right:
timer->sigq is *not* freed by collect_signal(); it's done by
release_posix_timer() instead, under siglock. Frankly, this
/*
* If it is queued it will be freed when dequeued,
* like the "regular" sigqueue.
*/
if (!list_empty(&q->list))
q = NULL;
in sigqueue_free() smells like it's asking for races. Sigh...
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-15 15:36 ` Al Viro
0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-15 15:36 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: Eric Sandeen, Linux Kernel, xfs, Dave Jones, Linus Torvalds
On Sat, Feb 15, 2014 at 03:22:51PM +0000, Al Viro wrote:
> On Sat, Feb 15, 2014 at 03:27:00PM +0100, Oleg Nesterov wrote:
>
> > 1. info->q can be already freed if SIGQUEUE_PREALLOC.
> >
> > Once get_signal_to_deliver() or any other caller drops ->siglock
> > another thread can do sys_timer_delete()->sigqueue_free().
>
> How the devil would it find the sucker? It's off the list already.
Ouch... I think I see what you mean. Let me see if I got it right:
timer->sigq is *not* freed by collect_signal(); it's done by
release_posix_timer() instead, under siglock. Frankly, this
/*
* If it is queued it will be freed when dequeued,
* like the "regular" sigqueue.
*/
if (!list_empty(&q->list))
q = NULL;
in sigqueue_free() smells like it's asking for races. Sigh...
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-15 15:36 ` Al Viro
@ 2014-02-15 15:58 ` Al Viro
-1 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-15 15:58 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Linus Torvalds, Dave Chinner, Dave Jones, Eric Sandeen,
Linux Kernel, xfs
On Sat, Feb 15, 2014 at 03:36:31PM +0000, Al Viro wrote:
> On Sat, Feb 15, 2014 at 03:22:51PM +0000, Al Viro wrote:
> > On Sat, Feb 15, 2014 at 03:27:00PM +0100, Oleg Nesterov wrote:
> >
> > > 1. info->q can be already freed if SIGQUEUE_PREALLOC.
> > >
> > > Once get_signal_to_deliver() or any other caller drops ->siglock
> > > another thread can do sys_timer_delete()->sigqueue_free().
> >
> > How the devil would it find the sucker? It's off the list already.
>
> Ouch... I think I see what you mean. Let me see if I got it right:
> timer->sigq is *not* freed by collect_signal(); it's done by
> release_posix_timer() instead, under siglock. Frankly, this
> /*
> * If it is queued it will be freed when dequeued,
> * like the "regular" sigqueue.
> */
> if (!list_empty(&q->list))
> q = NULL;
> in sigqueue_free() smells like it's asking for races. Sigh...
So basically we want a different condition for "can we just go ahead and
free that sucker", right? Instead of "it's on the list, shan't free it"
it ought to be something like "it's on the list or it is referenced by
ksiginfo". Locking will be interesting, though... ;-/
BTW, I really wonder how does that stuff interact with PTRACE_SETSIGINFO.
What happens if tracer does PTRACE_GETSIGINFO, changes ->si_signo to
something blocked, shoves it back with PTRACE_SETSIGINFO and does
PTRACE_CONT with that new signal number? Would we get two sigqueue instances
with the same ->si_tid, one of them matching the timer->sigq and another
- not?
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-15 15:58 ` Al Viro
0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-15 15:58 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: Eric Sandeen, Linux Kernel, xfs, Dave Jones, Linus Torvalds
On Sat, Feb 15, 2014 at 03:36:31PM +0000, Al Viro wrote:
> On Sat, Feb 15, 2014 at 03:22:51PM +0000, Al Viro wrote:
> > On Sat, Feb 15, 2014 at 03:27:00PM +0100, Oleg Nesterov wrote:
> >
> > > 1. info->q can be already freed if SIGQUEUE_PREALLOC.
> > >
> > > Once get_signal_to_deliver() or any other caller drops ->siglock
> > > another thread can do sys_timer_delete()->sigqueue_free().
> >
> > How the devil would it find the sucker? It's off the list already.
>
> Ouch... I think I see what you mean. Let me see if I got it right:
> timer->sigq is *not* freed by collect_signal(); it's done by
> release_posix_timer() instead, under siglock. Frankly, this
> /*
> * If it is queued it will be freed when dequeued,
> * like the "regular" sigqueue.
> */
> if (!list_empty(&q->list))
> q = NULL;
> in sigqueue_free() smells like it's asking for races. Sigh...
So basically we want a different condition for "can we just go ahead and
free that sucker", right? Instead of "it's on the list, shan't free it"
it ought to be something like "it's on the list or it is referenced by
ksiginfo". Locking will be interesting, though... ;-/
BTW, I really wonder how does that stuff interact with PTRACE_SETSIGINFO.
What happens if tracer does PTRACE_GETSIGINFO, changes ->si_signo to
something blocked, shoves it back with PTRACE_SETSIGINFO and does
PTRACE_CONT with that new signal number? Would we get two sigqueue instances
with the same ->si_tid, one of them matching the timer->sigq and another
- not?
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-15 15:58 ` Al Viro
@ 2014-02-15 16:59 ` Al Viro
-1 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-15 16:59 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Linus Torvalds, Dave Chinner, Dave Jones, Eric Sandeen,
Linux Kernel, xfs
On Sat, Feb 15, 2014 at 03:58:38PM +0000, Al Viro wrote:
> BTW, I really wonder how does that stuff interact with PTRACE_SETSIGINFO.
> What happens if tracer does PTRACE_GETSIGINFO, changes ->si_signo to
> something blocked, shoves it back with PTRACE_SETSIGINFO and does
> PTRACE_CONT with that new signal number? Would we get two sigqueue instances
> with the same ->si_tid, one of them matching the timer->sigq and another
> - not?
I wonder if it would be simpler to use the pointer *only* for si_code < 0
case. It still gives us ksiginfo_t much smaller than siginfo_t, avoids
all the mess with timers and AFAICS results in less intrusive patch.
IOW, the split between "we know what that sucker is" and "completely
opaque shit the userland has given us".
I'll try to put together something along those lines and see how well does
that work...
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-15 16:59 ` Al Viro
0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-15 16:59 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: Eric Sandeen, Linux Kernel, xfs, Dave Jones, Linus Torvalds
On Sat, Feb 15, 2014 at 03:58:38PM +0000, Al Viro wrote:
> BTW, I really wonder how does that stuff interact with PTRACE_SETSIGINFO.
> What happens if tracer does PTRACE_GETSIGINFO, changes ->si_signo to
> something blocked, shoves it back with PTRACE_SETSIGINFO and does
> PTRACE_CONT with that new signal number? Would we get two sigqueue instances
> with the same ->si_tid, one of them matching the timer->sigq and another
> - not?
I wonder if it would be simpler to use the pointer *only* for si_code < 0
case. It still gives us ksiginfo_t much smaller than siginfo_t, avoids
all the mess with timers and AFAICS results in less intrusive patch.
IOW, the split between "we know what that sucker is" and "completely
opaque shit the userland has given us".
I'll try to put together something along those lines and see how well does
that work...
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-15 15:58 ` Al Viro
@ 2014-02-15 17:43 ` Oleg Nesterov
-1 siblings, 0 replies; 132+ messages in thread
From: Oleg Nesterov @ 2014-02-15 17:43 UTC (permalink / raw)
To: Al Viro
Cc: Linus Torvalds, Dave Chinner, Dave Jones, Eric Sandeen,
Linux Kernel, xfs
On 02/15, Al Viro wrote:
>
> > Ouch... I think I see what you mean. Let me see if I got it right:
> > timer->sigq is *not* freed by collect_signal(); it's done by
> > release_posix_timer() instead, under siglock. Frankly, this
> > /*
> > * If it is queued it will be freed when dequeued,
> > * like the "regular" sigqueue.
> > */
> > if (!list_empty(&q->list))
> > q = NULL;
> > in sigqueue_free() smells like it's asking for races. Sigh...
This is protected by ->siglock, should be safe...
> So basically we want a different condition for "can we just go ahead and
> free that sucker", right? Instead of "it's on the list, shan't free it"
> it ought to be something like "it's on the list or it is referenced by
> ksiginfo". Locking will be interesting, though... ;-/
I guess yes... send_sigqueue() checks list_empty() too, probably nobody else.
> BTW, I really wonder how does that stuff interact with PTRACE_SETSIGINFO.
> What happens if tracer does PTRACE_GETSIGINFO, changes ->si_signo to
> something blocked, shoves it back with PTRACE_SETSIGINFO and does
> PTRACE_CONT with that new signal number? Would we get two sigqueue instances
> with the same ->si_tid, one of them matching the timer->sigq and another
> - not?
Or the task sends a SI_TIMER info to itself via sys_rt_sigqueueinfo().
Afaics, nothing really bad can happen, I mean the kernel should not
crash or something like this. do_schedule_next_timer() can be fooled,
but at least lock_timer() can only succeed if this process actually
has a timer with the same timer_id. This sigqueue != timer->sigq, but
I think this doesn't matter, posix_timer_event() will use timer->sigq
anyway.
Oleg.
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-15 17:43 ` Oleg Nesterov
0 siblings, 0 replies; 132+ messages in thread
From: Oleg Nesterov @ 2014-02-15 17:43 UTC (permalink / raw)
To: Al Viro; +Cc: Eric Sandeen, Linux Kernel, xfs, Dave Jones, Linus Torvalds
On 02/15, Al Viro wrote:
>
> > Ouch... I think I see what you mean. Let me see if I got it right:
> > timer->sigq is *not* freed by collect_signal(); it's done by
> > release_posix_timer() instead, under siglock. Frankly, this
> > /*
> > * If it is queued it will be freed when dequeued,
> > * like the "regular" sigqueue.
> > */
> > if (!list_empty(&q->list))
> > q = NULL;
> > in sigqueue_free() smells like it's asking for races. Sigh...
This is protected by ->siglock, should be safe...
> So basically we want a different condition for "can we just go ahead and
> free that sucker", right? Instead of "it's on the list, shan't free it"
> it ought to be something like "it's on the list or it is referenced by
> ksiginfo". Locking will be interesting, though... ;-/
I guess yes... send_sigqueue() checks list_empty() too, probably nobody else.
> BTW, I really wonder how does that stuff interact with PTRACE_SETSIGINFO.
> What happens if tracer does PTRACE_GETSIGINFO, changes ->si_signo to
> something blocked, shoves it back with PTRACE_SETSIGINFO and does
> PTRACE_CONT with that new signal number? Would we get two sigqueue instances
> with the same ->si_tid, one of them matching the timer->sigq and another
> - not?
Or the task sends a SI_TIMER info to itself via sys_rt_sigqueueinfo().
Afaics, nothing really bad can happen, I mean the kernel should not
crash or something like this. do_schedule_next_timer() can be fooled,
but at least lock_timer() can only succeed if this process actually
has a timer with the same timer_id. This sigqueue != timer->sigq, but
I think this doesn't matter, posix_timer_event() will use timer->sigq
anyway.
Oleg.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-15 17:43 ` Oleg Nesterov
@ 2014-02-15 18:05 ` Al Viro
-1 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-15 18:05 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Linus Torvalds, Dave Chinner, Dave Jones, Eric Sandeen,
Linux Kernel, xfs
On Sat, Feb 15, 2014 at 06:43:45PM +0100, Oleg Nesterov wrote:
> > So basically we want a different condition for "can we just go ahead and
> > free that sucker", right? Instead of "it's on the list, shan't free it"
> > it ought to be something like "it's on the list or it is referenced by
> > ksiginfo". Locking will be interesting, though... ;-/
>
> I guess yes... send_sigqueue() checks list_empty() too, probably nobody else.
The trouble being, we might end up with
Q picked by collect_signal and and stuff into ksiginfo
Q resubmitted by timer code
Q picked by *another* thread into its ksiginfo
the first thread finally done with signal
and at that point we still have a reference in the second thread's ksiginfo.
Hell knows - my first reflex in that kind of situation is to replace
that flag with refcount, so that timer code would hold a reference from
timer_create(2) to timer_delete(2), send_sigqueue() would bump it and
dismiss_siginfo() - drop the sucker. But that means either grabbing
siglock in dismiss_siginfo() or making the counter atomic; either way
it's a cacheline ping-pong. Atomic counter is less painful in that respect -
it would be right next to the list, so we dirty that cacheline anyway...
I'm still trying another approach (slightly bigger ksiginfo used to store
all variants with si_code >= 0), but it has messiness of its own; we'll
see how it goes...
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-15 18:05 ` Al Viro
0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-15 18:05 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: Eric Sandeen, Linux Kernel, xfs, Dave Jones, Linus Torvalds
On Sat, Feb 15, 2014 at 06:43:45PM +0100, Oleg Nesterov wrote:
> > So basically we want a different condition for "can we just go ahead and
> > free that sucker", right? Instead of "it's on the list, shan't free it"
> > it ought to be something like "it's on the list or it is referenced by
> > ksiginfo". Locking will be interesting, though... ;-/
>
> I guess yes... send_sigqueue() checks list_empty() too, probably nobody else.
The trouble being, we might end up with
Q picked by collect_signal and and stuff into ksiginfo
Q resubmitted by timer code
Q picked by *another* thread into its ksiginfo
the first thread finally done with signal
and at that point we still have a reference in the second thread's ksiginfo.
Hell knows - my first reflex in that kind of situation is to replace
that flag with refcount, so that timer code would hold a reference from
timer_create(2) to timer_delete(2), send_sigqueue() would bump it and
dismiss_siginfo() - drop the sucker. But that means either grabbing
siglock in dismiss_siginfo() or making the counter atomic; either way
it's a cacheline ping-pong. Atomic counter is less painful in that respect -
it would be right next to the list, so we dirty that cacheline anyway...
I'm still trying another approach (slightly bigger ksiginfo used to store
all variants with si_code >= 0), but it has messiness of its own; we'll
see how it goes...
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-15 18:05 ` Al Viro
@ 2014-02-15 18:45 ` Oleg Nesterov
-1 siblings, 0 replies; 132+ messages in thread
From: Oleg Nesterov @ 2014-02-15 18:45 UTC (permalink / raw)
To: Al Viro
Cc: Linus Torvalds, Dave Chinner, Dave Jones, Eric Sandeen,
Linux Kernel, xfs
On 02/15, Al Viro wrote:
>
> On Sat, Feb 15, 2014 at 06:43:45PM +0100, Oleg Nesterov wrote:
> > > So basically we want a different condition for "can we just go ahead and
> > > free that sucker", right? Instead of "it's on the list, shan't free it"
> > > it ought to be something like "it's on the list or it is referenced by
> > > ksiginfo". Locking will be interesting, though... ;-/
> >
> > I guess yes... send_sigqueue() checks list_empty() too, probably nobody else.
>
> The trouble being, we might end up with
> Q picked by collect_signal and and stuff into ksiginfo
> Q resubmitted by timer code
In this case the timer code should simply inc ->si_overrun and do nothing.
IOW, list_empty() should be turned into is_queued(), and is_queued()
should be true until dismiss_siginfo() which should also do
do_schedule_next_timer(). I think.
Oleg.
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-15 18:45 ` Oleg Nesterov
0 siblings, 0 replies; 132+ messages in thread
From: Oleg Nesterov @ 2014-02-15 18:45 UTC (permalink / raw)
To: Al Viro; +Cc: Eric Sandeen, Linux Kernel, xfs, Dave Jones, Linus Torvalds
On 02/15, Al Viro wrote:
>
> On Sat, Feb 15, 2014 at 06:43:45PM +0100, Oleg Nesterov wrote:
> > > So basically we want a different condition for "can we just go ahead and
> > > free that sucker", right? Instead of "it's on the list, shan't free it"
> > > it ought to be something like "it's on the list or it is referenced by
> > > ksiginfo". Locking will be interesting, though... ;-/
> >
> > I guess yes... send_sigqueue() checks list_empty() too, probably nobody else.
>
> The trouble being, we might end up with
> Q picked by collect_signal and and stuff into ksiginfo
> Q resubmitted by timer code
In this case the timer code should simply inc ->si_overrun and do nothing.
IOW, list_empty() should be turned into is_queued(), and is_queued()
should be true until dismiss_siginfo() which should also do
do_schedule_next_timer(). I think.
Oleg.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-14 16:01 ` Dave Jones
@ 2014-02-15 22:23 ` Dave Chinner
-1 siblings, 0 replies; 132+ messages in thread
From: Dave Chinner @ 2014-02-15 22:23 UTC (permalink / raw)
To: Dave Jones, Linus Torvalds, Al Viro, Eric Sandeen, Linux Kernel, xfs
On Fri, Feb 14, 2014 at 11:01:23AM -0500, Dave Jones wrote:
> On Fri, Feb 14, 2014 at 11:24:27AM +1100, Dave Chinner wrote:
>
> > > I can fix this one easily - we already have a workqueue for doing
> > > async log pushes (will split the stack between xlog_cil_force_lsn
> > > and xlog_cil_push), but the reason we haven't used it for synchronous
> > > log forces is that screws up fsync performance on CFQ. We don't
> > > recommend CFQ with XFS anyway, so I think I'll make this change
> > > anyway.
> >
> > Dave, the patch below should chop off the stack usage from
> > xfs_log_force_lsn() issuing IO by deferring it to the CIL workqueue.
> > Can you given this a run?
>
> Looks like it's survived an overnight run..
Great.
One thing that has been puzzling me is why I'm seeing stack usage
reported that is way above what we declare locally on the stack.
e.g.
29) 2048 224 xfs_da_grow_inode_int+0xbb/0x340
30) 1824 96 xfs_dir2_grow_inode+0x63/0x110
31) 1728 208 xfs_dir2_sf_to_block+0xe7/0x5e0
32) 1520 144 xfs_dir2_sf_addname+0x115/0x5c0
33) 1376 96 xfs_dir_createname+0x164/0x1a0
34) 1280 224 xfs_create+0x536/0x660
35) 1056 128 xfs_vn_mknod+0xc8/0x1d0
I pulled 128 bytes out of xfs_dir_createname by allocating the
xfs_da_args structure, but I still couldn't reconcile the amount of
stack use being reported with the amount used by locally declared
variables (even considering in-lined leaf functions). For example:
Locally
Declared Used function
88 224 xfs_da_grow_inode_int
32 96 xfs_dir2_grow_inode
168 208 xfs_dir2_sf_to_block
56 144 xfs_dir2_sf_addname
16 96 xfs_dir_createname
120 224 xfs_create
52 128 xfs_vn_mknod
There's a pretty massive difference between the actual stack usage
of the local variables and the amount of stack being used by the
compiled code.
What it appears to be is that the compiler is pushing 6-10 registers
to the stack on every function call. So a function that only has 3
local variables and does very little but allocate a structure and
call other functions saves an 6 registers to the stack before it
starts:
Dump of assembler code for function xfs_dir_createname:
214 {
0xffffffff814d7380 <+0>: callq 0xffffffff81cf0940
0xffffffff814d7385 <+5>: push %rbp
0xffffffff814d7386 <+6>: mov %rsp,%rbp
0xffffffff814d7389 <+9>: sub $0x50,%rsp
0xffffffff814d738d <+13>: mov %rbx,-0x28(%rbp)
0xffffffff814d7391 <+17>: mov %rdi,%rbx
0xffffffff814d7394 <+20>: mov %r12,-0x20(%rbp)
0xffffffff814d7398 <+24>: mov %rcx,%r12
0xffffffff814d739b <+27>: mov %r13,-0x18(%rbp)
0xffffffff814d739f <+31>: mov %rsi,%r13
0xffffffff814d73a5 <+37>: mov %r14,-0x10(%rbp)
0xffffffff814d73a9 <+41>: mov %rdx,%r14
0xffffffff814d73ac <+44>: mov %r15,-0x8(%rbp)
0xffffffff814d73b0 <+48>: mov %r8,%r15
0xffffffff814d73b7 <+55>: mov %r9,-0x48(%rbp)
.....
If this is typical across the call chain (appears to be from my
quick survey) then we are averaging 40-50 bytes of stack per
call for saved registers. That's a lot of stack space we can't
directly control the usage of, especially when we are talking about
call chains that can get 50+ functions deep...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-15 22:23 ` Dave Chinner
0 siblings, 0 replies; 132+ messages in thread
From: Dave Chinner @ 2014-02-15 22:23 UTC (permalink / raw)
To: Dave Jones, Linus Torvalds, Al Viro, Eric Sandeen, Linux Kernel, xfs
On Fri, Feb 14, 2014 at 11:01:23AM -0500, Dave Jones wrote:
> On Fri, Feb 14, 2014 at 11:24:27AM +1100, Dave Chinner wrote:
>
> > > I can fix this one easily - we already have a workqueue for doing
> > > async log pushes (will split the stack between xlog_cil_force_lsn
> > > and xlog_cil_push), but the reason we haven't used it for synchronous
> > > log forces is that screws up fsync performance on CFQ. We don't
> > > recommend CFQ with XFS anyway, so I think I'll make this change
> > > anyway.
> >
> > Dave, the patch below should chop off the stack usage from
> > xfs_log_force_lsn() issuing IO by deferring it to the CIL workqueue.
> > Can you given this a run?
>
> Looks like it's survived an overnight run..
Great.
One thing that has been puzzling me is why I'm seeing stack usage
reported that is way above what we declare locally on the stack.
e.g.
29) 2048 224 xfs_da_grow_inode_int+0xbb/0x340
30) 1824 96 xfs_dir2_grow_inode+0x63/0x110
31) 1728 208 xfs_dir2_sf_to_block+0xe7/0x5e0
32) 1520 144 xfs_dir2_sf_addname+0x115/0x5c0
33) 1376 96 xfs_dir_createname+0x164/0x1a0
34) 1280 224 xfs_create+0x536/0x660
35) 1056 128 xfs_vn_mknod+0xc8/0x1d0
I pulled 128 bytes out of xfs_dir_createname by allocating the
xfs_da_args structure, but I still couldn't reconcile the amount of
stack use being reported with the amount used by locally declared
variables (even considering in-lined leaf functions). For example:
Locally
Declared Used function
88 224 xfs_da_grow_inode_int
32 96 xfs_dir2_grow_inode
168 208 xfs_dir2_sf_to_block
56 144 xfs_dir2_sf_addname
16 96 xfs_dir_createname
120 224 xfs_create
52 128 xfs_vn_mknod
There's a pretty massive difference between the actual stack usage
of the local variables and the amount of stack being used by the
compiled code.
What it appears to be is that the compiler is pushing 6-10 registers
to the stack on every function call. So a function that only has 3
local variables and does very little but allocate a structure and
call other functions saves an 6 registers to the stack before it
starts:
Dump of assembler code for function xfs_dir_createname:
214 {
0xffffffff814d7380 <+0>: callq 0xffffffff81cf0940
0xffffffff814d7385 <+5>: push %rbp
0xffffffff814d7386 <+6>: mov %rsp,%rbp
0xffffffff814d7389 <+9>: sub $0x50,%rsp
0xffffffff814d738d <+13>: mov %rbx,-0x28(%rbp)
0xffffffff814d7391 <+17>: mov %rdi,%rbx
0xffffffff814d7394 <+20>: mov %r12,-0x20(%rbp)
0xffffffff814d7398 <+24>: mov %rcx,%r12
0xffffffff814d739b <+27>: mov %r13,-0x18(%rbp)
0xffffffff814d739f <+31>: mov %rsi,%r13
0xffffffff814d73a5 <+37>: mov %r14,-0x10(%rbp)
0xffffffff814d73a9 <+41>: mov %rdx,%r14
0xffffffff814d73ac <+44>: mov %r15,-0x8(%rbp)
0xffffffff814d73b0 <+48>: mov %r8,%r15
0xffffffff814d73b7 <+55>: mov %r9,-0x48(%rbp)
.....
If this is typical across the call chain (appears to be from my
quick survey) then we are averaging 40-50 bytes of stack per
call for saved registers. That's a lot of stack space we can't
directly control the usage of, especially when we are talking about
call chains that can get 50+ functions deep...
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] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-15 22:23 ` Dave Chinner
@ 2014-02-15 22:28 ` Dave Jones
-1 siblings, 0 replies; 132+ messages in thread
From: Dave Jones @ 2014-02-15 22:28 UTC (permalink / raw)
To: Dave Chinner; +Cc: Linus Torvalds, Al Viro, Eric Sandeen, Linux Kernel, xfs
On Sun, Feb 16, 2014 at 09:23:56AM +1100, Dave Chinner wrote:
> There's a pretty massive difference between the actual stack usage
> of the local variables and the amount of stack being used by the
> compiled code.
>
> What it appears to be is that the compiler is pushing 6-10 registers
> to the stack on every function call. So a function that only has 3
> local variables and does very little but allocate a structure and
> call other functions saves an 6 registers to the stack before it
> starts:
I've got a shitload of debug options enabled, which may explain it.
Or perhaps that new STACK_PROTECTOR_STRONG stuff ?
Dave
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-15 22:28 ` Dave Jones
0 siblings, 0 replies; 132+ messages in thread
From: Dave Jones @ 2014-02-15 22:28 UTC (permalink / raw)
To: Dave Chinner; +Cc: Eric Sandeen, xfs, Linus Torvalds, Al Viro, Linux Kernel
On Sun, Feb 16, 2014 at 09:23:56AM +1100, Dave Chinner wrote:
> There's a pretty massive difference between the actual stack usage
> of the local variables and the amount of stack being used by the
> compiled code.
>
> What it appears to be is that the compiler is pushing 6-10 registers
> to the stack on every function call. So a function that only has 3
> local variables and does very little but allocate a structure and
> call other functions saves an 6 registers to the stack before it
> starts:
I've got a shitload of debug options enabled, which may explain it.
Or perhaps that new STACK_PROTECTOR_STRONG stuff ?
Dave
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-15 22:28 ` Dave Jones
@ 2014-02-15 22:43 ` Linus Torvalds
-1 siblings, 0 replies; 132+ messages in thread
From: Linus Torvalds @ 2014-02-15 22:43 UTC (permalink / raw)
To: Dave Jones, Dave Chinner, Linus Torvalds, Al Viro, Eric Sandeen,
Linux Kernel, xfs
On Sat, Feb 15, 2014 at 2:28 PM, Dave Jones <davej@redhat.com> wrote:
>
> I've got a shitload of debug options enabled, which may explain it.
> Or perhaps that new STACK_PROTECTOR_STRONG stuff ?
Well, a lot of it is just the callee-saved registers. The compiler
will tend to preferentially allocate registers in the callee-trashed
registers, but if the function isn't a leaf function, any registers
that are live around a function call will have to be saved somewhere -
either explicitly around the function call, or - more likely - in
callee-saved registers that then get saved in the prologue/epilogue of
the function. And this will happen even in leaf functions when there
is enough register pressure that the callee-trashed registers aren't
sufficient (which is pretty common).
So saving 5-6 registers on the stack (in addition to any actual stack
frame) is pretty much the norm for anything but the very simplest
cases.
But yeah, I'm sure some config options make it worse.
STACK_PROTECTOR_STRONG could easily be one of those.
Linus
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-15 22:43 ` Linus Torvalds
0 siblings, 0 replies; 132+ messages in thread
From: Linus Torvalds @ 2014-02-15 22:43 UTC (permalink / raw)
To: Dave Jones, Dave Chinner, Linus Torvalds, Al Viro, Eric Sandeen,
Linux Kernel, xfs
On Sat, Feb 15, 2014 at 2:28 PM, Dave Jones <davej@redhat.com> wrote:
>
> I've got a shitload of debug options enabled, which may explain it.
> Or perhaps that new STACK_PROTECTOR_STRONG stuff ?
Well, a lot of it is just the callee-saved registers. The compiler
will tend to preferentially allocate registers in the callee-trashed
registers, but if the function isn't a leaf function, any registers
that are live around a function call will have to be saved somewhere -
either explicitly around the function call, or - more likely - in
callee-saved registers that then get saved in the prologue/epilogue of
the function. And this will happen even in leaf functions when there
is enough register pressure that the callee-trashed registers aren't
sufficient (which is pretty common).
So saving 5-6 registers on the stack (in addition to any actual stack
frame) is pretty much the norm for anything but the very simplest
cases.
But yeah, I'm sure some config options make it worse.
STACK_PROTECTOR_STRONG could easily be one of those.
Linus
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-14 0:24 ` Dave Chinner
(?)
@ 2014-02-15 23:50 ` Linus Torvalds
-1 siblings, 0 replies; 132+ messages in thread
From: Linus Torvalds @ 2014-02-15 23:50 UTC (permalink / raw)
To: Dave Chinner, linux-mm
Cc: Al Viro, Dave Jones, Eric Sandeen, Linux Kernel, xfs
[ Added linux-mm to the participants list ]
On Thu, Feb 13, 2014 at 4:24 PM, Dave Chinner <david@fromorbit.com> wrote:
>
> Dave, the patch below should chop off the stack usage from
> xfs_log_force_lsn() issuing IO by deferring it to the CIL workqueue.
> Can you given this a run?
Ok, so DaveJ confirmed that DaveC's patch fixes his issue (damn,
people, your parents were some seriously boring people, were they not?
We've got too many Dave's around), but DaveC earlier pointed out that
pretty much any memory allocation path can end up using 3kB of stack
even without XFS being involved.
Which does bring up the question whether we should look (once more) at
the VM direct-reclaim path, and try to avoid GFP_FS/IO direct
reclaim..
Direct reclaim historically used to be an important throttling
mechanism, and I used to not be a fan of trying to avoid direct
reclaim. But the stack depth issue really looks to be pretty bad, and
I think we've gotten better at throttling explicitly, so..
I *think* we already limit filesystem writeback to just kswapd (in
shrink_page_list()), but DaveC posted a backtrace that goes through
do_try_to_free_pages() to shrink_slab(), and through there to the
filesystem and then IO. That looked like a disaster.
And that's because (if I read things right) shrink_page_list() limits
filesystem page writeback to kswapd, but not swap pages. Which I think
probably made more sense back in the days than it does now (I
certainly *hope* that swapping is less important today than it was,
say, ten years ago)
So I'm wondering whether we should remove that page_is_file_cache()
check from shrink_page_list()?
And then there is that whole shrink_slab() case...
Linus
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-15 23:50 ` Linus Torvalds
0 siblings, 0 replies; 132+ messages in thread
From: Linus Torvalds @ 2014-02-15 23:50 UTC (permalink / raw)
To: Dave Chinner, linux-mm
Cc: Dave Jones, xfs, Eric Sandeen, Al Viro, Linux Kernel
[ Added linux-mm to the participants list ]
On Thu, Feb 13, 2014 at 4:24 PM, Dave Chinner <david@fromorbit.com> wrote:
>
> Dave, the patch below should chop off the stack usage from
> xfs_log_force_lsn() issuing IO by deferring it to the CIL workqueue.
> Can you given this a run?
Ok, so DaveJ confirmed that DaveC's patch fixes his issue (damn,
people, your parents were some seriously boring people, were they not?
We've got too many Dave's around), but DaveC earlier pointed out that
pretty much any memory allocation path can end up using 3kB of stack
even without XFS being involved.
Which does bring up the question whether we should look (once more) at
the VM direct-reclaim path, and try to avoid GFP_FS/IO direct
reclaim..
Direct reclaim historically used to be an important throttling
mechanism, and I used to not be a fan of trying to avoid direct
reclaim. But the stack depth issue really looks to be pretty bad, and
I think we've gotten better at throttling explicitly, so..
I *think* we already limit filesystem writeback to just kswapd (in
shrink_page_list()), but DaveC posted a backtrace that goes through
do_try_to_free_pages() to shrink_slab(), and through there to the
filesystem and then IO. That looked like a disaster.
And that's because (if I read things right) shrink_page_list() limits
filesystem page writeback to kswapd, but not swap pages. Which I think
probably made more sense back in the days than it does now (I
certainly *hope* that swapping is less important today than it was,
say, ten years ago)
So I'm wondering whether we should remove that page_is_file_cache()
check from shrink_page_list()?
And then there is that whole shrink_slab() case...
Linus
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-15 23:50 ` Linus Torvalds
0 siblings, 0 replies; 132+ messages in thread
From: Linus Torvalds @ 2014-02-15 23:50 UTC (permalink / raw)
To: Dave Chinner, linux-mm
Cc: Al Viro, Dave Jones, Eric Sandeen, Linux Kernel, xfs
[ Added linux-mm to the participants list ]
On Thu, Feb 13, 2014 at 4:24 PM, Dave Chinner <david@fromorbit.com> wrote:
>
> Dave, the patch below should chop off the stack usage from
> xfs_log_force_lsn() issuing IO by deferring it to the CIL workqueue.
> Can you given this a run?
Ok, so DaveJ confirmed that DaveC's patch fixes his issue (damn,
people, your parents were some seriously boring people, were they not?
We've got too many Dave's around), but DaveC earlier pointed out that
pretty much any memory allocation path can end up using 3kB of stack
even without XFS being involved.
Which does bring up the question whether we should look (once more) at
the VM direct-reclaim path, and try to avoid GFP_FS/IO direct
reclaim..
Direct reclaim historically used to be an important throttling
mechanism, and I used to not be a fan of trying to avoid direct
reclaim. But the stack depth issue really looks to be pretty bad, and
I think we've gotten better at throttling explicitly, so..
I *think* we already limit filesystem writeback to just kswapd (in
shrink_page_list()), but DaveC posted a backtrace that goes through
do_try_to_free_pages() to shrink_slab(), and through there to the
filesystem and then IO. That looked like a disaster.
And that's because (if I read things right) shrink_page_list() limits
filesystem page writeback to kswapd, but not swap pages. Which I think
probably made more sense back in the days than it does now (I
certainly *hope* that swapping is less important today than it was,
say, ten years ago)
So I'm wondering whether we should remove that page_is_file_cache()
check from shrink_page_list()?
And then there is that whole shrink_slab() case...
Linus
--
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] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-15 18:45 ` Oleg Nesterov
@ 2014-02-17 16:57 ` Oleg Nesterov
-1 siblings, 0 replies; 132+ messages in thread
From: Oleg Nesterov @ 2014-02-17 16:57 UTC (permalink / raw)
To: Al Viro
Cc: Linus Torvalds, Dave Chinner, Dave Jones, Eric Sandeen,
Linux Kernel, xfs
On 02/15, Oleg Nesterov wrote:
>
> On 02/15, Al Viro wrote:
> >
> > On Sat, Feb 15, 2014 at 06:43:45PM +0100, Oleg Nesterov wrote:
> > > > So basically we want a different condition for "can we just go ahead and
> > > > free that sucker", right? Instead of "it's on the list, shan't free it"
> > > > it ought to be something like "it's on the list or it is referenced by
> > > > ksiginfo". Locking will be interesting, though... ;-/
> > >
> > > I guess yes... send_sigqueue() checks list_empty() too, probably nobody else.
> >
> > The trouble being, we might end up with
> > Q picked by collect_signal and and stuff into ksiginfo
> > Q resubmitted by timer code
>
> In this case the timer code should simply inc ->si_overrun and do nothing.
>
> IOW, list_empty() should be turned into is_queued(), and is_queued()
> should be true until dismiss_siginfo() which should also do
> do_schedule_next_timer(). I think.
No, this is even more complicated. We also need do_schedule_next_timer()
to calculate ->si_overrun we are going to report, I missed this...
Looks like, this is all is really nasty. Actually, I think siginfo on
stack is not that bad if we are going to do handle_signal() or restart,
perhaps we can do the extra kmalloc/memcpy/kfree for do_coredump().
Something like below.
Oleg.
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index 9e5de68..52f16f9 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -684,6 +684,52 @@ handle_signal(struct ksignal *ksig, struct pt_regs *regs)
test_thread_flag(TIF_IA32) ? __NR_ia32_restart_syscall : __NR_restart_syscall
#endif /* CONFIG_X86_32 */
+static noinline int process_signal(struct pt_regs *regs, siginfo_t **pinfo)
+{
+ struct ksignal ksig;
+
+ switch (get_signal(&ksig)) {
+ case SIG_DUMP:
+ *pinfo = kmalloc(sizeof(siginfo_t), GFP_KERNEL);
+ if (*pinfo)
+ copy_siginfo(*pinfo, &ksig.info);
+
+ case SIG_EXIT:
+ return ksig.info.si_signo;
+
+ default:
+ handle_signal(&ksig, regs);
+ break;
+
+ case 0:
+ /* Did we come from a system call? */
+ if (syscall_get_nr(current, regs) >= 0) {
+ /* Restart the system call - no handlers present */
+ switch (syscall_get_error(current, regs)) {
+ case -ERESTARTNOHAND:
+ case -ERESTARTSYS:
+ case -ERESTARTNOINTR:
+ regs->ax = regs->orig_ax;
+ regs->ip -= 2;
+ break;
+
+ case -ERESTART_RESTARTBLOCK:
+ regs->ax = NR_restart_syscall;
+ regs->ip -= 2;
+ break;
+ }
+ }
+
+ /*
+ * If there's no signal to deliver, we just put the saved sigmask
+ * back.
+ */
+ restore_saved_sigmask();
+ }
+
+ return 0;
+}
+
/*
* Note that 'init' is a special process: it doesn't get signals it doesn't
* want to handle. Thus you cannot kill init even with a SIGKILL even by
@@ -691,37 +737,16 @@ handle_signal(struct ksignal *ksig, struct pt_regs *regs)
*/
static void do_signal(struct pt_regs *regs)
{
- struct ksignal ksig;
+ siginfo_t *info = NULL;
+ int sig = process_signal(regs, &info);
- if (get_signal(&ksig)) {
- /* Whee! Actually deliver the signal. */
- handle_signal(&ksig, regs);
- return;
- }
-
- /* Did we come from a system call? */
- if (syscall_get_nr(current, regs) >= 0) {
- /* Restart the system call - no handlers present */
- switch (syscall_get_error(current, regs)) {
- case -ERESTARTNOHAND:
- case -ERESTARTSYS:
- case -ERESTARTNOINTR:
- regs->ax = regs->orig_ax;
- regs->ip -= 2;
- break;
-
- case -ERESTART_RESTARTBLOCK:
- regs->ax = NR_restart_syscall;
- regs->ip -= 2;
- break;
+ if (sig) {
+ if (info) {
+ do_coredump(info);
+ kfree(info);
}
+ do_group_exit(sig);
}
-
- /*
- * If there's no signal to deliver, we just put the saved sigmask
- * back.
- */
- restore_saved_sigmask();
}
/*
diff --git a/include/linux/signal.h b/include/linux/signal.h
index 2ac423b..33b5e04 100644
--- a/include/linux/signal.h
+++ b/include/linux/signal.h
@@ -285,6 +285,9 @@ struct ksignal {
int sig;
};
+#define SIG_EXIT -1
+#define SIG_DUMP -2
+
extern int get_signal_to_deliver(siginfo_t *info, struct k_sigaction *return_ka, struct pt_regs *regs, void *cookie);
extern void signal_setup_done(int failed, struct ksignal *ksig, int stepping);
extern void signal_delivered(int sig, siginfo_t *info, struct k_sigaction *ka, struct pt_regs *regs, int stepping);
@@ -299,7 +302,7 @@ extern void exit_signals(struct task_struct *tsk);
struct ksignal *p = (ksig); \
p->sig = get_signal_to_deliver(&p->info, &p->ka, \
signal_pt_regs(), NULL);\
- p->sig > 0; \
+ p->sig; \
})
extern struct kmem_cache *sighand_cachep;
diff --git a/kernel/signal.c b/kernel/signal.c
index 52f881d..8a4c4a3 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2353,22 +2353,11 @@ relock:
if (print_fatal_signals)
print_fatal_signal(info->si_signo);
proc_coredump_connector(current);
- /*
- * If it was able to dump core, this kills all
- * other threads in the group and synchronizes with
- * their demise. If we lost the race with another
- * thread getting here, it set group_exit_code
- * first and our do_group_exit call below will use
- * that value and ignore the one we pass it.
- */
- do_coredump(info);
+ return SIG_DUMP;
}
- /*
- * Death signals, no core dump.
- */
- do_group_exit(info->si_signo);
- /* NOTREACHED */
+ return SIG_EXIT;
+
}
spin_unlock_irq(&sighand->siglock);
return signr;
^ permalink raw reply related [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-17 16:57 ` Oleg Nesterov
0 siblings, 0 replies; 132+ messages in thread
From: Oleg Nesterov @ 2014-02-17 16:57 UTC (permalink / raw)
To: Al Viro; +Cc: Eric Sandeen, Linux Kernel, xfs, Dave Jones, Linus Torvalds
On 02/15, Oleg Nesterov wrote:
>
> On 02/15, Al Viro wrote:
> >
> > On Sat, Feb 15, 2014 at 06:43:45PM +0100, Oleg Nesterov wrote:
> > > > So basically we want a different condition for "can we just go ahead and
> > > > free that sucker", right? Instead of "it's on the list, shan't free it"
> > > > it ought to be something like "it's on the list or it is referenced by
> > > > ksiginfo". Locking will be interesting, though... ;-/
> > >
> > > I guess yes... send_sigqueue() checks list_empty() too, probably nobody else.
> >
> > The trouble being, we might end up with
> > Q picked by collect_signal and and stuff into ksiginfo
> > Q resubmitted by timer code
>
> In this case the timer code should simply inc ->si_overrun and do nothing.
>
> IOW, list_empty() should be turned into is_queued(), and is_queued()
> should be true until dismiss_siginfo() which should also do
> do_schedule_next_timer(). I think.
No, this is even more complicated. We also need do_schedule_next_timer()
to calculate ->si_overrun we are going to report, I missed this...
Looks like, this is all is really nasty. Actually, I think siginfo on
stack is not that bad if we are going to do handle_signal() or restart,
perhaps we can do the extra kmalloc/memcpy/kfree for do_coredump().
Something like below.
Oleg.
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index 9e5de68..52f16f9 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -684,6 +684,52 @@ handle_signal(struct ksignal *ksig, struct pt_regs *regs)
test_thread_flag(TIF_IA32) ? __NR_ia32_restart_syscall : __NR_restart_syscall
#endif /* CONFIG_X86_32 */
+static noinline int process_signal(struct pt_regs *regs, siginfo_t **pinfo)
+{
+ struct ksignal ksig;
+
+ switch (get_signal(&ksig)) {
+ case SIG_DUMP:
+ *pinfo = kmalloc(sizeof(siginfo_t), GFP_KERNEL);
+ if (*pinfo)
+ copy_siginfo(*pinfo, &ksig.info);
+
+ case SIG_EXIT:
+ return ksig.info.si_signo;
+
+ default:
+ handle_signal(&ksig, regs);
+ break;
+
+ case 0:
+ /* Did we come from a system call? */
+ if (syscall_get_nr(current, regs) >= 0) {
+ /* Restart the system call - no handlers present */
+ switch (syscall_get_error(current, regs)) {
+ case -ERESTARTNOHAND:
+ case -ERESTARTSYS:
+ case -ERESTARTNOINTR:
+ regs->ax = regs->orig_ax;
+ regs->ip -= 2;
+ break;
+
+ case -ERESTART_RESTARTBLOCK:
+ regs->ax = NR_restart_syscall;
+ regs->ip -= 2;
+ break;
+ }
+ }
+
+ /*
+ * If there's no signal to deliver, we just put the saved sigmask
+ * back.
+ */
+ restore_saved_sigmask();
+ }
+
+ return 0;
+}
+
/*
* Note that 'init' is a special process: it doesn't get signals it doesn't
* want to handle. Thus you cannot kill init even with a SIGKILL even by
@@ -691,37 +737,16 @@ handle_signal(struct ksignal *ksig, struct pt_regs *regs)
*/
static void do_signal(struct pt_regs *regs)
{
- struct ksignal ksig;
+ siginfo_t *info = NULL;
+ int sig = process_signal(regs, &info);
- if (get_signal(&ksig)) {
- /* Whee! Actually deliver the signal. */
- handle_signal(&ksig, regs);
- return;
- }
-
- /* Did we come from a system call? */
- if (syscall_get_nr(current, regs) >= 0) {
- /* Restart the system call - no handlers present */
- switch (syscall_get_error(current, regs)) {
- case -ERESTARTNOHAND:
- case -ERESTARTSYS:
- case -ERESTARTNOINTR:
- regs->ax = regs->orig_ax;
- regs->ip -= 2;
- break;
-
- case -ERESTART_RESTARTBLOCK:
- regs->ax = NR_restart_syscall;
- regs->ip -= 2;
- break;
+ if (sig) {
+ if (info) {
+ do_coredump(info);
+ kfree(info);
}
+ do_group_exit(sig);
}
-
- /*
- * If there's no signal to deliver, we just put the saved sigmask
- * back.
- */
- restore_saved_sigmask();
}
/*
diff --git a/include/linux/signal.h b/include/linux/signal.h
index 2ac423b..33b5e04 100644
--- a/include/linux/signal.h
+++ b/include/linux/signal.h
@@ -285,6 +285,9 @@ struct ksignal {
int sig;
};
+#define SIG_EXIT -1
+#define SIG_DUMP -2
+
extern int get_signal_to_deliver(siginfo_t *info, struct k_sigaction *return_ka, struct pt_regs *regs, void *cookie);
extern void signal_setup_done(int failed, struct ksignal *ksig, int stepping);
extern void signal_delivered(int sig, siginfo_t *info, struct k_sigaction *ka, struct pt_regs *regs, int stepping);
@@ -299,7 +302,7 @@ extern void exit_signals(struct task_struct *tsk);
struct ksignal *p = (ksig); \
p->sig = get_signal_to_deliver(&p->info, &p->ka, \
signal_pt_regs(), NULL);\
- p->sig > 0; \
+ p->sig; \
})
extern struct kmem_cache *sighand_cachep;
diff --git a/kernel/signal.c b/kernel/signal.c
index 52f881d..8a4c4a3 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2353,22 +2353,11 @@ relock:
if (print_fatal_signals)
print_fatal_signal(info->si_signo);
proc_coredump_connector(current);
- /*
- * If it was able to dump core, this kills all
- * other threads in the group and synchronizes with
- * their demise. If we lost the race with another
- * thread getting here, it set group_exit_code
- * first and our do_group_exit call below will use
- * that value and ignore the one we pass it.
- */
- do_coredump(info);
+ return SIG_DUMP;
}
- /*
- * Death signals, no core dump.
- */
- do_group_exit(info->si_signo);
- /* NOTREACHED */
+ return SIG_EXIT;
+
}
spin_unlock_irq(&sighand->siglock);
return signr;
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply related [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-17 16:57 ` Oleg Nesterov
@ 2014-02-17 17:40 ` Al Viro
-1 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-17 17:40 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Linus Torvalds, Dave Chinner, Dave Jones, Eric Sandeen,
Linux Kernel, xfs
On Mon, Feb 17, 2014 at 05:57:35PM +0100, Oleg Nesterov wrote:
> Looks like, this is all is really nasty. Actually, I think siginfo on
> stack is not that bad if we are going to do handle_signal() or restart,
> perhaps we can do the extra kmalloc/memcpy/kfree for do_coredump().
> Something like below.
Yecchhhh... You've just broken every architecture other than x86, and to
fix them you'll need to massage every get_signal()/get_signal_to_deliver()
user out there, pulling the logics *out* of kernel/signal.c and into arch/*.
This is just plain wrong.
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-17 17:40 ` Al Viro
0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-17 17:40 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: Eric Sandeen, Linux Kernel, xfs, Dave Jones, Linus Torvalds
On Mon, Feb 17, 2014 at 05:57:35PM +0100, Oleg Nesterov wrote:
> Looks like, this is all is really nasty. Actually, I think siginfo on
> stack is not that bad if we are going to do handle_signal() or restart,
> perhaps we can do the extra kmalloc/memcpy/kfree for do_coredump().
> Something like below.
Yecchhhh... You've just broken every architecture other than x86, and to
fix them you'll need to massage every get_signal()/get_signal_to_deliver()
user out there, pulling the logics *out* of kernel/signal.c and into arch/*.
This is just plain wrong.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-17 17:40 ` Al Viro
@ 2014-02-17 17:46 ` Oleg Nesterov
-1 siblings, 0 replies; 132+ messages in thread
From: Oleg Nesterov @ 2014-02-17 17:46 UTC (permalink / raw)
To: Al Viro
Cc: Linus Torvalds, Dave Chinner, Dave Jones, Eric Sandeen,
Linux Kernel, xfs
On 02/17, Al Viro wrote:
>
> On Mon, Feb 17, 2014 at 05:57:35PM +0100, Oleg Nesterov wrote:
>
> > Looks like, this is all is really nasty. Actually, I think siginfo on
> > stack is not that bad if we are going to do handle_signal() or restart,
> > perhaps we can do the extra kmalloc/memcpy/kfree for do_coredump().
> > Something like below.
>
> Yecchhhh... You've just broken every architecture other than x86,
Of course, this is only to explain what I meant.
> and to
> fix them you'll need to massage every get_signal()/get_signal_to_deliver()
> user out there,
Yes.
> pulling the logics *out* of kernel/signal.c and into arch/*.
Not really, I think. Of course this change should be cleanuped. And it
should not require to change all architectures at once.
> This is just plain wrong.
I agree, this change is also ugly.
Oleg.
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-17 17:46 ` Oleg Nesterov
0 siblings, 0 replies; 132+ messages in thread
From: Oleg Nesterov @ 2014-02-17 17:46 UTC (permalink / raw)
To: Al Viro; +Cc: Eric Sandeen, Linux Kernel, xfs, Dave Jones, Linus Torvalds
On 02/17, Al Viro wrote:
>
> On Mon, Feb 17, 2014 at 05:57:35PM +0100, Oleg Nesterov wrote:
>
> > Looks like, this is all is really nasty. Actually, I think siginfo on
> > stack is not that bad if we are going to do handle_signal() or restart,
> > perhaps we can do the extra kmalloc/memcpy/kfree for do_coredump().
> > Something like below.
>
> Yecchhhh... You've just broken every architecture other than x86,
Of course, this is only to explain what I meant.
> and to
> fix them you'll need to massage every get_signal()/get_signal_to_deliver()
> user out there,
Yes.
> pulling the logics *out* of kernel/signal.c and into arch/*.
Not really, I think. Of course this change should be cleanuped. And it
should not require to change all architectures at once.
> This is just plain wrong.
I agree, this change is also ugly.
Oleg.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-17 17:46 ` Oleg Nesterov
@ 2014-02-17 17:54 ` Al Viro
-1 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-17 17:54 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Linus Torvalds, Dave Chinner, Dave Jones, Eric Sandeen,
Linux Kernel, xfs
On Mon, Feb 17, 2014 at 06:46:48PM +0100, Oleg Nesterov wrote:
> > pulling the logics *out* of kernel/signal.c and into arch/*.
>
> Not really, I think.
How so? You propose to make all architectures call do_coredump()
themselves, instead of having it done centrally. It's more boilerplate
for all of them to get wrong. And IME any boilerplate in that are
*will* be gotten wrong - I've gone through signal handling on all
architectures more than a few times and every time it caught a pile
of bugs...
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-17 17:54 ` Al Viro
0 siblings, 0 replies; 132+ messages in thread
From: Al Viro @ 2014-02-17 17:54 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: Eric Sandeen, Linux Kernel, xfs, Dave Jones, Linus Torvalds
On Mon, Feb 17, 2014 at 06:46:48PM +0100, Oleg Nesterov wrote:
> > pulling the logics *out* of kernel/signal.c and into arch/*.
>
> Not really, I think.
How so? You propose to make all architectures call do_coredump()
themselves, instead of having it done centrally. It's more boilerplate
for all of them to get wrong. And IME any boilerplate in that are
*will* be gotten wrong - I've gone through signal handling on all
architectures more than a few times and every time it caught a pile
of bugs...
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
2014-02-15 23:50 ` Linus Torvalds
(?)
@ 2014-02-18 1:27 ` Dave Chinner
-1 siblings, 0 replies; 132+ messages in thread
From: Dave Chinner @ 2014-02-18 1:27 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-mm, Al Viro, Dave Jones, Eric Sandeen, Linux Kernel, xfs
On Sat, Feb 15, 2014 at 03:50:29PM -0800, Linus Torvalds wrote:
> [ Added linux-mm to the participants list ]
>
> On Thu, Feb 13, 2014 at 4:24 PM, Dave Chinner <david@fromorbit.com> wrote:
> >
> > Dave, the patch below should chop off the stack usage from
> > xfs_log_force_lsn() issuing IO by deferring it to the CIL workqueue.
> > Can you given this a run?
>
> Ok, so DaveJ confirmed that DaveC's patch fixes his issue (damn,
> people, your parents were some seriously boring people, were they not?
> We've got too many Dave's around),
It's an exclusive club - we have 'kernel hacker Dave' reunions in
bars around the world. We should get some tshirts made up.... :)
> but DaveC earlier pointed out that
> pretty much any memory allocation path can end up using 3kB of stack
> even without XFS being involved.
>
> Which does bring up the question whether we should look (once more) at
> the VM direct-reclaim path, and try to avoid GFP_FS/IO direct
> reclaim..
We do that mostly already, but GFP_KERNEL allows swap IO and that's
where the deepest stack I saw came from.
Even if we don't allow IO at all, we're still going to see stack
usage of 2-2.5k in direct reclaim. e.g. invalidate a page and enter
the rmap code. The rmap is protected by a mutex, so if we fail to
get that we have about 1.2k of stack consumed from there and that is
on top of the the allocator/reclaim that has already consumes ~1k of
stack...
> Direct reclaim historically used to be an important throttling
> mechanism, and I used to not be a fan of trying to avoid direct
> reclaim. But the stack depth issue really looks to be pretty bad, and
> I think we've gotten better at throttling explicitly, so..
>
> I *think* we already limit filesystem writeback to just kswapd (in
> shrink_page_list()), but DaveC posted a backtrace that goes through
> do_try_to_free_pages() to shrink_slab(), and through there to the
> filesystem and then IO. That looked like a disaster.
Right, that's an XFS problem, and I'm working on fixing it. The
Patch I sent to DaveJ fixes the worst case, but I need to make it
completely IO-less while still retaining the throttling the IO gives
us.
> And that's because (if I read things right) shrink_page_list() limits
> filesystem page writeback to kswapd, but not swap pages. Which I think
> probably made more sense back in the days than it does now (I
> certainly *hope* that swapping is less important today than it was,
> say, ten years ago)
>
> So I'm wondering whether we should remove that page_is_file_cache()
> check from shrink_page_list()?
The thing is, the stack usage from the swap IO path is pretty well
bound - it's just the worst case stack of issuing IO. We know it
won't recurse into direct reclaim, so mempool allocation and
blocking is all we need to consider. Compare that to a filesystem
which may need to allocate extents and hence do transactions and
split btrees and read metadata and allocate large amounts of memory
even before it gets to the IO layers.
Hence I suspect that we could do a simple thing like only allow swap
if there's more than half the stack available in the current reclaim
context. Because, let's face it, if the submit_bio path is consuming
more than half the available stack then we're totally screwed from a
filesystem perspective....
> And then there is that whole shrink_slab() case...
I think with shrinkers we just need to be more careful. The XFS
behaviour is all my fault, and I should have known better that to
design code that requires IO in the direct reclaim path. :/
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-18 1:27 ` Dave Chinner
0 siblings, 0 replies; 132+ messages in thread
From: Dave Chinner @ 2014-02-18 1:27 UTC (permalink / raw)
To: Linus Torvalds
Cc: Eric Sandeen, Linux Kernel, xfs, linux-mm, Al Viro, Dave Jones
On Sat, Feb 15, 2014 at 03:50:29PM -0800, Linus Torvalds wrote:
> [ Added linux-mm to the participants list ]
>
> On Thu, Feb 13, 2014 at 4:24 PM, Dave Chinner <david@fromorbit.com> wrote:
> >
> > Dave, the patch below should chop off the stack usage from
> > xfs_log_force_lsn() issuing IO by deferring it to the CIL workqueue.
> > Can you given this a run?
>
> Ok, so DaveJ confirmed that DaveC's patch fixes his issue (damn,
> people, your parents were some seriously boring people, were they not?
> We've got too many Dave's around),
It's an exclusive club - we have 'kernel hacker Dave' reunions in
bars around the world. We should get some tshirts made up.... :)
> but DaveC earlier pointed out that
> pretty much any memory allocation path can end up using 3kB of stack
> even without XFS being involved.
>
> Which does bring up the question whether we should look (once more) at
> the VM direct-reclaim path, and try to avoid GFP_FS/IO direct
> reclaim..
We do that mostly already, but GFP_KERNEL allows swap IO and that's
where the deepest stack I saw came from.
Even if we don't allow IO at all, we're still going to see stack
usage of 2-2.5k in direct reclaim. e.g. invalidate a page and enter
the rmap code. The rmap is protected by a mutex, so if we fail to
get that we have about 1.2k of stack consumed from there and that is
on top of the the allocator/reclaim that has already consumes ~1k of
stack...
> Direct reclaim historically used to be an important throttling
> mechanism, and I used to not be a fan of trying to avoid direct
> reclaim. But the stack depth issue really looks to be pretty bad, and
> I think we've gotten better at throttling explicitly, so..
>
> I *think* we already limit filesystem writeback to just kswapd (in
> shrink_page_list()), but DaveC posted a backtrace that goes through
> do_try_to_free_pages() to shrink_slab(), and through there to the
> filesystem and then IO. That looked like a disaster.
Right, that's an XFS problem, and I'm working on fixing it. The
Patch I sent to DaveJ fixes the worst case, but I need to make it
completely IO-less while still retaining the throttling the IO gives
us.
> And that's because (if I read things right) shrink_page_list() limits
> filesystem page writeback to kswapd, but not swap pages. Which I think
> probably made more sense back in the days than it does now (I
> certainly *hope* that swapping is less important today than it was,
> say, ten years ago)
>
> So I'm wondering whether we should remove that page_is_file_cache()
> check from shrink_page_list()?
The thing is, the stack usage from the swap IO path is pretty well
bound - it's just the worst case stack of issuing IO. We know it
won't recurse into direct reclaim, so mempool allocation and
blocking is all we need to consider. Compare that to a filesystem
which may need to allocate extents and hence do transactions and
split btrees and read metadata and allocate large amounts of memory
even before it gets to the IO layers.
Hence I suspect that we could do a simple thing like only allow swap
if there's more than half the stack available in the current reclaim
context. Because, let's face it, if the submit_bio path is consuming
more than half the available stack then we're totally screwed from a
filesystem perspective....
> And then there is that whole shrink_slab() case...
I think with shrinkers we just need to be more careful. The XFS
behaviour is all my fault, and I should have known better that to
design code that requires IO in the direct reclaim path. :/
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] 132+ messages in thread
* Re: 3.14-rc2 XFS backtrace because irqs_disabled.
@ 2014-02-18 1:27 ` Dave Chinner
0 siblings, 0 replies; 132+ messages in thread
From: Dave Chinner @ 2014-02-18 1:27 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-mm, Al Viro, Dave Jones, Eric Sandeen, Linux Kernel, xfs
On Sat, Feb 15, 2014 at 03:50:29PM -0800, Linus Torvalds wrote:
> [ Added linux-mm to the participants list ]
>
> On Thu, Feb 13, 2014 at 4:24 PM, Dave Chinner <david@fromorbit.com> wrote:
> >
> > Dave, the patch below should chop off the stack usage from
> > xfs_log_force_lsn() issuing IO by deferring it to the CIL workqueue.
> > Can you given this a run?
>
> Ok, so DaveJ confirmed that DaveC's patch fixes his issue (damn,
> people, your parents were some seriously boring people, were they not?
> We've got too many Dave's around),
It's an exclusive club - we have 'kernel hacker Dave' reunions in
bars around the world. We should get some tshirts made up.... :)
> but DaveC earlier pointed out that
> pretty much any memory allocation path can end up using 3kB of stack
> even without XFS being involved.
>
> Which does bring up the question whether we should look (once more) at
> the VM direct-reclaim path, and try to avoid GFP_FS/IO direct
> reclaim..
We do that mostly already, but GFP_KERNEL allows swap IO and that's
where the deepest stack I saw came from.
Even if we don't allow IO at all, we're still going to see stack
usage of 2-2.5k in direct reclaim. e.g. invalidate a page and enter
the rmap code. The rmap is protected by a mutex, so if we fail to
get that we have about 1.2k of stack consumed from there and that is
on top of the the allocator/reclaim that has already consumes ~1k of
stack...
> Direct reclaim historically used to be an important throttling
> mechanism, and I used to not be a fan of trying to avoid direct
> reclaim. But the stack depth issue really looks to be pretty bad, and
> I think we've gotten better at throttling explicitly, so..
>
> I *think* we already limit filesystem writeback to just kswapd (in
> shrink_page_list()), but DaveC posted a backtrace that goes through
> do_try_to_free_pages() to shrink_slab(), and through there to the
> filesystem and then IO. That looked like a disaster.
Right, that's an XFS problem, and I'm working on fixing it. The
Patch I sent to DaveJ fixes the worst case, but I need to make it
completely IO-less while still retaining the throttling the IO gives
us.
> And that's because (if I read things right) shrink_page_list() limits
> filesystem page writeback to kswapd, but not swap pages. Which I think
> probably made more sense back in the days than it does now (I
> certainly *hope* that swapping is less important today than it was,
> say, ten years ago)
>
> So I'm wondering whether we should remove that page_is_file_cache()
> check from shrink_page_list()?
The thing is, the stack usage from the swap IO path is pretty well
bound - it's just the worst case stack of issuing IO. We know it
won't recurse into direct reclaim, so mempool allocation and
blocking is all we need to consider. Compare that to a filesystem
which may need to allocate extents and hence do transactions and
split btrees and read metadata and allocate large amounts of memory
even before it gets to the IO layers.
Hence I suspect that we could do a simple thing like only allow swap
if there's more than half the stack available in the current reclaim
context. Because, let's face it, if the submit_bio path is consuming
more than half the available stack then we're totally screwed from a
filesystem perspective....
> And then there is that whole shrink_slab() case...
I think with shrinkers we just need to be more careful. The XFS
behaviour is all my fault, and I should have known better that to
design code that requires IO in the direct reclaim path. :/
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] 132+ messages in thread
end of thread, other threads:[~2014-02-18 1:28 UTC | newest]
Thread overview: 132+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-11 17:27 3.14-rc2 XFS backtrace because irqs_disabled Dave Jones
2014-02-11 17:27 ` Dave Jones
2014-02-11 21:08 ` Dave Chinner
2014-02-11 21:08 ` Dave Chinner
2014-02-11 21:49 ` Eric Sandeen
2014-02-11 21:49 ` Eric Sandeen
2014-02-12 0:44 ` Dave Jones
2014-02-12 0:44 ` Dave Jones
2014-02-12 1:09 ` Al Viro
2014-02-12 1:09 ` Al Viro
2014-02-12 2:52 ` Linus Torvalds
2014-02-12 2:52 ` Linus Torvalds
2014-02-12 4:03 ` Dave Jones
2014-02-12 4:03 ` Dave Jones
2014-02-12 4:22 ` Al Viro
2014-02-12 4:22 ` Al Viro
2014-02-12 5:40 ` Dave Chinner
2014-02-12 5:40 ` Dave Chinner
2014-02-12 5:50 ` Dave Jones
2014-02-12 5:50 ` Dave Jones
2014-02-12 6:10 ` Dave Chinner
2014-02-12 6:10 ` Dave Chinner
2014-02-12 6:31 ` Dave Chinner
2014-02-12 6:31 ` Dave Chinner
2014-02-12 6:59 ` Linus Torvalds
2014-02-12 6:59 ` Linus Torvalds
2014-02-12 8:13 ` Tejun Heo
2014-02-12 8:13 ` Tejun Heo
2014-02-12 12:44 ` Steven Rostedt
2014-02-12 12:44 ` Steven Rostedt
2014-02-12 8:35 ` Dave Chinner
2014-02-12 8:35 ` Dave Chinner
2014-02-12 12:50 ` Steven Rostedt
2014-02-12 12:50 ` Steven Rostedt
2014-02-12 12:40 ` Steven Rostedt
2014-02-12 12:40 ` Steven Rostedt
2014-02-12 13:29 ` Peter Zijlstra
2014-02-12 13:29 ` Peter Zijlstra
2014-02-12 14:25 ` Dave Jones
2014-02-12 14:25 ` Dave Jones
2014-02-12 21:14 ` Dave Chinner
2014-02-12 21:14 ` Dave Chinner
2014-02-12 15:57 ` Eric Sandeen
2014-02-12 15:57 ` Eric Sandeen
2014-02-12 6:28 ` Linus Torvalds
2014-02-12 6:28 ` Linus Torvalds
2014-02-12 7:18 ` Dave Chinner
2014-02-12 7:18 ` Dave Chinner
2014-02-14 0:24 ` Dave Chinner
2014-02-14 0:24 ` Dave Chinner
2014-02-14 16:01 ` Dave Jones
2014-02-14 16:01 ` Dave Jones
2014-02-15 22:23 ` Dave Chinner
2014-02-15 22:23 ` Dave Chinner
2014-02-15 22:28 ` Dave Jones
2014-02-15 22:28 ` Dave Jones
2014-02-15 22:43 ` Linus Torvalds
2014-02-15 22:43 ` Linus Torvalds
2014-02-15 23:50 ` Linus Torvalds
2014-02-15 23:50 ` Linus Torvalds
2014-02-15 23:50 ` Linus Torvalds
2014-02-18 1:27 ` Dave Chinner
2014-02-18 1:27 ` Dave Chinner
2014-02-18 1:27 ` Dave Chinner
2014-02-12 11:39 ` Al Viro
2014-02-12 11:39 ` Al Viro
2014-02-12 20:13 ` Linus Torvalds
2014-02-12 20:13 ` Linus Torvalds
2014-02-12 21:14 ` Al Viro
2014-02-12 21:14 ` Al Viro
2014-02-12 21:32 ` Linus Torvalds
2014-02-12 21:32 ` Linus Torvalds
2014-02-12 21:44 ` Al Viro
2014-02-12 21:44 ` Al Viro
2014-02-13 20:51 ` Al Viro
2014-02-13 20:51 ` Al Viro
2014-02-14 0:09 ` Al Viro
2014-02-14 0:09 ` Al Viro
2014-02-14 13:25 ` Christoph Hellwig
2014-02-14 13:25 ` Christoph Hellwig
2014-02-14 13:29 ` Richard Weinberger
2014-02-14 13:29 ` Richard Weinberger
2014-02-14 15:20 ` Al Viro
2014-02-14 15:20 ` Al Viro
2014-02-14 16:08 ` Oleg Nesterov
2014-02-14 16:08 ` Oleg Nesterov
2014-02-13 17:40 ` Oleg Nesterov
2014-02-13 17:40 ` Oleg Nesterov
2014-02-13 17:58 ` Linus Torvalds
2014-02-13 17:58 ` Linus Torvalds
2014-02-13 18:10 ` Oleg Nesterov
2014-02-13 18:10 ` Oleg Nesterov
2014-02-13 18:37 ` Oleg Nesterov
2014-02-13 18:37 ` Oleg Nesterov
2014-02-15 5:25 ` Al Viro
2014-02-15 5:25 ` Al Viro
2014-02-15 14:27 ` Oleg Nesterov
2014-02-15 14:27 ` Oleg Nesterov
2014-02-15 15:22 ` Al Viro
2014-02-15 15:22 ` Al Viro
2014-02-15 15:33 ` Oleg Nesterov
2014-02-15 15:33 ` Oleg Nesterov
2014-02-15 15:36 ` Al Viro
2014-02-15 15:36 ` Al Viro
2014-02-15 15:58 ` Al Viro
2014-02-15 15:58 ` Al Viro
2014-02-15 16:59 ` Al Viro
2014-02-15 16:59 ` Al Viro
2014-02-15 17:43 ` Oleg Nesterov
2014-02-15 17:43 ` Oleg Nesterov
2014-02-15 18:05 ` Al Viro
2014-02-15 18:05 ` Al Viro
2014-02-15 18:45 ` Oleg Nesterov
2014-02-15 18:45 ` Oleg Nesterov
2014-02-17 16:57 ` Oleg Nesterov
2014-02-17 16:57 ` Oleg Nesterov
2014-02-17 17:40 ` Al Viro
2014-02-17 17:40 ` Al Viro
2014-02-17 17:46 ` Oleg Nesterov
2014-02-17 17:46 ` Oleg Nesterov
2014-02-17 17:54 ` Al Viro
2014-02-17 17:54 ` Al Viro
2014-02-14 16:13 ` Christoph Hellwig
2014-02-14 16:13 ` Christoph Hellwig
2014-02-14 16:16 ` Al Viro
2014-02-14 16:16 ` Al Viro
2014-02-14 16:18 ` Al Viro
2014-02-14 16:18 ` Al Viro
2014-02-14 16:19 ` Christoph Hellwig
2014-02-14 16:19 ` Christoph Hellwig
2014-02-15 14:46 ` Oleg Nesterov
2014-02-15 14:46 ` Oleg Nesterov
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.