Re: LKMM patch scorecard for v4.19 merge window

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: LKMM patch scorecard for v4.19 merge window

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-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 2/2] tools/memory-model: Add write ordering by release-acquire and by locks

-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)

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

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

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

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: [PATCH] usb: don't offload isochronous urb completions to ksoftirq

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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: LKMM litmus test for Roman Penyaev's rcu-rr

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

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: [RFC] driver core: don't hold dev's parent lock when using async probe

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

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

On Thu, 24 May 2018, Nicolas Boichat wrote: > On Thu, May 24, 2018 at 12:39 AM, Greg Kroah-Hartman > wrote: > > On Wed, May 23, 2018 at 10:03:55AM -0400, Alan Stern wrote: > >> On Wed, 23 May 2018, Nicolas Boichat wrote: > >> > >> > The "old"

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

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: [PATCH] usb: hub: Per-port setting to use old enumeration scheme

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

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: [RFC] driver core: don't hold dev's parent lock when using async probe

ng 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

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 v2 0/2] Re: usb-storage: Add quirks to make G-Technology "G-Drive" work

unusual_uas.h | 9 + > 3 files changed, 24 insertions(+) Acked-by: Alan Stern 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

; 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

; 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

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: [PATCH] usb-storage: Add quirks to make G-Technology "G-Drive" work

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

* 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: [usb-storage] Re: [PATCH] usb-storage: Add quirks to make G-Technology "G-Drive" work

* 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

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

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

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

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: Improve mixed-access checking in lock.cat

Commit-ID: 30b795df11a1a9dd7fc50c1ff4677343b67cb379 Gitweb: https://git.kernel.org/tip/30b795df11a1a9dd7fc50c1ff4677343b67cb379 Author: Alan Stern AuthorDate: Mon, 14 May 2018 16:33:52 -0700 Committer: Ingo Molnar CommitDate: Tue, 15 May 2018 08:11:18 +0200 tools/memory-model: Improve

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

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: Remove out-of-date comments and code from lock.cat

Commit-ID: cee0321a404fe6b43d1f4364639c8ffe2f2b37d1 Gitweb: https://git.kernel.org/tip/cee0321a404fe6b43d1f4364639c8ffe2f2b37d1 Author: Alan Stern AuthorDate: Mon, 14 May 2018 16:33:53 -0700 Committer: Ingo Molnar CommitDate: Tue, 15 May 2018 08:11:18 +0200 tools/memory-model: Remove

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

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: Improve comments in lock.cat

Commit-ID: fd0359dbac3df00d1c6c22769e7d647b16b920cc Gitweb: https://git.kernel.org/tip/fd0359dbac3df00d1c6c22769e7d647b16b920cc Author: Alan Stern AuthorDate: Mon, 14 May 2018 16:33:51 -0700 Committer: Ingo Molnar CommitDate: Tue, 15 May 2018 08:11:18 +0200 tools/memory-model: Improve

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

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: Remove duplicated code from lock.cat

Commit-ID: 8559183ccaec97454b2515ac426f113967256cf9 Gitweb: https://git.kernel.org/tip/8559183ccaec97454b2515ac426f113967256cf9 Author: Alan Stern AuthorDate: Mon, 14 May 2018 16:33:50 -0700 Committer: Ingo Molnar CommitDate: Tue, 15 May 2018 08:11:17 +0200 tools/memory-model: Remove

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

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: Redefine rb in terms of rcu-fence

Commit-ID: 9d036883a17969caf8796d1fce813af0ab016986 Gitweb: https://git.kernel.org/tip/9d036883a17969caf8796d1fce813af0ab016986 Author: Alan Stern AuthorDate: Mon, 14 May 2018 16:33:40 -0700 Committer: Ingo Molnar CommitDate: Tue, 15 May 2018 08:11:16 +0200 tools/memory-model

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

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:

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

Commit-ID: 1ee2da5f9b5a8e814b397b77a08d44fed5f96a4a Gitweb: https://git.kernel.org/tip/1ee2da5f9b5a8e814b397b77a08d44fed5f96a4a Author: Alan Stern AuthorDate: Mon, 14 May 2018 16:33:39 -0700 Committer: Ingo Molnar CommitDate: Tue, 15 May 2018 08:11:15 +0200 tools/memory-model: Rename

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

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 V5] USB: Increment wakeup count on remote wakeup.

> root_hub pointer. > V2: Fixed the build failure error due to uninitialized dev pointer. Acked-by: Alan Stern

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

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 V3] USB: Increment wakeup count on remote wakeup.

e; 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..aa9968d90a48c 100644 > --- a/drivers/usb/co

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

;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 V2] USB: Increment wakeup count on remote wakeup.

> + pm_wakeup_event(dev, 0); > spin_lock_irqsave (_root_hub_lock, flags); > if (hcd->rh_registered) { > set_bit(HCD_FLAG_WAKEUP_PENDING, >flags); In general, hcd->self.root_hub is guaranteed to be non-NULL only when hcd->rh_registered is set. Therefore the

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

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: Increment wakeup count on remote wakeup.

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

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] usb: storage: Replace mdelay with msleep in init_freecom

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-Ju Bai A

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

->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: [PATCH 1/2] clk: at91: Added more information logging.

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?

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?

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?

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?

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?

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: Control dependency between prior load in while condition and later store?

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()

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 v2 1/3] locking: Document the semantics of spin_is_locked()

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 the comment? what else? > > > >

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

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 RFC tools/memory-model] Add s390.{cfg,cat}

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 > >

<    3   4   5   6   7   8   9   10   11   12   >