From: Michel Lespinasse <walken@google.com>
To: Oleg Nesterov <oleg@redhat.com>,
David Howells <dhowells@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>
Cc: torvalds@linux-foundation.org, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: [RFC PATCH 1/5] kernel: add tasklist_{read,write}_lock{,_any} helper functions
Date: Thu, 7 Mar 2013 20:37:13 -0800 [thread overview]
Message-ID: <1362717437-1729-2-git-send-email-walken@google.com> (raw)
In-Reply-To: <1362717437-1729-1-git-send-email-walken@google.com>
Add tasklist_{read,write}_lock{,_any} functions to acquire/release the
tasklist_lock.
The _any variants may be called from any context, while the others must
be called from process context only.
One of the objectives here is to add explicit annotations for this.
If the call sites for the _any variants could be eliminated somehow,
all remaining tasklist_lock acquisitions would be in process context
so we wouldn't have to use an unfair rwlock_t implementation anymore.
Signed-off-by: Michel Lespinasse <walken@google.com>
---
include/linux/sched.h | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index ac8dbca5ea15..4eb58b796261 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -218,6 +218,7 @@ extern char ___assert_task_state[1 - 2*!!(
#define TASK_COMM_LEN 16
#include <linux/spinlock.h>
+#include <linux/hardirq.h>
/*
* This serializes "schedule()" and also protects
@@ -228,6 +229,43 @@ extern char ___assert_task_state[1 - 2*!!(
extern rwlock_t tasklist_lock;
extern spinlock_t mmlist_lock;
+static inline void tasklist_write_lock(void)
+{
+ WARN_ON_ONCE(in_serving_softirq() || in_irq() || in_nmi());
+ write_lock_irq(&tasklist_lock);
+}
+
+static inline void tasklist_write_unlock(void)
+{
+ write_unlock_irq(&tasklist_lock);
+}
+
+static inline void tasklist_read_lock(void)
+{
+ WARN_ON_ONCE(in_serving_softirq() || in_irq() || in_nmi());
+ read_lock(&tasklist_lock);
+}
+
+static inline void tasklist_read_unlock(void)
+{
+ read_unlock(&tasklist_lock);
+}
+
+static inline void tasklist_read_lock_any(void)
+{
+ read_lock(&tasklist_lock);
+}
+
+static inline int tasklist_read_trylock_any(void)
+{
+ return read_trylock(&tasklist_lock);
+}
+
+static inline void tasklist_read_unlock_any(void)
+{
+ read_unlock(&tasklist_lock);
+}
+
struct task_struct;
#ifdef CONFIG_PROVE_RCU
--
1.8.1.3
next prev parent reply other threads:[~2013-03-08 4:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-08 4:37 [RFC PATCH 0/5] tasklist_lock fairness issues Michel Lespinasse
2013-03-08 4:37 ` Michel Lespinasse [this message]
2013-03-08 4:37 ` [RFC PATCH 2/5] kernel: use tasklist_read_lock_any() when locking tasklist in irq context Michel Lespinasse
2013-03-08 4:37 ` [RFC PATCH 3/5] kernel: use tasklist_{read,write}_lock() to lock tasklist in process context Michel Lespinasse
2013-03-08 4:37 ` [RFC PATCH 4/5] kernel: add ticket based fair rwlock Michel Lespinasse
2013-03-08 4:37 ` [RFC PATCH 5/5] kernel: make tasklist_lock fair for process context call sites Michel Lespinasse
2013-03-09 18:26 ` [RFC PATCH 0/5] tasklist_lock fairness issues Oleg Nesterov
2013-03-10 2:37 ` Michel Lespinasse
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=1362717437-1729-2-git-send-email-walken@google.com \
--to=walken@google.com \
--cc=akpm@linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox