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: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-06 11:55 [Intel-wired-lan] [PATCH v3] net: ethernet: fix uninitialized pointers with free attribute Ally Heev
2025-11-06 11:55 ` 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 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.