RE: [PATCH v7 01/10] usb: gadget: udc: Add timer support for usb requests

2018-12-04 Thread Alan Stern
ams() > we can add an configfs entry in stream gadget to update the timeout. Please > provide > your opinion on this approach. Since the purpose of the timeout is to detect a deadlock caused by a hardware bug, I suggest a fixed and relatively short timeout value such as one second. Cancelling and requeuing a few requests at 1-second intervals shouldn't add very much overhead. Alan Stern

RE: [PATCH v7 01/10] usb: gadget: udc: Add timer support for usb requests

2018-12-03 Thread Alan Stern
t;way to tell when the host wants to start the transfer. > > Yes , I agree with you that the timeout may vary from usage to usage. This > timeout > should be decided by the class driver which queues the request. As discussed > above > this issue was observed in streaming protocol

Re: [PATCH 0/3] tools/memory-model: Add SRCU support

2018-11-16 Thread Alan Stern
On Thu, 15 Nov 2018, Paul E. McKenney wrote: > On Thu, Nov 15, 2018 at 11:19:24AM -0500, Alan Stern wrote: > > Paul and other LKMM maintainers: > > > > The following series of patches adds support for SRCU to the Linux > > Kernel Memory Model. That is,

Re: [PATCH 2/3] tools/memory-model: Refactor some RCU relations

2018-11-15 Thread Alan Stern
On Fri, 16 Nov 2018, Boqun Feng wrote: > > -let rcu-rscsi = po ; rcu-rscs^-1 ; po? > > +let rcu-gp = [Sync-rcu](* Compare with gp *) > > +let rcu-rscsi = rcu-rscs^-1 > > Isn't it more straight-forward to use "rcu-rscs^-1" other than > "rcu-rscsi" in the definition of "rcu-fence", is

[PATCH 3/3] tools/memory-model: Add SRCU support

2018-11-15 Thread Alan Stern
bell) were written by Luc Maranget. Signed-off-by: Alan Stern CC: Luc Maranget --- tools/memory-model/linux-kernel.bell | 25 + tools/memory-model/linux-kernel.cat | 18 ++ tools/memory-model/linux-kernel.def |5 + 3 files changed, 44 insert

[PATCH 2/3] tools/memory-model: Refactor some RCU relations

2018-11-15 Thread Alan Stern
for SRCU, we will have to use the loc relation to check that the terms at the start and end of each disjunct in the definition of rcu-fence refer to the same srcu_struct location. If these terms are hidden behind po and po?, there's no way to carry out this check. Signed-off-by: Alan Stern

[PATCH 1/3] tools/memory-model: Rename some RCU relations

2018-11-15 Thread Alan Stern
luded mostly to show that it could be done. Rather than add equivalent unnecessary code for SRCU lock nesting, it seemed better to remove the existing code. Signed-off-by: Alan Stern --- tools/memory-model/linux-kernel.bell |9 +++-- tools/memory-model/linux-kernel.cat | 1

[PATCH 0/3] tools/memory-model: Add SRCU support

2018-11-15 Thread Alan Stern
Paul and other LKMM maintainers: The following series of patches adds support for SRCU to the Linux Kernel Memory Model. That is, it adds the srcu_read_lock(), srcu_read_unlock(), and synchronize_srcu() primitives to the model. Patch 1/3 does some renaming of the RCU parts of the

Re: [PATCH V3 4/6] usb: ohci-platform: Add support for Broadcom STB SoC's

2018-11-07 Thread Alan Stern
On Wed, 7 Nov 2018, Al Cooper wrote: > On 11/7/18 10:23 AM, Alan Stern wrote: > > On Tue, 6 Nov 2018, Florian Fainelli wrote: > > > >> On 11/6/18 1:40 PM, Al Cooper wrote: > >>> On 11/6/18 11:08 AM, Alan Stern wrote: > >>>> On Mon, 5 No

Re: [PATCH 4/6] usb: gadget: add functions to signal udc driver to delay status stage

2018-11-07 Thread Alan Stern
On Wed, 7 Nov 2018, Felipe Balbi wrote: > Hi, > > Alan Stern writes: > >> Alan Stern writes: > >> > There's a similar race at the hardware level. What happens if the > >> > controller receives a new SETUP packet and concurrently the driver is

Re: Interrupts, smp_load_acquire(), smp_store_release(), etc.

