xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Zoltan Kiss <zoltan.kiss@citrix.com>
To: ian.campbell@citrix.com, wei.liu2@citrix.com,
	xen-devel@lists.xenproject.org
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Zoltan Kiss <zoltan.kiss@citrix.com>,
	jonathan.davies@citrix.com
Subject: [PATCH net-next v7 5/9] xen-netback: Remove old TX grant copy definitons and fix indentations
Date: Thu, 6 Mar 2014 21:48:27 +0000	[thread overview]
Message-ID: <1394142511-14827-6-git-send-email-zoltan.kiss@citrix.com> (raw)
In-Reply-To: <1394142511-14827-1-git-send-email-zoltan.kiss@citrix.com>

These became obsolete with grant mapping. I've left intentionally the
indentations in this way, to improve readability of previous patches.

NOTE: if bisect brought you here, you should apply the series up until
"xen-netback: Timeout packets in RX path", otherwise Windows guests can't work
properly and malicious guests can block other guests by not releasing their sent
packets.

Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
---
v2:
- move the indentation fixup patch here

v4:
- indentation fixes

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 8719500..8e59b14 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -48,37 +48,8 @@
 typedef unsigned int pending_ring_idx_t;
 #define INVALID_PENDING_RING_IDX (~0U)
 
-/* For the head field in pending_tx_info: it is used to indicate
- * whether this tx info is the head of one or more coalesced requests.
- *
- * When head != INVALID_PENDING_RING_IDX, it means the start of a new
- * tx requests queue and the end of previous queue.
- *
- * An example sequence of head fields (I = INVALID_PENDING_RING_IDX):
- *
- * ...|0 I I I|5 I|9 I I I|...
- * -->|<-INUSE----------------
- *
- * After consuming the first slot(s) we have:
- *
- * ...|V V V V|5 I|9 I I I|...
- * -----FREE->|<-INUSE--------
- *
- * where V stands for "valid pending ring index". Any number other
- * than INVALID_PENDING_RING_IDX is OK. These entries are considered
- * free and can contain any number other than
- * INVALID_PENDING_RING_IDX. In practice we use 0.
- *
- * The in use non-INVALID_PENDING_RING_IDX (say 0, 5 and 9 in the
- * above example) number is the index into pending_tx_info and
- * mmap_pages arrays.
- */
 struct pending_tx_info {
-	struct xen_netif_tx_request req; /* coalesced tx request */
-	pending_ring_idx_t head; /* head != INVALID_PENDING_RING_IDX
-				  * if it is head of one or more tx
-				  * reqs
-				  */
+	struct xen_netif_tx_request req; /* tx request */
 	/* Callback data for released SKBs. The callback is always
 	 * xenvif_zerocopy_callback, desc contains the pending_idx, which is
 	 * also an index in pending_tx_info array. It is initialized in
@@ -149,11 +120,6 @@ struct xenvif {
 	struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
 	grant_handle_t grant_tx_handle[MAX_PENDING_REQS];
 
-	/* Coalescing tx requests before copying makes number of grant
-	 * copy ops greater or equal to number of slots required. In
-	 * worst case a tx request consumes 2 gnttab_copy.
-	 */
-	struct gnttab_copy tx_copy_ops[2*MAX_PENDING_REQS];
 	struct gnttab_map_grant_ref tx_map_ops[MAX_PENDING_REQS];
 	struct gnttab_unmap_grant_ref tx_unmap_ops[MAX_PENDING_REQS];
 	/* passed to gnttab_[un]map_refs with pages under (un)mapping */
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 763d49a..bd09028 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -62,16 +62,6 @@ module_param(separate_tx_rx_irq, bool, 0644);
 static unsigned int fatal_skb_slots = FATAL_SKB_SLOTS_DEFAULT;
 module_param(fatal_skb_slots, uint, 0444);
 
-/*
- * If head != INVALID_PENDING_RING_IDX, it means this tx request is head of
- * one or more merged tx requests, otherwise it is the continuation of
- * previous tx request.
- */
-static inline int pending_tx_is_head(struct xenvif *vif, RING_IDX idx)
-{
-	return vif->pending_tx_info[idx].head != INVALID_PENDING_RING_IDX;
-}
-
 static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx,
 			       u8 status);
 
@@ -790,19 +780,6 @@ static int xenvif_count_requests(struct xenvif *vif,
 	return slots;
 }
 
