From patchwork Tue May 3 15:10:06 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jiri Benc X-Patchwork-Id: 618027 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3qzl3w48MZz9t5V for ; Wed, 4 May 2016 01:10:52 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933470AbcECPKk (ORCPT ); Tue, 3 May 2016 11:10:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49709 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755635AbcECPKi (ORCPT ); Tue, 3 May 2016 11:10:38 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 62171C08A409; Tue, 3 May 2016 15:10:33 +0000 (UTC) Received: from griffin.localdomain (ovpn-204-105.brq.redhat.com [10.40.204.105]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u43FASJR011643; Tue, 3 May 2016 11:10:31 -0400 From: Jiri Benc To: netdev@vger.kernel.org Cc: Thomas Graf , pravin shelar , Simon Horman Subject: [PATCH net-next 1/3] gre: remove superfluous pskb_may_pull Date: Tue, 3 May 2016 17:10:06 +0200 Message-Id: <16f60994d62766aca2de269f1bfca44eb0b184ec.1462286214.git.jbenc@redhat.com> In-Reply-To: References: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org The call to gre_parse_header is either followed by iptunnel_pull_header, or in the case of ICMP error path, the actual header is not accessed at all. In the first case, iptunnel_pull_header will call pskb_may_pull anyway and it's pointless to do it twice. The only difference is what call will fail with what error code but the net effect is still the same in all call sites. In the second case, pskb_may_pull is pointless, as skb->data is at the outer IP header and not at the GRE header. Signed-off-by: Jiri Benc --- net/ipv4/gre_demux.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/net/ipv4/gre_demux.c b/net/ipv4/gre_demux.c index a41e73ab1369..d78e2eefc0f7 100644 --- a/net/ipv4/gre_demux.c +++ b/net/ipv4/gre_demux.c @@ -114,11 +114,8 @@ int gre_parse_header(struct sk_buff *skb, struct tnl_ptk_info *tpi, */ if (greh->flags == 0 && tpi->proto == htons(ETH_P_WCCP)) { tpi->proto = htons(ETH_P_IP); - if ((*(u8 *)options & 0xF0) != 0x40) { + if ((*(u8 *)options & 0xF0) != 0x40) hdr_len += 4; - if (!pskb_may_pull(skb, hdr_len)) - return -EINVAL; - } } return hdr_len; }