Thread (49 messages) 49 messages, 7 authors, 2021-01-22

Re: [EXT] Re: [PATCH v4 03/13] task_isolation: userspace hard isolation from kernel

From: Alex Belits <hidden>
Date: 2020-10-04 15:03:07
Also in: linux-arch, linux-arm-kernel, lkml, netdev

On Thu, 2020-10-01 at 16:40 +0200, Frederic Weisbecker wrote:
External Email

-------------------------------------------------------------------
---
On Wed, Jul 22, 2020 at 02:49:49PM +0000, Alex Belits wrote:
quoted
+/**
+ * task_isolation_kernel_enter() - clear low-level task isolation
flag
+ *
+ * This should be called immediately after entering kernel.
+ */
+static inline void task_isolation_kernel_enter(void)
+{
+	unsigned long flags;
+
+	/*
+	 * This function runs on a CPU that ran isolated task.
+	 *
+	 * We don't want this CPU running code from the rest of kernel
+	 * until other CPUs know that it is no longer isolated.
+	 * When CPU is running isolated task until this point anything
+	 * that causes an interrupt on this CPU must end up calling
this
+	 * before touching the rest of kernel. That is, this function
or
+	 * fast_task_isolation_cpu_cleanup() or stop_isolation()
calling
+	 * it. If any interrupt, including scheduling timer, arrives,
it
+	 * will still end up here early after entering kernel.
+	 * From this point interrupts are disabled until all CPUs will
see
+	 * that this CPU is no longer running isolated task.
+	 *
+	 * See also fast_task_isolation_cpu_cleanup().
+	 */
+	smp_rmb();
I'm a bit confused what this read memory barrier is ordering. Also
against
what it pairs.
My bad, I have kept it after there were left no write accesses from
other CPUs.
quoted
+	if((this_cpu_read(ll_isol_flags) & FLAG_LL_TASK_ISOLATION) ==
0)
+		return;
+
+	local_irq_save(flags);
+
+	/* Clear low-level flags */
+	this_cpu_write(ll_isol_flags, 0);
+
+	/*
+	 * If something happened that requires a barrier that would
+	 * otherwise be called from remote CPUs by CPU kick procedure,
+	 * this barrier runs instead of it. After this barrier, CPU
+	 * kick procedure would see the updated ll_isol_flags, so it
+	 * will run its own IPI to trigger a barrier.
+	 */
+	smp_mb();
+	/*
+	 * Synchronize instructions -- this CPU was not kicked while
+	 * in isolated mode, so it might require synchronization.
+	 * There might be an IPI if kick procedure happened and
+	 * ll_isol_flags was already updated while it assembled a CPU
+	 * mask. However if this did not happen, synchronize everything
+	 * here.
+	 */
+	instr_sync();
It's the first time I meet an instruction barrier. I should get
information
about that but what is it ordering here?
Against barriers in instruction cache flushing (flush_icache_range()
and such). 
quoted
+	local_irq_restore(flags);
+}
Thanks.
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help