All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mat Martineau <martineau@kernel.org>
To: Matthieu Baerts <matttbe@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>, mptcp@lists.linux.dev
Subject: Re: [PATCH mptcp-net] mptcp: avoid printing warning once on client side
Date: Fri, 16 Feb 2024 11:59:02 -0800 (PST)	[thread overview]
Message-ID: <bc35a839-0353-abd3-cb51-2d48228f4078@kernel.org> (raw)
In-Reply-To: <59625ef0-1f81-4660-b585-2e9a9ac4a8c6@kernel.org>

[-- Attachment #1: Type: text/plain, Size: 2061 bytes --]

On Fri, 16 Feb 2024, Matthieu Baerts wrote:

> Hi Paolo,
>
> Thank you for your reply!
>
> On 16/02/2024 12:23, Paolo Abeni wrote:
>> On Fri, 2024-02-16 at 11:42 +0100, Matthieu Baerts wrote:
>>> On 16/02/2024 00:25, Mat Martineau wrote:
>>>> On Thu, 15 Feb 2024, Matthieu Baerts (NGI0) wrote:
>
> (...)
>
>>>>> Notes:
>>>>> - Should we convert this pr_warn_once() to a WARN_ONCE()? Or just in
>>>>>   our tree? Or just in DEBUG mode?
>>>>
>>>> I think it makes sense to keep this patch minimal for -net and stable
>>>> (just moving the label).
>>>>
>>>> Also given the consequences of panic_on_warn, would be better to make
>>>> any changes to WARN_ONCE() in mptcp-next/net-next. I don't see extra
>>>> complexity to modify this warning in our tree or debug mode as being
>>>> worth it, do you think it would be valuable?
>>>
>>> Sorry, I'm a bit confused by your reply. For the moment, our CI
>>> complains when a "Call Trace:" is printed, but it doesn't complain when
>>> there is a pr_warn().
>>>

Ok, I didn't realize our CI ignored pr_warn() output so didn't really see 
the motivation for switching to the WARN() macro - but did want to make 
sure (at a minimum) that you weren't proposing WARN() for a -net patch.

>>> If the warning here can be caused by interactions with a buggy host, it
>>> makes sense not to have a WARN() when used in production, but it would
>>> be good for our CI can catch that. If the warning can only be caused by
>>> an internal bug, then easier to use a WARN_ONCE().

This makes sense - I agree it's better for CI to catch it.

>>
>> We can trigger the warning due to either:
>> * local S/W bug
>> * bugged/malicious peer.
>>
>> I think we should avoid a WARN there.
>>
>>> So I think here, we could maybe convert it to a DEBUG_NET_WARN_ON_ONCE()
>>> and upstream that. WDYT?
>>
>> DEBUG_NET is quite lightweight and could be enabled even in production,
>
> Ah OK, I didn't know that!
>
>> that should be an export-branch only change.
>

+1

> Fine by me! I appreciate your suggestion.
>

Thanks Paolo and Matthieu


- Mat

  reply	other threads:[~2024-02-16 19:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-15 15:06 [PATCH mptcp-net] mptcp: avoid printing warning once on client side Matthieu Baerts (NGI0)
2024-02-15 15:54 ` mptcp: avoid printing warning once on client side: Tests Results MPTCP CI
2024-02-15 16:20 ` MPTCP CI
2024-02-15 16:43 ` MPTCP CI
2024-02-15 23:25 ` [PATCH mptcp-net] mptcp: avoid printing warning once on client side Mat Martineau
2024-02-16 10:42   ` Matthieu Baerts
2024-02-16 11:23     ` Paolo Abeni
2024-02-16 11:33       ` Matthieu Baerts
2024-02-16 19:59         ` Mat Martineau [this message]
2024-02-16  0:24 ` mptcp: avoid printing warning once on client side: Tests Results MPTCP CI
2024-02-16  0:45 ` MPTCP CI
2024-02-16 10:46 ` [PATCH mptcp-net] mptcp: avoid printing warning once on client side 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=bc35a839-0353-abd3-cb51-2d48228f4078@kernel.org \
    --to=martineau@kernel.org \
    --cc=matttbe@kernel.org \
    --cc=mptcp@lists.linux.dev \
    --cc=pabeni@redhat.com \
    /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.