From: "Krzysztof Hałasa" <khalasa@piap.pl>
To: Paolo Abeni <pabeni@redhat.com>
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, 07 Oct 2025 13:38:42 +0200 [thread overview]
Message-ID: <m3347vszzx.fsf@t19.piap.pl> (raw)
In-Reply-To: <71dda358-c1f7-46ab-a241-dffc3c1c065d@redhat.com> (Paolo Abeni's message of "Tue, 7 Oct 2025 12:46:02 +0200")
Paolo Abeni <pabeni@redhat.com> writes:
> 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.
But there is no "other case", any numeric argument this function is
called with is expected. This is not a hdlc-ppp-wide function. Such
a function was simply not needed. That the function returned NULL in an
impossible case is just, I guess, my coding deficiency. Not my worst,
though :-)
Would you rather like #define proto_name(x) ((x) == PID_LCP ? "LCP" : (x)
== PID_IPCP ? "IPCP" : "IPV6CP")? Or maybe you would like the "unknown"
case there as well?
This function is for only those 3 protocols, all of them being "control
protocols": IP control protocol, IPv6 control protocol, and link control
protocol. Think of it as of
enum control_protocols {LCP, IP, IPV6};
proto_name(enum control_protocols)
...
You must not call this function in any other context, e.g. it's not OK
to call it with PID_IP nor PID_IPV6 (which are otherwise perfectly valid
PIDs in this very file).
If the function's name is misleading, perhaps it could be extended to
control_proto_name(). Not that I find such changes entertaining, but it
would be technically correct after all.
HTH,
--
Krzysztof "Chris" Hałasa
Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa
next prev parent reply other threads:[~2025-10-07 11:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-02 18:05 [PATCH] drivers/net/wan/hdlc_ppp: fix potential null pointer in ppp_cp_event logging 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
2025-10-07 11:38 ` Krzysztof Hałasa [this message]
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=m3347vszzx.fsf@t19.piap.pl \
--to=khalasa@piap.pl \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--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 \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).