linux-kernel - Is stopmachine() preempt safe?

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: <10990.1156671752@ocs10w.ocs.com.au>
Date:	Sun, 27 Aug 2006 19:42:32 +1000
From:	Keith Owens <kaos@....com.au>
To:	linux-kernel@...r.kernel.org
cc:	rusty@...tcorp.com.au, mingo@...e.hu
Subject: Is stopmachine() preempt safe?

I cannot convince myself that stopmachine() is preempt safe.  What
prevents this race with CONFIG_PREEMPT=y?

cpu 0				cpu 1
stop_machine()
				Process <n> reads a global resource
do_stop()
kernel_thread(stopmachine, 1)
				Process <n> is preempted
				stopmachine() runs on cpu 1
				STOPMACHINE_PREPARE
				STOPMACHINE_DISABLE_IRQ
do_stop() calls smdata->fn
smdata->fn changes global data
restart_machine()
				STOPMACHINE_EXIT
				stopmachine() exits
				Scheduler resumes process <n>
				The global resource is out of sync

The stopmachine() threads on the other cpus are set to MAX_RT_PRIO-1 so
they will preempt any existing process.  The yield() in stopmachine()
only guarantees that these kernel threads get onto the other cpus, it
does not guarantee that all running tasks will proceed to a yield
themselves before stopmachine runs.  IOW, what guarantees that the
scheduler will only run stopmachine() on the target cpus when those
cpus are completely idle with no locally cached global resources?

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