For reporting bugs send an email to the list. Alternatively, you can create an issue on our Github project: * https://github.com/netsniff-ng/netsniff-ng/issues If you use Fedora or have a RHEL subscription, you can also report bugs to: * https://bugzilla.redhat.com/ If you use Debian Linux, we might also process / track bugs there: * http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=netsniff-ng In any way, you'll get a reply from us. Please do not contact individual developers directly in case of netsniff-ng issues or patches, but rather always our mailing list. By this, you're not wasting time of a single developer and increase your chances of getting a reply from us. In general, we are also highly interested in how you use the toolkit, what problems you are trying to solve and what kind of things you would like to have improved. So feel free to drop us some feature requests as well. a>
net-next plumbingsTobias Klauser
summaryrefslogtreecommitdiff
path: root/tools/testing/selftests/rcutorture/doc/rcu-test-image.txt
diff options
context:
space:
mode:
authorEric W. Biederman <ebiederm@xmission.com>2017-01-03 14:18:43 +1300
committerEric W. Biederman <ebiederm@xmission.com>2017-01-10 13:34:43 +1300
commit3895dbf8985f656675b5bde610723a29cbce3fa7 (patch)
tree91d4517f09918fd573998eb40b8f35f08ed1c470 /tools/testing/selftests/rcutorture/doc/rcu-test-image.txt
parent0c744ea4f77d72b3dcebb7a8f2684633ec79be88 (diff)
mnt: Protect the mountpoint hashtable with mount_lock
Protecting the mountpoint hashtable with namespace_sem was sufficient until a call to umount_mnt was added to mntput_no_expire. At which point it became possible for multiple calls of put_mountpoint on the same hash chain to happen on the same time. Kristen Johansen <kjlx@templeofstupid.com> reported: > This can cause a panic when simultaneous callers of put_mountpoint > attempt to free the same mountpoint. This occurs because some callers > hold the mount_hash_lock, while others hold the namespace lock. Some > even hold both. > > In this submitter's case, the panic manifested itself as a GP fault in > put_mountpoint() when it called hlist_del() and attempted to dereference > a m_hash.pprev that had been poisioned by another thread. Al Viro observed that the simple fix is to switch from using the namespace_sem to the mount_lock to protect the mountpoint hash table. I have taken Al's suggested patch moved put_mountpoint in pivot_root (instead of taking mount_lock an additional time), and have replaced new_mountpoint with get_mountpoint a function that does the hash table lookup and addition under the mount_lock. The introduction of get_mounptoint ensures that only the mount_lock is needed to manipulate the mountpoint hashtable. d_set_mounted is modified to only set DCACHE_MOUNTED if it is not already set. This allows get_mountpoint to use the setting of DCACHE_MOUNTED to ensure adding a struct mountpoint for a dentry happens exactly once. Cc: stable@vger.kernel.org Fixes: ce07d891a089 ("mnt: Honor MNT_LOCKED when detaching mounts") Reported-by: Krister Johansen <kjlx@templeofstupid.com> Suggested-by: Al Viro <viro@ZenIV.linux.org.uk> Acked-by: Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Diffstat (limited to 'tools/testing/selftests/rcutorture/doc/rcu-test-image.txt')