From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BF609C43334 for ; Thu, 2 Jun 2022 13:20:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=uYwaAcf/S+bF/ZY/z29oBHAJREvsBk0ntr0S0Y52PX0=; b=skSJEBqwGmZcKc Ce8eVAmLxLZZt8WcJjdvQjET+Xg1b/zd1/7J3xZ6t0NbWyZ0ti/Y30xOA3NMLDh6Ii9vHyhcIOCv6 mKQQnAc4Hkk64vB/VdxYUreO3MajT8+4XFNBtAZTBS672aACCfwF9Bt0xm9RR1N/8Aof0LGbeLh4T h7aPVXtcoRwVOKpTOvB8YH4+gkNT1TL6gP7TQc2ywNV+BbvAjZOL14KnXVcmAtE8H6L0nMjgh78Lq 6jF4fwqXdiS8Kvaf1Yq8MTdmJrasywEGodFXXzpsv1strFLcUnQtesc9ZjHRrqJ4aqgqw1V/M0rvm foHahCbI6+Cma/qI4URA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nwkj4-003MDx-9K; Thu, 02 Jun 2022 13:18:58 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nwkj1-003MDI-J6 for linux-arm-kernel@lists.infradead.org; Thu, 02 Jun 2022 13:18:56 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id CB45961792 for ; Thu, 2 Jun 2022 13:18:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B0DA4C341C5 for ; Thu, 2 Jun 2022 13:18:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1654175933; bh=5/p8dmgrGPA2ZsIPjOx4+AwbHaan9APIR7Tpm6W6rt8=; h=References:In-Reply-To:From:Date:Subject:To:List-Id:Cc:From; b=FN2sF6HvAolkidDJaqp2kZlxWl/5afYy7jUO3bSP1tdy+L526ThqL/pS27x+FrJDA SmKkgAp4m00bXerO1FnHQt/wFsb19k/SqeFx1xfkg5YJOtdpj0D3GxMxFlWg6jMEse HJW9guV61r1wyjaesbsOnCX582BFnbZNSFHrqj7Rf961HL2LR2m63+1LYfDeSXy3zz +WT/auDdOu7jjfjigjBEbAAUtivYxdIDK7v5P8LE7GbPlQDjgKU+ji5l2g1uaXlkAZ tomIrihsV1zujUUc8BU/FxDh9LbYjkyxSqjBQwe8YrRyl6DX+h5CWxOXgVWgJtmETZ RY/gRE3GQRUrQ== Received: by mail-oa1-f42.google.com with SMTP id 586e51a60fabf-f2bb84f9edso6666908fac.10 for ; Thu, 02 Jun 2022 06:18:53 -0700 (PDT) X-Gm-Message-State: AOAM530ZMGyoJMI9V7vv2/Kmcw/ABUcH69A87BDcTkC9mmReInlZn2AH yNfJa0tWEVhVVAQCpwKxZifqLkA435haqQwdfBc= X-Google-Smtp-Source: ABdhPJxFsJGO81CYc3f6E0d03J50Q4I8OunsbzbdfEYFCQFSEMWBIauQWtSYSJc3LAxbTKbbs0GWECI//BU8uzok/GA= X-Received: by 2002:a05:6870:eaa5:b0:da:b3f:2b45 with SMTP id s37-20020a056870eaa500b000da0b3f2b45mr20546037oap.228.1654175932711; Thu, 02 Jun 2022 06:18:52 -0700 (PDT) MIME-Version: 1.0 References: <91E67F46-A3C7-4159-9E0C-C6C6306F3669@inria.fr> <74bed19a-713f-1a25-8142-cf32984beada@I-love.SAKURA.ne.jp> In-Reply-To: From: Ard Biesheuvel Date: Thu, 2 Jun 2022 15:18:41 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: mainline build failure due to f1e4c916f97f ("drm/edid: add EDID block count and size helpers") To: Arnd Bergmann Cc: Tetsuo Handa , Linus Torvalds , Keisuke Nishimura , Kentaro Takeda , Ayush Sawal , Vinay Kumar Yadav , Rohit Maheshwari , Julia Lawall , Jani Nikula , Sudip Mukherjee , Russell King , Viresh Kumar , Shiraz Hashim , =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , dri-devel , Linux Kernel Mailing List , Linux ARM , SoC Team X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220602_061855_746253_B2BC7991 X-CRM114-Status: GOOD ( 28.47 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 2 Jun 2022 at 14:12, Arnd Bergmann wrote: > > On Thu, Jun 2, 2022 at 1:21 PM Tetsuo Handa > wrote: > > On 2022/06/02 16:38, Arnd Bergmann wrote: > > >> But let's cc the tomoyo and chelsio people. > > > > > > I think both of them work because the structures are always > > > embedded inside of larger structures that have at least word > > > alignment. This is the thing I was looking for, and the > > > __packed attribute was added in error, most likely copied > > > from somewhere else. > > > > The __packed in "struct tomoyo_shared_acl_head" is to embed next > > naturally-aligned member of a larger struct into the bytes that > > would have been wasted if __packed is not specified. For example, > > > > struct tomoyo_shared_acl_head { > > struct list_head list; > > atomic_t users; > > } __packed; > > > > struct tomoyo_condition { > > struct tomoyo_shared_acl_head head; > > u32 size; /* Memory size allocated for this entry. */ > > (...snipped...) > > }; > > > > saves 4 bytes on 64 bits build. > > > > If the next naturally-aligned member of a larger struct is larger than > > the bytes that was saved by __packed, the saved bytes will be unused. > > Ok, got it. I think as gcc should still be able to always figure out the > alignment when accessing the atomic, without ever falling back > to byte access on an atomic_get() or atomic_set(). > > To be on the safe side, I would still either move the __packed attribute > to the 'list' member, or make the structure '__aligned(4)'. > The tomoyo code generates lots of byte size accesses when built for ARMv5, but interestingly, the atomic_t accesses are emitted normally, probably due to the fact that the C api (atomic_read, atomic_set, etc) takes atomic_t pointers, and so GCC assumes natural alignment, even when inlining. But ordinary accesses of multi-byte fields in the structs in question are emitted as sequences of LDRB instructions. I understand the reason for these annotations, but I think we should drop them anyway, and just let the compiler organize the structs. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel