linux-kernel - Re: [2.6.23] tasks stuck in running state?

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:	Sun, 21 Oct 2007 19:25:10 +0200
From:	"Dmitry Adamushko" <dmitry.adamushko@...il.com>
To:	"Jeff Garzik" <jeff@...zik.org>
Cc:	"Ingo Molnar" <mingo@...e.hu>, "Chuck Ebbert" <cebbert@...hat.com>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: [2.6.23] tasks stuck in running state?

On 20/10/2007, Jeff Garzik <jeff@...zik.org> wrote:
> Chuck Ebbert wrote:
> > On 10/19/2007 05:39 PM, Jeff Garzik wrote:
> >> On my main devel box, vanilla 2.6.23 on x86-64/Fedora-7, I'm seeing a
> >> certain behavior at least once a day.  I'll start a kernel build (make
> >> -sj5 on this box), and it will "hang" in the following way:
> >>
> >
> > Can you try to strace the hanging task?
>
> Well, to the system it's running, so that doesn't do much of anything...
>
> >
> >  8482 pts/0    S+     0:00                          \_ /bin/sh /garz/repo/misc-2.6/scripts/hdrcheck.sh /garz/repo/misc-2.6/usr/include /garz/repo/misc-2.6/usr/include/linux/kernelcapi.h /garz/repo/misc-2.6/usr/include/linux/.check.kernelcapi.h
> >  8484 pts/0    R+     3:10                              \_ grep ^[ \t]*#[ \t]*include[ \t]*< /garz/repo/misc-2.6/usr/include/linux/kernelcapi.h
> >  8486 pts/0    S+     0:00                              \_ cut -f2 -d<
> >  8487 pts/0    S+     0:00                              \_ cut -f1 -d>
> >  8488 pts/0    S+     0:00                              \_ egrep ^linux|^asm
> > [jgarzik@...tzel misc-2.6]$ strace -p8484
> > Process 8484 attached - interrupt to quit
> [sits there, chewing up CPU grepping a 47-line header file]

I think, the following information would be helpful :

(1)  # cat /proc/PID/stat ; sleep 5; cat /proc/PID/stat

as we could know :

- whether utime or/and stime keeps increasing ;

- one of the fields is actually 'eip' ... so we could, hopefully, more
or less precisely localize the area of the code where it's looping.

(do_task_stat() in fs/proc/array.c)


(2) # cat /proc/sched_debug;
and
# cat /proc/PID/sched

(if your kernel has CONFIG_SCHED_DEBUG=y)


(3) is anything else able to run on this CPU (as I understand it's
SMP) or the task does completely locks it up.

again, one of the fields of /proc/PID/stat is the CPU# on which the
task is currently active.

Let's start a buzy-loop task on this cpu and see wheather it's able to
make any progress (TIME counter in 'ps')

# taskset -c THIS_CPU some_busy_looping_prog

TIA,

-- 
Best regards,
Dmitry Adamushko
-
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/