On Thu, 2 Jun 2022 at 14:12, Arnd Bergmann arnd@arndb.de wrote:
On Thu, Jun 2, 2022 at 1:21 PM Tetsuo Handa penguin-kernel@i-love.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)'.
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.