linux-kernel - Re: [PATCH v4 3/4] misc: fastrpc: Expand context ID mask for DSP polling mode support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <dcf552d6-dc1e-493d-9039-b7531ebb6a7f@oss.qualcomm.com>
Date: Tue, 2 Dec 2025 10:54:40 +0530
From: Ekansh Gupta <ekansh.gupta@....qualcomm.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>, srini@...nel.org,
        linux-arm-msm@...r.kernel.org
Cc: gregkh@...uxfoundation.org, quic_bkumar@...cinc.com,
        linux-kernel@...r.kernel.org, quic_chennak@...cinc.com,
        dri-devel@...ts.freedesktop.org, arnd@...db.de,
        dmitry.baryshkov@....qualcomm.com
Subject: Re: [PATCH v4 3/4] misc: fastrpc: Expand context ID mask for DSP
 polling mode support



On 11/28/2025 5:21 PM, Konrad Dybcio wrote:
> On 11/28/25 6:05 AM, Ekansh Gupta wrote:
>> Current FastRPC message context uses a 12-bit mask where the upper
>> 8 bits represent the context ID from idr_alloc_cyclic and the lower
>> 4 bits represent the PD type.
> <newline>
>
>> This layout works for normal FastRPC
>> calls but fails for polling mode because DSP expects a 16-bit context
>> with an additional async mode bit. 
> <newline>
>
>> To enable polling mode support
>> from DSP(DSP writes to poll memory), DSP expects a 16-bit context
>> where the upper 8 bits are context ID, the lower 4 bits are PD type
>> and the 5th bit from the end denotes async mode(not yet upstreamed).
> <newline>
Ack.
>
> so we get
>
> 1
> 5	       0
> CCCCCCCCxxxAPPPP
>
> where C is context ID, A is is_async, and P is PD type
>
> are the x bits reserved, or do they serve some purpose?
x bits are reserved.
>
>> If this bit is set, DSP disables polling. With the current design,
>> odd context IDs set this bit, causing DSP to skip poll memory updates.
> <newline>
>
>> Update the context mask to ensure a hole which won't get populated,
> "to avoid erroneously setting that bit"
Ack.
>
>> ensuring polling mode works as expected. This is not a bug and the
>> change is added to support polling mode.
> I think the main question that remains unanswered here is that you alter
> the non-polling mode mask to become compliant with what polling-mode
> expects.
>
> Is that intended? Will this still work fine without patch 4 and the
> new FASTRPC_IOCTL_SET_OPTION?
Things works fine with or without patch 4. Patch 4 is needed only to
enable polling mode option.

I'll rephrase the commit text to include this information as well.

//Ekansh
>
> Konrad