From: Tim Hockin <thockin@sun.com>
To: Linux Kernel mailing list <linux-kernel@vger.kernel.org>
Subject: calling flush_scheduled_work()
Date: Fri, 12 Mar 2004 12:58:15 -0800 [thread overview]
Message-ID: <20040312205814.GY1333@sun.com> (raw)
We've recently bumped into an issue, and I'm not sure which is the real bug.
In short we have a case where mntput() is called from the kevetd workqueue.
When that mntput() hit an NFS mount, we got a deadlock. It turns out that
deep in the RPC code, someone calls flush_scheduled_work(). Deadlock.
So what is the real bug?
Is it verboten to call mntput() from keventd? What other things might lead
to a flush_scheduled_work() and must therefore be avoided?
Should callers of flush_scheduled_work() be changed to use private
workqueues? There are 31 calls that I got from grep. 25 are in drivers/, 1
in ncpfs, 3 in nfs4, 2 in sunrpc. The drivers/ are *probably* ok. Should
those other 6 be changed?
Either way, it seems like there should maybe be a check and a badness
warning if flush_workqueue is called from that workqueue.
Which avenue should we follow? Our own problem can be fixed differently,
but I didn't want to just ignore this unstated assumption that it is safe to
call flush_scheduled_work() anywhere.
Tim
--
Tim Hockin
Sun Microsystems, Linux Software Engineering
thockin@sun.com
All opinions are my own, not Sun's
next reply other threads:[~2004-03-12 21:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-12 20:58 Tim Hockin [this message]
2004-03-12 22:00 ` calling flush_scheduled_work() Trond Myklebust
2004-03-12 22:38 ` Tim Hockin
2004-03-12 23:19 ` Trond Myklebust
2004-03-12 23:27 ` Tim Hockin
2004-03-12 23:27 ` Andrew Morton
2004-03-13 0:20 ` Tim Hockin
2004-03-13 1:17 ` Trond Myklebust
2004-03-13 2:12 ` Andrew Morton
2004-03-13 2:24 ` Trond Myklebust
-- strict thread matches above, loose matches on Subject: below --
2004-03-13 11:45 Stefan Rompf
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=20040312205814.GY1333@sun.com \
--to=thockin@sun.com \
--cc=linux-kernel@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