[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <D7DE3103-994D-478E-B7F6-42CE8B6469FE@vmware.com>
Date: Thu, 1 Dec 2022 15:14:20 +0000
From: Vishnu Dasa <vdasa@...are.com>
To: Stefano Garzarella <sgarzare@...hat.com>,
Arseniy Krasnov <AVKrasnov@...rdevices.ru>
CC: Bryan Tan <bryantan@...are.com>,
"David S. Miller" <davem@...emloft.net>,
"edumazet@...gle.com" <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
"kys@...rosoft.com" <kys@...rosoft.com>,
"haiyangz@...rosoft.com" <haiyangz@...rosoft.com>,
"wei.liu@...nel.org" <wei.liu@...nel.org>,
Dexuan Cui <decui@...rosoft.com>,
Krasnov Arseniy <oxffffaa@...il.com>,
Bobby Eshleman <bobby.eshleman@...il.com>,
Bobby Eshleman <bobby.eshleman@...edance.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"virtualization@...ts.linux-foundation.org"
<virtualization@...ts.linux-foundation.org>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
kernel <kernel@...rdevices.ru>
Subject: Re: [RFC PATCH v2 3/6] vsock/vmci: always return ENOMEM in case of
error
> On Dec 1, 2022, at 1:30 AM, Stefano Garzarella <sgarzare@...hat.com> wrote:
>
> !! External Email
>
> On Fri, Nov 25, 2022 at 05:08:06PM +0000, Arseniy Krasnov wrote:
>> From: Bobby Eshleman <bobby.eshleman@...edance.com>
>>
>> This saves original behaviour from af_vsock.c - switch any error
>> code returned from transport layer to ENOMEM.
>>
>> Signed-off-by: Bobby Eshleman <bobby.eshleman@...edance.com>
>> Signed-off-by: Arseniy Krasnov <AVKrasnov@...rdevices.ru>
>> ---
>> net/vmw_vsock/vmci_transport.c | 9 ++++++++-
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> @Bryan @Vishnu what do you think about this patch?
>
> A bit of context:
>
> Before this series, the af_vsock core always returned ENOMEM to the user
> if the transport failed to queue the packet.
>
> Now we are changing it by returning the transport error. So I think here
> we want to preserve the previous behavior for vmci, but I don't know if
> that's the right thing.
>
Agree with Stefano. I don't think we need to preserve the previous
behavior for vmci.
>
> @Arseniy please in the next versions describe better in the commit
> messages the reasons for these changes, so it is easier review for
> others and also in the future by reading the commit message we can
> understand the reason for the change.
>
> Thanks,
> Stefano
>
>>
>> diff --git a/net/vmw_vsock/vmci_transport.c b/net/vmw_vsock/vmci_transport.c
>> index 842c94286d31..289a36a203a2 100644
>> --- a/net/vmw_vsock/vmci_transport.c
>> +++ b/net/vmw_vsock/vmci_transport.c
>> @@ -1838,7 +1838,14 @@ static ssize_t vmci_transport_stream_enqueue(
>> struct msghdr *msg,
>> size_t len)
>> {
>> - return vmci_qpair_enquev(vmci_trans(vsk)->qpair, msg, len, 0);
>> + int err;
>> +
>> + err = vmci_qpair_enquev(vmci_trans(vsk)->qpair, msg, len, 0);
>> +
>> + if (err < 0)
>> + err = -ENOMEM;
>> +
>> + return err;
>> }
>>
>> static s64 vmci_transport_stream_has_data(struct vsock_sock *vsk)
>> --
>> 2.25.1
>
>
> !! External Email: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender.
Powered by blists - more mailing lists