This is not something I intend to work on, but I'm throwing it out
there given the recent refcount bug. Perhaps someone(tm) will pick it
up. Given that I'm offering 0 effort, I'm not going to argue about it
either. ;)
I believe the current handling is highly error prone and it does not
have to be like that, albeit I fully admit I have no idea how much
work is needed to redo things the way I'm describing here.
The key problem is that path_put can't do anything about pointers
stored in the obj and consequently can't help detect bad consumers.
two key notions to combat the problem:
1. an invariant that a populated struct path holds exactly one ref on
a dentry and one ref a mount point
2. path is invalid to access in any capacity after path_put (other
than reinitialization of course) -- no null checks, no nothing
This implies that path_get() goes away.
Opening a file has a spurious path_get/put trip I already complained
about, that goes away as a side effect.
A dedicated routine can be added for consumers which need to copy a path.
For example the following in get_path_from_fd():
spin_lock(&fs->lock);
*root = fs->pwd;
path_get(root);
spin_unlock(&fs->lock);
can become:
spin_lock(&fs->lock);
path_clone(fs->pwd, root);
spin_unlock(&fs->lock);
There are legitimate reasons for multiple threads to share one path
obj, for example like it happens in struct file -- this remains
unaffected.
One idea how to implement path_put():
- if sanitizers are available, the dentry and mount pointers are
marked as poisoned -- it is illegal to even read them
- otherwise the pointers are set to a known bad address (for example a
non-canonical address on amd64) -- this does not prevent loads, but it
does guarantee trapping on deref ; this can be conditional on
CONFIG_DEBUG_VFS to not affect prod runtime
Personally I would go even a step further and make unpopulated path
invalid to pass to path_put().
path_put() is a kind of a bad name as it implies reference handling. I
would change it to path_destroy() or similar.
My $0,03.
--
Mateusz Guzik <mjguzik gmail.com>
