On 01/21/2015 05:12 PM, Davidlohr Bueso wrote: > On Wed, 2015-01-21 at 22:37 +0100, Bruno Prémont wrote: >> On Wed, 21 January 2015 Bruno Prémont wrote: >>> On Tue, 20 January 2015 Linus Torvalds wrote: >>>> On Tue, Jan 20, 2015 at 6:02 AM, Bruno Prémont wrote: >>>>> >>>>> No idea yet which rc is the offender (nor exact patch), but on my not >>>>> so recent UP laptop with a pccard slot I have 2 pccardd kernel threads >>>>> converting my laptop into a heater.
[...] >> Bisecting to the end did point me at (the warning traces produced in great >> quantities might not be the very same issue as the abusive CPU usage, but >> certainly look very related): >> [CCing people on CC for the patch] >> >> commit 8eb23b9f35aae413140d3fda766a98092c21e9b0 >> Author: Peter Zijlstra <pet...@infradead.org> >> Date: Wed Sep 24 10:18:55 2014 +0200 [...] >> Which does produce the following trace (hand-copied most important parts of >> it): >> Warning: CPU 0 PID: 68 at kernel/sched/core.c:7311 >> __might_sleep+0x143/0x170 >> do not call blocking ops when !TASK_RUNNING; state=1 set at [<c1436390>] >> pccardd+0xa0/0x3e0 >> ... >> Call trace: >> ... >> __might_sleep+0x143/0x170 >> ? pccardd+0xa0/0x3e0 >> ? pccardd+0xa0/0x3e0 >> mutex_lock+0x17/0x2a >> pccardd+0xe9/0x3e0 >> ? pcmcia_socket_uevent+0x30/0x30 >> >> pccardd() is located in drivers/pcmcia/cs.c and seems to be of the structure >> Peter's patch wants to warn about. > > Yeah setting current to interruptable so early in the game is bogus. It > should be set after unlocking the skt_mutex. Yeah, but the debug check is triggering worse behavior, requiring bisecting back to the debug commit. How does the might_sleep() check here guarantee the task won't sleep? Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/