2018-10-21 Thread Alan Stern
On Sat, 20 Oct 2018, Paul E. McKenney wrote: > On Sat, Oct 20, 2018 at 10:22:29PM +0200, Andrea Parri wrote: > > [...] > > > > > The second (informal) litmus test has a more interesting Linux-kernel > > > counterpart: > > > > > > void t1_interrupt(void) > > > { > > > r0 =

Re: Interrupts, smp_load_acquire(), smp_store_release(), etc.

2018-10-20 Thread Alan Stern
On Sat, 20 Oct 2018, Paul E. McKenney wrote: > The second (informal) litmus test has a more interesting Linux-kernel > counterpart: > > void t1_interrupt(void) > { > r0 = READ_ONCE(y); > smp_store_release(, 1); > } > > void t1(void) > {

[tip:locking/core] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

2018-10-02 Thread tip-bot for Alan Stern
Commit-ID: 6e89e831a90172bc3d34ecbba52af5b9c4a447d1 Gitweb: https://git.kernel.org/tip/6e89e831a90172bc3d34ecbba52af5b9c4a447d1 Author: Alan Stern AuthorDate: Wed, 26 Sep 2018 11:29:17 -0700 Committer: Ingo Molnar CommitDate: Tue, 2 Oct 2018 10:28:01 +0200 tools/memory-model: Add

[PATCH v5] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

2018-09-14 Thread Alan Stern
ith the maintainers' wishes. Signed-off-by: Alan Stern Reviewed-by: Will Deacon Acked-by: Peter Zijlstra (Intel) Reviewed-by: Andrea Parri --- v.5: Incorporated feedback from Andrea regarding the updated Changelog. v.4: Added pros and cons discussion to the Changelog. v.3: Rebased against

Re: [PATCH RFC memory-model 0/7] Memory-model changes

2018-09-14 Thread Alan Stern
should not be controversial (famous last words). > > Please take a look and consider giving feedback > and/or a review/ack. What branch is this commit in? It doesn't seem to be in the lkmm branch. In any case, the change is trivial and obviously cor

Re: [PATCH RFC LKMM 1/7] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

2018-09-14 Thread Alan Stern
ng this patch would require of locks. In theory this could be ameliorated by requiring smp_cond_load_acquire() in combination with ordinary release also to be RCtso (which is currently true on all supported architectures). On future weakly ordered architectures,

Re: [PATCH RFC LKMM 1/7] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

2018-09-13 Thread Alan Stern
latively minor, and it appears mostly to boil down to a matter of opinion. Since the opinions of long-time kernel developers such as Linus, Peter, and Will carry more weight than those of Luc and Andrea, this patch changes the model in accordance with the developers' wishes. Signed-off-by: Ala

Re: [PATCH 1/5] misc: rtsx_usb: Use USB remote wakeup signaling for card insertion detection

2018-09-13 Thread Alan Stern
them? It should not be necessary to do this. Alan Stern

Re: [PATCH RFC LKMM 1/7] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

2018-09-12 Thread Alan Stern
On Tue, 11 Sep 2018, Paul E. McKenney wrote: > > I think what you meant to write in the second and third sentences was > > something more like this: > > > > Any code in an RCU critical section that extends beyond the > > end of a given RCU grace period is guaranteed to see the > >

Re: [PATCH RFC LKMM 1/7] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

2018-09-11 Thread Alan Stern
On Thu, 12 Jul 2018, Paul E. McKenney wrote: > > > Take for instance the pattern where RCU relies on RCsc locks, this is an > > > entirely simple and straight forward use of locks, yet completely fails > > > on this subtle point. > > > > Do you happen to remember exactly where in the kernel

Re: [PATCH RFC LKMM 1/7] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

2018-09-07 Thread Alan Stern
On Fri, 7 Sep 2018, Daniel Lustig wrote: > On 9/7/2018 9:09 AM, Will Deacon wrote: > > On Fri, Sep 07, 2018 at 12:00:19PM -0400, Alan Stern wrote: > >> On Thu, 6 Sep 2018, Andrea Parri wrote: > >> > >>>> Have you noticed any part of the generic code that

Re: [PATCH RFC LKMM 1/7] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

2018-09-07 Thread Alan Stern
On Thu, 6 Sep 2018, Andrea Parri wrote: > > Have you noticed any part of the generic code that relies on ordinary > > acquire-release (rather than atomic RMW acquire-release) in order to > > implement locking constructs? > > There are several places in code where the "lock-acquire" seems to be

Re: [PATCH RFC LKMM 1/7] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

2018-09-05 Thread Alan Stern
On Mon, 3 Sep 2018, Andrea Parri wrote: > I take this opportunity to summarize my viewpoint on these matters: > > Someone would have to write the commit message for the above diff ... > that is, to describe -why- we should go RCtso (and update the documen- > tation accordingly); by now, the only

Re: [PATCH RFC LKMM 1/7] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

2018-09-04 Thread Alan Stern
On Tue, 4 Sep 2018, Andrea Parri wrote: > Heh, your confusion might be the reflection of mine... ;-) That was > indeed a long and not conclusive discussion (meaning there're pending > issues); and I cannot claim to find "arguments" such as: > > "More than one kernel developer has expressed the

Re: [PATCH RFC LKMM 1/7] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

2018-09-03 Thread Alan Stern
On Mon, 3 Sep 2018, Andrea Parri wrote: > In Cat speak, > > diff --git a/tools/memory-model/linux-kernel.cat > b/tools/memory-model/linux-kernel.cat > index 59b5cbe6b6240..fd9c0831adf0a 100644 > --- a/tools/memory-model/linux-kernel.cat > +++ b/tools/memory-model/linux-kernel.cat > @@ -38,7

Re: [PATCH RFC LKMM 1/7] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

2018-08-31 Thread Alan Stern
On Fri, 31 Aug 2018, Andrea Parri wrote: > On Thu, Aug 30, 2018 at 05:31:32PM -0400, Alan Stern wrote: > > On Thu, 30 Aug 2018, Andrea Parri wrote: > > > > > > All the architectures supported by the Linux kernel (including RISC-V) > > > > do provide this

Re: [PATCH RFC LKMM 1/7] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

2018-08-30 Thread Alan Stern
hes. > > > > Signed-off-by: Alan Stern > > Signed-off-by: Paul E. McKenney > > Reviewed-by: Will Deacon > > Acked-by: Peter Zijlstra (Intel) > > Round 2 ;-), I guess... Let me start from the uncontroversial points: > > 1) being able to use the LKMM t

