Re: [tipc-discussion] [PATCH net 0/3] net: fix quite a few dst_cache crashes reported by syzbot

Commenting on Jon's response fist. Den tors 20 juni 2019 kl 13:26 skrev Xin Long : > > On Mon, Jun 17, 2019 at 10:28 PM Jon Maloy wrote: > > Hi Xin, > > As I remember the discussion around introduction of UDP media a few years ago, the developer, Erik Huge, only chose to register TIPC as a udp

Re: [tipc-discussion] [net-next] tipc: add loopback device tracking

Change in netlink.c unrelated to the commit //E On Tue, 18 Jun 2019, 02:23 John Rutherford, wrote: > Since node internal messages are passed directly to socket it is not > possible to observe this message exchange via tcpdump or wireshark. > > We now remedy this by making it possible to clone

Re: [tipc-discussion] Using TIPC protocol for ZeroMQ bindings, in Clojure CLR

Check out: http://hintjens.com/blog:70 //E On Tue, 30 Apr 2019, 10:59 Jon Maloy, wrote: > Hi Ivan, > > Asa matter of fact, TIPC is already supported by ZeroMQ. This was done by > Erik Hugne when he was working at Ericsson a few years back. > > As I understand it, the s

Re: [tipc-discussion] Subscribing for "all" service changes?

You could probably cook up an eBPF program to do this. Have a look at bpftrace, it doesn't give the full solution, but points the right way. //E On Fri, 26 Apr 2019, 11:50 Peter Fröhlich, wrote: > I expressed myself unclearly in that second email, sorry for that. > What I am looking for is

Re: [tipc-discussion] FW: [PATCH 1/1] tipc: eliminate node rwlock

Hi. I remember this  The node struct size could potentially be a problem on preempt kernels is if we need to do synchronize_rcu in a hot path (tipc_rcv). But i dont think thats necessary, and that the RCU approach is preferrable. //E On Tue, 26 Mar 2019, 22:03 Jon Maloy, wrote: > Hi Hoang,

Re: [tipc-discussion] Topology subscriptions in bash

ils as a > separate module, or possibly as part of libtipc, which is already there. > > You are still registered as developer at SF/tipc, so you are free to do > it. Otherwise I can fix it, but I am pretty busy these days. > > > > BR > > ///jon > > > > >

[tipc-discussion] [PATCH v2 net] tipc: fix cancellation of topology subscriptions

From: Erik Hugne When cancelling a subscription, we have to clear the cancel bit in the request before iterating over any established subscriptions with memcmp. Otherwise no subscription will ever be found, and it will not be possible to unsubscribe. Signed-off-by: Erik Hugne --- v2: clear bit

Re: [tipc-discussion] Topology subscriptions in bash

ing to > tipc_utils? > > ///jon > > > > -Original Message----- > > From: Erik Hugne > > Sent: 19-Mar-19 22:33 > > To: tipc-discussion@lists.sourceforge.net; Jon Maloy > > > > Subject: Topology subscriptions in bash > > > > A small tool to get

[tipc-discussion] Topology subscriptions in bash

A small tool to get shell integrations to the TIPC topology server, maybe someone will find it useful https://github.com/Hugne/tipc.sh The subscriber examples use part of the functionality that i plan to submit to the bash project for network redirection support, e.g: [root@kdev ~] exec

Re: [tipc-discussion] [PATCH net-next] tipc: fix cancellation of topology subscriptions

s like a bug fix and should > go to 'net'. > I'll post it for you if you want. > > ///jon > > > -Original Message- > > From: erik.hu...@gmail.com > > Sent: 19-Mar-19 11:08 > > To: tipc-discussion@lists.sourceforge.net; Jon Maloy > > ; ying@windriv

[tipc-discussion] [PATCH net-next] tipc: fix cancellation of topology subscriptions

From: Erik Hugne When cancelling a subscription, we have to clear the cancel bit in the request before iterating over any established subscriptions with memcmp. Otherwise no subscription will ever be found, and it will not be possible to unsubscribe. Signed-off-by: Erik Hugne --- Ignore my

[tipc-discussion] [PATCH v3] tipc: allow service ranges to be connect()'ed on RDM/DGRAM

From: Erik Hugne We move the check that prevents connecting service service ranges to after the RDM/DGRAM check, and split out address sanitizing to a separate function that also validates the service range. Fixes: 23998835be98 ("tipc: improve address sanity check in tipc_connect()")

Re: [tipc-discussion] [PATCH v2] tipc: allow service ranges to be connect()'ed on RDM/DGRAM

