[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dac45098-27e0-cd0f-97b2-868e5e294c93@linux.intel.com>
Date: Fri, 7 Jun 2019 18:01:54 -0500
From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To: Alex Levin <levinale@...omium.org>, alsa-devel@...a-project.org
Cc: Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
Jie Yang <yang.jie@...ux.intel.com>,
Mark Brown <broonie@...nel.org>,
Jaroslav Kysela <perex@...ex.cz>,
Takashi Iwai <tiwai@...e.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
linux-kernel@...r.kernel.org, benzh@...omium.org,
cujomalainey@...omium.org
Subject: Re: [PATCH] ASoC: Intel: sst: fix kmalloc call with wrong flags
On 6/7/19 5:19 PM, Alex Levin wrote:
> When calling kmalloc with GFP_KERNEL in case CONFIG_SLOB is unset,
> kmem_cache_alloc_trace is called.
>
> In case CONFIG_TRACING is set, kmem_cache_alloc_trace will ball
> slab_alloc, which will call slab_pre_alloc_hook which might_sleep_if.
>
> The context in which it is called in this case, the
> intel_sst_interrupt_mrfld, calling a sleeping kmalloc generates a BUG():
Thanks for reporting this and suggesting a fix.
I just checked and all our test configs have CONFIG_SLOB unset and
CONFIG_TRACING=y, but I don't recall having seen this. Could you share
your config so that we can see if we are missing something?
>
> Fixes: 972b0d456e64 ("ASoC: Intel: remove GFP_ATOMIC, use GFP_KERNEL")
>
> [ 20.250671] BUG: sleeping function called from invalid context at mm/slab.h:422
> [ 20.250683] in_atomic(): 1, irqs_disabled(): 1, pid: 1791, name: Chrome_IOThread
> [ 20.250690] CPU: 0 PID: 1791 Comm: Chrome_IOThread Tainted: G W 4.19.43 #61
> [ 20.250693] Hardware name: GOOGLE Kefka, BIOS Google_Kefka.7287.337.0 03/02/2017
> [ 20.250697] Call Trace:
> [ 20.250704] <IRQ>
> [ 20.250716] dump_stack+0x7e/0xc3
> [ 20.250725] ___might_sleep+0x12a/0x140
> [ 20.250731] kmem_cache_alloc_trace+0x53/0x1c5
> [ 20.250736] ? update_cfs_rq_load_avg+0x17e/0x1aa
> [ 20.250740] ? cpu_load_update+0x6c/0xc2
> [ 20.250746] sst_create_ipc_msg+0x2d/0x88
> [ 20.250752] intel_sst_interrupt_mrfld+0x12a/0x22c
> [ 20.250758] __handle_irq_event_percpu+0x133/0x228
> [ 20.250764] handle_irq_event_percpu+0x35/0x7a
> [ 20.250768] handle_irq_event+0x36/0x55
> [ 20.250773] handle_fasteoi_irq+0xab/0x16c
> [ 20.250779] handle_irq+0xd9/0x11e
> [ 20.250785] do_IRQ+0x54/0xe0
> [ 20.250791] common_interrupt+0xf/0xf
> [ 20.250795] </IRQ>
> [ 20.250800] RIP: 0010:__lru_cache_add+0x4e/0xad
> [ 20.250806] Code: 00 01 48 c7 c7 b8 df 01 00 65 48 03 3c 25 28 f1 00 00 48 8b 48 08 48 89 ca 48 ff ca f6 c1 01 48 0f 44 d0 f0 ff 42 34 0f b6 0f <89> ca fe c2 88 17 48 89 44 cf 08 80 fa 0f 74 0e 48 8b 08 66 85 c9
> [ 20.250809] RSP: 0000:ffffa568810bfd98 EFLAGS: 00000202 ORIG_RAX: ffffffffffffffd6
> [ 20.250814] RAX: ffffd3b904eb1940 RBX: ffffd3b904eb1940 RCX: 0000000000000004
> [ 20.250817] RDX: ffffd3b904eb1940 RSI: ffffa10ee5c47450 RDI: ffffa10efba1dfb8
> [ 20.250821] RBP: ffffa568810bfda8 R08: ffffa10ef9c741c1 R09: dead000000000100
> [ 20.250824] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa10ee8d52a40
> [ 20.250827] R13: ffffa10ee8d52000 R14: ffffa10ee5c47450 R15: 800000013ac65067
> [ 20.250835] lru_cache_add_active_or_unevictable+0x4e/0xb8
> [ 20.250841] handle_mm_fault+0xd98/0x10c4
> [ 20.250848] __do_page_fault+0x235/0x42d
> [ 20.250853] ? page_fault+0x8/0x30
> [ 20.250858] do_page_fault+0x3d/0x17a
> [ 20.250862] ? page_fault+0x8/0x30
> [ 20.250866] page_fault+0x1e/0x30
> [ 20.250872] RIP: 0033:0x7962fdea9304
> [ 20.250875] Code: 0f 11 4c 17 f0 c3 48 3b 15 f1 26 31 00 0f 83 e2 00 00 00 48 39 f7 72 0f 74 12 4c 8d 0c 16 4c 39 cf 0f 82 63 01 00 00 48 89 d1 <f3> a4 c3 80 fa 08 73 12 80 fa 04 73 1e 80 fa 01 77 26 72 05 0f b6
> [ 20.250879] RSP: 002b:00007962f4db5468 EFLAGS: 00010206
> [ 20.250883] RAX: 00003c8cc9d47008 RBX: 0000000000000000 RCX: 0000000000001b48
> [ 20.250886] RDX: 0000000000002b40 RSI: 00003c8cc9551000 RDI: 00003c8cc9d48000
> [ 20.250890] RBP: 00007962f4db5820 R08: 0000000000000000 R09: 00003c8cc9552b48
> [ 20.250893] R10: 0000562dd1064d30 R11: 00003c8cc825b908 R12: 00003c8cc966d3c0
> [ 20.250896] R13: 00003c8cc9e280c0 R14: 0000000000000000 R15: 0000000000000000
>
> Signed-off-by: Alex Levin <levinale@...omium.org>
> ---
>
> sound/soc/intel/atom/sst/sst_pvt.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/intel/atom/sst/sst_pvt.c b/sound/soc/intel/atom/sst/sst_pvt.c
> index 00a37a09dc9b..dba0ca07ebf9 100644
> --- a/sound/soc/intel/atom/sst/sst_pvt.c
> +++ b/sound/soc/intel/atom/sst/sst_pvt.c
> @@ -166,11 +166,11 @@ int sst_create_ipc_msg(struct ipc_post **arg, bool large)
> {
> struct ipc_post *msg;
>
> - msg = kzalloc(sizeof(*msg), GFP_KERNEL);
> + msg = kzalloc(sizeof(*msg), GFP_ATOMIC);
> if (!msg)
> return -ENOMEM;
> if (large) {
> - msg->mailbox_data = kzalloc(SST_MAILBOX_SIZE, GFP_KERNEL);
> + msg->mailbox_data = kzalloc(SST_MAILBOX_SIZE, GFP_ATOMIC);
> if (!msg->mailbox_data) {
> kfree(msg);
> return -ENOMEM;
>
Powered by blists - more mailing lists