From: Paul Bolle <pebolle@tiscali.nl>
To: Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org,
Davide Libenzi <davidel@xmailserver.org>,
Nelson Elhage <nelhage@ksplice.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
davidel@xmailserver.org, Dave Jones <davej@redhat.com>
Subject: Re: recursive locking: epoll.
Date: Fri, 29 Jul 2011 20:50:55 +0200 [thread overview]
Message-ID: <1311965462.2351.28.camel@t41.thuisdomein> (raw)
In-Reply-To: <1311249346.2098.12.camel@t41.thuisdomein>
(Sent to the addresses get_maintainer.pl suggested and to Davide and
Nelson, because this is about code they cared about half a year ago.
CC'ed to the addresses involved until now.)
On Thu, 2011-07-21 at 13:55 +0200, Paul Bolle wrote:
> That number turned out to be 722472
> ( https://bugzilla.redhat.com/show_bug.cgi?id=722472 ).
0) This seems to be a lockdep false alarm. The cause is an epoll
instance added to another epoll instance (ie, nesting epoll instances).
Apparently lockdep isn't supplied enough information to determine what's
going on here. Now there might be a number of ways to fix this. But
after having looked at this for quite some time and updating the above
bug report a number of times, I guessed that involving people outside
those tracking that report might move things forward towards a solution.
At least, I wasn't able to find a, well, clean solution.
1) The call chain triggering the warning with the nice
*** DEADLOCK ***
line can be summarized like this:
sys_epoll_ctl
mutex_lock epmutex
ep_call_nested
ep_loop_check_proc
mutex_lock ep->mtx
mutex_unlock ep->mtx
mutex_lock ep->mtx
ep_eventpoll_poll
ep_ptable_queue_proc
ep_call_nested
ep_poll_readyevents_pro
ep_scan_ready_list
mutex_lock ep->mtx
ep_read_events_proc
mutex_unlock ep->mtx
mutex_unlock ep->mtx
mutex_unlock epmutex
2) When ep_scan_ready_list() calls mutex_lock(), lockdep notices
recursive locking on ep->mtx. It is not supplied enough information to
determine that the lock is related to two separate epoll instances (the
outer instance and the nested instance). The solution appears to involve
supplying lockdep that information (ie, "lockdep annotation").
3) Please see the bugzilla.redhat.com report for further background.
Paul Bolle
next prev parent reply other threads:[~2011-07-29 18:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4E1FF63F.4040704@gmail.com>
2011-07-15 21:04 ` Dave Jones
2011-07-20 8:05 ` Paul Bolle
2011-07-21 11:55 ` Paul Bolle
2011-07-29 18:50 ` Paul Bolle [this message]
2011-07-30 18:26 ` Nelson Elhage
2011-07-30 21:25 ` Nelson Elhage
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=1311965462.2351.28.camel@t41.thuisdomein \
--to=pebolle@tiscali.nl \
--cc=davej@redhat.com \
--cc=davidel@xmailserver.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nelhage@ksplice.com \
--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®