config BTRFS_FS tristate "Btrfs filesystem support" select CRYPTO select CRYPTO_CRC32C select ZLIB_INFLATE select ZLIB_DEFLATE select LZO_COMPRESS select LZO_DECOMPRESS select RAID6_PQ select XOR_BLOCKS select SRCU help Btrfs is a general purpose copy-on-write filesystem with extents, writable snapshotting, support for multiple devices and many more features focused on fault tolerance, repair and easy administration. The filesystem disk format is no longer unstable, and it's not expected to change unless there are strong reasons to do so. If there is a format change, file systems with a unchanged format will continue to be mountable and usable by newer kernels. For more information, please see the web pages at http://btrfs.wiki.kernel.org. To compile this file system support as a module, choose M here. The module will be called btrfs. If unsure, say N. config BTRFS_FS_POSIX_ACL bool "Btrfs POSIX Access Control Lists" depends on BTRFS_FS select FS_POSIX_ACL help POSIX Access Control Lists (ACLs) support permissions for users and groups beyond the owner/group/world scheme. To learn more about Access Control Lists, visit the POSIX ACLs for Linux website . If you don't know what Access Control Lists are, say N config BTRFS_FS_CHECK_INTEGRITY bool "Btrfs with integrity check tool compiled in (DANGEROUS)" depends on BTRFS_FS help Adds code that examines all block write requests (including writes of the super block). The goal is to verify that the state of the filesystem on disk is always consistent, i.e., after a power-loss or kernel panic event the filesystem is in a consistent state. If the integrity check tool is included and activated in the mount options, plenty of kernel memory is used, and plenty of additional CPU cycles are spent. Enabling this functionality is not intended for normal use. In most cases, unless you are a btrfs developer who needs to verify the integrity of (super)-block write requests during the run of a regression test, say N config BTRFS_FS_RUN_SANITY_TESTS bool "Btrfs will run sanity tests upon loading" depends on BTRFS_FS help This will run some basic sanity tests on the free space cache code to make sure it is acting as it should. These are mostly regression tests and are only really interesting to btrfs developers. If unsure, say N. config BTRFS_DEBUG bool "Btrfs debugging support" depends on BTRFS_FS help Enable run-time debugging support for the btrfs filesystem. This may enable additional and expensive checks with negative impact on performance, or export extra information via sysfs. If unsure, say N. config BTRFS_ASSERT bool "Btrfs assert support" depends on BTRFS_FS help Enable run-time assertion checking. This will result in panics if any of the assertions trip. This is meant for btrfs developers only. If unsure, say N. 154?id=966d2b04e070bc040319aaebfec09e0144dc3341'>ieee802154/nl_policy.c
diff options
context:
space:
mode:
authorDouglas Miller <dougmill@linux.vnet.ibm.com>2017-01-28 06:42:20 -0600
committerTejun Heo <tj@kernel.org>2017-01-28 07:49:42 -0500
commit966d2b04e070bc040319aaebfec09e0144dc3341 (patch)
tree4b96156e3d1dd4dfd6039b7c219c9dc4616da52d /net/ieee802154/nl_policy.c
parent1b1bc42c1692e9b62756323c675a44cb1a1f9dbd (diff)
percpu-refcount: fix reference leak during percpu-atomic transition
percpu_ref_tryget() and percpu_ref_tryget_live() should return "true" IFF they acquire a reference. But the return value from atomic_long_inc_not_zero() is a long and may have high bits set, e.g. PERCPU_COUNT_BIAS, and the return value of the tryget routines is bool so the reference may actually be acquired but the routines return "false" which results in a reference leak since the caller assumes it does not need to do a corresponding percpu_ref_put(). This was seen when performing CPU hotplug during I/O, as hangs in blk_mq_freeze_queue_wait where percpu_ref_kill (blk_mq_freeze_queue_start) raced with percpu_ref_tryget (blk_mq_timeout_work). Sample stack trace: __switch_to+0x2c0/0x450 __schedule+0x2f8/0x970 schedule+0x48/0xc0 blk_mq_freeze_queue_wait+0x94/0x120 blk_mq_queue_reinit_work+0xb8/0x180 blk_mq_queue_reinit_prepare+0x84/0xa0 cpuhp_invoke_callback+0x17c/0x600 cpuhp_up_callbacks+0x58/0x150 _cpu_up+0xf0/0x1c0 do_cpu_up+0x120/0x150 cpu_subsys_online+0x64/0xe0 device_online+0xb4/0x120 online_store+0xb4/0xc0 dev_attr_store+0x68/0xa0 sysfs_kf_write+0x80/0xb0 kernfs_fop_write+0x17c/0x250 __vfs_write+0x6c/0x1e0 vfs_write+0xd0/0x270 SyS_write+0x6c/0x110 system_call+0x38/0xe0 Examination of the queue showed a single reference (no PERCPU_COUNT_BIAS, and __PERCPU_REF_DEAD, __PERCPU_REF_ATOMIC set) and no requests. However, conditions at the time of the race are count of PERCPU_COUNT_BIAS + 0 and __PERCPU_REF_DEAD and __PERCPU_REF_ATOMIC set. The fix is to make the tryget routines use an actual boolean internally instead of the atomic long result truncated to a int. Fixes: e625305b3907 percpu-refcount: make percpu_ref based on longs instead of ints Link: https://bugzilla.kernel.org/show_bug.cgi?id=190751 Signed-off-by: Douglas Miller <dougmill@linux.vnet.ibm.com> Reviewed-by: Jens Axboe <axboe@fb.com> Signed-off-by: Tejun Heo <tj@kernel.org> Fixes: e625305b3907 ("percpu-refcount: make percpu_ref based on longs instead of ints") Cc: stable@vger.kernel.org # v3.18+
Diffstat (limited to 'net/ieee802154/nl_policy.c')