linux-kernel - RE: [PATCH 6/8] vfio/mdev: Follow correct remove sequence

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 for Android: free password hash cracker in your pocket

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

Message-ID: <VI1PR0501MB2271EC2E7F748DB29E7E2B4CD15E0@VI1PR0501MB2271.eurprd05.prod.outlook.com>
Date:   Mon, 25 Mar 2019 21:31:56 +0000
From:   Parav Pandit <parav@...lanox.com>
To:     Alex Williamson <alex.williamson@...hat.com>
CC:     "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kwankhede@...dia.com" <kwankhede@...dia.com>
Subject: RE: [PATCH 6/8] vfio/mdev: Follow correct remove sequence



> -----Original Message-----
> From: Alex Williamson <alex.williamson@...hat.com>
> Sent: Monday, March 25, 2019 3:21 PM
> To: Parav Pandit <parav@...lanox.com>
> Cc: kvm@...r.kernel.org; linux-kernel@...r.kernel.org;
> kwankhede@...dia.com
> Subject: Re: [PATCH 6/8] vfio/mdev: Follow correct remove sequence
> 
> On Fri, 22 Mar 2019 18:20:33 -0500
> Parav Pandit <parav@...lanox.com> wrote:
> 
> > mdev_remove_sysfs_files() should follow exact mirror sequence of a
> > create, similar to what is followed in error unwinding path of
> > mdev_create_sysfs_files().
> >
> > Fixes: 7b96953bc640 ("vfio: Mediated device Core driver")
> > Signed-off-by: Parav Pandit <parav@...lanox.com>
> > ---
> >  drivers/vfio/mdev/mdev_sysfs.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/vfio/mdev/mdev_sysfs.c
> > b/drivers/vfio/mdev/mdev_sysfs.c index ce5dd21..c782fa9 100644
> > --- a/drivers/vfio/mdev/mdev_sysfs.c
> > +++ b/drivers/vfio/mdev/mdev_sysfs.c
> > @@ -280,7 +280,7 @@ int  mdev_create_sysfs_files(struct device *dev,
> > struct mdev_type *type)
> >
> >  void mdev_remove_sysfs_files(struct device *dev, struct mdev_type
> > *type)  {
> > +	sysfs_remove_files(&dev->kobj, mdev_device_attrs);
> >  	sysfs_remove_link(&dev->kobj, "mdev_type");
> >  	sysfs_remove_link(type->devices_kobj, dev_name(dev));
> > -	sysfs_remove_files(&dev->kobj, mdev_device_attrs);
> >  }
> 
> Ok, I agree this is good practice, but what qualifies a "Fixes:" tag here?  The
> fixes reference is incorrect in any case, 6a62c1dfb5c7 changed the creation
> ordering and didn't update the remove ordering to match, but I still don't
> see an actual problem with the remove ordering that necessitates the tag.
> Please clarify.  Thanks,
> 
In netdev and rdma subsystem we always follow Fixes tag line whenever there is fix, small or big.
So following good practice is better.
I will fix the tag number in v1.

> Alex