No love for this? :( RDM connect is pretty handicapped right now ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion

[tipc-discussion] [PATCH v2] tipc: allow service ranges to be connect()'ed on RDM/DGRAM

From: Erik Hugne We move the check that prevents connecting service service ranges to after the RDM/DGRAM check, and split out address sanitizing to a separate function that also validates the service range. Signed-off-by: Erik Hugne --- I was pondering to move all sanitize stuff (including

Re: [tipc-discussion] [PATCH net] tipc: allow multicast address to be associated for RDM/DGRAM sockets

OTOH, an invalid address will be caught on the first send(), where -EHOSTUNREACH will be returned. Jon, what do you think? Den fre 8 mars 2019 kl 21:16 skrev Erik Hugne : > I just realized that we may need to do some basic validation of > TIPC_MULTICAST addresses. > With t

Re: [tipc-discussion] [PATCH net] tipc: allow multicast address to be associated for RDM/DGRAM sockets

I just realized that we may need to do some basic validation of TIPC_MULTICAST addresses. With this patch, it will allow to connect() an address with lower > upper, which is bad. Den fre 8 mars 2019 kl 20:09 skrev : > From: Erik Hugne > > Perform the address type validation af

[tipc-discussion] [PATCH net] tipc: allow multicast address to be associated for RDM/DGRAM sockets

From: Erik Hugne Perform the address type validation after we check if it's a connectionless socket, allowing TIPC_MULTICAST addresses to be associated with RDM/DGRAM sockets. This was broken in the commit listed below. Fixes: 23998835be98 ("tipc: improve address sanity check in tipc_co

Re: [tipc-discussion] [PATCH] tipc: allow multicast address to be associated for RDM/DGRAM sockets

scussion@lists.sourceforge.net; Jon Maloy > > ; ying@windriver.com > > Cc: Erik Hugne > > Subject: [PATCH] tipc: allow multicast address to be associated for > > RDM/DGRAM sockets > > > > From: Erik Hugne > > > > Perform the address type validation afte

[tipc-discussion] [PATCH] tipc: allow multicast address to be associated for RDM/DGRAM sockets

From: Erik Hugne Perform the address type validation after we check if it's a connectionless socket, allowing TIPC_MULTICAST addresses to be associated with RDM/DGRAM sockets. --- net/tipc/socket.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/net/tipc/socket.c b

[tipc-discussion] Thoughts/comments on bash redirect functionality?

If you are interested in network redirection support for bash: https://github.com/Hugne/bash/commit/master Currently, it works in RDM/DGRAM mode only i want to keep the interface simple and not involve any seqpacket/rdm switches in the file path specification. So currently, you can do something

[tipc-discussion] [PATCH net] tipc: fix RDM/DGRAM connect() regression

From: Erik Hugne Fix regression bug introduced in commit 365ad353c256 ("tipc: reduce risk of user starvation during link congestion") Only signal -EDESTADDRREQ for RDM/DGRAM if we don't have a cached sockaddr. Signed-off-by: Erik Hugne --- Jon/Ying, i have a very limited test set

Re: [tipc-discussion] RDM connect error

kernels there was another bug where m->msg_namelen was checked (even if we used a cached sockaddr), but that seems to have been fixed Den lör 2 mars 2019 kl 19:57 skrev Erik Hugne : > It was added in this one, sorry > > https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.gi

[tipc-discussion] RDM sockaddr association broken?

Hi. Years ago, a patch was submitted that added the ability to associate a sockaddr with a connectionless socket: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/net/tipc/socket.c?id=f2f8036e391eb82ee78764483f869f2feafb5da8 subsequent send() over this socket would then

Re: [tipc-discussion] [RFC PATCH v1 12/12] tipc: remove SS_CONNECTED sock state

un some non blocking test for rdm and stream sockets and they work. > Can you elaborate if you have something specific in mind? > > /Partha > On 07/25/2016 10:28 PM, Erik Hugne wrote: > > Nonblocking sockets tested? :) > > //E > > On Jul 25, 2016 14:26, "Parthas

Re: [tipc-discussion] [RFC PATCH v1 12/12] tipc: remove SS_CONNECTED sock state

Nonblocking sockets tested? :) //E On Jul 25, 2016 14:26, "Parthasarathy Bhuvaragan" < parthasarathy.bhuvara...@ericsson.com> wrote: > In this commit, we remove the state SS_CONNECTED and replace it > with the function tipc_sk_state_connected() wherever possible. > A socket with sk_state

