[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190107105334.354530758@linuxfoundation.org>
Date: Mon, 7 Jan 2019 13:32:14 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-kernel@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
stable@...r.kernel.org, Dietmar Hahn <dietmar.hahn@...fujitsu.com>,
Juergen Gross <jgross@...e.com>,
"David S. Miller" <davem@...emloft.net>
Subject: [PATCH 4.14 026/101] xen/netfront: tolerate frags with no data
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Juergen Gross <jgross@...e.com>
[ Upstream commit d81c5054a5d1d4999c7cdead7636b6cd4af83d36 ]
At least old Xen net backends seem to send frags with no real data
sometimes. In case such a fragment happens to occur with the frag limit
already reached the frontend will BUG currently even if this situation
is easily recoverable.
Modify the BUG_ON() condition accordingly.
Tested-by: Dietmar Hahn <dietmar.hahn@...fujitsu.com>
Signed-off-by: Juergen Gross <jgross@...e.com>
Signed-off-by: David S. Miller <davem@...emloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
---
drivers/net/xen-netfront.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -904,7 +904,7 @@ static RING_IDX xennet_fill_frags(struct
if (skb_shinfo(skb)->nr_frags == MAX_SKB_FRAGS) {
unsigned int pull_to = NETFRONT_SKB_CB(skb)->pull_to;
- BUG_ON(pull_to <= skb_headlen(skb));
+ BUG_ON(pull_to < skb_headlen(skb));
__pskb_pull_tail(skb, pull_to - skb_headlen(skb));
}
if (unlikely(skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS)) {
Powered by blists - more mailing lists