Re: [RFC 04/11] x86/mm: Track the TLB's tlb_gen and update the flushing algorithm

[Nadav Amit <nadav.amit@gmail.com>]

Maybe it’s me, but I find it rather hard to figure out whether
flush_tlb_func_common() is safe, since it can be re-entered - if a local TLB
flush is performed, and during this local flush a remote shootdown IPI is
received.

Did I miss irq being disabled during the local flush?

Otherwise, it raises the question whether flush_tlb_func_common() changes were
designed with re-entry in mind. Regarding it in the comments would really be
helpful.

Anyhow, I suspect that at least the following warning can be triggered:

	WARN_ON_ONCE(local_tlb_gen > mm_tlb_gen);


> static void flush_tlb_func_common(const struct flush_tlb_info *f,
> 				  bool local, enum tlb_flush_reason reason)
> {
> +	struct mm_struct *loaded_mm = this_cpu_read(cpu_tlbstate.loaded_mm);
> +
> +	/*
> +	 * Our memory ordering requirement is that any TLB fills that
> +	 * happen after we flush the TLB are ordered after we read
> +	 * active_mm's tlb_gen.  We don't need any explicit barrier
> +	 * because all x86 flush operations are serializing and the
> +	 * atomic64_read operation won't be reordered by the compiler.
> +	 */
> +	u64 mm_tlb_gen = atomic64_read(&loaded_mm->context.tlb_gen);

If for example a shootdown IPI can be delivered here... 

> +	u64 local_tlb_gen = this_cpu_read(cpu_tlbstate.ctxs[0].tlb_gen);
> +


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>