Re: [PATCH 4/5] memstick: rtsx_usb_ms: Support runtime power management

2018-07-25 Thread Alan Stern
put_noidle() correctly. The basic idea is to use these when you know beforehand that the device is already at full power (for _get_noresume) and the usage count will not go to 0 (for _put_noidle). If you aren't certain of these requirements then you should call pm_runtime_get_sync() and pm_runtime_put(). Alan Stern

Re: [PATCH 2/5] memstick: Prevent memstick host from getting runtime suspended during card detection

2018-07-25 Thread Alan Stern
k(struct work_struct *work) > host->set_param(host, MEMSTICK_POWER, MEMSTICK_POWER_OFF); > > mutex_unlock(>lock); > + > + pm_runtime_put_noidle(host->dev.parent); > dev_dbg(>dev, "memstick_check finished\n"); > } This should be pm_runtime_put(), not _put_noidle(). The reason is because if this call causes the PM runtime usage count to drop to 0, you do want the device to go into runtime suspend. Alan Stern

Re: [PATCH v2] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

2018-07-17 Thread Alan Stern
On Tue, 17 Jul 2018, Peter Zijlstra wrote: > Isn't ISYNC the instruction-sync pipeline flush instruction? That is > used as an smp_rmb() here to, together with the control dependency from the > LL/SC, to form a LOAD->{LOAD,STORE} (aka LOAD-ACQUIRE) ordering? That's right. > Where LWSYNC

Re: [PATCH v2] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

2018-07-17 Thread Alan Stern
isync *is* (when in that *sequence*) a memory barrier for a > store->load case (and has to be: loads inside a spinlocked region MUST > NOT be done earlier than stores outside of it!). Why not? Instructions are allowed to migrate _into_ critical sections, just not _out_ of them. So a store p

Re: [PATCH v2] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

2018-07-13 Thread Alan Stern
On Fri, 13 Jul 2018, Andrea Parri wrote: > On Fri, Jul 13, 2018 at 10:16:48AM -0700, Linus Torvalds wrote: > > On Fri, Jul 13, 2018 at 2:34 AM Will Deacon wrote: > > > > > > And, since we're stating preferences, I'll reiterate my preference > > > towards: > > > > > > * RCsc unlock/lock

Re: [PATCH v2] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

2018-07-12 Thread Alan Stern
On Thu, 12 Jul 2018, Andrea Parri wrote: > > It seems reasonable to ask people to learn that locks have stronger > > ordering guarantees than RMW atomics do. Maybe not the greatest > > situation in the world, but one I think we could live with. > > Yeah, this was one of my main objections.

Re: [PATCH v2] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

2018-07-12 Thread Alan Stern
On Thu, 12 Jul 2018, Peter Zijlstra wrote: > > But again, these are stuble patterns, and my guess is that several/ > > most kernel developers really won't care about such guarantees (and > > if some will do, they'll have the tools to figure out what they can > > actually rely on ...) > > Yes it

RE: [PATCH v3] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

2018-07-11 Thread Alan Stern
On Wed, 11 Jul 2018, David Laight wrote: > > From: Alan Stern > > Sent: 10 July 2018 19:18 > > More than one kernel developer has expressed the opinion that the LKMM > > should enforce ordering of writes by locking. In other words, given > > the following

Re: [PATCH v2] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

2018-07-11 Thread Alan Stern
On Wed, 11 Jul 2018, Andrea Parri wrote: > > > Does something like "po; [UL]; rf; [LKR]; po" fit in with the rest > > > of the model? If so, maybe that solves the asymmetry and also > > > legalizes the approach of putting fence.tso in front? > > > > That would work just as well. For this

Re: [PATCH v3] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

2018-07-10 Thread Alan Stern
On Tue, 10 Jul 2018, Paul E. McKenney wrote: > On Tue, Jul 10, 2018 at 02:18:13PM -0400, Alan Stern wrote: > > More than one kernel developer has expressed the opinion that the LKMM > > should enforce ordering of writes by locking. In other words, given > &g

[PATCH v3] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

2018-07-10 Thread Alan Stern
kernel (including RISC-V) do provide this ordering for locks, albeit for varying reasons. Therefore this patch changes the model in accordance with the developers' wishes. Signed-off-by: Alan Stern --- v.3: Rebased against the dev branch of Paul's linux-rcu tree. Changed unlock-rf-lock-po to po

Re: [PATCH v2] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

2018-07-10 Thread Alan Stern
On Tue, 10 Jul 2018, Daniel Lustig wrote: > > --- usb-4.x.orig/tools/memory-model/linux-kernel.cat > > +++ usb-4.x/tools/memory-model/linux-kernel.cat > > @@ -38,7 +38,7 @@ let strong-fence = mb | gp > > (* Release Acquire *) > > let acq-po = [Acquire] ; po ; [M] > > let po-rel = [M] ; po ;

