[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a0n_n+PnfYmAdS9923yheLqYXRp8=65hKf9abLCRAX8ig@mail.gmail.com>
Date: Fri, 26 Nov 2021 14:59:29 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Christophe Leroy <christophe.leroy@...roup.eu>
Cc: Anders Roxell <anders.roxell@...aro.org>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
Arnd Bergmann <arnd@...db.de>, llvm@...ts.linux.dev,
Nick Desaulniers <ndesaulniers@...gle.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Nathan Chancellor <nathan@...nel.org>,
linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [PATCH] powerpc: mm: radix_tlb: rearrange the if-else block
On Fri, Nov 26, 2021 at 2:43 PM Christophe Leroy
<christophe.leroy@...roup.eu> wrote:
> Le 25/11/2021 à 16:44, Anders Roxell a écrit :
> Can't you fix CLANG instead :) ?
>
> Or just add an else to the IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) that
> sets hstart and hend to 0 ?
That doesn't sound any less risky than duplicating the code, it can lead to
incorrect changes just as easily if a patch ends up actually flushing at the
wrong address, and the compiler fails to complain because of the bogus
initialization.
> Or just put hstart and hend calculation outside the IS_ENABLED() ? After
> all GCC should drop the calculation when not used.
I like this one. I'm still unsure how clang can get so confused about whether
the variables are initialized or not, usually it handles this much better than
gcc. My best guess is that one of the memory clobbers makes it conclude
that 'hflush' can be true when it gets written to by an inline asm.
Arnd
Powered by blists - more mailing lists