From: Stanislaw Gruszka <stf_xl@wp.pl>
To: Rosen Penev <rosenp@gmail.com>
Cc: linux-wireless@vger.kernel.org, Kees Cook <kees@kernel.org>,
"Gustavo A. R. Silva" <gustavoars@kernel.org>,
open list <linux-kernel@vger.kernel.org>,
"open list:KERNEL HARDENING (not covered by other
areas):Keyword:b__counted_by(_le|_be|_ptr)?b"
<linux-hardening@vger.kernel.org>
Subject: Re: [PATCH wireless-next] wifi: rt2x00: Use flexible array for hw_mode_spec channels
Date: Fri, 24 Jul 2026 08:29:02 +0200 [thread overview]
Message-ID: <20260724062902.GA2146@wp.pl> (raw)
In-Reply-To: <CAKxU2N_LbndYqrGDQ__sAjj87mj-J8Hs-RWeD90eRcGK1dDAcw@mail.gmail.com>
On Thu, Jul 23, 2026 at 12:26:41PM -0700, Rosen Penev wrote:
> On Thu, Jul 23, 2026 at 12:53 AM Stanislaw Gruszka <stf_xl@wp.pl> wrote:
> >
> > Hi,
> >
> > On Sun, Jun 28, 2026 at 08:31:56PM -0700, Rosen Penev wrote:
> > > struct hw_mode_spec stores channel information that is allocated by the
> > > individual rt2x00 drivers during hardware probing. The channel info
> > > array has the same lifetime as the hardware mode specification, but it
> > > is currently allocated separately and then freed through a separate
> > > pointer.
> > >
> > > Make struct rt2x00_dev hold a pointer to the hardware mode
> > > specification, store the channel info as a flexible array member, and
> > > allocate both pieces together with kzalloc_flex().
> > >
> > > Assisted-by: Codex:GPT-5.5
> > > Signed-off-by: Rosen Penev <rosenp@gmail.com>
> > > ---
> > > .../net/wireless/ralink/rt2x00/rt2400pci.c | 24 +++---
> > > .../net/wireless/ralink/rt2x00/rt2500pci.c | 55 ++++++++------
> > > .../net/wireless/ralink/rt2x00/rt2500usb.c | 55 ++++++++------
> > > .../net/wireless/ralink/rt2x00/rt2800lib.c | 74 ++++++++++---------
> > > drivers/net/wireless/ralink/rt2x00/rt2x00.h | 4 +-
> > > .../net/wireless/ralink/rt2x00/rt2x00config.c | 12 +--
> > > .../net/wireless/ralink/rt2x00/rt2x00dev.c | 4 +-
> > > drivers/net/wireless/ralink/rt2x00/rt61pci.c | 42 ++++++-----
> > > drivers/net/wireless/ralink/rt2x00/rt73usb.c | 50 +++++++------
> > > 9 files changed, 177 insertions(+), 143 deletions(-)
> >
> > This result in extra code. I do not see benefit of avoiding
> > kzalloc calls at cost of adding more lines of code.
> On runtime there's extra UBSAN analysis. Reducing allocations is always good.
No, not always.
Sanitizes are for catching bugs, not for performance.
Adding complexity to the driver to run faster with them
is not good idea.
Also, this is on initialization path, which done usually
once per system boot, so visible gains will be something
between zero an non-existing.
Regards
Stanislaw
prev parent reply other threads:[~2026-07-24 6:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-29 3:31 [PATCH wireless-next] wifi: rt2x00: Use flexible array for hw_mode_spec channels Rosen Penev
2026-07-23 7:53 ` Stanislaw Gruszka
2026-07-23 19:26 ` Rosen Penev
2026-07-24 6:29 ` Stanislaw Gruszka [this message]
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=20260724062902.GA2146@wp.pl \
--to=stf_xl@wp.pl \
--cc=gustavoars@kernel.org \
--cc=kees@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=rosenp@gmail.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