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@xxxxxxxxxxxxxxx
> > Signed-off-by: Harin Lee <me@xxxxxxxxx>
>
> 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