config NILFS2_FS
tristate "NILFS2 file system support"
select CRC32
help
NILFS2 is a log-structured file system (LFS) supporting continuous
snapshotting. In addition to versioning capability of the entire
file system, users can even restore files mistakenly overwritten or
destroyed just a few seconds ago. Since this file system can keep
consistency like conventional LFS, it achieves quick recovery after
system crashes.
NILFS2 creates a number of checkpoints every few seconds or per
synchronous write basis (unless there is no change). Users can
select significant versions among continuously created checkpoints,
and can change them into snapshots which will be preserved for long
periods until they are changed back to checkpoints. Each
snapshot is mountable as a read-only file system concurrently with
its writable mount, and this feature is convenient for online backup.
Some features including atime, extended attributes, and POSIX ACLs,
are not supported yet.
To compile this file system support as a module, choose M here: the
module will be called nilfs2. If unsure, say N.
master
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 'net/6lowpan/nhc_mobility.c')