Re: [PATCH v2] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

2018-07-10 Thread Alan Stern
On Tue, 10 Jul 2018, Andrea Parri wrote: > > > ACQUIRE operations include LOCK operations and both smp_load_acquire() > > > and smp_cond_acquire() operations. [BTW, the latter was replaced by > > > smp_cond_load_acquire() in 1f03e8d2919270 ...] > > > > > > RELEASE operations include

Re: [PATCH v2] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

2018-07-10 Thread Alan Stern
On Tue, 10 Jul 2018, Andrea Parri wrote: > On Mon, Jul 09, 2018 at 04:01:57PM -0400, Alan Stern wrote: > > More than one kernel developer has expressed the opinion that the LKMM > > should enforce ordering of writes by locking. In other words, given > > I'd like to step

Re: [PATCH v2] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

2018-07-10 Thread Alan Stern
On Mon, 9 Jul 2018, Paul E. McKenney wrote: > On Mon, Jul 09, 2018 at 04:01:57PM -0400, Alan Stern wrote: > > More than one kernel developer has expressed the opinion that the LKMM > > should enforce ordering of writes by locking. In other words, given > &g

[PATCH v2] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

2018-07-09 Thread Alan Stern
kernel (including RISC-V) do provide this ordering for locks, albeit for varying reasons. Therefore this patch changes the model in accordance with the developers' wishes. Signed-off-by: Alan Stern --- v.2: Restrict the ordering to lock operations, not general release and acquire fences. [as1871b

Re: [PATCH 2/2] tools/memory-model: Add write ordering by release-acquire and by locks

2018-07-09 Thread Alan Stern
On Mon, 9 Jul 2018, Daniel Lustig wrote: > On 7/9/2018 9:52 AM, Will Deacon wrote: > > On Fri, Jul 06, 2018 at 02:10:55PM -0700, Paul E. McKenney wrote: > >> On Fri, Jul 06, 2018 at 04:37:21PM -0400, Alan Stern wrote: > >>> On Thu, 5 Jul 2018, Andrea Parri wr

Re: LKMM patch scorecard for v4.19 merge window

2018-07-09 Thread Alan Stern
l: Rename litmus tests to comply to norm7 > > This one still needs an ack. I have audited this patch. Acked-by: Alan Stern Alan

Re: [PATCH 2/2] tools/memory-model: Add write ordering by release-acquire and by locks

2018-07-06 Thread Alan Stern
On Thu, 5 Jul 2018, Andrea Parri wrote: > > At any rate, it looks like instead of strengthening the relation, I > > should write a patch that removes it entirely. I also will add new, > > stronger relations for use with locking, essentially making spin_lock > > and spin_unlock be RCsc. > >

Re: [PATCH 2/2] tools/memory-model: Add write ordering by release-acquire and by locks

2018-07-05 Thread Alan Stern
Will: On Thu, 5 Jul 2018, Will Deacon wrote: > On Thu, Jul 05, 2018 at 10:21:36AM -0400, Alan Stern wrote: > > On Wed, 4 Jul 2018, Will Deacon wrote: > > > On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote: > > > > Would this be allowed if smp_load_acquir

Re: [PATCH 2/2] tools/memory-model: Add write ordering by release-acquire and by locks

2018-07-05 Thread Alan Stern
On Wed, 4 Jul 2018, Will Deacon wrote: > On Wed, Jul 04, 2018 at 04:28:52AM -0700, Paul E. McKenney wrote: > > On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote: > > > PS: Paul, is the patch which introduced rel-rf-acq-po currently present > > > in any of your

Re: [PATCH 2/2] tools/memory-model: Add write ordering by release-acquire and by locks

2018-07-05 Thread Alan Stern
On Wed, 4 Jul 2018, Will Deacon wrote: > Hi Alan, > > On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote: > > On Mon, 25 Jun 2018, Andrea Parri wrote: > > > > > On Fri, Jun 22, 2018 at 07:30:08PM +0100, Will Deacon wrote: > > > > > > I

Re: [PATCH 2/2] tools/memory-model: Add write ordering by release-acquire and by locks

2018-07-03 Thread Alan Stern
Will: On Mon, 25 Jun 2018, Andrea Parri wrote: > On Fri, Jun 22, 2018 at 07:30:08PM +0100, Will Deacon wrote: > > > > I think the second example would preclude us using LDAPR for > > > > load-acquire, > > > I don't think it's a moot point. We want new architectures to implement > >

Re: [PATCH 2/2] tools/memory-model: Add write ordering by release-acquire and by locks

2018-06-22 Thread Alan Stern
On Fri, 22 Jun 2018, Andrea Parri wrote: > On Thu, Jun 21, 2018 at 01:27:12PM -0400, Alan Stern wrote: > > More than one kernel developer has expressed the opinion that the LKMM > > should enforce ordering of writes by release-acquire chains and by > > locking.

Re: [PATCH 2/2] tools/memory-model: Add write ordering by release-acquire and by locks

