From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dominique Martinet <asmadeus@codewreck.org>
Subject: Re: KCM - recvmsg() mangles packets?
Date: Sat, 4 Aug 2018 04:08:06 +0200
Message-ID: <20180804020806.GA32338@nautica>
References: <20180803182830.GB29193@nautica>
 <CAPDqMeorHCcYKmbobH4biiZdoWf34Mw4BUk_L1deSTRK2TSmRA@mail.gmail.com>
 <20180803232057.GB7583@nautica>
 <CAPDqMeo_OW29=5oT8-YBvrD-sg1uNmPn3wSJtKWAgF2LRwLKWA@mail.gmail.com>
 <20180804014132.GA26606@nautica>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Cc: Linux Kernel Network Developers <netdev@vger.kernel.org>
To: Tom Herbert <tom@quantonium.net>
Return-path: <netdev-owner@vger.kernel.org>
Received: from nautica.notk.org ([91.121.71.147]:60414 "EHLO nautica.notk.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1725722AbeHDEHN (ORCPT <rfc822;netdev@vger.kernel.org>);
        Sat, 4 Aug 2018 00:07:13 -0400
Content-Disposition: inline
In-Reply-To: <20180804014132.GA26606@nautica>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

Dominique Martinet wrote on Sat, Aug 04, 2018:
> Actually, now I'm looking closer to the timing, it looks specific to the
> connection setup. This send loop works:
>         int i = 1;
>         while(i <= 1000) {
>                 int len = (i++ * 1312739ULL) % 31 + 1;
>                 my_msg.hdr.len = htonl(len);
>                 for (int j = 0; j < len; ) {
>                         j += snprintf(my_msg.data + j, len - j,
>                                       "%i", i - 1);
>                 }
>                 my_msg.data[len-1] = '\0';
>                 //printf("%d: writing %d\n", i-1, len);
>                 len = write(s, &my_msg, sizeof(my_msg.hdr) + len);
>                 if (error == -1)
>                         err(EXIT_FAILURE, "write");
>                 if (i == 2)
>                         usleep(1);
>         }
> 
> But removing the usleep(1) after the first packet makes recvmsg()
> "fail": it reads the content of the second packet with the size of the
> first.

I talked too fast, I can get this to fail on later packets e.g.
Got 18, expected 31 on 452nd message: 453453453453453453; flags: 80

The content is 453 in a loop so this really is the 453rd packet...

But being slower e.g. doing that usleep after every single packets and I
could let the loop run until 100k without a hintch.


There really has to be something wrong, I just can't tell what from
looking at the code with my naive eyes.
Maybe we need to lock both the tcp and the kcm sockets?


Thanks,
-- 
Dominique