From: Paolo Abeni <pabeni@redhat.com>
To: "Krzysztof Hałasa" <khalasa@piap.pl>
Cc: Kriish Sharma <kriish.sharma2006@gmail.com>,
khc@pm.waw.pl, andrew+netdev@lunn.ch, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drivers/net/wan/hdlc_ppp: fix potential null pointer in ppp_cp_event logging
Date: Tue, 7 Oct 2025 12:46:02 +0200 [thread overview]
Message-ID: <71dda358-c1f7-46ab-a241-dffc3c1c065d@redhat.com> (raw)
In-Reply-To: <m37bx7t604.fsf@t19.piap.pl>
On 10/7/25 11:28 AM, Krzysztof Hałasa wrote:
> Paolo Abeni <pabeni@redhat.com> writes:
>> If v2 is not ready yet, I think it would be better returning "unknown"
>> instead of "LCP" when the protocol id is actually unknown.
>>
>> In the current code base, such case is unexpected/impossible, but the
>> compiler force us to handle it anyway. I think we should avoid hiding
>> the unexpected event.
>>
>> Assuming all the code paths calling proto_name() ensure the pid is a
>> valid one, you should possibly add a WARN_ONCE() on the default case.
>
> Look, this is really simple code. Do we need additional bloat
> everywhere?
>
> The compiler doesn't force us to anything. We define that, as far as
> get_proto() is concerned, PID_IPCP is "IPCP", PID_IPV6CP is "IPV6CP",
> and all other values mean "LCP". Then we construct the switch statement
> accordingly. Well, it seems I failed it slightly originally, most
> probably due to copy & paste from get_proto(). Now Kriish has noticed it
> and agreed to make it perfect.
>
> Do you really think we should now change semantics of this 20 years old
> code (most probably never working incorrectly), adding some "unknown"
> (yet impossible) case, and WARNing about a condition which is excluded
> at the start of the whole RX parser?
Note that the suggested change is not going to change any semantic, just
make it clear for future changes that such case is not really expected.
And that in turn is my point. If someone else is going to touch this
code in the (not so near) future, such person will not have to read all
the possible code paths leading to proto_name() to understand the
assumption in the current code base.
Cheers,
Paolo
next prev parent reply other threads:[~2025-10-07 10:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-02 18:05 Kriish Sharma
2025-10-02 18:16 ` Dimitri Daskalakis
2025-10-02 18:31 ` Kriish Sharma
2025-10-03 6:34 ` Krzysztof Hałasa
2025-10-03 6:43 ` Kriish Sharma
2025-10-07 8:41 ` Paolo Abeni
2025-10-07 9:28 ` Krzysztof Hałasa
2025-10-07 10:46 ` Paolo Abeni [this message]
2025-10-07 11:38 ` Krzysztof Hałasa
2025-10-03 8:33 ` Simon Horman
2025-10-03 9:02 ` Kriish Sharma
2025-10-03 9:40 ` Simon Horman
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=71dda358-c1f7-46ab-a241-dffc3c1c065d@redhat.com \
--to=pabeni@redhat.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=khalasa@piap.pl \
--cc=khc@pm.waw.pl \
--cc=kriish.sharma2006@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®