linux-kernel - Re: next-20090202: task kmemleak:763 blocked for more than 120 seconds.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 2 Feb 2009 13:57:40 -0800
From:	Mandeep Singh Baines <msb@...gle.com>
To:	Frédéric Weisbecker <fweisbec@...il.com>
Cc:	Catalin Marinas <catalin.marinas@....com>,
	Alexander Beregalov <a.beregalov@...il.com>,
	"linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: next-20090202: task kmemleak:763 blocked for more than 120 seconds.

Frédéric Weisbecker (fweisbec@...il.com) wrote:
> 2009/2/2 Catalin Marinas <catalin.marinas@....com>:
> > Alexander Beregalov <a.beregalov@...il.com> wrote:
> >> It seems it is blocked forever.
> >
> > Scanning the full memory may take a lot of time, depending on the
> > amount of RAM and the number of objects allocated. It is not unlikely
> > to take more than 120 seconds on some loaded systems. However, it
> > should call schedule() periodically to let other tasks run. Is your
> > system unresponsive during this?
> >
> >> [ 1704.619898] INFO: task kmemleak:763 blocked for more than 120 seconds.
> >> [ 1704.697951] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> >> disables this message.
> >> [ 1704.791613] kmemleak      D 0000000000000001  6008   763      2
> > [...]
> >> [ 1706.246334] no locks held by kmemleak/763.
> >
> > It looks like the kmemleak thread is in the TASK_UNINTERUPTIBLE state.
> > This happens when it calls schedule_timeout_uninterruptible() to sleep
> > between scans. It probably took more than 120 to scan the memory and
> > hence the report.
> >
> > It doesn't look like a problem, only that the watchdog thread checks
> > for uninterruptible tasks. I can try to make it sleep with
> > TASK_INTERRUPTIBLE to avoid the message.
> >
> > Thanks.
> >
> > --
> > Catalin
> > --
> 
> 
> Hi,
> 
> May be it would be better to make the softlockup detector hooking into
> schedule_timeout()
> (ie by using a tracepoint) to check if a thread chose to sleep more
> than hung_task_timeout_secs
> intentionally in a TASK_UNINTERRUPTIBLE state.
> 
> Fixing it into kmemleak would not solve the problem in other tasks
> which do similar sleeps...
> 

The hung_task timeout is now 480 seconds because of sys_sync:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fb822db465bd9fd4208eef1af4490539b236c54e

But are there are really any other tasks which call
schedule_timeout_uninterruptibl() for with a timeout >480 seconds?

Right now kmemleak appears to be the only exception. (A quick grep didn't turn
anything up.) And it is trivial to change kmemleak to use INTERRUPTIBLE.
Might even be a nice feature. You could stop it faster that way.

I suspect cases where long UNINTERRUPTIBLE sleeps is the right solution are
extremely rare. Since kmemleak can be modified, maybe hold off on ignoring
schedule_timeout_uninterruptible(). Not exempting schedule_timeout_uninter*
reduces code sprawl and discourages long UNINTERRUPTIBLE sleeps.

> Mandeep, if you agree I can try something? Or perhaps you prefer to do
> it yourself. As you wish.

Nah, don't wait for me. If you have a useful patch, just send it;) I'm
actually not the maintainer of hung_task, mingo@...e.hu is, but I am more than
happy to review patches.
--
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/