All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: "Reshetova, Elena" <elena.reshetova@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
	"tj@kernel.org" <tj@kernel.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"hannes@cmpxchg.org" <hannes@cmpxchg.org>,
	"lizefan@huawei.com" <lizefan@huawei.com>,
	"acme@kernel.org" <acme@kernel.org>,
	"alexander.shishkin@linux.intel.com" 
	<alexander.shishkin@linux.intel.com>,
	"eparis@redhat.com" <eparis@redhat.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"luto@kernel.org" <luto@kernel.org>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"dvhart@infradead.org" <dvhart@infradead.org>,
	"ebiederm@xmission.com" <ebiederm@xmission.com>
Subject: Re: [PATCH 14/15] futex: convert futex_pi_state.refcount to refcount_t
Date: Mon, 4 Sep 2017 14:00:09 +0200	[thread overview]
Message-ID: <20170904120009.ah2qu3lbgdqdgz6i@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <2236FBA76BA1254E88B949DDB74E612B6FF63ED7@IRSMSX102.ger.corp.intel.com>

On Mon, Sep 04, 2017 at 10:31:54AM +0000, Reshetova, Elena wrote:
> > > But can they make "fast" implementation on ARM that would give stronger
> > > memory guarantees?
> > 
> > Whatever for?
> 
> Well, maybe just by default when arch.-specific implementation is
> done. But I was just trying to speculate to understand. I will resend
> this one with new comment added. 

So the generic lib/refcount.c already has weak ordering. It doesn't make
sense for an arch specific implementation (on a weakly ordered machine)
to provide stronger guarantees (it would make things slower).

The weaker ordering of the refcount_t primitives is sufficient if we're
talking pure refcounts. If for some reason code relies on stronger
ordering there _SHOULD_ be a comment with describing the additional
ordering requirements.

But that's a fairly big 'should'. I can well imagine the comment not
being there. In fact, see below.

> Still not sure if I need to resend the whole series with updated
> commits or break this up by individual patches further for the
> separate merges. 

I've yet to look at the ones targeted at subsystems I do, I'm forever
and terminally behind on review :/

I called out the issue on futex in particular because it is fairly
tricky code that.

Now Thomas would like you to mention the fact that refcount_t doesn't
provide the exact same ordering as the atomic_t usages it replaces and
I think it would be good if you could hand-wave an argument on why the
futex code doesn't care.