-static struct page *xenvif_alloc_page(struct xenvif *vif,
-				      u16 pending_idx)
-{
-	struct page *page;
-
-	page = alloc_page(GFP_ATOMIC|__GFP_COLD);
-	if (!page)
-		return NULL;
-	vif->mmap_pages[pending_idx] = page;
-
-	return page;
-}
-
 
 struct xenvif_tx_cb {
 	u16 pending_idx;
@@ -832,13 +809,9 @@ static struct gnttab_map_grant_ref *xenvif_get_requests(struct xenvif *vif,
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	skb_frag_t *frags = shinfo->frags;
 	u16 pending_idx = XENVIF_TX_CB(skb)->pending_idx;
-	u16 head_idx = 0;
-	int slot, start;
-	struct page *page;
-	pending_ring_idx_t index, start_idx = 0;
-	uint16_t dst_offset;
+	int start;
+	pending_ring_idx_t index;
 	unsigned int nr_slots;
-	struct pending_tx_info *first = NULL;
 
 	/* At this point shinfo->nr_frags is in fact the number of
 	 * slots, which can be as large as XEN_NETBK_LEGACY_SLOTS_MAX.
@@ -850,8 +823,8 @@ static struct gnttab_map_grant_ref *xenvif_get_requests(struct xenvif *vif,
 
 	for (shinfo->nr_frags = start; shinfo->nr_frags < nr_slots;
 	     shinfo->nr_frags++, txp++, gop++) {
-				index = pending_index(vif->pending_cons++);
-				pending_idx = vif->pending_ring[index];
+		index = pending_index(vif->pending_cons++);
+		pending_idx = vif->pending_ring[index];
 		xenvif_tx_create_gop(vif, pending_idx, txp, gop);
 		frag_set_pending_idx(&frags[shinfo->nr_frags], pending_idx);
 	}
@@ -859,18 +832,6 @@ static struct gnttab_map_grant_ref *xenvif_get_requests(struct xenvif *vif,
 	BUG_ON(shinfo->nr_frags > MAX_SKB_FRAGS);
 
 	return gop;
-err:
-	/* Unwind, freeing all pages and sending error responses. */
-	while (shinfo->nr_frags-- > start) {
-		xenvif_idx_release(vif,
-				frag_get_pending_idx(&frags[shinfo->nr_frags]),
-				XEN_NETIF_RSP_ERROR);
-	}
-	/* The head too, if necessary. */
-	if (start)
-		xenvif_idx_release(vif, pending_idx, XEN_NETIF_RSP_ERROR);
-
-	return NULL;
 }
 
 static inline void xenvif_grant_handle_set(struct xenvif *vif,
@@ -910,7 +871,6 @@ static int xenvif_tx_check_gop(struct xenvif *vif,
 	struct pending_tx_info *tx_info;
 	int nr_frags = shinfo->nr_frags;
 	int i, err, start;
-	u16 peek; /* peek into next tx request */
 
 	/* Check status of header. */
 	err = gop->status;
@@ -924,14 +884,12 @@ static int xenvif_tx_check_gop(struct xenvif *vif,
 
 	for (i = start; i < nr_frags; i++) {
 		int j, newerr;
-		pending_ring_idx_t head;
 
 		pending_idx = frag_get_pending_idx(&shinfo->frags[i]);
 		tx_info = &vif->pending_tx_info[pending_idx];
-		head = tx_info->head;
 
 		/* Check error status: if okay then remember grant handle. */
-			newerr = (++gop)->status;
+		newerr = (++gop)->status;
 
 		if (likely(!newerr)) {
 			xenvif_grant_handle_set(vif, pending_idx , gop->handle);
@@ -1136,7 +1094,6 @@ static unsigned xenvif_tx_build_gops(struct xenvif *vif, int budget)
 	       (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 page *page;
 		struct xen_netif_extra_info extras[XEN_NETIF_EXTRA_TYPE_MAX-1];
 		u16 pending_idx;
 		RING_IDX idx;
@@ -1507,18 +1464,17 @@ static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx,
 {
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
-	u16 peek; /* peek into next tx request */
 	unsigned long flags;
 
-		pending_tx_info = &vif->pending_tx_info[pending_idx];
-		spin_lock_irqsave(&vif->response_lock, flags);
-		make_tx_response(vif, &pending_tx_info->req, status);
-		index = pending_index(vif->pending_prod);
-		vif->pending_ring[index] = pending_idx;
-		/* TX shouldn't use the index before we give it back here */
-		mb();
-		vif->pending_prod++;
-		spin_unlock_irqrestore(&vif->response_lock, flags);
+	pending_tx_info = &vif->pending_tx_info[pending_idx];
+	spin_lock_irqsave(&vif->response_lock, flags);
+	make_tx_response(vif, &pending_tx_info->req, status);
+	index = pending_index(vif->pending_prod);
+	vif->pending_ring[index] = pending_idx;
+	/* TX shouldn't use the index before we give it back here */
+	mb();
+	vif->pending_prod++;
+	spin_unlock_irqrestore(&vif->response_lock, flags);
 }

  parent reply	other threads:[~2014-03-06 21:49 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1394142511-14827-1-git-send-email-zoltan.kiss@citrix.com>
2014-03-06 21:48 ` [PATCH net-next v7 1/9] xen-netback: Use skb->cb for pending_idx Zoltan Kiss
2014-03-06 21:48 ` [PATCH net-next v7 2/9] xen-netback: Minor refactoring of netback code Zoltan Kiss
2014-03-06 21:48 ` [PATCH net-next v7 3/9] xen-netback: Handle foreign mapped pages on the guest RX path Zoltan Kiss
2014-03-06 21:48 ` [PATCH net-next v7 4/9] xen-netback: Introduce TX grant mapping Zoltan Kiss
2014-03-06 21:48 ` Zoltan Kiss [this message]
2014-03-06 21:48 ` [PATCH net-next v7 6/9] xen-netback: Add stat counters for zerocopy Zoltan Kiss
2014-03-06 21:48 ` [PATCH net-next v7 7/9] xen-netback: Handle guests with too many frags Zoltan Kiss
2014-03-06 21:48 ` [PATCH net-next v7 8/9] xen-netback: Timeout packets in RX path Zoltan Kiss
2014-03-13 10:39   ` Ian Campbell
2014-03-06 21:48 ` [PATCH net-next v7 9/9] xen-netback: Aggregate TX unmap operations Zoltan Kiss
2014-03-07 21:05 ` [PATCH net-next v7 0/9] xen-netback: TX grant mapping with SKBTX_DEV_ZEROCOPY instead of copy David Miller
     [not found] ` <20140307.160552.282750558679341658.davem@davemloft.net>
2014-03-08 14:37   ` Zoltan Kiss
     [not found]   ` <531B2B3E.5050800@citrix.com>
2014-03-08 23:57     ` David Miller
     [not found]     ` <20140308.185759.494043114567727021.davem@davemloft.net>
2014-03-10 10:15       ` Wei Liu
2014-03-12 15:40       ` Ian Campbell
     [not found]       ` <1394638843.3457.11.camel@kazak.uk.xensource.com>
2014-03-12 18:49         ` Zoltan Kiss
2014-03-13 10:43         ` Ian Campbell
2014-03-13 10:08 ` Ian Campbell
     [not found] ` <1394142511-14827-5-git-send-email-zoltan.kiss@citrix.com>
2014-03-13 10:17   ` [PATCH net-next v7 4/9] xen-netback: Introduce TX grant mapping Ian Campbell
2014-03-13 10:33   ` Ian Campbell
     [not found]   ` <1394705874.25873.19.camel@kazak.uk.xensource.com>
2014-03-13 12:34     ` Zoltan Kiss
     [not found]   ` <1394706812.25873.28.camel@kazak.uk.xensource.com>
2014-03-13 10:56     ` David Vrabel
     [not found]     ` <53218EDA.8040904@citrix.com>
2014-03-13 11:02       ` Ian Campbell
     [not found]       ` <1394708555.25873.43.camel@kazak.uk.xensource.com>
2014-03-13 11:09         ` David Vrabel
2014-03-13 11:13         ` Wei Liu
2014-03-13 13:17     ` Zoltan Kiss
     [not found]     ` <5321B006.9070608@citrix.com>
2014-03-13 13:56       ` Ian Campbell
     [not found]       ` <1394718990.25873.70.camel@kazak.uk.xensource.com>
2014-03-13 17:43         ` Zoltan Kiss
     [not found] ` <1394705313.25873.13.camel@kazak.uk.xensource.com>
2014-03-13 18:23   ` [PATCH net-next v7 0/9] xen-netback: TX grant mapping with SKBTX_DEV_ZEROCOPY instead of copy Zoltan Kiss
     [not found] ` <1394142511-14827-10-git-send-email-zoltan.kiss@citrix.com>
2014-03-19 21:16   ` [PATCH net-next v7 9/9] xen-netback: Aggregate TX unmap operations Zoltan Kiss
     [not found]   ` <532A0915.5090006@citrix.com>
2014-03-20  9:53     ` Paul Durrant
2014-03-20 10:48     ` Wei Liu
     [not found]     ` <20140320104855.GA16285@zion.uk.xensource.com>
2014-03-20 11:14       ` Paul Durrant
     [not found]       ` <9AAE0902D5BC7E449B7C8E4E778ABCD0292550@AMSPEX01CL01.citrite.net>
2014-03-20 12:38         ` Wei Liu
     [not found]         ` <20140320123839.GK16807@zion.uk.xensource.com>
2014-03-20 16:11           ` 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=1394142511-14827-6-git-send-email-zoltan.kiss@citrix.com \
    --to=zoltan.kiss@citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=jonathan.davies@citrix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=wei.liu2@citrix.com \
    --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;
as well as URLs for NNTP newsgroup(s).