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

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

linux-kernel=151981440005264=2 > > Signed-off-by: Andrea Parri > Cc: Alan Stern > Cc: Will Deacon > Cc: Peter Zijlstra > Cc: Boqun Feng > Cc: Nicholas Piggin > Cc: David Howells > Cc: Jade Alglave > Cc: Luc Maranget > Cc: "Paul E. McKenney" > C

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

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}

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}

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}

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}

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

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

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: [v6] usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()

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

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

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

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

Re: [PATCH v3] USB: announce bcdDevice as well as idVendor, idProduct.

; + bcdDevice >> 8, bcdDevice & 0xff); > dev_info(>dev, > "New USB device strings: Mfr=%d, Product=%d, SerialNumber=%d\n", > udev->descriptor.iManufacturer, Acked-by: Alan Stern <st...@rowland.harvard.edu>

Re: [PATCH v3] USB: announce bcdDevice as well as idVendor, idProduct.

;> 8, bcdDevice & 0xff); > dev_info(>dev, > "New USB device strings: Mfr=%d, Product=%d, SerialNumber=%d\n", > udev->descriptor.iManufacturer, Acked-by: Alan Stern

Re: [PATCH v2] USB: announce bcdDevice as well as idVendor, idProduct.

udev->descriptor.iManufacturer, > - udev->descriptor.iProduct, > - udev->descriptor.iSerialNumber); > + "New USB device strings: Mfr=%d, Product=%d, > SerialNumber=%d\n", > + udev->descriptor.iManufacturer, > + udev->descriptor.iProduct, > + udev->descriptor.iSerialNumber); Same here. Alan Stern

Re: [PATCH v2] USB: announce bcdDevice as well as idVendor, idProduct.

facturer, > - udev->descriptor.iProduct, > - udev->descriptor.iSerialNumber); > + "New USB device strings: Mfr=%d, Product=%d, > SerialNumber=%d\n", > + udev->descriptor.iManufacturer, > + udev->descriptor.iProduct, > + udev->descriptor.iSerialNumber); Same here. Alan Stern

[PATCH 2/2] tools/memory-model: redefine rb in terms of rcu-fence

rcu-path expresses a form of temporal ordering. This change should not affect the semantics of the memory model, just its internal organization. Signed-off-by: Alan Stern <st...@rowland.harvard.edu> Reviewed-by: Andrea Parri <parri.and...@gmail.com> --- Index: usb-4.x/tools/mem

[PATCH 1/2] tools/memory-model: rename link and rcu-path to rcu-link and rb

won't become apparent until the second patch in this series. Signed-off-by: Alan Stern <st...@rowland.harvard.edu> Acked-by: Andrea Parri <parri.and...@gmail.com> --- Index: usb-4.x/tools/memory-model/linux-kernel.cat === --- u

[PATCH 2/2] tools/memory-model: redefine rb in terms of rcu-fence

rcu-path expresses a form of temporal ordering. This change should not affect the semantics of the memory model, just its internal organization. Signed-off-by: Alan Stern Reviewed-by: Andrea Parri --- Index: usb-4.x/tools/memory-model/linux-kernel.

[PATCH 1/2] tools/memory-model: rename link and rcu-path to rcu-link and rb

won't become apparent until the second patch in this series. Signed-off-by: Alan Stern Acked-by: Andrea Parri --- Index: usb-4.x/tools/memory-model/linux-kernel.cat === --- usb-4.x.orig/tools/memory-model/linux-kernel.cat +++ usb-4.x/t

Re: [PATCH 37/47] usb: host: remove tilegx platform glue

; > delete mode 100644 drivers/usb/host/ohci-tilegx.c > > delete mode 100644 include/linux/usb/tilegx.h > > Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org> Acked-by: Alan Stern <st...@rowland.harvard.edu>

Re: [PATCH 37/47] usb: host: remove tilegx platform glue

mode 100644 drivers/usb/host/ohci-tilegx.c > > delete mode 100644 include/linux/usb/tilegx.h > > Acked-by: Greg Kroah-Hartman Acked-by: Alan Stern

[tip:locking/core] tools/memory-model: Finish the removal of rb-dep, smp_read_barrier_depends(), and lockless_dereference()

Commit-ID: bd5c0ba2cd78a4c116726ead84f8f37dc92d043e Gitweb: https://git.kernel.org/tip/bd5c0ba2cd78a4c116726ead84f8f37dc92d043e Author: Alan Stern <st...@rowland.harvard.edu> AuthorDate: Wed, 7 Mar 2018 09:27:40 -0800 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Sat,

