[...]
>> > -destroy_port:
>> > - port->count -= 1;
>> > - if (!port->count)
>> > - macvlan_port_destroy(lowerdev);
>> I think you still need this when it fails netdev_upper_dev_link(). The
>> only thing you should remove is the label.
>
> I don't think so. I think the doub
From: Francesco Ruggeri
Date: Sat, 23 Apr 2016 15:03:32 -0700
> If macvlan_common_newlink fails in register_netdevice after macvlan_init
> then it decrements port->count twice, first in macvlan_uninit (from
> register_netdevice or rollback_registered) and then again in
> macvlan_common_newlink.
>
On Tue, Apr 26, 2016 at 11:54 AM, Mahesh Bandewar wrote:
>
> On Sat, Apr 23, 2016 at 3:03 PM, Francesco Ruggeri
> wrote:
> > If macvlan_common_newlink fails in register_netdevice after macvlan_init
> > then it decrements port->count twice, first in macvlan_uninit (from
> > register_netdevice or
On Sat, Apr 23, 2016 at 3:03 PM, Francesco Ruggeri wrote:
> If macvlan_common_newlink fails in register_netdevice after macvlan_init
> then it decrements port->count twice, first in macvlan_uninit (from
> register_netdevice or rollback_registered) and then again in
> macvlan_common_newlink.
> A si
Francesco Ruggeri writes:
> If macvlan_common_newlink fails in register_netdevice after macvlan_init
> then it decrements port->count twice, first in macvlan_uninit (from
> register_netdevice or rollback_registered) and then again in
> macvlan_common_newlink.
> A similar problem may exist in the
If macvlan_common_newlink fails in register_netdevice after macvlan_init
then it decrements port->count twice, first in macvlan_uninit (from
register_netdevice or rollback_registered) and then again in
macvlan_common_newlink.
A similar problem may exist in the ipvlan driver.
This patch consolidates
Francesco Ruggeri writes:
> On Thu, Apr 21, 2016 at 10:44 AM, Eric W. Biederman
> wrote:
> <
>>> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
>>> index 95394ed..e770221 100644
>>> --- a/drivers/net/macvtap.c
>>> +++ b/drivers/net/macvtap.c
>>> @@ -1303,6 +1303,8 @@ static int macvt
On Thu, Apr 21, 2016 at 10:44 AM, Eric W. Biederman
wrote:
<
>> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
>> index 95394ed..e770221 100644
>> --- a/drivers/net/macvtap.c
>> +++ b/drivers/net/macvtap.c
>> @@ -1303,6 +1303,8 @@ static int macvtap_device_event(struct notifier_block
Francesco Ruggeri writes:
> If macvlan_common_newlink fails in register_netdevice after macvlan_init
> then it decrements port->count twice, first in macvlan_uninit (from
> register_netdevice or rollback_registered) and then again in
> macvlan_common_newlink.
> A similar problem may exist in the
If macvlan_common_newlink fails in register_netdevice after macvlan_init
then it decrements port->count twice, first in macvlan_uninit (from
register_netdevice or rollback_registered) and then again in
macvlan_common_newlink.
A similar problem may exist in the ipvlan driver.
This patch consolidates
On Mon, Apr 18, 2016 at 2:33 PM, Eric W. Biederman
wrote:
>
> But please see if you can get macvlan_init to do the necessary work.
> That should simplify everything, and make clever games unnecessary.
Using macvlan_init seems to work. I will test it a couple of days and
then resubmit.
Thanks,
Fr
Francesco Ruggeri writes:
> On Mon, Apr 18, 2016 at 11:48 AM, Eric W. Biederman
> wrote:
>>
>> These interactions all seem a little bit funny. At a quick skim it
>> would make more sense to increment the port count in macvlan_init,
>> and completely remove the need to mess with port counts anyw
On Mon, Apr 18, 2016 at 11:48 AM, Eric W. Biederman
wrote:
>
> These interactions all seem a little bit funny. At a quick skim it
> would make more sense to increment the port count in macvlan_init,
> and completely remove the need to mess with port counts anywhere except
> macvlan_init and macvl
Francesco Ruggeri writes:
> Resending, did not include netdev the first time ...
>
> If a macvlan/macvtap creation fails in register_netdevice in
> call_netdevice_notifiers(NETDEV_REGISTER) then while cleaning things up in
> rollback_registered_many it invokes macvlan_uninit. This results in
> p
Resending, did not include netdev the first time ...
If a macvlan/macvtap creation fails in register_netdevice in
call_netdevice_notifiers(NETDEV_REGISTER) then while cleaning things up in
rollback_registered_many it invokes macvlan_uninit. This results in
port->count being decremented twice (in m
15 matches
Mail list logo