Re: [tipc-discussion] ENOMEM

> > > Is there a TIPC specific buffer pool (like there is for UDP and TCP)? > > > > *From:* Erik Hugne [mailto:erik.hu...@gmail.com] > *Sent:* Wednesday, July 20, 2016 11:43 AM > *To:* Rune Torgersen > *Cc:* tipc-discussion@lists.sourceforge.net > *Subject:

Re: [tipc-discussion] ENOMEM

Each send() call will cause a new skb to be allocated from a cache. the caches are of fixed size, and do not grow (afaik, but the allocator can pick from higher order pool). The skbs are reclaimed by the cache when the stack is done with them. If the cache is exhausted when we call alloc_skb,

Re: [tipc-discussion] [PATCH net-next 3/6] tipc: introduce UDP replicast

On Jun 30, 2016 15:05, "Richard Alpe" wrote: > > On 2016-06-29 21:20, Jon Maloy wrote: > > > > > >> -Original Message- > >> From: Jon Maloy [mailto:jon.ma...@ericsson.com] > >> Sent: Wednesday, 29 June, 2016 12:05 > >> To: Jon Maloy;

Re: [tipc-discussion] [PATCH net-next 3/3] tipc: use sock addr family to indicate IP version

This change is not backwards compatible, udp_media_addr is carried in the neighbor discovery messages. //E On Jun 22, 2016 10:03, "Richard Alpe" wrote: > Use socket address family instead of ethernet protocol ID to identify > IP version internally. > --- >

Re: [tipc-discussion] [PATCH net v3 1/1] tipc: fix socket timer deadlock

On Mon, Jun 13, 2016 at 01:51:15PM -0400, Jon Maloy wrote: > --- a/net/tipc/socket.c > +++ b/net/tipc/socket.c > @@ -1830,6 +1834,14 @@ void tipc_sk_rcv(struct net *net, struct sk_buff_head > *inputq) > tipc_sk_enqueue(inputq, sk, dport); >

Re: [tipc-discussion] Configuring multiple network ids on a node

On Jun 13, 2016 7:36 AM, "Arjun Pandey" wrote: [...] > Based on my understanding of the above we should be able to configure > multiple netid's on the same eth port. This effictively would allow > one to have 2 TIPC networks via the same port. > For this to work, you need

Re: [tipc-discussion] Configuring multiple network ids on a node

The tipc netid defaults to 4711, if you need to change this, it must be done before you assign an address to the nodes. But you probably dont want/need to change it unless you run multiple tipc networks on the same medium. //E On Jun 13, 2016 7:36 AM, "Arjun Pandey"

Re: [tipc-discussion] [RFC PATCH] tipc: fix timer handling when socket is owned

If/when all agrees on this, i leave it in your capable hands to signoff/send to netdev when you feel the time is right. //E On Jun 7, 2016 09:46, "Xue, Ying" <ying@windriver.com> wrote: > Tested-by: Ying Xue <ying@windriver.com> > > -Original

Re: [tipc-discussion] [RFC PATCH] tipc: fix timer handling when socket is owned

On Jun 2, 2016 1:03 PM, "Xue, Ying" wrote: > > Acked-by: Ying Xue > > Jon, whatever the patch can fix Guna's issue or not, I think the change is right because there is an obvious error that we deliver message through tipc_node_xmit_skb() when

Re: [tipc-discussion] tipc_sk_rcv: Kernel panic on one of the card on 4.4.0

On May 31, 2016 6:12 PM, "GUNA" wrote: > > Could you provide me the exact code change for rescheduling, so I > don't want to make any mistake. > Nope, I'm travelling now. But if you want to try the resched-timer-if-owned hack, use: sk_reset_timer(sk, >sk_timer, (HZ / 20));

Re: [tipc-discussion] tipc_sk_rcv: Kernel panic on one of the card on 4.4.0

On May 31, 2016 17:34, "GUNA" wrote: > > Which Erik's patch you are talking about? > Is this one, "tipc: fix timer handling when socket is owned" ? I think he was referring to my earlier suggestion to reschedule the timer if the socket is owned by user when it fires. The

Re: [tipc-discussion] tipc_sk_rcv: Kernel panic on one of the card on 4.4.0

I will continue my analysis, but input from others would be appreciated. > > ///jon > > > > -Original Message- > > From: GUNA [mailto:gbala...@gmail.com] > > Sent: Saturday, 28 May, 2016 06:00 > > To: Jon Maloy; tipc-discussion@lists.sourceforge.net; Erik H

