On Thu, Jul 12, 2018 at 11:13:48PM +0200, Andrea Parri wrote:
> On Thu, Jul 12, 2018 at 04:43:46PM -0400, Alan Stern wrote:
> > On Thu, 12 Jul 2018, Andrea Parri wrote:
> >
> > > > It seems reasonable to ask people to learn that locks have stronger
> > > >
On Thu, Jul 12, 2018 at 04:43:46PM -0400, Alan Stern wrote:
> On Thu, 12 Jul 2018, Andrea Parri wrote:
>
> > > It seems reasonable to ask people to learn that locks have stronger
> > > ordering guarantees than RMW atomics do. Maybe not the greatest
> > > situat
On Thu, Jul 12, 2018 at 09:52:42PM +0200, Andrea Parri wrote:
> On Thu, Jul 12, 2018 at 11:10:58AM -0700, Linus Torvalds wrote:
> > On Thu, Jul 12, 2018 at 11:05 AM Peter Zijlstra
> > wrote:
> > >
> > > The locking pattern is fairly simple and shows where RCpc c
On Thu, Jul 12, 2018 at 11:10:58AM -0700, Linus Torvalds wrote:
> On Thu, Jul 12, 2018 at 11:05 AM Peter Zijlstra wrote:
> >
> > The locking pattern is fairly simple and shows where RCpc comes apart
> > from expectation real nice.
>
> So who does RCpc right now for the unlock-lock sequence? Someb
> It seems reasonable to ask people to learn that locks have stronger
> ordering guarantees than RMW atomics do. Maybe not the greatest
> situation in the world, but one I think we could live with.
Yeah, this was one of my main objections.
> > Hence my proposal to strenghten rmw-acquire, becaus
> Anyway, back to the problem of being able to use the memory model to
> describe locks. This is I think a useful property.
>
> My earlier reasoning was that:
>
> - smp_store_release() + smp_load_acquire() := RCpc
>
> - we use smp_store_release() as unlock()
>
> Therefore, if we want unlock
On Thu, Jul 12, 2018 at 01:52:49PM +0200, Andrea Parri wrote:
> On Thu, Jul 12, 2018 at 09:40:40AM +0200, Peter Zijlstra wrote:
> > On Wed, Jul 11, 2018 at 02:34:21PM +0200, Andrea Parri wrote:
> > > Simplicity is the eye of the beholder. From my POV (LKMM maintainer), the
>
On Thu, Jul 12, 2018 at 09:40:40AM +0200, Peter Zijlstra wrote:
> On Wed, Jul 11, 2018 at 02:34:21PM +0200, Andrea Parri wrote:
> > Simplicity is the eye of the beholder. From my POV (LKMM maintainer), the
> > simplest solution would be to get rid of rfi-rel-acq and unlock-rf-lock
> All the discussion here[1] for example is about having ordering and
> doing an smp_cond_load_acquire() on a variable which is sometimes
> protected by a CPU's rq->lock and sometimes not? Isn't that one of the
> key use cases for this whole discussion?
Not a "pure" one:
http://lkml.kernel.or
> It might be simple to model, but I worry this weakens our locking
> implementations to a point where they will not be understood by the average
> kernel developer. As I've said before, I would prefer "full" RCsc locking,
> but that's not the case with architectures we currently support today, so
On Wed, Jul 11, 2018 at 08:42:11AM -0700, Paul E. McKenney wrote:
> On Wed, Jul 11, 2018 at 10:43:45AM +0100, Will Deacon wrote:
> > Hi Alan,
> >
> > On Tue, Jul 10, 2018 at 02:18:13PM -0400, Alan Stern wrote:
> > > More than one kernel developer has expressed the opinion that the LKMM
> > > shoul
On Wed, Jul 11, 2018 at 02:34:21PM +0200, Andrea Parri wrote:
> On Wed, Jul 11, 2018 at 10:43:11AM +0100, Will Deacon wrote:
> > On Tue, Jul 10, 2018 at 11:38:21AM +0200, Andrea Parri wrote:
> > > On Mon, Jul 09, 2018 at 04:01:57PM -0400, Alan Stern wrote:
> > > >
On Wed, Jul 11, 2018 at 10:43:11AM +0100, Will Deacon wrote:
> On Tue, Jul 10, 2018 at 11:38:21AM +0200, Andrea Parri wrote:
> > On Mon, Jul 09, 2018 at 04:01:57PM -0400, Alan Stern wrote:
> > > More than one kernel developer has expressed the opinion that the LKMM
> > >
On Tue, Jul 10, 2018 at 01:17:50PM -0400, Alan Stern wrote:
> On Tue, 10 Jul 2018, Daniel Lustig wrote:
>
> > > --- usb-4.x.orig/tools/memory-model/linux-kernel.cat
> > > +++ usb-4.x/tools/memory-model/linux-kernel.cat
> > > @@ -38,7 +38,7 @@ let strong-fence = mb | gp
> > > (* Release Acquire *)
On Tue, Jul 10, 2018 at 11:34:45AM -0400, Alan Stern wrote:
> On Tue, 10 Jul 2018, Andrea Parri wrote:
>
> > > > ACQUIRE operations include LOCK operations and both smp_load_acquire()
> > > > and smp_cond_acquire() operations. [BTW, the latter was replaced by
&
> > ACQUIRE operations include LOCK operations and both smp_load_acquire()
> > and smp_cond_acquire() operations. [BTW, the latter was replaced by
> > smp_cond_load_acquire() in 1f03e8d2919270 ...]
> >
> > RELEASE operations include UNLOCK operations and smp_store_release()
> > operatio
Amend commit 1f03e8d2919270 ("locking/barriers: Replace smp_cond_acquire()
with smp_cond_load_acquire()") by updating the documentation accordingly.
Signed-off-by: Andrea Parri
Cc: Alan Stern
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Boqun Feng
Cc: Nicholas Piggin
Cc: David Howells
On Mon, Jul 09, 2018 at 04:01:57PM -0400, Alan Stern wrote:
> More than one kernel developer has expressed the opinion that the LKMM
> should enforce ordering of writes by locking. In other words, given
I'd like to step back on this point: I still don't have a strong opinion
on this, but all this
On Sat, Jul 07, 2018 at 04:08:47PM +0800, Guo Ren wrote:
> On Fri, Jul 06, 2018 at 02:17:16PM +0200, Peter Zijlstra wrote:
> CPU0CPU1
>
> WRITE_ONCE(x, 1)WRITE_ONCE(y, 1)
> r0 = xchg(&y, 2)r1 = xchg(&x, 2)
>
> must not allow: r0==0 && r1==0
>
Hi Guo,
On Sat, Jul 07, 2018 at 03:42:10PM +0800, Guo Ren wrote:
> On Fri, Jul 06, 2018 at 01:56:14PM +0200, Peter Zijlstra wrote:
> > CPU0CPU1
> >
> > r1 = READ_ONCE(x); WRITE_ONCE(y, 1);
> > r2 = xchg(&y, 2); smp_store_release(&x, 1);
> >
> > must not
On Thu, Jul 05, 2018 at 08:38:36PM +0200, Andrea Parri wrote:
> > No, I'm definitely not pushing for anything stronger. I'm still just
> > wondering if the name "RCsc" is right for what you described. For
> > example, Andrea just said this in a paralle
> No, I'm definitely not pushing for anything stronger. I'm still just
> wondering if the name "RCsc" is right for what you described. For
> example, Andrea just said this in a parallel email:
>
> > "RCsc" as ordering everything except for W -> R, without the [extra]
> > barriers
And I already
On Thu, Jul 05, 2018 at 09:58:48AM -0700, Paul E. McKenney wrote:
> On Thu, Jul 05, 2018 at 05:39:06PM +0200, Andrea Parri wrote:
> > > > At any rate, it looks like instead of strengthening the relation, I
> > > > should write a patch that removes it ent
> > At any rate, it looks like instead of strengthening the relation, I
> > should write a patch that removes it entirely. I also will add new,
> > stronger relations for use with locking, essentially making spin_lock
> > and spin_unlock be RCsc.
>
> Only in the presence of smp_mb__after_unlock_l
> At any rate, it looks like instead of strengthening the relation, I
> should write a patch that removes it entirely. I also will add new,
> stronger relations for use with locking, essentially making spin_lock
> and spin_unlock be RCsc.
Thank you.
Ah let me put this forward: please keep an eye
On Wed, Jul 04, 2018 at 01:11:04PM +0100, Will Deacon wrote:
> Hi Alan,
>
> On Tue, Jul 03, 2018 at 01:28:17PM -0400, Alan Stern wrote:
> > On Mon, 25 Jun 2018, Andrea Parri wrote:
> >
> > > On Fri, Jun 22, 2018 at 07:30:08PM +0100, Will Deacon wrote:
> > >
Paul E. McKenney
> Cc: Alan Stern
> Cc: Andrea Parri
> Cc: Will Deacon
> Cc: Peter Zijlstra
> Cc: Boqun Feng
> Cc: Nicholas Piggin
> Cc: David Howells
> Cc: Jade Alglave
> Cc: Luc Maranget
> Cc: Akira Yokosawa
> C
On Tue, Jul 03, 2018 at 08:39:10AM -0700, Paul E. McKenney wrote:
[...]
> > + * smp_mb__after_spinlock() provides the equivalent of a full memory
> > barrier
> > + * between program-order earlier lock acquisitions and program-order later
>
> Not just the earlier lock acquisition, but also all p
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);
> > 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: D
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 th
> 1bc179880fba docs: atomic_ops: Describe atomic_set as a write operation
>
> The above patches need at least one additional Acked-by
> or Reviewed-by. If any of you gets a chance, please do
> look them over.
Glad this came out. ;-)
No objection to the patch: feel free to add
th the contemporary codebase.
>
> Thanks,
> Mark.
>
> Mark Rutland (2):
> tools/memory-model: remove ACCESS_ONCE() from recipes
> tools/memory-model: remove ACCESS_ONCE() from model
For the series:
Acked-by: Andrea Parri
Cheers,
Andrea
>
> tools/memory-mode
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 fo
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 lo
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
y 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
> >
> > > I also just realised that this prevents Power from using ctrl+isync to
> > > implement acquire, should they wish to do so.
> >
> > They in fact do so on chips lacking LWSYNC, see how PPC_ACQUIRE_BARRIER
> > (as used by atomic_*_acquire) turns into ISYNC (note however that they
> > do not use
by the Linux kernel (including RISC-V)
> do behave this way, albeit for varying reasons. Therefore this patch
> changes the model in accordance with the developers' wishes.
>
> Signed-off-by: Alan Stern
This patch changes the "Result" for ISA2+pooncelock+poonce
e, the new rule will still
> provide ordering. In the fr case, we also have ordering because there
> must be a co link to the same destination starting from the
> write-release.
>
> Signed-off-by: Alan Stern
Reviewed-by: Andrea Parri
Andrea
>
> ---
>
>
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 use
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 oper
[...]
> > 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 Po
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
so 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'
> &g
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
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->mem
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,releas
> Yeah, lemme put some details here:
>
> So we have three cases:
>
> Case #1 (from Will)
>
> P0: P1: P2:
>
> spin_lock(&slock) read_lock(&rwlock)
> write_lock(&rwlock)
> read_lo
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
> +++
Commit-ID: 1a00b4554d477f05199e22ee71ba4c2525ca44cb
Gitweb: https://git.kernel.org/tip/1a00b4554d477f05199e22ee71ba4c2525ca44cb
Author: Andrea Parri
AuthorDate: Mon, 14 May 2018 16:33:56 -0700
Committer: Ingo Molnar
CommitDate: Tue, 15 May 2018 08:11:18 +0200
tools/memory-model
Commit-ID: 99c12749b172758f6973fc023484f2fc8b91cd5a
Gitweb: https://git.kernel.org/tip/99c12749b172758f6973fc023484f2fc8b91cd5a
Author: Andrea Parri
AuthorDate: Mon, 14 May 2018 16:33:57 -0700
Committer: Ingo Molnar
CommitDate: Tue, 15 May 2018 08:11:19 +0200
tools/memory-model: Add
Commit-ID: 5ccdb7536ebec7a5f8a3883ba1985a80cec80dd3
Gitweb: https://git.kernel.org/tip/5ccdb7536ebec7a5f8a3883ba1985a80cec80dd3
Author: Andrea Parri
AuthorDate: Mon, 14 May 2018 16:33:55 -0700
Committer: Ingo Molnar
CommitDate: Tue, 15 May 2018 08:11:18 +0200
MAINTAINERS, tools/memory
Commit-ID: 05604e7e3adbd78f074b7f86b14f50888bf66252
Gitweb: https://git.kernel.org/tip/05604e7e3adbd78f074b7f86b14f50888bf66252
Author: Andrea Parri
AuthorDate: Mon, 14 May 2018 16:33:54 -0700
Committer: Ingo Molnar
CommitDate: Tue, 15 May 2018 08:11:18 +0200
tools/memory-model: Fix
Commit-ID: bf8c6d963d16d40fbe70e94b61d9bf18c455fc6b
Gitweb: https://git.kernel.org/tip/bf8c6d963d16d40fbe70e94b61d9bf18c455fc6b
Author: Andrea Parri
AuthorDate: Mon, 14 May 2018 16:33:45 -0700
Committer: Ingo Molnar
CommitDate: Tue, 15 May 2018 08:11:16 +0200
tools/memory-model: Model
Commit-ID: d17013e0bac66bb4d1be44f061754c7e53292b64
Gitweb: https://git.kernel.org/tip/d17013e0bac66bb4d1be44f061754c7e53292b64
Author: Andrea Parri
AuthorDate: Mon, 14 May 2018 16:33:46 -0700
Committer: Ingo Molnar
CommitDate: Tue, 15 May 2018 08:11:17 +0200
tools/memory-model: Fix
Commit-ID: 1362ae43c503a4e333ab6948fc4c6e0e794e1558
Gitweb: https://git.kernel.org/tip/1362ae43c503a4e333ab6948fc4c6e0e794e1558
Author: Andrea Parri
AuthorDate: Mon, 14 May 2018 16:01:29 -0700
Committer: Ingo Molnar
CommitDate: Tue, 15 May 2018 08:11:15 +0200
locking/spinlocks: Clean
Commit-ID: c6f5d02b6a0fb91be5d656885ce02cf28952181d
Gitweb: https://git.kernel.org/tip/c6f5d02b6a0fb91be5d656885ce02cf28952181d
Author: Andrea Parri
AuthorDate: Mon, 14 May 2018 16:01:28 -0700
Committer: Ingo Molnar
CommitDate: Tue, 15 May 2018 08:11:15 +0200
locking/spinlocks/arm64
Commit-ID: b7e4aadef28f217de8907eec60a964328797a2be
Gitweb: https://git.kernel.org/tip/b7e4aadef28f217de8907eec60a964328797a2be
Author: Andrea Parri
AuthorDate: Mon, 14 May 2018 16:01:27 -0700
Committer: Ingo Molnar
CommitDate: Tue, 15 May 2018 08:11:15 +0200
locking/spinlocks
On Thu, May 10, 2018 at 07:15:59AM -0600, Jonathan Corbet wrote:
> On Thu, 10 May 2018 14:23:35 +0200
> Andrea Parri wrote:
>
> > only
> > remember that other people (including some developers running into the
> > "disadventure" of opening an RST doc. fro
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
On Wed, May 09, 2018 at 11:11:36AM -0600, Jonathan Corbet wrote:
> On Wed, 9 May 2018 18:53:28 +0200
> Andrea Parri wrote:
>
> > > Now that I look a little closer, I think the real issue is that the
> > > "features" documentation assumes that there's
On Wed, May 09, 2018 at 08:59:20AM -0600, Jonathan Corbet wrote:
> On Wed, 9 May 2018 15:28:24 +0200
> Andrea Parri wrote:
>
> > > BTW, it would be nice if the the question "Why was this file removed?" was
> > > answered by that jc_docs commit message ...
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-r
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:
> >
> > Docu
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 suppo
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
> > >
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 thi
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 wrote:
> > > On Mon, May 07, 2018 at 06:35:41AM -0300, Mauro Carvalho Chehab wrote:
> >
Hi Jani,
On Tue, May 08, 2018 at 05:40:56PM +0300, Jani Nikula wrote:
> On Mon, 07 May 2018, Andrea Parri 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-
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
---
MAINTAINERS | 2 +-
certs/Kconfig | 2 +-
2 files
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
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 --
> Documentati
s file. Also refreshes
the status matrix by using the script 'features-refresh.sh'.
Suggested-by: Ingo Molnar
Signed-off-by: Andrea Parri
Cc: Ingo Molnar
Cc: Jonathan Corbet
Cc: Andrew Morton
---
Documentation/features/locking/rwsem-optimized/arch-support.txt | 8
1 file ch
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'
Suggested-by: Ingo Molnar
Signed-off-by: Andrea Parri
Cc: Ingo Molnar
Cc: Jonathan Corbet
Cc: Andrew Morton
---
.../features/lib/strncasecmp/arch-support.txt | 33 --
1 file changed, 33 deletions(-)
delete mode 100644 Documentation/features/lib/strncasecmp/arch
Suggested-by: Ingo Molnar
Signed-off-by: Andrea Parri
Cc: Ingo Molnar
Cc: Jonathan Corbet
Cc: Andrew Morton
---
.../features/vm/pte_special/arch-support.txt | 33 --
1 file changed, 33 deletions(-)
delete mode 100644 Documentation/features/vm/pte_special/arch
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
Cc: Ingo Molnar
Cc: Jonathan Corbet
Cc: Andrew Morton
---
Documentation/features/core/BPF-JIT/arch-support.txt
t all easy to
keep sync and to extend."
[1] http://lkml.kernel.org/r/20180328122211.GA25420@andrea
Suggested-by: Ingo Molnar
Signed-off-by: Andrea Parri
Cc: Ingo Molnar
Cc: Jonathan Corbet
Cc: Andrew Morton
---
Documentation/features/scripts/features-refresh.sh | 98 +++
g (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 s
On Sun, May 06, 2018 at 04:57:27PM +0200, Ingo Molnar wrote:
>
> * Andrea Parri wrote:
>
> > Hi Ingo,
> >
> > > From 5affbf7e91901143f84f1b2ca64f4afe70e210fd Mon Sep 17 00:00:00 2001
> > > From: Ingo Molnar
> > > Date: Sat, 5 May 2018 10:23
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
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 ato
On Fri, May 04, 2018 at 02:13:59PM -0700, Kees Cook wrote:
> On Fri, May 4, 2018 at 2:11 PM, Andrea Parri
> wrote:
> > The LKMM project has moved to 'tools/memory-model/'.
> >
> > Signed-off-by: Andrea Parri
> > ---
> > Documentation/core-api/refcou
The LKMM project has moved to 'tools/memory-model/'.
Signed-off-by: Andrea Parri
---
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-
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 ||
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
Hi Kirill,
On Thu, Apr 26, 2018 at 02:01:07PM +0300, Kirill Tkhai wrote:
> The patch finalizes the series and makes mm_update_next_owner()
> to iterate over task list using RCU instead of tasklist_lock.
> This is possible because of rules of inheritance of mm: it may be
> propagated to a child onl
Hi Waiman,
On Mon, Apr 23, 2018 at 12:46:12PM -0400, Waiman Long wrote:
> On 04/10/2018 01:22 PM, Waiman Long wrote:
> > It was observed occasionally in PowerPC systems that there was reader
> > who had not been woken up but that its waiter->task had been cleared.
Can you provide more details abo
Hi Ingo, Jon,
On Sun, Apr 08, 2018 at 06:30:21PM +0200, Andrea Parri wrote:
> 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; previo
aul E. McKenney"
Cc: Akira Yokosawa
Andrea Parri (2):
tools/memory-model: Update ASPLOS information
tools/memory-model: Add reference for 'Simplifying ARM concurrency'
tools/memory-model/Documentation/references.txt | 17 -
tools/memory-model/linux-kernel.
The paper discusses the revised ARMv8 memory model; such revision
had an important impact on the design of the LKMM.
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
ASPLOS 2018 was held in March: make sure this is reflected in
header comments and references.
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
I moved to Amarula Solutions; switch to work e-mail address.
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
---
M
On Mon, Apr 16, 2018 at 09:22:50AM -0700, Paul E. McKenney wrote:
> From: Luc Maranget
>
> This commit first adds a trivial macro for spin_is_locked() to
> linux-kernel.def.
>
> It also adds cat code for enumerating all possible matches of lock
> write events (set LKW) with islocked events retur
On Mon, Apr 16, 2018 at 09:22:48AM -0700, Paul E. McKenney wrote:
> This commit adds a litmus test suggested by Alan Stern that is forbidden
> on multicopy atomic systems, but allowed on non-multicopy atomic systems.
> Note that other-multicopy atomic systems are examples of non-multicopy
> atomic
On Thu, Apr 12, 2018 at 02:06:27PM -0700, Paul E. McKenney wrote:
> On Thu, Apr 12, 2018 at 02:22:48PM +0200, Andrea Parri wrote:
> > Hi,
> >
> > This (tiny) series adds 'smp_store_mb()' to the model (patch 1/2), and
> > it fixes a stylistic discrepancy in
On Thu, Apr 12, 2018 at 02:18:36PM -0700, Paul E. McKenney wrote:
> On Thu, Apr 12, 2018 at 01:21:55PM +0200, Andrea Parri wrote:
> >
> > The litmus test that first comes to my mind when I think of cumulativity
> > (at least, 'cumulativity' as intended in LKMM) is
Fixes white spaces around semicolons.
Signed-off-by: Andrea Parri
---
tools/memory-model/linux-kernel.def | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/tools/memory-model/linux-kernel.def
b/tools/memory-model/linux-kernel.def
index
Says that 'smp_store_mb(x, val);' is _semantically_ equivalent to
'WRITE_ONCE(x, val); smp_mb();'.
Suggested-by: Paolo Bonzini
Suggested-by: Peter Zijlstra
Signed-off-by: Andrea Parri
---
tools/memory-model/linux-kernel.def | 1 +
1 file changed, 1 insertion(+)
diff
401 - 500 of 665 matches
Mail list logo
