[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54C02E08.4080405@hurleysoftware.com>
Date: Wed, 21 Jan 2015 17:54:00 -0500
From: Peter Hurley <peter@...leysoftware.com>
To: Davidlohr Bueso <dave@...olabs.net>,
Bruno Prémont <bonbons@...ux-vserver.org>,
Peter Zijlstra <peterz@...radead.org>
CC: Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
tglx@...utronix.de, ilya.dryomov@...tank.com,
umgwanakikbuti@...il.com, oleg@...hat.com
Subject: Re: Linux 3.19-rc5
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 <peterz@...radead.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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists