Thread (58 messages) 58 messages, 8 authors, 2025-10-28

Re: [PATCH v3 02/13] x86/xen: simplify flush_lazy_mmu()

From: Kevin Brodsky <hidden>
Date: 2025-10-16 07:32:29
Also in: linux-arm-kernel, linux-mm, lkml, sparclinux, xen-devel

On 15/10/2025 18:52, Dave Hansen wrote:
On 10/15/25 01:27, Kevin Brodsky wrote:
quoted
While at it, we can also avoid preempt_disable() if we are not
in lazy MMU mode - xen_get_lazy_mode() should tolerate preemption.
...
quoted
 static void xen_flush_lazy_mmu(void)
 {
-	preempt_disable();
-
 	if (xen_get_lazy_mode() == XEN_LAZY_MMU) {
-		arch_leave_lazy_mmu_mode();
-		arch_enter_lazy_mmu_mode();
+		preempt_disable();
+		xen_mc_flush();
+		preempt_enable();
 	}
But xen_get_lazy_mode() does:

	this_cpu_read(xen_lazy_mode);

Couldn't preemption end up doing the 'xen_lazy_mode' read and the
xen_mc_flush() on different CPUs?

That seems like a problem. Is there a reason it's safe?
You're right, I was thinking in terms of task, but xen_mc_flush() does
operate on the current CPU (and it's called when context-switching).
Will restore the original order in v4.

- Kevin

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help