All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Nazarewicz <mina86@mina86.com>
To: Wei.Yang@windriver.com, stern@rowland.harvard.edu
Cc: balbi@ti.com, andrzej.p@samsung.com, wei.yang@windriver.com,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] USB:gadget: Fix a warning while loading g_mass_storage
Date: Fri, 13 Jun 2014 11:44:51 +0200	[thread overview]
Message-ID: <xa1td2ednnxo.fsf@mina86.com> (raw)
In-Reply-To: <1402294798-27401-1-git-send-email-Wei.Yang@windriver.com>

On Mon, Jun 09 2014, Wei.Yang@windriver.com wrote:
> From: Yang Wei <Wei.Yang@windriver.com>
>
> While loading g_mass_storage module, the following warning
> is triggered.
>
> WARNING: at drivers/usb/gadget/composite.c:
> usb_composite_setup_continue: Unexpected call
> Modules linked in: fat vfat minix nls_cp437 nls_iso8859_1 g_mass_storage
> [<800179cc>] (unwind_backtrace+0x0/0x104) from [<80619608>] (dump_stack+0x20/0x24)
> [<80619608>] (dump_stack+0x20/0x24) from [<80025100>] (warn_slowpath_common+0x64/0x74)
> [<80025100>] (warn_slowpath_common+0x64/0x74) from [<800251cc>] (warn_slowpath_fmt+0x40/0x48)
> [<800251cc>] (warn_slowpath_fmt+0x40/0x48) from [<7f047774>] (usb_composite_setup_continue+0xb4/0xbc [g_mass_storage])
> [<7f047774>] (usb_composite_setup_continue+0xb4/0xbc [g_mass_storage]) from [<7f047ad4>] (handle_exception+0x358/0x3e4 [g_mass_storage])
> [<7f047ad4>] (handle_exception+0x358/0x3e4 [g_mass_storage]) from [<7f048080>] (fsg_main_thread+0x520/0x157c [g_mass_storage])
> [<7f048080>] (fsg_main_thread+0x520/0x157c [g_mass_storage]) from [<8004bc90>] (kthread+0x98/0x9c)
> [<8004bc90>] (kthread+0x98/0x9c) from [<8000faec>] (kernel_thread_exit+0x0/0x8)
>
> The root cause is that the existing code fails to take into
> account the possibility that common->new_fsg can change while
> do_set_interface() is running, because the spinlock isn't held
> at this point.

common->new_fsg is not protected by common->lock so this justification
is not valid.

>
> Signed-off-by: Yang Wei <Wei.Yang@windriver.com>
> Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> ---
>  drivers/usb/gadget/f_mass_storage.c |    6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> Hi Alan,
>
> Thanks for your review, there are a few changes in v3:
>
> 1) Fix a coding style issue.
> 2) Refine the commit log
>
> Regards
> Wei
>
> diff --git a/drivers/usb/gadget/f_mass_storage.c b/drivers/usb/gadget/f_mass_storage.c
> index b963939..0cd8f21 100644
> --- a/drivers/usb/gadget/f_mass_storage.c
> +++ b/drivers/usb/gadget/f_mass_storage.c
> @@ -2342,6 +2342,7 @@ static void handle_exception(struct fsg_common *common)
>  	struct fsg_buffhd	*bh;
>  	enum fsg_state		old_state;
>  	struct fsg_lun		*curlun;
> +	struct fsg_dev		*new_fsg;
>  	unsigned int		exception_req_tag;
>  
>  	/*
> @@ -2421,6 +2422,7 @@ static void handle_exception(struct fsg_common *common)
>  		}
>  		common->state = FSG_STATE_IDLE;
>  	}
> +	new_fsg = common->new_fsg;

Also, because common->new_fsg is not protected by common->lock, doing
this under a lock is kinda pointless.

>  	spin_unlock_irq(&common->lock);
>  
>  	/* Carry out any extra actions required for the exception */
> @@ -2460,8 +2462,8 @@ static void handle_exception(struct fsg_common *common)
>  		break;
>  
>  	case FSG_STATE_CONFIG_CHANGE:
> -		do_set_interface(common, common->new_fsg);
> -		if (common->new_fsg)
> +		do_set_interface(common, new_fsg);
> +		if (new_fsg)
>  			usb_composite_setup_continue(common->cdev);

As far as I can tell, it's safe to move the assignment to new_fsg here,
e.g.:

		new_fsg = common->new_fsg;
		do_set_interface(common, new_fsg);
		if (new_fsg)
			usb_composite_setup_continue(common->cdev);

>  		break;

But perhaps new_fsg should be protected by the lock.  I think valid fix
(which I did not test in *any* way) will be this:

-------------- >8 ------------------------------------------------------------

