[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180917.184502.447385458615284933.davem@davemloft.net>
Date: Mon, 17 Sep 2018 18:45:02 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: asmadeus@...ewreck.org
Cc: doronrk@...com, tom@...ntonium.net, davejwatson@...com,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] kcm: remove any offset before parsing messages
From: Dominique Martinet <asmadeus@...ewreck.org>
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...
Powered by blists - more mailing lists