[tip:locking/core] tools/memory-model: Finish the removal of rb-dep, smp_read_barrier_depends(), and lockless_dereference()

Commit-ID: bd5c0ba2cd78a4c116726ead84f8f37dc92d043e Gitweb: https://git.kernel.org/tip/bd5c0ba2cd78a4c116726ead84f8f37dc92d043e Author: Alan Stern AuthorDate: Wed, 7 Mar 2018 09:27:40 -0800 Committer: Ingo Molnar CommitDate: Sat, 10 Mar 2018 10:22:23 +0100 tools/memory-model: Finish

Re: [PATCH v2 2/2] riscv/atomic: Strengthen implementations with fences

nt r0; WRITE_ONCE(*x, 1); r0 = atomic_cmpxchg(y, 0, 0); } P1(int *x, int *y) { int r1; WRITE_ONCE(*y, 1); smp_mb(); r1 = READ_ONCE(*x); } exists (0:r0=0 /\ 1:r1=0) This is yet another illustration showing that full fences are stronger than cominations of release + acquire. Alan Stern

Re: [PATCH v2 2/2] riscv/atomic: Strengthen implementations with fences

nt r0; WRITE_ONCE(*x, 1); r0 = atomic_cmpxchg(y, 0, 0); } P1(int *x, int *y) { int r1; WRITE_ONCE(*y, 1); smp_mb(); r1 = READ_ONCE(*x); } exists (0:r0=0 /\ 1:r1=0) This is yet another illustration showing that full fences are stronger than cominations of release + acquire. Alan Stern

Re: [PATCH 2/2 v2 RFC] tools/memory-model: redefine rb in terms of rcu-fence

On Thu, 1 Mar 2018, Paul E. McKenney wrote: > On Fri, Mar 02, 2018 at 12:31:41PM +0800, Boqun Feng wrote: > > On Thu, Mar 01, 2018 at 10:37:58AM -0800, Paul E. McKenney wrote: > > > On Thu, Mar 01, 2018 at 09:49:06AM -0800, Paul E. McKenney wrote: > > [ . . . ] > > > > And as Andrea pointed out

Re: [PATCH 2/2 v2 RFC] tools/memory-model: redefine rb in terms of rcu-fence

On Thu, 1 Mar 2018, Paul E. McKenney wrote: > On Fri, Mar 02, 2018 at 12:31:41PM +0800, Boqun Feng wrote: > > On Thu, Mar 01, 2018 at 10:37:58AM -0800, Paul E. McKenney wrote: > > > On Thu, Mar 01, 2018 at 09:49:06AM -0800, Paul E. McKenney wrote: > > [ . . . ] > > > > And as Andrea pointed out

Re: [PATCH 2/2 v2 RFC] tools/memory-model: redefine rb in terms of rcu-fence

On Thu, 1 Mar 2018, Boqun Feng wrote: > > +let rec rcu-fence = gp | > > + (gp ; rcu-link ; rscs) | > > + (rscs ; rcu-link ; gp) | > > + (gp ; rcu-link ; rcu-fence ; rcu-link ; rscs) | > > + (rscs ; rcu-link ; rcu-fence ; rcu-link ; gp) | > > + (rcu-fence ; rcu-link ; rcu-fence) > > + >

Re: [PATCH 2/2 v2 RFC] tools/memory-model: redefine rb in terms of rcu-fence

On Thu, 1 Mar 2018, Boqun Feng wrote: > > +let rec rcu-fence = gp | > > + (gp ; rcu-link ; rscs) | > > + (rscs ; rcu-link ; gp) | > > + (gp ; rcu-link ; rcu-fence ; rcu-link ; rscs) | > > + (rscs ; rcu-link ; rcu-fence ; rcu-link ; gp) | > > + (rcu-fence ; rcu-link ; rcu-fence) > > + >

[PATCH 1/2 RFC] tools/memory-model: rename link and rcu-path to rcu-link and rb

won't become apparent until the second patch in this series. Signed-off-by: Alan Stern <st...@rowland.harvard.edu> --- Index: usb-4.x/tools/memory-model/linux-kernel.cat === --- usb-4.x.orig/tools/memory-model/linux-kernel.cat +++ usb

[PATCH 1/2 RFC] tools/memory-model: rename link and rcu-path to rcu-link and rb

won't become apparent until the second patch in this series. Signed-off-by: Alan Stern --- Index: usb-4.x/tools/memory-model/linux-kernel.cat === --- usb-4.x.orig/tools/memory-model/linux-kernel.cat +++ usb-4.x/tools/memory-model/linux-k

[PATCH 2/2 v2 RFC] tools/memory-model: redefine rb in terms of rcu-fence

