[lkml]   [2008]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 2/6] mmu_notifier: Callbacks to invalidate address ranges
    On Wed, Feb 27, 2008 at 02:35:59PM -0800, Christoph Lameter wrote:
    > Could you be specific? This refers to page migration? Hmmm... Guess we

    If the reader schedule, the synchronize_rcu will return in the other
    cpu and the objects in the list will be freed and overwritten, and
    when the task is scheduled back in, it'll follow dangling pointers...
    You can't use RCU if you want any of your invalidate methods to
    schedule. Otherwise it's like having zero locking.

    > 2. Not handle file backed mappings (XPmem could work mostly in such a
    > config)

    IMHO that fits under your definition of "hacking something in now and
    then having to modify it later".

    > 3. Keep the refcount elevated until pages are freed in another execution
    > context.

    Page refcount is not enough (the mmu_notifier_release will run in
    another cpu the moment after i_mmap_lock is unlocked) but mm_users may
    prevent us to change the i_mmap_lock to a mutex, but it'll slowdown
    truncate as it'll have to drop the lock and restart the radix tree
    walk every time so a change like this better fits as a separate

     \ /
      Last update: 2008-02-28 01:15    [W:0.040 / U:0.044 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site