lkml.org 
[lkml]   [2006]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Remapping pages mapped to userspace
    From
    Date
        Linus> Generally, replacing the mmap with an anonymous zero-mapped
    Linus> mapping would be a horribly bad idea.

    Linus> The fact is, you can't avoid the race of seeing the removed
    Linus> state (which _usually_ means that you will read 0xffffffff
    Linus> from the bus - normal PC's won't result in bus errors
    Linus> etc). Whatever the kernel does, it can do only after the
    Linus> device has already been removed - we no longer live in a
    Linus> world where the administrator can tell the system
    Linus> before-hand that something will go away.

    Linus> Replacing the MMIO map with a zero map would be absolutely
    Linus> horrible. It would be inconsistent, and not even help the
    Linus> fact that the user will haev seen the removed state.

    Linus> In fact, I think even "revert" is pretty useless. You're
    Linus> much better off just sending a perfectly good signal -
    Linus> something that the app will get regardless of whether it
    Linus> reads the MMIO space at that point in time or not. After
    Linus> all, the only thing the "revert" would really do is to send
    Linus> a signal, but then only if the user is trying to access the
    Linus> device.

    Hmm, you're probably right for the hot unplug case. However, there
    are a couple of other related situations I've thought of in this context:

    - Module remove: userspace has PCI memory mmap()ed. The module is
    removed. Userspace still has access to PCI memory. And if the
    module is reloaded, userspace still has access to the device that
    the driver doesn't know about, so the driver may hand off the same
    access to another process.

    The obvious solution here is to just take a module reference when
    userspace mmap()s the device. However unprivileged processes can
    get direct access to IB devices, and it may not be so nice for
    unprivileged processes to be able to hold off module removal.

    - PCI error recovery (or internal device error recovery): if the
    driver detects a problem with the PCI bus or device, it might have
    to reset the device. The most natural way to model this is as hot
    unplug followed by hot plug. However we don't want userspace
    processes to keep their BAR mapping across the device reset,
    because the device is probably not set up to handle it right after reset.

    Really in this case at least, revoking an mmap() seems the cleanest
    solution to me.

    Any further thoughts?

    Thanks,
    Roland
    -
    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-03-18 00:00    [W:0.024 / U:2.296 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site