rcu-path expresses a form of temporal ordering. This change should not affect the semantics of the memory model, just its internal organization. Signed-off-by: Alan Stern <st...@rowland.harvard.edu> --- v2: Rebase on top of the preceding patch which renames "link" to "

[PATCH 2/2 v2 RFC] tools/memory-model: redefine rb in terms of rcu-fence

rcu-path expresses a form of temporal ordering. This change should not affect the semantics of the memory model, just its internal organization. Signed-off-by: Alan Stern --- v2: Rebase on top of the preceding patch which renames "link" to "rcu-link" and "rcu-path&quo

Re: [PATCH] Documentation/locking: Document the semantics of spin_is_locked()

remains undocumented or that it has been historically > > linked to the (likewise unclear) semantics of spin_unlock_wait(). > > > > Document this semantics. > > > > Signed-off-by: Andrea Parri <parri.and...@gmail.com> > > Cc: Alan Stern <st...@rowland.ha

Re: [PATCH] Documentation/locking: Document the semantics of spin_is_locked()

remains undocumented or that it has been historically > > linked to the (likewise unclear) semantics of spin_unlock_wait(). > > > > Document this semantics. > > > > Signed-off-by: Andrea Parri > > Cc: Alan Stern > > Cc: Will Deacon > > Cc: Peter Zijlstr

Re: [PATCH] tools/memory-model: update: remove rb-dep, smp_read_barrier_depends, and lockless_dereference

On Sat, 24 Feb 2018, Andrea Parri wrote: > On Fri, Feb 23, 2018 at 07:30:13PM -0800, Paul E. McKenney wrote: > > On Sat, Feb 24, 2018 at 12:22:24PM +0900, Akira Yokosawa wrote: > > > On 2018/02/22 07:29:02 +0900, Akira Yokosawa wrote: > > > > On 201

Re: [PATCH] tools/memory-model: update: remove rb-dep, smp_read_barrier_depends, and lockless_dereference

On Sat, 24 Feb 2018, Andrea Parri wrote: > On Fri, Feb 23, 2018 at 07:30:13PM -0800, Paul E. McKenney wrote: > > On Sat, Feb 24, 2018 at 12:22:24PM +0900, Akira Yokosawa wrote: > > > On 2018/02/22 07:29:02 +0900, Akira Yokosawa wrote: > > > > On 201

Re: [RFC PATCH] usb: hcd: complete URBs in threaded-IRQ context instead of tasklet

On Thu, 22 Feb 2018, Sebastian Andrzej Siewior wrote: > On 2018-02-16 16:46:41 [-0500], Alan Stern wrote: > > > The theaded interrupt runs SCHED_FIFO priority 50 by default. The only > > > thing that can interrupt it are interrupts, a softirq (not ksoftirqd) > > >

Re: [RFC PATCH] usb: hcd: complete URBs in threaded-IRQ context instead of tasklet

On Thu, 22 Feb 2018, Sebastian Andrzej Siewior wrote: > On 2018-02-16 16:46:41 [-0500], Alan Stern wrote: > > > The theaded interrupt runs SCHED_FIFO priority 50 by default. The only > > > thing that can interrupt it are interrupts, a softirq (not ksoftirqd) > > >

Re: [PATCH v2] usb: host: ehci-platform: add support for optional external vbus supply

must be scalable to add this feature in the future. > > > > I agree that for now there don't seem to be any platforms requiring > > more than one regulator, but this should be implemented in a way that > > could be expanded if necessary. > > > > Anyway, the basic

Re: [PATCH v2] usb: host: ehci-platform: add support for optional external vbus supply

must be scalable to add this feature in the future. > > > > I agree that for now there don't seem to be any platforms requiring > > more than one regulator, but this should be implemented in a way that > > could be expanded if necessary. > > > > Anyway, the basic

Re: [PATCH RFC tools/lkmm 10/12] tools/memory-model: Add a S lock-based external-view litmus test

On Wed, 21 Feb 2018, Paul E. McKenney wrote: > On Wed, Feb 21, 2018 at 11:50:31AM -0500, Alan Stern wrote: > > On Wed, 21 Feb 2018, Paul E. McKenney wrote: > > > > > On Wed, Feb 21, 2018 at 10:09:00AM -0500, Alan Stern wrote: > > > > On Tue,

Re: [PATCH RFC tools/lkmm 10/12] tools/memory-model: Add a S lock-based external-view litmus test

