netdev - Re: [net PATCH 3/9] octeontx2-af: Do not allocate memory for devlink private

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210316132709.6b55bcf4@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Tue, 16 Mar 2021 13:27:09 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     sundeep subbaraya <sundeep.lkml@...il.com>
Cc:     Hariprasad Kelam <hkelam@...vell.com>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, David Miller <davem@...emloft.net>,
        Sunil Kovvuri Goutham <sgoutham@...vell.com>,
        lcherian@...vell.com, Geetha sowjanya <gakula@...vell.com>,
        jerinj@...vell.com, Subbaraya Sundeep <sbhatta@...vell.com>
Subject: Re: [net PATCH 3/9] octeontx2-af: Do not allocate memory for
 devlink private

On Tue, 16 Mar 2021 23:33:40 +0530 sundeep subbaraya wrote:
> On Tue, Mar 16, 2021 at 10:53 PM Jakub Kicinski <kuba@...nel.org> wrote:
> >
> > On Tue, 16 Mar 2021 14:57:07 +0530 Hariprasad Kelam wrote:  
> > > From: Subbaraya Sundeep <sbhatta@...vell.com>
> > >
> > > Memory for driver private structure rvu_devlink is
> > > also allocated during devlink_alloc. Hence use
> > > the allocated memory by devlink_alloc and access it
> > > by devlink_priv call.
> > >
> > > Fixes: fae06da4("octeontx2-af: Add devlink suppoort to af driver")
> > > Signed-off-by: Subbaraya Sundeep <sbhatta@...vell.com>
> > > Signed-off-by: Hariprasad Kelam <hkelam@...vell.com>
> > > Signed-off-by: Sunil Kovvuri Goutham <sgoutham@...vell.com>  
> >
> > Does it fix any bug? Looks like a coding improvement.  
> 
> Without this we cannot fetch our private struct 'rvu_devlink'  from any
> of the functions in devlink_ops which may get added in future.

"which may get added in future" does not sound like it's fixing 
an existing problem to me :(

If you have particular case where the existing setup is problematic
please describe it in more detail, or mention what other fix depends 
on this patch. Otherwise sending this one patch for net-next would 
be better IMHO.