On Mon, Nov 05, 2018 at 10:12:34AM +0300, Cyrill Gorcunov wrote:
>
> Andrew, looking into kernel code I wonder, maybe we should simply
> add this protocol into inet_protos during net/ipv4/af_inet.c:inet_init?
> It will require to add netns_ok into raw_prot of course.
After spending
On Sun, Nov 04, 2018 at 10:37:15PM -0800, Andrei Vagin wrote:
> IPPROTO_TCP isn't registred as an inet protocol, so
> inet_protos[protocol] is always NULL for it.
Typo, IPPROTO_RAW
>
> Cc: Cyrill Gorcunov
> Cc: Xin Long
> Fixes: bf2ae2e4bf93 ("sock_diag: reques
On Wed, Oct 25, 2017 at 09:55:07AM -0400, Roman Mashak wrote:
>
> I think __zero should be explicitly set to 0.
It will be by compiler default.
On Tue, Oct 24, 2017 at 05:25:16PM -0700, Andrei Vagin wrote:
> On Wed, Oct 25, 2017 at 12:48:14AM +0300, Cyrill Gorcunov wrote:
> > Currently unix_diag_vfs structure reports unix socket inode
> > as u32 value which of course doesn't fit to ino_t type and
>
> BTW: As
in future).
CC: Andrey Vagin
CC: David S. Miller
CC: Pavel Emelyanov
Signed-off-by: Cyrill Gorcunov
---
I build-tested it only thus not for inclusion yet, but rather
to discuss if there some better way to handle this potential
problem.
include/uapi/linux/unix_diag.h |8
On Thu, Dec 01, 2016 at 10:57:01AM -0800, Stephen Hemminger wrote:
>
> Applied both patches, but needed to remove inet_diag.h since
> already updated kernel headers.
Thank you! I think we might need to extend the matching interface
for killing raw sockets in near future, because for now it is
too
On Wed, Nov 02, 2016 at 09:36:55AM -0600, David Ahern wrote:
>
> Limited to raw sockets or are you looking at multiple spec options (dev,
> address, port)?
>
> I have not seen issues with tcp or udp. Running:
>
> ss -aK 'dev == red'
>
> drops all sockets bound to device 'red' (or at least
On Wed, Nov 02, 2016 at 09:10:32AM -0600, David Ahern wrote:
> > @__dif != 0 the match may return socket where sk_bound_dev_if = 0
> > instead of completely matching one. Isn't it?
>
> yes. I recently added an exact_dif to the lookup for listener sockets
> (see compute_score). Something like that
In case if some diag module is not present in the system,
say the kernel is not modern enough, we simply skip the
error code reported. Instead we should check for data
length in NLMSG_DONE and process unsupported case.
Signed-off-by: Cyrill Gorcunov
---
lib/libnetlink.c | 16
1
The diag interface for raw sockets is now in linux-net-next
http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=432490f9d455fb842d70219f22d9d2c812371676
so here is early patches for misc/ss
I've to update libnetlink code to keep backward compatibility and switch to
parse proc
unix, tcp, udp[lite], packet, netlink sockets already support diag
interface for their collection and killing. Implement support
for raw sockets.
Signed-off-by: Cyrill Gorcunov
---
include/linux/inet_diag.h | 15 +++
misc/ss.c | 20 ++--
2 files
Hi! Here are a few fixes for raw-diag sockets handling: missing
sock_put call and jump for exiting from nested cycle. I made
patches for iproute2 as well so will send them out soon.
Also I have a question about sockets lookup not for raw diag only
(though I didn't modify lookup procedure) but in g
In raw_diag_destroy the helper raw_sock_get returns
with sock_hold call, so we have to put it then.
CC: David S. Miller
CC: Eric Dumazet
CC: David Ahern
CC: Andrey Vagin
CC: Stephen Hemminger
Signed-off-by: Cyrill Gorcunov
---
net/ipv4/raw_diag.c |5 -
1 file changed, 4 insertions
I managed to miss that sk_for_each is called under "for"
cycle so need to use goto here to return matching socket.
CC: David S. Miller
CC: Eric Dumazet
CC: David Ahern
CC: Andrey Vagin
CC: Stephen Hemminger
Signed-off-by: Cyrill Gorcunov
---
net/ipv4/raw_diag.c |3 ++-
1 fi
g first patch, so I thought I've
to notify them with this typo in code.
> > Signed-off-by: Cyrill Gorcunov
>
> Acked-by: Eric Dumazet
>
> Thanks.
>
>
Cyrill
Signed-off-by: Cyrill Gorcunov
---
On top of net-next tree 22ca904ad70afc831d8503e80be1b6558a978759
net/ipv4/raw.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-ml.git/net/ipv4/raw.c
===
--- linux
On Thu, Oct 27, 2016 at 09:52:53AM +0300, Cyrill Gorcunov wrote:
...
> >
> > This looks like a mistake in how you implemented the functionality in the
> > kernel.
> > Despite what it looks like, all netlink request/reply functionality reports
> > errors in curre
On Wed, Oct 26, 2016 at 08:52:56PM -0700, Stephen Hemminger wrote:
> On Wed, 26 Oct 2016 22:30:07 +0300
> Cyrill Gorcunov wrote:
>
> >
> > if (h->nlmsg_type == NLMSG_DONE) {
> > +
In case if some diag module is not present in the system,
say the kernel is not modern enough, we simply skip the
error code reported. Instead we should check for data
length in NLMSG_DONE and process unsupported case.
Signed-off-by: Cyrill Gorcunov
---
lib/libnetlink.c | 21
unix, tcp, udp[lite], packet, netlink sockets already support diag
interface for their collection and killing. Now with commit XXX
this facility is implemented for raw sockets.
Signed-off-by: Cyrill Gorcunov
---
include/linux/inet_diag.h | 15 +++
misc/ss.c | 20
]# ./misc/ss -aKw 'dev == vm1'
State Recv-Q Send-QLocal Address:Port
Peer Address:Port
[root@pcs7 iproute2]#
It doesn't do all this in one pass, so I suspect I miss something in second
patch?
Pleas
On Tue, Oct 25, 2016 at 05:53:22PM +0200, Arnd Bergmann wrote:
> The newly added raw_diag.c fails to build in some configurations
> unless we include this header:
>
> In file included from net/ipv4/raw_diag.c:6:0:
> include/net/raw.h:71:21: error: field 'inet' has incomplete type
> net/ipv4/raw_di
On Sat, Oct 22, 2016 at 06:55:27PM -0400, David Miller wrote:
> From: Cyrill Gorcunov
> Date: Fri, 21 Oct 2016 13:03:44 +0300
>
> > In criu we are actively using diag interface to collect sockets
> > present in the system when dumping applications. And while for
> > u
f any of structure unintentionally changed.
CC: David S. Miller
CC: Eric Dumazet
CC: David Ahern
CC: Alexey Kuznetsov
CC: James Morris
CC: Hideaki YOSHIFUJI
CC: Patrick McHardy
CC: Andrey Vagin
CC: Stephen Hemminger
Signed-off-by: Cyrill Gorcunov
---
include/net/raw.h |6
On Thu, Oct 13, 2016 at 09:43:57AM -0600, David Ahern wrote:
> On 10/13/16 1:16 AM, Cyrill Gorcunov wrote:
> > On Wed, Oct 12, 2016 at 07:55:04PM -0400, David Miller wrote:
> >> From: Cyrill Gorcunov
> >> Date: Wed, 12 Oct 2016 09:53:29 +0300
> >>
> >>
On Wed, Oct 12, 2016 at 07:55:04PM -0400, David Miller wrote:
> From: Cyrill Gorcunov
> Date: Wed, 12 Oct 2016 09:53:29 +0300
>
> > I can't rename the field, neither a can use union.
>
> Remind me again what is wrong with using an anonymous union?
Anon union wou
On Wed, Oct 12, 2016 at 01:50:22AM -0400, David Miller wrote:
>
> Macros that look like function calls and are also lvalues tend to be
> troublesome.
>
> I know what you're trying to achieve, you want a named way to access
> this so that the intent and semantics are clear.
>
> But I'd rather you
ger
Signed-off-by: Cyrill Gorcunov
---
Really sorry for delay. Take a look please once time permit,
I think the most safe solution is to use macro which wraps
@pad access so the userspace progs won't fail on compilation
if they keep the reference on this field.
include/net/raw.h
On Wed, Sep 28, 2016 at 06:49:51AM -0700, Eric Dumazet wrote:
> >
> > 4.7 is pretty widespread, so I've to think...
>
> Sorry, 4.4.7 it was
>
> https://www.mail-archive.com/netdev@vger.kernel.org/msg128714.html
Ah, thanks for info!
On Wed, Sep 28, 2016 at 06:29:08AM -0700, Eric Dumazet wrote:
> >
> > Oh, crap :( I've been looking into uapi headers, found that we
> > use anonymous unions (for example include/uapi/linux/bcache.h)
> > and thought it will be safe (and my test builds didn't fail).
> > Are you happen to know which
On Wed, Sep 28, 2016 at 06:02:11AM -0700, Eric Dumazet wrote:
>
> This is a bit different of course, since struct tc_fq_qd_stats is only
> one way : Kernel produces the content and gives it to user space.
>
> User space should probably not need to initialize such a structure, but
> who knows what
On Wed, Sep 28, 2016 at 05:57:12AM -0700, Eric Dumazet wrote:
...
> Note that some programs could fail to compile with the added union
> anyway.
>
> Some gcc versions are unable to compile a static init with an union
>
> struct inet_diag_req_v2 foo = { .pad = 0, sdiag_family = AF_INET, };
>
> Wh
On Wed, Sep 28, 2016 at 08:50:31AM -0400, Jamal Hadi Salim wrote:
>
> struct tcp_info.
Yeah I see. As I said naming pads will be safe but to do so we
will have to compile on every arch we support and make sure the
implicit pad remains here.
> Sorry - i didnt mean to drag this for long; but the m
On Wed, Sep 28, 2016 at 08:27:24AM -0400, Jamal Hadi Salim wrote:
> >
> > They must initialize it to zero.
> >
>
> What if in the future actually meant to use 0 for
> something?;-> For example in Cyrill's case it means PROTO_IP
> Not sure if it useful to interpret or not but it is part of the
>
On Wed, Sep 28, 2016 at 08:06:51AM -0400, Jamal Hadi Salim wrote:
>
> I understood well your point;-> Maybe my response was not clear:
> _nobody should be fscking fondling pad fields_ setting them or
> otherwise.
> Maybe let these programs fail. I asked if you knew any such app which
> did anythin
On Wed, Sep 28, 2016 at 08:07:01AM -0400, David Miller wrote:
...
> >
> > I think you miss the point what I'm trying to say: currently end-user
> > may have reference to this member (for any reason) and his program
> > will compile and run. If we change the name the compilation procedure
> > fails
On Wed, Sep 28, 2016 at 07:06:26AM -0400, Jamal Hadi Salim wrote:
> >
> > This structure is uapi, so anyone has complete rights to reference
> > @pad in the userspace programs. Sure it would be more clear to remove
> > the @pad completely, but if we choose so I think it's better to do
> > on top i
On Wed, Sep 28, 2016 at 06:43:01AM -0400, Jamal Hadi Salim wrote:
...
> >
> > Someone may have set it to zero explicitly on source level, and the
> > compilation will fail on new kernel then. So no, keeping the name
> > is reasonable.
> >
>
> I dont know how compilation will fail but you may be
On Wed, Sep 28, 2016 at 06:08:00AM -0400, Jamal Hadi Salim wrote:
...
> > @@ -38,7 +38,10 @@ struct inet_diag_req_v2 {
> > __u8sdiag_family;
> > __u8sdiag_protocol;
> > __u8idiag_ext;
> > - __u8pad;
> > + union {
> > + __u8pad;
> > + __u8s
xey Kuznetsov
CC: James Morris
CC: Hideaki YOSHIFUJI
CC: Patrick McHardy
CC: Andrey Vagin
CC: Stephen Hemminger
Signed-off-by: Cyrill Gorcunov
---
Thanks all for feedback! Take a look please once time permit.
include/net/raw.h |6 +
include/net/rawv6.h|7 +
On Tue, Sep 27, 2016 at 08:39:59AM -0700, Eric Dumazet wrote:
...
> > + }
> > + if (sk && !atomic_inc_not_zero(&sk->sk_refcnt))
> > + sk = NULL;
>
> Minor detail, but note that raw sockets do not use rcu (yet)
>
> Since you have read_lock(&hashinfo->lock), no writer can suddenly cha
attribute and use
it for socket matching
CC: David S. Miller
CC: Eric Dumazet
CC: David Ahern
CC: Alexey Kuznetsov
CC: James Morris
CC: Hideaki YOSHIFUJI
CC: Patrick McHardy
CC: Andrey Vagin
CC: Stephen Hemminger
Signed-off-by: Cyrill Gorcunov
---
Guys, take a look please once time permit. I
On Mon, Sep 26, 2016 at 07:54:37PM -0600, David Ahern wrote:
> On 9/26/16 4:38 PM, Cyrill Gorcunov wrote:
> > Something like
> >
> > Index: linux-ml.git/include/uapi/linux/inet_diag.h
> > ===
> > -
On Wed, Sep 21, 2016 at 12:13:43AM +0300, Cyrill Gorcunov wrote:
> On Fri, Sep 16, 2016 at 11:07:22PM +0300, Cyrill Gorcunov wrote:
> > > It may well be a ss bug / problem. As I mentioned I am always seeing 255
> > > for the protocol which
> >
> > It is rather
On Fri, Sep 16, 2016 at 11:07:22PM +0300, Cyrill Gorcunov wrote:
> > It may well be a ss bug / problem. As I mentioned I am always seeing 255
> > for the protocol which
>
> It is rather not addressed in ss. I mean, look, when we send out a diag packet
> the kernel look ups
On Fri, Sep 16, 2016 at 01:55:42PM -0600, David Ahern wrote:
> >> Since the display is showing sockets in addition to IPPROTO_RAW:
> >>
> >> $ ss -A raw
> >> State Recv-Q Send-QLocal Address:Port
> >> Peer Address:Port
> >> UNCONN 0 0
On Fri, Sep 16, 2016 at 01:47:57PM -0600, David Ahern wrote:
> >>
> >> I'm guessing you passed IPPROTO_RAW (255) as the protocol to socket(). If
> >> you pass something
> >> else (IPPROTO_ICMP for example) it won't work.
> >
> > True. To support IPPROTO_ICMP it need enhancement. I thought start w
On Fri, Sep 16, 2016 at 01:30:28PM -0600, David Ahern wrote:
> > [root@pcs7 iproute2]# misc/ss -A raw
> > State Recv-Q Send-QLocal Address:Port
> >Peer Address:Port
> >
> > ESTAB 0 0
On Fri, Sep 16, 2016 at 10:06:23AM +0300, Cyrill Gorcunov wrote:
> On Thu, Sep 15, 2016 at 05:45:02PM -0600, David Ahern wrote:
> > >
> > > Try to be selective in the -K , do not kill tcp sockets ?
> >
> > I am running
> >ss -aKw 'dev == red&#
On Thu, Sep 15, 2016 at 05:45:02PM -0600, David Ahern wrote:
> >
> > Try to be selective in the -K , do not kill tcp sockets ?
>
> I am running
>ss -aKw 'dev == red'
>
> to kill raw sockets bound to device named 'red'.
Thanks David, Eric! I'll play with this option today and report the resu
On Thu, Sep 15, 2016 at 02:54:57PM -0600, David Ahern wrote:
> On 9/15/16 2:22 PM, Cyrill Gorcunov wrote:
> >> ss -K is not working. Socket lookup fails to find a match due to a
> >> protocol mismatch.
> >>
> >> haven't had time to track down why there
On Thu, Sep 15, 2016 at 01:53:13PM -0600, David Ahern wrote:
> On 9/13/16 11:19 AM, Cyrill Gorcunov wrote:
> > In criu we are actively using diag interface to collect sockets
> > present in the system when dumping applications. And while for
> > unix, tcp, udp[lite], packet
: Hideaki YOSHIFUJI
CC: Patrick McHardy
CC: Andrey Vagin
CC: Stephen Hemminger
Signed-off-by: Cyrill Gorcunov
---
include/net/raw.h |6 +
include/net/rawv6.h |7 +
net/ipv4/Kconfig|8 +
net/ipv4/Makefile |1
net/ipv4/raw.c | 21
net/ipv4/raw_diag.c | 226
On Tue, Sep 13, 2016 at 11:57:35AM -0400, David Miller wrote:
> >
> > Thanks for review, David. I updated against net-next.
>
> Please do not post new versions of patches as replies to existing
> discussions.
>
> Instead, make fresh patch postings to the list.
Oh, will do. Sorry for inconvenien
On Sat, Sep 10, 2016 at 04:28:40PM -0600, David Ahern wrote:
> On 9/10/16 4:05 PM, Cyrill Gorcunov wrote:
> > On Sat, Sep 10, 2016 at 10:31:35AM -0600, David Ahern wrote:
> >>
> >> Would you mind adding the destroy capability as well? The udp version
> >> shoul
yet so for review only.
Will do testing at Monday.
---
From: Cyrill Gorcunov
Subject: [PATCH v2] net: ip, diag -- Add diag interface for raw sockets
In criu we are actively using diag interface to collect sockets
present in the system when dumping applications. And while for
unix, tcp, udp[lite], p
On Sat, Sep 10, 2016 at 10:31:35AM -0600, David Ahern wrote:
> On 9/9/16 12:26 PM, Cyrill Gorcunov wrote:
> > In criu we are actively using diag interface to collect sockets
> > present in the system when dumping applications. And while for
> > unix, tcp, udp[lite], packet
On Fri, Sep 09, 2016 at 12:55:13PM -0700, Eric Dumazet wrote:
> > +
> > + rep = nlmsg_new(sizeof(struct inet_diag_msg) +
> > + sizeof(struct inet_diag_meminfo) + 64,
> > + GFP_KERNEL);
> > + if (!rep)
>
> There is a missing sock_put(sk)
>
> > + re
: James Morris
CC: Hideaki YOSHIFUJI
CC: Patrick McHardy
CC: Andrey Vagin
CC: Stephen Hemminger
Signed-off-by: Cyrill Gorcunov
---
Take a look please, once time permit. Hopefully I didn't
miss something obvious, tested as "ss -n -A raw" for modified
iproute2 instance and
On Wed, Aug 03, 2016 at 08:54:50PM +0400, Stanislav Kinsburskiy wrote:
> Otherwise freezer cgroup state might never become "FROZEN".
>
> Here is a deadlock scheme for 2 processes in one freezer cgroup, which is
> freezing:
>
> CPU 0 CPU 1
>
On Thu, Jul 28, 2016 at 12:33:58PM +0200, Guillaume Nault wrote:
> >
> > After staring more I think the patch should be fine as a fix
> > since implementing sync with ppp_[re|un]register_channel and
> > ppp_ioctl might need a way more work.
> >
>
> [Sorry for arriving so late in the game, I was
On Wed, Jul 06, 2016 at 11:26:02AM +0300, Cyrill Gorcunov wrote:
> On Tue, Jul 05, 2016 at 10:12:36PM -0700, Cong Wang wrote:
> > Matt reported that we have a NULL pointer dereference
> > in ppp_pernet() from ppp_connect_channel(),
> > i.e. pch->chan_net is NULL.
> &
96 ("ppp: take reference on channels netns")
> Reported-by: Matt Bennett
> Cc: Paul Mackerras
> Cc: linux-...@vger.kernel.org
> Cc: Guillaume Nault
> Cc: Cyrill Gorcunov
> Signed-off-by: Cong Wang
> ---
Hi Cong! I may be wrong, but this doesn't look right in
On Wed, Jun 01, 2016 at 10:52:57AM +0300, Nikolay Borisov wrote:
> This patch adds the necessary members to user_struct. The idea behind
> the solution is really simple - user the userns pointers as keys into
> a hash table which holds the inotify instances/watches counts. This
> allows to account
them to preclude their netns from being removed from
> under them.
>
...
>
> Fixes: 273ec51dd7ce ("net: ppp_generic - introduce net-namespace
> functionality v2")
> Reported-by: Baozeng Ding
> Signed-off-by: Guillaume Nault
Good catch! Thanks!
Reviewed-by: Cyrill Gorcunov
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.
> >
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
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
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.
Work
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: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 be
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 whe
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
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 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 t
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.
>
>
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 ~]# ./exp
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'
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 tes
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
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 overhea
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
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
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-26
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 complaini
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 w
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
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.
n for containers).
Lets introduce per-net limit (4096 by default)
of addresses, which can be tuned up via sysfs
entry /proc/sys/net/ipv4/ifa_limit.
Reported-by: Solar Designer
Signed-off-by: Cyrill Gorcunov
CC: Vasily Averin
CC: Andrey Vagin
CC: Pavel Emelianov
CC: Vladimir Davydov
CC: Konst
94 matches
Mail list logo