On Wed, 21 Feb 2018, Paul E. McKenney wrote: > On Wed, Feb 21, 2018 at 11:50:31AM -0500, Alan Stern wrote: > > On Wed, 21 Feb 2018, Paul E. McKenney wrote: > > > > > On Wed, Feb 21, 2018 at 10:09:00AM -0500, Alan Stern wrote: > > > > On Tue,

Re: [PATCH RFC tools/lkmm 10/12] tools/memory-model: Add a S lock-based external-view litmus test

On Wed, 21 Feb 2018, Paul E. McKenney wrote: > > > +ISA2+pooncelock+pooncelock+pombonce.litmus > > > + Tests whether the ordering provided by a lock-protected S litmus > > > > Call it an ISA2 litmus test, not an S litmus test! > > Given the structure of the test, the relationship to S is

Re: [PATCH RFC tools/lkmm 10/12] tools/memory-model: Add a S lock-based external-view litmus test

On Wed, 21 Feb 2018, Paul E. McKenney wrote: > > > +ISA2+pooncelock+pooncelock+pombonce.litmus > > > + Tests whether the ordering provided by a lock-protected S litmus > > > > Call it an ISA2 litmus test, not an S litmus test! > > Given the structure of the test, the relationship to S is

[PATCH] tools/memory-model: update: remove rb-dep, smp_read_barrier_depends, and lockless_dereference

ld mention commit 5a8897cc7631 ("locking/atomics/alpha: Add smp_read_barrier_depends() to _release()/_relaxed() atomics") as an important precursor, and he contributed commit cb13b424e986 ("locking/xchg/alpha: Add unconditional memory barrier to cmpxchg()"), an

[PATCH] tools/memory-model: update: remove rb-dep, smp_read_barrier_depends, and lockless_dereference

ld mention commit 5a8897cc7631 ("locking/atomics/alpha: Add smp_read_barrier_depends() to _release()/_relaxed() atomics") as an important precursor, and he contributed commit cb13b424e986 ("locking/xchg/alpha: Add unconditional memory barrier to cmpxchg()"), another prerequisit

Re: [PATCH RFC tools/lkmm 09/12] tools/memory-model: Add required herd7 version to README file

On Wed, 21 Feb 2018, Paul E. McKenney wrote: > On Wed, Feb 21, 2018 at 10:10:52AM -0500, Alan Stern wrote: > > On Tue, 20 Feb 2018, Paul E. McKenney wrote: > > > > > LKMM and the herd7 tool are co-evolving, and out-of-date herd7 tools > > > produce inaccurate res

Re: [PATCH RFC tools/lkmm 09/12] tools/memory-model: Add required herd7 version to README file

On Wed, 21 Feb 2018, Paul E. McKenney wrote: > On Wed, Feb 21, 2018 at 10:10:52AM -0500, Alan Stern wrote: > > On Tue, 20 Feb 2018, Paul E. McKenney wrote: > > > > > LKMM and the herd7 tool are co-evolving, and out-of-date herd7 tools > > > produce inaccurate res

Re: [PATCH RFC tools/lkmm 10/12] tools/memory-model: Add a S lock-based external-view litmus test

On Wed, 21 Feb 2018, Paul E. McKenney wrote: > On Wed, Feb 21, 2018 at 10:09:00AM -0500, Alan Stern wrote: > > On Tue, 20 Feb 2018, Paul E. McKenney wrote: > > > > > From: Alan Stern <st...@rowland.harvard.edu> > > > > > > This commit adds a litm

Re: [PATCH RFC tools/lkmm 10/12] tools/memory-model: Add a S lock-based external-view litmus test

On Wed, 21 Feb 2018, Paul E. McKenney wrote: > On Wed, Feb 21, 2018 at 10:09:00AM -0500, Alan Stern wrote: > > On Tue, 20 Feb 2018, Paul E. McKenney wrote: > > > > > From: Alan Stern > > > > > > This commit adds a litmus test in which P0() and

Re: [PATCH RFC tools/lkmm 09/12] tools/memory-model: Add required herd7 version to README file

On Tue, 20 Feb 2018, Paul E. McKenney wrote: > LKMM and the herd7 tool are co-evolving, and out-of-date herd7 tools > produce inaccurate results, often with no obvious error messages. This > commit therefore adds the required herd7 version to the LKMM README file. > > Longer term, it would be

Re: [PATCH RFC tools/lkmm 09/12] tools/memory-model: Add required herd7 version to README file

On Tue, 20 Feb 2018, Paul E. McKenney wrote: > LKMM and the herd7 tool are co-evolving, and out-of-date herd7 tools > produce inaccurate results, often with no obvious error messages. This > commit therefore adds the required herd7 version to the LKMM README file. > > Longer term, it would be

