Messages in this thread | | | From | Arnd Bergmann <> | Date | Wed, 30 Jan 2019 22:30:12 +0100 | Subject | Re: [PATCH] lib/ubsan: default UBSAN_ALIGNMENT to not set |
| |
On Wed, Jan 30, 2019 at 6:12 PM Andrey Ryabinin <aryabinin@virtuozzo.com> wrote: > On 1/30/19 4:36 AM, Andrew Morton wrote: > > On Fri, 11 Jan 2019 22:01:16 +0300 Andrey Ryabinin <aryabinin@virtuozzo.com> wrote: > >> On 12/17/18 6:03 PM, Anders Roxell wrote: > >>> When booting an allmodconfig kernel, there are a lot of false-positives. > >>> With a message like this 'UBSAN: Undefined behaviour in...' with a call > >>> trace that follows. > >>> > >>> Reworked so that when building a allmodconfig kernel that turns > >>> everything into '=m' or '=y' will turn off UBSAN_ALIGNMENT. > >>> > >>> Suggested-by: Arnd Bergmann <arnd@arndb.de> > >>> Signed-off-by: Anders Roxell <anders.roxell@linaro.org> > >>> --- > >> > >> Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com> > >> > > > > Confused. Why does allmodconfig result in UBSAN warnings? > > > > UBSAN warnings is a result of enabling noisy CONFIG_UBSAN_ALIGNMENT which is disabled > by default if HAVE_EFFICIENT_UNALIGNED_ACCESS=y. > It's noisy even if don't have efficient unaligned access, e.g. people often add > __cacheline_aligned_in_smp in structs, but forget to align allocations of such struct > (kmalloc() give 8-byte alignment in worst case).
That would be a fixable issue, but there is another one that I looked at with Anders: We have a number of list_for_each_entry_safe() loops that use a list_head on the stack and add objects of a type with large alignment. When list_for_each_entry_safe() gets to the end of that list, it sees a pointer to an unaligned structure starting few bytes before the list_head on stack. The only element of that structure that is ever used is that list_head, so there is no actual problem, but the warning triggers nonetheless.
Arnd
| |