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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