>From 1d0b638fab05489dfb52a96556b73e2670ab52ee Mon Sep 17 00:00:00 2001
From: Michal Nazarewicz <mina86@mina86.com>
Date: Fri, 13 Jun 2014 11:40:45 +0200
Subject: [PATCH] usb: gadget: f_mass_storage: Fix a warning while loading
 g_mass_storage

While loading g_mass_storage module, the following warning can
trigger:

WARNING: at drivers/usb/gadget/composite.c:
usb_composite_setup_continue: Unexpected call
Modules linked in: fat vfat minix nls_cp437 nls_iso8859_1 g_mass_storage
[<800179cc>] (unwind_backtrace+0x0/0x104) from [<80619608>] (dump_stack+0x20/0x24)
[<80619608>] (dump_stack+0x20/0x24) from [<80025100>] (warn_slowpath_common+0x64/0x74)
[<80025100>] (warn_slowpath_common+0x64/0x74) from [<800251cc>] (warn_slowpath_fmt+0x40/0x48)
[<800251cc>] (warn_slowpath_fmt+0x40/0x48) from [<7f047774>] (usb_composite_setup_continue+0xb4/0xbc [g_mass_storage])
[<7f047774>] (usb_composite_setup_continue+0xb4/0xbc [g_mass_storage]) from [<7f047ad4>] (handle_exception+0x358/0x3e4 [g_mass_storage])
[<7f047ad4>] (handle_exception+0x358/0x3e4 [g_mass_storage]) from [<7f048080>] (fsg_main_thread+0x520/0x157c [g_mass_storage])
[<7f048080>] (fsg_main_thread+0x520/0x157c [g_mass_storage]) from [<8004bc90>] (kthread+0x98/0x9c)
[<8004bc90>] (kthread+0x98/0x9c) from [<8000faec>] (kernel_thread_exit+0x0/0x8)

The root cause is that the existing code fails to take into account
the possibility that common->new_fsg can change while
do_set_interface() is running, because the spinlock does not protect
it.

Change the code so that the common->new_fsg field is protected by the
common->lock spin lock.

Reported-By: Yang Wei <Wei.Yang@windriver.com>
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
---
 drivers/usb/gadget/f_mass_storage.c | 54 +++++++++++++++++++++++--------------
 1 file changed, 34 insertions(+), 20 deletions(-)

diff --git a/drivers/usb/gadget/f_mass_storage.c b/drivers/usb/gadget/f_mass_storage.c
index b963939..bd663c2 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -264,7 +264,7 @@ struct fsg_common {
 	/* filesem protects: backing files in use */
 	struct rw_semaphore	filesem;
 
-	/* lock protects: state, all the req_busy's */
+	/* lock protects: state, all the req_busy's, and new_fsg */
 	spinlock_t		lock;
 
 	struct usb_ep		*ep0;		/* Copy of gadget->ep0 */
@@ -407,23 +407,39 @@ static void wakeup_thread(struct fsg_common *common)
 		wake_up_process(common->thread_task);
 }
 
-static void raise_exception(struct fsg_common *common, enum fsg_state new_state)
+static void __raise_exception(struct fsg_common *common,
+			      enum fsg_state new_state)
 {
-	unsigned long		flags;
-
 	/*
 	 * Do nothing if a higher-priority exception is already in progress.
 	 * If a lower-or-equal priority exception is in progress, preempt it
 	 * and notify the main thread by sending it a signal.
 	 */
+	if (common->state > new_state)
+		return;
+
+	common->exception_req_tag = common->ep0_req_tag;
+	common->state = new_state;
+	if (common->thread_task)
+		send_sig_info(SIGUSR1, SEND_SIG_FORCED, common->thread_task);
+}
+
+static void raise_exception(struct fsg_common *common, enum fsg_state new_state)
+{
+	unsigned long		flags;
 	spin_lock_irqsave(&common->lock, flags);
-	if (common->state <= new_state) {
-		common->exception_req_tag = common->ep0_req_tag;
-		common->state = new_state;
-		if (common->thread_task)
-			send_sig_info(SIGUSR1, SEND_SIG_FORCED,
-				      common->thread_task);
-	}
+	__raise_exception(common, new_state);
+	spin_unlock_irqrestore(&common->lock, flags);
+}
+
+static void raise_config_change_exception(struct fsg_common *common,
+					  struct fsg_dev *new_fsg)
+{
+	unsigned long		flags;
+
+	spin_lock_irqsave(&common->lock, flags);
+	common->new_fsg = new_fsg;
+	__raise_exception(common, FSG_STATE_CONFIG_CHANGE);
 	spin_unlock_irqrestore(&common->lock, flags);
 }
 
