[PATCH] pkt_sched: sch_qfq: remove redundant -if- control statement

[Andrea Parri]

The control !hlist_unhashed() in qfq_destroy_agg() is unnecessary
because already performed in hlist_del_init(), so remove it.

Signed-off-by: Andrea Parri parri.and...@gmail.com
---
 net/sched/sch_qfq.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c
index 3ec7e88..b8d73bc 100644
--- a/net/sched/sch_qfq.c
+++ b/net/sched/sch_qfq.c
@@ -339,8 +339,7 @@ static struct qfq_aggregate *qfq_choose_next_agg(struct 
qfq_sched *);
 
 static void qfq_destroy_agg(struct qfq_sched *q, struct qfq_aggregate *agg)
 {
-   if (!hlist_unhashed(agg-nonfull_next))
-   hlist_del_init(agg-nonfull_next);
+   hlist_del_init(agg-nonfull_next);
q-wsum -= agg-class_weight;
if (q-wsum != 0)
q-iwsum = ONE_FP / q-wsum;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH RESEND] pkt_sched: sch_qfq: remove redundant -if- control statement

[Andrea Parri]

The control !hlist_unhashed() in qfq_destroy_agg() is unnecessary
because already performed in hlist_del_init(), so remove it.

Signed-off-by: Andrea Parri parri.and...@gmail.com
---
 net/sched/sch_qfq.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c
index 3ec7e88..b8d73bc 100644
--- a/net/sched/sch_qfq.c
+++ b/net/sched/sch_qfq.c
@@ -339,8 +339,7 @@ static struct qfq_aggregate *qfq_choose_next_agg(struct 
qfq_sched *);
 
 static void qfq_destroy_agg(struct qfq_sched *q, struct qfq_aggregate *agg)
 {
-   if (!hlist_unhashed(agg-nonfull_next))
-   hlist_del_init(agg-nonfull_next);
+   hlist_del_init(agg-nonfull_next);
q-wsum -= agg-class_weight;
if (q-wsum != 0)
q-iwsum = ONE_FP / q-wsum;
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Documentation/scheduler/sched-deadline.txt: fix schedtool's time-units

[Andrea Parri]

Use the proper time-units for schedtool's reservation parameters.

Signed-off-by: Andrea Parri parri.and...@gmail.com
---
 Documentation/scheduler/sched-deadline.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/scheduler/sched-deadline.txt 
b/Documentation/scheduler/sched-deadline.txt
index 21461a0..9e8ca8c 100644
--- a/Documentation/scheduler/sched-deadline.txt
+++ b/Documentation/scheduler/sched-deadline.txt
@@ -393,7 +393,7 @@ Appendix A. Test suite
   # schedtool -E -t 1000:1 -e ./my_cpuhog_app
 
  With this, my_cpuhog_app is put to run inside a SCHED_DEADLINE reservation
- of 10ms every 100ms (note that parameters are expressed in microseconds).
+ of 10ms every 100ms (note that parameters are expressed in nanoseconds).
  You can also use schedtool to create a reservation for an already running
  application, given that you know its pid:
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH trivial] time/timer.c: coding style fix

[Andrea Parri]

Put the opening brace last on the line in switch statement.

Signed-off-by: Andrea Parri parri.and...@gmail.com
---
 kernel/time/timer.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 2ece3aa..19e61f2 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1473,8 +1473,7 @@ signed long __sched schedule_timeout(signed long timeout)
struct timer_list timer;
unsigned long expire;
 
-   switch (timeout)
-   {
+   switch (timeout) {
case MAX_SCHEDULE_TIMEOUT:
/*
 * These two special cases are useful to be comfortable
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] sched/deadline: fix comment in push_dl_tasks

[Andrea Parri]

The comment is misleading; fix it by adapting a comment from
push_rt_tasks.

Signed-off-by: Andrea Parri parri.and...@gmail.com
---
 kernel/sched/deadline.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 0a17af35..7c17001 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -1563,7 +1563,7 @@ out:
 
 static void push_dl_tasks(struct rq *rq)
 {
-   /* Terminates as it moves a -deadline task */
+   /* push_dl_task will return true if it moved a -deadline task */
while (push_dl_task(rq))
;
 }
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] sched/deadline: fix comment in enqueue_task_dl

[Andrea Parri]

The flag dl_boosted is set by comparing *absolute* deadlines
(c.f., rt_mutex_setprio).

Signed-off-by: Andrea Parri parri.and...@gmail.com
---
 kernel/sched/deadline.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 7c17001..be2ca5e 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -953,7 +953,7 @@ static void enqueue_task_dl(struct rq *rq, struct 
task_struct *p, int flags)
 
/*
 * Use the scheduling parameters of the top pi-waiter
-* task if we have one and its (relative) deadline is
+* task if we have one and its (absolute) deadline is
 * smaller than our one... OTW we keep our runtime and
 * deadline.
 */
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] pkt_sched: sch_qfq: remove unused member of struct qfq_sched

[Andrea Parri]

The member (u32) num_active_agg of struct qfq_sched has been unused
since its introduction in 462dbc9101acd38e92eda93c0726857517a24bbd
pkt_sched: QFQ Plus: fair-queueing service at DRR cost and (AFAICT)
there is no active plan to use it; this removes the member.

Signed-off-by: Andrea Parri parri.and...@gmail.com
Acked-by: Paolo Valente paolo.vale...@unimore.it
---
 net/sched/sch_qfq.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c
index b8d73bc..ffaeea6 100644
--- a/net/sched/sch_qfq.c
+++ b/net/sched/sch_qfq.c
@@ -186,7 +186,6 @@ struct qfq_sched {
 
u64 oldV, V;/* Precise virtual times. */
struct qfq_aggregate*in_serv_agg;   /* Aggregate being served. */
-   u32 num_active_agg; /* Num. of active aggregates */
u32 wsum;   /* weight sum */
u32 iwsum;  /* inverse weight sum */
 
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] events/uprobes: move smp_read_barrier_depends() where needed

[Andrea Parri]

There is no need to use the barrier if there is no dereference/
memory access; move it where needed (currently, affecting only
Alpha). While touching this, also make the reads _ONCE().

Signed-off-by: Andrea Parri <parri.and...@gmail.com>
---
 kernel/events/uprobes.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index b7a525ab2083..b1364acd683e 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1520,10 +1520,11 @@ static unsigned long get_trampoline_vaddr(void)
struct xol_area *area;
unsigned long trampoline_vaddr = -1;
 
-   area = current->mm->uprobes_state.xol_area;
-   smp_read_barrier_depends();
-   if (area)
-   trampoline_vaddr = area->vaddr;
+   area = READ_ONCE(current->mm->uprobes_state.xol_area);
+   if (area) {
+   smp_read_barrier_depends();
+   trampoline_vaddr = READ_ONCE(area->vaddr);
+   }
 
return trampoline_vaddr;
 }
-- 
1.9.1

Re: [PATCH v3] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

[Andrea Parri]

On Fri, Feb 17, 2017 at 03:43:40PM -0500, Waiman Long wrote:
> All the locking related cmpxchg's in the following functions are
> replaced with the _acquire variants:
>  - pv_queued_spin_steal_lock()
>  - trylock_clear_pending()
> 
> This change should help performance on architectures that use LL/SC.
> 
> On a 2-core 16-thread Power8 system with pvqspinlock explicitly
> enabled, the performance of a locking microbenchmark with and without
> this patch on a 4.10-rc8 kernel with Xinhui's PPC qspinlock patch
> were as follows:
> 
>   # of thread w/o patchwith patch  % Change
>   --- ---  
>4 4053.3 Mop/s  4223.7 Mop/s +4.2%
>8 3310.4 Mop/s  3406.0 Mop/s +2.9%
>   12 2576.4 Mop/s  2674.6 Mop/s +3.8%
> 
> Signed-off-by: Waiman Long 
> ---
> 
>  v2->v3:
>   - Reduce scope by relaxing cmpxchg's in fast path only.
> 
>  v1->v2:
>   - Add comments in changelog and code for the rationale of the change.
> 
>  kernel/locking/qspinlock_paravirt.h | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/kernel/locking/qspinlock_paravirt.h 
> b/kernel/locking/qspinlock_paravirt.h
> index e6b2f7a..a59dc05 100644
> --- a/kernel/locking/qspinlock_paravirt.h
> +++ b/kernel/locking/qspinlock_paravirt.h
> @@ -72,7 +72,7 @@ static inline bool pv_queued_spin_steal_lock(struct 
> qspinlock *lock)
>   struct __qspinlock *l = (void *)lock;
>  
>   if (!(atomic_read(>val) & _Q_LOCKED_PENDING_MASK) &&
> - (cmpxchg(>locked, 0, _Q_LOCKED_VAL) == 0)) {
> + (cmpxchg_acquire(>locked, 0, _Q_LOCKED_VAL) == 0)) {
>   qstat_inc(qstat_pv_lock_stealing, true);
>   return true;
>   }
> @@ -101,16 +101,16 @@ static __always_inline void clear_pending(struct 
> qspinlock *lock)
>  
>  /*
>   * The pending bit check in pv_queued_spin_steal_lock() isn't a memory
> - * barrier. Therefore, an atomic cmpxchg() is used to acquire the lock
> - * just to be sure that it will get it.
> + * barrier. Therefore, an atomic cmpxchg_acquire() is used to acquire the
> + * lock just to be sure that it will get it.
>   */
>  static __always_inline int trylock_clear_pending(struct qspinlock *lock)
>  {
>   struct __qspinlock *l = (void *)lock;
>  
>   return !READ_ONCE(l->locked) &&
> -(cmpxchg(>locked_pending, _Q_PENDING_VAL, _Q_LOCKED_VAL)
> - == _Q_PENDING_VAL);
> +(cmpxchg_acquire(>locked_pending, _Q_PENDING_VAL,
> + _Q_LOCKED_VAL) == _Q_PENDING_VAL);
>  }
>  #else /* _Q_PENDING_BITS == 8 */
>  static __always_inline void set_pending(struct qspinlock *lock)
> @@ -138,7 +138,7 @@ static __always_inline int trylock_clear_pending(struct 
> qspinlock *lock)
>*/
>   old = val;
>   new = (val & ~_Q_PENDING_MASK) | _Q_LOCKED_VAL;
> - val = atomic_cmpxchg(>val, old, new);
> + val = atomic_cmpxchg_acquire(>val, old, new);
>  
>   if (val == old)
>   return 1;
> @@ -361,6 +361,9 @@ static void pv_kick_node(struct qspinlock *lock, struct 
> mcs_spinlock *node)
>* observe its next->locked value and advance itself.
>*
>* Matches with smp_store_mb() and cmpxchg() in pv_wait_node()
> +  *
> +  * We can't used relaxed form of cmpxchg here as the loading of
> +  * pn->state can happen before setting next->locked in some archs.
>*/
>   if (cmpxchg(>state, vcpu_halted, vcpu_hashed) != vcpu_halted)

Hi Waiman.

cmpxchg() does not guarantee the (here implied) smp_mb(), in general; c.f.,
e.g., arch/arm64/include/asm/atomic_ll_sc.h, where cmpxchg() get "compiled"
to something like:

_loop: ldxr; eor; cbnz _exit; stlxr; cbnz _loop; dmb ish; _exit:

  Andrea


>   return;
> -- 
> 1.8.3.1
> 

Re: Question about DEC Alpha memory ordering

[Andrea Parri]

On Mon, Feb 13, 2017 at 01:24:36PM -0800, Paul E. McKenney wrote:
> On Mon, Feb 13, 2017 at 04:06:21PM -0500, Alan Stern wrote:
> > On Mon, 13 Feb 2017, Paul E. McKenney wrote:
> > 
> > > On Mon, Feb 13, 2017 at 08:14:23PM +0100, Tobias Klausmann wrote:
> > > > Hi! 
> > > > 
> > > > On Mon, 13 Feb 2017, Paul E. McKenney wrote:
> > > > > On Mon, Feb 13, 2017 at 01:53:27PM -0500, bob smith wrote:
> > > > > > On 2/13/17 1:39 PM, Paul E. McKenney wrote:
> > > > > > > can real DEC Alpha hardware end up with both instances of "r1"
> > > > > > > having the value 1?
> > > > > > 
> > > > > > I thought this question reminded me of something, so I found this:
> > > > > > > https://www.kernel.org/doc/Documentation/memory-barriers.txt
> > > > > > 
> > > > > > and I pasted in the content - David Howells is one of the authors 
> > > > > > and
> > > > > > maybe that is why the question sort of reminded me.
> > > > > > 
> > > > > > Maybe someone has an update but this is what was said then.
> > > > > 
> > > > > Well, thank you for pointing me to this, but my question was intended 
> > > > > to
> > > > > check whether or not the words I helped to write in 
> > > > > memory-barriers.txt
> > > > > are in fact accurate.  So if you have an SMP DEC Alpha system that you
> > > > > could provide remote access to, that would be very helpful!
> > > > 
> > > > I have a 4-cpu ES40. Send me a test program and I'll gladly run
> > > > it for you.
> > > 
> > > Andrea, could you please convert the litmus test below and send it to
> > > Tobias?
> > > 
> > >   Thanx, Paul
> > > 
> > > 
> > > 
> > > C auto/C-LB-LRW+OB-Dv
> > > (*
> > >  * Result: Never
> > >  * 
> > >  *)
> > > {
> > > }
> > > 
> > > P0(int *u0, int *x1)
> > > {
> > >   r1 = READ_ONCE(*u0);
> > >   smp_mb();
> > >   WRITE_ONCE(*x1, 1);
> > > }
> > > 
> > > 
> > > P1(int *u0, int *x1)
> > > {
> > >   r1 = rcu_dereference(*x1);
> > 
> > No, please, not this.  It should be:
> > 
> > r1 = READ_ONCE(*x1);
> > 
> > That is, the auto/C-LB-LRW+OB-Ov.litmus test.
> > 
> > >   WRITE_ONCE(*u0, r1);
> > > }
> > > 
> > > exists
> > > (0:r1=1 /\ 1:r1=1)
> 
> Sorry, here is the correct one in full.
> 
>   Thanx, Paul
> 
> 
> 
> C auto/C-LB-LRW+OB-Ov
> (*
>  * Result: Maybe
>  * P0-P1 rf OB-Ov: Never->Maybe: Note lack of C11 guarantee, control 
> dependency
>  * P1 Ov,LRW: Note lack of C11 guarantee, control dependency
>  *)
> {
> }
> 
> P0(int *u0, int *x1)
> {
>   r1 = READ_ONCE(*u0);
>   smp_mb();
>   WRITE_ONCE(*x1, 1);
> }
> 
> 
> P1(int *u0, int *x1)
> {
>   r1 = READ_ONCE(*x1);
>   WRITE_ONCE(*u0, r1);
> }
> 
> exists
> (0:r1=1 /\ 1:r1=1)
> 

The (automatically generated) module for this test is at

   http://retis.sssup.it/~a.parri/lkmm/C-LB-LRW+OB-Ov.tgz ;

the test is run by cat-ing /sys/kernel/litmus/p_count: this will execute
the thread bodies for "runs * size" iterations; results can be sentisive
to the "stride" and "affinity increment" parameters (c.f., the Makefile);
statistics for each experiments are printed on stdout.

Please let me know should you find any problem with this. Thank you,

  Andrea

Disclaimer: I'm not "excited", to use an euphemism, to post such an ugly
C code to LKML ...; _most importantly_, I've certainly never tested this
on any Alpha machine ...

Re: Question about DEC Alpha memory ordering

[Andrea Parri]

On Wed, Feb 15, 2017 at 08:26:46AM +1300, Michael Cree wrote:
> On Tue, Feb 14, 2017 at 12:35:58PM +0100, Andrea Parri wrote:
> > On Mon, Feb 13, 2017 at 01:24:36PM -0800, Paul E. McKenney wrote:
> > > 
> > > 
> > > C auto/C-LB-LRW+OB-Ov
> > > (*
> > >  * Result: Maybe
> > >  * P0-P1 rf OB-Ov: Never->Maybe: Note lack of C11 guarantee, control 
> > > dependency
> > >  * P1 Ov,LRW: Note lack of C11 guarantee, control dependency
> > >  *)
> > > {
> > > }
> > > 
> > > P0(int *u0, int *x1)
> > > {
> > >   r1 = READ_ONCE(*u0);
> > >   smp_mb();
> > >   WRITE_ONCE(*x1, 1);
> > > }
> > > 
> > > 
> > > P1(int *u0, int *x1)
> > > {
> > >   r1 = READ_ONCE(*x1);
> > >   WRITE_ONCE(*u0, r1);
> > > }
> > > 
> > > exists
> > > (0:r1=1 /\ 1:r1=1)
> > > 
> > 
> > The (automatically generated) module for this test is at
> > 
> >http://retis.sssup.it/~a.parri/lkmm/C-LB-LRW+OB-Ov.tgz ;
> > 
> > the test is run by cat-ing /sys/kernel/litmus/p_count: this will execute
> > the thread bodies for "runs * size" iterations; results can be sentisive
> > to the "stride" and "affinity increment" parameters (c.f., the Makefile);
> > statistics for each experiments are printed on stdout.
> 
> This is the test run on a 3-cpu ES45 with the settings in the Makefile:
> 
> Test auto/LB-LRW+OB-Ov Allowed
> Histogram (2 states)
> 5913093   :> 0:r1=0; 1:r1=0; 
> 4086907   :> 0:r1=0; 1:r1=1; 
> No
> Witnesses
> Positive: 0 Negative: 1000
> Condition exists (0:r1=1 /\ 1:r1=1) is NOT validated
> Observation auto/LB-LRW+OB-Ov Never 0 1000
> Time auto/LB-LRW+OB-Ov 9.570
> Hash=200258693ffc841829310726a4a0b7e3
> 
> How do we interpret these results?

Hi Michael. The log shows (together w/ other info.) an histogram

  [Total count]   :> [Final state]

where "Total count" is the number of times an execution of the test program
led to the associated "Final state", here represented by the final values
of the registers 0:r1, 1:r1.

The log also shows statistics relative to the final state specified by the
program's "exists" clause, here (0:r1=1 /\ 1:r1=1): this state was never
observed (Positive: 0) over a total of 1000 iterations/executions.

Thank you for running the test and for sharing these results.

  Andrea

> 
> Cheers
> Michael.

Re: [PATCH] osq_lock: fix osq_lock queue corruption

[Andrea Parri]

On Mon, Jul 31, 2017 at 10:54:50PM +0530, Prateek Sood wrote:
> Fix ordering of link creation between node->prev and prev->next in
> osq_lock(). A case in which the status of optimistic spin queue is
> CPU6->CPU2 in which CPU6 has acquired the lock.
> 
> tail
>   v
>   ,-. <- ,-.
>   |6||2|
>   `-' -> `-'
> 
> At this point if CPU0 comes in to acquire osq_lock, it will update the
> tail count.
> 
>   CPU2CPU0
>   --
> 
>  tail
>v
> ,-. <- ,-.,-.
> |6||2||0|
> `-' -> `-'`-'
> 
> After tail count update if CPU2 starts to unqueue itself from
> optimistic spin queue, it will find updated tail count with CPU0 and
> update CPU2 node->next to NULL in osq_wait_next().
> 
>   unqueue-A
> 
>  tail
>v
>   ,-. <- ,-.,-.
>   |6||2||0|
>   `-'`-'`-'
> 
>   unqueue-B
> 
>   ->tail != curr && !node->next
> 
> If reordering of following stores happen then
> prev->next where prev being CPU2 would be updated to point to CPU0 node:
> 
>  tail
>v
> ,-. <- ,-.,-.
> |6||2||0|
> `-' -> `-' -> `-'
> 
>   osq_wait_next()
> node->next <- 0
> xchg(node->next, NULL)
> 
>  tail
>v
>   ,-. <- ,-.,-.
>   |6||2||0|
>   `-'`-'`-'
> 
>   unqueue-C
> 
> At this point if next instruction
> WRITE_ONCE(next->prev, prev);
> in CPU2 path is committed before the update of CPU0 node->prev = prev then
> CPU0 node->prev will point to CPU6 node.
> 
>  tail
> V--. v
>   ,-. <- ,-.,-.
>   |6||2||0|
>   `-'`-'`-'
>  `--^
> 
> At this point if CPU0 path's node->prev = prev is committed resulting
> in change of CPU0 prev back to CPU2 node. CPU2 node->next is NULL
> currently,
> 
>  tail
>v
> ,-. <- ,-. <- ,-.
> |6||2||0|
> `-'`-'`-'
>`--^
> 
> so if CPU0 gets into unqueue path of osq_lock it will keep spinning
> in infinite loop as condition prev->next == node will never be true.
> 
> Signed-off-by: Prateek Sood <prs...@codeaurora.org>
> ---
>  kernel/locking/osq_lock.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/kernel/locking/osq_lock.c b/kernel/locking/osq_lock.c
> index a316794..9f4afa3 100644
> --- a/kernel/locking/osq_lock.c
> +++ b/kernel/locking/osq_lock.c
> @@ -109,6 +109,19 @@ bool osq_lock(struct optimistic_spin_queue *lock)
>  
>   prev = decode_cpu(old);
>   node->prev = prev;
> +
> + /*
> +  * osq_lock()   unqueue
> +  *
> +  * node->prev = prevosq_wait_next()
> +  * WMB  MB
> +  * prev->next = nodenext->prev = prev //unqueue-C
> +  *
> +  * Here 'node->prev' and 'next->prev' are the same variable and we need
> +  * to ensure these stores happen in-order to avoid corrupting the list.
> +  */

The interested pattern/behavior remains somehow implicit in this snippet
(for example, as you described above, a load "reading from" the store to
prev->next is implicit in that osq_wait_next()); however I was unable to
come up with an alternative solution without complicating the comment.

Reviewed-by: Andrea Parri <parri.and...@gmail.com>

  Andrea


> + smp_wmb();
> +
>   WRITE_ONCE(prev->next, node);
>  
>   /*
> -- 
> Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, 
> Inc., 
> is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
> 

Re: [PATCH] rwsem: fix missed wakeup due to reordering of load

[Andrea Parri]

On Thu, Jul 27, 2017 at 11:48:53AM -0400, Waiman Long wrote:
> On 07/26/2017 04:17 PM, Prateek Sood wrote:
> > If a spinner is present, there is a chance that the load of
> > rwsem_has_spinner() in rwsem_wake() can be reordered with
> > respect to decrement of rwsem count in __up_write() leading
> > to wakeup being missed.
> >
> >  spinning writer  up_write caller
> >  ---  ---
> >  [S] osq_unlock() [L] osq
> >   spin_lock(wait_lock)
> >   sem->count=0x0001
> > +0x
> >   count=sem->count
> >   MB
> >sem->count=0xFFFE0001
> >  -0x0001
> >spin_trylock(wait_lock)
> >return
> >  rwsem_try_write_lock(count)
> >  spin_unlock(wait_lock)
> >  schedule()
> >
> > Reordering of atomic_long_sub_return_release() in __up_write()
> > and rwsem_has_spinner() in rwsem_wake() can cause missing of
> > wakeup in up_write() context. In spinning writer, sem->count
> > and local variable count is 0XFFFE0001. It would result
> > in rwsem_try_write_lock() failing to acquire rwsem and spinning
> > writer going to sleep in rwsem_down_write_failed().
> >
> > The smp_rmb() will make sure that the spinner state is
> > consulted after sem->count is updated in up_write context.
> >
> > Signed-off-by: Prateek Sood 
> 
> Did you actually observe that the reordering happens?
> 
> I am not sure if some architectures can actually speculatively execute
> instruction ahead of a branch and then ahead into a function call. I
> know it can happen if the function call is inlined, but rwsem_wake()
> will not be inlined into __up_read() or __up_write().

Branches/control dependencies targeting a read do not necessarily preserve
program order; this is for example the case for PowerPC and ARM.

I'd not expect more than a compiler barrier from a function call (in fact,
not even that if the function happens to be inlined).


> 
> Even if that is the case, I am not sure if smp_rmb() alone is enough to
> guarantee the ordering as I think it will depend on how the
> atomic_long_sub_return_release() is implmented.

AFAICT, the pattern under discussion is MP with:

  - a store-release to osq->tail(unlock) followed by a store to sem->count,
separated by a MB (from atomic_long_add_return()) on CPU0;

  - a load of sem->count (for atomic_long_sub_return_release()) followed by
a load of osq->tail (rwsem_has_spinner()) on CPU1.

Thus a RMW between the two loads suffices to forbid the weak behaviour.

  Andrea


> 
> Cheers,
> Longman
> 

Re: [GIT PULL rcu/next] RCU commits for 4.13

[Andrea Parri]

On Wed, Jun 14, 2017 at 01:23:29PM -0700, Paul E. McKenney wrote:
> On Wed, Jun 14, 2017 at 04:33:22PM +0200, Andrea Parri wrote:
> > On Tue, Jun 13, 2017 at 09:33:17PM -0700, Paul E. McKenney wrote:
> > > On Wed, Jun 14, 2017 at 04:54:04AM +0200, Andrea Parri wrote:
> > > > On Mon, Jun 12, 2017 at 02:37:55PM -0700, Paul E. McKenney wrote:
> > > > > Hello, Ingo,
> > > > > 
> > > > > This pull request is unusual in being a single linear set of commits,
> > > > > as opposed to my usual topic branches.  This is due to the many
> > > > > large-footprint changes, which means that reasonable topic branches
> > > > > result in large numbers of merge conflicts.  In addition, some commits
> > > > > depend on other commits that should be on different topic branches.
> > > > > I will return to the topic-branch style next time.
> > > > > 
> > > > > The largest feature of this series is shrinking and simplification,
> > > > > with the following diffstat summary:
> > > > > 
> > > > >  79 files changed, 1496 insertions(+), 4211 deletions(-)
> > > > > 
> > > > > In other words, this series represents a net reduction of more than 
> > > > > 2700
> > > > > lines of code.
> > > > > 
> > > > > These commits were posted to LKML:
> > > > > 
> > > > >   
> > > > > http://lkml.kernel.org/r/20170525215934.ga11...@linux.vnet.ibm.com
> > > > 
> > > > I did raise some issues (AFAICT, unresolved) concerning...
> > > > 
> > > > 
> > > > > 
> > > > > Two of these commits (46/88 and 48/88) have been deferred, most likely
> > > > > to v4.14.  All of the remaining commits have been subjected to the 
> > > > > 0day
> > > > > Test Robot and -next testing, and are availiable in teh git 
> > > > > repository at:
> > > > > 
> > > > >   git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
> > > > > for-mingo
> > > > > 
> > > > > for you to fetch changes up to 
> > > > > 6d48152eafde1f0d0a4a9e0584fa7d9ff4fbfdac:
> > > > > 
> > > > >   rcu: Remove RCU CPU stall warnings from Tiny RCU (2017-06-08 
> > > > > 18:52:45 -0700)
> > > > > 
> > > > > 
> > > > > Arnd Bergmann (1):
> > > > >   bcm47xx: Fix build regression
> > > > > 
> > > > > Paul E. McKenney (83):
> > > > >   rcutorture: Add lockdep to one of the SRCU scenarios
> > > > >   rcutorture: Add three-level tree test for Tree SRCU
> > > > >   rcutorture: Fix bug in reporting Kconfig mis-settings
> > > > >   rcutorture: Add a scenario for Tiny SRCU
> > > > >   rcutorture: Add a scenario for Classic SRCU
> > > > >   rcu: Prevent rcu_barrier() from starting needless grace periods
> > > > >   rcutorture: Correctly handle CONFIG_RCU_TORTURE_TEST_* options
> > > > >   rcutorture: Update test scenarios based on new Kconfig 
> > > > > dependencies
> > > > >   srcu: Eliminate possibility of destructive counter overflow
> > > > >   rcu: Complain if blocking in preemptible RCU read-side critical 
> > > > > section
> > > > >   rcuperf: Defer expedited/normal check to end of test
> > > > >   rcuperf: Remove conflicting Kconfig options
> > > > >   rcu: Remove obsolete reference to synchronize_kernel()
> > > > >   rcuperf: Add ability to performance-test call_rcu() and friends
> > > > >   rcuperf: Add a Kconfig-fragment file for Classic SRCU
> > > > >   rcu: Make sync_rcu_preempt_exp_done() return bool
> > > > >   checkpatch: Remove checks for expedited grace periods
> > > > >   rcuperf: Add test for dynamically initialized srcu_struct
> > > > >   doc/atomic_ops: Clarify smp_mb__{before,after}_atomic()
> > > > >   atomics: Add header comment so spin_unlock_wait()
> > > > 
> > > > ... this one: c.f.,
> > > > 
> > > >   
> > > > http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1418503.html
> > > > 
> > > > Any hints

Re: [PATCH tip/core/rcu 20/88] atomics: Add header comment so spin_unlock_wait()

[Andrea Parri]

On Thu, May 25, 2017 at 02:58:53PM -0700, Paul E. McKenney wrote:
> There is material describing the ordering guarantees provided by
> spin_unlock_wait(), but it is not necessarily easy to find.  This commit
> therefore adds a docbook header comment to this function informally
> describing its semantics.
> 
> Signed-off-by: Paul E. McKenney 
> Acked-by: Peter Zijlstra 
> ---
>  include/linux/spinlock.h | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/include/linux/spinlock.h b/include/linux/spinlock.h
> index 59248dcc6ef3..d9510e8522d4 100644
> --- a/include/linux/spinlock.h
> +++ b/include/linux/spinlock.h
> @@ -369,6 +369,26 @@ static __always_inline int spin_trylock_irq(spinlock_t 
> *lock)
>   raw_spin_trylock_irqsave(spinlock_check(lock), flags); \
>  })
>  
> +/**
> + * spin_unlock_wait - Interpose between successive critical sections
> + * @lock: the spinlock whose critical sections are to be interposed.
> + *
> + * Semantically this is equivalent to a spin_lock() immediately
> + * followed by a spin_unlock().  However, most architectures have
> + * more efficient implementations in which the spin_unlock_wait()
> + * cannot block concurrent lock acquisition, and in some cases
> + * where spin_unlock_wait() does not write to the lock variable.
> + * Nevertheless, spin_unlock_wait() can have high overhead, so if
> + * you feel the need to use it, please check to see if there is
> + * a better way to get your job done.
> + *
> + * The ordering guarantees provided by spin_unlock_wait() are:
> + *
> + * 1.  All accesses preceding the spin_unlock_wait() happen before
> + * any accesses in later critical sections for this same lock.
> + * 2.  All accesses following the spin_unlock_wait() happen after
> + * any accesses in earlier critical sections for this same lock.
> + */

[From a discussion with Paul, Alan]

I understand that some implementation would need to "be strengthened" to
meet this "spin_lock(); spin_unlock()" semantics; please compare with

  726328d92a42b6d4b76078e2659f43067f82c4e8
  ("locking/spinlock, arch: Update and fix spin_unlock_wait() implementations")

Should we "relax" this description?  Should we integrate it with changes
to the implementation(s)? [...]  What do you think?

  Andrea


