[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <57c2976e-8b6c-4cee-803f-ca5b0636f30b@linux.ibm.com>
Date: Mon, 1 Sep 2025 11:42:38 +0530
From: Mahanta Jambigi <mjambigi@...ux.ibm.com>
To: dust.li@...ux.alibaba.com, andrew+netdev@...n.ch, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
alibuda@...ux.alibaba.com, sidraya@...ux.ibm.com, wenjia@...ux.ibm.com
Cc: pasic@...ux.ibm.com, horms@...nel.org, tonylu@...ux.alibaba.com,
guwen@...ux.alibaba.com, netdev@...r.kernel.org,
linux-s390@...r.kernel.org, linux-rdma@...r.kernel.org,
Alexandra Winter <wintera@...ux.ibm.com>
Subject: Re: [PATCH net] net/smc: Remove validation of reserved bits in CLC
Decline message
On 29/08/25 8:28 pm, Dust Li wrote:
>>
>> Fixes: 8ade200(net/smc: add v2 format of CLC decline message)
>>
>> Signed-off-by: Mahanta Jambigi <mjambigi@...ux.ibm.com>
>> Reference-ID: LTC214332
>
> I think this is your internal ID ? It's better not to leave that
> in the upstream patches.
Oops, I missed to remove it. Sure, I'll remove it.
>
>> Reviewed-by: Sidraya Jayagond <sidraya@...ux.ibm.com>
>> Reviewed-by: Alexandra Winter <wintera@...ux.ibm.com>
>>
>> ---
>> net/smc/smc_clc.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/net/smc/smc_clc.c b/net/smc/smc_clc.c
>> index 5a4db151fe95..08be56dfb3f2 100644
>> --- a/net/smc/smc_clc.c
>> +++ b/net/smc/smc_clc.c
>> @@ -426,8 +426,6 @@ smc_clc_msg_decl_valid(struct smc_clc_msg_decline *dclc)
>> {
>> struct smc_clc_msg_hdr *hdr = &dclc->hdr;
>>
>> - if (hdr->typev1 != SMC_TYPE_R && hdr->typev1 != SMC_TYPE_D)
>> - return false;
>
> Here it's checking the typev1 in smc_clc_msg_hdr, but your commit message
> says it's validating the reserved bits:
>
> Currently SMC code is validating the reserved bits while parsing the incoming
> CLC decline message & when this validation fails, its treated as a protocol
> error.
>
> Did I miss something ?
If you refer to struct *smc_clc_msg_hdr* in smc_clc.h file, typev1
member represents bits 4 & 5 at offset 7. If we compare it with the CLC
Decline message header, it represents one of the reserved(5-7 bits) at
offset 7. You can refer to below link for reserved bits.
https://datatracker.ietf.org/doc/html/rfc7609#page-105
>
> Best regards,
> Dust
Powered by blists - more mailing lists