linux-kernel - Re: [PATCH 3/5] 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:	Sat, 13 Aug 2011 04:54:54 -0400
From:	"Emilio G. Cota" <cota@...ap.org>
To:	Manohar Vanga <manohar.vanga@...n.ch>
Cc:	martyn.welch@...com, gregkh@...e.de, devel@...verdev.osuosl.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/5] staging: vme: add functions for bridge module
 refcounting

On Fri, Aug 12, 2011 at 12:30:49 +0200, Manohar Vanga wrote:
> This patch adds functions that allow for reference counting
> bridge modules. The patch introduces the functions
> 'vme_bridge_get()' and 'vme_bridge_put()'.
(snip)
> +int vme_bridge_get(unsigned int bus_id)
(snip)
> +void vme_bridge_put(struct vme_bridge *bridge)

Note the input parameter imbalance; in fact this is serious
(see my email on patch 5) because _get() needs to acquire
vme_buses_lock, whereas _put() doesn't. Since a caller with
bridge has bridge->num, but the opposite doesn't hold (num
doesn't give you the bridge without acquiring vme_buses_lock),
it seems reasonable to me to take the bus_id as the input for
both functions, because the requirements on the caller are lower.

But the locking needs to be handled with care, see my reply
to patch 5.

		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/