All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthieu Baerts <matttbe@kernel.org>
To: Geliang Tang <geliang@kernel.org>, mptcp@lists.linux.dev
Subject: Re: [PATCH mptcp-next v6 2/7] mptcp: pm: more precise error messages
Date: Mon, 6 Jan 2025 09:55:22 +0100	[thread overview]
Message-ID: <21387f9d-6c88-414c-9443-29263a03573d@kernel.org> (raw)
In-Reply-To: <0152caf3be99da2fe96a6d5e8a672b3ee18f19c7.camel@kernel.org>

Hi Geliang,

On 06/01/2025 09:38, Geliang Tang wrote:
> On Mon, 2024-12-30 at 14:24 +0100, Matthieu Baerts (NGI0) wrote:
>> Some errors reported by the userspace PM were vague: "this or that is
>> invalid".
>>
>> It is easier for the userspace to know which part is wrong, instead
>> of
>> having to guess that.
>>
>> By splitting some error messages, NL_SET_ERR_MSG_ATTR() can be used
>> instead of GENL_SET_ERR_MSG() in order to give an additional hint to
>> the
>> userspace developers about which attribute is wrong.
>>
>> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
>> ---
>>  net/mptcp/pm_userspace.c | 34 ++++++++++++++++++++++++++--------
>>  1 file changed, 26 insertions(+), 8 deletions(-)
>>
>> diff --git a/net/mptcp/pm_userspace.c b/net/mptcp/pm_userspace.c
>> index
>> 72d4861e497eef5a516fc1c3ec1659807ffedd53..9c0bec588c498e0aa78acf4018d
>> b509abe90cad2 100644
>> --- a/net/mptcp/pm_userspace.c
>> +++ b/net/mptcp/pm_userspace.c

(...)

>> @@ -592,9 +603,16 @@ int mptcp_userspace_pm_set_flags(struct sk_buff
>> *skb, struct genl_info *info)
>>  			goto set_flags_err;
>>  	}
>>  
>> -	if (loc.addr.family == AF_UNSPEC ||
>> -	    rem.addr.family == AF_UNSPEC) {
>> -		GENL_SET_ERR_MSG(info, "invalid address families");
>> +	if (loc.addr.family == AF_UNSPEC) {
>> +		NL_SET_ERR_MSG_ATTR(info->extack, attr,
>> +				    "invalid local address family");
>> +		ret = -EINVAL;
>> +		goto set_flags_err;
>> +	}
>> +
>> +	if (rem.addr.family == AF_UNSPEC) {
> 
> I moved this check into "if (attr_rem) {" block in v7.

If you do that, you are changing the behaviour: this attribute is then
no longer mandatory with the userspace PM. I don't think we should do
that, or at least, not as part of a refactoring as you did.

If we want to change the behaviour, we need an explicit patch for that.
See my patch description from patch v6 4/7, and also the
GENL_REQ_ATTR_CHECK() check added in patch v6 7/7.

> 
>> +		NL_SET_ERR_MSG_ATTR(info->extack, attr_rem,
>> +				    "invalid remote address
>> family");
>>  		ret = -EINVAL;
>>  		goto set_flags_err;
>>  	}
>>
> 

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.


  reply	other threads:[~2025-01-06  8:55 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 [this message]
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
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=21387f9d-6c88-414c-9443-29263a03573d@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.