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

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

[Harin Lee]

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>
---
 sound/pci/ctxfi/ctvmem.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/pci/ctxfi/ctvmem.h b/sound/pci/ctxfi/ctvmem.h
index da54cbcdb0be..43a0065b40c3 100644
--- a/sound/pci/ctxfi/ctvmem.h
+++ b/sound/pci/ctxfi/ctvmem.h
@@ -15,7 +15,7 @@
 #ifndef CTVMEM_H
 #define CTVMEM_H
 
-#define CT_PTP_NUM	4	/* num of device page table pages */
+#define CT_PTP_NUM	1	/* num of device page table pages */
 
 #include <linux/mutex.h>
 #include <linux/list.h>
-- 
2.53.0

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

[Takashi Iwai]

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

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

[Harin Lee]

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

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

[Takashi Iwai]

On Mon, 06 Apr 2026 12:32:43 +0200,
Harin Lee wrote:
> 
> 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.

Makes sense.  As already mentioned, your patch was applied.
If any further development to extend PTPs again, feel free to
resubmit.


thanks,

Takashi