All of lore.kernel.org
 help / color / mirror / Atom feed
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: sasha.levin@oracle.com
Cc: jeremy@goop.org,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	kvm@vger.kernel.org, peterz@infradead.org,
	virtualization@lists.linux-foundation.org,
	paul.gortmaker@windriver.com, hpa@zytor.com, ak@linux.intel.com,
	a.ryabinin@samsung.com, x86@kernel.org, borntraeger@de.ibm.com,
	mingo@redhat.com, xen-devel@lists.xenproject.org,
	paulmck@linux.vnet.ibm.com, riel@redhat.com,
	konrad.wilk@oracle.com, dave@stgolabs.net, davej@redhat.com,
	tglx@linutronix.de, waiman.long@hp.com, oleg@redhat.com,
	linux-kernel@vger.kernel.org, pbonzini@redhat.com,
	akpm@linux-foundation.org, torvalds@linux-foundation.org
Subject: Re: [PATCH V5] x86 spinlock: Fix memory corruption on completing completions
Date: Sun, 15 Feb 2015 11:31:54 +0530	[thread overview]
Message-ID: <54E03652.8010104@linux.vnet.ibm.com> (raw)
In-Reply-To: <1423979744-18320-1-git-send-email-raghavendra.kt@linux.vnet.ibm.com>

On 02/15/2015 11:25 AM, Raghavendra K T wrote:
> Paravirt spinlock clears slowpath flag after doing unlock.
> As explained by Linus currently it does:
>                  prev = *lock;
>                  add_smp(&lock->tickets.head, TICKET_LOCK_INC);
>
>                  /* add_smp() is a full mb() */
>
>                  if (unlikely(lock->tickets.tail & TICKET_SLOWPATH_FLAG))
>                          __ticket_unlock_slowpath(lock, prev);
>
> which is *exactly* the kind of things you cannot do with spinlocks,
> because after you've done the "add_smp()" and released the spinlock
> for the fast-path, you can't access the spinlock any more.  Exactly
> because a fast-path lock might come in, and release the whole data
> structure.
>
> Linus suggested that we should not do any writes to lock after unlock(),
> and we can move slowpath clearing to fastpath lock.
>
> So this patch implements the fix with:
> 1. Moving slowpath flag to head (Oleg):
> Unlocked locks don't care about the slowpath flag; therefore we can keep
> it set after the last unlock, and clear it again on the first (try)lock.
> -- this removes the write after unlock. note that keeping slowpath flag would
> result in unnecessary kicks.
> By moving the slowpath flag from the tail to the head ticket we also avoid
> the need to access both the head and tail tickets on unlock.
>
> 2. use xadd to avoid read/write after unlock that checks the need for
> unlock_kick (Linus):
> We further avoid the need for a read-after-release by using xadd;
> the prev head value will include the slowpath flag and indicate if we
> need to do PV kicking of suspended spinners -- on modern chips xadd
> isn't (much) more expensive than an add + load.
>
> Result:
>   setup: 16core (32 cpu +ht sandy bridge 8GB 16vcpu guest)
>   benchmark overcommit %improve
>   kernbench  1x           -0.13
>   kernbench  2x            0.02
>   dbench     1x           -1.77
>   dbench     2x           -0.63
>
> [Jeremy: hinted missing TICKET_LOCK_INC for kick]
> [Oleg: Moving slowpath flag to head, ticket_equals idea]
> [PeterZ: Detailed changelog]
>
> Reported-by: Sasha Levin <sasha.levin@oracle.com>
> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---

Sasha, Hope this addresses invalid read concern you had with latest
xadd based implementation.

(Think we need to test without Oleg's PATCH] sched/completion: 
completion_done() should serialize with complete() reported by Paul.)

WARNING: multiple messages have this Message-ID (diff)
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: sasha.levin@oracle.com
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
	peterz@infradead.org, torvalds@linux-foundation.org,
	konrad.wilk@oracle.com, pbonzini@redhat.com,
	paulmck@linux.vnet.ibm.com, waiman.long@hp.com, davej@redhat.com,
	oleg@redhat.com, x86@kernel.org, jeremy@goop.org,
	paul.gortmaker@windriver.com, ak@linux.intel.com,
	jasowang@redhat.com, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org, virtualization@lists.linux-foundation.org,
	xen-devel@lists.xenproject.org, riel@redhat.com,
	borntraeger@de.ibm.com, akpm@linux-foundation.org,
	a.ryabinin@samsung.com, dave@stgolabs.net
Subject: Re: [PATCH V5] x86 spinlock: Fix memory corruption on completing completions
Date: Sun, 15 Feb 2015 11:31:54 +0530	[thread overview]
Message-ID: <54E03652.8010104@linux.vnet.ibm.com> (raw)
In-Reply-To: <1423979744-18320-1-git-send-email-raghavendra.kt@linux.vnet.ibm.com>

