From: Matthieu Baerts <matttbe@kernel.org>
To: Geliang Tang <geliang@kernel.org>, mptcp@lists.linux.dev
Subject: Re: [PATCH mptcp-next v6 3/7] mptcp: pm: improve error messages
Date: Mon, 6 Jan 2025 10:03:08 +0100 [thread overview]
Message-ID: <c14cb0e4-b84f-416f-96d7-00314292b921@kernel.org> (raw)
In-Reply-To: <296441f6258e6f112dfca28e6f21a815d9cab598.camel@kernel.org>
On 06/01/2025 09:55, Geliang Tang wrote:
> Happy New Year Matt!
Thank you! :)
Happy New Year as well (even if I should probably say that to you at the
end of January :) )
> On Mon, 2025-01-06 at 09:45 +0100, Matthieu Baerts wrote:
>> Hi Geliang,
>>
>> On 06/01/2025 09:41, Geliang Tang wrote:
>>> On Mon, 2024-12-30 at 14:24 +0100, Matthieu Baerts (NGI0) wrote:
>>>> Some error messages were:
>>>>
>>>> - too generic: "missing input", "invalid request"
>>>>
>>>> - not precise enough: "limit greater than maximum" but what's
>>>> the
>>>> max?
>>>>
>>>> - missing: subflow not found, or connect error.
>>>>
>>>> This can be easily improved by being more precise, or adding new
>>>> error
>>>> messages.
>>
>> (...)
>>
>>>> diff --git a/net/mptcp/pm_userspace.c b/net/mptcp/pm_userspace.c
>>>> index
>>>> 9c0bec588c498e0aa78acf4018db509abe90cad2..a8f73b082460ba00f7fa998
>>>> cf76
>>>> 46368f8201e2e 100644
>>>> --- a/net/mptcp/pm_userspace.c
>>>> +++ b/net/mptcp/pm_userspace.c
>>
>> (...)
>>
>>>> @@ -634,6 +638,9 @@ int mptcp_userspace_pm_set_flags(struct
>>>> sk_buff
>>>> *skb, struct genl_info *info)
>>>> ret = mptcp_pm_nl_mp_prio_send_ack(msk, &loc.addr,
>>>> &rem.addr, bkup);
>>>> release_sock(sk);
>>>>
>>>> + if (ret)
>>>> + GENL_SET_ERR_MSG(info, "subflow not found");
>>>
>>> I guess you don't want to use "subflow not found" here. I changed
>>> it as
>>> "mp_prio send ack failed" in v7.
>>
>> No, I wanted to use "subflow not found":
>> mptcp_pm_nl_mp_prio_send_ack()
>> will fail only if it cannot find the subflow matching the local and
>> remote attributes.
>
> My bad, how about using "subflow not found in set_flags" here, and use
> "subflow not found in subflow_destroy" for
> mptcp_pm_nl_subflow_destroy_doit?
I don't think we need a different error message: the userspace will send
a specific Netlink command, and an error can be returned. No need to
mention which command it is I think.
If you prefer, feel free to add a comment above this error here:
/* mptcp_pm_nl_mp_prio_send_ack will fail if it cannot find a subflow */
While at it, if you plan to send a v8, please use 'if (ret < 0)' to
clearly show we are looking at errors. (When the variable is called
'err', that's clearer, but no need to change it here.)
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
next prev parent reply other threads:[~2025-01-06 9:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-30 13:24 [PATCH mptcp-next v6 0/7] mptcp: use GENL_REQ_ATTR_CHECK in userspace pm Matthieu Baerts (NGI0)
2024-12-30 13:24 ` [PATCH mptcp-next v6 1/7] mptcp: pm: use NL_SET_ERR_MSG_ATTR when possible Matthieu Baerts (NGI0)
2025-01-06 8:27 ` Geliang Tang
2024-12-30 13:24 ` [PATCH mptcp-next v6 2/7] mptcp: pm: more precise error messages Matthieu Baerts (NGI0)
2025-01-06 8:38 ` Geliang Tang
2025-01-06 8:55 ` Matthieu Baerts
2024-12-30 13:24 ` [PATCH mptcp-next v6 3/7] mptcp: pm: improve " Matthieu Baerts (NGI0)
2025-01-06 8:41 ` Geliang Tang
2025-01-06 8:45 ` Matthieu Baerts
2025-01-06 8:55 ` Geliang Tang
2025-01-06 9:03 ` Matthieu Baerts [this message]
2024-12-30 13:24 ` [PATCH mptcp-next v6 4/7] mptcp: pm: userspace: flags: clearer msg if no remote addr Matthieu Baerts (NGI0)
2025-01-06 8:46 ` Geliang Tang
2024-12-30 13:24 ` [PATCH mptcp-next v6 5/7] mptcp: pm: userspace: use GENL_REQ_ATTR_CHECK Matthieu Baerts (NGI0)
2024-12-30 13:24 ` [PATCH mptcp-next v6 6/7] mptcp: pm: remove duplicated error messages Matthieu Baerts (NGI0)
2024-12-30 13:24 ` [PATCH mptcp-next v6 7/7] mptcp: pm: mark missing address attributes Matthieu Baerts (NGI0)
2024-12-30 14:21 ` [PATCH mptcp-next v6 0/7] mptcp: use GENL_REQ_ATTR_CHECK in userspace pm MPTCP CI
2025-01-06 8:24 ` Geliang Tang
2025-01-06 9:08 ` Matthieu Baerts
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c14cb0e4-b84f-416f-96d7-00314292b921@kernel.org \
--to=matttbe@kernel.org \
--cc=geliang@kernel.org \
--cc=mptcp@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.