mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Davidlohr Bueso <dave@stgolabs.net>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	jbaron@akamai.com, viro@zeniv.linux.org.uk,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH -next 0/2] fs/epoll: loosen irq safety when possible
Date: Sat, 21 Jul 2018 11:31:27 -0700	[thread overview]
Message-ID: <20180721183127.3busfa335zlcjeox@linux-r8p5> (raw)
In-Reply-To: <20180721173944.GV2494@hirez.programming.kicks-ass.net>

On Sat, 21 Jul 2018, Peter Zijlstra wrote:

>On Sat, Jul 21, 2018 at 10:21:20AM -0700, Davidlohr Bueso wrote:
>> On Fri, 20 Jul 2018, Andrew Morton wrote:
>>
>> > We could open-code it locally.  Add a couple of
>> > WARN_ON_ONCE(irqs_disabled())?  That might need re-benchmarking with
>> > Xen but surely just reading the thing isn't too expensive?
>>
>> We could also pass on the responsibility to lockdep and just use
>> lockdep_assert_irqs_disabled(). But I guess that would be less effective
>> than to just open code it in epoll without lockdep -- note that over 80
>> places in the kernel do this.
>
>The lockdep thing is relatively recent. I think someone proposed to go
>replace a bunch of the open-coded ones at some point.

For the open coded checks, I'm seeing a small (1-2% ish) cost for bare
metal on workload 1). I don't see (via code inspection) any additional
overhead in xen either. While negligible in the overall of things, I do
like the idea of lockdep handling it nonetheless.

I can add the open coded version if people really feel that it would catch
more bugs (no lockdep users out there in production afaik :) in the long
term; but if lockdep is where things are headed...

Thanks,
Davidlohr

-------8<--------------------------------------------------------
[PATCH -next 3/2] fs/epoll: robustify irq safety with  lockdep_assert_irqs_enabled()

Sprinkle lockdep_assert_irqs_enabled() checks in the functions that
do not save and restore interrupts when dealing with the ep->wq.lock.
These are ep_scan_ready_list() and those called by epoll_ctl():
ep_insert, ep_modify and ep_remove.

Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
---
 fs/eventpoll.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 1b1abc461fc0..97b9b73dfec8 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -670,6 +670,9 @@ static __poll_t ep_scan_ready_list(struct eventpoll *ep,
 	struct epitem *epi, *nepi;
 	LIST_HEAD(txlist);
 
+	/* must not be called with irqs off */
+	lockdep_assert_irqs_enabled();
+
 	/*
 	 * We need to lock this because we could be hit by
 	 * eventpoll_release_file() and epoll_ctl().
@@ -764,6 +767,9 @@ static int ep_remove(struct eventpoll *ep, struct epitem *epi)
 {
 	struct file *file = epi->ffd.file;
 
+	/* must not be called with irqs off */
+	lockdep_assert_irqs_enabled();
+
 	/*
 	 * Removes poll wait queue hooks.
 	 */
@@ -1412,6 +1418,9 @@ static int ep_insert(struct eventpoll *ep, const struct epoll_event *event,
 	struct epitem *epi;
 	struct ep_pqueue epq;
 
+	/* must not be called with irqs off */
+	lockdep_assert_irqs_enabled();
+
 	user_watches = atomic_long_read(&ep->user->epoll_watches);
 	if (unlikely(user_watches >= max_user_watches))
 		return -ENOSPC;
@@ -1540,6 +1549,9 @@ static int ep_modify(struct eventpoll *ep, struct epitem *epi,
 	int pwake = 0;
 	poll_table pt;
 
+	/* must not be called with irqs off */
+	lockdep_assert_irqs_enabled();
+
 	init_poll_funcptr(&pt, NULL);
 
 	/*
-- 
2.16.4


  reply	other threads:[~2018-07-21 18:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-20 17:29 Davidlohr Bueso
2018-07-20 17:29 ` [PATCH 1/2] fs/epoll: loosen irq safety in ep_scan_ready_list() Davidlohr Bueso
2018-07-20 17:29 ` [PATCH 2/2] fs/epoll: loosen irq safety in epoll_insert() and epoll_remove() Davidlohr Bueso
2018-07-20 19:42 ` [PATCH -next 0/2] fs/epoll: loosen irq safety when possible Andrew Morton
2018-07-20 20:05   ` Davidlohr Bueso
2018-07-20 20:44     ` Andrew Morton
2018-07-21  0:22       ` Davidlohr Bueso
2018-07-21 17:21       ` Davidlohr Bueso
2018-07-21 17:39         ` Peter Zijlstra
2018-07-21 18:31           ` Davidlohr Bueso [this message]
2018-07-24 23:43             ` Andrew Morton
2018-09-06 19:11     ` Peter Zijlstra
2018-09-06 20:55       ` 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=20180721183127.3busfa335zlcjeox@linux-r8p5 \
    --to=dave@stgolabs.net \
    --cc=akpm@linux-foundation.org \
    --cc=jbaron@akamai.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®