netdev - Re: [PATCH net v2] openvswitch: properly refcount vport-vxlan module

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]

Date:	Tue, 01 Dec 2015 14:26:28 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	hannes@...essinduktion.org
Cc:	pabeni@...hat.com, netdev@...r.kernel.org, pshelar@...ira.com,
	tgraf@...g.ch
Subject: Re: [PATCH net v2] openvswitch: properly refcount vport-vxlan
 module

From: Hannes Frederic Sowa <hannes@...essinduktion.org>
Date: Tue, 01 Dec 2015 16:41:48 +0100

> On Tue, Dec 1, 2015, at 14:19, Paolo Abeni wrote:
>> Currently all the vport_ops list manipulation functions are protected by
>> the ovs_lock (even the lookup): the scenario described above should not
>> be possible.
> 
> This makes all sense and it seems no use-after-free is possible at all
> (I didn't notice the lookup path takes the lock). But the macro still
> looks ugly and modifies a global struct with a per-module linked symbol.
> David, why exactly didn't you like the first patch? Seems to me it does
> what is actually needed.

Because it is error prone.

I want it hidden quietly and reliably in a macro, just like we do for
other similar cases across the tree.

The caller of the registry functions has no reason to be concerned
with these details if we can take care of it transparently.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html