Re: [PATCH 3/4] libunload: A library to help remove open files

[Greg KH <gregkh@linuxfoundation.org>]

On Fri, Jan 16, 2015 at 10:49:38AM -0800, Mandeep Sandhu wrote:
> The problem of how to remove open files due to module unloading or
> device hotunplugging keeps coming up.  We have multiple implementations
> of roughly the same logic in proc, sysctl, sysfs, tun and now I am
> working on yet another one for uio. It is time to start working on a
> generic implementation.
> 
> This library does not aim to allow wrapping any arbitray set of file
> operations and making it safe to unload any module. This library aims
> to work in conjunction with the code implementiong an object to make it
> safe to remove the object while file handles to it are still open.
> libunload implements the necessary locking and logic to make it
> striaght forward to implement file_operations for objects that are
> removed at runtime.
> 
> It is hard to arrange for the ->close method of vm_operations_struct to
> be called when an object is being removed, and this code doesn't even
> attempt to help with that. Instead it is assumed that calling ->close
> is not needed. Without close support mmap at hotunplug time is simply a
> matter of calling umap_mapping_range() to invaildate the mappings, and
> to arrange for vm_fault to return VM_FAULT_SIGBUS when the
> unload_trylock fails.
> 
> Wait queues and fasync queues can safely be woken up after
> unload_barrier making the semantics clean. The fasync entries can be
> freed as a list of all of the file descriptors is kept. poll entries
> can not be freed so the poll wait queue heads must be kept around. If
> someone else's poll method is being wrapped, the wrapped poll wait
> queue head could be freed, but it requires that there is a wrapping
> wait queue head that is kept around. If there is no other way wrapping
> a poll wait queue head seems practical but in general it isn't
> particularly useful.
> 
> libunload is best understood from the perspective of code that calls
> unload_barrier(). Past the unload barrier it is guaranteed that there
> is no code in the critical sections protectecd by the unload lock, and
> the unload release lock. Past the unload barrier it is safe to call the
> release methods for remaining file descriptors, to ensure some logical
> state does not persist.

Can you provide some documentation for how to use this, kerneldoc at the
very least.

Also, can you port the above mentioned interfaces (proc, sysfs, tun,
etc.) that need this type of logic to this api, so we can see how well
it works out?  Just providing one user of the code (uio), doesn't really
show if this is "generic" enough for everyone to use.

thanks,

greg k-h