lkml.org 
[lkml]   [2010]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: USB mass storage and ARM cache coherency
    > There's two potential problems with the approach, and maybe more that I
    > have missed though. One is the case of a networked filesystem where the
    > executable pages are modified remotely. However, I would expect such a
    > program to invalidate the PTE mappings before making the change visible,
    > so we -do- get a chance to re-flush provided something clears PG_arch_1.
    >
    > Then, there's In the case of a multithread app, where one thread does
    > the cache flush and another thread then executes, the earlier ARMs
    > without broadcast ops have a potential problem there. In fact, some
    > variant of PowerPC 440 have the same problem and some people are
    > (ab)using those for SMP setups I'm being told.
    >
    > For that case, I see two options. One is a big hammer but would make
    > existing code work to "most" extent: Don't allow a page to be both
    > writable and executable. Ping-pong the page permission lazily and flush
    > when transitioning from write to exec.
    >
    > That means using a spare bit for Linux _PAGE_RW separate from your real
    > RW bit I suppose, since you have HW loaded PTEs (on 440 it's easier
    > since we SW load, we can do the fixup there, though it has a perf impact
    > obviously).
    >
    > Another option would be to make some syscall mandatory to "sync" caches
    > which could then do IPIs or whatever else is needed. But that would
    > require changing existing userspace code.

    Or you could do first option by default, and add mmap flag that says
    that application is responsible for cross-cpu cache flushes...?
    Pavel
    --
    (english) http://www.livejournal.com/~pavelmachek
    (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


    \
     
     \ /
      Last update: 2010-02-28 20:19    [W:4.142 / U:0.116 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site