RE: [EXTERNAL] [PATCH net] octeontx2-af: cn10k: restrict LMTLINE sharing to same PF

[Geethasowjanya Akula]

>-----Original Message-----
>From: Junrui Luo <moonafterrain@xxxxxxxxxxx>
>Sent: Thursday, May 28, 2026 9:58 PM
>To: Geethasowjanya Akula <gakula@xxxxxxxxxxx>
>Cc: Jakub Kicinski <kuba@xxxxxxxxxx>; Yuhao Jiang <danisjiang@xxxxxxxxx>;
>Sunil Kovvuri Goutham <sgoutham@xxxxxxxxxxx>; Linu Cherian
><lcherian@xxxxxxxxxxx>; Hariprasad Kelam <hkelam@xxxxxxxxxxx>;
>Subbaraya Sundeep Bhatta <sbhatta@xxxxxxxxxxx>; Andrew Lunn
><andrew+netdev@xxxxxxx>; David S. Miller <davem@xxxxxxxxxxxxx>; Eric
>Dumazet <edumazet@xxxxxxxxxx>; Paolo Abeni <pabeni@xxxxxxxxxx>;
>netdev@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; stable@xxxxxxxxxxxxxxx
>Subject: Re: [EXTERNAL] [PATCH net] octeontx2-af: cn10k: restrict LMTLINE
>sharing to same PF
>On Wed, May 27, 2026 at 05:20:12AM +0000, Geethasowjanya Akula wrote:
>> Hi Junrui and Jakub,
>>
>> This patch enforces that the requester’s pcifunc and req->base_pcifunc
>belong to the same PF.
>> However, this assumption is not always valid.
>> We have valid use cases where LMTST lines are intentionally shared
>> across multiple PFs. In such scenarios, the base_pcifunc may
>> legitimately belong to a different PF, and restricting access to the same PF
>would break these existing use cases.
>
>Thanks for the review. To preserve cross-PF sharing while still restricting VF
>callers, would the check below match your expectation?
>
>	if (is_vf(req->hdr.pcifunc) &&
>	    rvu_get_pf(rvu->pdev, req->hdr.pcifunc) !=
>	    rvu_get_pf(rvu->pdev, req->base_pcifunc))
>	        return -EPERM;

Hi Junrui,

Thanks for the update,
Restricting only VF callers from accessing LMTLINEs across PF boundaries makes sense from a security standpoint.
The changes  aligns with our expectations.
LGTM.

Geetha.
>
>Thanks,
>Junrui Luo