All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Paul Turner <pjt@google.com>, Andrew Hunter <ahh@google.com>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
	Andy Lutomirski <luto@amacapital.net>,
	Andi Kleen <andi@firstfloor.org>,
	Dave Watson <davejwatson@fb.com>, Chris Lameter <cl@linux.com>,
	Ingo Molnar <mingo@redhat.com>, Ben Maurer <bmaurer@fb.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Josh Triplett <josh@joshtriplett.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Russell King <linux@arm.linux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Michael Kerrisk <mtk.manpages@gmail.com>
Subject: Re: [RFC PATCH 1/3] getcpu_cache system call: cache CPU number of running thread
Date: Tue, 5 Jan 2016 12:04:01 +0000	[thread overview]
Message-ID: <20160105120400.GD10705@arm.com> (raw)
In-Reply-To: <1451977320-4886-2-git-send-email-mathieu.desnoyers@efficios.com>

Hi Mathieu,

On Tue, Jan 05, 2016 at 02:01:58AM -0500, Mathieu Desnoyers wrote:
> Expose a new system call allowing threads to register userspace memory
> areas where to store the CPU number on which the calling thread is
> running. Scheduler migration sets the TIF_NOTIFY_RESUME flag on the
> current thread. Upon return to user-space, a notify-resume handler
> updates the current CPU value within each registered user-space memory
> area. User-space can then read the current CPU number directly from
> memory.

What guarantees do you provide if a thread other than the one which
registered the cache tries to access the value? Obviously, there's a
potential data race here with the kernel issuing a parallel update, but
are you intending to have single-copy atomicity semantics (like relaxed
atomics in C11) or is this simply going to give you junk?

I ask because, in the absence of alignment checks on the cache pointer,
we can't guarantee single-copy atomicity on ARM when the kernel writes
the current CPU value.

Cheers,

Will

  reply	other threads:[~2016-01-05 12:04 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-05  7:01 [RFC PATCH 0/3] Implement getcpu_cache system call Mathieu Desnoyers
2016-01-05  7:01 ` Mathieu Desnoyers
2016-01-05  7:01 ` [RFC PATCH 1/3] getcpu_cache system call: cache CPU number of running thread Mathieu Desnoyers
2016-01-05  7:01   ` Mathieu Desnoyers
2016-01-05 12:04   ` Will Deacon [this message]
2016-01-05 17:31     ` Mathieu Desnoyers
2016-01-05 17:34       ` Mathieu Desnoyers
2016-01-05 17:34         ` Mathieu Desnoyers
2016-01-05 17:40       ` Russell King - ARM Linux
2016-01-05 17:40         ` Russell King - ARM Linux
2016-01-05 17:49         ` Mathieu Desnoyers
2016-01-05 21:47         ` Paul E. McKenney
2016-01-05 21:47           ` Paul E. McKenney
2016-01-05 22:34           ` Mathieu Desnoyers
2016-01-05 22:34             ` Mathieu Desnoyers
2016-01-05 22:54             ` Paul E. McKenney
2016-01-05 22:54               ` Paul E. McKenney
2016-01-05  7:01 ` [RFC PATCH 2/3] getcpu_cache: wire up ARM system call Mathieu Desnoyers
2016-01-05  7:02 ` [RFC PATCH 3/3] getcpu_cache: wire up x86 32/64 " Mathieu Desnoyers
2016-01-05  7:02   ` Mathieu Desnoyers
2016-01-11 22:38 ` [RFC PATCH 0/3] Implement getcpu_cache " Seymour, Shane M
2016-01-11 22:38   ` Seymour, Shane M
2016-01-11 23:03   ` Josh Triplett
2016-01-12  0:49     ` Mathieu Desnoyers
2016-01-12  0:49       ` Mathieu Desnoyers
2016-01-12  2:45       ` Josh Triplett
2016-01-12  4:27         ` Ben Maurer
2016-01-12  4:27           ` Ben Maurer
2016-01-12  6:40           ` Seymour, Shane M
2016-01-12  6:40             ` Seymour, Shane M
2016-01-12 13:15           ` Mathieu Desnoyers
2016-01-12 13:15             ` Mathieu Desnoyers
2016-01-12 21:02             ` Ben Maurer
2016-01-12 21:02               ` Ben Maurer
2016-01-13  0:22               ` Mathieu Desnoyers
2016-01-13  0:22                 ` Mathieu Desnoyers
2016-01-13  0:51                 ` Josh Triplett
2016-01-13  0:51                   ` Josh Triplett
2016-01-14 15:58                   ` Mathieu Desnoyers
2016-01-14 15:58                     ` Mathieu Desnoyers
2016-01-11 23:16   ` Seymour, Shane M
2016-01-11 23:16     ` Seymour, Shane M

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=20160105120400.GD10705@arm.com \
    --to=will.deacon@arm.com \
    --cc=ahh@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=bmaurer@fb.com \
    --cc=catalin.marinas@arm.com \
    --cc=cl@linux.com \
    --cc=davejwatson@fb.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=luto@amacapital.net \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@redhat.com \
    --cc=mtk.manpages@gmail.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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.