ASoC: soc-pcm: dpcm: fix playback/capture checks by plbossart · Pull Request #2058 · thesofproject/linux

plbossart · 2020-04-27T22:40:35Z

Recent changes in the ASoC core prevent multi-cpu BE dailinks from
being used. DPCM does support multi-cpu DAIs for BE Dailinks, but not
for FE.

Handle the FE checks first, and make sure all DAIs support the same
capabilities within the same dailink.

BugLink: #2031
Fixes: 9b5db05 ("ASoC: soc-pcm: dpcm: Only allow playback/capture if supported")
Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com

plbossart · 2020-04-27T22:40:47Z

Fixes #2031

plbossart · 2020-04-27T23:33:07Z

@Minecrell FYI

bardliao

LGTM

kv2019i

I run out of time a bit -- it seems I'd need to study the surrounding code more to really understand whether this is ok or not.

kv2019i · 2020-04-28T16:29:49Z

+
+ if (rtd->dai_link->dpcm_playback) {
+ stream = SNDRV_PCM_STREAM_PLAYBACK;
+ if (snd_soc_dai_stream_valid(cpu_dai, stream)) {


Oh, ASoC makes my head hurt again.
I don't quite get why "snd_soc_dai_stream_valid()==true" must apply for the first CPU DAI of the rtd, but for 2..N CPU DAIs, stream_valid check can fail.

the idea was to check that ALL cpu_dais in a dailink that says it can do playack can indeed do so. So my proposal is to bail if you encounter one DAI that doesn't support playback.

@plbossart I was thinking of following sequence:
CPU DAI #1 capture only but dai_link->dpcm_playback is set for the rtd so we go to L2923
CPU DAI #2 playback -> ok, playback set as 1
CPU DAI #3 another capture DAI -> as playback was set, we will return error that "CPU DAI #3 does not support playback"
... I guess this is not a case that can practically happen. If you think this is ok, I'm ok as well.

no, you're right this doesn't work in all cases.
Maybe the correct thing to do is just increment a counter for valid dais, and check after the look that they are all valid.

@kv2019i this check is good to catch human errors with the dai drv array declaration in the driver.

Recent changes in the ASoC core prevent multi-cpu BE dailinks from being used. DPCM does support multi-cpu DAIs for BE Dailinks, but not for FE. Handle the FE checks first, and make sure all DAIs support the same capabilities within the same dailink. BugLink: thesofproject#2031 Fixes: 9b5db05 ("ASoC: soc-pcm: dpcm: Only allow playback/capture if supported") Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>

…al LWT setup Recent updates to the locking mechanism that protects IPv6 routing tables [1] have affected the SRv6 networking subsystem. Such changes cause problems with some SRv6 Endpoints behaviors, like End.B6.Encaps and also impact SRv6 counters. Starting from commit 169fd62 ("ipv6: Get rid of RTNL for SIOCADDRT and RTM_NEWROUTE."), the inet6_rtm_newroute() function no longer needs to acquire the RTNL lock for creating and configuring IPv6 routes and set up lwtunnels. The RTNL lock can be avoided because the ip6_route_add() function finishes setting up a new route in a section protected by RCU. This makes sure that no dev/nexthops can disappear during the operation. Because of this, the steps for setting up lwtunnels - i.e., calling lwtunnel_build_state() - are now done in a RCU lock section and not under the RTNL lock anymore. However, creating and configuring a lwtunnel instance in an RCU-protected section can be problematic when that tunnel needs to allocate memory using the GFP_KERNEL flag. For example, the following trace shows what happens when an SRv6 End.B6.Encaps behavior is instantiated after commit 169fd62 ("ipv6: Get rid of RTNL for SIOCADDRT and RTM_NEWROUTE."): [ 3061.219696] BUG: sleeping function called from invalid context at ./include/linux/sched/mm.h:321 [ 3061.226136] in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 445, name: ip [ 3061.232101] preempt_count: 0, expected: 0 [ 3061.235414] RCU nest depth: 1, expected: 0 [ 3061.238622] 1 lock held by ip/445: [ 3061.241458] #0: ffffffff83ec64a0 (rcu_read_lock){....}-{1:3}, at: ip6_route_add+0x41/0x1e0 [ 3061.248520] CPU: 1 UID: 0 PID: 445 Comm: ip Not tainted 6.15.0-rc3-micro-vm-dev-00590-ge527e891492d thesofproject#2058 PREEMPT(full) [ 3061.248532] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 [ 3061.248549] Call Trace: [ 3061.248620] <TASK> [ 3061.248633] dump_stack_lvl+0xa9/0xc0 [ 3061.248846] __might_resched+0x218/0x360 [ 3061.248871] __kmalloc_node_track_caller_noprof+0x332/0x4e0 [ 3061.248889] ? rcu_is_watching+0x3a/0x70 [ 3061.248902] ? parse_nla_srh+0x56/0xa0 [ 3061.248938] kmemdup_noprof+0x1c/0x40 [ 3061.248952] parse_nla_srh+0x56/0xa0 [ 3061.248969] seg6_local_build_state+0x2e0/0x580 [ 3061.248992] ? __lock_acquire+0xaff/0x1cd0 [ 3061.249013] ? do_raw_spin_lock+0x111/0x1d0 [ 3061.249027] ? __pfx_seg6_local_build_state+0x10/0x10 [ 3061.249068] ? lwtunnel_build_state+0xe1/0x3a0 [ 3061.249274] lwtunnel_build_state+0x10d/0x3a0 [ 3061.249303] fib_nh_common_init+0xce/0x1e0 [ 3061.249337] ? __pfx_fib_nh_common_init+0x10/0x10 [ 3061.249352] ? in6_dev_get+0xaf/0x1f0 [ 3061.249369] ? __rcu_read_unlock+0x64/0x2e0 [ 3061.249392] fib6_nh_init+0x290/0xc30 [ 3061.249422] ? __pfx_fib6_nh_init+0x10/0x10 [ 3061.249447] ? __lock_acquire+0xaff/0x1cd0 [ 3061.249459] ? _raw_spin_unlock_irqrestore+0x22/0x70 [ 3061.249624] ? ip6_route_info_create+0x423/0x520 [ 3061.249641] ? rcu_is_watching+0x3a/0x70 [ 3061.249683] ip6_route_info_create_nh+0x190/0x390 [ 3061.249715] ip6_route_add+0x71/0x1e0 [ 3061.249730] ? __pfx_inet6_rtm_newroute+0x10/0x10 [ 3061.249743] inet6_rtm_newroute+0x426/0xc50 [ 3061.249764] ? avc_has_perm_noaudit+0x13d/0x360 [ 3061.249853] ? __pfx_inet6_rtm_newroute+0x10/0x10 [ 3061.249905] ? __lock_acquire+0xaff/0x1cd0 [ 3061.249962] ? rtnetlink_rcv_msg+0x52f/0x890 [ 3061.249996] ? __pfx_inet6_rtm_newroute+0x10/0x10 [ 3061.250012] rtnetlink_rcv_msg+0x551/0x890 [ 3061.250040] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 [ 3061.250065] ? __lock_acquire+0xaff/0x1cd0 [ 3061.250092] netlink_rcv_skb+0xbd/0x1f0 [ 3061.250108] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 [ 3061.250124] ? __pfx_netlink_rcv_skb+0x10/0x10 [ 3061.250179] ? netlink_deliver_tap+0x10b/0x700 [ 3061.250210] netlink_unicast+0x2e7/0x410 [ 3061.250232] ? __pfx_netlink_unicast+0x10/0x10 [ 3061.250241] ? __lock_acquire+0xaff/0x1cd0 [ 3061.250280] netlink_sendmsg+0x366/0x670 [ 3061.250306] ? __pfx_netlink_sendmsg+0x10/0x10 [ 3061.250313] ? find_held_lock+0x2d/0xa0 [ 3061.250344] ? import_ubuf+0xbc/0xf0 [ 3061.250370] ? __pfx_netlink_sendmsg+0x10/0x10 [ 3061.250381] __sock_sendmsg+0x13e/0x150 [ 3061.250420] ____sys_sendmsg+0x33d/0x450 [ 3061.250442] ? __pfx_____sys_sendmsg+0x10/0x10 [ 3061.250453] ? __pfx_copy_msghdr_from_user+0x10/0x10 [ 3061.250489] ? __pfx_slab_free_after_rcu_debug+0x10/0x10 [ 3061.250514] ___sys_sendmsg+0xe5/0x160 [ 3061.250530] ? __pfx____sys_sendmsg+0x10/0x10 [ 3061.250568] ? __lock_acquire+0xaff/0x1cd0 [ 3061.250617] ? find_held_lock+0x2d/0xa0 [ 3061.250678] ? __virt_addr_valid+0x199/0x340 [ 3061.250704] ? preempt_count_sub+0xf/0xc0 [ 3061.250736] __sys_sendmsg+0xca/0x140 [ 3061.250750] ? __pfx___sys_sendmsg+0x10/0x10 [ 3061.250786] ? syscall_exit_to_user_mode+0xa2/0x1e0 [ 3061.250825] do_syscall_64+0x62/0x140 [ 3061.250844] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 3061.250855] RIP: 0033:0x7f0b042ef914 [ 3061.250868] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 48 8d 05 e9 5d 0c 00 8b 00 85 c0 75 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 41 89 d4 55 48 89 f5 53 [ 3061.250876] RSP: 002b:00007ffc2d113ef8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e [ 3061.250885] RAX: ffffffffffffffda RBX: 00000000680f93fa RCX: 00007f0b042ef914 [ 3061.250891] RDX: 0000000000000000 RSI: 00007ffc2d113f60 RDI: 0000000000000003 [ 3061.250897] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000008 [ 3061.250902] R10: fffffffffffff26d R11: 0000000000000246 R12: 0000000000000001 [ 3061.250907] R13: 000055a961f8a520 R14: 000055a961f63eae R15: 00007ffc2d115270 [ 3061.250952] </TASK> To solve this issue, we replace the GFP_KERNEL flag with the GFP_ATOMIC one in those SRv6 Endpoints that need to allocate memory during the setup phase. This change makes sure that memory allocations are handled in a way that works with RCU critical sections. [1] - https://lore.kernel.org/all/20250418000443.43734-1-kuniyu@amazon.com/ Fixes: 169fd62 ("ipv6: Get rid of RTNL for SIOCADDRT and RTM_NEWROUTE.") Signed-off-by: Andrea Mayer <andrea.mayer@uniroma2.it> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://patch.msgid.link/20250429132453.31605-1-andrea.mayer@uniroma2.it Signed-off-by: Jakub Kicinski <kuba@kernel.org>

plbossart requested review from dbaluta, kv2019i, lgirdwood and ranj063 as code owners April 27, 2020 22:40

plbossart requested review from RanderWang, bardliao, lyakh and sinahuang April 27, 2020 22:41

plbossart mentioned this pull request Apr 27, 2020
[SDW][]BUG][CML-H]Dmesg shows "sof_sdw sof_sdw: ASoC: can't create pcm SDW1-Playback :-22 " when system boot up successfully. #2031
Closed

sinahuang mentioned this pull request Apr 28, 2020
[UCM2][CML-H][BUG]Speaker0,2 can't have sound output when do paplay. #2060
Closed

bardliao previously approved these changes Apr 28, 2020
View reviewed changes

RanderWang reviewed Apr 28, 2020
View reviewed changes

Comment threadsound/soc/soc-pcm.c Outdated

lyakh requested changes Apr 28, 2020
View reviewed changes

Comment threadsound/soc/soc-pcm.c Outdated

plbossart dismissed bardliao’s stale review via c32ff05April 28, 2020 13:53

plbossart force-pushed the fix/soc-new-pcm branch from 920a436 to c32ff05Compare April 28, 2020 13:53

kv2019i reviewed Apr 28, 2020
View reviewed changes

plbossart force-pushed the fix/soc-new-pcm branch from c32ff05 to 8f9cf9cCompare April 28, 2020 17:06

RanderWang approved these changes Apr 29, 2020
View reviewed changes

bardliao approved these changes Apr 29, 2020
View reviewed changes

sinahuang mentioned this pull request Apr 29, 2020
[Bug][SDW][CML_2 RTC1308] Paplay via speaker only has Left Channel Output. #1564
Closed

lyakh approved these changes Apr 29, 2020
View reviewed changes

ranj063 approved these changes Apr 29, 2020
View reviewed changes

ranj063 merged commit f97d55a into thesofproject:topic/sof-devApr 29, 2020

plbossart mentioned this pull request Apr 29, 2020
fixup! ASoC: soc-pcm: dpcm: fix playback/capture checks #2070
Merged

Navigation Menu

Uh oh!

ASoC: soc-pcm: dpcm: fix playback/capture checks - #2058

ASoC: soc-pcm: dpcm: fix playback/capture checks#2058
ranj063 merged 1 commit into
thesofproject:topic/sof-devfrom
plbossart:fix/soc-new-pcm

plbossart commented Apr 27, 2020

Uh oh!

plbossart commented Apr 27, 2020

Uh oh!

plbossart commented Apr 27, 2020

Uh oh!

bardliao left a comment

Uh oh!

Uh oh!

Uh oh!

kv2019i left a comment

Uh oh!

Uh oh!

kv2019iApr 28, 2020

Uh oh!

plbossartApr 28, 2020

Uh oh!

kv2019iApr 29, 2020

Uh oh!

plbossartApr 29, 2020

Uh oh!

ranj063Apr 29, 2020•
edited
Loading

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Uh oh!

Conversation

plbossart commented Apr 27, 2020

Uh oh!

plbossart commented Apr 27, 2020

Uh oh!

plbossart commented Apr 27, 2020

Uh oh!

bardliao left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

kv2019i left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

kv2019iApr 28, 2020

Choose a reason for hiding this comment

Uh oh!

plbossartApr 28, 2020

Choose a reason for hiding this comment

Uh oh!

kv2019iApr 29, 2020

Choose a reason for hiding this comment

Uh oh!

plbossartApr 29, 2020

Choose a reason for hiding this comment

Uh oh!

ranj063Apr 29, 2020• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

ranj063Apr 29, 2020•
edited
Loading