From: Zoltan Kiss <zoltan.kiss@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>,
Jan Beulich <JBeulich@suse.com>,
Zoltan Kiss <zoltan.kiss@schaman.hu>,
"Tim (Xen.org)" <tim@xen.org>
Cc: "Keir (Xen.org)" <keir@xen.org>,
Ian Campbell <Ian.Campbell@citrix.com>,
"freebsd-xen@freebsd.org" <freebsd-xen@freebsd.org>,
Alan Somers <alans@spectralogic.com>,
Manuel Bouyer <bouyer@NetBSD.org>,
Stefano Stabellini <Stefano.Stabellini@citrix.com>,
David Vrabel <david.vrabel@citrix.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Wei Liu <wei.liu2@citrix.com>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Roger Pau Monne <roger.pau@citrix.com>,
John Suykerbuyk <johns@spectralogic.com>
Subject: Re: [PATCH RFC] xen/public/ring.h: simplify RING_HAS_UNCONSUMED_REQUESTS()
Date: Mon, 24 Mar 2014 23:55:58 +0000 [thread overview]
Message-ID: <5330C60E.7060501@citrix.com> (raw)
In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD02977EA@AMSPEX01CL01.citrite.net>
On 24/03/14 13:52, Paul Durrant wrote:
>> -----Original Message-----
>> From: Zoltan Kiss
>> Sent: 24 March 2014 12:24
>> To: Jan Beulich; Zoltan Kiss; Tim (Xen.org)
>> Cc: Wei Liu; Ian Campbell; Stefano Stabellini; Keir (Xen.org); freebsd-
>> xen@freebsd.org; Alan Somers; Paul Durrant; David Vrabel; xen-
>> devel@lists.xenproject.org; Boris Ostrovsky; John Suykerbuyk; Manuel
>> Bouyer; Roger Pau Monne
>> Subject: Re: [Xen-devel] [PATCH RFC] xen/public/ring.h: simplify
>> RING_HAS_UNCONSUMED_REQUESTS()
>>
>> On 24/03/14 07:38, Jan Beulich wrote:
>>>>>> On 22.03.14 at 18:14, <tim@xen.org> wrote:
>>>> At 14:18 +0000 on 22 Mar (1395494283), Zoltan Kiss wrote:
>>>>> I think I might have an explanation why do we need this, see this mailing:
>>>>>
>>>>> https://lkml.org/lkml/2014/3/20/710
>>>>> https://lkml.org/lkml/2014/3/21/111
>>>>> https://lkml.org/lkml/2014/3/21/390
>>>> Quoting from the third of these:
>>>>
>>>> | But consuming overrunning requests after rsp_prod_pvt is a problem:
>>>> | - NAPI instance races with dealloc thread over the slots. The first
>>>> | reads them as requests, the second writes them as responses
>>>> | - the NAPI instance overwrites used pending slots as well, so skb frag
>>>> | release go wrong etc.
>>>>
>>>> OK, so the backend needs to be careful not to follow the frontend into
>>>> overrun, not because of the ring itself being corrupted but because it
>>>> will mess up the backend's internal bookkeeping.
>>> With s/will/may/ I'm not sure that's a reason to withdraw the patch:
>>> The generic macros in ring.h imo shouldn't dictate any particular
>>> protection policy beyond protecting the ring itself. I.e. I'd think if
>>> netback need protection beyond the one provided by ring.h macros,
>>> it should take care to implement them itself.
>> It's not "may", it is a "will". In case of Linux netback for sure, but I
>> think it's reasonable for any backend to rely on the fact that the ring
>> macros protect them from abusive frontends. Protecting a backend to read
>> requests from the [rsp_prod_pvt, req_cons] range is a sensible thing to
>> do in the ring macros.
> I disagree. That's not what the name of the macro implies; it implies a range for req_prod - req_cons. The backend is responsible for its own rsp_prod_pvt value and should make sure it's safe. If, to that end, it wants to have its own variant of the macro then that's reasonable, but adding such a clause to the macro in the generic header is (as has been proven) confusing.
My opinion is that the name of the macro implies the caller wants to
know if there are unconsumed requests on the ring (and it doesn't imply
it, but the return value is actually how many unconsumed requests you
have). Returning req_prod - req_cons seems to be logical at first (and
second and ...) thought, but - and that's not implied in the name
indeed, but I think it's sensible, and should be documented in a comment
- if you want to protect the backend from abusive frontends, you should
check if req_prod is not overrunning rsp_prod_pvt. You could check
rsp_prod, but rsp_prod_pvt is better, because the latter should be
always equal to or ahead of the former, and from the backend point of
view the responses between the two (if any) doesn't matter.
It's not about the backend making sure it's rsp_prod_pvt is valid or
not, it's about protection from a frontend. And I think it should be a
general thing for the ring users to have this safety check, rather than
something backend-specific, as all of them could be affected.
Zoli
>
> Paul
>
>> Also, RING_FINAL_CHECK_FOR_REQUESTS relies on this macro, removing
>> this
>> protection may cause other issues, e.g. netback keeps the NAPI instance
>> spinning while it's not consuming any requests.
>>
>> Zoli
next prev parent reply other threads:[~2014-03-24 23:56 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-06 15:47 RING_HAS_UNCONSUMED_REQUESTS oddness Zoltan Kiss
2014-03-06 15:53 ` Ian Campbell
2014-03-06 16:31 ` Zoltan Kiss
2014-03-06 17:30 ` Tim Deegan
2014-03-06 21:39 ` Zoltan Kiss
2014-03-07 9:23 ` Paul Durrant
2014-03-07 17:43 ` Zoltan Kiss
2014-03-07 12:02 ` Wei Liu
2014-03-07 18:58 ` Zoltan Kiss
2014-03-11 15:55 ` Ian Campbell
2014-03-11 23:34 ` Zoltan Kiss
2014-03-13 16:38 ` [PATCH RFC] xen/public/ring.h: simplify RING_HAS_UNCONSUMED_REQUESTS() Tim Deegan
2014-03-22 14:18 ` Zoltan Kiss
2014-03-22 17:14 ` Tim Deegan
2014-03-24 7:38 ` Jan Beulich
2014-03-24 9:39 ` Paul Durrant
2014-03-24 9:59 ` Jan Beulich
2014-03-24 11:03 ` Paul Durrant
2014-03-24 12:23 ` Zoltan Kiss
2014-03-24 13:52 ` Paul Durrant
2014-03-24 23:55 ` Zoltan Kiss [this message]
2014-04-03 9:38 ` Tim Deegan
2014-04-03 15:34 ` Zoltan Kiss
2014-03-11 15:44 ` RING_HAS_UNCONSUMED_REQUESTS oddness Ian Campbell
2014-03-11 23:24 ` Zoltan Kiss
2014-03-12 10:28 ` Ian Campbell
2014-03-12 10:48 ` Roger Pau Monné
2014-03-12 11:25 ` Paul Durrant
2014-03-12 11:38 ` Paul Durrant
2014-03-12 14:41 ` Zoltan Kiss
2014-03-12 15:23 ` Paul Durrant
2014-03-12 15:42 ` Wei Liu
2014-03-12 15:56 ` Paul Durrant
2014-03-12 16:02 ` Paul Durrant
2014-03-12 16:13 ` Zoltan Kiss
2014-03-12 16:42 ` Paul Durrant
2014-03-12 19:06 ` Zoltan Kiss
2014-03-13 9:26 ` Paul Durrant
2014-03-13 10:02 ` Ian Campbell
2014-03-13 10:58 ` Paul Durrant
2014-03-13 12:19 ` Ian Campbell
2014-03-13 12:28 ` Zoltan Kiss
2014-03-13 12:29 ` Paul Durrant
2014-03-13 12:44 ` Ian Campbell
2014-03-12 14:25 ` Zoltan Kiss
2014-03-12 14:27 ` Zoltan Kiss
2014-03-12 14:30 ` Ian Campbell
2014-03-12 15:14 ` Zoltan Kiss
2014-03-12 15:37 ` Ian Campbell
2014-03-12 17:14 ` Zoltan Kiss
2014-03-12 17:43 ` Ian Campbell
2014-03-12 21:10 ` Zoltan Kiss
2014-03-13 10:04 ` Ian Campbell
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=5330C60E.7060501@citrix.com \
--to=zoltan.kiss@citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=JBeulich@suse.com \
--cc=Paul.Durrant@citrix.com \
--cc=Stefano.Stabellini@citrix.com \
--cc=alans@spectralogic.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bouyer@NetBSD.org \
--cc=david.vrabel@citrix.com \
--cc=freebsd-xen@freebsd.org \
--cc=johns@spectralogic.com \
--cc=keir@xen.org \
--cc=roger.pau@citrix.com \
--cc=tim@xen.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.org \
--cc=zoltan.kiss@schaman.hu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.