[PATCH v2] IP_GRE: Fix kernel panic in IP_GRE with GRE csum.

Fixed code indentation according to comments from David Miller.

--8<--------------------------cut here-------------------------->8--
Due to GSO support, GRE can recieve non linear skb which
results in panic in case of GRE_CSUM.
Following patch fixes it by using correct csum API.

Signed-off-by: Pravin B Shelar <redacted>
---
 net/ipv4/ip_gre.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 303012a..8179e066 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c

@@ -964,7 +964,10 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
 		}
 		if (tunnel->parms.o_flags&GRE_CSUM) {
 			*ptr = 0;
-			*(__sum16 *)ptr = ip_compute_csum((void *)(iph+1), skb->len - sizeof(struct iphdr));
+			*(__sum16 *)ptr = csum_fold(skb_checksum(skb,
+						    skb_transport_offset(skb),
+						    skb->len - skb_transport_offset(skb),
+						    0));
 		}
 	}
 

-- 
1.7.10

From: Pravin B Shelar <redacted>
Date: Tue, 22 Jan 2013 14:56:38 -0800

Fixed code indentation according to comments from David Miller.

--8<--------------------------cut here-------------------------->8--

This doesn't do what you think it does.  No automated tool is going
to edit the commit message the way you think this will.

You should instead put your "what is different in this revision"
comments right after the "---" below.

Due to GSO support, GRE can recieve non linear skb which
results in panic in case of GRE_CSUM.
Following patch fixes it by using correct csum API.

Signed-off-by: Pravin B Shelar <redacted>
---

 ^^^

Right after that line.

David Miller [off-list ref] writes:

From: Pravin B Shelar <redacted>
Date: Tue, 22 Jan 2013 14:56:38 -0800

quoted

Fixed code indentation according to comments from David Miller.

--8<--------------------------cut here-------------------------->8--

This doesn't do what you think it does.  No automated tool is going
to edit the commit message the way you think this will.

"git am" does if you run with --scissors, see git-am(1):

       -c, --scissors
           Remove everything in body before a scissors line (see git-
           mailinfo(1)).

and git-mailinfo(1);

       --scissors
           Remove everything in body before a scissors line. A line that
           mainly consists of scissors (either ">8" or "8<") and perforation
           (dash "-") marks is called a scissors line, and is used to request
           the reader to cut the message at that line. If such a line appears
           in the body of the message before the patch, everything before it
           (including the scissors line itself) is ignored when this option is
           used.

           This is useful if you want to begin your message in a discussion
           thread with comments and suggestions on the message you are
           responding to, and to conclude it with a patch submission,
           separating the discussion and the beginning of the proposed commit
           log message with a scissors line.

           This can enabled by default with the configuration option
           mailinfo.scissors.

From: Ben Pfaff <redacted>
Date: Tue, 22 Jan 2013 21:08:33 -0800

David Miller [off-list ref] writes:

quoted

From: Pravin B Shelar <redacted>
Date: Tue, 22 Jan 2013 14:56:38 -0800

quoted

Fixed code indentation according to comments from David Miller.

--8<--------------------------cut here-------------------------->8--

This doesn't do what you think it does.  No automated tool is going
to edit the commit message the way you think this will.

"git am" does if you run with --scissors, see git-am(1):

       -c, --scissors
           Remove everything in body before a scissors line (see git-
           mailinfo(1)).

I'd rather not have to do that for submissions, thanks.
Furthermore patchwork doesn't parse this convention either.

Pravin B Shelar wrote:

IMHO, arguments for skb_checksum() should be aligned:

			*(__sum16 *)ptr = csum_fold(skb_checksum(skb,
								 skb_transport_offset(skb),
								 skb->len - skb_transport_offset(skb),
								 0));

--yoshfuji