From patchwork Thu Jan 12 21:36:30 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Dumazet X-Patchwork-Id: 714664 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 3tzzbk5sB6z9t2p for ; Fri, 13 Jan 2017 08:36:34 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="Jwpj4sUU"; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750780AbdALVge (ORCPT ); Thu, 12 Jan 2017 16:36:34 -0500 Received: from mail-pf0-f196.google.com ([209.85.192.196]:33804 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750760AbdALVgd (ORCPT ); Thu, 12 Jan 2017 16:36:33 -0500 Received: by mail-pf0-f196.google.com with SMTP id y143so5074592pfb.1; Thu, 12 Jan 2017 13:36:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=HOibvuxtOwxqqVi11WG7voJZvSq+RVJJF+R4YMACvag=; b=Jwpj4sUUQMxxE081scnJTWxS+RaObkijCyGIo56D0VVrvdTGucgYS0tXY4zFMwlkgv xvFAkslKfa/qO60zc83pDuG6UvWJWmv8e+BDpkuLroGGHfdrmxwXkB6hvw8m8t0ZvLWw cQoNaiVXZhCKRT5V+lmj7nz43hz0rod2YK0QIPMKv2WEvAtFvtLprhantPSves7E2KGa bOU7wDlP73B+BGDmBoECVkkNJwRU957Q9KRFLWVJOXPungFAAwroBd5frzLGCB7Ekzkk JHAyN24DwoYf+L6hIvWCidfYZCk8KIQrnEuGuOWvVYWibAMCci3sqsjMnXw2nXnYidYB nQUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=HOibvuxtOwxqqVi11WG7voJZvSq+RVJJF+R4YMACvag=; b=fnWGBySaZ4yGmHnl0l1sCcWjUf/n5wiJEZRoa+kqzNu5jmzvVGjsIR8WW1UR7I+n3A BTuHVNHj+abqM6E+n/QGMQhW2FAEnXSMvjVd9v6k2ZGPy0e4I/E5U0tO4in83oEfEjXG XYJbSi8AmDyrtdpmrEZKs36mUwO790mLosjqSBW8gabE6RPvdM8kQlqaVpIwlbzw+b/i nKkpMe6ms5Jb6I8xRadV84oPg8ObjdWHde2ZUSyZkN2nMT0LRDHWcNqlcFLfN+aaZxYd PhVV4LBRtFt5OesJh6kHayYdWNzkZiriacuxKz9lfxymqKDdB1ZvRZocNKXCuzVudjla z7sg== X-Gm-Message-State: AIkVDXJzns5joL0yhTwbKUCkf2i9Uw9c153bAes2G3TSRGpi+tzgb0Lak4spvv3EEjP+cg== X-Received: by 10.99.98.132 with SMTP id w126mr20209080pgb.59.1484256991949; Thu, 12 Jan 2017 13:36:31 -0800 (PST) Received: from ?IPv6:2620:0:1000:1704:f8c5:be4f:1340:84f1? ([2620:0:1000:1704:f8c5:be4f:1340:84f1]) by smtp.googlemail.com with ESMTPSA id r2sm23860735pfi.67.2017.01.12.13.36.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 13:36:31 -0800 (PST) Message-ID: <1484256990.13165.6.camel@edumazet-glaptop3.roam.corp.google.com> Subject: Re: [PATCH] tcp: fix tcp_fastopen unaligned access complaints on sparc From: Eric Dumazet To: David Miller Cc: shannon.nelson@oracle.com, rob.gardner@oracle.com, netdev@vger.kernel.org, sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org Date: Thu, 12 Jan 2017 13:36:30 -0800 In-Reply-To: <20170112.161852.1469407145449781531.davem@davemloft.net> References: <1c39bf41-4ebf-643a-c6a0-caf98a17a89c@oracle.com> <20170112.154143.1940764507974590907.davem@davemloft.net> <131ec7b7-5b74-2545-8bf7-92812443a876@oracle.com> <20170112.161852.1469407145449781531.davem@davemloft.net> X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Sender: sparclinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: sparclinux@vger.kernel.org On Thu, 2017-01-12 at 16:18 -0500, David Miller wrote: > From: Shannon Nelson > Date: Thu, 12 Jan 2017 12:56:08 -0800 > > > > > > > On 1/12/2017 12:41 PM, David Miller wrote: > >> From: Shannon Nelson > >> Date: Thu, 12 Jan 2017 12:30:38 -0800 > >> > >>> On 1/12/2017 12:25 PM, Eric Dumazet wrote: > >>>> On Thu, 2017-01-12 at 13:15 -0700, Rob Gardner wrote: > >>>> > >>>>> > >>>>> I suspect that someplace, somebody is casting val to an int * or > >>>>> something like that. > >>>> > >>>> Then that would be the bug. Can we root cause this please ? > >>>> > >>>> > >>> > >>> Look in net/ipv4/tcp_fastopen.c:tcp_fastopen_cookie_gen() for the line > >>> > >>> struct in6_addr *buf = (struct in6_addr *) tmp.val; > >> > >> Oh yeah, that's it. I didn't notice that at all. > >> > > > > It looked to me like swapping the data fields would be the easiest and > > least impactive way to fix this. I didn't want to mess with the > > logic. I'm certainly open to other suggestions. > > Given the nature of the problem, your fix is probably fine. > > Eric, any objections? I am still objecting to this fix. gcc makes no provision for aligning an variable that has alignof() = 1 We had such issues in the past. We need the proper annotation on ->val field itself, to get proper alignment. Then moving around the other field is a matter of avoiding a hole. val should be an union, so that proper alignment is enforced by one member. --- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/include/linux/tcp.h b/include/linux/tcp.h index fc5848dad7a43216b3f124c4afdaa6b64b23910c..5b790abf4c16313c9110996683be3a7fb368b66f 100644 --- a/include/linux/tcp.h +++ b/include/linux/tcp.h @@ -62,8 +62,13 @@ static inline unsigned int tcp_optlen(const struct sk_buff *skb) /* TCP Fast Open Cookie as stored in memory */ struct tcp_fastopen_cookie { + union { + u8 val[TCP_FASTOPEN_COOKIE_MAX]; +#if IS_ENABLED(CONFIG_IPV6) + struct in6_addr addr; +#endif + }; s8 len; - u8 val[TCP_FASTOPEN_COOKIE_MAX]; bool exp; /* In RFC6994 experimental option format */ };