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@xxxxxxxx> 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@xxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
