Message ID | 20230925155413.471287-1-arnd@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:cae8:0:b0:403:3b70:6f57 with SMTP id r8csp1323844vqu; Mon, 25 Sep 2023 09:10:57 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHWzXH54eTdoqhCTxXoWHAp1W7V8W/XtJGLtApn4pbJPF+PUhJj1vLyX5ZknPA/vQV2Vb0v X-Received: by 2002:a17:90a:de02:b0:274:9970:9f17 with SMTP id m2-20020a17090ade0200b0027499709f17mr4735821pjv.26.1695658256673; Mon, 25 Sep 2023 09:10:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695658256; cv=none; d=google.com; s=arc-20160816; b=lytJ+ninEwU9PeOeLqRkKTXJ5mn59ucUxoNsqXUKoAZxEnBSf/athBmi6QwYzP1V+p egf8n7+mbUJurCnjGFeaDetov51idVPENuW/+BuO+w2UxT6Fdyp7p6IkmhA46l2XyELr yu4nmeXvYShgRXNt0S39fDu9FPJu8+hRSc+YPODaBbKbq/ISBS566f71NZuo1xpXU2rv uWcDpY3ltmDJh2+iH17MncLYVpPcevd8qjT1I9Vj1LZEgQb0kZ0exs48WktRguDmWoFb 4iwQqV7ED+tiAMhSe1Aic4M6gJ6unBOPzoPE7gXWSus2jnM3ZLoBHhyeXLDy60NyJfq5 5UjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=eIqgsQHN1SASp/CY9HQo6XSI/oxY62+j0aF9wGSdJqM=; fh=nMj5Hw5Dr4N11JafrU82sbdbNsfLUlXaL7zXG028vUY=; b=xFGeXtNevD8ywMyWOWeEO9ryLQLm++rS0seaSa/hEKbBZpe0xuLt1haQAYMhWCuXFy m9vmZNVbwQjnDBuxht1uBrENQMcqcPf4VbCmjsOmQwYLCOq53BvzrYzxR4WJhNK79go2 zZpxt49w+TTWzhdjb3Jj+DRMVN99DNbtRB3qemT3QOerpZ5zDgR+EmmZ7Lwfv0HU/Fh0 GU6RqcPRFg5Dz7AHM9C5hcfc+z6jR1lBJFDCXkczE6PPC1W6cKWO/+oXxa6ntnWvjcMV wALKAStV17UZvsECzXm3SUTP+0eSYhOD7mDlQ7EAQQ/EQ8i+G2NkJX9PdfuuM46faMrX KyXw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Xz+FlTT0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id na7-20020a17090b4c0700b0026f4d1e6940si13896869pjb.160.2023.09.25.09.10.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Sep 2023 09:10:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Xz+FlTT0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id C951381142F1; Mon, 25 Sep 2023 08:54:39 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232539AbjIYPy1 (ORCPT <rfc822;pusanteemu@gmail.com> + 29 others); Mon, 25 Sep 2023 11:54:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56416 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232469AbjIYPy0 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 25 Sep 2023 11:54:26 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7A92092 for <linux-kernel@vger.kernel.org>; Mon, 25 Sep 2023 08:54:19 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4D79BC433C7; Mon, 25 Sep 2023 15:54:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1695657259; bh=B4lato5sKbIJfj/DcTxCJi6Fpi7KSgnK6AAG1dAv0WI=; h=From:To:Cc:Subject:Date:From; b=Xz+FlTT0VGq3tgbriqS2EDaNs11wwdg05SylJzWh/+MjuJrj6gv1A33uV0K9z5PZC uOISJiUJKkEfwop5py2fR6lDz+1iQQ6PHYEaklwFtAntZ98Sjo2CZkjVZQB6/mZ4W1 7E+xM/4XJFyE5im3h2UkBLth88NECJC+iYzwrzAW1r5CdowA+gkpxrOIGwIrt8sjW2 g7J6SLzreVvMH81sYwZlSKjZpAFTQR6r/s+P4suoajmsgKqxGuadxO7oXDBUklo+s+ cPSE8QCwH/QgHLGt4KMavTHbP2MAqnGwY8I+Cq8haydsunntR0FqvgV3tQkU46n1TB WY+A+7V+baI3w== From: Arnd Bergmann <arnd@kernel.org> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Philipp Hortmann <philipp.g.hortmann@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de>, Tree Davies <tdavies@darkphysics.net>, Yogesh Hegde <yogi.kernel@gmail.com>, Sumitra Sharma <sumitraartsy@gmail.com>, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH 1/2] staging: rtl8192e: fix structure alignment Date: Mon, 25 Sep 2023 17:54:03 +0200 Message-Id: <20230925155413.471287-1-arnd@kernel.org> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Mon, 25 Sep 2023 08:54:39 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778026551984209843 X-GMAIL-MSGID: 1778026551984209843 |
Series |
[1/2] staging: rtl8192e: fix structure alignment
|
|
Commit Message
Arnd Bergmann
Sept. 25, 2023, 3:54 p.m. UTC
From: Arnd Bergmann <arnd@arndb.de> A recent cleanup changed the rtl8192e from using the custom misaligned rtllib_hdr_3addr structure to the generic ieee80211_hdr_3addr definition that enforces 16-bit structure alignment in memory. This causes a gcc warning about conflicting alignment requirements: drivers/staging/rtl8192e/rtllib.h:645:1: error: alignment 1 of 'struct rtllib_authentication' is less than 2 [-Werror=packed-not-aligned] 645 | } __packed; | ^ rtllib.h:650:1: error: alignment 1 of 'struct rtllib_disauth' is less than 2 [-Werror=packed-not-aligned] rtllib.h:655:1: error: alignment 1 of 'struct rtllib_disassoc' is less than 2 [-Werror=packed-not-aligned] rtllib.h:661:1: error: alignment 1 of 'struct rtllib_probe_request' is less than 2 [-Werror=packed-not-aligned] rtllib.h:672:1: error: alignment 1 of 'struct rtllib_probe_response' is less than 2 [-Werror=packed-not-aligned] rtllib.h:683:1: error: alignment 1 of 'struct rtllib_assoc_request_frame' is less than 2 [-Werror=packed-not-aligned] rtllib.h:691:1: error: alignment 1 of 'struct rtllib_assoc_response_frame' is less than 2 [-Werror=packed-not-aligned] Change all of the structure definitions that include this one to also use 16-bit alignment. This assumes that the objects are actually aligned in memory, but that is normally guaranteed by the slab allocator already. All members of the structure definitions are already 16-bit aligned, so the layouts do not change. As an added benefit, 16-bit accesses are generally faster than 8-bit accesses, so architectures without unaligned load/store instructions can produce better code now by avoiding byte-wise accesses. Fixes: 71ddc43ed7c71 ("staging: rtl8192e: Replace struct rtllib_hdr_3addr in structs of rtllib.h") Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- drivers/staging/rtl8192e/rtllib.h | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
Comments
On 9/25/23 17:54, Arnd Bergmann wrote: > From: Arnd Bergmann<arnd@arndb.de> > > A recent cleanup changed the rtl8192e from using the custom misaligned > rtllib_hdr_3addr structure to the generic ieee80211_hdr_3addr definition > that enforces 16-bit structure alignment in memory. > > This causes a gcc warning about conflicting alignment requirements: > > drivers/staging/rtl8192e/rtllib.h:645:1: error: alignment 1 of 'struct rtllib_authentication' is less than 2 [-Werror=packed-not-aligned] > 645 | } __packed; > | ^ > rtllib.h:650:1: error: alignment 1 of 'struct rtllib_disauth' is less than 2 [-Werror=packed-not-aligned] > rtllib.h:655:1: error: alignment 1 of 'struct rtllib_disassoc' is less than 2 [-Werror=packed-not-aligned] > rtllib.h:661:1: error: alignment 1 of 'struct rtllib_probe_request' is less than 2 [-Werror=packed-not-aligned] > rtllib.h:672:1: error: alignment 1 of 'struct rtllib_probe_response' is less than 2 [-Werror=packed-not-aligned] > rtllib.h:683:1: error: alignment 1 of 'struct rtllib_assoc_request_frame' is less than 2 [-Werror=packed-not-aligned] > rtllib.h:691:1: error: alignment 1 of 'struct rtllib_assoc_response_frame' is less than 2 [-Werror=packed-not-aligned] > > Change all of the structure definitions that include this one to also > use 16-bit alignment. This assumes that the objects are actually aligned > in memory, but that is normally guaranteed by the slab allocator already. > > All members of the structure definitions are already 16-bit aligned, > so the layouts do not change. As an added benefit, 16-bit accesses are > generally faster than 8-bit accesses, so architectures without unaligned > load/store instructions can produce better code now by avoiding byte-wise > accesses. > > Fixes: 71ddc43ed7c71 ("staging: rtl8192e: Replace struct rtllib_hdr_3addr in structs of rtllib.h") > Signed-off-by: Arnd Bergmann<arnd@arndb.de> Hi, thanks for your support. your patches cannot be applied on top of the 24 patches which are in the queue. But may be Greg will not accept all of the patches send in. Will see what happens when Greg sorts them out. I tried your patches on hardware without the 24 patches send in. All OK Tested-by: Philipp Hortmann <philipp.g.hortmann@gmail.com> I use the following command to compile. Why I am not seeing the issue above? make "KCFLAGS=-pipe -Wpacked-not-aligned" -C . M=drivers/staging /rtl8192e Thanks Bye Philipp
On Mon, Sep 25, 2023 at 09:11:14PM +0200, Philipp Hortmann wrote: > On 9/25/23 17:54, Arnd Bergmann wrote: > > From: Arnd Bergmann<arnd@arndb.de> > > > > A recent cleanup changed the rtl8192e from using the custom misaligned > > rtllib_hdr_3addr structure to the generic ieee80211_hdr_3addr definition > > that enforces 16-bit structure alignment in memory. > > > > This causes a gcc warning about conflicting alignment requirements: > > > > drivers/staging/rtl8192e/rtllib.h:645:1: error: alignment 1 of 'struct rtllib_authentication' is less than 2 [-Werror=packed-not-aligned] > > 645 | } __packed; > > | ^ > > rtllib.h:650:1: error: alignment 1 of 'struct rtllib_disauth' is less than 2 [-Werror=packed-not-aligned] > > rtllib.h:655:1: error: alignment 1 of 'struct rtllib_disassoc' is less than 2 [-Werror=packed-not-aligned] > > rtllib.h:661:1: error: alignment 1 of 'struct rtllib_probe_request' is less than 2 [-Werror=packed-not-aligned] > > rtllib.h:672:1: error: alignment 1 of 'struct rtllib_probe_response' is less than 2 [-Werror=packed-not-aligned] > > rtllib.h:683:1: error: alignment 1 of 'struct rtllib_assoc_request_frame' is less than 2 [-Werror=packed-not-aligned] > > rtllib.h:691:1: error: alignment 1 of 'struct rtllib_assoc_response_frame' is less than 2 [-Werror=packed-not-aligned] > > > > Change all of the structure definitions that include this one to also > > use 16-bit alignment. This assumes that the objects are actually aligned > > in memory, but that is normally guaranteed by the slab allocator already. > > > > All members of the structure definitions are already 16-bit aligned, > > so the layouts do not change. As an added benefit, 16-bit accesses are > > generally faster than 8-bit accesses, so architectures without unaligned > > load/store instructions can produce better code now by avoiding byte-wise > > accesses. > > > > Fixes: 71ddc43ed7c71 ("staging: rtl8192e: Replace struct rtllib_hdr_3addr in structs of rtllib.h") > > Signed-off-by: Arnd Bergmann<arnd@arndb.de> > > Hi, > > thanks for your support. > > your patches cannot be applied on top of the 24 patches which are in the > queue. But may be Greg will not accept all of the patches send in. > > Will see what happens when Greg sorts them out. > > I tried your patches on hardware without the 24 patches send in. All OK > > Tested-by: Philipp Hortmann <philipp.g.hortmann@gmail.com> The first one didn't apply as it was already sent by someone else, but the second one applied fine, thanks. greg k-h
diff --git a/drivers/staging/rtl8192e/rtllib.h b/drivers/staging/rtl8192e/rtllib.h index 5517b9df65bee..7d26910a0b162 100644 --- a/drivers/staging/rtl8192e/rtllib.h +++ b/drivers/staging/rtl8192e/rtllib.h @@ -642,23 +642,23 @@ struct rtllib_authentication { __le16 status; /*challenge*/ struct rtllib_info_element info_element[]; -} __packed; +} __packed __aligned(2); struct rtllib_disauth { struct ieee80211_hdr_3addr header; __le16 reason; -} __packed; +} __packed __aligned(2); struct rtllib_disassoc { struct ieee80211_hdr_3addr header; __le16 reason; -} __packed; +} __packed __aligned(2); struct rtllib_probe_request { struct ieee80211_hdr_3addr header; /* SSID, supported rates */ struct rtllib_info_element info_element[]; -} __packed; +} __packed __aligned(2); struct rtllib_probe_response { struct ieee80211_hdr_3addr header; @@ -669,7 +669,7 @@ struct rtllib_probe_response { * CF params, IBSS params, TIM (if beacon), RSN */ struct rtllib_info_element info_element[]; -} __packed; +} __packed __aligned(2); /* Alias beacon for probe_response */ #define rtllib_beacon rtllib_probe_response @@ -680,7 +680,7 @@ struct rtllib_assoc_request_frame { __le16 listen_interval; /* SSID, supported rates, RSN */ struct rtllib_info_element info_element[]; -} __packed; +} __packed __aligned(2); struct rtllib_assoc_response_frame { struct ieee80211_hdr_3addr header; @@ -688,7 +688,7 @@ struct rtllib_assoc_response_frame { __le16 status; __le16 aid; struct rtllib_info_element info_element[]; /* supported rates */ -} __packed; +} __packed __aligned(2); struct rtllib_txb { u8 nr_frags;