menu "Allwinner SoC Audio support" depends on ARCH_SUNXI || COMPILE_TEST config SND_SUN4I_CODEC tristate "Allwinner A10 Codec Support" select SND_SOC_GENERIC_DMAENGINE_PCM select REGMAP_MMIO help Select Y or M to add support for the Codec embedded in the Allwinner A10 and affiliated SoCs. config SND_SUN8I_CODEC_ANALOG tristate "Allwinner sun8i Codec Analog Controls Support" depends on MACH_SUN8I || COMPILE_TEST select REGMAP help Say Y or M if you want to add support for the analog controls for the codec embedded in newer Allwinner SoCs. config SND_SUN4I_I2S tristate "Allwinner A10 I2S Support" select SND_SOC_GENERIC_DMAENGINE_PCM select REGMAP_MMIO help Say Y or M if you want to add support for codecs attached to the Allwinner A10 I2S. You will also need to select the individual machine drivers to support below. config SND_SUN4I_SPDIF tristate "Allwinner A10 SPDIF Support" depends on OF select SND_SOC_GENERIC_DMAENGINE_PCM select REGMAP_MMIO help Say Y or M to add support for the S/PDIF audio block in the Allwinner A10 and affiliated SoCs. endmenu up'>emaclite-cleanup net-next plumbingsTobias Klauser
summaryrefslogtreecommitdiff
path: root/tools/testing/selftests/rcutorture/doc
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
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')