@@ -2320,16 +2336,14 @@ reset:
 static int fsg_set_alt(struct usb_function *f, unsigned intf, unsigned alt)
 {
 	struct fsg_dev *fsg = fsg_from_func(f);
-	fsg->common->new_fsg = fsg;
-	raise_exception(fsg->common, FSG_STATE_CONFIG_CHANGE);
+	raise_config_change_exception(fsg->common, fsg);
 	return USB_GADGET_DELAYED_STATUS;
 }
 
 static void fsg_disable(struct usb_function *f)
 {
 	struct fsg_dev *fsg = fsg_from_func(f);
-	fsg->common->new_fsg = NULL;
-	raise_exception(fsg->common, FSG_STATE_CONFIG_CHANGE);
+	raise_config_change_exception(fsg->common, NULL);
 }
 
 
@@ -2342,6 +2356,7 @@ static void handle_exception(struct fsg_common *common)
 	struct fsg_buffhd	*bh;
 	enum fsg_state		old_state;
 	struct fsg_lun		*curlun;
+	struct fsg_dev		*new_fsg;
 	unsigned int		exception_req_tag;
 
 	/*
@@ -2405,6 +2420,7 @@ static void handle_exception(struct fsg_common *common)
 	common->next_buffhd_to_drain = &common->buffhds[0];
 	exception_req_tag = common->exception_req_tag;
 	old_state = common->state;
+	new_fsg = common->new_fsg;
 
 	if (old_state == FSG_STATE_ABORT_BULK_OUT)
 		common->state = FSG_STATE_STATUS_PHASE;
@@ -2460,8 +2476,8 @@ static void handle_exception(struct fsg_common *common)
 		break;
 
 	case FSG_STATE_CONFIG_CHANGE:
-		do_set_interface(common, common->new_fsg);
-		if (common->new_fsg)
+		do_set_interface(common, new_fsg);
+		if (new_fsg)
 			usb_composite_setup_continue(common->cdev);
 		break;
 
@@ -3178,8 +3194,7 @@ static void fsg_unbind(struct usb_configuration *c, struct usb_function *f)
 
 	DBG(fsg, "unbind\n");
 	if (fsg->common->fsg == fsg) {
-		fsg->common->new_fsg = NULL;
-		raise_exception(fsg->common, FSG_STATE_CONFIG_CHANGE);
+		raise_config_change_exception(fsg->common, NULL);
 		/* FIXME: make interruptible or killable somehow? */
 		wait_event(common->fsg_wait, common->fsg != fsg);
 	}
@@ -3665,4 +3680,3 @@ void fsg_config_from_params(struct fsg_config *cfg,
 	cfg->fsg_num_buffers = fsg_num_buffers;
 }
 EXPORT_SYMBOL_GPL(fsg_config_from_params);
-
-- 
2.0.0.526.g5318336


  parent reply	other threads:[~2014-06-13  9:45 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-03  9:37 [PATCH v1] USB:gadget: Fix a warning while loading g_mass_storage Wei.Yang
2014-06-03 14:48 ` Alan Stern
2014-06-04  1:20   ` Yang,Wei
2014-06-04  1:45     ` Peter Chen
2014-06-04  3:16       ` Yang,Wei
2014-06-04  4:41         ` Peter Chen
2014-06-04 13:56         ` Alan Stern
2014-06-04 18:48           ` Paul Zimmerman
2014-06-05  1:30           ` Peter Chen
2014-06-05 14:21             ` Alan Stern
2014-06-04  2:34     ` Yang,Wei
2014-06-04 12:06   ` Andrzej Pietrasiewicz
2014-06-04 15:26     ` Alan Stern
2014-06-05 10:00       ` Andrzej Pietrasiewicz
2014-06-05 18:10         ` Alan Stern
2014-06-04  4:32 ` [PATCH v2] " Wei.Yang
2014-06-05 18:08   ` Alan Stern
2014-06-09  6:02     ` Yang,Wei
2014-06-09  6:19   ` [PATCH v3] " Wei.Yang
2014-06-13  6:22     ` Yang,Wei
2014-06-13 13:39       ` Alan Stern
2014-06-14 13:10         ` Yang,Wei
2014-06-13  9:44     ` Michal Nazarewicz [this message]
2014-06-13 13:43       ` Alan Stern
2014-06-13 14:57         ` Michal Nazarewicz
2014-06-15  2:40   ` [PATCH] " Wei.Yang
2014-06-15  2:42     ` Yang,Wei
2014-06-17  5:59       ` Yang,Wei
2014-06-17 14:18         ` Alan Stern
2014-06-18  1:08           ` Yang,Wei
2014-06-18 11:44             ` Michal Nazarewicz
2014-06-18 14:22               ` Alan Stern
2014-06-19  1:48               ` Yang,Wei
2014-06-17 18:20     ` Michal Nazarewicz

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=xa1td2ednnxo.fsf@mina86.com \
    --to=mina86@mina86.com \
    --cc=Wei.Yang@windriver.com \
    --cc=andrzej.p@samsung.com \
    --cc=balbi@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /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.