On Thu, 13 Dec 2018, Paul E. McKenney wrote:
> > > I guess that I still haven't gotten over being a bit surprised that the
> > > RCU counting rule also applies to sys_membarrier(). ;-)
> >
> > Why not? They are both synchronization mechanisms with heavy-weight
> > write sides and light-weight
On Thu, 13 Dec 2018, Paul E. McKenney wrote:
> > > A good next step would be to automatically generate random tests along
> > > with an automatically generated prediction, like I did for RCU a few
> > > years back. I should be able to generalize my time-based cheat for RCU to
> > > also cover
On Wed, 12 Dec 2018, Paul E. McKenney wrote:
> > Well, what are you trying to accomplish? Do you want to find an
> > argument similar to the one I posted for the 6-CPU test to show that
> > this test should be forbidden?
>
> I am trying to check odd corner cases. Your sys_membarrier() model
On Wed, 12 Dec 2018, Paul E. McKenney wrote:
> > > I believe that this ordering forbids the cycle:
> > >
> > > Wa=1 > membs -> [m01] -> Rc=0 -> Wc=2 -> rcu_read_unlock() ->
> > > return from synchronize_rcu() -> Ra
> > >
> > > Does this make sense, or am I missing something?
> >
>
On Wed, 12 Dec 2018, Paul E. McKenney wrote:
> OK. How about this one?
>
> P0 P1 P2 P3
> Wa=2rcu_read_lock()Wc=2Wd=2
> membWb=2 Rd=0synchronize_rcu();
> Rb=0Rc=0 Ra=0
>
On Wed, 12 Dec 2018, Paul E. McKenney wrote:
> > > > Or am I still missing something here?
> > >
> > > You tell me...
> >
> > I think I am on board. ;-)
>
> And more to the point, here is a three-process variant showing a cycle
> that is permitted:
>
>
> P0 P1 P2
>
On Tue, 11 Dec 2018, Paul E. McKenney wrote:
> > Rewriting the litmus test in these terms gives:
> >
> > P0 P1 P2 P3 P4 P5
> > Wa=2Wb=2Wc=2[mb23] [mb14] [mb05]
> > mb0smb1smb2sWd=2We=2Wf=2
> > mb0emb1e
, and it adds a short paragraph mentioning the new support for SRCU.
Signed-off-by: Alan Stern
Cc: Akira Yokosawa
Cc: Andrea Parri
Cc: Boqun Feng
Cc: Daniel Lustig
Cc: David Howells
Cc: Jade Alglave
Cc: Luc Maranget
Cc: Nicholas Piggin
Cc: "Paul E. McKenney"
Cc: Peter Zi
On Mon, 10 Dec 2018, Paul E. McKenney wrote:
> On Mon, Dec 10, 2018 at 11:22:31AM -0500, Alan Stern wrote:
> > On Thu, 6 Dec 2018, Paul E. McKenney wrote:
> >
> > > Hello, David,
> > >
> > > I took a crack at extending LKMM to accommodate what I think
d *hcd)
>
> usb_dev->devnum = devnum;
> usb_dev->bus->devnum_next = devnum + 1;
> - memset (_dev->bus->devmap.devicemap, 0,
> - sizeof usb_dev->bus->devmap.devicemap);
> set_bit (devnum, usb_dev->bus->devmap.devicemap);
> usb_set_device_state(usb_dev, USB_STATE_ADDRESS);
Acked-by: Alan Stern
On Thu, 6 Dec 2018, Paul E. McKenney wrote:
> Hello, David,
>
> I took a crack at extending LKMM to accommodate what I think would
> support what you have in your paper. Please see the very end of this
> email for a patch against the "dev" branch of my -rcu tree.
>
> This gives the expected
next.
But the USB 3 spec says what should happen when the host and gadget
disagree in this way, doesn't it? And it doesn't say that they should
deadlock. :-) Or have I misread the spec?
> One way to avoid this would be to never pre-start any streams and always
> rely on XferNotReady, but that would mean greatly reduced throughput for
> streams.
It would be good if there was some way to actively detect the problem
instead of passively waiting for a timer to expire.
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
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
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
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
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,
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 =
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 =
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)
> {
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)
> {
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
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
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
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
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
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
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,
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,
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
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
them?
It should not be necessary to do this.
Alan Stern
them?
It should not be necessary to do this.
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
> >
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
> >
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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.
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
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
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
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
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
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
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
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
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
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
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 ;
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 ;
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
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
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
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
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
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
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
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
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
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
601 - 700 of 5703 matches
Mail list logo
