Hi Geliang, Mat,
Thank you for the reviews!
On 23/03/2021 04:06, Geliang Tang wrote:
Thanks for your patches.
Mat Martineau <mathew.j.martineau(a)linux.intel.com> 于2021年3月23日周二 上午5:56写道：
> On Mon, 22 Mar 2021, Matthieu Baerts wrote:
>> Fix issues reported by sparse because we are doing non explicit casting
>> from __be16 to integer.
>> net/mptcp/options.c:604:24: warning: restricted __be16 degrades to integer
>> net/mptcp/options.c:605:24: warning: restricted __be16 degrades to integer
>> Before the mentioned commit, we were using port in u16 given in argument
>> of add_addr_generate_hmac function, everything was OK.
>> Signed-off-by: Matthieu Baerts <matthieu.baerts(a)tessares.net>
>> net/mptcp/options.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
> I think the subject line is incorrect on this one (it applies cleanly to
> "mptcp: unify add_addr(6)_generate_hmac" instead)
Oh yes sorry, I picked the wrong commit, thank you for noticing that :)
> , but other than that all
> three patches look good to squash. Thanks!
>> diff --git a/net/mptcp/options.c b/net/mptcp/options.c
>> index 071b446aa2c9..d9e5f864d774 100644
>> --- a/net/mptcp/options.c
>> +++ b/net/mptcp/options.c
>> @@ -586,6 +586,7 @@ static bool mptcp_established_options_dss(struct sock *sk,
struct sk_buff *skb,
>> static u64 add_addr_generate_hmac(u64 key1, u64 key2,
>> struct mptcp_addr_info *addr)
>> + u16 port = be16_to_cpu(addr->port);
I prefer to use ntohs/htons instead of be16_to_cpu/cpu_to_be16 in these
three patches to keep the consistency of the port number converting.
No you are right, I don't know why I didn't use ntohs/htons, I think I
was focused on the compiler issue forgetting the network env :)
I hope you don't mind if I apply the modifications (code and commit
messages) directly without sending a v2. Then I would be able to unblock
the CI to have new versions of the export branch.
Tessares | Belgium | Hybrid Access Solutions