linux-kernel - Re: [PATCH] asm-generic: bug.h: add unreachable() in BUG() for CONFIG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a3XDY5gMUA3h3tVmQuxSHn_J3qOw_rDurzBx-KFdGhCKA@mail.gmail.com>
Date:   Sun, 17 Oct 2021 21:09:05 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Randy Dunlap <rdunlap@...radead.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        linux-arch <linux-arch@...r.kernel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>
Subject: Re: [PATCH] asm-generic: bug.h: add unreachable() in BUG() for
 CONFIG_BUG not set

On Sun, Oct 17, 2021 at 7:49 PM Randy Dunlap <rdunlap@...radead.org> wrote:
>
> When CONFIG_BUG is not set/enabled, there is a warning
> on ARCH=m68k, gcc version 11.1.0-nolibc from Arnd's crosstools:
>
> ../fs/afs/dir.c: In function 'afs_dir_set_page_dirty':
> ../fs/afs/dir.c:51:1: error: no return statement in function returning non-void [-Werror=return-type]
>
> Adding "unreachable()" in the BUG() macro silences the warning.

No, I don't think this is the right solution:

> -#define BUG() do {} while (1)
> +#define BUG() do {unreachable();} while (1)

Marking this code unreachable() means the compiler is free
to assume any code path leading here will never be entered,
which leads to additional undefined behavior and other warnings
rather than just hanging reproducibly.

The endless loop here should normally be sufficient to tell the
compiler that the function never returns, so it sounds like a
problem in gcc for m68k.

Did you see any other issues like this one on m68k, or the
same one on another architecture?

        Arnd