linux-kernel - Re: [PATCH 5/8] staging: vme: add functions for bridge module refcounting

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]

Date:	Tue, 9 Aug 2011 15:19:15 -0400
From:	"Emilio G. Cota" <cota@...ap.org>
To:	Martyn Welch <martyn.welch@...com>
Cc:	"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
	Greg KH <gregkh@...e.de>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 5/8] staging: vme: add functions for bridge module
 refcounting

On Tue, Aug 09, 2011 at 10:00:09 +0100, Martyn Welch wrote:
> So, out of the 3 bus types you have used to demonstrate that refcounts should
> always be handled explicitly, 2 of the 3 (at least to me) appear to implicitly
> handling refcounting.
(snip)
> It appears to me that both PCI and RapidIO (both buses that you have tried to
> use to defend your position) don't seem to me to by-and-large expect drivers
> to explicitly manage refcounting.

Well if that's the impression you get, perhaps you need to
actually read the code:

In drivers/rapidio/rio-driver.c:

/**
 * rio_dev_get - Increments the reference count of the RIO device structure
 *
 * @rdev: RIO device being referenced
 *
 * Each live reference to a device should be refcounted.
 *
 * Drivers for RIO devices should normally record such references in
 * their probe() methods, when they bind to a device, and release
 * them by calling rio_dev_put(), in their disconnect() methods.
 */
struct rio_dev *rio_dev_get(struct rio_dev *rdev)
{
        if (rdev)
                get_device(&rdev->dev);

        return rdev;
}

You can find a similar function (with almost the very same description)
for usb and pci.

> That leaves USB, which I'd argue is a very different bus to VME.

>From the device model's viewpoint, VME is not special in any way,
something you don't seem to understand.

> > I'm tired of your non-arguments. I'm just trying to persuade you
> > to do what everyone else is doing, with technical reasons. To me
> > (and to everybody else in this list, I'd imagine) refcounting
> > should be explicit. You're going against what I perceive are
> > well-established pratices in the kernel. I can't understand it.
> 
> Which I have yet to see you convincingly backup. I see a
> large amount of bluff about oppses and how buses apparently
> deal with refcounting.  I also know I have had a number of
> commits to the VME code by a number of others (which is a
> matter of public record, you can look at the commits in git)
> that haven't complained about how the bus code is structured.

You're in denial. Manohar's patch fixes a very obvious bug,
which is fixed in the same way other buses deal with this.

> I also know I have had a number of commits to the VME code
> by a number of others (which is a matter of public record,
> you can look at the commits in git) that haven't complained
> about how the bus code is structured.

The fact that other people didn't notice this bug is irrelevant.

> You have proposed a completely different structure. Manohar has proposed some
> changes and I am trying to work with him to find a solution that satisfies
> both of us.

??? I just want you to ack Manohar's patch.

		Emilio

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/