Message ID | 76e7698d-890b-d14d-fa34-da5dd7dd13d8@sberdevices.ru |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp3451666wrd; Tue, 28 Feb 2023 21:46:08 -0800 (PST) X-Google-Smtp-Source: AK7set8P1wXX/J5dYpbPvID39fZqm2+W8+oXNiZl9kfBP/7dj0vsCU/PIY3F0JvQ6S1XTRXgTtQ7 X-Received: by 2002:a17:906:348f:b0:8a9:f870:d259 with SMTP id g15-20020a170906348f00b008a9f870d259mr5327491ejb.48.1677649568725; Tue, 28 Feb 2023 21:46:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1677649568; cv=none; d=google.com; s=arc-20160816; b=jnquOy/OeHbJhdnvhEbm15/08nKZT4+gv6DyOpuETkL+S0oMgCMbmHGk6cL6PKhrKO acu7EgxMRu2dAQ2FgLfo7B8JHT/I3P46zXP4MulFnySRwXK5K+dtxkS0GOD2M4/NDIeq K9sQ5uMV68CUNX9KegsvV5ex+L+tfWJLhYUm+dQ9RdnknzLzXKNkut7DCuMpN7UQElWt uYmzGOsgh9Mb5DxWwrPEbRFGQ8sR1MgDIOE82AiqXfdDDYLrpD+ToenKZKlVv808a5ZZ cV7hC3KonCwD3KOlsuQbmoqzCzGgmyvEvEBLwCeTx/SSuqGDD3NsOSBKAMS2zgWhmY1M ABPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:subject:from:cc:to :content-language:user-agent:mime-version:date:message-id :dkim-signature; bh=pSybxYLtaFBPZn4llcjWoXZByulTRftoVwSM3MF7hHo=; b=s+k7Yo5LBWujULYNe1+8s/qUnmJT1qe6gtxY8gdDXl+9DpL50kStrjkjbnQKoxG0Nd mb+8XUNdFKkjoD4FjTytsi8e18mVvhaqW9jnqRagJjzyIvmjA8SRwF7LaRPYkqFOTH2v +KbNokaXl1nhoJw1i7zv4m3223DTZ9fZbw3ArD/GBI+EptDRD3VIUAosArgWX66XT6yX hNwPJcrLc5If4PqvBmLxOZr4ksc7Wme359bAaMcdbdaf8Be9UJTFm9Y3Lmyo4lKAdYAL LhhlStnudwS3hfWbcHpfyCNyXPfSzGNb2akhaHfOXn+kiZPgUvW9036ZkIna9i6jTx/d IaAA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sberdevices.ru header.s=mail header.b=tDGr+UA3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=sberdevices.ru Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a17-20020a1709063a5100b008b17891459fsi12067665ejf.298.2023.02.28.21.45.46; Tue, 28 Feb 2023 21:46:08 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@sberdevices.ru header.s=mail header.b=tDGr+UA3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=sberdevices.ru Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229745AbjCAFWm (ORCPT <rfc822;aaron.seo0120@gmail.com> + 99 others); Wed, 1 Mar 2023 00:22:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50708 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229509AbjCAFWk (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 1 Mar 2023 00:22:40 -0500 Received: from mx.sberdevices.ru (mx.sberdevices.ru [45.89.227.171]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C70283757A; Tue, 28 Feb 2023 21:22:37 -0800 (PST) Received: from s-lin-edge02.sberdevices.ru (localhost [127.0.0.1]) by mx.sberdevices.ru (Postfix) with ESMTP id B29095FD5F; Wed, 1 Mar 2023 08:22:34 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sberdevices.ru; s=mail; t=1677648154; bh=pSybxYLtaFBPZn4llcjWoXZByulTRftoVwSM3MF7hHo=; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type; b=tDGr+UA3jvR+kF0RvxTyVjehhcpoRu7UxYNr+9dfAuOuKp2zy7+x7r0cfQcTVsVgb yYhwvmecXJ1pyBJsEGOXZrUcoGNLO3IKPPZIfNxQBAGafERZZIZjZU6YZSIDarck9x OQzfG6rxypuBlELR0LptuaSVDC9zzp3wogV3ISlu5m3T6/GDh0V9t9GIk9rCpJzJS3 /E+6t9zBR7AYUOLtyvmhMJgIA9uqTe3EwmLk7z5ieM0RARIBhqmtbJ1olGqwfWQitL v8mDnvA7VEOn9HiDMPigpzQ+1YTXNuMuPlO51Jolh6XSm2KiWdnIAr1AYdp3L2YNbm uXZSi1KfXA/qA== Received: from S-MS-EXCH01.sberdevices.ru (S-MS-EXCH01.sberdevices.ru [172.16.1.4]) by mx.sberdevices.ru (Postfix) with ESMTP; Wed, 1 Mar 2023 08:22:31 +0300 (MSK) Message-ID: <76e7698d-890b-d14d-fa34-da5dd7dd13d8@sberdevices.ru> Date: Wed, 1 Mar 2023 08:19:45 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Content-Language: en-US To: Stefano Garzarella <sgarzare@redhat.com>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com> CC: <oxffffaa@gmail.com>, <kernel@sberdevices.ru>, <avkrasnov@sberdevices.ru>, <virtualization@lists.linux-foundation.org>, <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org> From: Arseniy Krasnov <avkrasnov@sberdevices.ru> Subject: [RFC PATCH v1] vsock: check error queue to set EPOLLERR Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.1.6] X-ClientProxiedBy: S-MS-EXCH01.sberdevices.ru (172.16.1.4) To S-MS-EXCH01.sberdevices.ru (172.16.1.4) X-KSMG-Rule-ID: 4 X-KSMG-Message-Action: clean X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiPhishing: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 1.1.2.30, bases: 2023/03/01 02:04:00 #20904788 X-KSMG-AntiVirus-Status: Clean, skipped X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759143073961088815?= X-GMAIL-MSGID: =?utf-8?q?1759143073961088815?= |
Series |
[RFC,v1] vsock: check error queue to set EPOLLERR
|
|
Commit Message
Arseniy Krasnov
March 1, 2023, 5:19 a.m. UTC
EPOLLERR must be set not only when there is error on the socket, but also
when error queue of it is not empty (may be it contains some control
messages). Without this patch 'poll()' won't detect data in error queue.
This patch is based on 'tcp_poll()'.
Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
---
net/vmw_vsock/af_vsock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Wed, Mar 01, 2023 at 08:19:45AM +0300, Arseniy Krasnov wrote: >EPOLLERR must be set not only when there is error on the socket, but also >when error queue of it is not empty (may be it contains some control >messages). Without this patch 'poll()' won't detect data in error queue. Do you have a reproducer? >This patch is based on 'tcp_poll()'. LGTM but we should add a Fixes tag. It's not clear to me whether the problem depends on when we switched to using sk_buff or was pre-existing. Do you have any idea when we introduced this issue? Thanks, Stefano > >Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru> >--- > net/vmw_vsock/af_vsock.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c >index 19aea7cba26e..b5e51ef4a74c 100644 >--- a/net/vmw_vsock/af_vsock.c >+++ b/net/vmw_vsock/af_vsock.c >@@ -1026,7 +1026,7 @@ static __poll_t vsock_poll(struct file *file, struct socket *sock, > poll_wait(file, sk_sleep(sk), wait); > mask = 0; > >- if (sk->sk_err) >+ if (sk->sk_err || !skb_queue_empty_lockless(&sk->sk_error_queue)) > /* Signify that there has been an error on this socket. */ > mask |= EPOLLERR; > >-- >2.25.1 >
Hello! On 02.03.2023 13:06, Stefano Garzarella wrote: > On Wed, Mar 01, 2023 at 08:19:45AM +0300, Arseniy Krasnov wrote: >> EPOLLERR must be set not only when there is error on the socket, but also >> when error queue of it is not empty (may be it contains some control >> messages). Without this patch 'poll()' won't detect data in error queue. > > Do you have a reproducer? > Dedicated reproducer - no:) To reproduce this issue, i used last MSG_ZEROCOPY patches. Completion was inserted to error queue, and 'poll()' didn't report about it. That was the reason, why this patch was included to MSG_ZEROCOPY patchset. But also i think it is better to reduce number of patches in it(i'm working on v2), so it is good to handle this patch separately. May be one way to reproduce it is use SO_TIMESTAMP(time info about skbuff will be queued to the error queue). IIUC this feature is implemented at socket layer and may work in vsock (but i'm not sure). Ok, i'll check it and try to implement reproducer. IIUC, for future, policy for fixes is "for each fix implement reproducer in vsock_test"? >> This patch is based on 'tcp_poll()'. > > LGTM but we should add a Fixes tag. > It's not clear to me whether the problem depends on when we switched to using sk_buff or was pre-existing. > > Do you have any idea when we introduced this issue? git blame shows, that this code exists since first commit to vsock: commit d021c344051af91f42c5ba9fdedc176740cbd238 Author: Andy King <acking@vmware.com> Date: Wed Feb 6 14:23:56 2013 +0000 VSOCK: Introduce VM Sockets For TCP same logic was added by: commit 4ed2d765dfaccff5ebdac68e2064b59125033a3b Author: Willem de Bruijn <willemb@google.com> Date: Mon Aug 4 22:11:49 2014 -0400 net-timestamp: TCP timestamping > > Thanks, > Stefano > Thanks Arseniy >> >> Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru> >> --- >> net/vmw_vsock/af_vsock.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c >> index 19aea7cba26e..b5e51ef4a74c 100644 >> --- a/net/vmw_vsock/af_vsock.c >> +++ b/net/vmw_vsock/af_vsock.c >> @@ -1026,7 +1026,7 @@ static __poll_t vsock_poll(struct file *file, struct socket *sock, >> poll_wait(file, sk_sleep(sk), wait); >> mask = 0; >> >> - if (sk->sk_err) >> + if (sk->sk_err || !skb_queue_empty_lockless(&sk->sk_error_queue)) >> /* Signify that there has been an error on this socket. */ >> mask |= EPOLLERR; >> >> -- >> 2.25.1 >> >
On Thu, Mar 02, 2023 at 02:41:29PM +0300, Arseniy Krasnov wrote: >Hello! > >On 02.03.2023 13:06, Stefano Garzarella wrote: >> On Wed, Mar 01, 2023 at 08:19:45AM +0300, Arseniy Krasnov wrote: >>> EPOLLERR must be set not only when there is error on the socket, but also >>> when error queue of it is not empty (may be it contains some control >>> messages). Without this patch 'poll()' won't detect data in error queue. >> >> Do you have a reproducer? >> >Dedicated reproducer - no:) >To reproduce this issue, i used last MSG_ZEROCOPY patches. Completion was inserted to >error queue, and 'poll()' didn't report about it. That was the reason, why this patch >was included to MSG_ZEROCOPY patchset. But also i think it is better to reduce number >of patches in it(i'm working on v2), so it is good to handle this patch separately. Yep, absolutely! >May be one way to reproduce it is use SO_TIMESTAMP(time info about skbuff will be queued >to the error queue). IIUC this feature is implemented at socket layer and may work in >vsock (but i'm not sure). Ok, i'll check it and try to implement reproducer. > >IIUC, for future, policy for fixes is "for each fix implement reproducer in vsock_test"? Nope, but for each fix we should have a Fixes tag. Usually we use vsock_test to check regressions on features and also the behaviour of different transports. My question was more about whether this problem was there before supporting sk_buff or not, to figure out which Fixes tag to use. > >>> This patch is based on 'tcp_poll()'. >> >> LGTM but we should add a Fixes tag. >> It's not clear to me whether the problem depends on when we switched to using sk_buff or was pre-existing. >> >> Do you have any idea when we introduced this issue? >git blame shows, that this code exists since first commit to vsock: Okay, but did we use sk_error_queue before supporting sk_buff? Anyway, if we are not sure I think we can use the following Fixes tag, I don't see any issue if we backport this patch also before supporting sk_buff. Thanks, Stefano > >commit d021c344051af91f42c5ba9fdedc176740cbd238 >Author: Andy King <acking@vmware.com> >Date: Wed Feb 6 14:23:56 2013 +0000 > > VSOCK: Introduce VM Sockets > >For TCP same logic was added by: > >commit 4ed2d765dfaccff5ebdac68e2064b59125033a3b >Author: Willem de Bruijn <willemb@google.com> >Date: Mon Aug 4 22:11:49 2014 -0400 > > net-timestamp: TCP timestamping > > >> >> Thanks, >> Stefano >> > >Thanks Arseniy > >>> >>> Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru> >>> --- >>> net/vmw_vsock/af_vsock.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c >>> index 19aea7cba26e..b5e51ef4a74c 100644 >>> --- a/net/vmw_vsock/af_vsock.c >>> +++ b/net/vmw_vsock/af_vsock.c >>> @@ -1026,7 +1026,7 @@ static __poll_t vsock_poll(struct file *file, struct socket *sock, >>> poll_wait(file, sk_sleep(sk), wait); >>> mask = 0; >>> >>> - if (sk->sk_err) >>> + if (sk->sk_err || !skb_queue_empty_lockless(&sk->sk_error_queue)) >>> /* Signify that there has been an error on this socket. */ >>> mask |= EPOLLERR; >>> >>> -- >>> 2.25.1 >>> >> >
On 02.03.2023 16:38, Stefano Garzarella wrote: > On Thu, Mar 02, 2023 at 02:41:29PM +0300, Arseniy Krasnov wrote: >> Hello! >> >> On 02.03.2023 13:06, Stefano Garzarella wrote: >>> On Wed, Mar 01, 2023 at 08:19:45AM +0300, Arseniy Krasnov wrote: >>>> EPOLLERR must be set not only when there is error on the socket, but also >>>> when error queue of it is not empty (may be it contains some control >>>> messages). Without this patch 'poll()' won't detect data in error queue. >>> >>> Do you have a reproducer? >>> >> Dedicated reproducer - no:) >> To reproduce this issue, i used last MSG_ZEROCOPY patches. Completion was inserted to >> error queue, and 'poll()' didn't report about it. That was the reason, why this patch >> was included to MSG_ZEROCOPY patchset. But also i think it is better to reduce number >> of patches in it(i'm working on v2), so it is good to handle this patch separately. > > Yep, absolutely! > >> May be one way to reproduce it is use SO_TIMESTAMP(time info about skbuff will be queued >> to the error queue). IIUC this feature is implemented at socket layer and may work in >> vsock (but i'm not sure). Ok, i'll check it and try to implement reproducer. >> >> IIUC, for future, policy for fixes is "for each fix implement reproducer in vsock_test"? > > Nope, but for each fix we should have a Fixes tag. > > Usually we use vsock_test to check regressions on features and also the > behaviour of different transports. > My question was more about whether this problem was there before > supporting sk_buff or not, to figure out which Fixes tag to use. > Ok i see >> >>>> This patch is based on 'tcp_poll()'. >>> >>> LGTM but we should add a Fixes tag. >>> It's not clear to me whether the problem depends on when we switched to using sk_buff or was pre-existing. >>> >>> Do you have any idea when we introduced this issue? >> git blame shows, that this code exists since first commit to vsock: > > Okay, but did we use sk_error_queue before supporting sk_buff? > No I think, sk_error_queue was unavailable to user(and still unavailable today), because we don't have check for MSG_ERRQUEUE flag in recv logic in af_vsock.c (i've added it in MSG_ZEROCOPY). So even if some subsystem of the kernel inserts skb to sk_error_queue in AF_VSOCK case, user won't dequeue it. > Anyway, if we are not sure I think we can use the following Fixes tag, > I don't see any issue if we backport this patch also before supporting > sk_buff. > Ok, i'll try to prepare reproducer(may be in vsock_test) and add Fixes tag with the commit "VSOCK: Introduce VM Sockets." Thanks, Arseniy > Thanks, > Stefano > >> >> commit d021c344051af91f42c5ba9fdedc176740cbd238 >> Author: Andy King <acking@vmware.com> >> Date: Wed Feb 6 14:23:56 2013 +0000 >> >> VSOCK: Introduce VM Sockets >> >> For TCP same logic was added by: >> >> commit 4ed2d765dfaccff5ebdac68e2064b59125033a3b >> Author: Willem de Bruijn <willemb@google.com> >> Date: Mon Aug 4 22:11:49 2014 -0400 >> >> net-timestamp: TCP timestamping >> >> >>> >>> Thanks, >>> Stefano >>> >> >> Thanks Arseniy >> >>>> >>>> Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru> >>>> --- >>>> net/vmw_vsock/af_vsock.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c >>>> index 19aea7cba26e..b5e51ef4a74c 100644 >>>> --- a/net/vmw_vsock/af_vsock.c >>>> +++ b/net/vmw_vsock/af_vsock.c >>>> @@ -1026,7 +1026,7 @@ static __poll_t vsock_poll(struct file *file, struct socket *sock, >>>> poll_wait(file, sk_sleep(sk), wait); >>>> mask = 0; >>>> >>>> - if (sk->sk_err) >>>> + if (sk->sk_err || !skb_queue_empty_lockless(&sk->sk_error_queue)) >>>> /* Signify that there has been an error on this socket. */ >>>> mask |= EPOLLERR; >>>> >>>> -- >>>> 2.25.1 >>>> >>> >> >
On 02.03.2023 18:06, Arseniy Krasnov wrote: > > > On 02.03.2023 16:38, Stefano Garzarella wrote: >> On Thu, Mar 02, 2023 at 02:41:29PM +0300, Arseniy Krasnov wrote: >>> Hello! >>> >>> On 02.03.2023 13:06, Stefano Garzarella wrote: >>>> On Wed, Mar 01, 2023 at 08:19:45AM +0300, Arseniy Krasnov wrote: >>>>> EPOLLERR must be set not only when there is error on the socket, but also >>>>> when error queue of it is not empty (may be it contains some control >>>>> messages). Without this patch 'poll()' won't detect data in error queue. >>>> >>>> Do you have a reproducer? >>>> >>> Dedicated reproducer - no:) >>> To reproduce this issue, i used last MSG_ZEROCOPY patches. Completion was inserted to >>> error queue, and 'poll()' didn't report about it. That was the reason, why this patch >>> was included to MSG_ZEROCOPY patchset. But also i think it is better to reduce number >>> of patches in it(i'm working on v2), so it is good to handle this patch separately. >> >> Yep, absolutely! >> >>> May be one way to reproduce it is use SO_TIMESTAMP(time info about skbuff will be queued >>> to the error queue). IIUC this feature is implemented at socket layer and may work in >>> vsock (but i'm not sure). Ok, i'll check it and try to implement reproducer. >>> >>> IIUC, for future, policy for fixes is "for each fix implement reproducer in vsock_test"? >> >> Nope, but for each fix we should have a Fixes tag. >> >> Usually we use vsock_test to check regressions on features and also the >> behaviour of different transports. >> My question was more about whether this problem was there before >> supporting sk_buff or not, to figure out which Fixes tag to use. >> > Ok i see >>> >>>>> This patch is based on 'tcp_poll()'. >>>> >>>> LGTM but we should add a Fixes tag. >>>> It's not clear to me whether the problem depends on when we switched to using sk_buff or was pre-existing. >>>> >>>> Do you have any idea when we introduced this issue? >>> git blame shows, that this code exists since first commit to vsock: >> >> Okay, but did we use sk_error_queue before supporting sk_buff? >> > No I think, sk_error_queue was unavailable to user(and still unavailable today), > because we don't have check for MSG_ERRQUEUE flag in recv logic in af_vsock.c > (i've added it in MSG_ZEROCOPY). So even if some subsystem of the kernel inserts > skb to sk_error_queue in AF_VSOCK case, user won't dequeue it. > >> Anyway, if we are not sure I think we can use the following Fixes tag, >> I don't see any issue if we backport this patch also before supporting >> sk_buff. >> > Ok, i'll try to prepare reproducer(may be in vsock_test) and add Fixes tag with the > commit "VSOCK: Introduce VM Sockets." Hm, seems there is no way to reproduce it with AF_VSOCK in the current kernel: 1) I can't find test case how to use sk_error_queue(SO_TIMESTAMPXXX doesn't work on vsock - web says that it depends on NIC driver). And i don't see any generic socket layer features which uses sk_error_queue. 2) Anyway, as i mentioned above - user can't read data from sk_error_queue, because MSG_ERRQUEUE flag is not handled in af_vsock.c. So i'll resend this patch in MSG_ZEROCOPY v2 patchset - in this case, new MSG_ZEROCOPY logic will use this patch: it will be the "reproducer" Thanks, Arseniy > > Thanks, Arseniy >> Thanks, >> Stefano >> >>> >>> commit d021c344051af91f42c5ba9fdedc176740cbd238 >>> Author: Andy King <acking@vmware.com> >>> Date: Wed Feb 6 14:23:56 2013 +0000 >>> >>> VSOCK: Introduce VM Sockets >>> >>> For TCP same logic was added by: >>> >>> commit 4ed2d765dfaccff5ebdac68e2064b59125033a3b >>> Author: Willem de Bruijn <willemb@google.com> >>> Date: Mon Aug 4 22:11:49 2014 -0400 >>> >>> net-timestamp: TCP timestamping >>> >>> >>>> >>>> Thanks, >>>> Stefano >>>> >>> >>> Thanks Arseniy >>> >>>>> >>>>> Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru> >>>>> --- >>>>> net/vmw_vsock/af_vsock.c | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c >>>>> index 19aea7cba26e..b5e51ef4a74c 100644 >>>>> --- a/net/vmw_vsock/af_vsock.c >>>>> +++ b/net/vmw_vsock/af_vsock.c >>>>> @@ -1026,7 +1026,7 @@ static __poll_t vsock_poll(struct file *file, struct socket *sock, >>>>> poll_wait(file, sk_sleep(sk), wait); >>>>> mask = 0; >>>>> >>>>> - if (sk->sk_err) >>>>> + if (sk->sk_err || !skb_queue_empty_lockless(&sk->sk_error_queue)) >>>>> /* Signify that there has been an error on this socket. */ >>>>> mask |= EPOLLERR; >>>>> >>>>> -- >>>>> 2.25.1 >>>>> >>>> >>> >>
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c index 19aea7cba26e..b5e51ef4a74c 100644 --- a/net/vmw_vsock/af_vsock.c +++ b/net/vmw_vsock/af_vsock.c @@ -1026,7 +1026,7 @@ static __poll_t vsock_poll(struct file *file, struct socket *sock, poll_wait(file, sk_sleep(sk), wait); mask = 0; - if (sk->sk_err) + if (sk->sk_err || !skb_queue_empty_lockless(&sk->sk_error_queue)) /* Signify that there has been an error on this socket. */ mask |= EPOLLERR;