2018-06-22 Thread Alan Stern
On Fri, 22 Jun 2018, Will Deacon wrote: > Hi Alan, > > On Fri, Jun 22, 2018 at 02:09:04PM -0400, Alan Stern wrote: > > On Fri, 22 Jun 2018, Will Deacon wrote: > > > On Thu, Jun 21, 2018 at 01:27:12PM -0400, Alan Stern wrote: > > > > More than one kernel

Re: [PATCH 2/2] tools/memory-model: Add write ordering by release-acquire and by locks

2018-06-22 Thread Alan Stern
On Fri, 22 Jun 2018, Will Deacon wrote: > Hi Alan, > > On Thu, Jun 21, 2018 at 01:27:12PM -0400, Alan Stern wrote: > > More than one kernel developer has expressed the opinion that the LKMM > > should enforce ordering of writes by release-acquire chains and by > > lock

[PATCH 2/2] tools/memory-model: Add write ordering by release-acquire and by locks

2018-06-21 Thread Alan Stern
-off-by: Alan Stern --- [as1871] tools/memory-model/Documentation/explanation.txt | 81 +++ tools/memory-model/linux-kernel.cat |2 2 files changed, 82 insertions(+), 1 deletion(-) Index: usb-4.x/tools/memory-model/linux-kernel.cat

[PATCH 1/2] tools/memory-model: Change rel-rfi-acq ordering to (rel-rf-acq-po & int)

2018-06-21 Thread Alan Stern
starting from the write-release. Signed-off-by: Alan Stern --- [as1870] tools/memory-model/Documentation/explanation.txt | 35 --- tools/memory-model/linux-kernel.cat |6 +-- 2 files changed, 22 insertions(+), 19 deletions(-) Index: usb-4.x/tools/memory

Re: [PATCH] usb: don't offload isochronous urb completions to ksoftirq

