Hi,
On Wed, 2018-06-06 at 13:25 +0300, Kirill Tkhai wrote:
> Hi, Paolo,
>
> below is couple my thoughts about this.
>
> On 06.06.2018 12:44, Paolo Abeni wrote:
> > On Tue, 2018-06-05 at 18:06 +0200, Paolo Abeni wrote:
> > > On Tue, 2018-06-05 at 08:35 -0700, Tom Herbert wrote:
> > > > Paolo, tha
Hi, Paolo,
below is couple my thoughts about this.
On 06.06.2018 12:44, Paolo Abeni wrote:
> On Tue, 2018-06-05 at 18:06 +0200, Paolo Abeni wrote:
>> On Tue, 2018-06-05 at 08:35 -0700, Tom Herbert wrote:
>>> Paolo, thanks for looking into this! Can you try replacing
>>> __skb_dequeue in requeue_r
On Tue, 2018-06-05 at 18:06 +0200, Paolo Abeni wrote:
> On Tue, 2018-06-05 at 08:35 -0700, Tom Herbert wrote:
> > Paolo, thanks for looking into this! Can you try replacing
> > __skb_dequeue in requeue_rx_msgs with skb_dequeue to see if that is
> > the fix.
>
> Sure, I'll retrigger the test, and r
Hi,
On Tue, 2018-06-05 at 08:35 -0700, Tom Herbert wrote:
> On Tue, Jun 5, 2018 at 7:53 AM, David Miller wrote:
> > From: Paolo Abeni
> > Date: Tue, 5 Jun 2018 12:32:33 +0200
> >
> >> @@ -1157,7 +1158,9 @@ static int kcm_recvmsg(struct socket *sock, struct
> >> msghdr *msg,
> >>
From: Paolo Abeni
Date: Tue, 5 Jun 2018 12:32:33 +0200
> @@ -1157,7 +1158,9 @@ static int kcm_recvmsg(struct socket *sock, struct
> msghdr *msg,
> /* Finished with message */
> msg->msg_flags |= MSG_EOR;
> KCM_STATS_INCR(kcm->sta
Currently kcm holds both the RX mux lock and the socket lock when
updating the sk receive queue, except in some notable cases:
- kcm_rfree holds only the RX mux lock
- kcm_recvmsg holds only the socket lock
has results there are possible races which cause receive queue
corruption, as reported by
