On 07/09/2018 03:23 AM, Alexey Brodkin wrote: > Hi David, > > On Mon, 2018-07-09 at 10:18 +0000, David Laight wrote: >> From: Alexey Brodkin >>> Sent: 09 July 2018 11:00 >> >> ... >>> That's a good idea indeed but it doesn't solve the problem with >>> struct devres_node. Consider the following snippet: >>> -------------------------------->8------------------------------- >>> struct mystruct { >>> atomic64_t myvar; >>> } >>> >>> struct mystruct *p; >>> p = devm_kzalloc(dev, sizeof(*p), GFP_KERNEL); >>> -------------------------------->8------------------------------- >>> >>> Here myvar address will match address of "data" member of struct devres_node. >>> So if "data" is has offset of 12 bytes from the beginning of a page then >>> myvar won't be 64-bit aligned regardless of myvar's attribute, right? >> >> ... >>>>> - unsigned long long data[]; /* guarantee ull alignment */ >> >> Ahh, that line should be: >> u8 data[] __aligned(8); /* Guarantee 64bit alignment */ > > And that pretty much what I suggested in my initial patch :) > > For the record x86 has exactly the same atomic64_t as you suggested, > see https://elixir.bootlin.com/linux/latest/source/arch/x86/include/asm/atomic64_32.h#L13: > ---------------------->8------------------ > typedef struct { > u64 __aligned(8) counter; > } atomic64_t; > ---------------------->8------------------ And so does the ARC version since when the atomic64_t support was added by commit ce6365270ecd Also, you should consider using the pre-canned type aligned_u64. typedef struct { aligned_u64 counter; ^^^^^^^^^^^ } atomic64_t;