2009/2/2 Catalin Marinas <catalin.marinas@xxxxxxx>: > Alexander Beregalov <a.beregalov@xxxxxxxxx> 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... Mandeep, if you agree I can try something? Or perhaps you prefer to do it yourself. As you wish. -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
