linux-kernel - Re: mmotm 2009-04-10-02-21 uploaded

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-next>] [day] [month] [year] [list]

Message-ID: <4609.1239456126@turing-police.cc.vt.edu>
Date:	Sat, 11 Apr 2009 09:22:06 -0400
From:	Valdis.Kletnieks@...edu
To:	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...l.org>
Cc:	linux-kernel@...r.kernel.org, mm-commits@...r.kernel.org
Subject: Re: mmotm 2009-04-10-02-21 uploaded - forkbombed by work_for_cpu

On Fri, 10 Apr 2009 02:22:23 PDT, akpm@...ux-foundation.org said:
> The mm-of-the-moment snapshot 2009-04-10-02-21 has been uploaded to
> 
>    http://userweb.kernel.org/~akpm/mmotm/

My system is reporting 70-90 forks per second, 'lastcomm' is reporting:

work_for_cpu      F    root     ??         0.00 secs Sat Apr 11 08:37
work_for_cpu      F    root     ??         0.00 secs Sat Apr 11 08:37
work_for_cpu      F    root     ??         0.00 secs Sat Apr 11 08:37
work_for_cpu      F    root     ??         0.00 secs Sat Apr 11 08:37
work_for_cpu      F    root     ??         0.00 secs Sat Apr 11 08:37
work_for_cpu      F    root     ??         0.00 secs Sat Apr 11 08:37
work_for_cpu      F    root     ??         0.00 secs Sat Apr 11 08:37
work_for_cpu      F    root     ??         0.00 secs Sat Apr 11 08:37
work_for_cpu      F    root     ??         0.00 secs Sat Apr 11 08:37

(and about 100K more of same).

Reverting this commit made the forks go away:

commit 6b44003e5ca66a3fffeb5bc90f40ada2c4340896
Author: Andrew Morton <akpm@...ux-foundation.org>
Date:   Thu Apr 9 09:50:37 2009 -0600

    work_on_cpu(): rewrite it to create a kernel thread on demand

No, I don't see why this generated a user-visible fork and accounting
record to be cut.  Maybe that's a normal side effect of kthread_create()
that I've never noticed because kthreads rarely exit, especially not at
90/sec.  I also don't know who's *calling* work_on_cpu() 90 times a
second, but I suspect it's this:

    This is not terribly fast, but the only current caller of work_on_cpu() is
    pci_call_probe().

Umm. No.

% find . -name '*.c' | xargs grep -l work_on_cpu 2> /dev/null 
./arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
./arch/x86/kernel/microcode_core.c
./arch/x86/kernel/acpi/cstate.c
./arch/x86/kernel/apm_32.c
./kernel/workqueue.c
./drivers/acpi/processor_throttling.c
./drivers/pci/pci-driver.c

Probable cause for my problem:

arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c calls work_on_cpu(). We get into a
state where we have enough activity to kick us to a high CPU speed, and then
the activity of writing 90 acct records per sec keeps us there - with continual
callbacks to see if we can drop the CPU speed.

Content of type "application/pgp-signature" skipped