Now, suppose we were to convert i_count to refcount_t (yes, I know, my
initial conversion wasn't well received), then we need to add
futex_get_inode() similar to futex_get_mm().

That is, smp_mb__{before,after}_atomic() works as expected and can be
used to fortify the implied barriers by refcount_t.

---
Subject: fs,inode: Add comment explaining additional ordering

Add a note to ihold() to document the ordering futex relies upon.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
 fs/inode.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fs/inode.c b/fs/inode.c
index 50370599e371..17192ba92fef 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -395,6 +395,10 @@ void __iget(struct inode *inode)
  */
 void ihold(struct inode *inode)
 {
+	/*
+	 * Note: futex.c:get_futex_key_refs() relies on this function
+	 * implying an smp_mb().
+	 */
 	WARN_ON(atomic_inc_return(&inode->i_count) < 2);
 }
 EXPORT_SYMBOL(ihold);

  reply	other threads:[~2017-09-04 12:00 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-30 12:22 [PATCH 00/15] v5 kernel core pieces refcount conversions Elena Reshetova
2017-08-30 12:22 ` [PATCH 01/15] sched: convert sighand_struct.count to refcount_t Elena Reshetova
2017-08-30 12:22 ` [PATCH 02/15] sched: convert signal_struct.sigcnt " Elena Reshetova
2017-08-30 12:22 ` [PATCH 03/15] sched: convert user_struct.__count " Elena Reshetova
2017-08-30 12:22 ` [PATCH 04/15] sched: convert numa_group.refcount " Elena Reshetova
2017-08-30 12:22 ` [PATCH 05/15] sched/task_struct: convert task_struct.usage " Elena Reshetova
2017-08-30 12:22 ` [PATCH 06/15] sched/task_struct: convert task_struct.stack_refcount " Elena Reshetova
2017-08-30 12:22 ` [PATCH 07/15] perf: convert perf_event_context.refcount " Elena Reshetova
2017-08-30 12:22 ` [PATCH 08/15] perf/ring_buffer: convert ring_buffer.refcount " Elena Reshetova
2017-08-30 12:22 ` [PATCH 09/15] perf/ring_buffer: convert ring_buffer.aux_refcount " Elena Reshetova
2017-08-30 12:22 ` [PATCH 10/15] uprobes: convert uprobe.ref " Elena Reshetova
2017-08-30 12:22 ` [PATCH 11/15] nsproxy: convert nsproxy.count " Elena Reshetova
2017-08-30 12:22 ` [PATCH 12/15] groups: convert group_info.usage " Elena Reshetova
2017-08-30 12:22 ` [PATCH 13/15] creds: convert cred.usage " Elena Reshetova
2017-08-30 12:22 ` [PATCH 14/15] futex: convert futex_pi_state.refcount " Elena Reshetova
2017-09-01  7:39   ` Thomas Gleixner
2017-09-01  9:38     ` Peter Zijlstra
2017-09-01  9:43       ` Thomas Gleixner
2017-09-01 10:52         ` Reshetova, Elena
2017-09-01 10:52           ` Reshetova, Elena
2017-09-01 11:05         ` Reshetova, Elena
2017-09-01 11:05           ` Reshetova, Elena
2017-09-01 12:34           ` Peter Zijlstra
2017-09-01 12:34             ` Peter Zijlstra
2017-09-01 13:24             ` Reshetova, Elena
2017-09-01 13:24               ` Reshetova, Elena
2017-09-01 13:36               ` Peter Zijlstra
2017-09-01 13:36                 ` Peter Zijlstra
2017-09-01 17:03                 ` Reshetova, Elena
2017-09-01 17:03                   ` Reshetova, Elena
2017-09-01 19:12                   ` Peter Zijlstra
2017-09-01 19:12                     ` Peter Zijlstra
2017-09-04 10:31                     ` Reshetova, Elena
2017-09-04 10:31                       ` Reshetova, Elena
2017-09-04 12:00                       ` Peter Zijlstra [this message]
2017-09-04 12:00                         ` Peter Zijlstra
2017-09-14 16:02                         ` Reshetova, Elena
2017-09-14 16:02                           ` Reshetova, Elena
2017-10-20 12:03                           ` Reshetova, Elena
2017-10-20 12:03                             ` Reshetova, Elena
2017-10-20 12:30                             ` Thomas Gleixner
2017-10-20 12:30                               ` Thomas Gleixner
2017-10-23  7:36                               ` Reshetova, Elena
2017-10-23  7:36                                 ` Reshetova, Elena
2017-08-30 12:22 ` [PATCH 15/15] kcov: convert kcov.refcount " Elena Reshetova
2017-08-31 23:48 ` [PATCH 00/15] v5 kernel core pieces refcount conversions Kees Cook
2017-09-01  9:48   ` Peter Zijlstra
2017-09-01 16:55     ` Kees Cook
2017-09-01 17:08       ` Reshetova, Elena
  -- strict thread matches above, loose matches on Subject: below --
2017-08-25  9:41 [PATCH 00/15] v4 " Elena Reshetova
2017-08-25  9:41 ` [PATCH 14/15] futex: convert futex_pi_state.refcount to refcount_t Elena Reshetova
2017-07-18 10:29 [PATCH 00/15] v4 kernel core pieces refcount conversions Elena Reshetova
2017-07-18 10:30 ` [PATCH 14/15] futex: convert futex_pi_state.refcount to refcount_t Elena Reshetova

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=20170904120009.ah2qu3lbgdqdgz6i@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=dvhart@infradead.org \
    --cc=ebiederm@xmission.com \
    --cc=elena.reshetova@intel.com \
    --cc=eparis@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=keescook@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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.