All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@kernel.org>
To: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
	linux-usb@vger.kernel.org,
	Philipp Gesang <philipp.gesang@intra2net.com>,
	Ingo Molnar <mingo@kernel.org>
Cc: John Youn <John.Youn@synopsys.com>,
	Alan Stern <stern@rowland.harvard.edu>,
	stable@vger.kernel.org
Subject: Re: [PATCH v2 2/2] usb: gadget: f_mass_storage: Serialize wake and sleep execution
Date: Tue, 16 May 2017 11:09:24 +0300	[thread overview]
Message-ID: <87tw4lw7d7.fsf@linux.intel.com> (raw)
In-Reply-To: <a69a607e9b92156f97d4ba5e2a6c4177eeb2aea7.1494546251.git.thinhn@synopsys.com>

[-- Attachment #1: Type: text/plain, Size: 2548 bytes --]


Hi,

Thinh Nguyen <Thinh.Nguyen@synopsys.com> writes:
> f_mass_storage has a memorry barrier issue with the sleep and wake
> functions that can cause a deadlock. This results in intermittent hangs
> during MSC file transfer. The host will reset the device after receiving
> no response to resume the transfer. This issue is seen when dwc3 is
> processing 2 transfer-in-progress events at the same time, invoking
> completion handlers for CSW and CBW. Also this issue occurs depending on
> the system timing and latency.
>
> To increase the chance to hit this issue, you can force dwc3 driver to
> wait and process those 2 events at once by adding a small delay (~100us)
> in dwc3_check_event_buf() whenever the request is for CSW and read the
> event count again. Avoid debugging with printk and ftrace as extra
> delays and memory barrier will mask this issue.
>
> Scenario which can lead to failure:
> -----------------------------------
> 1) The main thread sleeps and waits for the next command in
>    get_next_command().
> 2) bulk_in_complete() wakes up main thread for CSW.
> 3) bulk_out_complete() tries to wake up the running main thread for CBW.
> 4) thread_wakeup_needed is not loaded with correct value in
>    sleep_thread().
> 5) Main thread goes to sleep again.
>
> The pattern is shown below. Note the 2 critical variables.
>  * common->thread_wakeup_needed
>  * bh->state
>
> 	CPU 0 (sleep_thread)		CPU 1 (wakeup_thread)
> 	==============================  ===============================
>
> 					bh->state = BH_STATE_FULL;
> 					smp_wmb();
> 	thread_wakeup_needed = 0;	thread_wakeup_needed = 1;
> 	smp_rmb();
> 	if (bh->state != BH_STATE_FULL)
> 		sleep again ...
>
> As pointed out by Alan Stern, this is an R-pattern issue. The issue can
> be seen when there are two wakeups in quick succession. The
> thread_wakeup_needed can be overwritten in sleep_thread, and the read of
> the bh->state maybe reordered before the write to thread_wakeup_needed.
>
> This patch applies full memory barrier smp_mb() in both sleep_thread()
> and wakeup_thread() to ensure the order which the thread_wakeup_needed
> and bh->state are written and loaded.
>
> However, a better solution in the future would be to use wait_queue
> method that takes care of managing memory barrier between waker and
> waiter.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>

Alan, just to make sure you're okay with this patch. Can I have your
acked-by?

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2017-05-16  8:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-12  0:26 [PATCH v2 1/2] usb: dwc3: gadget: Prevent losing events in event cache Thinh Nguyen
2017-05-12  0:26 ` [PATCH v2 2/2] usb: gadget: f_mass_storage: Serialize wake and sleep execution Thinh Nguyen
2017-05-16  8:09   ` Felipe Balbi [this message]
2017-05-16 13:58     ` Alan Stern
2017-05-18 22:26   ` Thinh Nguyen

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=87tw4lw7d7.fsf@linux.intel.com \
    --to=balbi@kernel.org \
    --cc=John.Youn@synopsys.com \
    --cc=Thinh.Nguyen@synopsys.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=philipp.gesang@intra2net.com \
    --cc=stable@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.