Re: DMA-API backtrace from rtsx_usb_ms driver
On Thu, 2015-02-19 at 11:58 -0500, Josh Boyer wrote: > Hi All, > > We've had a few bug reports with the stack trace below. It looks like > the ms_read_bytes and ms_write_bytes functions in > drivers/memstick/host/rtsx_usb_mc.c are using a stack variable when > calling rtsx_usb_ep0_read_register. That eventually gets to the > DMA-API debugging checks, which throws the warning backtrace. > > A typical fix is to replace: > > u8 val; > > rtsx_usb_ep0_read_register(ucr, MS_TRANS_CFG, ); > dev_dbg(ms_dev(host), "MS_TRANS_CFG: 0x%02x\n", val); > > with something like: > > u8 val = kzalloc(sizeof(u8), GFP_KERNEL); > if (!val) return -ENOMEM; > > rtsx_usb_ep0_read_register(ucr, MS_TRANS_CFG, ); > dev_dbg(ms_dev(host), "MS_TRANS_CFG: 0x%02x\n", val); > > <> > kfree(val); > > However, I'm not familiar enough with this driver to know if this > function is called frequently in an IRQ handler, etc. If the above > pseudo code looks sufficient, I can come up with a patch. > Thanks for reporting this. rtsx_usb_ep0_read_register() is not called in any interrupt context. It is a high-priority(control pipe) but less used alternative to communicate with device. It is primarily for error handling. I'll fix it inside rtsx_usb_ep0_read_register() itself by a DMA'able double buffer because it could be called somewhere else(e.g. mmc side). > WARNING: CPU: 1 PID: 25 at lib/dma-debug.c:1166 check_for_stack+0x96/0xe0() > ehci-pci :00:1a.0: DMA-API: device driver maps memory from stack > [addr=8801199e3cef] > Modules linked in: rtsx_usb_ms arc4 memstick intel_rapl iosf_mbi > rtl8192ce snd_hda_codec_hdmi snd_hda_codec_realtek > snd_hda_codec_generic snd_hda_intel rtl_pci rtl8192c_common > snd_hda_controller x86_pkg_temp_thermal snd_hda_codec rtlwifi mac80211 > coretemp kvm_intel kvm iTCO_wdt snd_hwdep snd_seq snd_seq_device > crct10dif_pclmul iTCO_vendor_support sparse_keymap cfg80211 > crc32_pclmul snd_pcm crc32c_intel ghash_clmulni_intel rfkill i2c_i801 > snd_timer shpchp snd serio_raw mei_me lpc_ich soundcore mei tpm_tis > tpm wmi nfsd auth_rpcgss nfs_acl lockd grace sunrpc i915 > rtsx_usb_sdmmc mmc_core 8021q uas garp stp i2c_algo_bit llc mrp > drm_kms_helper usb_storage drm rtsx_usb mfd_core r8169 mii video > CPU: 1 PID: 25 Comm: kworker/1:2 Not tainted 3.20.0-0.rc0.git7.3.fc22.x86_64 > #1 > Hardware name: WB WB-B06211/WB-B0621, BIOS EB062IWB V1.0 12/12/2013 > Workqueue: events rtsx_usb_ms_handle_req [rtsx_usb_ms] > 3d188e66 8801199e3808 8187642b > 8801199e3860 8801199e3848 810ab39a > 8801199e3864 8801199e3cef 880119b57098 880119b37320 > Call Trace: > [] dump_stack+0x4c/0x65 > [] warn_slowpath_common+0x8a/0xc0 > [] warn_slowpath_fmt+0x55/0x70 > [] ? _raw_spin_unlock_irqrestore+0x36/0x70 > [] check_for_stack+0x96/0xe0 > [] debug_dma_map_page+0x104/0x150 > [] usb_hcd_map_urb_for_dma+0x646/0x790 > [] usb_hcd_submit_urb+0x1d5/0xa90 > [] ? mark_held_locks+0x7f/0xc0 > [] ? mark_held_locks+0x7f/0xc0 > [] ? lockdep_init_map+0x65/0x5d0 > [] usb_submit_urb+0x42e/0x5f0 > [] usb_start_wait_urb+0x77/0x190 > [] ? __kmalloc+0x205/0x2d0 > [] usb_control_msg+0xdc/0x130 > [] rtsx_usb_ep0_read_register+0x59/0x70 [rtsx_usb] > [] ? rtsx_usb_get_rsp+0x41/0x50 [rtsx_usb] > [] rtsx_usb_ms_handle_req+0x7ce/0x9c5 [rtsx_usb_ms] > [] ? process_one_work+0x19b/0x860 > [] process_one_work+0x232/0x860 > [] ? process_one_work+0x19b/0x860 > [] ? worker_thread+0xda/0x470 > [] worker_thread+0x53/0x470 > [] ? process_one_work+0x860/0x860 > [] kthread+0x104/0x120 > [] ? local_clock+0x25/0x30 > [] ? kthread_create_on_node+0x250/0x250 > [] ret_from_fork+0x7c/0xb0 > [] ? kthread_create_on_node+0x250/0x250 > > josh > > --Please consider the environment before printing this e-mail. -- Best regards, Roger Tseng
Re: DMA-API backtrace from rtsx_usb_ms driver
On Thu, 2015-02-19 at 11:58 -0500, Josh Boyer wrote: Hi All, We've had a few bug reports with the stack trace below. It looks like the ms_read_bytes and ms_write_bytes functions in drivers/memstick/host/rtsx_usb_mc.c are using a stack variable when calling rtsx_usb_ep0_read_register. That eventually gets to the DMA-API debugging checks, which throws the warning backtrace. A typical fix is to replace: u8 val; rtsx_usb_ep0_read_register(ucr, MS_TRANS_CFG, val); dev_dbg(ms_dev(host), MS_TRANS_CFG: 0x%02x\n, val); with something like: u8 val = kzalloc(sizeof(u8), GFP_KERNEL); if (!val) return -ENOMEM; rtsx_usb_ep0_read_register(ucr, MS_TRANS_CFG, val); dev_dbg(ms_dev(host), MS_TRANS_CFG: 0x%02x\n, val); kfree(val); However, I'm not familiar enough with this driver to know if this function is called frequently in an IRQ handler, etc. If the above pseudo code looks sufficient, I can come up with a patch. Thanks for reporting this. rtsx_usb_ep0_read_register() is not called in any interrupt context. It is a high-priority(control pipe) but less used alternative to communicate with device. It is primarily for error handling. I'll fix it inside rtsx_usb_ep0_read_register() itself by a DMA'able double buffer because it could be called somewhere else(e.g. mmc side). WARNING: CPU: 1 PID: 25 at lib/dma-debug.c:1166 check_for_stack+0x96/0xe0() ehci-pci :00:1a.0: DMA-API: device driver maps memory from stack [addr=8801199e3cef] Modules linked in: rtsx_usb_ms arc4 memstick intel_rapl iosf_mbi rtl8192ce snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel rtl_pci rtl8192c_common snd_hda_controller x86_pkg_temp_thermal snd_hda_codec rtlwifi mac80211 coretemp kvm_intel kvm iTCO_wdt snd_hwdep snd_seq snd_seq_device crct10dif_pclmul iTCO_vendor_support sparse_keymap cfg80211 crc32_pclmul snd_pcm crc32c_intel ghash_clmulni_intel rfkill i2c_i801 snd_timer shpchp snd serio_raw mei_me lpc_ich soundcore mei tpm_tis tpm wmi nfsd auth_rpcgss nfs_acl lockd grace sunrpc i915 rtsx_usb_sdmmc mmc_core 8021q uas garp stp i2c_algo_bit llc mrp drm_kms_helper usb_storage drm rtsx_usb mfd_core r8169 mii video CPU: 1 PID: 25 Comm: kworker/1:2 Not tainted 3.20.0-0.rc0.git7.3.fc22.x86_64 #1 Hardware name: WB WB-B06211/WB-B0621, BIOS EB062IWB V1.0 12/12/2013 Workqueue: events rtsx_usb_ms_handle_req [rtsx_usb_ms] 3d188e66 8801199e3808 8187642b 8801199e3860 8801199e3848 810ab39a 8801199e3864 8801199e3cef 880119b57098 880119b37320 Call Trace: [8187642b] dump_stack+0x4c/0x65 [810ab39a] warn_slowpath_common+0x8a/0xc0 [810ab425] warn_slowpath_fmt+0x55/0x70 [8187efe6] ? _raw_spin_unlock_irqrestore+0x36/0x70 [81453156] check_for_stack+0x96/0xe0 [81453934] debug_dma_map_page+0x104/0x150 [81613b86] usb_hcd_map_urb_for_dma+0x646/0x790 [81614165] usb_hcd_submit_urb+0x1d5/0xa90 [81106f8f] ? mark_held_locks+0x7f/0xc0 [81106f8f] ? mark_held_locks+0x7f/0xc0 [81103a15] ? lockdep_init_map+0x65/0x5d0 [81615d7e] usb_submit_urb+0x42e/0x5f0 [81616787] usb_start_wait_urb+0x77/0x190 [8124f035] ? __kmalloc+0x205/0x2d0 [8161697c] usb_control_msg+0xdc/0x130 [a0031669] rtsx_usb_ep0_read_register+0x59/0x70 [rtsx_usb] [a00310c1] ? rtsx_usb_get_rsp+0x41/0x50 [rtsx_usb] [a071da4e] rtsx_usb_ms_handle_req+0x7ce/0x9c5 [rtsx_usb_ms] [810cc60b] ? process_one_work+0x19b/0x860 [810cc6a2] process_one_work+0x232/0x860 [810cc60b] ? process_one_work+0x19b/0x860 [810ccdaa] ? worker_thread+0xda/0x470 [810ccd23] worker_thread+0x53/0x470 [810cccd0] ? process_one_work+0x860/0x860 [810d31b4] kthread+0x104/0x120 [810e7fb5] ? local_clock+0x25/0x30 [810d30b0] ? kthread_create_on_node+0x250/0x250 [8187fb7c] ret_from_fork+0x7c/0xb0 [810d30b0] ? kthread_create_on_node+0x250/0x250 josh --Please consider the environment before printing this e-mail. -- Best regards, Roger Tseng
DMA-API backtrace from rtsx_usb_ms driver
Hi All, We've had a few bug reports with the stack trace below. It looks like the ms_read_bytes and ms_write_bytes functions in drivers/memstick/host/rtsx_usb_mc.c are using a stack variable when calling rtsx_usb_ep0_read_register. That eventually gets to the DMA-API debugging checks, which throws the warning backtrace. A typical fix is to replace: u8 val; rtsx_usb_ep0_read_register(ucr, MS_TRANS_CFG, ); dev_dbg(ms_dev(host), "MS_TRANS_CFG: 0x%02x\n", val); with something like: u8 val = kzalloc(sizeof(u8), GFP_KERNEL); if (!val) return -ENOMEM; rtsx_usb_ep0_read_register(ucr, MS_TRANS_CFG, ); dev_dbg(ms_dev(host), "MS_TRANS_CFG: 0x%02x\n", val); <> kfree(val); However, I'm not familiar enough with this driver to know if this function is called frequently in an IRQ handler, etc. If the above pseudo code looks sufficient, I can come up with a patch. WARNING: CPU: 1 PID: 25 at lib/dma-debug.c:1166 check_for_stack+0x96/0xe0() ehci-pci :00:1a.0: DMA-API: device driver maps memory from stack [addr=8801199e3cef] Modules linked in: rtsx_usb_ms arc4 memstick intel_rapl iosf_mbi rtl8192ce snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel rtl_pci rtl8192c_common snd_hda_controller x86_pkg_temp_thermal snd_hda_codec rtlwifi mac80211 coretemp kvm_intel kvm iTCO_wdt snd_hwdep snd_seq snd_seq_device crct10dif_pclmul iTCO_vendor_support sparse_keymap cfg80211 crc32_pclmul snd_pcm crc32c_intel ghash_clmulni_intel rfkill i2c_i801 snd_timer shpchp snd serio_raw mei_me lpc_ich soundcore mei tpm_tis tpm wmi nfsd auth_rpcgss nfs_acl lockd grace sunrpc i915 rtsx_usb_sdmmc mmc_core 8021q uas garp stp i2c_algo_bit llc mrp drm_kms_helper usb_storage drm rtsx_usb mfd_core r8169 mii video CPU: 1 PID: 25 Comm: kworker/1:2 Not tainted 3.20.0-0.rc0.git7.3.fc22.x86_64 #1 Hardware name: WB WB-B06211/WB-B0621, BIOS EB062IWB V1.0 12/12/2013 Workqueue: events rtsx_usb_ms_handle_req [rtsx_usb_ms] 3d188e66 8801199e3808 8187642b 8801199e3860 8801199e3848 810ab39a 8801199e3864 8801199e3cef 880119b57098 880119b37320 Call Trace: [] dump_stack+0x4c/0x65 [] warn_slowpath_common+0x8a/0xc0 [] warn_slowpath_fmt+0x55/0x70 [] ? _raw_spin_unlock_irqrestore+0x36/0x70 [] check_for_stack+0x96/0xe0 [] debug_dma_map_page+0x104/0x150 [] usb_hcd_map_urb_for_dma+0x646/0x790 [] usb_hcd_submit_urb+0x1d5/0xa90 [] ? mark_held_locks+0x7f/0xc0 [] ? mark_held_locks+0x7f/0xc0 [] ? lockdep_init_map+0x65/0x5d0 [] usb_submit_urb+0x42e/0x5f0 [] usb_start_wait_urb+0x77/0x190 [] ? __kmalloc+0x205/0x2d0 [] usb_control_msg+0xdc/0x130 [] rtsx_usb_ep0_read_register+0x59/0x70 [rtsx_usb] [] ? rtsx_usb_get_rsp+0x41/0x50 [rtsx_usb] [] rtsx_usb_ms_handle_req+0x7ce/0x9c5 [rtsx_usb_ms] [] ? process_one_work+0x19b/0x860 [] process_one_work+0x232/0x860 [] ? process_one_work+0x19b/0x860 [] ? worker_thread+0xda/0x470 [] worker_thread+0x53/0x470 [] ? process_one_work+0x860/0x860 [] kthread+0x104/0x120 [] ? local_clock+0x25/0x30 [] ? kthread_create_on_node+0x250/0x250 [] ret_from_fork+0x7c/0xb0 [] ? kthread_create_on_node+0x250/0x250 josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
DMA-API backtrace from rtsx_usb_ms driver
Hi All, We've had a few bug reports with the stack trace below. It looks like the ms_read_bytes and ms_write_bytes functions in drivers/memstick/host/rtsx_usb_mc.c are using a stack variable when calling rtsx_usb_ep0_read_register. That eventually gets to the DMA-API debugging checks, which throws the warning backtrace. A typical fix is to replace: u8 val; rtsx_usb_ep0_read_register(ucr, MS_TRANS_CFG, val); dev_dbg(ms_dev(host), MS_TRANS_CFG: 0x%02x\n, val); with something like: u8 val = kzalloc(sizeof(u8), GFP_KERNEL); if (!val) return -ENOMEM; rtsx_usb_ep0_read_register(ucr, MS_TRANS_CFG, val); dev_dbg(ms_dev(host), MS_TRANS_CFG: 0x%02x\n, val); kfree(val); However, I'm not familiar enough with this driver to know if this function is called frequently in an IRQ handler, etc. If the above pseudo code looks sufficient, I can come up with a patch. WARNING: CPU: 1 PID: 25 at lib/dma-debug.c:1166 check_for_stack+0x96/0xe0() ehci-pci :00:1a.0: DMA-API: device driver maps memory from stack [addr=8801199e3cef] Modules linked in: rtsx_usb_ms arc4 memstick intel_rapl iosf_mbi rtl8192ce snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel rtl_pci rtl8192c_common snd_hda_controller x86_pkg_temp_thermal snd_hda_codec rtlwifi mac80211 coretemp kvm_intel kvm iTCO_wdt snd_hwdep snd_seq snd_seq_device crct10dif_pclmul iTCO_vendor_support sparse_keymap cfg80211 crc32_pclmul snd_pcm crc32c_intel ghash_clmulni_intel rfkill i2c_i801 snd_timer shpchp snd serio_raw mei_me lpc_ich soundcore mei tpm_tis tpm wmi nfsd auth_rpcgss nfs_acl lockd grace sunrpc i915 rtsx_usb_sdmmc mmc_core 8021q uas garp stp i2c_algo_bit llc mrp drm_kms_helper usb_storage drm rtsx_usb mfd_core r8169 mii video CPU: 1 PID: 25 Comm: kworker/1:2 Not tainted 3.20.0-0.rc0.git7.3.fc22.x86_64 #1 Hardware name: WB WB-B06211/WB-B0621, BIOS EB062IWB V1.0 12/12/2013 Workqueue: events rtsx_usb_ms_handle_req [rtsx_usb_ms] 3d188e66 8801199e3808 8187642b 8801199e3860 8801199e3848 810ab39a 8801199e3864 8801199e3cef 880119b57098 880119b37320 Call Trace: [8187642b] dump_stack+0x4c/0x65 [810ab39a] warn_slowpath_common+0x8a/0xc0 [810ab425] warn_slowpath_fmt+0x55/0x70 [8187efe6] ? _raw_spin_unlock_irqrestore+0x36/0x70 [81453156] check_for_stack+0x96/0xe0 [81453934] debug_dma_map_page+0x104/0x150 [81613b86] usb_hcd_map_urb_for_dma+0x646/0x790 [81614165] usb_hcd_submit_urb+0x1d5/0xa90 [81106f8f] ? mark_held_locks+0x7f/0xc0 [81106f8f] ? mark_held_locks+0x7f/0xc0 [81103a15] ? lockdep_init_map+0x65/0x5d0 [81615d7e] usb_submit_urb+0x42e/0x5f0 [81616787] usb_start_wait_urb+0x77/0x190 [8124f035] ? __kmalloc+0x205/0x2d0 [8161697c] usb_control_msg+0xdc/0x130 [a0031669] rtsx_usb_ep0_read_register+0x59/0x70 [rtsx_usb] [a00310c1] ? rtsx_usb_get_rsp+0x41/0x50 [rtsx_usb] [a071da4e] rtsx_usb_ms_handle_req+0x7ce/0x9c5 [rtsx_usb_ms] [810cc60b] ? process_one_work+0x19b/0x860 [810cc6a2] process_one_work+0x232/0x860 [810cc60b] ? process_one_work+0x19b/0x860 [810ccdaa] ? worker_thread+0xda/0x470 [810ccd23] worker_thread+0x53/0x470 [810cccd0] ? process_one_work+0x860/0x860 [810d31b4] kthread+0x104/0x120 [810e7fb5] ? local_clock+0x25/0x30 [810d30b0] ? kthread_create_on_node+0x250/0x250 [8187fb7c] ret_from_fork+0x7c/0xb0 [810d30b0] ? kthread_create_on_node+0x250/0x250 josh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
