Jon Maloy | 15 Jul 12:23 2014
Picon

[PATCH net-next v7 0/7] tipc: multicast and internal users to new send functions

We move the remaining data transmit users: multicast, name table
distributor, and link internal protocols to use the new data
transmission framework introduced in a previous commit series
("tipc: new unicast transmission code").

Finally, we remove the code obsoleted by the new functions.

v2: Major changes to commits #3 and 4:
    - #3: bcast_xmit2() takes no parameter "local" and "remote" anymore.
      Instead, it unconditionally sends a cloned copy of the message to
      the receive function in the socket before, also unconditionally,
      sending it out on the broadcast link.
    - Renamed the clone+reassemly function in msg.c to 
      tipc_msg_reassemble().
    - #4:  Removed the initial lookup at the send side of a multicast.
      The lookup is now made only in one place, in tipc_sk_mcast_rcv().
    - I discovered that the current code violates the spec by completely
      ignoring the 'lookup scope' given to the message by the sender, and
      replacing it with hard-coded values. This is unfortunate, but
      I dare not change this now, so we will have to live with it.
    - Fixed two problems reported by Ying: a potential small memory leak,
      and a send failure due to a wrong return value from the multicast
      send function.

v3: - Fixed a typo in commit #v3/3 discovered by Ying.
    - Added a new commit #1, fixing a very serious bug in broadcast msg
      reassmbly. This is the same as the one David applied to 'net' a
      few days ago.
    - Added a new commit #2, fixing a problem that the last of a
      reassembled buffer chain may have a non-NULL next pointer.
(Continue reading)

Jon Maloy | 15 Jul 04:45 2014
Picon

[PATCH net-next v6 0/9] tipc: multicast and internal users to new send functions

In the two first commits, we fix a couple of bugs in tipc_buf_append()
that have impact on multicast/broadcast reasembly. Commit #1 has already
been applied to 'net', but we need it in 'net-next too, for the rest of
this series to work properly

We then move the remaining data transmit users: multicast, name table
distributor, and link internal protocols to use the new data
transmission framework.

Finally, we clean up the code obsoleted by the new functions.

v2: Major changes to commits #3 and 4:
    - #3: bcast_xmit2() takes no parameter "local" and "remote" anymore.
      Instead, it unconditionally sends a cloned copy of the message to
      the receive function in the socket before, also unconditionally,
      sending it out on the broadcast link.
    - Renamed the clone+reassemly function in msg.c to 
      tipc_msg_reassemble().
    - #4:  Removed the initial lookup at the send side of a multicast.
      The lookup is now made only in one place, in tipc_sk_mcast_rcv().
    - I discovered that the current code violates the spec by completely
      ignoring the 'lookup scope' given to the message by the sender, and
      replacing it with hard-coded values. This is unfortunate, but
      I dare not change this now, so we will have to live with it.
    - Fixed two problems reported by Ying: a potential small memory leak,
      and a send failure due to a wrong return value from the multicast
      send function.

v3: - Fixed a typo in commit #v3/3 discovered by Ying.
    - Added a new commit #1, fixing a very serious bug in broadcast msg
(Continue reading)

Jon Maloy | 14 Jul 04:31 2014
Picon

[PATCH net-next v5 0/9] tipc: multicast and internal users to new send functions


In the two first commits, we fix a couple of bugs in tipc_buf_append()
that have impact on multicast/broadcast reasembly. Commit #1 has already
been applied to 'net', but we need it in 'net-next too, for the rest of
this series to work properly

We then move the remaining data transmit users: multicast, name table
distributor, and link internal protocols to use the new data
transmission framework.

Finally, we clean up the code obsoleted by the new functions.

v2: Major changes to commits #3 and 4:
    - #3: bcast_xmit2() takes no parameter "local" and "remote" anymore.
      Instead, it unconditionally sends a cloned copy of the message to
      the receive function in the socket before, also unconditionally,
      sending it out on the broadcast link.
    - Renamed the clone+reassemly function in msg.c to 
      tipc_msg_reassemble().
    - #4:  Removed the initial lookup at the send side of a multicast.
      The lookup is now made only in one place, in tipc_sk_mcast_rcv().
    - I discovered that the current code violates the spec by completely
      ignoring the 'lookup scope' given to the message by the sender, and
      replacing it with hard-coded values. This is unfortunate, but
      I dare not change this now, so we will have to live with it.
    - Fixed two problems reported by Ying: a potential small memory leak,
      and a send failure due to a wrong return value from the multicast
      send function.

v3: - Fixed a typo in commit #v3/3 discovered by Ying.
(Continue reading)

Jon Maloy | 14 Jul 04:03 2014
Picon

[PATCH net-next v4 0/8] tipc: multicast and internal users to new send functions

In the two first commits, we fix a couple of bugs in tipc_buf_append()
that have impact on multicast/broadcast reasembly. Commit #1 has already
been applied to 'net', but we need it in 'net-next too, for the rest of
this series to work properly

