From: Davidlohr Bueso <dave@stgolabs.net>
To: Mel Gorman <mgorman@techsingularity.net>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@kernel.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Chris Mason <clm@fb.com>, Darren Hart <dvhart@linux.intel.com>,
linux-kernel@vger.kernel.org, Davidlohr Bueso <dbueso@suse.de>
Subject: Re: [PATCH v3] futex: Remove requirement for lock_page in
Date: Wed, 20 Jan 2016 11:55:23 -0800 [thread overview]
Message-ID: <20160120195523.GF27825@linux-uzut.site> (raw)
In-Reply-To: <1453249853-1184-1-git-send-email-dave@stgolabs.net>
On Tue, 19 Jan 2016, Bueso wrote:
> /*
> * Private mappings are handled in a simple way.
> *
>+ * If the futex key is stored on an anonymous page, then the associated
>+ * object is the mm which is implicitly pinned by the calling process.
>+ *
> * NOTE: When userspace waits on a MAP_SHARED mapping, even if
> * it's a read-only handle, it's expected that futexes attach to
> * the object not the particular process.
>@@ -566,16 +592,61 @@ again:
> key->both.offset |= FUT_OFF_MMSHARED; /* ref taken on mm */
> key->private.mm = mm;
> key->private.address = address;
>+
>+ get_futex_key_refs(key); /* implies MB (B) */
>+
> } else {
>+ struct inode *inode;
>+
>+ /*
>+ * The associtated futex object in this case is the inode and
>+ * the page->mapping must be traversed. Ordinarily this should
>+ * be stabilised under page lock but it's not strictly
>+ * necessary in this case as we just want to pin the inode, not
>+ * update radix tree or anything like that.
>+ *
>+ * The RCU read lock is taken as the inode is finally freed
>+ * under RCU. If the mapping still matches expectations then the
>+ * mapping->host can be safely accessed as being a valid inode.
>+ */
>+ rcu_read_lock();
>+ if (READ_ONCE(page->mapping) != mapping ||
>+ !mapping->host) {
>+ rcu_read_unlock();
>+ put_page(page);
>+
>+ goto again;
>+ }
>+ inode = READ_ONCE(mapping->host);
>+
>+ /*
>+ * Take a reference unless it is about to be freed. Previously
>+ * this reference was taken by ihold under the page lock
>+ * pinning the inode in place so i_lock was unnecessary. The
>+ * only way for this check to fail is if the inode was
>+ * truncated in parallel so warn for now if this happens.
>+ *
>+ * We are not calling into get_futex_key_refs() in file-backed
>+ * cases, therefore a successful atomic_inc return below will
>+ * guarantee that get_futex_key() will continue to imply MB (B).
>+ */
>+ if (WARN_ON_ONCE(!atomic_inc_not_zero(&inode->i_count))) {
>+ rcu_read_unlock();
>+ put_page(page);
>+
>+ goto again;
>+ }
>+
>+ /* Should be impossible but lets be paranoid for now */
>+ BUG_ON(inode->i_mapping != mapping);
Hmm, do we want to transform this into an if and do rcu unlock and then just
call BUG()? I't doesn't matter at this point _anyway_, but it would be the right
thing to do, no?
>+
> key->both.offset |= FUT_OFF_INODE; /* inode-based key */
>- key->shared.inode = mapping->host;
>+ key->shared.inode = inode;
> key->shared.pgoff = basepage_index(page);
>+ rcu_read_unlock();
> }
>
>- get_futex_key_refs(key); /* implies MB (B) */
>-
> out:
>- unlock_page(page);
> put_page(page);
> return err;
> }
next prev parent reply other threads:[~2016-01-20 19:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-20 0:30 [PATCH v3] futex: Remove requirement for lock_page in Davidlohr Bueso
2016-01-20 14:03 ` Mel Gorman
2016-01-20 19:55 ` Davidlohr Bueso [this message]
2016-01-20 20:01 ` Thomas Gleixner
2016-01-20 20:20 ` Davidlohr Bueso
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=20160120195523.GF27825@linux-uzut.site \
--to=dave@stgolabs.net \
--cc=bigeasy@linutronix.de \
--cc=clm@fb.com \
--cc=dbueso@suse.de \
--cc=dvhart@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@techsingularity.net \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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.