From: Paolo Abeni
Date: Mon, 30 Nov 2015 12:31:43 +0100
> After 614732eaa12d, no refcount is maintained for the vport-vxlan module.
> This allows the userspace to remove such module while vport-vxlan
> devices still exist, which leads to later oops.
>
> v1 -> v2:
> - move vport 'owner' initiali
From: Hannes Frederic Sowa
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 mak
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 not
On Tue, 2015-12-01 at 13:03 +0100, Hannes Frederic Sowa wrote:
> Hello Paolo,
>
> On Mon, Nov 30, 2015, at 12:31, Paolo Abeni wrote:
> > After 614732eaa12d, no refcount is maintained for the vport-vxlan module.
> > This allows the userspace to remove such module while vport-vxlan
> > devices still
Hello Paolo,
On Mon, Nov 30, 2015, at 12:31, Paolo Abeni wrote:
> After 614732eaa12d, no refcount is maintained for the vport-vxlan module.
> This allows the userspace to remove such module while vport-vxlan
> devices still exist, which leads to later oops.
>
> v1 -> v2:
> - move vport 'owner' i
After 614732eaa12d, no refcount is maintained for the vport-vxlan module.
This allows the userspace to remove such module while vport-vxlan
devices still exist, which leads to later oops.
v1 -> v2:
- move vport 'owner' initialization in ovs_vport_ops_register()
and make such function a macro
