1. 26 Jun, 2019 1 commit
  2. 24 Jun, 2019 3 commits
    • Mark Brown's avatar
      ASoC: dapm: Adapt for debugfs API change · ceaea851
      Mark Brown authored
      Back in ff9fb72b (debugfs: return error values, not NULL) the
      debugfs APIs were changed to return error pointers rather than NULL
      pointers on error, breaking the error checking in ASoC. Update the
      code to use IS_ERR() and log the codes that are returned as part of
      the error messages.
      
      Fixes: ff9fb72b (debugfs: return error values, not NULL)
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      ceaea851
    • Mark Brown's avatar
      ASoC: core: Adapt for debugfs API change · c2c928c9
      Mark Brown authored
      Back in ff9fb72b (debugfs: return error values, not NULL) the
      debugfs APIs were changed to return error pointers rather than NULL
      pointers on error, breaking the error checking in ASoC. Update the
      code to use IS_ERR() and log the codes that are returned as part of
      the error messages.
      
      Fixes: ff9fb72b (debugfs: return error values, not NULL)
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      c2c928c9
    • Kuninori Morimoto's avatar
      ASoC: soc-core: call snd_soc_unbind_card() under mutex_lock; · b545542a
      Kuninori Morimoto authored
      commit 34ac3c3e ("ASoC: core: lock client_mutex while removing
      link components") added mutex_lock() at soc_remove_link_components().
      
      Is is called from snd_soc_unbind_card()
      
      	snd_soc_unbind_card()
      =>		soc_remove_link_components()
      		soc_cleanup_card_resources()
      			soc_remove_dai_links()
      =>				soc_remove_link_components()
      
      And, there are 2 way to call it.
      
      (1)
      	snd_soc_unregister_component()
      **		mutex_lock()
      			snd_soc_component_del_unlocked()
      =>				snd_soc_unbind_card()
      **		mutex_unlock()
      
      (2)
      	snd_soc_unregister_card()
      =>		snd_soc_unbind_card()
      
      (1) case is already using mutex_lock() when it calles
      snd_soc_unbind_card(), thus, we will get lockdep warning.
      
      commit 495f926c ("ASoC: core: Fix deadlock in
      snd_soc_instantiate_card()") tried to fixup it, but still not
      enough. We still have lockdep warning when we try unbind/bind.
      
      We need mutex_lock() under snd_soc_unregister_card()
      instead of snd_remove_link_components()/snd_soc_unbind_card().
      
      Fixes: 34ac3c3e ("ASoC: core: lock client_mutex while removing link components")
      Fixes: 495f926c ("ASoC: core: Fix deadlock in snd_soc_instantiate_card()")
      Signed-off-by: default avatarKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      b545542a
  3. 18 Jun, 2019 3 commits
  4. 17 Jun, 2019 1 commit
  5. 13 Jun, 2019 5 commits
  6. 10 Jun, 2019 2 commits
    • Alex Levin's avatar
      ASoC: Intel: sst: fix kmalloc call with wrong flags · 3da428ff
      Alex Levin authored
      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():
      
      Fixes: 972b0d45 ("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: default avatarAlex Levin <levinale@chromium.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      3da428ff
    • Ranjani Sridharan's avatar
      ASoC: core: Fix deadlock in snd_soc_instantiate_card() · 495f926c
      Ranjani Sridharan authored
      Move the client_mutex lock to snd_soc_unbind_card() before
      removing link components. This prevents the deadlock
      in the error path in snd_soc_instantiate_card().
      
      Fixes: 34ac3c3e (ASoC: core: lock client_mutex while removing
      link components)
      Reported-by: default avatarkernelci.org bot <bot@kernelci.org>
      Signed-off-by: default avatarRanjani Sridharan <ranjani.sridharan@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      495f926c
  7. 06 Jun, 2019 8 commits
  8. 04 Jun, 2019 5 commits
  9. 03 Jun, 2019 7 commits
  10. 29 May, 2019 1 commit
  11. 28 May, 2019 4 commits