Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20181217150326.30933-1-anders.roxell@linaro.org>
 <8bc73bbf-6c12-7fd1-3253-676731bf5ae5@virtuozzo.com> <20190129173634.ee579795b227b141efc8bd30@linux-foundation.org>
 <2370bfbc-762f-fb3f-79b1-483a095fdf7c@virtuozzo.com>
In-Reply-To: <2370bfbc-762f-fb3f-79b1-483a095fdf7c@virtuozzo.com>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Wed, 30 Jan 2019 22:30:12 +0100
Message-ID: <CAK8P3a1ZKyaDUjz3Zvxr0REQxyu8vWGHAbpfJ=w_XGyohe2bnw@mail.gmail.com>
Subject: Re: [PATCH] lib/ubsan: default UBSAN_ALIGNMENT to not set
To:     Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Anders Roxell <anders.roxell@linaro.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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