public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Devesh Sharma <devesh.sharma@broadcom.com>
Cc: Leon Romanovsky <leon@kernel.org>,
	Doug Ledford <dledford@redhat.com>,
	linux-rdma <linux-rdma@vger.kernel.org>,
	Naresh Kumar PBS <nareshkumar.pbs@broadcom.com>,
	Selvin Xavier <selvin.xavier@broadcom.com>,
	Somnath Kotur <somnath.kotur@broadcom.com>,
	Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Subject: Re: [PATCH rdma-next] bnxt_re: Rely on Kconfig to keep module dependency
Date: Wed, 24 Mar 2021 14:35:56 -0300	[thread overview]
Message-ID: <20210324173556.GO2356281@nvidia.com> (raw)
In-Reply-To: <CANjDDBh_H1jqQxBJFgu-uO2AmWe4-3Qiuos93vxMPxHOx8md+w@mail.gmail.com>

On Wed, Mar 24, 2021 at 10:54:58PM +0530, Devesh Sharma wrote:
> On Wed, Mar 24, 2021 at 10:26 PM Jason Gunthorpe <jgg@nvidia.com> wrote:
> >
> > On Wed, Mar 24, 2021 at 10:00:05PM +0530, Devesh Sharma wrote:
> >
> > > > > > -static void bnxt_re_dev_unprobe(struct net_device *netdev,
> > > > > > -                           struct bnxt_en_dev *en_dev)
> > > > > > -{
> > > > > > -   dev_put(netdev);
> > > > > > -   module_put(en_dev->pdev->driver->driver.owner);
> > > > > > -}
> > > > >
> > > > > And you are right to be wondering WTF is this
> > >
> > > Still trying to understand but what's the big idea here may be I can help.
> >
> > A driver should not have module put things like the above
> >
> > It should not be accessing ->driver without holding the device_lock()
> >
> > Basically it is all nonsense coding, Leon suggests to delete it and he
> > is probably right.
> >
> > Can you explain what it thinks it is doing?
> That F'ed up  code is trying to prevent a situation where someone
> tries to remove the bnxt_en driver while bnxt_re driver is using it.
> All because bnxt_re driver is at the mercy of bnxt_en drive and there
> is not symbole dependence, Do you suggest anything to prevent that
> unload of bnxt_en other than doing this jargon.

Well, the module put says nothing about the validity of the 'struct
bnxt' and related it extracted from the netdev - you should have a
mechanism that prevents that from going invalid which in turn will
ensure the function pointers you want to touch are still valid
too. (as the struct containing function pointers must become invalid
before the module unloads)

Probably the netdev refcount does that already but I always forget the
exact point during unregister that it waits on that...

As far as strict module dependencies go, replace the pointless
brp->ulp_probe function pointer with an actual call to
bnxt_ulp_probe() and you get the same effect as the module_get.

Jason

  reply	other threads:[~2021-03-24 17:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-24 14:25 [PATCH rdma-next] bnxt_re: Rely on Kconfig to keep module dependency Leon Romanovsky
2021-03-24 15:07 ` Jason Gunthorpe
2021-03-24 15:16   ` Leon Romanovsky
2021-03-24 16:30     ` Devesh Sharma
2021-03-24 16:56       ` Jason Gunthorpe
2021-03-24 17:24         ` Devesh Sharma
2021-03-24 17:35           ` Jason Gunthorpe [this message]
2021-03-25  8:40             ` Leon Romanovsky
2021-03-26  6:09               ` Devesh Sharma

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=20210324173556.GO2356281@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=devesh.sharma@broadcom.com \
    --cc=dledford@redhat.com \
    --cc=leon@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=nareshkumar.pbs@broadcom.com \
    --cc=selvin.xavier@broadcom.com \
    --cc=somnath.kotur@broadcom.com \
    --cc=sriharsha.basavapatna@broadcom.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