Hi Hoang,
Yes, but the code for collecting data in the stack was different with "native"
tipc-config vs. now, when tipc-config in reality is using the same code as
"tipc" just via the "compat" layer.
Not sure when this changed was done, but probably at the uplift to sp2.
///jon
> -----Original Message-----
> From: Hoang Le <hoang.h...@dektech.com.au>
> Sent: 9-Apr-19 04:14
> To: Jon Maloy <jon.ma...@ericsson.com>; ma...@donjonn.com;
> ying....@windriver.com; tipc-discussion@lists.sourceforge.net
> Subject: RE: [net] tipc: missing entries in name table of publications
>
> Hi Jon,
>
> In my reproduction, I'm seeing the problem either tipc-config.
> I guest almost systems were not using as special service type as my test, then
> all node state service type fit in one skb.
>
> Regards,
> Hoang
> -----Original Message-----
> From: Jon Maloy <jon.ma...@ericsson.com>
> Sent: Tuesday, April 9, 2019 5:39 AM
> To: Hoang Huu Le <hoang.h...@dektech.com.au>; ma...@donjonn.com;
> ying....@windriver.com; tipc-discussion@lists.sourceforge.net
> Subject: RE: [net] tipc: missing entries in name table of publications
>
> Nice job. I am just flabbergasted by the fact that this seems to be a bug that
> has always been around, and still it wasn't seen until now, with all the
> systems with huge name tables we have running around in the world.
> Maybe most people are still using "tipc-config"....
>
> Acked-by: Jon Maloy <jon.ma...@ericsson.com>
>
>
> > -----Original Message-----
> > From: Hoang Le <hoang.h...@dektech.com.au>
> > Sent: 8-Apr-19 07:08
> > To: Jon Maloy <jon.ma...@ericsson.com>; ma...@donjonn.com;
> > ying....@windriver.com; tipc-discussion@lists.sourceforge.net
> > Subject: [net] tipc: missing entries in name table of publications
> >
> > When binding multiple services with specific type 1Ki, 2Ki.., this
> > leads to some entries in the name table of publications missing when
> > listed out via 'tipc name show'.
> >
> > The problem is at identify zero last_type conditional provided via
> > netlink. The first is initial 'type' when starting name table
> > dummping. The second is continuously with zero type (node state
> > service type). Then, lookup function failure to finding node state service
> type next iteration.
> >
> > To solve this, adding more conditional to marked as dirty type and
> > lookup correct service type for the next iteration instead of select
> > the first service as initial 'type' zero.
> >
> > Signed-off-by: Hoang Le <hoang.h...@dektech.com.au>
> > ---
> > net/tipc/name_table.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c index
> > bff241f03525..89993afe0fbd 100644
> > --- a/net/tipc/name_table.c
> > +++ b/net/tipc/name_table.c
> > @@ -909,7 +909,8 @@ static int tipc_nl_service_list(struct net *net,
> > struct tipc_nl_msg *msg,
> > for (; i < TIPC_NAMETBL_SIZE; i++) {
> > head = &tn->nametbl->services[i];
> >
> > - if (*last_type) {
> > + if (*last_type ||
> > + (!i && *last_key && (*last_lower == *last_key))) {
> > service = tipc_service_find(net, *last_type);
> > if (!service)
> > return -EPIPE;
> > --
> > 2.17.1
>
_______________________________________________
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
