On Sun, Apr 07, 2019 at 08:43:24AM -0700, Stephen Hemminger wrote:
> On Thu, 4 Apr 2019 20:45:18 +0800
> Hangbin Liu wrote:
>
> > Similarly to dad9b335c694 ("netdevice: Fix promiscuity and allmulti
> > overflow"), we should not decrease promiscuity if it is already 0.
>
> This should never happ
Hi David,
On Sat, Apr 06, 2019 at 06:14:28PM -0700, David Miller wrote:
> From: Hangbin Liu
> Date: Thu, 4 Apr 2019 20:45:18 +0800
>
> > Similarly to dad9b335c694 ("netdevice: Fix promiscuity and allmulti
> > overflow"), we should not decrease promiscuity if it is already 0.
> >
> > An example
On Thu, 4 Apr 2019 20:45:18 +0800
Hangbin Liu wrote:
> Similarly to dad9b335c694 ("netdevice: Fix promiscuity and allmulti
> overflow"), we should not decrease promiscuity if it is already 0.
This should never happen. If it is a kernel bug and should be reported
like refcnt_t overflow.
From: Hangbin Liu
Date: Thu, 4 Apr 2019 20:45:18 +0800
> Similarly to dad9b335c694 ("netdevice: Fix promiscuity and allmulti
> overflow"), we should not decrease promiscuity if it is already 0.
>
> An example is after adding a team interface to bridge, the team interface
> will enter promisc mo
Similarly to dad9b335c694 ("netdevice: Fix promiscuity and allmulti
overflow"), we should not decrease promiscuity if it is already 0.
An example is after adding a team interface to bridge, the team interface
will enter promisc mode. Then if we add a slave to team0, the slave will
keep promisc off
