search for: lcoking

From: Davidlohr Bueso <dave at stgolabs.net> With commit b92b8b35a2e ("locking/arch: Rename set_mb() to smp_store_mb()") it was made clear that the context of this call (and thus set_mb) is strictly for CPU ordering, as opposed to IO. As such all archs should use the smp variant of mb(), respecting the semantics and saving a mandatory barrier on UP. Signed-off-by: Davidlohr Bueso

...omas Gleixner <tglx at linutronix.de> > Cc: Tony Luck <tony.luck at intel.com> > Cc: dave at stgolabs.net > Link: http://lkml.kernel.org/r/1445975631-17047-3-git-send-email-dave at stgolabs.net > Signed-off-by: Ingo Molnar <mingo at kernel.org> Aside from a need for s/lcoking/locking/ in the subject line: Reviewed-by: Paul E. McKenney <paulmck at linux.vnet.ibm.com> > --- > arch/ia64/include/asm/barrier.h | 2 +- > arch/powerpc/include/asm/barrier.h | 2 +- > arch/s390/include/asm/barrier.h | 2 +- > include/asm-generic/barrier.h | 2 +...

...omas Gleixner <tglx at linutronix.de> > Cc: Tony Luck <tony.luck at intel.com> > Cc: dave at stgolabs.net > Link: http://lkml.kernel.org/r/1445975631-17047-3-git-send-email-dave at stgolabs.net > Signed-off-by: Ingo Molnar <mingo at kernel.org> Aside from a need for s/lcoking/locking/ in the subject line: Reviewed-by: Paul E. McKenney <paulmck at linux.vnet.ibm.com> > --- > arch/ia64/include/asm/barrier.h | 2 +- > arch/powerpc/include/asm/barrier.h | 2 +- > arch/s390/include/asm/barrier.h | 2 +- > include/asm-generic/barrier.h | 2 +...

...mb(var, value) do { WRITE_ONCE(var, value); mb(); } while (0) > +#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); smp_mb(); } while (0) > #endif > > #ifndef smp_mb__before_atomic > The same patch is already in the tip tree scheduled for 4.5 as d5a73cadf3fd ("lcoking/barriers, arch: Use smp barriers in smp_store_release()"). I think you can drop your version. arnd

...mb(var, value) do { WRITE_ONCE(var, value); mb(); } while (0) > +#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); smp_mb(); } while (0) > #endif > > #ifndef smp_mb__before_atomic > The same patch is already in the tip tree scheduled for 4.5 as d5a73cadf3fd ("lcoking/barriers, arch: Use smp barriers in smp_store_release()"). I think you can drop your version. arnd

...and reworks virtio and xen to use it. Plus some fixes here and there. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> ---------------------------------------------------------------- Yes I know that the patch by Davidlohr Bueso has a typo in the subject :( Davidlohr Bueso (1): lcoking/barriers, arch: Use smp barriers in smp_store_release() Michael S. Tsirkin (40): asm-generic: guard smp_store_release/load_acquire ia64: rename nop->iosapic_nop ia64: reuse asm-generic/barrier.h powerpc: reuse asm-generic/barrier.h s390: reuse asm-generic/barrier.h...

...and reworks virtio and xen to use it. Plus some fixes here and there. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> ---------------------------------------------------------------- Yes I know that the patch by Davidlohr Bueso has a typo in the subject :( Davidlohr Bueso (1): lcoking/barriers, arch: Use smp barriers in smp_store_release() Michael S. Tsirkin (40): asm-generic: guard smp_store_release/load_acquire ia64: rename nop->iosapic_nop ia64: reuse asm-generic/barrier.h powerpc: reuse asm-generic/barrier.h s390: reuse asm-generic/barrier.h...

...ue); mb(); } while (0) > > +#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); smp_mb(); } while (0) > > #endif > > > > #ifndef smp_mb__before_atomic > > > > The same patch is already in the tip tree scheduled for 4.5 as d5a73cadf3fd > ("lcoking/barriers, arch: Use smp barriers in smp_store_release()"). Sorry which tree do you mean exactly? > I think you can drop your version. > > arnd Will drop mine, thanks. I kind of dislike that if I just drop it, some arches will temporarily regress to a slower implementation. I thin...

