Re: [PATCH] ALSA: ctxfi: Limit PTP to a single page

[Harin Lee <me@harin.net>]

On 4/6/26 5:50 PM, Takashi Iwai wrote:
> On Mon, 06 Apr 2026 09:48:57 +0200,
> Harin Lee wrote:
>>
>> Commit 391e69143d0a increased CT_PTP_NUM from 1 to 4 to support 256
>> playback streams, but the additional pages are not used by the card
>> correctly. The CT20K2 hardware already has multiple VMEM_PTPAL
>> registers, but using them separately would require refactoring the
>> entire virtual memory allocation logic.
>>
>> ct_vm_map() always uses PTEs in vm->ptp[0].area regardless of
>> CT_PTP_NUM. On AMD64 systems, a single PTP covers 512 PTEs (2M). When
>> aggregate memory allocations exceed this limit, ct_vm_map() tries to
>> access beyond the allocated space and causes a page fault:
>>
>>    BUG: unable to handle page fault for address: ffffd4ae8a10a000
>>    Oops: Oops: 0002 [#1] SMP PTI
>>    RIP: 0010:ct_vm_map+0x17c/0x280 [snd_ctxfi]
>>    Call Trace:
>>    atc_pcm_playback_prepare+0x225/0x3b0
>>    ct_pcm_playback_prepare+0x38/0x60
>>    snd_pcm_do_prepare+0x2f/0x50
>>    snd_pcm_action_single+0x36/0x90
>>    snd_pcm_action_nonatomic+0xbf/0xd0
>>    snd_pcm_ioctl+0x28/0x40
>>    __x64_sys_ioctl+0x97/0xe0
>>    do_syscall_64+0x81/0x610
>>    entry_SYSCALL_64_after_hwframe+0x76/0x7e
>>
>> Revert CT_PTP_NUM to 1. The 256 SRC_RESOURCE_NUM and playback_count
>> remain unchanged.
>>
>> Fixes: 391e69143d0a ("ALSA: ctxfi: Bump playback substreams to 256")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Harin Lee <me@harin.net>
> 
> Applied to for-next branch now, as it's no regression in 7.0, per se.
> 
> But, I wonder whether fixing in ctvmem.c would be relatively easy.
> Isn't it only about ct_vm_map() and ct_get_ptp_phys()?
> 
> 
> thanks,
> 
> Takashi

Hi Takashi.

info.vm_pgt_phys is set in atc_create_hw_devs().

   ...
   /* Initialize card hardware. */
   info.rsr = atc->rsr;
   info.msr = atc->msr;
   info.vm_pgt_phys = atc_get_ptp_phys(atc, 0);
   err = hw->card_init(hw, &info);
   if (err < 0)
     return err;
   ...

The atc_get_ptp_phys() function actually calls ct_get_ptp_phys().
However, the index is 0, which only retrieves the address of the
first PTP.

The hw_trn_init() for CT20K1 and CT20K2 writes the value of
info.vm_pgt_phys to the hardware registers.

   ...
   ptp_phys_low = (u32)info->vm_pgt_phys;
   ptp_phys_high = upper_32_bits(info->vm_pgt_phys);
   ...

CT20K1 implementation writes to the PTPALX and PTPAHX registers.
CT20K2 implementation writes same single PTP address to all 64
VMEM_PTPAL and VMEM_PTPAH registers.

We don't know if CT20K2 hardware actually supports independent PTPs,
and refactoring would be risky. So I think the current approach is
the safest for now.

This is what I've found so far.

Thanks.
Harin Lee