lkml.org 
[lkml]   [2006]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again
    From
    Date
    > > > > Yes, note the flush_dcache_page() call in fuse_copy_finish().  That
    > > > > could be replaced by the flush_kernel_dcache_page() (added by James
    > > > > Bottomley together with flush_anon_page()) when all relevant
    > > > > architectures have defined it.
    > > >
    > > > I should say that flush_anon_page() in its current form is going to be
    > > > problematic for ARM. It is passed:
    > > >
    > > > 1. the struct page
    > > > 2. the virtual address in process memory for the page
    > > >
    > > > It is not passed the mm or vma. This means that we have no idea whether
    > > > the virtual address is in the currently mapped VM space or not. The
    > > > common use of get_area_pages() is to get pages from other address
    > > > spaces.
    > >
    > > I'm not sure I understand. flush_anon_page() needs only to flush the
    > > mapping for the given virtual address, no?
    >
    > Yes, but that virtual /user/ address is meaningless without knowing
    > which process address space it belongs to.
    >
    > > It's always mapped at that address (since it was just accessed through
    > > that).
    >
    > No. Consider ptrace() (invoked by gdb) reading data from another
    > processes address space to obtain structure data or instructions.
    >
    > > Any other mappings
    > > of the anonymous page are irrelevant, they don't need to be flushed.
    >
    > Again, incorrect. Consider if the page you're accessing is a file-
    > backed page, and is mapped into a process using a shared mapping.
    > Because you've written to the file, those shared mappings need to see
    > that write, and the interface for achieving that is flush_dcache_page().
    > If not, data loss can occur.

    Yes, for file backed pages. But flush_anon_page() only needs to deal
    with anonymous (not file backed) pages.

    > > > If we use the supplied virtual address to perform cache maintainence of
    > > > the userspace mapping, we might end up hitting a completely different
    > > > processes address space, which may contain some page sensitive to such
    > > > operations, or may not contain any page and thereby could cause a page
    > > > fault on some ARM CPUs.
    > >
    > > I think calling get_user_pages() from a different process' address
    > > space simply doesn't make any sense.
    >
    > That was it's main use - to implement ptrace() to read other processes
    > address spaces. Why do you think it takes a task_struct and mm_struct?

    Right, I missed that.

    Miklos
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-12-21 19:33    [W:0.023 / U:34.072 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site