From: "J. Bruce Fields" <bfields@fieldses.org>
To: "Myklebust, Trond" <Trond.Myklebust@netapp.com>
Cc: Dave Jones <davej@redhat.com>,
Linux Kernel <linux-kernel@vger.kernel.org>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"Adamson, Dros" <Weston.Adamson@netapp.com>
Subject: Re: nfsd oops on Linus' current tree.
Date: Fri, 21 Dec 2012 18:26:09 -0500 [thread overview]
Message-ID: <20121221232609.GC29739@fieldses.org> (raw)
In-Reply-To: <4FA345DA4F4AE44899BD2B03EEEC2FA911972C73@SACEXCMBX04-PRD.hq.netapp.com>
On Fri, Dec 21, 2012 at 11:15:40PM +0000, Myklebust, Trond wrote:
> Apologies for top-posting. The SSD on my laptop died, and so I'm stuck using webmail for this account...
Fun! If that happens to me on this trip, I've got a week trying to hack
the kernel from my cell phone....
> Our experience with nfsiod is that the WQ_MEM_RECLAIM option still deadlocks despite the "rescuer thread". The CPU that is running the workqueue will deadlock with any rpciod task that is assigned to the same CPU. Interestingly enough, the WQ_UNBOUND option also appears able to deadlock in the same situation.
>
> Sorry, I have no explanation why...
As I said:
> there shouldn't be any deadlock as long as there's no circular
> dependency among the three.
There was a circular dependency (of rpciod on itself), so having a
dedicated rpciod rescuer thread wouldn't help--once the rescuer thread
is waiting for work queued to do the same queue you're asking for
trouble.
The last argument in
alloc_workqueue("rpciod", WQ_MEM_RECLAIM, 1);
ensures that it will never allow more than 1 piece of work to run per
CPU, so the deadlock should be pretty easy to hit.
And with UNBOUND that's only one piece of work globally, so yeah all you
need is an rpc at shutdown time and it should deadlock every time.
--b.
next prev parent reply other threads:[~2012-12-21 23:26 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-21 15:33 nfsd oops on Linus' current tree Dave Jones
2012-12-21 18:08 ` J. Bruce Fields
2012-12-21 18:40 ` Myklebust, Trond
2012-12-21 23:08 ` J. Bruce Fields
2012-12-21 23:15 ` Myklebust, Trond
2012-12-21 23:26 ` J. Bruce Fields [this message]
2012-12-21 23:36 ` Myklebust, Trond
2012-12-21 23:45 ` J. Bruce Fields
2013-01-03 16:28 ` Adamson, Dros
2013-01-03 20:11 ` J. Bruce Fields
2013-01-03 20:27 ` Adamson, Dros
2013-01-03 20:52 ` J. Bruce Fields
2013-01-03 22:15 ` Tejun Heo
2013-01-03 22:08 ` Tejun Heo
2013-01-03 22:12 ` Myklebust, Trond
2013-01-03 22:26 ` Tejun Heo
2013-01-03 22:34 ` Tejun Heo
2013-01-03 23:11 ` Myklebust, Trond
[not found] ` <1357254692.55285.33.camel@lade.trondhjem.org>
2013-01-03 23:26 ` Myklebust, Trond
2013-01-04 17:11 ` Adamson, Dros
2013-01-03 22:03 ` Tejun Heo
2013-01-03 23:08 ` J. Bruce Fields
2012-12-22 0:48 ` [PATCH] Revert "nfsd: warn on odd reply state in nfsd_vfs_read" J. Bruce Fields
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=20121221232609.GC29739@fieldses.org \
--to=bfields@fieldses.org \
--cc=Trond.Myklebust@netapp.com \
--cc=Weston.Adamson@netapp.com \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.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