2018-06-12 Thread Alan Stern
On Tue, 12 Jun 2018, Mikulas Patocka wrote: > > > On Tue, 12 Jun 2018, Alan Stern wrote: > > > On Tue, 12 Jun 2018, Mikulas Patocka wrote: > > > > > I have a single-core machine with usb2 soundcard. When I increase mplayer > > > priority (to real-time

Re: LKMM litmus test for Roman Penyaev's rcu-rr

2018-06-07 Thread Alan Stern
On Thu, 7 Jun 2018, Paul E. McKenney wrote: > On Wed, Jun 06, 2018 at 12:23:33PM -0700, Linus Torvalds wrote: > > On Wed, Jun 6, 2018 at 12:05 PM Paul E. McKenney > > wrote: > > > > > > 3. Introduce a new marking/attribute in the .def file that indicates > > > whether an access is

Re: LKMM litmus test for Roman Penyaev's rcu-rr

2018-06-06 Thread Alan Stern
On Wed, 6 Jun 2018, Roman Penyaev wrote: > On Wed, Jun 6, 2018 at 3:54 PM, Alan Stern wrote: > > On Wed, 6 Jun 2018, Roman Penyaev wrote: > > > >> > Preserving the order of volatile accesses isn't sufficient. The > >> > compiler is still allowed to transla

Re: LKMM litmus test for Roman Penyaev's rcu-rr

2018-06-06 Thread Alan Stern
On Wed, 6 Jun 2018, Roman Penyaev wrote: > > Preserving the order of volatile accesses isn't sufficient. The > > compiler is still allowed to translate > > > > r1 = READ_ONCE(x); > > if (r1) { > > ... > > } > > WRITE_ONCE(y, r2); > > > > into

Re: LKMM litmus test for Roman Penyaev's rcu-rr

2018-06-04 Thread Alan Stern
On Sat, 2 Jun 2018, Paul E. McKenney wrote: > One crude but effective workaround is to replicate the code following the > "if" statement into both legs of the "if" statement. This has the effect > of extending the control dependency to cover all of the code that used to > follow the "if"

Re: LKMM litmus test for Roman Penyaev's rcu-rr

2018-05-31 Thread Alan Stern
On Wed, 30 May 2018, Paul E. McKenney wrote: > On Wed, May 30, 2018 at 05:01:01PM -0500, Linus Torvalds wrote: > > On Wed, May 30, 2018 at 2:08 PM Alan Stern > > wrote: > > > > > > Indeed. The very first line Linus quoted in his firs

Re: LKMM litmus test for Roman Penyaev's rcu-rr

2018-05-30 Thread Alan Stern
On Wed, 30 May 2018, Paul E. McKenney wrote: > > > My current guess is that we need to change the memory-model tool. If > > > that is the case, here are some possible resolutions: > > > > > > 1.Make herd's C-language control dependencies work the same as its > > > assembly language,

Re: LKMM litmus test for Roman Penyaev's rcu-rr

2018-05-30 Thread Alan Stern
On Wed, 30 May 2018, Paul E. McKenney wrote: > On Wed, May 30, 2018 at 09:59:28AM -0500, Linus Torvalds wrote: > > On Wed, May 30, 2018 at 9:29 AM Alan Stern > > wrote: > > > > > > > > > > Can't we simplify the whole sequence as basical

Re: LKMM litmus test for Roman Penyaev's rcu-rr

2018-05-30 Thread Alan Stern
On Wed, 30 May 2018, Linus Torvalds wrote: > On Wed, May 30, 2018 at 9:29 AM Alan Stern > wrote: > > > > > > > Can't we simplify the whole sequence as basically > > > > > > A > > > if (!B) > > > D > > > &

Re: LKMM litmus test for Roman Penyaev's rcu-rr

2018-05-30 Thread Alan Stern
On Tue, 29 May 2018, Paul E. McKenney wrote: > On Tue, May 29, 2018 at 04:10:02PM -0500, Linus Torvalds wrote: > > On Tue, May 29, 2018 at 3:49 PM Alan Stern > > wrote: > > > > > Putting this into herd would be extremely difficult, if not impossible, > >

Re: LKMM litmus test for Roman Penyaev's rcu-rr

2018-05-30 Thread Alan Stern
On Tue, 29 May 2018, Linus Torvalds wrote: > On Tue, May 29, 2018 at 3:49 PM Alan Stern > wrote: > > > Putting this into herd would be extremely difficult, if not impossible, > > because it involves analyzing code that was not executed. > > Does it? > > Can

Re: LKMM litmus test for Roman Penyaev's rcu-rr

2018-05-29 Thread Alan Stern
On Tue, 29 May 2018, Paul E. McKenney wrote: > On Tue, May 29, 2018 at 02:35:34PM -0400, Alan Stern wrote: > > On Mon, 28 May 2018, Paul E. McKenney wrote: > > > > > Hello! > > > > > > The litmus test below is a first attempt to model Roman's rcu-rr &

Re: LKMM litmus test for Roman Penyaev's rcu-rr

2018-05-29 Thread Alan Stern
On Mon, 28 May 2018, Paul E. McKenney wrote: > Hello! > > The litmus test below is a first attempt to model Roman's rcu-rr > round-robin RCU-protected linked list. His test code, which includes > the algorithm under test, may be found here: > >

Re: [RFC] driver core: don't hold dev's parent lock when using async probe

2018-05-24 Thread Alan Stern
On Thu, 24 May 2018, Martin Liu wrote: > On Tue, May 22, 2018 at 01:09:44PM -0400, Alan Stern wrote: > > On Tue, 22 May 2018, martin_liu wrote: > > > > > not sure if we still need 'bf74ad5bc417 ("[PATCH] Hold the > > > device's parent's lock during probe

Re: [PATCH] usb: hub: Per-port setting to use old enumeration scheme

2018-05-24 Thread Alan Stern
On Thu, 24 May 2018, Nicolas Boichat wrote: > On Thu, May 24, 2018 at 12:39 AM, Greg Kroah-Hartman > <gre...@linuxfoundation.org> wrote: > > On Wed, May 23, 2018 at 10:03:55AM -0400, Alan Stern wrote: > >> On Wed, 23 May 2018, Nicolas Boichat wrote: > >>

Re: [PATCH] usb: hub: Per-port setting to use old enumeration scheme

2018-05-23 Thread Alan Stern
heme_first parameter. Let's see what some other people think. Yours is a rather special case, because you know exactly what device will be attached to a specific port. Still, I can see that sort of thing happening in constrained and special-purpose settings. How do you arrange to set the new quirk before the device is discovered? Alan Stern

Re: [RFC] driver core: don't hold dev's parent lock when using async probe

2018-05-22 Thread Alan Stern
hold the device lock. During a normal probe sequence, for example, the interfaces get probed by the hub driver while it owns the device lock. But for probes under other circumstances (for example, if the user writes to the driver's "bind" attribute in sysfs), the device lock might not be held. A driver cannot tell these two cases apart. The only way to make it work all the time is to have the caller _always_ hold the device lock while the driver is probed (or the removed, for that matter). Alan Stern

Re: [PATCH v2 0/2] Re: usb-storage: Add quirks to make G-Technology "G-Drive" work

2018-05-21 Thread Alan Stern
unusual_uas.h | 9 + > 3 files changed, 24 insertions(+) Acked-by: Alan Stern <st...@rowland.harvard.edu> This is okay with me. Oliver, what do you think? Alan Stern

Re: [PATCH] usb-storage: Add quirks to make G-Technology "G-Drive" work

2018-05-18 Thread Alan Stern
; to reserve a quirk bit for what's currently only a single device known to > have this issue. Please advise. Yes, I think we want a patch. Unless Oliver disagrees, please go ahead and prepare one. Alan Stern

Re: [PATCH] usb-storage: Add quirks to make G-Technology "G-Drive" work

2018-05-17 Thread Alan Stern
with dd works fine, whereas > trying to mount a filesystem immediately crashes it. I suspect this is > because check_disk_change is called on mount (which eventually calls down > to sd_read_write_protect_flag, which is where the US_FL_NO_WP_DETECT flag > comes into play). Was this tested with uas or usb-storage? Alan Stern

Re: [usb-storage] Re: [PATCH] usb-storage: Add quirks to make G-Technology "G-Drive" work

2018-05-17 Thread Alan Stern
* is write-protected. Now that we tell the sd driver > * to do a 192-byte transfer with this command the > * majority of devices work fine, but a few still can't > * handle it. The sd driver will simply assume those > * devices are write-enabled. > */ > if (us->fflags & US_FL_NO_WP_DETECT) > sdev->skip_ms_page_3f = 1; Yeah, but that comment referred to driver that fail when they receive the MODE SENSE. Have you tried using uas _and_ setting the sdev->skip_ms_page_3f flag? Alan Stern

Re: [PATCH] usb-storage: Add quirks to make G-Technology "G-Drive" work

2018-05-16 Thread Alan Stern
On Wed, 16 May 2018, Alexander Kappner wrote: > The "G-Drive" (sold by G-Technology) external USB 3.0 drive > hangs on write access under UAS: > > [ 136.079121] sd 15:0:0:0: [sdi] tag#0 FAILED Result: hostbyte=DID_OK > driverbyte=DRIVER_SENSE > [ 136.079144] sd 15:0:0:0: [sdi] tag#0 Sense

[tip:locking/core] tools/memory-model: Improve mixed-access checking in lock.cat

2018-05-15 Thread tip-bot for Alan Stern
Commit-ID: 30b795df11a1a9dd7fc50c1ff4677343b67cb379 Gitweb: https://git.kernel.org/tip/30b795df11a1a9dd7fc50c1ff4677343b67cb379 Author: Alan Stern <st...@rowland.harvard.edu> AuthorDate: Mon, 14 May 2018 16:33:52 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:locking/core] tools/memory-model: Remove out-of-date comments and code from lock.cat

2018-05-15 Thread tip-bot for Alan Stern
Commit-ID: cee0321a404fe6b43d1f4364639c8ffe2f2b37d1 Gitweb: https://git.kernel.org/tip/cee0321a404fe6b43d1f4364639c8ffe2f2b37d1 Author: Alan Stern <st...@rowland.harvard.edu> AuthorDate: Mon, 14 May 2018 16:33:53 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:locking/core] tools/memory-model: Improve comments in lock.cat

2018-05-15 Thread tip-bot for Alan Stern
Commit-ID: fd0359dbac3df00d1c6c22769e7d647b16b920cc Gitweb: https://git.kernel.org/tip/fd0359dbac3df00d1c6c22769e7d647b16b920cc Author: Alan Stern <st...@rowland.harvard.edu> AuthorDate: Mon, 14 May 2018 16:33:51 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:locking/core] tools/memory-model: Remove duplicated code from lock.cat

2018-05-15 Thread tip-bot for Alan Stern
Commit-ID: 8559183ccaec97454b2515ac426f113967256cf9 Gitweb: https://git.kernel.org/tip/8559183ccaec97454b2515ac426f113967256cf9 Author: Alan Stern <st...@rowland.harvard.edu> AuthorDate: Mon, 14 May 2018 16:33:50 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:locking/core] tools/memory-model: Redefine rb in terms of rcu-fence

2018-05-15 Thread tip-bot for Alan Stern
Commit-ID: 9d036883a17969caf8796d1fce813af0ab016986 Gitweb: https://git.kernel.org/tip/9d036883a17969caf8796d1fce813af0ab016986 Author: Alan Stern <st...@rowland.harvard.edu> AuthorDate: Mon, 14 May 2018 16:33:40 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:locking/core] tools/memory-model: Rename link and rcu-path to rcu-link and rb

2018-05-15 Thread tip-bot for Alan Stern
Commit-ID: 1ee2da5f9b5a8e814b397b77a08d44fed5f96a4a Gitweb: https://git.kernel.org/tip/1ee2da5f9b5a8e814b397b77a08d44fed5f96a4a Author: Alan Stern <st...@rowland.harvard.edu> AuthorDate: Mon, 14 May 2018 16:33:39 -0700 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

Re: [PATCH V5] USB: Increment wakeup count on remote wakeup.

2018-04-20 Thread Alan Stern
istered is set before accessing > root_hub pointer. > V2: Fixed the build failure error due to uninitialized dev pointer. Acked-by: Alan Stern <st...@rowland.harvard.edu>

Re: [PATCH V3] USB: Increment wakeup count on remote wakeup.

2018-04-20 Thread Alan Stern
h_registered can change at any time; it is protected by the hcd_root_hub_lock spinlock. That's why I said your code should be moved inside the existing "if" statement. Alan Stern > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c > index f6ea16e9f6bb9..aa

Re: [PATCH V2] USB: Increment wakeup count on remote wakeup.

2018-04-20 Thread Alan Stern
;rh_registered is set. Therefore the assignment to dev and the call to pm_wakeup_event() should be moved within this "if" statement. The rest of the patch looks okay. Alan Stern > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c > index f6ea16e9f6bb9.

Re: [PATCH] USB: Increment wakeup count on remote wakeup.

2018-04-19 Thread Alan Stern
p the initial Clear-Suspend step for a remote wakeup */ > status = hub_port_status(hub, port1, , ); > - if (status == 0 && !port_is_suspended(hub, portstatus)) > + /* Skip the initial Clear-Suspend step for a remote wakeup */ What is the rea

Re: [PATCH] usb: storage: Replace mdelay with msleep in init_freecom

2018-04-10 Thread Alan Stern
context, init_freecom() > calls mdelay() to busily wait. > This is not necessary and can be replaced with msleep() to > avoid busy waiting. > > This is found by a static analysis tool named DCNS written by myself. > And I also manually check it. > > Signed-off-by: Jia-

Re: [PATCH 1/2] clk: at91: Added more information logging.

2018-04-08 Thread Alan Stern
->hclk)); > + dev_dbg(>dev, "iclk set to: %lu hz\n", > clk_get_rate(ohci_at91->iclk)); > + dev_dbg(>dev, "fclk set to: %lu hz\n", > clk_get_rate(ohci_at91->fclk)); Here you list all the clocks a second time and give all the frequencies. > } > > static void at91_stop_hc(struct platform_device *pdev) Alan Stern

