lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <0f0a8603-e8a1-5fb2-23d9-5773c808ef85@sberdevices.ru> Date: Tue, 28 Mar 2023 13:42:19 +0300 From: Arseniy Krasnov <avkrasnov@...rdevices.ru> To: Stefano Garzarella <sgarzare@...hat.com>, Bryan Tan <bryantan@...are.com>, Vishnu Dasa <vdasa@...are.com>, VMware PV-Drivers Reviewers <pv-drivers@...are.com> CC: Stefan Hajnoczi <stefanha@...hat.com>, "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Bobby Eshleman <bobby.eshleman@...edance.com>, <kvm@...r.kernel.org>, <virtualization@...ts.linux-foundation.org>, <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>, <kernel@...rdevices.ru>, <oxffffaa@...il.com> Subject: Re: [RFC PATCH v1 1/2] vsock: return errors other than -ENOMEM to socket On 28.03.2023 12:42, Stefano Garzarella wrote: > I pressed send too early... > > CCing Bryan, Vishnu, and pv-drivers@...are.com > > On Tue, Mar 28, 2023 at 11:39 AM Stefano Garzarella <sgarzare@...hat.com> wrote: >> >> On Sun, Mar 26, 2023 at 01:13:11AM +0300, Arseniy Krasnov wrote: >>> This removes behaviour, where error code returned from any transport >>> was always switched to ENOMEM. This works in the same way as: >>> commit >>> c43170b7e157 ("vsock: return errors other than -ENOMEM to socket"), >>> but for receive calls. >>> >>> Signed-off-by: Arseniy Krasnov <AVKrasnov@...rdevices.ru> >>> --- >>> net/vmw_vsock/af_vsock.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c >>> index 19aea7cba26e..9262e0b77d47 100644 >>> --- a/net/vmw_vsock/af_vsock.c >>> +++ b/net/vmw_vsock/af_vsock.c >>> @@ -2007,7 +2007,7 @@ static int __vsock_stream_recvmsg(struct sock *sk, struct msghdr *msg, >>> >>> read = transport->stream_dequeue(vsk, msg, len - copied, flags); >> >> In vmci_transport_stream_dequeue() vmci_qpair_peekv() and >> vmci_qpair_dequev() return VMCI_ERROR_* in case of errors. >> >> Maybe we should return -ENOMEM in vmci_transport_stream_dequeue() if >> those functions fail to keep the same behavior. Yes, seems i missed it, because several months ago we had similar question for send logic: https://www.spinics.net/lists/kernel/msg4611091.html And it was ok to not handle VMCI send path in this way. So i think current implementation for tx is a little bit buggy, because VMCI specific error from 'vmci_qpair_enquev()' is returned to af_vsock.c. I think error conversion must be added to VMCI transport for tx also. Good thing is that Hyper-V uses general error codes. Thanks, Arseniy >> >> CCing Bryan, Vishnu, and pv-drivers@...are.com >> >> The other transports seem okay to me. >> >> Thanks, >> Stefano >> >>> if (read < 0) { >>> - err = -ENOMEM; >>> + err = read; >>> break; >>> } >>> >>> @@ -2058,7 +2058,7 @@ static int __vsock_seqpacket_recvmsg(struct sock *sk, struct msghdr *msg, >>> msg_len = transport->seqpacket_dequeue(vsk, msg, flags); >>> >>> if (msg_len < 0) { >>> - err = -ENOMEM; >>> + err = msg_len; >>> goto out; >>> } >>> >>> -- >>> 2.25.1 >>> >
Powered by blists - more mailing lists