search for: davidlohr

...ov 30, 2018 at 11:27 AM Jarkko Sakkinen ><jarkko.sakkinen at linux.intel.com> wrote: >> >> In order to comply with the CoC, replace **** with a hug. I hope this is some kind of joke. How would anyone get offended by reading technical comments? This is all beyond me... Thanks, Davidlohr

...--------- virtio: barrier rework+fixes This adds a new kind of barrier, 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 power...

...--------- virtio: barrier rework+fixes This adds a new kind of barrier, 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 power...

...^^ detect >+ * and break. Could you please remove the rest of this comment? Its just noise to point out that vcpu_is_preempted is a macro defined by arch/false. This is standard protocol in the kernel. Same goes for all locks you change with this. Thanks, Davidlohr > * vcpu_is_preempted is a macro defined by false if >+ * arch does not support vcpu preempted check, > */ >- if (need_resched()) >+ if (need_resched() || vcpu_is_preempted(node_cpu(node->prev))) > goto unqueue; > > cpu_relax_lowlatency(); >...

...^^ detect >+ * and break. Could you please remove the rest of this comment? Its just noise to point out that vcpu_is_preempted is a macro defined by arch/false. This is standard protocol in the kernel. Same goes for all locks you change with this. Thanks, Davidlohr > * vcpu_is_preempted is a macro defined by false if >+ * arch does not support vcpu preempted check, > */ >- if (need_resched()) >+ if (need_resched() || vcpu_is_preempted(node_cpu(node->prev))) > goto unqueue; > > cpu_relax_lowlatency(); >...

On 11/30/18 12:56 PM, Davidlohr Bueso wrote: > On Fri, 30 Nov 2018, Kees Cook wrote: > >> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen >> <jarkko.sakkinen at linux.intel.com> wrote: >>> >>> In order to comply with the CoC, replace **** with a hug. > > I hope this is some kind...

On Fri, 2015-02-06 at 08:25 -0800, Linus Torvalds wrote: > On Fri, Feb 6, 2015 at 6:49 AM, Raghavendra K T > <raghavendra.kt at linux.vnet.ibm.com> wrote: > > Paravirt spinlock clears slowpath flag after doing unlock. > [ fix edited out ] > > So I'm not going to be applying this for 3.19, because it's much too > late and the patch is too scary. Plus the bug

On Fri, 2015-02-06 at 08:25 -0800, Linus Torvalds wrote: > On Fri, Feb 6, 2015 at 6:49 AM, Raghavendra K T > <raghavendra.kt at linux.vnet.ibm.com> wrote: > > Paravirt spinlock clears slowpath flag after doing unlock. > [ fix edited out ] > > So I'm not going to be applying this for 3.19, because it's much too > late and the patch is too scary. Plus the bug

mb() typically uses mfence on modern x86, but a micro-benchmark shows that it's 2 to 3 times slower than lock; addl that we use on older CPUs. So we really should use the locked variant everywhere, except that intel manual says that clflush is only ordered by mfence, so we can't. Note: some callers of clflush seems to assume sfence will order it, so there could be existing bugs around

mb() typically uses mfence on modern x86, but a micro-benchmark shows that it's 2 to 3 times slower than lock; addl that we use on older CPUs. So we really should use the locked variant everywhere, except that intel manual says that clflush is only ordered by mfence, so we can't. Note: some callers of clflush seems to assume sfence will order it, so there could be existing bugs around

On Sun, Jan 10, 2016 at 04:16:32PM +0200, Michael S. Tsirkin wrote: > 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 v...

On Sun, Jan 10, 2016 at 04:16:32PM +0200, Michael S. Tsirkin wrote: > 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 v...

On Friday, 30 November 2018 20:35:07 GMT David Miller wrote: > From: Jens Axboe <axboe at kernel.dk> > Date: Fri, 30 Nov 2018 13:12:26 -0700 > > > On 11/30/18 12:56 PM, Davidlohr Bueso wrote: > >> On Fri, 30 Nov 2018, Kees Cook wrote: > >> > >>> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen > >>> <jarkko.sakkinen at linux.intel.com> wrote: > >>>> > >>>> In order to comply with the CoC, replace...

On Fri, 04 Oct 2019, Michel Lespinasse wrote: >On Thu, Oct 03, 2019 at 01:18:54PM -0700, Davidlohr Bueso wrote: >> @@ -1320,15 +1320,14 @@ static bool iotlb_access_ok(struct vhost_virtqueue *vq, >> { >> const struct vhost_umem_node *node; >> struct vhost_umem *umem = vq->iotlb; >> - u64 s = 0, size, orig_addr = addr, last = addr + len - 1; >> + u64 s =...

...'end', which both a more suitable name for the half closed interval and also reduces the chances of some caller being missed. Cc: Michael S. Tsirkin" <mst at redhat.com> Cc: Jason Wang <jasowang at redhat.com> Cc: virtualization at lists.linux-foundation.org Signed-off-by: Davidlohr Bueso <dbueso at suse.de> --- drivers/vhost/vhost.c | 19 +++++++++---------- drivers/vhost/vhost.h | 4 ++-- 2 files changed, 11 insertions(+), 12 deletions(-) diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index 36ca2cf419bf..80c3cca24dc7 100644 --- a/drivers/vhost/vhost.c ++...

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(), respectin...

...This adds a new kind of barrier, 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:...

Am 01.12.2018 um 09:12 schrieb Jens Axboe: > On 11/30/18 12:56 PM, Davidlohr Bueso wrote: >> On Fri, 30 Nov 2018, Kees Cook wrote: >> >>> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen >>> <jarkko.sakkinen at linux.intel.com> wrote: >>>> >>>> In order to comply with the CoC, replace **** with a hug. >> >...

From: Jens Axboe <axboe at kernel.dk> Date: Fri, 30 Nov 2018 13:12:26 -0700 > On 11/30/18 12:56 PM, Davidlohr Bueso wrote: >> On Fri, 30 Nov 2018, Kees Cook wrote: >> >>> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen >>> <jarkko.sakkinen at linux.intel.com> wrote: >>>> >>>> In order to comply with the CoC, replace **** with a hug. >> &g...

...i, 30 Nov 2018 20:39:01 +0000 Abuse <abuse at 2.abuse.bgcomp.co.uk> wrote: > On Friday, 30 November 2018 20:35:07 GMT David Miller wrote: > > From: Jens Axboe <axboe at kernel.dk> > > Date: Fri, 30 Nov 2018 13:12:26 -0700 > > > > > On 11/30/18 12:56 PM, Davidlohr Bueso wrote: > > >> On Fri, 30 Nov 2018, Kees Cook wrote: > > >> > > >>> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen > > >>> <jarkko.sakkinen at linux.intel.com> wrote: > > >>>> > > >>>> In o...