> -----Original Message-----
> From: GUNA [mailto:gbala...@gmail.com]
> Sent: Friday, 29 April, 2016 10:48
> To: Jon Maloy
> Cc: tipc-discussion@lists.sourceforge.net
> Subject: Re: Tipc: name table mismatch between different cards in a system
>
> The two skb_linearize() calls and the update of ‘hdr' fixes are
> already in my load did not solve this issue. The issue remains same
> even after today's ACTIVE state fix (before one of link is STANDBY
> even same priority)
>
> // IO card, note this does not run latest kernel or tipc
> [root@10 ~]# tipc-config -nt |grep 2334480598
> 20012 20012 <1.1.12:2334480598> 2334480599
> cluster
>
> // runs latest kernel on all CPU cards.
> [root@2 ~]# tipc-config -nt |grep 2334480598
> 50009 20012 20012 <1.1.12:2334480598> 2334480598
> cluster
This was easy to reproduce, and actually looks like another presentation
problem.
When I run the "tipc" tool I see the correct value, i.e., key == (portid + 1).
When I run tipc-config (which is deprecated in the new version), I see the
wrong value key == portid for the same publications!
So, your code will probably work correct, but the values presented will be
wrong on the new version and correct on the old one.
I think this is something for Richard Alpe, who wrote the new netlink
compatibility code, to take a look at.
///jon
>
>
> On Thu, Apr 28, 2016 at 8:19 PM, GUNA <gbala...@gmail.com> wrote:
> > Thanks Jon. I already applied this patch on currently running module.
> >
> > On Thursday, April 28, 2016, Jon Maloy <jon.ma...@ericsson.com> wrote:
> >>
> >> Here it is. (This is just pasted into Outlook, so don’t try to apply it)
> >>
> >> If you manually add the two skb_linearize() calls and the update of ‘hdr’
> >> you should be safe.
> >>
> >>
> >>
> >> Good luck!
> >>
> >> ///jon
> >>
> >>
> >>
> >>
> >>
> >> commit c7cad0d6f70cd4ce8644ffe528a4df1cdc2e77f5
> >>
> >> Author: Jon Paul Maloy <jon.ma...@ericsson.com>
> >>
> >> Date: Thu Nov 19 14:30:40 2015 -0500
> >>
> >>
> >>
> >> tipc: move linearization of buffers to generic code
> >>
> >>
> >>
> >> In commit 5cbb28a4bf65c7e4 ("tipc: linearize arriving NAME_DISTR
> >>
> >> and LINK_PROTO buffers") we added linearization of NAME_DISTRIBUTOR,
> >>
> >> LINK_PROTOCOL/RESET and LINK_PROTOCOL/ACTIVATE to the function
> >>
> >> tipc_udp_recv(). The location of the change was selected in order
> >>
> >> to make the commit easily appliable to 'net' and 'stable'.
> >>
> >>
> >>
> >> We now move this linearization to where it should be done, in the
> >>
> >> functions tipc_named_rcv() and tipc_link_proto_rcv() respectively.
> >>
> >>
> >>
> >> Reviewed-by: Ying Xue <ying....@windriver.com>
> >>
> >> Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
> >>
> >> Signed-off-by: David S. Miller <da...@davemloft.net>
> >>
> >>
> >>
> >> diff --git a/net/tipc/link.c b/net/tipc/link.c
> >>
> >> index 9efbdbd..fa452fb 100644
> >>
> >> --- a/net/tipc/link.c
> >>
> >> +++ b/net/tipc/link.c
> >>
> >> @@ -1260,6 +1260,8 @@ static int tipc_link_proto_rcv(struct tipc_link *l,
> >> struct sk_buff *skb,
> >>
> >> /* fall thru' */
> >>
> >> case ACTIVATE_MSG:
> >>
> >> + skb_linearize(skb);
> >>
> >> + hdr = buf_msg(skb);
> >>
> >> /* Complete own link name with peer's interface name */
> >>
> >> if_name = strrchr(l->name, ':') + 1;
> >>
> >> diff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c
> >>
> >> index c07612b..f51c8bd 100644
> >>
> >> --- a/net/tipc/name_distr.c
> >>
> >> +++ b/net/tipc/name_distr.c
> >>
> >> @@ -397,6 +397,7 @@ void tipc_named_rcv(struct net *net, struct
> >> sk_buff_head *inputq)
> >>
> >> spin_lock_bh(&tn->nametbl_lock);
> >>
> >> for (skb = skb_dequeue(inputq); skb; skb = skb_dequeue(inputq)) {
> >>
> >> + skb_linearize(skb);
> >>
> >> msg = buf_msg(skb);
> >>
> >> mtype = msg_type(msg);
> >>
> >> item = (struct distr_item *)msg_data(msg);
> >>
> >> diff --git a/net/tipc/udp_media.c b/net/tipc/udp_media.c
> >>
> >> index ad2719a..816914e 100644
> >>
> >> --- a/net/tipc/udp_media.c
> >>
> >> +++ b/net/tipc/udp_media.c
> >>
> >> @@ -48,7 +48,6 @@
> >>
> >> #include <linux/tipc_netlink.h>
> >>
> >> #include "core.h"
> >>
> >> #include "bearer.h"
> >>
> >> -#include "msg.h"
> >>
> >> /* IANA assigned UDP port */
> >>
> >> #define UDP_PORT_DEFAULT 6118
> >>
> >> @@ -221,10 +220,6 @@ static int tipc_udp_recv(struct sock *sk, struct
> >> sk_buff *skb)
> >>
> >> {
> >>
> >> struct udp_bearer *ub;
> >>
> >> struct tipc_bearer *b;
> >>
> >> - int usr = msg_user(buf_msg(skb));
> >>
> >> -
> >>
> >> - if ((usr == LINK_PROTOCOL) || (usr == NAME_DISTRIBUTOR))
> >>
> >> - skb_linearize(skb);
> >>
> >> ub = rcu_dereference_sk_user_data(sk);
> >>
> >> if (!ub) {
> >>
> >>
> >>
> >> From: GUNA [mailto:gbala...@gmail.com]
> >> Sent: Thursday, 28 April, 2016 19:24
> >> To: Jon Maloy
> >> Cc: tipc-discussion@lists.sourceforge.net
> >> Subject: Re: Tipc: name table mismatch between different cards in a system
> >>
> >>
> >>
> >> See inline
> >>
> >> On Thursday, April 28, 2016, Jon Maloy <jon.ma...@ericsson.com> wrote:
> >>
> >>
> >>
> >> > -----Original Message-----
> >> > From: GUNA [mailto:gbala...@gmail.com]
> >> > Sent: Thursday, 28 April, 2016 17:43
> >> > To: tipc-discussion@lists.sourceforge.net
> >> > Subject: [tipc-discussion] Tipc: name table mismatch between different
> >> > cards in a
> >> > system
> >> >
> >> > After upgraded CPU cards to 4.4.0 Kernel, there is table mismatch
> >> > between
> >> > CPU and IO cards. The IO Publication value = CPU Publication + 1 as you
> >> > see
> >> > example below:
> >> >
> >> > In CPU (slot 2)
> >> >
> >> > Type Lower Upper Port Identity Publication
> >> >
> >> > 16789314 3201 3201 <1.1.6:1540208445> 1540208445
> >> >
> >> > 16789823 4 4 <1.1.6:3035967304> 3035967304
> >> >
> >> > 16832168 3201 3201 <1.1.6:723652841> 723652841
> >> >
> >> > …
> >> >
> >> >
> >> >
> >> > In IO (slot10)
> >> >
> >> > 16789314 3201 3201 <1.1.6:1540208445> 1540208446
> >> >
> >> > 16789823 4 4 <1.1.6:3035967304> 3035967305
> >> >
> >> > 16832168 3201 3201 <1.1.6:723652841> 723652842
> >> >
> >> > …
> >>
> >> This looks like another artefact of the problem we have in 4.4 with
> >> corrupted entries, where old entries are not withdrawn, so the new ones
> >> cannot replace them in "CPU", while it happens to work in "IO". If 1.1.6
> >> is "IO" or a third node this could make sense.
> >>
> >>
> >>
> >> 1.1.6 is node6 but I see similar for all other nodes as well. Ie: same for
> >> 1.1.2,1.1.3,....1.1.13.
> >>
> >>
> >>
> >>
> >>
> >> This problem has been fixed in Ubuntu 16.04, but has not been released
> >> yet. I would suggest you try 4.5 or 4.6rc4 to see if it disappears.
> >> According to Rune Torgersen it is definitely working in 4.6.
> >>
> >> ///jon
> >>
> >>
> >>
> >> I could not move to new kernel now, but I could rebuild the 4.4.0 if I get
> >> the fix.
> >>
> >> If you are aware of the fix please let me know detail of the fix.
> >>
> >>
> >>
> >> >
> >> >
> >> > All the entries are similar pattern in both IO & CPU. The CPU match with
> >> > rest of the CPUs.
> >> >
> >> >
> >> > The system runs on previous kernel did not see this issue.
> >> >
> >> >
> >> > There are two links on IO and CPU cards. Both links are ACTIVE in IO
> >> > and
> >> > in CPU one ACTIVE and other STANDBY.
> >> >
> >> > Is that cause the issue? If so, is it possible to make both links to be
> >> > ACTIVE ?
> >> >
> >> >
> >> > // IO
> >> >
> >> > Link <1.1.10:eth0-1.1.2:p19p1>
> >> >
> >> > ACTIVE MTU:1500 Priority:10 Tolerance:1200 ms Window:50 packets
> >> >
> >> > Link <1.1.10:eth1-1.1.2:p19p2>
> >> >
> >> > ACTIVE MTU:1500 Priority:10 Tolerance:1200 ms Window:50 packets
> >> >
> >> > // CPU
> >> > Link <1.1.2:p19p1-1.1.10:eth0>
> >> > ACTIVE MTU:1500 Priority:10 Tolerance:1200 ms Window:50 packets
> >> >
> >> > Link <1.1.2:p19p2-1.1.10:eth1>
> >> > STANDBY MTU:1500 Priority:10 Tolerance:1200 ms Window:50 packets
> >> >
> >> > thanks,
> >> >
> >> > Guna
> >> >
> >> > ------------------------------------------------------------------------------
> >> > Find and fix application performance issues faster with Applications
> >> > Manager
> >> > Applications Manager provides deep performance insights into multiple
> >> > tiers of
> >> > your business applications. It resolves application problems quickly and
> >> > reduces your MTTR. Get your free trial!
> >> > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> >> > _______________________________________________
> >> > tipc-discussion mailing list
> >> > tipc-discussion@lists.sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/tipc-discussion
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
