Re: kmap_atomic and preemption

From: Vineet Gupta
Date: Thu May 05 2016 - 08:37:32 EST

On Wednesday 04 May 2016 08:31 PM, Peter Zijlstra wrote:
> So I'm fairly sure people rely on the fact you cannot have pagefault
> inside a kmap_atomic().

So this translates to: any hardware page faults inside kmap_atomic() can't lead to
do_page_fault() taking a lock - those can only be ex_table fixups, yes ?
Could you please also help explain your earlier comment about kmap_atomic needing
to disable preemption so that "returned pointer stayed valid". I can't quite
fathom how that can happen

> But you could potentially get away with leaving preemption enabled. Give
> it a try, see if something goes *bang* ;-)

So tried patch further below: on a quad core slowish FPGA setup, concurrent
hackbench and LMBench seem to run w/o issues - so it is not obviously broken even
if not proven otherwise. But the point is highmem page is a slow path anyways -
needs a PTE update, new TLB entry etc. I hoped to not wiggle even a single cache
line for the low page - but seems like that is not possible.

OTOH, if we do keep the status quo - then making these 2 cache lines into 1 is not
possible either. From reading the orig "decoupling of prremption and page fault"
thread it seems to be because preempt count is per cpu on x86.

@@ -67,7 +67,6 @@ void *kmap_atomic(struct page *page)
int idx, cpu_idx;
unsigned long vaddr;

- preempt_disable();
if (!PageHighMem(page))
return page_address(page);
@@ -107,7 +106,6 @@ void __kunmap_atomic(void *kv)

- preempt_enable();