All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chen Yu <chenyu56@huawei.com>
To: <gregkh@linuxfoundation.org>
Cc: <wangbinghui@hisilicon.com>, <linux-kernel@vger.kernel.org>,
	<linux-usb@vger.kernel.org>, John Stultz <john.stultz@linaro.org>,
	"Amit Pundir" <amit.pundir@linaro.org>,
	Guodong Xu <guodong.xu@linaro.org>,
	<felipe.balbi@linux.intel.com>, <mina86@mina86.com>
Subject: BUG: scheduling while atomic in f_fs when gadget remove driver
Date: Tue, 27 Sep 2016 17:44:18 +0800	[thread overview]
Message-ID: <205cfce1-d54c-262d-f939-ad9f37b0c52c@huawei.com> (raw)

Hi All,

I'm working on Hikey board based around the HiSilicon Kirin 620, with linaro kernel version 4.8.rc1 and I
get below BUG error while extracting USB cable from PC.

The funtion using f_fs is adb and usb_gadget_unregister_driver will be called after extracting USB cable from PC.

[   89.456512s][pid:1,cpu1,init]BUG: scheduling while atomic: init/1/0x00000002
[   89.456573s]Modules linked in:
[   89.456604s]Preemption disabled at:[<ffffffc0006a6dc0>] composite_disconnect+0x30/0xac
[   89.456665s][pid:1,cpu1,init]TGID: 1 Comm: init
[   89.456695s][pid:1,cpu1,init]Call trace:
[   89.456726s][pid:1,cpu1,init][<ffffffc00008a5e0>] dump_backtrace+0x0/0x15c
[   89.456756s][pid:1,cpu1,init][<ffffffc00008a75c>] show_stack+0x20/0x28
[   89.456756s][pid:1,cpu1,init][<ffffffc001153714>] dump_stack+0x84/0xa8
[   89.456787s][pid:1,cpu1,init][<ffffffc0000cfc5c>] __schedule_bug+0x88/0xdc
[   89.456817s][pid:1,cpu1,init][<ffffffc00115c4f0>] __schedule+0x714/0x854
[   89.456817s][pid:1,cpu1,init][<ffffffc00115c678>] schedule+0x48/0xa4
[   89.456817s][pid:1,cpu1,init][<ffffffc00115cbf0>] schedule_preempt_disabled+0x4c/0xf4
[   89.456848s][pid:1,cpu1,init][<ffffffc00115ea90>] __mutex_lock_slowpath+0xbc/0x1a4
[   89.456878s][pid:1,cpu1,init][<ffffffc00115ebd8>] mutex_lock+0x60/0x64
[   89.456878s][pid:1,cpu1,init][<ffffffc0006beb00>] ffs_func_eps_disable.isra.17+0x54/0x114
[   89.456909s][pid:1,cpu1,init][<ffffffc0006c05a4>] ffs_func_disable+0x30/0xa0
[   89.456909s][pid:1,cpu1,init][<ffffffc0006a6c4c>] reset_config.isra.8+0x44/0x78
[   89.456939s][pid:1,cpu1,init][<ffffffc0006a6dd8>] composite_disconnect+0x48/0xac
[   89.456939s][pid:1,cpu1,init][<ffffffc0006aafd4>] android_disconnect+0x48/0x54
[   89.456970s][pid:1,cpu1,init][<ffffffc0006ad9d0>] usb_gadget_remove_driver+0x58/0xa0
[   89.456970s][pid:1,cpu1,init][<ffffffc0006ada90>] usb_gadget_unregister_driver+0x78/0xc4

I checked the codes of composite_disconnect and found spin_lock_irqsave called before reset_config in which
ffs_func_eps_disable is called.

void composite_disconnect(struct usb_gadget *gadget)
{
        struct usb_composite_dev        *cdev = get_gadget_data(gadget);
        unsigned long                   flags;

        /* REVISIT:  should we have config and device level
         * disconnect callbacks?
         */
        spin_lock_irqsave(&cdev->lock, flags);
        if (cdev->config)
                reset_config(cdev);
        if (cdev->driver->disconnect)
                cdev->driver->disconnect(cdev);
        spin_unlock_irqrestore(&cdev->lock, flags);
}

static void ffs_func_eps_disable(struct ffs_function *func)
{
        struct ffs_ep *ep         = func->eps;
        struct ffs_epfile *epfile = func->ffs->epfiles;
        unsigned count            = func->ffs->eps_count;
        unsigned long flags;

        do {
                if (epfile)
                        mutex_lock(&epfile->mutex);
                spin_lock_irqsave(&func->ffs->eps_lock, flags);
                /* pending requests get nuked */
                if (likely(ep->ep))
                        usb_ep_disable(ep->ep);
                ++ep;
                spin_unlock_irqrestore(&func->ffs->eps_lock, flags);

                if (epfile) {
                        epfile->ep = NULL;
                        kfree(epfile->read_buffer);
                        epfile->read_buffer = NULL;
                        mutex_unlock(&epfile->mutex);
                        ++epfile;
                }
        } while (--count);
}

Should the epfile->read_buffer be cleared another place and the mutex_lock can be removed in ffs_func_eps_disable?

Thanks and Regards
Chen Yu

             reply	other threads:[~2016-09-27  9:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-27  9:44 Chen Yu [this message]
2016-09-27 10:01 ` BUG: scheduling while atomic in f_fs when gadget remove driver Felipe Balbi
2016-09-28  9:47   ` Chen Yu
2016-09-28 16:31     ` Michal Nazarewicz
2016-09-28 21:38       ` Michal Nazarewicz
2016-09-30  1:49         ` Chen Yu
2016-10-03 19:19         ` John Stultz
2016-10-03 20:07           ` Michal Nazarewicz
2016-10-03 20:16             ` John Stultz
2016-10-03 23:36               ` John Stultz
2016-10-04  0:07 ` [PATCH 1/2] usb: gadget: f_fs: edit epfile->ep under lock Michal Nazarewicz
2016-10-04  0:07   ` [PATCH 2/2] usb: gadget: f_fs: stop sleeping in ffs_func_eps_disable Michal Nazarewicz
2016-10-04  0:26     ` John Stultz
2016-10-08  6:52     ` Chen Yu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=205cfce1-d54c-262d-f939-ad9f37b0c52c@huawei.com \
    --to=chenyu56@huawei.com \
    --cc=amit.pundir@linaro.org \
    --cc=felipe.balbi@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=guodong.xu@linaro.org \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mina86@mina86.com \
    --cc=wangbinghui@hisilicon.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.