RE: [PATCH net v1] idpf: Fix vport IRQ name leak on request failure

[Romanowski, Rafal]

> -----Original Message-----
> From: Simon Horman <horms@xxxxxxxxxx>
> Sent: Tuesday, October 6, 2026 5:11 PM
> To: Yuho Choi <oss.patchbox@xxxxxxxxx>
> Cc: Nguyen, Anthony L <anthony.l.nguyen@xxxxxxxxx>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@xxxxxxxxx>; Lobakin, Aleksander
> <aleksander.lobakin@xxxxxxxxx>; intel-wired-lan@xxxxxxxxxxxxxxxx;
> netdev@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH net v1] idpf: Fix vport IRQ name leak on request failure
> 
> On Wed, Sep 30, 2026 at 12:06:48PM -0400, Yuho Choi wrote:
> > I appreciate your time to review this.
> >
> > On Mon, 28 Sept 2026 at 05:15, Simon Horman <horms@xxxxxxxxxx> wrote:
> > >
> > > > Fixes: bf9bf7042a38 ("idpf: avoid bloating &idpf_q_vector with big
> > > > %NR_CPUS")
> > >
> > > I don't believe that commit introduced this problem.
> >
> > Thanks for catching this. I'll fix this tag.
> >
> > > name is allocated by kasprintf() which is a wrapper around kvasprintf_const().
> > > And kvasprintf_const() documents that it's return value should be
> > > freed using kfree_const(). I don't think it will make any run-time
> > > difference here, but perhaps it would be best to follow that convention.
> >
> > kasprintf() uses kvasprintf(), not kvasprintf_const(), so the name is
> > always kmalloc'ed and kfree() matches the kfree(free_irq()) used on
> > the normal path. Please correct me if I'm wrong.
> 
> Yes, of course you are right.
> No idea how I managed to muddle that one up.
> Sorry for the noise.
> 
> >
> > > Also, for completeness, shouldn't there be error handling for the
> > > case where the allocation of name fails?
> > >
> >
> > Agreed, I'll add it in v2


Tested-by: Rafal Romanowski <rafal.romanowski@xxxxxxxxx>