From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH v2] kcm: remove any offset before parsing messages Date: Mon, 17 Sep 2018 18:45:02 -0700 (PDT) Message-ID: <20180917.184502.447385458615284933.davem@davemloft.net> References: <1536657703-27577-1-git-send-email-asmadeus@codewreck.org> <20180912053642.GA2912@nautica> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: doronrk@fb.com, tom@quantonium.net, davejwatson@fb.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org To: asmadeus@codewreck.org Return-path: In-Reply-To: <20180912053642.GA2912@nautica> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org From: Dominique Martinet Date: Wed, 12 Sep 2018 07:36:42 +0200 > Dominique Martinet wrote on Tue, Sep 11, 2018: >> Hmm, while trying to benchmark this, I sometimes got hangs in >> kcm_wait_data() for the last packet somehow? >> The sender program was done (exited (zombie) so I assumed the sender >> socket flushed), but the receiver was in kcm_wait_data in kcm_recvmsg >> indicating it parsed a header but there was no skb to peek at? >> But the sock is locked so this shouldn't be racy... >> >> I can get it fairly often with this patch and small messages with an >> offset, but I think it's just because the pull changes some timing - I >> can't hit it with just the clone, and I can hit it with a pull without >> clone as well.... And I don't see how pulling a cloned skb can impact >> the original socket, but I'm a bit fuzzy on this. > > This is weird, I cannot reproduce at all without that pull, even if I > add another delay there instead of the pull, so it's not just timing... I really can't apply this patch until you resolve this. It is weird, given your description, though...