Received: by 2002:ac0:8c8e:0:0:0:0:0 with SMTP id r14csp290262ima; Tue, 5 Feb 2019 23:27:44 -0800 (PST) X-Google-Smtp-Source: AHgI3IZVmyfeKjgoNf/GtMyXsR+UAGlpe9VeIAooUN/hpQWTbRx9+PCqmmyq8XTV8OwrxFUTMqa6 X-Received: by 2002:a63:dc53:: with SMTP id f19mr659847pgj.406.1549438064923; Tue, 05 Feb 2019 23:27:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549438064; cv=none; d=google.com; s=arc-20160816; b=eBLscQZeYPB0VhKs29HcmCyr2tIgotzKMI19+6wfs6oqTrchTxrmKCG2e5pXTbhfPH mysAuUAx/stP28tBAtNcoU8MWU2zhZrsc1yvxTt9bEJ2Yxg67LR43+vgW9YN6GLmLGM0 l3J6PZ6+0Bsw2WVPKceeT5D0GHCRTXicVc/rr3ahQtyg+4jjnambShN7laVpqM/DDwND 50UFESoyZO0+COOwMWM3NiikHXOHou5Ji/dH8vheFlRzagHeRhQ1QzuL6ZmJCqEHslGy yGltFCoJ4G9JNbwNJlo9333ryvEDC6Ui5pBCnm7z5zxrT+i9JO65zPxRfk//S98q5I/D kleg== 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=MSp/gn8dV/zWQSOiPRYSkSVSGg/P3w0x5tUxVJ+WPgs=; b=hWK59Lrtg+4NS86adDgCgqfmppAcOcBNqzcrPFPgkAT6Gx4gAMETT32r+142OCcRQq rQXW6lxf12REUY26BojZgbj1vhXtqlfEUoc68n+Liz+vnF+bI9GFFOz/Nkw3sYJxOKzU bm+ZzbZ8BW9zRTmtg4buvhAT3ae/yf8xWeH61pyjrVHR1o9PmbBvQ5uc/z4e53qlqUFT L/wuUz6sXCGF+/whPjzB844RhxnRL+6UtbTQDzGjyR58X14Jla3eVEJajD9PSIw6IWmN Q3W/WuTYcZRJAVhGMjTL+2QFQt1P/tovOcy1a8sOi7ddfyjaf6InVQ9HnDPBQP71i1JA IxVw== 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 d9si5088151pgm.133.2019.02.05.23.27.29; Tue, 05 Feb 2019 23:27:44 -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 S1728105AbfBFHZe (ORCPT + 99 others); Wed, 6 Feb 2019 02:25:34 -0500 Received: from mx2.suse.de ([195.135.220.15]:51382 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725897AbfBFHZe (ORCPT ); Wed, 6 Feb 2019 02:25:34 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id E3F1FAFBE; Wed, 6 Feb 2019 07:25:31 +0000 (UTC) Received: by unicorn.suse.cz (Postfix, from userid 1000) id AF9F6E0142; Wed, 6 Feb 2019 08:25:30 +0100 (CET) Date: Wed, 6 Feb 2019 08:25:30 +0100 From: Michal Kubecek To: netdev@vger.kernel.org Cc: Joe Perches , David Miller , thierry.reding@gmail.com, hkallweit1@gmail.com, andrew@lunn.ch, nic_swsd@realtek.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 2/2] r8169: Avoid pointer aliasing Message-ID: <20190206072530.GH21401@unicorn.suse.cz> References: <20190204164213.30727-2-thierry.reding@gmail.com> <20190204.192040.1074738183781998611.davem@davemloft.net> <8553086eaec167846992f1cff12aa388cee81767.camel@perches.com> <20190205.111404.1429981997134153696.davem@davemloft.net> <143a8f022c73c71f170eb04dc0b763f9ae83f6b5.camel@perches.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <143a8f022c73c71f170eb04dc0b763f9ae83f6b5.camel@perches.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 05, 2019 at 11:19:04AM -0800, Joe Perches wrote: > On Tue, 2019-02-05 at 11:14 -0800, David Miller wrote: > > From: Joe Perches > > Date: Tue, 05 Feb 2019 10:42:54 -0800 > > > > > On Mon, 2019-02-04 at 19:20 -0800, David Miller wrote: > > >> From: Thierry Reding > > >> Date: Mon, 4 Feb 2019 17:42:13 +0100 > > >> > > >> > @@ -7316,7 +7325,7 @@ static int rtl_get_ether_clk(struct rtl8169_private *tp) > > >> > static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) > > >> > { > > >> > const struct rtl_cfg_info *cfg = rtl_cfg_infos + ent->driver_data; > > >> > - u8 mac_addr[ETH_ALEN] __aligned(4) = {}; > > >> > + u8 mac_addr[ETH_ALEN] = {}; > > >> > struct rtl8169_private *tp; > > >> > > >> I agree with Heiner, you have to provide at least 2 byte alignment for this > > >> buffer due to the reasons he stated. > > > > > > It's declared after a pointer so it is already is 2 byte aligned. > > > > > > A lot of drivers wouldn't work otherwise. > > > > That's assuming a lot about what the compiler will do when nit allocates > > local variables to the stack. > > It's also assuming what a compiler will do when > it defines a struct. This is not a structure member, it's a local variable. I'm not aware of any C norm requirement for ordering of local variables on the stack. After all, some of them might not be on the stack at all and use only registers or be optimized out completely. Michal Kubecek