On 02/15/2015 11:25 AM, Raghavendra K T wrote:
> Paravirt spinlock clears slowpath flag after doing unlock.
> As explained by Linus currently it does:
>                  prev = *lock;
>                  add_smp(&lock->tickets.head, TICKET_LOCK_INC);
>
>                  /* add_smp() is a full mb() */
>
>                  if (unlikely(lock->tickets.tail & TICKET_SLOWPATH_FLAG))
>                          __ticket_unlock_slowpath(lock, prev);
>
> which is *exactly* the kind of things you cannot do with spinlocks,
> because after you've done the "add_smp()" and released the spinlock
> for the fast-path, you can't access the spinlock any more.  Exactly
> because a fast-path lock might come in, and release the whole data
> structure.
>
> Linus suggested that we should not do any writes to lock after unlock(),
> and we can move slowpath clearing to fastpath lock.
>
> So this patch implements the fix with:
> 1. Moving slowpath flag to head (Oleg):
> Unlocked locks don't care about the slowpath flag; therefore we can keep
> it set after the last unlock, and clear it again on the first (try)lock.
> -- this removes the write after unlock. note that keeping slowpath flag would
> result in unnecessary kicks.
> By moving the slowpath flag from the tail to the head ticket we also avoid
> the need to access both the head and tail tickets on unlock.
>
> 2. use xadd to avoid read/write after unlock that checks the need for
> unlock_kick (Linus):
> We further avoid the need for a read-after-release by using xadd;
> the prev head value will include the slowpath flag and indicate if we
> need to do PV kicking of suspended spinners -- on modern chips xadd
> isn't (much) more expensive than an add + load.
>
> Result:
>   setup: 16core (32 cpu +ht sandy bridge 8GB 16vcpu guest)
>   benchmark overcommit %improve
>   kernbench  1x           -0.13
>   kernbench  2x            0.02
>   dbench     1x           -1.77
>   dbench     2x           -0.63
>
> [Jeremy: hinted missing TICKET_LOCK_INC for kick]
> [Oleg: Moving slowpath flag to head, ticket_equals idea]
> [PeterZ: Detailed changelog]
>
> Reported-by: Sasha Levin <sasha.levin@oracle.com>
> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---

Sasha, Hope this addresses invalid read concern you had with latest
xadd based implementation.

(Think we need to test without Oleg's PATCH] sched/completion: 
completion_done() should serialize with complete() reported by Paul.)


  parent reply	other threads:[~2015-02-15  6:01 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-15  5:55 [PATCH V5] x86 spinlock: Fix memory corruption on completing completions Raghavendra K T
2015-02-15  5:55 ` Raghavendra K T
2015-02-15  5:55 ` Raghavendra K T
2015-02-15  6:01 ` Raghavendra K T
2015-02-15  6:01 ` Raghavendra K T [this message]
2015-02-15  6:01   ` Raghavendra K T
2015-02-17 18:26   ` Sasha Levin
2015-02-17 18:26   ` Sasha Levin
2015-02-17 18:26     ` Sasha Levin
2015-02-15 16:17 ` Oleg Nesterov
2015-02-15 16:17 ` Oleg Nesterov
2015-02-15 16:17   ` Oleg Nesterov
2015-02-15 17:34   ` Raghavendra K T
2015-02-15 17:34   ` Raghavendra K T
2015-02-15 17:34   ` Raghavendra K T
2015-02-15 17:30 ` Raghavendra K T
2015-02-15 17:30   ` Raghavendra K T
2015-02-15 17:30   ` Raghavendra K T
2015-02-15 20:31   ` Oleg Nesterov
2015-02-15 20:31   ` Oleg Nesterov
2015-02-15 20:31     ` Oleg Nesterov
2015-02-16 16:47   ` David Vrabel
2015-02-16 16:47   ` [Xen-devel] " David Vrabel
2015-02-16 16:47     ` David Vrabel
2015-02-17 10:03     ` Raghavendra K T
2015-02-17 10:03     ` Raghavendra K T
2015-02-17 10:03     ` Raghavendra K T
2015-02-18 17:07   ` [tip:locking/core] x86/spinlocks/paravirt: Fix memory corruption on unlock tip-bot for Raghavendra K T
2015-02-15 17:30 ` [PATCH V5] x86 spinlock: Fix memory corruption on completing completions Raghavendra K T
  -- strict thread matches above, loose matches on Subject: below --
2015-02-15  5:55 Raghavendra K T

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54E03652.8010104@linux.vnet.ibm.com \
    --to=raghavendra.kt@linux.vnet.ibm.com \
    --cc=a.ryabinin@samsung.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=borntraeger@de.ibm.com \
    --cc=dave@stgolabs.net \
    --cc=davej@redhat.com \
    --cc=hpa@zytor.com \
    --cc=jeremy@goop.org \
    --cc=konrad.wilk@oracle.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=paul.gortmaker@windriver.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=sasha.levin@oracle.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=waiman.long@hp.com \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.