>  static __always_inline void spin_unlock_wait(spinlock_t *lock)
>  {
>   raw_spin_unlock_wait(>rlock);
> -- 
> 2.5.2
> 

Re: [GIT PULL rcu/next] RCU commits for 4.13

[Andrea Parri]

On Mon, Jun 12, 2017 at 02:37:55PM -0700, Paul E. McKenney wrote:
> Hello, Ingo,
> 
> This pull request is unusual in being a single linear set of commits,
> as opposed to my usual topic branches.  This is due to the many
> large-footprint changes, which means that reasonable topic branches
> result in large numbers of merge conflicts.  In addition, some commits
> depend on other commits that should be on different topic branches.
> I will return to the topic-branch style next time.
> 
> The largest feature of this series is shrinking and simplification,
> with the following diffstat summary:
> 
>  79 files changed, 1496 insertions(+), 4211 deletions(-)
> 
> In other words, this series represents a net reduction of more than 2700
> lines of code.
> 
> These commits were posted to LKML:
> 
>   http://lkml.kernel.org/r/20170525215934.ga11...@linux.vnet.ibm.com

I did raise some issues (AFAICT, unresolved) concerning...


> 
> Two of these commits (46/88 and 48/88) have been deferred, most likely
> to v4.14.  All of the remaining commits have been subjected to the 0day
> Test Robot and -next testing, and are availiable in teh git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
> for-mingo
> 
> for you to fetch changes up to 6d48152eafde1f0d0a4a9e0584fa7d9ff4fbfdac:
> 
>   rcu: Remove RCU CPU stall warnings from Tiny RCU (2017-06-08 18:52:45 -0700)
> 
> 
> Arnd Bergmann (1):
>   bcm47xx: Fix build regression
> 
> Paul E. McKenney (83):
>   rcutorture: Add lockdep to one of the SRCU scenarios
>   rcutorture: Add three-level tree test for Tree SRCU
>   rcutorture: Fix bug in reporting Kconfig mis-settings
>   rcutorture: Add a scenario for Tiny SRCU
>   rcutorture: Add a scenario for Classic SRCU
>   rcu: Prevent rcu_barrier() from starting needless grace periods
>   rcutorture: Correctly handle CONFIG_RCU_TORTURE_TEST_* options
>   rcutorture: Update test scenarios based on new Kconfig dependencies
>   srcu: Eliminate possibility of destructive counter overflow
>   rcu: Complain if blocking in preemptible RCU read-side critical section
>   rcuperf: Defer expedited/normal check to end of test
>   rcuperf: Remove conflicting Kconfig options
>   rcu: Remove obsolete reference to synchronize_kernel()
>   rcuperf: Add ability to performance-test call_rcu() and friends
>   rcuperf: Add a Kconfig-fragment file for Classic SRCU
>   rcu: Make sync_rcu_preempt_exp_done() return bool
>   checkpatch: Remove checks for expedited grace periods
>   rcuperf: Add test for dynamically initialized srcu_struct
>   doc/atomic_ops: Clarify smp_mb__{before,after}_atomic()
>   atomics: Add header comment so spin_unlock_wait()

... this one: c.f.,

  http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1418503.html

Any hints about those?

  Andrea

>   rcuperf: Add the ability to test tiny RCU flavors
>   srcu: Make Classic and Tree SRCU announce themselves at bootup
>   rcutorture: Reduce CPUs dedicated to testing Classic SRCU
>   srcu: Shrink Tiny SRCU a bit more
>   rcuperf: Set more user-friendly defaults
>   rcuperf: Add writer_holdoff boot parameter
>   rcutorture: Add "git diff" output to testid.txt file
>   srcu: Document auto-expediting requirement
>   doc: Take tail recursion into account in RCU requirements
>   rcu: Add preemptibility checks in rcu_sched_qs() and rcu_bh_qs()
>   rcu: Print out rcupdate.c non-default boot-time settings
>   rcu: Update rcu_bootup_announce_oddness()
>   srcu: Make exp_holdoff module parameter be static
>   srcu: Print non-default exp_holdoff values at boot time
>   rcu: Add lockdep_assert_held() teeth to tree.c
>   rcu: Add lockdep_assert_held() teeth to tree_plugin.h
>   srcu: Make SRCU be once again optional
>   srcu: Shrink Tiny SRCU a bit
>   srcu: Add DEBUG_OBJECTS_RCU_HEAD functionality
>   rcu: Make synchronize_rcu_mult() check for duplicates
>   sched: Rely on synchronize_rcu_mult() de-duplication
>   rcu: Use RCU_NOCB_WAKE rather than RCU_NOGP_WAKE
>   rcu: Add memory barriers for NOCB leader wakeup
>   rcu: Flag need for rcu_node_tree.h and rcu_segcblist.h visibility
>   rcu: Move docbook comments out of rcupdate.h
>   rcu: Move rcu_expedited and rcu_normal externs from rcupdate.h
>   rcu: Move expediting-related access/control out of rcupdate.h
>   rcu: Move torture-related definitions from rcupdate.h to rcu.h
>   rcu: Remove UINT_CMP_GE() and UINT_CMP_LT()
>   rcu: Move rcupdate.h to new empty-function style
>   rcu: Eliminate the unused __rcu_is_watching() function
>   rcu: Move the RCU_SCHEDULER_ definitions from rcupdate.h
>   rcu: Remove linux/debugobjects.h from rcupdate.h
>   rcu: Improve __call_rcu() debug-objects error message
>   rcu: 

Re: [GIT PULL rcu/next] RCU commits for 4.13

[Andrea Parri]

On Tue, Jun 13, 2017 at 09:33:17PM -0700, Paul E. McKenney wrote:
> On Wed, Jun 14, 2017 at 04:54:04AM +0200, Andrea Parri wrote:
> > On Mon, Jun 12, 2017 at 02:37:55PM -0700, Paul E. McKenney wrote:
> > > Hello, Ingo,
> > > 
> > > This pull request is unusual in being a single linear set of commits,
> > > as opposed to my usual topic branches.  This is due to the many
> > > large-footprint changes, which means that reasonable topic branches
> > > result in large numbers of merge conflicts.  In addition, some commits
> > > depend on other commits that should be on different topic branches.
> > > I will return to the topic-branch style next time.
> > > 
> > > The largest feature of this series is shrinking and simplification,
> > > with the following diffstat summary:
> > > 
> > >  79 files changed, 1496 insertions(+), 4211 deletions(-)
> > > 
> > > In other words, this series represents a net reduction of more than 2700
> > > lines of code.
> > > 
> > > These commits were posted to LKML:
> > > 
> > >   http://lkml.kernel.org/r/20170525215934.ga11...@linux.vnet.ibm.com
> > 
> > I did raise some issues (AFAICT, unresolved) concerning...
> > 
> > 
> > > 
> > > Two of these commits (46/88 and 48/88) have been deferred, most likely
> > > to v4.14.  All of the remaining commits have been subjected to the 0day
> > > Test Robot and -next testing, and are availiable in teh git repository at:
> > > 
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
> > > for-mingo
> > > 
> > > for you to fetch changes up to 6d48152eafde1f0d0a4a9e0584fa7d9ff4fbfdac:
> > > 
> > >   rcu: Remove RCU CPU stall warnings from Tiny RCU (2017-06-08 18:52:45 
> > > -0700)
> > > 
> > > 
> > > Arnd Bergmann (1):
> > >   bcm47xx: Fix build regression
> > > 
> > > Paul E. McKenney (83):
> > >   rcutorture: Add lockdep to one of the SRCU scenarios
> > >   rcutorture: Add three-level tree test for Tree SRCU
> > >   rcutorture: Fix bug in reporting Kconfig mis-settings
> > >   rcutorture: Add a scenario for Tiny SRCU
> > >   rcutorture: Add a scenario for Classic SRCU
> > >   rcu: Prevent rcu_barrier() from starting needless grace periods
> > >   rcutorture: Correctly handle CONFIG_RCU_TORTURE_TEST_* options
> > >   rcutorture: Update test scenarios based on new Kconfig dependencies
> > >   srcu: Eliminate possibility of destructive counter overflow
> > >   rcu: Complain if blocking in preemptible RCU read-side critical 
> > > section
> > >   rcuperf: Defer expedited/normal check to end of test
> > >   rcuperf: Remove conflicting Kconfig options
> > >   rcu: Remove obsolete reference to synchronize_kernel()
> > >   rcuperf: Add ability to performance-test call_rcu() and friends
> > >   rcuperf: Add a Kconfig-fragment file for Classic SRCU
> > >   rcu: Make sync_rcu_preempt_exp_done() return bool
> > >   checkpatch: Remove checks for expedited grace periods
> > >   rcuperf: Add test for dynamically initialized srcu_struct
> > >   doc/atomic_ops: Clarify smp_mb__{before,after}_atomic()
> > >   atomics: Add header comment so spin_unlock_wait()
> > 
> > ... this one: c.f.,
> > 
> >   http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1418503.html
> > 
> > Any hints about those?
> 
> I suggest being -extremely- clear.  This is about ARM, correct?
> If so, lay out the exact situation (code example, which hardware,
> which spin_unlock_wait(), which sequence of events) that could lead to
> the failure.
> 
> The problem here is that no one knows which of the 30 CPU families you
> might be talking about, nor do they know exactly what the problem is.
> I didn't worry about it at the time because I figured that you had
> sent private email to Will with the full story.
> 
> Yes, the four of us (you, Alan, Luc, and me) discussed it, but we weren't
> sure whether it was a bug in the memory model, the spin_unlock_wait()
> code, or my description of spin_unlock_wait().  Given that Will didn't
> object to my April 13th email (the one that you were not CCed on),
> I figured that he wasn't going to claim that the spin_unlock_wait()
> description was wrong, especially since he went to so much effort some
> years back to make ARM64 meet that 

Re: [PATCH v2] membarrier: Document scheduler barrier requirements

[Andrea Parri]

On Tue, Sep 19, 2017 at 03:56:31PM -0400, Mathieu Desnoyers wrote:
> Document the membarrier requirement on having a full memory barrier in
> __schedule() after coming from user-space, before storing to rq->curr.
> It is provided by smp_mb__before_spinlock() in __schedule().

It is smp_mb__after_spinlock(). (Yes: I missed it in my previous email.)

  Andrea


> 
> Document that membarrier requires a full barrier on transition from
> kernel thread to userspace thread. We currently have an implicit barrier
> from atomic_dec_and_test() in mmdrop() that ensures this.
> 
> The x86 switch_mm_irqs_off() full barrier is currently provided by many
> cpumask update operations as well as write_cr3(). Document that
> write_cr3() provides this barrier.
> 
> Changes since v1:
> - Update comments to match reality for code paths which are after
>   storing to rq->curr, before returning to user-space.
> 
> Signed-off-by: Mathieu Desnoyers 
> CC: Peter Zijlstra 
> CC: Paul E. McKenney 
> CC: Boqun Feng 
> CC: Andrew Hunter 
> CC: Maged Michael 
> CC: gro...@google.com
> CC: Avi Kivity 
> CC: Benjamin Herrenschmidt 
> CC: Paul Mackerras 
> CC: Michael Ellerman 
> CC: Dave Watson 
> ---
>  arch/x86/mm/tlb.c| 5 +
>  include/linux/sched/mm.h | 5 +
>  kernel/sched/core.c  | 9 +
>  3 files changed, 19 insertions(+)
> 
> diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
> index 1ab3821f9e26..74f94fe4aded 100644
> --- a/arch/x86/mm/tlb.c
> +++ b/arch/x86/mm/tlb.c
> @@ -144,6 +144,11 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct 
> mm_struct *next,
>   }
>  #endif
>  
> + /*
> +  * The membarrier system call requires a full memory barrier
> +  * before returning to user-space, after storing to rq->curr.
> +  * Writing to CR3 provides that full memory barrier.
> +  */
>   if (real_prev == next) {
>   VM_BUG_ON(this_cpu_read(cpu_tlbstate.ctxs[prev_asid].ctx_id) !=
> next->context.ctx_id);
> diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
> index 3a19c253bdb1..766cc47c4d7c 100644
> --- a/include/linux/sched/mm.h
> +++ b/include/linux/sched/mm.h
> @@ -38,6 +38,11 @@ static inline void mmgrab(struct mm_struct *mm)
>  extern void __mmdrop(struct mm_struct *);
>  static inline void mmdrop(struct mm_struct *mm)
>  {
> + /*
> +  * The implicit full barrier implied by atomic_dec_and_test is
> +  * required by the membarrier system call before returning to
> +  * user-space, after storing to rq->curr.
> +  */
>   if (unlikely(atomic_dec_and_test(>mm_count)))
>   __mmdrop(mm);
>  }
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 18a6966567da..7977b25acf54 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2658,6 +2658,12 @@ static struct rq *finish_task_switch(struct 
> task_struct *prev)
>   finish_arch_post_lock_switch();
>  
>   fire_sched_in_preempt_notifiers(current);
> + /*
> +  * When transitioning from a kernel thread to a userspace
> +  * thread, mmdrop()'s implicit full barrier is required by the
> +  * membarrier system call, because the current active_mm can
> +  * become the current mm without going through switch_mm().
> +  */
>   if (mm)
>   mmdrop(mm);
>   if (unlikely(prev_state == TASK_DEAD)) {
> @@ -3299,6 +3305,9 @@ static void __sched notrace __schedule(bool preempt)
>* Make sure that signal_pending_state()->signal_pending() below
>* can't be reordered with __set_current_state(TASK_INTERRUPTIBLE)
>* done by the caller to avoid the race with signal_wake_up().
> +  *
> +  * The membarrier system call requires a full memory barrier
> +  * after coming from user-space, before storing to rq->curr.
>*/
>   rq_lock(rq, );
>   smp_mb__after_spinlock();
> -- 
> 2.11.0
> 

Re: [PATCH] rwsem: fix missed wakeup due to reordering of load

[Andrea Parri]

On Thu, Sep 07, 2017 at 08:00:58PM +0530, Prateek Sood wrote:
> If a spinner is present, there is a chance that the load of
> rwsem_has_spinner() in rwsem_wake() can be reordered with
> respect to decrement of rwsem count in __up_write() leading
> to wakeup being missed.
> 
>  spinning writer  up_write caller
>  ---  ---
>  [S] osq_unlock() [L] osq
>   spin_lock(wait_lock)
>   sem->count=0x0001
> +0x
>   count=sem->count
>   MB
>sem->count=0xFFFE0001
>  -0x0001
>spin_trylock(wait_lock)
>return
>  rwsem_try_write_lock(count)
>  spin_unlock(wait_lock)
>  schedule()
> 
> Reordering of atomic_long_sub_return_release() in __up_write()
> and rwsem_has_spinner() in rwsem_wake() can cause missing of
> wakeup in up_write() context. In spinning writer, sem->count
> and local variable count is 0XFFFE0001. It would result
> in rwsem_try_write_lock() failing to acquire rwsem and spinning
> writer going to sleep in rwsem_down_write_failed().
> 
> The smp_rmb() will make sure that the spinner state is
> consulted after sem->count is updated in up_write context.
> 
> Signed-off-by: Prateek Sood <prs...@codeaurora.org>

Reviewed-by: Andrea Parri <parri.and...@gmail.com>

I understand that the merge window and LPC made this stalls for
a while... what am I missing? are there other changes that need
to be considered for this patch?

  Andrea


> ---
>  kernel/locking/rwsem-xadd.c | 27 +++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
> index 02f6606..1fefe6d 100644
> --- a/kernel/locking/rwsem-xadd.c
> +++ b/kernel/locking/rwsem-xadd.c
> @@ -613,6 +613,33 @@ struct rw_semaphore *rwsem_wake(struct rw_semaphore *sem)
>   DEFINE_WAKE_Q(wake_q);
>  
>   /*
> + * __rwsem_down_write_failed_common(sem)
> + *   rwsem_optimistic_spin(sem)
> + * osq_unlock(sem->osq)
> + *   ...
> + *   atomic_long_add_return(>count)
> + *
> + *  - VS -
> + *
> + *  __up_write()
> + *if (atomic_long_sub_return_release(>count) < 0)
> + *  rwsem_wake(sem)
> + *osq_is_locked(>osq)
> + *
> + * And __up_write() must observe !osq_is_locked() when it observes the
> + * atomic_long_add_return() in order to not miss a wakeup.
> + *
> + * This boils down to:
> + *
> + * [S.rel] X = 1[RmW] r0 = (Y += 0)
> + * MB RMB
> + * [RmW]   Y += 1   [L]   r1 = X
> + *
> + * exists (r0=1 /\ r1=0)
> + */
> + smp_rmb();
> +
> + /*
>* If a spinner is present, it is not necessary to do the wakeup.
>* Try to do wakeup only if the trylock succeeds to minimize
>* spinlock contention which may introduce too much delay in the
> -- 
> Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, 
> Inc., 
> is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
> 

Re: [PATCH] rwsem: fix missed wakeup due to reordering of load

[Andrea Parri]

On Wed, Sep 20, 2017 at 07:52:54AM -0700, Davidlohr Bueso wrote:
> On Thu, 07 Sep 2017, Prateek Sood wrote:
> > /*
> >+* __rwsem_down_write_failed_common(sem)
> >+*   rwsem_optimistic_spin(sem)
> >+* osq_unlock(sem->osq)
> >+*   ...
> >+*   atomic_long_add_return(>count)
> >+*
> >+*  - VS -
> >+*
> >+*  __up_write()
> >+*if (atomic_long_sub_return_release(>count) < 0)
> >+*  rwsem_wake(sem)
> >+*osq_is_locked(>osq)
> >+*
> >+* And __up_write() must observe !osq_is_locked() when it observes the
> >+* atomic_long_add_return() in order to not miss a wakeup.
> >+*
> >+* This boils down to:
> >+*
> >+* [S.rel] X = 1[RmW] r0 = (Y += 0)
> >+* MB RMB
> >+* [RmW]   Y += 1   [L]   r1 = X
> >+*
> >+* exists (r0=1 /\ r1=0)
> >+*/
> >+smp_rmb();
> 
> Instead, how about just removing the release from 
> atomic_long_sub_return_release()
> such that the osq load is not hoisted over the atomic compound (along with 
> Peter's
> comment):

This solution will actually enforce a stronger (full) ordering w.r.t. the
solution described by Prateek and Peter. Also, it will "trade" two lwsync
for two sync (powerpc), one dmb.ld for one dmb (arm64).

What are the reasons you would prefer this?

  Andrea


> 
> diff --git a/include/asm-generic/rwsem.h b/include/asm-generic/rwsem.h
> index 6c6a2141f271..487ce31078ff 100644
> --- a/include/asm-generic/rwsem.h
> +++ b/include/asm-generic/rwsem.h
> @@ -101,7 +101,7 @@ static inline void __up_read(struct rw_semaphore *sem)
>  */
> static inline void __up_write(struct rw_semaphore *sem)
> {
> - if (unlikely(atomic_long_sub_return_release(RWSEM_ACTIVE_WRITE_BIAS,
> + if (unlikely(atomic_long_sub_return(RWSEM_ACTIVE_WRITE_BIAS,
>   >count) < 0))
>   rwsem_wake(sem);
> }

Re: [PATCH v4 11/13] xen/pvcalls: implement poll command

[Andrea Parri]

Hi Stefano,

On Fri, Sep 15, 2017 at 04:00:38PM -0700, Stefano Stabellini wrote:
> For active sockets, check the indexes and use the inflight_conn_req
> waitqueue to wait.
> 
> For passive sockets if an accept is outstanding
> (PVCALLS_FLAG_ACCEPT_INFLIGHT), check if it has been answered by looking
> at bedata->rsp[req_id]. If so, return POLLIN.  Otherwise use the
> inflight_accept_req waitqueue.
> 
> If no accepts are inflight, send PVCALLS_POLL to the backend. If we have
> outstanding POLL requests awaiting for a response use the inflight_req
> waitqueue: inflight_req is awaken when a new response is received; on
> wakeup we check whether the POLL response is arrived by looking at the
> PVCALLS_FLAG_POLL_RET flag. We set the flag from
> pvcalls_front_event_handler, if the response was for a POLL command.
> 
> In pvcalls_front_event_handler, get the struct sock_mapping from the
> poll id (we previously converted struct sock_mapping* to uint64_t and
> used it as id).
> 
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
> ---
>  drivers/xen/pvcalls-front.c | 144 
> +---
>  drivers/xen/pvcalls-front.h |   3 +
>  2 files changed, 138 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
> index 01a5a69..8a90213 100644
> --- a/drivers/xen/pvcalls-front.c
> +++ b/drivers/xen/pvcalls-front.c
> @@ -85,6 +85,8 @@ struct sock_mapping {
>* Only one poll operation can be inflight for a given socket.
>*/
>  #define PVCALLS_FLAG_ACCEPT_INFLIGHT 0
> +#define PVCALLS_FLAG_POLL_INFLIGHT   1
> +#define PVCALLS_FLAG_POLL_RET2
>   uint8_t flags;
>   uint32_t inflight_req_id;
>   struct sock_mapping *accept_map;
> @@ -155,15 +157,32 @@ static irqreturn_t pvcalls_front_event_handler(int irq, 
> void *dev_id)
>   rsp = RING_GET_RESPONSE(>ring, bedata->ring.rsp_cons);
>  
>   req_id = rsp->req_id;
> - dst = (uint8_t *)>rsp[req_id] + sizeof(rsp->req_id);
> - src = (uint8_t *)rsp + sizeof(rsp->req_id);
> - memcpy(dst, src, sizeof(*rsp) - sizeof(rsp->req_id));
> - /*
> -  * First copy the rest of the data, then req_id. It is
> -  * paired with the barrier when accessing bedata->rsp.
> -  */
> - smp_wmb();
> - WRITE_ONCE(bedata->rsp[req_id].req_id, rsp->req_id);
> + if (rsp->cmd == PVCALLS_POLL) {
> + struct sock_mapping *map = (struct sock_mapping *)
> +rsp->u.poll.id;
> +
> + set_bit(PVCALLS_FLAG_POLL_RET,
> + (void *)>passive.flags);
> + /*
> +  * Set RET, then clear INFLIGHT. It pairs with
> +  * the checks at the beginning of
> +  * pvcalls_front_poll_passive.
> +  */
> + smp_wmb();

pvcalls_front_poll_passive() seems to first check RET, then INFLIGHT
(no "crossing of mem. locations"): can you elaborate here?


> + clear_bit(PVCALLS_FLAG_POLL_INFLIGHT,
> +   (void *)>passive.flags);
> + } else {
> + dst = (uint8_t *)>rsp[req_id] +
> +   sizeof(rsp->req_id);
> + src = (uint8_t *)rsp + sizeof(rsp->req_id);
> + memcpy(dst, src, sizeof(*rsp) - sizeof(rsp->req_id));
> + /*
> +  * First copy the rest of the data, then req_id. It is
> +  * paired with the barrier when accessing bedata->rsp.
> +  */
> + smp_wmb();

Would you point me to the "pairing barrier"? (not sure I understand
the logic here...)


> + WRITE_ONCE(bedata->rsp[req_id].req_id, rsp->req_id);

Could this be rewritten as

   WRITE_ONCE(bedata->rsp[req_id].req_id, req_id);


> + }
>  
>   done = 1;
>   bedata->ring.rsp_cons++;
> @@ -834,6 +853,113 @@ int pvcalls_front_accept(struct socket *sock, struct 
> socket *newsock, int flags)
>   return ret;
>  }
>  
> +static unsigned int pvcalls_front_poll_passive(struct file *file,
> +struct pvcalls_bedata *bedata,
> +struct sock_mapping *map,
> +poll_table *wait)
> +{
> + int notify, req_id, ret;
> + struct xen_pvcalls_request *req;
> +
> + if (test_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
> +  (void *)>passive.flags)) {
> + uint32_t req_id = READ_ONCE(map->passive.inflight_req_id);
> +
> + if (req_id != PVCALLS_INVALID_ID &&
> +

Re: [PATCH] membarrier: Document scheduler barrier requirements

[Andrea Parri]

On Mon, Sep 18, 2017 at 02:01:22PM -0400, Mathieu Desnoyers wrote:
> Document the membarrier requirement on having a full memory barrier in
> __schedule() after coming from user-space, before storing to rq->curr.
> It is provided by smp_mb__before_spinlock() in __schedule().
> 
> Document that membarrier requires a full barrier on transition from
> kernel thread to userspace thread. We currently have an implicit barrier
> from atomic_dec_and_test() in mmdrop() that ensures this.
> 
> The x86 switch_mm_irqs_off() full barrier is currently provided by many
> cpumask update operations as well as write_cr3(). Document that
> write_cr3() provides this barrier.
> 
> Signed-off-by: Mathieu Desnoyers 
> CC: Peter Zijlstra 
> CC: Paul E. McKenney 
> CC: Boqun Feng 
> CC: Andrew Hunter 
> CC: Maged Michael 
> CC: gro...@google.com
> CC: Avi Kivity 
> CC: Benjamin Herrenschmidt 
> CC: Paul Mackerras 
> CC: Michael Ellerman 
> CC: Dave Watson 
> ---
>  arch/x86/mm/tlb.c| 5 +
>  include/linux/sched/mm.h | 4 
>  kernel/sched/core.c  | 9 +
>  3 files changed, 18 insertions(+)
> 
> diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
> index 1ab3821f9e26..fa3bbe048af0 100644
> --- a/arch/x86/mm/tlb.c
> +++ b/arch/x86/mm/tlb.c
> @@ -144,6 +144,11 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct 
> mm_struct *next,
>   }
>  #endif
>  
> + /*
> +  * The membarrier system call requires a full memory barrier
> +  * after coming from user-space, before storing to rq->curr.

I'm confused: isn't this case covered by the

   rq_lock(rq, );
   smp_mb__after_spinlock();

below (all archs)? You meant "before returning to user-space, after
storing to rq->curr"?


> +  * Writing to CR3 provides that full memory barrier.
> +  */
>   if (real_prev == next) {
>   VM_BUG_ON(this_cpu_read(cpu_tlbstate.ctxs[prev_asid].ctx_id) !=
> next->context.ctx_id);
> diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
> index df4005e2c4cf..f3bc261fe7c7 100644
> --- a/include/linux/sched/mm.h
> +++ b/include/linux/sched/mm.h
> @@ -38,6 +38,10 @@ static inline void mmgrab(struct mm_struct *mm)
>  extern void __mmdrop(struct mm_struct *);
>  static inline void mmdrop(struct mm_struct *mm)
>  {
> + /*
> +  * The implicit full barrier implied by atomic_dec_and_test is
> +  * required by the membarrier system call.

"before returning to user-space, after storing to rq->curr", right?

(your commit says "on transition from kernel thread _to_ userspace"
 regarding mmdrop()).

  Andrea


> +  */
>   if (unlikely(atomic_dec_and_test(>mm_count)))
>   __mmdrop(mm);
>  }
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index c5c1b2c51807..48d524b18868 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2648,6 +2648,12 @@ static struct rq *finish_task_switch(struct 
> task_struct *prev)
>   finish_arch_post_lock_switch();
>  
>   fire_sched_in_preempt_notifiers(current);
> + /*
> +  * When transitioning from a kernel thread to a userspace
> +  * thread, mmdrop()'s implicit full barrier is required by the
> +  * membarrier system call, because the current active_mm can
> +  * become the current mm without going through switch_mm().
> +  */
>   if (mm)
>   mmdrop(mm);
>   if (unlikely(prev_state == TASK_DEAD)) {
> @@ -3289,6 +3295,9 @@ static void __sched notrace __schedule(bool preempt)
>* Make sure that signal_pending_state()->signal_pending() below
>* can't be reordered with __set_current_state(TASK_INTERRUPTIBLE)
>* done by the caller to avoid the race with signal_wake_up().
> +  *
> +  * The membarrier system call requires a full memory barrier
> +  * after coming from user-space, before storing to rq->curr.
>*/
>   rq_lock(rq, );
>   smp_mb__after_spinlock();
> -- 
> 2.11.0
> 

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

[Andrea Parri]

On Mon, Oct 09, 2017 at 10:16:37AM +0200, Peter Zijlstra wrote:
> On Sat, Oct 07, 2017 at 11:28:57AM -0700, Paul E. McKenney wrote:
> > But if you are saying that it would be good to have wait_for_completion()
> > and complete() directly modeled at some point, no argument.  In addition,
> > I hope that the memory model is applied to other tools that analyze kernel
> > code.
> 
> > > I'm not sure I got the point across; so I'll try once more. Without
> > > providing this ordering the completion would be fundamentally broken. It
> > > _must_ provide this ordering.
> > 
> > OK, I now understand what you are getting at, and I do very much like
> > that guarantee.
> 
> Right, so maybe we should update the completion comments a bit to call
> out this property, because I'm not sure its there.
> 
> Also, with this, I think the smp_store_release() / smp_load_acquire() is
> a perfectly fine abstraction of it, I don't think the model needs to be
> taught about the completion interface.
> 
> > > Why not? In what sort of cases does it go wobbly?
> > 
> > For one, when it conflicts with maintainability.  For example, it would
> > probably be OK for some of RCU's rcu_node ->lock acquisitions to skip the
> > smp_mb__after_unlock_lock() invocations.  But those are slowpaths, and the
> > small speedup on only one architecture is just not worth the added pain.
> > Especially given the nice wrapper functions that you provided.
> > 
> > But of course if this were instead (say) rcu_read_lock() or common-case
> > rcu_read_unlock(), I would be willing to undergo much more pain.  On the
> > other hand, for that exact reason, that common-case code path doesn't
> > acquire locks in the first place.  ;-)
> 
> Ah, so for models I would go absolutely minimal; it helps understand
> what the strict requirements are and where we over-provide etc..

Except, maybe, that simplicity and maintainability do apply to "models"
(design) as well... ;-)

As Ingo once put it [1] (referring to the "Linux-kernel memory model"):

  "it's not true that Linux has to offer a barrier and locking model
   that panders to the weakest (and craziest!) memory ordering model
   amongst all the possible Linux platforms - theoretical or real metal.

   Instead what we want to do is to consciously, intelligently _pick_
   a sane, maintainable memory model and offer primitives for that -
   at least as far as generic code is concerned. Each architecture can
   map those primitives to the best of its abilities."

  Andrea

[1] https://marc.info/?l=linux-mm=138513336717990=2


> 
> For actual code you're entirely right, there's no point in trying to be
> cute with the rcu-node locks. Simplicity rules etc..

Re: Linux-kernel examples for LKMM recipes

[Andrea Parri]

Hi Paul,

On Wed, Oct 11, 2017 at 03:32:30PM -0700, Paul E. McKenney wrote:
> Hello!
> 
> At Linux Plumbers Conference, we got requests for a recipes document,
> and a further request to point to actual code in the Linux kernel.
> I have pulled together some examples for various litmus-test families,
> as shown below.  The decoder ring for the abbreviations (ISA2, LB, SB,
> MP, ...) is here:
> 
>   https://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test6.pdf
> 
> This document is also checked into the memory-models git archive:
> 
>   https://github.com/aparri/memory-model.git
> 
> I would be especially interested in simpler examples in general, and
> of course any example at all for the cases where I was unable to find
> any.  Thoughts?

Below are some examples we did discuss (at some point):

The comment in kernel/events/ring_buffer.c:perf_output_put_handle()
describes instances of MP+wmb+rmb and LB+ctrl+mb.

The comments in kernel/sched/core.c:try_to_wake_up() describes more
instances of MP ("plus locking") and LB (see finish_lock_switch()).

The comment in kernel/sched/core.c:task_rq_lock() describes an ins-
tance of MP+wmb+addr-acqpo.

The comment in include/linux/wait.h:waitqueue_active() describes an
instance of SB+mb+mb.

63cae12bce986 ("perf/core: Fix sys_perf_event_open() vs. hotplug")
describes an instance of W+RWC+porel+mb+mb.

[...]

I wish we could say "any barrier (explicit or implicit) in sources
is accompanied by a comment mentioning the interested pattern...",
but life is not always this simple. ;-)

  Andrea


> 
>   Thanx, Paul
> 
> 
> 
> This document lists the litmus-test patterns that we have been discussing,
> along with examples from the Linux kernel.  This is intended to feed into
> the recipes document.  All examples are from v4.13.
> 
> 0.Single-variable SC.
> 
>   a.  Within a single CPU, the use of the ->dynticks_nmi_nesting
>   counter by rcu_nmi_enter() and rcu_nmi_exit() qualifies
>   (see kernel/rcu/tree.c).  The counter is accessed by
>   interrupts and NMIs as well as by process-level code.
>   This counter can be accessed by other CPUs, but only
>   for debug output.
> 
>   b.  Between CPUs, I would put forward the ->dflags
>   updates, but this is anything but simple.  But maybe
>   OK for an illustration?
> 
> 1.MP (see test6.pdf for nickname translation)
> 
>   a.  smp_store_release() / smp_load_acquire()
> 
>   init_stack_slab() in lib/stackdepot.c uses release-acquire
>   to handle initialization of a slab of the stack.  Working
>   out the mutual-exclusion design is left as an exercise for
>   the reader.
> 
>   b.  rcu_assign_pointer() / rcu_dereference()
> 
>   expand_to_next_prime() does the rcu_assign_pointer(),
>   and next_prime_number() does the rcu_dereference().
>   This mediates access to a bit vector that is expanded
>   as additional primes are needed.  These two functions
>   are in lib/prime_numbers.c.
> 
>   c.  smp_wmb() / smp_rmb()
> 
>   xlog_state_switch_iclogs() contains the following:
> 
>   log->l_curr_block -= log->l_logBBsize;
>   ASSERT(log->l_curr_block >= 0);
>   smp_wmb();
>   log->l_curr_cycle++;
> 
>   And xlog_valid_lsn() contains the following:
> 
>   cur_cycle = ACCESS_ONCE(log->l_curr_cycle);
>   smp_rmb();
>   cur_block = ACCESS_ONCE(log->l_curr_block);
> 
>   d.  Replacing either of the above with smp_mb()
> 
>   Holding off on this one for the moment...
> 
> 2.Release-acquire chains, AKA ISA2, Z6.2, LB, and 3.LB
> 
>   Lots of variety here, can in some cases substitute:
>   
>   a.  READ_ONCE() for smp_load_acquire()
>   b.  WRITE_ONCE() for smp_store_release()
>   c.  Dependencies for both smp_load_acquire() and
>   smp_store_release().
>   d.  smp_wmb() for smp_store_release() in first thread
>   of ISA2 and Z6.2.
>   e.  smp_rmb() for smp_load_acquire() in last thread of ISA2.
> 
>   The canonical illustration of LB involves the various memory
>   allocators, where you don't want a load from about-to-be-freed
>   memory to see a store initializing a later incarnation of that
>   same memory area.  But the per-CPU caches make this a very
>   long and complicated example.
> 
>   I am not aware of any three-CPU release-acquire chains in the
>   Linux kernel.  There are three-CPU lock-based chains in RCU,
>   but these are not at all simple, either.
> 
>   Thoughts?
> 
> 3.  

Re: [PATCH] blk-mq: Start to fix memory ordering...

[Andrea Parri]

On Mon, Sep 04, 2017 at 11:09:32AM +0200, Peter Zijlstra wrote:
> 
> Attempt to untangle the ordering in blk-mq. The patch introducing the
> single smp_mb__before_atomic() is obviously broken in that it doesn't
> clearly specify a pairing barrier and an obtained guarantee.
> 
> The comment is further misleading in that it hints that the
> deadline store and the COMPLETE store also need to be ordered, but
> AFAICT there is no such dependency. However what does appear to be
> important is the clear happening _after_ the store, and that worked by
> pure accident.
> 
> This clarifies blk_mq_start_request() -- we should not get there with
> STARTING set -- this simplifies the code and makes the barrier usage
> sane (the old code could be read to allow not having _any_ atomic after
> the barrier, in which case the barrier hasn't got anything to order). We
> then also introduce the missing pairing barrier for it.
> 
> And it documents the STARTING vs COMPLETE ordering. Although I've not
> been entirely successful in reverse engineering the blk-mq state
> machine so there might still be more funnies around timeout vs
> requeue.
> 
> If I got anything wrong, feel free to educate me by adding comments to
> clarify things ;-)
> 
> Cc: Alan Stern <st...@rowland.harvard.edu>
> Cc: Will Deacon <will.dea...@arm.com>
> Cc: Ming Lei <tom.leim...@gmail.com>
> Cc: Jens Axboe <ax...@fb.com>
> Cc: Andrea Parri <parri.and...@gmail.com>
> Cc: Boqun Feng <boqun.f...@gmail.com>
> Cc: "Paul E. McKenney" <paul...@linux.vnet.ibm.com>
> Cc: Christoph Hellwig <h...@lst.de>
> Cc: Bart Van Assche <bart.vanass...@wdc.com>
> Fixes: 538b75341835 ("blk-mq: request deadline must be visible before marking 
> rq as started")
> Signed-off-by: Peter Zijlstra (Intel) <pet...@infradead.org>
> ---
>  block/blk-mq.c |   48 +---
>  1 file changed, 37 insertions(+), 11 deletions(-)
> 
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -558,22 +558,29 @@ void blk_mq_start_request(struct request
>  
>   blk_add_timer(rq);
>  
> - /*
> -  * Ensure that ->deadline is visible before set the started
> -  * flag and clear the completed flag.
> -  */
> - smp_mb__before_atomic();
> + WARN_ON_ONCE(test_bit(REQ_ATOM_STARTED, >atomic_flags));
>  
>   /*
>* Mark us as started and clear complete. Complete might have been
>* set if requeue raced with timeout, which then marked it as
>* complete. So be sure to clear complete again when we start
>* the request, otherwise we'll ignore the completion event.
> +  *
> +  * Ensure that ->deadline is visible before set STARTED, such that
> +  * blk_mq_check_expired() is guaranteed to observe our ->deadline
> +  * when it observes STARTED.
>*/
> - if (!test_bit(REQ_ATOM_STARTED, >atomic_flags))
> - set_bit(REQ_ATOM_STARTED, >atomic_flags);
> - if (test_bit(REQ_ATOM_COMPLETE, >atomic_flags))
> + smp_mb__before_atomic();

I am wondering whether we should be using smp_wmb() instead: this would
provide the above guarantee and save a full barrier on powerpc/arm64.


> + set_bit(REQ_ATOM_STARTED, >atomic_flags);
> + if (test_bit(REQ_ATOM_COMPLETE, >atomic_flags)) {
> + /*
> +  * Coherence order guarantees these consequtive stores to a
> +  * singe variable propagate in the specified order. Thus the
> +  * clear_bit() is ordered _after_ the set bit. See
> +  * blk_mq_check_expired().
> +  */
>   clear_bit(REQ_ATOM_COMPLETE, >atomic_flags);

It could be useful to stress that set_bit(), clear_bit()  must "act" on
the same subword of the unsigned long (whatever "subword" means at this
level...) to rely on the coherence order (c.f., alpha's implementation).


> + }
>  
>   if (q->dma_drain_size && blk_rq_bytes(rq)) {
>   /*
> @@ -744,11 +751,20 @@ static void blk_mq_check_expired(struct
>   struct request *rq, void *priv, bool reserved)
>  {
>   struct blk_mq_timeout_data *data = priv;
> + unsigned long deadline;
>  
>   if (!test_bit(REQ_ATOM_STARTED, >atomic_flags))
>   return;
>  
>   /*
> +  * Ensures that if we see STARTED we must also see our
> +  * up-to-date deadline, see blk_mq_start_request().
> +  */
> + smp_rmb();
> +
> + deadline = READ_ONCE(rq->deaedline);
> +
> + /*
>* The rq being checked may have been freed and reallocated
&g

Re: [PATCH] swait: add missing barrier to swake_up

[Andrea Parri]

On Fri, Sep 01, 2017 at 04:14:50PM +1000, Nicholas Piggin wrote:
> swake_up and swake_up_all test the swaitqueue outside the lock,
> but they are missing the barrier that would ensure visibility
> of a previous store that sets the wakeup condition with the
> load that tests the swaitqueue. This could lead to a lost wakeup
> if there is memory reordering. Fix this as prescribed by the
> waitqueue_active comments.
> 
> Signed-off-by: Nicholas Piggin 
> --
> I noticed this when chasing down that rcu hang bug (which
> turned out to not be anything of the sort). I might be missing
> something here and it's safe somehow, but if so then it should
> have a comment where it diverges from normal waitqueues.
> 
> It looks like there's a few callers which are also testing
> swait_active before swake_up without a barrier which look wrong,
> so I must be missing something but I'm not sure what.

Hi Nicholas. I noticed

  35a2897c2a306cca344ca5c0b43416707018f434
  ("sched/wait: Remove the lockless swait_active() check in swake_up*()")

in tip:locking/core.

  Andrea


> 
> Thanks,
> Nick
> ---
>  kernel/sched/swait.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/kernel/sched/swait.c b/kernel/sched/swait.c
> index 3d5610dcce11..9056278001d9 100644
> --- a/kernel/sched/swait.c
> +++ b/kernel/sched/swait.c
> @@ -33,6 +33,11 @@ void swake_up(struct swait_queue_head *q)
>  {
>   unsigned long flags;
>  
> + /*
> +  * See waitqueue_active() comments for checking waiters outside
> +  * the lock. Same principle applies here.
> +  */
> + smp_mb();
>   if (!swait_active(q))
>   return;
>  
> @@ -51,6 +56,11 @@ void swake_up_all(struct swait_queue_head *q)
>   struct swait_queue *curr;
>   LIST_HEAD(tmp);
>  
> + /*
> +  * See waitqueue_active() comments for checking waiters outside
> +  * the lock. Same principle applies here.
> +  */
> + smp_mb();
>   if (!swait_active(q))
>   return;
>  
> -- 
> 2.13.3
> 

Re: [RFC PATCH 1/2] arm64: mm: Use READ_ONCE/WRITE_ONCE when accessing page tables

[Andrea Parri]

Hi Will,

none of my comments below represent objections to this patch, but
let me remark:


On Thu, Oct 05, 2017 at 05:31:54PM +0100, Will Deacon wrote:
> Hi Paul,
> 
> On Tue, Oct 03, 2017 at 12:11:10PM -0700, Paul E. McKenney wrote:
> > On Fri, Sep 29, 2017 at 05:33:49PM +0100, Will Deacon wrote:
> > > On Fri, Sep 29, 2017 at 09:29:39AM -0700, Paul E. McKenney wrote:
> > > > On Fri, Sep 29, 2017 at 10:08:43AM +0100, Will Deacon wrote:
> > > > > Ok, but where does that leave us wrt my initial proposal of moving
> > > > > smp_read_barrier_depends() into READ_ONCE and getting rid of
> > > > > lockless_dereference?
> > > > > 
> > > > > Michael (or anybody else running mainline on SMP Alpha) -- would you 
> > > > > be
> > > > > able to give the diff below a spin and see whether there's a 
> > > > > measurable
> > > > > performance impact?
> > > > 
> > > > This will be a sensitive test.  The smp_read_barrier_depends() can be
> > > > removed from lockless_dereference().  Without this removal Alpha will
> > > > get two memory barriers from rcu_dereference() and friends.
> > > 
> > > Oh yes, good point. I was trying to keep the diff simple, but you're
> > > right that this is packing too many barriers. Fixed diff below.
> > 
> > Not seeing any objections thus far.  If there are none by (say) the
> > end of this week, I would be happy to queue a patch for the 4.16
> > merge window.  That should give ample opportunity for further review
> > and testing.
> 
> Ok, full patch below.
> 
> Will
> 
> --->8
> 
> From 15956d0cc6b37208d8542b1858a8d8b64227acf4 Mon Sep 17 00:00:00 2001
> From: Will Deacon 
> Date: Thu, 5 Oct 2017 16:57:36 +0100
> Subject: [PATCH] locking/barriers: Kill lockless_dereference
> 
> lockless_dereference is a nice idea, but it's gained little traction in
> kernel code since it's introduction three years ago. This is partly
> because it's a pain to type, but also because using READ_ONCE instead
> will work correctly on all architectures apart from Alpha, which is a
> fully supported but somewhat niche architecture these days.

lockless_dereference might be a mouthful, but it does (explicitly)
say/remark: "Yep, we are relying on the following address dep. to
be "in strong-ppo" ".

Such information will be lost or, at least, not immediately clear
by just reading a READ_ONCE(). (And Yes, this information is only
relevant when we "include" Alpha in the picture/analysis.)


> 
> This patch moves smp_read_barrier_depends() (a NOP on all architectures
> other than Alpha) from lockless_dereference into READ_ONCE, converts
> the few actual users over to READ_ONCE and then finally removes
> lockless_dereference altogether.

Notice that several "potential users" of lockless_dereference are
currently hidden in other call sites for smp_read_barrier_depends
(i.e., cases where this barrier is not called from within a lock-
less or an RCU dereference).

Some of these usages (e.g.,

  include/linux/percpu-refcount.h:__ref_is_percpu,
  mm/ksm.c:get_ksm_page,
  security/keys/keyring.c:search_nested_keyrings )

precedes this barrier with a READ_ONCE; others (e.g.,

  arch/alpha/include/asm/pgtable.h:pmd_offset,
  net/ipv4/netfilter/arp_tables.c:arpt_do_table
  kernel/kernel/events/uprobes.c:get_trampiline_vaddr )

with a plain read.

There also appear to be cases where the barrier is preceded by an
ACCESS_ONCE (c.f, fs/dcache.c:prepend_name) or by an xchg_release
(c.f., kernel/locking/qspinlock.c:queued_spin_lock_slowpath), and
it would not be difficult to imagine/create different usages.


> 
> Signed-off-by: Will Deacon 

I understand that we all agree we're missing a Tested-by here ;-).

  Andrea


> ---
>  Documentation/memory-barriers.txt   | 12 
>  .../translations/ko_KR/memory-barriers.txt  | 12 
>  arch/x86/events/core.c  |  2 +-
>  arch/x86/include/asm/mmu_context.h  |  4 ++--
>  arch/x86/kernel/ldt.c   |  2 +-
>  drivers/md/dm-mpath.c   | 20 ++--
>  fs/dcache.c |  4 ++--
>  fs/overlayfs/ovl_entry.h|  2 +-
>  fs/overlayfs/readdir.c  |  2 +-
>  include/linux/compiler.h| 21 
> +
>  include/linux/rculist.h |  4 ++--
>  include/linux/rcupdate.h|  4 ++--
>  kernel/events/core.c|  4 ++--
>  kernel/seccomp.c|  2 +-
>  kernel/task_work.c  |  2 +-
>  mm/slab.h   |  2 +-
>  16 files changed, 28 insertions(+), 71 deletions(-)
> 
> diff --git a/Documentation/memory-barriers.txt 
> b/Documentation/memory-barriers.txt
> index b759a60624fd..470a682f3fa4 100644
> --- 

Re: [PATCH tip/core/rcu 1/3] membarrier: Provide register expedited private command

[Andrea Parri]

On Thu, Oct 05, 2017 at 04:02:06PM +, Mathieu Desnoyers wrote:
> - On Oct 5, 2017, at 8:12 AM, Peter Zijlstra pet...@infradead.org wrote:
> 
> > On Wed, Oct 04, 2017 at 02:37:53PM -0700, Paul E. McKenney wrote:
> >> diff --git a/arch/powerpc/kernel/membarrier.c 
> >> b/arch/powerpc/kernel/membarrier.c
> >> new file mode 100644
> >> index ..b0d79a5f5981
> >> --- /dev/null
> >> +++ b/arch/powerpc/kernel/membarrier.c
> >> @@ -0,0 +1,45 @@
> > 
> >> +void membarrier_arch_register_private_expedited(struct task_struct *p)
> >> +{
> >> +  struct task_struct *t;
> >> +
> >> +  if (get_nr_threads(p) == 1) {
> >> +  set_thread_flag(TIF_MEMBARRIER_PRIVATE_EXPEDITED);
> >> +  return;
> >> +  }
> >> +  /*
> >> +   * Coherence of TIF_MEMBARRIER_PRIVATE_EXPEDITED against thread
> >> +   * fork is protected by siglock.
> >> +   */
> >> +  spin_lock(>sighand->siglock);
> >> +  for_each_thread(p, t)
> >> +  set_ti_thread_flag(task_thread_info(t),
> >> +  TIF_MEMBARRIER_PRIVATE_EXPEDITED);
> > 
> > I'm not sure this works correctly vs CLONE_VM without CLONE_THREAD.
> 
> The intent here is to hold the sighand siglock to provide mutual
> exclusion against invocation of membarrier_fork(p, clone_flags)
> by copy_process().
> 
> copy_process() grabs spin_lock(>sighand->siglock) for both
> CLONE_THREAD and not CLONE_THREAD flags.
> 
> What am I missing here ?
> 
> > 
> >> +  spin_unlock(>sighand->siglock);
> >> +  /*
> >> +   * Ensure all future scheduler executions will observe the new
> >> +   * thread flag state for this process.
> >> +   */
> >> +  synchronize_sched();
> > 
> > This relies on the flag being read inside rq->lock, right?
> 
> Yes. The flag is read by membarrier_arch_switch_mm(), invoked
> within switch_mm_irqs_off(), called by context_switch() before
> finish_task_switch() releases the rq lock.

I fail to graps the relation between this synchronize_sched() and rq->lock.

(Besides, we made no reference to rq->lock while discussing:

  
https://github.com/paulmckrcu/litmus/commit/47039df324b60ace0cf7b2403299580be730119b
  replace membarrier_arch_sched_in with switch_mm_irqs_off )

Could you elaborate?

  Andrea


> 
> Is the comment clear enough, or do you have suggestions for
> improvements ?



> 
> Thanks,
> 
> Mathieu
> 
> > 
> > > +}
> 
> -- 
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com

Re: [PATCH tip/core/rcu 1/3] membarrier: Provide register expedited private command

[Andrea Parri]

On Fri, Oct 06, 2017 at 10:32:19AM +0200, Peter Zijlstra wrote:
> > AFAIU the scheduler rq->lock is held while preemption is disabled.
> > synchronize_sched() is used here to ensure that all pre-existing
> > preempt-off critical sections have completed.
> > 
> > So saying that we use synchronize_sched() to synchronize with rq->lock
> > would be stretching the truth a bit. It's actually only true because the
> > scheduler holding the rq->lock is surrounded by a preempt-off
> > critical section.
> 
> No, rq->lock is sufficient, note that rq->lock is a raw_spinlock_t which
> implies !preempt. Yes, we also surround the rq->lock usage with a
> slightly larger preempt_disable() section but that's not in fact
> required for this.

That's what it is, according to the current sources: we seemed to agree that
a preempt-off critical section is what we rely on here and that the start of
this critical section is not marked by that raw_spin_lock.

  Andrea

[Question] drivers/infiniband: on smp_read_barrier_depends() usages

[Andrea Parri]

Dear IB supporters,

I was reviewing current usages of smp_read_barrier_depends()

   https://marc.info/?l=linux-kernel=150723193717856=2

when I stubled over drivers/infiniband/: I've found 19 instances of this
barrier here, but their intent is unclear to me and I'm wondering if you
could clarify it. (Most of these usages are accompanied by the comment

   /* see post_one_send() */

suggesting that they're sharing a common intent.)

Thanks in advance,
  Andrea

Re: Memory-ordering recipes

[Andrea Parri]

On Tue, Oct 17, 2017 at 02:01:37PM -0700, Paul E. McKenney wrote:
> On Sun, Sep 17, 2017 at 04:05:09PM -0700, Paul E. McKenney wrote:
> > Hello!
> > 
> > The topic of memory-ordering recipes came up at the Linux Plumbers
> > Conference microconference on Friday, so I thought that I should summarize
> > what is currently "out there":
> 
> And here is an updated list of potential Linux-kernel examples for a
> "recipes" document, and thank you for the feedback.  Please feel free
> to counterpropose better examples.  In addition, if there is some other
> pattern that is commonplace and important enough to be included in a
> recipes document, please point it out.
> 
>   Thanx, Paul
> 
> 
> 
> This document lists the litmus-test patterns that we have been discussing,
> along with examples from the Linux kernel.  This is intended to feed into
> the recipes document.  All examples are from v4.13.
> 
> 0.Simple special cases
> 
>   If there is only one CPU on the one hand or only one variable
>   on the other, the code will execute in order.  There are (as
>   usual) some things to be careful of:
> 
>   a.  There are some aspects of the C language that are
>   unordered.  For example, in the expression "f(x) + g(y)",
>   the order in which f and g are called is not defined;
>   the object code is allowed to use either order or even
>   to interleave the computations.
> 
>   b.  Compilers are permitted to use the "as-if" rule.  That is,
>   a compiler can emit whatever code it likes, as long as
>   the results of a single-threaded execution appear just
>   as if the compiler had followed all the relevant rules.
>   To see this, compile with a high level of optimization
>   and run the debugger on the resulting binary.
> 
>   c.  If there is only one variable but multiple CPUs, all
>   that variable must be properly aligned and all accesses
>   to that variable must be full sized.  Variables that
>   straddle cachelines or pages void your full-ordering
>   warranty, as do undersized accesses that load from or
>   store to only part of the variable.
> 
> 1.Another simple case: Locking.  [ Assuming you don't think too
>   hard about it, that is! ]
> 
>   Any CPU that has acquired a given lock sees any changes previously
>   made by any CPU prior to having released that same lock.
> 
>   [ Should we discuss chaining back through different locks,
> sort of like release-acquire chains? ]
> 
> 2.MP (see test6.pdf for nickname translation)
> 
>   a.  smp_store_release() / smp_load_acquire()
> 
>   init_stack_slab() in lib/stackdepot.c uses release-acquire
>   to handle initialization of a slab of the stack.  Working
>   out the mutual-exclusion design is left as an exercise for
>   the reader.
> 
>   b.  rcu_assign_pointer() / rcu_dereference()
> 
>   expand_to_next_prime() does the rcu_assign_pointer(),
>   and next_prime_number() does the rcu_dereference().
>   This mediates access to a bit vector that is expanded
>   as additional primes are needed.  These two functions
>   are in lib/prime_numbers.c.
> 
>   c.  smp_wmb() / smp_rmb()
> 
>   xlog_state_switch_iclogs() contains the following:
> 
>   log->l_curr_block -= log->l_logBBsize;
>   ASSERT(log->l_curr_block >= 0);
>   smp_wmb();
>   log->l_curr_cycle++;
> 
>   And xlog_valid_lsn() contains the following:
> 
>   cur_cycle = ACCESS_ONCE(log->l_curr_cycle);
>   smp_rmb();
>   cur_block = ACCESS_ONCE(log->l_curr_block);
> 
>   Alternatively, from the comment in perf_output_put_handle()
>   in kernel/events/ring_buffer.c:
> 
>*   kernel user
>*
>*   if (LOAD ->data_tail) {LOAD ->data_head
>*  (A) smp_rmb()   (C)
>*  STORE $data LOAD $data
>*  smp_wmb()   (B) smp_mb()(D)
>*  STORE ->data_head   STORE ->data_tail
>*   }
>*
>* Where A pairs with D, and B pairs with C.
> 
>   The B/C pairing is MP with smp_wmb() and smp_rmb().
> 
>   d.  Replacing either of the above with smp_mb()
> 
>   Holding off on this one for the moment...
> 
> 3.LB
> 
>   a.  LB+ctrl+mb

Re: [PATCH] refcount: provide same memory ordering guarantees as in atomic_t

[Andrea Parri]

On Wed, Nov 15, 2017 at 09:03:07PM +0100, Peter Zijlstra wrote:
> On Wed, Nov 15, 2017 at 02:15:19PM -0500, Alan Stern wrote:
> > On Wed, 15 Nov 2017, Will Deacon wrote:
> > 
> > > On Thu, Nov 02, 2017 at 04:21:56PM -0400, Alan Stern wrote:
> > > > I was trying to think of something completely different.  If you have a
> > > > release/acquire to the same address, it creates a happens-before
> > > > ordering:
> > > > 
> > > > Access x
> > > > Release a
> > > > Acquire a
> > > > Access y
> > > > 
> > > > Here is the access to x happens-before the access to y.  This is true
> > > > even on x86, even in the presence of forwarding -- the CPU still has to
> > > > execute the instructions in order.  But if the release and acquire are
> > > > to different addresses:
> > > > 
> > > > Access x
> > > > Release a
> > > > Acquire b
> > > > Access y
> > > > 
> > > > then there is no happens-before ordering for x and y -- the CPU can
> > > > execute the last two instructions before the first two.  x86 and
> > > > PowerPC won't do this, but I believe ARMv8 can.  (Please correct me if
> > > > it can't.)
> > > 
> > > Release/Acquire are RCsc on ARMv8, so they are ordered irrespective of
> > > address.
> > 
> > Ah, okay, thanks.
> > 
> > In any case, we have considered removing this ordering constraint
> > (store-release followed by load-acquire for the same location) from the
> > Linux-kernel memory model.
> 
> Why? Its a perfectly sensible construct.
> 
> > I'm not aware of any code in the kernel that depends on it.  Do any of
> > you happen to know of any examples?
> 
> All locks? Something like:
> 
>   spin_lock()
>   /* foo */
>   spin_unlock()
>   spin_lock()
>   /* bar */
>   spin_unlock();
> 
> Has a fairly high foo happens-before bar expectation level.
> 
> And in specific things like:
> 
>   135e8c9250dd5
>   ecf7d01c229d1
> 
> which use the release of rq->lock paired with the next acquire of the
> same rq->lock to match with an smp_rmb().

Those cycles are currently forbidden by LKMM _when_ you consider the
smp_mb__after_spinlock() from schedule().  See rfi-rel-acq-is-not-mb
from my previous email and Alan's remarks about cumul-fence.

  Andrea

Re: Prototype patch for Linux-kernel memory model

[Andrea Parri]

On Fri, Nov 17, 2017 at 07:27:46PM +0800, Boqun Feng wrote:
> On Wed, Nov 15, 2017 at 08:37:49AM -0800, Paul E. McKenney wrote:
> > On Tue, Nov 14, 2017 at 09:15:05AM -0800, Paul E. McKenney wrote:
> > > On Tue, Nov 14, 2017 at 10:19:21AM -0500, Alan Stern wrote:
> > > > On Tue, 14 Nov 2017, Peter Zijlstra wrote:
> > > > 
> > > > > On Mon, Nov 13, 2017 at 10:40:31AM -0800, Paul E. McKenney wrote:
> > > > > > commit 82a1431549b4eae531e83298fd72cd0acea08540
> > > > > > Author: Paul E. McKenney <paul...@linux.vnet.ibm.com>
> > > > > > Date:   Mon Nov 13 10:30:07 2017 -0800
> > > > > > 
> > > > > > tools: Automate memory-barriers.txt; provide Linux-kernel 
> > > > > > memory model
> > > > > > 
> > > > > > There is some reason to believe that 
> > > > > > Documentation/memory-barriers.txt
> > > > > > could use some help, and a major purpose of this patch is to 
> > > > > > provide
> > > > > > that help in the form of a design-time tool that can produce 
> > > > > > all valid
> > > > > > executions of a small fragment of concurrent Linux-kernel code, 
> > > > > > which is
> > > > > > called a "litmus test".  This tool's functionality is roughly 
> > > > > > similar to
> > > > > > a full state-space search.  Please note that this is a 
> > > > > > design-time tool,
> > > > > > not useful for regression testing.  However, we hope that the 
> > > > > > underlying
> > > > > > Linux-kernel memory model will be incorporated into other tools 
> > > > > > capable
> > > > > > of analyzing large bodies of code for regression-testing 
> > > > > > purposes.
> > > > > > 
> > > > > > The main tool is herd7, together with the linux-kernel.bell,
> > > > > > linux-kernel.cat, linux-kernel.cfg, linux-kernel.def, and 
> > > > > > lock.cat files
> > > > > > added by this patch.  The herd7 executable takes the other 
> > > > > > files as input,
> > > > > > and all of these files collectively define the Linux-kernel 
> > > > > > memory memory
> > > > > > model.  A brief description of each of these other files is 
> > > > > > provided
> > > > > > in the README file.  Although this tool does have its 
> > > > > > limitations,
> > > > > > which are documented in the README file, it does improve on the 
> > > > > > version
> > > > > > reported on in the LWN series (https://lwn.net/Articles/718628/ 
> > > > > > and
> > > > > > https://lwn.net/Articles/720550/) by supporting locking and 
> > > > > > arithmetic,
> > > > > > including a much wider variety of read-modify-write atomic 
> > > > > > operations.
> > > > > > Please note that herd7 is not part of this submission, but is 
> > > > > > freely
> > > > > > available from http://diy.inria.fr/sources/index.html (and via 
> > > > > > "git"
> > > > > > at https://github.com/herd/herdtools7).
> > > > > > 
> > > > > > A second tool is klitmus7, which converts litmus tests to 
> > > > > > loadable
> > > > > > kernel modules for direct testing.  As with herd7, the klitmus7
> > > > > > code is freely available from 
> > > > > > http://diy.inria.fr/sources/index.html
> > > > > > (and via "git" at https://github.com/herd/herdtools7).
> > > > > > 
> > > > > > Of course, litmus tests are not always the best way to fully 
> > > > > > understand a
> > > > > > memory model, so this patch also includes 
> > > > > > Documentation/explanation.txt,
> > > > > > which describes the memory model in detail.  In addition,
> > > > > > Documentation/recipes.txt provides example known-good and 
> > > > > > known-bad use
> > > > > > cases for those who prefer working by example.
> > > > >

Re: [PATCH] refcount: provide same memory ordering guarantees as in atomic_t

[Andrea Parri]

On Thu, Nov 16, 2017 at 09:58:04AM +0100, Peter Zijlstra wrote:
> On Wed, Nov 15, 2017 at 10:01:11PM +0100, Andrea Parri wrote:
> 
> > > And in specific things like:
> > > 
> > >   135e8c9250dd5
> > >   ecf7d01c229d1
> > > 
> > > which use the release of rq->lock paired with the next acquire of the
> > > same rq->lock to match with an smp_rmb().
> > 
> > Those cycles are currently forbidden by LKMM _when_ you consider the
> > smp_mb__after_spinlock() from schedule().  See rfi-rel-acq-is-not-mb
> > from my previous email and Alan's remarks about cumul-fence.
> 
> I'm not sure I get your point; and you all seem to forget I do not in
> fact speak the ordering lingo. So I have no idea what
> rfi-blah-blah or cumul-fence mean.

I expand on my comment. Consider the following test:

C T1

{}

P0(int *x, int *y, spinlock_t *s)
{
spin_lock(s);
WRITE_ONCE(*x, 1);
spin_unlock(s);
spin_lock(s);
WRITE_ONCE(*y, 1);
spin_unlock(s);
}

P1(int *x, int *y)
{
int r0;
int r1;

r0 = READ_ONCE(*y);
smp_rmb();
r1 = READ_ONCE(*x);
}

exists (1:r0=1 /\ 1:r1=0)

According to LKMM, the store to x happens before the store to y but there
is no guarantee that the former store propagate (to P1) before the latter
(which is what we need to forbid that state).  As a result, that state in
the "exists" clause is _allowed_ by LKMM.

The LKMM encodes happens-before (or execution) ordering with a relation
named "hb", while it encodes "propagation ordering" with "cumul-fence".

  Andrea


> 
> I know rel-acq isn't smp_mb() and I don't think any of the above patches
> need it to be. They just need it do be a local ordering, no?
> 
> Even without smp_mb__after_spinlock() we get that:
> 
>   spin_lock()
>   x = 1
>   spin_unlock()
>   spin_lock()
>   y = 1
>   spin_unlock()
> 
> guarantees that x happens-before y, right?
> 
> And that should be sufficient to then order something else against, like
> for example:
> 
>   r2 = y
>   smp_rmb()
>   r1 = x
> 
> no?
> 
> 

Re: [PATCH] refcount: provide same memory ordering guarantees as in atomic_t

[Andrea Parri]

On Thu, Nov 02, 2017 at 01:08:52PM -0400, Alan Stern wrote:
> On Thu, 2 Nov 2017, Peter Zijlstra wrote:
> 
> > On Thu, Nov 02, 2017 at 11:40:35AM -0400, Alan Stern wrote:
> > > On Thu, 2 Nov 2017, Peter Zijlstra wrote:
> > > 
> > > > > Lock functions such as refcount_dec_and_lock() &
> > > > > refcount_dec_and_mutex_lock() Provide exactly the same guarantees as
> > > > > they atomic counterparts. 
> > > > 
> > > > Nope. The atomic_dec_and_lock() provides smp_mb() while
> > > > refcount_dec_and_lock() merely orders all prior load/store's against all
> > > > later load/store's.
> > > 
> > > In fact there is no guaranteed ordering when refcount_dec_and_lock()  
> > > returns false; 
> > 
> > It should provide a release:
> > 
> >  - if !=1, dec_not_one will provide release
> >  - if ==1, dec_not_one will no-op, but then we'll acquire the lock and
> >dec_and_test will provide the release, even if the test fails and we
> >unlock again it should still dec.
> > 
> > The one exception is when the counter is saturated, but in that case
> > we'll never free the object and the ordering is moot in any case.
> 
> Also if the counter is 0, but that will never happen if the 
> refcounting is correct.
> 
> > > it provides ordering only if the return value is true.  
> > > In which case it provides acquire ordering (thanks to the spin_lock),
> > > and both release ordering and a control dependency (thanks to the
> > > refcount_dec_and_test).
> > > 
> > > > The difference is subtle and involves at least 3 CPUs. I can't seem to
> > > > write up anything simple, keeps turning into monsters :/ Will, Paul,
> > > > have you got anything simple around?
> > > 
> > > The combination of acquire + release is not the same as smp_mb, because 
> > 
> > acquire+release is nothing, its release+acquire that I meant which
> > should order things locally, but now that you've got me looking at it
> > again, we don't in fact do that.
> > 
> > So refcount_dec_and_lock() will provide a release, irrespective of the
> > return value (assuming we're not saturated). If it returns true, it also
> > does an acquire for the lock.
> > 
> > But combined they're acquire+release, which is unfortunate.. it means
> > the lock section and the refcount stuff overlaps, but I don't suppose
> > that's actually a problem. Need to consider more.
> 
> Right.  To address your point: release + acquire isn't the same as a
> full barrier either.  The SB pattern illustrates the difference:
> 
>   P0  P1
>   Write x=1   Write y=1
>   Release a   smp_mb
>   Acquire b   Read x=0
>   Read y=0
> 
> This would not be allowed if the release + acquire sequence was 
> replaced by smp_mb.  But as it stands, this is allowed because nothing 
> prevents the CPU from interchanging the order of the release and the 
> acquire -- and then you're back to the acquire + release case.
> 
> However, there is one circumstance where this interchange isn't 
> allowed: when the release and acquire access the same memory 
> location.  Thus:
> 
>   P0(int *x, int *y, int *a)
>   {
>   int r0;
> 
>   WRITE_ONCE(*x, 1);
>   smp_store_release(a, 1);
>   smp_load_acquire(a);
>   r0 = READ_ONCE(*y);
>   }
> 
>   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 forbidden.  It would remain forbidden even if the smp_mb in P1 
> were replaced by a similar release/acquire pair for the same memory 
> location.

Hopefully, the LKMM does not agree with this assessment... ;-)


> 
> To see the difference between smp_mb and release/acquire requires three 
> threads:
> 
>   P0  P1  P2
>   Write x=1   Read y=1Read z=1
>   Release a   data dep.   smp_rmb
>   Acquire a   Write z=1   Read x=0
>   Write y=1
> 
> The Linux Kernel Memory Model allows this execution, although as far as 
> I know, no existing hardware will do it.  But with smp_mb in P0, the 
> execution would be forbidden.

Here's a two-threads example showing that "(w)mb is _not_ rfi-rel-acq":

C rfi-rel-acq-is-not-mb

{}

P0(int *x, int *y, int *a)
{
WRITE_ONCE(*x, 1);
smp_store_release(a, 1);
r1 = smp_load_acquire(a);
WRITE_ONCE(*y, 1);
}

P1(int *x, int *y)
{
int r0;
int r1;

r0 = READ_ONCE(*y);
smp_rmb();
r1 = READ_ONCE(*x);
}

exists (1:r0=1 /\ 1:r1=0)

  Andrea


> 
> None of this should be a problem for refcount_dec_and_lock, assuming it 
> is used purely for reference counting.
> 
> Alan Stern
> 

Re: [patches] Re: [GIT PULL] RISC-V Cleanups and ABI Fixes for 4.15-rc2

[Andrea Parri]

On Thu, Dec 07, 2017 at 12:59:35PM -0800, Palmer Dabbelt wrote:
> On Sat, 02 Dec 2017 19:20:02 PST (-0800), parri.and...@gmail.com wrote:
> >On Fri, Dec 01, 2017 at 01:39:12PM -0800, Palmer Dabbelt wrote:
> >>  RISC-V: Remove smb_mb__{before,after}_spinlock()
> >
> >I wonder whether you really meant to remove smp_mb__after_spinlock():
> >on the one hand, this primitive doesn't seem "obsolete" (as suggested
> >by the commit message); on the other hand, the Draft Specification at
> >
> >  https://marc.info/?l=linux-kernel=151218405830993=2
> >
> >suggests that you need "to strengthen" the generic implementation for
> >this primitive (considered the current spinlock.h in riscv).  What am
> >I missing?
> 
> The comment was incorrect, which caused me to incorrectly remove the fence
> from our port.  I just sent out a patch (well, actually, I did last night --
> I just found this email sitting in a buffer...).
> 
>  https://lkml.org/lkml/2017/12/6/1136

Thank you for the clarification (and for the patch),

  Andrea


> 
> Thanks for catching this!

Re: [GIT PULL] RISC-V Cleanups and ABI Fixes for 4.15-rc2

[Andrea Parri]

Hi Palmer,

On Fri, Dec 01, 2017 at 01:39:12PM -0800, Palmer Dabbelt wrote:
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
> 
>   Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
> 
> are available in the git repository at:
> 
>   ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git 
> tags/riscv-for-linus-4.15-rc2_cleanups
> 
> for you to fetch changes up to 3b62de26cf5ef17340a0e986d3e53eb4f74f96d5:
> 
>   RISC-V: Fixes for clean allmodconfig build (2017-12-01 13:31:31 -0800)
> 
> 
> RISC-V Cleanups and ABI Fixes for 4.15-rc2
> 
> This tag contains a handful of small cleanups that are a result of
> feedback that didn't make it into our original patch set, either because
> the feedback hadn't been given yet, I missed the original emails, or
> we weren't ready to submit the changes yet.
> 
> I've been maintaining the various cleanup patch sets I have as their own
> branches, which I then merged together and signed.  Each merge commit
> has a short summary of the changes, and each branch is based on your
> latest tag (4.15-rc1, in this case).  If this isn't the right way to do
> this then feel free to suggest something else, but it seems sane to me.
> 
> Here's a short summary of the changes, roughly in order of how
> interesting they are.
> 
> * libgcc.h has been moved from include/lib, where it's the only member,
>   to include/linux.  This is meant to avoid tab completion conflicts.
> * VDSO entries for clock_get/gettimeofday/getcpu have been added.  These
>   are simple syscalls now, but we want to let glibc use them from the
>   start so we can make them faster later.
> * A VDSO entry for instruction cache flushing has been added so
>   userspace can flush the instruction cache.
> * The VDSO symbol versions for __vdso_cmpxchg{32,64} have been removed,
>   as those VDSO entries don't actually exist.
> * __io_writes has been corrected to respect the given type.
> * A new READ_ONCE in arch_spin_is_locked().
> * __test_and_op_bit_ord() is now actually ordered.
> * Various small fixes throughout the tree to enable allmodconfig to
>   build cleanly.
> * Removal of some dead code in our atomic support headers.
> * Improvements to various comments in our atomic support headers.
> 
> 
> Andrew Waterman (3):
>   RISC-V: Add VDSO entries for clock_get/gettimeofday/getcpu
>   RISC-V: Flush I$ when making a dirty page executable
>   RISC-V: Allow userspace to flush the instruction cache
> 
> Christoph Hellwig (1):
>   move libgcc.h to include/linux
> 
> Olof Johansson (8):
>   RISC-V: use generic serial.h
>   RISC-V: use RISCV_{INT,SHORT} instead of {INT,SHORT} for asm macros
>   RISC-V: io.h: type fixes for warnings
>   RISC-V: move empty_zero_page definition to C and export it
>   RISC-V: Export some expected symbols for modules
>   RISC-V: Provide stub of setup_profiling_timer()
>   RISC-V: Use define for get_cycles like other architectures
>   RISC-V: Add missing include
> 
> Palmer Dabbelt (16):
>   RISC-V: Remove __vdso_cmpxchg{32,64} symbol versions
>   RISC-V: Remove unused arguments from ATOMIC_OP
>   RISC-V: Comment on why {,cmp}xchg is ordered how it is
>   RISC-V: Remove __smp_bp__{before,after}_atomic
>   RISC-V: Remove smb_mb__{before,after}_spinlock()

I wonder whether you really meant to remove smp_mb__after_spinlock():
on the one hand, this primitive doesn't seem "obsolete" (as suggested
by the commit message); on the other hand, the Draft Specification at

  https://marc.info/?l=linux-kernel=151218405830993=2

suggests that you need "to strengthen" the generic implementation for
this primitive (considered the current spinlock.h in riscv).  What am
I missing?

  Andrea


>   RISC-V: __test_and_op_bit_ord should be strongly ordered
>   RISC-V: Add READ_ONCE in arch_spin_is_locked()
>   RISC-V: `sfence.vma` orderes the instruction cache
>   RISC-V: remove spin_unlock_wait()
>   RISC-V: Clean up an unused include
>   RISC-V: __io_writes should respect the length argument
>   RISC-V Atomic Cleanups
>   RISC-V: User-Visible Changes
>   RISC-V: __io_writes should respect the length argument
>   move libgcc.h to include/linux
>   RISC-V: Fixes for clean allmodconfig build
> 
>  arch/riscv/include/asm/Kbuild  |   1 +
>  arch/riscv/include/asm/asm.h   |  12 ++--
>  arch/riscv/include/asm/atomic.h| 103 
> +
>  arch/riscv/include/asm/barrier.h   |  23 
>  arch/riscv/include/asm/bitops.h|   2 +-
>  arch/riscv/include/asm/bug.h   |   6 +-
>  arch/riscv/include/asm/cacheflush.h|  30 --
>  arch/riscv/include/asm/io.h|  18 +++---
>  arch/riscv/include/asm/mmu.h   |   4 ++
>  arch/riscv/include/asm/mmu_context.h   |  45 

Re: [PATCH] refcount_t: documentation for memory ordering differences

[Andrea Parri]

On Fri, Dec 01, 2017 at 12:34:23PM -0800, Randy Dunlap wrote:
> On 11/29/2017 04:36 AM, Elena Reshetova wrote:
> > Some functions from refcount_t API provide different
> > memory ordering guarantees that their atomic counterparts.
> > This adds a document outlining these differences.
> > 
> > Signed-off-by: Elena Reshetova 
> > ---
> >  Documentation/core-api/index.rst  |   1 +
> >  Documentation/core-api/refcount-vs-atomic.rst | 129 
> > ++
> >  2 files changed, 130 insertions(+)
> >  create mode 100644 Documentation/core-api/refcount-vs-atomic.rst
> 
> > diff --git a/Documentation/core-api/refcount-vs-atomic.rst 
> > b/Documentation/core-api/refcount-vs-atomic.rst
> > new file mode 100644
> > index 000..5619d48
> > --- /dev/null
> > +++ b/Documentation/core-api/refcount-vs-atomic.rst
> > @@ -0,0 +1,129 @@
> > +===
> > +refcount_t API compared to atomic_t
> > +===
> > +
> > +The goal of refcount_t API is to provide a minimal API for implementing
> > +an object's reference counters. While a generic architecture-independent
> > +implementation from lib/refcount.c uses atomic operations underneath,
> > +there are a number of differences between some of the refcount_*() and
> > +atomic_*() functions with regards to the memory ordering guarantees.
> > +This document outlines the differences and provides respective examples
> > +in order to help maintainers validate their code against the change in
> > +these memory ordering guarantees.
> > +
> > +memory-barriers.txt and atomic_t.txt provide more background to the
> > +memory ordering in general and for atomic operations specifically.
> > +
> > +Relevant types of memory ordering
> > +=
> > +
> > +**Note**: the following section only covers some of the memory
> > +ordering types that are relevant for the atomics and reference
> > +counters and used through this document. For a much broader picture
> > +please consult memory-barriers.txt document.
> > +
> > +In the absence of any memory ordering guarantees (i.e. fully unordered)
> > +atomics & refcounters only provide atomicity and
> > +program order (po) relation (on the same CPU). It guarantees that
> > +each atomic_*() and refcount_*() operation is atomic and instructions
> > +are executed in program order on a single CPU.
> > +This is implemented using READ_ONCE()/WRITE_ONCE() and
> > +compare-and-swap primitives.
> > +
> > +A strong (full) memory ordering guarantees that all prior loads and
> > +stores (all po-earlier instructions) on the same CPU are completed
> > +before any po-later instruction is executed on the same CPU.
> > +It also guarantees that all po-earlier stores on the same CPU
> > +and all propagated stores from other CPUs must propagate to all
> > +other CPUs before any po-later instruction is executed on the original
> > +CPU (A-cumulative property). This is implemented using smp_mb().
> 
> I don't know what "A-cumulative property" means, and google search didn't
> either.

The description above seems to follow the (informal) definition given in:

  
https://github.com/aparri/memory-model/blob/master/Documentation/explanation.txt
  (c.f., in part., Sect. 13-14)

and formalized by the LKMM. (The notion of A-cumulativity also appears, in
different contexts, in some memory consistency literature, e.g.,

  http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/index.html
  http://www.cl.cam.ac.uk/~pes20/armv8-mca/
  https://arxiv.org/abs/1308.6810 )

A typical illustration of A-cumulativity (for smp_store_release(), say) is
given with the following program:

int x = 0;
int y = 0;

void thread0()
{
WRITE_ONCE(x, 1);
}

void thread1()
{
int r0;

r0 = READ_ONCE(x);
smp_store_release(, 1);
}

void thread2()
{
int r1;
int r2;

r1 = READ_ONCE(y);
smp_rmb();
r2 = READ_ONCE(x);
}

(This is a variation of the so called "message-passing" pattern, where the
 stores are "distributed" over two threads; see also

  
https://github.com/aparri/memory-model/blob/master/litmus-tests/WRC%2Bpooncerelease%2Brmbonceonce%2BOnce.litmus
 )

The question we want to address is whether the final state

  (r0 == 1 && r1 == 1 && r2 == 0)

can be reached/is allowed, and the answer is no (due to the A-cumulativity
of the store-release).

By contrast, dependencies provides no (A-)cumulativity; for example, if we
modify the previous program by replacing the store-release with a data dep.
as follows:

int x = 0;
int y = 0;

void thread0()
{
WRITE_ONCE(x, 1);
}

void thread1()
{
int r0;

r0 = READ_ONCE(x);
WRITE_ONCE(x, r0);
}

void thread2()
{
int r1;
int r2;

r1 = READ_ONCE(y);
smp_rmb();
r2 = READ_ONCE(x);
}

then that same final state is allowed (and observed on some PPC machines).

  Andrea


> 
> Is it non-cumulative, similar to 

Re: [PATCH] refcount_t: documentation for memory ordering differences

[Andrea Parri]

On Sun, Dec 03, 2017 at 07:20:03AM +0100, Andrea Parri wrote:
> On Fri, Dec 01, 2017 at 12:34:23PM -0800, Randy Dunlap wrote:
> > On 11/29/2017 04:36 AM, Elena Reshetova wrote:
> > > Some functions from refcount_t API provide different
> > > memory ordering guarantees that their atomic counterparts.
> > > This adds a document outlining these differences.
> > > 
> > > Signed-off-by: Elena Reshetova <elena.reshet...@intel.com>
> > > ---
> > >  Documentation/core-api/index.rst  |   1 +
> > >  Documentation/core-api/refcount-vs-atomic.rst | 129 
> > > ++
> > >  2 files changed, 130 insertions(+)
> > >  create mode 100644 Documentation/core-api/refcount-vs-atomic.rst
> > 
> > > diff --git a/Documentation/core-api/refcount-vs-atomic.rst 
> > > b/Documentation/core-api/refcount-vs-atomic.rst
> > > new file mode 100644
> > > index 000..5619d48
> > > --- /dev/null
> > > +++ b/Documentation/core-api/refcount-vs-atomic.rst
> > > @@ -0,0 +1,129 @@
> > > +===
> > > +refcount_t API compared to atomic_t
> > > +===
> > > +
> > > +The goal of refcount_t API is to provide a minimal API for implementing
> > > +an object's reference counters. While a generic architecture-independent
> > > +implementation from lib/refcount.c uses atomic operations underneath,
> > > +there are a number of differences between some of the refcount_*() and
> > > +atomic_*() functions with regards to the memory ordering guarantees.
> > > +This document outlines the differences and provides respective examples
> > > +in order to help maintainers validate their code against the change in
> > > +these memory ordering guarantees.
> > > +
> > > +memory-barriers.txt and atomic_t.txt provide more background to the
> > > +memory ordering in general and for atomic operations specifically.
> > > +
> > > +Relevant types of memory ordering
> > > +=
> > > +
> > > +**Note**: the following section only covers some of the memory
> > > +ordering types that are relevant for the atomics and reference
> > > +counters and used through this document. For a much broader picture
> > > +please consult memory-barriers.txt document.
> > > +
> > > +In the absence of any memory ordering guarantees (i.e. fully unordered)
> > > +atomics & refcounters only provide atomicity and
> > > +program order (po) relation (on the same CPU). It guarantees that
> > > +each atomic_*() and refcount_*() operation is atomic and instructions
> > > +are executed in program order on a single CPU.
> > > +This is implemented using READ_ONCE()/WRITE_ONCE() and
> > > +compare-and-swap primitives.
> > > +
> > > +A strong (full) memory ordering guarantees that all prior loads and
> > > +stores (all po-earlier instructions) on the same CPU are completed
> > > +before any po-later instruction is executed on the same CPU.
> > > +It also guarantees that all po-earlier stores on the same CPU
> > > +and all propagated stores from other CPUs must propagate to all
> > > +other CPUs before any po-later instruction is executed on the original
> > > +CPU (A-cumulative property). This is implemented using smp_mb().
> > 
> > I don't know what "A-cumulative property" means, and google search didn't
> > either.
> 
> The description above seems to follow the (informal) definition given in:
> 
>   
> https://github.com/aparri/memory-model/blob/master/Documentation/explanation.txt
>   (c.f., in part., Sect. 13-14)
> 
> and formalized by the LKMM. (The notion of A-cumulativity also appears, in
> different contexts, in some memory consistency literature, e.g.,
> 
>   http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/index.html
>   http://www.cl.cam.ac.uk/~pes20/armv8-mca/
>   https://arxiv.org/abs/1308.6810 )
> 
> A typical illustration of A-cumulativity (for smp_store_release(), say) is
> given with the following program:
> 
> int x = 0;
> int y = 0;
> 
> void thread0()
> {
>   WRITE_ONCE(x, 1);
> }
> 
> void thread1()
> {
>   int r0;
> 
>   r0 = READ_ONCE(x);
>   smp_store_release(, 1);
> }
> 
> void thread2()
> {
>   int r1;
>   int r2;
> 
>   r1 = READ_ONCE(y);
>   smp_rmb();
>   r2 = READ_ONCE(x);
> }
> 
> (This is a variation of the so called "message-passing&

[PATCH] Documentation: refcount-vs-atomic: Update reference to LKMM doc.

[Andrea Parri]

The LKMM project has moved to 'tools/memory-model/'.

Signed-off-by: Andrea Parri <andrea.pa...@amarulasolutions.com>
---
 Documentation/core-api/refcount-vs-atomic.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/core-api/refcount-vs-atomic.rst 
b/Documentation/core-api/refcount-vs-atomic.rst
index 83351c258cdb9..322851bada167 100644
--- a/Documentation/core-api/refcount-vs-atomic.rst
+++ b/Documentation/core-api/refcount-vs-atomic.rst
@@ -17,7 +17,7 @@ in order to help maintainers validate their code against the 
change in
 these memory ordering guarantees.
 
 The terms used through this document try to follow the formal LKMM defined in
-github.com/aparri/memory-model/blob/master/Documentation/explanation.txt
+tools/memory-model/Documentation/explanation.txt.
 
 memory-barriers.txt and atomic_t.txt provide more background to the
 memory ordering in general and for atomic operations specifically.
-- 
2.7.4

Re: [PATCH] Documentation: refcount-vs-atomic: Update reference to LKMM doc.

[Andrea Parri]

On Fri, May 04, 2018 at 02:13:59PM -0700, Kees Cook wrote:
> On Fri, May 4, 2018 at 2:11 PM, Andrea Parri
> <andrea.pa...@amarulasolutions.com> wrote:
> > The LKMM project has moved to 'tools/memory-model/'.
> >
> > Signed-off-by: Andrea Parri <andrea.pa...@amarulasolutions.com>
> > ---
> >  Documentation/core-api/refcount-vs-atomic.rst | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/core-api/refcount-vs-atomic.rst 
> > b/Documentation/core-api/refcount-vs-atomic.rst
> > index 83351c258cdb9..322851bada167 100644
> > --- a/Documentation/core-api/refcount-vs-atomic.rst
> > +++ b/Documentation/core-api/refcount-vs-atomic.rst
> > @@ -17,7 +17,7 @@ in order to help maintainers validate their code against 
> > the change in
> >  these memory ordering guarantees.
> >
> >  The terms used through this document try to follow the formal LKMM defined 
> > in
> > -github.com/aparri/memory-model/blob/master/Documentation/explanation.txt
> > +tools/memory-model/Documentation/explanation.txt.
> >
> >  memory-barriers.txt and atomic_t.txt provide more background to the
> >  memory ordering in general and for atomic operations specifically.
> 
> Will this get linkified by rst ?

I believe not, but I'm not too familiar with rst...  FWIW, I'm seeing that
the above memory-barriers.txt, atomic_t.txt are not linkified.

  Andrea


> 
> -Kees
> 
> -- 
> Kees Cook
> Pixel Security

[RFC PATCH v3 0/6] Documentation/features: Provide and apply 'features-refresh.sh'

[Andrea Parri]

Hi,

This series provides the script 'features-refresh.sh', which operates on
the arch support status files, and it applies this script to refresh the
status files in place; previous discussions about this series are at [1].

The series is organized as follows.

  - Patch 1/6 adds the script to 'Documentation/features/scripts/'.

  - Patch 2/6 presents the results of running the script; this run
also printed the messages

   WARNING: 'HAVE_BPF_JIT' is not a valid Kconfig
   WARNING: '__HAVE_ARCH_STRNCASECMP' is not a valid Kconfig
   WARNING: 'Optimized asm/rwsem.h' is not a valid Kconfig
   WARNING: '__HAVE_ARCH_PTE_SPECIAL' is not a valid Kconfig

to standard output.

  - Patches 3-6/6 fix each of these warnings.

(Applies on -rc4.)

Cheers,
  Andrea

[1] 
http://lkml.kernel.org/r/1523205027-31786-1-git-send-email-andrea.pa...@amarulasolutions.com

http://lkml.kernel.org/r/1522774551-9503-1-git-send-email-andrea.pa...@amarulasolutions.com
http://lkml.kernel.org/r/20180328122211.GA25420@andrea

Changes in v3:
  - rebase on -rc4

Changes in v2:
  - support negation operators in Kconfig (suggested by Ingo Molnar)
  - reorder patches 2/6 and 3/6 (suggested by Ingo Molnar)
  - add patches 4-6/6 (suggested by Ingo Molnar)

Andrea Parri (6):
  Documentation/features: Add script that refreshes the arch support
status files in place
  Documentation/features: Refresh the arch support status files in place
  Documentation/features/core: Add arch support status files for
'cBPF-JIT' and 'eBPF-JIT'
  Documentation/features/locking: Use '!RWSEM_GENERIC_SPINLOCK' as
Kconfig for 'rwsem-optimized'
  Documentation/features/lib: Remove arch support status file for
'strncasecmp'
  Documentation/features/vm: Remove arch support status file for
'pte_special'

 .../features/core/BPF-JIT/arch-support.txt | 31 ---
 .../features/core/cBPF-JIT/arch-support.txt| 33 
 .../features/core/eBPF-JIT/arch-support.txt| 33 
 .../core/generic-idle-thread/arch-support.txt  |  4 +-
 .../features/core/jump-labels/arch-support.txt |  2 +
 .../features/core/tracehook/arch-support.txt   |  2 +
 .../features/debug/KASAN/arch-support.txt  |  4 +-
 .../debug/gcov-profile-all/arch-support.txt|  2 +
 Documentation/features/debug/kgdb/arch-support.txt |  4 +-
 .../debug/kprobes-on-ftrace/arch-support.txt   |  2 +
 .../features/debug/kprobes/arch-support.txt|  4 +-
 .../features/debug/kretprobes/arch-support.txt |  4 +-
 .../features/debug/optprobes/arch-support.txt  |  4 +-
 .../features/debug/stackprotector/arch-support.txt |  2 +
 .../features/debug/uprobes/arch-support.txt|  6 +-
 .../debug/user-ret-profiler/arch-support.txt   |  2 +
 .../features/io/dma-api-debug/arch-support.txt |  2 +
 .../features/io/dma-contiguous/arch-support.txt|  4 +-
 .../features/io/sg-chain/arch-support.txt  |  2 +
 .../features/lib/strncasecmp/arch-support.txt  | 31 ---
 .../locking/cmpxchg-local/arch-support.txt |  4 +-
 .../features/locking/lockdep/arch-support.txt  |  4 +-
 .../locking/queued-rwlocks/arch-support.txt| 10 ++-
 .../locking/queued-spinlocks/arch-support.txt  |  8 +-
 .../locking/rwsem-optimized/arch-support.txt   | 10 ++-
 .../features/perf/kprobes-event/arch-support.txt   |  6 +-
 .../features/perf/perf-regs/arch-support.txt   |  4 +-
 .../features/perf/perf-stackdump/arch-support.txt  |  4 +-
 .../sched/membarrier-sync-core/arch-support.txt|  2 +
 .../features/sched/numa-balancing/arch-support.txt |  6 +-
 Documentation/features/scripts/features-refresh.sh | 98 ++
 .../seccomp/seccomp-filter/arch-support.txt|  6 +-
 .../time/arch-tick-broadcast/arch-support.txt  |  4 +-
 .../features/time/clockevents/arch-support.txt |  4 +-
 .../time/context-tracking/arch-support.txt |  2 +
 .../features/time/irq-time-acct/arch-support.txt   |  4 +-
 .../time/modern-timekeeping/arch-support.txt   |  2 +
 .../features/time/virt-cpuacct/arch-support.txt|  2 +
 .../features/vm/ELF-ASLR/arch-support.txt  |  4 +-
 .../features/vm/PG_uncached/arch-support.txt   |  2 +
 Documentation/features/vm/THP/arch-support.txt |  2 +
 Documentation/features/vm/TLB/arch-support.txt |  2 +
 .../features/vm/huge-vmap/arch-support.txt |  2 +
 .../features/vm/ioremap_prot/arch-support.txt  |  2 +
 .../features/vm/numa-memblock/arch-support.txt |  4 +-
 .../features/vm/pte_special/arch-support.txt   | 31 ---
 46 files changed, 279 insertions(+), 128 deletions(-)
 delete mode 100644 Documentation/features/core/BPF-JIT/arch-support.txt
 create mode 100644 Documentation/features/core/cBPF-JIT/arch-support.txt
 create mode 100644 Documentation/features/core/eBPF-JIT/arch-support.txt
 delete mode 100644 Documentation/features/lib/strncasecmp/arch-support.txt
 create mode 100755 Documentation

[RFC PATCH v3 3/6] Documentation/features/core: Add arch support status files for 'cBPF-JIT' and 'eBPF-JIT'

[Andrea Parri]

Commit 606b5908e split 'HAVE_BPF_JIT' into cBPF and eBPF variant.
Adds arch support status files for the new variants, and removes the
status file corresponding to 'HAVE_BPT_JIT'. The new status matrices
were auto-generated using the script 'features-refresh.sh'.

Signed-off-by: Andrea Parri <andrea.pa...@amarulasolutions.com>
Cc: Ingo Molnar <mi...@kernel.org>
Cc: Jonathan Corbet <cor...@lwn.net>
Cc: Andrew Morton <a...@linux-foundation.org>
---
 .../features/core/BPF-JIT/arch-support.txt | 33 --
 .../features/core/cBPF-JIT/arch-support.txt| 33 ++
 .../features/core/eBPF-JIT/arch-support.txt| 33 ++
 3 files changed, 66 insertions(+), 33 deletions(-)
 delete mode 100644 Documentation/features/core/BPF-JIT/arch-support.txt
 create mode 100644 Documentation/features/core/cBPF-JIT/arch-support.txt
 create mode 100644 Documentation/features/core/eBPF-JIT/arch-support.txt

diff --git a/Documentation/features/core/BPF-JIT/arch-support.txt 
b/Documentation/features/core/BPF-JIT/arch-support.txt
deleted file mode 100644
index d277f971ccd6b..0
--- a/Documentation/features/core/BPF-JIT/arch-support.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-#
-# Feature name:  BPF-JIT
-# Kconfig:   HAVE_BPF_JIT
-# description:   arch supports BPF JIT optimizations
-#
----
-| arch |status|
----
-|   alpha: | TODO |
-| arc: | TODO |
-| arm: |  ok  |
-|   arm64: |  ok  |
-| c6x: | TODO |
-|   h8300: | TODO |
-| hexagon: | TODO |
-|ia64: | TODO |
-|m68k: | TODO |
-|  microblaze: | TODO |
-|mips: |  ok  |
-|   nds32: | TODO |
-|   nios2: | TODO |
-|openrisc: | TODO |
-|  parisc: | TODO |
-| powerpc: |  ok  |
-|   riscv: | TODO |
-|s390: |  ok  |
-|  sh: | TODO |
-|   sparc: |  ok  |
-|  um: | TODO |
-|   unicore32: | TODO |
-| x86: |  ok  |
-|  xtensa: | TODO |
----
diff --git a/Documentation/features/core/cBPF-JIT/arch-support.txt 
b/Documentation/features/core/cBPF-JIT/arch-support.txt
new file mode 100644
index 0..90459cdde3143
--- /dev/null
+++ b/Documentation/features/core/cBPF-JIT/arch-support.txt
@@ -0,0 +1,33 @@
+#
+# Feature name:  cBPF-JIT
+# Kconfig:   HAVE_CBPF_JIT
+# description:   arch supports cBPF JIT optimizations
+#
+---
+| arch |status|
+---
+|   alpha: | TODO |
+| arc: | TODO |
+| arm: | TODO |
+|   arm64: | TODO |
+| c6x: | TODO |
+|   h8300: | TODO |
+| hexagon: | TODO |
+|ia64: | TODO |
+|m68k: | TODO |
+|  microblaze: | TODO |
+|mips: |  ok  |
+|   nds32: | TODO |
+|   nios2: | TODO |
+|openrisc: | TODO |
+|  parisc: | TODO |
+| powerpc: |  ok  |
+|   riscv: | TODO |
+|s390: | TODO |
+|  sh: | TODO |
+|   sparc: |  ok  |
+|  um: | TODO |
+|   unicore32: | TODO |
+| x86: | TODO |
+|  xtensa: | TODO |
+---
diff --git a/Documentation/features/core/eBPF-JIT/arch-support.txt 
b/Documentation/features/core/eBPF-JIT/arch-support.txt
new file mode 100644
index 0..c90a0382fe667
--- /dev/null
+++ b/Documentation/features/core/eBPF-JIT/arch-support.txt
@@ -0,0 +1,33 @@
+#
+# Feature name:  eBPF-JIT
+# Kconfig:   HAVE_EBPF_JIT
+# description:   arch supports eBPF JIT optimizations
+#
+---
+| arch |status|
+---
+|   alpha: | TODO |
+| arc: | TODO |
+| arm: |  ok  |
+|   arm64: |  ok  |
+| c6x: | TODO |
+|   h8300: | TODO |
+| hexagon: | TODO |
+|ia64: | TODO |
+|m68k: | TODO |
+|  microblaze: | TODO |
+|mips: |  ok  |
+|   nds32: | TODO |
+|   nios2: | TODO |
+|openrisc: | TODO |
+|  parisc: | TODO |
+| powerpc: |  ok  |
+|   riscv: | TODO |
+|s390: |  ok  |
+|  sh: | TODO |
+|   sparc: |  ok  |
+|  um: | TODO |
+|   unicore32: | TODO |
+| x86: |  ok  |
+|  xtensa: | TODO |
+---
-- 
2.7.4

[RFC PATCH v3 4/6] Documentation/features/locking: Use '!RWSEM_GENERIC_SPINLOCK' as Kconfig for 'rwsem-optimized'

[Andrea Parri]

Uses '!RWSEM_GENERIC_SPINLOCK' in place of 'Optimized asm/rwsem.h' as
Kconfig for 'rwsem-optimized': the new Kconfig expresses this feature
equivalently, while also enabling the script 'features-refresh.sh' to
operate on the corresponding arch support status file. Also refreshes
the status matrix by using the script 'features-refresh.sh'.

Suggested-by: Ingo Molnar <mi...@kernel.org>
Signed-off-by: Andrea Parri <andrea.pa...@amarulasolutions.com>
Cc: Ingo Molnar <mi...@kernel.org>
Cc: Jonathan Corbet <cor...@lwn.net>
Cc: Andrew Morton <a...@linux-foundation.org>
---
 Documentation/features/locking/rwsem-optimized/arch-support.txt | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/features/locking/rwsem-optimized/arch-support.txt 
b/Documentation/features/locking/rwsem-optimized/arch-support.txt
index 8afe24ffa3ab4..e54b1f1a8091d 100644
--- a/Documentation/features/locking/rwsem-optimized/arch-support.txt
+++ b/Documentation/features/locking/rwsem-optimized/arch-support.txt
@@ -1,6 +1,6 @@
 #
 # Feature name:  rwsem-optimized
-# Kconfig:   Optimized asm/rwsem.h
+# Kconfig:   !RWSEM_GENERIC_SPINLOCK
 # description:   arch provides optimized rwsem APIs
 #
 ---
@@ -8,8 +8,8 @@
 ---
 |   alpha: |  ok  |
 | arc: | TODO |
-| arm: | TODO |
-|   arm64: | TODO |
+| arm: |  ok  |
+|   arm64: |  ok  |
 | c6x: | TODO |
 |   h8300: | TODO |
 | hexagon: | TODO |
@@ -26,7 +26,7 @@
 |s390: |  ok  |
 |  sh: |  ok  |
 |   sparc: |  ok  |
-|  um: | TODO |
+|  um: |  ok  |
 |   unicore32: | TODO |
 | x86: |  ok  |
 |  xtensa: |  ok  |
-- 
2.7.4

Re: [PATCH] locking/atomics: Simplify the op definitions in atomic.h some more

[Andrea Parri]

On Sun, May 06, 2018 at 04:57:27PM +0200, Ingo Molnar wrote:
> 
> * Andrea Parri <andrea.pa...@amarulasolutions.com> wrote:
> 
> > Hi Ingo,
> > 
> > > From 5affbf7e91901143f84f1b2ca64f4afe70e210fd Mon Sep 17 00:00:00 2001
> > > From: Ingo Molnar <mi...@kernel.org>
> > > Date: Sat, 5 May 2018 10:23:23 +0200
> > > Subject: [PATCH] locking/atomics: Simplify the op definitions in atomic.h 
> > > some more
> > > 
> > > Before:
> > > 
> > >  #ifndef atomic_fetch_dec_relaxed
> > >  # ifndef atomic_fetch_dec
> > >  #  define atomic_fetch_dec(v)atomic_fetch_sub(1, (v))
> > >  #  define atomic_fetch_dec_relaxed(v)
> > > atomic_fetch_sub_relaxed(1, (v))
> > >  #  define atomic_fetch_dec_acquire(v)
> > > atomic_fetch_sub_acquire(1, (v))
> > >  #  define atomic_fetch_dec_release(v)
> > > atomic_fetch_sub_release(1, (v))
> > >  # else
> > >  #  define atomic_fetch_dec_relaxed   atomic_fetch_dec
> > >  #  define atomic_fetch_dec_acquire   atomic_fetch_dec
> > >  #  define atomic_fetch_dec_release   atomic_fetch_dec
> > >  # endif
> > >  #else
> > >  # ifndef atomic_fetch_dec_acquire
> > >  #  define atomic_fetch_dec_acquire(...)  
> > > __atomic_op_acquire(atomic_fetch_dec, __VA_ARGS__)
> > >  # endif
> > >  # ifndef atomic_fetch_dec_release
> > >  #  define atomic_fetch_dec_release(...)  
> > > __atomic_op_release(atomic_fetch_dec, __VA_ARGS__)
> > >  # endif
> > >  # ifndef atomic_fetch_dec
> > >  #  define atomic_fetch_dec(...)  
> > > __atomic_op_fence(atomic_fetch_dec, __VA_ARGS__)
> > >  # endif
> > >  #endif
> > > 
> > > After:
> > > 
> > >  #ifndef atomic_fetch_dec_relaxed
> > >  # ifndef atomic_fetch_dec
> > >  #  define atomic_fetch_dec(v)atomic_fetch_sub(1, (v))
> > >  #  define atomic_fetch_dec_relaxed(v)
> > > atomic_fetch_sub_relaxed(1, (v))
> > >  #  define atomic_fetch_dec_acquire(v)
> > > atomic_fetch_sub_acquire(1, (v))
> > >  #  define atomic_fetch_dec_release(v)
> > > atomic_fetch_sub_release(1, (v))
> > >  # else
> > >  #  define atomic_fetch_dec_relaxed   atomic_fetch_dec
> > >  #  define atomic_fetch_dec_acquire   atomic_fetch_dec
> > >  #  define atomic_fetch_dec_release   atomic_fetch_dec
> > >  # endif
> > >  #else
> > >  # ifndef atomic_fetch_dec
> > >  #  define atomic_fetch_dec(...)  
> > > __atomic_op_fence(atomic_fetch_dec, __VA_ARGS__)
> > >  #  define atomic_fetch_dec_acquire(...)  
> > > __atomic_op_acquire(atomic_fetch_dec, __VA_ARGS__)
> > >  #  define atomic_fetch_dec_release(...)  
> > > __atomic_op_release(atomic_fetch_dec, __VA_ARGS__)
> > >  # endif
> > >  #endif
> > > 
> > > The idea is that because we already group these APIs by certain defines
> > > such as atomic_fetch_dec_relaxed and atomic_fetch_dec in the primary
> > > branches - we can do the same in the secondary branch as well.
> > > 
> > > ( Also remove some unnecessarily duplicate comments, as the API
> > >   group defines are now pretty much self-documenting. )
> > > 
> > > No change in functionality.
> > > 
> > > Cc: Peter Zijlstra <pet...@infradead.org>
> > > Cc: Linus Torvalds <torva...@linux-foundation.org>
> > > Cc: Andrew Morton <a...@linux-foundation.org>
> > > Cc: Thomas Gleixner <t...@linutronix.de>
> > > Cc: Paul E. McKenney <paul...@linux.vnet.ibm.com>
> > > Cc: Will Deacon <will.dea...@arm.com>
> > > Cc: linux-kernel@vger.kernel.org
> > > Signed-off-by: Ingo Molnar <mi...@kernel.org>
> > 
> > This breaks compilation on RISC-V. (For some of its atomics, the arch
> > currently defines the _relaxed and the full variants and it relies on
> > the generic definitions for the _acquire and the _release variants.)
> 
> I don't have cross-compilation for RISC-V, which is a relatively new arch.
> (Is there any RISC-V set of cross-compilation tools on kernel.org somewhere?)

I'm using the toolchain from:

  https://riscv.org/software-tools/

(adding Palmer and Albert in Cc:)


> 
> Could you please send a patch that defines those variants against Linus's 
> tree, 
> like the PowerPC patc

[RFC PATCH v3 1/6] Documentation/features: Add script that refreshes the arch support status files in place

[Andrea Parri]

Provides the script:

Documentation/features/scripts/features-refresh.sh

which operates on the arch-support.txt files and refreshes them in place.

This way [1],

   "[...] we soft- decouple the refreshing of the entries from the
introduction of the features, while still making it all easy to
keep sync and to extend."

[1] http://lkml.kernel.org/r/20180328122211.GA25420@andrea

Suggested-by: Ingo Molnar <mi...@kernel.org>
Signed-off-by: Andrea Parri <andrea.pa...@amarulasolutions.com>
Cc: Ingo Molnar <mi...@kernel.org>
Cc: Jonathan Corbet <cor...@lwn.net>
Cc: Andrew Morton <a...@linux-foundation.org>
---
 Documentation/features/scripts/features-refresh.sh | 98 ++
 1 file changed, 98 insertions(+)
 create mode 100755 Documentation/features/scripts/features-refresh.sh

diff --git a/Documentation/features/scripts/features-refresh.sh 
b/Documentation/features/scripts/features-refresh.sh
new file mode 100755
index 0..9e72d38a0720e
--- /dev/null
+++ b/Documentation/features/scripts/features-refresh.sh
@@ -0,0 +1,98 @@
+#
+# Small script that refreshes the kernel feature support status in place.
+#
+
+for F_FILE in Documentation/features/*/*/arch-support.txt; do
+   F=$(grep "^# Kconfig:" "$F_FILE" | cut -c26-)
+
+   #
+   # Each feature F is identified by a pair (O, K), where 'O' can
+   # be either the empty string (for 'nop') or "not" (the logical
+   # negation operator '!'); other operators are not supported.
+   #
+   O=""
+   K=$F
+   if [[ "$F" == !* ]]; then
+   O="not"
+   K=$(echo $F | sed -e 's/^!//g')
+   fi
+
+   #
+   # F := (O, K) is 'valid' iff there is a Kconfig file (for some
+   # arch) which contains K.
+   #
+   # Notice that this definition entails an 'asymmetry' between
+   # the case 'O = ""' and the case 'O = "not"'. E.g., F may be
+   # _invalid_ if:
+   #
+   # [case 'O = ""']
+   #   1) no arch provides support for F,
+   #   2) K does not exist (e.g., it was renamed/mis-typed);
+   #
+   # [case 'O = "not"']
+   #   3) all archs provide support for F,
+   #   4) as in (2).
+   #
+   # The rationale for adopting this definition (and, thus, for
+   # keeping the asymmetry) is:
+   #
+   #   We want to be able to 'detect' (2) (or (4)).
+   #
+   # (1) and (3) may further warn the developers about the fact
+   # that K can be removed.
+   #
+   F_VALID="false"
+   for ARCH_DIR in arch/*/; do
+   K_FILES=$(find $ARCH_DIR -name "Kconfig*")
+   K_GREP=$(grep "$K" $K_FILES)
+   if [ ! -z "$K_GREP" ]; then
+   F_VALID="true"
+   break
+   fi
+   done
+   if [ "$F_VALID" = "false" ]; then
+   printf "WARNING: '%s' is not a valid Kconfig\n" "$F"
+   fi
+
+   T_FILE="$F_FILE.tmp"
+   grep "^#" $F_FILE > $T_FILE
+   echo "---" >> $T_FILE
+   echo "| arch |status|" >> $T_FILE
+   echo "---" >> $T_FILE
+   for ARCH_DIR in arch/*/; do
+   ARCH=$(echo $ARCH_DIR | sed -e 's/arch//g' | sed -e 's/\///g')
+   K_FILES=$(find $ARCH_DIR -name "Kconfig*")
+   K_GREP=$(grep "$K" $K_FILES)
+   #
+   # Arch support status values for (O, K) are updated according
+   # to the following rules.
+   #
+   #   - ("", K) is 'supported by a given arch', if there is a
+   # Kconfig file for that arch which contains K;
+   #
+   #   - ("not", K) is 'supported by a given arch', if there is
+   # no Kconfig file for that arch which contains K;
+   #
+   #   - otherwise: preserve the previous status value (if any),
+   #default to 'not yet supported'.
+   #
+   # Notice that, according these rules, invalid features may be
+   # updated/modified.
+   #
+   if [ "$O" = "" ] && [ ! -z "$K_GREP" ]; then
+   printf "|%12s: |  ok  |\n" "$ARCH" >> $T_FILE
+   elif [ "$O" = "not" ] && [ -z "$K_GREP" ]; then
+   printf "|%12s: |  ok  |\n" "$ARCH" >> $T_FILE
+   else
+   S=$(grep -v "^#" "$F_FILE" | grep " $ARCH:")
+   if [ ! -z "$S" ]; then
+   echo "$S" >> $T_FILE
+   else
+   printf "|%12s: | TODO |\n" "$ARCH" \
+   >> $T_FILE
+   fi
+   fi
+   done
+   echo "---" >> $T_FILE
+   mv $T_FILE $F_FILE
+done
-- 
2.7.4

[RFC PATCH v3 2/6] Documentation/features: Refresh the arch support status files in place

[Andrea Parri]

Now that the script 'features-refresh.sh' is available, uses this script
to refresh all the arch-support.txt files in place.

Signed-off-by: Andrea Parri <andrea.pa...@amarulasolutions.com>
Cc: Ingo Molnar <mi...@kernel.org>
Cc: Jonathan Corbet <cor...@lwn.net>
Cc: Andrew Morton <a...@linux-foundation.org>
---
 Documentation/features/core/BPF-JIT/arch-support.txt   |  2 ++
 .../features/core/generic-idle-thread/arch-support.txt |  4 +++-
 Documentation/features/core/jump-labels/arch-support.txt   |  2 ++
 Documentation/features/core/tracehook/arch-support.txt |  2 ++
 Documentation/features/debug/KASAN/arch-support.txt|  4 +++-
 Documentation/features/debug/gcov-profile-all/arch-support.txt |  2 ++
 Documentation/features/debug/kgdb/arch-support.txt |  4 +++-
 .../features/debug/kprobes-on-ftrace/arch-support.txt  |  2 ++
 Documentation/features/debug/kprobes/arch-support.txt  |  4 +++-
 Documentation/features/debug/kretprobes/arch-support.txt   |  4 +++-
 Documentation/features/debug/optprobes/arch-support.txt|  4 +++-
 Documentation/features/debug/stackprotector/arch-support.txt   |  2 ++
 Documentation/features/debug/uprobes/arch-support.txt  |  6 --
 .../features/debug/user-ret-profiler/arch-support.txt  |  2 ++
 Documentation/features/io/dma-api-debug/arch-support.txt   |  2 ++
 Documentation/features/io/dma-contiguous/arch-support.txt  |  4 +++-
 Documentation/features/io/sg-chain/arch-support.txt|  2 ++
 Documentation/features/lib/strncasecmp/arch-support.txt|  2 ++
 Documentation/features/locking/cmpxchg-local/arch-support.txt  |  4 +++-
 Documentation/features/locking/lockdep/arch-support.txt|  4 +++-
 Documentation/features/locking/queued-rwlocks/arch-support.txt | 10 ++
 .../features/locking/queued-spinlocks/arch-support.txt |  8 +---
 .../features/locking/rwsem-optimized/arch-support.txt  |  2 ++
 Documentation/features/perf/kprobes-event/arch-support.txt |  6 --
 Documentation/features/perf/perf-regs/arch-support.txt |  4 +++-
 Documentation/features/perf/perf-stackdump/arch-support.txt|  4 +++-
 .../features/sched/membarrier-sync-core/arch-support.txt   |  2 ++
 Documentation/features/sched/numa-balancing/arch-support.txt   |  6 --
 Documentation/features/seccomp/seccomp-filter/arch-support.txt |  6 --
 .../features/time/arch-tick-broadcast/arch-support.txt |  4 +++-
 Documentation/features/time/clockevents/arch-support.txt   |  4 +++-
 Documentation/features/time/context-tracking/arch-support.txt  |  2 ++
 Documentation/features/time/irq-time-acct/arch-support.txt |  4 +++-
 .../features/time/modern-timekeeping/arch-support.txt  |  2 ++
 Documentation/features/time/virt-cpuacct/arch-support.txt  |  2 ++
 Documentation/features/vm/ELF-ASLR/arch-support.txt|  4 +++-
 Documentation/features/vm/PG_uncached/arch-support.txt |  2 ++
 Documentation/features/vm/THP/arch-support.txt |  2 ++
 Documentation/features/vm/TLB/arch-support.txt |  2 ++
 Documentation/features/vm/huge-vmap/arch-support.txt   |  2 ++
 Documentation/features/vm/ioremap_prot/arch-support.txt|  2 ++
 Documentation/features/vm/numa-memblock/arch-support.txt   |  4 +++-
 Documentation/features/vm/pte_special/arch-support.txt |  2 ++
 43 files changed, 117 insertions(+), 31 deletions(-)

diff --git a/Documentation/features/core/BPF-JIT/arch-support.txt 
b/Documentation/features/core/BPF-JIT/arch-support.txt
index 0b96b4e1e7d4a..d277f971ccd6b 100644
--- a/Documentation/features/core/BPF-JIT/arch-support.txt
+++ b/Documentation/features/core/BPF-JIT/arch-support.txt
@@ -17,10 +17,12 @@
 |m68k: | TODO |
 |  microblaze: | TODO |
 |mips: |  ok  |
+|   nds32: | TODO |
 |   nios2: | TODO |
 |openrisc: | TODO |
 |  parisc: | TODO |
 | powerpc: |  ok  |
+|   riscv: | TODO |
 |s390: |  ok  |
 |  sh: | TODO |
 |   sparc: |  ok  |
diff --git a/Documentation/features/core/generic-idle-thread/arch-support.txt 
b/Documentation/features/core/generic-idle-thread/arch-support.txt
index 372a2b18a6172..0ef6acdb991c7 100644
--- a/Documentation/features/core/generic-idle-thread/arch-support.txt
+++ b/Documentation/features/core/generic-idle-thread/arch-support.txt
@@ -17,10 +17,12 @@
 |m68k: | TODO |
 |  microblaze: | TODO |
 |mips: |  ok  |
+|   nds32: | TODO |
 |   nios2: | TODO |
-|openrisc: | TODO |
+|openrisc: |  ok  |
 |  parisc: |  ok  |
 | powerpc: |  ok  |
+|   riscv: |  ok  |
 |s390: |  ok  |
 |  sh: |  ok  |
 |   sparc: |  ok  |
diff --git a/Documentation/features/core/jump-labels/arch-support.txt 

[RFC PATCH v3 5/6] Documentation/features/lib: Remove arch support status file for 'strncasecmp'

[Andrea Parri]

Suggested-by: Ingo Molnar <mi...@kernel.org>
Signed-off-by: Andrea Parri <andrea.pa...@amarulasolutions.com>
Cc: Ingo Molnar <mi...@kernel.org>
Cc: Jonathan Corbet <cor...@lwn.net>
Cc: Andrew Morton <a...@linux-foundation.org>
---
 .../features/lib/strncasecmp/arch-support.txt  | 33 --
 1 file changed, 33 deletions(-)
 delete mode 100644 Documentation/features/lib/strncasecmp/arch-support.txt

diff --git a/Documentation/features/lib/strncasecmp/arch-support.txt 
b/Documentation/features/lib/strncasecmp/arch-support.txt
deleted file mode 100644
index 6148f42c3d902..0
--- a/Documentation/features/lib/strncasecmp/arch-support.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-#
-# Feature name:  strncasecmp
-# Kconfig:   __HAVE_ARCH_STRNCASECMP
-# description:   arch provides an optimized strncasecmp() function
-#
----
-| arch |status|
----
-|   alpha: | TODO |
-| arc: | TODO |
-| arm: | TODO |
-|   arm64: | TODO |
-| c6x: | TODO |
-|   h8300: | TODO |
-| hexagon: | TODO |
-|ia64: | TODO |
-|m68k: | TODO |
-|  microblaze: | TODO |
-|mips: | TODO |
-|   nds32: | TODO |
-|   nios2: | TODO |
-|openrisc: | TODO |
-|  parisc: | TODO |
-| powerpc: | TODO |
-|   riscv: | TODO |
-|s390: | TODO |
-|  sh: | TODO |
-|   sparc: | TODO |
-|  um: | TODO |
-|   unicore32: | TODO |
-| x86: | TODO |
-|  xtensa: | TODO |
----
-- 
2.7.4

[RFC PATCH v3 6/6] Documentation/features/vm: Remove arch support status file for 'pte_special'

[Andrea Parri]

Suggested-by: Ingo Molnar <mi...@kernel.org>
Signed-off-by: Andrea Parri <andrea.pa...@amarulasolutions.com>
Cc: Ingo Molnar <mi...@kernel.org>
Cc: Jonathan Corbet <cor...@lwn.net>
Cc: Andrew Morton <a...@linux-foundation.org>
---
 .../features/vm/pte_special/arch-support.txt   | 33 --
 1 file changed, 33 deletions(-)
 delete mode 100644 Documentation/features/vm/pte_special/arch-support.txt

diff --git a/Documentation/features/vm/pte_special/arch-support.txt 
b/Documentation/features/vm/pte_special/arch-support.txt
deleted file mode 100644
index 6a608a6dcf71d..0
--- a/Documentation/features/vm/pte_special/arch-support.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-#
-# Feature name:  pte_special
-# Kconfig:   __HAVE_ARCH_PTE_SPECIAL
-# description:   arch supports the pte_special()/pte_mkspecial() VM 
APIs
-#
----
-| arch |status|
----
-|   alpha: | TODO |
-| arc: |  ok  |
-| arm: |  ok  |
-|   arm64: |  ok  |
-| c6x: | TODO |
-|   h8300: | TODO |
-| hexagon: | TODO |
-|ia64: | TODO |
-|m68k: | TODO |
-|  microblaze: | TODO |
-|mips: | TODO |
-|   nds32: | TODO |
-|   nios2: | TODO |
-|openrisc: | TODO |
-|  parisc: | TODO |
-| powerpc: |  ok  |
-|   riscv: | TODO |
-|s390: |  ok  |
-|  sh: |  ok  |
-|   sparc: |  ok  |
-|  um: | TODO |
-|   unicore32: | TODO |
-| x86: |  ok  |
-|  xtensa: | TODO |
----
-- 
2.7.4

Re: [PATCH 07/18] docs: core-api: add circular-buffers documentation

[Andrea Parri]

On Mon, May 07, 2018 at 06:35:43AM -0300, Mauro Carvalho Chehab wrote:
> The circular-buffers.txt is already in ReST format. So, move it to the
> core-api guide, where it belongs.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  Documentation/00-INDEX  | 2 --
>  .../{circular-buffers.txt => core-api/circular-buffers.rst} | 0
>  Documentation/core-api/index.rst| 1 +
>  Documentation/memory-barriers.txt   | 2 +-
>  Documentation/translations/ko_KR/memory-barriers.txt| 2 +-
>  5 files changed, 3 insertions(+), 4 deletions(-)
>  rename Documentation/{circular-buffers.txt => core-api/circular-buffers.rst} 
> (100%)

Similarly:

./include/linux/circ_buf.h: * See Documentation/circular-buffers.txt for more 
information.
./drivers/lightnvm/pblk-rb.c: * (Documentation/circular-buffers.txt)
./drivers/media/dvb-core/dvb_ringbuffer.c:   * for memory barriers also see 
Documentation/circular-buffers.txt

  Andrea


> 
> diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
> index c6b81ef9827b..a9dd1384d8e3 100644
> --- a/Documentation/00-INDEX
> +++ b/Documentation/00-INDEX
> @@ -80,8 +80,6 @@ cdrom/
>   - directory with information on the CD-ROM drivers that Linux has.
>  cgroup-v1/
>   - cgroups v1 features, including cpusets and memory controller.
> -circular-buffers.txt
> - - how to make use of the existing circular buffer infrastructure
>  clk.txt
>   - info on the common clock framework
>  cma/
> diff --git a/Documentation/circular-buffers.txt 
> b/Documentation/core-api/circular-buffers.rst
> similarity index 100%
> rename from Documentation/circular-buffers.txt
> rename to Documentation/core-api/circular-buffers.rst
> diff --git a/Documentation/core-api/index.rst 
> b/Documentation/core-api/index.rst
> index d4d71ee564ae..3864de589126 100644
> --- a/Documentation/core-api/index.rst
> +++ b/Documentation/core-api/index.rst
> @@ -26,6 +26,7 @@ Core utilities
> genalloc
> errseq
> printk-formats
> +   circular-buffers
>  
>  Interfaces for kernel debugging
>  ===
> diff --git a/Documentation/memory-barriers.txt 
> b/Documentation/memory-barriers.txt
> index 983249906fc6..33b8bc9573f8 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -3083,7 +3083,7 @@ CIRCULAR BUFFERS
>  Memory barriers can be used to implement circular buffering without the need
>  of a lock to serialise the producer with the consumer.  See:
>  
> - Documentation/circular-buffers.txt
> + Documentation/core-api/circular-buffers.rst
>  
>  for details.
>  
> diff --git a/Documentation/translations/ko_KR/memory-barriers.txt 
> b/Documentation/translations/ko_KR/memory-barriers.txt
> index 081937577c1a..2ec5fe0c9cf4 100644
> --- a/Documentation/translations/ko_KR/memory-barriers.txt
> +++ b/Documentation/translations/ko_KR/memory-barriers.txt
> @@ -3023,7 +3023,7 @@ smp_mb() 가 아니라 virt_mb() 를 사용해야 합니다.
>  동기화에 락을 사용하지 않고 구현하는데에 사용될 수 있습니다.  더 자세한 내용을
>  위해선 다음을 참고하세요:
>  
> - Documentation/circular-buffers.txt
> + Documentation/core-api/circular-buffers.rst
>  
>  
>  =
> -- 
> 2.17.0
> 

Re: [PATCH 05/18] docs: core-api: add cachetlb documentation

[Andrea Parri]

On Mon, May 07, 2018 at 06:35:41AM -0300, Mauro Carvalho Chehab wrote:
> The cachetlb.txt is already in ReST format. So, move it to the
> core-api guide, where it belongs.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  Documentation/00-INDEX| 2 --
>  Documentation/{cachetlb.txt => core-api/cachetlb.rst} | 0
>  Documentation/core-api/index.rst  | 1 +
>  Documentation/memory-barriers.txt | 2 +-
>  Documentation/translations/ko_KR/memory-barriers.txt  | 2 +-
>  5 files changed, 3 insertions(+), 4 deletions(-)
>  rename Documentation/{cachetlb.txt => core-api/cachetlb.rst} (100%)

I see a few "inline" references to the .txt file in -rc4 (see below):
I am not sure if you managed to update them too.

./arch/microblaze/include/asm/cacheflush.h:/* Look at 
Documentation/cachetlb.txt */
./arch/unicore32/include/asm/cacheflush.h: *See Documentation/cachetlb.txt 
for more information.
./arch/arm64/include/asm/cacheflush.h: *See Documentation/cachetlb.txt 
for more information. Please note that
./arch/arm/include/asm/cacheflush.h: *  See Documentation/cachetlb.txt for more 
information.
./arch/xtensa/include/asm/cacheflush.h: * (see also Documentation/cachetlb.txt)
./arch/xtensa/include/asm/cacheflush.h:/* This is not required, see 
Documentation/cachetlb.txt */

  Andrea


> 
> diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
> index 53699c79ee54..04074059bcdc 100644
> --- a/Documentation/00-INDEX
> +++ b/Documentation/00-INDEX
> @@ -76,8 +76,6 @@ bus-devices/
>   - directory with info on TI GPMC (General Purpose Memory Controller)
>  bus-virt-phys-mapping.txt
>   - how to access I/O mapped memory from within device drivers.
> -cachetlb.txt
> - - describes the cache/TLB flushing interfaces Linux uses.
>  cdrom/
>   - directory with information on the CD-ROM drivers that Linux has.
>  cgroup-v1/
> diff --git a/Documentation/cachetlb.txt b/Documentation/core-api/cachetlb.rst
> similarity index 100%
> rename from Documentation/cachetlb.txt
> rename to Documentation/core-api/cachetlb.rst
> diff --git a/Documentation/core-api/index.rst 
> b/Documentation/core-api/index.rst
> index c670a8031786..d4d71ee564ae 100644
> --- a/Documentation/core-api/index.rst
> +++ b/Documentation/core-api/index.rst
> @@ -14,6 +14,7 @@ Core utilities
> kernel-api
> assoc_array
> atomic_ops
> +   cachetlb
> refcount-vs-atomic
> cpu_hotplug
> idr
> diff --git a/Documentation/memory-barriers.txt 
> b/Documentation/memory-barriers.txt
> index 6dafc8085acc..983249906fc6 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -2903,7 +2903,7 @@ is discarded from the CPU's cache and reloaded.  To 
> deal with this, the
>  appropriate part of the kernel must invalidate the overlapping bits of the
>  cache on each CPU.
>  
> -See Documentation/cachetlb.txt for more information on cache management.
> +See Documentation/core-api/cachetlb.rst for more information on cache 
> management.
>  
>  
>  CACHE COHERENCY VS MMIO
> diff --git a/Documentation/translations/ko_KR/memory-barriers.txt 
> b/Documentation/translations/ko_KR/memory-barriers.txt
> index 0a0930ab4156..081937577c1a 100644
> --- a/Documentation/translations/ko_KR/memory-barriers.txt
> +++ b/Documentation/translations/ko_KR/memory-barriers.txt
> @@ -2846,7 +2846,7 @@ CPU 의 캐시에서 RAM 으로 쓰여지는 더티 캐시 라인에 의해 덮
>  문제를 해결하기 위해선, 커널의 적절한 부분에서 각 CPU 의 캐시 안의 문제가 되는
>  비트들을 무효화 시켜야 합니다.
>  
> -캐시 관리에 대한 더 많은 정보를 위해선 Documentation/cachetlb.txt 를
> +캐시 관리에 대한 더 많은 정보를 위해선 Documentation/core-api/cachetlb.rst 를
>  참고하세요.
>  
>  
> -- 
> 2.17.0
> 

[PATCH] certificate handling: Update references to the documentation

[Andrea Parri]

Commit 94e980cc45f2b2 ("Documentation/module-signing.txt: convert to
ReST markup") converted the .txt doc. to ReST markup, but it did not
update the references to the doc. (including in MAINTAINERS).

Signed-off-by: Andrea Parri <andrea.pa...@amarulasolutions.com>
---
 MAINTAINERS   | 2 +-
 certs/Kconfig | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index df6e9bb2559af..803d4b4ff5f1d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3347,7 +3347,7 @@ M:David Howells <dhowe...@redhat.com>
 M: David Woodhouse <dw...@infradead.org>
 L: keyri...@vger.kernel.org
 S: Maintained
-F: Documentation/module-signing.txt
+F: Documentation/admin-guide/module-signing.rst
 F: certs/
 F: scripts/sign-file.c
 F: scripts/extract-cert.c
diff --git a/certs/Kconfig b/certs/Kconfig
index 5f7663df6e8e3..c94e93d8bccf0 100644
--- a/certs/Kconfig
+++ b/certs/Kconfig
@@ -13,7 +13,7 @@ config MODULE_SIG_KEY
 
  If this option is unchanged from its default "certs/signing_key.pem",
  then the kernel will automatically generate the private key and
- certificate as described in Documentation/module-signing.txt
+ certificate as described in 
Documentation/admin-guide/module-signing.rst
 
 config SYSTEM_TRUSTED_KEYRING
bool "Provide system-wide ring of trusted keys"
-- 
2.7.4

Re: [PATCH 05/18] docs: core-api: add cachetlb documentation

[Andrea Parri]

On Tue, May 08, 2018 at 03:28:51PM -0300, Mauro Carvalho Chehab wrote:
> Em Tue, 8 May 2018 15:05:07 -0300
> Mauro Carvalho Chehab  escreveu:
> 
> > Em Tue, 08 May 2018 17:40:56 +0300
> > Jani Nikula  escreveu:

[...]

> > > Side note, there's scripts/documentation-file-ref-check to grep the
> > > kernel tree for things that look like file references to Documentation/*
> > > and complain if they don't exist.
> > > 
> > > I get about 350+ hits with that, patches welcome! ;)  
> > 
> > This small script fixes a bunch of such errors:
> > 
> > scripts/documentation-file-ref-check 2>broken_refs
> > for i in $(cat broken_refs|cut -d: -f 2|grep -v 
> > devicetree|sort|uniq|grep \\.txt); do
> > rst=$(basename $i)
> > rst=${rst/.txt/.rst}
> > f=$(find . -name $rst)
> > f=${f#./}
> > if [ "$f" != "" ]; then
> > echo "Replacing $i to $f"
> > for j in $(git grep -l $i); do
> > sed "s@$i@$f@g" -i $j
> > done
> > fi
> > done
> 
> It follows an improvement to the above script that shows also what
> it didn't find as a ReST file, and the ones that have common names
> with multiple matches.
> 
> I guess we could integrate something like that at 
> scripts/documentation-file-ref-check, in order to allow auto-correcting
> renamed .txt files.

FWIW, this would be more than welcome with me; thank you,

  Andrea


> 
> Regards,
> Mauro
> 
> 
> #!/bin/bash
> 
> scripts/documentation-file-ref-check 2>broken_refs
> for i in $(cat broken_refs|cut -d: -f 2|grep -v devicetree|sort|uniq|grep 
> \\.txt); do
> rst=$(basename $i)
> rst=${rst/.txt/.rst}
> f=$(find . -name $rst)
> 
> if [ "$f" == "" ]; then
> echo "ERROR: Didn't find a .rst replacement for $i"
> elif [ "$(echo $f | grep ' ')" != "" ]; then
> echo "ERROR: Found multiple possible replacements for $i:"
> for j in $f; do
> echo "$j"
> done
> else
> echo "Replacing $i to $f"
> f=${f#./}
> for j in $(git grep -l $i); do
> sed "s@$i@$f@g" -i $j
> done
> fi
> done
> 
> 
> Thanks,
> Mauro

Re: [PATCH v9 1/2] arch/*: Add CONFIG_ARCH_HAVE_CMPXCHG64

[Andrea Parri]

Hi Bart,

On Mon, May 14, 2018 at 11:46:33AM -0700, Bart Van Assche wrote:

[...]

> diff --git a/Documentation/features/locking/cmpxchg64/arch-support.txt 
> b/Documentation/features/locking/cmpxchg64/arch-support.txt
> new file mode 100644
> index ..65b3290ce5d5
> --- /dev/null
> +++ b/Documentation/features/locking/cmpxchg64/arch-support.txt
> @@ -0,0 +1,31 @@
> +#
> +# Feature name:  cmpxchg64
> +# Kconfig:   ARCH_HAVE_CMPXCHG64
> +# description:   arch supports the cmpxchg64() API
> +#
> +---
> +| arch |status|
> +---
> +|   alpha: |  ok  |
> +| arc: | TODO |
> +| arm: |!thumb|
> +|   arm64: |  ok  |
> +| c6x: | TODO |
> +|   h8300: | TODO |
> +| hexagon: | TODO |
> +|ia64: |  ok  |
> +|m68k: |  ok  |
> +|  microblaze: | TODO |
> +|mips: |64-bit|
> +|   nios2: | TODO |
> +|openrisc: | TODO |
> +|  parisc: |  ok  |
> +| powerpc: |64-bit|
> +|s390: |  ok  |
> +|  sh: | TODO |
> +|   sparc: |  ok  |
> +|  um: | TODO |
> +|   unicore32: | TODO |
> +| x86: |  ok  |
> +|  xtensa: |  ok  |
> +---

nds32 and riscv seem to be missing from the table. I'd also suggest
sticking to the three entries documented in

  Documentation/features/arch-support.txt
  
and using the header comment to provide any additional information.

A script that refreshes the arch support status file in place (from
the Kconfig files) is currently available in linux-next: c.f.,

  Documentation/features/scripts/features-refresh.sh

  Andrea

Re: linux-next: manual merge of the akpm-current tree with the jc_docs tree

[Andrea Parri]

Really Cc-ing Ingo:

On Wed, May 09, 2018 at 03:28:24PM +0200, Andrea Parri wrote:
> On Wed, May 09, 2018 at 08:25:26PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the akpm-current tree got a conflict in:
> > 
> >   Documentation/features/vm/pte_special/arch-support.txt
> > 
> > between commit:
> > 
> >   2bef69a385b4 ("Documentation/features/vm: Remove arch support status file 
> > for 'pte_special'")
> > 
> > from the jc_docs tree and commit:
> > 
> >   1099dc900e93 ("mm: introduce ARCH_HAS_PTE_SPECIAL")
> > 
> > from the akpm-current tree.
> > 
> > I fixed it up (the former removed the file, so I did that) and can
> > carry the fix as necessary. This is now fixed as far as linux-next is
> > concerned, but any non trivial conflicts should be mentioned to your
> > upstream maintainer when your tree is submitted for merging.  You may
> > also want to consider cooperating with the maintainer of the conflicting
> > tree to minimise any particularly complex conflicts.
> > 
> > BTW, it would be nice if the the question "Why was this file removed?" was
> > answered by that jc_docs commit message ...  I actually wonder if this
> > file needs to return (I have no way of knowing).
> 
> My bad; thanks for pointing this out.
> 
> Mmh... "why" would have been something like "the feature has no Kconfig". ;-)
> 
> I defer to your (community) decision regarding "if this file needs to return"
> (Cc-ing Ingo, who created the file and also suggested its removal); I remain
> available for preparing the patch to restore (and refresh) this file, should
> you agree with this approach.
> 
>   Andrea
> 
> 
> > 
> > -- 
> > Cheers,
> > Stephen Rothwell
> 
> 

Re: linux-next: manual merge of the akpm-current tree with the jc_docs tree

[Andrea Parri]

On Wed, May 09, 2018 at 08:25:26PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   Documentation/features/vm/pte_special/arch-support.txt
> 
> between commit:
> 
>   2bef69a385b4 ("Documentation/features/vm: Remove arch support status file 
> for 'pte_special'")
> 
> from the jc_docs tree and commit:
> 
>   1099dc900e93 ("mm: introduce ARCH_HAS_PTE_SPECIAL")
> 
> from the akpm-current tree.
> 
> I fixed it up (the former removed the file, so I did that) and can
> carry the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging.  You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
> 
> BTW, it would be nice if the the question "Why was this file removed?" was
> answered by that jc_docs commit message ...  I actually wonder if this
> file needs to return (I have no way of knowing).

My bad; thanks for pointing this out.

Mmh... "why" would have been something like "the feature has no Kconfig". ;-)

I defer to your (community) decision regarding "if this file needs to return"
(Cc-ing Ingo, who created the file and also suggested its removal); I remain
available for preparing the patch to restore (and refresh) this file, should
you agree with this approach.

  Andrea


> 
> -- 
> Cheers,
> Stephen Rothwell

Re: [PATCH v2 08/11] docs: refcount-vs-atomic.rst: prefix url with https

[Andrea Parri]

Hi Mauro,

On Wed, May 09, 2018 at 10:18:51AM -0300, Mauro Carvalho Chehab wrote:
> There's a github URL there, but it is not prefixed by https.
> Add a prefix, to avoid false-positives with:
>   ./scripts/documentation-file-ref-check
> 
> As a side effect, Sphinx should also generate a cross-ref.
> 
> Signed-off-by: Mauro Carvalho Chehab 

There seems to be a "conflicting" patch ("applied" according to Jon):


http://lkml.kernel.org/r/1525468309-5310-1-git-send-email-andrea.pa...@amarulasolutions.com

Let me stress here that the github repo. is out-of-date (and we have
no plans to keep that in sync with mainline).

  Andrea


> ---
>  Documentation/core-api/refcount-vs-atomic.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/core-api/refcount-vs-atomic.rst 
> b/Documentation/core-api/refcount-vs-atomic.rst
> index 83351c258cdb..185d659e350a 100644
> --- a/Documentation/core-api/refcount-vs-atomic.rst
> +++ b/Documentation/core-api/refcount-vs-atomic.rst
> @@ -17,7 +17,7 @@ in order to help maintainers validate their code against 
> the change in
>  these memory ordering guarantees.
>  
>  The terms used through this document try to follow the formal LKMM defined in
> -github.com/aparri/memory-model/blob/master/Documentation/explanation.txt
> +https://github.com/aparri/memory-model/blob/master/Documentation/explanation.txt
>  
>  memory-barriers.txt and atomic_t.txt provide more background to the
>  memory ordering in general and for atomic operations specifically.
> -- 
> 2.17.0
> 

Re: linux-next: manual merge of the akpm-current tree with the jc_docs tree

[Andrea Parri]

On Wed, May 09, 2018 at 11:11:36AM -0600, Jonathan Corbet wrote:
> On Wed, 9 May 2018 18:53:28 +0200
> Andrea Parri <andrea.pa...@amarulasolutions.com> wrote:
> 
> > > Now that I look a little closer, I think the real issue is that the
> > > "features" documentation assumes that there's a Kconfig option for each,
> > > but there isn't in this case.  The lack of a Kconfig option does not,
> > > this time around, imply that the feature has gone away.
> > > 
> > > I think that I should probably revert this patch in the short term.
> > > Longer-term, it would be good to have an alternative syntax for "variable
> > > set in the arch headers" to describe situations like this.  
> > 
> > Both matters were discussed during v1:
> > 
> >   
> > http://lkml.kernel.org/r/1522774551-9503-1-git-send-email-andrea.pa...@amarulasolutions.com
> > 
> > ... (and the glory details are documented in features-refresh.sh ;-) ).
> 
> So I'll admit to being confused, since I don't see discussion of the
> actual topic at hand.

A couple of clicks on "next in thread"  :-)

  https://marc.info/?l=linux-kernel=152284705204400=2
  https://marc.info/?l=linux-kernel=152294150600751=2


> 
> > As I suggested above, simply reverting this patch will leave this file,
> > (and only this file!) out-of-date (and won't resolve the conflict with
> > Laurent's patch ...).
> 
> Reverting this patch retains the updates from earlier in the series, and
> does indeed make the conflict go away, so I'm still confused.  What am I
> missing?

The updates from earlier added "TODO" rows for nds32 and riscv, but missed
the "TODO -> ok" update for riscv.

  Andrea


> 
> Thanks,
> 
> jon

Re: linux-next: manual merge of the akpm-current tree with the jc_docs tree

[Andrea Parri]

On Wed, May 09, 2018 at 08:59:20AM -0600, Jonathan Corbet wrote:
> On Wed, 9 May 2018 15:28:24 +0200
> Andrea Parri <andrea.pa...@amarulasolutions.com> wrote:
> 
> > > BTW, it would be nice if the the question "Why was this file removed?" was
> > > answered by that jc_docs commit message ...  I actually wonder if this
> > > file needs to return (I have no way of knowing).  
> > 
> > My bad; thanks for pointing this out.
> > 
> > Mmh... "why" would have been something like "the feature has no Kconfig". 
> > ;-)
> > 
> > I defer to your (community) decision regarding "if this file needs to 
> > return"
> > (Cc-ing Ingo, who created the file and also suggested its removal); I remain
> > available for preparing the patch to restore (and refresh) this file, should
> > you agree with this approach.
> 
> So I'll confess that I balked on the lack of a changelog, but then decided
> to proceed with the patch (and the other removal as well) due to the lack
> of the Kconfig option.
> 
> Now that I look a little closer, I think the real issue is that the
> "features" documentation assumes that there's a Kconfig option for each,
> but there isn't in this case.  The lack of a Kconfig option does not,
> this time around, imply that the feature has gone away.
> 
> I think that I should probably revert this patch in the short term.
> Longer-term, it would be good to have an alternative syntax for "variable
> set in the arch headers" to describe situations like this.

Both matters were discussed during v1:

  
http://lkml.kernel.org/r/1522774551-9503-1-git-send-email-andrea.pa...@amarulasolutions.com

... (and the glory details are documented in features-refresh.sh ;-) ).

As I suggested above, simply reverting this patch will leave this file,
(and only this file!) out-of-date (and won't resolve the conflict with
Laurent's patch ...).

  Andrea


> 
> Make sense?
> 
> Thanks,
> 
> jon

Re: [PATCH 13/18] wait: wait.h: Get rid of a kernel-doc/Sphinx warnings

[Andrea Parri]

On Wed, May 09, 2018 at 08:45:18AM -0600, Jonathan Corbet wrote:
> On Wed, 9 May 2018 10:41:20 +0200
> Peter Zijlstra  wrote:
> 
> > > This is easily done by using "::" instead of just ":".  
> > 
> > And I'll voice my objection once again. This makes a regular comment
> > worse. This rst stuff is utter shit for making normal text files less
> > readable in your favourite text editor.
> > 
> > If this gets merged, I'll simply remove that spurious ':' the next time
> > I'm near that comment.
> 
> Seriously, Peter?
> 
> It's a simple colon.  It goes along with the /** marker for kerneldoc
> comments and the @ markers found within them, both of which you seem to
> have found a way to live with.
> 
> The RST work was discussed for a year before we even started.  It has
> brought in the efforts of a large number of developers, all of whom see
> the value in actually caring about our documentation and making it
> accessible to a much larger group of readers.  And it has all happened
> while preserving the primacy of the plain-text documentation.
> 
> You're not the only consumer of the docs.  You may not appreciate the
> improvements that have come, but others certainly do.  I do hope that you
> can find it in youself to avoid vandalizing things for everybody else ...?

You wrote it:  the fact that some people (including its developers) see
a value in the RST work or the fact that such work made the kernel doc.
accessible to a larger group of readers are not in question here;  only
remember that other people (including some developers running into the
"disadventure" of opening an RST doc. from their preferred text editor
and being brought to conclude:  "WTH!  I need to open a web browser, I
guess...") _use_ such doc. and _do care_ about it, and that what might
be an improvement for some people might look as "vandalizing" to others.

We're talking about readability/accessibility here, but I think similar
considerations apply to other aspects of the doc. such as availability/
completeness (yes, I did hear developers arguing "I won't write such a
doc., because...") and consistency (w.r.t. the doc. itself and sources).

  Andrea


> 
> Thanks,
> 
> jon

Re: [PATCH 13/18] wait: wait.h: Get rid of a kernel-doc/Sphinx warnings

[Andrea Parri]

On Thu, May 10, 2018 at 07:15:59AM -0600, Jonathan Corbet wrote:
> On Thu, 10 May 2018 14:23:35 +0200
> Andrea Parri <andrea.pa...@amarulasolutions.com> wrote:
> 
> > only
> > remember that other people (including some developers running into the
> > "disadventure" of opening an RST doc. from their preferred text editor
> > and being brought to conclude:  "WTH!  I need to open a web browser, I
> > guess...") _use_ such doc. and _do care_ about it, and that what might
> > be an improvement for some people might look as "vandalizing" to others.
> 
> If you have an example of a place where use of a web browser has been
> made mandatory, please point it out.  Avoiding that was at the top of the
> list of explicit requirements.

That's all I need.


>Surely an extra colon is not going to
> force you to run screaming to the protective embrace of Firefox...?

Let me put it in these terms: I believe that that extra colon (or the
"diagram" keywork) is not going to improve/help my use of the doc. ;D

  Andrea


> 
> Thanks,
> 
> jon

Re: [PATCH 05/18] docs: core-api: add cachetlb documentation

[Andrea Parri]

Hi Jani,

On Tue, May 08, 2018 at 05:40:56PM +0300, Jani Nikula wrote:
> On Mon, 07 May 2018, Andrea Parri <andrea.pa...@amarulasolutions.com> wrote:
> > On Mon, May 07, 2018 at 06:35:41AM -0300, Mauro Carvalho Chehab wrote:
> >> The cachetlb.txt is already in ReST format. So, move it to the
> >> core-api guide, where it belongs.
> >> 
> >> Signed-off-by: Mauro Carvalho Chehab <mchehab+sams...@kernel.org>
> >> ---
> >>  Documentation/00-INDEX| 2 --
> >>  Documentation/{cachetlb.txt => core-api/cachetlb.rst} | 0
> >>  Documentation/core-api/index.rst  | 1 +
> >>  Documentation/memory-barriers.txt | 2 +-
> >>  Documentation/translations/ko_KR/memory-barriers.txt  | 2 +-
> >>  5 files changed, 3 insertions(+), 4 deletions(-)
> >>  rename Documentation/{cachetlb.txt => core-api/cachetlb.rst} (100%)
> >
> > I see a few "inline" references to the .txt file in -rc4 (see below):
> > I am not sure if you managed to update them too.
> 
> Side note, there's scripts/documentation-file-ref-check to grep the
> kernel tree for things that look like file references to Documentation/*
> and complain if they don't exist.
> 
> I get about 350+ hits with that, patches welcome! ;)

Thanks for pointing out the script/results.

It's also worth stressing, I think, the fact that some of those are from
the MAINTAINERS file; I stumbled accross one of them yesterday:

  
http://lkml.kernel.org/r/1525707655-3542-1-git-send-email-andrea.pa...@amarulasolutions.com

False positives apart (e.g., the four references in tools/memory-model/),
those are regressions from my POV: please do not (consiously) merge more!

  Andrea


> 
> 
> BR,
> Jani.
> 
> 
> >
> > ./arch/microblaze/include/asm/cacheflush.h:/* Look at 
> > Documentation/cachetlb.txt */
> > ./arch/unicore32/include/asm/cacheflush.h: *See 
> > Documentation/cachetlb.txt for more information.
> > ./arch/arm64/include/asm/cacheflush.h: *See Documentation/cachetlb.txt 
> > for more information. Please note that
> > ./arch/arm/include/asm/cacheflush.h: *  See Documentation/cachetlb.txt 
> > for more information.
> > ./arch/xtensa/include/asm/cacheflush.h: * (see also 
> > Documentation/cachetlb.txt)
> > ./arch/xtensa/include/asm/cacheflush.h:/* This is not required, see 
> > Documentation/cachetlb.txt */
> >
> >   Andrea
> >
> >
> >> 
> >> diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
> >> index 53699c79ee54..04074059bcdc 100644
> >> --- a/Documentation/00-INDEX
> >> +++ b/Documentation/00-INDEX
> >> @@ -76,8 +76,6 @@ bus-devices/
> >>- directory with info on TI GPMC (General Purpose Memory Controller)
> >>  bus-virt-phys-mapping.txt
> >>- how to access I/O mapped memory from within device drivers.
> >> -cachetlb.txt
> >> -  - describes the cache/TLB flushing interfaces Linux uses.
> >>  cdrom/
> >>- directory with information on the CD-ROM drivers that Linux has.
> >>  cgroup-v1/
> >> diff --git a/Documentation/cachetlb.txt 
> >> b/Documentation/core-api/cachetlb.rst
> >> similarity index 100%
> >> rename from Documentation/cachetlb.txt
> >> rename to Documentation/core-api/cachetlb.rst
> >> diff --git a/Documentation/core-api/index.rst 
> >> b/Documentation/core-api/index.rst
> >> index c670a8031786..d4d71ee564ae 100644
> >> --- a/Documentation/core-api/index.rst
> >> +++ b/Documentation/core-api/index.rst
> >> @@ -14,6 +14,7 @@ Core utilities
> >> kernel-api
> >> assoc_array
> >> atomic_ops
> >> +   cachetlb
> >> refcount-vs-atomic
> >> cpu_hotplug
> >> idr
> >> diff --git a/Documentation/memory-barriers.txt 
> >> b/Documentation/memory-barriers.txt
> >> index 6dafc8085acc..983249906fc6 100644
> >> --- a/Documentation/memory-barriers.txt
> >> +++ b/Documentation/memory-barriers.txt
> >> @@ -2903,7 +2903,7 @@ is discarded from the CPU's cache and reloaded.  To 
> >> deal with this, the
> >>  appropriate part of the kernel must invalidate the overlapping bits of the
> >>  cache on each CPU.
> >>  
> >> -See Documentation/cachetlb.txt for more information on cache management.
> >> +See Documentation/core-api/cachetlb.rst for more information on cache 
> >> management.
> >>  
> >>  
> >>  CACHE COHERENCY VS MMIO
> >

Re: [PATCH 05/18] docs: core-api: add cachetlb documentation

[Andrea Parri]

On Tue, May 08, 2018 at 06:02:42PM +0200, Andrea Parri wrote:
> Hi Jani,
> 
> On Tue, May 08, 2018 at 05:40:56PM +0300, Jani Nikula wrote:
> > On Mon, 07 May 2018, Andrea Parri <andrea.pa...@amarulasolutions.com> wrote:
> > > On Mon, May 07, 2018 at 06:35:41AM -0300, Mauro Carvalho Chehab wrote:
> > >> The cachetlb.txt is already in ReST format. So, move it to the
> > >> core-api guide, where it belongs.
> > >> 
> > >> Signed-off-by: Mauro Carvalho Chehab <mchehab+sams...@kernel.org>
> > >> ---
> > >>  Documentation/00-INDEX| 2 --
> > >>  Documentation/{cachetlb.txt => core-api/cachetlb.rst} | 0
> > >>  Documentation/core-api/index.rst  | 1 +
> > >>  Documentation/memory-barriers.txt | 2 +-
> > >>  Documentation/translations/ko_KR/memory-barriers.txt  | 2 +-
> > >>  5 files changed, 3 insertions(+), 4 deletions(-)
> > >>  rename Documentation/{cachetlb.txt => core-api/cachetlb.rst} (100%)
> > >
> > > I see a few "inline" references to the .txt file in -rc4 (see below):
> > > I am not sure if you managed to update them too.
> > 
> > Side note, there's scripts/documentation-file-ref-check to grep the
> > kernel tree for things that look like file references to Documentation/*
> > and complain if they don't exist.
> > 
> > I get about 350+ hits with that, patches welcome! ;)
> 
> Thanks for pointing out the script/results.
> 
> It's also worth stressing, I think, the fact that some of those are from
> the MAINTAINERS file; I stumbled accross one of them yesterday:
> 
>   
> http://lkml.kernel.org/r/1525707655-3542-1-git-send-email-andrea.pa...@amarulasolutions.com
> 
> False positives apart (e.g., the four references in tools/memory-model/),
> those are regressions from my POV: please do not (consiously) merge more!

s/four/five

  Andrea


> 
>   Andrea
> 
> 
> > 
> > 
> > BR,
> > Jani.
> > 
> > 
> > >
> > > ./arch/microblaze/include/asm/cacheflush.h:/* Look at 
> > > Documentation/cachetlb.txt */
> > > ./arch/unicore32/include/asm/cacheflush.h: *  See 
> > > Documentation/cachetlb.txt for more information.
> > > ./arch/arm64/include/asm/cacheflush.h: *  See Documentation/cachetlb.txt 
> > > for more information. Please note that
> > > ./arch/arm/include/asm/cacheflush.h: *See Documentation/cachetlb.txt 
> > > for more information.
> > > ./arch/xtensa/include/asm/cacheflush.h: * (see also 
> > > Documentation/cachetlb.txt)
> > > ./arch/xtensa/include/asm/cacheflush.h:/* This is not required, see 
> > > Documentation/cachetlb.txt */
> > >
> > >   Andrea
> > >
> > >
> > >> 
> > >> diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
> > >> index 53699c79ee54..04074059bcdc 100644
> > >> --- a/Documentation/00-INDEX
> > >> +++ b/Documentation/00-INDEX
> > >> @@ -76,8 +76,6 @@ bus-devices/
> > >>  - directory with info on TI GPMC (General Purpose Memory 
> > >> Controller)
> > >>  bus-virt-phys-mapping.txt
> > >>  - how to access I/O mapped memory from within device drivers.
> > >> -cachetlb.txt
> > >> -- describes the cache/TLB flushing interfaces Linux uses.
> > >>  cdrom/
> > >>  - directory with information on the CD-ROM drivers that Linux 
> > >> has.
> > >>  cgroup-v1/
> > >> diff --git a/Documentation/cachetlb.txt 
> > >> b/Documentation/core-api/cachetlb.rst
> > >> similarity index 100%
> > >> rename from Documentation/cachetlb.txt
> > >> rename to Documentation/core-api/cachetlb.rst
> > >> diff --git a/Documentation/core-api/index.rst 
> > >> b/Documentation/core-api/index.rst
> > >> index c670a8031786..d4d71ee564ae 100644
> > >> --- a/Documentation/core-api/index.rst
> > >> +++ b/Documentation/core-api/index.rst
> > >> @@ -14,6 +14,7 @@ Core utilities
> > >> kernel-api
> > >> assoc_array
> > >> atomic_ops
> > >> +   cachetlb
> > >> refcount-vs-atomic
> > >> cpu_hotplug
> > >> idr
> > >> diff --git a/Documentation/memory-barriers.txt 
> > >> b/Documentation/memory-barriers.txt
> > >> index 6dafc8085acc..983249906fc6 100644
> > >> -

Re: [PATCH 05/18] docs: core-api: add cachetlb documentation

[Andrea Parri]

On Tue, May 08, 2018 at 10:04:08AM -0600, Jonathan Corbet wrote:
> On Mon,  7 May 2018 06:35:41 -0300
> Mauro Carvalho Chehab  wrote:
> 
> > The cachetlb.txt is already in ReST format. So, move it to the
> > core-api guide, where it belongs.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> 
> I think we could do a better job of this by integrating it with the
> kerneldoc comments.  Meanwhile, though, this is a step in the right
> direction, so I've applied it, thanks.

This depends on what you mean by "the right direction": IMO, breaking
in-sources references and get_maintainer.pl does not qualify as such.

  Andrea


> 
> jon

Re: [PATCH] locking/atomics: Simplify the op definitions in atomic.h some more

[Andrea Parri]

Hi Ingo,

> From 5affbf7e91901143f84f1b2ca64f4afe70e210fd Mon Sep 17 00:00:00 2001
> From: Ingo Molnar 
> Date: Sat, 5 May 2018 10:23:23 +0200
> Subject: [PATCH] locking/atomics: Simplify the op definitions in atomic.h 
> some more
> 
> Before:
> 
>  #ifndef atomic_fetch_dec_relaxed
>  # ifndef atomic_fetch_dec
>  #  define atomic_fetch_dec(v)atomic_fetch_sub(1, (v))
>  #  define atomic_fetch_dec_relaxed(v)
> atomic_fetch_sub_relaxed(1, (v))
>  #  define atomic_fetch_dec_acquire(v)
> atomic_fetch_sub_acquire(1, (v))
>  #  define atomic_fetch_dec_release(v)
> atomic_fetch_sub_release(1, (v))
>  # else
>  #  define atomic_fetch_dec_relaxed   atomic_fetch_dec
>  #  define atomic_fetch_dec_acquire   atomic_fetch_dec
>  #  define atomic_fetch_dec_release   atomic_fetch_dec
>  # endif
>  #else
>  # ifndef atomic_fetch_dec_acquire
>  #  define atomic_fetch_dec_acquire(...)  
> __atomic_op_acquire(atomic_fetch_dec, __VA_ARGS__)
>  # endif
>  # ifndef atomic_fetch_dec_release
>  #  define atomic_fetch_dec_release(...)  
> __atomic_op_release(atomic_fetch_dec, __VA_ARGS__)
>  # endif
>  # ifndef atomic_fetch_dec
>  #  define atomic_fetch_dec(...)  
> __atomic_op_fence(atomic_fetch_dec, __VA_ARGS__)
>  # endif
>  #endif
> 
> After:
> 
>  #ifndef atomic_fetch_dec_relaxed
>  # ifndef atomic_fetch_dec
>  #  define atomic_fetch_dec(v)atomic_fetch_sub(1, (v))
>  #  define atomic_fetch_dec_relaxed(v)
> atomic_fetch_sub_relaxed(1, (v))
>  #  define atomic_fetch_dec_acquire(v)
> atomic_fetch_sub_acquire(1, (v))
>  #  define atomic_fetch_dec_release(v)
> atomic_fetch_sub_release(1, (v))
>  # else
>  #  define atomic_fetch_dec_relaxed   atomic_fetch_dec
>  #  define atomic_fetch_dec_acquire   atomic_fetch_dec
>  #  define atomic_fetch_dec_release   atomic_fetch_dec
>  # endif
>  #else
>  # ifndef atomic_fetch_dec
>  #  define atomic_fetch_dec(...)  
> __atomic_op_fence(atomic_fetch_dec, __VA_ARGS__)
>  #  define atomic_fetch_dec_acquire(...)  
> __atomic_op_acquire(atomic_fetch_dec, __VA_ARGS__)
>  #  define atomic_fetch_dec_release(...)  
> __atomic_op_release(atomic_fetch_dec, __VA_ARGS__)
>  # endif
>  #endif
> 
> The idea is that because we already group these APIs by certain defines
> such as atomic_fetch_dec_relaxed and atomic_fetch_dec in the primary
> branches - we can do the same in the secondary branch as well.
> 
> ( Also remove some unnecessarily duplicate comments, as the API
>   group defines are now pretty much self-documenting. )
> 
> No change in functionality.
> 
> Cc: Peter Zijlstra 
> Cc: Linus Torvalds 
> Cc: Andrew Morton 
> Cc: Thomas Gleixner 
> Cc: Paul E. McKenney 
> Cc: Will Deacon 
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Ingo Molnar 

This breaks compilation on RISC-V. (For some of its atomics, the arch
currently defines the _relaxed and the full variants and it relies on
the generic definitions for the _acquire and the _release variants.)

  Andrea


> ---
>  include/linux/atomic.h | 312 
> ++---
>  1 file changed, 62 insertions(+), 250 deletions(-)
> 
> diff --git a/include/linux/atomic.h b/include/linux/atomic.h
> index 67aaafba256b..352ecc72d7f5 100644
> --- a/include/linux/atomic.h
> +++ b/include/linux/atomic.h
> @@ -71,98 +71,66 @@
>  })
>  #endif
>  
> -/* atomic_add_return_relaxed() et al: */
> -
>  #ifndef atomic_add_return_relaxed
>  # define atomic_add_return_relaxed   atomic_add_return
>  # define atomic_add_return_acquire   atomic_add_return
>  # define atomic_add_return_release   atomic_add_return
>  #else
> -# ifndef atomic_add_return_acquire
> -#  define atomic_add_return_acquire(...) 
> __atomic_op_acquire(atomic_add_return, __VA_ARGS__)
> -# endif
> -# ifndef atomic_add_return_release
> -#  define atomic_add_return_release(...) 
> __atomic_op_release(atomic_add_return, __VA_ARGS__)
> -# endif
>  # ifndef atomic_add_return
>  #  define atomic_add_return(...) 
> __atomic_op_fence(atomic_add_return, __VA_ARGS__)
> +#  define atomic_add_return_acquire(...) 
> __atomic_op_acquire(atomic_add_return, __VA_ARGS__)
> +#  define atomic_add_return_release(...) 
> __atomic_op_release(atomic_add_return, __VA_ARGS__)
>  # endif
>  #endif
>  
> -/* atomic_inc_return_relaxed() et al: */
> -
>  #ifndef atomic_inc_return_relaxed
>  # define atomic_inc_return_relaxed   atomic_inc_return
>  # define atomic_inc_return_acquire   atomic_inc_return
>  # define atomic_inc_return_release   atomic_inc_return
>  #else
> -# ifndef atomic_inc_return_acquire
> -#  define 

Re: [PATCH] locking/atomics: Combine the atomic_andnot() and atomic64_andnot() API definitions

[Andrea Parri]

Hi Ingo,

> From f5efafa83af8c46b9e81b010b46caeeadb450179 Mon Sep 17 00:00:00 2001
> From: Ingo Molnar 
> Date: Sat, 5 May 2018 10:46:41 +0200
> Subject: [PATCH] locking/atomics: Combine the atomic_andnot() and 
> atomic64_andnot() API definitions
> 
> The atomic_andnot() and atomic64_andnot() are defined in 4 separate groups
> spred out in the atomic.h header:
> 
>  #ifdef atomic_andnot
>  ...
>  #endif /* atomic_andnot */
>  ...
>  #ifndef atomic_andnot
>  ...
>  #endif
>  ...
>  #ifdef atomic64_andnot
>  ...
>  #endif /* atomic64_andnot */
>  ...
>  #ifndef atomic64_andnot
>  ...
>  #endif
> 
> Combine them into unify them into two groups:

Nit: "Combine them into unify them into"

  Andrea


> 
>  #ifdef atomic_andnot
>  #else
>  #endif
> 
>  ...
> 
>  #ifdef atomic64_andnot
>  #else
>  #endif
> 
> So that one API group is defined in a single place within the header.
> 
> Cc: Peter Zijlstra 
> Cc: Linus Torvalds 
> Cc: Andrew Morton 
> Cc: Thomas Gleixner 
> Cc: Paul E. McKenney 
> Cc: Will Deacon 
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Ingo Molnar 
> ---
>  include/linux/atomic.h | 72 
> +-
>  1 file changed, 36 insertions(+), 36 deletions(-)
> 
> diff --git a/include/linux/atomic.h b/include/linux/atomic.h
> index 352ecc72d7f5..1176cf7c6f03 100644
> --- a/include/linux/atomic.h
> +++ b/include/linux/atomic.h
> @@ -205,22 +205,6 @@
>  # endif
>  #endif
>  
> -#ifdef atomic_andnot
> -
> -#ifndef atomic_fetch_andnot_relaxed
> -# define atomic_fetch_andnot_relaxed atomic_fetch_andnot
> -# define atomic_fetch_andnot_acquire atomic_fetch_andnot
> -# define atomic_fetch_andnot_release atomic_fetch_andnot
> -#else
> -# ifndef atomic_fetch_andnot
> -#  define atomic_fetch_andnot(...)   
> __atomic_op_fence(atomic_fetch_andnot, __VA_ARGS__)
> -#  define atomic_fetch_andnot_acquire(...)   
> __atomic_op_acquire(atomic_fetch_andnot, __VA_ARGS__)
> -#  define atomic_fetch_andnot_release(...)   
> __atomic_op_release(atomic_fetch_andnot, __VA_ARGS__)
> -# endif
> -#endif
> -
> -#endif /* atomic_andnot */
> -
>  #ifndef atomic_fetch_xor_relaxed
>  # define atomic_fetch_xor_relaxedatomic_fetch_xor
>  # define atomic_fetch_xor_acquireatomic_fetch_xor
> @@ -338,7 +322,22 @@ static inline int atomic_add_unless(atomic_t *v, int a, 
> int u)
>  # define atomic_inc_not_zero(v)  atomic_add_unless((v), 
> 1, 0)
>  #endif
>  
> -#ifndef atomic_andnot
> +#ifdef atomic_andnot
> +
> +#ifndef atomic_fetch_andnot_relaxed
> +# define atomic_fetch_andnot_relaxed atomic_fetch_andnot
> +# define atomic_fetch_andnot_acquire atomic_fetch_andnot
> +# define atomic_fetch_andnot_release atomic_fetch_andnot
> +#else
> +# ifndef atomic_fetch_andnot
> +#  define atomic_fetch_andnot(...)   
> __atomic_op_fence(atomic_fetch_andnot, __VA_ARGS__)
> +#  define atomic_fetch_andnot_acquire(...)   
> __atomic_op_acquire(atomic_fetch_andnot, __VA_ARGS__)
> +#  define atomic_fetch_andnot_release(...)   
> __atomic_op_release(atomic_fetch_andnot, __VA_ARGS__)
> +# endif
> +#endif
> +
> +#else /* !atomic_andnot: */
> +
>  static inline void atomic_andnot(int i, atomic_t *v)
>  {
>   atomic_and(~i, v);
> @@ -363,7 +362,8 @@ static inline int atomic_fetch_andnot_release(int i, 
> atomic_t *v)
>  {
>   return atomic_fetch_and_release(~i, v);
>  }
> -#endif
> +
> +#endif /* !atomic_andnot */
>  
>  /**
>   * atomic_inc_not_zero_hint - increment if not null
> @@ -600,22 +600,6 @@ static inline int atomic_dec_if_positive(atomic_t *v)
>  # endif
>  #endif
>  
> -#ifdef atomic64_andnot
> -
> -#ifndef atomic64_fetch_andnot_relaxed
> -# define atomic64_fetch_andnot_relaxed   atomic64_fetch_andnot
> -# define atomic64_fetch_andnot_acquire   atomic64_fetch_andnot
> -# define atomic64_fetch_andnot_release   atomic64_fetch_andnot
> -#else
> -# ifndef atomic64_fetch_andnot
> -#  define atomic64_fetch_andnot(...) 
> __atomic_op_fence(atomic64_fetch_andnot, __VA_ARGS__)
> -#  define atomic64_fetch_andnot_acquire(...) 
> __atomic_op_acquire(atomic64_fetch_andnot, __VA_ARGS__)
> -#  define atomic64_fetch_andnot_release(...) 
> __atomic_op_release(atomic64_fetch_andnot, __VA_ARGS__)
> -# endif
> -#endif
> -
> -#endif /* atomic64_andnot */
> -
>  #ifndef atomic64_fetch_xor_relaxed
>  # define atomic64_fetch_xor_relaxed  atomic64_fetch_xor
>  # define atomic64_fetch_xor_acquire  atomic64_fetch_xor
> @@ -672,7 +656,22 @@ static inline int atomic_dec_if_positive(atomic_t *v)
>  # define atomic64_try_cmpxchg_releaseatomic64_try_cmpxchg
>  #endif
>  
> -#ifndef atomic64_andnot
> +#ifdef atomic64_andnot
> +
> +#ifndef atomic64_fetch_andnot_relaxed
> 

Re: write_lock_irq(_lock)

[Andrea Parri]

> Yeah, lemme put some details here:
> 
> So we have three cases:
> 
> Case #1 (from Will)
> 
>   P0: P1: P2:
> 
>   spin_lock()   read_lock()
>   write_lock()
>   read_lock()  spin_lock()
> 
> , which is a deadlock, and couldn't not be detected by lockdep yet. And
> lockdep could detect this with the patch I attach at the end of the
> mail.
> 
> Case #2
> 
>   P0: P1: P2:
> 
>   
>   spin_lock()   read_lock()
>   write_lock()
>   read_lock()  spin_lock_irq()
> 
> , which is not a deadlock, as the read_lock() on P0 can use the unfair
> fastpass.
> 
> Case #3
> 
>   P0: P1: P2:
> 
>   
>   spin_lock_irq()   read_lock()
>   write_lock_irq()
>   read_lock()  spin_lock()
> 
> , which is a deadlock, as the read_lock() on P0 cannot use the fastpass.

Mmh, I'm starting to think that, maybe, we need a model (a tool) to
distinguish these and other(?) cases (sorry, I could not resist ;-)

[...]


> --->8
> Subject: [PATCH] locking: More accurate annotations for read_lock()
> 
> On the archs using QUEUED_RWLOCKS, read_lock() is not always a recursive
> read lock, actually it's only recursive if in_interrupt() is true. So

Mmh, taking the "common denominator" over archs/Kconfig options and
CPU states, this would suggest that read_lock() is non-recursive;

it looks like I can say "good-bye" to my idea to define (formalize)
consistent executions/the memory ordering of RW-LOCKS "by following"
the following _emulation_:

void read_lock(rwlock_t *s)
{
r0 = atomic_fetch_inc_acquire(>val);
}

void read_unlock(rwlock_t *s)
{
r0 = atomic_fetch_sub_release(>val);
}

void write_lock(rwlock_t *s)
{
r0 = atomic_cmpxchg_acquire(>val, 0, -1);
}

void write_unlock(rwlock_t *s)
{
atomic_set_release(>val, 0);
}

filter (~read_lock:r0=-1 /\ write_lock:r0=0)

[...]


> The code is done, I'm just working on the rework for documention stuff,
> so if anyone is interested, could try it out ;-)

Any idea on how to "educate" the LKMM about this code/documentation?

  Andrea

Re: [PATCH 6/9] asm-generic/bitops/atomic.h: Rewrite using atomic_fetch_*

[Andrea Parri]

Hi Mark,

> As an aside, If I complete the autogeneration stuff, it'll be possible
> to generate those. I split out the necessary barriers in [1], but I
> still have a lot of other preparatory cleanup to do.

I do grasp the rationale behind that naming:

  __atomic_mb_{before,after}_{acquire,release,fence}()

and yet I remain puzzled by it:

For example, can you imagine (using):

  __atomic_mb_before_acquire() ?

(as your __atomic_mb_after_acquire() is whispering me "acquire-fences"...)

Another example:

  the "atomic" in that "smp_mb__{before,after}_atomic" is so "suggestive"!
   
(think at x86...), but it's not explicit in the proposed names.

I don't have other names to suggest at the moment...  ;/ (aka just saying)

  Andrea


> 
> IIUC, the void-returning atomic ops are relaxed, so trying to unify that
> with the usual rule that no suffix means fence will slow things down
> unless we want to do a treewide substitition to fixup for that.
> 
> Thanks,
> Mark.
> 
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/commit/?h=atomics/api-unification=c6b9ff2627d06776e427a7f1a7f83caeff3db536

Re: [PATCH 0/2] mm->owner to mm->memcg fixes

[Andrea Parri]

On Thu, May 24, 2018 at 02:16:35PM -0700, Andrew Morton wrote:
> On Thu, 24 May 2018 13:10:02 +0200 Michal Hocko  wrote:
> 
> > I would really prefer and appreciate a repost with all the fixes folded
> > in.
> 
> [1/2]
> 
> From: "Eric W. Biederman" 
> Subject: memcg: replace mm->owner with mm->memcg
> 
> Recently it was reported that mm_update_next_owner could get into cases
> where it was executing its fallback for_each_process part of the loop and
> thus taking up a lot of time.

Reference?


> 
> To deal with this replace mm->owner with mm->memcg.  This just reduces the
> complexity of everything.

"the complexity of everything"?


> As much as possible I have maintained the
> current semantics.

"As much as possible"?


> There are two siginificant exceptions.

s/siginificant/significant


> During fork
> the memcg of the process calling fork is charged rather than init_css_set.
> During memory cgroup migration the charges are migrated not if the
> process is the owner of the mm, but if the process being migrated has the
> same memory cgroup as the mm.
> 
> I believe it was a bug

It was a bug or not??


> if init_css_set is charged for memory activity
> during fork, and the old behavior was simply a consequence of the new task
> not having tsk->cgroup not initialized to it's proper cgroup.
> 
> During cgroup migration only thread group leaders are allowed to migrate. 
> Which means in practice there should only be one.

"in practice there should"??


> Linux tasks created
> with CLONE_VM are the only exception, but the common cases are already
> ruled out.  Processes created with vfork have a suspended parent and can
> do nothing but call exec so they should never show up.  Threads of the
> same cgroup are not the thread group leader so also should not show up. 
> That leaves the old LinuxThreads library which is probably out of use by

"probably"???


> now, and someone doing something very creative with cgroups,

"very creative"?


> and rolling
> their own threads with CLONE_VM.  So in practice I don't think

"in practice I don't think"??

  Andrea


> the
> difference charge migration will affect anyone.
> 
> To ensure that mm->memcg is updated appropriately I have implemented
> cgroup "attach" and "fork" methods.  This ensures that at those points the
> mm pointed to the task has the appropriate memory cgroup.
> 
> For simplicity instead of introducing a new mm lock I simply use exchange
> on the pointer where the mm->memcg is updated to get atomic updates.
> 
> Looking at the history effectively this change is a revert.  The reason
> given for adding mm->owner is so that multiple cgroups can be attached to
> the same mm.  In the last 8 years a second user of mm->owner has not
> appeared.  A feature that has never used, makes the code more complicated
> and has horrible worst case performance should go.
> 
> [ebied...@xmission.com: update to work when !CONFIG_MMU]
>   Link: http://lkml.kernel.org/r/87lgczcox0.fsf...@xmission.com
> [ebied...@xmission.com: close race between migration and installing bprm->mm 
> as mm]
>   Link: http://lkml.kernel.org/r/87fu37cow4.fsf...@xmission.com
> Link: http://lkml.kernel.org/r/87lgd1zww0.fsf...@xmission.com
> Fixes: cf475ad28ac3 ("cgroups: add an owner to the mm_struct")
> Signed-off-by: "Eric W. Biederman" 
> Reported-by: Kirill Tkhai 
> Acked-by: Johannes Weiner 
> Cc: Michal Hocko 
> Cc: "Kirill A. Shutemov" 
> Cc: Tejun Heo 
> Cc: Oleg Nesterov 
> Signed-off-by: Andrew Morton 
> ---
> 
>  fs/exec.c  |3 -
>  include/linux/memcontrol.h |   16 +-
>  include/linux/mm_types.h   |   12 
>  include/linux/sched/mm.h   |8 ---
>  kernel/exit.c  |   89 ---
>  kernel/fork.c  |   17 +-
>  mm/debug.c |4 -
>  mm/memcontrol.c|   81 +++
>  8 files changed, 93 insertions(+), 137 deletions(-)
> 
> diff -puN fs/exec.c~memcg-replace-mm-owner-with-mm-memcg fs/exec.c
> --- a/fs/exec.c~memcg-replace-mm-owner-with-mm-memcg
> +++ a/fs/exec.c
> @@ -1040,11 +1040,12 @@ static int exec_mmap(struct mm_struct *m
>   up_read(_mm->mmap_sem);
>   BUG_ON(active_mm != old_mm);
>   setmax_mm_hiwater_rss(>signal->maxrss, old_mm);
> - mm_update_next_owner(old_mm);
>   mmput(old_mm);
>   return 0;
>   }
>   mmdrop(active_mm);
> + /* The tsk may have migrated before the new mm was attached */
> + mm_sync_memcg_from_task(tsk);
>   return 0;
>  }
>  
> diff -puN include/linux/memcontrol.h~memcg-replace-mm-owner-with-mm-memcg 
> include/linux/memcontrol.h
> --- a/include/linux/memcontrol.h~memcg-replace-mm-owner-with-mm-memcg
> +++ 

Re: [PATCH V5] powercap/drivers/idle_injection: Add an idle injection framework

[Andrea Parri]

Hi Daniel, Viresh,

On Wed, Jun 06, 2018 at 04:15:28PM +0530, Viresh Kumar wrote:
> On 06-06-18, 12:22, Daniel Lezcano wrote:
> > (mb() are done in the atomic operations AFAICT).

To do my bit, not all atomic ops do/imply memory barriers; e.g.,

  [from Documentation/atomic_t.txt]

  - non-RMW operations [e.g., atomic_set()] are unordered

  - RMW operations that have no return value [e.g., atomic_inc()] are unordered


> 
> AFAIU, it is required to make sure the operations are seen in a particular 
> order
> on another CPU and the compiler doesn't reorganize code to optimize it.
> 
> For example, in our case what if the compiler reorganizes the atomic-set
> operation after wakeup-process ? But maybe that wouldn't happen across 
> function
> calls and we should be safe then.

IIUC, wake_up_process() implies a full memory barrier and a compiler barrier,
due to:

  raw_spin_lock_irqsave(>pi_lock, flags);
  smp_mb__after_spinlock();

The pattern under discussion isn't clear to me, but if you'll end up relying
on this "implicit" barrier I'd suggest documenting it with a comment.

  Andrea

Re: [PATCH v4 1/3] compiler-gcc.h: add gnu_inline to all inline declarations

[Andrea Parri]

On Fri, Jun 08, 2018 at 12:04:36PM +0200, Sedat Dilek wrote:
> On Fri, Jun 8, 2018 at 9:59 AM, Arnd Bergmann  wrote:
> > On Thu, Jun 7, 2018 at 10:49 PM, Nick Desaulniers
> >  wrote:
> >> Functions marked extern inline do not emit an externally visible
> >> function when the gnu89 C standard is used. Some KBUILD Makefiles
> >> overwrite KBUILD_CFLAGS. This is an issue for GCC 5.1+ users as without
> >> an explicit C standard specified, the default is gnu11. Since c99, the
> >> semantics of extern inline have changed such that an externally visible
> >> function is always emitted. This can lead to multiple definition errors
> >> of extern inline functions at link time of compilation units whose build
> >> files have removed an explicit C standard compiler flag for users of GCC
> >> 5.1+ or Clang.
> >>
> >> Signed-off-by: Nick Desaulniers 
> >> Suggested-by: H. Peter Anvin 
> >> Suggested-by: Joe Perches 
> >
> > I suspect this will break Geert's gcc-4.1.2, which I think doesn't have that
> > attribute yet (4.1.3 or higher have it according to the documentation.
> >
> > It wouldn't be hard to work around that if we want to keep that version
> > working, or we could decide that it's time to officially stop supporting
> > that version, but we should probably decide on one or the other.
> >
> 
> Good point.
> What is the minimum requirement of GCC version currently?

Good question ;-)  (I recently had the impression that
Documentation/process/changes.rst was making fun of me ;-)


> AFAICS x86/asm-goto support requires GCC >= 4.5?
> 
> Just FYI...
> ...saw the last days in upstream commits that kbuild/kconfig for
> 4.18-rc1 offers possibilities to check for cc-version dependencies.

Good to know!  Mind retrieving/sharing the commit id(s)
or links to the corresponding discussion on LKML?

Thanks,
  Andrea


> 
> - sed@ -

Re: [PATCH RFC tools/memory-model] Add litmus-test naming scheme

[Andrea Parri]

Mbs** FenceMbs*R FenceMbs*W FenceMbsR* FenceMbsRR 
> FenceMbsRW FenceMbsW* FenceMbsWR FenceMbsWW FenceRcu-lock FenceRcu-lockd** 
> FenceRcu-lockd*R FenceRcu-lockd*W FenceRcu-lockdR* FenceRcu-lockdRR 
> FenceRcu-lockdRW FenceRcu-lockdW* FenceRcu-lockdWR FenceRcu-lockdWW 
> FenceRcu-locks** FenceRcu-locks*R FenceRcu-locks*W FenceRcu-locksR* 
> FenceRcu-locksRR FenceRcu-locksRW FenceRcu-locksW* FenceRcu-locksWR 
> FenceRcu-locksWW FenceRcu-unlock FenceRcu-unlockd** FenceRcu-unlockd*R 
> FenceRcu-unlockd*W FenceRcu-unlockdR* FenceRcu-unlockdRR FenceRcu-unlockdRW 
> FenceRcu-unlockdW* FenceRcu-unlockdWR FenceRcu-unlockdWW FenceRcu-unlocks** 
> FenceRcu-unlocks*R FenceRcu-unlocks*W FenceRcu-unlocksR* FenceRcu-unlocksRR 
> FenceRcu-unlocksRW FenceRcu-unlocksW* FenceRcu-unlocksWR FenceRcu-unlocksWW 
> FenceRmb FenceRmbd** FenceRmbd*R FenceRmbd*W FenceRmbdR* FenceRmbdRR 
> FenceRmbdRW FenceRmbdW* FenceRmbdWR FenceRmbdWW FenceRmbs** FenceRmbs*R 
> FenceRmbs*W FenceRmbsR* FenceRmbsRR FenceRmbsRW FenceRmbsW* FenceRmbsWR 
> FenceRmbsWW FenceSync-rcu FenceSync-rcud** FenceSync-rcud*R FenceSync-rcud*W 
> FenceSync-rcudR* FenceSync-rcudRR FenceSync-rcudRW FenceSync-rcudW* 
> FenceSync-rcudWR FenceSync-rcudWW FenceSync-rcus** FenceSync-rcus*R 
> FenceSync-rcus*W FenceSync-rcusR* FenceSync-rcusRR FenceSync-rcusRW 
> FenceSync-rcusW* FenceSync-rcusWR FenceSync-rcusWW FenceWmb FenceWmbd** 
> FenceWmbd*R FenceWmbd*W FenceWmbdR* FenceWmbdRR FenceWmbdRW FenceWmbdW* 
> FenceWmbdWR FenceWmbdWW FenceWmbs** FenceWmbs*R FenceWmbs*W FenceWmbsR* 
> FenceWmbsRR FenceWmbsRW FenceWmbsW* FenceWmbsWR FenceWmbsWW Fenced** Fenced*R 
> Fenced*W FencedR* FencedRR FencedRW FencedW* FencedWR FencedWW Fences** 
> Fences*R Fences*W FencesR* FencesRR FencesRW FencesW* FencesWR FencesWW 
> FrBack FrLeave Fre Fri Hat Na Pod** Pod*R Pod*W PodR* PodRR PodRW PodW* PodWR 
> PodWW Pos** Pos*R Pos*W PosR* PosRR PosRW PosW* PosWR PosWW R Read RfBack 
> RfLeave Rfe Rfi Rmw W Write WsBack WsLeave Wse Wsi
> 
> I added the following at the end:
> 
> Please note that the above is a partial list.  To see the full list of
> descriptors, execute the following command:
> 
> $ diyone7 -bell linux-kernel.bell -show edges

Thanks.  One more nit: I'd indent this and the above "norm7" commands as
we do in our "main" README.


> 
> > I also notice that our current names for tests with fences (and cycle)
> > deviate from the corresponding 'norm7' results; e.g.,
> > 
> >   $ norm7 -bell linux-kernel.bell FenceWmbdWW Once Rfe Once FenceRmbdRR 
> > Once Fre Once | sed -e 's/:.*//g'
> >   MP+fencewmbonceonce+fencermbonceonce
> > 
> > while we use 'MP+wmbonceonce+rmbonceonce' (that is, we omit the 'fence'
> > prefixes).
> 
> Would you be willing to send me a patch fixing them up?

Yes, I'll work this out.

  Andrea


> 
> Please see below for updated patch.
> 
>   Thanx, Paul
> 
> 
> 
> commit 04a897a8e202e8d79dd47910321f0e8efb081854
> Author: Paul E. McKenney 
> Date:   Fri May 25 12:02:53 2018 -0700
> 
> EXP tools/memory-model: Add litmus-test naming scheme
> 
> This commit documents the scheme used to generate the names for the
> litmus tests.
> 
> Signed-off-by: Paul E. McKenney 
> [ paulmck: Apply feedback from Andrea Parri. ]
> 
> diff --git a/tools/memory-model/litmus-tests/README 
> b/tools/memory-model/litmus-tests/README
> index 00140aaf58b7..9c0ea65c5362 100644
> --- a/tools/memory-model/litmus-tests/README
> +++ b/tools/memory-model/litmus-tests/README
> @@ -1,4 +1,6 @@
> -This directory contains the following litmus tests:
> +
> +LITMUS TESTS
> +
>  
>  CoRR+poonceonce+Once.litmus
>   Test of read-read coherence, that is, whether or not two
> @@ -151,3 +153,143 @@ Z6.0+pooncerelease+poacquirerelease+mbonceonce.litmus
>  A great many more litmus tests are available here:
>  
>   https://github.com/paulmckrcu/litmus
> +
> +==
> +LITMUS TEST NAMING
> +==
> +
> +Litmus tests are usually named based on their contents, which means that
> +looking at the name tells you what the litmus test does.  The naming
> +scheme covers litmus tests having a single cycle that passes through
> +each process exactly once, so litmus tests not fitting this description
> +are named on an ad-hoc basis.
> +
> +The structure of a litmus-test name is the litmus-test class, a plus
> +sign ("+"), and one string for each process, separated by plus signs.
> +The end of the name is ".litmus".
> +
> +The litmus-test classes may 

[PATCH] tools/memory-model: Rename litmus tests to comply to norm7

[Andrea Parri]

norm7 produces the 'normalized' name of a litmus test,  when the test
can be generated from a single cycle that passes through each process
exactly once. The commit renames such tests in order to comply to the
naming scheme implemented by this tool.

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" 
Cc: Akira Yokosawa 
---
 tools/memory-model/Documentation/recipes.txt   |  8 ++--
 tools/memory-model/README  | 20 +-
 .../IRIW+fencembonceonces+OnceOnce.litmus  | 45 ++
 .../litmus-tests/IRIW+mbonceonces+OnceOnce.litmus  | 45 --
 .../litmus-tests/LB+ctrlonceonce+mbonceonce.litmus | 34 
 .../LB+fencembonceonce+ctrlonceonce.litmus | 34 
 .../MP+fencewmbonceonce+fencermbonceonce.litmus| 30 +++
 .../litmus-tests/MP+wmbonceonce+rmbonceonce.litmus | 30 ---
 .../litmus-tests/R+fencembonceonces.litmus | 30 +++
 .../memory-model/litmus-tests/R+mbonceonces.litmus | 30 ---
 tools/memory-model/litmus-tests/README | 16 
 .../S+fencewmbonceonce+poacquireonce.litmus| 27 +
 .../S+wmbonceonce+poacquireonce.litmus | 27 -
 .../litmus-tests/SB+fencembonceonces.litmus| 32 +++
 .../litmus-tests/SB+mbonceonces.litmus | 32 ---
 .../WRC+pooncerelease+fencermbonceonce+Once.litmus | 38 ++
 .../WRC+pooncerelease+rmbonceonce+Once.litmus  | 38 --
 ...release+poacquirerelease+fencembonceonce.litmus | 42 
 ...ooncerelease+poacquirerelease+mbonceonce.litmus | 42 
 19 files changed, 300 insertions(+), 300 deletions(-)
 create mode 100644 
tools/memory-model/litmus-tests/IRIW+fencembonceonces+OnceOnce.litmus
 delete mode 100644 
tools/memory-model/litmus-tests/IRIW+mbonceonces+OnceOnce.litmus
 delete mode 100644 
tools/memory-model/litmus-tests/LB+ctrlonceonce+mbonceonce.litmus
 create mode 100644 
tools/memory-model/litmus-tests/LB+fencembonceonce+ctrlonceonce.litmus
 create mode 100644 
tools/memory-model/litmus-tests/MP+fencewmbonceonce+fencermbonceonce.litmus
 delete mode 100644 
tools/memory-model/litmus-tests/MP+wmbonceonce+rmbonceonce.litmus
 create mode 100644 tools/memory-model/litmus-tests/R+fencembonceonces.litmus
 delete mode 100644 tools/memory-model/litmus-tests/R+mbonceonces.litmus
 create mode 100644 
tools/memory-model/litmus-tests/S+fencewmbonceonce+poacquireonce.litmus
 delete mode 100644 
tools/memory-model/litmus-tests/S+wmbonceonce+poacquireonce.litmus
 create mode 100644 tools/memory-model/litmus-tests/SB+fencembonceonces.litmus
 delete mode 100644 tools/memory-model/litmus-tests/SB+mbonceonces.litmus
 create mode 100644 
tools/memory-model/litmus-tests/WRC+pooncerelease+fencermbonceonce+Once.litmus
 delete mode 100644 
tools/memory-model/litmus-tests/WRC+pooncerelease+rmbonceonce+Once.litmus
 create mode 100644 
tools/memory-model/litmus-tests/Z6.0+pooncerelease+poacquirerelease+fencembonceonce.litmus
 delete mode 100644 
tools/memory-model/litmus-tests/Z6.0+pooncerelease+poacquirerelease+mbonceonce.litmus

diff --git a/tools/memory-model/Documentation/recipes.txt 
b/tools/memory-model/Documentation/recipes.txt
index ee4309a87fc45..a40802fa1099e 100644
--- a/tools/memory-model/Documentation/recipes.txt
+++ b/tools/memory-model/Documentation/recipes.txt
@@ -126,7 +126,7 @@ However, it is not necessarily the case that accesses 
ordered by
 locking will be seen as ordered by CPUs not holding that lock.
 Consider this example:
 
-   /* See Z6.0+pooncelock+pooncelock+pombonce.litmus. */
+   /* See Z6.0+pooncerelease+poacquirerelease+fencembonceonce.litmus. */
void CPU0(void)
{
spin_lock();
@@ -292,7 +292,7 @@ and to use smp_load_acquire() instead of smp_rmb().  
However, the older
 smp_wmb() and smp_rmb() APIs are still heavily used, so it is important
 to understand their use cases.  The general approach is shown below:
 
-   /* See MP+wmbonceonce+rmbonceonce.litmus. */
+   /* See MP+fencewmbonceonce+fencermbonceonce.litmus. */
void CPU0(void)
{
WRITE_ONCE(x, 1);
@@ -360,7 +360,7 @@ can be seen in the LB+poonceonces.litmus litmus test.
 One way of avoiding the counter-intuitive outcome is through the use of a
 control dependency paired with a full memory barrier:
 
-   /* See LB+ctrlonceonce+mbonceonce.litmus. */
+   /* See LB+fencembonceonce+ctrlonceonce.litmus. */
void CPU0(void)
{
r0 = READ_ONCE(x);
@@ -476,7 +476,7 @@ that one CPU first stores to one variable and then loads 
from a second,
 while another CPU stores to the second variable and then loads from the
 first.  Preserving orde

Re: [PATCH RFC tools/memory-model] Add litmus-test naming scheme

[Andrea Parri]

[...]

> > Right, thanks.  Ah, maybe we should strive to meet the 80-chars bound
> > by splitting the command with "\"?
> 
> We could, but combined with your later request for indentation, we end
> up with something like this:
> 
>   $ norm7 -bell linux-kernel.bell \
>   Rfi Once PodRR Once Fre Once Rfi Once PodRR Once Fre Once | \
> sed -e 's/:.*//g'
>   SB+rfionceonce-poonceonces
> 
> In the immortal words of MSDOS, are you sure?  ;-)

I find it more readable, but it's just taste ;-)  Commands are indented
with 2 spaces in the other README.


> > Well, "Rfi" produces "rfi" while "PosWR" produces "pos" for a name...
> 
> Right you are!  How about this, then?
> 
> Rfi: Read-from internal.  The current process wrote a variable and then
> immediately read the value back from it.  For the purposes of
> litmus-test code generation, Rfi acts identically to PosWR.
> However, they differ for purposes of naming, and they also result
> in different "exists" clauses.
>   Example:  ???

LGTM, thanks.

  Andrea

Re: [PATCH RFC tools/memory-model] Add litmus-test naming scheme

[Andrea Parri]

On Fri, May 25, 2018 at 12:10:20PM -0700, Paul E. McKenney wrote:
> This commit documents the scheme used to generate the names for the
> litmus tests.
> 
> Signed-off-by: Paul E. McKenney 
> ---
>  README |  136 
> -
>  1 file changed, 135 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/memory-model/litmus-tests/README 
> b/tools/memory-model/litmus-tests/README
> index 00140aaf58b7..b81f51054cd3 100644
> --- a/tools/memory-model/litmus-tests/README
> +++ b/tools/memory-model/litmus-tests/README
> @@ -1,4 +1,6 @@
> -This directory contains the following litmus tests:
> +
> +LITMUS TESTS
> +
>  
>  CoRR+poonceonce+Once.litmus
>   Test of read-read coherence, that is, whether or not two
> @@ -151,3 +153,135 @@ Z6.0+pooncerelease+poacquirerelease+mbonceonce.litmus
>  A great many more litmus tests are available here:
>  
>   https://github.com/paulmckrcu/litmus
> +
> +==
> +LITMUS TEST NAMING
> +==
> +
> +Litmus tests are usually named based on their contents, which means that
> +looking at the name tells you what the litmus test does.  The naming
> +scheme covers litmus tests having a single cycle that passes through
> +each process exactly once, so litmus tests not fitting this description
> +are named on an ad-hoc basis.
> +
> +The structure of a litmus-test name is the litmus-test class, a plus
> +sign ("+"), and one string for each process, separated by plus signs.
> +The end of the name is ".litmus".

We used to distinguigh between the test name and the test filename; we
currently have only one test whose name ends with .litmus:

  ISA2+pooncelock+pooncelock+pombonce.litmus

(that I missed until now...).


> +
> +The litmus-test classes may be found in the infamous test6.pdf:
> +https://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test6.pdf
> +Each class defines the pattern of accesses and of the variables accessed.
> +For example, if the one process writes to a pair of variables, and
> +the other process reads from these same variables, the corresponding
> +litmus-test class is "MP" (message passing), which may be found on the
> +left-hand end of the second row of tests on page one of test6.pdf.
> +
> +The strings used to identify the actions carried out by each process are
> +complex due to a desire to have finite-length names.

I'm not sure what you mean here: can you elaborate/rephrase?


> Thus, there is a
> +tool to generate these strings from a given litmus test's actions.  For
> +example, consider the processes from SB+rfionceonce-poonceonces.litmus:
> +
> + P0(int *x, int *y)
> + {
> + int r1;
> + int r2;
> +
> + WRITE_ONCE(*x, 1);
> + r1 = READ_ONCE(*x);
> + r2 = READ_ONCE(*y);
> + }
> +
> + P1(int *x, int *y)
> + {
> + int r3;
> + int r4;
> +
> + WRITE_ONCE(*y, 1);
> + r3 = READ_ONCE(*y);
> + r4 = READ_ONCE(*x);
> + }
> +
> +The next step is to construct a space-separated list of descriptors,
> +interleaving descriptions of the relation between a pair of consecutive
> +accesses with descriptions of the second access in the pair.
> +
> +P0()'s WRITE_ONCE() is read by its first READ_ONCE(), which is a
> +reads-from link (rf) and internal to the P0() process.  This is
> +"rfi", which is an abbreviation for "reads-from internal".  Because
> +some of the tools string these abbreviations together with space
> +characters separating processes, the first character is capitalized,
> +resulting in "Rfi".
> +
> +P0()'s second access is a READ_ONCE(), as opposed to (for example)
> +smp_load_acquire(), so next is "Once".  Thus far, we have "Rfi Once".
> +
> +P0()'s third access is also a READ_ONCE(), but to y rather than x.
> +This is related to P0()'s second access by program order ("po"),
> +to a different variable ("d"), and both accesses are reads ("RR").
> +The resulting descriptor is "PodRR".  Because P0()'s third access is
> +READ_ONCE(), we add another "Once" descriptor.
> +
> +A from-read ("fre") relation links P0()'s third to P1()'s first
> +access, and the resulting descriptor is "Fre".  P1()'s first access is
> +WRITE_ONCE(), which as before gives the descriptor "Once".  The string
> +thus far is thus "Rfi Once PodRR Once Fre Once".
> +
> +The remainder of P1() is similar to P0(), which means we add
> +"Rfi Once PodRR Once".  Another fre links P1()'s last access to
> +P0()'s first access, which is WRITE_ONCE(), so we add "Fre Once".
> +The full string is thus:
> +
> + Rfi Once PodRR Once Fre Once Rfi Once PodRR Once Fre Once
> +
> +This string can be given to the "norm7" and "classify7" tools to
> +produce the name:
> +
> +$ norm7 -bell linux-kernel.bell Rfi Once PodRR Once Fre Once Rfi Once PodRR 
> Once Fre Once |  classify7 -bell linux-kernel.bell -diyone | sed -e 's/:.*//g'
> 

Re: [PATCHv2 03/11] atomics: simplify cmpxchg() instrumentation

[Andrea Parri]

On Mon, Jun 25, 2018 at 11:59:44AM +0100, Mark Rutland wrote:
> Currently we define some fairly verbose wrappers for the cmpxchg()
> family so that we can pass a pointer and size into kasan_check_write().
> 
> The wrapper duplicate the size-switching logic necessary in arch code,
> and only work for scalar types. On some architectures, (cmp)xchg are
> used on non-scalar types, and thus the instrumented wrappers need to be
> able to handle this.
> 
> We could take the type-punning logic form {READ,WRITE}_ONCE(), but this
> makes the wrappers even more verbose, and requires several local
> variables in the macros.
> 
> Instead, let's simplify the wrappers into simple macros which:
> 
>  * snapshot the pointer into a single local variable, called __ai_ptr to
>avoid conflicts with variables in the scope of the caller.
> 
>  * call kasan_check_read() on __ai_ptr.

Maybe I'm misreading the diff: aren't you calling kasan_check_write()?
(not sure if it makes a difference in this case/for KTSan, but CMPXCHG
does not necessarily perform a write...)

  Andrea


> 
>  * invoke the arch_ function, passing the original arguments, bar
>__ai_ptr being substituted for ptr.
> 
> There should be no functional change as a result of this patch.
> 
> Signed-off-by: Mark Rutland 
> Cc: Boqun Feng 
> Cc: Dmitry Vyukov 
> Cc: Peter Zijlstra 
> Cc: Will Deacon 
> ---
>  include/asm-generic/atomic-instrumented.h | 100 
> +-
>  1 file changed, 15 insertions(+), 85 deletions(-)
> 
> diff --git a/include/asm-generic/atomic-instrumented.h 
> b/include/asm-generic/atomic-instrumented.h
> index 3c64e95d5ed0..c7c3e4cdd942 100644
> --- a/include/asm-generic/atomic-instrumented.h
> +++ b/include/asm-generic/atomic-instrumented.h
> @@ -408,109 +408,39 @@ static __always_inline bool atomic64_add_negative(s64 
> i, atomic64_t *v)
>  }
>  #endif
>  
> -static __always_inline unsigned long
> -cmpxchg_size(volatile void *ptr, unsigned long old, unsigned long new, int 
> size)
> -{
> - kasan_check_write(ptr, size);
> - switch (size) {
> - case 1:
> - return arch_cmpxchg((u8 *)ptr, (u8)old, (u8)new);
> - case 2:
> - return arch_cmpxchg((u16 *)ptr, (u16)old, (u16)new);
> - case 4:
> - return arch_cmpxchg((u32 *)ptr, (u32)old, (u32)new);
> - case 8:
> - BUILD_BUG_ON(sizeof(unsigned long) != 8);
> - return arch_cmpxchg((u64 *)ptr, (u64)old, (u64)new);
> - }
> - BUILD_BUG();
> - return 0;
> -}
> -
>  #define cmpxchg(ptr, old, new)   
> \
>  ({   \
> - ((__typeof__(*(ptr)))cmpxchg_size((ptr), (unsigned long)(old),  \
> - (unsigned long)(new), sizeof(*(ptr; \
> + typeof(ptr) __ai_ptr = (ptr);   \
> + kasan_check_write(__ai_ptr, sizeof(*__ai_ptr)); \
> + arch_cmpxchg(__ai_ptr, (old), (new));   \
>  })
>  
> -static __always_inline unsigned long
> -sync_cmpxchg_size(volatile void *ptr, unsigned long old, unsigned long new,
> -   int size)
> -{
> - kasan_check_write(ptr, size);
> - switch (size) {
> - case 1:
> - return arch_sync_cmpxchg((u8 *)ptr, (u8)old, (u8)new);
> - case 2:
> - return arch_sync_cmpxchg((u16 *)ptr, (u16)old, (u16)new);
> - case 4:
> - return arch_sync_cmpxchg((u32 *)ptr, (u32)old, (u32)new);
> - case 8:
> - BUILD_BUG_ON(sizeof(unsigned long) != 8);
> - return arch_sync_cmpxchg((u64 *)ptr, (u64)old, (u64)new);
> - }
> - BUILD_BUG();
> - return 0;
> -}
> -
>  #define sync_cmpxchg(ptr, old, new)  \
>  ({   \
> - ((__typeof__(*(ptr)))sync_cmpxchg_size((ptr),   \
> - (unsigned long)(old), (unsigned long)(new), \
> - sizeof(*(ptr;   \
> + typeof(ptr) __ai_ptr = (ptr);   \
> + kasan_check_write(__ai_ptr, sizeof(*__ai_ptr)); \
> + arch_sync_cmpxchg(__ai_ptr, (old), (new));  \
>  })
>  
> -static __always_inline unsigned long
> -cmpxchg_local_size(volatile void *ptr, unsigned long old, unsigned long new,
> -int size)
> -{
> - kasan_check_write(ptr, size);
> - switch (size) {
> - case 1:
> - return arch_cmpxchg_local((u8 *)ptr, (u8)old, (u8)new);
> - case 2:
> - return arch_cmpxchg_local((u16 *)ptr, (u16)old, (u16)new);
> - case 4:
> - return arch_cmpxchg_local((u32 *)ptr, (u32)old, (u32)new);
> - case 8:
> - BUILD_BUG_ON(sizeof(unsigned long) != 8);
> - return arch_cmpxchg_local((u64 *)ptr, (u64)old, (u64)new);
> - }

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

[Andrea Parri]

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
> acquire/release efficiently, and it's not unlikely that they will have
> acquire loads that are similar in semantics to LDAPR. This patch prevents
> them from doing so,

By this same argument, you should not be a "big fan" of rfi-rel-acq in ppo ;)
consider, e.g., the two litmus tests below: what am I missing?

  Andrea


C MP+fencewmbonceonce+pooncerelease-rfireleaseacquire-poacquireonce

{}

P0(int *x, int *y)
{
WRITE_ONCE(*x, 1);
smp_wmb();
WRITE_ONCE(*y, 1);
}

P1(int *x, int *y, int *z)
{
r0 = READ_ONCE(*y);
smp_store_release(z, 1);
r1 = smp_load_acquire(z);
r2 = READ_ONCE(*x);
}

exists (1:r0=1 /\ 1:r1=1 /\ 1:r2=0)


AArch64 MP+dmb.st+popl-rfilq-poqp
"DMB.STdWW Rfe PodRWPL RfiLQ PodRRQP Fre"
Generator=diyone7 (version 7.49+02(dev))
Prefetch=0:x=F,0:y=W,1:y=F,1:x=T
Com=Rf Fr
Orig=DMB.STdWW Rfe PodRWPL RfiLQ PodRRQP Fre
{
0:X1=x; 0:X3=y;
1:X1=y; 1:X3=z; 1:X6=x;
}
 P0  | P1;
 MOV W0,#1   | LDR W0,[X1]   ;
 STR W0,[X1] | MOV W2,#1 ;
 DMB ST  | STLR W2,[X3]  ;
 MOV W2,#1   | LDAPR W4,[X3] ;
 STR W2,[X3] | LDR W5,[X6]   ;
exists
(1:X0=1 /\ 1:X4=1 /\ 1:X5=0)

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

[Andrea Parri]

On Mon, Jun 25, 2018 at 09:32:29AM +0200, Peter Zijlstra wrote:
> 
> I have yet to digest the rest of the discussion, however:
> 
> On Fri, Jun 22, 2018 at 02:09:04PM -0400, Alan Stern wrote:
> > The LKMM uses the same CAT code for acquire/release and lock/unlock.
> > (In essence, it considers a lock to be an acquire and an unlock to be a
> > release; everything else follows from that.)  Treating one differently
> > from the other in these tests would require some significant changes.
> > It wouldn't be easy.
> 
> That is problematic, acquire+release are very much simpler operations
> than lock+unlock.
> 
> At the very least, lock includes a control-dependency, where acquire
> does not.

I don't see how this is relevant here; roughly, "if something is guaranteed
by a control-dependency, that is also guaranteed by an acquire".  Right? ;)

  Andrea

Re: [PATCH] MAINTAINERS: Add Daniel Lustig as a LKMM reviewer

[Andrea Parri]

> > Thanks.  Unless anyone has any opposition I'll submit the fixed
> > patch as part of my next pull request.
> 
> Works for me, especially if this means that Daniel is RISC-V's official
> representative.  ;-)

I'd rather the "fixed patch" go through the LKMM's tree.  If not for
other, we tend to use get_maintainer.pl on your (TBD ;/) development
branch...


> 
> Acked-by: Paul E. McKenney 
> 
> > commit 9d01337e4724be4d34bfe848a7c64d14bfdb89ea
> > gpg: Signature made Fri 22 Jun 2018 03:35:24 PM PDT
> > gpg:using RSA key 00CE76D1834960DFCE886DF8EF4CA1502CCBAB41
> > gpg:issuer "pal...@dabbelt.com"
> > gpg: Good signature from "Palmer Dabbelt " [ultimate]
> > gpg: aka "Palmer Dabbelt " [ultimate]
> > Author: Palmer Dabbelt 
> > Date:   Fri Jun 22 14:04:42 2018 -0700
> > 
> >MAINTAINERS: Add Daniel Lustig as a LKMM reviewer

Nit: an LKMM


> > 
> >Dan runs the RISC-V memory model working group.  I've been forwarding
> >him LKMM emails that end up in my inbox, but I'm far from an expert in
> >this stuff.  He requested to be added as a reviewer, which seem sane to

Nit: which seems


> >me as it'll take a human out of the loop.
> > 
> >CC: Daniel Lustig 
> >Acked-by: Daniel Lustig 
> >Signed-off-by: Palmer Dabbelt 

Glad to read this!  Please feel free to add:

Acked-by: Andrea Parri 

  Andrea


> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 9d5eeff51b5f..ac8ed55dbe9b 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -8316,6 +8316,7 @@ M:Jade Alglave 
> > M:  Luc Maranget 
> > M:  "Paul E. McKenney" 
> > R:  Akira Yokosawa 
> > +R: Daniel Lustig 
> > L:  linux-kernel@vger.kernel.org
> > S:  Supported
> > T:  git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git

[PATCH v2 2/3] locking: Clarify requirements for smp_mb__after_spinlock()

[Andrea Parri]

There are 11 interpretations of the requirements described in the header
comment for smp_mb__after_spinlock(): one for each LKMM maintainer, and
one currently encoded in the Cat file. Stick to the latter (until a more
satisfactory solution is available).

This also reworks some snippets related to the barrier to illustrate the
requirements and to link them to the idioms which are relied upon at its
call sites.

Suggested-by: Boqun Feng 
Signed-off-by: Andrea Parri 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Will Deacon 
Cc: "Paul E. McKenney" 
---
Changes since v1:

  - reworked the snippets (Peter Zijlstra)
  - style fixes (Alan Stern and Matthew Wilcox)
  - added Boqun's Suggested-by: tag

 include/linux/spinlock.h | 51 
 kernel/sched/core.c  | 41 +++---
 2 files changed, 55 insertions(+), 37 deletions(-)

diff --git a/include/linux/spinlock.h b/include/linux/spinlock.h
index 1e8a464358384..0b46efca659f9 100644
--- a/include/linux/spinlock.h
+++ b/include/linux/spinlock.h
@@ -114,29 +114,46 @@ do {  
\
 #endif /*arch_spin_is_contended*/
 
 /*
- * This barrier must provide two things:
+ * smp_mb__after_spinlock() provides the equivalent of a full memory barrier
+ * between program-order earlier lock acquisitions and program-order later
+ * memory accesses.
  *
- *   - it must guarantee a STORE before the spin_lock() is ordered against a
- * LOAD after it, see the comments at its two usage sites.
+ * This guarantees that the following two properties hold:
  *
- *   - it must ensure the critical section is RCsc.
+ *   1) Given the snippet:
  *
- * The latter is important for cases where we observe values written by other
- * CPUs in spin-loops, without barriers, while being subject to scheduling.
+ *   { X = 0;  Y = 0; }
  *
- * CPU0CPU1CPU2
+ *   CPU0  CPU1
  *
- * for (;;) {
- *   if (READ_ONCE(X))
- * break;
- * }
- * X=1
- * 
- * 
- * r = X;
+ *   WRITE_ONCE(X, 1); WRITE_ONCE(Y, 1);
+ *   spin_lock(S); smp_mb();
+ *   smp_mb__after_spinlock(); r1 = READ_ONCE(X);
+ *   r0 = READ_ONCE(Y);
+ *   spin_unlock(S);
  *
- * without transitivity it could be that CPU1 observes X!=0 breaks the loop,
- * we get migrated and CPU2 sees X==0.
+ *  it is forbidden that CPU0 does not observe CPU1's store to Y (r0 = 0)
+ *  and CPU1 does not observe CPU0's store to X (r1 = 0); see the comments
+ *  preceding the call to smp_mb__after_spinlock() in __schedule() and in
+ *  try_to_wake_up().
+ *
+ *   2) Given the snippet:
+ *
+ *  { X = 0;  Y = 0; }
+ *
+ *  CPU0   CPU1CPU2
+ *
+ *  spin_lock(S);  spin_lock(S);   r1 = READ_ONCE(Y);
+ *  WRITE_ONCE(X, 1);  smp_mb__after_spinlock();   smp_rmb();
+ *  spin_unlock(S);r0 = READ_ONCE(X);  r2 = READ_ONCE(X);
+ * WRITE_ONCE(Y, 1);
+ * spin_unlock(S);
+ *
+ *  it is forbidden that CPU0's critical section executes before CPU1's
+ *  critical section (r0 = 1), CPU2 observes CPU1's store to Y (r1 = 1)
+ *  and CPU2 does not observe CPU0's store to X (r2 = 0); see the comments
+ *  preceding the calls to smp_rmb() in try_to_wake_up() for similar
+ *  snippets but "projected" onto two CPUs.
  *
  * Since most load-store architectures implement ACQUIRE with an smp_mb() after
  * the LL/SC loop, they need no further barriers. Similarly all our TSO
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index da8f12119a127..ec9ef0aec71ac 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1999,21 +1999,20 @@ try_to_wake_up(struct task_struct *p, unsigned int 
state, int wake_flags)
 * be possible to, falsely, observe p->on_rq == 0 and get stuck
 * in smp_cond_load_acquire() below.
 *
-* sched_ttwu_pending() try_to_wake_up()
-*   [S] p->on_rq = 1;  [L] P->state
-*   UNLOCK rq->lock  -.
-*  \
-*   +---   RMB
-* schedule()   /
-*   LOCK rq->lock-'
-*   UNLOCK rq->lock
+* sched_ttwu_pending() try_to_wake_up()
+*   STORE p->on_rq = 1   LOAD p->state
+*   UNLOCK rq->lock
+*
+* __schedule() (switch to task 'p')
+*   LOCK rq->locksmp_rmb();
+*   smp_mb__after_spinlock();
+*   UNLOCK rq->l

Re: [PATCH 0/2] tools/memory-model: remove ACCESS_ONCE()

[Andrea Parri]

> >   1) Merge the file touched by that patch into (the recently created):
> >   
> > Documentation/atomic_t.txt
> > 
> >  (FWIW, queued in my TODO list).
> 
> Some consolidation of documentation would be good.  ;-)
> 
> Thoughts from others?
> 
> >   2) Add the entry:
> > 
> > F: Documentation/atomic_t.txt
> > 
> >  to the "ATOMIC INFRASTRUCTURE" subsystem in the MAINTAINERS file so
> >  that developers can easily find (the intended?) reviewers for their
> >  patch. (Of course, this will need ACK from the ATOMIC people).
> 
> If the merging will take awhile, it might also be good to put
> Documentation/core-api/atomic_ops.rst somewhere as well.

Indeed.  And let's not forget the "orphaned":

  Documentation/atomic_bitops.txt
  Documentation/core-api/refcount-vs-atomic.rst

;-)

  Andrea

Re: [PATCH] refcount: always allow checked forms

[Andrea Parri]

Hi Mark,

a typo below:


>  /**
> - * refcount_inc - increment a refcount
> + * refcount_inc_checked - increment a refcount
>   * @r: the refcount to increment
>   *
>   * Similar to atomic_inc(), but will saturate at UINT_MAX and WARN.
> @@ -148,14 +146,14 @@ EXPORT_SYMBOL(refcount_inc_not_zero);
>   * Will WARN if the refcount is 0, as this represents a possible 
> use-after-free
>   * condition.
>   */
> -void refcount_inc(refcount_t *r)
> +void refcount_inc_chcked(refcount_t *r)

s/chcked/checked

  Andrea

Re: [PATCH 4/4] exit: Lockless iteration over task list in mm_update_next_owner()

[Andrea Parri]

On Thu, Apr 26, 2018 at 04:52:39PM +0300, Kirill Tkhai wrote:
> On 26.04.2018 15:35, Andrea Parri wrote:

[...]

> > 
> > Mmh, it's possible that I am misunderstanding this statement but it does
> > not seem quite correct to me; a counter-example would be provided by the
> > test at "tools/memory-model/litmus-tests/SB+mbonceonces.litmus" (replace
> > either of the smp_mb() with the sequence:
> > 
> >spin_lock(s); spin_unlock(s); spin_lock(s); spin_unlock(s); ).
> > 
> > BTW, your commit message suggests that your case would work with "imply
> > an smp_wmb()".  This implication should hold "w.r.t. current implementa-
> > tions".  We (LKMM people) discussed changes to the LKMM to make it hold
> > in LKMM but such changes are still in our TODO list as of today...
> 
> I'm not close to LKMM, so the test you referenced is not clear for me.

The test could be concisely described by:

   {initially: x=y=0; }

   Thread0  Thread1

   x = 1;   y = 1;
   MB   MB
   r0 = y;  r1 = x;

   Can r0,r1 be both 0 after joining?

The answer to the question is -No-; however, if you replaced any of the
MB with the locking sequence described above, then the answer is -Yes-:
full fences on both sides are required to forbid that state and this is
something that the locking sequences won't be able to provide (think at
the implementation of these primitives for powerpc, for example).


> Does LKMM show the real hardware behavior? Or there are added the most
> cases, and work is still in progress?

Very roughly speaking, LKMM is an "envelope" of the underlying hardware
memory models/architectures supported by the Linux kernel which in turn
may not coincide with the observable behavior on a given implementation
/processor of that architecture.  Also, LKMM doesn't aim to be a "tight"
envelope.  I'd refer to the documentation within "tools/memory-model/";
please let me know if I can provide further info.


> 
> In the patch I used the logic, that the below code:
> 
>   x = A;
>   spin_lock();
>   spin_unlock();
>   spin_lock();
>   spin_unlock();
>   y = B;
> 
> cannot reorder much than:
> 
>   spin_lock();
>   x = A;  <- this can't become visible later, that spin_unlock()
>   spin_unlock();
>   spin_lock();
>   y = B;  <- this can't become visible earlier, than spin_lock()
>   spin_unlock();
> 
> Is there a problem?

As mentioned in the previous email, if smp_wmb() is what you're looking
for then this should be fine (considering current implementations; LKMM
will likely be there soon...).

BTW, the behavior in question has been recently discussed on the list;
c.f., for example, the test "unlock-lock-write-ordering" described in:

  
http://lkml.kernel.org/r/1519301990-11766-1-git-send-email-parri.and...@gmail.com

as well as

  0123f4d76ca63b7b895f40089be0ce4809e392d8
  ("riscv/spinlock: Strengthen implementations with fences")

  Andrea


> 
> Kirill

Re: [PATCH v1] kthread/smpboot: Serialize kthread parking against wakeup

[Andrea Parri]

On Thu, Apr 26, 2018 at 10:41:31AM +0200, Peter Zijlstra wrote:

[...]

> +/*
> + * Special states are those that do not use the normal wait-loop pattern. See
> + * the comment with set_special_state().
> + */
> +#define is_special_state(state)  \
> + ((state) == TASK_DEAD ||\
> +  (state) == TASK_STOPPED)
> +
>  #ifdef CONFIG_DEBUG_ATOMIC_SLEEP
>  
> +/*
> + * Assert we don't use the regular *set_current_state() helpers for special
> + * states. See the comment with set_special_state().
> + */
> +#define assert_special_state(state)  WARN_ON_ONCE(is_special_state(state))

Nitpicking, this name suggests "Shout if the state is NOT special" to me:
maybe,

#define assert_special_state(state) WARN_ON_ONCE(!is_special_state(state))
#define assert_regular_state(state) WARN_ON_ONCE(is_special_state(state))

or just do with the WARN_ON_ONCE()s ?

  Andrea


> +
>  #define __set_current_state(state_value) \
>   do {\
> + assert_special_state(state_value);  \
>   current->task_state_change = _THIS_IP_; \
>   current->state = (state_value); \
>   } while (0)
> +
>  #define set_current_state(state_value)   \
>   do {\
> + assert_special_state(state_value);  \
>   current->task_state_change = _THIS_IP_; \
>   smp_store_mb(current->state, (state_value));\
>   } while (0)
>  
> +#define set_special_state(state_value)   
> \
> + do {\
> + unsigned long flags; /* may shadow */   \
> + WARN_ON_ONCE(!is_special_state(state_value));   \
> + raw_spin_lock_irqsave(>pi_lock, flags);\
> + current->task_state_change = _THIS_IP_; \
> + current->state = (state_value); \
> + raw_spin_unlock_irqrestore(>pi_lock, flags);   \
> + } while (0)

Re: [PATCH] locking/qspinlock: Ensure node is initialised before updating prev->next

[Andrea Parri]

On Wed, Jan 31, 2018 at 01:38:59PM +0100, Peter Zijlstra wrote:
> On Wed, Jan 31, 2018 at 12:20:46PM +, Will Deacon wrote:
> > diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
> > index 294294c71ba4..1ebbc366a31d 100644
> > --- a/kernel/locking/qspinlock.c
> > +++ b/kernel/locking/qspinlock.c
> > @@ -408,16 +408,15 @@ void queued_spin_lock_slowpath(struct qspinlock 
> > *lock, u32 val)
> >  */
> > if (old & _Q_TAIL_MASK) {
> > prev = decode_tail(old);
> > +
> > /*
> > -* The above xchg_tail() is also a load of @lock which 
> > generates,
> > -* through decode_tail(), a pointer.
> > -*
> > -* The address dependency matches the RELEASE of xchg_tail()
> > -* such that the access to @prev must happen after.
> > +* We must ensure that the stores to @node are observed before
> > +* the write to prev->next. The address dependency on xchg_tail
> > +* is not sufficient to ensure this because the read component
> > +* of xchg_tail is unordered with respect to the initialisation
> > +* of node.
> >  */
> > -   smp_read_barrier_depends();
> 
> Right, except you're patching old code here, please try again on a tree
> that includes commit:
> 
>   548095dea63f ("locking: Remove smp_read_barrier_depends() from 
> queued_spin_lock_slowpath()")

BTW, which loads was/is the smp_read_barrier_depends() supposed to order? ;)

I was somehow guessing that this barrier was/is there to "order" the load
from xchg_tail() with the address-dependent loads from pv_wait_node(); is
this true? (Does Will's patch really remove the reliance on the barrier?)

  Andrea


> 
> > -
> > -   WRITE_ONCE(prev->next, node);
> > +   smp_store_release(prev->next, node);
> >  
> > pv_wait_node(node, prev);
> > arch_mcs_spin_lock_contended(>locked);
> > -- 
> > 2.1.4
> > 

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

[Andrea Parri]

Ingo pointed out that:

  "The "memory model" name is overly generic, ambiguous and somewhat
   misleading, as we usually mean the virtual memory layout/model
   when we say "memory model". GCC too uses it in that sense [...]"

Make it clearer that, in the context of tools/memory-model/, the term
"memory-model" is used as shorthand for "memory consistency model" by
calling out this convention in tools/memory-model/README.

Stick to the full 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>
---
 tools/memory-model/MAINTAINERS   |  2 +-
 tools/memory-model/README| 14 +++---
 tools/memory-model/linux-kernel.bell |  2 +-
 tools/memory-model/linux-kernel.cat  |  2 +-
 4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/tools/memory-model/MAINTAINERS b/tools/memory-model/MAINTAINERS
index 711cbe72d6066..db3bd3fc0435b 100644
--- a/tools/memory-model/MAINTAINERS
+++ b/tools/memory-model/MAINTAINERS
@@ -1,4 +1,4 @@
-LINUX KERNEL MEMORY MODEL
+LINUX KERNEL MEMORY CONSISTENCY MODEL
 M:     Alan Stern <st...@rowland.harvard.edu>
 M: Andrea Parri <parri.and...@gmail.com>
 M: Will Deacon <will.dea...@arm.com>
diff --git a/tools/memory-model/README b/tools/memory-model/README
index 43ba49492111c..91414a49fac53 100644
--- a/tools/memory-model/README
+++ b/tools/memory-model/README
@@ -1,15 +1,15 @@
-   =
-   LINUX KERNEL MEMORY MODEL
-   =
+   =
+   LINUX KERNEL MEMORY CONSISTENCY MODEL
+   =
 
 
 INTRODUCTION
 
 
-This directory contains the memory model of the Linux kernel, written
-in the "cat" language and executable by the (externally provided)
-"herd7" simulator, which exhaustively explores the state space of
-small litmus tests.
+This directory contains the memory consistency model (memory model, for
+short) of the Linux kernel, written in the "cat" language and executable
+by the externally provided "herd7" simulator, which exhaustively explores
+the state space of small litmus tests.
 
 In addition, the "klitmus7" tool (also externally provided) may be used
 to convert a litmus test to a Linux kernel module, which in turn allows
diff --git a/tools/memory-model/linux-kernel.bell 
b/tools/memory-model/linux-kernel.bell
index 57112505f5e03..b984bbda01a5c 100644
--- a/tools/memory-model/linux-kernel.bell
+++ b/tools/memory-model/linux-kernel.bell
@@ -11,7 +11,7 @@
  * which is to appear in ASPLOS 2018.
  *)
 
-"Linux kernel memory model"
+"Linux-kernel memory consistency model"
 
 enum Accesses = 'once (*READ_ONCE,WRITE_ONCE,ACCESS_ONCE*) ||
'release (*smp_store_release*) ||
diff --git a/tools/memory-model/linux-kernel.cat 
b/tools/memory-model/linux-kernel.cat
index 15b7a5dd8a9af..babe2b3b0bb32 100644
--- a/tools/memory-model/linux-kernel.cat
+++ b/tools/memory-model/linux-kernel.cat
@@ -11,7 +11,7 @@
  * which is to appear in ASPLOS 2018.
  *)
 
-"Linux kernel memory model"
+"Linux-kernel memory consistency model"
 
 (*
  * File "lock.cat" handles locks and is experimental.
-- 
2.7.4

[PATCH 2/2] MAINTAINERS: add the Memory Consistency Model subsystem

[Andrea Parri]

Integrate (and then remove) tools/memory-model/MAINTAINERS into the
main MAINTAINERS file. This way get_maintainer.pl can give a "right
answer" for tools/memory-model/.

Suggested-by: Ingo Molnar <mi...@kernel.org>
Signed-off-by: Andrea Parri <parri.and...@gmail.com>
---
 MAINTAINERS| 16 
 tools/memory-model/MAINTAINERS | 15 ---
 2 files changed, 16 insertions(+), 15 deletions(-)
 delete mode 100644 tools/memory-model/MAINTAINERS

diff --git a/MAINTAINERS b/MAINTAINERS
index 217a8759e897e..08454be9237d7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8091,6 +8091,22 @@ M:   Kees Cook <keesc...@chromium.org>
 S: Maintained
 F: drivers/misc/lkdtm*
 
+LINUX KERNEL MEMORY CONSISTENCY MODEL
+M: Alan Stern <st...@rowland.harvard.edu>
+M: Andrea Parri <parri.and...@gmail.com>
+M: Will Deacon <will.dea...@arm.com>
+M: Peter Zijlstra <pet...@infradead.org>
+M: Boqun Feng <boqun.f...@gmail.com>
+M: Nicholas Piggin <npig...@gmail.com>
+M: David Howells <dhowe...@redhat.com>
+M: Jade Alglave <j.algl...@ucl.ac.uk>
+M: Luc Maranget <luc.maran...@inria.fr>
+M: "Paul E. McKenney" <paul...@linux.vnet.ibm.com>
+L: linux-kernel@vger.kernel.org
+S: Supported
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
+F: tools/memory-model/
+
 LINUX SECURITY MODULE (LSM) FRAMEWORK
 M: Chris Wright <chr...@sous-sol.org>
 L: linux-security-mod...@vger.kernel.org
diff --git a/tools/memory-model/MAINTAINERS b/tools/memory-model/MAINTAINERS
deleted file mode 100644
index db3bd3fc0435b..0
--- a/tools/memory-model/MAINTAINERS
+++ /dev/null
@@ -1,15 +0,0 @@
-LINUX KERNEL MEMORY CONSISTENCY MODEL
-M: Alan Stern <st...@rowland.harvard.edu>
-M: Andrea Parri <parri.and...@gmail.com>
-M: Will Deacon <will.dea...@arm.com>
-M: Peter Zijlstra <pet...@infradead.org>
-M: Boqun Feng <boqun.f...@gmail.com>
-M: Nicholas Piggin <npig...@gmail.com>
-M: David Howells <dhowe...@redhat.com>
-M: Jade Alglave <j.algl...@ucl.ac.uk>
-M: Luc Maranget <luc.maran...@inria.fr>
-M: "Paul E. McKenney" <paul...@linux.vnet.ibm.com>
-L: linux-kernel@vger.kernel.org
-S: Supported
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
-F: tools/memory-model/
-- 
2.7.4

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

[Andrea Parri]

On Fri, Feb 02, 2018 at 03:19:22PM -0800, Paul E. McKenney wrote:
> On Fri, Feb 02, 2018 at 11:44:21AM +0100, Andrea Parri wrote:
> > On Thu, Feb 01, 2018 at 03:09:41PM -0800, Paul E. McKenney wrote:
> > > On Thu, Feb 01, 2018 at 10:26:50AM -0500, Alan Stern wrote:
> > > > On Thu, 1 Feb 2018, Andrea Parri wrote:
> > > > 
> > > > > Ingo pointed out that:
> > > > > 
> > > > >   "The "memory model" name is overly generic, ambiguous and somewhat
> > > > >misleading, as we usually mean the virtual memory layout/model
> > > > >when we say "memory model". GCC too uses it in that sense [...]"
> > > > > 
> > > > > Make it clearer that, in the context of tools/memory-model/, the term
> > > > > "memory-model" is used as shorthand for "memory consistency model" by
> > > > > calling out this convention in tools/memory-model/README.
> > > > > 
> > > > > Stick to the full 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>
> > > 
> > > Thank you all -- I have queued this and pushed it to my RCU tree on
> > > branch lkmm.  I did reword the commit log a bit, please see below and
> > > please let me know if any of my rewordings need halp.
> > 
> > Seems to me that your message has a leftover "is used".
> 
> Good catch, how about this instead?

Looks good to me. The same for 12a62a1d07031.

Thanks,
  Andrea


> 
>   Thanx, Paul
> 
> ---
> 
> commit 2b1b4ab5166209da849f306fbdc84114d9e611fd
> Author: Andrea Parri <parri.and...@gmail.com>
> Date:   Thu Feb 1 13:03:29 2018 +0100
> 
> tools/memory-model: Clarify the origin/scope of the tool name
> 
> Ingo pointed out that:
> 
>   "The "memory model" name is overly generic, ambiguous and somewhat
>misleading, as we usually mean the virtual memory layout/model
>when we say "memory model". GCC too uses it in that sense [...]"
> 
> Make it clear that tools/memory-model/ uses the term "memory model" as
> shorthand for "memory consistency model" by calling out this convention
> in tools/memory-model/README.
> 
> Stick to the original "memory model" term in sources' headers and for
> the subsystem name.
> 
> Suggested-by: Ingo Molnar <mi...@kernel.org>
> Signed-off-by: Andrea Parri <parri.and...@gmail.com>
> Acked-by: Will Deacon <will.dea...@arm.com>
> Acked-by: Alan Stern <st...@rowland.harvard.edu>
> Signed-off-by: Paul E. McKenney <paul...@linux.vnet.ibm.com>
> 
> diff --git a/tools/memory-model/MAINTAINERS b/tools/memory-model/MAINTAINERS
> index 711cbe72d606..db3bd3fc0435 100644
> --- a/tools/memory-model/MAINTAINERS
> +++ b/tools/memory-model/MAINTAINERS
> @@ -1,4 +1,4 @@
> -LINUX KERNEL MEMORY MODEL
> +LINUX KERNEL MEMORY CONSISTENCY MODEL
>  M:   Alan Stern <st...@rowland.harvard.edu>
>  M:   Andrea Parri <parri.and...@gmail.com>
>  M:   Will Deacon <will.dea...@arm.com>
> diff --git a/tools/memory-model/README b/tools/memory-model/README
> index 43ba49492111..91414a49fac5 100644
> --- a/tools/memory-model/README
> +++ b/tools/memory-model/README
> @@ -1,15 +1,15 @@
> - =
> - LINUX KERNEL MEMORY MODEL
> - =
> + =
> + LINUX KERNEL MEMORY CONSISTENCY MODEL
> + =
>  
>  
>  INTRODUCTION
>  
>  
> -This directory contains the memory model of the Linux kernel, written
> -in the "cat" language and executable by the (externally provided)
> -"herd7" simulator, which exhaustively explores the state space of
> -small litmus tests.
> +This directory contains the memory consistency model (memory model, for
> +short) of the Linux kernel, written in the "cat" language and executable
> +by the externally provided "herd7" simulator, which exhaustively e

Re: [PATCH 2/2] MAINTAINERS: list file memory-barriers.txt within the LKMM entry

[Andrea Parri]

On Fri, Feb 02, 2018 at 03:51:02PM -0800, Paul E. McKenney wrote:
> On Fri, Feb 02, 2018 at 10:13:42AM +0100, Andrea Parri wrote:
> > Now that a formal specification of the LKMM has become available to
> > the developer, some concern about how to track changes to the model
> > on the level of the "high-level documentation" was raised.
> > 
> > A first "mitigation" to this issue, suggested by Will, is to assign
> > maintainership (and responsibility!!)  of such documentation (here,
> > memory-barriers.txt) to the maintainers of the LKMM themselves.
> > 
> > Suggested-by: Will Deacon <will.dea...@arm.com>
> > Signed-off-by: Andrea Parri <parri.and...@gmail.com>
> 
> Very good, thank you, queued!  Please see below for the usual commit-log
> rework.  BTW, in future submissions, could you please capitalize the
> first word after the colon (":") in the subject line?  It is all too
> easy for me to forget to change this, as Ingo can attest.  ;-)

Sorry, I'll do my best! ;-)


> 
> If we are going to continue to use the LKMM acronym, should we make the
> first line of the MAINTAINERS block look something like this?

I've no strong opinion about whether we should, but it makes sense to me.
(The acronym is currently defined (and heavily used) in explanation.txt.)

Thanks,
  Andrea


> 
>   LINUX KERNEL MEMORY CONSISTENCY MODEL (LKMM)
> 
> One alternative would be to start calling it LKMCM, though that does
> look a bit like a Roman numeral.  ;-)
> 
>   Thanx, Paul
> 
> 
> 
> commit 2f80571625dc2d1977acdef79267ba1645b07c53
> Author: Andrea Parri <parri.and...@gmail.com>
> Date:   Fri Feb 2 10:13:42 2018 +0100
> 
> MAINTAINERS: List file memory-barriers.txt within the LKMM entry
> 
> We now have a shiny new Linux-kernel memory model (LKMM) and the old
> tried-and-true Documentation/memory-barrier.txt.  It would be good to
> keep these automatically synchronized, but in the meantime we need at
> least let people know that they are related.  Will suggested adding the
> Documentation/memory-barrier.txt file to the LKMM maintainership list,
> thus making the LKMM maintainers responsible for both the old and the new.
> This commit follows Will's excellent suggestion.
> 
> Suggested-by: Will Deacon <will.dea...@arm.com>
> Signed-off-by: Andrea Parri <parri.and...@gmail.com>
> Signed-off-by: Paul E. McKenney <paul...@linux.vnet.ibm.com>
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ba4dc08fbe95..e6ad9b44e8fb 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8101,6 +8101,7 @@ L:  linux-kernel@vger.kernel.org
>  S:   Supported
>  T:   git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
>  F:   tools/memory-model/
> +F:   Documentation/memory-barriers.txt
>  
>  LINUX SECURITY MODULE (LSM) FRAMEWORK
>  M:   Chris Wright <chr...@sous-sol.org>
> 

Re: [PATCH 2/2] MAINTAINERS: add the Memory Consistency Model subsystem

[Andrea Parri]

On Thu, Feb 01, 2018 at 01:44:01PM +, Will Deacon wrote:
> On Thu, Feb 01, 2018 at 01:04:26PM +0100, Andrea Parri wrote:
> > Integrate (and then remove) tools/memory-model/MAINTAINERS into the
> > main MAINTAINERS file. This way get_maintainer.pl can give a "right
> > answer" for tools/memory-model/.
> > 
> > Suggested-by: Ingo Molnar <mi...@kernel.org>
> > Signed-off-by: Andrea Parri <parri.and...@gmail.com>
> > ---
> >  MAINTAINERS| 16 
> >  tools/memory-model/MAINTAINERS | 15 ---
> >  2 files changed, 16 insertions(+), 15 deletions(-)
> >  delete mode 100644 tools/memory-model/MAINTAINERS
> 
> Acked-by: Will Deacon <will.dea...@arm.com>
> 
> Makes a lot more sense having this in the top-level MAINTAINERS file.
> It might also make sense to add:
> 
>   F:  Documentation/memory-barriers.txt
> 
> as a separate patch now that we have a hit-list of memory model people
> who can help poor old Jon (who currently gets blamed by get_maintainer.pl).

This does make sense to me: I'll prepare/send such a patch tomorrow.

  Andrea


> 
> Will

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

[Andrea Parri]

On Thu, Feb 01, 2018 at 03:09:41PM -0800, Paul E. McKenney wrote:
> On Thu, Feb 01, 2018 at 10:26:50AM -0500, Alan Stern wrote:
> > On Thu, 1 Feb 2018, Andrea Parri wrote:
> > 
> > > Ingo pointed out that:
> > > 
> > >   "The "memory model" name is overly generic, ambiguous and somewhat
> > >misleading, as we usually mean the virtual memory layout/model
> > >when we say "memory model". GCC too uses it in that sense [...]"
> > > 
> > > Make it clearer that, in the context of tools/memory-model/, the term
> > > "memory-model" is used as shorthand for "memory consistency model" by
> > > calling out this convention in tools/memory-model/README.
> > > 
> > > Stick to the full 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>
> 
> Thank you all -- I have queued this and pushed it to my RCU tree on
> branch lkmm.  I did reword the commit log a bit, please see below and
> please let me know if any of my rewordings need halp.
> 
> Andrea, when you resend your second patch, could you please add Alan's
> Acked-by?

You mean in order to integrate Will's suggestion? I was planning to send
that as a separate patch, as suggested by Will: the patch is on its way,
IAC, please let me know if you'd prefer a V2 merging the two changes.

  Andrea


> 
>   Thanx, Paul
> 
> 
> 
> commit de175b697f71b8e3e6d980b7186b909fee0c4378
> Author: Andrea Parri <parri.and...@gmail.com>
> Date:   Thu Feb 1 13:03:29 2018 +0100
> 
> tools/memory-model: Clarify the origin/scope of the tool name
> 
> Ingo pointed out that:
> 
>   "The "memory model" name is overly generic, ambiguous and somewhat
>misleading, as we usually mean the virtual memory layout/model
>when we say "memory model". GCC too uses it in that sense [...]"
> 
> Make it clearer that tools/memory-model/ uses the term "memory model"
> is used as shorthand for "memory consistency model" by calling out this
> convention in tools/memory-model/README.
> 
> Stick to the original "memory model" term in sources' headers and for
> the subsystem name.
> 
> Suggested-by: Ingo Molnar <mi...@kernel.org>
> Signed-off-by: Andrea Parri <parri.and...@gmail.com>
> Acked-by: Will Deacon <will.dea...@arm.com>
> Acked-by: Alan Stern <st...@rowland.harvard.edu>
> Signed-off-by: Paul E. McKenney <paul...@linux.vnet.ibm.com>
> 
> diff --git a/tools/memory-model/MAINTAINERS b/tools/memory-model/MAINTAINERS
> index 711cbe72d606..db3bd3fc0435 100644
> --- a/tools/memory-model/MAINTAINERS
> +++ b/tools/memory-model/MAINTAINERS
> @@ -1,4 +1,4 @@
> -LINUX KERNEL MEMORY MODEL
> +LINUX KERNEL MEMORY CONSISTENCY MODEL
>  M:   Alan Stern <st...@rowland.harvard.edu>
>  M:   Andrea Parri <parri.and...@gmail.com>
>  M:   Will Deacon <will.dea...@arm.com>
> diff --git a/tools/memory-model/README b/tools/memory-model/README
> index 43ba49492111..91414a49fac5 100644
> --- a/tools/memory-model/README
> +++ b/tools/memory-model/README
> @@ -1,15 +1,15 @@
> - =
> - LINUX KERNEL MEMORY MODEL
> - =
> + =
> + LINUX KERNEL MEMORY CONSISTENCY MODEL
> + =
>  
>  
>  INTRODUCTION
>  
>  
> -This directory contains the memory model of the Linux kernel, written
> -in the "cat" language and executable by the (externally provided)
> -"herd7" simulator, which exhaustively explores the state space of
> -small litmus tests.
> +This directory contains the memory consistency model (memory model, for
> +short) of the Linux kernel, written in the "cat" language and executable
> +by the externally provided "herd7" simulator, which exhaustively explores
> +the state space of small litmus tests.
>  
>  In addition, the "klitmus7" tool (also externally provided) may be used
>  to convert a litmus test to a Linux kernel module, which in turn allows
> diff --git a/tools/memory-m

[PATCH 1/2] Documentation/memory-barriers.txt: cross-reference "tools/memory-model/"

[Andrea Parri]

Recent efforts led to the specification of a memory consistency model
for the Linux kernel [1], which "can (roughly speaking) be thought of
as an automated version of memory-barriers.txt" and which is (in turn)
"accompanied by extensive documentation on its use and its design".

Make sure that the (occasional) reader of memory-barriers.txt will be
aware of these developments.

[1] https://marc.info/?l=linux-kernel=151687290114799=2

Signed-off-by: Andrea Parri <parri.and...@gmail.com>
---
 Documentation/memory-barriers.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/memory-barriers.txt 
b/Documentation/memory-barriers.txt
index a863009849a3b..8cc3f098f4a7d 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -17,7 +17,9 @@ meant as a guide to using the various memory barriers 
provided by Linux, but
 in case of any doubt (and there are many) please ask.
 
 To repeat, this document is not a specification of what Linux expects from
-hardware.
+hardware.  For such a specification, in the form of a memory consistency
+model, and for documentation about its usage and its design, the reader is
+referred to "tools/memory-model/".
 
 The purpose of this document is twofold:
 
-- 
2.7.4

[PATCH 2/2] MAINTAINERS: list file memory-barriers.txt within the LKMM entry

[Andrea Parri]

Now that a formal specification of the LKMM has become available to
the developer, some concern about how to track changes to the model
on the level of the "high-level documentation" was raised.

A first "mitigation" to this issue, suggested by Will, is to assign
maintainership (and responsibility!!)  of such documentation (here,
memory-barriers.txt) to the maintainers of the LKMM themselves.

Suggested-by: Will Deacon <will.dea...@arm.com>
Signed-off-by: Andrea Parri <parri.and...@gmail.com>
---
 On top of: https://marc.info/?l=linux-kernel=151748668632046=2 

 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 08454be9237d7..9466907aa4db1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8106,6 +8106,7 @@ L:linux-kernel@vger.kernel.org
 S: Supported
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
 F: tools/memory-model/
+F: Documentation/memory-barriers.txt
 
 LINUX SECURITY MODULE (LSM) FRAMEWORK
 M: Chris Wright <chr...@sous-sol.org>
-- 
2.7.4

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

[Andrea Parri]

On Thu, Feb 01, 2018 at 03:09:41PM -0800, Paul E. McKenney wrote:
> On Thu, Feb 01, 2018 at 10:26:50AM -0500, Alan Stern wrote:
> > On Thu, 1 Feb 2018, Andrea Parri wrote:
> > 
> > > Ingo pointed out that:
> > > 
> > >   "The "memory model" name is overly generic, ambiguous and somewhat
> > >misleading, as we usually mean the virtual memory layout/model
> > >when we say "memory model". GCC too uses it in that sense [...]"
> > > 
> > > Make it clearer that, in the context of tools/memory-model/, the term
> > > "memory-model" is used as shorthand for "memory consistency model" by
> > > calling out this convention in tools/memory-model/README.
> > > 
> > > Stick to the full 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>
> 
> Thank you all -- I have queued this and pushed it to my RCU tree on
> branch lkmm.  I did reword the commit log a bit, please see below and
> please let me know if any of my rewordings need halp.

Seems to me that your message has a leftover "is used".

  Andrea


> 
> Andrea, when you resend your second patch, could you please add Alan's
> Acked-by?
> 
>   Thanx, Paul
> 
> 
> 
> commit de175b697f71b8e3e6d980b7186b909fee0c4378
> Author: Andrea Parri <parri.and...@gmail.com>
> Date:   Thu Feb 1 13:03:29 2018 +0100
> 
> tools/memory-model: Clarify the origin/scope of the tool name
> 
> Ingo pointed out that:
> 
>   "The "memory model" name is overly generic, ambiguous and somewhat
>misleading, as we usually mean the virtual memory layout/model
>when we say "memory model". GCC too uses it in that sense [...]"
> 
> Make it clearer that tools/memory-model/ uses the term "memory model"
> is used as shorthand for "memory consistency model" by calling out this
> convention in tools/memory-model/README.
> 
> Stick to the original "memory model" term in sources' headers and for
> the subsystem name.
> 
> Suggested-by: Ingo Molnar <mi...@kernel.org>
> Signed-off-by: Andrea Parri <parri.and...@gmail.com>
> Acked-by: Will Deacon <will.dea...@arm.com>
> Acked-by: Alan Stern <st...@rowland.harvard.edu>
> Signed-off-by: Paul E. McKenney <paul...@linux.vnet.ibm.com>
> 
> diff --git a/tools/memory-model/MAINTAINERS b/tools/memory-model/MAINTAINERS
> index 711cbe72d606..db3bd3fc0435 100644
> --- a/tools/memory-model/MAINTAINERS
> +++ b/tools/memory-model/MAINTAINERS
> @@ -1,4 +1,4 @@
> -LINUX KERNEL MEMORY MODEL
> +LINUX KERNEL MEMORY CONSISTENCY MODEL
>  M:   Alan Stern <st...@rowland.harvard.edu>
>  M:   Andrea Parri <parri.and...@gmail.com>
>  M:   Will Deacon <will.dea...@arm.com>
> diff --git a/tools/memory-model/README b/tools/memory-model/README
> index 43ba49492111..91414a49fac5 100644
> --- a/tools/memory-model/README
> +++ b/tools/memory-model/README
> @@ -1,15 +1,15 @@
> - =
> - LINUX KERNEL MEMORY MODEL
> - =
> + =
> + LINUX KERNEL MEMORY CONSISTENCY MODEL
> + =
>  
>  
>  INTRODUCTION
>  
>  
> -This directory contains the memory model of the Linux kernel, written
> -in the "cat" language and executable by the (externally provided)
> -"herd7" simulator, which exhaustively explores the state space of
> -small litmus tests.
> +This directory contains the memory consistency model (memory model, for
> +short) of the Linux kernel, written in the "cat" language and executable
> +by the externally provided "herd7" simulator, which exhaustively explores
> +the state space of small litmus tests.
>  
>  In addition, the "klitmus7" tool (also externally provided) may be used
>  to convert a litmus test to a Linux kernel module, which in turn allows
> diff --git a/tools/memory-model/linux-kernel.bell 
> b/tools/memory-model/linux-kernel.bell
> index 57112505f5e0..b984bbda01a5 100644
> --- a/tools/memory-model/linux-kern

Re: [GIT PULL tools] Linux kernel memory model

[Andrea Parri]

On Sun, Feb 04, 2018 at 02:17:00AM -0800, Paul E. McKenney wrote:

[...]

> And here is the updated commit adding comments to the litmus test,
> which adds comments for the three litmus tests added above.  I have also
> marked this commit with "EXP" indicating that it has not yet had time
> for review.  This marking appears only on my commits -- others' commits
> don't get pulled until there has been time for review.  (I have to put
> my commits somewhere, and maintaining two different branches would be
> a real mess given the likelihood of depeendencies among comits.)
> 
>   Thanx, Paul
> 
> 
> 
> commit 49af6e403afab890a54518980d345431d74234a4
> Author: Paul E. McKenney 
> Date:   Sat Feb 3 00:04:49 2018 -0800
> 
> EXP litmus_tests:  Add comments explaining tests' purposes
> 
> 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 
> 
> diff --git a/tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus 
> b/tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus
> index 5b83d57f6ac5..8e8ae8989085 100644
> --- a/tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus
> +++ b/tools/memory-model/litmus-tests/CoRR+poonceonce+Once.litmus
> @@ -1,5 +1,11 @@
>  C CoRR+poonceonce+Once
>  
> +(*
> + * Test of read-read coherence, that is, whether or not two successive
> + * reads from the same variable are ordered.  They should be ordered,
> + * that is, this test should be forbidden.
> + *)
> +
>  {}
>  
>  P0(int *x)
> diff --git a/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus 
> b/tools/memory-model/litmus-tests/CoRW+poonceonce+Once.litmus
> index fab91c13d52c..0078ecd76f5e 100644
> --- 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 read from a
> + * given variable followed by a write to that same variable are ordered.
> + * This should be ordered, that is, this test should be forbidden.
> + *)
> +
>  {}
>  
>  P0(int *x)
> diff --git a/tools/memory-model/litmus-tests/CoWR+poonceonce+Once.litmus 
> b/tools/memory-model/litmus-tests/CoWR+poonceonce+Once.litmus
> index 6a35ec2042ea..c9d342c8fbec 100644
> --- a/tools/memory-model/litmus-tests/CoWR+poonceonce+Once.litmus
> +++ b/tools/memory-model/litmus-tests/CoWR+poonceonce+Once.litmus
> @@ -1,5 +1,11 @@
>  C CoWR+poonceonce+Once
>  
> +(*
> + * Test of write-read coherence, that is, whether or not a write to a
> + * given variable followed by a read from that same variable are ordered.
> + * They should be ordered, that is, this test should be forbidden.
> + *)
> +
>  {}
>  
>  P0(int *x)
> diff --git a/tools/memory-model/litmus-tests/CoWW+poonceonce.litmus 
> b/tools/memory-model/litmus-tests/CoWW+poonceonce.litmus
> index 32a96b832021..ad51c7b17f7b 100644
> --- a/tools/memory-model/litmus-tests/CoWW+poonceonce.litmus
> +++ b/tools/memory-model/litmus-tests/CoWW+poonceonce.litmus
> @@ -1,5 +1,11 @@
>  C CoWW+poonceonce
>  
> +(*
> + * Test of write-write coherence, that is, whether or not two successive
> + * writes to the same variable are ordered.  They should be ordered, that
> + * is, this test should be forbidden.
> + *)
> +
>  {}
>  
>  P0(int *x)
> diff --git a/tools/memory-model/litmus-tests/IRIW+mbonceonces+OnceOnce.litmus 
> b/tools/memory-model/litmus-tests/IRIW+mbonceonces+OnceOnce.litmus
> index 7eba2c68992b..8a58abce69fe 100644
> --- a/tools/memory-model/litmus-tests/IRIW+mbonceonces+OnceOnce.litmus
> +++ b/tools/memory-model/litmus-tests/IRIW+mbonceonces+OnceOnce.litmus
> @@ -1,5 +1,14 @@
>  C IRIW+mbonceonces+OnceOnce
>  
> +(*
> + * Test of independent reads from independent writes with smp_mb()
> + * between each pairs of reads.  In other words, is smp_mb() sufficient to
> + * cause two different reading processes to agree on the order of a pair
> + * of writes, where each write is to a different variable by a different
> + * process?  The smp_mb()s should be sufficient, that is, this test should
> + * be forbidden.
> + *)
> +
>  {}
>  
>  P0(int *x)
> diff --git a/tools/memory-model/litmus-tests/IRIW+poonceonces+OnceOnce.litmus 
> b/tools/memory-model/litmus-tests/IRIW+poonceonces+OnceOnce.litmus
> index b0556c6c75d4..c736cd372207 100644
> --- a/tools/memory-model/litmus-tests/IRIW+poonceonces+OnceOnce.litmus
> +++ b/tools/memory-model/litmus-tests/IRIW+poonceonces+OnceOnce.litmus
> @@ -1,5 +1,14 @@
>  C IRIW+poonceonces+OnceOnce
>  
> +(*
> + * Test of independent reads from independent writes with nothing
> + * between each pairs of reads.  In other words, is anything at all
> 

Re: [PATCH 1/2] Documentation/memory-barriers.txt: cross-reference "tools/memory-model/"

[Andrea Parri]

Hi Akira,

On Mon, Feb 05, 2018 at 01:14:10AM +0900, Akira Yokosawa wrote:
> Hi Paul,
> CC: Andrea
> 
> This is intentionally off the list, as I was not cc'd in the thread.
> If you think it is worthwhile, could you help me join the thread by
> forwarding the following part as a reply to your message, plus CC: to me.

[CCing lists and other people]


> 
> On Fri, Feb 02, 2018 at 17:21:03AM -0800, Paul E. McKenney wrote:
> > On Fri, Feb 02, 2018 at 10:12:48AM +0100, Andrea Parri wrote:
> >> Recent efforts led to the specification of a memory consistency model
> >> for the Linux kernel [1], which "can (roughly speaking) be thought of
> >> as an automated version of memory-barriers.txt" and which is (in turn)
> >> "accompanied by extensive documentation on its use and its design".
> >> 
> >> Make sure that the (occasional) reader of memory-barriers.txt will be
> >> aware of these developments.
> >> 
> >> [1] https://marc.info/?l=linux-kernel=151687290114799=2
> >> 
> >> Signed-off-by: Andrea Parri <parri.andrea@x>
> > 
> > I am inclined to pull in something along these lines, but would like
> > some feedback on the wording, especially how "official" we want to
> > make the memory model to be.
> > 
> > Thoughts?
> 
> The change log of commit e7720af5f9ac ("locking/Documentation: Add 
> disclaimer") says:
> 
> It appears people are reading this document as a requirements list for
> building hardware. This is not the intent of this document. Nor is it
> particularly suited for this purpose.
> 
> The primary purpose of this document is our collective attempt to define
> a set of primitives that (hopefully) allow us to write correct code on
> the myriad of SMP platforms Linux supports.
> 
> Its a definite work in progress as our understanding of these platforms,
> and memory ordering in general, progresses.
> 
> Nor does being mentioned in this document mean we think its a
> particularly good idea; the data dependency barrier required by Alpha
> being a prime example. Yes we have it, no you're insane to require it
> when building new hardware.
> 
> My take on the Linux Kernel memory-consistency model is a supplement of
> memory-barriers.txt and the disclaimer also applies to the memory model.
> 
> > 
> > If I don't hear otherwise in a couple of days, I will pull this as is.
> > 
> > Thanx, Paul
> > 
> >> ---
> >>  Documentation/memory-barriers.txt | 4 +++-
> >>  1 file changed, 3 insertions(+), 1 deletion(-)
> >> 
> >> diff --git a/Documentation/memory-barriers.txt 
> >> b/Documentation/memory-barriers.txt
> >> index a863009849a3b..8cc3f098f4a7d 100644
> >> --- a/Documentation/memory-barriers.txt
> >> +++ b/Documentation/memory-barriers.txt
> >> @@ -17,7 +17,9 @@ meant as a guide to using the various memory barriers 
> >> provided by Linux, but
> >>  in case of any doubt (and there are many) please ask.
> >> 
> >>  To repeat, this document is not a specification of what Linux expects from
> >> -hardware.
> >> +hardware.  For such a specification, in the form of a memory consistency
> >> +model, and for documentation about its usage and its design, the reader is
> >> +referred to "tools/memory-model/".
> >> 
> 
> Adding cross-reference in this way can _weaken_ the message of the disclaimer.

Thank you for your remarks; I do share the same concern.


> What about adding it in the previous sentence as the patch appended bellow?

I do like this idea: I believe that my phrasing (and that "what Linux
expects from hardware") may be easily subject to misinterpretation...
which your solution can avoid.

  Andrea


> 
> The tag use in the change log may need adjustments. I'm not familiar with the
> manner in modifying other persons' patches. Of course, the wording itself can
> be improved further.  Any feedback is welcome.
> 
>  Thanks, Akira
> 
> >>  The purpose of this document is twofold:
> >> 
> >> -- 
> >> 2.7.4
> >> 
> 
> 8<---
> From 714e8c4b09acd6e965de116532dce05070b9e636 Mon Sep 17 00:00:00 2001
> From: Akira Yokosawa <aki...@gmail.com>
> Date: Mon, 5 Feb 2018 00:28:36 +0900
> Subject: [PATCH] Documentation/memory-barriers.txt: cross-reference 
> "tools/memory-model/"
> 
> Recent efforts led to the specification of a memory consistency model
> for the Linux kernel [

Re: [PATCH v2 1/3] sched: Stop nohz stats when decayed

[Andrea Parri]

On Thu, Feb 08, 2018 at 04:03:41PM +, Will Deacon wrote:
> On Thu, Feb 08, 2018 at 04:46:43PM +0100, Peter Zijlstra wrote:
> > On Thu, Feb 08, 2018 at 03:30:31PM +, Will Deacon wrote:
> > > On Thu, Feb 08, 2018 at 03:00:05PM +0100, Peter Zijlstra wrote:
> > 
> > > > Without this ordering I think it would be possible to loose has_blocked
> > > > and not observe the CPU either.
> > > 
> > > I had a quick look at this, and I think you're right. This looks very much
> > > like an 'R'-shaped test, which means it's smp_mb() all round otherwise 
> > > Power
> > > will go wrong. That also means the smp_mb__after_atomic() in
> > > nohz_balance_enter_idle *cannot* be an smp_wmb(), so you might want a
> > > comment stating that explicitly.
> > 
> > Thanks Will. BTW, where does that 'R' shape nomenclature come from?
> > This is the first I've heard of it.
> 
> I don't know where it originates from, but the imfamous "test6.pdf" has it:
> 
> https://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test6.pdf
> 
> half way down the first page on the left. It says "needs sync+sync" which

Indeed.  As a curiosity: I've never _observed_ R+lwsync+sync (the lwsync
separating the two writes), and other people who tried found the same

  http://moscova.inria.fr/~maranget/cats7/linux/hard.html#unseen
  http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/ppc051.html#toc8 .

It would be interesting to hear about different results ... ;-)

  Andrea


> is about as bad as it gets for Power (compare with "2+2w", which gets away
> with lwsync+lwsync). See also:
> 
> http://materials.dagstuhl.de/files/16/16471/16471.DerekWilliams.Slides.pdf
> 
> for a light-hearted, yet technically accurate story about the latter.
> 
> Will

Re: [PATCH 1/2] Documentation/memory-barriers.txt: cross-reference "tools/memory-model/"

[Andrea Parri]

On Fri, Feb 09, 2018 at 06:29:23AM -0800, Paul E. McKenney wrote:
> On Fri, Feb 09, 2018 at 01:50:51PM +0100, Andrea Parri wrote:
> > On Fri, Feb 09, 2018 at 04:31:00AM -0800, Paul E. McKenney wrote:
> > > On Sun, Feb 04, 2018 at 07:37:08PM +0100, Andrea Parri wrote:
> > > > Hi Akira,
> > > > 
> > > > On Mon, Feb 05, 2018 at 01:14:10AM +0900, Akira Yokosawa wrote:
> > > > > Hi Paul,
> > > > > CC: Andrea
> > > > > 
> > > > > This is intentionally off the list, as I was not cc'd in the thread.
> > > > > If you think it is worthwhile, could you help me join the thread by
> > > > > forwarding the following part as a reply to your message, plus CC: to 
> > > > > me.
> > > > 
> > > > [CCing lists and other people]
> > > > 
> > > > 
> > > > > 
> > > > > On Fri, Feb 02, 2018 at 17:21:03AM -0800, Paul E. McKenney wrote:
> > > > > > On Fri, Feb 02, 2018 at 10:12:48AM +0100, Andrea Parri wrote:
> > > > > >> Recent efforts led to the specification of a memory consistency 
> > > > > >> model
> > > > > >> for the Linux kernel [1], which "can (roughly speaking) be thought 
> > > > > >> of
> > > > > >> as an automated version of memory-barriers.txt" and which is (in 
> > > > > >> turn)
> > > > > >> "accompanied by extensive documentation on its use and its design".
> > > > > >> 
> > > > > >> Make sure that the (occasional) reader of memory-barriers.txt will 
> > > > > >> be
> > > > > >> aware of these developments.
> > > > > >> 
> > > > > >> [1] https://marc.info/?l=linux-kernel=151687290114799=2
> > > > > >> 
> > > > > >> Signed-off-by: Andrea Parri <parri.andrea@x>
> > > > > > 
> > > > > > I am inclined to pull in something along these lines, but would like
> > > > > > some feedback on the wording, especially how "official" we want to
> > > > > > make the memory model to be.
> > > > > > 
> > > > > > Thoughts?
> > > > > 
> > > > > The change log of commit e7720af5f9ac ("locking/Documentation: Add 
> > > > > disclaimer") says:
> > > > > 
> > > > > It appears people are reading this document as a requirements 
> > > > > list for
> > > > > building hardware. This is not the intent of this document. Nor 
> > > > > is it
> > > > > particularly suited for this purpose.
> > > > > 
> > > > > The primary purpose of this document is our collective attempt to 
> > > > > define
> > > > > a set of primitives that (hopefully) allow us to write correct 
> > > > > code on
> > > > > the myriad of SMP platforms Linux supports.
> > > > > 
> > > > > Its a definite work in progress as our understanding of these 
> > > > > platforms,
> > > > > and memory ordering in general, progresses.
> > > > > 
> > > > > Nor does being mentioned in this document mean we think its a
> > > > > particularly good idea; the data dependency barrier required by 
> > > > > Alpha
> > > > > being a prime example. Yes we have it, no you're insane to 
> > > > > require it
> > > > > when building new hardware.
> > > > > 
> > > > > My take on the Linux Kernel memory-consistency model is a supplement 
> > > > > of
> > > > > memory-barriers.txt and the disclaimer also applies to the memory 
> > > > > model.
> > > > > 
> > > > > > 
> > > > > > If I don't hear otherwise in a couple of days, I will pull this as 
> > > > > > is.
> > > > > > 
> > > > > > Thanx, Paul
> > > > > > 
> > > > > >> ---
> > > > > >>  Documentation/memory-barriers.txt | 4 +++-
> > > > > >>  1 file changed, 3 insertions(+), 1 deletion(-)
> > > > > >> 
> > > > > >> diff --git

Re: [GIT PULL tools] Linux kernel memory model

[Andrea Parri]

On Fri, Feb 09, 2018 at 03:29:37AM -0800, Paul E. McKenney wrote:
> On Fri, Feb 09, 2018 at 10:11:10AM +0100, Andrea Parri wrote:
> > On Thu, Feb 08, 2018 at 09:02:19PM +0100, Peter Zijlstra wrote:
> > > On Thu, Feb 08, 2018 at 06:41:06PM +, Patrick Bellasi wrote:
> > > > Hi Paul,
> > > > thanks to you and all the involved guys for this useful tool.
> > > > 
> > > > I give it a try today and found that by installing herd7 by just
> > > > following the instruction in herdtools7/INSTALL.md, and precisely
> > > > installing it via:
> > > > 
> > > >opam install herdtools7
> > > > 
> > > > it seems to give you a tool which fails to run the basic example in
> > > > your README with this error:
> > > > 
> > > >File "./linux-kernel.def", line 44, characters 29-30: unexpected '-' 
> > > > (in macros)
> > > > 
> > > > As suggested by Will, by building instead herd7 HEAD (commit 44d69c2)
> > > > everything works fine.
> > > > 
> > > > Maybe it's a know issue, in case just ignore me. :)
> > > > 
> > > > Otherwise, maybe it can be worth to add to the README a note on which
> > > > minimum version of the herd7 tool is required.
> > > > 
> > > >  opma   version (not working): 7.47, Rev: exported
> > > >  master version (working for me) : 7.47+7(dev), Rev: 
> > > > 44d69c2b1b5ca0f97bd138899d31532ee5e4e084
> > > 
> > > Urgh. So that's why it wouldn't work.
> > > 
> > > I remember Paul saying you needed the latest version, which is why I
> > > rebuild from opam, but building top of git is a bit much.
> > 
> > +1
> > 
> > _Sadly_ enough, co-developers and I were aware of this issue,
> > but it was only mildly reported here (c.f.,
> > 
> >   https://marc.info/?l=linux-kernel=151638196427685=2 ).
> > 
> > This bisects to that (crazy):
> > 
> >   2d5fba7782d669c6a1cc577dbc3bf507780273bb
> >   ("linux-kernel*: Make RCU identifiers match ASPLOS paper")
> > 
> >   From repo.: https://github.com/aparri/memory-model
> > 
> > which not only did break 7.47, but also made the bell uglier
> > by mixing dashes and underscores in a very same block.
> > 
> > As a solution to this issue, I can envisage a partial revert
> > of that commit (just replace those dashes); Paul, Jade, Luc:
> > any better solution?
> > 
> > (Sorry for being late on IRC, glad this came out here,)
> 
> Or maybe a 7.48 release?

This would work, _prior upgrade. (This's not my call of course).

I do however want to iterate, looking again at the above commit:

'rb_dep (*smp_read_barrier_depends*) ||
-   'rcu_read_lock (*rcu_read_lock*)  ||
-   'rcu_read_unlock (*rcu_read_unlock*) ||
-   'sync (*synchronize_rcu*) ||
+   'rcu-lock (*rcu_read_lock*)  ||
+   'rcu-unlock (*rcu_read_unlock*) ||
+   'sync-rcu (*synchronize_rcu*) ||
'before_atomic (*smp_mb__before_atomic*) ||
'after_atomic (*smp_mb__after_atomic*) ||
'after_spinlock (*smp_mb__after_spinlock*)

The question arises: dash or underscore? This needs to be fixed.

  Andrea


> 
>   Thanx, Paul
> 

Re: [PATCH 1/2] Documentation/memory-barriers.txt: cross-reference "tools/memory-model/"

[Andrea Parri]

On Fri, Feb 09, 2018 at 04:31:00AM -0800, Paul E. McKenney wrote:
> On Sun, Feb 04, 2018 at 07:37:08PM +0100, Andrea Parri wrote:
> > Hi Akira,
> > 
> > On Mon, Feb 05, 2018 at 01:14:10AM +0900, Akira Yokosawa wrote:
> > > Hi Paul,
> > > CC: Andrea
> > > 
> > > This is intentionally off the list, as I was not cc'd in the thread.
> > > If you think it is worthwhile, could you help me join the thread by
> > > forwarding the following part as a reply to your message, plus CC: to me.
> > 
> > [CCing lists and other people]
> > 
> > 
> > > 
> > > On Fri, Feb 02, 2018 at 17:21:03AM -0800, Paul E. McKenney wrote:
> > > > On Fri, Feb 02, 2018 at 10:12:48AM +0100, Andrea Parri wrote:
> > > >> Recent efforts led to the specification of a memory consistency model
> > > >> for the Linux kernel [1], which "can (roughly speaking) be thought of
> > > >> as an automated version of memory-barriers.txt" and which is (in turn)
> > > >> "accompanied by extensive documentation on its use and its design".
> > > >> 
> > > >> Make sure that the (occasional) reader of memory-barriers.txt will be
> > > >> aware of these developments.
> > > >> 
> > > >> [1] https://marc.info/?l=linux-kernel=151687290114799=2
> > > >> 
> > > >> Signed-off-by: Andrea Parri <parri.andrea@x>
> > > > 
> > > > I am inclined to pull in something along these lines, but would like
> > > > some feedback on the wording, especially how "official" we want to
> > > > make the memory model to be.
> > > > 
> > > > Thoughts?
> > > 
> > > The change log of commit e7720af5f9ac ("locking/Documentation: Add 
> > > disclaimer") says:
> > > 
> > > It appears people are reading this document as a requirements list for
> > > building hardware. This is not the intent of this document. Nor is it
> > > particularly suited for this purpose.
> > > 
> > > The primary purpose of this document is our collective attempt to 
> > > define
> > > a set of primitives that (hopefully) allow us to write correct code on
> > > the myriad of SMP platforms Linux supports.
> > > 
> > > Its a definite work in progress as our understanding of these 
> > > platforms,
> > > and memory ordering in general, progresses.
> > > 
> > > Nor does being mentioned in this document mean we think its a
> > > particularly good idea; the data dependency barrier required by Alpha
> > > being a prime example. Yes we have it, no you're insane to require it
> > > when building new hardware.
> > > 
> > > My take on the Linux Kernel memory-consistency model is a supplement of
> > > memory-barriers.txt and the disclaimer also applies to the memory model.
> > > 
> > > > 
> > > > If I don't hear otherwise in a couple of days, I will pull this as is.
> > > > 
> > > > Thanx, Paul
> > > > 
> > > >> ---
> > > >>  Documentation/memory-barriers.txt | 4 +++-
> > > >>  1 file changed, 3 insertions(+), 1 deletion(-)
> > > >> 
> > > >> diff --git a/Documentation/memory-barriers.txt 
> > > >> b/Documentation/memory-barriers.txt
> > > >> index a863009849a3b..8cc3f098f4a7d 100644
> > > >> --- a/Documentation/memory-barriers.txt
> > > >> +++ b/Documentation/memory-barriers.txt
> > > >> @@ -17,7 +17,9 @@ meant as a guide to using the various memory 
> > > >> barriers provided by Linux, but
> > > >>  in case of any doubt (and there are many) please ask.
> > > >> 
> > > >>  To repeat, this document is not a specification of what Linux expects 
> > > >> from
> > > >> -hardware.
> > > >> +hardware.  For such a specification, in the form of a memory 
> > > >> consistency
> > > >> +model, and for documentation about its usage and its design, the 
> > > >> reader is
> > > >> +referred to "tools/memory-model/".
> > > >> 
> > > 
> > > Adding cross-reference in this way can _weaken_ the message of the 
> > > disclaimer.
> > 
> > Thank y