netdev - Re: [RFC PATCH v4 01/25] virtual-bus: Implementation of Virtual Bus

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: <20200215000154.GZ31668@ziepe.ca>
Date:   Fri, 14 Feb 2020 20:01:54 -0400
From:   Jason Gunthorpe <jgg@...pe.ca>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Jeff Kirsher <jeffrey.t.kirsher@...el.com>, davem@...emloft.net,
        Dave Ertman <david.m.ertman@...el.com>, netdev@...r.kernel.org,
        linux-rdma@...r.kernel.org, nhorman@...hat.com,
        sassmann@...hat.com, parav@...lanox.com, galpress@...zon.com,
        selvin.xavier@...adcom.com, sriharsha.basavapatna@...adcom.com,
        benve@...co.com, bharat@...lsio.com, xavier.huwei@...wei.com,
        yishaih@...lanox.com, leonro@...lanox.com, mkalderon@...vell.com,
        aditr@...are.com, Kiran Patil <kiran.patil@...el.com>,
        Andrew Bowers <andrewx.bowers@...el.com>
Subject: Re: [RFC PATCH v4 01/25] virtual-bus: Implementation of Virtual Bus

On Fri, Feb 14, 2020 at 03:43:41PM -0500, Greg KH wrote:
> On Fri, Feb 14, 2020 at 04:34:55PM -0400, Jason Gunthorpe wrote:
> > On Fri, Feb 14, 2020 at 09:02:40AM -0800, Greg KH wrote:
> > > > +/**
> > > > + * virtbus_dev_register - add a virtual bus device
> > > > + * @vdev: virtual bus device to add
> > > > + */
> > > > +int virtbus_dev_register(struct virtbus_device *vdev)
> > > > +{
> > > > +	int ret;
> > > > +
> > > > +	if (!vdev->release) {
> > > > +		dev_err(&vdev->dev, "virtbus_device .release callback NULL\n");
> > > 
> > > "virtbus_device MUST have a .release callback that does something!\n" 
> > > 
> > > > +		return -EINVAL;
> > > > +	}
> > > > +
> > > > +	device_initialize(&vdev->dev);
> > > > +
> > > > +	vdev->dev.bus = &virtual_bus_type;
> > > > +	vdev->dev.release = virtbus_dev_release;
> > > > +	/* All device IDs are automatically allocated */
> > > > +	ret = ida_simple_get(&virtbus_dev_ida, 0, 0, GFP_KERNEL);
> > > > +	if (ret < 0) {
> > > > +		dev_err(&vdev->dev, "get IDA idx for virtbus device failed!\n");
> > > > +		put_device(&vdev->dev);
> > > 
> > > If you allocate the number before device_initialize(), no need to call
> > > put_device().  Just a minor thing, no big deal.
> > 
> > If *_regster does put_device on error then it must always do
> > put_device on any error, for instance the above return -EINVAL with
> > no put_device leaks memory.
> 
> That's why I said to move the ida_simple_get() call to before
> device_initialize() is called.  Once device_initialize() is called, you
> HAVE to call put_device().

Yes put_device() becomes mandatory, but if the ida is moved up then
the caller doesn't know how to handle an error:

   if (ida_simple_get() < 0)
       return -EINVAL; // caller must do kfree
   device_initialize();
   if (device_register())
       return -EINVAL // caller must do put_device

If the device_initialize is bundled in the function the best answer is
to always do device_initialize() and never do put_device(). The caller
must realize the unwind switches from kfree to put_device (tricky and
uglyifies the goto unwind!).

This is the pattern something like platform_device_register() uses,
and with a random survey I found only __ipmi_bmc_register() getting it
right. Even then it seems to have a bug related to bmc_reg_mutex due
to the ugly split goto unwind..

I prefer to see device_initialize done shortly after allocation, that
seems to be the most likely to end up correct..

Jason