...me fixes here and there. > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > > ---------------------------------------------------------------- > > Yes I know that the patch by Davidlohr Bueso has a typo in the subject :( > > Davidlohr Bueso (1): > lcoking/barriers, arch: Use smp barriers in smp_store_release() > > Michael S. Tsirkin (40): > asm-generic: guard smp_store_release/load_acquire > ia64: rename nop->iosapic_nop > ia64: reuse asm-generic/barrier.h > powerpc: reuse asm-generic/barrier.h >...

...he new barriers -. Patches 37-39 convert xen drivers to use the virt_xxx APIs compiled only (by intel 0-day infrastructure) -. Patch 40 makes some smp barriers on s390 more efficient included here to avoid merge conflicts, at maintainer's request tested on x86 Davidlohr Bueso (1): lcoking/barriers, arch: Use smp barriers in smp_store_release() Michael S. Tsirkin (40): asm-generic: guard smp_store_release/load_acquire ia64: rename nop->iosapic_nop ia64: reuse asm-generic/barrier.h powerpc: reuse asm-generic/barrier.h s390: reuse asm-generic/barrier.h sparc: reuse asm-...

...he new barriers -. Patches 37-39 convert xen drivers to use the virt_xxx APIs compiled only (by intel 0-day infrastructure) -. Patch 40 makes some smp barriers on s390 more efficient included here to avoid merge conflicts, at maintainer's request tested on x86 Davidlohr Bueso (1): lcoking/barriers, arch: Use smp barriers in smp_store_release() Michael S. Tsirkin (40): asm-generic: guard smp_store_release/load_acquire ia64: rename nop->iosapic_nop ia64: reuse asm-generic/barrier.h powerpc: reuse asm-generic/barrier.h s390: reuse asm-generic/barrier.h sparc: reuse asm-...

This is really trying to cleanup some virt code, as suggested by Peter, who said > You could of course go fix that instead of mutilating things into > sort-of functional state. This work is needed for virtio, so it's probably easiest to merge it through my tree - is this fine by everyone? Arnd, if you agree, could you ack this please? Note to arch maintainers: please don't

This is really trying to cleanup some virt code, as suggested by Peter, who said > You could of course go fix that instead of mutilating things into > sort-of functional state. This work is needed for virtio, so it's probably easiest to merge it through my tree - is this fine by everyone? Arnd, if you agree, could you ack this please? Note to arch maintainers: please don't

...sh architecture was missing a 2-byte smp_store_mb, the fix is trivial although my code is not optimal: if anyone cares, pls send me a patch to apply on top. I didn't build this architecture, but intel's 0-day infrastructure builds it. tested on x86 Davidlohr Bueso (1): lcoking/barriers, arch: Use smp barriers in smp_store_release() Michael S. Tsirkin (33): asm-generic: guard smp_store_release/load_acquire ia64: rename nop->iosapic_nop ia64: reuse asm-generic/barrier.h powerpc: reuse asm-generic/barrier.h s390: reuse asm-generic/barrier.h sparc: reuse asm-...

...sh architecture was missing a 2-byte smp_store_mb, the fix is trivial although my code is not optimal: if anyone cares, pls send me a patch to apply on top. I didn't build this architecture, but intel's 0-day infrastructure builds it. tested on x86 Davidlohr Bueso (1): lcoking/barriers, arch: Use smp barriers in smp_store_release() Michael S. Tsirkin (33): asm-generic: guard smp_store_release/load_acquire ia64: rename nop->iosapic_nop ia64: reuse asm-generic/barrier.h powerpc: reuse asm-generic/barrier.h s390: reuse asm-generic/barrier.h sparc: reuse asm-...

...; about 10 minutes. > No success, I waited and waited. Then I reboot w2k. > After reboot I didn't see any printer in Printer folder on samba server. > > OK. I get backuped .tdb . > btw, I copy from backup only printing.tdb and ntdrivers.tdb, so wrong locking is not caused by old lcoking tdb. -- Wire connection and Windows reinstallation senior engineer Dmitry Melekhov http://www.belkam.com/~dm 2:5050/11.23@fidonet Return-Path: <mikes@hartwellcorp.com> Delivered-To: samba@lists.samba.org Received: from guardian.hartwellcorp.com (guardian.hartwellcorp.com [209.223.127.178...