On Tue, Dec 23, 2014 at 1:43 PM, Benjamin LaHaise <bcrl@xxxxxxxxx>
wrote:
On Mon, Dec 22, 2014 at 07:16:25PM -0500, Chris Mason wrote:
The 3.19 merge window brought in a great new warning to catch
someone
calling might_sleep with their state != TASK_RUNNING. The idea was
to
find buggy code locking mutexes after calling prepare_to_wait(),
kind
of like this:
...
This has been lightly tested and hasn't been benchmarked, so RFC for
now.
This was on my list of things to look at today.
I'm not at all happy with this particular patch. It looks like this
issue
was introduced back in 3.10 by Kent's big overhaul of things. The
main
benefit Kent's changes achieved stems from holding ring_lock across
fetching
multiple events rather than taking the spin lock for every event. I'm
going to see if I can come up with a simpler way of fixing this.
Works for me, the patch is mostly a (somewhat commented) list of all
the places we're currently doing it wrong.
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