Re: [PATCH RFC tools/lkmm 10/12] tools/memory-model: Add a S lock-based external-view litmus test

On Tue, 20 Feb 2018, Paul E. McKenney wrote: > From: Alan Stern <st...@rowland.harvard.edu> > > This commit adds a litmus test in which P0() and P1() form a lock-based S > litmus test, with the addition of P2(), which observes P0()'s and P1()'s Why do you call this an "

Re: [PATCH RFC tools/lkmm 10/12] tools/memory-model: Add a S lock-based external-view litmus test

On Tue, 20 Feb 2018, Paul E. McKenney wrote: > From: Alan Stern > > This commit adds a litmus test in which P0() and P1() form a lock-based S > litmus test, with the addition of P2(), which observes P0()'s and P1()'s Why do you call this an "S" litmus test? Isn't ISA2

Re: [PATCH] tools/memory-model: remove rb-dep, smp_read_barrier_depends, and lockless_dereference

On Fri, 16 Feb 2018, Paul E. McKenney wrote: > On Fri, Feb 16, 2018 at 05:22:55PM -0500, Alan Stern wrote: > > Since commit 76ebbe78f739 ("locking/barriers: Add implicit > > smp_read_barrier_depends() to READ_ONCE()") was merged for the 4.15 > > kernel, i

Re: [PATCH] tools/memory-model: remove rb-dep, smp_read_barrier_depends, and lockless_dereference

On Fri, 16 Feb 2018, Paul E. McKenney wrote: > On Fri, Feb 16, 2018 at 05:22:55PM -0500, Alan Stern wrote: > > Since commit 76ebbe78f739 ("locking/barriers: Add implicit > > smp_read_barrier_depends() to READ_ONCE()") was merged for the 4.15 > > kernel, i

[tip:locking/core] tools/memory-model: Remove rb-dep, smp_read_barrier_depends, and lockless_dereference

Commit-ID: bf28ae5627442355dbb8d99238da4fb95c2dd4ec Gitweb: https://git.kernel.org/tip/bf28ae5627442355dbb8d99238da4fb95c2dd4ec Author: Alan Stern <st...@rowland.harvard.edu> AuthorDate: Tue, 20 Feb 2018 15:25:12 -0800 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:locking/core] tools/memory-model: Remove rb-dep, smp_read_barrier_depends, and lockless_dereference

Commit-ID: bf28ae5627442355dbb8d99238da4fb95c2dd4ec Gitweb: https://git.kernel.org/tip/bf28ae5627442355dbb8d99238da4fb95c2dd4ec Author: Alan Stern AuthorDate: Tue, 20 Feb 2018 15:25:12 -0800 Committer: Ingo Molnar CommitDate: Wed, 21 Feb 2018 09:58:16 +0100 tools/memory-model: Remove

[tip:locking/core] tools/memory-model: Add a S lock-based external-view litmus test

Commit-ID: 556bb7d252ae42d4653557325670e665087c38ad Gitweb: https://git.kernel.org/tip/556bb7d252ae42d4653557325670e665087c38ad Author: Alan Stern <st...@rowland.harvard.edu> AuthorDate: Tue, 20 Feb 2018 15:25:10 -0800 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:locking/core] tools/memory-model: Add a S lock-based external-view litmus test

Commit-ID: 556bb7d252ae42d4653557325670e665087c38ad Gitweb: https://git.kernel.org/tip/556bb7d252ae42d4653557325670e665087c38ad Author: Alan Stern AuthorDate: Tue, 20 Feb 2018 15:25:10 -0800 Committer: Ingo Molnar CommitDate: Wed, 21 Feb 2018 09:58:15 +0100 tools/memory-model: Add a S

Re: [PATCH v2] usb: host: ehci-platform: add support for optional external vbus supply

ine to me but we need to get Alan's opinion if this is worth the > effort. > If there isn't a single platform needing it we could probably do without it > but the DT binding must be scalable to add this feature in the future. I agree that for now there don't seem t

Re: [PATCH v2] usb: host: ehci-platform: add support for optional external vbus supply

Alan's opinion if this is worth the > effort. > If there isn't a single platform needing it we could probably do without it > but the DT binding must be scalable to add this feature in the future. I agree that for now there don't seem to be any platforms requiring more than one reg

Re: [PATCH] tools/memory-model: remove rb-dep, smp_read_barrier_depends, and lockless_dereference

On Tue, 20 Feb 2018, Andrea Parri wrote: > > This leaves us with a question: Do we want to change the kernel by > > adding memory barriers after unsuccessful RMW operations on Alpha, or > > do we want to change the model by excluding such operations from > > address dependencies? > > I'd like to

