lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 2 Jun 2022 14:11:13 +0200 From: Arnd Bergmann <arnd@...db.de> To: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp> Cc: Arnd Bergmann <arnd@...db.de>, Linus Torvalds <torvalds@...ux-foundation.org>, Keisuke Nishimura <keisuke.nishimura@...ia.fr>, Kentaro Takeda <takedakn@...data.co.jp>, Ayush Sawal <ayush.sawal@...lsio.com>, Vinay Kumar Yadav <vinay.yadav@...lsio.com>, Rohit Maheshwari <rohitm@...lsio.com>, Julia Lawall <Julia.Lawall@...ia.fr>, Jani Nikula <jani.nikula@...el.com>, Sudip Mukherjee <sudipm.mukherjee@...il.com>, Russell King <linux@...linux.org.uk>, Viresh Kumar <vireshk@...nel.org>, Shiraz Hashim <shiraz.linux.kernel@...il.com>, Ville Syrjälä <ville.syrjala@...ux.intel.com>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...ux.ie>, Daniel Vetter <daniel@...ll.ch>, dri-devel <dri-devel@...ts.freedesktop.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Linux ARM <linux-arm-kernel@...ts.infradead.org>, SoC Team <soc@...nel.org> Subject: Re: mainline build failure due to f1e4c916f97f ("drm/edid: add EDID block count and size helpers") On Thu, Jun 2, 2022 at 1:21 PM Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp> 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)'. Arnd
Powered by blists - more mailing lists