config SND_SOC_IMG bool "Audio support for Imagination Technologies designs" help Audio support for Imagination Technologies audio hardware config SND_SOC_IMG_I2S_IN tristate "Imagination I2S Input Device Driver" depends on SND_SOC_IMG select SND_SOC_GENERIC_DMAENGINE_PCM help Say Y or M if you want to add support for I2S in driver for Imagination Technologies I2S in device. config SND_SOC_IMG_I2S_OUT tristate "Imagination I2S Output Device Driver" depends on SND_SOC_IMG select SND_SOC_GENERIC_DMAENGINE_PCM help Say Y or M if you want to add support for I2S out driver for Imagination Technologies I2S out device. config SND_SOC_IMG_PARALLEL_OUT tristate "Imagination Parallel Output Device Driver" depends on SND_SOC_IMG select SND_SOC_GENERIC_DMAENGINE_PCM help Say Y or M if you want to add support for parallel out driver for Imagination Technologies parallel out device. config SND_SOC_IMG_SPDIF_IN tristate "Imagination SPDIF Input Device Driver" depends on SND_SOC_IMG select SND_SOC_GENERIC_DMAENGINE_PCM help Say Y or M if you want to add support for SPDIF input driver for Imagination Technologies SPDIF input device. config SND_SOC_IMG_SPDIF_OUT tristate "Imagination SPDIF Output Device Driver" depends on SND_SOC_IMG select SND_SOC_GENERIC_DMAENGINE_PCM help Say Y or M if you want to add support for SPDIF out driver for Imagination Technologies SPDIF out device. config SND_SOC_IMG_PISTACHIO_INTERNAL_DAC tristate "Support for Pistachio SoC Internal DAC Driver" depends on SND_SOC_IMG help Say Y or M if you want to add support for Pistachio internal DAC driver for Imagination Technologies Pistachio internal DAC device. uild'>logtreecommitdiff
path: root/tools/perf/Build
diff options
context:
space:
mode:
authorEric Dumazet <edumazet@google.com>2017-01-27 08:11:44 -0800
committerDavid S. Miller <davem@davemloft.net>2017-01-29 18:30:56 -0500
commitf1712c73714088a7252d276a57126d56c7d37e64 (patch)
tree962ee49daf8d1cba8403fcf03b315d4a142ec944 /tools/perf/Build
parentdc97a89e726c4e1830320d1db8215ef77ecebae0 (diff)
can: Fix kernel panic at security_sock_rcv_skb
Zhang Yanmin reported crashes [1] and provided a patch adding a synchronize_rcu() call in can_rx_unregister() The main problem seems that the sockets themselves are not RCU protected. If CAN uses RCU for delivery, then sockets should be freed only after one RCU grace period. Recent kernels could use sock_set_flag(sk, SOCK_RCU_FREE), but let's ease stable backports with the following fix instead. [1] BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff81495e25>] selinux_socket_sock_rcv_skb+0x65/0x2a0 Call Trace: <IRQ> [<ffffffff81485d8c>] security_sock_rcv_skb+0x4c/0x60 [<ffffffff81d55771>] sk_filter+0x41/0x210 [<ffffffff81d12913>] sock_queue_rcv_skb+0x53/0x3a0 [<ffffffff81f0a2b3>] raw_rcv+0x2a3/0x3c0 [<ffffffff81f06eab>] can_rcv_filter+0x12b/0x370 [<ffffffff81f07af9>] can_receive+0xd9/0x120 [<ffffffff81f07beb>] can_rcv+0xab/0x100 [<ffffffff81d362ac>] __netif_receive_skb_core+0xd8c/0x11f0 [<ffffffff81d36734>] __netif_receive_skb+0x24/0xb0 [<ffffffff81d37f67>] process_backlog+0x127/0x280 [<ffffffff81d36f7b>] net_rx_action+0x33b/0x4f0 [<ffffffff810c88d4>] __do_softirq+0x184/0x440 [<ffffffff81f9e86c>] do_softirq_own_stack+0x1c/0x30 <EOI> [<ffffffff810c76fb>] do_softirq.part.18+0x3b/0x40 [<ffffffff810c8bed>] do_softirq+0x1d/0x20 [<ffffffff81d30085>] netif_rx_ni+0xe5/0x110 [<ffffffff8199cc87>] slcan_receive_buf+0x507/0x520 [<ffffffff8167ef7c>] flush_to_ldisc+0x21c/0x230 [<ffffffff810e3baf>] process_one_work+0x24f/0x670 [<ffffffff810e44ed>] worker_thread+0x9d/0x6f0 [<ffffffff810e4450>] ? rescuer_thread+0x480/0x480 [<ffffffff810ebafc>] kthread+0x12c/0x150 [<ffffffff81f9ccef>] ret_from_fork+0x3f/0x70 Reported-by: Zhang Yanmin <yanmin.zhang@intel.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'tools/perf/Build')