All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: kwankhede@nvidia.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] vfio/mdev: Check globally for duplicate devices
Date: Wed, 16 May 2018 16:38:17 +0200	[thread overview]
Message-ID: <20180516163817.41175428.cohuck@redhat.com> (raw)
In-Reply-To: <20180516082320.43d4ac06@w520.home>

On Wed, 16 May 2018 08:23:20 -0600
Alex Williamson <alex.williamson@redhat.com> wrote:

> On Wed, 16 May 2018 11:05:06 +0200
> Cornelia Huck <cohuck@redhat.com> wrote:
> 
> > On Tue, 15 May 2018 14:17:04 -0600
> > Alex Williamson <alex.williamson@redhat.com> wrote:
> >   
> > > When we create an mdev device, we check for duplicates against the
> > > parent device and return -EEXIST if found, but the mdev device
> > > namespace is global since we'll link all devices from the bus.  We do
> > > catch this later in sysfs_do_create_link_sd() to return -EEXIST, but
> > > with it comes a kernel warning and stack trace for trying to create
> > > duplicate sysfs links, which makes it an undesirable response.
> > > 
> > > Therefore we should really be looking for duplicates across all mdev
> > > parent devices, or as implemented here, against our mdev device list.
> > > 
> > > Notably, mdev_parent.lock really only seems to be serializing device
> > > creation and removal per parent.  I'm not sure if this is necessary,
> > > mdev vendor drivers could easily provide this serialization if it
> > > is required, but a side-effect of holding the mdev_list_lock to
> > > protect the namespace is actually greater serialization across the
> > > create and remove paths, so mdev_parent.lock is removed.  If we can
> > > show that vendor drivers handle the create/remove paths themselves,
> > > perhaps we can refine the locking granularity.    
> > 
> > I'm not sure whether more locking granularity on the create/remove
> > paths is really worth the effort.  
> 
> Perhaps not, but I thought I should at least mention it as a
> consideration.
> 
> > > Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> > > ---
> > >  drivers/vfio/mdev/mdev_core.c    |   79 ++++++++++----------------------------
> > >  drivers/vfio/mdev/mdev_private.h |    1 
> > >  2 files changed, 20 insertions(+), 60 deletions(-)    
> > 
> > In general, I think this patch makes sense; some nits below.
> >   
> > > 
> > > diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
> > > index 126991046eb7..3d8898a2baaf 100644
> > > --- a/drivers/vfio/mdev/mdev_core.c
> > > +++ b/drivers/vfio/mdev/mdev_core.c    
> >   
> > > @@ -376,12 +346,13 @@ int mdev_device_remove(struct device *dev, bool force_remove)
> > >  	struct mdev_device *mdev, *tmp;
> > >  	struct mdev_parent *parent;
> > >  	struct mdev_type *type;
> > > -	int ret;
> > > +	int ret = 0;    
> > 
> > I don't think you need to init this, as ret should either be set to
> > -ENODEV or the return code of mdev_device_remove_ops(), shouldn't it?  
> 
> Yep, I think this is a leftover from before I decided I should goto a
> common out, it's unnecessary now.  Removed.

OK, with that change

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

      reply	other threads:[~2018-05-16 14:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-15 20:17 [PATCH] vfio/mdev: Check globally for duplicate devices Alex Williamson
2018-05-16  9:05 ` Cornelia Huck
2018-05-16 14:23   ` Alex Williamson
2018-05-16 14:38     ` Cornelia Huck [this message]

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=20180516163817.41175428.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    /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.