Re: [tipc-discussion] [PATCH iproute2 4/4] tipc: implement bearer add functionality

> .ti -8 > +.B tipc bearer add remoteip REMOTEIP media udp name NAME Why is the parameter order different from "bearer enable"? tipc bearer enable media udp localip xxx name yyy? Or can you specify it in this order when adding replicast remoteips aswell? //E

Re: [tipc-discussion] tipc_sk_rcv: Kernel panic on one of the card on 4.4.0

3/0x130 [686813.257936] NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [swapper/3:0] On Thu, May 19, 2016 at 3:06 PM, Erik Hugne <erik.hu...@gmail.com> wrote: > On Thu, May 19, 2016 at 10:34:05AM -0400, GUNA wrote: >> One of the card in my system is dead and rebooted to

Re: [tipc-discussion] tipc_sk_rcv: Kernel panic on one of the card on 4.4.0

On Thu, May 19, 2016 at 10:34:05AM -0400, GUNA wrote: > One of the card in my system is dead and rebooted to recover it. > The system is running on Kernel 4.4.0 + some latest TIPC patches. > Your earliest feedback of the issue is recommended. > At first i thought this might be a spinlock

Re: [tipc-discussion] [zeromq/libzmq] Tests and Protocol Support for TIPC partially broken (#1968)

On May 11, 2016 14:34, "Jon Maloy" <ma...@donjonn.com> wrote: > > > > On 05/10/2016 04:22 PM, Erik Hugne wrote: > > Problem was that the test system didn't have a TIPC address configured, but > > this is assumed to always be done in the name resolv

Re: [tipc-discussion] [zeromq/libzmq] Tests and Protocol Support for TIPC partially broken (#1968)

Problem was that the test system didn't have a TIPC address configured, but this is assumed to always be done in the name resolve function (another problem is that i've hardcoded the lookup domain to 1.0.0) https://github.com/zeromq/libzmq/issues/1968 So name lookups will fail to resolve

[tipc-discussion] Fwd: Re: [zeromq/libzmq] Tests and Protocol Support for TIPC partially broken (#1968)

sts and Protocol Support for TIPC partially broken (#1968) To: "zeromq/libzmq" <lib...@noreply.github.com> Cc: "Erik Hugne" <erik.hu...@gmail.com>, "Mention" < ment...@noreply.github.com> Good question. I would like to think so. I attempted to trace it

Re: [tipc-discussion] tipc: tipc_recv_stream with kernel panic

(On mobile) At first glance, it seems that the socket was freed, but there was a pending wakeup signal for it. Which then causes the subsequent spin_lock_bh() to deref freed mem. //E On May 3, 2016 02:43, "GUNA" wrote [...] >> [375832.498126] BUG: unable to handle kernel

Re: [tipc-discussion] kernel page allocation problem

On Apr 10, 2016 15:27, "Leon Pollak" wrote: > > After your answer I again looked through the both manuals and did not find > anything saying that connectionless messaging allows drops. Vice verse, the > programmer's manual explicitly states that "TIPC is designed to be a reliable

Re: [tipc-discussion] [PATCH net-next 1/1] tipc: add neighbor monitoring framework

On Sat, Apr 09, 2016 at 02:38:15PM -0400, Jon Maloy wrote: > TIPC based clusters are by default set up with full-mesh link > connectivity between all nodes. Those links are expected to provide > a short failure detection time, by default set to 1500 ms. Because > of this, the background load for

Re: [tipc-discussion] [PATCH 0/3] tipcutils: remove duplicated functionality

Actually, there doesn't seem to be a way to tell git format-patch that it should 'just' delete the file. I always get that blob no matter how i generate the patch.. 2016-04-09 8:31 GMT+02:00 Erik Hugne <erik.hu...@gmail.com>: > On Sat, Apr 09, 2016 at 08:21:03AM +0200, Erik Hu

Re: [tipc-discussion] [PATCH 0/3] tipcutils: remove duplicated functionality

On Sat, Apr 09, 2016 at 08:21:03AM +0200, Erik Hugne wrote: > It made sense to keep tipcconfig in the tipcutils package for a while > after Richard merged it to iproute2, but now it's becoming more of a > source of confusion. And any patches submitted to iproute2/tipc would > need t

[tipc-discussion] [PATCH 1/3] tipcutils: fix .gitignore and remove binaries from git control

Signed-off-by: Erik Hugne <erik.hu...@gmail.com> --- .gitignore | 3 +++ demos/c_api_demo/tipc_c_api_client | Bin 44348 -> 0 bytes demos/c_api_demo/tipc_c_api_server | Bin 44404 -> 0 bytes 3 files changed, 3 insertions(+) delete mode 100755 demo

[tipc-discussion] [PATCH 3/3] tipcutils: purge old config tool

This have been moved to the iproute2 package. Signed-off-by: Erik Hugne <erik.hu...@gmail.com> --- Makefile.am |1 - configure.ac |3 +- man/Makefile.am |2 +- man/tipc-config.1 | 115 man/tipc-pipe.1 |3 - tipc-

[tipc-discussion] [PATCH 2/3] tipcutils: fix build warnings

add missing .h files and type specifiers, and remove unused declarations Signed-off-by: Erik Hugne <erik.hu...@gmail.com> --- demos/iov_control/iov_control.c | 4 +++- ptts/tipc_ts_server.c | 9 - tipc-pipe/tipc-pipe.c | 2 +- 3 files changed, 4 insertions(

[tipc-discussion] [PATCH 0/3] tipcutils: remove duplicated functionality

, and also does some other small cleanups. Erik Hugne (3): tipcutils: fix .gitignore and remove binaries from git control tipcutils: fix build warnings tipcutils: purge old config tool .gitignore |3 + Makefile.am|1 - configure.ac

Re: [tipc-discussion] Kernel 4.4.0 TIPC: links were bouncing and not stable enough

On Fri, Apr 08, 2016 at 05:23:44PM -0400, Jon Maloy wrote: > 1) Enable the printouts "Lost link..." and "Established link..." in > node.c and observe in the kernel log if those links really are (or were, > before your patches) instable. Or he could use the userspace logger. git clone

[tipc-discussion] [PATCH 0/2] tipc: name distributor pernet queue

/gmane.network.tipc.general/9837/focus=9918 I have not been able to test this properly, my crappy laptop can barely run two VM's. Maybe Richard or Partha could run this through the named stresstest? ;) Erik Hugne (2): tipc: make dist queue pernet tipc: purge deferred updates from dead nodes net/tipc/core.c

[tipc-discussion] [PATCH 1/2] tipc: make dist queue pernet

pernet instead. Signed-off-by: Erik Hugne <erik.hu...@gmail.com> --- net/tipc/core.c | 1 + net/tipc/core.h | 3 +++ net/tipc/name_distr.c | 16 +++- 3 files changed, 11 insertions(+), 9 deletions(-) diff --git a/net/tipc/core.c b/net/tipc/core.c index 03a8428..e2

[tipc-discussion] [PATCH 2/2] tipc: purge deferred updates from dead nodes

If a peer node becomes unavailable, in addition to removing the nametable entries from this node we also need to purge all deferred updates associated with this node. Signed-off-by: Erik Hugne <erik.hu...@gmail.com> --- net/tipc/name_distr.c | 19 +++ 1 file chang

Re: [tipc-discussion] tipc nametable update problem

} from <1.1.1> key=0 > Mar 22 10:34:34 mitchelltelctrl2 kernel: Dropping name table update (0) of > {0, 0, 16600} from <1.1.1> key=4294915584 > > but they do not mention port 104. > > If I restart the application on 1 having 104:1025 open, it shows up on 2. > > -

Re: [tipc-discussion] tipc nametable update problem

Hi Rune. When the problem occurs, have you seen any traces like "tipc: Dropping name table update" ? //E On Mar 18, 2016 02:11, "Rune Torgersen" wrote: > More info. > The failing ports are all opened as TIPC_ZONE_SCOPE. > Addresses of the two computers are 1.1.1 and

Re: [tipc-discussion] [PATCH tipc-discussion] tipc: fix headroom of copied skb in link retransmit

Expand head conditionally based on udp_media_addr.proto? For ETH_P_IPV6 it would be 48b i guess, if the v6 stack doesn't feel like adding extension headers that is.. //E On Mar 10, 2016 15:47, "Jon Maloy" wrote: > > > > -Original Message- > > From: Richard Alpe >

Re: [tipc-discussion] [PATCH v1 1/4] tipc: add net device to skb before UDP xmit

On Wed, Mar 02, 2016 at 06:11:13PM +0100, Richard Alpe wrote: > Prior to this patch enabling a IPv4 UDP bearer caused a null pointer > dereference in iptunnel_xmit_stats(), when it tried to dereference the > net device from the skb. To resolve this we now point the skb device > to the net device