From: ally heev <allyheev@gmail.com>
To: Przemek Kitszel <przemyslaw.kitszel@intel.com>,
Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>,
"K. Y. Srinivasan" <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
Wei Liu <wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>,
Aleksandr Loktionov <aleksandr.loktionov@intel.com>,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
Dan Carpenter <dan.carpenter@linaro.org>
Subject: Re: [Intel-wired-lan] [PATCH v3] net: ethernet: fix uninitialized pointers with free attribute
Date: Fri, 07 Nov 2025 12:57:18 +0530 [thread overview]
Message-ID: <cb130473feb7b02a85c210df192fc6482ff4fa35.camel@gmail.com> (raw)
In-Reply-To: <afa219b7-9ce3-4da8-a339-8f363d77824e@intel.com>
On Fri, 2025-11-07 at 06:39 +0100, Przemek Kitszel wrote:
> On 11/6/25 17:05, ally heev wrote:
> > On Thu, 2025-11-06 at 15:07 +0100, Alexander Lobakin wrote:
> > [..]
> > > >
> > > > diff --git a/drivers/net/ethernet/intel/ice/ice_flow.c b/drivers/net/ethernet/intel/ice/ice_flow.c
> > > > index 6d5c939dc8a515c252cd2b77d155b69fa264ee92..3590dacf3ee57879b3809d715e40bb290e40c4aa 100644
> > > > --- a/drivers/net/ethernet/intel/ice/ice_flow.c
> > > > +++ b/drivers/net/ethernet/intel/ice/ice_flow.c
> > > > @@ -1573,12 +1573,13 @@ ice_flow_set_parser_prof(struct ice_hw *hw, u16 dest_vsi, u16 fdir_vsi,
> > > > struct ice_parser_profile *prof, enum ice_block blk)
> > > > {
> > > > u64 id = find_first_bit(prof->ptypes, ICE_FLOW_PTYPE_MAX);
> > > > - struct ice_flow_prof_params *params __free(kfree);
> > > > u8 fv_words = hw->blk[blk].es.fvw;
> > > > int status;
> > > > int i, idx;
> > > >
> > > > - params = kzalloc(sizeof(*params), GFP_KERNEL);
> > > > + struct ice_flow_prof_params *params __free(kfree) =
> > > > + kzalloc(sizeof(*params), GFP_KERNEL);
> > >
> > > Please don't do it that way. It's not C++ with RAII and
> > > declare-where-you-use.
> > > Just leave the variable declarations where they are, but initialize them
> > > with `= NULL`.
>
> +1
>
> > >
> > > Variable declarations must be in one block and sorted from the longest
> > > to the shortest.
> > >
> > > But most important, I'm not even sure how you could trigger an
> > > "undefined behaviour" here. Both here and below the variable tagged with
> > > `__free` is initialized right after the declaration block, before any
> > > return. So how to trigger an UB here?
> >
> > It doesn't occur here. But, many maintainers/developers consider it a
> > bad practice because if the function returns before initialization or
> > use of `goto` can cause such behaviors.
>
> we were bitten by that already, scenario is as follow:
> 0. have a good code w/o UB and w/o redundant = NULL
> 1. add some early return, say:
> if (dest_vsi == fdir_vsi)
> return -EINVAL;
> 2. almost granted that person adding 1. will forget to add = NULL to all
> declarations marked __free
>
> >
> > Here though, the definitions are still at the top right? Maybe I could
> > just sort them
>
> we discourage putting any operations, including allocations, that may
> fail into the declarations block
>
Makes sense. I will just initialize them with NULL then
next prev parent reply other threads:[~2025-11-07 7:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-06 11:55 [PATCH v3] net: ethernet: fix uninitialized pointers with free attribute Ally Heev
2025-11-06 14:07 ` [Intel-wired-lan] " Alexander Lobakin
2025-11-06 16:05 ` ally heev
2025-11-07 5:39 ` Przemek Kitszel
2025-11-07 7:27 ` ally heev [this message]
2025-11-08 16:36 ` Simon Horman
2025-11-10 6:56 ` ally heev
2025-11-17 13:11 ` Dan Carpenter
2025-11-17 14:37 ` Alexander Lobakin
2025-11-17 18:11 ` Dan Carpenter
2025-11-19 11:25 ` Alexander Lobakin
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=cb130473feb7b02a85c210df192fc6482ff4fa35.camel@gmail.com \
--to=allyheev@gmail.com \
--cc=aleksander.lobakin@intel.com \
--cc=aleksandr.loktionov@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=dan.carpenter@linaro.org \
--cc=davem@davemloft.net \
--cc=decui@microsoft.com \
--cc=edumazet@google.com \
--cc=haiyangz@microsoft.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=kuba@kernel.org \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=wei.liu@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;
as well as URLs for NNTP newsgroup(s).