linux-kernel - Re: Fw: Re: [mm PATCH 4/6] RCU: (now) CPU hotplug

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: <20070128153005.f320b834.akpm@osdl.org>
Date:	Sun, 28 Jan 2007 15:30:05 -0800
From:	Andrew Morton <akpm@...l.org>
To:	paulmck@...ux.vnet.ibm.com
Cc:	dipankar@...ibm.com, Gautham Shenoy <ego@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>
Subject: Re: Fw: Re: [mm PATCH 4/6] RCU: (now) CPU hotplug

On Sun, 28 Jan 2007 14:47:56 -0800
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> wrote:

> > If we use the process freezer, these bugs all get automatically fixed,
> > and we get to remove the existing locking, and we don't need to think
> > about it any more.
> 
> The idea being to essentially suspend the system to RAM, remove the
> CPU and then unsuspend it?  Seems like quite high overhead -- or am
> I misunderstanding the proposal?

The process freezer basically wakes up all threads in the machine and makes
them go to sleep in a specific place, so they're all in a known state. 
kernel threads are also captured, via their open-coded polling call to
try_to_freeze().

The machine suspend code uses the process freezer, as does kprobes.  The
freezer isn't tied to suspend or to power management.

The freezer does have potential to be expensive if used frequently and if
there are many threads.  But I don't think anyone has looked at optimising
it.  For example, there are certain places in the kernel where threads
commonly sleep (eg, select()).  We know that this is a safe place to sleep
wrt (at least) CPU hotplug, so there's not really a need to wake those
processes up.  Perhaps something could be done with that observation...

But first we'd need to demonstrate that we actually have a problem.
-
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/