linux-kernel - Re: 3.13.5 : rm -rf running forever, one cpu at approx 100%

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]

Message-ID: <1393476762.5519.35.camel@marge.simpson.net>
Date:	Thu, 27 Feb 2014 05:52:42 +0100
From:	Mike Galbraith <bitbucket@...ine.de>
To:	Ken Moffat <zarniwhoop@...world.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: 3.13.5 : rm -rf running forever, one cpu at approx 100%

On Thu, 2014-02-27 at 03:45 +0000, Ken Moffat wrote: 
> On Thu, Feb 27, 2014 at 04:26:35AM +0100, Mike Galbraith wrote:
> > 
> > I would start with strace to see if a task is looping in userspace, then
> > move on to perf top -g -p <pid> (or perf record/report) to peek at what
> > it's up to in the kernel.  Once you have the where, trace_printk() is
> > the best thing since sliced bread (which ranks just below printk()).
> > 
> > -Mike
>  Thanks.  I'll need to build perf.

You may want to build the kernel with frame-pointers too, for easy gdb
list *0x(hexnum) of *func()+0x(hexoffset) use.  Crash is also pretty
handy both for rummaging live via crash vmlinux /proc/kcore, and for
leisurely postmortem analysis if you set the box up to crashdump in
advance, and force a dump (poke sysrq-c or echo c > /proc/sysrq-trigger)
when you see the bad thing happen.  Crash has all kinds of goodies,
including invocation of gdb.

-Mike

--
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/