From: Felipe Balbi <felipe.balbi@linux.intel.com>
To: Alan Stern <stern@rowland.harvard.edu>,
Peter Zijlstra <peterz@infradead.org>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Ingo Molnar <mingo@redhat.com>,
USB list <linux-usb@vger.kernel.org>,
Kernel development list <linux-kernel@vger.kernel.org>,
Will Deacon <will.deacon@arm.com>
Subject: Re: Memory barrier needed with wake_up_process()?
Date: Wed, 07 Sep 2016 13:12:40 +0300 [thread overview]
Message-ID: <87oa40koh3.fsf@linux.intel.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1609061043420.1951-100000@iolanthe.rowland.org>
[-- Attachment #1: Type: text/plain, Size: 4809 bytes --]
Hi,
Alan Stern <stern@rowland.harvard.edu> writes:
> On Tue, 6 Sep 2016, Peter Zijlstra wrote:
>
>> On Tue, Sep 06, 2016 at 01:49:37PM +0200, Peter Zijlstra wrote:
>> > On Tue, Sep 06, 2016 at 02:43:39PM +0300, Felipe Balbi wrote:
>>
>> > > My fear now, however, is that changing smp_[rw]mb() to smp_mb() just
>> > > adds extra overhead which makes the problem much, much less likely to
>> > > happen. Does that sound plausible to you?
>> >
>> > I did consider that, but I've not sufficiently grokked the code to rule
>> > out actual fail. So let me stare at this a bit more.
>>
>> OK, so I'm really not seeing it, we've got:
>>
>> while (bh->state != FULL) {
>> for (;;) {
>> set_current_state(INTERRUPTIBLE); /* MB after */
>> if (signal_pending(current))
>> return -EINTR;
>> if (common->thread_wakeup_needed)
>> break;
>> schedule(); /* MB */
>> }
>> __set_current_state(RUNNING);
>> common->thread_wakeup_needed = 0;
>> smp_rmb(); /* NOP */
>> }
>>
>>
>> VS.
>>
>>
>> spin_lock(&common->lock); /* MB */
>> bh->state = FULL;
>> smp_wmb(); /* NOP */
>> common->thread_wakeup_needed = 1;
>> wake_up_process(common->thread_task); /* MB before */
>> spin_unlock(&common->lock);
>>
>>
>>
>> (the MB annotations specific to x86, not true in general)
>>
>>
>> If we observe thread_wakeup_needed, we must also observe bh->state.
>>
>> And the sleep/wakeup ordering is also correct, we either see
>> thread_wakeup_needed and continue, or we see task->state == RUNNING
>> (from the wakeup) and NO-OP schedule(). The MB from set_current_statE()
>> then matches with the MB from wake_up_process() to ensure we must see
>> thead_wakeup_needed.
>>
>> Or, we go sleep, and get woken up, at which point the same happens.
>> Since the waking CPU gets the task back on its RQ the happens-before
>> chain includes the waking CPUs state along with the state of the task
>> itself before it went to sleep.
>>
>> At which point we're back where we started, once we see
>> thread_wakeup_needed we must then also see bh->state (and all state
>> prior to that on the waking CPU).
>>
>>
>>
>> There's enough cruft in the while-sleep loop to force reload bh->state.
>>
>> Load/store tearing cannot be a problem because all values are single
>> bytes (the variables are multi bytes, but all values used only affect
>> the LSB).
>>
>> Colour me puzzled.
>
> Felipe, can you please try this patch on an unmodified tree? If the
> problem still occurs, what shows up in the kernel log?
>
> Alan Stern
>
>
>
> Index: usb-4.x/drivers/usb/gadget/function/f_mass_storage.c
> ===================================================================
> --- usb-4.x.orig/drivers/usb/gadget/function/f_mass_storage.c
> +++ usb-4.x/drivers/usb/gadget/function/f_mass_storage.c
> @@ -485,6 +485,8 @@ static void bulk_out_complete(struct usb
> spin_lock(&common->lock);
> bh->outreq_busy = 0;
> bh->state = BUF_STATE_FULL;
> + if (bh->bulk_out_intended_length == US_BULK_CB_WRAP_LEN)
> + INFO(common, "compl: bh %p state %d\n", bh, bh->state);
> wakeup_thread(common);
> spin_unlock(&common->lock);
> }
> @@ -2207,6 +2209,7 @@ static int get_next_command(struct fsg_c
> rc = sleep_thread(common, true);
> if (rc)
> return rc;
> + INFO(common, "next: bh %p state %d\n", bh, bh->state);
> }
> smp_rmb();
> rc = fsg_is_set(common) ? received_cbw(common->fsg, bh) : -EIO;
I've replace INFO() with trace_printk() (which is what I have been using
anyway):
diff --git a/drivers/usb/gadget/function/f_mass_storage.c b/drivers/usb/gadget/function/f_mass_storage.c
index 2505117e88e8..dbc6a380b38b 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -485,6 +485,8 @@ static void bulk_out_complete(struct usb_ep *ep, struct usb_request *req)
spin_lock(&common->lock);
bh->outreq_busy = 0;
bh->state = BUF_STATE_FULL;
+ if (bh->bulk_out_intended_length == US_BULK_CB_WRAP_LEN)
+ trace_printk("compl: bh %p state %d\n", bh, bh->state);
wakeup_thread(common);
spin_unlock(&common->lock);
}
@@ -2207,6 +2209,7 @@ static int get_next_command(struct fsg_common *common)
rc = sleep_thread(common, true);
if (rc)
return rc;
+ trace_printk("next: bh %p state %d\n", bh, bh->state);
}
smp_rmb();
rc = fsg_is_set(common) ? received_cbw(common->fsg, bh) : -EIO;
But I can't reproduce as reliably as before. I'll keep the thing running
an infinite loop which will stop only when interrupts in UDC (dwc3 in
this case) stop increasing.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]
next prev parent reply other threads:[~2016-09-07 10:13 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-02 18:10 Memory barrier needed with wake_up_process()? Alan Stern
2016-09-02 18:47 ` Paul E. McKenney
2016-09-02 20:29 ` Alan Stern
2016-09-03 9:07 ` Paul E. McKenney
2016-09-03 12:31 ` Peter Zijlstra
2016-09-03 14:26 ` Alan Stern
2016-09-03 14:49 ` Alan Stern
2016-09-05 8:33 ` Peter Zijlstra
2016-09-05 15:29 ` Alan Stern
2016-09-06 11:36 ` Peter Zijlstra
2016-09-06 11:43 ` Felipe Balbi
2016-09-06 11:49 ` Peter Zijlstra
2016-09-06 12:20 ` Peter Zijlstra
2016-09-06 14:46 ` Alan Stern
2016-09-06 15:05 ` Peter Zijlstra
2016-09-07 10:12 ` Felipe Balbi [this message]
2016-09-09 10:36 ` Felipe Balbi
2016-09-09 16:12 ` Alan Stern
2016-09-19 11:11 ` Felipe Balbi
2016-09-19 17:35 ` Alan Stern
2016-09-20 10:12 ` Felipe Balbi
2016-09-20 12:53 ` Felipe Balbi
2016-09-20 14:40 ` Alan Stern
2017-01-16 11:12 ` Felipe Balbi
2017-01-16 17:09 ` Alan Stern
2017-01-16 19:04 ` Felipe Balbi
2017-01-16 19:19 ` Felipe Balbi
2016-09-02 19:18 ` Peter Zijlstra
2016-09-02 20:16 ` Alan Stern
2016-09-02 22:14 ` Peter Zijlstra
2016-09-02 22:16 ` Peter Zijlstra
2016-09-05 9:43 ` Will Deacon
2016-09-06 11:10 ` Peter Zijlstra
2016-09-02 22:16 ` Peter Zijlstra
2016-09-03 6:58 ` Felipe Balbi
2016-09-03 12:19 ` Peter Zijlstra
2016-09-03 13:51 ` Felipe Balbi
2016-09-05 8:09 ` Peter Zijlstra
2016-09-03 14:16 ` Alan Stern
2016-09-05 8:08 ` Peter Zijlstra
2016-09-05 14:33 ` Alan Stern
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=87oa40koh3.fsf@linux.intel.com \
--to=felipe.balbi@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=stern@rowland.harvard.edu \
--cc=will.deacon@arm.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.