Re: Control dependency between prior load in while condition and later store?

2018-04-05 Thread Alan Stern
On Thu, 5 Apr 2018, Peter Zijlstra wrote: > On Thu, Apr 05, 2018 at 10:35:22AM -0400, Alan Stern wrote: > > In this example, READ_ONCE() is in fact a volatile access, so we're > > okay. > > But our documentation clearly states a control-dep can only be from a > R

Re: Control dependency between prior load in while condition and later store?

2018-04-05 Thread Alan Stern
On Thu, 5 Apr 2018, Peter Zijlstra wrote: > On Wed, Apr 04, 2018 at 04:35:32PM -0400, Alan Stern wrote: > > On Wed, 4 Apr 2018, Daniel Jordan wrote: > > > > > A question for memory-barriers.txt aficionados. > > > > > > Is there a

Re: Control dependency between prior load in while condition and later store?

2018-04-04 Thread Alan Stern
On Wed, 4 Apr 2018, Daniel Jordan wrote: > A question for memory-barriers.txt aficionados. > > Is there a control dependency between the prior load of 'a' and the > later store of 'c'?: > >while (READ_ONCE(a)); >WRITE_ONCE(c, 1); I would say that yes, there is. > I have my doubts

Re: [PATCH v2 1/3] locking: Document the semantics of spin_is_locked()

