/* * This header provides clock numbers for the ingenic,jz4780-cgu DT binding. * * They are roughly ordered as: * - external clocks * - PLLs * - muxes/dividers in the order they appear in the jz4780 programmers manual * - gates in order of their bit in the CLKGR* registers */ #ifndef __DT_BINDINGS_CLOCK_JZ4780_CGU_H__ #define __DT_BINDINGS_CLOCK_JZ4780_CGU_H__ #define JZ4780_CLK_EXCLK 0 #define JZ4780_CLK_RTCLK 1 #define JZ4780_CLK_APLL 2 #define JZ4780_CLK_MPLL 3 #define JZ4780_CLK_EPLL 4 #define JZ4780_CLK_VPLL 5 #define JZ4780_CLK_OTGPHY 6 #define JZ4780_CLK_SCLKA 7 #define JZ4780_CLK_CPUMUX 8 #define JZ4780_CLK_CPU 9 #define JZ4780_CLK_L2CACHE 10 #define JZ4780_CLK_AHB0 11 #define JZ4780_CLK_AHB2PMUX 12 #define JZ4780_CLK_AHB2 13 #define JZ4780_CLK_PCLK 14 #define JZ4780_CLK_DDR 15 #define JZ4780_CLK_VPU 16 #define JZ4780_CLK_I2SPLL 17 #define JZ4780_CLK_I2S 18 #define JZ4780_CLK_LCD0PIXCLK 19 #define JZ4780_CLK_LCD1PIXCLK 20 #define JZ4780_CLK_MSCMUX 21 #define JZ4780_CLK_MSC0 22 #define JZ4780_CLK_MSC1 23 #define JZ4780_CLK_MSC2 24 #define JZ4780_CLK_UHC 25 #define JZ4780_CLK_SSIPLL 26 #define JZ4780_CLK_SSI 27 #define JZ4780_CLK_CIMMCLK 28 #define JZ4780_CLK_PCMPLL 29 #define JZ4780_CLK_PCM 30 #define JZ4780_CLK_GPU 31 #define JZ4780_CLK_HDMI 32 #define JZ4780_CLK_BCH 33 #define JZ4780_CLK_NEMC 34 #define JZ4780_CLK_OTG0 35 #define JZ4780_CLK_SSI0 36 #define JZ4780_CLK_SMB0 37 #define JZ4780_CLK_SMB1 38 #define JZ4780_CLK_SCC 39 #define JZ4780_CLK_AIC 40 #define JZ4780_CLK_TSSI0 41 #define JZ4780_CLK_OWI 42 #define JZ4780_CLK_KBC 43 #define JZ4780_CLK_SADC 44 #define JZ4780_CLK_UART0 45 #define JZ4780_CLK_UART1 46 #define JZ4780_CLK_UART2 47 #define JZ4780_CLK_UART3 48 #define JZ4780_CLK_SSI1 49 #define JZ4780_CLK_SSI2 50 #define JZ4780_CLK_PDMA 51 #define JZ4780_CLK_GPS 52 #define JZ4780_CLK_MAC 53 #define JZ4780_CLK_SMB2 54 #define JZ4780_CLK_CIM 55 #define JZ4780_CLK_LCD 56 #define JZ4780_CLK_TVE 57 #define JZ4780_CLK_IPU 58 #define JZ4780_CLK_DDR0 59 #define JZ4780_CLK_DDR1 60 #define JZ4780_CLK_SMB3 61 #define JZ4780_CLK_TSSI1 62 #define JZ4780_CLK_COMPRESS 63 #define JZ4780_CLK_AIC1 64 #define JZ4780_CLK_GPVLC 65 #define JZ4780_CLK_OTG1 66 #define JZ4780_CLK_UART4 67 #define JZ4780_CLK_AHBMON 68 #define JZ4780_CLK_SMB4 69 #define JZ4780_CLK_DES 70 #define JZ4780_CLK_X2D 71 #define JZ4780_CLK_CORE1 72 #endif /* __DT_BINDINGS_CLOCK_JZ4780_CGU_H__ */ 'id' value='ea07b862ac8ef9b8c8358517d2e39f847dda6659'/>
path: root/tools/lib/symbol
diff options
context:
space:
mode:
authorJohannes Weiner <hannes@cmpxchg.org>2017-01-06 19:21:43 -0500
committerLinus Torvalds <torvalds@linux-foundation.org>2017-01-07 18:22:40 -0800
commitea07b862ac8ef9b8c8358517d2e39f847dda6659 (patch)
treea1db46e9dd5dcf4c26dca819fad0b69fbb37e073 /tools/lib/symbol
parentb0b9b3df27d100a975b4e8818f35382b64a5e35c (diff)
mm: workingset: fix use-after-free in shadow node shrinker
Several people report seeing warnings about inconsistent radix tree nodes followed by crashes in the workingset code, which all looked like use-after-free access from the shadow node shrinker. Dave Jones managed to reproduce the issue with a debug patch applied, which confirmed that the radix tree shrinking indeed frees shadow nodes while they are still linked to the shadow LRU: WARNING: CPU: 2 PID: 53 at lib/radix-tree.c:643 delete_node+0x1e4/0x200 CPU: 2 PID: 53 Comm: kswapd0 Not tainted 4.10.0-rc2-think+ #3 Call Trace: delete_node+0x1e4/0x200 __radix_tree_delete_node+0xd/0x10 shadow_lru_isolate+0xe6/0x220 __list_lru_walk_one.isra.4+0x9b/0x190 list_lru_walk_one+0x23/0x30 scan_shadow_nodes+0x2e/0x40 shrink_slab.part.44+0x23d/0x5d0 shrink_node+0x22c/0x330 kswapd+0x392/0x8f0 This is the WARN_ON_ONCE(!list_empty(&node->private_list)) placed in the inlined radix_tree_shrink(). The problem is with 14b468791fa9 ("mm: workingset: move shadow entry tracking to radix tree exceptional tracking"), which passes an update callback into the radix tree to link and unlink shadow leaf nodes when tree entries change, but forgot to pass the callback when reclaiming a shadow node. While the reclaimed shadow node itself is unlinked by the shrinker, its deletion from the tree can cause the left-most leaf node in the tree to be shrunk. If that happens to be a shadow node as well, we don't unlink it from the LRU as we should. Consider this tree, where the s are shadow entries: root->rnode | [0 n] | | [s ] [sssss] Now the shadow node shrinker reclaims the rightmost leaf node through the shadow node LRU: root->rnode | [0 ] | [s ] Because the parent of the deleted node is the first level below the root and has only one child in the left-most slot, the intermediate level is shrunk and the node containing the single shadow is put in its place: root->rnode | [s ] The shrinker again sees a single left-most slot in a first level node and thus decides to store the shadow in root->rnode directly and free the node - which is a leaf node on the shadow node LRU. root->rnode | s Without the update callback, the freed node remains on the shadow LRU, where it causes later shrinker runs to crash. Pass the node updater callback into __radix_tree_delete_node() in case the deletion causes the left-most branch in the tree to collapse too. Also add warnings when linked nodes are freed right away, rather than wait for the use-after-free when the list is scanned much later. Fixes: 14b468791fa9 ("mm: workingset: move shadow entry tracking to radix tree exceptional tracking") Reported-by: Dave Chinner <david@fromorbit.com> Reported-by: Hugh Dickins <hughd@google.com> Reported-by: Andrea Arcangeli <aarcange@redhat.com> Reported-and-tested-by: Dave Jones <davej@codemonkey.org.uk> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Cc: Christoph Hellwig <hch@lst.de> Cc: Chris Leech <cleech@redhat.com> Cc: Lee Duncan <lduncan@suse.com> Cc: Jan Kara <jack@suse.cz> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Matthew Wilcox <mawilcox@linuxonhyperv.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'tools/lib/symbol')