> -----Original Message----- > From: Simon Horman <[email protected]> > Sent: Tuesday, October 6, 2026 5:11 PM > To: Yuho Choi <[email protected]> > Cc: Nguyen, Anthony L <[email protected]>; Kitszel, Przemyslaw > <[email protected]>; Lobakin, Aleksander > <[email protected]>; [email protected]; > [email protected]; [email protected] > 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 <[email protected]> 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 <[email protected]>
