Impossible to get file lock again after opening a device and doing map_mapping

[SebastianHambura]

While doing some more test, I think I found a bug: rust-uio is not always unlocking the file when dropping, and then we try to get the lock again it's blocking and waiting forever.

I was trying to use uiodevice to get the raw memory of my custom device, copy the data into a Rust struct using Deku, change some value in the rust struct, and then write the new value back to the device.

Reading is working fine, but trying to write back hangs on devfile.lock_exclusive()?;. Replacing this call by try_lock_exclusive raises an Error ( Resource temporarily unavailable (os error 11) ). My guess is that we get a file lock, but we because we do memory mapping afterwards, when we drop the file it's not completely dropped, and the lock survives.

Anyways, adding the following seems to solve the issue (but I'm wondering if we should also unmap the memory at the same time ?):

impl Drop for UioDevice {
    fn drop(&mut self) {
        self.devfile.unlock();
    }
}

Sorry if that doesn't make sense, I'm not very used to work on that kind of things.

[joshchngs]

Yes, your Drop impl is enough. For the munmapping, it's a separate issue. mmaps are tracked separately to the file, so it's OK to close the file descriptor and keep the maps.

However, it's not super cool that rust-uio never unmaps them – they'll remain in process address space until the process ends. I'll do a separate PR for a new API if I get time; it's a bit of an intrusive change.