Re: Happy New Year PARISC

[John David Anglin <dave.anglin@bell.net>]

On 1/3/2012 10:32 AM, James Bottomley wrote:
> On Tue, 2012-01-03 at 10:13 -0500, John David Anglin wrote:
>> On 1/3/2012 6:50 AM, Carlos O'Donell wrote:
>>> On Mon, Jan 2, 2012 at 6:12 PM, John David Anglin<dave.anglin@bell.net>   wrote:
>>>> None of this worked.  Attached patch as it stands.  Comments and testing
>>>> appreciated.
>>> Could you clarify what you mean by "none of this worked?"
>>>
>> I tried eliminating the flushes that occur in kunmap_atomic on PA8800
>> and PA8900
>> after the calls to clear_user_page and copy_user_page by defining
>> clear_user_highpage
>> and copy_user_highpage.  I had thought the flushes weren't necessary.
>> There's something
>> about this that I don't understand.  Why do we need to flush
>> non-equivalent page mappings
>> that aren't used?
> But they are used:  Your work makes sure that all user space mappings
> are equivalent.  However, because of the way Linux sets up kernel
> mappings (from the pfn array and offsets) the user virtual address and
> kernel virtual address almost never are.  kmap is exclusively used so
> the kernel can access a user page, and at that point, we need to flush
> because we've set up an inequivalent alias (even if it's only done for
> read)
>
> kmap/kmap_atomic is used in more than just copy/flush ... or did you
> mean that you removed the kmap calls in copy/flush and the whole thing
> doesn't work (rather than as you imply you removed the flush in kunmap?)
>
I didn't modify kmap/kunmap_atomic.  I wrote versions of 
clear_user_highpage and
copy_user_highpage to replace the default versions in linux/highmem.h.  
I replaced
the kunmap_atomic calls with pagefault_enable to avoid the flush in the 
returns from
clear/copy_user_page (actually, I only used one call to 
pagefault_enable, so maybe
that was the issue).  As far as I could tell, clear/copy_user_page are 
only called via
clear/copy_user_highpage.  The behavior of kmap/kunmap_atomic in other 
situations
shouldn't have changed.

Chapter F makes it clear that *all* inequivalent aliases to a page have 
to be removed
when a write capable translation is enabled (no flush needed).  When a 
write-capable
translation needs to be read through an inequivalent alias, the page is 
supposed to
be flushed, the write-capable translation is supposed to be removed from 
the page
directory and then purged.

That's why I added the purge_tlb_entries calls to set_pte_at and 
ptep_set_wrprotect.
We avoid the flush by doing the `from' read through an equivalent 
mapping.  However,
the inequivalent mapping is still there.  It seems to be necessary to 
purge the TLB
entries prior to clearing/copying.  However, from what I read in Chapter 
F, the purge
is probably insufficient to speculative prevent move in.  If I recall 
correctly, the
kunmap_atomic also generates another TLB purge as well as a flush.

There is a special access type (7) that can be used to prevent read and 
write move in.

Dave

-- 
John David Anglin    dave.anglin@bell.net