Received: by 2002:ac0:b08d:0:0:0:0:0 with SMTP id l13csp4503067imc; Mon, 25 Feb 2019 06:08:56 -0800 (PST) X-Google-Smtp-Source: AHgI3IauXCiRovt6UkgQm/f2B9XxTvWw9d83s2XuXLGQ8jtODj+/uPalIkSH27STdiJfhD6/01+X X-Received: by 2002:a63:d64:: with SMTP id 36mr18730282pgn.360.1551103736044; Mon, 25 Feb 2019 06:08:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551103736; cv=none; d=google.com; s=arc-20160816; b=hlkpwoHt0L4qR9e3WdZ+QbNs88daHDAXzvsXN5I+t1o+3xlJGXQDZKS9qX8D+qDFfd TipJqlshdw+G+nscnANljPH4WIoolI0Q5S6Qj0aoZ5k4glQXxdeulD/rP+tNyFNWfubW hg7+0IvpQwir7ztYoQxHDMgtowUsiWqkKGQp0ZHy0POfaJP66T3OZl+mTGMYWFObJske WKr57c36fvXYK6pch9CA+TGISbBU04qMxsKApkPlseGwjnOMyRFuKH8hnaPhEn7ws5+h 2zUhGiefzYPY7QvRv9SAsiUgmG7rf0nRDR0AIyLaTjWlGeS1y7y8B+mdnYy/kKWQNCRX N2xw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=769UW1jFpkicoJ9TqrEkGSoKbv1B/15v8Te32rzdveM=; b=B7dyH87R5lvYUAg78ef2bkNKqNd5785HVCZf7EJSSwJiHgQhP5A8LlT//iNKXT68dq 6thyWtl/2LEO0xOpqRGYKj4uH2DgDJ+fCuFyMsmXtknj2ewXrs/qYWjj1gz8ahQbvDaQ M+0+4cnv8cv+E1zAdn6+PLZijJb6IbugfcbiFAMUWKiTlk0edTGjh4jlju7WUPYuRGef xRLn69hvcsgAgfpCGbsEAYBrsjFdM+/IrQWXezQ+yEuaxk4XMyTzOe+6jz5zaqNiVPW/ s4n0TrL9/1O4uZ2hfwaSe6y0SeUq/Z6Fbx3Zme1/L9n5vvaGpWHmMpD0i/vlE6IoZmn9 ZPdw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u27si9639108pgk.555.2019.02.25.06.08.39; Mon, 25 Feb 2019 06:08:56 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727410AbfBYOIQ (ORCPT + 99 others); Mon, 25 Feb 2019 09:08:16 -0500 Received: from charlotte.tuxdriver.com ([70.61.120.58]:55807 "EHLO smtp.tuxdriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726233AbfBYOIP (ORCPT ); Mon, 25 Feb 2019 09:08:15 -0500 Received: from cpe-2606-a000-111b-405a-9816-2c85-c514-8f7a.dyn6.twc.com ([2606:a000:111b:405a:9816:2c85:c514:8f7a] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1gyGvD-0003nF-SL; Mon, 25 Feb 2019 09:08:08 -0500 Date: Mon, 25 Feb 2019 09:07:20 -0500 From: Neil Horman To: Xin Long Cc: LKML , network dev , linux-sctp@vger.kernel.org, davem , Marcelo Ricardo Leitner Subject: Re: [PATCH net] sctp: get sctphdr by offset in sctp_compute_cksum Message-ID: <20190225140720.GC30699@hmswarspite.think-freely.org> References: <2aee76766861ac9e46b7acf123d5d6e8f2adf8e0.1551093937.git.lucien.xin@gmail.com> <20190225124614.GB30699@hmswarspite.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Score: -2.9 (--) X-Spam-Status: No Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 25, 2019 at 09:20:44PM +0800, Xin Long wrote: > On Mon, Feb 25, 2019 at 8:47 PM Neil Horman wrote: > > > > On Mon, Feb 25, 2019 at 07:25:37PM +0800, Xin Long wrote: > > > sctp_hdr(skb) only works when skb->transport_header is set properly. > > > > > > But in the path of nf_conntrack_in: sctp_packet() -> sctp_error() > > > > > > skb->transport_header is not guaranteed to be right value for sctp. > > > It will cause to fail to check the checksum for sctp packets. > > > > > > So fix it by using offset, which is always right in all places. > > > > > > Fixes: e6d8b64b34aa ("net: sctp: fix and consolidate SCTP checksumming code") > > > Reported-by: Li Shuang > > > Signed-off-by: Xin Long > > > --- > > > include/net/sctp/checksum.h | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/include/net/sctp/checksum.h b/include/net/sctp/checksum.h > > > index 32ee65a..1c6e6c0 100644 > > > --- a/include/net/sctp/checksum.h > > > +++ b/include/net/sctp/checksum.h > > > @@ -61,7 +61,7 @@ static inline __wsum sctp_csum_combine(__wsum csum, __wsum csum2, > > > static inline __le32 sctp_compute_cksum(const struct sk_buff *skb, > > > unsigned int offset) > > > { > > > - struct sctphdr *sh = sctp_hdr(skb); > > > + struct sctphdr *sh = (struct sctphdr *)(skb->data + offset); > > > const struct skb_checksum_ops ops = { > > > .update = sctp_csum_update, > > > .combine = sctp_csum_combine, > > > -- > > > 2.1.0 > > > > > > > > Shouldn't you use skb_set_transport_header and skb_transport_header here? > you mean: > skb_set_transport_header(skb, offset); > sh = sctp_hdr(skb); > ? > > There's no place counting on here to set transport_header. > It will be a kinda redundant job, yet skb is 'const'. > I'm not sure what you mean by "theres no place counting here". We have the transport header offset, and you're doing the exact same computation that that function does. It seems like we should use it in case the underlying implementation changes. I understand what you are saying regarding the use of a const variable there, but perhaps thats an argument for removing the const storage classifier. Better still, it would be good to figure out why all paths to this function don't already set the transport header offset to begin with (addressing your redundant comment) Regards Neil