From: Przemek Kitszel <przemyslaw.kitszel@intel.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: <netdev@vger.kernel.org>, <rafal.romanowski@intel.com>,
<aleksandr.loktionov@intel.com>, <andrew+netdev@lunn.ch>,
<edumazet@google.com>, <marcin.szycik@linux.intel.com>,
<anthony.l.nguyen@intel.com>, <horms@kernel.org>,
<intel-wired-lan@lists.osuosl.org>, <pabeni@redhat.com>,
<davem@davemloft.net>
Subject: Re: [Intel-wired-lan] [PATCH net v2 2/2] ice: fix stats array overflow via proper realloc
Date: Wed, 19 Aug 2026 12:52:39 +0200 [thread overview]
Message-ID: <53c50cd8-edfa-4fe3-aec7-a6d66194e635@intel.com> (raw)
In-Reply-To: <20260817205047.3612990-1-kuba@kernel.org>
> [Severity: Low]
> Does moving the ice_vsi_realloc_stat_arrays() call change what happens when
> the stat array allocation fails during a rebuild?
>
> Before this patch, ice_vsi_rebuild() did the realloc before
> ice_vsi_decfg(), so a krealloc_array() failure returned -ENOMEM with the VSI
> still fully configured:
>
> ret = ice_vsi_realloc_stat_arrays(vsi);
> if (ret)
> goto unlock;
>
> ice_vsi_decfg(vsi);
>
> Now the only call site is inside ice_vsi_cfg_def(), which runs after
> ice_vsi_decfg(), so an -ENOMEM there unwinds via unroll_vsi_alloc and is
> propagated out of ice_vsi_rebuild() with the queues, vectors and rings
> already released.
>
> For the ethtool -L path that leaves ice_vsi_recfg_qs() in ice_main.c with
> only this recovery:
>
> rebuild_err:
> dev_err(ice_pf_to_dev(pf), "Error during VSI rebuild: %d. Unload and reload the driver.\n",
> err);
>
> The same outcome was already reachable pre-patch through the other
> allocations in ice_vsi_cfg_def() (ice_vsi_alloc_def(),
> ice_vsi_alloc_q_vectors(), ice_vsi_alloc_rings(),
> ice_vsi_alloc_ring_stats()), so this adds one more allocation to an
> already-destructive region rather than a new failure mode.
>
> The commit message describes the move only as:
>
> Also drop one callsite to avoid some duplication.
>
> Could it also mention that the previously non-destructive failure path for
> this allocation is gone?
I see no point documenting such minor details in commit message.
As a whole, this patch trades a real bug - memory overwrite - for
a slightly different order of operations and slightly different
failure point when there is no memory
> --
> pw-bot: cr
I would still like to apply as-is, it would be better to spent
"refactor time" on different things in this driver.
next prev parent reply other threads:[~2026-08-19 10:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 20:18 [PATCH net 0/2][pull request] Intel Wired LAN Driver Updates 2026-08-12 (ice) Przemek Kitszel
2026-08-12 20:18 ` [PATCH net 1/2] ice: move ice_vsi_realloc_stat_arrays() up Przemek Kitszel
2026-08-12 20:18 ` [PATCH net v2 2/2] ice: fix stats array overflow via proper realloc Przemek Kitszel
2026-08-17 20:50 ` [Intel-wired-lan] " Jakub Kicinski
2026-08-19 10:52 ` Przemek Kitszel [this message]
2026-08-17 15:55 ` [PATCH net 0/2][pull request] Intel Wired LAN Driver Updates 2026-08-12 (ice) Tony Nguyen
2026-08-17 20:51 ` Jakub Kicinski
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=53c50cd8-edfa-4fe3-aec7-a6d66194e635@intel.com \
--to=przemyslaw.kitszel@intel.com \
--cc=aleksandr.loktionov@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=kuba@kernel.org \
--cc=marcin.szycik@linux.intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rafal.romanowski@intel.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