2018-04-03 Thread Alan Stern
On Tue, 3 Apr 2018, Andrea Parri wrote: > On Tue, Apr 03, 2018 at 04:23:07PM +0100, David Howells wrote: > > Andrea Parri wrote: > > > > > Sorry, but I don't understand your objection: are you suggesting to add > > > something like "Always return 0 on !SMP" to

Re: [PATCH RFC tools/memory-model] Add s390.{cfg,cat}

2018-04-03 Thread Alan Stern
On Mon, 2 Apr 2018, Paul E. McKenney wrote: > > > I will look at this more later, reaching end of both battery and useful > > > attention span... > > Like the following, perhaps? > > Thanx, Paul > >

Re: [PATCH v2 1/3] locking: Document the semantics of spin_is_locked()

2018-04-02 Thread Alan Stern
linux-kernel=151981440005264=2 > > Signed-off-by: Andrea Parri <parri.and...@gmail.com> > Cc: Alan Stern <st...@rowland.harvard.edu> > Cc: Will Deacon <will.dea...@arm.com> > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Boqun Feng <boqun.f...@gmai

Re: [PATCH RFC tools/memory-model] Add s390.{cfg,cat}

2018-03-29 Thread Alan Stern
On Wed, 28 Mar 2018, Paul E. McKenney wrote: > > > In the meantime, does the cat file look to you like it correctly > > > models the combination of TSO and multicopy atomicity? Do the > > > fences really work, or did I just get lucky with my choice of > > > litmus tests? > > > > You got lucky.

Re: [PATCH RFC tools/memory-model] Add s390.{cfg,cat}

2018-03-28 Thread Alan Stern
On Wed, 28 Mar 2018, Paul E. McKenney wrote: > On Wed, Mar 28, 2018 at 11:01:25AM -0400, Alan Stern wrote: > > On Wed, 28 Mar 2018, Paul E. McKenney wrote: > > > > > Hello! > > > > > > The prototype patch shown below provides files required to allow

Re: [PATCH RFC tools/memory-model] Add s390.{cfg,cat}

2018-03-28 Thread Alan Stern
On Wed, 28 Mar 2018, Paul E. McKenney wrote: > Hello! > > The prototype patch shown below provides files required to allow herd7 to > evaluate C-language litmus tests for the multicopy-atomic TSO ordering > provided by s390. This patch should be viewed with great suspicion. > It does what I

Re: [v6] usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()

2018-03-27 Thread Alan Stern
t if you could debug this farther. I'm not sure what to suggest, however. Clearly we need to know what's going on in ohci-q.c's finish_unlinks() routine; unfortunately this routine probably gets called thousands of times before the problem shows up. Anyway, here's a patch you can try out on th

Re: [PATCH] usb: host: Remove the deprecated ATH79 USB host config options

2018-03-26 Thread Alan Stern
- > - Enables support for the built-in OHCI controller present on the > - Atheros AR71XX/AR7240 SoCs. > - > config USB_OHCI_HCD_PPC_OF_BE > bool "OHCI support for OF platform bus (big endian)" > depends on PPC For the EHCI and OHCI portions: Acked-by: Alan Stern <st...@rowland.harvard.edu>

  1   2   3   4   5   6   7   8   9   10   >