We then move the remaining data transmit users: multicast, name table
distributor, and link internal protocols to use the new data
transmission framework.

Finally, we clean up the code obsoleted by the new functions.

v2: Major changes to commits #3 and 4:
    - #3: bcast_xmit2() takes no parameter "local" and "remote" anymore.
      Instead, it unconditionally sends a cloned copy of the message to
      the receive function in the socket before, also unconditionally,
      sending it out on the broadcast link.
    - Renamed the clone+reassemly function in msg.c to 
      tipc_msg_reassemble().
    - #4:  Removed the initial lookup at the send side of a multicast.
      The lookup is now made only in one place, in tipc_sk_mcast_rcv().
    - I discovered that the current code violates the spec by completely
      ignoring the 'lookup scope' given to the message by the sender, and
      replacing it with hard-coded values. This is unfortunate, but
      I dare not change this now, so we will have to live with it.
    - Fixed two problems reported by Ying: a potential small memory leak,
      and a send failure due to a wrong return value from the multicast
      send function.

v3: - Fixed a typo in commit #v3/3 discovered by Ying.
    - Added a new commit #1, fixing a very serious bug in broadcast msg
(Continue reading)

Jon Maloy | 11 Jul 03:20 2014
Picon

[PATCH net-next v3 0/8] tipc: multicast and internal users to new send functions

In the two first commits, we fix a couple of bugs in tipc_buf_append()
that have impact on multicast/broadcast reassembly. Commit #1 has already
been applied to 'net', but we need it in 'net-next' too, for the rest of
this series to work properly

We then move the remaining data transmit users: multicast, name table
distributor, and link internal protocols to use the new data
transmission framework introduced in a recent commit series.

Finally, we clean up the code obsoleted by the new functions.

v2: Major changes to commits #3 and 4:
    - #3: bcast_xmit2() takes no parameter "local" and "remote" anymore.
      Instead, it unconditionally sends a cloned copy of the message to
      the receive function in the socket before, also unconditionally,
      sending it out on the broadcast link.
    - Renamed the clone+reassemly function in msg.c to 
      tipc_msg_reassemble().
    - #4:  Removed the initial lookup at the send side of a multicast.
      The lookup is now made only in one place, in tipc_sk_mcast_rcv().
    - I discovered that the current code violates the spec by completely
      ignoring the 'lookup scope' given to the message by the sender, and
      replacing it with hard-coded values. This is unfortunate, but
      I dare not change this now, so we will have to live with it.
    - Fixed two problems reported by Ying: a potential small memory leak,
      and a send failure due to a wrong return value from the multicast
      send function.

v3: - Fixed a typo in commit #v3/3 discovered by Ying.
    - Added a new commit #1, fixing a very serious bug in broadcast msg
(Continue reading)

Jon Maloy | 8 Jul 20:07 2014
Picon

[PATCH net-next v2 0/6] tipc: multicast and internal users to new send functions

In this series, we move the remaining data transmit users: multicast
data users, the name table distributor, and the link internal protocols
to use the new data transmission framework.

We also clean up the code obsoleted by the new functions.

v2: Major changes to commits #3 and 4:
    - #3: bcast_xmit2() takes no parameter "local" and "remote" anymore.
      Instead, it unconditionally sends a cloned copy of the message to
      the receive function in the socket before, also unconditionally,
      sending it out on the broadcast link.
    - Renamed the clone+reassemly function in msg.c to 
      tipc_msg_reassemble().
    - #4:  Removed the initial lookup at the send side of a multicast.
      The lookup is now made only in one place, in tipc_sk_mcast_rcv().
    - I discovered that the current code violates the spec by completely
      ignoring the 'lookup scope' given to the message by the sender, and
      replacing it with hard-coded values. This is unfortunate, but
      I dare not change this now, so we will have to live with it.
    - Fixed two problems reported by Ying: a potential small memory leak,
      and a send failure due to a wrong return value from the multicast
      send function.

Jon Maloy (6):
  tipc: tipc: make name table distributor use new send function
  tipc: let internal link users call the new link send function
  tipc: add new functions for multicast and broadcast distribution
  tipc: start using the new multicast functions
  tipc: remove unreferenced functions
  tipc: rename temporarily named functions
(Continue reading)

Jon Maloy | 4 Jul 02:17 2014
Picon

[PATCH net-next 0/6] tipc: multicast and internal users to new send functions

In this series, we move the remaining data transmit users: multicast
data users, the name table distributor, and the link internal protocols
to use the new data transmission framework.

We also clean up the code obsoleted by the new functions.

