From: Mahesh Bandewar
Date: Thu, 1 Sep 2016 22:18:34 -0700
> From: Mahesh Bandewar
>
> Following few steps will crash kernel -
>
> (a) Create bonding master
> > modprobe bonding miimon=50
> (b) Create macvlan bridge on eth2
> > ip link add link eth2 dev mvl0 address aa:0:0:0:0
Fri, Sep 02, 2016 at 07:08:54PM CEST, mahe...@google.com wrote:
>On Fri, Sep 2, 2016 at 9:37 AM, Eric Dumazet wrote:
>> On Fri, 2016-09-02 at 18:25 +0200, Jiri Pirko wrote:
>>
>>> Understand the reason. All I say is we tried hard (I surely did) in
>>> the past to remove bonding specific quirks and
On Fri, Sep 2, 2016 at 9:37 AM, Eric Dumazet wrote:
> On Fri, 2016-09-02 at 18:25 +0200, Jiri Pirko wrote:
>
>> Understand the reason. All I say is we tried hard (I surely did) in
>> the past to remove bonding specific quirks and now we are adding one.
>> And the simple reason is that the code is
On Fri, 2016-09-02 at 18:25 +0200, Jiri Pirko wrote:
> Understand the reason. All I say is we tried hard (I surely did) in
> the past to remove bonding specific quirks and now we are adding one.
> And the simple reason is that the code is such a mess.
>
> Just use team instead and you'll be fine.
Fri, Sep 02, 2016 at 03:33:20PM CEST, eric.duma...@gmail.com wrote:
>On Fri, 2016-09-02 at 09:52 +0200, Jiri Pirko wrote:
>
>>
>> No, please, don't make bonding a spacial citizen introducing this.
>> Please handle the issue inside the bonding code, like we do for the rest
>> of master devices (and
On Fri, 2016-09-02 at 08:21 -0700, Eric Dumazet wrote:
> Ideally the netdev_rx_handler_register() should be called only when no
> further errors can be detected in the 'enslaving' process, otherwise
> some live packets could come and be incorrectly processed/dropped by a
> not fully initialized dr
On Fri, 2016-09-02 at 08:57 -0600, David Ahern wrote:
> I hit this same problem yesterday but with the bridge. I forgot I had
> a macvlan device on an interface and tried to enslave it to a bridge.
> It failed with EBUSY without crashing the kernel so it is one example
> that handles the conflict,
On 9/2/16 8:45 AM, Eric Dumazet wrote:
> On Fri, 2016-09-02 at 08:30 -0600, David Ahern wrote:
>
>> This check duplicates what netdev_rx_handler_register does. Why not
>> move the call to netdev_rx_handler_register here and then call
>> unregister on failure paths?
>
> As soon as you call netdev_
On Fri, 2016-09-02 at 08:30 -0600, David Ahern wrote:
> This check duplicates what netdev_rx_handler_register does. Why not
> move the call to netdev_rx_handler_register here and then call
> unregister on failure paths?
As soon as you call netdev_rx_handler_register(), incoming packets will
hit y
On 9/1/16 11:18 PM, Mahesh Bandewar wrote:
> From: Mahesh Bandewar
>
> Following few steps will crash kernel -
>
> (a) Create bonding master
> > modprobe bonding miimon=50
> (b) Create macvlan bridge on eth2
> > ip link add link eth2 dev mvl0 address aa:0:0:0:0:01 \
> ty
On Fri, 2016-09-02 at 09:52 +0200, Jiri Pirko wrote:
>
> No, please, don't make bonding a spacial citizen introducing this.
> Please handle the issue inside the bonding code, like we do for the rest
> of master devices (and how it was once done for bonding). Thanks.
I do not feel this netdev_is_
Fri, Sep 02, 2016 at 07:18:34AM CEST, mah...@bandewar.net wrote:
>From: Mahesh Bandewar
>
>Following few steps will crash kernel -
>
> (a) Create bonding master
> > modprobe bonding miimon=50
> (b) Create macvlan bridge on eth2
> > ip link add link eth2 dev mvl0 address aa:0:0:0:0:01 \
From: Mahesh Bandewar
Following few steps will crash kernel -
(a) Create bonding master
> modprobe bonding miimon=50
(b) Create macvlan bridge on eth2
> ip link add link eth2 dev mvl0 address aa:0:0:0:0:01 \
type macvlan
(c) Now try adding eth2 into the bond
>
13 matches
Mail list logo
