summaryrefslogtreecommitdiff
path: root/dissector_80211.c
diff options
context:
space:
mode:
authorTobias Klauser <tklauser@distanz.ch>2017-05-03 14:33:41 +0200
committerTobias Klauser <tklauser@distanz.ch>2017-05-03 14:33:41 +0200
commita9f4431e0a205617bb316dbe459ac6188dd8b490 (patch)
treefc62c02cfb8372cbcbf378ed1c58d0c33b0c4ffd /dissector_80211.c
parenta5a5a91342ebd83d13b8eff8f85d9c923e08f701 (diff)
proc: include headers to get definitions for ino_t and pid_t
Include <unistd.h> and <sys/types.h> in the header already as the declarations for proc_find_by_inode(...) and proc_exists(...) use ino_t and pid_t, respectively. Fixes: 1edfb2409d15 ("flowtop: Move & refactor walk_processes() to proc.c") Fixes: 1df0f481922a ("flowtop: Add process UI tab entry") Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Diffstat (limited to 'dissector_80211.c')
0 files changed, 0 insertions, 0 deletions
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-09-28 11:14:51 +0000
node candidates which fall within the proximity range of the new register. If we choose the first node we encounter, under certain register insertion patterns it is possible to end up with overlapping ranges. This will break order in the rbtree and can cause the cached register value to become corrupted. E.g. take the simplified example where the proximity range is 2 and the register insertion sequence is 1, 4, 2, 3, 5. * Insert of register 1 creates a new node, this is the root of the rbtree * Insert of register 4 creates a new node, which is inserted to the right of the root. * Insert of register 2 gets inserted to the first node * Insert of register 3 gets inserted to the first node * Insert of register 5 also gets inserted into the first node since this is the first node encountered and it is within the proximity range. Now there are two overlapping nodes. To avoid this always choose the node that is closest to the new register. This will ensure that nodes will not overlap. The tree traversal is still done as a binary search, we just don't stop at the first node found. So the complexity of the algorithm stays within the same order. Ideally if a new register is in the range of two adjacent blocks those blocks should be merged, but that is a much more invasive change and left for later. The issue was initially introduced in commit 472fdec7380c ("regmap: rbtree: Reduce number of nodes, take 2"), but became much more exposed by commit 6399aea629b0 ("regmap: rbtree: When adding a reg do a bsearch for target node") which changed the order in which nodes are looked-up. Fixes: 6399aea629b0 ("regmap: rbtree: When adding a reg do a bsearch for target node") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
Diffstat (limited to 'Documentation/devicetree')