Re: [PATCH] inet: delay address promotion check until last request in message

On Mon, Nov 09, 2015 at 07:31:38AM +0900, David Miller wrote: > From: Neil Horman > Date: Sun, 8 Nov 2015 16:56:41 -0500 > > > All I'm doing is, in effect masking the promote_secondaries sysctl > > for an interface doing a flush operation. > > Packets and other entities

Re: [PATCH] inet: delay address promotion check until last request in message

Hello, On Sun, 8 Nov 2015, Neil Horman wrote: > On Sat, Nov 07, 2015 at 01:49:25AM +0200, Julian Anastasov wrote: > > > > flush can provide many parameters. As there is no > > any kind of indication in the netlink message that all addresses > > are removed, we can not avoid the

Re: [PATCH] inet: delay address promotion check until last request in message

On Mon, Nov 09, 2015 at 10:35:42PM +0200, Julian Anastasov wrote: > > Hello, > > On Sun, 8 Nov 2015, Neil Horman wrote: > > > On Sat, Nov 07, 2015 at 01:49:25AM +0200, Julian Anastasov wrote: > > > > > > flush can provide many parameters. As there is no > > > any kind of indication in

Re: [PATCH] inet: delay address promotion check until last request in message

On Sat, Nov 07, 2015 at 01:49:25AM +0200, Julian Anastasov wrote: > > Hello, > > On Fri, 6 Nov 2015, Neil Horman wrote: > > > The solution is to recognize that its pointless to promote an address to be > > a > > new primary, if there is a possibility that it will just be removed in the

Re: [PATCH] inet: delay address promotion check until last request in message

From: Neil Horman Date: Sun, 8 Nov 2015 16:56:41 -0500 > All I'm doing is, in effect masking the promote_secondaries sysctl > for an interface doing a flush operation. Packets and other entities not controlled by RTNL can see an inconsistent state: no primary address on

Re: [PATCH] inet: delay address promotion check until last request in message

From: Julian Anastasov Date: Sat, 7 Nov 2015 01:49:25 +0200 (EET) > On Fri, 6 Nov 2015, Neil Horman wrote: > >> The solution is to recognize that its pointless to promote an address to be a >> new primary, if there is a possibility that it will just be removed in the >> near >>

Re: [PATCH] inet: delay address promotion check until last request in message

Hello, On Fri, 6 Nov 2015, Neil Horman wrote: > The solution is to recognize that its pointless to promote an address to be a > new primary, if there is a possibility that it will just be removed in the > near > future. As such this patch peeks ahead to the next request in the

[PATCH] inet: delay address promotion check until last request in message

I recently got a report that, after a user added 40,000 addresses to an interface and ran ip addr flush , their system blocked on interface access for literally hours, and issued hundreds of hung task warnings. due to rtnl being held during this operation. While its certainly arguable that long