from:"Jon Paul Maloy"

Re: [tipc-discussion] [PATCH] tipc: add back tipc prefix to log messages

2017-11-23 Thread Jon Paul Maloy

Acked-by Jon Maloy  wrote:   
The tipc prefix to log messages generated by tipc was
removed in commit 07f6c4bc0 ("tipc: convert tipc reference
table to use generic rhashtable").

This is still a useful prefix and so add it back.

Signed-off-by: John Thompson 
---
 net/tipc/core.c | 2 --
 net/tipc/core.h | 2 ++
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/tipc/core.c b/net/tipc/core.c
index 0b982d048fb9..4cd9e57446ec 100644
--- a/net/tipc/core.c
+++ b/net/tipc/core.c
@@ -34,8 +34,6 @@
  * POSSIBILITY OF SUCH DAMAGE.
  */

-#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-
 #include "core.h"
 #include "name_table.h"
 #include "subscr.h"
diff --git a/net/tipc/core.h b/net/tipc/core.h
index 964342689f2c..f89f9a3c18c2 100644
--- a/net/tipc/core.h
+++ b/net/tipc/core.h
@@ -37,6 +37,8 @@
 #ifndef _TIPC_CORE_H
 #define _TIPC_CORE_H

+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
 #include 
 #include 
 #include 
-- 
2.15.0
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
  
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion

[tipc-discussion] Tr : RE : Link retransmission implementation

2008-03-04 Thread Jon Paul Maloy

Forgot to cc tipc-dicussion...
///jon

--- Jon Paul Maloy [EMAIL PROTECTED] a écrit :

 Date : Tue, 4 Mar 2008 11:20:50 -0500 (EST)
 De : Jon Paul Maloy [EMAIL PROTECTED]
 Objet: RE : [tipc-discussion] Link retransmission
 implementation
 À : [EMAIL PROTECTED]
 
 Regards
 ///jon
 
 --- [EMAIL PROTECTED] a écrit :
 
  Hi,
  
   though I read every documentation about TIPC that
 I
  could find, I still have many unanswered
 questions,
  especially about the implementation of reliable
  datagram communication (this is the only
  communication type we are currently using). Maybe
  you can help answering some of them:
  
  1. Exactly how does a link detect a message loss
  that did not occur due to link congestion (e. g.
  lost in the switch)? Does the receiver send acks
 or
  is the loss detected only by gaps in the serial
  number? 
 Both. The receiver sends an ack (a link state
 message) every 16th received packets. This is more
 for
 flow control than for loss detection, but the
 message
 contains all info needed for possible retransmission
 and detection of gaps. 
  
  2. Is a message automatically retransmitted if it
  gets lost and the reason is not a link congestion?
 Yes. And even if the reason is link congestion. As a
 user, link congestion isn't anything you need to
 worry
 about. 
 (However, I suspect that you really mean
 destination
 overload by this term, i.e. that a message may be
 rejected at the receiving socket because of a too
 slow
 receiver. With RDM sockets you must always be
 prepared
 for that.)
  
  3. When I send a message via an RDM link, does it
  get buffered somewhere till an ack has arrived (if
  acks are used, see 1.)?
 Yes. In a configurable-size send queue per link.
  
  4. If it gets buffered can it be accessed using
 the
  internal API? 
 No.
  I'd like to give an example to this : I send a RDM
  message via the internal API, a link congestion
  occurs and the appropriate error handler is called
  with reason ELINKCONG. Now I'd like to retransmit
  this message. How can I accomplish this?
 
 As a user, you will never see an ELINKCONG. At link
 congestion, the sending process is blocked until the
 congestion has abated, and then the message is sent
 automatically be the socket code.
 
  
  5. Is there a difference in error detection (i. e.
  lost messages) and retransmission between reliable
  datagrams and messages sent over a connection
  (assuming the DEST_DROPPABLE flag is not set on
 the
  RDM socket)?
 
 No. It is the same mechanism. However, connection
 oriented message are subject to a socket-to-socket
 flow control that assures that you will never see a
 message rejected due to destination socket overload.
 
  
  Thx for any answers!
  
  Regards,
  J.K.
  
  
  
  
 

-
  This SF.net email is sponsored by: Microsoft
  Defy all challenges. Microsoft(R) Visual Studio
  2008.
 

http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
  ___
  tipc-discussion mailing list
  tipc-discussion@lists.sourceforge.net
 

https://lists.sourceforge.net/lists/listinfo/tipc-discussion
  
 
 


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion

[tipc-discussion] RE : /net/tipc/port.c: Use tipc_port_unlock

2008-01-08 Thread Jon Paul Maloy

I have no objections.
///jon

--- Julia Lawall [EMAIL PROTECTED] a écrit :

 From: Julia Lawall [EMAIL PROTECTED]
 
 The file net/tipc/port.c takes a lock using the
 function tipc_port_lock and
 then releases the lock sometimes using
 tipc_port_unlock and sometimes using
 spin_unlock_bh(p_ptr-publ.lock).  tipc_port_unlock
 simply does the
 spin_unlock_bh, but it seems cleaner to use it
 everywhere.
 
 
 The problem was fixed using the following semantic
 patch.
 (http://www.emn.fr/x-info/coccinelle/)
 
 // smpl
 @@
 struct port *p_ptr;
 @@
 
p_ptr = tipc_port_lock(...)
...
 (
p_ptr = tipc_port_lock(...);
 |
 ?- spin_unlock_bh(p_ptr-publ.lock);
 +  tipc_port_unlock(p_ptr);
 )
 // /smpl
 
 Signed-off-by: Julia Lawall [EMAIL PROTECTED]
 ---
 
 diff -u -p a/net/tipc/port.c b/net/tipc/port.c
 --- a/net/tipc/port.c 2008-01-01 10:43:55.0
 +0100
 +++ b/net/tipc/port.c 2008-01-04 10:51:05.0
 +0100
 @@ -340,7 +340,7 @@ int tipc_portunreliable(u32 ref,
 unsigne
   if (!p_ptr)
   return -EINVAL;
   *isunreliable = port_unreliable(p_ptr);
 - spin_unlock_bh(p_ptr-publ.lock);
 + tipc_port_unlock(p_ptr);
   return TIPC_OK;
  }
 
 @@ -369,7 +369,7 @@ int tipc_portunreturnable(u32
 ref, unsig
   if (!p_ptr)
   return -EINVAL;
   *isunrejectable = port_unreturnable(p_ptr);
 - spin_unlock_bh(p_ptr-publ.lock);
 + tipc_port_unlock(p_ptr);
   return TIPC_OK;
  }
 
 @@ -843,7 +843,7 @@ static void
 port_dispatcher_sigh(void *d
   u32 peer_port = port_peerport(p_ptr);
   u32 peer_node = port_peernode(p_ptr);
 
 - spin_unlock_bh(p_ptr-publ.lock);
 + tipc_port_unlock(p_ptr);
   if (unlikely(!connected)) {
   if (unlikely(published))
   goto reject;
 @@ -867,7 +867,7 @@ static void
 port_dispatcher_sigh(void *d
   case TIPC_DIRECT_MSG:{
   tipc_msg_event cb = up_ptr-msg_cb;
 
 - spin_unlock_bh(p_ptr-publ.lock);
 + tipc_port_unlock(p_ptr);
   if (unlikely(connected))
   goto reject;
   if (unlikely(!cb))
 @@ -882,7 +882,7 @@ static void
 port_dispatcher_sigh(void *d
   case TIPC_NAMED_MSG:{
   tipc_named_msg_event cb = up_ptr-named_msg_cb;
 
 - spin_unlock_bh(p_ptr-publ.lock);
 + tipc_port_unlock(p_ptr);
   if (unlikely(connected))
   goto reject;
   if (unlikely(!cb))
 @@ -913,7 +913,7 @@ err:
   u32 peer_port = port_peerport(p_ptr);
   u32 peer_node = port_peernode(p_ptr);
 
 - spin_unlock_bh(p_ptr-publ.lock);
 + tipc_port_unlock(p_ptr);
   if (!connected || !cb)
   break;
   if (msg_origport(msg) != peer_port)
 @@ -929,7 +929,7 @@ err:
   case TIPC_DIRECT_MSG:{
   tipc_msg_err_event cb = up_ptr-err_cb;
 
 - spin_unlock_bh(p_ptr-publ.lock);
 + tipc_port_unlock(p_ptr);
   if (connected || !cb)
   break;
   skb_pull(buf, msg_hdr_sz(msg));
 @@ -942,7 +942,7 @@ err:
   tipc_named_msg_err_event cb =
   up_ptr-named_err_cb;
 
 - spin_unlock_bh(p_ptr-publ.lock);
 + tipc_port_unlock(p_ptr);
   if (connected || !cb)
   break;
   dseq.type =  msg_nametype(msg);
 @@ -1107,7 +1107,7 @@ int tipc_portimportance(u32
 ref, unsigne
   if (!p_ptr)
   return -EINVAL;
   *importance = (unsigned
 int)msg_importance(p_ptr-publ.phdr);
 - spin_unlock_bh(p_ptr-publ.lock);
 + tipc_port_unlock(p_ptr);
   return TIPC_OK;
  }
 
 @@ -1122,7 +1122,7 @@ int
 tipc_set_portimportance(u32 ref, uns
   if (!p_ptr)
   return -EINVAL;
   msg_set_importance(p_ptr-publ.phdr, (u32)imp);
 - spin_unlock_bh(p_ptr-publ.lock);
 + tipc_port_unlock(p_ptr);
   return TIPC_OK;
  }
 
 

-
 This SF.net email is sponsored by: Microsoft
 Defy all challenges. Microsoft(R) Visual Studio
 2005.

http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/

Re: [tipc-discussion] pytipc - A TIPC module for Python

2007-12-17 Thread Jon Paul Maloy


I don't know much about Python, but it looks ok
to me, according to your description.

Yo may have noticed that TIPC_ADDR_NAMESEQ
and TIPC_ADDR_MCAST in reality indicates the same
address type, i.e. they have the same value.

Maybe that will simplify your code a little ?

Regards
///jon


Alberto Bertogli wrote:

On Sun, Dec 16, 2007 at 01:20:44PM -0300, Alberto Bertogli wrote:
  

I know there are two more address types (TIPC_ADDR_MCAST and
TIPC_ADDR_ID), but I have never used them, so I don't know the
semantics well enough.



I've added support for those two address types, and an optional fifth
tuple element for the socket scope.

The following patch is an updated version of the previous one containing
these changes.

Thanks a lot,
Alberto

  



From: Alberto Bertogli [EMAIL PROTECTED]
Date: Wed, 5 Dec 2007 18:39:18 -0300
Subject: [PATCH] Make socket support TIPC.

TIPC (http://tipc.sf.net) is an open protocol designed for use in
clustered computer environments. It currently has an open source
implementation for Linux (= 2.6.16), and VxWorks.

This patch adds optional Linux-only support for TIPC in the socket module.
---
 Modules/socketmodule.c |  156 +++-
 Modules/socketmodule.h |4 +
 configure.in   |2 +-
 3 files changed, 160 insertions(+), 2 deletions(-)

diff --git a/Modules/socketmodule.c b/Modules/socketmodule.c
--- a/Modules/socketmodule.c
+++ b/Modules/socketmodule.c
@@ -7,7 +7,8 @@ This module provides an interface to Berkeley socket IPC.
 Limitations:
 
 - Only AF_INET, AF_INET6 and AF_UNIX address families are supported in a

-  portable manner, though AF_PACKET and AF_NETLINK are supported under Linux.
+  portable manner, though AF_PACKET, AF_NETLINK and AF_TIPC are supported
+  under Linux.
 - No read/write operations (use sendall/recv or makefile instead).
 - Additional restrictions apply on some non-Unix platforms (compensated
   for by socket.py).
@@ -52,6 +53,25 @@ Module interface:
   the Ethernet protocol number to be received. For example:
   (eth0,0x1234).  Optional 3rd,4th,5th elements in the tuple
   specify packet-type and ha-type/addr.
+- an AF_TIPC socket address is expressed as
+ (addr_type, v1, v2, v3 [, scope]); where addr_type can be one of:
+   TIPC_ADDR_NAMESEQ, TIPC_ADDR_MCAST, TIPC_ADDR_NAME, and TIPC_ADDR_ID;
+  and scope can be one of:
+   TIPC_ZONE_SCOPE, TIPC_CLUSTER_SCOPE, and TIPC_NODE_SCOPE.
+  The meaning of v1, v2 and v3 depends on the value of addr_type:
+   if addr_type is TIPC_ADDR_NAME:
+   v1 is the server type
+   v2 is the port identifier
+   v3 is ignored
+   if addr_type is TIPC_ADDR_NAMESEQ or TIPC_ADDR_MCAST:
+   v1 is the server type
+   v2 is the lower port number
+   v3 is the upper port number
+   if addr_type is TIPC_ADDR_ID:
+   v1 is the node
+   v2 is the ref
+   v3 is ignored
+
 
 Local naming conventions:
 
@@ -1094,6 +1114,40 @@ makesockaddr(int sockfd, struct sockaddr *addr, int addrlen, int proto)

}
 #endif
 
+#ifdef HAVE_LINUX_TIPC_H

+   case AF_TIPC:
+   {
+   struct sockaddr_tipc *a = (struct sockaddr_tipc *) addr;
+   if (a-addrtype == TIPC_ADDR_NAMESEQ ||
+   a-addrtype == TIPC_ADDR_MCAST) {
+   return Py_BuildValue(I,
+   a-addrtype,
+   a-addr.nameseq.type,
+   a-addr.nameseq.lower,
+   a-addr.nameseq.upper,
+   a-scope);
+   } else if (a-addrtype == TIPC_ADDR_NAME) {
+   return Py_BuildValue(I,
+   a-addrtype,
+   a-addr.name.name.type,
+   a-addr.name.name.instance,
+   a-addr.name.name.instance,
+   a-scope);
+   } else if (a-addrtype == TIPC_ADDR_ID) {
+   return Py_BuildValue(I,
+   a-addrtype,
+   a-addr.id.node,
+   a-addr.id.ref,
+   0,
+   a-scope);
+   } else {
+   PyErr_SetString(PyExc_TypeError,
+   Invalid address type);
+   return NULL;
+   }
+   }
+#endif
+
/* More cases here... */
 
 	default:

@@ -1379,6 +1433,56 @@ getsockaddrarg(PySocketSockObject *s, PyObject *args,
}
 #endif
 
+#ifdef HAVE_LINUX_TIPC_H

+   case

Re: [tipc-discussion] TIPC one-sided link tear-down issue (session ID discussion)

2007-12-05 Thread Jon Paul Maloy

Hi Elmer,
Se my comments/questions below.

///jon


Horvath, Elmer wrote:
 TIPC session ID mismatch and one-sided link tear-down
   

 It may be prudent to put a check on the session ID in the state message
 reception to detect stale session IDs.  Perhaps just drop offending
 messages and the link will eventually go down.  I would hesitate to
 recommend dropping a link if the session ID is wrong in case an old (or
 malformed) packet happened to be received.
   
Yes, we should drop such messages, just to fulfill the protocol. It is 
not a
complete solution to the problem, though, because on-going traffic may
still keep the link up for  a while, either until the traffic becomes so 
low
hat the link supervision mechanism kicks in and resets the link, or until
the other endpoint resets itself because of too many failed retransmission
attempts. (The sequence numbers will not match).

But what really puzzles me is how this can occur in the first place.
If you have a look at the state diagram for link activation below, and  
the 
corresponding  text (pasted in from the tipc-protocol draft), you will 
see that a
link endpoint can never ever come back to  WORKING_WORKING after
a reset without having a confirmation that the other endpoint has also been
reset, i.e. having  received either a RESET or an ACTIVATE message
from the other end.

This is the state machine we have been using for many years, and I have
had reason  to come back to it on many occasions, only to confirm each time
that it really is  water-proof. I have not heard of any problem like the 
one
you describe earlier.

I can only see two possible explanations for this: Either the code 
doesn't match
the state machine (a bug somewhere), or a stray RESET or ACTIVATE is
received from the other end (or somewhere else?) despite that the link is
up and running.  I have seen the latter happen, once I was using a switch
that was sometimes delivering packets completely out of order, with several
seconds  of delay. (This was the initial reason for introducing the 
session id.)
But this can only happen if the link has been recently started or reset, 
as far
as I can see.

Is the latter a possibility? How long has the link been up when this occurs?
Are you using a switch with any known issues? Have you seen this on Linux
too, or only on VxWorks?

Pasted in: 


  2.6.2. Link Activation

Link activation and supervision is completely handled by the generic 
part of the protocol, in contrast to the partially media-dependent 
neighbour detection protocol.

The following FSM describes how a link is activated and supervised.




  ---   ---
 |   |--(CHECKPOINT == LAST_REC)--|   |
 |   | |   |
 |Working-Unknown|TRAFFIC/ACTIVATE_MSG|Working-Working|
 |   | |   |
 |   |---+  +-ACTIVATE_MSG|   |
  --- \/A--
 | \  /   | |
 | NO TRAFFIC/  \/ RESET_MSG  TRAFFIC/
 | NO PROBE /\|  ACTIVATE_MSG
 | REPLY   /  \   | |
  ---V--- /\--V
 |   |---+  +--RESET_MSG--|   |
 |   | |   |
 | Reset-Unknown | |  Reset-Reset  |
 |   |--RESET_MSG-|   |
 |   | |   |
  -A-   ---
   |   |
   | BLOCK/| UNBLOCK/
   | CHANGEOVER| CHANGEOVER END
   | ORIG_MSG  |
  -V-
 |   |
 |   |
 |Blocked|
 |   |
 |   |
  ---


* Figure 20: Link finite state machine *



A link enpoint's state is defined by the own endpoint's state, combined 
with what is known about the other endpoint's state. The following 
states exist:

Reset-Unknown

Own link endpoint reset, i.e. queues are emptied and sequence
numbers are set back to their initial values. The state of the peer
endpoint is unknown. LINK_PROTOCOL/RESET_MSG messages are sent
periodically at CONTINUITY_INTERVAL to inform peer about the own
endpoint's state, and to force it to reset its own enpoint,if this
has not already been done. If the peer endpoint is rebooting, or has
reset for some other reason, it will sooner or later also reach the
state Reset-Unknown, and start sending its own RESET_MSG messages
periodically. At least one of the endpoints, and often both, will

Re: [tipc-discussion] TIPC on Solaris

2007-11-26 Thread Jon Paul Maloy

Hi Laurent,
This is good news, and would be much appreciated.  The CVS repository at SF
has not been used for a long time. After the inclusion in the Linux 
kernel, we
decided to make the GIT tree at kernel.org the main repository.
I your case I think a .tar file is necessary, since it is so much easier 
for people
to download. About whether to use CVS or not, I assume that depends on
if you want/expect others to contribute to the code or not. 

Regards
///jon

[EMAIL PROTECTED] wrote:
 Hi Allan and Koushik,

 I'm working at Sun Microsystems on a project for which TIPC on Solaris 
 would be very interesting.
 If there is no port on-going, I propose to start doing the port.

 It is not an easy task, but there is a new project in OpenSolaris ( 
 http://www.opensolaris.org/os/project/volo/ ) that will
 provide a pluggable socket framework to ease the job of implementing 
 Solaris kernel modules defining new socket families.

 So to ease the task, I was planning to first do the port on OpenSolaris 
 using this new pluggable socket framework.
 And when this is done, I will go on with the port on Solaris 10.

 Hoping to get something in three months from now, if you agree I would 
 be glad to provide it to this sourceforge project.

 Would you prefer to get it as a tar file or as a subtree in the CVS 
 repository ?
 I downloaded the TIPC 1.7.5 tar and had a look to the CVS repository but 
 I didn't find a subtree with the latest version.

 Thanks



 Stephens, Allan wrote:
   
 Hi Koushik:
  
 I think the answer to your questions are no and no.  It's 
 clearly something that could be done, but no one has expressed an 
 interest in doing it so far.
  
 -- Al
  

 
 *From:* [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] *On Behalf
 Of *Koushik Ghosh
 *Sent:* Monday, November 26, 2007 5:03 AM
 *To:* tipc-discussion@lists.sourceforge.net
 *Subject:* [tipc-discussion] TIPC on Solaris

 Hi Guys,

 I want to know if TIPC is available on Solaris. Or if there is any
 work going on making TIPC available on Solaris.

 Thanks for your help.

 Koushik.

 

 -
 This SF.net email is sponsored by: Microsoft
 Defy all challenges. Microsoft(R) Visual Studio 2005.
 http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
   
 

 ___
 tipc-discussion mailing list
 tipc-discussion@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/tipc-discussion
   
 


 -
 This SF.net email is sponsored by: Microsoft
 Defy all challenges. Microsoft(R) Visual Studio 2005.
 http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
 ___
 tipc-discussion mailing list
 tipc-discussion@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/tipc-discussion
   


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion

Re: [tipc-discussion] TIPC Virtualization

2007-10-22 Thread Jon Paul Maloy

Hi,
Very interesting work. I will give it a try as soon as I find some time.

Regards
///jon


Randy Macleod wrote:
   Hi!

 Ravi Rao wrote:
 As you may remember, I've been working with Randy MacLeod on 
 virtualizing TIPC so that two TIPC stacks can be run on a cluster, 
 where each node has a separate connection to a control plane LAN and 
 a data plane LAN.
 ...
 P.S. the patches,demo programs and readme files will be sent by Randy 
 in a later mail..

 See attached. It's big because it include the original
 tipc-1.5.12.tar.gz file.

  tar tjvf /tmp/vtipc_package_201020070041.bz2
 drwxr-x---   0  vtipc_package_201020070041/
 -rw-r-  141224  vtipc_package_201020070041/
 tipc-1.5.12.tar.bz2
 -rw-r-   21278  vtipc_package_201020070041/
 vtipc-1.5.12_191020072304.patch
 -rwxr-x---4084  vtipc_package_201020070041/snr
 -rw-r-   17183 vtipc_package_201020070041/
 tipc-1.5.12_191020072304.patch


 To build:
 Extract the tarball. tar xjvf /tmp/vtipc_package_201020070041.bz2
 cd vtipc_package_201020070041/
 run the snr script. ./snr
 then build the tipc  vtipc packages as usual.

 When done you'll have tipc.ko  vtipc.ko
 sudo insmod tipc.ko
 sudo insmod vtipc.ko

 The tipc-config in the tipc dir has been patched
 to take the extra -P=[01] paramter to talk to tipc/vtipc
 respectively. You can do tests in single node mode as usual.

 BUT
 The bad news...

 It works on 2.6.10/ppc64 where Ravi has been doing development.
 There are some issues with x86 loading that Ravi and I are trying to
 iron out. It compiles, tipc loads but vtipc runs into some trouble.
 We'll post a new version when we've fixed these problems hopefully
 on Monday.

 I don't have the demo programs packaged up but if your keen,
 you just have to change socket(x,y,0) to socket(x,y,1)
 and everything will work.

 Let us know what you think.

 Have fun,
 // Randy
 

 -
 This SF.net email is sponsored by: Splunk Inc.
 Still grepping through log files to find problems?  Stop.
 Now Search log events and configuration files using AJAX and a browser.
 Download your FREE copy of Splunk now  http://get.splunk.com/
 

 ___
 tipc-discussion mailing list
 tipc-discussion@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/tipc-discussion


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion

[tipc-discussion] A couple of issues

2007-10-05 Thread Jon Paul Maloy

Hi Allan,
At the last meeting I mentioned that we here at Ericsson had seen some
issues with TIPC when  using the native interface, combined with using
dual links between nodes.

First discovery:
---
Access of a specific port via the native interface is non-
re-entrant. The reason for this is that the header for each message is 
cached in
the port structure, which is unprotected from parallel access. (With the 
socket interface
this is no problem, because the port is implicitly protected by sock_lock).
Scenario: CPU A is sending a  connectionless message. The header is 
constructed
in the corresponding port structure, before being copied into the allocated
sk_buff in the call msg_build().
In parallel, CPU B is also sending a message, to a different 
destination. Before A's
header has been copied to the send buffer, it is modified by B. The 
result that
we may have an sk_buff in the send queue to one node, with destination 
address
to another node. Of course destination port, message length and possibly 
even other
header fields may be wrong. We saw this happen several times.

I see three remedies for this: b) We add an extra lock, to protect each 
port. This would
give the penalty of having a redundant lock when accessing via the 
socket interface.
b) We build the header on the stack, at least for connectionless 
messages. For
connection-oriented messages the header will not change, except for 
message packet
length. If we make sure to write packet length directly into the 
sk_buff, just as we do with
sequence numbers and other link-layer fields, we can possibly keep the 
header cache
for this type of messages. (This needs to be analyzed further).
c) We don't change anything. We just make it clear in the Programmers 
Guide, and in
comments in the header file, that these functions are *not* re-entrant, 
and must be
protected by a user-provided lock.

I would prefer solution b), if my assumption about connection-oriented 
headers holds.

Second Discovery:
-
When running parallel links between two nodes, a race condition occurs 
between the
discovery procedures of the two bearers.
Scenario: A discovery message from node A comes in on bearer 1. In
tipc_disc_recv_msg(), we check if there already is an allocated 
structure for
node A, and if not, we create one.
In parallel, a discovery message from node A also comes in on bearer 2. 
The same check is
done, after bearer 1 did the test, but before the node structure is 
actually allocated and added
to the net structure.
This is possible because we only read-lock net_lock when a packet 
arrive in tipc_recv_msg.
Unfortunately, we actually *do* change the net structure here, so this 
is clearly wrong, and
results in a nasty crash later on.
The work-around we used was to add a local spin_lock around these lines 
of the code, but
this does not feel completely satisfactory. Any suggestions here?


Regards
///jon

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion

[tipc-discussion] [PATCH 2/3] [TIPC]: Use standard socket not implemented routines

2007-05-17 Thread Jon Paul Maloy

This patch modifies TIPC's socket API to utilize existing
generic routines to indicate unsupported operations, rather
than adding similar TIPC-specific routines.

Signed-off-by: Allan Stephens [EMAIL PROTECTED]
Signed-off-by: Jon Paul Maloy [EMAIL PROTECTED]
---
 net/tipc/socket.c |   55 +---
 1 files changed, 14 insertions(+), 41 deletions(-)

diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 45832fb..ac7f2aa 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -1,8 +1,8 @@
 /*
  * net/tipc/socket.c: TIPC socket API
  *
- * Copyright (c) 2001-2006, Ericsson AB
- * Copyright (c) 2004-2006, Wind River Systems
+ * Copyright (c) 2001-2007, Ericsson AB
+ * Copyright (c) 2004-2007, Wind River Systems
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -1600,33 +1600,6 @@ static int getsockopt(struct socket *sock,
 }
 
 /**
- * Placeholders for non-implemented functionality
- *
- * Returns error code (POSIX-compliant where defined)
- */
-
-static int ioctl(struct socket *s, u32 cmd, unsigned long arg)
-{
-   return -EINVAL;
-}
-
-static int no_mmap(struct file *file, struct socket *sock,
-  struct vm_area_struct *vma)
-{
-   return -EINVAL;
-}
-static ssize_t no_sendpage(struct socket *sock, struct page *page,
-  int offset, size_t size, int flags)
-{
-   return -EINVAL;
-}
-
-static int no_skpair(struct socket *s1, struct socket *s2)
-{
-   return -EOPNOTSUPP;
-}
-
-/**
  * Protocol switches for the various types of TIPC sockets
  */
 
@@ -1636,19 +1609,19 @@ static struct proto_ops msg_ops = {
.release= release,
.bind   = bind,
.connect= connect,
-   .socketpair = no_skpair,
+   .socketpair = sock_no_socketpair,
.accept = accept,
.getname= get_name,
.poll   = poll,
-   .ioctl  = ioctl,
+   .ioctl  = sock_no_ioctl,
.listen = listen,
.shutdown   = shutdown,
.setsockopt = setsockopt,
.getsockopt = getsockopt,
.sendmsg= send_msg,
.recvmsg= recv_msg,
-   .mmap   = no_mmap,
-   .sendpage   = no_sendpage
+.mmap  = sock_no_mmap,
+.sendpage  = sock_no_sendpage
 };
 
 static struct proto_ops packet_ops = {
@@ -1657,19 +1630,19 @@ static struct proto_ops packet_ops = {
.release= release,
.bind   = bind,
.connect= connect,
-   .socketpair = no_skpair,
+   .socketpair = sock_no_socketpair,
.accept = accept,
.getname= get_name,
.poll   = poll,
-   .ioctl  = ioctl,
+   .ioctl  = sock_no_ioctl,
.listen = listen,
.shutdown   = shutdown,
.setsockopt = setsockopt,
.getsockopt = getsockopt,
.sendmsg= send_packet,
.recvmsg= recv_msg,
-   .mmap   = no_mmap,
-   .sendpage   = no_sendpage
+.mmap  = sock_no_mmap,
+.sendpage  = sock_no_sendpage
 };
 
 static struct proto_ops stream_ops = {
@@ -1678,19 +1651,19 @@ static struct proto_ops stream_ops = {
.release= release,
.bind   = bind,
.connect= connect,
-   .socketpair = no_skpair,
+   .socketpair = sock_no_socketpair,
.accept = accept,
.getname= get_name,
.poll   = poll,
-   .ioctl  = ioctl,
+   .ioctl  = sock_no_ioctl,
.listen = listen,
.shutdown   = shutdown,
.setsockopt = setsockopt,
.getsockopt = getsockopt,
.sendmsg= send_stream,
.recvmsg= recv_stream,
-   .mmap   = no_mmap,
-   .sendpage   = no_sendpage
+.mmap  = sock_no_mmap,
+.sendpage  = sock_no_sendpage
 };
 
 static struct net_proto_family tipc_family_ops = {
-- 
1.5.0.5


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion

[tipc-discussion] [PATCH 1/3] [TIPC]: Improved support for Ethernet traffic filtering

2007-05-17 Thread Jon Paul Maloy

This patch simplifies TIPC's Ethernet receive routine to take
advantage of information already present in each incoming sk_buff
indicating whether the packet was explicitly sent to the interface,
has been broadcast to all interfaces, or was picked up because the
interface is in promiscous mode.

This new approach also fixes the problem of TIPC accepting unwanted
traffic through UML's multicast-based Ethernet interfaces (which
deliver traffic in a promiscuous manner even if the interface is
not configured to be promiscuous).

Signed-off-by: Allan Stephens [EMAIL PROTECTED]
Signed-off-by: Jon Paul Maloy [EMAIL PROTECTED]
---
 net/tipc/eth_media.c |   11 ++-
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/net/tipc/eth_media.c b/net/tipc/eth_media.c
index c73c206..19a71cf 100644
--- a/net/tipc/eth_media.c
+++ b/net/tipc/eth_media.c
@@ -1,8 +1,8 @@
 /*
  * net/tipc/eth_media.c: Ethernet bearer support for TIPC
  *
- * Copyright (c) 2001-2006, Ericsson AB
- * Copyright (c) 2005-2006, Wind River Systems
+ * Copyright (c) 2001-2007, Ericsson AB
+ * Copyright (c) 2005-2007, Wind River Systems
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -87,6 +87,9 @@ static int send_msg(struct sk_buff *buf, struct tipc_bearer 
*tb_ptr,
 /**
  * recv_msg - handle incoming TIPC message from an Ethernet interface
  *
+ * Accept only packets explicitly sent to this node, or broadcast packets;
+ * ignores packets sent using Ethernet multicast, and traffic sent to other
+ * nodes (which can happen if interface is running in promiscuous mode).
  * Routine truncates any Ethernet padding/CRC appended to the message,
  * and ensures message size matches actual length
  */
@@ -98,9 +101,7 @@ static int recv_msg(struct sk_buff *buf, struct net_device 
*dev,
u32 size;
 
if (likely(eb_ptr-bearer)) {
-  if (likely(!dev-promiscuity) ||
-  !memcmp(skb_mac_header(buf), dev-dev_addr, ETH_ALEN) ||
-  !memcmp(skb_mac_header(buf), dev-broadcast, ETH_ALEN)) {
+   if (likely(buf-pkt_type = PACKET_BROADCAST)) {
size = msg_size((struct tipc_msg *)buf-data);
skb_trim(buf, size);
if (likely(buf-len == size)) {
-- 
1.5.0.5


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion

Re: [tipc-discussion] 3 Patches for TIPC 1.6

2007-05-15 Thread Jon Paul Maloy

Acknowledged.
///jon

Stephens, Allan wrote:
 Hi Jon:

 Attached you will find 3 more patches for submission to the TIPC 1.6
 stream.  They were generated from the master TIPC repository, which is
 currently updated to Linux 2.6.21.

 Please review, validate, and pass on to David Miller.

 Regards,
 Al

   
 

 From nobody Mon Sep 17 00:00:00 2001
 From: Allan Stephens [EMAIL PROTECTED]
 Date: Tue, 15 May 2007 10:34:15 -0400
 Subject: [PATCH] [TIPC]: Optimize stream send routine to avoid fragmentation

 This patch enhances TIPC's stream socket send routine so that
 it avoids transmitting data in chunks that require fragmentation
 and reassembly, thereby improving performance at both the
 sending and receiving ends of the connection.

 The maximum packet size hint that records MTU info allows
 the socket to decide how big a chunk it should send; in the
 event that the hint has become stale, fragmentation may still
 occur, but the data will be passed correctly and the hint will
 be updated in time for the following send.  Note: The 66060 byte
 pseudo-MTU used for intra-node connections requires the send
 routine to perform an additional check to ensure it does not
 exceed TIPCs limit of 66000 bytes of user data per chunk.

 Signed-off-by: Allan Stephens [EMAIL PROTECTED]

 ---

  include/net/tipc/tipc_port.h |2 ++
  net/tipc/link.c  |   12 ++--
  net/tipc/port.c  |6 +++---
  net/tipc/port.h  |2 --
  net/tipc/socket.c|   25 +
  5 files changed, 28 insertions(+), 19 deletions(-)

 ab11d4a37b305486fbc380386990cde6b4c225a2
 diff --git a/include/net/tipc/tipc_port.h b/include/net/tipc/tipc_port.h
 index 333bba6..5e5e67f 100644
 --- a/include/net/tipc/tipc_port.h
 +++ b/include/net/tipc/tipc_port.h
 @@ -55,6 +55,7 @@ #define TIPC_FLOW_CONTROL_WIN 512
   * @conn_unacked: number of unacknowledged messages received from peer port
   * @published: non-zero if port has one or more associated names
   * @congested: non-zero if cannot send because of link or port congestion
 + * @max_pkt: maximum packet size hint used when building messages sent by 
 port
   * @ref: unique reference to port in TIPC object registry
   * @phdr: preformatted message header used when sending messages
   */
 @@ -68,6 +69,7 @@ struct tipc_port {
   u32 conn_unacked;
   int published;
   u32 congested;
 + u32 max_pkt;
   u32 ref;
   struct tipc_msg phdr;
  };
 diff --git a/net/tipc/link.c b/net/tipc/link.c
 index 2124f32..1f731f3 100644
 --- a/net/tipc/link.c
 +++ b/net/tipc/link.c
 @@ -1260,7 +1260,7 @@ again:
* (Must not hold any locks while building message.)
*/
  
 - res = msg_build(hdr, msg_sect, num_sect, sender-max_pkt,
 + res = msg_build(hdr, msg_sect, num_sect, sender-publ.max_pkt,
   !sender-user_port, buf);
  
   read_lock_bh(tipc_net_lock);
 @@ -1271,7 +1271,7 @@ again:
   if (likely(l_ptr)) {
   if (likely(buf)) {
   res = link_send_buf_fast(l_ptr, buf,
 -  sender-max_pkt);
 +  sender-publ.max_pkt);
   if (unlikely(res  0))
   buf_discard(buf);
  exit:
 @@ -1299,12 +1299,12 @@ exit:
* then re-try fast path or fragment the message
*/
  
 - sender-max_pkt = link_max_pkt(l_ptr);
 + sender-publ.max_pkt = link_max_pkt(l_ptr);
   tipc_node_unlock(node);
   read_unlock_bh(tipc_net_lock);
  
  
 - if ((msg_hdr_sz(hdr) + res) = sender-max_pkt)
 + if ((msg_hdr_sz(hdr) + res) = sender-publ.max_pkt)
   goto again;
  
   return link_send_sections_long(sender, msg_sect,
 @@ -1357,7 +1357,7 @@ static int link_send_sections_long(struc
  
  again:
   fragm_no = 1;
 - max_pkt = sender-max_pkt - INT_H_SIZE;
 + max_pkt = sender-publ.max_pkt - INT_H_SIZE;
   /* leave room for tunnel header in case of link changeover */
   fragm_sz = max_pkt - INT_H_SIZE;
   /* leave room for fragmentation header in each fragment */
 @@ -1463,7 +1463,7 @@ error:
   goto reject;
   }
   if (link_max_pkt(l_ptr)  max_pkt) {
 - sender-max_pkt = link_max_pkt(l_ptr);
 + sender-publ.max_pkt = link_max_pkt(l_ptr);
   tipc_node_unlock(node);
   for (; buf_chain; buf_chain = buf) {
   buf = buf_chain-next;
 diff --git a/net/tipc/port.c b/net/tipc/port.c
 index bcd5da0..01481af 100644
 --- a/net/tipc/port.c
 +++

Re: [tipc-discussion] [PATCH] tipc: add back tipc prefix to log messages

[tipc-discussion] Tr : RE : Link retransmission implementation

[tipc-discussion] RE : /net/tipc/port.c: Use tipc_port_unlock

Re: [tipc-discussion] pytipc - A TIPC module for Python

Re: [tipc-discussion] TIPC one-sided link tear-down issue (session ID discussion)

Re: [tipc-discussion] TIPC on Solaris

Re: [tipc-discussion] TIPC Virtualization

[tipc-discussion] A couple of issues

[tipc-discussion] [PATCH 2/3] [TIPC]: Use standard socket not implemented routines

[tipc-discussion] [PATCH 1/3] [TIPC]: Improved support for Ethernet traffic filtering

Re: [tipc-discussion] 3 Patches for TIPC 1.6

11 matches

Site Navigation

Mail list logo

Footer information