summaryrefslogtreecommitdiff
path: root/net/ieee802154/Kconfig
blob: 188135bcb803531b4ef24f68113a729122336390 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
menuconfig IEEE802154
	tristate "IEEE Std 802.15.4 Low-Rate Wireless Personal Area Networks support"
	---help---
	  IEEE Std 802.15.4 defines a low data rate, low power and low
	  complexity short range wireless personal area networks. It was
	  designed to organise networks of sensors, switches, etc automation
	  devices. Maximum allowed data rate is 250 kb/s and typical personal
	  operating space around 10m.

	  Say Y here to compile LR-WPAN support into the kernel or say M to
	  compile it as modules.

if IEEE802154

config IEEE802154_NL802154_EXPERIMENTAL
	bool "IEEE 802.15.4 experimental netlink support"
	---help---
	  Adds experimental netlink support for nl802154.

config IEEE802154_SOCKET
	tristate "IEEE 802.15.4 socket interface"
	default y
	---help---
	  Socket interface for IEEE 802.15.4. Contains DGRAM sockets interface
	  for 802.15.4 dataframes. Also RAW socket interface to build MAC
	  header from userspace.

source "net/ieee802154/6lowpan/Kconfig"

endif
/linux/net-next.git/diff/fs/xfs/xfs_pnfs.c?id=91539eb1fda2d530d3b268eef542c5414e54bf1a&id2=6610d0edf6dc7ee97e46ab3a538a565c79d26199'>diff)
dmaengine: pl330: fix double lock
The static bug finder EBA (http://www.iagoabal.eu/eba/) reported the following double-lock bug: Double lock: 1. spin_lock_irqsave(pch->lock, flags) at pl330_free_chan_resources:2236; 2. call to function `pl330_release_channel' immediately after; 3. call to function `dma_pl330_rqcb' in line 1753; 4. spin_lock_irqsave(pch->lock, flags) at dma_pl330_rqcb:1505. I have fixed it as suggested by Marek Szyprowski. First, I have replaced `pch->lock' with `pl330->lock' in functions `pl330_alloc_chan_resources' and `pl330_free_chan_resources'. This avoids the double-lock by acquiring a different lock than `dma_pl330_rqcb'. NOTE that, as a result, `pl330_free_chan_resources' executes `list_splice_tail_init' on `pch->work_list' under lock `pl330->lock', whereas in the rest of the code `pch->work_list' is protected by `pch->lock'. I don't know if this may cause race conditions. Similarly `pch->cyclic' is written by `pl330_alloc_chan_resources' under `pl330->lock' but read by `pl330_tx_submit' under `pch->lock'. Second, I have removed locking from `pl330_request_channel' and `pl330_release_channel' functions. Function `pl330_request_channel' is only called from `pl330_alloc_chan_resources', so the lock is already held. Function `pl330_release_channel' is called from `pl330_free_chan_resources', which already holds the lock, and from `pl330_del'. Function `pl330_del' is called in an error path of `pl330_probe' and at the end of `pl330_remove', but I assume that there cannot be concurrent accesses to the protected data at those points. Signed-off-by: Iago Abal <mail@iagoabal.eu> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Diffstat (limited to 'fs/xfs/xfs_pnfs.c')