-Walign-mismatch in block/blk-mq.c
nathanchance opened this issue · 12 comments
block/blk-mq.c:630:39: warning: passing 8-byte aligned argument to 32-byte aligned parameter 2 of 'smp_call_function_single_async' may result in an unaligned pointer access [-Walign-mismatch]
smp_call_function_single_async(cpu, &rq->csd);
^
1 warning generated.
Reported upstream due to the history behind it: https://lore.kernel.org/r/20210310182307.zzcbi5w5jrmveld4@archlinux-ax161/
@jcai19 also sent a patch for this: https://lore.kernel.org/lkml/20210330230249.709221-1-jiancai@google.com/
@groeck links to: http://crbug.com/1193732
@davidbolvansky cc'ed me on https://reviews.llvm.org/D100037 which looks somewhat related to this.
Patch sent to disable the warning for the one problematic translation unit: https://lore.kernel.org/r/20210408194458.501617-1-nathan@kernel.org/
If creating an unaligned pointer is UB...
6.3.2.3 Pointers 7 (N2176 ISO/IEC 9899:2017)
A pointer to an object type may be converted to a pointer to a different object type. If the resulting
pointer is not correctly aligned) for the referenced type, the behavior is undefined.
I wonder if we should be detecting whether the address of the pointer is at runtime a multiple of the larger aligned type and casting else memcpying the unaligned struct to an aligned-alloc'ed struct of the larger alignment, then passing a pointer to that, then freeing it.
How else do you solve such issues trying to use data that that's currently underaligned from what a caller expects, safely? Making a copy of the data is the only thing that comes to mind.
Posted a new patch: https://lore.kernel.org/lkml/20210429150940.3256656-1-arnd@kernel.org/
(Will need to backport to stable)
Merged into mainline: https://git.kernel.org/linus/1139aeb1c521eb4a050920ce6c64c36c4f2a3ab7
I can do the backports tomorrow.
Backports submitted: https://lore.kernel.org/r/YJmneuxxFWIrqyWN@archlinux-ax161/
I expect these to be picked up and released within the next couple of weeks so I am closing this up for now.