Re: [PATCH] tools/memory-model: remove rb-dep, smp_read_barrier_depends, and lockless_dereference

On Tue, 20 Feb 2018, Andrea Parri wrote: > > This leaves us with a question: Do we want to change the kernel by > > adding memory barriers after unsuccessful RMW operations on Alpha, or > > do we want to change the model by excluding such operations from > > address dependencies? > > I'd like to

Re: [PATCH] tools/memory-model: remove rb-dep, smp_read_barrier_depends, and lockless_dereference

On Tue, 20 Feb 2018, Paul E. McKenney wrote: > On Mon, Feb 19, 2018 at 09:28:44PM +0100, Peter Zijlstra wrote: > > On Mon, Feb 19, 2018 at 11:41:23AM -0800, Paul E. McKenney wrote: > > > On Mon, Feb 19, 2018 at 12:14:45PM -0500, Alan Stern wrote: > > > > This leaves

Re: [PATCH] tools/memory-model: remove rb-dep, smp_read_barrier_depends, and lockless_dereference

On Tue, 20 Feb 2018, Paul E. McKenney wrote: > On Mon, Feb 19, 2018 at 09:28:44PM +0100, Peter Zijlstra wrote: > > On Mon, Feb 19, 2018 at 11:41:23AM -0800, Paul E. McKenney wrote: > > > On Mon, Feb 19, 2018 at 12:14:45PM -0500, Alan Stern wrote: > > > > This leaves

Re: [PATCH] tools/memory-model: remove rb-dep, smp_read_barrier_depends, and lockless_dereference

On Sat, 17 Feb 2018, Andrea Parri wrote: > > Akira's observation about READ_ONCE extends to all (annotated) loads. In > > fact, it also applies to loads corresponding to unsuccessful RMW operations; > > consider, for example, the following variation of MP+onceassign+derefonce: > > > > C T > >

Re: [PATCH] tools/memory-model: remove rb-dep, smp_read_barrier_depends, and lockless_dereference

On Sat, 17 Feb 2018, Andrea Parri wrote: > > Akira's observation about READ_ONCE extends to all (annotated) loads. In > > fact, it also applies to loads corresponding to unsuccessful RMW operations; > > consider, for example, the following variation of MP+onceassign+derefonce: > > > > C T > >

[PATCH] tools/memory-model: remove rb-dep, smp_read_barrier_depends, and lockless_dereference

nce()") removed lockless_dereference() from the kernel. Since these primitives are no longer part of the kernel, they do not belong in the Linux Kernel Memory Consistency Model. This patch removes them, along with the internal rb-dep relation, and updates the revelant documentation. Signed-of

[PATCH] tools/memory-model: remove rb-dep, smp_read_barrier_depends, and lockless_dereference

nce()") removed lockless_dereference() from the kernel. Since these primitives are no longer part of the kernel, they do not belong in the Linux Kernel Memory Consistency Model. This patch removes them, along with the internal rb-dep relation, and updates the revelant documentation. Signed-off-by: Ala

Re: [RFC PATCH] usb: hcd: complete URBs in threaded-IRQ context instead of tasklet

On Fri, 16 Feb 2018, Sebastian Andrzej Siewior wrote: > On 2018-02-16 13:29:01 [-0500], Alan Stern wrote: > > We originally used tasklets because we didn't want to incur the delays > > associated with running in a process context. It seems odd to be > > revers

Re: [RFC PATCH] usb: hcd: complete URBs in threaded-IRQ context instead of tasklet

On Fri, 16 Feb 2018, Sebastian Andrzej Siewior wrote: > On 2018-02-16 13:29:01 [-0500], Alan Stern wrote: > > We originally used tasklets because we didn't want to incur the delays > > associated with running in a process context. It seems odd to be > > revers

Re: [RFC PATCH] usb: hcd: complete URBs in threaded-IRQ context instead of tasklet

