search for: smp_mb__

...log _completely_ fails to explain the sync 0x11 and sync > 0x12 semantics nor does it provide a publicly accessible link to > documentation that does. Ralf pointed me at: https://imgtec.com/mips/architectures/mips64/ > 3) it really should have explained what you did with > smp_llsc_mb/smp_mb__before_llsc() in _detail_. And reading the MIPS64 v6.04 instruction set manual, I think 0x11/0x12 are _NOT_ transitive and therefore cannot be used to implement the smp_mb__{before,after} stuff. That is, in MIPS speak, those SYNC types are Ordering Barriers, not Completion Barriers. They need not...

...log _completely_ fails to explain the sync 0x11 and sync > 0x12 semantics nor does it provide a publicly accessible link to > documentation that does. Ralf pointed me at: https://imgtec.com/mips/architectures/mips64/ > 3) it really should have explained what you did with > smp_llsc_mb/smp_mb__before_llsc() in _detail_. And reading the MIPS64 v6.04 instruction set manual, I think 0x11/0x12 are _NOT_ transitive and therefore cannot be used to implement the smp_mb__{before,after} stuff. That is, in MIPS speak, those SYNC types are Ordering Barriers, not Completion Barriers. They need not...

On Sun, 2016-01-10 at 13:56 +0200, Michael S. Tsirkin wrote: > SMP-only barriers were missing in checkpatch.pl > > Refactor code slightly to make adding more variants easier. [] > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl [] > @@ -5116,7 +5116,25 @@ sub process { > ? } > ? } > ?# check for memory barriers without a comment. > - if ($line =~

On Sun, 2016-01-10 at 13:56 +0200, Michael S. Tsirkin wrote: > SMP-only barriers were missing in checkpatch.pl > > Refactor code slightly to make adding more variants easier. [] > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl [] > @@ -5116,7 +5116,25 @@ sub process { > ? } > ? } > ?# check for memory barriers without a comment. > - if ($line =~

...; 0x12 semantics nor does it provide a publicly accessible link to > > > documentation that does. > > > > Ralf pointed me at: https://imgtec.com/mips/architectures/mips64/ > > > > > 3) it really should have explained what you did with > > > smp_llsc_mb/smp_mb__before_llsc() in _detail_. > > > > And reading the MIPS64 v6.04 instruction set manual, I think 0x11/0x12 > > are _NOT_ transitive and therefore cannot be used to implement the > > smp_mb__{before,after} stuff. > > > > That is, in MIPS speak, those SYNC types ar...

...; 0x12 semantics nor does it provide a publicly accessible link to > > > documentation that does. > > > > Ralf pointed me at: https://imgtec.com/mips/architectures/mips64/ > > > > > 3) it really should have explained what you did with > > > smp_llsc_mb/smp_mb__before_llsc() in _detail_. > > > > And reading the MIPS64 v6.04 instruction set manual, I think 0x11/0x12 > > are _NOT_ transitive and therefore cannot be used to implement the > > smp_mb__{before,after} stuff. > > > > That is, in MIPS speak, those SYNC types ar...

.... However the latest MIPS/Imagination CPU have a pipeline long enough to hit a problem - absence of SYNC at LL/SC inside atomics, barriers etc. > And reading the MIPS64 v6.04 instruction set manual, I think 0x11/0x12 > are_NOT_ transitive and therefore cannot be used to implement the > smp_mb__{before,after} stuff. > > That is, in MIPS speak, those SYNC types are Ordering Barriers, not > Completion Barriers. Please see above, point 2. > That is, currently all architectures -- with exception of PPC -- have > RCsc locks, but using these non-transitive things will get you RC...

...lly be the smp_barriers, not to have to > prefix it with smp_ before using it. > > my $smp_barriers = qr{ > smp_store_release| > smp_load_acquire| > smp_store_mb| > smp_read_barrier_depends That's missing (?:barriers) too. btw: shouldn't this also have smp_mb__(?:before|after)_atomic ?

...he sync 0x11 and sync > > 0x12 semantics nor does it provide a publicly accessible link to > > documentation that does. > > Ralf pointed me at: https://imgtec.com/mips/architectures/mips64/ > > > 3) it really should have explained what you did with > > smp_llsc_mb/smp_mb__before_llsc() in _detail_. > > And reading the MIPS64 v6.04 instruction set manual, I think 0x11/0x12 > are _NOT_ transitive and therefore cannot be used to implement the > smp_mb__{before,after} stuff. > > That is, in MIPS speak, those SYNC types are Ordering Barriers, not >...

On 01/10/2016 06:18 AM, Michael S. Tsirkin wrote: > On mips dma_rmb, dma_wmb, smp_store_mb, read_barrier_depends, > smp_read_barrier_depends, smp_store_release and smp_load_acquire match > the asm-generic variants exactly. Drop the local definitions and pull in > asm-generic/barrier.h instead. > This statement doesn't fit MIPS barriers variations. Moreover, there is a reason

On 01/10/2016 06:18 AM, Michael S. Tsirkin wrote: > On mips dma_rmb, dma_wmb, smp_store_mb, read_barrier_depends, > smp_read_barrier_depends, smp_store_release and smp_load_acquire match > the asm-generic variants exactly. Drop the local definitions and pull in > asm-generic/barrier.h instead. > This statement doesn't fit MIPS barriers variations. Moreover, there is a reason

...etc. What ?! Are you saying that because R2 has short pipelines its unlikely to hit the reordering issues and we can omit barriers? > >And reading the MIPS64 v6.04 instruction set manual, I think 0x11/0x12 > >are_NOT_ transitive and therefore cannot be used to implement the > >smp_mb__{before,after} stuff. > > > >That is, in MIPS speak, those SYNC types are Ordering Barriers, not > >Completion Barriers. > > Please see above, point 2. That did not in fact enlighten things. Are they transitive/multi-copy atomic or not? (and here Will will go into great de...

...ntry_ie() (Stanislaw Gruszka) [1776205 1776206] +- [wireless] mwifiex: Fix heap overflow in mmwifiex_process_tdls_action_frame() (Stanislaw Gruszka) [1776156 1776157] {CVE-2019-14901} +- [fs] vfs: Fix EOVERFLOW testing in put_compat_statfs64 (Eric Sandeen) [1775678 1758001] +- [x86] x86/atomic: Fix smp_mb__{before,after}_atomic() (Prarit Bhargava) [1772812 1769569] +- [mm] mm-vmstat-reduce-zone-lock-holding-time-by-proc-pagetypeinfo-fix (Waiman Long) [1770732 1757943] +- [mm] mm, vmstat: reduce zone->lock holding time by /proc/pagetypeinfo (Waiman Long) [1770732 1757943] +- [mm] mm, vmstat: hide /p...

On our CentOS 7 servers I see there is a new kernel available when doing yum update: kernel 3.10.0-1062.12.1.el7 kernel-devel 3.10.0-1062.12.1.el7 However I am not able to find any announcement at redhat.com for this kernel. The only announcement I find is this from CentOS: https://www.mail-archive.com/centos-announce at centos.org/msg11573.html However that CentOS announcement links to