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:	Mon, 8 Aug 2011 05:14:32 -0400
From:	"Emilio G. Cota" <cota@...ap.org>
To:	Martyn Welch <martyn.welch@...com>
Cc:	gregkh@...e.de, devel@...verdev.osuosl.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/8] staging: vme: add functions for bridge module
 refcounting

On Mon, Aug 08, 2011 at 09:01:46 +0100, Martyn Welch wrote:
> On 05/08/11 18:47, Emilio G. Cota wrote:
> > A driver leaking a resource will then leave a bogus refcount
> > Refcounting must be kept simple & stupid; doing it behind the
> > backs of the drivers we're trying to protect is a mistake.
> 
> I just simply disagree. Forcing each driver to specifically maintain the
> refcount is just stupid when an alternative is possible.

Martyn, no one in the kernel is doing what you propose, for
good reason. Look at USB, PCI, RapidIO.  They all provide get
and put functions to be called from probe and release.

Doing otherwise is a bug. If a driver needs a resource *not
necessarily at .probe time*, it increments the refcount
then (in .probe) to make sure that the parent driver won't
be removed. IOW if you increase the refcount in the bridge
driver only when a resource is requested you're doomed,
because when the non-probe request arrives, the bridge driver
may have been removed already.. And the kernel gently reminds
you of this fact in the form of an oops.

There is a technical reason why we want drivers to explicitly
manage refcounts in the device hierarchy. It's the sane thing
to do.

		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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