From: Cyrill Gorcunov
Date: Sat, 12 Mar 2016 00:59:12 +0300
> Here is a cumulative one, which works just brilliant! Thanks a lot, David!
> (I cahcnged reported-by tag, since it's Solar Designer who tell us
> about the issue, I forgot to mentioned it in first report, very
> sorry).
Thanks for f
On Sat, Mar 12, 2016 at 12:22:47AM +0300, Cyrill Gorcunov wrote:
> On Fri, Mar 11, 2016 at 03:40:46PM -0500, David Miller wrote:
> > > Thanks a lot, David!
> >
> > Cyrill please retest this final patch and let me know if it still works
> > properly.
> >
> > I looked at ipv6, and it's more complic
On Fri, Mar 11, 2016 at 03:40:46PM -0500, David Miller wrote:
> > Thanks a lot, David!
>
> Cyrill please retest this final patch and let me know if it still works
> properly.
>
> I looked at ipv6, and it's more complicated. The problem is that ipv6
> doesn't mark the inet6dev object as dead in t
On Fri, Mar 11, 2016 at 03:40:46PM -0500, David Miller wrote:
> >
> > Thanks a lot, David!
>
> Cyrill please retest this final patch and let me know if it still works
> properly.
...
Thanks David! Give me some time, gonna build and run test.
Cyrill
David Miller wrote:
> From: Cyrill Gorcunov
> Date: Fri, 11 Mar 2016 01:40:56 +0300
>
> > On Thu, Mar 10, 2016 at 05:36:30PM -0500, David Miller wrote:
> >> >
> >> > Works like a charm! So David, what are the next steps then?
> >> > Mind to gather all your patches into one (maybe)?
> >>
> >> I
From: Cyrill Gorcunov
Date: Fri, 11 Mar 2016 01:40:56 +0300
> On Thu, Mar 10, 2016 at 05:36:30PM -0500, David Miller wrote:
>> >
>> > Works like a charm! So David, what are the next steps then?
>> > Mind to gather all your patches into one (maybe)?
>>
>> I'll re-review all of the changes tomorr
On Thu, Mar 10, 2016 at 05:36:30PM -0500, David Miller wrote:
> >
> > Works like a charm! So David, what are the next steps then?
> > Mind to gather all your patches into one (maybe)?
>
> I'll re-review all of the changes tomorrow and also look into ipv6
> masq, to see if it needs the same treatm
From: Cyrill Gorcunov
Date: Fri, 11 Mar 2016 00:59:59 +0300
> On Fri, Mar 11, 2016 at 12:19:45AM +0300, Cyrill Gorcunov wrote:
>> >
>> > Oh yes they do, from masq's non-inet notifier. masq registers two
>> > notifiers, one for generic netdev and one for inetdev.
>>
>> Thanks a huge David! I'll
On Fri, Mar 11, 2016 at 12:19:45AM +0300, Cyrill Gorcunov wrote:
> >
> > Oh yes they do, from masq's non-inet notifier. masq registers two
> > notifiers, one for generic netdev and one for inetdev.
>
> Thanks a huge David! I'll test it just to be sure.
Works like a charm! So David, what are the
On Thu, Mar 10, 2016 at 04:05:21PM -0500, David Miller wrote:
> >
> > and nobody calls for nf_ct_iterate_cleanup, no?
>
> Oh yes they do, from masq's non-inet notifier. masq registers two
> notifiers, one for generic netdev and one for inetdev.
Thanks a huge David! I'll test it just to be sure.
On Thu, Mar 10, 2016 at 11:55 AM, David Miller wrote:
> Indeed, good catch. Therefore:
>
> 1) Keep the masq netdev notifier. That will flush the conntrack table
>for the inetdev_destroy event.
>
> 2) Make the inetdev notifier only do something if inetdev->dead is
>false. (ie. we are flu
From: Cyrill Gorcunov
Date: Thu, 10 Mar 2016 23:13:51 +0300
> On Thu, Mar 10, 2016 at 03:03:11PM -0500, David Miller wrote:
>> From: Cyrill Gorcunov
>> Date: Thu, 10 Mar 2016 23:01:34 +0300
>>
>> > On Thu, Mar 10, 2016 at 02:55:43PM -0500, David Miller wrote:
>> >> >
>> >> > Hmm, but inetdev_d
On Thu, Mar 10, 2016 at 11:13:51PM +0300, Cyrill Gorcunov wrote:
> >
> > Both notifiers are run in the inetdev_destroy() case.
> >
> > Maybe that's what you are missing.
>
> No :) Look, here is what I mean. Previously with your two patches
> we've been calling nf-cleanup for every address, so we
On Thu, Mar 10, 2016 at 03:03:11PM -0500, David Miller wrote:
> From: Cyrill Gorcunov
> Date: Thu, 10 Mar 2016 23:01:34 +0300
>
> > On Thu, Mar 10, 2016 at 02:55:43PM -0500, David Miller wrote:
> >> >
> >> > Hmm, but inetdev_destroy() is only called when NETDEV_UNREGISTER
> >> > is happening and
From: Cyrill Gorcunov
Date: Thu, 10 Mar 2016 23:01:34 +0300
> On Thu, Mar 10, 2016 at 02:55:43PM -0500, David Miller wrote:
>> >
>> > Hmm, but inetdev_destroy() is only called when NETDEV_UNREGISTER
>> > is happening and masq already registers a netdev notifier...
>>
>> Indeed, good catch. The
On Thu, Mar 10, 2016 at 02:55:43PM -0500, David Miller wrote:
> >
> > Hmm, but inetdev_destroy() is only called when NETDEV_UNREGISTER
> > is happening and masq already registers a netdev notifier...
>
> Indeed, good catch. Therefore:
>
> 1) Keep the masq netdev notifier. That will flush the c
From: Cong Wang
Date: Thu, 10 Mar 2016 11:02:28 -0800
> On Thu, Mar 10, 2016 at 10:01 AM, David Miller wrote:
>> I'm tempted to say that we should provide these notifier handlers with
>> the information they need, explicitly, to handle this case.
>>
>> Most intdev notifiers actually want to know
On Thu, Mar 10, 2016 at 10:01 AM, David Miller wrote:
> I'm tempted to say that we should provide these notifier handlers with
> the information they need, explicitly, to handle this case.
>
> Most intdev notifiers actually want to know the individual addresses
> that get removed, one by one. Tha
On Thu, Mar 10, 2016 at 01:01:38PM -0500, David Miller wrote:
> From: Cyrill Gorcunov
> Date: Thu, 10 Mar 2016 18:09:20 +0300
>
> > On Thu, Mar 10, 2016 at 02:03:24PM +0300, Cyrill Gorcunov wrote:
> >> On Thu, Mar 10, 2016 at 01:20:18PM +0300, Cyrill Gorcunov wrote:
> >> > On Thu, Mar 10, 2016 at
From: Cyrill Gorcunov
Date: Thu, 10 Mar 2016 18:09:20 +0300
> On Thu, Mar 10, 2016 at 02:03:24PM +0300, Cyrill Gorcunov wrote:
>> On Thu, Mar 10, 2016 at 01:20:18PM +0300, Cyrill Gorcunov wrote:
>> > On Thu, Mar 10, 2016 at 12:16:29AM +0300, Cyrill Gorcunov wrote:
>> > >
>> > > Thanks for explan
On Thu, Mar 10, 2016 at 02:03:24PM +0300, Cyrill Gorcunov wrote:
> On Thu, Mar 10, 2016 at 01:20:18PM +0300, Cyrill Gorcunov wrote:
> > On Thu, Mar 10, 2016 at 12:16:29AM +0300, Cyrill Gorcunov wrote:
> > >
> > > Thanks for explanation, Dave! I'll continue on this task tomorrow
> > > tryin to impl
On Thu, Mar 10, 2016 at 01:20:18PM +0300, Cyrill Gorcunov wrote:
> On Thu, Mar 10, 2016 at 12:16:29AM +0300, Cyrill Gorcunov wrote:
> >
> > Thanks for explanation, Dave! I'll continue on this task tomorrow
> > tryin to implement optimization you proposed.
>
> OK, here are the results for the prel
On Thu, Mar 10, 2016 at 12:16:29AM +0300, Cyrill Gorcunov wrote:
>
> Thanks for explanation, Dave! I'll continue on this task tomorrow
> tryin to implement optimization you proposed.
OK, here are the results for the preliminary patch with conntrack running
---
[root@s125 ~]# ./exploit.sh
START 4
On Wed, Mar 09, 2016 at 04:10:38PM -0500, David Miller wrote:
> >
> > and here we call for NETDEV_DOWN, which then hits masq_device_event
> > and go further to conntrack code.
>
> Yes that's where the notifier comes from, which happens with or without
> my patch.
Thanks for explanation, Dave! I'
From: Cyrill Gorcunov
Date: Wed, 9 Mar 2016 23:57:47 +0300
> Aha! So in your patch __inet_del_ifa bypass first blocking_notifier_call_chain
>
> __inet_del_ifa
> ...
> if (in_dev->dead)
> goto no_promotions;
>
> // First call to NETDEV_DOWN
> ...
> no_promotions:
On Wed, Mar 09, 2016 at 03:47:25PM -0500, David Miller wrote:
> From: Cyrill Gorcunov
> Date: Wed, 9 Mar 2016 23:41:58 +0300
>
> > On Wed, Mar 09, 2016 at 03:27:30PM -0500, David Miller wrote:
> >> >
> >> > Yes. I can drop it off for a while and run tests without it,
> >> > then turn it back and
From: Cyrill Gorcunov
Date: Wed, 9 Mar 2016 23:41:58 +0300
> On Wed, Mar 09, 2016 at 03:27:30PM -0500, David Miller wrote:
>> >
>> > Yes. I can drop it off for a while and run tests without it,
>> > then turn it back and try again. Would you like to see such
>> > numbers?
>>
>> That would be ve
On Wed, Mar 09, 2016 at 03:27:30PM -0500, David Miller wrote:
> >
> > Yes. I can drop it off for a while and run tests without it,
> > then turn it back and try again. Would you like to see such
> > numbers?
>
> That would be very helpful, yes.
Just sent out. Take a look please. Indeed it sits i
From: Cyrill Gorcunov
Date: Wed, 9 Mar 2016 20:53:07 +0300
> On Wed, Mar 09, 2016 at 12:24:00PM -0500, David Miller wrote:
> ...
>> We asked you for numbers without a lot of features enabled, it'll
>> help us diagnose which subsystem still causes a lot of overhead
>> much more clearly.
>>
>> So
On Wed, Mar 09, 2016 at 08:53:07PM +0300, Cyrill Gorcunov wrote:
> On Wed, Mar 09, 2016 at 12:24:00PM -0500, David Miller wrote:
> ...
> > We asked you for numbers without a lot of features enabled, it'll
> > help us diagnose which subsystem still causes a lot of overhead
> > much more clearly.
> >
On Wed, Mar 09, 2016 at 12:24:00PM -0500, David Miller wrote:
...
> We asked you for numbers without a lot of features enabled, it'll
> help us diagnose which subsystem still causes a lot of overhead
> much more clearly.
>
> So please do so.
Sure. Gimme some time and I'll back with numbers.
> Al
From: Cyrill Gorcunov
Date: Wed, 9 Mar 2016 20:09:21 +0300
> On Wed, Mar 09, 2016 at 08:58:52AM -0800, Alexei Starovoitov wrote:
> ...
>>
>> above line is an indication that you have:
>> #if defined(CONFIG_DEBUG_PREEMPT) || defined(CONFIG_PREEMPT_TRACER)
>> turning it off will speed up things si
From: Cyrill Gorcunov
Date: Wed, 9 Mar 2016 19:39:19 +0300
>9.21% [kernel][k] nf_ct_iterate_cleanup
...
> Release
> ---
> 24.26% [kernel][k] _raw_spin_lock
> 17.55% [kernel][k] preempt_count_add
> 14.81% [kernel]
On Wed, Mar 09, 2016 at 08:58:52AM -0800, Alexei Starovoitov wrote:
...
>
> above line is an indication that you have:
> #if defined(CONFIG_DEBUG_PREEMPT) || defined(CONFIG_PREEMPT_TRACER)
> turning it off will speed up things significantly.
Look, this won't change the overall picture. For sure i
On Wed, Mar 09, 2016 at 07:39:19PM +0300, Cyrill Gorcunov wrote:
> On Sun, Mar 06, 2016 at 08:06:41PM +0300, Cyrill Gorcunov wrote:
> > >
> > > Well, this looks like LOCKDEP kernel. Are you really running LOCKDEP on
> > > production kernels ?
> >
>
> Hi Eric, David. Sorry for the delay. Finally
On Wed, Mar 09, 2016 at 07:39:19PM +0300, Cyrill Gorcunov wrote:
> On Sun, Mar 06, 2016 at 08:06:41PM +0300, Cyrill Gorcunov wrote:
> > >
> > > Well, this looks like LOCKDEP kernel. Are you really running LOCKDEP on
> > > production kernels ?
> >
>
> Hi Eric, David. Sorry for the delay. Finally
On Sun, Mar 06, 2016 at 08:06:41PM +0300, Cyrill Gorcunov wrote:
> >
> > Well, this looks like LOCKDEP kernel. Are you really running LOCKDEP on
> > production kernels ?
>
Hi Eric, David. Sorry for the delay. Finally I've measured the
latency on the hw. It's i7-2600 cpu with 16G of memory. Here
On Sun, Mar 06, 2016 at 08:23:12AM -0800, Eric Dumazet wrote:
> On dim., 2016-03-06 at 13:09 +0300, Cyrill Gorcunov wrote:
>
> > Anyway, then I run this script for 255 as parameter
> > in one pass which gen. requests to create 65025 addresses
> > and kernel start complaining:
> >
> > Perf output
On dim., 2016-03-06 at 13:09 +0300, Cyrill Gorcunov wrote:
> Anyway, then I run this script for 255 as parameter
> in one pass which gen. requests to create 65025 addresses
> and kernel start complaining:
>
> Perf output
> ---
> 24.95% [kernel] [k] __local_bh_enabl
On Sat, Mar 05, 2016 at 09:44:59PM +0300, Cyrill Gorcunov wrote:
> On Sat, Mar 05, 2016 at 11:33:12AM -0500, David Miller wrote:
> ...
> >
> > Probably the same optimization can be applied there, see patch below.
> > And if that doesn't do it, there is a really easy way to batch the
> > delete by
On Sat, Mar 05, 2016 at 11:33:12AM -0500, David Miller wrote:
...
>
> Probably the same optimization can be applied there, see patch below.
> And if that doesn't do it, there is a really easy way to batch the
> delete by scanning the FIB tree in one go and deleting every entry
> that points to "in
On Sat, Mar 05, 2016 at 11:33:12AM -0500, David Miller wrote:
> > and until everything get cleaned up I couldn't connect
> > to the node via ssh. I continue playing with patch maybe
> > I find some other optimization paths. Thanks!
>
> What is the order of magnitude of the delay, as a function of
From: Cyrill Gorcunov
Date: Sat, 5 Mar 2016 18:57:14 +0300
> On Fri, Mar 04, 2016 at 11:11:09PM -0500, David Miller wrote:
>> From: Eric Dumazet
>> Date: Fri, 04 Mar 2016 16:08:30 -0800
>>
>> > __inet_del_ifa() should probably take into account in_dev->dead (no
>> > promotion, no list scan...)
On Fri, Mar 04, 2016 at 11:11:09PM -0500, David Miller wrote:
> From: Eric Dumazet
> Date: Fri, 04 Mar 2016 16:08:30 -0800
>
> > __inet_del_ifa() should probably take into account in_dev->dead (no
> > promotion, no list scan...)
>
> Indeed, that is the real problem:
Well, tried it out. Indeed i
On Fri, Mar 04, 2016 at 11:11:09PM -0500, David Miller wrote:
> From: Eric Dumazet
> Date: Fri, 04 Mar 2016 16:08:30 -0800
>
> > __inet_del_ifa() should probably take into account in_dev->dead (no
> > promotion, no list scan...)
>
> Indeed, that is the real problem:
Oh, this email dropped into
On Fri, Mar 04, 2016 at 05:50:32PM -0500, David Miller wrote:
>
> Arbitrary limits are... arbitrary.
>
> If the freeing loop is the issue, splice the list at teardown and
> process that list asynchronously via a workqueue or similar.
Thanks! I'll try.
From: Eric Dumazet
Date: Fri, 04 Mar 2016 16:08:30 -0800
> __inet_del_ifa() should probably take into account in_dev->dead (no
> promotion, no list scan...)
Indeed, that is the real problem:
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 8c3df2c..7412feb 100644
--- a/net/ipv4/devine
On ven., 2016-03-04 at 17:50 -0500, David Miller wrote:
> From: Cyrill Gorcunov
> Date: Sat, 5 Mar 2016 00:39:20 +0300
>
> > Currenlty all the kernels (including vanilla) free ifa
> > list under rtln_lock() taken which takes a huge time
> > to release all entries when we stop the container.
> > M
From: Cyrill Gorcunov
Date: Sat, 5 Mar 2016 00:39:20 +0300
> Currenlty all the kernels (including vanilla) free ifa
> list under rtln_lock() taken which takes a huge time
> to release all entries when we stop the container.
> Moreover it's allowed to create unlimited number
> of addresses from in
Currenlty all the kernels (including vanilla) free ifa
list under rtln_lock() taken which takes a huge time
to release all entries when we stop the container.
Moreover it's allowed to create unlimited number
of addresses from inside of net-namespace if
CAP-NET_ADMIN granted (which is common for con
50 matches
Mail list logo
