Now that the new methods are plugged in and they are functional use
them instead of invoking the pointer to functions through kvm_x86_ops.
Signed-off-by: Andrea Arcangeli
---
arch/x86/include/asm/kvm_host.h | 10 +-
arch/x86/kvm/cpuid.c| 22 +--
arch/x86/kvm/hyperv.c
y and
unexpectedly leave bit 2 set in SPEC_CTRL.
Signed-off-by: Andrea Arcangeli
---
arch/x86/include/asm/msr-index.h | 2 ++
arch/x86/kernel/cpu/bugs.c | 20 +++-
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/as
e. Previous export was in arch/x86/kvm/kvm-intel.ko
WARNING: arch/x86/kvm/kvm-amd: 'kvm_page_track_unregister_notifier' exported
twice. Previous export was in arch/x86/kvm/kvm-intel.ko
a
Signed-off-by: Andrea Arcangeli
---
virt/kvm/eventfd.c | 1 -
virt/kvm/kvm_main.c | 65 ---
Plug in the new external functions and their extern declarations in
the respective kernel modules (kvm-intel and kvm-amd).
Signed-off-by: Andrea Arcangeli
---
arch/x86/kvm/pmu.h | 2 ++
arch/x86/kvm/pmu_amd.c | 2 ++
arch/x86/kvm/vmx/pmu_intel.c | 2 ++
3 files changed, 6
This replaces all kvm_pmu_ops pointer to functions with regular
external functions that don't require indirect calls.
Signed-off-by: Andrea Arcangeli
---
arch/x86/kvm/pmu_amd_ops.c | 68
arch/x86/kvm/pmu_ops.h | 22 +++
arch/x86/kv
It's enough to check the exit value and issue a direct call to avoid
the retpoline for all the common vmexit reasons.
Signed-off-by: Andrea Arcangeli
---
arch/x86/kvm/vmx/vmx.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/vmx/vm
64+89
entry_SYSCALL_64_after_hwframe+68
]: 499845
@total: 1780243
SVM has no TSC based programmable preemption timer so it is invoking
ktime_get() frequently.
Signed-off-by: Andrea Arcangeli
---
arch/x86/kvm/svm.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/x86/kvm/svm.c b
Adjusts the section prefixes of some KVM common code function because
with the monolithic methods the section checker can now do a more
accurate analysis at build time and this allows to build without
CONFIG_SECTION_MISMATCH_WARN_ONLY=n.
Signed-off-by: Andrea Arcangeli
---
arch/x86/kvm/svm.c
on-multicopy-atomic systems, as the WWC pattern demonstrates.
>
> This patch changes the LKMM to accept either a wr-vis or a reverse
> rw-xbstar link as a proof of non-concurrency.
>
> Signed-off-by: Alan Stern
Acked-by: Andrea
On Wed, Sep 04, 2019 at 12:54:15PM -0700, David Rientjes wrote:
> Two commits:
>
> commit a8282608c88e08b1782141026eab61204c1e533f
> Author: Andrea Arcangeli
> Date: Tue Aug 13 15:37:53 2019 -0700
>
> Revert "mm, thp: restore node-local hugepag
2e8e51c2129d33ddf5e4c76a49
> >
> > N.B. This analysis generally depends on the assumption that every marked
> > access (e.g., the cmpxchg_release() called out above and the READ_ONCE()
> > heading the address dependencies) are _single-copy atomic, an assumption
> > wh
Sorry for top posting, but I forgot to mention: as you might have
noticed, my @amarulasolutions address is not active anymore; FWIW,
you should still be able to reach me at this @gmail address.
Thanks,
Andrea
On Mon, Aug 26, 2019 at 10:34:36AM +0200, Andrea Parri wrote
ds from bD.
> > +*
> > +* Relies on:
> > +*
> > +* RELEASE from bD to bE
> > +*matching
> > +* ADDRESS DEP. from bB to bC->aA
> > +*/
> > + WRITE_ONCE(n->seq, seq + 1);
>
> Do we really need WRITE_ONCE() here?
> It is the same problem as with setting n->next_id above.
Same considerations as above would apply here.
Andrea
of course specific to the given
context: the language, the memory model, etc. )
IOW, I'd say that that wheel _and a common denominator here can be
represented by the notion of "litmus test". I'm not suggesting to
reinvent this wheel of course; my point was more along the lines of
"let's use the wheel, it'll be helpful..." ;-)
Andrea
tness. Is this the case?
>From what I've read so far, it _should be relatively straighforward
to write down a litmus test from any such comment (and give this to
the LKMM simulator).
>
> In each case, it should follow some "widely" used format.
> We should not invent
changed, 13 insertions(+), 12 deletions(-)
Reviewed-by: Andrea Arcangeli
Thanks,
Andrea
Commit-ID: f1c6ece23729257fb46562ff9224cf5f61b818da
Gitweb: https://git.kernel.org/tip/f1c6ece23729257fb46562ff9224cf5f61b818da
Author: Andrea Righi
AuthorDate: Mon, 12 Aug 2019 20:43:02 +0200
Committer: Ingo Molnar
CommitDate: Mon, 19 Aug 2019 12:22:19 +0200
kprobes: Fix potential
t*'
That immediately triggers the lockdep splat.
Fix by acquiring text_mutex before module_mutex in kprobe_optimizer().
Fixes: d5b844a2cf50 ("ftrace/x86: Remove possible deadlock between
register_kprobe() and ftrace_run_update_code()")
Signed-off-by: Andrea Righi
---
kernel/kp
Moreover, make sure to wake up the garbage collector thread when
bch_prio_write() is failing to allocate buckets.
BugLink: https://bugs.launchpad.net/bugs/1784665
BugLink: https://bugs.launchpad.net/bugs/1796292
Signed-off-by: Andrea Righi
---
Changes in v3:
- prevent buckets leak in bch_prio_write(
On Tue, Aug 06, 2019 at 07:36:48PM +0200, Andrea Righi wrote:
> On Tue, Aug 06, 2019 at 11:18:01AM +0200, Andrea Righi wrote:
> > bcache_allocator() can call the following:
> >
> > bch_allocator_thread()
> > -> bch_prio_write()
> > -> bch_bucket_
On Tue, Aug 06, 2019 at 11:18:01AM +0200, Andrea Righi wrote:
> bcache_allocator() can call the following:
>
> bch_allocator_thread()
> -> bch_prio_write()
> -> bch_bucket_alloc()
> -> wait on &ca->set->bucket_wait
>
> But the wake up ev
Moreover, make sure to wake up the garbage collector thread when
bch_prio_write() is failing to allocate buckets.
BugLink: https://bugs.launchpad.net/bugs/1784665
BugLink: https://bugs.launchpad.net/bugs/1796292
Signed-off-by: Andrea Righi
---
Changes in v2:
- prevent retry_invalidate busy loop
On Wed, Jul 10, 2019 at 05:46:56PM +0200, Andrea Righi wrote:
> On Wed, Jul 10, 2019 at 11:11:37PM +0800, Coly Li wrote:
> > On 2019/7/10 5:31 下午, Andrea Righi wrote:
> > > bcache_allocator() can call the following:
> > >
> > > bch_allocato
On Mon, Aug 05, 2019 at 08:23:38AM -0700, James Bottomley wrote:
> On Mon, 2019-08-05 at 17:15 +0200, Andrea Parri wrote:
> > > Why don't you also add an entry in .mailmap as Will did in commit
> > > c584b1202f2d ("MAINTAINERS: Update my email address to use
ded/desired).
Thanks,
Andrea
My @amarulasolutions.com address stopped working this July, so update
to my @gmail.com address where you'll still be able to reach me.
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 Alglav
/* Provide lock ACQUIRE */
> + smp_acquire__after_ctrl_dep();
Does this also make the lock RCtso? Or maybe RCtso was already
guaranteed (and I'm failing to see why)?
Thanks,
Andrea
On Wed, Jul 10, 2019 at 11:11:37PM +0800, Coly Li wrote:
> On 2019/7/10 5:31 下午, Andrea Righi wrote:
> > bcache_allocator() can call the following:
> >
> > bch_allocator_thread()
> > -> bch_prio_write()
> > -> bch_bucket_alloc()
> >
er waits on itself.
Moreover, make sure to wake up the garbage collector thread when
bch_prio_write() is failing to allocate buckets.
BugLink: https://bugs.launchpad.net/bugs/1784665
Signed-off-by: Andrea Righi
---
drivers/md/bcache/alloc.c | 6 +-
drivers/md/bcache/bcache.h | 2
On Sun, Jun 30, 2019 at 04:03:34AM +0200, John Ogness wrote:
> On 2019-06-29, Andrea Parri wrote:
> >> /**
> >> * add_descr_list() - Add a descriptor to the descriptor list.
> >> *
> >> * @e: An entry that has already reserved data.
> >> *
&g
.
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
Cc: Daniel Lustig
---
tools/memory-model/Documentation/explanatio
o the iterating reader in the pairing
>* MB6-read context.
>*
>* Note: Before this store, the value of @next of the
>* previously newest descriptor is EOL.
>*/
Same as above but for MB6-read and the acce
On Sat, Jun 29, 2019 at 12:15:15PM -0700, Paul E. McKenney wrote:
> On Sat, Jun 29, 2019 at 08:09:10PM +0200, Andrea Parri wrote:
> > On Sat, Jun 29, 2019 at 09:55:33AM -0700, Paul E. McKenney wrote:
> > > On Sat, Jun 29, 2019 at 05:12:36PM +0200, Andrea Parri wrote
be (more) paranoid? ..."
should have been "IPIs are serializing" (so all a different "order"...)
Andrea
On Sat, Jun 29, 2019 at 09:55:33AM -0700, Paul E. McKenney wrote:
> On Sat, Jun 29, 2019 at 05:12:36PM +0200, Andrea Parri wrote:
> > Hi Steve,
> >
> > > As Paul stated, interrupts are synchronization points. Archs can only
> > > play games with ordering when deal
t the stores are
> done in that order as the interrupt sees it.
Hopefully I'm not derailing the conversation too much with my questions
... but I was wondering if we had any documentation (or inline comments)
elaborating on this "interrupts are synchronization points"?
Thanks,
Andrea
, it's quite possible that I'm missing
something subtle here; said this, ;-) the patch does look good to
me: FWIW,
Reviewed-by: Andrea Parri
Thanks,
Andrea
>
> ---
> Changed to RFC to get any feedback on the memory ordering.
>
>
> include/linux/pid.h | 5 +++-
ter
if network or disk with userfaultfd or just pagecache readpage on
filebacked kernel faults) and only a minor fault is required to obtain
the page. But it is better to defer that second minor fault to the
point where "pages" already become != NULL, so we end up calling
__get_user_pages 2 times instead of 3 times.
Thanks,
Andrea
= cmpxchg(addr, old, new);
(and it will complain loudly without that "loc_var = " part...); this
is something that could be improved, or at least it seems this way...
A similar consideration holds for all the value-returning primitives.
Thanks,
Andrea
vis
> relations).
>
> With these changes, the LKMM gives the desired result for Herbert's
> litmus test and other related ones.
>
> Signed-off-by: Alan Stern
> Reported-by: Herbert Xu
For the entire series:
Acked-by: Andrea Parri
Two nits, but up to Paul A
illustrated in the examples pointed out above.
I'd suggest to _not be stingy with memory barriers explanations: this
eases/makes it possible the review itself as well as future changes or
fixes to the implementation.
FWIW (and as anticipated time ago in a private email), when I see code
like this I tend to look elsewhere... ;-/
Thanks,
Andrea
tate backporting, but in my view
it's more a bug in the coredump code that will eventually have to be
rewritten to stop invoking page faults without the mmap_sem for
reading. So the long term plan is still to drop all
mmget_still_valid().
Cc:
Fixes: ba76149f47d8 ("thp: khugepaged")
Re
On Thu, Jun 06, 2019 at 11:04:39AM +0200, Peter Zijlstra wrote:
> On Thu, Jun 06, 2019 at 10:44:21AM +0200, Andrea Parri wrote:
> > On Mon, Jun 03, 2019 at 06:46:54AM -0700, tip-bot for Peter Zijlstra wrote:
> > > Commit-ID: fff9b6c7d26943a8eb32b58364b7ec6b9369746a
> > &g
Cc: Thomas Gleixner
> Link:
> https://lkml.kernel.org/r/20190524115231.gn2...@hirez.programming.kicks-ass.net
> Signed-off-by: Ingo Molnar
I'd appreciate if you could Cc: me in future changes to this doc.
(as currently suggested by get_maintainer.pl).
This is particularly annoying when you spend time
On Mon, Jun 03, 2019 at 10:46:40AM +0800, Herbert Xu wrote:
> The case we were discussing is from net/ipv4/inet_fragment.c from
> the net-next tree:
BTW, thank you for keeping me and other people who intervened in that
discussion in Cc:...
Andrea
>
> void fqdir_exit(struct
code and the informal doc
will have settled in such direction).
It seems worth stressing the fact that _neither_ of these changes will
prevent the test below from being racy, considered the two accesses to
"a" happen concurrently / without synchronization.
Thanks,
Andrea
C xu-2
{
acquire__after_ctrl_dep() is for cases in which you would
> otherwise need a full memory barrier - smp_mb() - and you want to be
> able to reduce it to a read barrier.
It is supposed to be used when you want an ACQUIRE but you only have a
control dependency (so you "augment the dependency" with this barrier).
FWIW, I do agree on the "dark magic"..., and I'd strongly recommend to
not use this barrier (or, at least, to use it with high suspicion).
Andrea
On Tue, May 28, 2019 at 12:47:19PM +0200, Peter Zijlstra wrote:
> On Sat, May 25, 2019 at 12:43:40AM +0200, Andrea Parri wrote:
> > > ---
> > > Subject: Documentation/atomic_t.txt: Clarify pure non-rmw usage
> > >
> > > Clarify that pure non-RMW u
/linux-mmots.git/commit/?id=87efc56527b92a59d15c5d4e4b05f875b276a59a
Thanks,
Andrea
ps://lkml.kernel.org/r/20190523135013.gl28...@linux.ibm.com
Signed-off-by: Andrea Parri
Cc: "Paul E. McKenney"
Cc: Josh Triplett
Cc: Steven Rostedt
Cc: Mathieu Desnoyers
Cc: Lai Jiangshan
Cc: Joel Fernandes
Cc: r...@vger.kernel.org
Cc: Peter Zijlstra
Cc: Will Deacon
Cc: Mark R
counterargument (not so theoretic, just look around in the kernel!) is:
we all 'forget' to use READ_ONCE() and WRITE_ONCE(), it should be difficult
or more difficult to forget to use atomic_read() and atomic_set()... IAC,
I wouldn't call any of them 'wrong'.
Andrea
>
vior for
compaction+reclaim interleaving if only the whole system would be out
of memory in all nodes (and it isn't).
The false positive result from the automated testing (where swapping
overall performance decreased because fariness increased) wasn't
anybody's fault and so the revert at the end of the merge window was a
safe approach. So we can try again to fix it now.
Thanks!
Andrea
On Fri, May 24, 2019 at 12:45:09PM -0400, Joel Fernandes wrote:
> On Fri, May 24, 2019 at 12:36:37PM +0200, Andrea Parri wrote:
> > Quoting Paul [1]:
> >
> > "Given that a quick (and perhaps error-prone) search of the uses
> > of rcu_assign_pointer() in v5.1
On Fri, May 24, 2019 at 06:29:11AM -0700, Paul E. McKenney wrote:
> On Fri, May 24, 2019 at 12:36:37PM +0200, Andrea Parri wrote:
> > Quoting Paul [1]:
> >
> > "Given that a quick (and perhaps error-prone) search of the uses
> > of rcu_assign_pointer() in v5.1
for the confirmation, Greg. I'll drop mine.
At this time, it's not clear to me where Peter's patch will be applied,
and where/whether I should rebase 2/2 (if there is interested in that):
Please let me know.
Thanks,
Andrea
On Fri, May 24, 2019 at 12:39:34PM +0200, Peter Zijlstra wrote:
> On Fri, May 24, 2019 at 12:35:35PM +0200, Andrea Parri wrote:
> > The primitive vmci_q_set_pointer() relies on atomic*_set() being of
> > type 'void', but this is a non-portable implementation detail.
&
assign_pointer() patch.
>
> ... since we do want the WRITE_ONCE() itself to be evaluated.
>
> On Fri, May 24, 2019 at 12:35:36PM +0200, Andrea Parri wrote:
> > Now that there's no single use of the value of WRITE_ONCE(), change
> > the implementation to eliminate it.
>
://lkml.kernel.org/r/20190523135013.gl28...@linux.ibm.com
Signed-off-by: Andrea Parri
Cc: "Paul E. McKenney"
Cc: Josh Triplett
Cc: Steven Rostedt
Cc: Mathieu Desnoyers
Cc: Lai Jiangshan
Cc: Joel Fernandes
Cc: r...@vger.kernel.org
Cc: Peter Zijlstra
Cc: Will Deacon
Cc: Mark Rutland
The primitive vmci_q_set_pointer() relies on atomic*_set() being of
type 'void', but this is a non-portable implementation detail.
Reported-by: Mark Rutland
Signed-off-by: Andrea Parri
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Jorgen Hansen
Cc: Peter Zijlstra
Cc: Will Deacon
o to WRITE_ONCE() (which is currently
evaluated).
Mark suggested to clean up all non-portable users of atomic*_set(),
and to prevent WRITE_ONCE() from being evaluated [2]; this resulted
in this first attempt/patchset based on Mark's atomics/type-cleanup
branch [3].
Cheers Andrea
Now that there's no single use of the value of WRITE_ONCE(), change
the implementation to eliminate it.
Suggested-by: Mark Rutland
Signed-off-by: Andrea Parri
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Jorgen Hansen
Cc: Peter Zijlstra
Cc: Will Deacon
Cc: Mark Rutland
Cc: &q
st one user that needs to be cleaned up
> first (relying on non-portable implementation detaisl of atomic*_set()),
> but I suspect rcu_assign_pointer() isn't used as much as a building
> block for low-level macros.
Thanks for the confirmation, Mark.
I can look at the WRITE_ONCE() issues (user and implementation); it will
probably be a separate patchset...
Thanks,
Andrea
eliminate the return value.
Thanks for the confirmation, Paul; I'll prepare the new patch shortly...
Andrea
nter(*y, x);
can currently result in the compiler warning
warning: assignment to ‘int *’ from ‘uintptr_t’ {aka ‘long unsigned int’}
makes pointer from integer without a cast [-Wint-conversion]
Cast the uintptr_t value to a typeof(p) value.
Signed-off-by: Andrea Parri
Cc: "Paul E. McKe
ctures implementing arch_atomic_* will have both of these functions
> returning void. Currently that's x86 and arm64, but (time permitting) I intend
> to migrate other architectures, so I guess we'll have to fix the above up as
> required.
>
> I think it's best to avoid the construct above.
Thank you for the clarification, Mark. I agree with you that it'd be
better to avoid such constructs. (FWIW, it is not currently possible
to use them in litmus tests for the LKMM...)
Thanks,
Andrea
y in the
implementation of atomic64_set() or if this would also need to be fixed
/addressed (say in a different patchset)?
Thanks,
Andrea
y"
Reported-by: Peter Zijlstra
Signed-off-by: Andrea Parri
Cc: "Yan, Zheng"
Cc: Sage Weil
Cc: Ilya Dryomov
Cc: ceph-de...@vger.kernel.org
Cc: "Paul E. McKenney"
Cc: Peter Zijlstra
---
fs/ceph/super.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff -
d-by: "Paul E. McKenney"
Reported-by: Peter Zijlstra
Signed-off-by: Andrea Parri
Reviewed-by: Ming Lei
Cc: Jens Axboe
Cc: Ming Lei
Cc: linux-bl...@vger.kernel.org
Cc: "Paul E. McKenney"
Cc: Peter Zijlstra
---
include/linux/bio.h | 2 +-
1 file changed, 1 insertion(+), 1
aul E. McKenney"
Reported-by: Peter Zijlstra
Signed-off-by: Andrea Parri
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jordan Crouse
Cc: linux-arm-...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Cc: "Paul E. McKe
://lkml.kernel.org/r/20190430164404.GA2874@andrea
Cheers Andrea
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jordan Crouse
Cc: Jens Axboe
Cc: Omar Sandoval
Cc: Ming Lei
Cc: "Yan, Zheng"
Cc: Sage Weil
Cc: Ilya Dryomov
Cc: "Paul E. McKenney"
Cc: Pet
On Tue, May 14, 2019 at 08:32:52AM -0400, Dennis Dalessandro wrote:
> On 5/9/2019 5:12 PM, Andrea Parri wrote:
> >On Tue, Apr 30, 2019 at 01:16:57AM +0200, Andrea Parri wrote:
> >>Hi Mike,
> >>
> >>>>This barrier only applies to the read-modify-write op
ordered with following atomic64_set.
> >
> >Thanks for the suggestion, Yan.
> >
> >To be clear: would you like me to integrate your comment and resend?
> >any other suggestions?
> >
>
> Yes, please
Will do: I'll let the merge window close and send v2 on top of -rc1.
Thanks,
Andrea
e the issue.
>
> Thank you! May I add your Tested-by?
Please feel free to do so. But it may be worth to squash "the commits"
(and adjust the changelogs accordingly). And you might want to remove
some of those debug checks/prints?
Andrea
to Linux
Kernel" project [1] and (for the "dynamic analysis" side) the efforts
to revive the Kernel Thread sanitizer [2]. I should also mention the
efforts to add (support for) "unmarked" accesses and to formalize the
notion of "data race" in the memory consistency mo
is down!!!
Peter (echoing Paul): Thank you for pointing that shuffler out!
Andrea
eter Zijlstra kindly volunteered over IRC to look at this more closely
> tomorrow (well, today, his time). It is quite strange, though! ;-)
Sounds good! ;-)
Thanx,
Andrea
On Thu, May 09, 2019 at 11:40:25PM +0200, Andrea Parri wrote:
> On Thu, May 09, 2019 at 10:36:54AM -0700, Paul E. McKenney wrote:
> > On Tue, May 07, 2019 at 03:16:13PM -0700, Paul E. McKenney wrote:
> > > On Wed, May 01, 2019 at 01:27:13PM -0700, Paul E. McKenney wrote:
>
Except
> > that this rcutorture scenario doesn't offline anything, and I don't see
> > any CPU-hotplug removal messages. So I added another trace_printk() to
> > print out cpu_online_mask. This gets me the following:
> >
> > [ 31.565605] 0) | /* On unexpected CPU 0, expected 1!!! */
> > [ 31.565605] 0) | /* Online CPUs: 0-7 */
> >
> > So we didn't make it to CPU 1 despite its being online. I placed the
> > console log here:
> >
> > http://www2.rdrop.com/~paulmck/submission/console.tpkol.log.gz
> >
> > Thoughts?
And I can finally see/reproduce it!!
Frankly, no idea how this is happening (I have been staring at these
traces/functions for hours/days now... ;-/ )
Adding some "sched" folks in Cc: hopefully, they can shed some light
about this.
And yes, my only suggestion/approach would be to keep bisecting this
code with printk*..., 'fun' ;-/
Andrea
On Tue, Apr 30, 2019 at 01:16:57AM +0200, Andrea Parri wrote:
> Hi Mike,
>
> > >This barrier only applies to the read-modify-write operations; in
> > >particular, it does not apply to the atomic_read() primitive.
> > >
> > >Replace the barrier with an smp
On Tue, Apr 30, 2019 at 05:08:43PM +0800, Yan, Zheng wrote:
> On Tue, Apr 30, 2019 at 4:26 PM Peter Zijlstra wrote:
> >
> > On Mon, Apr 29, 2019 at 10:15:00PM +0200, Andrea Parri wrote:
> > > This barrier only applies to the read-modify-write operations; in
> > >
s.
>
> This improves the text to make the actual ordering implications clear,
> and also to explain how these barriers differ from a RELEASE or
> ACQUIRE ordering.
>
> Signed-off-by: Alan Stern
> CC: Peter Zijlstra
I understand that this does indeed better describe the inte
in feature for guest mode is worth it, to swap "DN 4k | DN+1 THP"
with "DN+1 THP | DN 4k" at every NUMA distance crossing.
Signed-off-by: Andrea Arcangeli
---
include/linux/mempolicy.h | 2 ++
mm/huge_memory.c | 42 ---
mm/mempol
rther. The silver lining is that this
extra time allowed to think more at this issue and also plan for a
future direction to improve things further in terms of THP NUMA
locality.
Thank you,
Andrea
Andrea Arcangeli (2):
Revert "Revert "mm, thp: consolidate THP gfp handling into
alloc_hug
This reverts commit 356ff8a9a78fb35d6482584d260c3754dcbdf669.
Signed-off-by: Andrea Arcangeli
---
include/linux/gfp.h | 12
mm/huge_memory.c| 27 ++-
mm/mempolicy.c | 32 +++-
mm/shmem.c | 2 +-
4 files changed
On Tue, Apr 30, 2019 at 10:34:09AM +0200, Peter Zijlstra wrote:
> On Mon, Apr 29, 2019 at 10:14:56PM +0200, Andrea Parri wrote:
> > Hello!
> >
> > A relatively common misuse of these barriers is to apply these to
> > operations which are not read-modify-write operati
nto.
>
> See:
>
> [PATCH for-next 6/9] IB/rdmavt: Add new completion inline
>
> We will take a look at this one as well.
Thank you for the reference and for looking into this,
Andrea
y: "Paul E. McKenney"
Reported-by: Peter Zijlstra
Signed-off-by: Andrea Parri
Cc: Dennis Dalessandro
Cc: Mike Marciniszyn
Cc: Doug Ledford
Cc: Jason Gunthorpe
Cc: linux-r...@vger.kernel.org
---
drivers/infiniband/sw/rdmavt/qp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deleti
y"
Reported-by: Peter Zijlstra
Signed-off-by: Andrea Parri
Cc: "Yan, Zheng"
Cc: Sage Weil
Cc: Ilya Dryomov
Cc: ceph-de...@vger.kernel.org
---
fs/ceph/super.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ceph/super.h b/fs/ceph/super.h
index 16c03188578ea.
}_atomic() barriers with full memory barriers.
Applies on 5.1-rc7.
Thanks,
Andrea
Cc: "Paul E. McKenney"
Cc: Peter Zijlstra
Cc: Rob Clark
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jordan Crouse
Cc: Jens Axboe
Cc: Omar Sandoval
Cc: "Yan, Zheng"
Cc: Sage We
specifies
> > the barriers only apply to RmW ops and both _set() and _read() are
> > specified to not be a RmW.
>
> Agreed. The "Ditto" covers my atomic_set() consternation. ;-)
I was working on some of these before the Easter break [1, 2]: the plan
was to continue next week
t; facility. The basic design has been explained in various emails, and
> a separate documentation patch will be submitted later.
>
> This work is based on an earlier formulation of data races for the
> LKMM by Andrea Parri.
>
> Signed-off-by: Alan Stern
For the entire series,
Reviewed-by: Andrea Parri
Thanks,
Andrea
ich
are free to reorder the atomic_dec() with the READ_ONCE() execute a full
memory barrier in smp_mb__before_atomic() ... This assumption currently
holds, AFAICT, but yes: it may well become "non-portable"! ... ;-)
Andrea
hese boil down to:
https://elixir.bootlin.com/linux/v5.1-rc5/source/arch/x86/include/asm/atomic.h#L95
https://elixir.bootlin.com/linux/v5.1-rc5/source/arch/x86/include/asm/barrier.h#L84
Andrea
CE(*y, 1);
when CONFIG_WEAK_ORDERING=y, CONFIG_WEAK_REORDERING_BEYOND_LLSC=n.
Do these observations make sense to you? Thoughts?
Andrea
smp_mb__before_atomic() can not be applied to atomic_set(). Remove the
barrier and rely on RELEASE synchronization.
Fixes: ba16b2846a8c6 ("kernfs: add an API to get kernfs node from inode number")
Cc: sta...@vger.kernel.org
Signed-off-by: Andrea Parri
---
fs/kernfs/dir.c | 5 ++-
On Tue, Apr 09, 2019 at 08:01:32AM -0700, Paul E. McKenney wrote:
> On Tue, Apr 09, 2019 at 03:36:18AM +0200, Andrea Parri wrote:
> > > > The formula was more along the line of "do not assume either of these
> > > > cases to hold; use barrier() is y
is equivalent to:
smp_mb__before_atomic();
atomic_fetch_add_relaxed();
smp_mb__after_atomic();
[...]
2) Some implementations of the _relaxed() variants do not provide any
compiler barrier currently.
Andrea
So consider the following test:
> >
> > C non-transitive-wmb-2
> >
> > {
> > x=0x0001;
> > }
> >
> > P0(int *x, int *y)
> > {
> > *x = 1;
> > smp_store_release(y, 1);
> > }
> >
> > P1(int *x, int *y, int *z)
> > {
> > int r1;
> >
> > r1 = smp_load_acquire(y);
> > if (r1) {
> > *x = 2;
> > smp_wmb();
> > WRITE_ONCE(*z, 1);
> > }
> > }
> >
> > P2(int *x, int *z)
> > {
> > int r3;
> > int r4 = 0;
> >
> > r3 = READ_ONCE(*z);
> > if (r3) {
> > smp_rmb();
> > r4 = READ_ONCE(*x); /* E */
> > }
> > }
> >
> > exists (2:r3=1 /\ 2:r4=2)
> >
> > The proposed model says that this is race-free. Now suppose that the
> > compiler mapped the two plain writes above as follows:
> >
> > *x = 1; --> A:write 0x0001 at x
> > B:write 0x at (x + 2)
> >
> > *x = 2; --> C:write 0x0002 at x
> > if ((D:read of 2 bytes at (x + 2)) != 0x)
> > write 0x at (x + 2)
> >
> > and consider the execution where 1:r1=1 and 2:r3=1. We know that A and
> > B propagate to P1 before C and D execute (release/acquire) and that C
> > propagates to P2 before E executes (wmb/rmb). But what guarantees that
> > B, say, propagates to P2 before E executes? AFAICT, nothing prevent P2
> > from reading the value 0x00010002 for x, that is, from reading the least
> > significant bits from P1's "write 0x0002 at x" and the most significant
> > bits from the initial write. However, the proposed model doesn't report
> > the corresponding execution/state.
>
> Ah, that is indeed an excellent example! I had not considered
> mixed-size accesses generated by the compiler.
>
> So perhaps it would be better to get rid of the whole notion of super
> and major writes, and declare that non-transitive-wmb is racy in all
> its variants.
This makes sense to me.
Andrea
; As mentioned earlier, ww-vis is contained in ww-xb and wr-vis is
> > > contained in wr-xb. It turns out that the LKMM can almost prove that
> > > the ij-xb relations are transitive, in the following sense. If W is a
> > > write and R is a read, then:
> > >
&
om the series do not apply to "tip/core/rcu"
(from the Subject), but this seems straightforward enough:
Acked-by: Andrea Parri
Andrea
>
> // Atomic
> atomic_read(X) READ_ONCE(*X)
> --
> 2.17.1
>
501 - 600 of 2678 matches
Mail list logo
