From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: jgross@suse.com, xen-devel@lists.xenproject.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] pvcalls-back: do not return error on inet_accept EAGAIN
Date: Mon, 5 Feb 2018 13:34:13 -0500 [thread overview]
Message-ID: <abe7aeba-ad27-467d-3da0-1026f5966a43@oracle.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1802050953570.10160@sstabellini-ThinkPad-X260>
On 02/05/2018 01:01 PM, Stefano Stabellini wrote:
> On Sun, 4 Feb 2018, Boris Ostrovsky wrote:
>> On 02/02/2018 08:34 PM, Stefano Stabellini wrote:
>>> When the client sends a regular blocking accept request, the backend is
>>> expected to return only when the accept is completed, simulating a
>>> blocking behavior, or return an error.
>>>
>>> Specifically, on EAGAIN from inet_accept, the backend shouldn't return
>>> "EAGAIN" to the client. Instead, it should simply continue the wait.
>>> Otherwise, the client will send another accept request, which will cause
>>> another EAGAIN to be sent back, which is a waste of resources and not
>>> conforming to the expected behavior. Change the behavior by turning the
>>> "goto error" into a return.
>>>
>>> Signed-off-by: Stefano Stabellini <stefano@aporeto.com>
>>
>> I am looking at SYSCALL_DEFINE4(accept4) and sock->ops->accept (which *I
>> think* is inet_accept, at least in some cases) passes all errors (including
>> EAGAIN) back to the caller. Is this a different case?
> Hi Boris,
>
> I didn't explain myself well. You are right that inet_accept passes all
> errors back to the caller, but this is different: not only it would be a
> waste of resources to do so, but the different behavior is specified in
> the PVCalls spec:
>
> "The backend will reply to the request only when a new connection is
> successfully accepted, i.e. the backend does not return EAGAIN or
> EWOULDBLOCK."
Got it, thanks.
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
-boris
>
> https://xenbits.xen.org/docs/unstable/misc/pvcalls.html
>
> Look under the "Accept" sub-chapter.
>
> Cheers,
>
> Stefano
next prev parent reply other threads:[~2018-02-05 18:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-03 1:34 Stefano Stabellini
2018-02-04 19:20 ` Boris Ostrovsky
2018-02-05 18:01 ` Stefano Stabellini
2018-02-05 18:34 ` Boris Ostrovsky [this message]
2018-02-06 14:52 ` Juergen Gross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=abe7aeba-ad27-467d-3da0-1026f5966a43@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®