Original- Maintainer: Debian VSquare Team īugs: https:/ /bugs.launchpad. I've confirmed that making that changes allows me to create symlinks happily on the mounted filesystem.
Fuse ext2 linux mint code#
This is simply due to a code bug in fuse-ext2/op_link.c (lines 104 and 109) where the code calls FUSE_EXT2_LOCK rather than FUSE_EXT2_UNLOCK on exiting the function. Trying to create a symlink in a filesystem mounted by fuseext2 causes the fuseext2 userspace process to deadlock before responding to the fuse request. * This issue seems to apply to all versions of fuseext2 in the ubuntu repos (well, at least it's there in trusty, xenial and zesty)
com/alperakcan/ fuse-ext2 but that doesn't have any locking code at all (even in the reentrant branch) so I can't see where this issue came from. * I can't actually work out where the upstream code for this project lives, the only upstream I could find is https:/ /github. * Since the program at risk is (by design) a userspace program, the risk of kernel data leakage is minimal. * The places where the change has been made are at the exit points of the function, and match where similar unlocks are made in other places in the code.
* Since this changes the locking strategy of the code to hold locks less, the main risk is exposing a case where data can be accessed in a non-threadsafe manner, leading to unexpected behaviour. * In another shell try to do anything else in the mount directory (ls, touch, rm) - Don't complete * dd if=/dev/zero of=partition bs=1M count=200 * Any attempt to create/overwrite symlinks in a partition mounted by fuseext2 causes the fuseext2 process to deadlock, preventing the mounted filesystem from being used at all until the userspace process is killed and the filesystem is remounted.
0 kommentar(er)
