All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Yongji Xie <xieyongji@bytedance.com>
Cc: virtualization <virtualization@lists.linux-foundation.org>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH 1/2] vduse: Remove empty vduse_mgmtdev_release()
Date: Thu, 12 May 2022 08:19:39 +0200	[thread overview]
Message-ID: <Ynym+9BgJOyJdEkn@kroah.com> (raw)
In-Reply-To: <CACycT3tibej7Hw3LtNRyDiNLLm7W5PzssENbuSGXsvK8-Cg43Q@mail.gmail.com>

On Thu, May 12, 2022 at 01:59:00PM +0800, Yongji Xie wrote:
> On Thu, May 12, 2022 at 1:23 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Thu, May 12, 2022 at 01:19:58PM +0800, Yongji Xie wrote:
> > > On Wed, May 11, 2022 at 10:02 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Wed, May 11, 2022 at 09:55:22PM +0800, Xie Yongji wrote:
> > > > > It's not recommended to provide an "empty" release function
> > > > > for the device object as Documentation/core-api/kobject.rst
> > > > > mentioned.
> > > >
> > > > "it is a bug to have an empty release function" is more like it :)
> > > >
> > >
> > > OK.
> > >
> > > > > So let's allocate the device object dynamically
> > > > > to get rid of it.
> > > >
> > > > Much better, but not quite there, see below for details.
> > > >
> > > > >
> > > > > Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
> > > > > ---
> > > > >  drivers/vdpa/vdpa_user/vduse_dev.c | 43 +++++++++++++++++-------------
> > > > >  1 file changed, 25 insertions(+), 18 deletions(-)
> > > > >
> > > > > diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c
> > > > > index 160e40d03084..a8a5ebaefa10 100644
> > > > > --- a/drivers/vdpa/vdpa_user/vduse_dev.c
> > > > > +++ b/drivers/vdpa/vdpa_user/vduse_dev.c
> > > > > @@ -1475,15 +1475,6 @@ static char *vduse_devnode(struct device *dev, umode_t *mode)
> > > > >       return kasprintf(GFP_KERNEL, "vduse/%s", dev_name(dev));
> > > > >  }
> > > > >
> > > > > -static void vduse_mgmtdev_release(struct device *dev)
> > > > > -{
> > > > > -}
> > > > > -
> > > > > -static struct device vduse_mgmtdev = {
> > > > > -     .init_name = "vduse",
> > > > > -     .release = vduse_mgmtdev_release,
> > > > > -};
> > > > > -
> > > > >  static struct vdpa_mgmt_dev mgmt_dev;
> > > >
> > > > Close.  This should be a pointer and the device structure within it
> > > > should control the lifecycle of that structure.  It should not be a
> > > > single static structure like this, that's very odd.
> > > >
> > >
> > > OK, I can define mgmt_dev as a pointer. But the device is defined as a
> > > parent device for structure vdpa_mgmt_dev. So I think we can't use it
> > > to control the lifecycle of the structure vdpa_mgmt_dev.
> >
> > You should be able to control the lifecycle of it, especially if it is
> > the parent device of something.  To not do that correctly is to have
> > everything messed up as you should be using the driver model properly.
> > As it is, you are not :(
> >
> 
> I can control the lifecycle of it. What I mean is that I can not free
> it in the release function of the device object since it is the parent
> device of mgmt_dev. E.g., in other cases (such as ifcvf_probe()), the
> device object comes from a pci device but the structure vdpa_mgmt_dev
> is created during driver probing. The structure vdpa_mgmt_dev just
> maintains a pointer to the device object. So the structure
> vdpa_mgmt_dev and the device object have different lifecycles.

Then something is very very wrong here.  The structure's lifespace
should only be controlled by one reference count, not multiple ones.
Have it be controlled by the device you create and properly register as
a child of the pci device and all should be fine.

thanks,

greg k-h
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  parent reply	other threads:[~2022-05-12  6:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20220511135523.147-1-xieyongji@bytedance.com>
2022-05-11 14:02 ` [PATCH 1/2] vduse: Remove empty vduse_mgmtdev_release() Greg KH
     [not found]   ` <CACycT3s_-E=whAX02C0KKnr-1qx2yWdvTrRnQN=Km1L98VFThg@mail.gmail.com>
2022-05-12  5:23     ` Greg KH
     [not found]       ` <CACycT3tibej7Hw3LtNRyDiNLLm7W5PzssENbuSGXsvK8-Cg43Q@mail.gmail.com>
2022-05-12  6:19         ` Greg KH [this message]
     [not found]           ` <CACycT3uHn0BnQO8kHY6P+EnLu1-YAVqC3koWP8AKzvcXH4hHYw@mail.gmail.com>
2022-05-12  8:52             ` Jason Wang
2022-05-12  8:58             ` Greg KH
     [not found]               ` <CACycT3uf61r0Wduw=SSMGvbMRA7XWf208Ow0Thc4N6M6nCd0nA@mail.gmail.com>
2022-05-12  9:40                 ` Greg KH
2022-05-13  3:53                   ` Jason Wang
     [not found]                     ` <CACycT3tF=zc1P+PBUFoZZqob6P9Hmydexfqj0pWW0_a+dk5Dag@mail.gmail.com>
2022-05-13  6:18                       ` Jason Wang

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=Ynym+9BgJOyJdEkn@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=mst@redhat.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=xieyongji@bytedance.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.