From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zoltan Kiss <zoltan.kiss@citrix.com>
Cc: <wei.liu2@citrix.com>, <xen-devel@lists.xenproject.org>,
<paul.durrant@citrix.com>, <netdev@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <jonathan.davies@citrix.com>
Subject: Re: [PATCH net-next] xen-netback: Stop using xenvif_tx_pending_slots_available
Date: Fri, 21 Mar 2014 09:36:43 +0000 [thread overview]
Message-ID: <1395394603.27358.8.camel@kazak.uk.xensource.com> (raw)
In-Reply-To: <1395343961-4744-1-git-send-email-zoltan.kiss@citrix.com>
On Thu, 2014-03-20 at 19:32 +0000, Zoltan Kiss wrote:
> Since the early days TX stops if there isn't enough free pending slots to
> consume a maximum sized (slot-wise) packet. Probably the reason for that is to
> avoid the case when we don't have enough free pending slot in the ring to finish
> the packet. But if we make sure that the pending ring has the same size as the
> shared ring, that shouldn't really happen. The frontend can only post packets
> which fit the to the free space of the shared ring. If it doesn't, the frontend
> has to stop, as it can only increase the req_prod when the whole packet fits
> onto the ring.
My only real concern here is that by removing these checks we are
introducing a way for a malicious or buggy guest to trigger misbehaviour
in the backend, leading to e.g. a DoS.
Should we need to some sanity checks which shutdown the ring if
something like this occurs? i.e. if we come to consume a packet and
there is insufficient space on the pending ring we kill the vif.
What's the invariant we are relying on here, is it:
req_prod >= req_cons >= pending_prod >= pending_cons >= rsp_prod >= rsp_cons
?
> This patch avoid using this checking, makes sure the 2 ring has the same size,
> and remove a checking from the callback. As now we don't stop the NAPI instance
> on this condition, we don't have to wake it up if we free pending slots up.
>
> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
> ---
> diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
> index bef37be..a800a8e 100644
> --- a/drivers/net/xen-netback/common.h
> +++ b/drivers/net/xen-netback/common.h
> @@ -81,7 +81,7 @@ struct xenvif_rx_meta {
>
> #define MAX_BUFFER_OFFSET PAGE_SIZE
>
> -#define MAX_PENDING_REQS 256
> +#define MAX_PENDING_REQS XEN_NETIF_TX_RING_SIZE
XEN_NETIF_TX_RING_SIZE is already == 256, right? (Just want to make sure
this is semantically no change).
> /* It's possible for an skb to have a maximal number of frags
> * but still be less than MAX_BUFFER_OFFSET in size. Thus the
> @@ -253,12 +253,6 @@ static inline pending_ring_idx_t nr_pending_reqs(struct xenvif *vif)
> vif->pending_prod + vif->pending_cons;
> }
>
> -static inline bool xenvif_tx_pending_slots_available(struct xenvif *vif)
> -{
> - return nr_pending_reqs(vif) + XEN_NETBK_LEGACY_SLOTS_MAX
> - < MAX_PENDING_REQS;
> -}
> -
> /* Callback from stack when TX packet can be released */
> void xenvif_zerocopy_callback(struct ubuf_info *ubuf, bool zerocopy_success);
>
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> index 83a71ac..7bb7734 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -88,8 +88,7 @@ static int xenvif_poll(struct napi_struct *napi, int budget)
> local_irq_save(flags);
>
> RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, more_to_do);
> - if (!(more_to_do &&
> - xenvif_tx_pending_slots_available(vif)))
> + if (!more_to_do)
> __napi_complete(napi);
>
> local_irq_restore(flags);
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index bc94320..5df8d63 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1175,8 +1175,7 @@ static unsigned xenvif_tx_build_gops(struct xenvif *vif, int budget)
> struct sk_buff *skb;
> int ret;
>
> - while (xenvif_tx_pending_slots_available(vif) &&
> - (skb_queue_len(&vif->tx_queue) < budget)) {
> + while (skb_queue_len(&vif->tx_queue) < budget) {
> struct xen_netif_tx_request txreq;
> struct xen_netif_tx_request txfrags[XEN_NETBK_LEGACY_SLOTS_MAX];
> struct xen_netif_extra_info extras[XEN_NETIF_EXTRA_TYPE_MAX-1];
> @@ -1516,13 +1515,6 @@ void xenvif_zerocopy_callback(struct ubuf_info *ubuf, bool zerocopy_success)
> wake_up(&vif->dealloc_wq);
> spin_unlock_irqrestore(&vif->callback_lock, flags);
>
> - if (RING_HAS_UNCONSUMED_REQUESTS(&vif->tx) &&
> - xenvif_tx_pending_slots_available(vif)) {
> - local_bh_disable();
> - napi_schedule(&vif->napi);
> - local_bh_enable();
> - }
> -
> if (likely(zerocopy_success))
> vif->tx_zerocopy_success++;
> else
> @@ -1714,8 +1706,7 @@ static inline int rx_work_todo(struct xenvif *vif)
> static inline int tx_work_todo(struct xenvif *vif)
> {
>
> - if (likely(RING_HAS_UNCONSUMED_REQUESTS(&vif->tx)) &&
> - xenvif_tx_pending_slots_available(vif))
> + if (likely(RING_HAS_UNCONSUMED_REQUESTS(&vif->tx)))
> return 1;
>
> return 0;
next prev parent reply other threads:[~2014-03-21 9:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-20 19:32 Zoltan Kiss
2014-03-20 19:32 ` [PATCH net-next] xen-netback: Follow-up patch for grant mapping series Zoltan Kiss
2014-03-21 9:41 ` Ian Campbell
2014-03-21 19:31 ` Zoltan Kiss
2014-03-24 10:34 ` Ian Campbell
2014-03-21 18:13 ` David Miller
2014-03-21 9:36 ` Ian Campbell [this message]
2014-03-21 19:16 ` [PATCH net-next] xen-netback: Stop using xenvif_tx_pending_slots_available Zoltan Kiss
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=1395394603.27358.8.camel@kazak.uk.xensource.com \
--to=ian.campbell@citrix.com \
--cc=jonathan.davies@citrix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paul.durrant@citrix.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.org \
--cc=zoltan.kiss@citrix.com \
/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®