It seems odd to be reversing that decision now. > The URBs from the root-hub never create an interrupt so I currently > process them in a workqueue (I'm not sure if an URB-enqueue in the > completion handler would break something). It worked okay before we changed over to using tasklets. Alan Stern

Re: [RFC PATCH] usb: hcd: complete URBs in threaded-IRQ context instead of tasklet

It seems odd to be reversing that decision now. > The URBs from the root-hub never create an interrupt so I currently > process them in a workqueue (I'm not sure if an URB-enqueue in the > completion handler would break something). It worked okay before we changed over to using tasklets. Alan Stern

Re: Trial of conflict resolution of Alan's patch

On Fri, 16 Feb 2018, Akira Yokosawa wrote: > Hi, > > My forward-port patch doesn't apply to the "lkmm" branch. > It looks like "linux-kernel-hardware.cat" is intentionally omitted there. > Am I guessing right? > > If this is the case, I can prepare a patch to be applied to "lkmm". > But I can't

Re: Trial of conflict resolution of Alan's patch

On Fri, 16 Feb 2018, Akira Yokosawa wrote: > Hi, > > My forward-port patch doesn't apply to the "lkmm" branch. > It looks like "linux-kernel-hardware.cat" is intentionally omitted there. > Am I guessing right? > > If this is the case, I can prepare a patch to be applied to "lkmm". > But I can't

Re: Trial of conflict resolution of Alan's patch

On Fri, 16 Feb 2018, Akira Yokosawa wrote: > So, I attempted to rebase the patch to current (somewhat old) master of > https://github.com/aparri/memory-model. Why? Because the lkmm branch > in Paul's -rcu tree doesn't have linux-kernel-hardware.cat. > > However, after this change,

Re: Trial of conflict resolution of Alan's patch

On Fri, 16 Feb 2018, Akira Yokosawa wrote: > So, I attempted to rebase the patch to current (somewhat old) master of > https://github.com/aparri/memory-model. Why? Because the lkmm branch > in Paul's -rcu tree doesn't have linux-kernel-hardware.cat. > > However, after this change,

Re: [PATCH v2] tools/memory-model: Make compat with herd7 7.47 ("-" -> "_")

On Wed, 14 Feb 2018, Paul E. McKenney wrote: > Let's see, examining the Z6 litmus tests and running on herd7 version 7.48: > > Z6.0+pooncelock+pooncelock+pombonce Sometimes 1 7 > Z6.0+pooncelock+poonceLock+pombonce Never 0 7 > Z6.0+pooncerelease+poacquirerelease+mbonceonce Sometimes 1 7 > > But

Re: [PATCH v2] tools/memory-model: Make compat with herd7 7.47 ("-" -> "_")

On Wed, 14 Feb 2018, Paul E. McKenney wrote: > Let's see, examining the Z6 litmus tests and running on herd7 version 7.48: > > Z6.0+pooncelock+pooncelock+pombonce Sometimes 1 7 > Z6.0+pooncelock+poonceLock+pombonce Never 0 7 > Z6.0+pooncerelease+poacquirerelease+mbonceonce Sometimes 1 7 > > But

Re: [PATCH RFC tip/lkmm 04/10] EXP litmus_tests: Add comments explaining tests' purposes

On Fri, 9 Feb 2018, Paul E. McKenney wrote: > This commit adds comments to the litmus tests summarizing what these > tests are intended to demonstrate. > > Suggested-by: Ingo Molnar > Signed-off-by: Paul E. McKenney > [ paulmck: Apply Andrea's and

Re: [PATCH RFC tip/lkmm 04/10] EXP litmus_tests: Add comments explaining tests' purposes

On Fri, 9 Feb 2018, Paul E. McKenney wrote: > This commit adds comments to the litmus tests summarizing what these > tests are intended to demonstrate. > > Suggested-by: Ingo Molnar > Signed-off-by: Paul E. McKenney > [ paulmck: Apply Andrea's and Alan's feedback. ] > --- > ---

Re: [GIT PULL tools] Linux kernel memory model

On Sun, 4 Feb 2018, Paul E. McKenney wrote: > --- a/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus > +++ b/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus > @@ -1,5 +1,11 @@ > C CoRW+poonceonce+Once > > +(* > + * Test of read-write coherence, that is, whether or not a

Re: [GIT PULL tools] Linux kernel memory model

On Sun, 4 Feb 2018, Paul E. McKenney wrote: > --- a/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus > +++ b/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus > @@ -1,5 +1,11 @@ > C CoRW+poonceonce+Once > > +(* > + * Test of read-write coherence, that is, whether or not a

Re: [GIT PULL tools] Linux kernel memory model

On Sat, 3 Feb 2018, Paul E. McKenney wrote: > Please see below for an initial patch to this effect. This activity > proved to be more productive than expected for these tests, which certainly > supports our assertion that locking needs more testing... > > MP+polocks.litmus >

Re: [GIT PULL tools] Linux kernel memory model

On Sat, 3 Feb 2018, Paul E. McKenney wrote: > Please see below for an initial patch to this effect. This activity > proved to be more productive than expected for these tests, which certainly > supports our assertion that locking needs more testing... > > MP+polocks.litmus >

Re: [V2][PATCH] ohci-hcd: Fix race condition caused by ohci_urb_enqueue() and io_watchdog_func()

; not overwritten while io_watchdog_func() is running. > > v2: Instead of adding an extra flag variable, defining IO_WATCHDOG_OFF > as a special sentinel value for prev_frame_no. > > Signed-off-by: Shigeru Yoshida <shigeru.yosh...@windriver.com> > Signed-off-by: Haiqing

Re: [V2][PATCH] ohci-hcd: Fix race condition caused by ohci_urb_enqueue() and io_watchdog_func()

func() is running. > > v2: Instead of adding an extra flag variable, defining IO_WATCHDOG_OFF > as a special sentinel value for prev_frame_no. > > Signed-off-by: Shigeru Yoshida > Signed-off-by: Haiqing Bai The "v2" explanation is supposed to go below the "

Re: [PATCH] ohci-hcd: Fix race condition caused by ohci_urb_enqueue() and io_watchdog_func()

On Thu, 1 Feb 2018, Yoshida, Shigeru wrote: > Hi Alan, > > Thank you for your commenting. > > On Wed, 31 Jan 2018 11:02:47 -0500, Alan Stern wrote: > >> To address above scenario, this patch introduces timer_running flag to > >> ohci_hcd structure. Setting true

Re: [PATCH] ohci-hcd: Fix race condition caused by ohci_urb_enqueue() and io_watchdog_func()

On Thu, 1 Feb 2018, Yoshida, Shigeru wrote: > Hi Alan, > > Thank you for your commenting. > > On Wed, 31 Jan 2018 11:02:47 -0500, Alan Stern wrote: > >> To address above scenario, this patch introduces timer_running flag to > >> ohci_hcd structure. Setting true

Re: [PATCH 1/2] tools/memory-model: clarify the origin/scope of the tool name

in sources' headers and for the subsystem name. > > Suggested-by: Ingo Molnar <mi...@kernel.org> > Signed-off-by: Andrea Parri <parri.and...@gmail.com> For both patches: Acked-by: Alan Stern <st...@rowland.harvard.edu>

Re: [PATCH 1/2] tools/memory-model: clarify the origin/scope of the tool name

name in sources' headers and for the subsystem name. > > Suggested-by: Ingo Molnar > Signed-off-by: Andrea Parri For both patches: Acked-by: Alan Stern

Re: [PATCH] ohci-hcd: Fix race condition caused by ohci_urb_enqueue() and io_watchdog_func()

variable, which has to be kept in sync with the timer routine, how about defining a special sentinel value for prev_frame_no? For example: #define IO_WATCHDOG_OFF 0xff00 Then whenever the timer isn't scheduled or running, set ohci->prev_frame_no to IO_WATCHDOG_OFF. And instead of testing timer_pending(), compare prev_frame_no to this special value. I think that approach will be slightly more robust. Alan Stern

Re: [PATCH] ohci-hcd: Fix race condition caused by ohci_urb_enqueue() and io_watchdog_func()

variable, which has to be kept in sync with the timer routine, how about defining a special sentinel value for prev_frame_no? For example: #define IO_WATCHDOG_OFF 0xff00 Then whenever the timer isn't scheduled or running, set ohci->prev_frame_no to IO_WATCHDOG_OFF. And instead of testing timer_pending(), compare prev_frame_no to this special value. I think that approach will be slightly more robust. Alan Stern

Re: dvb usb issues since kernel 4.9

question uses bulk transfers. xhci-hcd, on the other hand, does not use these tasklets (it doesn't set the HCD_BH bit in the hc_driver's .flags member). Alan Stern

Re: dvb usb issues since kernel 4.9

question uses bulk transfers. xhci-hcd, on the other hand, does not use these tasklets (it doesn't set the HCD_BH bit in the hc_driver's .flags member). Alan Stern

Re: Aw: Re: Re: dvb usb issues since kernel 4.9

ost says that the testing was done on an x86_64 machine. > Gesendet: Montag, 08. Januar 2018 um 17:31 Uhr > Von: "Alan Stern" <st...@rowland.harvard.edu> > An: "Josef Griebichler" <griebichler.jo...@gmx.at> > Cc: "Mauro Carvalho Chehab"

Re: Aw: Re: Re: dvb usb issues since kernel 4.9

ost says that the testing was done on an x86_64 machine. > Gesendet: Montag, 08. Januar 2018 um 17:31 Uhr > Von: "Alan Stern" > An: "Josef Griebichler" > Cc: "Mauro Carvalho Chehab" , "Greg Kroah-Hartman" > , linux-...@vger.kernel.org, "

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