Jon Maloy (6):
  tipc: tipc: make name table distributor use new send function
  tipc: let internal link users call the new link send function
  tipc: add new functions for multicast and broadcast distribution
  tipc: start using the new multicast functions
  tipc: remove unreferenced functions
  tipc: rename temporarily named functions

 net/tipc/bcast.c      |   60 ++++++----
 net/tipc/bcast.h      |    5 +-
 net/tipc/link.c       |  307 ++-----------------------------------------------
 net/tipc/link.h       |    9 +-
 net/tipc/msg.c        |   78 +++++++------
 net/tipc/msg.h        |    9 +-
 net/tipc/name_distr.c |   76 ++++++------
 net/tipc/name_distr.h |    2 +-
 net/tipc/name_table.c |   34 ++++++
 net/tipc/name_table.h |    2 +
 net/tipc/node.c       |   13 +--
 net/tipc/port.c       |  122 +-------------------
 net/tipc/port.h       |   10 --
 net/tipc/socket.c     |   93 +++++++++++----
 net/tipc/socket.h     |    2 +
 15 files changed, 259 insertions(+), 563 deletions(-)
(Continue reading)

erik.hugne | 2 Jul 14:06 2014
Picon

[PATCH v2] tipc: fix a memleak when sending data

From: Erik Hugne <erik.hugne <at> ericsson.com>

This fixes a regression bug caused by:
067608e9d019d6477fd45dd948e81af0e5bf599f ("tipc: introduce direct
iovec to buffer chain fragmentation function")

If data is sent on a nonblocking socket and the destination link
is congested, the buffer chain is leaked. We fix this by freeing
the chain in this case.

Signed-off-by: Erik Hugne <erik.hugne <at> ericsson.com>
---
 net/tipc/socket.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index ede78b1..8c5600c 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
 <at>  <at>  -784,8 +784,9  <at>  <at>  new_mtu:
 			break;

 		rc = tipc_wait_for_sndmsg(sock, &timeo);
+		if (rc)
+			kfree_skb_list(buf);
 	} while (!rc);
-
 exit:
 	if (iocb)
 		release_sock(sk);
(Continue reading)

erik.hugne | 1 Jul 15:31 2014
Picon

[PATCH] tipc: fix a memleak when sending data

From: Erik Hugne <erik.hugne <at> ericsson.com>

This fixes a regression bug caused by:
067608e9d019d6477fd45dd948e81af0e5bf599f ("tipc: introduce direct
iovec to buffer chain fragmentation function")

If data is sent on a nonblocking socket and the destination link
is congested, the buffer chain is leaked. We fix this by freeing
the chain in this case.

Signed-off-by: Erik Hugne <erik.hugne <at> ericsson.com>
---
 net/tipc/socket.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index ede78b1..bd8ede0 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
 <at>  <at>  -785,8 +785,9  <at>  <at>  new_mtu:

 		rc = tipc_wait_for_sndmsg(sock, &timeo);
 	} while (!rc);
-
 exit:
+	if (rc == -EAGAIN)
+		kfree_skb_list(buf);
 	if (iocb)
 		release_sock(sk);

(Continue reading)

Aho, Tero | 30 Jun 10:32 2014

Namespace support for running TIPC in LXC

Hello, I'm working on a project that would benefit in having namespace
support for running TIPC inside Linux containers. So far we have been
running TIPC in a host bridge containers can access and that works
for a related group of containers. But if we want to run more than one
group of containers in the same host, we should be able to setup TIPC
properly in each container.

While there are ways to go around this, like running related containers
inside KVM guests and running TIPC there, those are far from perfect as
they take away the container performance gain.

Searching through the mailing list I found a thread started earlier this
year to implement just the namespace support I was planning to start
on. As far as I understood from the conversation, TIPC code is going
through some heavy changes and namespace support would have
to wait for those until it would have a chance to get accepted.

Before starting to experiment on my own (and lazy as I am), I'm quietly
asking if the author of the namespace implementation would want to make
his version somehow available? And if so, is there something to help on?

Regards, Tero

============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
(Continue reading)

erik.hugne | 30 Jun 09:37 2014
Picon

[PATCH v4 0/2] tipc: link state processing improvements

From: Erik Hugne <erik.hugne <at> ericsson.com>

Message delivery is separated from the link state processing, and
we fix a bug in receive-path triggered acks.

v4: rebase and indent fix.

v3: After comments from Ying, renamed the message delivery functions.
instead of the msgtype, tipc_link_prepare_input() returns -EINVAL as nonzero
value if the message was consumed by an internal user (like MSG_FRAGMENTER).
Fixed break; indentation.

v2: After comment from Ying, the message delivery is split into two parts,
first we take care of the message processing that requires node lock
protection in tipc_process_link_msg(), and then the message is delivered
after node lock have been released with tipc_deliver_msg(), locking behavior
should be the same as before.

Erik Hugne (2):
  tipc: refactor message delivery out of tipc_rcv
  tipc: fix link acknowledge logic in receive path

 net/tipc/link.c | 133 ++++++++++++++++++++++++++++++++++++--------------------
 1 file changed, 86 insertions(+), 47 deletions(-)

--

-- 
1.8.3.2

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
(Continue reading)


Gmane