From: Steven Rostedt <rostedt@goodmis.org>
To: Jeff Layton <jlayton@redhat.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
linux-cifs@vger.kernel.org, Steve French <sfrench@samba.org>,
Peter Zijlstra <peterz@infradead.org>,
Clark Williams <williams@redhat.com>,
"Luis Claudio R. Goncalves" <lclaudio@uudg.org>,
Thomas Gleixner <tglx@linutronix.de>, Tejun Heo <tj@kernel.org>,
uobergfe@redhat.com, Pavel Shilovsky <piastryyy@gmail.com>
Subject: Re: [RFC PATCH] cifs: Fix possible deadlock with cifs and work queues
Date: Thu, 20 Mar 2014 22:23:43 -0400 [thread overview]
Message-ID: <20140320222343.4faaa137@gandalf.local.home> (raw)
In-Reply-To: <20140320170239.51d20a0e@tlielax.poochiereds.net>
On Thu, 20 Mar 2014 17:02:39 -0400
Jeff Layton <jlayton@redhat.com> wrote:
> Eventually the server should just allow the read to complete even if
> the client doesn't respond to the oplock break. It has to since clients
> can suddenly drop off the net while holding an oplock. That should
> allow everything to unwedge eventually (though it may take a while).
>
> If that's not happening then I'd be curious as to why...
The problem is that the data is being filled in the page and the reader
is waiting for the page lock to be released. The kworker for the reader
will issue the complete() and unlock the page to wake up the reader.
But because the other workqueue callback calls down_read(), and there
can be a down_write() waiting for the reader to finish, this
down_read() will block on the lock as well (rwsems are fair locks).
This blocks the other workqueue callback from issuing the complete and
page_unlock() that will wake up the reader that is holding the rwsem
with down_read().
DEADLOCK.
-- Steve
next prev parent reply other threads:[~2014-03-21 2:24 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-19 19:12 Steven Rostedt
2014-03-19 19:34 ` Peter Zijlstra
2014-03-19 19:43 ` Steven Rostedt
2014-03-19 19:46 ` Steven Rostedt
2014-03-19 19:47 ` Peter Zijlstra
2014-03-19 20:28 ` Tejun Heo
2014-03-20 19:28 ` Jeffrey Layton
2014-03-20 20:57 ` Steven Rostedt
2014-03-20 21:02 ` Jeff Layton
2014-03-21 2:23 ` Steven Rostedt [this message]
2014-03-21 8:32 ` Pavel Shilovsky
2014-03-21 11:59 ` Jeff Layton
2014-03-21 12:17 ` Steven Rostedt
2014-03-21 12:41 ` Jeff Layton
2014-03-21 12:54 ` Steven Rostedt
2014-03-21 15:07 ` [PATCH v2] " Steven Rostedt
2014-03-23 5:57 ` Shirish Pargaonkar
2014-03-20 23:53 ` [RFC PATCH] " Jeff Layton
2014-03-21 2:19 ` Steven Rostedt
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=20140320222343.4faaa137@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=jlayton@redhat.com \
--cc=lclaudio@uudg.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=piastryyy@gmail.com \
--cc=sfrench@samba.org \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=uobergfe@redhat.com \
--cc=williams@redhat.com \
/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®