Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752769AbbBSQ6n (ORCPT <rfc822;w@1wt.eu>);
	Thu, 19 Feb 2015 11:58:43 -0500
Received: from mail-ob0-f172.google.com ([209.85.214.172]:51876 "EHLO
	mail-ob0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751795AbbBSQ6l (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 19 Feb 2015 11:58:41 -0500
MIME-Version: 1.0
Date: Thu, 19 Feb 2015 11:58:41 -0500
X-Google-Sender-Auth: sc0OtnhL2aX961ZpWHhPuKW-3CU
Message-ID: <CA+5PVA4Vd3x50cyZDA+qfFN_JreZdc2pa6spS2TEnyxhaaacgQ@mail.gmail.com>
Subject: DMA-API backtrace from rtsx_usb_ms driver
From: Josh Boyer <jwboyer@fedoraproject.org>
To: Roger Tseng <rogerable@realtek.com>, Wolfram Sang <wsa@the-dreams.de>
Cc: Lee Jones <lee.jones@linaro.org>,
        "Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset=ISO-8859-1
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 4096
Lines: 87

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 0000:00:1a.0: DMA-API: device driver maps memory from stack
[addr=ffff8801199e3cef]
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]
 0000000000000000 000000003d188e66 ffff8801199e3808 ffffffff8187642b
 0000000000000000 ffff8801199e3860 ffff8801199e3848 ffffffff810ab39a
 ffff8801199e3864 ffff8801199e3cef ffff880119b57098 ffff880119b37320
Call Trace:
 [<ffffffff8187642b>] dump_stack+0x4c/0x65
 [<ffffffff810ab39a>] warn_slowpath_common+0x8a/0xc0
 [<ffffffff810ab425>] warn_slowpath_fmt+0x55/0x70
 [<ffffffff8187efe6>] ? _raw_spin_unlock_irqrestore+0x36/0x70
 [<ffffffff81453156>] check_for_stack+0x96/0xe0
 [<ffffffff81453934>] debug_dma_map_page+0x104/0x150
 [<ffffffff81613b86>] usb_hcd_map_urb_for_dma+0x646/0x790
 [<ffffffff81614165>] usb_hcd_submit_urb+0x1d5/0xa90
 [<ffffffff81106f8f>] ? mark_held_locks+0x7f/0xc0
 [<ffffffff81106f8f>] ? mark_held_locks+0x7f/0xc0
 [<ffffffff81103a15>] ? lockdep_init_map+0x65/0x5d0
 [<ffffffff81615d7e>] usb_submit_urb+0x42e/0x5f0
 [<ffffffff81616787>] usb_start_wait_urb+0x77/0x190
 [<ffffffff8124f035>] ? __kmalloc+0x205/0x2d0
 [<ffffffff8161697c>] usb_control_msg+0xdc/0x130
 [<ffffffffa0031669>] rtsx_usb_ep0_read_register+0x59/0x70 [rtsx_usb]
 [<ffffffffa00310c1>] ? rtsx_usb_get_rsp+0x41/0x50 [rtsx_usb]
 [<ffffffffa071da4e>] rtsx_usb_ms_handle_req+0x7ce/0x9c5 [rtsx_usb_ms]
 [<ffffffff810cc60b>] ? process_one_work+0x19b/0x860
 [<ffffffff810cc6a2>] process_one_work+0x232/0x860
 [<ffffffff810cc60b>] ? process_one_work+0x19b/0x860
 [<ffffffff810ccdaa>] ? worker_thread+0xda/0x470
 [<ffffffff810ccd23>] worker_thread+0x53/0x470
 [<ffffffff810cccd0>] ? process_one_work+0x860/0x860
 [<ffffffff810d31b4>] kthread+0x104/0x120
 [<ffffffff810e7fb5>] ? local_clock+0x25/0x30
 [<ffffffff810d30b0>] ? kthread_create_on_node+0x250/0x250
 [<ffffffff8187fb7c>] ret_from_fork+0x7c/0xb0
 [<ffffffff810d30b0>] ? 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/