* Re: [Qemu-devel][PATCH] x86/cpu: Use max host physical address if -cpu max option is applied
@ 2021-01-25 18:19 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-25 18:19 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Yang Weijiang, qemu-devel, seanjc
On Mon, Jan 25, 2021 at 11:42:43AM +0100, Paolo Bonzini wrote:
> On 25/01/21 08:10, Nathan Chancellor wrote:
> > > > This patch as commit 5a140b255d ("x86/cpu: Use max host physical address
> > > > if -cpu max option is applied") prevents me from using '-cpu host' while
> > > > booting an i386_defconfig kernel.
> > > >
> > > > $ qemu-system-i386 \
> > > > -append console=ttyS0 \
> > > > -cpu host \
> > > > -display none \
> > > > -enable-kvm \
> > > > -initrd rootfs.cpio \
> > > > -kernel bzImage \
> > > > -serial mon:stdio
> > > > qemu-system-i386: phys-bits should be between 32 and 36 (but is 48)
> > > >
> > > > Am I expected to pass "-cpu host,host-phys-bits=false" now or did this
> > > > do something unexpected?
>
> Yes, it's setting the LM bit for a 32-bit guest.
>
> Does this work for you?
Yes, it does!
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 72a79e6019..70df57337f 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -5081,6 +5081,11 @@ static uint64_t
> x86_cpu_get_supported_feature_word(FeatureWord w,
> } else {
> return ~0;
> }
> +#ifdef TARGET_I386
> + if (wi->cpuid.eax = 0x80000001) {
This should be a '==':
../target/i386/cpu.c: In function ‘x86_cpu_get_supported_feature_word’:
../target/i386/cpu.c:5085:9: error: suggest parentheses around
assignment used as truth value [-Werror=parentheses]
5085 | if (wi->cpuid.eax = 0x80000001) {
| ^~
cc1: all warnings being treated as errors
> + r &= ~CPUID_EXT2_LM;
> + }
> +#endif
> if (migratable_only) {
> r &= x86_cpu_get_migratable_flags(w);
> }
>
>
> Paolo
>
> > > Hi, Nathan,
> > > Could you try Paolo's latest patch?
> > >
> > > [PULL 03/31] x86/cpu: Use max host physical address if -cpu max option is applied
> >
> > Hi Yang,
> >
> > That is the version of the patch I tried, which has been pulled into the
> > master branch.
> >
> > Cheers,
> > Nathan
> >
V>
^ permalink raw reply [relevance 99%]
* Re: [Qemu-devel][PATCH] x86/cpu: Use max host physical address if -cpu max option is applied
@ 2021-01-25 7:10 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2021-01-25 7:10 UTC (permalink / raw)
To: Yang Weijiang; +Cc: pbonzini, qemu-devel, seanjc
On Mon, Jan 25, 2021 at 01:41:50PM +0800, Yang Weijiang wrote:
> On Sun, Jan 24, 2021 at 02:08:29PM -0700, Nathan Chancellor wrote:
> > On Wed, Jan 13, 2021 at 05:04:30PM +0800, Yang Weijiang wrote:
> > > QEMU option -cpu max(max_features) means "Enables all features supported by
> > > the accelerator in the current host", this looks true for all the features
> > > except guest max physical address width, so add this patch to enable it.
> > >
> > > Signed-off-by: Yang Weijiang <weijiang.yang@intel.com>
> > > ---
> > > target/i386/cpu.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> > > index 35459a38bb..b5943406f7 100644
> > > --- a/target/i386/cpu.c
> > > +++ b/target/i386/cpu.c
> > > @@ -6673,7 +6673,7 @@ static void x86_cpu_realizefn(DeviceState *dev, Error **errp)
> > > warned = true;
> > > }
> > >
> > > - if (cpu->host_phys_bits) {
> > > + if (cpu->host_phys_bits || cpu->max_features) {
> > > /* The user asked for us to use the host physical bits */
> > > cpu->phys_bits = host_phys_bits;
> > > if (cpu->host_phys_bits_limit &&
> > > --
> > > 2.17.2
> > >
> > >
> >
> > Hi,
> >
> > This patch as commit 5a140b255d ("x86/cpu: Use max host physical address
> > if -cpu max option is applied") prevents me from using '-cpu host' while
> > booting an i386_defconfig kernel.
> >
> > $ qemu-system-i386 \
> > -append console=ttyS0 \
> > -cpu host \
> > -display none \
> > -enable-kvm \
> > -initrd rootfs.cpio \
> > -kernel bzImage \
> > -serial mon:stdio
> > qemu-system-i386: phys-bits should be between 32 and 36 (but is 48)
> >
> > Am I expected to pass "-cpu host,host-phys-bits=false" now or did this
> > do something unexpected?
> >
> Hi, Nathan,
> Could you try Paolo's latest patch?
>
> [PULL 03/31] x86/cpu: Use max host physical address if -cpu max option is applied
Hi Yang,
That is the version of the patch I tried, which has been pulled into the
master branch.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [Qemu-devel][PATCH] x86/cpu: Use max host physical address if -cpu max option is applied
@ 2021-01-24 21:08 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2021-01-24 21:08 UTC (permalink / raw)
To: Yang Weijiang; +Cc: pbonzini, qemu-devel, seanjc
On Wed, Jan 13, 2021 at 05:04:30PM +0800, Yang Weijiang wrote:
> QEMU option -cpu max(max_features) means "Enables all features supported by
> the accelerator in the current host", this looks true for all the features
> except guest max physical address width, so add this patch to enable it.
>
> Signed-off-by: Yang Weijiang <weijiang.yang@intel.com>
> ---
> target/i386/cpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 35459a38bb..b5943406f7 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -6673,7 +6673,7 @@ static void x86_cpu_realizefn(DeviceState *dev, Error **errp)
> warned = true;
> }
>
> - if (cpu->host_phys_bits) {
> + if (cpu->host_phys_bits || cpu->max_features) {
> /* The user asked for us to use the host physical bits */
> cpu->phys_bits = host_phys_bits;
> if (cpu->host_phys_bits_limit &&
> --
> 2.17.2
>
>
Hi,
This patch as commit 5a140b255d ("x86/cpu: Use max host physical address
if -cpu max option is applied") prevents me from using '-cpu host' while
booting an i386_defconfig kernel.
$ qemu-system-i386 \
-append console=ttyS0 \
-cpu host \
-display none \
-enable-kvm \
-initrd rootfs.cpio \
-kernel bzImage \
-serial mon:stdio
qemu-system-i386: phys-bits should be between 32 and 36 (but is 48)
Am I expected to pass "-cpu host,host-phys-bits=false" now or did this
do something unexpected?
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH 4.14 00/50] 4.14.217-rc1 review
@ 2021-01-22 15:42 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-22 15:42 UTC (permalink / raw)
To: Will Deacon
Cc: Naresh Kamboju, Greg Kroah-Hartman, open list, Shuah Khan,
patches, lkft-triage, linux-stable, pavel, Andrew Morton,
Linus Torvalds, Guenter Roeck, clang-built-linux, Russell King,
Arnd Bergmann, Nick Desaulniers
On Fri, Jan 22, 2021 at 03:36:04PM +0000, Will Deacon wrote:
> On Fri, Jan 22, 2021 at 08:43:18PM +0530, Naresh Kamboju wrote:
> > On Fri, 22 Jan 2021 at 20:38, Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Fri, Jan 22, 2021 at 08:32:46PM +0530, Naresh Kamboju wrote:
> > > > On Fri, 22 Jan 2021 at 19:45, Greg Kroah-Hartman
> > > > <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > This is the start of the stable review cycle for the 4.14.217 release.
> > > > > There are 50 patches in this series, all will be posted as a response
> > > > > to this one. If anyone has any issues with these being applied, please
> > > > > let me know.
> > > > >
> > > > > Responses should be made by Sun, 24 Jan 2021 13:57:23 +0000.
> > > > > Anything received after that time might be too late.
> > > > >
> > > > > The whole patch series can be found in one patch at:
> > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.217-rc1.gz
> > > > > or in the git tree and branch at:
> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
> > > > > and the diffstat can be found below.
> > > > >
> > > > > thanks,
> > > > >
> > > > > greg k-h
> > > >
> > > > arm64 clang-10 builds breaks due to this patch on
> > > > - stable-rc 4.14
> > > > - stable-rc 4.9
> > > > - stable-rc 4.4
> > > >
> > > > > Will Deacon <will@kernel.org>
> > > > > compiler.h: Raise minimum version of GCC to 5.1 for arm64
> > > >
> > > > arm64 (defconfig) with clang-10 - FAILED
> > >
> > > How is a clang build breaking on a "check what version of gcc is being
> > > used" change?
> > >
> > > What is the error message?
> >
> > make --silent --keep-going --jobs=8
> > O=/home/tuxbuild/.cache/tuxmake/builds/1/tmp ARCH=arm64
> > CROSS_COMPILE=aarch64-linux-gnu- 'HOSTCC=sccache clang' 'CC=sccache
> > clang'
> > In file included from <built-in>:1:
> > include/linux/kconfig.h:74:
> > include/linux/compiler_types.h:58:
> > include/linux/compiler-gcc.h:160:3: error: Sorry, your version of GCC
> > is too old - please use 5.1 or newer.
> > # error Sorry, your version of GCC is too old - please use 5.1 or newer.
> > ^
> > 1 error generated.
> >
> > build error link:
> > https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc/-/jobs/980489003#L514
>
> Urgh, looks like we need backports of 815f0ddb346c
> ("include/linux/compiler*.h: make compiler-*.h mutually exclusive") then.
>
> Greg -- please drop my changes from 4.14, 4.9 and 4.4 for now and I'll
> look at this next week.
That backport is going to be pretty gnarly, there was a pretty decent
tailwind of fixes around that patch IIRC.
The simple solution would be to stick a !defined(__clang__) in that
preprocessor conditional so that it truly fires only for GCC.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: arch/riscv/kernel/vdso/vdso-syms.S:2: Error: junk at end of line, first unrecognized character is `@'
@ 2021-01-22 7:08 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-22 7:08 UTC (permalink / raw)
To: kernel test robot
Cc: Palmer Dabbelt, kbuild-all, clang-built-linux, linux-kernel
On Fri, Jan 22, 2021 at 09:41:35AM +0800, kernel test robot wrote:
> Hi Palmer,
>
> First bad commit (maybe != root cause):
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head: 9f29bd8b2e7132b409178d1367dae1813017bd0e
> commit: c2c81bb2f69138f902e1a58d3bef6ad97fb8a92c RISC-V: Fix the VDSO symbol generaton for binutils-2.35+
> date: 3 months ago
> config: riscv-randconfig-r002-20210122 (attached as .config)
> compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project bd3a387ee76f58caa0d7901f3f84e9bb3d006f27)
> reproduce (this is a W=1 build):
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # install riscv cross compiling tool for clang build
> # apt-get install binutils-riscv64-linux-gnu
> # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c2c81bb2f69138f902e1a58d3bef6ad97fb8a92c
> git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> git fetch --no-tags linus master
> git checkout c2c81bb2f69138f902e1a58d3bef6ad97fb8a92c
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=riscv
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
>
> All errors (new ones prefixed by >>):
>
> arch/riscv/kernel/vdso/vdso-syms.S: Assembler messages:
> >> arch/riscv/kernel/vdso/vdso-syms.S:2: Error: junk at end of line, first unrecognized character is `@'
> arch/riscv/kernel/vdso/vdso-syms.S:4: Error: junk at end of line, first unrecognized character is `@'
> arch/riscv/kernel/vdso/vdso-syms.S:6: Error: junk at end of line, first unrecognized character is `@'
> arch/riscv/kernel/vdso/vdso-syms.S:8: Error: junk at end of line, first unrecognized character is `@'
> arch/riscv/kernel/vdso/vdso-syms.S:10: Error: junk at end of line, first unrecognized character is `@'
> arch/riscv/kernel/vdso/vdso-syms.S:12: Error: junk at end of line, first unrecognized character is `@'
> clang-12: error: assembler command failed with exit code 1 (use -v to see invocation)
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
I believe this is https://github.com/ClangBuiltLinux/linux/issues/1266.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* [PATCH] mm/zswap: Add return value in zswap_frontswap_load
@ 2021-01-21 21:48 96% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-21 21:48 UTC (permalink / raw)
To: Andrew Morton
Cc: Seth Jennings, Dan Streetman, Vitaly Wool, Nick Desaulniers,
Tian Tao, linux-mm, linux-kernel, clang-built-linux,
Nathan Chancellor, kernelci . org bot, kernel test robot
Clang warns:
mm/zswap.c:1271:6: warning: variable 'ret' is used uninitialized
whenever 'if' condition is true [-Wsometimes-uninitialized]
if (!entry->length) {
^~~~~~~~~~~~~~
mm/zswap.c:1322:9: note: uninitialized use occurs here
return ret;
^~~
mm/zswap.c:1271:2: note: remove the 'if' if its condition is always
false
if (!entry->length) {
^~~~~~~~~~~~~~~~~~~~~
mm/zswap.c:1259:9: note: initialize the variable 'ret' to silence this
warning
int ret;
^
= 0
1 warning generated.
Prior to "mm/zswap: add the flag can_sleep_mapped", this path always
returned 0. Restore that so we are not returning uninitialized memory.
Link: https://github.com/ClangBuiltLinux/linux/issues/1263
Reported-by: kernelci.org bot <bot@kernelci.org>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
Andrew, please fold this into
mm-zswap-add-the-flag-can_sleep_mapped.patch
mm/zswap.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/zswap.c b/mm/zswap.c
index 6e0bb61d2a2c..a85334b719b9 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -1272,6 +1272,7 @@ static int zswap_frontswap_load(unsigned type, pgoff_t offset,
dst = kmap_atomic(page);
zswap_fill_page(dst, entry->value);
kunmap_atomic(dst);
+ ret = 0;
goto freeentry;
}
base-commit: bc085f8fc88fc16796c9f2364e2bfb3fef305cad
--
2.30.0
^ permalink raw reply related [relevance 96%]
* Re: [PATCH] MAINTAINERS: adjust to clang-version.sh removal
@ 2021-01-21 16:16 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-21 16:16 UTC (permalink / raw)
To: Lukas Bulwahn, Andrew Morton
Cc: Masahiro Yamada, linux-kbuild, Nick Desaulniers,
clang-built-linux, Joe Perches, Ralf Ramsauer, Pia Eichinger,
kernel-janitors, linux-kernel
On Thu, Jan 21, 2021 at 05:01:15PM +0100, Lukas Bulwahn wrote:
> Commit 6c8ad4427f6e ("kbuild: check the minimum compiler version in
> Kconfig") removed ./scripts/clang-version.sh and moved its content to
> ./scripts/cc-version.sh.
>
> Since then, ./scripts/get_maintainer.pl --self-test=patterns complains:
>
> warning: no file matches F: scripts/clang-version.sh
>
> The CLANG/LLVM BUILD SUPPORT section in MAINTAINERS intends to track
> changes in ./scripts/clang-version.sh; as the file is removed, track
> changes in ./scripts/cc-version.sh instead now.
>
> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
> ---
> applies cleanly on next-20210121
>
> Masahiro-san, please pick this quick fix-up patch.
Masahiro cannot pick this up because the patch to add clang-version.sh
to MAINTAINERS is in mmotm.
I think the better solution is for Andrew to drop the current version of
maintainers-add-a-couple-more-files-to-the-clang-llvm-section.patch
and pick up the second one I sent, which allows us to deal with this:
https://lore.kernel.org/lkml/20210114171629.592007-1-natechancellor@gmail.com/
I am not sure it is right for us to maintain cc-version.sh but I am open
to it if Masahiro agrees.
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e5d7cf38ec82..aafbea806a82 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4355,8 +4355,8 @@ B: https://github.com/ClangBuiltLinux/linux/issues
> C: irc://chat.freenode.net/clangbuiltlinux
> F: Documentation/kbuild/llvm.rst
> F: include/linux/compiler-clang.h
> +F: scripts/cc-version.sh
> F: scripts/clang-tools/
> -F: scripts/clang-version.sh
> F: scripts/lld-version.sh
> K: \b(?i:clang|llvm)\b
>
> --
> 2.17.1
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] MAINTAINERS: adjust to clang-version.sh removal
@ 2021-01-21 16:16 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-21 16:16 UTC (permalink / raw)
To: Lukas Bulwahn, Andrew Morton
Cc: Masahiro Yamada, linux-kbuild, Nick Desaulniers,
clang-built-linux, Joe Perches, Ralf Ramsauer, Pia Eichinger,
kernel-janitors, linux-kernel
On Thu, Jan 21, 2021 at 05:01:15PM +0100, Lukas Bulwahn wrote:
> Commit 6c8ad4427f6e ("kbuild: check the minimum compiler version in
> Kconfig") removed ./scripts/clang-version.sh and moved its content to
> ./scripts/cc-version.sh.
>
> Since then, ./scripts/get_maintainer.pl --self-test=patterns complains:
>
> warning: no file matches F: scripts/clang-version.sh
>
> The CLANG/LLVM BUILD SUPPORT section in MAINTAINERS intends to track
> changes in ./scripts/clang-version.sh; as the file is removed, track
> changes in ./scripts/cc-version.sh instead now.
>
> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
> ---
> applies cleanly on next-20210121
>
> Masahiro-san, please pick this quick fix-up patch.
Masahiro cannot pick this up because the patch to add clang-version.sh
to MAINTAINERS is in mmotm.
I think the better solution is for Andrew to drop the current version of
maintainers-add-a-couple-more-files-to-the-clang-llvm-section.patch
and pick up the second one I sent, which allows us to deal with this:
https://lore.kernel.org/lkml/20210114171629.592007-1-natechancellor@gmail.com/
I am not sure it is right for us to maintain cc-version.sh but I am open
to it if Masahiro agrees.
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e5d7cf38ec82..aafbea806a82 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4355,8 +4355,8 @@ B: https://github.com/ClangBuiltLinux/linux/issues
> C: irc://chat.freenode.net/clangbuiltlinux
> F: Documentation/kbuild/llvm.rst
> F: include/linux/compiler-clang.h
> +F: scripts/cc-version.sh
> F: scripts/clang-tools/
> -F: scripts/clang-version.sh
> F: scripts/lld-version.sh
> K: \b(?i:clang|llvm)\b
>
> --
> 2.17.1
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH bpf-next v3] samples/bpf: Update build procedure for manually compiling LLVM and Clang
@ 2021-01-21 14:23 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-21 14:23 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Tiezhu Yang, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Nick Desaulniers, Networking, bpf,
clang-built-linux, open list, Xuefeng Li, Fangrui Song
On Thu, Jan 21, 2021 at 12:08:31AM -0800, Andrii Nakryiko wrote:
> On Wed, Jan 20, 2021 at 9:36 PM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> >
> > On Thu, Jan 21, 2021 at 01:27:35PM +0800, Tiezhu Yang wrote:
> > > The current LLVM and Clang build procedure in samples/bpf/README.rst is
> > > out of date. See below that the links are not accessible any more.
> > >
> > > $ git clone http://llvm.org/git/llvm.git
> > > Cloning into 'llvm'...
> > > fatal: unable to access 'http://llvm.org/git/llvm.git/': Maximum (20) redirects followed
> > > $ git clone --depth 1 http://llvm.org/git/clang.git
> > > Cloning into 'clang'...
> > > fatal: unable to access 'http://llvm.org/git/clang.git/': Maximum (20) redirects followed
> > >
> > > The LLVM community has adopted new ways to build the compiler. There are
> > > different ways to build LLVM and Clang, the Clang Getting Started page [1]
> > > has one way. As Yonghong said, it is better to copy the build procedure
> > > in Documentation/bpf/bpf_devel_QA.rst to keep consistent.
> > >
> > > I verified the procedure and it is proved to be feasible, so we should
> > > update README.rst to reflect the reality. At the same time, update the
> > > related comment in Makefile.
> > >
> > > Additionally, as Fangrui said, the dir llvm-project/llvm/build/install is
> > > not used, BUILD_SHARED_LIBS=OFF is the default option [2], so also change
> > > Documentation/bpf/bpf_devel_QA.rst together.
> > >
> > > [1] https://clang.llvm.org/get_started.html
> > > [2] https://www.llvm.org/docs/CMake.html
> > >
> > > Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
> > > Acked-by: Yonghong Song <yhs@fb.com>
> >
> > Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> >
> > Small comment below.
> >
> > > ---
> > >
> > > v2: Update the commit message suggested by Yonghong,
> > > thank you very much.
> > >
> > > v3: Remove the default option BUILD_SHARED_LIBS=OFF
> > > and just mkdir llvm-project/llvm/build suggested
> > > by Fangrui.
> > >
> > > Documentation/bpf/bpf_devel_QA.rst | 3 +--
> > > samples/bpf/Makefile | 2 +-
> > > samples/bpf/README.rst | 16 +++++++++-------
> > > 3 files changed, 11 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/Documentation/bpf/bpf_devel_QA.rst b/Documentation/bpf/bpf_devel_QA.rst
> > > index 5b613d2..18788bb 100644
> > > --- a/Documentation/bpf/bpf_devel_QA.rst
> > > +++ b/Documentation/bpf/bpf_devel_QA.rst
> > > @@ -506,11 +506,10 @@ that set up, proceed with building the latest LLVM and clang version
> > > from the git repositories::
> > >
> > > $ git clone https://github.com/llvm/llvm-project.git
> > > - $ mkdir -p llvm-project/llvm/build/install
> > > + $ mkdir -p llvm-project/llvm/build
> > > $ cd llvm-project/llvm/build
> > > $ cmake .. -G "Ninja" -DLLVM_TARGETS_TO_BUILD="BPF;X86" \
> > > -DLLVM_ENABLE_PROJECTS="clang" \
> > > - -DBUILD_SHARED_LIBS=OFF \
> > > -DCMAKE_BUILD_TYPE=Release \
> > > -DLLVM_BUILD_RUNTIME=OFF
> > > $ ninja
> > > diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
> > > index 26fc96c..d061446 100644
> > > --- a/samples/bpf/Makefile
> > > +++ b/samples/bpf/Makefile
> > > @@ -208,7 +208,7 @@ TPROGLDLIBS_xdpsock += -pthread -lcap
> > > TPROGLDLIBS_xsk_fwd += -pthread
> > >
> > > # Allows pointing LLC/CLANG to a LLVM backend with bpf support, redefine on cmdline:
> > > -# make M=samples/bpf/ LLC=~/git/llvm/build/bin/llc CLANG=~/git/llvm/build/bin/clang
> > > +# make M=samples/bpf LLC=~/git/llvm-project/llvm/build/bin/llc CLANG=~/git/llvm-project/llvm/build/bin/clang
> > > LLC ?= llc
> > > CLANG ?= clang
> > > OPT ?= opt
> > > diff --git a/samples/bpf/README.rst b/samples/bpf/README.rst
> > > index dd34b2d..23006cb 100644
> > > --- a/samples/bpf/README.rst
> > > +++ b/samples/bpf/README.rst
> > > @@ -65,17 +65,19 @@ To generate a smaller llc binary one can use::
> > > Quick sniplet for manually compiling LLVM and clang
> > > (build dependencies are cmake and gcc-c++)::
> >
> > Technically, ninja is now a build dependency as well, it might be worth
> > mentioning that here (usually the package is ninja or ninja-build).
>
> it's possible to generate Makefile by passing `-g "Unix Makefiles"`,
> which would avoid dependency on ninja, no?
Yes, although I am fairly certain that building with ninja is quicker so
I would recommend keeping it. One small extra dependency never killed
anyone plus ninja is becoming more common nowadays :)
> > Regardless of whether that is addressed or not (because it is small),
> > feel free to carry forward my tag in any future revisions unless they
> > drastically change.
> >
> > > - $ git clone http://llvm.org/git/llvm.git
> > > - $ cd llvm/tools
> > > - $ git clone --depth 1 http://llvm.org/git/clang.git
> > > - $ cd ..; mkdir build; cd build
> > > - $ cmake .. -DLLVM_TARGETS_TO_BUILD="BPF;X86"
> > > - $ make -j $(getconf _NPROCESSORS_ONLN)
> > > + $ git clone https://github.com/llvm/llvm-project.git
> > > + $ mkdir -p llvm-project/llvm/build
> > > + $ cd llvm-project/llvm/build
> > > + $ cmake .. -G "Ninja" -DLLVM_TARGETS_TO_BUILD="BPF;X86" \
> > > + -DLLVM_ENABLE_PROJECTS="clang" \
> > > + -DCMAKE_BUILD_TYPE=Release \
> > > + -DLLVM_BUILD_RUNTIME=OFF
> > > + $ ninja
> > >
> > > It is also possible to point make to the newly compiled 'llc' or
> > > 'clang' command via redefining LLC or CLANG on the make command line::
> > >
> > > - make M=samples/bpf LLC=~/git/llvm/build/bin/llc CLANG=~/git/llvm/build/bin/clang
> > > + make M=samples/bpf LLC=~/git/llvm-project/llvm/build/bin/llc CLANG=~/git/llvm-project/llvm/build/bin/clang
> > >
> > > Cross compiling samples
> > > -----------------------
> > > --
> > > 2.1.0
> > >
^ permalink raw reply [relevance 99%]
* Re: [PATCH bpf-next v3] samples/bpf: Update build procedure for manually compiling LLVM and Clang
@ 2021-01-21 5:36 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2021-01-21 5:36 UTC (permalink / raw)
To: Tiezhu Yang
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Nick Desaulniers, netdev, bpf, clang-built-linux,
linux-kernel, Xuefeng Li, Fangrui Song
On Thu, Jan 21, 2021 at 01:27:35PM +0800, Tiezhu Yang wrote:
> The current LLVM and Clang build procedure in samples/bpf/README.rst is
> out of date. See below that the links are not accessible any more.
>
> $ git clone http://llvm.org/git/llvm.git
> Cloning into 'llvm'...
> fatal: unable to access 'http://llvm.org/git/llvm.git/': Maximum (20) redirects followed
> $ git clone --depth 1 http://llvm.org/git/clang.git
> Cloning into 'clang'...
> fatal: unable to access 'http://llvm.org/git/clang.git/': Maximum (20) redirects followed
>
> The LLVM community has adopted new ways to build the compiler. There are
> different ways to build LLVM and Clang, the Clang Getting Started page [1]
> has one way. As Yonghong said, it is better to copy the build procedure
> in Documentation/bpf/bpf_devel_QA.rst to keep consistent.
>
> I verified the procedure and it is proved to be feasible, so we should
> update README.rst to reflect the reality. At the same time, update the
> related comment in Makefile.
>
> Additionally, as Fangrui said, the dir llvm-project/llvm/build/install is
> not used, BUILD_SHARED_LIBS=OFF is the default option [2], so also change
> Documentation/bpf/bpf_devel_QA.rst together.
>
> [1] https://clang.llvm.org/get_started.html
> [2] https://www.llvm.org/docs/CMake.html
>
> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
> Acked-by: Yonghong Song <yhs@fb.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Small comment below.
> ---
>
> v2: Update the commit message suggested by Yonghong,
> thank you very much.
>
> v3: Remove the default option BUILD_SHARED_LIBS=OFF
> and just mkdir llvm-project/llvm/build suggested
> by Fangrui.
>
> Documentation/bpf/bpf_devel_QA.rst | 3 +--
> samples/bpf/Makefile | 2 +-
> samples/bpf/README.rst | 16 +++++++++-------
> 3 files changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/bpf/bpf_devel_QA.rst b/Documentation/bpf/bpf_devel_QA.rst
> index 5b613d2..18788bb 100644
> --- a/Documentation/bpf/bpf_devel_QA.rst
> +++ b/Documentation/bpf/bpf_devel_QA.rst
> @@ -506,11 +506,10 @@ that set up, proceed with building the latest LLVM and clang version
> from the git repositories::
>
> $ git clone https://github.com/llvm/llvm-project.git
> - $ mkdir -p llvm-project/llvm/build/install
> + $ mkdir -p llvm-project/llvm/build
> $ cd llvm-project/llvm/build
> $ cmake .. -G "Ninja" -DLLVM_TARGETS_TO_BUILD="BPF;X86" \
> -DLLVM_ENABLE_PROJECTS="clang" \
> - -DBUILD_SHARED_LIBS=OFF \
> -DCMAKE_BUILD_TYPE=Release \
> -DLLVM_BUILD_RUNTIME=OFF
> $ ninja
> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
> index 26fc96c..d061446 100644
> --- a/samples/bpf/Makefile
> +++ b/samples/bpf/Makefile
> @@ -208,7 +208,7 @@ TPROGLDLIBS_xdpsock += -pthread -lcap
> TPROGLDLIBS_xsk_fwd += -pthread
>
> # Allows pointing LLC/CLANG to a LLVM backend with bpf support, redefine on cmdline:
> -# make M=samples/bpf/ LLC=~/git/llvm/build/bin/llc CLANG=~/git/llvm/build/bin/clang
> +# make M=samples/bpf LLC=~/git/llvm-project/llvm/build/bin/llc CLANG=~/git/llvm-project/llvm/build/bin/clang
> LLC ?= llc
> CLANG ?= clang
> OPT ?= opt
> diff --git a/samples/bpf/README.rst b/samples/bpf/README.rst
> index dd34b2d..23006cb 100644
> --- a/samples/bpf/README.rst
> +++ b/samples/bpf/README.rst
> @@ -65,17 +65,19 @@ To generate a smaller llc binary one can use::
> Quick sniplet for manually compiling LLVM and clang
> (build dependencies are cmake and gcc-c++)::
Technically, ninja is now a build dependency as well, it might be worth
mentioning that here (usually the package is ninja or ninja-build).
Regardless of whether that is addressed or not (because it is small),
feel free to carry forward my tag in any future revisions unless they
drastically change.
> - $ git clone http://llvm.org/git/llvm.git
> - $ cd llvm/tools
> - $ git clone --depth 1 http://llvm.org/git/clang.git
> - $ cd ..; mkdir build; cd build
> - $ cmake .. -DLLVM_TARGETS_TO_BUILD="BPF;X86"
> - $ make -j $(getconf _NPROCESSORS_ONLN)
> + $ git clone https://github.com/llvm/llvm-project.git
> + $ mkdir -p llvm-project/llvm/build
> + $ cd llvm-project/llvm/build
> + $ cmake .. -G "Ninja" -DLLVM_TARGETS_TO_BUILD="BPF;X86" \
> + -DLLVM_ENABLE_PROJECTS="clang" \
> + -DCMAKE_BUILD_TYPE=Release \
> + -DLLVM_BUILD_RUNTIME=OFF
> + $ ninja
>
> It is also possible to point make to the newly compiled 'llc' or
> 'clang' command via redefining LLC or CLANG on the make command line::
>
> - make M=samples/bpf LLC=~/git/llvm/build/bin/llc CLANG=~/git/llvm/build/bin/clang
> + make M=samples/bpf LLC=~/git/llvm-project/llvm/build/bin/llc CLANG=~/git/llvm-project/llvm/build/bin/clang
>
> Cross compiling samples
> -----------------------
> --
> 2.1.0
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH v5 2/3] Kbuild: make DWARF version a choice
@ 2021-01-20 20:40 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-20 20:40 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Masahiro Yamada, Andrew Morton, Sedat Dilek, linux-kernel,
clang-built-linux, linux-kbuild, linux-arch, Jakub Jelinek,
Fangrui Song, Caroline Tice, Nick Clifton, Yonghong Song,
Jiri Olsa, Andrii Nakryiko, Arnaldo Carvalho de Melo,
Arvind Sankar
On Fri, Jan 15, 2021 at 01:06:15PM -0800, Nick Desaulniers wrote:
> Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice. Adds an
> explicit CONFIG_DEBUG_INFO_DWARF2, which is the default. Does so in a
> way that's forward compatible with existing configs, and makes adding
> future versions more straightforward.
>
> Suggested-by: Arvind Sankar <nivedita@alum.mit.edu>
> Suggested-by: Fangrui Song <maskray@google.com>
> Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> ---
> Makefile | 13 ++++++-------
> lib/Kconfig.debug | 21 ++++++++++++++++-----
> 2 files changed, 22 insertions(+), 12 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index d49c3f39ceb4..4eb3bf7ee974 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -826,13 +826,12 @@ else
> DEBUG_CFLAGS += -g
> endif
>
> -ifneq ($(LLVM_IAS),1)
> -KBUILD_AFLAGS += -Wa,-gdwarf-2
> -endif
Aren't you regressing this with this patch? Why is the hunk from 3/3
that adds
ifdef CONFIG_CC_IS_CLANG
ifneq ($(LLVM_IAS),1)
not in this patch?
> -ifdef CONFIG_DEBUG_INFO_DWARF4
> -DEBUG_CFLAGS += -gdwarf-4
> -endif
> +dwarf-version-$(CONFIG_DEBUG_INFO_DWARF2) := 2
> +dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
> +DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y)
> +# Binutils 2.35+ required for -gdwarf-4+ support.
> +dwarf-aflag := $(call as-option,-Wa$(comma)-gdwarf-$(dwarf-version-y))
> +KBUILD_AFLAGS += $(dwarf-aflag)
>
> ifdef CONFIG_DEBUG_INFO_REDUCED
> DEBUG_CFLAGS += $(call cc-option, -femit-struct-debug-baseonly) \
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index dd7d8d35b2a5..e80770fac4f0 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -256,13 +256,24 @@ config DEBUG_INFO_SPLIT
> to know about the .dwo files and include them.
> Incompatible with older versions of ccache.
>
> +choice
> + prompt "DWARF version"
> + help
> + Which version of DWARF debug info to emit.
> +
> +config DEBUG_INFO_DWARF2
> + bool "Generate DWARF Version 2 debuginfo"
> + help
> + Generate DWARF v2 debug info.
> +
> config DEBUG_INFO_DWARF4
> - bool "Generate dwarf4 debuginfo"
> + bool "Generate DWARF Version 4 debuginfo"
> help
> - Generate dwarf4 debug info. This requires recent versions
> - of gcc and gdb. It makes the debug information larger.
> - But it significantly improves the success of resolving
> - variables in gdb on optimized code.
> + Generate DWARF v4 debug info. This requires gcc 4.5+ and gdb 7.0+.
> + It makes the debug information larger, but it significantly
> + improves the success of resolving variables in gdb on optimized code.
> +
> +endchoice # "DWARF version"
>
> config DEBUG_INFO_BTF
> bool "Generate BTF typeinfo"
> --
> 2.30.0.284.gd98b1dd5eaa7-goog
>
^ permalink raw reply [relevance 99%]
* Re: [STABLE BACKPORT 4.4.y, 4.9.y and 4.14.y] compiler.h: Raise minimum version of GCC to 5.1 for arm64
@ 2021-01-19 23:29 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-19 23:29 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Will Deacon, Greg KH, Arnd Bergmann, # 3.4.x, LKML, Russell King,
Linus Torvalds, Theodore Ts'o, Florian Weimer,
Peter Zijlstra, Catalin Marinas, Caroline Tice, Luis Lozano,
Stephen Hines
On Tue, Jan 19, 2021 at 02:15:43PM -0800, Nick Desaulniers wrote:
> On Mon, Jan 18, 2021 at 5:54 AM Will Deacon <will@kernel.org> wrote:
> >
> > commit dca5244d2f5b94f1809f0c02a549edf41ccd5493 upstream.
> >
> > GCC versions >= 4.9 and < 5.1 have been shown to emit memory references
> > beyond the stack pointer, resulting in memory corruption if an interrupt
> > is taken after the stack pointer has been adjusted but before the
> > reference has been executed. This leads to subtle, infrequent data
> > corruption such as the EXT4 problems reported by Russell King at the
> > link below.
> >
> > Life is too short for buggy compilers, so raise the minimum GCC version
> > required by arm64 to 5.1.
> >
> > Reported-by: Russell King <linux@armlinux.org.uk>
> > Suggested-by: Arnd Bergmann <arnd@kernel.org>
> > Signed-off-by: Will Deacon <will@kernel.org>
> > Tested-by: Nathan Chancellor <natechancellor@gmail.com>
> > Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> > Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> > Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
> > Cc: <stable@vger.kernel.org> # 4.4.y, 4.9.y and 4.14.y only
> > Cc: Theodore Ts'o <tytso@mit.edu>
> > Cc: Florian Weimer <fweimer@redhat.com>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Cc: Nick Desaulniers <ndesaulniers@google.com>
> > Link: https://lore.kernel.org/r/20210105154726.GD1551@shell.armlinux.org.uk
> > Link: https://lore.kernel.org/r/20210112224832.10980-1-will@kernel.org
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > [will: backport to 4.4.y/4.9.y/4.14.y]
>
> Merging this from stable into "Android Common Kernel" trees that were
> built with AOSP GCC 4.9, I expect this to break some builds. Arnd,
> IIRC did you mention that AOSP GCC had picked up a fix? If so, did
> you verify that via disassembly, or gerrit patch file?
>
> (AOSP GCC 4.9: https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/
> master branch, roll back a few commits).
> It looks like AOSP GCC `#defines __android__ 1`.
It seems like this is the source for that toolchain?
https://android.googlesource.com/toolchain/gcc
If so, it looks like that patch was picked up in this commit.
https://android.googlesource.com/toolchain/gcc/+/5ae0308a147ec3f6502fd321860524e634a647a6
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH v4 1/2] arm: lib: xor-neon: remove unnecessary GCC < 4.6 warning
@ 2021-01-19 21:54 95% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-19 21:54 UTC (permalink / raw)
To: Adrian Ratiu
Cc: linux-arm-kernel, Nick Desaulniers, Arnd Bergmann, Russell King,
Ard Biesheuvel, Arvind Sankar, clang-built-linux, kernel,
Linux Kernel Mailing List
On Tue, Jan 19, 2021 at 03:17:23PM +0200, Adrian Ratiu wrote:
> From: Nathan Chancellor <natechancellor@gmail.com>
>
> Drop warning because kernel now requires GCC >= v4.9 after
> commit 6ec4476ac825 ("Raise gcc version requirement to 4.9")
> and clarify that -ftree-vectorize now always needs enabling
> for GCC by directly testing the presence of CONFIG_CC_IS_GCC.
>
> Another reason to remove the warning is that Clang exposes
> itself as GCC < 4.6 so it triggers the warning about GCC
> which doesn't make much sense and misleads Clang users by
> telling them to update GCC.
>
> Because Clang is now supported by the kernel print a clear
> Clang-specific warning.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/496
> Link: https://github.com/ClangBuiltLinux/linux/issues/503
> Reported-by: Nick Desaulniers <ndesaulniers@google.com>
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
The commit message looks like it is written by me but I never added a
Clang specific warning. I appreciate wanting to give me credit but when
you change things about my original commit message, please make it
clear that you did the edits, something like:
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
[adrian: Add clang specific warning]
Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
> ---
> arch/arm/lib/xor-neon.c | 18 ++++++++++--------
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/lib/xor-neon.c b/arch/arm/lib/xor-neon.c
> index b99dd8e1c93f..f9f3601cc2d1 100644
> --- a/arch/arm/lib/xor-neon.c
> +++ b/arch/arm/lib/xor-neon.c
> @@ -14,20 +14,22 @@ MODULE_LICENSE("GPL");
> #error You should compile this file with '-march=armv7-a -mfloat-abi=softfp -mfpu=neon'
> #endif
>
> +/*
> + * TODO: Even though -ftree-vectorize is enabled by default in Clang, the
> + * compiler does not produce vectorized code due to its cost model.
> + * See: https://github.com/ClangBuiltLinux/linux/issues/503
> + */
> +#ifdef CONFIG_CC_IS_CLANG
> +#warning Clang does not vectorize code in this file.
> +#endif
I really do not like this. With the GCC specific warning, the user could
just upgrade their GCC. With this warning, it is basically telling them
don't use clang, in which case, it would just be better to disable this
code altogether. I would rather see:
1. Just don't build this file with clang altogether, which I believe was
v1's 2/2 patch.
OR
2. Use the pragma:
#pragma clang loop vectorize(enable)
as Nick suggests in v1's 2/2 patch.
Alternatively, __restrict__ sounds like it might be beneficial for both
GCC and clang:
https://lore.kernel.org/lkml/20201112215033.GA438824@rani.riverdale.lan/
> /*
> * Pull in the reference implementations while instructing GCC (through
> * -ftree-vectorize) to attempt to exploit implicit parallelism and emit
> * NEON instructions.
> */
> -#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6)
> +#ifdef CONFIG_CC_IS_GCC
> #pragma GCC optimize "tree-vectorize"
> -#else
> -/*
> - * While older versions of GCC do not generate incorrect code, they fail to
> - * recognize the parallel nature of these functions, and emit plain ARM code,
> - * which is known to be slower than the optimized ARM code in asm-arm/xor.h.
> - */
> -#warning This code requires at least version 4.6 of GCC
> #endif
>
> #pragma GCC diagnostic ignored "-Wunused-variable"
> --
> 2.30.0
>
^ permalink raw reply [relevance 97%]
* Re: [PATCH v4 1/2] arm: lib: xor-neon: remove unnecessary GCC < 4.6 warning
@ 2021-01-19 21:54 95% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-19 21:54 UTC (permalink / raw)
To: Adrian Ratiu
Cc: Arnd Bergmann, Nick Desaulniers, Russell King,
Linux Kernel Mailing List, clang-built-linux, Arvind Sankar,
kernel, Ard Biesheuvel, linux-arm-kernel
On Tue, Jan 19, 2021 at 03:17:23PM +0200, Adrian Ratiu wrote:
> From: Nathan Chancellor <natechancellor@gmail.com>
>
> Drop warning because kernel now requires GCC >= v4.9 after
> commit 6ec4476ac825 ("Raise gcc version requirement to 4.9")
> and clarify that -ftree-vectorize now always needs enabling
> for GCC by directly testing the presence of CONFIG_CC_IS_GCC.
>
> Another reason to remove the warning is that Clang exposes
> itself as GCC < 4.6 so it triggers the warning about GCC
> which doesn't make much sense and misleads Clang users by
> telling them to update GCC.
>
> Because Clang is now supported by the kernel print a clear
> Clang-specific warning.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/496
> Link: https://github.com/ClangBuiltLinux/linux/issues/503
> Reported-by: Nick Desaulniers <ndesaulniers@google.com>
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
The commit message looks like it is written by me but I never added a
Clang specific warning. I appreciate wanting to give me credit but when
you change things about my original commit message, please make it
clear that you did the edits, something like:
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
[adrian: Add clang specific warning]
Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
> ---
> arch/arm/lib/xor-neon.c | 18 ++++++++++--------
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/lib/xor-neon.c b/arch/arm/lib/xor-neon.c
> index b99dd8e1c93f..f9f3601cc2d1 100644
> --- a/arch/arm/lib/xor-neon.c
> +++ b/arch/arm/lib/xor-neon.c
> @@ -14,20 +14,22 @@ MODULE_LICENSE("GPL");
> #error You should compile this file with '-march=armv7-a -mfloat-abi=softfp -mfpu=neon'
> #endif
>
> +/*
> + * TODO: Even though -ftree-vectorize is enabled by default in Clang, the
> + * compiler does not produce vectorized code due to its cost model.
> + * See: https://github.com/ClangBuiltLinux/linux/issues/503
> + */
> +#ifdef CONFIG_CC_IS_CLANG
> +#warning Clang does not vectorize code in this file.
> +#endif
I really do not like this. With the GCC specific warning, the user could
just upgrade their GCC. With this warning, it is basically telling them
don't use clang, in which case, it would just be better to disable this
code altogether. I would rather see:
1. Just don't build this file with clang altogether, which I believe was
v1's 2/2 patch.
OR
2. Use the pragma:
#pragma clang loop vectorize(enable)
as Nick suggests in v1's 2/2 patch.
Alternatively, __restrict__ sounds like it might be beneficial for both
GCC and clang:
https://lore.kernel.org/lkml/20201112215033.GA438824@rani.riverdale.lan/
> /*
> * Pull in the reference implementations while instructing GCC (through
> * -ftree-vectorize) to attempt to exploit implicit parallelism and emit
> * NEON instructions.
> */
> -#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6)
> +#ifdef CONFIG_CC_IS_GCC
> #pragma GCC optimize "tree-vectorize"
> -#else
> -/*
> - * While older versions of GCC do not generate incorrect code, they fail to
> - * recognize the parallel nature of these functions, and emit plain ARM code,
> - * which is known to be slower than the optimized ARM code in asm-arm/xor.h.
> - */
> -#warning This code requires at least version 4.6 of GCC
> #endif
>
> #pragma GCC diagnostic ignored "-Wunused-variable"
> --
> 2.30.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [relevance 95%]
* Re: [PATCH v2] powerpc: Handle .text.{hot,unlikely}.* in linker script
@ 2021-01-16 18:52 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-16 18:52 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Nick Desaulniers, linux-kernel, stable, clang-built-linux,
Paul Mackerras, linuxppc-dev
On Sat, Jan 16, 2021 at 12:44:38PM -0600, Segher Boessenkool wrote:
> Hi!
>
> Very late of course, and the patch is fine, but:
>
> On Mon, Jan 04, 2021 at 01:59:53PM -0700, Nathan Chancellor wrote:
> > Commit eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input
> > sections") added ".text.unlikely.*" and ".text.hot.*" due to an LLVM
> > change [1].
> >
> > After another LLVM change [2], these sections are seen in some PowerPC
> > builds, where there is a orphan section warning then build failure:
> >
> > $ make -skj"$(nproc)" \
> > ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- LLVM=1 O=out \
> > distclean powernv_defconfig zImage.epapr
> > ld.lld: warning: kernel/built-in.a(panic.o):(.text.unlikely.) is being placed in '.text.unlikely.'
>
> Is the section really called ".text.unlikely.", i.e. the name ending in
> a dot? How very unusual, is there some bug elsewhere?
No, this was an intention change done by LLVM:
https://reviews.llvm.org/D79600
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH v2] powerpc: Handle .text.{hot,unlikely}.* in linker script
@ 2021-01-16 18:52 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-16 18:52 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Michael Ellerman, Nick Desaulniers, linux-kernel, stable,
clang-built-linux, Paul Mackerras, linuxppc-dev
On Sat, Jan 16, 2021 at 12:44:38PM -0600, Segher Boessenkool wrote:
> Hi!
>
> Very late of course, and the patch is fine, but:
>
> On Mon, Jan 04, 2021 at 01:59:53PM -0700, Nathan Chancellor wrote:
> > Commit eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input
> > sections") added ".text.unlikely.*" and ".text.hot.*" due to an LLVM
> > change [1].
> >
> > After another LLVM change [2], these sections are seen in some PowerPC
> > builds, where there is a orphan section warning then build failure:
> >
> > $ make -skj"$(nproc)" \
> > ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- LLVM=1 O=out \
> > distclean powernv_defconfig zImage.epapr
> > ld.lld: warning: kernel/built-in.a(panic.o):(.text.unlikely.) is being placed in '.text.unlikely.'
>
> Is the section really called ".text.unlikely.", i.e. the name ending in
> a dot? How very unusual, is there some bug elsewhere?
No, this was an intention change done by LLVM:
https://reviews.llvm.org/D79600
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH 5.4 40/62] spi: spi-geni-qcom: Fix geni_spi_isr() NULL dereference in timeout case
@ 2021-01-16 18:48 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-16 18:48 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, Douglas Anderson, Stephen Boyd, Mark Brown
On Fri, Jan 15, 2021 at 01:28:02PM +0100, Greg Kroah-Hartman wrote:
> From: Douglas Anderson <dianders@chromium.org>
>
> commit 4aa1464acbe3697710279a4bd65cb4801ed30425 upstream.
>
> In commit 7ba9bdcb91f6 ("spi: spi-geni-qcom: Don't keep a local state
> variable") we changed handle_fifo_timeout() so that we set
> "mas->cur_xfer" to NULL to make absolutely sure that we don't mess
> with the buffers from the previous transfer in the timeout case.
>
> Unfortunately, this caused the IRQ handler to dereference NULL in some
> cases. One case:
>
> CPU0 CPU1
> ---- ----
> setup_fifo_xfer()
> geni_se_setup_m_cmd()
> <hardware starts transfer>
> <transfer completes in hardware>
> <hardware sets M_RX_FIFO_WATERMARK_EN in m_irq>
> ...
> handle_fifo_timeout()
> spin_lock_irq(mas->lock)
> mas->cur_xfer = NULL
> geni_se_cancel_m_cmd()
> spin_unlock_irq(mas->lock)
>
> geni_spi_isr()
> spin_lock(mas->lock)
> if (m_irq & M_RX_FIFO_WATERMARK_EN)
> geni_spi_handle_rx()
> mas->cur_xfer NULL dereference!
>
> tl;dr: Seriously delayed interrupts for RX/TX can lead to timeout
> handling setting mas->cur_xfer to NULL.
>
> Let's check for the NULL transfer in the TX and RX cases and reset the
> watermark or clear out the fifo respectively to put the hardware back
> into a sane state.
>
> NOTE: things still could get confused if we get timeouts all the way
> through handle_fifo_timeout() and then start a new transfer because
> interrupts from the old transfer / cancel / abort could still be
> pending. A future patch will help this corner case.
>
> Fixes: 561de45f72bd ("spi: spi-geni-qcom: Add SPI driver support for GENI based QUP")
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> Reviewed-by: Stephen Boyd <swboyd@chromium.org>
> Link: https://lore.kernel.org/r/20201217142842.v3.1.I99ee04f0cb823415df59bd4f550d6ff5756e43d6@changeid
> Signed-off-by: Mark Brown <broonie@kernel.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> ---
> drivers/spi/spi-geni-qcom.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> --- a/drivers/spi/spi-geni-qcom.c
> +++ b/drivers/spi/spi-geni-qcom.c
> @@ -415,6 +415,12 @@ static void geni_spi_handle_tx(struct sp
> unsigned int bytes_per_fifo_word = geni_byte_per_fifo_word(mas);
> unsigned int i = 0;
>
> + /* Stop the watermark IRQ if nothing to send */
> + if (!mas->cur_xfer) {
> + writel(0, se->base + SE_GENI_TX_WATERMARK_REG);
> + return false;
> + }
> +
> max_bytes = (mas->tx_fifo_depth - mas->tx_wm) * bytes_per_fifo_word;
> if (mas->tx_rem_bytes < max_bytes)
> max_bytes = mas->tx_rem_bytes;
> @@ -454,6 +460,14 @@ static void geni_spi_handle_rx(struct sp
> if (rx_last_byte_valid && rx_last_byte_valid < 4)
> rx_bytes -= bytes_per_fifo_word - rx_last_byte_valid;
> }
> +
> + /* Clear out the FIFO and bail if nowhere to put it */
> + if (!mas->cur_xfer) {
> + for (i = 0; i < DIV_ROUND_UP(rx_bytes, bytes_per_fifo_word); i++)
> + readl(se->base + SE_GENI_RX_FIFOn);
> + return;
> + }
> +
> if (mas->rx_rem_bytes < rx_bytes)
> rx_bytes = mas->rx_rem_bytes;
>
>
>
This commit breaks the build with clang:
drivers/spi/spi-geni-qcom.c:421:3: error: void function
'geni_spi_handle_tx' should not return a value [-Wreturn-type]
return false;
^ ~~~~~
1 error generated.
It looks like commit 6d66507d9b55 ("spi: spi-geni-qcom: Don't wait to
start 1st transfer if transmitting") would resolve this.
It might be worth picking up commit 172aad81a882 ("kbuild: enforce
-Werror=return-type") so that GCC behaves like clang does.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH 5.10 086/103] regmap: debugfs: Fix a memory leak when calling regmap_attach_dev
@ 2021-01-15 20:22 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-15 20:22 UTC (permalink / raw)
To: Pavel Machek
Cc: Greg Kroah-Hartman, linux-kernel, stable, Xiaolei Wang, Mark Brown
On Fri, Jan 15, 2021 at 09:18:19PM +0100, Pavel Machek wrote:
> Hi!
>
> > From: Xiaolei Wang <xiaolei.wang@windriver.com>
> >
> > commit cffa4b2122f5f3e53cf3d529bbc74651f95856d5 upstream.
> >
> > After initializing the regmap through
> > syscon_regmap_lookup_by_compatible, then regmap_attach_dev to the
> > device, because the debugfs_name has been allocated, there is no
> > need to redistribute it again
>
> ? redistribute?
>
> Anyway, this patch is clearly buggy:
>
> >
> > if (!strcmp(name, "dummy")) {
> > - kfree(map->debugfs_name);
> > + if (!map->debugfs_name)
> > + kfree(map->debugfs_name);
> >
>
> It runs kfree only if the variable is NULL. That's clearly useless,
> kfree(NULL) is NOP, and this causes memory leak.
Fixed by commit f6bcb4c7f366 ("regmap: debugfs: Fix a reversed if
statement in regmap_debugfs_init()") in mainline.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH v3] module: Ignore _GLOBAL_OFFSET_TABLE_ when warning for undefined symbols
@ 2021-01-15 19:55 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-15 19:55 UTC (permalink / raw)
To: Fangrui Song
Cc: linux-kernel, Jessica Yu, clang-built-linux, Sam Ravnborg,
Marco Elver, Nick Desaulniers, stable
On Fri, Jan 15, 2021 at 11:52:22AM -0800, 'Fangrui Song' via Clang Built Linux wrote:
> clang-12 -fno-pic (since
> https://github.com/llvm/llvm-project/commit/a084c0388e2a59b9556f2de0083333232da3f1d6)
> can emit `call __stack_chk_fail@PLT` instead of `call __stack_chk_fail`
> on x86. The two forms should have identical behaviors on x86-64 but the
> former causes GNU as<2.37 to produce an unreferenced undefined symbol
> _GLOBAL_OFFSET_TABLE_.
>
> (On x86-32, there is an R_386_PC32 vs R_386_PLT32 difference but the
> linker behavior is identical as far as Linux kernel is concerned.)
>
> Simply ignore _GLOBAL_OFFSET_TABLE_ for now, like what
> scripts/mod/modpost.c:ignore_undef_symbol does. This also fixes the
> problem for gcc/clang -fpie and -fpic, which may emit `call foo@PLT` for
> external function calls on x86.
>
> Note: ld -z defs and dynamic loaders do not error for unreferenced
> undefined symbols so the module loader is reading too much. If we ever
> need to ignore more symbols, the code should be refactored to ignore
> unreferenced symbols.
>
> Reported-by: Marco Elver <elver@google.com>
> Link: https://github.com/ClangBuiltLinux/linux/issues/1250
> Signed-off-by: Fangrui Song <maskray@google.com>
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> Tested-by: Marco Elver <elver@google.com>
> Cc: <stable@vger.kernel.org>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
>
> ---
> Changes in v2:
> * Fix Marco's email address
> * Add a function ignore_undef_symbol similar to scripts/mod/modpost.c:ignore_undef_symbol
> ---
> Changes in v3:
> * Fix the style of a multi-line comment.
> * Use static bool ignore_undef_symbol.
> ---
> kernel/module.c | 21 +++++++++++++++++++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/module.c b/kernel/module.c
> index 4bf30e4b3eaa..805c49d1b86d 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -2348,6 +2348,21 @@ static int verify_exported_symbols(struct module *mod)
> return 0;
> }
>
> +static bool ignore_undef_symbol(Elf_Half emachine, const char *name)
> +{
> + /*
> + * On x86, PIC code and Clang non-PIC code may have call foo@PLT. GNU as
> + * before 2.37 produces an unreferenced _GLOBAL_OFFSET_TABLE_ on x86-64.
> + * i386 has a similar problem but may not deserve a fix.
> + *
> + * If we ever have to ignore many symbols, consider refactoring the code to
> + * only warn if referenced by a relocation.
> + */
> + if (emachine == EM_386 || emachine == EM_X86_64)
> + return !strcmp(name, "_GLOBAL_OFFSET_TABLE_");
> + return false;
> +}
> +
> /* Change all symbols so that st_value encodes the pointer directly. */
> static int simplify_symbols(struct module *mod, const struct load_info *info)
> {
> @@ -2395,8 +2410,10 @@ static int simplify_symbols(struct module *mod, const struct load_info *info)
> break;
> }
>
> - /* Ok if weak. */
> - if (!ksym && ELF_ST_BIND(sym[i].st_info) == STB_WEAK)
> + /* Ok if weak or ignored. */
> + if (!ksym &&
> + (ELF_ST_BIND(sym[i].st_info) == STB_WEAK ||
> + ignore_undef_symbol(info->hdr->e_machine, name)))
> break;
>
> ret = PTR_ERR(ksym) ?: -ENOENT;
> --
> 2.30.0.296.g2bfb1c46d8-goog
>
> --
> You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-linux+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/20210115195222.3453262-1-maskray%40google.com.
^ permalink raw reply [relevance 99%]
* Re: [PATCH] mips: vdso: fix DWARF2 warning
@ 2021-01-15 19:28 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-15 19:28 UTC (permalink / raw)
To: Anders Roxell
Cc: tsbogend, ndesaulniers, linux-mips, linux-kernel,
clang-built-linux, stable
On Fri, Jan 15, 2021 at 08:13:30PM +0100, Anders Roxell wrote:
> When building mips tinyconifg the following warning show up
>
> make --silent --keep-going --jobs=8 O=/home/anders/src/kernel/next/out/builddir ARCH=mips CROSS_COMPILE=mips-linux-gnu- HOSTCC=clang CC=clang
> /srv/src/kernel/next/arch/mips/vdso/elf.S:14:1: warning: DWARF2 only supports one section per compilation unit
> .pushsection .note.Linux, "a",@note ; .balign 4 ; .long 2f - 1f ; .long 4484f - 3f ; .long 0 ; 1:.asciz "Linux" ; 2:.balign 4 ; 3:
> ^
> /srv/src/kernel/next/arch/mips/vdso/elf.S:34:2: warning: DWARF2 only supports one section per compilation unit
> .section .mips_abiflags, "a"
> ^
>
> Rework so the mips vdso Makefile adds flag '-no-integrated-as' unless
> LLVM_IAS is defined.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/1256
> Cc: stable@vger.kernel.org # v4.19+
> Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
> Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
I believe this is the better solution:
https://lore.kernel.org/r/20210115192622.3828545-1-natechancellor@gmail.com/
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* [PATCH] MIPS: VDSO: Use CLANG_FLAGS instead of filtering out '--target='
@ 2021-01-15 19:26 91% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-15 19:26 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: Nick Desaulniers, linux-mips, linux-kernel, clang-built-linux,
Nathan Chancellor, stable, Anders Roxell
Commit ee67855ecd9d ("MIPS: vdso: Allow clang's --target flag in VDSO
cflags") allowed the '--target=' flag from the main Makefile to filter
through to the vDSO. However, it did not bring any of the other clang
specific flags for controlling the integrated assembler and the GNU
tools locations (--prefix=, --gcc-toolchain=, and -no-integrated-as).
Without these, we will get a warning (visible with tinyconfig):
arch/mips/vdso/elf.S:14:1: warning: DWARF2 only supports one section per
compilation unit
.pushsection .note.Linux, "a",@note ; .balign 4 ; .long 2f - 1f ; .long
4484f - 3f ; .long 0 ; 1:.asciz "Linux" ; 2:.balign 4 ; 3:
^
arch/mips/vdso/elf.S:34:2: warning: DWARF2 only supports one section per
compilation unit
.section .mips_abiflags, "a"
^
All of these flags are bundled up under CLANG_FLAGS in the main Makefile
and exported so that they can be added to Makefiles that set their own
CFLAGS. Use this value instead of filtering out '--target=' so there is
no warning and all of the tools are properly used.
Cc: stable@vger.kernel.org
Fixes: ee67855ecd9d ("MIPS: vdso: Allow clang's --target flag in VDSO cflags")
Link: https://github.com/ClangBuiltLinux/linux/issues/1256
Reported-by: Anders Roxell <anders.roxell@linaro.org>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
arch/mips/vdso/Makefile | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/mips/vdso/Makefile b/arch/mips/vdso/Makefile
index 5810cc12bc1d..2131d3fd7333 100644
--- a/arch/mips/vdso/Makefile
+++ b/arch/mips/vdso/Makefile
@@ -16,16 +16,13 @@ ccflags-vdso := \
$(filter -march=%,$(KBUILD_CFLAGS)) \
$(filter -m%-float,$(KBUILD_CFLAGS)) \
$(filter -mno-loongson-%,$(KBUILD_CFLAGS)) \
+ $(CLANG_FLAGS) \
-D__VDSO__
ifndef CONFIG_64BIT
ccflags-vdso += -DBUILD_VDSO32
endif
-ifdef CONFIG_CC_IS_CLANG
-ccflags-vdso += $(filter --target=%,$(KBUILD_CFLAGS))
-endif
-
#
# The -fno-jump-tables flag only prevents the compiler from generating
# jump tables but does not prevent the compiler from emitting absolute
base-commit: 7b490a8ab0f2d3ab8d838a4ff22ae86edafd34a1
--
2.30.0
^ permalink raw reply related [relevance 91%]
* Re: [PATCH] ubifs: replay: Fix high stack usage, again
@ 2021-01-15 18:38 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-15 18:38 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Wang Hai, Herbert Xu, Arnd Bergmann, Eric Biggers,
Richard Weinberger, Randy Dunlap, Nick Desaulniers, linux-kernel,
clang-built-linux, linux-mtd, Zhihao Cheng
On Thu, Jan 14, 2021 at 10:30:11PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> An earlier commit moved out some functions to not be inlined by gcc, but
> after some other rework to remove one of those, clang started inlining
> the other one and ran into the same problem as gcc did before:
>
> fs/ubifs/replay.c:1174:5: error: stack frame size of 1152 bytes in function 'ubifs_replay_journal' [-Werror,-Wframe-larger-than=]
>
> Mark the function as noinline_for_stack to ensure it doesn't happen
> again.
>
> Fixes: f80df3851246 ("ubifs: use crypto_shash_tfm_digest()")
> Fixes: eb66eff6636d ("ubifs: replay: Fix high stack usage")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> fs/ubifs/replay.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/fs/ubifs/replay.c b/fs/ubifs/replay.c
> index 79801c9a5b87..0f8a6a16421b 100644
> --- a/fs/ubifs/replay.c
> +++ b/fs/ubifs/replay.c
> @@ -559,7 +559,9 @@ static int is_last_bud(struct ubifs_info *c, struct ubifs_bud *bud)
> }
>
> /* authenticate_sleb_hash is split out for stack usage */
> -static int authenticate_sleb_hash(struct ubifs_info *c, struct shash_desc *log_hash, u8 *hash)
> +static int noinline_for_stack
> +authenticate_sleb_hash(struct ubifs_info *c,
> + struct shash_desc *log_hash, u8 *hash)
> {
> SHASH_DESC_ON_STACK(hash_desc, c->hash_tfm);
>
> --
> 2.29.2
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [relevance 99%]
* Re: [PATCH] ubifs: replay: Fix high stack usage, again
@ 2021-01-15 18:38 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-15 18:38 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Richard Weinberger, Nick Desaulniers, Eric Biggers, Herbert Xu,
Arnd Bergmann, Zhihao Cheng, Randy Dunlap, Wang Hai, linux-mtd,
linux-kernel, clang-built-linux
On Thu, Jan 14, 2021 at 10:30:11PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> An earlier commit moved out some functions to not be inlined by gcc, but
> after some other rework to remove one of those, clang started inlining
> the other one and ran into the same problem as gcc did before:
>
> fs/ubifs/replay.c:1174:5: error: stack frame size of 1152 bytes in function 'ubifs_replay_journal' [-Werror,-Wframe-larger-than=]
>
> Mark the function as noinline_for_stack to ensure it doesn't happen
> again.
>
> Fixes: f80df3851246 ("ubifs: use crypto_shash_tfm_digest()")
> Fixes: eb66eff6636d ("ubifs: replay: Fix high stack usage")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> fs/ubifs/replay.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/fs/ubifs/replay.c b/fs/ubifs/replay.c
> index 79801c9a5b87..0f8a6a16421b 100644
> --- a/fs/ubifs/replay.c
> +++ b/fs/ubifs/replay.c
> @@ -559,7 +559,9 @@ static int is_last_bud(struct ubifs_info *c, struct ubifs_bud *bud)
> }
>
> /* authenticate_sleb_hash is split out for stack usage */
> -static int authenticate_sleb_hash(struct ubifs_info *c, struct shash_desc *log_hash, u8 *hash)
> +static int noinline_for_stack
> +authenticate_sleb_hash(struct ubifs_info *c,
> + struct shash_desc *log_hash, u8 *hash)
> {
> SHASH_DESC_ON_STACK(hash_desc, c->hash_tfm);
>
> --
> 2.29.2
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] x86: efi: avoid BUILD_BUG_ON() for non-constant p4d_index
@ 2021-01-15 18:32 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-15 18:32 UTC (permalink / raw)
To: Borislav Petkov
Cc: Arnd Bergmann, Ard Biesheuvel, Thomas Gleixner, Ingo Molnar, x86,
Nick Desaulniers, Arnd Bergmann, Darren Hart, Andy Shevchenko,
H. Peter Anvin, linux-efi, platform-driver-x86, linux-kernel,
clang-built-linux
On Fri, Jan 15, 2021 at 07:23:00PM +0100, Borislav Petkov wrote:
> On Thu, Jan 07, 2021 at 11:34:15PM +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > When 5-level page tables are enabled, clang triggers a BUILD_BUG_ON():
>
> I have CONFIG_X86_5LEVEL=y, CONFIG_EFI=y and am using Debian clang
> version 10.0.1-8+b1 but my .config builds just fine.
>
> How do you trigger this?
I triggered it with CONFIG_UBSAN=y + CONFIG_UBSAN_UNSIGNED_OVERFLOW=y
(it can be exposed with an allyesconfig/allmodconfig on mainline
currently).
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] objtool: Don't fail on missing symbol table
@ 2021-01-14 22:32 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-14 22:32 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: x86, linux-kernel, Nick Desaulniers, Peter Zijlstra, Miroslav Benes
On Thu, Jan 14, 2021 at 04:24:15PM -0600, Josh Poimboeuf wrote:
> Thanks to a recent binutils change which doesn't generate unused
> symbols, it's now possible for thunk_64.o be completely empty with
> CONFIG_PREEMPTION: no text, no data, no symbols.
>
> We could edit the Makefile to only build that file when
> CONFIG_PREEMPTION is enabled, but that will likely create confusion
> if/when the thunks end up getting used by some other code again.
>
> Just ignore it and move on.
>
> Reported-by: Nathan Chancellor <natechancellor@gmail.com>
> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Thanks for the quick fix!
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Is it worth a cc to stable given that I hit this in 5.4? I suppose it is
not super critical now but it seems like someone might eventually hit
this as times goes on and binutils 2.37 becomes more common.
> ---
> tools/objtool/elf.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
> index be89c741ba9a..2b0f4f52f7b5 100644
> --- a/tools/objtool/elf.c
> +++ b/tools/objtool/elf.c
> @@ -380,8 +380,11 @@ static int read_symbols(struct elf *elf)
>
> symtab = find_section_by_name(elf, ".symtab");
> if (!symtab) {
> - WARN("missing symbol table");
> - return -1;
> + /*
> + * A missing symbol table is actually possible if it's an empty
> + * .o file. This can happen for thunk_64.o.
> + */
> + return 0;
> }
>
> symtab_shndx = find_section_by_name(elf, ".symtab_shndx");
> --
> 2.29.2
>
^ permalink raw reply [relevance 99%]
* Re: drivers/iio/accel/adxl372.c:949:3: warning: converting the result of '<<' to a boolean always evaluates to true
@ 2021-01-14 18:24 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-14 18:24 UTC (permalink / raw)
To: kernel test robot
Cc: Stefan Popa, kbuild-all, clang-built-linux, linux-kernel,
Jonathan Cameron, Alexandru Tachici
On Fri, Jan 15, 2021 at 02:19:41AM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head: 65f0d2414b7079556fbbcc070b3d1c9f9587606d
> commit: b0fc6783d4ae58f796fb183c40dbc7fa3199d51d iio: accel: adxl372: Add support for FIFO peak mode
> date: 4 months ago
> config: mips-randconfig-r026-20210114 (attached as .config)
> compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 68ff52ffead2ba25cca442778ab19286000daad7)
> reproduce (this is a W=1 build):
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # install mips cross compiling tool for clang build
> # apt-get install binutils-mips-linux-gnu
> # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b0fc6783d4ae58f796fb183c40dbc7fa3199d51d
> git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> git fetch --no-tags linus master
> git checkout b0fc6783d4ae58f796fb183c40dbc7fa3199d51d
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=mips
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
>
> All warnings (new ones prefixed by >>):
>
> In file included from include/linux/interrupt.h:8:
> In file included from include/linux/cpumask.h:13:
> In file included from include/linux/atomic.h:7:
> arch/mips/include/asm/atomic.h:52:1: warning: converting the result of '<<' to a boolean always evaluates to true [-Wtautological-constant-compare]
> arch/mips/include/asm/atomic.h:45:9: note: expanded from macro 'ATOMIC_OPS'
> return xchg(&v->counter, n); \
> ^
> arch/mips/include/asm/cmpxchg.h:102:7: note: expanded from macro 'xchg'
> if (!__SYNC_loongson3_war) \
> ^
> arch/mips/include/asm/sync.h:147:34: note: expanded from macro '__SYNC_loongson3_war'
> # define __SYNC_loongson3_war (1 << 31)
> ^
Sorry for the noise, I have sent a patch to fix this:
https://lore.kernel.org/lkml/20210114173416.738455-1-natechancellor@gmail.com/
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH v3] kbuild: check the minimum compiler version in Kconfig
@ 2021-01-14 18:23 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-14 18:23 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-kbuild, Paul Gortmaker, Linus Torvalds, Nick Desaulniers,
Will Deacon, clang-built-linux, linux-kernel
On Fri, Jan 15, 2021 at 03:07:09AM +0900, Masahiro Yamada wrote:
> Paul Gortmaker reported a regression in the GCC version check [1].
> If you use GCC 4.8, the build breaks before showing the error message
> "error Sorry, your version of GCC is too old - please use 4.9 or newer."
>
> I do not want to apply his fix-up since it implies we would not be able
> to remove any cc-option test. Anyway, I admit checking the GCC version
> in <linux/compiler-gcc.h> is too late.
>
> Almost at the same time, Linus also suggested to move the compiler
> version error to Kconfig time. [2]
>
> I unified the similar two scripts, gcc-version.sh and clang-version.sh
> into the new cc-version.sh. The old scripts invoked the compiler multiple
> times (3 times for gcc-version.sh, 4 times for clang-version.sh). I
> refactored the code so the new one invokes the compiler just once, and
> also tried my best to use shell-builtin commands where possible.
>
> The new script runs faster.
>
> $ time ./scripts/clang-version.sh clang
> 120000
>
> real 0m0.029s
> user 0m0.012s
> sys 0m0.021s
>
> $ time ./scripts/cc-version.sh clang
> Clang 120000
>
> real 0m0.009s
> user 0m0.006s
> sys 0m0.004s
>
> The cc-version.sh also shows the error if the compiler is old:
>
> $ make defconfig CC=clang-9
> *** Default configuration is based on 'x86_64_defconfig'
> ***
> *** Compiler is too old.
> *** Your Clang version: 9.0.1
> *** Minimum Clang version: 10.0.1
> ***
> scripts/Kconfig.include:46: Sorry, this compiler is not supported.
> make[1]: *** [scripts/kconfig/Makefile:81: defconfig] Error 1
> make: *** [Makefile:602: defconfig] Error 2
>
> I removed the clang version check from <linux/compiler-clang.h>
>
> For now, I did not touch <linux/compiler-gcc.h> in order to avoid
> merge conflict with [3], which has been queued up in the arm64 tree.
> We will be able to clean it up later.
>
> The new script takes care of ICC because we have <linux/compiler-intel.h>
> although I am not sure if building the kernel with ICC is well-supported.
>
> [1] https://lkml.org/lkml/2021/1/10/250
> [2] https://lkml.org/lkml/2021/1/12/1708
> [3] https://lkml.org/lkml/2021/1/12/1533
>
> Fixes: 87de84c9140e ("kbuild: remove cc-option test of -Werror=date-time")
> Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
^ permalink raw reply [relevance 99%]
* [PATCH] MIPS: Compare __SYNC_loongson3_war against 0
@ 2021-01-14 17:34 86% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-14 17:34 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: Nick Desaulniers, linux-kernel, linux-mips, clang-built-linux,
Nathan Chancellor, kernel test robot
When building with clang when CONFIG_CPU_LOONGSON3_WORKAROUNDS is
enabled:
In file included from lib/errseq.c:4:
In file included from ./include/linux/atomic.h:7:
./arch/mips/include/asm/atomic.h:52:1: warning: converting the result of
'<<' to a boolean always evaluates to true
[-Wtautological-constant-compare]
ATOMIC_OPS(atomic64, s64)
^
./arch/mips/include/asm/atomic.h:40:9: note: expanded from macro
'ATOMIC_OPS'
return cmpxchg(&v->counter, o, n);
^
./arch/mips/include/asm/cmpxchg.h:194:7: note: expanded from macro
'cmpxchg'
if (!__SYNC_loongson3_war)
^
./arch/mips/include/asm/sync.h:147:34: note: expanded from macro
'__SYNC_loongson3_war'
# define __SYNC_loongson3_war (1 << 31)
^
While it is not wrong that the result of this shift is always true in a
boolean context, it is not a problem here. Regardless, the warning is
really noisy so rather than making the shift a boolean implicitly, use
it in an equality comparison so the shift is used as an integer value.
Fixes: 4d1dbfe6cbec ("MIPS: atomic: Emit Loongson3 sync workarounds within asm")
Fixes: a91f2a1dba44 ("MIPS: cmpxchg: Omit redundant barriers for Loongson3")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
arch/mips/include/asm/atomic.h | 2 +-
arch/mips/include/asm/cmpxchg.h | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/mips/include/asm/atomic.h b/arch/mips/include/asm/atomic.h
index f904084fcb1f..27ad76791539 100644
--- a/arch/mips/include/asm/atomic.h
+++ b/arch/mips/include/asm/atomic.h
@@ -248,7 +248,7 @@ static __inline__ int pfx##_sub_if_positive(type i, pfx##_t * v) \
* bltz that can branch to code outside of the LL/SC loop. As \
* such, we don't need to emit another barrier here. \
*/ \
- if (!__SYNC_loongson3_war) \
+ if (__SYNC_loongson3_war == 0) \
smp_mb__after_atomic(); \
\
return result; \
diff --git a/arch/mips/include/asm/cmpxchg.h b/arch/mips/include/asm/cmpxchg.h
index 5b0b3a6777ea..ed8f3f3c4304 100644
--- a/arch/mips/include/asm/cmpxchg.h
+++ b/arch/mips/include/asm/cmpxchg.h
@@ -99,7 +99,7 @@ unsigned long __xchg(volatile void *ptr, unsigned long x, int size)
* contains a completion barrier prior to the LL, so we don't \
* need to emit an extra one here. \
*/ \
- if (!__SYNC_loongson3_war) \
+ if (__SYNC_loongson3_war == 0) \
smp_mb__before_llsc(); \
\
__res = (__typeof__(*(ptr))) \
@@ -191,7 +191,7 @@ unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
* contains a completion barrier prior to the LL, so we don't \
* need to emit an extra one here. \
*/ \
- if (!__SYNC_loongson3_war) \
+ if (__SYNC_loongson3_war == 0) \
smp_mb__before_llsc(); \
\
__res = cmpxchg_local((ptr), (old), (new)); \
@@ -201,7 +201,7 @@ unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
* contains a completion barrier after the SC, so we don't \
* need to emit an extra one here. \
*/ \
- if (!__SYNC_loongson3_war) \
+ if (__SYNC_loongson3_war == 0) \
smp_llsc_mb(); \
\
__res; \
base-commit: 7c53f6b671f4aba70ff15e1b05148b10d58c2837
--
2.30.0
^ permalink raw reply related [relevance 86%]
* [PATCH v2] MAINTAINERS: Add compiler-clang.h to the Clang/LLVM section
2021-01-14 0:40 99% [PATCH] MAINTAINERS: Add a couple more files to the Clang/LLVM section Nathan Chancellor
@ 2021-01-14 17:16 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-14 17:16 UTC (permalink / raw)
To: Andrew Morton
Cc: Nick Desaulniers, clang-built-linux, linux-kernel, Nathan Chancellor
The K: entry should ensure that Nick and I always get CC'd on patches
that touch thid file but it is better to be explicit rather than
implicit.
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
v1 -> v2:
* Omit scripts/clang-version.sh as Masahiro has proposed unifying
{clang,gcc}-version.sh into one cc-version.sh:
https://lore.kernel.org/r/20210114042420.229524-1-masahiroy@kernel.org/
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index cc1e6a5ee6e6..8036a7860836 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4313,6 +4313,7 @@ W: https://clangbuiltlinux.github.io/
B: https://github.com/ClangBuiltLinux/linux/issues
C: irc://chat.freenode.net/clangbuiltlinux
F: Documentation/kbuild/llvm.rst
+F: include/linux/compiler-clang.h
F: scripts/clang-tools/
F: scripts/lld-version.sh
K: \b(?i:clang|llvm)\b
base-commit: 7c53f6b671f4aba70ff15e1b05148b10d58c2837
--
2.30.0
^ permalink raw reply related [relevance 99%]
* Re: [PATCH v2] kbuild: check the minimum compiler version in Kconfig
@ 2021-01-14 17:07 99% ` Nathan Chancellor
1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-14 17:07 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-kbuild, Paul Gortmaker, Linus Torvalds, Nick Desaulniers,
Will Deacon, clang-built-linux, linux-kernel
On Thu, Jan 14, 2021 at 01:24:19PM +0900, Masahiro Yamada wrote:
> Paul Gortmaker reported a regression in the GCC version check [1].
> If you use GCC 4.8, the build breaks before showing the error message
> "error Sorry, your version of GCC is too old - please use 4.9 or newer."
>
> I do not want to apply his fix-up since it implies we would not be able
> to remove any cc-option test. Anyway, I admit checking the GCC version
> in <linux/compiler-gcc.h> is too late.
>
> Almost at the same time, Linus also suggested to move the compiler
> version error to Kconfig time. [2]
>
> I unified the similar two scripts, gcc-version.sh and clang-version.sh
> into the new cc-version.sh. The old scripts invoked the compiler multiple
> times (3 times for gcc-version.sh, 4 times for clang-version.sh). I
> refactored the code so the new one invokes the compiler just once, and
> also tried my best to use shell-builtin commands where possible.
>
> The new script runs faster.
>
> $ time ./scripts/clang-version.sh clang
> 120000
>
> real 0m0.029s
> user 0m0.012s
> sys 0m0.021s
>
> $ time ./scripts/cc-version.sh clang
> Clang 120000
>
> real 0m0.009s
> user 0m0.006s
> sys 0m0.004s
>
> The cc-version.sh also shows the error if the compiler is old:
>
> $ make defconfig CC=clang-9
> *** Default configuration is based on 'x86_64_defconfig'
> ***
> *** Compiler is too old.
> *** Your Clang version: 9.0.1
> *** Minimum Clang version: 10.0.1
> ***
> scripts/Kconfig.include:46: Sorry, this compiler is unsupported.
> make[1]: *** [scripts/kconfig/Makefile:81: defconfig] Error 1
> make: *** [Makefile:602: defconfig] Error 2
>
> I removed the clang version check from <linux/compiler-clang.h>
>
> For now, I did not touch <linux/compiler-gcc.h> in order to avoid
> merge conflict with [3], which has been queued up in the arm64 tree.
> We will be able to clean it up later.
>
> I put the stub for ICC because I see <linux/compiler-intel.h> although
> I am not sure if building the kernel with ICC is well-supported.
>
> [1] https://lkml.org/lkml/2021/1/10/250
> [2] https://lkml.org/lkml/2021/1/12/1708
> [3] https://lkml.org/lkml/2021/1/12/1533
I would recommend the lore version of these links:
[1]: https://lore.kernel.org/r/20210110190807.134996-1-paul.gortmaker@windriver.com
[2]: https://lore.kernel.org/r/CAHk-=wh-+TMHPTFo1qs-MYyK7tZh-OQovA=pP3=e06aCVp6_kA@mail.gmail.com
[3]: https://lore.kernel.org/r/20210112224832.10980-1-will@kernel.org
> Fixes: 87de84c9140e ("kbuild: remove cc-option test of -Werror=date-time")
> Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
I like this a lot, I think that erroring as early as possible when
something is misconfigured is a good user experience.
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
>
> Changes in v2:
> - fix the function name
>
> include/linux/compiler-clang.h | 10 -----
> init/Kconfig | 9 +++--
> scripts/Kconfig.include | 6 +++
> scripts/cc-version.sh | 69 ++++++++++++++++++++++++++++++++++
> scripts/clang-version.sh | 19 ----------
> scripts/gcc-version.sh | 20 ----------
> 6 files changed, 80 insertions(+), 53 deletions(-)
> create mode 100755 scripts/cc-version.sh
> delete mode 100755 scripts/clang-version.sh
> delete mode 100755 scripts/gcc-version.sh
>
> diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
> index 98cff1b4b088..04c0a5a717f7 100644
> --- a/include/linux/compiler-clang.h
> +++ b/include/linux/compiler-clang.h
> @@ -3,16 +3,6 @@
> #error "Please don't include <linux/compiler-clang.h> directly, include <linux/compiler.h> instead."
> #endif
>
> -#define CLANG_VERSION (__clang_major__ * 10000 \
> - + __clang_minor__ * 100 \
> - + __clang_patchlevel__)
> -
> -#if CLANG_VERSION < 100001
> -#ifndef __BPF_TRACING__
> -# error Sorry, your version of Clang is too old - please use 10.0.1 or newer.
> -#endif
> -#endif
> -
> /* Compiler specific definitions for Clang compiler */
>
> /* same as gcc, this was present in clang-2.6 so we can assume it works
> diff --git a/init/Kconfig b/init/Kconfig
> index b77c60f8b963..01108dd1318b 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -26,11 +26,11 @@ config CC_VERSION_TEXT
> and then every file will be rebuilt.
>
> config CC_IS_GCC
> - def_bool $(success,echo "$(CC_VERSION_TEXT)" | grep -q gcc)
> + def_bool $(success,test $(cc-name) = GCC)
>
> config GCC_VERSION
> int
> - default $(shell,$(srctree)/scripts/gcc-version.sh $(CC)) if CC_IS_GCC
> + default $(cc-version) if CC_IS_GCC
> default 0
>
> config LD_VERSION
> @@ -38,14 +38,15 @@ config LD_VERSION
> default $(shell,$(LD) --version | $(srctree)/scripts/ld-version.sh)
>
> config CC_IS_CLANG
> - def_bool $(success,echo "$(CC_VERSION_TEXT)" | grep -q clang)
> + def_bool $(success,test $(cc-name) = Clang)
>
> config LD_IS_LLD
> def_bool $(success,$(LD) -v | head -n 1 | grep -q LLD)
>
> config CLANG_VERSION
> int
> - default $(shell,$(srctree)/scripts/clang-version.sh $(CC))
> + default $(cc-version) if CC_IS_CLANG
> + default 0
>
> config LLD_VERSION
> int
> diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
> index a5fe72c504ff..cdc8726d2904 100644
> --- a/scripts/Kconfig.include
> +++ b/scripts/Kconfig.include
> @@ -39,6 +39,12 @@ as-instr = $(success,printf "%b\n" "$(1)" | $(CC) $(CLANG_FLAGS) -c -x assembler
> $(error-if,$(failure,command -v $(CC)),compiler '$(CC)' not found)
> $(error-if,$(failure,command -v $(LD)),linker '$(LD)' not found)
>
> +# Get the compiler name, version, and error out if it is unsupported.
> +cc-info := $(shell,scripts/cc-version.sh $(CC))
> +$(error-if,$(success,test -z "$(cc-info)"),Sorry$(comma) this compiler is unsupported.)
> +cc-name := $(shell,set -- $(cc-info); echo $1)
> +cc-version := $(shell,set -- $(cc-info); echo $2)
> +
> # Fail if the linker is gold as it's not capable of linking the kernel proper
> $(error-if,$(success, $(LD) -v | grep -q gold), gold linker '$(LD)' not supported)
>
> diff --git a/scripts/cc-version.sh b/scripts/cc-version.sh
> new file mode 100755
> index 000000000000..9c17c1de401c
> --- /dev/null
> +++ b/scripts/cc-version.sh
> @@ -0,0 +1,69 @@
> +#!/bin/sh
> +# SPDX-License-Identifier: GPL-2.0
> +#
> +# Print the compiler name and its version in a 5 or 6-digit form.
> +# Also, perform the minimum version check.
> +
> +set -e
> +
> +# When you raise the compiler version, please update
> +# Documentation/process/changes.rst as well.
> +gcc_min_version=4.9.0
> +clang_min_version=10.0.1
> +
> +# print the compiler name, major version, minor version, patchlevel version
> +get_compiler_info()
> +{
> + cat <<- EOF | "$@" -E -P -x c - 2>/dev/null
> + #if defined(__clang__)
> + Clang __clang_major__ __clang_minor__ __clang_patchlevel__
> + #elif defined(__INTEL_COMPILER)
> + /* How to get the version of intel compiler? */
> + ICC 0 0 0
> + #elif defined(__GNUC__)
> + GCC __GNUC__ __GNUC_MINOR__ __GNUC_PATCHLEVEL__
> + #else
> + unsupported 0 0 0
> + #endif
> + EOF
> +}
> +
> +# convert the version to a canonical 5 or 6-digit form for numerical comparison
> +get_canonical_version()
> +{
> + IFS=.
> + set -- $1
> + echo $((10000 * $1 + 100 * $2 + $3))
> +}
> +
> +# $@ instead of $1 because multiple words might be given e.g. CC="ccache gcc"
> +orig_args="$@"
> +set -- $(get_compiler_info "$@")
> +
> +name=$1
> +version=$2.$3.$4
> +
> +case "$name" in
> +GCC) min_version=$gcc_min_version;;
> +Clang) min_version=$clang_min_version;;
> +ICC) ;; # ICC min version undefined?
> +*) echo "$orig_args: unknown compiler" >&2; exit 1;;
> +esac
> +
> +cversion=$(get_canonical_version $version)
> +
> +if [ -n "$min_version" ]; then
> +
> + min_cversion=$(get_canonical_version $min_version)
> +
> + if [ "$cversion" -lt "$min_cversion" ]; then
> + echo >&2 "***"
> + echo >&2 "*** Compiler is too old."
> + echo >&2 "*** Your $name version: $version"
> + echo >&2 "*** Minimum $name version: $min_version"
> + echo >&2 "***"
> + exit 1
> + fi
> +fi
> +
> +echo $name $cversion
> diff --git a/scripts/clang-version.sh b/scripts/clang-version.sh
> deleted file mode 100755
> index 6fabf0695761..000000000000
> --- a/scripts/clang-version.sh
> +++ /dev/null
> @@ -1,19 +0,0 @@
> -#!/bin/sh
> -# SPDX-License-Identifier: GPL-2.0
> -#
> -# clang-version clang-command
> -#
> -# Print the compiler version of `clang-command' in a 5 or 6-digit form
> -# such as `50001' for clang-5.0.1 etc.
> -
> -compiler="$*"
> -
> -if ! ( $compiler --version | grep -q clang) ; then
> - echo 0
> - exit 1
> -fi
> -
> -MAJOR=$(echo __clang_major__ | $compiler -E -x c - | tail -n 1)
> -MINOR=$(echo __clang_minor__ | $compiler -E -x c - | tail -n 1)
> -PATCHLEVEL=$(echo __clang_patchlevel__ | $compiler -E -x c - | tail -n 1)
> -printf "%d%02d%02d\\n" $MAJOR $MINOR $PATCHLEVEL
> diff --git a/scripts/gcc-version.sh b/scripts/gcc-version.sh
> deleted file mode 100755
> index ae353432539b..000000000000
> --- a/scripts/gcc-version.sh
> +++ /dev/null
> @@ -1,20 +0,0 @@
> -#!/bin/sh
> -# SPDX-License-Identifier: GPL-2.0
> -#
> -# gcc-version gcc-command
> -#
> -# Print the gcc version of `gcc-command' in a 5 or 6-digit form
> -# such as `29503' for gcc-2.95.3, `30301' for gcc-3.3.1, etc.
> -
> -compiler="$*"
> -
> -if [ ${#compiler} -eq 0 ]; then
> - echo "Error: No compiler specified." >&2
> - printf "Usage:\n\t$0 <gcc-command>\n" >&2
> - exit 1
> -fi
> -
> -MAJOR=$(echo __GNUC__ | $compiler -E -x c - | tail -n 1)
> -MINOR=$(echo __GNUC_MINOR__ | $compiler -E -x c - | tail -n 1)
> -PATCHLEVEL=$(echo __GNUC_PATCHLEVEL__ | $compiler -E -x c - | tail -n 1)
> -printf "%d%02d%02d\\n" $MAJOR $MINOR $PATCHLEVEL
> --
> 2.27.0
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH v2] kbuild: check the minimum compiler version in Kconfig
@ 2021-01-14 16:49 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-14 16:49 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Ilie Halip, Linux Kbuild mailing list, Paul Gortmaker,
Linus Torvalds, Nick Desaulniers, Will Deacon, clang-built-linux,
Linux Kernel Mailing List
On Thu, Jan 14, 2021 at 06:20:15PM +0900, Masahiro Yamada wrote:
> BTW, when I tried ICC a few years ago,
> I could not build the kernel with it.
Looking at the history behind include/linux/compiler-intel.h, the last
time I see a change that actually references building a kernel with icc
was 503cf95c061a ("x86, build, icc: Remove uninitialized_var() from
compiler-intel.h"), all the way back in 2013. Since then, there do not
appear to be any meaningful changes; every change is basically doing
something for clang or gcc and not wanting to leave icc behind. It might
be worth considering tearing it out.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] Documentation/llvm: Add a section about supported architectures
@ 2021-01-14 2:23 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-14 2:23 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Jonathan Corbet, Masahiro Yamada, Michal Marek,
clang-built-linux, Linux Kbuild mailing list,
Linux Doc Mailing List, LKML, Miguel Ojeda
On Wed, Jan 13, 2021 at 06:05:32PM -0800, Nick Desaulniers wrote:
> On Wed, Jan 13, 2021 at 5:19 PM Nick Desaulniers
> <ndesaulniers@google.com> wrote:
> >
> > Patch looks fine, but `make -j htmldocs` seems to be taking forever
> > for me so I can't render it. Is this a known issue?
> >
> > $ make -j htmldocs
A clean "make -skj24 htmldocs" takes me a little over three minutes or
so on my Ryzen 9 3900X. Just to give some perspective.
> Just took a while, lots of warning spew (but not from this addition AFAICT).
> Reviewed-by: Nick Desaulniers <ndesaulnier@google.com>
Thanks for the review!
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] bpf: Hoise pahole version checks into Kconfig
@ 2021-01-13 23:07 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-13 23:07 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Masahiro Yamada, Michal Marek, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau, Song Liu,
Yonghong Song, John Fastabend, KP Singh,
Linux Kernel Mailing List, Linux Kbuild mailing list, Networking,
bpf, Sedat Dilek
On Wed, Jan 13, 2021 at 02:38:27PM -0800, Andrii Nakryiko wrote:
> Hm.. Just saw Linus proposing using $(error-if) in Kconfig for an
> unrelated issue ([0]). If we can make this work, then it would catch
> such issue early on, yet won't have any downsides of hiding
> CONFIG_DEBUG_INFO_BTF if pahole is too old. WDYT?
>
> [0] https://lore.kernel.org/lkml/CAHk-=wh-+TMHPTFo1qs-MYyK7tZh-OQovA=pP3=e06aCVp6_kA@mail.gmail.com/
Yes, I think that would be exactly what we want because DEBUG_INFO_BTF
could cause the build to error if PAHOLE_VERSION is not >= 116. I will
try to keep an eye on that thread to see how it goes then respin this
based on anything that comes from it.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* [PATCH] Documentation/llvm: Add a section about supported architectures
@ 2021-01-14 0:34 86% Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2021-01-14 0:34 UTC (permalink / raw)
To: Nick Desaulniers, Masahiro Yamada, Michal Marek, Jonathan Corbet
Cc: clang-built-linux, linux-kbuild, linux-doc, linux-kernel,
Nathan Chancellor, Miguel Ojeda
The most common question around building the Linux kernel with clang is
"does it work?" and the answer has always been "it depends on your
architecture, configuration, and LLVM version" with no hard answers for
users wanting to experiment. LLVM support has significantly improved
over the past couple of years, resulting in more architectures and
configurations supported, and continuous integration has made it easier
to see what works and what does not.
Add a section that goes over what architectures are supported in the
current kernel version, how they should be built (with just clang or the
LLVM utilities as well), and the level of support they receive. This
will make it easier for people to try out building their kernel with
LLVM and reporting issues that come about from it.
Suggested-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
Documentation/kbuild/llvm.rst | 44 +++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/Documentation/kbuild/llvm.rst b/Documentation/kbuild/llvm.rst
index 21c847890d03..b18401d2ba82 100644
--- a/Documentation/kbuild/llvm.rst
+++ b/Documentation/kbuild/llvm.rst
@@ -63,6 +63,50 @@ They can be enabled individually. The full list of the parameters: ::
Currently, the integrated assembler is disabled by default. You can pass
``LLVM_IAS=1`` to enable it.
+Supported Architectures
+-----------------------
+
+LLVM does not target all of the architectures that Linux supports and
+just because a target is supported in LLVM does not mean that the kernel
+will build or work without any issues. Below is a general summary of
+architectures that currently work with ``CC=clang`` or ``LLVM=1``. Level
+of support corresponds to "S" values in the MAINTAINERS files. If an
+architecture is not present, it either means that LLVM does not target
+it or there are known issues. Using the latest stable version of LLVM or
+even the development tree will generally yield the best results.
+An architecture's ``defconfig`` is generally expected to work well,
+certain configurations may have problems that have not been uncovered
+yet. Bug reports are always welcome at the issue tracker below!
+
+.. list-table::
+ :widths: 10 10 10
+ :header-rows: 1
+
+ * - Architecture
+ - Level of support
+ - ``make`` command
+ * - arm
+ - Supported
+ - ``LLVM=1``
+ * - arm64
+ - Supported
+ - ``LLVM=1``
+ * - mips
+ - Maintained
+ - ``CC=clang``
+ * - powerpc
+ - Maintained
+ - ``CC=clang``
+ * - riscv
+ - Maintained
+ - ``CC=clang``
+ * - s390
+ - Maintained
+ - ``CC=clang``
+ * - x86
+ - Supported
+ - ``LLVM=1``
+
Getting Help
------------
base-commit: 7c53f6b671f4aba70ff15e1b05148b10d58c2837
--
2.30.0
^ permalink raw reply related [relevance 86%]
* [PATCH] MAINTAINERS: Add a couple more files to the Clang/LLVM section
@ 2021-01-14 0:40 99% Nathan Chancellor
2021-01-14 17:16 99% ` [PATCH v2] MAINTAINERS: Add compiler-clang.h " Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2021-01-14 0:40 UTC (permalink / raw)
To: Nick Desaulniers, Andrew Morton
Cc: linux-kernel, clang-built-linux, Nathan Chancellor
The K: entry should ensure that Nick and I always get CC'd on patches
that touch these files but it is better to be explicit rather than
implicit.
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index cc1e6a5ee6e6..9127456b7eb1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4313,7 +4313,9 @@ W: https://clangbuiltlinux.github.io/
B: https://github.com/ClangBuiltLinux/linux/issues
C: irc://chat.freenode.net/clangbuiltlinux
F: Documentation/kbuild/llvm.rst
+F: include/linux/compiler-clang.h
F: scripts/clang-tools/
+F: scripts/clang-version.sh
F: scripts/lld-version.sh
K: \b(?i:clang|llvm)\b
base-commit: 7c53f6b671f4aba70ff15e1b05148b10d58c2837
--
2.30.0
^ permalink raw reply related [relevance 99%]
* Re: [PATCH v4] pgo: add clang's Profile Guided Optimization infrastructure
@ 2021-01-13 20:55 97% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-13 20:55 UTC (permalink / raw)
To: Bill Wendling
Cc: Jonathan Corbet, Masahiro Yamada, linux-doc, linux-kernel,
linux-kbuild, clang-built-linux, Andrew Morton, Nick Desaulniers,
Sami Tolvanen
Hi Bill,
On Tue, Jan 12, 2021 at 10:19:58PM -0800, Bill Wendling wrote:
> From: Sami Tolvanen <samitolvanen@google.com>
>
> Enable the use of clang's Profile-Guided Optimization[1]. To generate a
> profile, the kernel is instrumented with PGO counters, a representative
> workload is run, and the raw profile data is collected from
> /sys/kernel/debug/pgo/profraw.
>
> The raw profile data must be processed by clang's "llvm-profdata" tool
> before it can be used during recompilation:
>
> $ cp /sys/kernel/debug/pgo/profraw vmlinux.profraw
> $ llvm-profdata merge --output=vmlinux.profdata vmlinux.profraw
>
> Multiple raw profiles may be merged during this step.
>
> The data can now be used by the compiler:
>
> $ make LLVM=1 KCFLAGS=-fprofile-use=vmlinux.profdata ...
>
> This initial submission is restricted to x86, as that's the platform we
> know works. This restriction can be lifted once other platforms have
> been verified to work with PGO.
>
> Note that this method of profiling the kernel is clang-native, unlike
> the clang support in kernel/gcov.
>
> [1] https://clang.llvm.org/docs/UsersManual.html#profile-guided-optimization
>
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> Co-developed-by: Bill Wendling <morbo@google.com>
> Signed-off-by: Bill Wendling <morbo@google.com>
> Change-Id: Ic78e69c682286d3a44c4549a0138578c98138b77
Small nit: This should be removed.
I applied this patch on top of v5.11-rc3, built it with LLVM 12
(f1d5cbbdee5526bc86eac0a5652b115d9bc158e5 + D94470) with Microsoft's
WSL 5.4 config [1] + CONFIG_PGO_CLANG=y, and ran it on WSL2.
$ zgrep PGO /proc/config.gz
# Profile Guided Optimization (PGO) (EXPERIMENTAL)
CONFIG_ARCH_SUPPORTS_PGO_CLANG=y
CONFIG_PGO_CLANG=y
# end of Profile Guided Optimization (PGO) (EXPERIMENTAL)
However, I see an issue with actually using the data:
$ sudo -s
# mount -t debugfs none /sys/kernel/debug
# cp -a /sys/kernel/debug/pgo/profraw vmlinux.profraw
# chown nathan:nathan vmlinux.profraw
# exit
$ tc-build/build/llvm/stage1/bin/llvm-profdata merge --output=vmlinux.profdata vmlinux.profraw
warning: vmlinux.profraw: Invalid instrumentation profile data (bad magic)
error: No profiles could be merged.
Am I holding it wrong? :) Note, this is virtualized, I do not have any
"real" x86 hardware that I can afford to test on right now.
[1]: https://github.com/microsoft/WSL2-Linux-Kernel/raw/linux-msft-wsl-5.4.y/Microsoft/config-wsl
Cheers,
Nathan
^ permalink raw reply [relevance 97%]
* Backports of eff8728fe69880d3f7983bec3fb6cea4c306261f for 4.4 to 5.4
@ 2021-01-13 18:57 47% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-13 18:57 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sasha Levin
Cc: stable, Nick Desaulniers, clang-built-linux
[-- Attachment #1: Type: text/plain, Size: 261 bytes --]
Hi Greg and Sasha,
Please apply the attached backports of commit
eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input sections") to
4.4 through 5.4. I tried to make the file names obvious. This fixes a
boot failure on ARCH=arm with LLVM 12.
Cheers,
Nathan
[-- Attachment #2: eff8728fe6988-5.4-4.14.patch --]
[-- Type: text/x-diff, Size: 4210 bytes --]
From 6afd4a462594ea24bb602350cd95b4b00a2d8f5b Mon Sep 17 00:00:00 2001
From: Nick Desaulniers <ndesaulniers@google.com>
Date: Fri, 21 Aug 2020 12:42:47 -0700
Subject: [PATCH 5.4 to 4.14] vmlinux.lds.h: Add PGO and AutoFDO input sections
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
commit eff8728fe69880d3f7983bec3fb6cea4c306261f upstream.
Basically, consider .text.{hot|unlikely|unknown}.* part of .text, too.
When compiling with profiling information (collected via PGO
instrumentations or AutoFDO sampling), Clang will separate code into
.text.hot, .text.unlikely, or .text.unknown sections based on profiling
information. After D79600 (clang-11), these sections will have a
trailing `.` suffix, ie. .text.hot., .text.unlikely., .text.unknown..
When using -ffunction-sections together with profiling infomation,
either explicitly (FGKASLR) or implicitly (LTO), code may be placed in
sections following the convention:
.text.hot.<foo>, .text.unlikely.<bar>, .text.unknown.<baz>
where <foo>, <bar>, and <baz> are functions. (This produces one section
per function; we generally try to merge these all back via linker script
so that we don't have 50k sections).
For the above cases, we need to teach our linker scripts that such
sections might exist and that we'd explicitly like them grouped
together, otherwise we can wind up with code outside of the
_stext/_etext boundaries that might not be mapped properly for some
architectures, resulting in boot failures.
If the linker script is not told about possible input sections, then
where the section is placed as output is a heuristic-laiden mess that's
non-portable between linkers (ie. BFD and LLD), and has resulted in many
hard to debug bugs. Kees Cook is working on cleaning this up by adding
--orphan-handling=warn linker flag used in ARCH=powerpc to additional
architectures. In the case of linker scripts, borrowing from the Zen of
Python: explicit is better than implicit.
Also, ld.bfd's internal linker script considers .text.hot AND
.text.hot.* to be part of .text, as well as .text.unlikely and
.text.unlikely.*. I didn't see support for .text.unknown.*, and didn't
see Clang producing such code in our kernel builds, but I see code in
LLVM that can produce such section names if profiling information is
missing. That may point to a larger issue with generating or collecting
profiles, but I would much rather be safe and explicit than have to
debug yet another issue related to orphan section placement.
Reported-by: Jian Cai <jiancai@google.com>
Suggested-by: Fāng-ruì Sòng <maskray@google.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Tested-by: Luis Lozano <llozano@google.com>
Tested-by: Manoj Gupta <manojgupta@google.com>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: linux-arch@vger.kernel.org
Cc: stable@vger.kernel.org
Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=add44f8d5c5c05e08b11e033127a744d61c26aee
Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=1de778ed23ce7492c523d5850c6c6dbb34152655
Link: https://reviews.llvm.org/D79600
Link: https://bugs.chromium.org/p/chromium/issues/detail?id=1084760
Link: https://lore.kernel.org/r/20200821194310.3089815-7-keescook@chromium.org
Debugged-by: Luis Lozano <llozano@google.com>
[nc: Resolve small conflict due to lack of NOINSTR_TEXT]
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
include/asm-generic/vmlinux.lds.h | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index e5e242587595..130f16cc0b86 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -520,7 +520,10 @@
*/
#define TEXT_TEXT \
ALIGN_FUNCTION(); \
- *(.text.hot TEXT_MAIN .text.fixup .text.unlikely) \
+ *(.text.hot .text.hot.*) \
+ *(TEXT_MAIN .text.fixup) \
+ *(.text.unlikely .text.unlikely.*) \
+ *(.text.unknown .text.unknown.*) \
*(.text..refcount) \
*(.ref.text) \
MEM_KEEP(init.text*) \
--
2.30.0
[-- Attachment #3: eff8728fe6988-4.9.patch --]
[-- Type: text/x-diff, Size: 4218 bytes --]
From a017289ff8851b0b219b9b9d755685043ef4e5e3 Mon Sep 17 00:00:00 2001
From: Nick Desaulniers <ndesaulniers@google.com>
Date: Fri, 21 Aug 2020 12:42:47 -0700
Subject: [PATCH 4.9] vmlinux.lds.h: Add PGO and AutoFDO input sections
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
commit eff8728fe69880d3f7983bec3fb6cea4c306261f upstream.
Basically, consider .text.{hot|unlikely|unknown}.* part of .text, too.
When compiling with profiling information (collected via PGO
instrumentations or AutoFDO sampling), Clang will separate code into
.text.hot, .text.unlikely, or .text.unknown sections based on profiling
information. After D79600 (clang-11), these sections will have a
trailing `.` suffix, ie. .text.hot., .text.unlikely., .text.unknown..
When using -ffunction-sections together with profiling infomation,
either explicitly (FGKASLR) or implicitly (LTO), code may be placed in
sections following the convention:
.text.hot.<foo>, .text.unlikely.<bar>, .text.unknown.<baz>
where <foo>, <bar>, and <baz> are functions. (This produces one section
per function; we generally try to merge these all back via linker script
so that we don't have 50k sections).
For the above cases, we need to teach our linker scripts that such
sections might exist and that we'd explicitly like them grouped
together, otherwise we can wind up with code outside of the
_stext/_etext boundaries that might not be mapped properly for some
architectures, resulting in boot failures.
If the linker script is not told about possible input sections, then
where the section is placed as output is a heuristic-laiden mess that's
non-portable between linkers (ie. BFD and LLD), and has resulted in many
hard to debug bugs. Kees Cook is working on cleaning this up by adding
--orphan-handling=warn linker flag used in ARCH=powerpc to additional
architectures. In the case of linker scripts, borrowing from the Zen of
Python: explicit is better than implicit.
Also, ld.bfd's internal linker script considers .text.hot AND
.text.hot.* to be part of .text, as well as .text.unlikely and
.text.unlikely.*. I didn't see support for .text.unknown.*, and didn't
see Clang producing such code in our kernel builds, but I see code in
LLVM that can produce such section names if profiling information is
missing. That may point to a larger issue with generating or collecting
profiles, but I would much rather be safe and explicit than have to
debug yet another issue related to orphan section placement.
Reported-by: Jian Cai <jiancai@google.com>
Suggested-by: Fāng-ruì Sòng <maskray@google.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Tested-by: Luis Lozano <llozano@google.com>
Tested-by: Manoj Gupta <manojgupta@google.com>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: linux-arch@vger.kernel.org
Cc: stable@vger.kernel.org
Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=add44f8d5c5c05e08b11e033127a744d61c26aee
Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=1de778ed23ce7492c523d5850c6c6dbb34152655
Link: https://reviews.llvm.org/D79600
Link: https://bugs.chromium.org/p/chromium/issues/detail?id=1084760
Link: https://lore.kernel.org/r/20200821194310.3089815-7-keescook@chromium.org
Debugged-by: Luis Lozano <llozano@google.com>
[nc: Fix small conflict around lack of NOINSTR_TEXT and .text..refcount]
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
include/asm-generic/vmlinux.lds.h | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 4fdb1d984844..36198563fb8b 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -460,7 +460,10 @@
*/
#define TEXT_TEXT \
ALIGN_FUNCTION(); \
- *(.text.hot TEXT_MAIN .text.fixup .text.unlikely) \
+ *(.text.hot .text.hot.*) \
+ *(TEXT_MAIN .text.fixup) \
+ *(.text.unlikely .text.unlikely.*) \
+ *(.text.unknown .text.unknown.*) \
*(.ref.text) \
MEM_KEEP(init.text) \
MEM_KEEP(exit.text) \
--
2.30.0
[-- Attachment #4: eff8728fe6988-4.4.patch --]
[-- Type: text/x-diff, Size: 4292 bytes --]
From 43398bda7eafc0c5a79fbf9dfd593f106fd7f013 Mon Sep 17 00:00:00 2001
From: Nick Desaulniers <ndesaulniers@google.com>
Date: Fri, 21 Aug 2020 12:42:47 -0700
Subject: [PATCH 4.4] vmlinux.lds.h: Add PGO and AutoFDO input sections
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
commit eff8728fe69880d3f7983bec3fb6cea4c306261f upstream.
Basically, consider .text.{hot|unlikely|unknown}.* part of .text, too.
When compiling with profiling information (collected via PGO
instrumentations or AutoFDO sampling), Clang will separate code into
.text.hot, .text.unlikely, or .text.unknown sections based on profiling
information. After D79600 (clang-11), these sections will have a
trailing `.` suffix, ie. .text.hot., .text.unlikely., .text.unknown..
When using -ffunction-sections together with profiling infomation,
either explicitly (FGKASLR) or implicitly (LTO), code may be placed in
sections following the convention:
.text.hot.<foo>, .text.unlikely.<bar>, .text.unknown.<baz>
where <foo>, <bar>, and <baz> are functions. (This produces one section
per function; we generally try to merge these all back via linker script
so that we don't have 50k sections).
For the above cases, we need to teach our linker scripts that such
sections might exist and that we'd explicitly like them grouped
together, otherwise we can wind up with code outside of the
_stext/_etext boundaries that might not be mapped properly for some
architectures, resulting in boot failures.
If the linker script is not told about possible input sections, then
where the section is placed as output is a heuristic-laiden mess that's
non-portable between linkers (ie. BFD and LLD), and has resulted in many
hard to debug bugs. Kees Cook is working on cleaning this up by adding
--orphan-handling=warn linker flag used in ARCH=powerpc to additional
architectures. In the case of linker scripts, borrowing from the Zen of
Python: explicit is better than implicit.
Also, ld.bfd's internal linker script considers .text.hot AND
.text.hot.* to be part of .text, as well as .text.unlikely and
.text.unlikely.*. I didn't see support for .text.unknown.*, and didn't
see Clang producing such code in our kernel builds, but I see code in
LLVM that can produce such section names if profiling information is
missing. That may point to a larger issue with generating or collecting
profiles, but I would much rather be safe and explicit than have to
debug yet another issue related to orphan section placement.
Reported-by: Jian Cai <jiancai@google.com>
Suggested-by: Fāng-ruì Sòng <maskray@google.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Tested-by: Luis Lozano <llozano@google.com>
Tested-by: Manoj Gupta <manojgupta@google.com>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: linux-arch@vger.kernel.org
Cc: stable@vger.kernel.org
Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=add44f8d5c5c05e08b11e033127a744d61c26aee
Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=1de778ed23ce7492c523d5850c6c6dbb34152655
Link: https://reviews.llvm.org/D79600
Link: https://bugs.chromium.org/p/chromium/issues/detail?id=1084760
Link: https://lore.kernel.org/r/20200821194310.3089815-7-keescook@chromium.org
Debugged-by: Luis Lozano <llozano@google.com>
[nc: Fix conflicts around lack of TEXT_MAIN, NOINSTR_TEXT, and
.text..refcount]
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
include/asm-generic/vmlinux.lds.h | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index a461b6604fd9..c8535bc1826f 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -422,7 +422,10 @@
* during second ld run in second ld pass when generating System.map */
#define TEXT_TEXT \
ALIGN_FUNCTION(); \
- *(.text.hot .text .text.fixup .text.unlikely) \
+ *(.text.hot .text.hot.*) \
+ *(.text .text.fixup) \
+ *(.text.unlikely .text.unlikely.*) \
+ *(.text.unknown .text.unknown.*) \
*(.ref.text) \
MEM_KEEP(init.text) \
MEM_KEEP(exit.text) \
--
2.30.0
^ permalink raw reply related [relevance 47%]
* Re: [PATCH v4 3/3] Kbuild: implement support for DWARF v5
@ 2021-01-13 17:55 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-13 17:55 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Masahiro Yamada, Andrew Morton, Sedat Dilek, linux-kernel,
clang-built-linux, linux-kbuild, linux-arch, Jakub Jelinek,
Fangrui Song, Caroline Tice, Nick Clifton, Arvind Sankar
On Tue, Jan 12, 2021 at 04:32:35PM -0800, Nick Desaulniers wrote:
> DWARF v5 is the latest standard of the DWARF debug info format.
>
> Feature detection of DWARF5 is onerous, especially given that we've
> removed $(AS), so we must query $(CC) for DWARF5 assembler directive
> support. GNU `as` only recently gained support for specifying
> -gdwarf-5.
>
> The DWARF version of a binary can be validated with:
> $ llvm-dwarfdump vmlinux | head -n 4 | grep version
> or
> $ readelf --debug-dump=info vmlinux 2>/dev/null | grep Version
>
> DWARF5 wins significantly in terms of size when mixed with compression
> (CONFIG_DEBUG_INFO_COMPRESSED).
>
> 363M vmlinux.clang12.dwarf5.compressed
> 434M vmlinux.clang12.dwarf4.compressed
> 439M vmlinux.clang12.dwarf2.compressed
> 457M vmlinux.clang12.dwarf5
> 536M vmlinux.clang12.dwarf4
> 548M vmlinux.clang12.dwarf2
>
> 515M vmlinux.gcc10.2.dwarf5.compressed
> 599M vmlinux.gcc10.2.dwarf4.compressed
> 624M vmlinux.gcc10.2.dwarf2.compressed
> 630M vmlinux.gcc10.2.dwarf5
> 765M vmlinux.gcc10.2.dwarf4
> 809M vmlinux.gcc10.2.dwarf2
>
> Though the quality of debug info is harder to quantify; size is not a
> proxy for quality.
>
> Jakub notes:
> All [GCC] 5.1 - 6.x did was start accepting -gdwarf-5 as experimental
> option that enabled some small DWARF subset (initially only a few
> DW_LANG_* codes newly added to DWARF5 drafts). Only GCC 7 (released
> after DWARF 5 has been finalized) started emitting DWARF5 section
> headers and got most of the DWARF5 changes in...
>
> Version check GCC so that we don't need to worry about the difference in
> command line args between GNU readelf and llvm-readelf/llvm-dwarfdump to
> validate the DWARF Version in the assembler feature detection script.
>
> Link: http://www.dwarfstd.org/doc/DWARF5.pdf
> Suggested-by: Arvind Sankar <nivedita@alum.mit.edu>
> Suggested-by: Jakub Jelinek <jakub@redhat.com>
> Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
> Suggested-by: Fangrui Song <maskray@google.com>
> Suggested-by: Caroline Tice <cmtice@google.com>
> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
One small nit below.
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> Makefile | 1 +
> include/asm-generic/vmlinux.lds.h | 6 +++++-
> lib/Kconfig.debug | 17 +++++++++++++++++
> scripts/test_dwarf5_support.sh | 9 +++++++++
> 4 files changed, 32 insertions(+), 1 deletion(-)
> create mode 100755 scripts/test_dwarf5_support.sh
>
> diff --git a/Makefile b/Makefile
> index 656fff17b331..1067cfd98249 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -828,6 +828,7 @@ endif
>
> dwarf-version-$(CONFIG_DEBUG_INFO_DWARF2) := 2
> dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
> +dwarf-version-$(CONFIG_DEBUG_INFO_DWARF5) := 5
> DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y)
> ifneq ($(dwarf-version-y)$(LLVM_IAS),21)
> # Binutils 2.35+ required for -gdwarf-4+ support.
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index 49944f00d2b3..37dc4110875e 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -843,7 +843,11 @@
> .debug_types 0 : { *(.debug_types) } \
> /* DWARF 5 */ \
> .debug_macro 0 : { *(.debug_macro) } \
> - .debug_addr 0 : { *(.debug_addr) }
> + .debug_addr 0 : { *(.debug_addr) } \
> + .debug_line_str 0 : { *(.debug_line_str) } \
> + .debug_loclists 0 : { *(.debug_loclists) } \
> + .debug_rnglists 0 : { *(.debug_rnglists) } \
> + .debug_str_offsets 0 : { *(.debug_str_offsets) }
>
> /* Stabs debugging sections. */
> #define STABS_DEBUG \
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index e80770fac4f0..60a4f5e27ada 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -273,6 +273,23 @@ config DEBUG_INFO_DWARF4
> It makes the debug information larger, but it significantly
> improves the success of resolving variables in gdb on optimized code.
>
> +config DEBUG_INFO_DWARF5
> + bool "Generate DWARF Version 5 debuginfo"
> + depends on GCC_VERSION >= 50000 || CC_IS_CLANG
> + depends on CC_IS_GCC || $(success,$(srctree)/scripts/test_dwarf5_support.sh $(CC) $(CLANG_FLAGS))
> + help
> + Generate DWARF v5 debug info. Requires binutils 2.35, gcc 5.0+ (gcc
> + 5.0+ accepts the -gdwarf-5 flag but only had partial support for some
> + draft features until 7.0), and gdb 8.0+.
> +
> + Changes to the structure of debug info in Version 5 allow for around
> + 15-18% savings in resulting image and debug info section sizes as
> + compared to DWARF Version 4. DWARF Version 5 standardizes previous
> + extensions such as accelerators for symbol indexing and the format
> + for fission (.dwo/.dwp) files. Users may not want to select this
> + config if they rely on tooling that has not yet been updated to
> + support DWARF Version 5.
> +
> endchoice # "DWARF version"
>
> config DEBUG_INFO_BTF
> diff --git a/scripts/test_dwarf5_support.sh b/scripts/test_dwarf5_support.sh
> new file mode 100755
> index 000000000000..142a1b5c7fa2
> --- /dev/null
> +++ b/scripts/test_dwarf5_support.sh
> @@ -0,0 +1,9 @@
> +#!/bin/sh
> +# SPDX-License-Identifier: GPL-2.0
> +
> +# Test that assembler accepts -gdwarf-5 and .file 0 directives, which were bugs
> +# in binutils < 2.35.
> +# https://sourceware.org/bugzilla/show_bug.cgi?id=25612
> +# https://sourceware.org/bugzilla/show_bug.cgi?id=25614
> +set -e
This is unnecessary, clang will error without this and a script's exit
code is the exit code of its last command.
> +echo '.file 0 "filename"' | $* -gdwarf-5 -Wa,-gdwarf-5 -c -x assembler -o /dev/null -
> --
> 2.30.0.284.gd98b1dd5eaa7-goog
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH v4 2/3] Kbuild: make DWARF version a choice
@ 2021-01-13 17:51 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-13 17:51 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Masahiro Yamada, Andrew Morton, Sedat Dilek, linux-kernel,
clang-built-linux, linux-kbuild, linux-arch, Jakub Jelinek,
Fangrui Song, Caroline Tice, Nick Clifton
On Tue, Jan 12, 2021 at 04:32:34PM -0800, Nick Desaulniers wrote:
> Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice. Adds an
> explicit CONFIG_DEBUG_INFO_DWARF2, which is the default. Does so in a
> way that's forward compatible with existing configs, and makes adding
> future versions more straightforward.
>
> Suggested-by: Fangrui Song <maskray@google.com>
> Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> Makefile | 14 +++++++++-----
> lib/Kconfig.debug | 21 ++++++++++++++++-----
> 2 files changed, 25 insertions(+), 10 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index d49c3f39ceb4..656fff17b331 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -826,12 +826,16 @@ else
> DEBUG_CFLAGS += -g
> endif
>
> -ifneq ($(LLVM_IAS),1)
> -KBUILD_AFLAGS += -Wa,-gdwarf-2
> +dwarf-version-$(CONFIG_DEBUG_INFO_DWARF2) := 2
> +dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
> +DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y)
> +ifneq ($(dwarf-version-y)$(LLVM_IAS),21)
> +# Binutils 2.35+ required for -gdwarf-4+ support.
> +dwarf-aflag := $(call as-option,-Wa$(comma)-gdwarf-$(dwarf-version-y))
> +ifdef CONFIG_CC_IS_CLANG
> +DEBUG_CFLAGS += $(dwarf-aflag)
> endif
> -
> -ifdef CONFIG_DEBUG_INFO_DWARF4
> -DEBUG_CFLAGS += -gdwarf-4
> +KBUILD_AFLAGS += $(dwarf-aflag)
> endif
>
> ifdef CONFIG_DEBUG_INFO_REDUCED
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index dd7d8d35b2a5..e80770fac4f0 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -256,13 +256,24 @@ config DEBUG_INFO_SPLIT
> to know about the .dwo files and include them.
> Incompatible with older versions of ccache.
>
> +choice
> + prompt "DWARF version"
> + help
> + Which version of DWARF debug info to emit.
> +
> +config DEBUG_INFO_DWARF2
> + bool "Generate DWARF Version 2 debuginfo"
> + help
> + Generate DWARF v2 debug info.
> +
> config DEBUG_INFO_DWARF4
> - bool "Generate dwarf4 debuginfo"
> + bool "Generate DWARF Version 4 debuginfo"
> help
> - Generate dwarf4 debug info. This requires recent versions
> - of gcc and gdb. It makes the debug information larger.
> - But it significantly improves the success of resolving
> - variables in gdb on optimized code.
> + Generate DWARF v4 debug info. This requires gcc 4.5+ and gdb 7.0+.
> + It makes the debug information larger, but it significantly
> + improves the success of resolving variables in gdb on optimized code.
> +
> +endchoice # "DWARF version"
>
> config DEBUG_INFO_BTF
> bool "Generate BTF typeinfo"
> --
> 2.30.0.284.gd98b1dd5eaa7-goog
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH v4 1/3] Remove $(cc-option,-gdwarf-4) dependency from CONFIG_DEBUG_INFO_DWARF4
@ 2021-01-13 17:48 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-13 17:48 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Masahiro Yamada, Andrew Morton, Sedat Dilek, linux-kernel,
clang-built-linux, linux-kbuild, linux-arch, Jakub Jelinek,
Fangrui Song, Caroline Tice, Nick Clifton
On Tue, Jan 12, 2021 at 04:32:33PM -0800, Nick Desaulniers wrote:
> From: Masahiro Yamada <masahiroy@kernel.org>
>
> The -gdwarf-4 flag is supported by GCC 4.5+, and also by Clang.
>
> You can see it at https://godbolt.org/z/6ed1oW
>
> For gcc 4.5.3 pane, line 37: .value 0x4
> For clang 10.0.1 pane, line 117: .short 4
>
> Given Documentation/process/changes.rst stating GCC 4.9 is the minimal
> version, this cc-option is unneeded.
>
> Note
> ----
>
> CONFIG_DEBUG_INFO_DWARF4 controls the DWARF version only for C files.
>
> As you can see in the top Makefile, -gdwarf-4 is only passed to CFLAGS.
>
> ifdef CONFIG_DEBUG_INFO_DWARF4
> DEBUG_CFLAGS += -gdwarf-4
> endif
>
> This flag is used when compiling *.c files.
>
> On the other hand, the assembler is always given -gdwarf-2.
>
> KBUILD_AFLAGS += -Wa,-gdwarf-2
>
> Hence, the debug info that comes from *.S files is always DWARF v2.
> This is simply because GAS supported only -gdwarf-2 for a long time.
>
> Recently, GAS gained the support for --dwarf-[3|4|5] options. [1]
> And, also we have Clang integrated assembler. So, the debug info
> for *.S files might be improved if we want.
>
> In my understanding, the current code is intentional, not a bug.
>
> [1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=31bf18645d98b4d3d7357353be840e320649a67d
>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> lib/Kconfig.debug | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 78361f0abe3a..dd7d8d35b2a5 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -258,7 +258,6 @@ config DEBUG_INFO_SPLIT
>
> config DEBUG_INFO_DWARF4
> bool "Generate dwarf4 debuginfo"
> - depends on $(cc-option,-gdwarf-4)
> help
> Generate dwarf4 debug info. This requires recent versions
> of gcc and gdb. It makes the debug information larger.
> --
> 2.30.0.284.gd98b1dd5eaa7-goog
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] ubsan: Implement __ubsan_handle_alignment_assumption
@ 2021-01-13 1:31 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-13 1:31 UTC (permalink / raw)
To: kernel test robot
Cc: Kees Cook, Andrew Morton, kbuild-all, clang-built-linux,
Linux Memory Management List, Nick Desaulniers, linux-kernel
On Wed, Jan 13, 2021 at 08:39:52AM +0800, kernel test robot wrote:
> Hi Nathan,
>
> I love your patch! Perhaps something to improve:
>
> [auto build test WARNING on 7c53f6b671f4aba70ff15e1b05148b10d58c2837]
>
> url: https://github.com/0day-ci/linux/commits/Nathan-Chancellor/ubsan-Implement-__ubsan_handle_alignment_assumption/20210113-055714
> base: 7c53f6b671f4aba70ff15e1b05148b10d58c2837
> config: arm64-randconfig-r031-20210112 (attached as .config)
> compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 32bcfcda4e28375e5a85268d2acfabcfcc011abf)
> reproduce (this is a W=1 build):
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # install arm64 cross compiling tool for clang build
> # apt-get install binutils-aarch64-linux-gnu
> # https://github.com/0day-ci/linux/commit/775adad26a60878926c0ee6cd460a1375bbe51e6
> git remote add linux-review https://github.com/0day-ci/linux
> git fetch --no-tags linux-review Nathan-Chancellor/ubsan-Implement-__ubsan_handle_alignment_assumption/20210113-055714
> git checkout 775adad26a60878926c0ee6cd460a1375bbe51e6
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
>
> All warnings (new ones prefixed by >>):
>
> lib/ubsan.c:192:6: warning: no previous prototype for function '__ubsan_handle_add_overflow' [-Wmissing-prototypes]
> void __ubsan_handle_add_overflow(void *data,
> ^
> lib/ubsan.c:192:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
> void __ubsan_handle_add_overflow(void *data,
> ^
> static
> lib/ubsan.c:200:6: warning: no previous prototype for function '__ubsan_handle_sub_overflow' [-Wmissing-prototypes]
> void __ubsan_handle_sub_overflow(void *data,
> ^
> lib/ubsan.c:200:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
> void __ubsan_handle_sub_overflow(void *data,
> ^
Given that these are compiler inserted functions, there is not much of a
point to having prototypes to them. If people feel shutting these
warnings up is worthwhile, we can just add the prototypes right above
the function definition in a follow up patch.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] [v2] ubsan: disable unsigned-overflow check for i386
@ 2021-01-13 0:05 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-13 0:05 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Nick Desaulniers, Kees Cook, Stephen Rothwell, Andrew Morton,
Arnd Bergmann, Marco Elver, George Popescu, linux-kernel,
clang-built-linux
On Tue, Jan 12, 2021 at 09:29:15PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Building ubsan kernels even for compile-testing introduced these
> warnings in my randconfig environment:
>
> crypto/blake2b_generic.c:98:13: error: stack frame size of 9636 bytes in function 'blake2b_compress' [-Werror,-Wframe-larger-than=]
> static void blake2b_compress(struct blake2b_state *S,
> crypto/sha512_generic.c:151:13: error: stack frame size of 1292 bytes in function 'sha512_generic_block_fn' [-Werror,-Wframe-larger-than=]
> static void sha512_generic_block_fn(struct sha512_state *sst, u8 const *src,
> lib/crypto/curve25519-fiat32.c:312:22: error: stack frame size of 2180 bytes in function 'fe_mul_impl' [-Werror,-Wframe-larger-than=]
> static noinline void fe_mul_impl(u32 out[10], const u32 in1[10], const u32 in2[10])
> lib/crypto/curve25519-fiat32.c:444:22: error: stack frame size of 1588 bytes in function 'fe_sqr_impl' [-Werror,-Wframe-larger-than=]
> static noinline void fe_sqr_impl(u32 out[10], const u32 in1[10])
>
> Further testing showed that this is caused by
> -fsanitize=unsigned-integer-overflow, but is isolated to the 32-bit
> x86 architecture.
>
> The one in blake2b immediately overflows the 8KB stack area architectures,
> so better ensure this never happens by disabling the option for 32-bit
> x86.
>
> Fixes: d0a3ac549f38 ("ubsan: enable for all*config builds")
> Link: https://lore.kernel.org/lkml/20201230154749.746641-1-arnd@kernel.org/
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> v2: only turn it off for i386 as discussed
> ---
> lib/Kconfig.ubsan | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
> index 8b635fd75fe4..3a0b1c930733 100644
> --- a/lib/Kconfig.ubsan
> +++ b/lib/Kconfig.ubsan
> @@ -123,6 +123,7 @@ config UBSAN_SIGNED_OVERFLOW
> config UBSAN_UNSIGNED_OVERFLOW
> bool "Perform checking for unsigned arithmetic overflow"
> depends on $(cc-option,-fsanitize=unsigned-integer-overflow)
> + depends on !X86_32 # avoid excessive stack usage on x86-32/clang
> help
> This option enables -fsanitize=unsigned-integer-overflow which checks
> for overflow of any arithmetic operations with unsigned integers. This
> --
> 2.29.2
>
^ permalink raw reply [relevance 99%]
* [PATCH v2] ubsan: Implement __ubsan_handle_alignment_assumption
2021-01-12 20:55 95% [PATCH] ubsan: Implement __ubsan_handle_alignment_assumption Nathan Chancellor
@ 2021-01-13 0:12 93% ` Nathan Chancellor
2 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-13 0:12 UTC (permalink / raw)
To: Andrew Morton
Cc: Kees Cook, Nick Desaulniers, linux-kernel, clang-built-linux,
Nathan Chancellor
When building ARCH=mips 32r2el_defconfig with CONFIG_UBSAN_ALIGNMENT:
ld.lld: error: undefined symbol: __ubsan_handle_alignment_assumption
>>> referenced by slab.h:557 (include/linux/slab.h:557)
>>> main.o:(do_initcalls) in archive init/built-in.a
>>> referenced by slab.h:448 (include/linux/slab.h:448)
>>> do_mounts_rd.o:(rd_load_image) in archive init/built-in.a
>>> referenced by slab.h:448 (include/linux/slab.h:448)
>>> do_mounts_rd.o:(identify_ramdisk_image) in archive init/built-in.a
>>> referenced 1579 more times
Implement this for the kernel based on LLVM's
handleAlignmentAssumptionImpl because the kernel is not linked against
the compiler runtime.
Link: https://github.com/ClangBuiltLinux/linux/issues/1245
Link: https://github.com/llvm/llvm-project/blob/llvmorg-11.0.1/compiler-rt/lib/ubsan/ubsan_handlers.cpp#L151-L190
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
v1 -> v2:
* Use __ffs instead of ffs because due to size of input (unsigned long
vs int) and we want a zero based index (Nick Desaulniers).
* Pick up Kees's ack.
lib/ubsan.c | 28 ++++++++++++++++++++++++++++
lib/ubsan.h | 6 ++++++
2 files changed, 34 insertions(+)
diff --git a/lib/ubsan.c b/lib/ubsan.c
index 3e3352f3d0da..1432a8645224 100644
--- a/lib/ubsan.c
+++ b/lib/ubsan.c
@@ -427,3 +427,31 @@ void __ubsan_handle_load_invalid_value(void *_data, void *val)
ubsan_epilogue();
}
EXPORT_SYMBOL(__ubsan_handle_load_invalid_value);
+
+void __ubsan_handle_alignment_assumption(void *_data, unsigned long ptr,
+ unsigned long align,
+ unsigned long offset)
+{
+ struct alignment_assumption_data *data = _data;
+ unsigned long real_ptr;
+
+ if (suppress_report(&data->location))
+ return;
+
+ ubsan_prologue(&data->location, "alignment-assumption");
+
+ if (offset)
+ pr_err("assumption of %lu byte alignment (with offset of %lu byte) for pointer of type %s failed",
+ align, offset, data->type->type_name);
+ else
+ pr_err("assumption of %lu byte alignment for pointer of type %s failed",
+ align, data->type->type_name);
+
+ real_ptr = ptr - offset;
+ pr_err("%saddress is %lu aligned, misalignment offset is %lu bytes",
+ offset ? "offset " : "", BIT(real_ptr ? __ffs(real_ptr) : 0),
+ real_ptr & (align - 1));
+
+ ubsan_epilogue();
+}
+EXPORT_SYMBOL(__ubsan_handle_alignment_assumption);
diff --git a/lib/ubsan.h b/lib/ubsan.h
index 7b56c09473a9..9a0b71c5ff9f 100644
--- a/lib/ubsan.h
+++ b/lib/ubsan.h
@@ -78,6 +78,12 @@ struct invalid_value_data {
struct type_descriptor *type;
};
+struct alignment_assumption_data {
+ struct source_location location;
+ struct source_location assumption_location;
+ struct type_descriptor *type;
+};
+
#if defined(CONFIG_ARCH_SUPPORTS_INT128)
typedef __int128 s_max;
typedef unsigned __int128 u_max;
base-commit: 7c53f6b671f4aba70ff15e1b05148b10d58c2837
--
2.30.0
^ permalink raw reply related [relevance 93%]
* Re: [PATCH] compiler.h: Raise minimum version of GCC to 5.1 for arm64
@ 2021-01-12 23:06 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-12 23:06 UTC (permalink / raw)
To: Will Deacon
Cc: Florian Weimer, Arnd Bergmann, Theodore Ts'o, Peter Zijlstra,
Catalin Marinas, Nick Desaulniers, linux-kernel, Russell King,
Linus Torvalds, kernel-team, linux-arm-kernel
On Tue, Jan 12, 2021 at 10:48:32PM +0000, Will Deacon wrote:
> GCC versions >= 4.9 and < 5.1 have been shown to emit memory references
> beyond the stack pointer, resulting in memory corruption if an interrupt
> is taken after the stack pointer has been adjusted but before the
> reference has been executed. This leads to subtle, infrequent data
> corruption such as the EXT4 problems reported by Russell King at the
> link below.
>
> Life is too short for buggy compilers, so raise the minimum GCC version
> required by arm64 to 5.1.
>
> Cc: Theodore Ts'o <tytso@mit.edu>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Florian Weimer <fweimer@redhat.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Nick Desaulniers <ndesaulniers@google.com>
> Reported-by: Russell King <linux@armlinux.org.uk>
> Suggested-by: Arnd Bergmann <arnd@kernel.org>
> Link: https://lore.kernel.org/r/20210105154726.GD1551@shell.armlinux.org.uk
> Signed-off-by: Will Deacon <will@kernel.org>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> include/linux/compiler-gcc.h | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index 74c6c0486eed..555ab0fddbef 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -13,6 +13,12 @@
> /* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 */
> #if GCC_VERSION < 40900
> # error Sorry, your version of GCC is too old - please use 4.9 or newer.
> +#elif defined(CONFIG_ARM64) && GCC_VERSION < 50100
> +/*
> + * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63293
> + * https://lore.kernel.org/r/20210107111841.GN1551@shell.armlinux.org.uk
> + */
> +# error Sorry, your version of GCC is too old - please use 5.1 or newer.
> #endif
>
> /*
> --
> 2.30.0.284.gd98b1dd5eaa7-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [relevance 99%]
* Re: [PATCH] compiler.h: Raise minimum version of GCC to 5.1 for arm64
@ 2021-01-12 23:06 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-12 23:06 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arm-kernel, kernel-team, linux-kernel, Theodore Ts'o,
Catalin Marinas, Florian Weimer, Peter Zijlstra, Linus Torvalds,
Nick Desaulniers, Russell King, Arnd Bergmann
On Tue, Jan 12, 2021 at 10:48:32PM +0000, Will Deacon wrote:
> GCC versions >= 4.9 and < 5.1 have been shown to emit memory references
> beyond the stack pointer, resulting in memory corruption if an interrupt
> is taken after the stack pointer has been adjusted but before the
> reference has been executed. This leads to subtle, infrequent data
> corruption such as the EXT4 problems reported by Russell King at the
> link below.
>
> Life is too short for buggy compilers, so raise the minimum GCC version
> required by arm64 to 5.1.
>
> Cc: Theodore Ts'o <tytso@mit.edu>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Florian Weimer <fweimer@redhat.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Nick Desaulniers <ndesaulniers@google.com>
> Reported-by: Russell King <linux@armlinux.org.uk>
> Suggested-by: Arnd Bergmann <arnd@kernel.org>
> Link: https://lore.kernel.org/r/20210105154726.GD1551@shell.armlinux.org.uk
> Signed-off-by: Will Deacon <will@kernel.org>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> include/linux/compiler-gcc.h | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index 74c6c0486eed..555ab0fddbef 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -13,6 +13,12 @@
> /* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 */
> #if GCC_VERSION < 40900
> # error Sorry, your version of GCC is too old - please use 4.9 or newer.
> +#elif defined(CONFIG_ARM64) && GCC_VERSION < 50100
> +/*
> + * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63293
> + * https://lore.kernel.org/r/20210107111841.GN1551@shell.armlinux.org.uk
> + */
> +# error Sorry, your version of GCC is too old - please use 5.1 or newer.
> #endif
>
> /*
> --
> 2.30.0.284.gd98b1dd5eaa7-goog
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] ubsan: Implement __ubsan_handle_alignment_assumption
@ 2021-01-12 22:06 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-12 22:06 UTC (permalink / raw)
To: Nick Desaulniers; +Cc: Kees Cook, Andrew Morton, LKML, clang-built-linux
On Tue, Jan 12, 2021 at 01:53:30PM -0800, Nick Desaulniers wrote:
> On Tue, Jan 12, 2021 at 1:37 PM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> >
> > > if real_ptr is an unsigned long, do we want to use `__ffs(real_ptr) +
> > > 1` here rather than ffs which takes an int? It seems the kernel is
> > > missing a definition of ffsl. :(
> >
> > Why the + 1? I think if we use __ffs (which it seems like we should), I
> > think that needs to become
>
> This came up recently in an internal code review; ffs and __ffs differ
> in output by one. See also the definition of ffs for alpha in
> arch/alpha/include/asm/bitops.h.
Interesting, thanks for bringing it up! Looks like ffs returns 1-32 and
__ffs returns 0-31. I think that we want __ffs here because we are
shifting (1UL << 32 overflows on 32-bit architectures) and the code in
LLVM appears to agree. LeastSignificantSetBitIndex evaluates to
__builtin_ctzl, which is the asm-generic implementation of __ffs.
Cheers,
NAthan
^ permalink raw reply [relevance 99%]
* Re: upstream build error (12)
2021-01-12 19:40 99% ` Nathan Chancellor
@ 2021-01-12 20:32 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-12 20:32 UTC (permalink / raw)
To: syzbot
Cc: linux-kernel, syzkaller-bugs, clang-built-linux, Dmitry Vyukov,
Marco Elver
On Tue, Jan 12, 2021 at 12:40:58PM -0700, Nathan Chancellor wrote:
> On Tue, Jan 12, 2021 at 11:20:27AM -0800, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit: e609571b Merge tag 'nfs-for-5.11-2' of git://git.linux-nfs..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=15965a00d00000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=6157970d0a91b812
> > dashboard link: https://syzkaller.appspot.com/bug?extid=76880518931d755473cf
> > compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project.git ca2dcbd030eadbf0aa9b660efe864ff08af6e18b)
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+76880518931d755473cf@syzkaller.appspotmail.com
> >
> > clang-11: error: unable to execute command: Aborted (core dumped)
> > clang-11: error: clang frontend command failed due to signal (use -v to see invocation)
> >
> > ---
> > This report is generated by a bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for more information about syzbot.
> > syzbot engineers can be reached at syzkaller@googlegroups.com.
> >
> > syzbot will keep track of this issue. See:
> > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
> Would it be possible for clang-built-linux@googlegroups.com to be CC'd
> when there is a build error and the compiler is clang? Especially if
> clang is hitting an assertion.
I cannot reproduce this with clang 11.0.1. I did a reverse bisect on
LLVM and found commit 4b0aa5724fea ("Change the INLINEASM_BR MachineInstr
to be a non-terminating instruction.") as the fix (which makes sense,
that commit has direct kernel implications). It is probably worth
upgrading syzkaller's clang to 11.0.1, where I have not seen any
assertions across all of the configurations that I test.
Ccing Dmitry and Marco directly.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* [PATCH] ubsan: Implement __ubsan_handle_alignment_assumption
@ 2021-01-12 20:55 95% Nathan Chancellor
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Nathan Chancellor @ 2021-01-12 20:55 UTC (permalink / raw)
To: Kees Cook, Andrew Morton
Cc: Nick Desaulniers, linux-kernel, clang-built-linux, Nathan Chancellor
When building ARCH=mips 32r2el_defconfig with CONFIG_UBSAN_ALIGNMENT:
ld.lld: error: undefined symbol: __ubsan_handle_alignment_assumption
>>> referenced by slab.h:557 (include/linux/slab.h:557)
>>> main.o:(do_initcalls) in archive init/built-in.a
>>> referenced by slab.h:448 (include/linux/slab.h:448)
>>> do_mounts_rd.o:(rd_load_image) in archive init/built-in.a
>>> referenced by slab.h:448 (include/linux/slab.h:448)
>>> do_mounts_rd.o:(identify_ramdisk_image) in archive init/built-in.a
>>> referenced 1579 more times
Implement this for the kernel based on LLVM's
handleAlignmentAssumptionImpl because the kernel is not linked against
the compiler runtime.
Link: https://github.com/ClangBuiltLinux/linux/issues/1245
Link: https://github.com/llvm/llvm-project/blob/llvmorg-11.0.1/compiler-rt/lib/ubsan/ubsan_handlers.cpp#L151-L190
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
lib/ubsan.c | 28 ++++++++++++++++++++++++++++
lib/ubsan.h | 6 ++++++
2 files changed, 34 insertions(+)
diff --git a/lib/ubsan.c b/lib/ubsan.c
index 3e3352f3d0da..a1e6cc9993f8 100644
--- a/lib/ubsan.c
+++ b/lib/ubsan.c
@@ -427,3 +427,31 @@ void __ubsan_handle_load_invalid_value(void *_data, void *val)
ubsan_epilogue();
}
EXPORT_SYMBOL(__ubsan_handle_load_invalid_value);
+
+void __ubsan_handle_alignment_assumption(void *_data, unsigned long ptr,
+ unsigned long align,
+ unsigned long offset)
+{
+ struct alignment_assumption_data *data = _data;
+ unsigned long real_ptr;
+
+ if (suppress_report(&data->location))
+ return;
+
+ ubsan_prologue(&data->location, "alignment-assumption");
+
+ if (offset)
+ pr_err("assumption of %lu byte alignment (with offset of %lu byte) for pointer of type %s failed",
+ align, offset, data->type->type_name);
+ else
+ pr_err("assumption of %lu byte alignment for pointer of type %s failed",
+ align, data->type->type_name);
+
+ real_ptr = ptr - offset;
+ pr_err("%saddress is %lu aligned, misalignment offset is %lu bytes",
+ offset ? "offset " : "", BIT(ffs(real_ptr)),
+ real_ptr & (align - 1));
+
+ ubsan_epilogue();
+}
+EXPORT_SYMBOL(__ubsan_handle_alignment_assumption);
diff --git a/lib/ubsan.h b/lib/ubsan.h
index 7b56c09473a9..9a0b71c5ff9f 100644
--- a/lib/ubsan.h
+++ b/lib/ubsan.h
@@ -78,6 +78,12 @@ struct invalid_value_data {
struct type_descriptor *type;
};
+struct alignment_assumption_data {
+ struct source_location location;
+ struct source_location assumption_location;
+ struct type_descriptor *type;
+};
+
#if defined(CONFIG_ARCH_SUPPORTS_INT128)
typedef __int128 s_max;
typedef unsigned __int128 u_max;
base-commit: 7c53f6b671f4aba70ff15e1b05148b10d58c2837
--
2.30.0
^ permalink raw reply related [relevance 95%]
* Re: [PATCH] ubsan: Implement __ubsan_handle_alignment_assumption
@ 2021-01-12 21:37 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2021-01-12 21:37 UTC (permalink / raw)
To: Nick Desaulniers; +Cc: Kees Cook, Andrew Morton, LKML, clang-built-linux
On Tue, Jan 12, 2021 at 01:15:42PM -0800, Nick Desaulniers wrote:
> On Tue, Jan 12, 2021 at 12:55 PM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> >
> > When building ARCH=mips 32r2el_defconfig with CONFIG_UBSAN_ALIGNMENT:
> >
> > ld.lld: error: undefined symbol: __ubsan_handle_alignment_assumption
> > >>> referenced by slab.h:557 (include/linux/slab.h:557)
> > >>> main.o:(do_initcalls) in archive init/built-in.a
> > >>> referenced by slab.h:448 (include/linux/slab.h:448)
> > >>> do_mounts_rd.o:(rd_load_image) in archive init/built-in.a
> > >>> referenced by slab.h:448 (include/linux/slab.h:448)
> > >>> do_mounts_rd.o:(identify_ramdisk_image) in archive init/built-in.a
> > >>> referenced 1579 more times
> >
> > Implement this for the kernel based on LLVM's
> > handleAlignmentAssumptionImpl because the kernel is not linked against
> > the compiler runtime.
> >
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1245
> > Link: https://github.com/llvm/llvm-project/blob/llvmorg-11.0.1/compiler-rt/lib/ubsan/ubsan_handlers.cpp#L151-L190
> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> > ---
> > lib/ubsan.c | 28 ++++++++++++++++++++++++++++
> > lib/ubsan.h | 6 ++++++
> > 2 files changed, 34 insertions(+)
> >
> > diff --git a/lib/ubsan.c b/lib/ubsan.c
> > index 3e3352f3d0da..a1e6cc9993f8 100644
> > --- a/lib/ubsan.c
> > +++ b/lib/ubsan.c
> > @@ -427,3 +427,31 @@ void __ubsan_handle_load_invalid_value(void *_data, void *val)
> > ubsan_epilogue();
> > }
> > EXPORT_SYMBOL(__ubsan_handle_load_invalid_value);
> > +
> > +void __ubsan_handle_alignment_assumption(void *_data, unsigned long ptr,
> > + unsigned long align,
> > + unsigned long offset)
> > +{
> > + struct alignment_assumption_data *data = _data;
> > + unsigned long real_ptr;
> > +
> > + if (suppress_report(&data->location))
> > + return;
> > +
> > + ubsan_prologue(&data->location, "alignment-assumption");
> > +
> > + if (offset)
> > + pr_err("assumption of %lu byte alignment (with offset of %lu byte) for pointer of type %s failed",
> > + align, offset, data->type->type_name);
> > + else
> > + pr_err("assumption of %lu byte alignment for pointer of type %s failed",
> > + align, data->type->type_name);
> > +
> > + real_ptr = ptr - offset;
> > + pr_err("%saddress is %lu aligned, misalignment offset is %lu bytes",
> > + offset ? "offset " : "", BIT(ffs(real_ptr)),
>
> if real_ptr is an unsigned long, do we want to use `__ffs(real_ptr) +
> 1` here rather than ffs which takes an int? It seems the kernel is
> missing a definition of ffsl. :(
Why the + 1? I think if we use __ffs (which it seems like we should), I
think that needs to become
BIT(real_ptr ? __ffs(real_ptr) : 0)
I have made that change locally and will send it for v2 in a day or so
to give Kees some time to check it out.
Thanks for the review!
Nathan
^ permalink raw reply [relevance 99%]
* Re: upstream build error (12)
@ 2021-01-12 19:40 99% ` Nathan Chancellor
2021-01-12 20:32 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2021-01-12 19:40 UTC (permalink / raw)
To: syzbot; +Cc: linux-kernel, syzkaller-bugs, clang-built-linux
On Tue, Jan 12, 2021 at 11:20:27AM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: e609571b Merge tag 'nfs-for-5.11-2' of git://git.linux-nfs..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15965a00d00000
> kernel config: https://syzkaller.appspot.com/x/.config?x=6157970d0a91b812
> dashboard link: https://syzkaller.appspot.com/bug?extid=76880518931d755473cf
> compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project.git ca2dcbd030eadbf0aa9b660efe864ff08af6e18b)
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+76880518931d755473cf@syzkaller.appspotmail.com
>
> clang-11: error: unable to execute command: Aborted (core dumped)
> clang-11: error: clang frontend command failed due to signal (use -v to see invocation)
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Would it be possible for clang-built-linux@googlegroups.com to be CC'd
when there is a build error and the compiler is clang? Especially if
clang is hitting an assertion.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] mm/mremap: fix BUILD_BUG_ON() error in get_extent
2021-01-04 22:36 99% ` Nathan Chancellor
@ 2021-01-12 19:16 99% ` Nathan Chancellor
1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-12 19:16 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andrew Morton, Nick Desaulniers, Kirill A. Shutemov, Wei Yang,
Arnd Bergmann, Vlastimil Babka, Dmitry Safonov, Brian Geffon,
linux-mm, linux-kernel, clang-built-linux
On Wed, Dec 30, 2020 at 04:40:40PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> clang cannt evaluate this function argument at compile time
> when the function is not inlined, which leads to a link
> time failure:
>
> ld.lld: error: undefined symbol: __compiletime_assert_414
> >>> referenced by mremap.c
> >>> mremap.o:(get_extent) in archive mm/built-in.a
>
> Mark the function as __always_inline to avoid it.
>
> Fixes: 9ad9718bfa41 ("mm/mremap: calculate extent in one place")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
I would like to see some movement on getting this fixed in 5.11. As it
stands, this is one of three __compiletime_assert references with
CONFIG_UBSAN_UNSIGNED_OVERFLOW. If we want to keep the BUILD_BUG()
around, I think this is fine. Alternatively, turning it into a runtime
check would be fine too.
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> mm/mremap.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/mm/mremap.c b/mm/mremap.c
> index c5590afe7165..1cb464a07184 100644
> --- a/mm/mremap.c
> +++ b/mm/mremap.c
> @@ -336,8 +336,9 @@ enum pgt_entry {
> * valid. Else returns a smaller extent bounded by the end of the source and
> * destination pgt_entry.
> */
> -static unsigned long get_extent(enum pgt_entry entry, unsigned long old_addr,
> - unsigned long old_end, unsigned long new_addr)
> +static __always_inline unsigned long get_extent(enum pgt_entry entry,
> + unsigned long old_addr, unsigned long old_end,
> + unsigned long new_addr)
> {
> unsigned long next, extent, mask, size;
>
> --
> 2.29.2
^ permalink raw reply [relevance 99%]
* [PATCH] dmaengine: qcom: Always inline gpi_update_reg
@ 2021-01-12 19:12 98% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-12 19:12 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Vinod Koul
Cc: Dan Williams, Nick Desaulniers, linux-arm-msm, dmaengine,
linux-kernel, clang-built-linux, Nathan Chancellor
When building with CONFIG_UBSAN_UNSIGNED_OVERFLOW, clang decides not to
inline gpi_update_reg, which causes a linkage failure around __bad_mask:
ld.lld: error: undefined symbol: __bad_mask
>>> referenced by bitfield.h:119 (include/linux/bitfield.h:119)
>>> dma/qcom/gpi.o:(gpi_update_reg) in archive drivers/built-in.a
>>> referenced by bitfield.h:119 (include/linux/bitfield.h:119)
>>> dma/qcom/gpi.o:(gpi_update_reg) in archive drivers/built-in.a
If gpi_update_reg is not inlined, the mask value will not be known at
compile time so the check in field_multiplier stays in the final
object file, causing the above linkage failure. Always inline
gpi_update_reg so that this check can never fail.
Fixes: 5d0c3533a19f ("dmaengine: qcom: Add GPI dma driver")
Link: https://github.com/ClangBuiltLinux/linux/issues/1243
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/dma/qcom/gpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/qcom/gpi.c b/drivers/dma/qcom/gpi.c
index 1a0bf6b0567a..e48eb397f433 100644
--- a/drivers/dma/qcom/gpi.c
+++ b/drivers/dma/qcom/gpi.c
@@ -584,7 +584,7 @@ static inline void gpi_write_reg_field(struct gpii *gpii, void __iomem *addr,
gpi_write_reg(gpii, addr, val);
}
-static inline void
+static __always_inline void
gpi_update_reg(struct gpii *gpii, u32 offset, u32 mask, u32 val)
{
void __iomem *addr = gpii->regs + offset;
base-commit: 7c53f6b671f4aba70ff15e1b05148b10d58c2837
--
2.30.0
^ permalink raw reply related [relevance 98%]
* Re: [PATCH] ASoC: imx-hdmi: Fix warning of the uninitialized variable ret
2021-01-12 19:09 99% ` Nathan Chancellor
@ 2021-01-12 19:09 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-12 19:09 UTC (permalink / raw)
To: Mark Brown
Cc: alsa-devel, timur, Xiubo.Lee, linuxppc-dev, Shengjiu Wang, tiwai,
perex, nicoleotsuka, festevam, linux-kernel
On Tue, Jan 12, 2021 at 06:48:48PM +0000, Mark Brown wrote:
> This is a random warning fix, why would you expect it to be sent as a
> bug fix? This is the first indication I've seen that anyone is seeing
> it in mainline, in general the people who report and fix warnings are
> doing so based on -next and the patch seems to be from a month ago. I
> don't have this in my inbox so I assume it's applied already or needs to
> be resubmitted anyway.
Well, I consider compiler warnings bugs. I have had plenty of my
compiler warning patches sent as bug fixes for an -rc. Furthermore, this
patch was sent three times by different people, that should give you some
indication that people are tripping over it.
https://lore.kernel.org/alsa-devel/X9NGQaF4pmK8oUAF@mwanda/
https://lore.kernel.org/alsa-devel/1608115464-18710-1-git-send-email-shengjiu.wang@nxp.com/
https://lore.kernel.org/alsa-devel/20201230154443.656997-1-arnd@kernel.org/
The first version was sent on December 11th, it looks like your pull for
5.11 went on the December 14th, then the second version was applied on
December 16th so I figured it might be destined for 5.11 but I could not
tell (your for-next branch is a merge of your for-5.11 and for-5.12):
https://lore.kernel.org/alsa-devel/160813397775.31838.8934909997692637790.b4-ty@kernel.org/
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] ASoC: imx-hdmi: Fix warning of the uninitialized variable ret
@ 2021-01-12 19:09 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-12 19:09 UTC (permalink / raw)
To: Mark Brown
Cc: alsa-devel, timur, Xiubo.Lee, linuxppc-dev, Shengjiu Wang, tiwai,
nicoleotsuka, festevam, linux-kernel
On Tue, Jan 12, 2021 at 06:48:48PM +0000, Mark Brown wrote:
> This is a random warning fix, why would you expect it to be sent as a
> bug fix? This is the first indication I've seen that anyone is seeing
> it in mainline, in general the people who report and fix warnings are
> doing so based on -next and the patch seems to be from a month ago. I
> don't have this in my inbox so I assume it's applied already or needs to
> be resubmitted anyway.
Well, I consider compiler warnings bugs. I have had plenty of my
compiler warning patches sent as bug fixes for an -rc. Furthermore, this
patch was sent three times by different people, that should give you some
indication that people are tripping over it.
https://lore.kernel.org/alsa-devel/X9NGQaF4pmK8oUAF@mwanda/
https://lore.kernel.org/alsa-devel/1608115464-18710-1-git-send-email-shengjiu.wang@nxp.com/
https://lore.kernel.org/alsa-devel/20201230154443.656997-1-arnd@kernel.org/
The first version was sent on December 11th, it looks like your pull for
5.11 went on the December 14th, then the second version was applied on
December 16th so I figured it might be destined for 5.11 but I could not
tell (your for-next branch is a merge of your for-5.11 and for-5.12):
https://lore.kernel.org/alsa-devel/160813397775.31838.8934909997692637790.b4-ty@kernel.org/
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] ASoC: imx-hdmi: Fix warning of the uninitialized variable ret
@ 2021-01-12 19:09 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-12 19:09 UTC (permalink / raw)
To: Mark Brown
Cc: Shengjiu Wang, timur, nicoleotsuka, Xiubo.Lee, festevam, perex,
tiwai, alsa-devel, linuxppc-dev, linux-kernel
On Tue, Jan 12, 2021 at 06:48:48PM +0000, Mark Brown wrote:
> This is a random warning fix, why would you expect it to be sent as a
> bug fix? This is the first indication I've seen that anyone is seeing
> it in mainline, in general the people who report and fix warnings are
> doing so based on -next and the patch seems to be from a month ago. I
> don't have this in my inbox so I assume it's applied already or needs to
> be resubmitted anyway.
Well, I consider compiler warnings bugs. I have had plenty of my
compiler warning patches sent as bug fixes for an -rc. Furthermore, this
patch was sent three times by different people, that should give you some
indication that people are tripping over it.
https://lore.kernel.org/alsa-devel/X9NGQaF4pmK8oUAF@mwanda/
https://lore.kernel.org/alsa-devel/1608115464-18710-1-git-send-email-shengjiu.wang@nxp.com/
https://lore.kernel.org/alsa-devel/20201230154443.656997-1-arnd@kernel.org/
The first version was sent on December 11th, it looks like your pull for
5.11 went on the December 14th, then the second version was applied on
December 16th so I figured it might be destined for 5.11 but I could not
tell (your for-next branch is a merge of your for-5.11 and for-5.12):
https://lore.kernel.org/alsa-devel/160813397775.31838.8934909997692637790.b4-ty@kernel.org/
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] ASoC: imx-hdmi: Fix warning of the uninitialized variable ret
2021-01-12 18:19 99% ` Nathan Chancellor
@ 2021-01-12 18:19 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-12 18:19 UTC (permalink / raw)
To: Shengjiu Wang
Cc: alsa-devel, timur, Xiubo.Lee, linuxppc-dev, tiwai, perex,
nicoleotsuka, broonie, festevam, linux-kernel
On Wed, Dec 16, 2020 at 06:44:24PM +0800, Shengjiu Wang wrote:
> From: shengjiu wang <shengjiu.wang@nxp.com>
>
> When condition ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in))
> is true, then goto fail, the uninitialized variable ret will be
> returned.
>
> Signed-off-by: shengjiu wang <shengjiu.wang@nxp.com>
> Reported-by: kernel test robot <lkp@intel.com>
> ---
> sound/soc/fsl/imx-hdmi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/sound/soc/fsl/imx-hdmi.c b/sound/soc/fsl/imx-hdmi.c
> index 2c2a76a71940..ede4a9ad1054 100644
> --- a/sound/soc/fsl/imx-hdmi.c
> +++ b/sound/soc/fsl/imx-hdmi.c
> @@ -164,6 +164,7 @@ static int imx_hdmi_probe(struct platform_device *pdev)
>
> if ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in)) {
> dev_err(&pdev->dev, "Invalid HDMI DAI link\n");
> + ret = -EINVAL;
> goto fail;
> }
>
> --
> 2.17.1
>
I still see a warning in v5.11-rc3 that is fixed by this patch, is it
not going in this release cycle? It is a regression fix, seems like it
should.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] ASoC: imx-hdmi: Fix warning of the uninitialized variable ret
@ 2021-01-12 18:19 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-12 18:19 UTC (permalink / raw)
To: Shengjiu Wang
Cc: alsa-devel, timur, Xiubo.Lee, linuxppc-dev, tiwai, nicoleotsuka,
broonie, festevam, linux-kernel
On Wed, Dec 16, 2020 at 06:44:24PM +0800, Shengjiu Wang wrote:
> From: shengjiu wang <shengjiu.wang@nxp.com>
>
> When condition ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in))
> is true, then goto fail, the uninitialized variable ret will be
> returned.
>
> Signed-off-by: shengjiu wang <shengjiu.wang@nxp.com>
> Reported-by: kernel test robot <lkp@intel.com>
> ---
> sound/soc/fsl/imx-hdmi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/sound/soc/fsl/imx-hdmi.c b/sound/soc/fsl/imx-hdmi.c
> index 2c2a76a71940..ede4a9ad1054 100644
> --- a/sound/soc/fsl/imx-hdmi.c
> +++ b/sound/soc/fsl/imx-hdmi.c
> @@ -164,6 +164,7 @@ static int imx_hdmi_probe(struct platform_device *pdev)
>
> if ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in)) {
> dev_err(&pdev->dev, "Invalid HDMI DAI link\n");
> + ret = -EINVAL;
> goto fail;
> }
>
> --
> 2.17.1
>
I still see a warning in v5.11-rc3 that is fixed by this patch, is it
not going in this release cycle? It is a regression fix, seems like it
should.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] ASoC: imx-hdmi: Fix warning of the uninitialized variable ret
@ 2021-01-12 18:19 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-12 18:19 UTC (permalink / raw)
To: Shengjiu Wang
Cc: timur, nicoleotsuka, Xiubo.Lee, festevam, broonie, perex, tiwai,
alsa-devel, linuxppc-dev, linux-kernel
On Wed, Dec 16, 2020 at 06:44:24PM +0800, Shengjiu Wang wrote:
> From: shengjiu wang <shengjiu.wang@nxp.com>
>
> When condition ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in))
> is true, then goto fail, the uninitialized variable ret will be
> returned.
>
> Signed-off-by: shengjiu wang <shengjiu.wang@nxp.com>
> Reported-by: kernel test robot <lkp@intel.com>
> ---
> sound/soc/fsl/imx-hdmi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/sound/soc/fsl/imx-hdmi.c b/sound/soc/fsl/imx-hdmi.c
> index 2c2a76a71940..ede4a9ad1054 100644
> --- a/sound/soc/fsl/imx-hdmi.c
> +++ b/sound/soc/fsl/imx-hdmi.c
> @@ -164,6 +164,7 @@ static int imx_hdmi_probe(struct platform_device *pdev)
>
> if ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in)) {
> dev_err(&pdev->dev, "Invalid HDMI DAI link\n");
> + ret = -EINVAL;
> goto fail;
> }
>
> --
> 2.17.1
>
I still see a warning in v5.11-rc3 that is fixed by this patch, is it
not going in this release cycle? It is a regression fix, seems like it
should.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH v3] pgo: add clang's Profile Guided Optimization infrastructure
@ 2021-01-12 17:22 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-12 17:22 UTC (permalink / raw)
To: kernel test robot
Cc: Bill Wendling, Jonathan Corbet, Masahiro Yamada, linux-doc,
linux-kernel, linux-kbuild, clang-built-linux, Andrew Morton,
kbuild-all, Linux Memory Management List, Nick Desaulniers
On Tue, Jan 12, 2021 at 05:10:04PM +0800, kernel test robot wrote:
> Hi Bill,
>
> I love your patch! Perhaps something to improve:
>
> [auto build test WARNING on linus/master]
> [also build test WARNING on v5.11-rc3]
> [cannot apply to powerpc/next s390/features tip/x86/core next-20210111]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
>
> url: https://github.com/0day-ci/linux/commits/Bill-Wendling/pgo-add-clang-s-Profile-Guided-Optimization-infrastructure/20210112-133315
> base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git a0d54b4f5b219fb31f0776e9f53aa137e78ae431
> config: x86_64-allyesconfig (attached as .config)
> compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
Hmmm... This should probably be gated on CC_IS_CLANG? Or even better
CLANG_VERSION >= 120000 due to
https://github.com/ClangBuiltLinux/linux/issues/1252?
> reproduce (this is a W=1 build):
> # https://github.com/0day-ci/linux/commit/6ab85bae7667afd0aa68c6442b7ca5c369fa1088
> git remote add linux-review https://github.com/0day-ci/linux
> git fetch --no-tags linux-review Bill-Wendling/pgo-add-clang-s-Profile-Guided-Optimization-infrastructure/20210112-133315
> git checkout 6ab85bae7667afd0aa68c6442b7ca5c369fa1088
> # save the attached .config to linux build tree
> make W=1 ARCH=x86_64
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
>
> All warnings (new ones prefixed by >>):
>
> kernel/pgo/instrument.c:72:6: warning: no previous prototype for '__llvm_profile_instrument_target' [-Wmissing-prototypes]
> 72 | void __llvm_profile_instrument_target(u64 target_value, void *data, u32 index)
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> kernel/pgo/instrument.c:135:6: warning: no previous prototype for '__llvm_profile_instrument_range' [-Wmissing-prototypes]
> 135 | void __llvm_profile_instrument_range(u64 target_value, void *data,
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> kernel/pgo/instrument.c:179:6: warning: no previous prototype for '__llvm_profile_instrument_memop' [-Wmissing-prototypes]
> 179 | void __llvm_profile_instrument_memop(u64 target_value, void *data,
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
I still think that this warning will show up with clang at W=1. Given
that these are compiler inserted functions, the prototypes don't matter
but we could shut it up by just putting the prototypes right above the
functions like was done in commit 1e1b6d63d634 ("lib/string.c: implement
stpcpy").
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] ARM: fix link warning with XIP + frame-pointer
@ 2021-01-12 16:27 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-12 16:27 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Vladimir Murzin, Kees Cook, Arnd Bergmann, Catalin Marinas,
Nick Desaulniers, Russell King, linux-kernel, clang-built-linux,
linux-arm-kernel
On Tue, Jan 12, 2021 at 04:46:40PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> When frame pointers are used instead of the ARM unwinder,
> and the kernel is built using clang with an external assembler
> and CONFIG_XIP_KERNEL, every file produces two warnings
> like:
>
> arm-linux-gnueabi-ld: warning: orphan section `.ARM.extab' from `net/mac802154/util.o' being placed in section `.ARM.extab'
> arm-linux-gnueabi-ld: warning: orphan section `.ARM.exidx' from `net/mac802154/util.o' being placed in section `.ARM.exidx'
>
> The same fix was already merged for the normal (non-XIP)
> linker script, with a longer description.
>
> Fixes: c39866f268f8 ("arm/build: Always handle .ARM.exidx and .ARM.extab sections")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> arch/arm/kernel/vmlinux-xip.lds.S | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/kernel/vmlinux-xip.lds.S b/arch/arm/kernel/vmlinux-xip.lds.S
> index 4d0b0cd9222e..ddb70c65d525 100644
> --- a/arch/arm/kernel/vmlinux-xip.lds.S
> +++ b/arch/arm/kernel/vmlinux-xip.lds.S
> @@ -43,6 +43,10 @@ SECTIONS
> ARM_DISCARD
> *(.alt.smp.init)
> *(.pv_table)
> +#ifndef CONFIG_ARM_UNWIND
> + *(.ARM.exidx) *(.ARM.exidx.*)
> + *(.ARM.extab) *(.ARM.extab.*)
> +#endif
> }
>
> . = XIP_VIRT_ADDR(CONFIG_XIP_PHYS_ADDR);
> --
> 2.29.2
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [relevance 99%]
* Re: [PATCH] ARM: fix link warning with XIP + frame-pointer
@ 2021-01-12 16:27 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-12 16:27 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Russell King, Nick Desaulniers, Kees Cook, Arnd Bergmann,
Catalin Marinas, Vladimir Murzin, linux-arm-kernel, linux-kernel,
clang-built-linux
On Tue, Jan 12, 2021 at 04:46:40PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> When frame pointers are used instead of the ARM unwinder,
> and the kernel is built using clang with an external assembler
> and CONFIG_XIP_KERNEL, every file produces two warnings
> like:
>
> arm-linux-gnueabi-ld: warning: orphan section `.ARM.extab' from `net/mac802154/util.o' being placed in section `.ARM.extab'
> arm-linux-gnueabi-ld: warning: orphan section `.ARM.exidx' from `net/mac802154/util.o' being placed in section `.ARM.exidx'
>
> The same fix was already merged for the normal (non-XIP)
> linker script, with a longer description.
>
> Fixes: c39866f268f8 ("arm/build: Always handle .ARM.exidx and .ARM.extab sections")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> arch/arm/kernel/vmlinux-xip.lds.S | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/kernel/vmlinux-xip.lds.S b/arch/arm/kernel/vmlinux-xip.lds.S
> index 4d0b0cd9222e..ddb70c65d525 100644
> --- a/arch/arm/kernel/vmlinux-xip.lds.S
> +++ b/arch/arm/kernel/vmlinux-xip.lds.S
> @@ -43,6 +43,10 @@ SECTIONS
> ARM_DISCARD
> *(.alt.smp.init)
> *(.pv_table)
> +#ifndef CONFIG_ARM_UNWIND
> + *(.ARM.exidx) *(.ARM.exidx.*)
> + *(.ARM.extab) *(.ARM.extab.*)
> +#endif
> }
>
> . = XIP_VIRT_ADDR(CONFIG_XIP_PHYS_ADDR);
> --
> 2.29.2
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] USB: serial: mos7720: improve handling of a kmalloc failure in read_mos_reg()
@ 2021-01-11 22:31 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-11 22:31 UTC (permalink / raw)
To: trix
Cc: johan, gregkh, ndesaulniers, linux-usb, linux-kernel, clang-built-linux
On Mon, Jan 11, 2021 at 02:09:04PM -0800, trix@redhat.com wrote:
> From: Tom Rix <trix@redhat.com>
>
> clang static analysis reports this problem
>
> mos7720.c:352:2: warning: Undefined or garbage value returned to caller
> return d;
> ^~~~~~~~
>
> In the parport_mos7715_read_data()'s call to read_mos_reg(), 'd' is
> only set after the alloc block.
>
> buf = kmalloc(1, GFP_KERNEL);
> if (!buf)
> return -ENOMEM;
>
> Although the problem is reported in parport_most7715_read_data(),
> none of the callee's of read_mos_reg() check the return status.
>
> So move the clearing of data to before the malloc.
>
> Fixes: 0d130367abf5 ("USB: serial: mos7720: fix control-message error handling")
> Signed-off-by: Tom Rix <trix@redhat.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> drivers/usb/serial/mos7720.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/serial/mos7720.c b/drivers/usb/serial/mos7720.c
> index 41ee2984a0df..23e8162c768b 100644
> --- a/drivers/usb/serial/mos7720.c
> +++ b/drivers/usb/serial/mos7720.c
> @@ -214,6 +214,7 @@ static int read_mos_reg(struct usb_serial *serial, unsigned int serial_portnum,
> u8 *buf;
> int status;
>
> + *data = 0;
> buf = kmalloc(1, GFP_KERNEL);
> if (!buf)
> return -ENOMEM;
> @@ -227,7 +228,6 @@ static int read_mos_reg(struct usb_serial *serial, unsigned int serial_portnum,
> "mos7720: usb_control_msg() failed: %d\n", status);
> if (status >= 0)
> status = -EIO;
> - *data = 0;
> }
>
> kfree(buf);
> --
> 2.27.0
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] pgo: add clang's Profile Guided Optimization infrastructure
@ 2021-01-11 21:04 96% ` Nathan Chancellor
1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-11 21:04 UTC (permalink / raw)
To: Bill Wendling
Cc: Jonathan Corbet, Masahiro Yamada, linux-doc, linux-kernel,
linux-kbuild, clang-built-linux, Andrew Morton, Nick Desaulniers,
Sami Tolvanen
On Mon, Jan 11, 2021 at 12:18:21AM -0800, Bill Wendling wrote:
> From: Sami Tolvanen <samitolvanen@google.com>
>
> Enable the use of clang's Profile-Guided Optimization[1]. To generate a
> profile, the kernel is instrumented with PGO counters, a representative
> workload is run, and the raw profile data is collected from
> /sys/kernel/debug/pgo/profraw.
>
> The raw profile data must be processed by clang's "llvm-profdata" tool before
> it can be used during recompilation:
>
> $ cp /sys/kernel/debug/pgo/profraw vmlinux.profraw
> $ llvm-profdata merge --output=vmlinux.profdata vmlinux.profraw
>
> Multiple raw profiles may be merged during this step.
>
> The data can be used either by the compiler if LTO isn't enabled:
>
> ... -fprofile-use=vmlinux.profdata ...
>
> or by LLD if LTO is enabled:
>
> ... -lto-cs-profile-file=vmlinux.profdata ...
>
> This initial submission is restricted to x86, as that's the platform we know
> works. This restriction can be lifted once other platforms have been verified
> to work with PGO.
>
> Note that this method of profiling the kernel is clang-native and isn't
> compatible with clang's gcov support in kernel/gcov.
>
> [1] https://clang.llvm.org/docs/UsersManual.html#profile-guided-optimization
>
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> Co-developed-by: Bill Wendling <morbo@google.com>
> Signed-off-by: Bill Wendling <morbo@google.com>
I took this for a spin against x86_64_defconfig and ran into two issues:
1. https://github.com/ClangBuiltLinux/linux/issues/1252
There is also one in drivers/gpu/drm/i915/i915_query.c. For the time
being, I added PGO_PROFILE_... := n for those two files.
2. After doing that, I run into an undefined function error with ld.lld.
How I tested:
$ make -skj"$(nproc)" LLVM=1 defconfig
$ scripts/config -e PGO_CLANG
$ make -skj"$(nproc)" LLVM=1 olddefconfig vmlinux all
ld.lld: error: undefined symbol: __llvm_profile_instrument_memop
>>> referenced by head64.c
>>> arch/x86/kernel/head64.o:(__early_make_pgtable)
>>> referenced by head64.c
>>> arch/x86/kernel/head64.o:(x86_64_start_kernel)
>>> referenced by head64.c
>>> arch/x86/kernel/head64.o:(copy_bootdata)
>>> referenced 2259 more times
Local diff:
diff --git a/drivers/char/Makefile b/drivers/char/Makefile
index ffce287ef415..4b2f238770b5 100644
--- a/drivers/char/Makefile
+++ b/drivers/char/Makefile
@@ -4,6 +4,7 @@
#
obj-y += mem.o random.o
+PGO_PROFILE_random.o := n
obj-$(CONFIG_TTY_PRINTK) += ttyprintk.o
obj-y += misc.o
obj-$(CONFIG_ATARI_DSP56K) += dsp56k.o
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index e5574e506a5c..d83cacc79b1a 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -168,6 +168,7 @@ i915-y += \
i915_vma.o \
intel_region_lmem.o \
intel_wopcm.o
+PGO_PROFILE_i915_query.o := n
# general-purpose microcontroller (GuC) support
i915-y += gt/uc/intel_uc.o \
^ permalink raw reply related [relevance 96%]
* Re: [PATCH] bpf: Hoise pahole version checks into Kconfig
@ 2021-01-11 20:00 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2021-01-11 20:00 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Michal Marek, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Linux Kernel Mailing List,
Linux Kbuild mailing list, Networking, bpf, Sedat Dilek
On Tue, Jan 12, 2021 at 04:50:50AM +0900, Masahiro Yamada wrote:
> On Tue, Jan 12, 2021 at 4:34 AM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> >
> > On Tue, Jan 12, 2021 at 04:19:01AM +0900, Masahiro Yamada wrote:
> > > On Tue, Jan 12, 2021 at 3:06 AM Nathan Chancellor
> > > <natechancellor@gmail.com> wrote:
> > > >
> > > > After commit da5fb18225b4 ("bpf: Support pre-2.25-binutils objcopy for
> > > > vmlinux BTF"), having CONFIG_DEBUG_INFO_BTF enabled but lacking a valid
> > > > copy of pahole results in a kernel that will fully compile but fail to
> > > > link. The user then has to either install pahole or disable
> > > > CONFIG_DEBUG_INFO_BTF and rebuild the kernel but only after their build
> > > > has failed, which could have been a significant amount of time depending
> > > > on the hardware.
> > > >
> > > > Avoid a poor user experience and require pahole to be installed with an
> > > > appropriate version to select and use CONFIG_DEBUG_INFO_BTF, which is
> > > > standard for options that require a specific tools version.
> > > >
> > > > Suggested-by: Sedat Dilek <sedat.dilek@gmail.com>
> > > > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> > >
> > >
> > >
> > > I am not sure if this is the right direction.
> > >
> > >
> > > I used to believe moving any tool test to the Kconfig
> > > was the right thing to do.
> > >
> > > For example, I tried to move the libelf test to Kconfig,
> > > and make STACK_VALIDATION depend on it.
> > >
> > > https://patchwork.kernel.org/project/linux-kbuild/patch/1531186516-15764-1-git-send-email-yamada.masahiro@socionext.com/
> > >
> > > It was rejected.
> > >
> > >
> > > In my understanding, it is good to test target toolchains
> > > in Kconfig (e.g. cc-option, ld-option, etc).
> > >
> > > As for host tools, in contrast, it is better to _intentionally_
> > > break the build in order to let users know that something needed is missing.
> > > Then, they will install necessary tools or libraries.
> > > It is just a one-time setup, in most cases,
> > > just running 'apt install' or 'dnf install'.
> > >
> > >
> > >
> > > Recently, a similar thing happened to GCC_PLUGINS
> > > https://patchwork.kernel.org/project/linux-kbuild/patch/20201203125700.161354-1-masahiroy@kernel.org/#23855673
> > >
> > >
> > >
> > >
> > > Following this pattern, if a new pahole is not installed,
> > > it might be better to break the build instead of hiding
> > > the CONFIG option.
> > >
> > > In my case, it is just a matter of 'apt install pahole'.
> > > On some distributions, the bundled pahole is not new enough,
> > > and people may end up with building pahole from the source code.
> >
> > This is fair enough. However, I think that parts of this patch could
> > still be salvaged into something that fits this by making it so that if
> > pahole is not installed (CONFIG_PAHOLE_VERSION=0) or too old, the build
> > errors at the beginning, rather at the end. I am not sure where the best
> > place to put that check would be though.
>
> Me neither.
>
>
> Collecting tool checks to the beginning would be user-friendly.
> However, scattering the related code to multiple places is not
> nice from the developer point of view.
>
> How big is it a problem if the build fails
> at the very last stage?
>
> You can install pahole, then resume "make".
>
> Kbuild skips unneeded building, then you will
> be able to come back to the last build stage shortly.
There will often be times where I am testing multiple configurations in
a row serially and the longer that a build takes to fail, the longer it
takes for me to get a "real" result. That is my motivation behind this
change. If people are happy with the current state of things, I will
just stick with universally disabling CONFIG_DEBUG_INFO_BTF in my test
framework.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] bpf: Hoise pahole version checks into Kconfig
@ 2021-01-11 19:34 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2021-01-11 19:34 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Michal Marek, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Linux Kernel Mailing List,
Linux Kbuild mailing list, Networking, bpf, Sedat Dilek
On Tue, Jan 12, 2021 at 04:19:01AM +0900, Masahiro Yamada wrote:
> On Tue, Jan 12, 2021 at 3:06 AM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> >
> > After commit da5fb18225b4 ("bpf: Support pre-2.25-binutils objcopy for
> > vmlinux BTF"), having CONFIG_DEBUG_INFO_BTF enabled but lacking a valid
> > copy of pahole results in a kernel that will fully compile but fail to
> > link. The user then has to either install pahole or disable
> > CONFIG_DEBUG_INFO_BTF and rebuild the kernel but only after their build
> > has failed, which could have been a significant amount of time depending
> > on the hardware.
> >
> > Avoid a poor user experience and require pahole to be installed with an
> > appropriate version to select and use CONFIG_DEBUG_INFO_BTF, which is
> > standard for options that require a specific tools version.
> >
> > Suggested-by: Sedat Dilek <sedat.dilek@gmail.com>
> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
>
>
>
> I am not sure if this is the right direction.
>
>
> I used to believe moving any tool test to the Kconfig
> was the right thing to do.
>
> For example, I tried to move the libelf test to Kconfig,
> and make STACK_VALIDATION depend on it.
>
> https://patchwork.kernel.org/project/linux-kbuild/patch/1531186516-15764-1-git-send-email-yamada.masahiro@socionext.com/
>
> It was rejected.
>
>
> In my understanding, it is good to test target toolchains
> in Kconfig (e.g. cc-option, ld-option, etc).
>
> As for host tools, in contrast, it is better to _intentionally_
> break the build in order to let users know that something needed is missing.
> Then, they will install necessary tools or libraries.
> It is just a one-time setup, in most cases,
> just running 'apt install' or 'dnf install'.
>
>
>
> Recently, a similar thing happened to GCC_PLUGINS
> https://patchwork.kernel.org/project/linux-kbuild/patch/20201203125700.161354-1-masahiroy@kernel.org/#23855673
>
>
>
>
> Following this pattern, if a new pahole is not installed,
> it might be better to break the build instead of hiding
> the CONFIG option.
>
> In my case, it is just a matter of 'apt install pahole'.
> On some distributions, the bundled pahole is not new enough,
> and people may end up with building pahole from the source code.
This is fair enough. However, I think that parts of this patch could
still be salvaged into something that fits this by making it so that if
pahole is not installed (CONFIG_PAHOLE_VERSION=0) or too old, the build
errors at the beginning, rather at the end. I am not sure where the best
place to put that check would be though.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH v3] kasan: remove redundant config option
2021-01-11 19:11 99% ` Nathan Chancellor
(?)
@ 2021-01-11 19:11 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-11 19:11 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Walter Wu, wsd_upstream, moderated list:ARM/Mediatek SoC...,
LKML, kasan-dev, Linux Memory Management List,
Alexander Potapenko, Linux ARM, Andrey Ryabinin, Andrew Morton,
Dmitry Vyukov
On Mon, Jan 11, 2021 at 08:03:29PM +0100, Andrey Konovalov wrote:
> On Mon, Jan 11, 2021 at 7:59 PM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> >
> > > > -config KASAN_STACK_ENABLE
> > > > +config KASAN_STACK
> > > > bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
> > >
> > > Does this syntax mean that KASAN_STACK is only present for
> > > CC_IS_CLANG? Or that it can only be disabled for CC_IS_CLANG?
> >
> > It means that the option can only be disabled for clang.
>
> OK, got it.
>
> > > Anyway, I think it's better to 1. allow to control KASAN_STACK
> > > regardless of the compiler (as it was possible before), and 2. avoid
> >
> > It has never been possible to control KASAN_STACK for GCC because of the
> > bool ... if ... syntax. This patch does not change that logic. Making it
> > possible to control KASAN_STACK with GCC seems fine but that is going to
> > be a new change that would probably be suited for a new patch on top of
> > this one.
>
> The if syntax was never applied to KASAN_STACK, only to
> KASAN_STACK_ENABLE, so it should have been possible (although I've
> never specifically tried it).
CONFIG_KASAN_STACK was not a user selectable symbol so it was always 1
for GCC.
Cheers,
Nathan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [relevance 99%]
* Re: [PATCH v3] kasan: remove redundant config option
@ 2021-01-11 19:11 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-11 19:11 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Walter Wu, Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov,
Andrew Morton, kasan-dev, Linux Memory Management List, LKML,
Linux ARM, wsd_upstream, moderated list:ARM/Mediatek SoC...
On Mon, Jan 11, 2021 at 08:03:29PM +0100, Andrey Konovalov wrote:
> On Mon, Jan 11, 2021 at 7:59 PM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> >
> > > > -config KASAN_STACK_ENABLE
> > > > +config KASAN_STACK
> > > > bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
> > >
> > > Does this syntax mean that KASAN_STACK is only present for
> > > CC_IS_CLANG? Or that it can only be disabled for CC_IS_CLANG?
> >
> > It means that the option can only be disabled for clang.
>
> OK, got it.
>
> > > Anyway, I think it's better to 1. allow to control KASAN_STACK
> > > regardless of the compiler (as it was possible before), and 2. avoid
> >
> > It has never been possible to control KASAN_STACK for GCC because of the
> > bool ... if ... syntax. This patch does not change that logic. Making it
> > possible to control KASAN_STACK with GCC seems fine but that is going to
> > be a new change that would probably be suited for a new patch on top of
> > this one.
>
> The if syntax was never applied to KASAN_STACK, only to
> KASAN_STACK_ENABLE, so it should have been possible (although I've
> never specifically tried it).
CONFIG_KASAN_STACK was not a user selectable symbol so it was always 1
for GCC.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH v3] kasan: remove redundant config option
@ 2021-01-11 19:11 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-11 19:11 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Walter Wu, wsd_upstream, moderated list:ARM/Mediatek SoC...,
LKML, kasan-dev, Linux Memory Management List,
Alexander Potapenko, Linux ARM, Andrey Ryabinin, Andrew Morton,
Dmitry Vyukov
On Mon, Jan 11, 2021 at 08:03:29PM +0100, Andrey Konovalov wrote:
> On Mon, Jan 11, 2021 at 7:59 PM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> >
> > > > -config KASAN_STACK_ENABLE
> > > > +config KASAN_STACK
> > > > bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
> > >
> > > Does this syntax mean that KASAN_STACK is only present for
> > > CC_IS_CLANG? Or that it can only be disabled for CC_IS_CLANG?
> >
> > It means that the option can only be disabled for clang.
>
> OK, got it.
>
> > > Anyway, I think it's better to 1. allow to control KASAN_STACK
> > > regardless of the compiler (as it was possible before), and 2. avoid
> >
> > It has never been possible to control KASAN_STACK for GCC because of the
> > bool ... if ... syntax. This patch does not change that logic. Making it
> > possible to control KASAN_STACK with GCC seems fine but that is going to
> > be a new change that would probably be suited for a new patch on top of
> > this one.
>
> The if syntax was never applied to KASAN_STACK, only to
> KASAN_STACK_ENABLE, so it should have been possible (although I've
> never specifically tried it).
CONFIG_KASAN_STACK was not a user selectable symbol so it was always 1
for GCC.
Cheers,
Nathan
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [relevance 99%]
* Re: [PATCH v3] kasan: remove redundant config option
@ 2021-01-11 19:11 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-11 19:11 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Walter Wu, Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov,
Andrew Morton, kasan-dev, Linux Memory Management List, LKML,
Linux ARM, wsd_upstream, moderated list:ARM/Mediatek SoC...
On Mon, Jan 11, 2021 at 08:03:29PM +0100, Andrey Konovalov wrote:
> On Mon, Jan 11, 2021 at 7:59 PM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> >
> > > > -config KASAN_STACK_ENABLE
> > > > +config KASAN_STACK
> > > > bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
> > >
> > > Does this syntax mean that KASAN_STACK is only present for
> > > CC_IS_CLANG? Or that it can only be disabled for CC_IS_CLANG?
> >
> > It means that the option can only be disabled for clang.
>
> OK, got it.
>
> > > Anyway, I think it's better to 1. allow to control KASAN_STACK
> > > regardless of the compiler (as it was possible before), and 2. avoid
> >
> > It has never been possible to control KASAN_STACK for GCC because of the
> > bool ... if ... syntax. This patch does not change that logic. Making it
> > possible to control KASAN_STACK with GCC seems fine but that is going to
> > be a new change that would probably be suited for a new patch on top of
> > this one.
>
> The if syntax was never applied to KASAN_STACK, only to
> KASAN_STACK_ENABLE, so it should have been possible (although I've
> never specifically tried it).
CONFIG_KASAN_STACK was not a user selectable symbol so it was always 1
for GCC.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH v3] kasan: remove redundant config option
2021-01-11 18:59 99% ` Nathan Chancellor
(?)
@ 2021-01-11 18:59 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-11 18:59 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Walter Wu, wsd_upstream, moderated list:ARM/Mediatek SoC...,
LKML, kasan-dev, Linux Memory Management List,
Alexander Potapenko, Linux ARM, Andrey Ryabinin, Andrew Morton,
Dmitry Vyukov
On Mon, Jan 11, 2021 at 06:49:37PM +0100, Andrey Konovalov wrote:
> On Fri, Jan 8, 2021 at 5:09 AM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> >
> > CONFIG_KASAN_STACK and CONFIG_KASAN_STACK_ENABLE both enable KASAN stack
> > instrumentation, but we should only need one config, so that we remove
> > CONFIG_KASAN_STACK_ENABLE and make CONFIG_KASAN_STACK workable. see [1].
> >
> > When enable KASAN stack instrumentation, then for gcc we could do
> > no prompt and default value y, and for clang prompt and default
> > value n.
> >
> > [1]: https://bugzilla.kernel.org/show_bug.cgi?id=210221
> >
> > Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> > Suggested-by: Dmitry Vyukov <dvyukov@google.com>
> > Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> > Cc: Dmitry Vyukov <dvyukov@google.com>
> > Cc: Andrey Konovalov <andreyknvl@google.com>
> > Cc: Alexander Potapenko <glider@google.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Nathan Chancellor <natechancellor@gmail.com>
> > ---
> >
> > v2: make commit log to be more readable.
> > v3: remain CONFIG_KASAN_STACK_ENABLE setting
> > fix the pre-processors syntax
> >
> > ---
> > arch/arm64/kernel/sleep.S | 2 +-
> > arch/x86/kernel/acpi/wakeup_64.S | 2 +-
> > include/linux/kasan.h | 2 +-
> > lib/Kconfig.kasan | 8 ++------
> > mm/kasan/common.c | 2 +-
> > mm/kasan/kasan.h | 2 +-
> > mm/kasan/report_generic.c | 2 +-
> > scripts/Makefile.kasan | 10 ++++++++--
> > 8 files changed, 16 insertions(+), 14 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S
> > index 6bdef7362c0e..7c44ede122a9 100644
> > --- a/arch/arm64/kernel/sleep.S
> > +++ b/arch/arm64/kernel/sleep.S
> > @@ -133,7 +133,7 @@ SYM_FUNC_START(_cpu_resume)
> > */
> > bl cpu_do_resume
> >
> > -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> > +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> > mov x0, sp
> > bl kasan_unpoison_task_stack_below
> > #endif
> > diff --git a/arch/x86/kernel/acpi/wakeup_64.S b/arch/x86/kernel/acpi/wakeup_64.S
> > index 5d3a0b8fd379..c7f412f4e07d 100644
> > --- a/arch/x86/kernel/acpi/wakeup_64.S
> > +++ b/arch/x86/kernel/acpi/wakeup_64.S
> > @@ -112,7 +112,7 @@ SYM_FUNC_START(do_suspend_lowlevel)
> > movq pt_regs_r14(%rax), %r14
> > movq pt_regs_r15(%rax), %r15
> >
> > -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> > +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> > /*
> > * The suspend path may have poisoned some areas deeper in the stack,
> > * which we now need to unpoison.
> > diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> > index 5e0655fb2a6f..35d1e9b2cbfa 100644
> > --- a/include/linux/kasan.h
> > +++ b/include/linux/kasan.h
> > @@ -302,7 +302,7 @@ static inline void kasan_kfree_large(void *ptr, unsigned long ip) {}
> >
> > #endif /* CONFIG_KASAN */
> >
> > -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> > +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> > void kasan_unpoison_task_stack(struct task_struct *task);
> > #else
> > static inline void kasan_unpoison_task_stack(struct task_struct *task) {}
> > diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
> > index f5fa4ba126bf..fde82ec85f8f 100644
> > --- a/lib/Kconfig.kasan
> > +++ b/lib/Kconfig.kasan
> > @@ -138,9 +138,10 @@ config KASAN_INLINE
> >
> > endchoice
> >
> > -config KASAN_STACK_ENABLE
> > +config KASAN_STACK
> > bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
>
> Does this syntax mean that KASAN_STACK is only present for
> CC_IS_CLANG? Or that it can only be disabled for CC_IS_CLANG?
It means that the option can only be disabled for clang.
> Anyway, I think it's better to 1. allow to control KASAN_STACK
> regardless of the compiler (as it was possible before), and 2. avoid
It has never been possible to control KASAN_STACK for GCC because of the
bool ... if ... syntax. This patch does not change that logic. Making it
possible to control KASAN_STACK with GCC seems fine but that is going to
be a new change that would probably be suited for a new patch on top of
this one.
> this "bool ... if ..." syntax as it's confusing.
>
> > depends on KASAN_GENERIC || KASAN_SW_TAGS
> > + default y if CC_IS_GCC
> > help
> > The LLVM stack address sanitizer has a know problem that
> > causes excessive stack usage in a lot of functions, see
> > @@ -154,11 +155,6 @@ config KASAN_STACK_ENABLE
> > CONFIG_COMPILE_TEST. On gcc it is assumed to always be safe
> > to use and enabled by default.
> >
> > -config KASAN_STACK
> > - int
> > - default 1 if KASAN_STACK_ENABLE || CC_IS_GCC
> > - default 0
> > -
> > config KASAN_SW_TAGS_IDENTIFY
> > bool "Enable memory corruption identification"
> > depends on KASAN_SW_TAGS
> > diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> > index 38ba2aecd8f4..bf8b073eed62 100644
> > --- a/mm/kasan/common.c
> > +++ b/mm/kasan/common.c
> > @@ -63,7 +63,7 @@ void __kasan_unpoison_range(const void *address, size_t size)
> > unpoison_range(address, size);
> > }
> >
> > -#if CONFIG_KASAN_STACK
> > +#ifdef CONFIG_KASAN_STACK
> > /* Unpoison the entire stack for a task. */
> > void kasan_unpoison_task_stack(struct task_struct *task)
> > {
> > diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> > index cc4d9e1d49b1..bdfdb1cff653 100644
> > --- a/mm/kasan/kasan.h
> > +++ b/mm/kasan/kasan.h
> > @@ -224,7 +224,7 @@ void *find_first_bad_addr(void *addr, size_t size);
> > const char *get_bug_type(struct kasan_access_info *info);
> > void metadata_fetch_row(char *buffer, void *row);
> >
> > -#if defined(CONFIG_KASAN_GENERIC) && CONFIG_KASAN_STACK
> > +#if defined(CONFIG_KASAN_GENERIC) && defined(CONFIG_KASAN_STACK)
> > void print_address_stack_frame(const void *addr);
> > #else
> > static inline void print_address_stack_frame(const void *addr) { }
> > diff --git a/mm/kasan/report_generic.c b/mm/kasan/report_generic.c
> > index 8a9c889872da..4e16518d9877 100644
> > --- a/mm/kasan/report_generic.c
> > +++ b/mm/kasan/report_generic.c
> > @@ -128,7 +128,7 @@ void metadata_fetch_row(char *buffer, void *row)
> > memcpy(buffer, kasan_mem_to_shadow(row), META_BYTES_PER_ROW);
> > }
> >
> > -#if CONFIG_KASAN_STACK
> > +#ifdef CONFIG_KASAN_STACK
> > static bool __must_check tokenize_frame_descr(const char **frame_descr,
> > char *token, size_t max_tok_len,
> > unsigned long *value)
> > diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan
> > index 1e000cc2e7b4..abf231d209b1 100644
> > --- a/scripts/Makefile.kasan
> > +++ b/scripts/Makefile.kasan
> > @@ -2,6 +2,12 @@
> > CFLAGS_KASAN_NOSANITIZE := -fno-builtin
> > KASAN_SHADOW_OFFSET ?= $(CONFIG_KASAN_SHADOW_OFFSET)
> >
> > +ifdef CONFIG_KASAN_STACK
> > + stack_enable := 1
> > +else
> > + stack_enable := 0
> > +endif
> > +
> > ifdef CONFIG_KASAN_GENERIC
> >
> > ifdef CONFIG_KASAN_INLINE
> > @@ -27,7 +33,7 @@ else
> > CFLAGS_KASAN := $(CFLAGS_KASAN_SHADOW) \
> > $(call cc-param,asan-globals=1) \
> > $(call cc-param,asan-instrumentation-with-call-threshold=$(call_threshold)) \
> > - $(call cc-param,asan-stack=$(CONFIG_KASAN_STACK)) \
> > + $(call cc-param,asan-stack=$(stack_enable)) \
> > $(call cc-param,asan-instrument-allocas=1)
> > endif
> >
> > @@ -42,7 +48,7 @@ else
> > endif
> >
> > CFLAGS_KASAN := -fsanitize=kernel-hwaddress \
> > - -mllvm -hwasan-instrument-stack=$(CONFIG_KASAN_STACK) \
> > + -mllvm -hwasan-instrument-stack=$(stack_enable) \
> > -mllvm -hwasan-use-short-granules=0 \
> > $(instrumentation_flags)
> >
> > --
> > 2.18.0
> >
> > --
> > You received this message because you are subscribed to the Google Groups "kasan-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com.
> > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20210108040940.1138-1-walter-zh.wu%40mediatek.com.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [relevance 99%]
* Re: [PATCH v3] kasan: remove redundant config option
@ 2021-01-11 18:59 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-11 18:59 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Walter Wu, Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov,
Andrew Morton, kasan-dev, Linux Memory Management List, LKML,
Linux ARM, wsd_upstream, moderated list:ARM/Mediatek SoC...
On Mon, Jan 11, 2021 at 06:49:37PM +0100, Andrey Konovalov wrote:
> On Fri, Jan 8, 2021 at 5:09 AM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> >
> > CONFIG_KASAN_STACK and CONFIG_KASAN_STACK_ENABLE both enable KASAN stack
> > instrumentation, but we should only need one config, so that we remove
> > CONFIG_KASAN_STACK_ENABLE and make CONFIG_KASAN_STACK workable. see [1].
> >
> > When enable KASAN stack instrumentation, then for gcc we could do
> > no prompt and default value y, and for clang prompt and default
> > value n.
> >
> > [1]: https://bugzilla.kernel.org/show_bug.cgi?id=210221
> >
> > Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> > Suggested-by: Dmitry Vyukov <dvyukov@google.com>
> > Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> > Cc: Dmitry Vyukov <dvyukov@google.com>
> > Cc: Andrey Konovalov <andreyknvl@google.com>
> > Cc: Alexander Potapenko <glider@google.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Nathan Chancellor <natechancellor@gmail.com>
> > ---
> >
> > v2: make commit log to be more readable.
> > v3: remain CONFIG_KASAN_STACK_ENABLE setting
> > fix the pre-processors syntax
> >
> > ---
> > arch/arm64/kernel/sleep.S | 2 +-
> > arch/x86/kernel/acpi/wakeup_64.S | 2 +-
> > include/linux/kasan.h | 2 +-
> > lib/Kconfig.kasan | 8 ++------
> > mm/kasan/common.c | 2 +-
> > mm/kasan/kasan.h | 2 +-
> > mm/kasan/report_generic.c | 2 +-
> > scripts/Makefile.kasan | 10 ++++++++--
> > 8 files changed, 16 insertions(+), 14 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S
> > index 6bdef7362c0e..7c44ede122a9 100644
> > --- a/arch/arm64/kernel/sleep.S
> > +++ b/arch/arm64/kernel/sleep.S
> > @@ -133,7 +133,7 @@ SYM_FUNC_START(_cpu_resume)
> > */
> > bl cpu_do_resume
> >
> > -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> > +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> > mov x0, sp
> > bl kasan_unpoison_task_stack_below
> > #endif
> > diff --git a/arch/x86/kernel/acpi/wakeup_64.S b/arch/x86/kernel/acpi/wakeup_64.S
> > index 5d3a0b8fd379..c7f412f4e07d 100644
> > --- a/arch/x86/kernel/acpi/wakeup_64.S
> > +++ b/arch/x86/kernel/acpi/wakeup_64.S
> > @@ -112,7 +112,7 @@ SYM_FUNC_START(do_suspend_lowlevel)
> > movq pt_regs_r14(%rax), %r14
> > movq pt_regs_r15(%rax), %r15
> >
> > -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> > +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> > /*
> > * The suspend path may have poisoned some areas deeper in the stack,
> > * which we now need to unpoison.
> > diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> > index 5e0655fb2a6f..35d1e9b2cbfa 100644
> > --- a/include/linux/kasan.h
> > +++ b/include/linux/kasan.h
> > @@ -302,7 +302,7 @@ static inline void kasan_kfree_large(void *ptr, unsigned long ip) {}
> >
> > #endif /* CONFIG_KASAN */
> >
> > -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> > +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> > void kasan_unpoison_task_stack(struct task_struct *task);
> > #else
> > static inline void kasan_unpoison_task_stack(struct task_struct *task) {}
> > diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
> > index f5fa4ba126bf..fde82ec85f8f 100644
> > --- a/lib/Kconfig.kasan
> > +++ b/lib/Kconfig.kasan
> > @@ -138,9 +138,10 @@ config KASAN_INLINE
> >
> > endchoice
> >
> > -config KASAN_STACK_ENABLE
> > +config KASAN_STACK
> > bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
>
> Does this syntax mean that KASAN_STACK is only present for
> CC_IS_CLANG? Or that it can only be disabled for CC_IS_CLANG?
It means that the option can only be disabled for clang.
> Anyway, I think it's better to 1. allow to control KASAN_STACK
> regardless of the compiler (as it was possible before), and 2. avoid
It has never been possible to control KASAN_STACK for GCC because of the
bool ... if ... syntax. This patch does not change that logic. Making it
possible to control KASAN_STACK with GCC seems fine but that is going to
be a new change that would probably be suited for a new patch on top of
this one.
> this "bool ... if ..." syntax as it's confusing.
>
> > depends on KASAN_GENERIC || KASAN_SW_TAGS
> > + default y if CC_IS_GCC
> > help
> > The LLVM stack address sanitizer has a know problem that
> > causes excessive stack usage in a lot of functions, see
> > @@ -154,11 +155,6 @@ config KASAN_STACK_ENABLE
> > CONFIG_COMPILE_TEST. On gcc it is assumed to always be safe
> > to use and enabled by default.
> >
> > -config KASAN_STACK
> > - int
> > - default 1 if KASAN_STACK_ENABLE || CC_IS_GCC
> > - default 0
> > -
> > config KASAN_SW_TAGS_IDENTIFY
> > bool "Enable memory corruption identification"
> > depends on KASAN_SW_TAGS
> > diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> > index 38ba2aecd8f4..bf8b073eed62 100644
> > --- a/mm/kasan/common.c
> > +++ b/mm/kasan/common.c
> > @@ -63,7 +63,7 @@ void __kasan_unpoison_range(const void *address, size_t size)
> > unpoison_range(address, size);
> > }
> >
> > -#if CONFIG_KASAN_STACK
> > +#ifdef CONFIG_KASAN_STACK
> > /* Unpoison the entire stack for a task. */
> > void kasan_unpoison_task_stack(struct task_struct *task)
> > {
> > diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> > index cc4d9e1d49b1..bdfdb1cff653 100644
> > --- a/mm/kasan/kasan.h
> > +++ b/mm/kasan/kasan.h
> > @@ -224,7 +224,7 @@ void *find_first_bad_addr(void *addr, size_t size);
> > const char *get_bug_type(struct kasan_access_info *info);
> > void metadata_fetch_row(char *buffer, void *row);
> >
> > -#if defined(CONFIG_KASAN_GENERIC) && CONFIG_KASAN_STACK
> > +#if defined(CONFIG_KASAN_GENERIC) && defined(CONFIG_KASAN_STACK)
> > void print_address_stack_frame(const void *addr);
> > #else
> > static inline void print_address_stack_frame(const void *addr) { }
> > diff --git a/mm/kasan/report_generic.c b/mm/kasan/report_generic.c
> > index 8a9c889872da..4e16518d9877 100644
> > --- a/mm/kasan/report_generic.c
> > +++ b/mm/kasan/report_generic.c
> > @@ -128,7 +128,7 @@ void metadata_fetch_row(char *buffer, void *row)
> > memcpy(buffer, kasan_mem_to_shadow(row), META_BYTES_PER_ROW);
> > }
> >
> > -#if CONFIG_KASAN_STACK
> > +#ifdef CONFIG_KASAN_STACK
> > static bool __must_check tokenize_frame_descr(const char **frame_descr,
> > char *token, size_t max_tok_len,
> > unsigned long *value)
> > diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan
> > index 1e000cc2e7b4..abf231d209b1 100644
> > --- a/scripts/Makefile.kasan
> > +++ b/scripts/Makefile.kasan
> > @@ -2,6 +2,12 @@
> > CFLAGS_KASAN_NOSANITIZE := -fno-builtin
> > KASAN_SHADOW_OFFSET ?= $(CONFIG_KASAN_SHADOW_OFFSET)
> >
> > +ifdef CONFIG_KASAN_STACK
> > + stack_enable := 1
> > +else
> > + stack_enable := 0
> > +endif
> > +
> > ifdef CONFIG_KASAN_GENERIC
> >
> > ifdef CONFIG_KASAN_INLINE
> > @@ -27,7 +33,7 @@ else
> > CFLAGS_KASAN := $(CFLAGS_KASAN_SHADOW) \
> > $(call cc-param,asan-globals=1) \
> > $(call cc-param,asan-instrumentation-with-call-threshold=$(call_threshold)) \
> > - $(call cc-param,asan-stack=$(CONFIG_KASAN_STACK)) \
> > + $(call cc-param,asan-stack=$(stack_enable)) \
> > $(call cc-param,asan-instrument-allocas=1)
> > endif
> >
> > @@ -42,7 +48,7 @@ else
> > endif
> >
> > CFLAGS_KASAN := -fsanitize=kernel-hwaddress \
> > - -mllvm -hwasan-instrument-stack=$(CONFIG_KASAN_STACK) \
> > + -mllvm -hwasan-instrument-stack=$(stack_enable) \
> > -mllvm -hwasan-use-short-granules=0 \
> > $(instrumentation_flags)
> >
> > --
> > 2.18.0
> >
> > --
> > You received this message because you are subscribed to the Google Groups "kasan-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com.
> > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20210108040940.1138-1-walter-zh.wu%40mediatek.com.
^ permalink raw reply [relevance 99%]
* Re: [PATCH v3] kasan: remove redundant config option
@ 2021-01-11 18:59 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-11 18:59 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Walter Wu, wsd_upstream, moderated list:ARM/Mediatek SoC...,
LKML, kasan-dev, Linux Memory Management List,
Alexander Potapenko, Linux ARM, Andrey Ryabinin, Andrew Morton,
Dmitry Vyukov
On Mon, Jan 11, 2021 at 06:49:37PM +0100, Andrey Konovalov wrote:
> On Fri, Jan 8, 2021 at 5:09 AM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> >
> > CONFIG_KASAN_STACK and CONFIG_KASAN_STACK_ENABLE both enable KASAN stack
> > instrumentation, but we should only need one config, so that we remove
> > CONFIG_KASAN_STACK_ENABLE and make CONFIG_KASAN_STACK workable. see [1].
> >
> > When enable KASAN stack instrumentation, then for gcc we could do
> > no prompt and default value y, and for clang prompt and default
> > value n.
> >
> > [1]: https://bugzilla.kernel.org/show_bug.cgi?id=210221
> >
> > Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> > Suggested-by: Dmitry Vyukov <dvyukov@google.com>
> > Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> > Cc: Dmitry Vyukov <dvyukov@google.com>
> > Cc: Andrey Konovalov <andreyknvl@google.com>
> > Cc: Alexander Potapenko <glider@google.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Nathan Chancellor <natechancellor@gmail.com>
> > ---
> >
> > v2: make commit log to be more readable.
> > v3: remain CONFIG_KASAN_STACK_ENABLE setting
> > fix the pre-processors syntax
> >
> > ---
> > arch/arm64/kernel/sleep.S | 2 +-
> > arch/x86/kernel/acpi/wakeup_64.S | 2 +-
> > include/linux/kasan.h | 2 +-
> > lib/Kconfig.kasan | 8 ++------
> > mm/kasan/common.c | 2 +-
> > mm/kasan/kasan.h | 2 +-
> > mm/kasan/report_generic.c | 2 +-
> > scripts/Makefile.kasan | 10 ++++++++--
> > 8 files changed, 16 insertions(+), 14 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S
> > index 6bdef7362c0e..7c44ede122a9 100644
> > --- a/arch/arm64/kernel/sleep.S
> > +++ b/arch/arm64/kernel/sleep.S
> > @@ -133,7 +133,7 @@ SYM_FUNC_START(_cpu_resume)
> > */
> > bl cpu_do_resume
> >
> > -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> > +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> > mov x0, sp
> > bl kasan_unpoison_task_stack_below
> > #endif
> > diff --git a/arch/x86/kernel/acpi/wakeup_64.S b/arch/x86/kernel/acpi/wakeup_64.S
> > index 5d3a0b8fd379..c7f412f4e07d 100644
> > --- a/arch/x86/kernel/acpi/wakeup_64.S
> > +++ b/arch/x86/kernel/acpi/wakeup_64.S
> > @@ -112,7 +112,7 @@ SYM_FUNC_START(do_suspend_lowlevel)
> > movq pt_regs_r14(%rax), %r14
> > movq pt_regs_r15(%rax), %r15
> >
> > -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> > +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> > /*
> > * The suspend path may have poisoned some areas deeper in the stack,
> > * which we now need to unpoison.
> > diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> > index 5e0655fb2a6f..35d1e9b2cbfa 100644
> > --- a/include/linux/kasan.h
> > +++ b/include/linux/kasan.h
> > @@ -302,7 +302,7 @@ static inline void kasan_kfree_large(void *ptr, unsigned long ip) {}
> >
> > #endif /* CONFIG_KASAN */
> >
> > -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> > +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> > void kasan_unpoison_task_stack(struct task_struct *task);
> > #else
> > static inline void kasan_unpoison_task_stack(struct task_struct *task) {}
> > diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
> > index f5fa4ba126bf..fde82ec85f8f 100644
> > --- a/lib/Kconfig.kasan
> > +++ b/lib/Kconfig.kasan
> > @@ -138,9 +138,10 @@ config KASAN_INLINE
> >
> > endchoice
> >
> > -config KASAN_STACK_ENABLE
> > +config KASAN_STACK
> > bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
>
> Does this syntax mean that KASAN_STACK is only present for
> CC_IS_CLANG? Or that it can only be disabled for CC_IS_CLANG?
It means that the option can only be disabled for clang.
> Anyway, I think it's better to 1. allow to control KASAN_STACK
> regardless of the compiler (as it was possible before), and 2. avoid
It has never been possible to control KASAN_STACK for GCC because of the
bool ... if ... syntax. This patch does not change that logic. Making it
possible to control KASAN_STACK with GCC seems fine but that is going to
be a new change that would probably be suited for a new patch on top of
this one.
> this "bool ... if ..." syntax as it's confusing.
>
> > depends on KASAN_GENERIC || KASAN_SW_TAGS
> > + default y if CC_IS_GCC
> > help
> > The LLVM stack address sanitizer has a know problem that
> > causes excessive stack usage in a lot of functions, see
> > @@ -154,11 +155,6 @@ config KASAN_STACK_ENABLE
> > CONFIG_COMPILE_TEST. On gcc it is assumed to always be safe
> > to use and enabled by default.
> >
> > -config KASAN_STACK
> > - int
> > - default 1 if KASAN_STACK_ENABLE || CC_IS_GCC
> > - default 0
> > -
> > config KASAN_SW_TAGS_IDENTIFY
> > bool "Enable memory corruption identification"
> > depends on KASAN_SW_TAGS
> > diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> > index 38ba2aecd8f4..bf8b073eed62 100644
> > --- a/mm/kasan/common.c
> > +++ b/mm/kasan/common.c
> > @@ -63,7 +63,7 @@ void __kasan_unpoison_range(const void *address, size_t size)
> > unpoison_range(address, size);
> > }
> >
> > -#if CONFIG_KASAN_STACK
> > +#ifdef CONFIG_KASAN_STACK
> > /* Unpoison the entire stack for a task. */
> > void kasan_unpoison_task_stack(struct task_struct *task)
> > {
> > diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> > index cc4d9e1d49b1..bdfdb1cff653 100644
> > --- a/mm/kasan/kasan.h
> > +++ b/mm/kasan/kasan.h
> > @@ -224,7 +224,7 @@ void *find_first_bad_addr(void *addr, size_t size);
> > const char *get_bug_type(struct kasan_access_info *info);
> > void metadata_fetch_row(char *buffer, void *row);
> >
> > -#if defined(CONFIG_KASAN_GENERIC) && CONFIG_KASAN_STACK
> > +#if defined(CONFIG_KASAN_GENERIC) && defined(CONFIG_KASAN_STACK)
> > void print_address_stack_frame(const void *addr);
> > #else
> > static inline void print_address_stack_frame(const void *addr) { }
> > diff --git a/mm/kasan/report_generic.c b/mm/kasan/report_generic.c
> > index 8a9c889872da..4e16518d9877 100644
> > --- a/mm/kasan/report_generic.c
> > +++ b/mm/kasan/report_generic.c
> > @@ -128,7 +128,7 @@ void metadata_fetch_row(char *buffer, void *row)
> > memcpy(buffer, kasan_mem_to_shadow(row), META_BYTES_PER_ROW);
> > }
> >
> > -#if CONFIG_KASAN_STACK
> > +#ifdef CONFIG_KASAN_STACK
> > static bool __must_check tokenize_frame_descr(const char **frame_descr,
> > char *token, size_t max_tok_len,
> > unsigned long *value)
> > diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan
> > index 1e000cc2e7b4..abf231d209b1 100644
> > --- a/scripts/Makefile.kasan
> > +++ b/scripts/Makefile.kasan
> > @@ -2,6 +2,12 @@
> > CFLAGS_KASAN_NOSANITIZE := -fno-builtin
> > KASAN_SHADOW_OFFSET ?= $(CONFIG_KASAN_SHADOW_OFFSET)
> >
> > +ifdef CONFIG_KASAN_STACK
> > + stack_enable := 1
> > +else
> > + stack_enable := 0
> > +endif
> > +
> > ifdef CONFIG_KASAN_GENERIC
> >
> > ifdef CONFIG_KASAN_INLINE
> > @@ -27,7 +33,7 @@ else
> > CFLAGS_KASAN := $(CFLAGS_KASAN_SHADOW) \
> > $(call cc-param,asan-globals=1) \
> > $(call cc-param,asan-instrumentation-with-call-threshold=$(call_threshold)) \
> > - $(call cc-param,asan-stack=$(CONFIG_KASAN_STACK)) \
> > + $(call cc-param,asan-stack=$(stack_enable)) \
> > $(call cc-param,asan-instrument-allocas=1)
> > endif
> >
> > @@ -42,7 +48,7 @@ else
> > endif
> >
> > CFLAGS_KASAN := -fsanitize=kernel-hwaddress \
> > - -mllvm -hwasan-instrument-stack=$(CONFIG_KASAN_STACK) \
> > + -mllvm -hwasan-instrument-stack=$(stack_enable) \
> > -mllvm -hwasan-use-short-granules=0 \
> > $(instrumentation_flags)
> >
> > --
> > 2.18.0
> >
> > --
> > You received this message because you are subscribed to the Google Groups "kasan-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com.
> > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20210108040940.1138-1-walter-zh.wu%40mediatek.com.
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [relevance 99%]
* Re: [PATCH v3] kasan: remove redundant config option
@ 2021-01-11 18:59 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-11 18:59 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Walter Wu, Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov,
Andrew Morton, kasan-dev, Linux Memory Management List, LKML,
Linux ARM, wsd_upstream, moderated list:ARM/Mediatek SoC...
On Mon, Jan 11, 2021 at 06:49:37PM +0100, Andrey Konovalov wrote:
> On Fri, Jan 8, 2021 at 5:09 AM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> >
> > CONFIG_KASAN_STACK and CONFIG_KASAN_STACK_ENABLE both enable KASAN stack
> > instrumentation, but we should only need one config, so that we remove
> > CONFIG_KASAN_STACK_ENABLE and make CONFIG_KASAN_STACK workable. see [1].
> >
> > When enable KASAN stack instrumentation, then for gcc we could do
> > no prompt and default value y, and for clang prompt and default
> > value n.
> >
> > [1]: https://bugzilla.kernel.org/show_bug.cgi?id=210221
> >
> > Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> > Suggested-by: Dmitry Vyukov <dvyukov@google.com>
> > Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> > Cc: Dmitry Vyukov <dvyukov@google.com>
> > Cc: Andrey Konovalov <andreyknvl@google.com>
> > Cc: Alexander Potapenko <glider@google.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Nathan Chancellor <natechancellor@gmail.com>
> > ---
> >
> > v2: make commit log to be more readable.
> > v3: remain CONFIG_KASAN_STACK_ENABLE setting
> > fix the pre-processors syntax
> >
> > ---
> > arch/arm64/kernel/sleep.S | 2 +-
> > arch/x86/kernel/acpi/wakeup_64.S | 2 +-
> > include/linux/kasan.h | 2 +-
> > lib/Kconfig.kasan | 8 ++------
> > mm/kasan/common.c | 2 +-
> > mm/kasan/kasan.h | 2 +-
> > mm/kasan/report_generic.c | 2 +-
> > scripts/Makefile.kasan | 10 ++++++++--
> > 8 files changed, 16 insertions(+), 14 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S
> > index 6bdef7362c0e..7c44ede122a9 100644
> > --- a/arch/arm64/kernel/sleep.S
> > +++ b/arch/arm64/kernel/sleep.S
> > @@ -133,7 +133,7 @@ SYM_FUNC_START(_cpu_resume)
> > */
> > bl cpu_do_resume
> >
> > -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> > +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> > mov x0, sp
> > bl kasan_unpoison_task_stack_below
> > #endif
> > diff --git a/arch/x86/kernel/acpi/wakeup_64.S b/arch/x86/kernel/acpi/wakeup_64.S
> > index 5d3a0b8fd379..c7f412f4e07d 100644
> > --- a/arch/x86/kernel/acpi/wakeup_64.S
> > +++ b/arch/x86/kernel/acpi/wakeup_64.S
> > @@ -112,7 +112,7 @@ SYM_FUNC_START(do_suspend_lowlevel)
> > movq pt_regs_r14(%rax), %r14
> > movq pt_regs_r15(%rax), %r15
> >
> > -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> > +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> > /*
> > * The suspend path may have poisoned some areas deeper in the stack,
> > * which we now need to unpoison.
> > diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> > index 5e0655fb2a6f..35d1e9b2cbfa 100644
> > --- a/include/linux/kasan.h
> > +++ b/include/linux/kasan.h
> > @@ -302,7 +302,7 @@ static inline void kasan_kfree_large(void *ptr, unsigned long ip) {}
> >
> > #endif /* CONFIG_KASAN */
> >
> > -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> > +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> > void kasan_unpoison_task_stack(struct task_struct *task);
> > #else
> > static inline void kasan_unpoison_task_stack(struct task_struct *task) {}
> > diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
> > index f5fa4ba126bf..fde82ec85f8f 100644
> > --- a/lib/Kconfig.kasan
> > +++ b/lib/Kconfig.kasan
> > @@ -138,9 +138,10 @@ config KASAN_INLINE
> >
> > endchoice
> >
> > -config KASAN_STACK_ENABLE
> > +config KASAN_STACK
> > bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
>
> Does this syntax mean that KASAN_STACK is only present for
> CC_IS_CLANG? Or that it can only be disabled for CC_IS_CLANG?
It means that the option can only be disabled for clang.
> Anyway, I think it's better to 1. allow to control KASAN_STACK
> regardless of the compiler (as it was possible before), and 2. avoid
It has never been possible to control KASAN_STACK for GCC because of the
bool ... if ... syntax. This patch does not change that logic. Making it
possible to control KASAN_STACK with GCC seems fine but that is going to
be a new change that would probably be suited for a new patch on top of
this one.
> this "bool ... if ..." syntax as it's confusing.
>
> > depends on KASAN_GENERIC || KASAN_SW_TAGS
> > + default y if CC_IS_GCC
> > help
> > The LLVM stack address sanitizer has a know problem that
> > causes excessive stack usage in a lot of functions, see
> > @@ -154,11 +155,6 @@ config KASAN_STACK_ENABLE
> > CONFIG_COMPILE_TEST. On gcc it is assumed to always be safe
> > to use and enabled by default.
> >
> > -config KASAN_STACK
> > - int
> > - default 1 if KASAN_STACK_ENABLE || CC_IS_GCC
> > - default 0
> > -
> > config KASAN_SW_TAGS_IDENTIFY
> > bool "Enable memory corruption identification"
> > depends on KASAN_SW_TAGS
> > diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> > index 38ba2aecd8f4..bf8b073eed62 100644
> > --- a/mm/kasan/common.c
> > +++ b/mm/kasan/common.c
> > @@ -63,7 +63,7 @@ void __kasan_unpoison_range(const void *address, size_t size)
> > unpoison_range(address, size);
> > }
> >
> > -#if CONFIG_KASAN_STACK
> > +#ifdef CONFIG_KASAN_STACK
> > /* Unpoison the entire stack for a task. */
> > void kasan_unpoison_task_stack(struct task_struct *task)
> > {
> > diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> > index cc4d9e1d49b1..bdfdb1cff653 100644
> > --- a/mm/kasan/kasan.h
> > +++ b/mm/kasan/kasan.h
> > @@ -224,7 +224,7 @@ void *find_first_bad_addr(void *addr, size_t size);
> > const char *get_bug_type(struct kasan_access_info *info);
> > void metadata_fetch_row(char *buffer, void *row);
> >
> > -#if defined(CONFIG_KASAN_GENERIC) && CONFIG_KASAN_STACK
> > +#if defined(CONFIG_KASAN_GENERIC) && defined(CONFIG_KASAN_STACK)
> > void print_address_stack_frame(const void *addr);
> > #else
> > static inline void print_address_stack_frame(const void *addr) { }
> > diff --git a/mm/kasan/report_generic.c b/mm/kasan/report_generic.c
> > index 8a9c889872da..4e16518d9877 100644
> > --- a/mm/kasan/report_generic.c
> > +++ b/mm/kasan/report_generic.c
> > @@ -128,7 +128,7 @@ void metadata_fetch_row(char *buffer, void *row)
> > memcpy(buffer, kasan_mem_to_shadow(row), META_BYTES_PER_ROW);
> > }
> >
> > -#if CONFIG_KASAN_STACK
> > +#ifdef CONFIG_KASAN_STACK
> > static bool __must_check tokenize_frame_descr(const char **frame_descr,
> > char *token, size_t max_tok_len,
> > unsigned long *value)
> > diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan
> > index 1e000cc2e7b4..abf231d209b1 100644
> > --- a/scripts/Makefile.kasan
> > +++ b/scripts/Makefile.kasan
> > @@ -2,6 +2,12 @@
> > CFLAGS_KASAN_NOSANITIZE := -fno-builtin
> > KASAN_SHADOW_OFFSET ?= $(CONFIG_KASAN_SHADOW_OFFSET)
> >
> > +ifdef CONFIG_KASAN_STACK
> > + stack_enable := 1
> > +else
> > + stack_enable := 0
> > +endif
> > +
> > ifdef CONFIG_KASAN_GENERIC
> >
> > ifdef CONFIG_KASAN_INLINE
> > @@ -27,7 +33,7 @@ else
> > CFLAGS_KASAN := $(CFLAGS_KASAN_SHADOW) \
> > $(call cc-param,asan-globals=1) \
> > $(call cc-param,asan-instrumentation-with-call-threshold=$(call_threshold)) \
> > - $(call cc-param,asan-stack=$(CONFIG_KASAN_STACK)) \
> > + $(call cc-param,asan-stack=$(stack_enable)) \
> > $(call cc-param,asan-instrument-allocas=1)
> > endif
> >
> > @@ -42,7 +48,7 @@ else
> > endif
> >
> > CFLAGS_KASAN := -fsanitize=kernel-hwaddress \
> > - -mllvm -hwasan-instrument-stack=$(CONFIG_KASAN_STACK) \
> > + -mllvm -hwasan-instrument-stack=$(stack_enable) \
> > -mllvm -hwasan-use-short-granules=0 \
> > $(instrumentation_flags)
> >
> > --
> > 2.18.0
> >
> > --
> > You received this message because you are subscribed to the Google Groups "kasan-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com.
> > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20210108040940.1138-1-walter-zh.wu%40mediatek.com.
^ permalink raw reply [relevance 99%]
* Re: [PATCH] pgo: add clang's Profile Guided Optimization infrastructure
@ 2021-01-11 18:28 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-11 18:28 UTC (permalink / raw)
To: Sedat Dilek
Cc: Bill Wendling, Jonathan Corbet, Masahiro Yamada, linux-doc, LKML,
Linux Kbuild mailing list, Clang-Built-Linux ML, Andrew Morton,
Nick Desaulniers, Sami Tolvanen
On Mon, Jan 11, 2021 at 10:57:35AM +0100, Sedat Dilek wrote:
> On Mon, Jan 11, 2021 at 10:17 AM Bill Wendling <morbo@google.com> wrote:
> >
> > On Mon, Jan 11, 2021 at 12:39 AM Sedat Dilek <sedat.dilek@gmail.com> wrote:
> > >
> > > On Mon, Jan 11, 2021 at 9:18 AM 'Bill Wendling' via Clang Built Linux
> > > <clang-built-linux@googlegroups.com> wrote:
> > > >
> > > > From: Sami Tolvanen <samitolvanen@google.com>
> > > >
> > > > Enable the use of clang's Profile-Guided Optimization[1]. To generate a
> > > > profile, the kernel is instrumented with PGO counters, a representative
> > > > workload is run, and the raw profile data is collected from
> > > > /sys/kernel/debug/pgo/profraw.
> > > >
> > > > The raw profile data must be processed by clang's "llvm-profdata" tool before
> > > > it can be used during recompilation:
> > > >
> > > > $ cp /sys/kernel/debug/pgo/profraw vmlinux.profraw
> > > > $ llvm-profdata merge --output=vmlinux.profdata vmlinux.profraw
> > > >
> > > > Multiple raw profiles may be merged during this step.
> > > >
> > > > The data can be used either by the compiler if LTO isn't enabled:
> > > >
> > > > ... -fprofile-use=vmlinux.profdata ...
> > > >
> > > > or by LLD if LTO is enabled:
> > > >
> > > > ... -lto-cs-profile-file=vmlinux.profdata ...
> > > >
> > > > This initial submission is restricted to x86, as that's the platform we know
> > > > works. This restriction can be lifted once other platforms have been verified
> > > > to work with PGO.
> > > >
> > > > Note that this method of profiling the kernel is clang-native and isn't
> > > > compatible with clang's gcov support in kernel/gcov.
> > > >
> > > > [1] https://clang.llvm.org/docs/UsersManual.html#profile-guided-optimization
> > > >
> > >
> > > Hi Bill and Sami,
> > >
> > > I have seen the pull-request in the CBL issue tracker and had some
> > > questions in mind.
> > >
> > > Good you send this.
> > >
> > > First of all, I like to fetch any development stuff easily from a Git
> > > repository.
> >
> > The version in the pull-request in the CBL issue tracker is roughly
> > the same as this patch. (There are some changes, but they aren't
> > functionality changes.)
> >
> > > Can you offer this, please?
> > > What is the base for your work?
> > > I hope this is (fresh released) Linux v5.11-rc3.
> > >
> > This patch (and the PR on the CBL issue tracker) are from top-of-tree Linux.
> >
> > > I myself had some experiences with a PGO + ThinLTO optimized LLVM
> > > toolchain built with the help of tc-build.
> > > Here it takes very long to build it.
> > >
> > > This means I have some profile-data archived.
> > > Can I use it?
> > >
> > LLVM is more tolerant of "stale" profile data than gcov, so it's
> > possible that your archived profile data would still work, but I can't
> > guarantee that it will be better than using new profile data.
> >
> > > Is an own PGO + ThinLTO optimized LLVM toolchain pre-requirement for
> > > this or not?
> > > That is one of my important questions.
> > >
> > Do you mean that the LLVM tools (clang, llc, etc.) are compiled with
> > PGO + ThinLTO?
> >
>
> Yes.
>
> - Sedat -
No, having an optimized LLVM toolchain is not a requirement of this
patchset. It will make compiling the kernel faster but it does nothing
more than that.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* [PATCH] bpf: Hoise pahole version checks into Kconfig
@ 2021-01-11 18:06 79% Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2021-01-11 18:06 UTC (permalink / raw)
To: Masahiro Yamada, Michal Marek, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko
Cc: Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
KP Singh, linux-kernel, linux-kbuild, netdev, bpf,
Nathan Chancellor, Sedat Dilek
After commit da5fb18225b4 ("bpf: Support pre-2.25-binutils objcopy for
vmlinux BTF"), having CONFIG_DEBUG_INFO_BTF enabled but lacking a valid
copy of pahole results in a kernel that will fully compile but fail to
link. The user then has to either install pahole or disable
CONFIG_DEBUG_INFO_BTF and rebuild the kernel but only after their build
has failed, which could have been a significant amount of time depending
on the hardware.
Avoid a poor user experience and require pahole to be installed with an
appropriate version to select and use CONFIG_DEBUG_INFO_BTF, which is
standard for options that require a specific tools version.
Suggested-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
MAINTAINERS | 1 +
init/Kconfig | 4 ++++
lib/Kconfig.debug | 6 ++----
scripts/link-vmlinux.sh | 13 -------------
scripts/pahole-version.sh | 16 ++++++++++++++++
5 files changed, 23 insertions(+), 17 deletions(-)
create mode 100755 scripts/pahole-version.sh
diff --git a/MAINTAINERS b/MAINTAINERS
index b8db7637263a..6f6e24285a94 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3282,6 +3282,7 @@ F: net/core/filter.c
F: net/sched/act_bpf.c
F: net/sched/cls_bpf.c
F: samples/bpf/
+F: scripts/pahole-version.sh
F: tools/bpf/
F: tools/lib/bpf/
F: tools/testing/selftests/bpf/
diff --git a/init/Kconfig b/init/Kconfig
index b77c60f8b963..872c61b5d204 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -74,6 +74,10 @@ config TOOLS_SUPPORT_RELR
config CC_HAS_ASM_INLINE
def_bool $(success,echo 'void foo(void) { asm inline (""); }' | $(CC) -x c - -c -o /dev/null)
+config PAHOLE_VERSION
+ int
+ default $(shell,$(srctree)/scripts/pahole-version.sh $(PAHOLE))
+
config CONSTRUCTORS
bool
depends on !UML
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 7937265ef879..70c446af9664 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -267,6 +267,7 @@ config DEBUG_INFO_DWARF4
config DEBUG_INFO_BTF
bool "Generate BTF typeinfo"
+ depends on PAHOLE_VERSION >= 116
depends on !DEBUG_INFO_SPLIT && !DEBUG_INFO_REDUCED
depends on !GCC_PLUGIN_RANDSTRUCT || COMPILE_TEST
help
@@ -274,12 +275,9 @@ config DEBUG_INFO_BTF
Turning this on expects presence of pahole tool, which will convert
DWARF type info into equivalent deduplicated BTF type info.
-config PAHOLE_HAS_SPLIT_BTF
- def_bool $(success, test `$(PAHOLE) --version | sed -E 's/v([0-9]+)\.([0-9]+)/\1\2/'` -ge "119")
-
config DEBUG_INFO_BTF_MODULES
def_bool y
- depends on DEBUG_INFO_BTF && MODULES && PAHOLE_HAS_SPLIT_BTF
+ depends on DEBUG_INFO_BTF && MODULES && PAHOLE_VERSION >= 119
help
Generate compact split BTF type information for kernel modules.
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index 6eded325c837..eef40fa9485d 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -139,19 +139,6 @@ vmlinux_link()
# ${2} - file to dump raw BTF data into
gen_btf()
{
- local pahole_ver
-
- if ! [ -x "$(command -v ${PAHOLE})" ]; then
- echo >&2 "BTF: ${1}: pahole (${PAHOLE}) is not available"
- return 1
- fi
-
- pahole_ver=$(${PAHOLE} --version | sed -E 's/v([0-9]+)\.([0-9]+)/\1\2/')
- if [ "${pahole_ver}" -lt "116" ]; then
- echo >&2 "BTF: ${1}: pahole version $(${PAHOLE} --version) is too old, need at least v1.16"
- return 1
- fi
-
vmlinux_link ${1}
info "BTF" ${2}
diff --git a/scripts/pahole-version.sh b/scripts/pahole-version.sh
new file mode 100755
index 000000000000..6de6f734a345
--- /dev/null
+++ b/scripts/pahole-version.sh
@@ -0,0 +1,16 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+#
+# Usage: $ ./scripts/pahole-version.sh pahole
+#
+# Print the pahole version as a three digit string
+# such as `119' for pahole v1.19 etc.
+
+pahole="$*"
+
+if ! [ -x "$(command -v $pahole)" ]; then
+ echo 0
+ exit 1
+fi
+
+$pahole --version | sed -E 's/v([0-9]+)\.([0-9]+)/\1\2/'
base-commit: e22d7f05e445165e58feddb4e40cc9c0f94453bc
--
2.30.0
^ permalink raw reply related [relevance 79%]
* Re: [PATCH 4/5] hw/ppc/ppc4xx_pci: Replace pointless warning by assert()
@ 2021-01-11 16:46 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-11 16:46 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Peter Maydell, Aleksandar Rikalo, qemu-trivial, Mark Cave-Ayland,
qemu-devel, Aleksandar Markovic, qemu-arm, qemu-ppc, Huacai Chen,
Philippe Mathieu-Daudé,
Aurelien Jarno, David Gibson
On Mon, Jan 11, 2021 at 11:04:25AM +0100, Philippe Mathieu-Daudé wrote:
> +Peter
>
> On 1/11/21 2:11 AM, Nathan Chancellor wrote:
> > On Tue, Sep 01, 2020 at 12:40:42PM +0200, Philippe Mathieu-Daudé wrote:
> >> We call pci_register_root_bus() to register 4 IRQs with the
> >> ppc4xx_pci_set_irq() handler. As it can only be called with
> >> values in the [0-4[ range, replace the pointless warning by
> >> an assert().
> >>
> >> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> >> ---
> >> hw/ppc/ppc4xx_pci.c | 5 +----
> >> 1 file changed, 1 insertion(+), 4 deletions(-)
> >>
> >> diff --git a/hw/ppc/ppc4xx_pci.c b/hw/ppc/ppc4xx_pci.c
> >> index cd3f192a138..503ef46b39a 100644
> >> --- a/hw/ppc/ppc4xx_pci.c
> >> +++ b/hw/ppc/ppc4xx_pci.c
> >> @@ -256,10 +256,7 @@ static void ppc4xx_pci_set_irq(void *opaque, int irq_num, int level)
> >> qemu_irq *pci_irqs = opaque;
> >>
> >> trace_ppc4xx_pci_set_irq(irq_num);
> >> - if (irq_num < 0) {
> >> - fprintf(stderr, "%s: PCI irq %d\n", __func__, irq_num);
> >> - return;
> >> - }
> >> + assert(irq_num >= 0);
> >> qemu_set_irq(pci_irqs[irq_num], level);
> >> }
> >>
> >> --
> >> 2.26.2
> >>
> >>
> >
> > Hopefully reporting this here is okay, I find Launchpad hard to use but
> > I can file it there if need be.
> >
> > The assertion added by this patch triggers while trying to boot a
> > ppc44x_defconfig Linux kernel:
> >
> > $ qemu-system-ppc \
> > -machine bamboo \
> > -no-reboot \
> > -append console=ttyS0 \
> > -display none \
> > -kernel uImage \
> > -m 128m \
> > -nodefaults \
> > -serial mon:stdio
> > Linux version 5.11.0-rc3 (nathan@ubuntu-m3-large-x86) (powerpc-linux-gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.35) #1 Sun Jan 10 15:52:24 MST 2021
> > Using PowerPC 44x Platform machine description
> > ioremap() called early from find_legacy_serial_ports+0x64c/0x794. Use early_ioremap() instead
> ...
> > PCI: Probing PCI hardware
> > PCI host bridge to bus 0000:00
> > pci_bus 0000:00: root bus resource [io 0x0000-0xffff]
> > pci_bus 0000:00: root bus resource [mem 0xa0000000-0xbfffffff]
> > pci_bus 0000:00: root bus resource [bus 00-ff]
> > pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to ff
> > pci 0000:00:00.0: [1014:027f] type 00 class 0x068000
> > qemu-system-ppc: ../hw/ppc/ppc4xx_pci.c:259: ppc4xx_pci_set_irq: Assertion `irq_num >= 0' failed.
> >
> > On v5.2.0, it looks like a higher assertion triggers, added by
> > commit 459ca8bfa4 ("pci: Assert irqnum is between 0 and bus->nirqs in
> > pci_bus_change_irq_level").
> >
> > qemu-system-ppc: ../hw/pci/pci.c:253: pci_bus_change_irq_level: Assertion `irq_num >= 0' failed.
>
> Running with '-trace ppc4xx_pci\*':
>
> 1275265@1610357661.994462:ppc4xx_pci_map_irq devfn 0x0 irq 0 -> 0
> 1275265@1610357661.994480:ppc4xx_pci_set_irq PCI irq -1
>
> (gdb) bt
> #0 0x00007fc70a8a19e5 in raise () at /lib64/libc.so.6
> #1 0x00007fc70a88a895 in abort () at /lib64/libc.so.6
> #2 0x00007fc70a88a769 in _nl_load_domain.cold () at /lib64/libc.so.6
> #3 0x00007fc70a899e76 in annobin_assert.c_end () at /lib64/libc.so.6
> #4 0x0000560953c2bfe0 in ppc4xx_pci_set_irq (opaque=0x560955dcf9a0,
> irq_num=-1, level=0) at hw/ppc/ppc4xx_pci.c:259
> #5 0x0000560953a20474 in pci_change_irq_level (pci_dev=0x560955dd0e40,
> irq_num=-1, change=0) at hw/pci/pci.c:262
> #6 0x0000560953a1d028 in pci_update_irq_disabled (d=0x560955dd0e40,
> was_irq_disabled=0) at hw/pci/pci.c:1375
> #7 0x0000560953a1ccb3 in pci_default_write_config (d=0x560955dd0e40,
> addr=4, val_in=1030, l=2) at hw/pci/pci.c:1415
> #8 0x0000560953978977 in pci_host_config_write_common
> (pci_dev=0x560955dd0e40, addr=4, limit=256, val=1030, len=2) at
> hw/pci/pci_host.c:83
> #9 0x0000560953978cb9 in pci_data_write (s=0x560955dd0210,
> addr=2147483652, val=1030, len=2) at hw/pci/pci_host.c:120
> #10 0x0000560953978eeb in pci_host_data_write (opaque=0x560955dcf350,
> addr=0, val=1030, len=2) at hw/pci/pci_host.c:167
>
> How can irq be -1? pci_update_irq_disabled() hasn't been updated
> since commit a7b15a5cc626 (2009-12-23):
>
> 1368 static void pci_update_irq_disabled(PCIDevice *d, int was_irq_disabled)
> 1369 {
> 1370 int i, disabled = pci_irq_disabled(d);
> 1371 if (disabled == was_irq_disabled)
> 1372 return;
> 1373 for (i = 0; i < PCI_NUM_PINS; ++i) {
> 1374 int state = pci_irq_state(d, i);
> 1375 pci_change_irq_level(d, i, disabled ? -state : state);
> 1376 }
> 1377 }
>
> Let's rebuild using --enable-sanitizers to check an overflow occured:
>
> 1286013@1610358549.342593:ppc4xx_pci_map_irq devfn 0x0 irq 0 -> 0
> =================================================================
> ==1286011==ERROR: AddressSanitizer: heap-buffer-overflow on address
> 0x60200004f78c at pc 0x55b6d738454c bp 0x7f779b9f7810 sp 0x7f779b9f7808
> READ of size 4 at 0x60200004f78c thread T2
> #0 0x55b6d738454b in pci_change_irq_level hw/pci/pci.c:261:29
> #1 0x55b6d73763be in pci_update_irq_disabled hw/pci/pci.c:1375:9
> #2 0x55b6d7374e2d in pci_default_write_config hw/pci/pci.c:1415:9
> #3 0x55b6d70cb8ec in pci_host_config_write_common hw/pci/pci_host.c:83:5
> #4 0x55b6d70cc43f in pci_data_write hw/pci/pci_host.c:120:5
> #5 0x55b6d70ccd43 in pci_host_data_write hw/pci/pci_host.c:167:9
> #6 0x55b6d8505348 in memory_region_write_accessor softmmu/memory.c:483:5
> #7 0x55b6d8504c1a in access_with_adjusted_size softmmu/memory.c:544:18
> #8 0x55b6d8503316 in memory_region_dispatch_write
> softmmu/memory.c:1465:16
> #9 0x55b6d878ab51 in flatview_write_continue exec.c:3177:23
> #10 0x55b6d8779046 in flatview_write exec.c:3217:14
> #11 0x55b6d879d1ab in subpage_write exec.c:2829:12
> #12 0x55b6d8505af7 in memory_region_write_with_attrs_accessor
> softmmu/memory.c:503:12
> #13 0x55b6d8504af4 in access_with_adjusted_size softmmu/memory.c:539:18
> #14 0x55b6d850376e in memory_region_dispatch_write
> softmmu/memory.c:1472:13
> #15 0x55b6d8485b60 in io_writex accel/tcg/cputlb.c:1121:9
> #16 0x55b6d845ef8b in store_helper accel/tcg/cputlb.c:2140:13
> #17 0x55b6d845f558 in helper_le_stw_mmu accel/tcg/cputlb.c:2194:5
> #18 0x7f77a40c0252 (<unknown module>)
>
> 0x60200004f78c is located 4 bytes to the left of 16-byte region
> [0x60200004f790,0x60200004f7a0)
> allocated by thread T0 here:
> #0 0x55b6d6ab9227 in calloc (qemu-system-ppc+0x1a9f227)
> #1 0x7f77f3ab19b0 in g_malloc0 (/lib64/libglib-2.0.so.0+0x589b0)
> #2 0x55b6d7370ef0 in pci_register_root_bus hw/pci/pci.c:493:5
> #3 0x55b6d7dec5de in ppc4xx_pcihost_realize hw/ppc/ppc4xx_pci.c:318:9
> #4 0x55b6d8a04ffb in device_set_realized hw/core/qdev.c:864:13
> #5 0x55b6d89309e8 in property_set_bool qom/object.c:2202:5
> #6 0x55b6d8928f92 in object_property_set qom/object.c:1349:5
> #7 0x55b6d891aa29 in object_property_set_qobject qom/qom-qobject.c:28:10
> #8 0x55b6d8929d71 in object_property_set_bool qom/object.c:1416:15
> #9 0x55b6d89f76fc in qdev_realize hw/core/qdev.c:379:12
> #10 0x55b6d89f7734 in qdev_realize_and_unref hw/core/qdev.c:386:11
> #11 0x55b6d7ccc37e in sysbus_realize_and_unref hw/core/sysbus.c:261:12
> #12 0x55b6d7ccc0a3 in sysbus_create_varargs hw/core/sysbus.c:236:5
> #13 0x55b6d7dbce60 in bamboo_init hw/ppc/ppc440_bamboo.c:212:11
> #14 0x55b6d6c3cdae in machine_run_board_init hw/core/machine.c:1144:5
> #15 0x55b6d86893ee in qemu_init softmmu/vl.c:4355:5
> #16 0x55b6d6af0f49 in main softmmu/main.c:49:5
> #17 0x7f77f23bd041 in __libc_start_main (/lib64/libc.so.6+0x27041)
>
> Thread T2 created by T0 here:
> #0 0x55b6d6a32bb6 in pthread_create (qemu-system-ppc+0x1a18bb6)
> #1 0x55b6d92a1df4 in qemu_thread_create util/qemu-thread-posix.c:558:11
> #2 0x55b6d8807dc5 in qemu_tcg_init_vcpu softmmu/cpus.c:1926:13
> #3 0x55b6d8807142 in qemu_init_vcpu softmmu/cpus.c:2047:9
> #4 0x55b6d7e79f88 in ppc_cpu_realize
> target/ppc/translate_init.c.inc:10146:5
> #5 0x55b6d8a04ffb in device_set_realized hw/core/qdev.c:864:13
> #6 0x55b6d89309e8 in property_set_bool qom/object.c:2202:5
> #7 0x55b6d8928f92 in object_property_set qom/object.c:1349:5
> #8 0x55b6d891aa29 in object_property_set_qobject qom/qom-qobject.c:28:10
> #9 0x55b6d8929d71 in object_property_set_bool qom/object.c:1416:15
> #10 0x55b6d89f76fc in qdev_realize hw/core/qdev.c:379:12
> #11 0x55b6d724d4db in cpu_create hw/core/cpu.c:62:10
> #12 0x55b6d7dbc024 in bamboo_init hw/ppc/ppc440_bamboo.c:183:11
> #13 0x55b6d6c3cdae in machine_run_board_init hw/core/machine.c:1144:5
> #14 0x55b6d86893ee in qemu_init softmmu/vl.c:4355:5
> #15 0x55b6d6af0f49 in main softmmu/main.c:49:5
> #16 0x7f77f23bd041 in __libc_start_main (/lib64/libc.so.6+0x27041)
>
> SUMMARY: AddressSanitizer: heap-buffer-overflow hw/pci/pci.c:261:29 in
> pci_change_irq_level
> Shadow bytes around the buggy address:
> 0x0c0480001ea0: fa fa fd fd fa fa fd fd fa fa 00 06 fa fa 00 02
> 0x0c0480001eb0: fa fa fd fd fa fa fd fd fa fa 00 06 fa fa 00 02
> 0x0c0480001ec0: fa fa fd fd fa fa fd fd fa fa 00 06 fa fa 00 02
> 0x0c0480001ed0: fa fa 00 00 fa fa 00 00 fa fa 00 01 fa fa 05 fa
> 0x0c0480001ee0: fa fa 06 fa fa fa fd fd fa fa 06 fa fa fa 00 03
> =>0x0c0480001ef0: fa[fa]00 00 fa fa fd fa fa fa fd fa fa fa fd fa
> 0x0c0480001f00: fa fa fd fa fa fa 00 01 fa fa fd fd fa fa fd fa
> 0x0c0480001f10: fa fa fd fd fa fa 00 02 fa fa fd fa fa fa 00 02
> 0x0c0480001f20: fa fa 05 fa fa fa 07 fa fa fa 00 01 fa fa 07 fa
> 0x0c0480001f30: fa fa 05 fa fa fa 07 fa fa fa fd fd fa fa 00 02
> 0x0c0480001f40: fa fa 05 fa fa fa 07 fa fa fa 00 01 fa fa 07 fa
> Shadow byte legend (one shadow byte represents 8 application bytes):
> Addressable: 00
> Partially addressable: 01 02 03 04 05 06 07
> Heap left redzone: fa
> Freed heap region: fd
> Stack left redzone: f1
> Stack mid redzone: f2
> Stack right redzone: f3
> Stack after return: f5
> Stack use after scope: f8
> Global redzone: f9
> Global init order: f6
> Poisoned by user: f7
> Container overflow: fc
> Array cookie: ac
> Intra object redzone: bb
> ASan internal: fe
> Left alloca redzone: ca
> Right alloca redzone: cb
> Shadow gap: cc
> ==1286011==ABORTING
>
> I see this sysbus_create_varargs() call in bamboo_init()
> has recently been updated by Peter in commit 0270d74ef88
> ("hw/ppc/ppc440_bamboo: Drop use of ppcuic_init()").
>
> Running with current master (7b09f127738) the assert is
> not reached:
>
> Linux version 5.11.0-rc3 (nathan@ubuntu-m3-large-x86) (powerpc-linux-gcc
> (GCC) 10.2.0, GNU ld (GNU Binutils) 2.35) #1 Sun Jan 10 15:52:24 MST 2021
> Using PowerPC 44x Platform machine description
> ioremap() called early from find_legacy_serial_ports+0x64c/0x794. Use
> early_ioremap() instead
> printk: bootconsole [udbg0] enabled
> -----------------------------------------------------
> phys_mem_size = 0x8000000
> dcache_bsize = 0x20
> icache_bsize = 0x20
> cpu_features = 0x0000000000000100
> possible = 0x0000000040000100
> always = 0x0000000000000100
> cpu_user_features = 0x8c008000 0x00000000
> mmu_features = 0x00000008
> -----------------------------------------------------
> Zone ranges:
> Normal [mem 0x0000000000000000-0x0000000007ffffff]
> Movable zone start for each node
> Early memory node ranges
> node 0: [mem 0x0000000000000000-0x0000000007ffffff]
> Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff]
> MMU: Allocated 1088 bytes of context maps for 255 contexts
> Built 1 zonelists, mobility grouping on. Total pages: 32448
> Kernel command line: console=ttyS0
> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear)
> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear)
> mem auto-init: stack:off, heap alloc:off, heap free:off
> Memory: 122712K/131072K available (5040K kernel code, 236K rwdata, 1260K
> rodata, 200K init, 134K bss, 8360K reserved, 0K cma-reserved)
> Kernel virtual memory layout:
> * 0xffbdf000..0xfffff000 : fixmap
> * 0xffbdd000..0xffbdf000 : early ioremap
> * 0xd1000000..0xffbdd000 : vmalloc & ioremap
> SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
> Oops: Exception in kernel mode, sig: 4 [#1]
> BE PAGE_SIZE=4K PowerPC 44x Platform
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper Not tainted 5.11.0-rc3 #1
> NIP: c0019e58 LR: c062e3a0 CTR: c0019e58
> REGS: c067fe90 TRAP: 0700 Not tainted (5.11.0-rc3)
> MSR: 000a1000 <CE,ME> CR: 84000224 XER: 20000000
>
> GPR00: c062e370 c067ff50 c065c300 c0019e58 00000000 c0019238 c067fde0
> c065c300
> GPR08: 00000000 00000000 c066fca4 00000066 84000222 00000000 00000000
> 00000000
> GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 c0000010
> 00000000
> GPR24: c0651594 c0651594 c0690000 c7ffe080 c0690000 c05c6f64 c0680000
> c0802100
> NIP [c0019e58] __mtdcr_table+0xc20/0x3ff8
> LR [c062e3a0] uic_init_one+0x13c/0x214
> Call Trace:
> [c067ff50] [c062e370] uic_init_one+0x10c/0x214 (unreliable)
> [c067ff80] [c062e4f8] uic_init_tree+0x80/0x174
> [c067ffb0] [c0627af8] start_kernel+0x33c/0x508
> [c067fff0] [c0000044] _start+0x44/0x88
> Instruction dump:
> 7c9f2b86 4e800020 7c603286 4e800020 7c803386 4e800020 7c613286 4e800020
> 7c813386 4e800020 7c623286 4e800020 <7c823386> 4e800020 7c633286 4e800020
> random: get_random_bytes called from oops_exit+0x44/0x84 with crng_init=0
> ---[ end trace 0000000000000000 ]---
>
> Kernel panic - not syncing: Attempted to kill the idle task!
> Rebooting in 180 seconds..
>
> I suppose we can end this thread as NOTABUG.
>
> Thanks for testing and your report,
>
> Phil.
For what it's worth, I initially ran into this assertion on v5.2.0,
which does not include Peter's commit since it is only in master (and
I reported a problem with separately). If they are indeed related then
fair enough :) thanks for taking a look.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: drivers/soc/litex/litex_soc_ctrl.c:143:34: warning: unused variable 'litex_soc_ctrl_of_match'
@ 2021-01-11 16:43 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-11 16:43 UTC (permalink / raw)
To: Stafford Horne
Cc: kernel test robot, Pawel Czarnecki, kbuild-all,
clang-built-linux, linux-kernel, Mateusz Holenko
On Mon, Jan 11, 2021 at 09:30:55PM +0900, Stafford Horne wrote:
> On Thu, Jan 07, 2021 at 04:04:47AM +0800, kernel test robot wrote:
> > Hi Pawel,
> >
> > FYI, the error/warning still remains.
> >
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > head: e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62
> > commit: 22447a99c97e353bde8f90c2353873f27681d57c drivers/soc/litex: add LiteX SoC Controller driver
> > date: 8 weeks ago
> > config: x86_64-randconfig-a001-20210107 (attached as .config)
> > compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 5c951623bc8965fa1e89660f2f5f4a2944e4981a)
> > reproduce (this is a W=1 build):
> > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # install x86_64 cross compiling tool for clang build
> > # apt-get install binutils-x86-64-linux-gnu
> > # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=22447a99c97e353bde8f90c2353873f27681d57c
> > git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > git fetch --no-tags linus master
> > git checkout 22447a99c97e353bde8f90c2353873f27681d57c
> > # save the attached .config to linux build tree
> > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
> >
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot <lkp@intel.com>
> >
> > All warnings (new ones prefixed by >>):
> >
> > >> drivers/soc/litex/litex_soc_ctrl.c:143:34: warning: unused variable 'litex_soc_ctrl_of_match' [-Wunused-const-variable]
> > static const struct of_device_id litex_soc_ctrl_of_match[] = {
> > ^
> > 1 warning generated.
> >
> >
> > vim +/litex_soc_ctrl_of_match +143 drivers/soc/litex/litex_soc_ctrl.c
> >
> > 142
> > > 143 static const struct of_device_id litex_soc_ctrl_of_match[] = {
> > 144 {.compatible = "litex,soc-controller"},
> > 145 {},
> > 146 };
> > 147
> >
>
> I don't use clang but GCC, and I cannot reproduce this warning.
>
> $ make drivers/soc/litex/litex_soc_ctrl.o
> CALL scripts/checksyscalls.sh
> CALL scripts/atomic/check-atomics.sh
> DESCEND objtool
> CC drivers/soc/litex/litex_soc_ctrl.o
>
> Also, I can see litex_soc_ctrl_of_match is used. I am not sure what is going on
> here.
>
> -Stafford
>
You need W=1
$ make -skj"$(nproc)" W=1 olddefconfig drivers/soc/litex/litex_soc_ctrl.o
drivers/soc/litex/litex_soc_ctrl.c:143:34: warning: ‘litex_soc_ctrl_of_match’ defined but not used [-Wunused-const-variable=]
143 | static const struct of_device_id litex_soc_ctrl_of_match[] = {
| ^~~~~~~~~~~~~~~~~~~~~~~
$ rg "CONFIG_OF|CONFIG_LITEX_SOC_CONTROLLER" .config
1124:# CONFIG_OF is not set
4673:CONFIG_LITEX_SOC_CONTROLLER=y
This variable is used in two places in that file, in the
MODULE_DEVICE_TABLE macro and the of_match_ptr macro. When CONFIG_OF is
disabled, of_match_ptr evaluates to NULL. When the file is built into
the kernel image, MODULE_DEVICE_TABLE evaluates to nothing, leaving this
variable defined but unused in the final preprocessed source.
Hope that helps!
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH mips-fixes] MIPS: relocatable: fix possible boot hangup with KASLR enabled
@ 2021-01-11 5:21 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-11 5:21 UTC (permalink / raw)
To: Alexander Lobakin
Cc: Thomas Bogendoerfer, Nick Desaulniers, Kees Cook, Jinyang He,
Ralf Baechle, Matt Redfearn, linux-mips, stable, linux-kernel,
clang-built-linux
On Sun, Jan 10, 2021 at 02:21:05PM +0000, Alexander Lobakin wrote:
> LLVM-built Linux triggered a boot hangup with KASLR enabled.
>
> arch/mips/kernel/relocate.c:get_random_boot() uses linux_banner,
> which is a string constant, as a random seed, but accesses it
> as an array of unsigned long (in rotate_xor()).
> When the address of linux_banner is not aligned to sizeof(long),
> such access emits unaligned access exception and hangs the kernel.
>
> Use PTR_ALIGN() to align input address to sizeof(long) and also
> align down the input length to prevent possible access-beyond-end.
>
> Fixes: 405bc8fd12f5 ("MIPS: Kernel: Implement KASLR using CONFIG_RELOCATABLE")
> Cc: stable@vger.kernel.org # 4.7+
> Signed-off-by: Alexander Lobakin <alobakin@pm.me>
Apologies for not being familiar enough with the issue to give a review
but I did reproduce the hang that the commit mentions with
malta_kvm_guest_defconfig + CONFIG_RELOCATABLE=y +
CONFIG_RANDOMIZE_BASE=y and this patch does resolve it so:
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> arch/mips/kernel/relocate.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/mips/kernel/relocate.c b/arch/mips/kernel/relocate.c
> index 47aeb3350a76..0e365b7c742d 100644
> --- a/arch/mips/kernel/relocate.c
> +++ b/arch/mips/kernel/relocate.c
> @@ -187,8 +187,14 @@ static int __init relocate_exception_table(long offset)
> static inline __init unsigned long rotate_xor(unsigned long hash,
> const void *area, size_t size)
> {
> - size_t i;
> - unsigned long *ptr = (unsigned long *)area;
> + const typeof(hash) *ptr = PTR_ALIGN(area, sizeof(hash));
> + size_t diff, i;
> +
> + diff = (void *)ptr - area;
> + if (unlikely(size < diff + sizeof(hash)))
> + return hash;
> +
> + size = ALIGN_DOWN(size - diff, sizeof(hash));
>
> for (i = 0; i < size / sizeof(hash); i++) {
> /* Rotate by odd number of bits and XOR. */
> --
> 2.30.0
>
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] block/rnbd-clt: improve find_or_create_sess() return check
@ 2021-01-11 5:14 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-11 5:14 UTC (permalink / raw)
To: trix
Cc: danil.kipnis, jinpu.wang, axboe, ndesaulniers, linux-block,
linux-kernel, clang-built-linux
On Sun, Jan 10, 2021 at 01:57:26PM -0800, trix@redhat.com wrote:
> From: Tom Rix <trix@redhat.com>
>
> clang static analysis reports this problem
>
> rnbd-clt.c:1212:11: warning: Branch condition evaluates to a
> garbage value
> else if (!first)
> ^~~~~~
Ah, is it complaining that the 'if (IS_ERR(sess)) {' section in
find_or_create_sess() does not initialize first even though that will be
caught by the 'if (sess == ERR_PTR(-ENOMEM))' in
find_and_get_or_create_sess() because alloc_sess() only returns an
-ENOMEM error pointer?
> This is triggered in the find_and_get_or_create_sess() call
> because the variable first is not initialized and the
> earlier check is specifically for
>
> if (sess == ERR_PTR(-ENOMEM))
>
> This is false positive.
>
> But the if-check can be reduced by initializing first to
> false and then returning if the call to find_or_creat_sess()
> does not set it to true. When it remains false, either
> sess will be valid or not. The not case is caught by
> find_and_get_or_create_sess()'s caller rnbd_clt_map_device()
>
> sess = find_and_get_or_create_sess(...);
> if (IS_ERR(sess))
> return ERR_CAST(sess);
>
> Since find_and_get_or_create_sess() initializes first to false
> setting it in find_or_create_sess() is not needed.
>
> Signed-off-by: Tom Rix <trix@redhat.com>
Every maintainer has their preference for where and how stuff gets
initialized but this makes sense to me. I am not sure the commit above
find_or_create_sess() is needed but again, personal preference.
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> drivers/block/rnbd/rnbd-clt.c | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/block/rnbd/rnbd-clt.c b/drivers/block/rnbd/rnbd-clt.c
> index 96e3f9fe8241..251f747cf10d 100644
> --- a/drivers/block/rnbd/rnbd-clt.c
> +++ b/drivers/block/rnbd/rnbd-clt.c
> @@ -919,6 +919,7 @@ static struct rnbd_clt_session *__find_and_get_sess(const char *sessname)
> return NULL;
> }
>
> +/* caller is responsible for initializing 'first' to false */
> static struct
> rnbd_clt_session *find_or_create_sess(const char *sessname, bool *first)
> {
> @@ -934,8 +935,7 @@ rnbd_clt_session *find_or_create_sess(const char *sessname, bool *first)
> }
> list_add(&sess->list, &sess_list);
> *first = true;
> - } else
> - *first = false;
> + }
> mutex_unlock(&sess_lock);
>
> return sess;
> @@ -1203,13 +1203,11 @@ find_and_get_or_create_sess(const char *sessname,
> struct rnbd_clt_session *sess;
> struct rtrs_attrs attrs;
> int err;
> - bool first;
> + bool first = false;
> struct rtrs_clt_ops rtrs_ops;
>
> sess = find_or_create_sess(sessname, &first);
> - if (sess == ERR_PTR(-ENOMEM))
> - return ERR_PTR(-ENOMEM);
> - else if (!first)
> + if (!first)
> return sess;
>
> if (!path_cnt) {
> --
> 2.27.0
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH v5 mips-next 8/9] vmlinux.lds.h: catch UBSAN's "unnamed data" into data
@ 2021-01-11 2:05 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-11 2:05 UTC (permalink / raw)
To: Alexander Lobakin
Cc: Thomas Bogendoerfer, Arnd Bergmann, Nick Desaulniers,
Huacai Chen, Pei Huang, Kees Cook, Fangrui Song, Jiaxun Yang,
Ralf Baechle, Corey Minyard, linux-mips, linux-kernel,
linux-arch, stable, clang-built-linux
On Sun, Jan 10, 2021 at 11:56:54AM +0000, Alexander Lobakin wrote:
> When building kernel with both LD_DEAD_CODE_DATA_ELIMINATION and
> UBSAN, LLVM stack generates lots of "unnamed data" sections:
>
> ld.lld: warning: net/built-in.a(netfilter/utils.o): (.data.$__unnamed_2)
> is being placed in '.data.$__unnamed_2'
> ld.lld: warning: net/built-in.a(netfilter/utils.o): (.data.$__unnamed_3)
> is being placed in '.data.$__unnamed_3'
> ld.lld: warning: net/built-in.a(netfilter/utils.o): (.data.$__unnamed_4)
> is being placed in '.data.$__unnamed_4'
> ld.lld: warning: net/built-in.a(netfilter/utils.o): (.data.$__unnamed_5)
> is being placed in '.data.$__unnamed_5'
>
> [...]
>
> Also handle this by adding the related sections to generic definitions.
>
> Signed-off-by: Alexander Lobakin <alobakin@pm.me>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> include/asm-generic/vmlinux.lds.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index 5f2f5b1db84f..cc659e77fcb0 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -95,7 +95,7 @@
> */
> #ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
> #define TEXT_MAIN .text .text.[0-9a-zA-Z_]*
> -#define DATA_MAIN .data .data.[0-9a-zA-Z_]* .data..L* .data..compoundliteral*
> +#define DATA_MAIN .data .data.[0-9a-zA-Z_]* .data..L* .data..compoundliteral* .data.$__unnamed_*
> #define SDATA_MAIN .sdata .sdata.[0-9a-zA-Z_]*
> #define RODATA_MAIN .rodata .rodata.[0-9a-zA-Z_]* .rodata..L*
> #define BSS_MAIN .bss .bss.[0-9a-zA-Z_]* .bss..compoundliteral*
> --
> 2.30.0
>
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH v5 mips-next 5/9] MIPS: vmlinux.lds.S: explicitly catch .rel.dyn symbols
@ 2021-01-11 1:28 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-11 1:28 UTC (permalink / raw)
To: Alexander Lobakin
Cc: Thomas Bogendoerfer, Arnd Bergmann, Nick Desaulniers,
Huacai Chen, Pei Huang, Kees Cook, Fangrui Song, Jiaxun Yang,
Ralf Baechle, Corey Minyard, linux-mips, linux-kernel,
linux-arch, stable, clang-built-linux
On Sun, Jan 10, 2021 at 11:56:34AM +0000, Alexander Lobakin wrote:
> According to linker warnings, both GCC and LLVM generate '.rel.dyn'
> symbols:
>
> mips-alpine-linux-musl-ld: warning: orphan section `.rel.dyn'
> from `init/main.o' being placed in section `.rel.dyn'
>
> Link-time assertion shows that this section is sometimes empty,
> sometimes not, depending on machine bitness and the compiler [0]:
>
> LD .tmp_vmlinux.kallsyms1
> mips64-linux-gnu-ld: Unexpected run-time relocations (.rel) detected!
>
> Just use the ARM64 approach and declare it in vmlinux.lds.S closer
> to __init_end.
>
> [0] https://lore.kernel.org/linux-mips/20210109111259.GA4213@alpha.franken.de
>
> Reported-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Signed-off-by: Alexander Lobakin <alobakin@pm.me>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> arch/mips/kernel/vmlinux.lds.S | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S
> index 10d8f0dcb76b..70bba1ff08da 100644
> --- a/arch/mips/kernel/vmlinux.lds.S
> +++ b/arch/mips/kernel/vmlinux.lds.S
> @@ -137,6 +137,11 @@ SECTIONS
> PERCPU_SECTION(1 << CONFIG_MIPS_L1_CACHE_SHIFT)
> #endif
>
> + .rel.dyn : ALIGN(8) {
> + *(.rel)
> + *(.rel*)
> + }
> +
> #ifdef CONFIG_MIPS_ELF_APPENDED_DTB
> .appended_dtb : AT(ADDR(.appended_dtb) - LOAD_OFFSET) {
> *(.appended_dtb)
> --
> 2.30.0
>
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH 4/5] hw/ppc/ppc4xx_pci: Replace pointless warning by assert()
@ 2021-01-11 1:11 82% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2021-01-11 1:11 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Peter Maydell, Aleksandar Rikalo, qemu-trivial, Mark Cave-Ayland,
qemu-devel, Aleksandar Markovic, qemu-arm, qemu-ppc, Huacai Chen,
Philippe Mathieu-Daudé,
Aurelien Jarno, David Gibson
On Tue, Sep 01, 2020 at 12:40:42PM +0200, Philippe Mathieu-Daudé wrote:
> We call pci_register_root_bus() to register 4 IRQs with the
> ppc4xx_pci_set_irq() handler. As it can only be called with
> values in the [0-4[ range, replace the pointless warning by
> an assert().
>
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
> hw/ppc/ppc4xx_pci.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/hw/ppc/ppc4xx_pci.c b/hw/ppc/ppc4xx_pci.c
> index cd3f192a138..503ef46b39a 100644
> --- a/hw/ppc/ppc4xx_pci.c
> +++ b/hw/ppc/ppc4xx_pci.c
> @@ -256,10 +256,7 @@ static void ppc4xx_pci_set_irq(void *opaque, int irq_num, int level)
> qemu_irq *pci_irqs = opaque;
>
> trace_ppc4xx_pci_set_irq(irq_num);
> - if (irq_num < 0) {
> - fprintf(stderr, "%s: PCI irq %d\n", __func__, irq_num);
> - return;
> - }
> + assert(irq_num >= 0);
> qemu_set_irq(pci_irqs[irq_num], level);
> }
>
> --
> 2.26.2
>
>
Hopefully reporting this here is okay, I find Launchpad hard to use but
I can file it there if need be.
The assertion added by this patch triggers while trying to boot a
ppc44x_defconfig Linux kernel:
$ qemu-system-ppc \
-machine bamboo \
-no-reboot \
-append console=ttyS0 \
-display none \
-kernel uImage \
-m 128m \
-nodefaults \
-serial mon:stdio
Linux version 5.11.0-rc3 (nathan@ubuntu-m3-large-x86) (powerpc-linux-gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.35) #1 Sun Jan 10 15:52:24 MST 2021
Using PowerPC 44x Platform machine description
ioremap() called early from find_legacy_serial_ports+0x64c/0x794. Use early_ioremap() instead
printk: bootconsole [udbg0] enabled
-----------------------------------------------------
phys_mem_size = 0x8000000
dcache_bsize = 0x20
icache_bsize = 0x20
cpu_features = 0x0000000000000100
possible = 0x0000000040000100
always = 0x0000000000000100
cpu_user_features = 0x8c008000 0x00000000
mmu_features = 0x00000008
-----------------------------------------------------
Zone ranges:
Normal [mem 0x0000000000000000-0x0000000007ffffff]
Movable zone start for each node
Early memory node ranges
node 0: [mem 0x0000000000000000-0x0000000007ffffff]
Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff]
MMU: Allocated 1088 bytes of context maps for 255 contexts
Built 1 zonelists, mobility grouping on. Total pages: 32448
Kernel command line: console=ttyS0
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear)
mem auto-init: stack:off, heap alloc:off, heap free:off
Memory: 122712K/131072K available (5040K kernel code, 236K rwdata, 1260K rodata, 200K init, 134K bss, 8360K reserved, 0K cma-reserved)
Kernel virtual memory layout:
* 0xffbdf000..0xfffff000 : fixmap
* 0xffbdd000..0xffbdf000 : early ioremap
* 0xd1000000..0xffbdd000 : vmalloc & ioremap
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
UIC0 (32 IRQ sources) at DCR 0xc0
random: get_random_u32 called from start_kernel+0x370/0x508 with crng_init=0
clocksource: timebase: mask: 0xffffffffffffffff max_cycles: 0x5c4093a7d1, max_idle_ns: 440795210635 ns
clocksource: timebase mult[2800000] shift[24] registered
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
futex hash table entries: 256 (order: -1, 3072 bytes, linear)
NET: Registered protocol family 16
DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations
PCI host bridge /plb/pci@ec000000 (primary) ranges:
MEM 0x00000000a0000000..0x00000000bfffffff -> 0x00000000a0000000
IO 0x00000000e8000000..0x00000000e800ffff -> 0x0000000000000000
4xx PCI DMA offset set to 0x00000000
4xx PCI DMA window base to 0x0000000000000000
DMA window size 0x0000000080000000
PCI: Probing PCI hardware
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x0000-0xffff]
pci_bus 0000:00: root bus resource [mem 0xa0000000-0xbfffffff]
pci_bus 0000:00: root bus resource [bus 00-ff]
pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to ff
pci 0000:00:00.0: [1014:027f] type 00 class 0x068000
qemu-system-ppc: ../hw/ppc/ppc4xx_pci.c:259: ppc4xx_pci_set_irq: Assertion `irq_num >= 0' failed.
On v5.2.0, it looks like a higher assertion triggers, added by
commit 459ca8bfa4 ("pci: Assert irqnum is between 0 and bus->nirqs in
pci_bus_change_irq_level").
qemu-system-ppc: ../hw/pci/pci.c:253: pci_bus_change_irq_level: Assertion `irq_num >= 0' failed.
I have uploaded the kernel image here:
https://github.com/nathanchance/bug-files/blob/8edf230441bd8eda067973fdf0eb063c94f04379/qemu-0270d74ef886235051c13c39b0de88500c628a02/uImage
Cheers,
Nathan
^ permalink raw reply [relevance 82%]
* Re: [PATCH 4/8] hw/ppc/ppc440_bamboo: Drop use of ppcuic_init()
@ 2021-01-11 1:00 86% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-11 1:00 UTC (permalink / raw)
To: Peter Maydell; +Cc: Edgar E. Iglesias, qemu-ppc, qemu-devel, David Gibson
On Sat, Dec 12, 2020 at 12:15:33AM +0000, Peter Maydell wrote:
> Switch the bamboo board to directly creating and configuring the UIC,
> rather than doing it via the old ppcuic_init() helper function.
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> hw/ppc/ppc440_bamboo.c | 38 +++++++++++++++++++++++++++-----------
> 1 file changed, 27 insertions(+), 11 deletions(-)
>
> diff --git a/hw/ppc/ppc440_bamboo.c b/hw/ppc/ppc440_bamboo.c
> index 665bc1784e1..b156bcb9990 100644
> --- a/hw/ppc/ppc440_bamboo.c
> +++ b/hw/ppc/ppc440_bamboo.c
> @@ -33,6 +33,9 @@
> #include "sysemu/qtest.h"
> #include "sysemu/reset.h"
> #include "hw/sysbus.h"
> +#include "hw/intc/ppc-uic.h"
> +#include "hw/qdev-properties.h"
> +#include "qapi/error.h"
>
> #define BINARY_DEVICE_TREE_FILE "bamboo.dtb"
>
> @@ -168,13 +171,13 @@ static void bamboo_init(MachineState *machine)
> MemoryRegion *ram_memories = g_new(MemoryRegion, PPC440EP_SDRAM_NR_BANKS);
> hwaddr ram_bases[PPC440EP_SDRAM_NR_BANKS];
> hwaddr ram_sizes[PPC440EP_SDRAM_NR_BANKS];
> - qemu_irq *pic;
> - qemu_irq *irqs;
> PCIBus *pcibus;
> PowerPCCPU *cpu;
> CPUPPCState *env;
> target_long initrd_size = 0;
> DeviceState *dev;
> + DeviceState *uicdev;
> + SysBusDevice *uicsbd;
> int success;
> int i;
>
> @@ -192,10 +195,17 @@ static void bamboo_init(MachineState *machine)
> ppc_dcr_init(env, NULL, NULL);
>
> /* interrupt controller */
> - irqs = g_new0(qemu_irq, PPCUIC_OUTPUT_NB);
> - irqs[PPCUIC_OUTPUT_INT] = ((qemu_irq *)env->irq_inputs)[PPC40x_INPUT_INT];
> - irqs[PPCUIC_OUTPUT_CINT] = ((qemu_irq *)env->irq_inputs)[PPC40x_INPUT_CINT];
> - pic = ppcuic_init(env, irqs, 0x0C0, 0, 1);
> + uicdev = qdev_new(TYPE_PPC_UIC);
> + uicsbd = SYS_BUS_DEVICE(uicdev);
> +
> + object_property_set_link(OBJECT(uicdev), "cpu", OBJECT(cpu),
> + &error_fatal);
> + sysbus_realize_and_unref(uicsbd, &error_fatal);
> +
> + sysbus_connect_irq(uicsbd, PPCUIC_OUTPUT_INT,
> + ((qemu_irq *)env->irq_inputs)[PPC40x_INPUT_INT]);
> + sysbus_connect_irq(uicsbd, PPCUIC_OUTPUT_CINT,
> + ((qemu_irq *)env->irq_inputs)[PPC40x_INPUT_CINT]);
>
> /* SDRAM controller */
> memset(ram_bases, 0, sizeof(ram_bases));
> @@ -203,14 +213,18 @@ static void bamboo_init(MachineState *machine)
> ppc4xx_sdram_banks(machine->ram, PPC440EP_SDRAM_NR_BANKS, ram_memories,
> ram_bases, ram_sizes, ppc440ep_sdram_bank_sizes);
> /* XXX 440EP's ECC interrupts are on UIC1, but we've only created UIC0. */
> - ppc4xx_sdram_init(env, pic[14], PPC440EP_SDRAM_NR_BANKS, ram_memories,
> + ppc4xx_sdram_init(env,
> + qdev_get_gpio_in(uicdev, 14),
> + PPC440EP_SDRAM_NR_BANKS, ram_memories,
> ram_bases, ram_sizes, 1);
>
> /* PCI */
> dev = sysbus_create_varargs(TYPE_PPC4xx_PCI_HOST_BRIDGE,
> PPC440EP_PCI_CONFIG,
> - pic[pci_irq_nrs[0]], pic[pci_irq_nrs[1]],
> - pic[pci_irq_nrs[2]], pic[pci_irq_nrs[3]],
> + qdev_get_gpio_in(uicdev, pci_irq_nrs[0]),
> + qdev_get_gpio_in(uicdev, pci_irq_nrs[1]),
> + qdev_get_gpio_in(uicdev, pci_irq_nrs[2]),
> + qdev_get_gpio_in(uicdev, pci_irq_nrs[3]),
> NULL);
> pcibus = (PCIBus *)qdev_get_child_bus(dev, "pci.0");
> if (!pcibus) {
> @@ -223,12 +237,14 @@ static void bamboo_init(MachineState *machine)
> memory_region_add_subregion(get_system_memory(), PPC440EP_PCI_IO, isa);
>
> if (serial_hd(0) != NULL) {
> - serial_mm_init(address_space_mem, 0xef600300, 0, pic[0],
> + serial_mm_init(address_space_mem, 0xef600300, 0,
> + qdev_get_gpio_in(uicdev, 0),
> PPC_SERIAL_MM_BAUDBASE, serial_hd(0),
> DEVICE_BIG_ENDIAN);
> }
> if (serial_hd(1) != NULL) {
> - serial_mm_init(address_space_mem, 0xef600400, 0, pic[1],
> + serial_mm_init(address_space_mem, 0xef600400, 0,
> + qdev_get_gpio_in(uicdev, 1),
> PPC_SERIAL_MM_BAUDBASE, serial_hd(1),
> DEVICE_BIG_ENDIAN);
> }
> --
> 2.20.1
>
>
Hopefully reporting this here is okay, I find Launchpad hard to use but
I can file it there if need be.
This patch causes a panic while trying to boot a ppc44x_defconfig Linux
kernel:
$ qemu-system-ppc \
-machine bamboo \
-no-reboot \
-append console=ttyS0 \
-display none \
-kernel uImage \
-m 128m \
-nodefaults \
-serial mon:stdio
Linux version 5.11.0-rc3 (nathan@ubuntu-m3-large-x86) (powerpc-linux-gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.35) #1 Sun Jan 10 15:52:24 MST 2021
Using PowerPC 44x Platform machine description
ioremap() called early from find_legacy_serial_ports+0x64c/0x794. Use early_ioremap() instead
printk: bootconsole [udbg0] enabled
-----------------------------------------------------
phys_mem_size = 0x8000000
dcache_bsize = 0x20
icache_bsize = 0x20
cpu_features = 0x0000000000000100
possible = 0x0000000040000100
always = 0x0000000000000100
cpu_user_features = 0x8c008000 0x00000000
mmu_features = 0x00000008
-----------------------------------------------------
Zone ranges:
Normal [mem 0x0000000000000000-0x0000000007ffffff]
Movable zone start for each node
Early memory node ranges
node 0: [mem 0x0000000000000000-0x0000000007ffffff]
Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff]
MMU: Allocated 1088 bytes of context maps for 255 contexts
Built 1 zonelists, mobility grouping on. Total pages: 32448
Kernel command line: console=ttyS0
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear)
mem auto-init: stack:off, heap alloc:off, heap free:off
Memory: 122712K/131072K available (5040K kernel code, 236K rwdata, 1260K rodata, 200K init, 134K bss, 8360K reserved, 0K cma-reserved)
Kernel virtual memory layout:
* 0xffbdf000..0xfffff000 : fixmap
* 0xffbdd000..0xffbdf000 : early ioremap
* 0xd1000000..0xffbdd000 : vmalloc & ioremap
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
Oops: Exception in kernel mode, sig: 4 [#1]
BE PAGE_SIZE=4K PowerPC 44x Platform
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 5.11.0-rc3 #1
NIP: c0019e58 LR: c062e3a0 CTR: c0019e58
REGS: c067fe90 TRAP: 0700 Not tainted (5.11.0-rc3)
MSR: 000a1000 <CE,ME> CR: 84000224 XER: 20000000
GPR00: c062e370 c067ff50 c065c300 c0019e58 00000000 c0019238 c067fde0 c065c300
GPR08: 00000000 00000000 c066fca4 00000066 84000222 00000000 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 c0000010 00000000
GPR24: c0651594 c0651594 c0690000 c7ffe080 c0690000 c05c6f64 c0680000 c0802100
NIP [c0019e58] __mtdcr_table+0xc20/0x3ff8
LR [c062e3a0] uic_init_one+0x13c/0x214
Call Trace:
[c067ff50] [c062e370] uic_init_one+0x10c/0x214 (unreliable)
[c067ff80] [c062e4f8] uic_init_tree+0x80/0x174
[c067ffb0] [c0627af8] start_kernel+0x33c/0x508
[c067fff0] [c0000044] _start+0x44/0x88
Instruction dump:
7c9f2b86 4e800020 7c603286 4e800020 7c803386 4e800020 7c613286 4e800020
7c813386 4e800020 7c623286 4e800020 <7c823386> 4e800020 7c633286 4e800020
random: get_random_bytes called from oops_exit+0x44/0x84 with crng_init=0
---[ end trace 0000000000000000 ]---
Kernel panic - not syncing: Attempted to kill the idle task!
Rebooting in 180 seconds..
I have uploaded the kernel image here:
https://github.com/nathanchance/bug-files/blob/8edf230441bd8eda067973fdf0eb063c94f04379/qemu-0270d74ef886235051c13c39b0de88500c628a02/uImage
Do note that this is not the only commit that causes an issue on this
machine, there is also a few assertion failures which I am about to
report as well.
Cheers,
Nathan
^ permalink raw reply [relevance 86%]
* Re: [PATCH v4 mips-next 7/7] MIPS: select ARCH_WANT_LD_ORPHAN_WARN
@ 2021-01-08 21:19 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-08 21:19 UTC (permalink / raw)
To: Alexander Lobakin
Cc: Thomas Bogendoerfer, Arnd Bergmann, Kees Cook, Nick Desaulniers,
Fangrui Song, Huacai Chen, Pei Huang, Jiaxun Yang, Sami Tolvanen,
Ingo Molnar, Ralf Baechle, Corey Minyard, linux-mips,
linux-kernel, linux-arch, stable, clang-built-linux
On Thu, Jan 07, 2021 at 01:21:02PM +0000, Alexander Lobakin wrote:
> Now, after that all the sections are explicitly described and
> declared in vmlinux.lds.S, we can enable ld orphan warnings to
> prevent from missing any new sections in future.
>
> Signed-off-by: Alexander Lobakin <alobakin@pm.me>
> Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> arch/mips/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index d68df1febd25..d3e64cc0932b 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -18,6 +18,7 @@ config MIPS
> select ARCH_USE_QUEUED_SPINLOCKS
> select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
> select ARCH_WANT_IPC_PARSE_VERSION
> + select ARCH_WANT_LD_ORPHAN_WARN
> select BUILDTIME_TABLE_SORT
> select CLONE_BACKWARDS
> select CPU_NO_EFFICIENT_FFS if (TARGET_ISA_REV < 1)
> --
> 2.30.0
>
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH v4 mips-next 6/7] vmlinux.lds.h: catch compound literals into data and BSS
@ 2021-01-08 21:19 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-08 21:19 UTC (permalink / raw)
To: Alexander Lobakin
Cc: Thomas Bogendoerfer, Arnd Bergmann, Kees Cook, Nick Desaulniers,
Fangrui Song, Huacai Chen, Pei Huang, Jiaxun Yang, Sami Tolvanen,
Ingo Molnar, Ralf Baechle, Corey Minyard, linux-mips,
linux-kernel, linux-arch, stable, clang-built-linux
On Thu, Jan 07, 2021 at 01:20:55PM +0000, Alexander Lobakin wrote:
> When building kernel with LD_DEAD_CODE_DATA_ELIMINATION, LLVM stack
> generates separate sections for compound literals, just like in case
> with enabled LTO [0]:
>
> ld.lld: warning: drivers/built-in.a(mtd/nand/spi/gigadevice.o):
> (.data..compoundliteral.14) is being placed in
> '.data..compoundliteral.14'
> ld.lld: warning: drivers/built-in.a(mtd/nand/spi/gigadevice.o):
> (.data..compoundliteral.15) is being placed in
> '.data..compoundliteral.15'
> ld.lld: warning: drivers/built-in.a(mtd/nand/spi/gigadevice.o):
> (.data..compoundliteral.16) is being placed in
> '.data..compoundliteral.16'
> ld.lld: warning: drivers/built-in.a(mtd/nand/spi/gigadevice.o):
> (.data..compoundliteral.17) is being placed in
> '.data..compoundliteral.17'
>
> [...]
>
> Handle this by adding the related sections to generic definitions
> as suggested by Sami [0].
>
> [0] https://lore.kernel.org/lkml/20201211184633.3213045-3-samitolvanen@google.com
>
> Suggested-by: Kees Cook <keescook@chromium.org>
> Signed-off-by: Alexander Lobakin <alobakin@pm.me>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> include/asm-generic/vmlinux.lds.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index b2b3d81b1535..5f2f5b1db84f 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -95,10 +95,10 @@
> */
> #ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
> #define TEXT_MAIN .text .text.[0-9a-zA-Z_]*
> -#define DATA_MAIN .data .data.[0-9a-zA-Z_]* .data..LPBX*
> +#define DATA_MAIN .data .data.[0-9a-zA-Z_]* .data..L* .data..compoundliteral*
> #define SDATA_MAIN .sdata .sdata.[0-9a-zA-Z_]*
> -#define RODATA_MAIN .rodata .rodata.[0-9a-zA-Z_]*
> -#define BSS_MAIN .bss .bss.[0-9a-zA-Z_]*
> +#define RODATA_MAIN .rodata .rodata.[0-9a-zA-Z_]* .rodata..L*
> +#define BSS_MAIN .bss .bss.[0-9a-zA-Z_]* .bss..compoundliteral*
> #define SBSS_MAIN .sbss .sbss.[0-9a-zA-Z_]*
> #else
> #define TEXT_MAIN .text
> --
> 2.30.0
>
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH v4 mips-next 5/7] MIPS: vmlinux.lds.S: explicitly declare .got table
@ 2021-01-08 21:17 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-08 21:17 UTC (permalink / raw)
To: Alexander Lobakin
Cc: Thomas Bogendoerfer, Arnd Bergmann, Kees Cook, Nick Desaulniers,
Fangrui Song, Huacai Chen, Pei Huang, Jiaxun Yang, Sami Tolvanen,
Ingo Molnar, Ralf Baechle, Corey Minyard, linux-mips,
linux-kernel, linux-arch, stable, clang-built-linux
On Thu, Jan 07, 2021 at 01:20:49PM +0000, Alexander Lobakin wrote:
> LLVM stack generates GOT table when building the kernel:
>
> ld.lld: warning: <internal>:(.got) is being placed in '.got'
>
> According to the debug assertions, it's not zero-sized and thus
> can't be handled the same way as .rel.dyn (like it's done for x86).
> Use the ARM/ARM64 path here and place it at the end of .text section.
>
> Reported-by: Nathan Chancellor <natechancellor@gmail.com>
> Signed-off-by: Alexander Lobakin <alobakin@pm.me>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> arch/mips/kernel/vmlinux.lds.S | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S
> index 0f736d60d43e..4709959f6985 100644
> --- a/arch/mips/kernel/vmlinux.lds.S
> +++ b/arch/mips/kernel/vmlinux.lds.S
> @@ -69,6 +69,7 @@ SECTIONS
> *(.text.*)
> *(.fixup)
> *(.gnu.warning)
> + *(.got)
> } :text = 0
> _etext = .; /* End of text section */
>
> --
> 2.30.0
>
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH v4 mips-next 4/7] MIPS: vmlinux.lds.S: catch bad .rel.dyn at link time
` (2 preceding siblings ...)
@ 2021-01-08 21:17 99% ` Nathan Chancellor
3 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-08 21:17 UTC (permalink / raw)
To: Alexander Lobakin
Cc: Thomas Bogendoerfer, Arnd Bergmann, Kees Cook, Nick Desaulniers,
Fangrui Song, Huacai Chen, Pei Huang, Jiaxun Yang, Sami Tolvanen,
Ingo Molnar, Ralf Baechle, Corey Minyard, linux-mips,
linux-kernel, linux-arch, stable, clang-built-linux
On Thu, Jan 07, 2021 at 01:20:33PM +0000, Alexander Lobakin wrote:
> Catch any symbols placed in .rel.dyn and check for these sections
> to be zero-sized at link time.
> Eliminates following ld warning:
>
> mips-alpine-linux-musl-ld: warning: orphan section `.rel.dyn'
> from `init/main.o' being placed in section `.rel.dyn'
>
> Adopted from x86/kernel/vmlinux.lds.S.
>
> Suggested-by: Fangrui Song <maskray@google.com>
> Signed-off-by: Alexander Lobakin <alobakin@pm.me>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> arch/mips/kernel/vmlinux.lds.S | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S
> index 0f4e46ea4458..0f736d60d43e 100644
> --- a/arch/mips/kernel/vmlinux.lds.S
> +++ b/arch/mips/kernel/vmlinux.lds.S
> @@ -226,4 +226,15 @@ SECTIONS
> *(.pdr)
> *(.reginfo)
> }
> +
> + /*
> + * Sections that should stay zero sized, which is safer to
> + * explicitly check instead of blindly discarding.
> + */
> +
> + .rel.dyn : {
> + *(.rel.*)
> + *(.rel_*)
> + }
> + ASSERT(SIZEOF(.rel.dyn) == 0, "Unexpected run-time relocations (.rel) detected!")
> }
> --
> 2.30.0
>
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH v4 mips-next 3/7] MIPS: properly stop .eh_frame generation
@ 2021-01-08 21:16 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-08 21:16 UTC (permalink / raw)
To: Alexander Lobakin
Cc: Thomas Bogendoerfer, Arnd Bergmann, Kees Cook, Nick Desaulniers,
Fangrui Song, Huacai Chen, Pei Huang, Jiaxun Yang, Sami Tolvanen,
Ingo Molnar, Ralf Baechle, Corey Minyard, linux-mips,
linux-kernel, linux-arch, stable, clang-built-linux
On Thu, Jan 07, 2021 at 12:35:01PM +0000, Alexander Lobakin wrote:
> Commit 866b6a89c6d1 ("MIPS: Add DWARF unwinding to assembly") added
> -fno-asynchronous-unwind-tables to KBUILD_CFLAGS to prevent compiler
> from emitting .eh_frame symbols.
> However, as MIPS heavily uses CFI, that's not enough. Use the
> approach taken for x86 (as it also uses CFI) and explicitly put CFI
> symbols into the .debug_frame section (except for VDSO).
> This allows us to drop .eh_frame from DISCARDS as it's no longer
> being generated.
>
> Fixes: 866b6a89c6d1 ("MIPS: Add DWARF unwinding to assembly")
> Suggested-by: Kees Cook <keescook@chromium.org>
> Signed-off-by: Alexander Lobakin <alobakin@pm.me>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> arch/mips/include/asm/asm.h | 18 ++++++++++++++++++
> arch/mips/kernel/vmlinux.lds.S | 1 -
> 2 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/arch/mips/include/asm/asm.h b/arch/mips/include/asm/asm.h
> index 3682d1a0bb80..908f6d6ae24b 100644
> --- a/arch/mips/include/asm/asm.h
> +++ b/arch/mips/include/asm/asm.h
> @@ -20,10 +20,27 @@
> #include <asm/sgidefs.h>
> #include <asm/asm-eva.h>
>
> +#ifndef __VDSO__
> +/*
> + * Emit CFI data in .debug_frame sections, not .eh_frame sections.
> + * We don't do DWARF unwinding at runtime, so only the offline DWARF
> + * information is useful to anyone. Note we should change this if we
> + * ever decide to enable DWARF unwinding at runtime.
> + */
> +#define CFI_SECTIONS .cfi_sections .debug_frame
> +#else
> + /*
> + * For the vDSO, emit both runtime unwind information and debug
> + * symbols for the .dbg file.
> + */
> +#define CFI_SECTIONS
> +#endif
> +
> /*
> * LEAF - declare leaf routine
> */
> #define LEAF(symbol) \
> + CFI_SECTIONS; \
> .globl symbol; \
> .align 2; \
> .type symbol, @function; \
> @@ -36,6 +53,7 @@ symbol: .frame sp, 0, ra; \
> * NESTED - declare nested routine entry point
> */
> #define NESTED(symbol, framesize, rpc) \
> + CFI_SECTIONS; \
> .globl symbol; \
> .align 2; \
> .type symbol, @function; \
> diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S
> index 16468957cba2..0f4e46ea4458 100644
> --- a/arch/mips/kernel/vmlinux.lds.S
> +++ b/arch/mips/kernel/vmlinux.lds.S
> @@ -225,6 +225,5 @@ SECTIONS
> *(.options)
> *(.pdr)
> *(.reginfo)
> - *(.eh_frame)
> }
> }
> --
> 2.30.0
>
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH v4 mips-next 2/7] MIPS: vmlinux.lds.S: add ".gnu.attributes" to DISCARDS
@ 2021-01-08 21:12 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-08 21:12 UTC (permalink / raw)
To: Alexander Lobakin
Cc: Thomas Bogendoerfer, Arnd Bergmann, Kees Cook, Nick Desaulniers,
Fangrui Song, Huacai Chen, Pei Huang, Jiaxun Yang, Sami Tolvanen,
Ingo Molnar, Ralf Baechle, Corey Minyard, linux-mips,
linux-kernel, linux-arch, stable, clang-built-linux
On Thu, Jan 07, 2021 at 12:34:53PM +0000, Alexander Lobakin wrote:
> Discard GNU attributes (MIPS FP type, GNU Hash etc.) at link time
> as kernel doesn't use it at all.
> Solves a dozen of the following ld warnings (one per every file):
>
> mips-alpine-linux-musl-ld: warning: orphan section `.gnu.attributes'
> from `arch/mips/kernel/head.o' being placed in section
> `.gnu.attributes'
> mips-alpine-linux-musl-ld: warning: orphan section `.gnu.attributes'
> from `init/main.o' being placed in section `.gnu.attributes'
>
> Signed-off-by: Alexander Lobakin <alobakin@pm.me>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> arch/mips/kernel/vmlinux.lds.S | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S
> index 83e27a181206..16468957cba2 100644
> --- a/arch/mips/kernel/vmlinux.lds.S
> +++ b/arch/mips/kernel/vmlinux.lds.S
> @@ -221,6 +221,7 @@ SECTIONS
> /* ABI crap starts here */
> *(.MIPS.abiflags)
> *(.MIPS.options)
> + *(.gnu.attributes)
> *(.options)
> *(.pdr)
> *(.reginfo)
> --
> 2.30.0
>
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH v4 mips-next 1/7] MIPS: vmlinux.lds.S: add missing PAGE_ALIGNED_DATA() section
@ 2021-01-08 21:10 99% ` Nathan Chancellor
2 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-08 21:10 UTC (permalink / raw)
To: Alexander Lobakin
Cc: Thomas Bogendoerfer, Arnd Bergmann, Kees Cook, Nick Desaulniers,
Fangrui Song, Huacai Chen, Pei Huang, Jiaxun Yang, Sami Tolvanen,
Ingo Molnar, Ralf Baechle, Corey Minyard, linux-mips,
linux-kernel, linux-arch, stable, clang-built-linux
On Thu, Jan 07, 2021 at 12:34:47PM +0000, Alexander Lobakin wrote:
> MIPS uses its own declaration of rwdata, and thus it should be kept
> in sync with the asm-generic one. Currently PAGE_ALIGNED_DATA() is
> missing from the linker script, which emits the following ld
> warnings:
>
> mips-alpine-linux-musl-ld: warning: orphan section
> `.data..page_aligned' from `arch/mips/kernel/vdso.o' being placed
> in section `.data..page_aligned'
> mips-alpine-linux-musl-ld: warning: orphan section
> `.data..page_aligned' from `arch/mips/vdso/vdso-image.o' being placed
> in section `.data..page_aligned'
>
> Add the necessary declaration, so the mentioned structures will be
> placed in vmlinux as intended:
>
> ffffffff80630580 D __end_once
> ffffffff80630580 D __start___dyndbg
> ffffffff80630580 D __start_once
> ffffffff80630580 D __stop___dyndbg
> ffffffff80634000 d mips_vdso_data
> ffffffff80638000 d vdso_data
> ffffffff80638580 D _gp
> ffffffff8063c000 T __init_begin
> ffffffff8063c000 D _edata
> ffffffff8063c000 T _sinittext
>
> ->
>
> ffffffff805a4000 D __end_init_task
> ffffffff805a4000 D __nosave_begin
> ffffffff805a4000 D __nosave_end
> ffffffff805a4000 d mips_vdso_data
> ffffffff805a8000 d vdso_data
> ffffffff805ac000 D mmlist_lock
> ffffffff805ac080 D tasklist_lock
>
> Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
> Cc: stable@vger.kernel.org # 4.4+
> Signed-off-by: Alexander Lobakin <alobakin@pm.me>
> Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> arch/mips/kernel/vmlinux.lds.S | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S
> index 5e97e9d02f98..83e27a181206 100644
> --- a/arch/mips/kernel/vmlinux.lds.S
> +++ b/arch/mips/kernel/vmlinux.lds.S
> @@ -90,6 +90,7 @@ SECTIONS
>
> INIT_TASK_DATA(THREAD_SIZE)
> NOSAVE_DATA
> + PAGE_ALIGNED_DATA(PAGE_SIZE)
> CACHELINE_ALIGNED_DATA(1 << CONFIG_MIPS_L1_CACHE_SHIFT)
> READ_MOSTLY_DATA(1 << CONFIG_MIPS_L1_CACHE_SHIFT)
> DATA_DATA
> --
> 2.30.0
>
>
^ permalink raw reply [relevance 99%]
* Re: UBSAN: object-size-mismatch in wg_xmit
@ 2021-01-08 20:54 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-08 20:54 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: noloader, Jason A. Donenfeld, Netdev, syzkaller-bugs,
WireGuard mailing list
On Fri, Jan 08, 2021 at 10:33:19AM +0100, Dmitry Vyukov wrote:
> On Thu, Jan 7, 2021 at 8:06 PM Jeffrey Walton <noloader@gmail.com> wrote:
> >
> > On Thu, Jan 7, 2021 at 2:03 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> > >
> > > On Thu, Jan 7, 2021 at 1:22 PM Dmitry Vyukov <dvyukov@google.com> wrote:
> > > >
> > > > On Mon, Dec 21, 2020 at 12:23 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> > > > >
> > > > > ...
> > > >
> > > > These UBSAN checks were just enabled recently.
> > > > It's indeed super easy to trigger: 133083 VMs were crashed on this already:
> > > > https://syzkaller.appspot.com/bug?extid=8f90d005ab2d22342b6d
> > > > So it's one of the top crashers by now.
> > >
> > > Ahh, makes sense. So it is easily reproducible after all.
> > >
> > > You're still of the opinion that it's a false positive, right? I
> > > shouldn't spend more cycles on this?
> >
> > You might consider making a test build with -fno-lto in case LTO is
> > mucking things up.
> >
> > Google Posts Patches So The Linux Kernel Can Be LTO-Optimized By
> > Clang, https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Clang-LTO-Patches
>
> Hi Jeff,
>
> Are these patches upstream now?
> syzbot doesn't enable LTO intentionally, nor I see CONFIG_LTO in the
> provided config.
Those patches are not upstream yet and LTO will have to be explicitly
enabled via config.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH v3] kasan: remove redundant config option
2021-01-08 4:16 99% ` Nathan Chancellor
@ 2021-01-08 4:16 99% ` Nathan Chancellor
1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-08 4:16 UTC (permalink / raw)
To: Walter Wu
Cc: wsd_upstream, Andrey Konovalov, linux-mediatek, linux-kernel,
kasan-dev, linux-mm, Alexander Potapenko, linux-arm-kernel,
Andrey Ryabinin, Andrew Morton, Dmitry Vyukov
On Fri, Jan 08, 2021 at 12:09:40PM +0800, Walter Wu wrote:
> CONFIG_KASAN_STACK and CONFIG_KASAN_STACK_ENABLE both enable KASAN stack
> instrumentation, but we should only need one config, so that we remove
> CONFIG_KASAN_STACK_ENABLE and make CONFIG_KASAN_STACK workable. see [1].
>
> When enable KASAN stack instrumentation, then for gcc we could do
> no prompt and default value y, and for clang prompt and default
> value n.
>
> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=210221
>
> Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> Suggested-by: Dmitry Vyukov <dvyukov@google.com>
> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Cc: Dmitry Vyukov <dvyukov@google.com>
> Cc: Andrey Konovalov <andreyknvl@google.com>
> Cc: Alexander Potapenko <glider@google.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
>
> v2: make commit log to be more readable.
> v3: remain CONFIG_KASAN_STACK_ENABLE setting
> fix the pre-processors syntax
>
> ---
> arch/arm64/kernel/sleep.S | 2 +-
> arch/x86/kernel/acpi/wakeup_64.S | 2 +-
> include/linux/kasan.h | 2 +-
> lib/Kconfig.kasan | 8 ++------
> mm/kasan/common.c | 2 +-
> mm/kasan/kasan.h | 2 +-
> mm/kasan/report_generic.c | 2 +-
> scripts/Makefile.kasan | 10 ++++++++--
> 8 files changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S
> index 6bdef7362c0e..7c44ede122a9 100644
> --- a/arch/arm64/kernel/sleep.S
> +++ b/arch/arm64/kernel/sleep.S
> @@ -133,7 +133,7 @@ SYM_FUNC_START(_cpu_resume)
> */
> bl cpu_do_resume
>
> -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> mov x0, sp
> bl kasan_unpoison_task_stack_below
> #endif
> diff --git a/arch/x86/kernel/acpi/wakeup_64.S b/arch/x86/kernel/acpi/wakeup_64.S
> index 5d3a0b8fd379..c7f412f4e07d 100644
> --- a/arch/x86/kernel/acpi/wakeup_64.S
> +++ b/arch/x86/kernel/acpi/wakeup_64.S
> @@ -112,7 +112,7 @@ SYM_FUNC_START(do_suspend_lowlevel)
> movq pt_regs_r14(%rax), %r14
> movq pt_regs_r15(%rax), %r15
>
> -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> /*
> * The suspend path may have poisoned some areas deeper in the stack,
> * which we now need to unpoison.
> diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> index 5e0655fb2a6f..35d1e9b2cbfa 100644
> --- a/include/linux/kasan.h
> +++ b/include/linux/kasan.h
> @@ -302,7 +302,7 @@ static inline void kasan_kfree_large(void *ptr, unsigned long ip) {}
>
> #endif /* CONFIG_KASAN */
>
> -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> void kasan_unpoison_task_stack(struct task_struct *task);
> #else
> static inline void kasan_unpoison_task_stack(struct task_struct *task) {}
> diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
> index f5fa4ba126bf..fde82ec85f8f 100644
> --- a/lib/Kconfig.kasan
> +++ b/lib/Kconfig.kasan
> @@ -138,9 +138,10 @@ config KASAN_INLINE
>
> endchoice
>
> -config KASAN_STACK_ENABLE
> +config KASAN_STACK
> bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
> depends on KASAN_GENERIC || KASAN_SW_TAGS
> + default y if CC_IS_GCC
> help
> The LLVM stack address sanitizer has a know problem that
> causes excessive stack usage in a lot of functions, see
> @@ -154,11 +155,6 @@ config KASAN_STACK_ENABLE
> CONFIG_COMPILE_TEST. On gcc it is assumed to always be safe
> to use and enabled by default.
>
> -config KASAN_STACK
> - int
> - default 1 if KASAN_STACK_ENABLE || CC_IS_GCC
> - default 0
> -
> config KASAN_SW_TAGS_IDENTIFY
> bool "Enable memory corruption identification"
> depends on KASAN_SW_TAGS
> diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> index 38ba2aecd8f4..bf8b073eed62 100644
> --- a/mm/kasan/common.c
> +++ b/mm/kasan/common.c
> @@ -63,7 +63,7 @@ void __kasan_unpoison_range(const void *address, size_t size)
> unpoison_range(address, size);
> }
>
> -#if CONFIG_KASAN_STACK
> +#ifdef CONFIG_KASAN_STACK
> /* Unpoison the entire stack for a task. */
> void kasan_unpoison_task_stack(struct task_struct *task)
> {
> diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> index cc4d9e1d49b1..bdfdb1cff653 100644
> --- a/mm/kasan/kasan.h
> +++ b/mm/kasan/kasan.h
> @@ -224,7 +224,7 @@ void *find_first_bad_addr(void *addr, size_t size);
> const char *get_bug_type(struct kasan_access_info *info);
> void metadata_fetch_row(char *buffer, void *row);
>
> -#if defined(CONFIG_KASAN_GENERIC) && CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN_GENERIC) && defined(CONFIG_KASAN_STACK)
> void print_address_stack_frame(const void *addr);
> #else
> static inline void print_address_stack_frame(const void *addr) { }
> diff --git a/mm/kasan/report_generic.c b/mm/kasan/report_generic.c
> index 8a9c889872da..4e16518d9877 100644
> --- a/mm/kasan/report_generic.c
> +++ b/mm/kasan/report_generic.c
> @@ -128,7 +128,7 @@ void metadata_fetch_row(char *buffer, void *row)
> memcpy(buffer, kasan_mem_to_shadow(row), META_BYTES_PER_ROW);
> }
>
> -#if CONFIG_KASAN_STACK
> +#ifdef CONFIG_KASAN_STACK
> static bool __must_check tokenize_frame_descr(const char **frame_descr,
> char *token, size_t max_tok_len,
> unsigned long *value)
> diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan
> index 1e000cc2e7b4..abf231d209b1 100644
> --- a/scripts/Makefile.kasan
> +++ b/scripts/Makefile.kasan
> @@ -2,6 +2,12 @@
> CFLAGS_KASAN_NOSANITIZE := -fno-builtin
> KASAN_SHADOW_OFFSET ?= $(CONFIG_KASAN_SHADOW_OFFSET)
>
> +ifdef CONFIG_KASAN_STACK
> + stack_enable := 1
> +else
> + stack_enable := 0
> +endif
> +
> ifdef CONFIG_KASAN_GENERIC
>
> ifdef CONFIG_KASAN_INLINE
> @@ -27,7 +33,7 @@ else
> CFLAGS_KASAN := $(CFLAGS_KASAN_SHADOW) \
> $(call cc-param,asan-globals=1) \
> $(call cc-param,asan-instrumentation-with-call-threshold=$(call_threshold)) \
> - $(call cc-param,asan-stack=$(CONFIG_KASAN_STACK)) \
> + $(call cc-param,asan-stack=$(stack_enable)) \
> $(call cc-param,asan-instrument-allocas=1)
> endif
>
> @@ -42,7 +48,7 @@ else
> endif
>
> CFLAGS_KASAN := -fsanitize=kernel-hwaddress \
> - -mllvm -hwasan-instrument-stack=$(CONFIG_KASAN_STACK) \
> + -mllvm -hwasan-instrument-stack=$(stack_enable) \
> -mllvm -hwasan-use-short-granules=0 \
> $(instrumentation_flags)
>
> --
> 2.18.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [relevance 99%]
* Re: [PATCH v3] kasan: remove redundant config option
@ 2021-01-08 4:16 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-08 4:16 UTC (permalink / raw)
To: Walter Wu
Cc: Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov,
Andrey Konovalov, Andrew Morton, kasan-dev, linux-mm,
linux-kernel, linux-arm-kernel, wsd_upstream, linux-mediatek
On Fri, Jan 08, 2021 at 12:09:40PM +0800, Walter Wu wrote:
> CONFIG_KASAN_STACK and CONFIG_KASAN_STACK_ENABLE both enable KASAN stack
> instrumentation, but we should only need one config, so that we remove
> CONFIG_KASAN_STACK_ENABLE and make CONFIG_KASAN_STACK workable. see [1].
>
> When enable KASAN stack instrumentation, then for gcc we could do
> no prompt and default value y, and for clang prompt and default
> value n.
>
> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=210221
>
> Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> Suggested-by: Dmitry Vyukov <dvyukov@google.com>
> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Cc: Dmitry Vyukov <dvyukov@google.com>
> Cc: Andrey Konovalov <andreyknvl@google.com>
> Cc: Alexander Potapenko <glider@google.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
>
> v2: make commit log to be more readable.
> v3: remain CONFIG_KASAN_STACK_ENABLE setting
> fix the pre-processors syntax
>
> ---
> arch/arm64/kernel/sleep.S | 2 +-
> arch/x86/kernel/acpi/wakeup_64.S | 2 +-
> include/linux/kasan.h | 2 +-
> lib/Kconfig.kasan | 8 ++------
> mm/kasan/common.c | 2 +-
> mm/kasan/kasan.h | 2 +-
> mm/kasan/report_generic.c | 2 +-
> scripts/Makefile.kasan | 10 ++++++++--
> 8 files changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S
> index 6bdef7362c0e..7c44ede122a9 100644
> --- a/arch/arm64/kernel/sleep.S
> +++ b/arch/arm64/kernel/sleep.S
> @@ -133,7 +133,7 @@ SYM_FUNC_START(_cpu_resume)
> */
> bl cpu_do_resume
>
> -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> mov x0, sp
> bl kasan_unpoison_task_stack_below
> #endif
> diff --git a/arch/x86/kernel/acpi/wakeup_64.S b/arch/x86/kernel/acpi/wakeup_64.S
> index 5d3a0b8fd379..c7f412f4e07d 100644
> --- a/arch/x86/kernel/acpi/wakeup_64.S
> +++ b/arch/x86/kernel/acpi/wakeup_64.S
> @@ -112,7 +112,7 @@ SYM_FUNC_START(do_suspend_lowlevel)
> movq pt_regs_r14(%rax), %r14
> movq pt_regs_r15(%rax), %r15
>
> -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> /*
> * The suspend path may have poisoned some areas deeper in the stack,
> * which we now need to unpoison.
> diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> index 5e0655fb2a6f..35d1e9b2cbfa 100644
> --- a/include/linux/kasan.h
> +++ b/include/linux/kasan.h
> @@ -302,7 +302,7 @@ static inline void kasan_kfree_large(void *ptr, unsigned long ip) {}
>
> #endif /* CONFIG_KASAN */
>
> -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> void kasan_unpoison_task_stack(struct task_struct *task);
> #else
> static inline void kasan_unpoison_task_stack(struct task_struct *task) {}
> diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
> index f5fa4ba126bf..fde82ec85f8f 100644
> --- a/lib/Kconfig.kasan
> +++ b/lib/Kconfig.kasan
> @@ -138,9 +138,10 @@ config KASAN_INLINE
>
> endchoice
>
> -config KASAN_STACK_ENABLE
> +config KASAN_STACK
> bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
> depends on KASAN_GENERIC || KASAN_SW_TAGS
> + default y if CC_IS_GCC
> help
> The LLVM stack address sanitizer has a know problem that
> causes excessive stack usage in a lot of functions, see
> @@ -154,11 +155,6 @@ config KASAN_STACK_ENABLE
> CONFIG_COMPILE_TEST. On gcc it is assumed to always be safe
> to use and enabled by default.
>
> -config KASAN_STACK
> - int
> - default 1 if KASAN_STACK_ENABLE || CC_IS_GCC
> - default 0
> -
> config KASAN_SW_TAGS_IDENTIFY
> bool "Enable memory corruption identification"
> depends on KASAN_SW_TAGS
> diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> index 38ba2aecd8f4..bf8b073eed62 100644
> --- a/mm/kasan/common.c
> +++ b/mm/kasan/common.c
> @@ -63,7 +63,7 @@ void __kasan_unpoison_range(const void *address, size_t size)
> unpoison_range(address, size);
> }
>
> -#if CONFIG_KASAN_STACK
> +#ifdef CONFIG_KASAN_STACK
> /* Unpoison the entire stack for a task. */
> void kasan_unpoison_task_stack(struct task_struct *task)
> {
> diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> index cc4d9e1d49b1..bdfdb1cff653 100644
> --- a/mm/kasan/kasan.h
> +++ b/mm/kasan/kasan.h
> @@ -224,7 +224,7 @@ void *find_first_bad_addr(void *addr, size_t size);
> const char *get_bug_type(struct kasan_access_info *info);
> void metadata_fetch_row(char *buffer, void *row);
>
> -#if defined(CONFIG_KASAN_GENERIC) && CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN_GENERIC) && defined(CONFIG_KASAN_STACK)
> void print_address_stack_frame(const void *addr);
> #else
> static inline void print_address_stack_frame(const void *addr) { }
> diff --git a/mm/kasan/report_generic.c b/mm/kasan/report_generic.c
> index 8a9c889872da..4e16518d9877 100644
> --- a/mm/kasan/report_generic.c
> +++ b/mm/kasan/report_generic.c
> @@ -128,7 +128,7 @@ void metadata_fetch_row(char *buffer, void *row)
> memcpy(buffer, kasan_mem_to_shadow(row), META_BYTES_PER_ROW);
> }
>
> -#if CONFIG_KASAN_STACK
> +#ifdef CONFIG_KASAN_STACK
> static bool __must_check tokenize_frame_descr(const char **frame_descr,
> char *token, size_t max_tok_len,
> unsigned long *value)
> diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan
> index 1e000cc2e7b4..abf231d209b1 100644
> --- a/scripts/Makefile.kasan
> +++ b/scripts/Makefile.kasan
> @@ -2,6 +2,12 @@
> CFLAGS_KASAN_NOSANITIZE := -fno-builtin
> KASAN_SHADOW_OFFSET ?= $(CONFIG_KASAN_SHADOW_OFFSET)
>
> +ifdef CONFIG_KASAN_STACK
> + stack_enable := 1
> +else
> + stack_enable := 0
> +endif
> +
> ifdef CONFIG_KASAN_GENERIC
>
> ifdef CONFIG_KASAN_INLINE
> @@ -27,7 +33,7 @@ else
> CFLAGS_KASAN := $(CFLAGS_KASAN_SHADOW) \
> $(call cc-param,asan-globals=1) \
> $(call cc-param,asan-instrumentation-with-call-threshold=$(call_threshold)) \
> - $(call cc-param,asan-stack=$(CONFIG_KASAN_STACK)) \
> + $(call cc-param,asan-stack=$(stack_enable)) \
> $(call cc-param,asan-instrument-allocas=1)
> endif
>
> @@ -42,7 +48,7 @@ else
> endif
>
> CFLAGS_KASAN := -fsanitize=kernel-hwaddress \
> - -mllvm -hwasan-instrument-stack=$(CONFIG_KASAN_STACK) \
> + -mllvm -hwasan-instrument-stack=$(stack_enable) \
> -mllvm -hwasan-use-short-granules=0 \
> $(instrumentation_flags)
>
> --
> 2.18.0
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH v3] kasan: remove redundant config option
@ 2021-01-08 4:16 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-08 4:16 UTC (permalink / raw)
To: Walter Wu
Cc: wsd_upstream, Andrey Konovalov, linux-mediatek, linux-kernel,
kasan-dev, linux-mm, Alexander Potapenko, linux-arm-kernel,
Andrey Ryabinin, Andrew Morton, Dmitry Vyukov
On Fri, Jan 08, 2021 at 12:09:40PM +0800, Walter Wu wrote:
> CONFIG_KASAN_STACK and CONFIG_KASAN_STACK_ENABLE both enable KASAN stack
> instrumentation, but we should only need one config, so that we remove
> CONFIG_KASAN_STACK_ENABLE and make CONFIG_KASAN_STACK workable. see [1].
>
> When enable KASAN stack instrumentation, then for gcc we could do
> no prompt and default value y, and for clang prompt and default
> value n.
>
> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=210221
>
> Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> Suggested-by: Dmitry Vyukov <dvyukov@google.com>
> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Cc: Dmitry Vyukov <dvyukov@google.com>
> Cc: Andrey Konovalov <andreyknvl@google.com>
> Cc: Alexander Potapenko <glider@google.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
>
> v2: make commit log to be more readable.
> v3: remain CONFIG_KASAN_STACK_ENABLE setting
> fix the pre-processors syntax
>
> ---
> arch/arm64/kernel/sleep.S | 2 +-
> arch/x86/kernel/acpi/wakeup_64.S | 2 +-
> include/linux/kasan.h | 2 +-
> lib/Kconfig.kasan | 8 ++------
> mm/kasan/common.c | 2 +-
> mm/kasan/kasan.h | 2 +-
> mm/kasan/report_generic.c | 2 +-
> scripts/Makefile.kasan | 10 ++++++++--
> 8 files changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S
> index 6bdef7362c0e..7c44ede122a9 100644
> --- a/arch/arm64/kernel/sleep.S
> +++ b/arch/arm64/kernel/sleep.S
> @@ -133,7 +133,7 @@ SYM_FUNC_START(_cpu_resume)
> */
> bl cpu_do_resume
>
> -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> mov x0, sp
> bl kasan_unpoison_task_stack_below
> #endif
> diff --git a/arch/x86/kernel/acpi/wakeup_64.S b/arch/x86/kernel/acpi/wakeup_64.S
> index 5d3a0b8fd379..c7f412f4e07d 100644
> --- a/arch/x86/kernel/acpi/wakeup_64.S
> +++ b/arch/x86/kernel/acpi/wakeup_64.S
> @@ -112,7 +112,7 @@ SYM_FUNC_START(do_suspend_lowlevel)
> movq pt_regs_r14(%rax), %r14
> movq pt_regs_r15(%rax), %r15
>
> -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> /*
> * The suspend path may have poisoned some areas deeper in the stack,
> * which we now need to unpoison.
> diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> index 5e0655fb2a6f..35d1e9b2cbfa 100644
> --- a/include/linux/kasan.h
> +++ b/include/linux/kasan.h
> @@ -302,7 +302,7 @@ static inline void kasan_kfree_large(void *ptr, unsigned long ip) {}
>
> #endif /* CONFIG_KASAN */
>
> -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> void kasan_unpoison_task_stack(struct task_struct *task);
> #else
> static inline void kasan_unpoison_task_stack(struct task_struct *task) {}
> diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
> index f5fa4ba126bf..fde82ec85f8f 100644
> --- a/lib/Kconfig.kasan
> +++ b/lib/Kconfig.kasan
> @@ -138,9 +138,10 @@ config KASAN_INLINE
>
> endchoice
>
> -config KASAN_STACK_ENABLE
> +config KASAN_STACK
> bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
> depends on KASAN_GENERIC || KASAN_SW_TAGS
> + default y if CC_IS_GCC
> help
> The LLVM stack address sanitizer has a know problem that
> causes excessive stack usage in a lot of functions, see
> @@ -154,11 +155,6 @@ config KASAN_STACK_ENABLE
> CONFIG_COMPILE_TEST. On gcc it is assumed to always be safe
> to use and enabled by default.
>
> -config KASAN_STACK
> - int
> - default 1 if KASAN_STACK_ENABLE || CC_IS_GCC
> - default 0
> -
> config KASAN_SW_TAGS_IDENTIFY
> bool "Enable memory corruption identification"
> depends on KASAN_SW_TAGS
> diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> index 38ba2aecd8f4..bf8b073eed62 100644
> --- a/mm/kasan/common.c
> +++ b/mm/kasan/common.c
> @@ -63,7 +63,7 @@ void __kasan_unpoison_range(const void *address, size_t size)
> unpoison_range(address, size);
> }
>
> -#if CONFIG_KASAN_STACK
> +#ifdef CONFIG_KASAN_STACK
> /* Unpoison the entire stack for a task. */
> void kasan_unpoison_task_stack(struct task_struct *task)
> {
> diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> index cc4d9e1d49b1..bdfdb1cff653 100644
> --- a/mm/kasan/kasan.h
> +++ b/mm/kasan/kasan.h
> @@ -224,7 +224,7 @@ void *find_first_bad_addr(void *addr, size_t size);
> const char *get_bug_type(struct kasan_access_info *info);
> void metadata_fetch_row(char *buffer, void *row);
>
> -#if defined(CONFIG_KASAN_GENERIC) && CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN_GENERIC) && defined(CONFIG_KASAN_STACK)
> void print_address_stack_frame(const void *addr);
> #else
> static inline void print_address_stack_frame(const void *addr) { }
> diff --git a/mm/kasan/report_generic.c b/mm/kasan/report_generic.c
> index 8a9c889872da..4e16518d9877 100644
> --- a/mm/kasan/report_generic.c
> +++ b/mm/kasan/report_generic.c
> @@ -128,7 +128,7 @@ void metadata_fetch_row(char *buffer, void *row)
> memcpy(buffer, kasan_mem_to_shadow(row), META_BYTES_PER_ROW);
> }
>
> -#if CONFIG_KASAN_STACK
> +#ifdef CONFIG_KASAN_STACK
> static bool __must_check tokenize_frame_descr(const char **frame_descr,
> char *token, size_t max_tok_len,
> unsigned long *value)
> diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan
> index 1e000cc2e7b4..abf231d209b1 100644
> --- a/scripts/Makefile.kasan
> +++ b/scripts/Makefile.kasan
> @@ -2,6 +2,12 @@
> CFLAGS_KASAN_NOSANITIZE := -fno-builtin
> KASAN_SHADOW_OFFSET ?= $(CONFIG_KASAN_SHADOW_OFFSET)
>
> +ifdef CONFIG_KASAN_STACK
> + stack_enable := 1
> +else
> + stack_enable := 0
> +endif
> +
> ifdef CONFIG_KASAN_GENERIC
>
> ifdef CONFIG_KASAN_INLINE
> @@ -27,7 +33,7 @@ else
> CFLAGS_KASAN := $(CFLAGS_KASAN_SHADOW) \
> $(call cc-param,asan-globals=1) \
> $(call cc-param,asan-instrumentation-with-call-threshold=$(call_threshold)) \
> - $(call cc-param,asan-stack=$(CONFIG_KASAN_STACK)) \
> + $(call cc-param,asan-stack=$(stack_enable)) \
> $(call cc-param,asan-instrument-allocas=1)
> endif
>
> @@ -42,7 +48,7 @@ else
> endif
>
> CFLAGS_KASAN := -fsanitize=kernel-hwaddress \
> - -mllvm -hwasan-instrument-stack=$(CONFIG_KASAN_STACK) \
> + -mllvm -hwasan-instrument-stack=$(stack_enable) \
> -mllvm -hwasan-use-short-granules=0 \
> $(instrumentation_flags)
>
> --
> 2.18.0
>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [relevance 99%]
* Re: [PATCH] x86: efi: avoid BUILD_BUG_ON() for non-constant p4d_index
@ 2021-01-07 22:42 99% ` Nathan Chancellor
1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-07 22:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Ard Biesheuvel, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
x86, Nick Desaulniers, Arnd Bergmann, Darren Hart,
Andy Shevchenko, H. Peter Anvin, linux-efi, platform-driver-x86,
linux-kernel, clang-built-linux
On Thu, Jan 07, 2021 at 11:34:15PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> When 5-level page tables are enabled, clang triggers a BUILD_BUG_ON():
>
> x86_64-linux-ld: arch/x86/platform/efi/efi_64.o: in function `efi_sync_low_kernel_mappings':
> efi_64.c:(.text+0x22c): undefined reference to `__compiletime_assert_354'
>
> Use the same method as in commit c65e774fb3f6 ("x86/mm: Make PGDIR_SHIFT
> and PTRS_PER_P4D variable") and change it to MAYBE_BUILD_BUG_ON(),
> so it only triggers for constant input.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/256
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> arch/x86/platform/efi/efi_64.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
> index e1e8d4e3a213..62bb1616b4a5 100644
> --- a/arch/x86/platform/efi/efi_64.c
> +++ b/arch/x86/platform/efi/efi_64.c
> @@ -137,8 +137,8 @@ void efi_sync_low_kernel_mappings(void)
> * As with PGDs, we share all P4D entries apart from the one entry
> * that covers the EFI runtime mapping space.
> */
> - BUILD_BUG_ON(p4d_index(EFI_VA_END) != p4d_index(MODULES_END));
> - BUILD_BUG_ON((EFI_VA_START & P4D_MASK) != (EFI_VA_END & P4D_MASK));
> + MAYBE_BUILD_BUG_ON(p4d_index(EFI_VA_END) != p4d_index(MODULES_END));
> + MAYBE_BUILD_BUG_ON((EFI_VA_START & P4D_MASK) != (EFI_VA_END & P4D_MASK));
>
> pgd_efi = efi_pgd + pgd_index(EFI_VA_END);
> pgd_k = pgd_offset_k(EFI_VA_END);
> --
> 2.29.2
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] kasan: remove redundant config option
2021-01-07 21:00 99% ` Nathan Chancellor
@ 2021-01-07 21:00 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-07 21:00 UTC (permalink / raw)
To: Walter Wu
Cc: wsd_upstream, clang-built-linux, Andrey Konovalov,
linux-mediatek, linux-kernel, kasan-dev, linux-mm,
Alexander Potapenko, linux-arm-kernel, Andrey Ryabinin,
Andrew Morton, Dmitry Vyukov
On Thu, Jan 07, 2021 at 02:21:52PM +0800, Walter Wu wrote:
> CONFIG_KASAN_STACK and CONFIG_KASAN_STACK_ENABLE both enable KASAN
> stack instrumentation, but we should only need one config option,
> so that we remove CONFIG_KASAN_STACK_ENABLE. see [1].
>
> For gcc we could do no prompt and default value y, and for clang
> prompt and default value n.
>
> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=210221
>
> Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> Suggested-by: Dmitry Vyukov <dvyukov@google.com>
> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Cc: Dmitry Vyukov <dvyukov@google.com>
> Cc: Andrey Konovalov <andreyknvl@google.com>
> Cc: Alexander Potapenko <glider@google.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> ---
> arch/arm64/kernel/sleep.S | 2 +-
> arch/x86/kernel/acpi/wakeup_64.S | 2 +-
> include/linux/kasan.h | 2 +-
> lib/Kconfig.kasan | 11 ++++-------
> mm/kasan/common.c | 2 +-
> mm/kasan/kasan.h | 2 +-
> mm/kasan/report_generic.c | 2 +-
> scripts/Makefile.kasan | 10 ++++++++--
> 8 files changed, 18 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S
> index 6bdef7362c0e..7c44ede122a9 100644
> --- a/arch/arm64/kernel/sleep.S
> +++ b/arch/arm64/kernel/sleep.S
> @@ -133,7 +133,7 @@ SYM_FUNC_START(_cpu_resume)
> */
> bl cpu_do_resume
>
> -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> mov x0, sp
> bl kasan_unpoison_task_stack_below
> #endif
> diff --git a/arch/x86/kernel/acpi/wakeup_64.S b/arch/x86/kernel/acpi/wakeup_64.S
> index 5d3a0b8fd379..c7f412f4e07d 100644
> --- a/arch/x86/kernel/acpi/wakeup_64.S
> +++ b/arch/x86/kernel/acpi/wakeup_64.S
> @@ -112,7 +112,7 @@ SYM_FUNC_START(do_suspend_lowlevel)
> movq pt_regs_r14(%rax), %r14
> movq pt_regs_r15(%rax), %r15
>
> -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> /*
> * The suspend path may have poisoned some areas deeper in the stack,
> * which we now need to unpoison.
> diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> index 5e0655fb2a6f..35d1e9b2cbfa 100644
> --- a/include/linux/kasan.h
> +++ b/include/linux/kasan.h
> @@ -302,7 +302,7 @@ static inline void kasan_kfree_large(void *ptr, unsigned long ip) {}
>
> #endif /* CONFIG_KASAN */
>
> -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> void kasan_unpoison_task_stack(struct task_struct *task);
> #else
> static inline void kasan_unpoison_task_stack(struct task_struct *task) {}
> diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
> index f5fa4ba126bf..59de74293454 100644
> --- a/lib/Kconfig.kasan
> +++ b/lib/Kconfig.kasan
> @@ -138,9 +138,11 @@ config KASAN_INLINE
>
> endchoice
>
> -config KASAN_STACK_ENABLE
> - bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
You are effectively undoing commits 6baec880d7a5 ("kasan: turn off
asan-stack for clang-8 and earlier") and ebb6d35a74ce ("kasan: remove
clang version check for KASAN_STACK") with this change. This change
should still remain around so that all{mod,yes}config remain mostly
clean for clang builds. This should not change anything from the user's
perspective because this option was never user selectable for GCC and
the default y keeps it on.
> +config KASAN_STACK
> + bool "Enable stack instrumentation (unsafe)"
> depends on KASAN_GENERIC || KASAN_SW_TAGS
> + default y if CC_IS_GCC
> + default n if CC_IS_CLANG
This is implied and can be removed.
> help
> The LLVM stack address sanitizer has a know problem that
> causes excessive stack usage in a lot of functions, see
> @@ -154,11 +156,6 @@ config KASAN_STACK_ENABLE
> CONFIG_COMPILE_TEST. On gcc it is assumed to always be safe
> to use and enabled by default.
>
> -config KASAN_STACK
> - int
> - default 1 if KASAN_STACK_ENABLE || CC_IS_GCC
> - default 0
> -
> config KASAN_SW_TAGS_IDENTIFY
> bool "Enable memory corruption identification"
> depends on KASAN_SW_TAGS
> diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> index 38ba2aecd8f4..02ec7f81dc16 100644
> --- a/mm/kasan/common.c
> +++ b/mm/kasan/common.c
> @@ -63,7 +63,7 @@ void __kasan_unpoison_range(const void *address, size_t size)
> unpoison_range(address, size);
> }
>
> -#if CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN_STACK)
Isn't '#ifdef CONFIG_...' preferred for CONFIG symbols?
> /* Unpoison the entire stack for a task. */
> void kasan_unpoison_task_stack(struct task_struct *task)
> {
> diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> index cc4d9e1d49b1..bdfdb1cff653 100644
> --- a/mm/kasan/kasan.h
> +++ b/mm/kasan/kasan.h
> @@ -224,7 +224,7 @@ void *find_first_bad_addr(void *addr, size_t size);
> const char *get_bug_type(struct kasan_access_info *info);
> void metadata_fetch_row(char *buffer, void *row);
>
> -#if defined(CONFIG_KASAN_GENERIC) && CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN_GENERIC) && defined(CONFIG_KASAN_STACK)
> void print_address_stack_frame(const void *addr);
> #else
> static inline void print_address_stack_frame(const void *addr) { }
> diff --git a/mm/kasan/report_generic.c b/mm/kasan/report_generic.c
> index 8a9c889872da..137a1dba1978 100644
> --- a/mm/kasan/report_generic.c
> +++ b/mm/kasan/report_generic.c
> @@ -128,7 +128,7 @@ void metadata_fetch_row(char *buffer, void *row)
> memcpy(buffer, kasan_mem_to_shadow(row), META_BYTES_PER_ROW);
> }
>
> -#if CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN_STACK)
> static bool __must_check tokenize_frame_descr(const char **frame_descr,
> char *token, size_t max_tok_len,
> unsigned long *value)
> diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan
> index 1e000cc2e7b4..abf231d209b1 100644
> --- a/scripts/Makefile.kasan
> +++ b/scripts/Makefile.kasan
> @@ -2,6 +2,12 @@
> CFLAGS_KASAN_NOSANITIZE := -fno-builtin
> KASAN_SHADOW_OFFSET ?= $(CONFIG_KASAN_SHADOW_OFFSET)
>
> +ifdef CONFIG_KASAN_STACK
> + stack_enable := 1
> +else
> + stack_enable := 0
> +endif
> +
> ifdef CONFIG_KASAN_GENERIC
>
> ifdef CONFIG_KASAN_INLINE
> @@ -27,7 +33,7 @@ else
> CFLAGS_KASAN := $(CFLAGS_KASAN_SHADOW) \
> $(call cc-param,asan-globals=1) \
> $(call cc-param,asan-instrumentation-with-call-threshold=$(call_threshold)) \
> - $(call cc-param,asan-stack=$(CONFIG_KASAN_STACK)) \
> + $(call cc-param,asan-stack=$(stack_enable)) \
> $(call cc-param,asan-instrument-allocas=1)
> endif
>
> @@ -42,7 +48,7 @@ else
> endif
>
> CFLAGS_KASAN := -fsanitize=kernel-hwaddress \
> - -mllvm -hwasan-instrument-stack=$(CONFIG_KASAN_STACK) \
> + -mllvm -hwasan-instrument-stack=$(stack_enable) \
> -mllvm -hwasan-use-short-granules=0 \
> $(instrumentation_flags)
>
> --
> 2.18.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [relevance 99%]
* Re: [PATCH] kasan: remove redundant config option
@ 2021-01-07 21:00 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-07 21:00 UTC (permalink / raw)
To: Walter Wu
Cc: Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov,
Andrey Konovalov, Andrew Morton, kasan-dev, linux-mm,
linux-kernel, linux-arm-kernel, wsd_upstream, linux-mediatek,
clang-built-linux
On Thu, Jan 07, 2021 at 02:21:52PM +0800, Walter Wu wrote:
> CONFIG_KASAN_STACK and CONFIG_KASAN_STACK_ENABLE both enable KASAN
> stack instrumentation, but we should only need one config option,
> so that we remove CONFIG_KASAN_STACK_ENABLE. see [1].
>
> For gcc we could do no prompt and default value y, and for clang
> prompt and default value n.
>
> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=210221
>
> Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> Suggested-by: Dmitry Vyukov <dvyukov@google.com>
> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Cc: Dmitry Vyukov <dvyukov@google.com>
> Cc: Andrey Konovalov <andreyknvl@google.com>
> Cc: Alexander Potapenko <glider@google.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> ---
> arch/arm64/kernel/sleep.S | 2 +-
> arch/x86/kernel/acpi/wakeup_64.S | 2 +-
> include/linux/kasan.h | 2 +-
> lib/Kconfig.kasan | 11 ++++-------
> mm/kasan/common.c | 2 +-
> mm/kasan/kasan.h | 2 +-
> mm/kasan/report_generic.c | 2 +-
> scripts/Makefile.kasan | 10 ++++++++--
> 8 files changed, 18 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S
> index 6bdef7362c0e..7c44ede122a9 100644
> --- a/arch/arm64/kernel/sleep.S
> +++ b/arch/arm64/kernel/sleep.S
> @@ -133,7 +133,7 @@ SYM_FUNC_START(_cpu_resume)
> */
> bl cpu_do_resume
>
> -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> mov x0, sp
> bl kasan_unpoison_task_stack_below
> #endif
> diff --git a/arch/x86/kernel/acpi/wakeup_64.S b/arch/x86/kernel/acpi/wakeup_64.S
> index 5d3a0b8fd379..c7f412f4e07d 100644
> --- a/arch/x86/kernel/acpi/wakeup_64.S
> +++ b/arch/x86/kernel/acpi/wakeup_64.S
> @@ -112,7 +112,7 @@ SYM_FUNC_START(do_suspend_lowlevel)
> movq pt_regs_r14(%rax), %r14
> movq pt_regs_r15(%rax), %r15
>
> -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> /*
> * The suspend path may have poisoned some areas deeper in the stack,
> * which we now need to unpoison.
> diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> index 5e0655fb2a6f..35d1e9b2cbfa 100644
> --- a/include/linux/kasan.h
> +++ b/include/linux/kasan.h
> @@ -302,7 +302,7 @@ static inline void kasan_kfree_large(void *ptr, unsigned long ip) {}
>
> #endif /* CONFIG_KASAN */
>
> -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> void kasan_unpoison_task_stack(struct task_struct *task);
> #else
> static inline void kasan_unpoison_task_stack(struct task_struct *task) {}
> diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
> index f5fa4ba126bf..59de74293454 100644
> --- a/lib/Kconfig.kasan
> +++ b/lib/Kconfig.kasan
> @@ -138,9 +138,11 @@ config KASAN_INLINE
>
> endchoice
>
> -config KASAN_STACK_ENABLE
> - bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
You are effectively undoing commits 6baec880d7a5 ("kasan: turn off
asan-stack for clang-8 and earlier") and ebb6d35a74ce ("kasan: remove
clang version check for KASAN_STACK") with this change. This change
should still remain around so that all{mod,yes}config remain mostly
clean for clang builds. This should not change anything from the user's
perspective because this option was never user selectable for GCC and
the default y keeps it on.
> +config KASAN_STACK
> + bool "Enable stack instrumentation (unsafe)"
> depends on KASAN_GENERIC || KASAN_SW_TAGS
> + default y if CC_IS_GCC
> + default n if CC_IS_CLANG
This is implied and can be removed.
> help
> The LLVM stack address sanitizer has a know problem that
> causes excessive stack usage in a lot of functions, see
> @@ -154,11 +156,6 @@ config KASAN_STACK_ENABLE
> CONFIG_COMPILE_TEST. On gcc it is assumed to always be safe
> to use and enabled by default.
>
> -config KASAN_STACK
> - int
> - default 1 if KASAN_STACK_ENABLE || CC_IS_GCC
> - default 0
> -
> config KASAN_SW_TAGS_IDENTIFY
> bool "Enable memory corruption identification"
> depends on KASAN_SW_TAGS
> diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> index 38ba2aecd8f4..02ec7f81dc16 100644
> --- a/mm/kasan/common.c
> +++ b/mm/kasan/common.c
> @@ -63,7 +63,7 @@ void __kasan_unpoison_range(const void *address, size_t size)
> unpoison_range(address, size);
> }
>
> -#if CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN_STACK)
Isn't '#ifdef CONFIG_...' preferred for CONFIG symbols?
> /* Unpoison the entire stack for a task. */
> void kasan_unpoison_task_stack(struct task_struct *task)
> {
> diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> index cc4d9e1d49b1..bdfdb1cff653 100644
> --- a/mm/kasan/kasan.h
> +++ b/mm/kasan/kasan.h
> @@ -224,7 +224,7 @@ void *find_first_bad_addr(void *addr, size_t size);
> const char *get_bug_type(struct kasan_access_info *info);
> void metadata_fetch_row(char *buffer, void *row);
>
> -#if defined(CONFIG_KASAN_GENERIC) && CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN_GENERIC) && defined(CONFIG_KASAN_STACK)
> void print_address_stack_frame(const void *addr);
> #else
> static inline void print_address_stack_frame(const void *addr) { }
> diff --git a/mm/kasan/report_generic.c b/mm/kasan/report_generic.c
> index 8a9c889872da..137a1dba1978 100644
> --- a/mm/kasan/report_generic.c
> +++ b/mm/kasan/report_generic.c
> @@ -128,7 +128,7 @@ void metadata_fetch_row(char *buffer, void *row)
> memcpy(buffer, kasan_mem_to_shadow(row), META_BYTES_PER_ROW);
> }
>
> -#if CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN_STACK)
> static bool __must_check tokenize_frame_descr(const char **frame_descr,
> char *token, size_t max_tok_len,
> unsigned long *value)
> diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan
> index 1e000cc2e7b4..abf231d209b1 100644
> --- a/scripts/Makefile.kasan
> +++ b/scripts/Makefile.kasan
> @@ -2,6 +2,12 @@
> CFLAGS_KASAN_NOSANITIZE := -fno-builtin
> KASAN_SHADOW_OFFSET ?= $(CONFIG_KASAN_SHADOW_OFFSET)
>
> +ifdef CONFIG_KASAN_STACK
> + stack_enable := 1
> +else
> + stack_enable := 0
> +endif
> +
> ifdef CONFIG_KASAN_GENERIC
>
> ifdef CONFIG_KASAN_INLINE
> @@ -27,7 +33,7 @@ else
> CFLAGS_KASAN := $(CFLAGS_KASAN_SHADOW) \
> $(call cc-param,asan-globals=1) \
> $(call cc-param,asan-instrumentation-with-call-threshold=$(call_threshold)) \
> - $(call cc-param,asan-stack=$(CONFIG_KASAN_STACK)) \
> + $(call cc-param,asan-stack=$(stack_enable)) \
> $(call cc-param,asan-instrument-allocas=1)
> endif
>
> @@ -42,7 +48,7 @@ else
> endif
>
> CFLAGS_KASAN := -fsanitize=kernel-hwaddress \
> - -mllvm -hwasan-instrument-stack=$(CONFIG_KASAN_STACK) \
> + -mllvm -hwasan-instrument-stack=$(stack_enable) \
> -mllvm -hwasan-use-short-granules=0 \
> $(instrumentation_flags)
>
> --
> 2.18.0
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] kasan: remove redundant config option
@ 2021-01-07 21:00 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-07 21:00 UTC (permalink / raw)
To: Walter Wu
Cc: wsd_upstream, clang-built-linux, Andrey Konovalov,
linux-mediatek, linux-kernel, kasan-dev, linux-mm,
Alexander Potapenko, linux-arm-kernel, Andrey Ryabinin,
Andrew Morton, Dmitry Vyukov
On Thu, Jan 07, 2021 at 02:21:52PM +0800, Walter Wu wrote:
> CONFIG_KASAN_STACK and CONFIG_KASAN_STACK_ENABLE both enable KASAN
> stack instrumentation, but we should only need one config option,
> so that we remove CONFIG_KASAN_STACK_ENABLE. see [1].
>
> For gcc we could do no prompt and default value y, and for clang
> prompt and default value n.
>
> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=210221
>
> Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
> Suggested-by: Dmitry Vyukov <dvyukov@google.com>
> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Cc: Dmitry Vyukov <dvyukov@google.com>
> Cc: Andrey Konovalov <andreyknvl@google.com>
> Cc: Alexander Potapenko <glider@google.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> ---
> arch/arm64/kernel/sleep.S | 2 +-
> arch/x86/kernel/acpi/wakeup_64.S | 2 +-
> include/linux/kasan.h | 2 +-
> lib/Kconfig.kasan | 11 ++++-------
> mm/kasan/common.c | 2 +-
> mm/kasan/kasan.h | 2 +-
> mm/kasan/report_generic.c | 2 +-
> scripts/Makefile.kasan | 10 ++++++++--
> 8 files changed, 18 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S
> index 6bdef7362c0e..7c44ede122a9 100644
> --- a/arch/arm64/kernel/sleep.S
> +++ b/arch/arm64/kernel/sleep.S
> @@ -133,7 +133,7 @@ SYM_FUNC_START(_cpu_resume)
> */
> bl cpu_do_resume
>
> -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> mov x0, sp
> bl kasan_unpoison_task_stack_below
> #endif
> diff --git a/arch/x86/kernel/acpi/wakeup_64.S b/arch/x86/kernel/acpi/wakeup_64.S
> index 5d3a0b8fd379..c7f412f4e07d 100644
> --- a/arch/x86/kernel/acpi/wakeup_64.S
> +++ b/arch/x86/kernel/acpi/wakeup_64.S
> @@ -112,7 +112,7 @@ SYM_FUNC_START(do_suspend_lowlevel)
> movq pt_regs_r14(%rax), %r14
> movq pt_regs_r15(%rax), %r15
>
> -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> /*
> * The suspend path may have poisoned some areas deeper in the stack,
> * which we now need to unpoison.
> diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> index 5e0655fb2a6f..35d1e9b2cbfa 100644
> --- a/include/linux/kasan.h
> +++ b/include/linux/kasan.h
> @@ -302,7 +302,7 @@ static inline void kasan_kfree_large(void *ptr, unsigned long ip) {}
>
> #endif /* CONFIG_KASAN */
>
> -#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> void kasan_unpoison_task_stack(struct task_struct *task);
> #else
> static inline void kasan_unpoison_task_stack(struct task_struct *task) {}
> diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
> index f5fa4ba126bf..59de74293454 100644
> --- a/lib/Kconfig.kasan
> +++ b/lib/Kconfig.kasan
> @@ -138,9 +138,11 @@ config KASAN_INLINE
>
> endchoice
>
> -config KASAN_STACK_ENABLE
> - bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
You are effectively undoing commits 6baec880d7a5 ("kasan: turn off
asan-stack for clang-8 and earlier") and ebb6d35a74ce ("kasan: remove
clang version check for KASAN_STACK") with this change. This change
should still remain around so that all{mod,yes}config remain mostly
clean for clang builds. This should not change anything from the user's
perspective because this option was never user selectable for GCC and
the default y keeps it on.
> +config KASAN_STACK
> + bool "Enable stack instrumentation (unsafe)"
> depends on KASAN_GENERIC || KASAN_SW_TAGS
> + default y if CC_IS_GCC
> + default n if CC_IS_CLANG
This is implied and can be removed.
> help
> The LLVM stack address sanitizer has a know problem that
> causes excessive stack usage in a lot of functions, see
> @@ -154,11 +156,6 @@ config KASAN_STACK_ENABLE
> CONFIG_COMPILE_TEST. On gcc it is assumed to always be safe
> to use and enabled by default.
>
> -config KASAN_STACK
> - int
> - default 1 if KASAN_STACK_ENABLE || CC_IS_GCC
> - default 0
> -
> config KASAN_SW_TAGS_IDENTIFY
> bool "Enable memory corruption identification"
> depends on KASAN_SW_TAGS
> diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> index 38ba2aecd8f4..02ec7f81dc16 100644
> --- a/mm/kasan/common.c
> +++ b/mm/kasan/common.c
> @@ -63,7 +63,7 @@ void __kasan_unpoison_range(const void *address, size_t size)
> unpoison_range(address, size);
> }
>
> -#if CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN_STACK)
Isn't '#ifdef CONFIG_...' preferred for CONFIG symbols?
> /* Unpoison the entire stack for a task. */
> void kasan_unpoison_task_stack(struct task_struct *task)
> {
> diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> index cc4d9e1d49b1..bdfdb1cff653 100644
> --- a/mm/kasan/kasan.h
> +++ b/mm/kasan/kasan.h
> @@ -224,7 +224,7 @@ void *find_first_bad_addr(void *addr, size_t size);
> const char *get_bug_type(struct kasan_access_info *info);
> void metadata_fetch_row(char *buffer, void *row);
>
> -#if defined(CONFIG_KASAN_GENERIC) && CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN_GENERIC) && defined(CONFIG_KASAN_STACK)
> void print_address_stack_frame(const void *addr);
> #else
> static inline void print_address_stack_frame(const void *addr) { }
> diff --git a/mm/kasan/report_generic.c b/mm/kasan/report_generic.c
> index 8a9c889872da..137a1dba1978 100644
> --- a/mm/kasan/report_generic.c
> +++ b/mm/kasan/report_generic.c
> @@ -128,7 +128,7 @@ void metadata_fetch_row(char *buffer, void *row)
> memcpy(buffer, kasan_mem_to_shadow(row), META_BYTES_PER_ROW);
> }
>
> -#if CONFIG_KASAN_STACK
> +#if defined(CONFIG_KASAN_STACK)
> static bool __must_check tokenize_frame_descr(const char **frame_descr,
> char *token, size_t max_tok_len,
> unsigned long *value)
> diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan
> index 1e000cc2e7b4..abf231d209b1 100644
> --- a/scripts/Makefile.kasan
> +++ b/scripts/Makefile.kasan
> @@ -2,6 +2,12 @@
> CFLAGS_KASAN_NOSANITIZE := -fno-builtin
> KASAN_SHADOW_OFFSET ?= $(CONFIG_KASAN_SHADOW_OFFSET)
>
> +ifdef CONFIG_KASAN_STACK
> + stack_enable := 1
> +else
> + stack_enable := 0
> +endif
> +
> ifdef CONFIG_KASAN_GENERIC
>
> ifdef CONFIG_KASAN_INLINE
> @@ -27,7 +33,7 @@ else
> CFLAGS_KASAN := $(CFLAGS_KASAN_SHADOW) \
> $(call cc-param,asan-globals=1) \
> $(call cc-param,asan-instrumentation-with-call-threshold=$(call_threshold)) \
> - $(call cc-param,asan-stack=$(CONFIG_KASAN_STACK)) \
> + $(call cc-param,asan-stack=$(stack_enable)) \
> $(call cc-param,asan-instrument-allocas=1)
> endif
>
> @@ -42,7 +48,7 @@ else
> endif
>
> CFLAGS_KASAN := -fsanitize=kernel-hwaddress \
> - -mllvm -hwasan-instrument-stack=$(CONFIG_KASAN_STACK) \
> + -mllvm -hwasan-instrument-stack=$(stack_enable) \
> -mllvm -hwasan-use-short-granules=0 \
> $(instrumentation_flags)
>
> --
> 2.18.0
>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply [relevance 99%]
* Re: [PATCH] ubsan: disable unsigned-integer-overflow sanitizer with clang
@ 2021-01-07 18:15 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-07 18:15 UTC (permalink / raw)
To: Kees Cook
Cc: Arnd Bergmann, Arnd Bergmann, Nick Desaulniers, Andrew Morton,
Marco Elver, George Popescu, Stephen Rothwell, linux-kernel,
clang-built-linux
On Thu, Jan 07, 2021 at 09:22:00AM -0800, Kees Cook wrote:
> On Thu, Jan 07, 2021 at 05:09:59PM +0100, Arnd Bergmann wrote:
> > On Wed, Jan 6, 2021 at 11:12 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > >
> > > On Wed, Jan 6, 2021 at 10:57 PM Kees Cook <keescook@chromium.org> wrote:
> > > > On Wed, Dec 30, 2020 at 04:47:35PM +0100, Arnd Bergmann wrote:
> > > > > diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
> > > > > index 8b635fd75fe4..e23873282ba7 100644
> > > > > --- a/lib/Kconfig.ubsan
> > > > > +++ b/lib/Kconfig.ubsan
> > > > > @@ -122,6 +122,8 @@ config UBSAN_SIGNED_OVERFLOW
> > > > >
> > > > > config UBSAN_UNSIGNED_OVERFLOW
> > > > > bool "Perform checking for unsigned arithmetic overflow"
> > > > > + # clang hugely expands stack usage with -fsanitize=object-size
> > > > > + depends on !CC_IS_CLANG
> > > > > depends on $(cc-option,-fsanitize=unsigned-integer-overflow)
> > > >
> > > > Because of Clang implementation issues (see commit c637693b20da), this is
> > > > already "default n" (and not supported under GCC at all). IIUC, setting
> > > > this to "depends on !COMPILE_TEST" won't work for randconfigs, yes?
> > >
> > > Ah, I had not realized this is clang specific. Adding the !COMPILE_TEST
> > > dependency would hide it for me, which may be good enough for me.
> > >
> > > > Is there some better way to mark this as "known to have issues, please
> > > > don't include in randconfig?"
> > > >
> > > > I'd like to keep it around so people can continue to work out the
> > > > problems with it, but not have unexpecting folks trip over it. ;)
> > >
> > > I've reverted that patch locally now and default-enabled for randconfigs.
> > > Now that I have an otherwise clean build, this should provide me
> > > with a full set of files that produce the warning. If the number is
> > > small enough, I could try opening individual github issues.
> >
> > A day's worth of randconfig builds with clang-11 or clang-12 shows these
> > instances that exceeded the warning limit:
> >
> > crypto/blake2b_generic.c:98:13: error: stack frame size of 9636 bytes
> > in function 'blake2b_compress' [-Werror,-Wframe-larger-than=]
> > crypto/sha512_generic.c:151:13: error: stack frame size of 1292 bytes
> > in function 'sha512_generic_block_fn' [-Werror,-Wframe-larger-than=]
> > lib/crypto/curve25519-fiat32.c:312:22: error: stack frame size of 2180
> > bytes in function 'fe_mul_impl' [-Werror,-Wframe-larger-than=]
> > lib/crypto/curve25519-fiat32.c:444:22: error: stack frame size of 1588
> > bytes in function 'fe_sqr_impl' [-Werror,-Wframe-larger-than=]
> > fs/btrfs/scrub.c:3028:31: error: stack frame size of 1132 bytes in
> > function 'scrub_stripe' [-Werror,-Wframe-larger-than=]
> > drivers/net/ethernet/intel/e1000/e1000_main.c:3590:6: warning: stack
> > frame size of 1100 bytes in function 'e1000_update_stats'
> > [-Wframe-larger-than=]
> > drivers/net/ethernet/broadcom/tg3.c:11829:13: warning: stack frame
> > size of 1188 bytes in function 'tg3_get_estats' [-Wframe-larger-than=]
> > drivers/net/ethernet/intel/igb/igb_main.c:6551:6: warning: stack frame
> > size of 1348 bytes in function 'igb_update_stats'
> > [-Wframe-larger-than=]
> > drivers/net/ethernet/intel/igc/igc_main.c:3608:6: warning: stack frame
> > size of 1124 bytes in function 'igc_update_stats'
> > [-Wframe-larger-than=]
> > drivers/net/ethernet/qlogic/qed/qed_l2.c:1759:1: warning: stack frame
> > size of 1300 bytes in function '__qed_get_vport_port_stats'
> > [-Wframe-larger-than=]
> > drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:7022:6: warning: stack
> > frame size of 1564 bytes in function 'ixgbe_update_stats'
> > [-Wframe-larger-than=]
> > drivers/net/ethernet/intel/ixgb/ixgb_main.c:1590:1: warning: stack
> > frame size of 1140 bytes in function 'ixgb_update_stats'
> > [-Wframe-larger-than=]
> > drivers/net/ethernet/mellanox/mlx5/core/ipoib/ipoib.c:145:6: warning:
> > stack frame size of 1068 bytes in function 'mlx5i_get_stats'
> > [-Wframe-larger-than=]
> > drivers/staging/media/atomisp/pci/atomisp_cmd.c:5600:5: warning: stack
> > frame size of 1052 bytes in function 'atomisp_set_fmt'
> > [-Wframe-larger-than=]
> >
> > All of these *only* happen on 32-bit x86, and can be reproduced in a
> > i386_defconfig, with the corresponding drivers (btrfs, sha512, blake2b,
> > curve25519, and the ethernet ones) and UBSAN_UNSIGNED_OVERFLOW
> > manually enabled. Given that few people still care about i386, maybe
> > we could just make the option depend on !CONFIG_X86_32
>
> I'm fine with that -- or maybe any 32-bit architecture, if the problem
> is poor stack space optimization on 32-bit archs?
>
> >
> > That config also runs into two more BUILD_BUG_ON() that I had not
> > seen in randconfig tests:
> >
> > (i386 defconfig plus ubsan)
> > ld.lld: error: undefined symbol: __compiletime_assert_207
> > >>> referenced by cpu_entry_area.c
> > >>> mm/cpu_entry_area.o:(setup_cpu_entry_area_ptes) in archive arch/x86/built-in.a
>
> That one I don't think I've seen before.
>
> >
> > (x86-64 defconfig plus ubsan)
> > ld.lld: error: undefined symbol: __compiletime_assert_362
> > >>> referenced by efi_64.c
> > >>> platform/efi/efi_64.o:(efi_sync_low_kernel_mappings) in archive arch/x86/built-in.a
>
> I think this is:
> https://github.com/ClangBuiltLinux/linux/issues/256
> and that bug needs re-opening? Or maybe there's a new bug I can't find?
The problem is that applying the fix for that issue does not work, nor
does converting p4d_index to a macro like mips and s390. I am not sure
what exactly is going on there, it appears that clang cannot reason
about ptrs_per_p4d because it is an extern variable with no assigned
value in its translation unit?
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] SPI: Fix distinct pointer types warning for ARCH=MIPS
@ 2021-01-07 17:30 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-07 17:30 UTC (permalink / raw)
To: Yanteng Si
Cc: Mark Brown, Philipp Zabel, linux-spi, Huacai Chen, Jiaxun Yang,
Yanteng Si
On Thu, Jan 07, 2021 at 07:57:04PM +0800, Yanteng Si wrote:
> Fix a new warning report by build for make ARCH=MIPS allmodconfig:
>
> drivers/spi/spi-cadence-quadspi.c: In function 'cqspi_direct_read_execute':
> ./include/linux/minmax.h:18:28: warning: comparison of distinct pointer types lacks a cast
> 18 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
> | ^~
> ./include/linux/minmax.h:32:4: note: in expansion of macro '__typecheck'
> 32 | (__typecheck(x, y) && __no_side_effects(x, y))
> | ^~~~~~~~~~~
> ./include/linux/minmax.h:42:24: note: in expansion of macro '__safe_cmp'
> 42 | __builtin_choose_expr(__safe_cmp(x, y), \
> | ^~~~~~~~~~
> ./include/linux/minmax.h:58:19: note: in expansion of macro '__careful_cmp'
> 58 | #define max(x, y) __careful_cmp(x, y, >)
> | ^~~~~~~~~~~~~
> drivers/spi/spi-cadence-quadspi.c:1153:24: note: in expansion of macro 'max'
> 1153 | msecs_to_jiffies(max(len, 500UL)))) {
> | ^~~
>
> "len" is unsigned,however,"500" is unsigned long.
>
> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
> ---
> drivers/spi/spi-cadence-quadspi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
> index 06a65e9a8a60..576610ba1118 100644
> --- a/drivers/spi/spi-cadence-quadspi.c
> +++ b/drivers/spi/spi-cadence-quadspi.c
> @@ -1150,7 +1150,7 @@ static int cqspi_direct_read_execute(struct cqspi_flash_pdata *f_pdata,
>
> dma_async_issue_pending(cqspi->rx_chan);
> if (!wait_for_completion_timeout(&cqspi->rx_dma_complete,
> - msecs_to_jiffies(max(len, 500UL)))) {
> + msecs_to_jiffies(max(len, 500U)))) {
> dmaengine_terminate_sync(cqspi->rx_chan);
> dev_err(dev, "DMA wait_for_completion_timeout\n");
> ret = -ETIMEDOUT;
> --
> 2.27.0
>
Isn't this just going to cause warnings on 64-bit platforms now because
size_t is defined as unsigned long and it will now be compared against
unsigned int? This fix should work for everyone, not sure how pretty it
is though.
Cheers,
Nathan
diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
index 06a65e9a8a60..af13c0025bf5 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -1150,7 +1150,7 @@ static int cqspi_direct_read_execute(struct cqspi_flash_pdata *f_pdata,
dma_async_issue_pending(cqspi->rx_chan);
if (!wait_for_completion_timeout(&cqspi->rx_dma_complete,
- msecs_to_jiffies(max(len, 500UL)))) {
+ msecs_to_jiffies(max_t(size_t, len, 500)))) {
dmaengine_terminate_sync(cqspi->rx_chan);
dev_err(dev, "DMA wait_for_completion_timeout\n");
ret = -ETIMEDOUT;
^ permalink raw reply related [relevance 99%]
* Re: [PATCH] ubsan: disable unsigned-integer-overflow sanitizer with clang
@ 2021-01-07 3:34 87% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-07 3:34 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Marco Elver, Kees Cook, Arnd Bergmann, Nick Desaulniers,
Andrew Morton, George Popescu, Stephen Rothwell, LKML,
clang-built-linux
On Wed, Jan 06, 2021 at 11:06:39PM +0100, Arnd Bergmann wrote:
> On Wed, Jan 6, 2021 at 10:38 PM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> > On Wed, Jan 06, 2021 at 10:12:51AM +0100, Arnd Bergmann wrote:
> > > On Tue, Jan 5, 2021 at 10:25 AM Arnd Bergmann <arnd@kernel.org> wrote:
> > > >
> > > > On Mon, Jan 4, 2021 at 11:33 PM Nathan Chancellor
> > > > <natechancellor@gmail.com> wrote:
> > > > > On Wed, Dec 30, 2020 at 05:13:03PM +0100, Marco Elver wrote:
> > > > > > On Wed, 30 Dec 2020 at 16:47, Arnd Bergmann <arnd@kernel.org> wrote:
> > > > > > >
> > > > > > > From: Arnd Bergmann <arnd@arndb.de>
> > > > > > >
> > > > > > > Building ubsan kernels even for compile-testing introduced these
> > > > > > > warnings in my randconfig environment:
> > > > > > >
> > > > > > > crypto/blake2b_generic.c:98:13: error: stack frame size of 9636 bytes in function 'blake2b_compress' [-Werror,-Wframe-larger-than=]
> > > > > > > static void blake2b_compress(struct blake2b_state *S,
> > > > > > > crypto/sha512_generic.c:151:13: error: stack frame size of 1292 bytes in function 'sha512_generic_block_fn' [-Werror,-Wframe-larger-than=]
> > > > > > > static void sha512_generic_block_fn(struct sha512_state *sst, u8 const *src,
> > > > > > > lib/crypto/curve25519-fiat32.c:312:22: error: stack frame size of 2180 bytes in function 'fe_mul_impl' [-Werror,-Wframe-larger-than=]
> > > > > > > static noinline void fe_mul_impl(u32 out[10], const u32 in1[10], const u32 in2[10])
> > > > > > > lib/crypto/curve25519-fiat32.c:444:22: error: stack frame size of 1588 bytes in function 'fe_sqr_impl' [-Werror,-Wframe-larger-than=]
> > > > > > > static noinline void fe_sqr_impl(u32 out[10], const u32 in1[10])
> > > > > > >
> > > > > > > Further testing showed that this is caused by
> > > > > > > -fsanitize=unsigned-integer-overflow.
> > > > > > >
> > > > > > > The one in blake2b immediately overflows the 8KB stack area on 32-bit
> > > > > > > architectures, so better ensure this never happens by making this
> > > > > > > option gcc-only.
> > > > >
> > > > > This patch also fixes the failed BUILD_BUG issue in mm/mremap.c that you
> > > > > sent a patch for [1], along with a couple of other issues I see such as:
> > > >
> > > > I'm fairly sure I still saw that BUILD_BUG() even after I had applied this
> > > > patch, I would guess that one just depends on inlining decisions that
> > > > are influenced by all kinds of compiler options including
> > > > -fsanitize=unsigned-integer-overflow, so it becomes less likely.
> > > >
> > > > I'll revert my other patch in the randconfig tree to see if it comes back.
> > >
> > > The qcom/gpi.c failure still happens with this patch applied:
> > >
> > > In file included from /git/arm-soc/drivers/dma/qcom/gpi.c:8:
> > > In function 'field_multiplier',
> > > inlined from 'gpi_update_reg' at
> > > /git/arm-soc/include/linux/bitfield.h:124:17:
> > > /git/arm-soc/include/linux/bitfield.h:119:3: error: call to
> > > '__bad_mask' declared with attribute error: bad bitfield mask
> > > 119 | __bad_mask();
> > > | ^~~~~~~~~~~~
> > > In function 'field_multiplier',
> > > inlined from 'gpi_update_reg' at
> > > /git/arm-soc/include/linux/bitfield.h:154:1:
> > > /git/arm-soc/include/linux/bitfield.h:119:3: error: call to
> > > '__bad_mask' declared with attribute error: bad bitfield mask
> > > 119 | __bad_mask();
> > > | ^~~~~~~~~~~~
> > >
> > > See https://pastebin.com/8UH6x4A2 for the .config
> > >
> > > Arnd
> >
> > That config does not build for me, am I holding it wrong?
> >
> > $ curl -LSso .config https://pastebin.com/raw/8UH6x4A2
>
> Sorry about that, you ran into a bug that I have applied a
> local fix for. You could enable CONFIG_EPOLL, or apply
> this patch:
>
> https://lore.kernel.org/linux-arm-kernel/20200429132349.1294904-1-arnd@arndb.de/
>
> Arnd
I decided to just try to build the file directly. As it turns out,
ARCH=arm allyesconfig does not show any error in get_extent or
gpi_update_reg but ARCH=arm64 allyesconfig does. Looks like this is
because of the lack of CONFIG_ARCH_HAS_UBSAN_SANITIZE_ALL for ARCH=arm.
$ rg UBSAN out/{arm,arm64}/.config
out/arm64/.config
13853:CONFIG_ARCH_HAS_UBSAN_SANITIZE_ALL=y
13854:CONFIG_UBSAN=y
13855:CONFIG_CC_HAS_UBSAN_BOUNDS=y
13856:CONFIG_CC_HAS_UBSAN_ARRAY_BOUNDS=y
13857:CONFIG_UBSAN_BOUNDS=y
13858:CONFIG_UBSAN_ARRAY_BOUNDS=y
13859:CONFIG_UBSAN_SHIFT=y
13860:CONFIG_UBSAN_DIV_ZERO=y
13861:CONFIG_UBSAN_UNREACHABLE=y
13862:CONFIG_UBSAN_SIGNED_OVERFLOW=y
13863:CONFIG_UBSAN_UNSIGNED_OVERFLOW=y
13864:CONFIG_UBSAN_OBJECT_SIZE=y
13865:CONFIG_UBSAN_BOOL=y
13866:CONFIG_UBSAN_ENUM=y
13867:CONFIG_UBSAN_SANITIZE_ALL=y
13868:CONFIG_TEST_UBSAN=m
out/arm/.config
14133:CONFIG_UBSAN=y
14134:CONFIG_CC_HAS_UBSAN_BOUNDS=y
14135:CONFIG_CC_HAS_UBSAN_ARRAY_BOUNDS=y
14136:CONFIG_UBSAN_BOUNDS=y
14137:CONFIG_UBSAN_ARRAY_BOUNDS=y
14138:CONFIG_UBSAN_SHIFT=y
14139:CONFIG_UBSAN_DIV_ZERO=y
14140:CONFIG_UBSAN_UNREACHABLE=y
14141:CONFIG_UBSAN_SIGNED_OVERFLOW=y
14142:CONFIG_UBSAN_UNSIGNED_OVERFLOW=y
14143:CONFIG_UBSAN_OBJECT_SIZE=y
14144:CONFIG_UBSAN_BOOL=y
14145:CONFIG_UBSAN_ENUM=y
14146:CONFIG_TEST_UBSAN=m
$ llvm-nm -S out/arm64/drivers/dma/qcom/gpi.o |& rg __bad_mask
U __bad_mask
$ llvm-nm -S out/arm/drivers/dma/qcom/gpi.o |& rg __bad_mask
Applying this diff causes __bad_mask to show up:
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
index 50f1e7014693..c261adb47960 100644
--- a/drivers/dma/qcom/Makefile
+++ b/drivers/dma/qcom/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_QCOM_ADM) += qcom_adm.o
obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
obj-$(CONFIG_QCOM_GPI_DMA) += gpi.o
+UBSAN_SANITIZE_gpi.o := y
obj-$(CONFIG_QCOM_HIDMA_MGMT) += hdma_mgmt.o
hdma_mgmt-objs := hidma_mgmt.o hidma_mgmt_sys.o
obj-$(CONFIG_QCOM_HIDMA) += hdma.o
$ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 \
O=out/arm distclean allyesconfig drivers/dma/qcom/gpi.o
$ llvm-nm -S out/arm/drivers/dma/qcom/gpi.o |& rg __bad_mask
U __bad_mask
So I guess I am curious how you saw this pop up. Not to mention it seems
like that error is with GCC rather than clang?
For what it's worth, when I run that .config through olddefconfig,
CONFIG_ARCH_QCOM and CONFIG_QCOM_GPI_DMA get disabled... Am I doing
something wrong?
$ curl -LSso /tmp/out/arm/.config https://pastebin.com/raw/8UH6x4A2
$ rg "CONFIG_ARCH_QCOM|CONFIG_QCOM_GPI_DMA" /tmp/out/arm/.config
377:CONFIG_ARCH_QCOM=y
4437:CONFIG_QCOM_GPI_DMA=y
$ make.sh ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1
O=/tmp/out/arm olddefconfig
.config:364:warning: override: ARCH_DOVE changes choice state
$ rg "CONFIG_ARCH_QCOM|CONFIG_QCOM_GPI_DMA" /tmp/out/arm/.config
Cheers,
Nathan
^ permalink raw reply related [relevance 87%]
* Re: [PATCH] x86: Treat R_386_PLT32 as R_386_PC32
@ 2021-01-07 2:31 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-07 2:31 UTC (permalink / raw)
To: Fangrui Song
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, x86, linux-kernel,
clang-built-linux, Nick Desaulniers, Arnd Bergmann
On Wed, Jan 06, 2021 at 04:17:39PM -0800, Fangrui Song wrote:
> This is similar to commit b21ebf2fb4cde1618915a97cc773e287ff49173e "x86:
> Treat R_X86_64_PLT32 as R_X86_64_PC32", but for i386. As far as Linux
> kernel is concerned, R_386_PLT32 can be treated the same as R_386_PC32.
>
> R_386_PC32/R_X86_64_PC32 are PC-relative relocation types with the
> requirement that the symbol address is significant.
> R_386_PLT32/R_X86_64_PLT32 are PC-relative relocation types without the
> address significance requirement.
>
> On x86-64, there is no PIC vs non-PIC PLT distinction and an
> R_X86_64_PLT32 relocation is produced for both `call/jmp foo` and
> `call/jmp foo@PLT` with newer (2018) GNU as/LLVM integrated assembler.
>
> On i386, there are 2 types of PLTs, PIC and non-PIC. Currently the
> convention is to use R_386_PC32 for non-PIC PLT and R_386_PLT32 for PIC
> PLT, but R_386_PLT32 is arguably preferable for -fno-pic code as well:
> this can avoid a "canonical PLT entry" (st_shndx=0, st_value!=0) if the
> symbol turns out to be defined externally. Latest Clang (since
> 961f31d8ad14c66829991522d73e14b5a96ff6d4) can use R_386_PLT32 for
> compiler produced symbols (if we drop -ffreestanding for CONFIG_X86_32,
> library call optimization can produce newer declarations) and future GCC
> may use R_386_PLT32 as well if the maintainers agree to adopt an option
> like -fdirect-access-external-data to avoid "canonical PLT entry"/copy
> relocations https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/1210
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Fangrui Song <maskray@google.com>
I agree with Nick's comments about the commit message. With those
addressed:
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> arch/x86/kernel/module.c | 1 +
> arch/x86/tools/relocs.c | 2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
> index 34b153cbd4ac..5e9a34b5bd74 100644
> --- a/arch/x86/kernel/module.c
> +++ b/arch/x86/kernel/module.c
> @@ -114,6 +114,7 @@ int apply_relocate(Elf32_Shdr *sechdrs,
> *location += sym->st_value;
> break;
> case R_386_PC32:
> + case R_386_PLT32:
> /* Add the value, subtract its position */
> *location += sym->st_value - (uint32_t)location;
> break;
> diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
> index ce7188cbdae5..717e48ca28b6 100644
> --- a/arch/x86/tools/relocs.c
> +++ b/arch/x86/tools/relocs.c
> @@ -867,6 +867,7 @@ static int do_reloc32(struct section *sec, Elf_Rel *rel, Elf_Sym *sym,
> case R_386_PC32:
> case R_386_PC16:
> case R_386_PC8:
> + case R_386_PLT32:
> /*
> * NONE can be ignored and PC relative relocations don't
> * need to be adjusted.
> @@ -910,6 +911,7 @@ static int do_reloc_real(struct section *sec, Elf_Rel *rel, Elf_Sym *sym,
> case R_386_PC32:
> case R_386_PC16:
> case R_386_PC8:
> + case R_386_PLT32:
> /*
> * NONE can be ignored and PC relative relocations don't
> * need to be adjusted.
> --
> 2.29.2.729.g45daf8777d-goog
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] ubsan: disable unsigned-integer-overflow sanitizer with clang
@ 2021-01-06 21:38 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2021-01-06 21:38 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Marco Elver, Kees Cook, Arnd Bergmann, Nick Desaulniers,
Andrew Morton, George Popescu, Stephen Rothwell, LKML,
clang-built-linux
On Wed, Jan 06, 2021 at 10:12:51AM +0100, Arnd Bergmann wrote:
> On Tue, Jan 5, 2021 at 10:25 AM Arnd Bergmann <arnd@kernel.org> wrote:
> >
> > On Mon, Jan 4, 2021 at 11:33 PM Nathan Chancellor
> > <natechancellor@gmail.com> wrote:
> > > On Wed, Dec 30, 2020 at 05:13:03PM +0100, Marco Elver wrote:
> > > > On Wed, 30 Dec 2020 at 16:47, Arnd Bergmann <arnd@kernel.org> wrote:
> > > > >
> > > > > From: Arnd Bergmann <arnd@arndb.de>
> > > > >
> > > > > Building ubsan kernels even for compile-testing introduced these
> > > > > warnings in my randconfig environment:
> > > > >
> > > > > crypto/blake2b_generic.c:98:13: error: stack frame size of 9636 bytes in function 'blake2b_compress' [-Werror,-Wframe-larger-than=]
> > > > > static void blake2b_compress(struct blake2b_state *S,
> > > > > crypto/sha512_generic.c:151:13: error: stack frame size of 1292 bytes in function 'sha512_generic_block_fn' [-Werror,-Wframe-larger-than=]
> > > > > static void sha512_generic_block_fn(struct sha512_state *sst, u8 const *src,
> > > > > lib/crypto/curve25519-fiat32.c:312:22: error: stack frame size of 2180 bytes in function 'fe_mul_impl' [-Werror,-Wframe-larger-than=]
> > > > > static noinline void fe_mul_impl(u32 out[10], const u32 in1[10], const u32 in2[10])
> > > > > lib/crypto/curve25519-fiat32.c:444:22: error: stack frame size of 1588 bytes in function 'fe_sqr_impl' [-Werror,-Wframe-larger-than=]
> > > > > static noinline void fe_sqr_impl(u32 out[10], const u32 in1[10])
> > > > >
> > > > > Further testing showed that this is caused by
> > > > > -fsanitize=unsigned-integer-overflow.
> > > > >
> > > > > The one in blake2b immediately overflows the 8KB stack area on 32-bit
> > > > > architectures, so better ensure this never happens by making this
> > > > > option gcc-only.
> > >
> > > This patch also fixes the failed BUILD_BUG issue in mm/mremap.c that you
> > > sent a patch for [1], along with a couple of other issues I see such as:
> >
> > I'm fairly sure I still saw that BUILD_BUG() even after I had applied this
> > patch, I would guess that one just depends on inlining decisions that
> > are influenced by all kinds of compiler options including
> > -fsanitize=unsigned-integer-overflow, so it becomes less likely.
> >
> > I'll revert my other patch in the randconfig tree to see if it comes back.
>
> The qcom/gpi.c failure still happens with this patch applied:
>
> In file included from /git/arm-soc/drivers/dma/qcom/gpi.c:8:
> In function 'field_multiplier',
> inlined from 'gpi_update_reg' at
> /git/arm-soc/include/linux/bitfield.h:124:17:
> /git/arm-soc/include/linux/bitfield.h:119:3: error: call to
> '__bad_mask' declared with attribute error: bad bitfield mask
> 119 | __bad_mask();
> | ^~~~~~~~~~~~
> In function 'field_multiplier',
> inlined from 'gpi_update_reg' at
> /git/arm-soc/include/linux/bitfield.h:154:1:
> /git/arm-soc/include/linux/bitfield.h:119:3: error: call to
> '__bad_mask' declared with attribute error: bad bitfield mask
> 119 | __bad_mask();
> | ^~~~~~~~~~~~
>
> See https://pastebin.com/8UH6x4A2 for the .config
>
> Arnd
That config does not build for me, am I holding it wrong?
$ curl -LSso .config https://pastebin.com/raw/8UH6x4A2
$ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 olddefconfig vmlinux
.config:364:warning: override: ARCH_DOVE changes choice state
arch/arm/kernel/sys_oabi-compat.c:257:6: error: implicit declaration of function 'ep_op_has_event' [-Werror,-Wimplicit-function-declaration]
if (ep_op_has_event(op) &&
^
arch/arm/kernel/sys_oabi-compat.c:264:9: error: implicit declaration of function 'do_epoll_ctl' [-Werror,-Wimplicit-function-declaration]
return do_epoll_ctl(epfd, op, fd, &kernel, false);
^
arch/arm/kernel/sys_oabi-compat.c:264:9: note: did you mean 'sys_epoll_ctl'?
./include/linux/syscalls.h:359:17: note: 'sys_epoll_ctl' declared here
asmlinkage long sys_epoll_ctl(int epfd, int op, int fd,
^
2 errors generated.
...
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH v2 mips-next 3/4] MIPS: vmlinux.lds.S: catch bad .got, .plt and .rel.dyn at link time
@ 2021-01-06 20:23 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-06 20:23 UTC (permalink / raw)
To: Alexander Lobakin
Cc: Thomas Bogendoerfer, Kees Cook, Fangrui Song, Jiaxun Yang,
Alex Smith, Ralf Baechle, Markos Chandras, linux-mips, stable,
linux-kernel
On Wed, Jan 06, 2021 at 08:08:29PM +0000, Alexander Lobakin wrote:
> Catch any symbols placed in .got, .got.plt, .plt, .rel.dyn
> or .rela.dyn and check for these sections to be zero-sized
> at link time.
>
> At least two of them were noticed in real builds:
>
> mips-alpine-linux-musl-ld: warning: orphan section `.rel.dyn'
> from `init/main.o' being placed in section `.rel.dyn'
>
> ld.lld: warning: <internal>:(.got) is being placed in '.got'
>
> Adopted from x86/kernel/vmlinux.lds.S.
>
> Reported-by: Nathan Chancellor <natechancellor@gmail.com> # .got
> Suggested-by: Fangrui Song <maskray@google.com> # .rel.dyn
> Signed-off-by: Alexander Lobakin <alobakin@pm.me>
> ---
> arch/mips/kernel/vmlinux.lds.S | 35 ++++++++++++++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S
> index 5d6563970ab2..05eda9d9a7d5 100644
> --- a/arch/mips/kernel/vmlinux.lds.S
> +++ b/arch/mips/kernel/vmlinux.lds.S
> @@ -227,4 +227,39 @@ SECTIONS
> *(.pdr)
> *(.reginfo)
> }
> +
> + /*
> + * Sections that should stay zero sized, which is safer to
> + * explicitly check instead of blindly discarding.
> + */
> +
> + .got : {
> + *(.got)
> + *(.igot.*)
> + }
> + ASSERT(SIZEOF(.got) == 0, "Unexpected GOT entries detected!")
This assertion does trigger now.
$ make -skj"$(nproc)" ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- LLVM=1 \
O=out/mipsel distclean malta_kvm_guest_defconfig all
...
ld.lld: error: Unexpected GOT entries detected!
ld.lld: error: Unexpected GOT entries detected!
...
> + .got.plt (INFO) : {
> + *(.got.plt)
> + }
> + ASSERT(SIZEOF(.got.plt) == 0, "Unexpected GOT/PLT entries detected!")
> +
> + .plt : {
> + *(.plt)
> + *(.plt.*)
> + *(.iplt)
> + }
> + ASSERT(SIZEOF(.plt) == 0, "Unexpected run-time procedure linkages detected!")
> +
> + .rel.dyn : {
> + *(.rel.*)
> + *(.rel_*)
> + }
> + ASSERT(SIZEOF(.rel.dyn) == 0, "Unexpected run-time relocations (.rel) detected!")
> +
> + .rela.dyn : {
> + *(.rela.*)
> + *(.rela_*)
> + }
> + ASSERT(SIZEOF(.rela.dyn) == 0, "Unexpected run-time relocations (.rela) detected!")
> }
> --
> 2.30.0
>
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] cifs: check pointer before freeing
@ 2021-01-05 22:25 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-05 22:25 UTC (permalink / raw)
To: trix
Cc: sfrench, ndesaulniers, aaptel, palcantara, linux-cifs,
samba-technical, linux-kernel, clang-built-linux
On Tue, Jan 05, 2021 at 12:21:26PM -0800, trix@redhat.com wrote:
> From: Tom Rix <trix@redhat.com>
>
> clang static analysis reports this problem
>
> dfs_cache.c:591:2: warning: Argument to kfree() is a constant address
> (18446744073709551614), which is not memory allocated by malloc()
> kfree(vi);
> ^~~~~~~~~
>
> In dfs_cache_del_vol() the volume info pointer 'vi' being freed
> is the return of a call to find_vol(). The large constant address
> is find_vol() returning an error.
>
> Add an error check to dfs_cache_del_vol() similar to the one done
> in dfs_cache_update_vol().
>
> Fixes: 54be1f6c1c37 ("cifs: Add DFS cache routines")
> Signed-off-by: Tom Rix <trix@redhat.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> fs/cifs/dfs_cache.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/cifs/dfs_cache.c b/fs/cifs/dfs_cache.c
> index 6ad6ba5f6ebe..0fdb0de7ff86 100644
> --- a/fs/cifs/dfs_cache.c
> +++ b/fs/cifs/dfs_cache.c
> @@ -1260,7 +1260,8 @@ void dfs_cache_del_vol(const char *fullpath)
> vi = find_vol(fullpath);
> spin_unlock(&vol_list_lock);
>
> - kref_put(&vi->refcnt, vol_release);
> + if (!IS_ERR(vi))
> + kref_put(&vi->refcnt, vol_release);
> }
>
> /**
> --
> 2.27.0
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] docs: remove mention of ENABLE_MUST_CHECK
@ 2021-01-05 22:25 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-05 22:25 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Jonathan Corbet, Masahiro Yamada, Jason A. Donenfeld,
Nick Desaulniers, Federico Vaga, Harry Wei, Alex Shi, linux-doc
On Tue, Jan 05, 2021 at 06:58:15AM +0100, Miguel Ojeda wrote:
> We removed ENABLE_MUST_CHECK in 196793946264 ("Compiler Attributes:
> remove CONFIG_ENABLE_MUST_CHECK"), so let's remove docs' mentions.
>
> At the same time, fix the outdated text related to
> ENABLE_WARN_DEPRECATED that wasn't removed in 3337d5cfe5e08
> ("configs: get rid of obsolete CONFIG_ENABLE_WARN_DEPRECATED").
>
> Finally, reflow the paragraph.
>
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> A couple translations (it and zh) should consider updating this
> too, since they also have the mention -- Cc'ing their maintainers.
>
> Documentation/process/4.Coding.rst | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/process/4.Coding.rst b/Documentation/process/4.Coding.rst
> index c27e59d2f702..0825dc496f22 100644
> --- a/Documentation/process/4.Coding.rst
> +++ b/Documentation/process/4.Coding.rst
> @@ -249,10 +249,8 @@ features; most of these are found in the "kernel hacking" submenu. Several
> of these options should be turned on for any kernel used for development or
> testing purposes. In particular, you should turn on:
>
> - - ENABLE_MUST_CHECK and FRAME_WARN to get an
> - extra set of warnings for problems like the use of deprecated interfaces
> - or ignoring an important return value from a function. The output
> - generated by these warnings can be verbose, but one need not worry about
> + - FRAME_WARN to get warnings for stack frames larger than a given amount.
> + The output generated can be verbose, but one need not worry about
> warnings from other parts of the kernel.
>
> - DEBUG_OBJECTS will add code to track the lifetime of various objects
> --
> 2.29.2
>
^ permalink raw reply [relevance 99%]
* [PATCH] MIPS: c-r4k: Fix section mismatch for loongson2_sc_init
@ 2021-01-05 20:34 99% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-05 20:34 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: Nick Desaulniers, linux-mips, linux-kernel, clang-built-linux,
Nathan Chancellor
When building with clang, the following section mismatch warning occurs:
WARNING: modpost: vmlinux.o(.text+0x24490): Section mismatch in
reference from the function r4k_cache_init() to the function
.init.text:loongson2_sc_init()
This should have been fixed with commit ad4fddef5f23 ("mips: fix Section
mismatch in reference") but it was missed. Remove the improper __init
annotation like that commit did.
Fixes: 078a55fc824c ("MIPS: Delete __cpuinit/__CPUINIT usage from MIPS code")
Link: https://github.com/ClangBuiltLinux/linux/issues/787
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
arch/mips/mm/c-r4k.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
index 4f976d687ab0..f67297b3175f 100644
--- a/arch/mips/mm/c-r4k.c
+++ b/arch/mips/mm/c-r4k.c
@@ -1593,7 +1593,7 @@ static int probe_scache(void)
return 1;
}
-static void __init loongson2_sc_init(void)
+static void loongson2_sc_init(void)
{
struct cpuinfo_mips *c = ¤t_cpu_data;
base-commit: 36bbbd0e234d817938bdc52121a0f5473b3e58f5
--
2.30.0
^ permalink raw reply related [relevance 99%]
* [PATCH] MIPS: Use address-of operator on section symbols
@ 2021-01-05 20:18 89% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-05 20:18 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: Florian Fainelli, John Crispin, Nick Desaulniers,
bcm-kernel-feedback-list, linux-mips, linux-kernel,
clang-built-linux, Nathan Chancellor
When building xway_defconfig with clang:
arch/mips/lantiq/prom.c:82:23: error: array comparison always evaluates
to true [-Werror,-Wtautological-compare]
else if (__dtb_start != __dtb_end)
^
1 error generated.
These are not true arrays, they are linker defined symbols, which are
just addresses. Using the address of operator silences the warning
and does not change the resulting assembly with either clang/ld.lld
or gcc/ld (tested with diff + objdump -Dr). Do the same thing across
the entire MIPS subsystem to ensure there are no more warnings around
this type of comparison.
Link: https://github.com/ClangBuiltLinux/linux/issues/1232
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
arch/mips/bmips/setup.c | 2 +-
arch/mips/lantiq/prom.c | 2 +-
arch/mips/pic32/pic32mzda/init.c | 2 +-
arch/mips/ralink/of.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/mips/bmips/setup.c b/arch/mips/bmips/setup.c
index 19308df5f577..1b06b25aea87 100644
--- a/arch/mips/bmips/setup.c
+++ b/arch/mips/bmips/setup.c
@@ -167,7 +167,7 @@ void __init plat_mem_setup(void)
dtb = phys_to_virt(fw_arg2);
else if (fw_passed_dtb) /* UHI interface or appended dtb */
dtb = (void *)fw_passed_dtb;
- else if (__dtb_start != __dtb_end)
+ else if (&__dtb_start != &__dtb_end)
dtb = (void *)__dtb_start;
else
panic("no dtb found");
diff --git a/arch/mips/lantiq/prom.c b/arch/mips/lantiq/prom.c
index 51a218f04fe0..3f568f5aae2d 100644
--- a/arch/mips/lantiq/prom.c
+++ b/arch/mips/lantiq/prom.c
@@ -79,7 +79,7 @@ void __init plat_mem_setup(void)
if (fw_passed_dtb) /* UHI interface */
dtb = (void *)fw_passed_dtb;
- else if (__dtb_start != __dtb_end)
+ else if (&__dtb_start != &__dtb_end)
dtb = (void *)__dtb_start;
else
panic("no dtb found");
diff --git a/arch/mips/pic32/pic32mzda/init.c b/arch/mips/pic32/pic32mzda/init.c
index 50f376f058f4..f232c77ff526 100644
--- a/arch/mips/pic32/pic32mzda/init.c
+++ b/arch/mips/pic32/pic32mzda/init.c
@@ -28,7 +28,7 @@ static ulong get_fdtaddr(void)
if (fw_passed_dtb && !fw_arg2 && !fw_arg3)
return (ulong)fw_passed_dtb;
- if (__dtb_start < __dtb_end)
+ if (&__dtb_start < &__dtb_end)
ftaddr = (ulong)__dtb_start;
return ftaddr;
diff --git a/arch/mips/ralink/of.c b/arch/mips/ralink/of.c
index cbae9d23ab7f..2c9af61efc20 100644
--- a/arch/mips/ralink/of.c
+++ b/arch/mips/ralink/of.c
@@ -75,7 +75,7 @@ void __init plat_mem_setup(void)
*/
if (fw_passed_dtb)
dtb = (void *)fw_passed_dtb;
- else if (__dtb_start != __dtb_end)
+ else if (&__dtb_start != &__dtb_end)
dtb = (void *)__dtb_start;
__dt_setup_arch(dtb);
base-commit: 36bbbd0e234d817938bdc52121a0f5473b3e58f5
--
2.30.0
^ permalink raw reply related [relevance 89%]
* [PATCH] MIPS: lantiq: Explicitly compare LTQ_EBU_PCC_ISTAT against 0
@ 2021-01-05 20:15 96% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-05 20:15 UTC (permalink / raw)
To: John Crispin, Thomas Bogendoerfer
Cc: Nick Desaulniers, linux-mips, linux-kernel, clang-built-linux,
Nathan Chancellor, Dmitry Golovin
When building xway_defconfig with clang:
arch/mips/lantiq/irq.c:305:48: error: use of logical '&&' with constant
operand [-Werror,-Wconstant-logical-operand]
if ((irq == LTQ_ICU_EBU_IRQ) && (module == 0) && LTQ_EBU_PCC_ISTAT)
^ ~~~~~~~~~~~~~~~~~
arch/mips/lantiq/irq.c:305:48: note: use '&' for a bitwise operation
if ((irq == LTQ_ICU_EBU_IRQ) && (module == 0) && LTQ_EBU_PCC_ISTAT)
^~
&
arch/mips/lantiq/irq.c:305:48: note: remove constant to silence this
warning
if ((irq == LTQ_ICU_EBU_IRQ) && (module == 0) && LTQ_EBU_PCC_ISTAT)
~^~~~~~~~~~~~~~~~~~~~
1 error generated.
Explicitly compare the constant LTQ_EBU_PCC_ISTAT against 0 to fix the
warning. Additionally, remove the unnecessary parentheses as this is a
simple conditional statement and shorthand '== 0' to '!'.
Fixes: 3645da0276ae ("OF: MIPS: lantiq: implement irq_domain support")
Link: https://github.com/ClangBuiltLinux/linux/issues/807
Reported-by: Dmitry Golovin <dima@golovin.in>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
arch/mips/lantiq/irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/lantiq/irq.c b/arch/mips/lantiq/irq.c
index df8eed3875f6..43c2f271e6ab 100644
--- a/arch/mips/lantiq/irq.c
+++ b/arch/mips/lantiq/irq.c
@@ -302,7 +302,7 @@ static void ltq_hw_irq_handler(struct irq_desc *desc)
generic_handle_irq(irq_linear_revmap(ltq_domain, hwirq));
/* if this is a EBU irq, we need to ack it or get a deadlock */
- if ((irq == LTQ_ICU_EBU_IRQ) && (module == 0) && LTQ_EBU_PCC_ISTAT)
+ if (irq == LTQ_ICU_EBU_IRQ && !module && LTQ_EBU_PCC_ISTAT != 0)
ltq_ebu_w32(ltq_ebu_r32(LTQ_EBU_PCC_ISTAT) | 0x10,
LTQ_EBU_PCC_ISTAT);
}
base-commit: 36bbbd0e234d817938bdc52121a0f5473b3e58f5
--
2.30.0
^ permalink raw reply related [relevance 96%]
* Re: [PATCH mips-next 0/4] MIPS: vmlinux.lds.S sections fix & cleanup
@ 2021-01-05 0:09 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-05 0:09 UTC (permalink / raw)
To: Alexander Lobakin
Cc: Thomas Bogendoerfer, Kees Cook, Ingo Molnar, Fangrui Song,
Jiaxun Yang, Ralf Baechle, Alex Smith, Markos Chandras,
linux-mips, stable, linux-kernel, clang-built-linux
On Mon, Jan 04, 2021 at 12:18:10PM +0000, Alexander Lobakin wrote:
> This series hunts the problems discovered after manual enabling of
> ARCH_WANT_LD_ORPHAN_WARN, notably the missing PAGE_ALIGNED_DATA()
> section affecting VDSO placement (marked for stable).
>
> Compile and runtime tested on MIPS32R2 CPS board with no issues.
>
> Alexander Lobakin (4):
> MIPS: vmlinux.lds.S: add missing PAGE_ALIGNED_DATA() section
> MIPS: vmlinux.lds.S: add ".rel.dyn" to DISCARDS
> MIPS: vmlinux.lds.S: add ".gnu.attributes" to DISCARDS
> MIPS: select ARCH_WANT_LD_ORPHAN_WARN
>
> arch/mips/Kconfig | 1 +
> arch/mips/kernel/vmlinux.lds.S | 5 ++++-
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> --
> 2.30.0
>
Glad to see ARCH_WANT_LD_ORPHAN_WARN catching on :)
I took this for a spin with clang with malta_kvm_guest_defconfig and I
only see one section unaccounted for:
$ make -skj"$(nproc)" ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- LLVM=1 O=out/mips distclean malta_kvm_guest_defconfig all
...
ld.lld: warning: <internal>:(.got) is being placed in '.got'
ld.lld: warning: <internal>:(.got) is being placed in '.got'
ld.lld: warning: <internal>:(.got) is being placed in '.got'
Looks like most architectures place it in .got (ia64, nios2, powerpc)
or .text (arm64).
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* [PATCH] powerpc: Handle .text.{hot,unlikely}.* in linker script
@ 2021-01-04 20:48 94% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-04 20:48 UTC (permalink / raw)
To: Michael Ellerman
Cc: Benjamin Herrenschmidt, Paul Mackerras, Nick Desaulniers,
linuxppc-dev, linux-kernel, clang-built-linux, Nathan Chancellor,
stable
Commit eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input
sections") added ".text.unlikely.*" and ".text.hot.*" due to an LLVM
change [1].
After another LLVM change [2], these sections are seen in some PowerPC
builds, where there is a orphan section warning then build failure:
$ make -skj"$(nproc)" \
ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- LLVM=1 O=out \
distclean powernv_defconfig zImage.epapr
ld.lld: warning: kernel/built-in.a(panic.o):(.text.unlikely.) is being placed in '.text.unlikely.'
...
ld.lld: warning: address (0xc000000000009314) of section .text is not a multiple of alignment (256)
...
ERROR: start_text address is c000000000009400, should be c000000000008000
ERROR: try to enable LD_HEAD_STUB_CATCH config option
ERROR: see comments in arch/powerpc/tools/head_check.sh
...
Explicitly handle these sections like in the main linker script so
there is no more build failure.
Cc: stable@vger.kernel.org
Fixes: 83a092cf95f2 ("powerpc: Link warning for orphan sections")
Link: https://github.com/ClangBuiltLinux/linux/issues/1218
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
arch/powerpc/kernel/vmlinux.lds.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index 0318ba436f34..8e0b1298bf19 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -85,7 +85,7 @@ SECTIONS
ALIGN_FUNCTION();
#endif
/* careful! __ftr_alt_* sections need to be close to .text */
- *(.text.hot TEXT_MAIN .text.fixup .text.unlikely .fixup __ftr_alt_* .ref.text);
+ *(.text.hot .text.hot.* TEXT_MAIN .text.fixup .text.unlikely .text.unlikely.* .fixup __ftr_alt_* .ref.text);
#ifdef CONFIG_PPC64
*(.tramp.ftrace.text);
#endif
base-commit: d8a4f20584d5906093a8fc6aa06622102a501095
--
2.30.0
^ permalink raw reply related [relevance 93%]
* [PATCH v2] powerpc: Handle .text.{hot,unlikely}.* in linker script
2021-01-04 20:48 94% ` Nathan Chancellor
@ 2021-01-04 20:59 92% ` Nathan Chancellor
-1 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-04 20:59 UTC (permalink / raw)
To: Michael Ellerman
Cc: Benjamin Herrenschmidt, Paul Mackerras, Nick Desaulniers,
linuxppc-dev, linux-kernel, clang-built-linux, Nathan Chancellor,
stable
Commit eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input
sections") added ".text.unlikely.*" and ".text.hot.*" due to an LLVM
change [1].
After another LLVM change [2], these sections are seen in some PowerPC
builds, where there is a orphan section warning then build failure:
$ make -skj"$(nproc)" \
ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- LLVM=1 O=out \
distclean powernv_defconfig zImage.epapr
ld.lld: warning: kernel/built-in.a(panic.o):(.text.unlikely.) is being placed in '.text.unlikely.'
...
ld.lld: warning: address (0xc000000000009314) of section .text is not a multiple of alignment (256)
...
ERROR: start_text address is c000000000009400, should be c000000000008000
ERROR: try to enable LD_HEAD_STUB_CATCH config option
ERROR: see comments in arch/powerpc/tools/head_check.sh
...
Explicitly handle these sections like in the main linker script so
there is no more build failure.
[1]: https://reviews.llvm.org/D79600
[2]: https://reviews.llvm.org/D92493
Cc: stable@vger.kernel.org
Fixes: 83a092cf95f2 ("powerpc: Link warning for orphan sections")
Link: https://github.com/ClangBuiltLinux/linux/issues/1218
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
v1 -> v2:
* Add missing [1] and [2] references in commit message. Thanks to Sedat
Dilek for pointing it out!
arch/powerpc/kernel/vmlinux.lds.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index 0318ba436f34..8e0b1298bf19 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -85,7 +85,7 @@ SECTIONS
ALIGN_FUNCTION();
#endif
/* careful! __ftr_alt_* sections need to be close to .text */
- *(.text.hot TEXT_MAIN .text.fixup .text.unlikely .fixup __ftr_alt_* .ref.text);
+ *(.text.hot .text.hot.* TEXT_MAIN .text.fixup .text.unlikely .text.unlikely.* .fixup __ftr_alt_* .ref.text);
#ifdef CONFIG_PPC64
*(.tramp.ftrace.text);
#endif
base-commit: d8a4f20584d5906093a8fc6aa06622102a501095
--
2.30.0
^ permalink raw reply related [relevance 92%]
* Re: [PATCH] percpu: fix clang modpost warning in pcpu_build_alloc_info()
@ 2021-01-04 23:46 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-04 23:46 UTC (permalink / raw)
To: Dennis Zhou
Cc: Tejun Heo, Christoph Lameter, linux-mm, linux-kernel,
clang-built-linux, kbuild-all, kernel test robot
On Thu, Dec 31, 2020 at 09:28:52PM +0000, Dennis Zhou wrote:
> This is an unusual situation so I thought it best to explain it in a
> separate patch.
>
> "percpu: reduce the number of cpu distance comparisons" introduces a
> dependency on cpumask helper functions in __init code. This code
> references a struct cpumask annotated __initdata. When the function is
> inlined (gcc), everything is fine, but clang decides not to inline these
> function calls. This causes modpost to warn about an __initdata access
> by a function not annotated with __init [1].
>
> Ways I thought about fixing it:
> 1. figure out why clang thinks this inlining is too costly.
> 2. create a wrapper function annotated __init (this).
> 3. annotate cpumask with __refdata.
>
> Ultimately it comes down to if it's worth saving the cpumask memory and
> allowing it to be freed. IIUC, __refdata won't be freed, so option 3 is
> just a little wasteful. 1 is out of my depth, leaving 2. I don't feel
> great about this behavior being dependent on inlining semantics, but
> cpumask helpers are small and probably should be inlined.
>
> modpost complaint:
> WARNING: modpost: vmlinux.o(.text+0x735425): Section mismatch in reference from the function cpumask_clear_cpu() to the variable .init.data:pcpu_build_alloc_info.mask
> The function cpumask_clear_cpu() references
> the variable __initdata pcpu_build_alloc_info.mask.
> This is often because cpumask_clear_cpu lacks a __initdata
> annotation or the annotation of pcpu_build_alloc_info.mask is wrong.
>
> clang output:
> mm/percpu.c:2724:5: remark: cpumask_clear_cpu not inlined into pcpu_build_alloc_info because too costly to inline (cost=725, threshold=325) [-Rpass-missed=inline]
>
> [1] https://lore.kernel.org/linux-mm/202012220454.9F6Bkz9q-lkp@intel.com/
>
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Dennis Zhou <dennis@kernel.org>
> ---
> This is on top of percpu#for-5.12.
>
> mm/percpu.c | 16 ++++++++++++++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/mm/percpu.c b/mm/percpu.c
> index 80f8f885a990..357977c4cb00 100644
> --- a/mm/percpu.c
> +++ b/mm/percpu.c
> @@ -2642,6 +2642,18 @@ early_param("percpu_alloc", percpu_alloc_setup);
>
> /* pcpu_build_alloc_info() is used by both embed and page first chunk */
> #if defined(BUILD_EMBED_FIRST_CHUNK) || defined(BUILD_PAGE_FIRST_CHUNK)
> +
> +/*
> + * This wrapper is to avoid a warning where cpumask_clear_cpu() is not inlined
> + * when compiling with clang causing modpost to warn about accessing __initdata
> + * from a non __init function. By doing this, we allow the struct cpumask to be
> + * freed instead of it taking space by annotating with __refdata.
> + */
> +static void __init pcpu_cpumask_clear_cpu(int cpu, struct cpumask *mask)
> +{
> + cpumask_clear_cpu(cpu, mask);
> +}
> +
> /**
> * pcpu_build_alloc_info - build alloc_info considering distances between CPUs
> * @reserved_size: the size of reserved percpu area in bytes
> @@ -2713,7 +2725,7 @@ static struct pcpu_alloc_info * __init pcpu_build_alloc_info(
> cpu = cpumask_first(&mask);
> group_map[cpu] = group;
> group_cnt[group]++;
> - cpumask_clear_cpu(cpu, &mask);
> + pcpu_cpumask_clear_cpu(cpu, &mask);
>
> for_each_cpu(tcpu, &mask) {
> if (!cpu_distance_fn ||
> @@ -2721,7 +2733,7 @@ static struct pcpu_alloc_info * __init pcpu_build_alloc_info(
> cpu_distance_fn(tcpu, cpu) == LOCAL_DISTANCE)) {
> group_map[tcpu] = group;
> group_cnt[group]++;
> - cpumask_clear_cpu(tcpu, &mask);
> + pcpu_cpumask_clear_cpu(tcpu, &mask);
> }
> }
> }
> --
> 2.29.2.729.g45daf8777d-goog
>
Hi Dennis,
I did a bisect of the problematic config against defconfig and it points
out that CONFIG_GCOV_PROFILE_ALL is in the bad config but not the good
config, which makes some sense as that will mess with clang's inlining
heuristics. It does not appear to be the single config that makes a
difference but it gives some clarity.
I do not personally have any strong opinions around the patch but is it
really that much wasted memory to just annotate mask with __refdata?
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] powerpc: Handle .text.{hot,unlikely}.* in linker script
@ 2021-01-04 20:57 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-04 20:57 UTC (permalink / raw)
To: Sedat Dilek
Cc: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Nick Desaulniers, linuxppc-dev, linux-kernel,
Clang-Built-Linux ML, stable
On Mon, Jan 04, 2021 at 09:55:20PM +0100, Sedat Dilek wrote:
> On Mon, Jan 4, 2021 at 9:49 PM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> >
> > Commit eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input
> > sections") added ".text.unlikely.*" and ".text.hot.*" due to an LLVM
> > change [1].
> >
> > After another LLVM change [2], these sections are seen in some PowerPC
> > builds, where there is a orphan section warning then build failure:
> >
>
> Looks like you forgot to add your references/links to [1] and [2].
Indeed, thank you for pointing that out! v2 coming shortly.
> Might be good to mention...?
>
> With CONFIG_LD_ORPHAN_WARN=y is enabled
Since this symbol is not user selectable, I do not really think it is
worth mentioning, plus PowerPC has had this enabled for a while :)
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] ubsan: disable unsigned-integer-overflow sanitizer with clang
@ 2021-01-04 22:33 99% ` Nathan Chancellor
0 siblings, 2 replies; 200+ results
From: Nathan Chancellor @ 2021-01-04 22:33 UTC (permalink / raw)
To: Marco Elver
Cc: Arnd Bergmann, Kees Cook, Arnd Bergmann, Nick Desaulniers,
Andrew Morton, George Popescu, Stephen Rothwell, LKML,
clang-built-linux
On Wed, Dec 30, 2020 at 05:13:03PM +0100, Marco Elver wrote:
> On Wed, 30 Dec 2020 at 16:47, Arnd Bergmann <arnd@kernel.org> wrote:
> >
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > Building ubsan kernels even for compile-testing introduced these
> > warnings in my randconfig environment:
> >
> > crypto/blake2b_generic.c:98:13: error: stack frame size of 9636 bytes in function 'blake2b_compress' [-Werror,-Wframe-larger-than=]
> > static void blake2b_compress(struct blake2b_state *S,
> > crypto/sha512_generic.c:151:13: error: stack frame size of 1292 bytes in function 'sha512_generic_block_fn' [-Werror,-Wframe-larger-than=]
> > static void sha512_generic_block_fn(struct sha512_state *sst, u8 const *src,
> > lib/crypto/curve25519-fiat32.c:312:22: error: stack frame size of 2180 bytes in function 'fe_mul_impl' [-Werror,-Wframe-larger-than=]
> > static noinline void fe_mul_impl(u32 out[10], const u32 in1[10], const u32 in2[10])
> > lib/crypto/curve25519-fiat32.c:444:22: error: stack frame size of 1588 bytes in function 'fe_sqr_impl' [-Werror,-Wframe-larger-than=]
> > static noinline void fe_sqr_impl(u32 out[10], const u32 in1[10])
> >
> > Further testing showed that this is caused by
> > -fsanitize=unsigned-integer-overflow.
> >
> > The one in blake2b immediately overflows the 8KB stack area on 32-bit
> > architectures, so better ensure this never happens by making this
> > option gcc-only.
This patch also fixes the failed BUILD_BUG issue in mm/mremap.c that you
sent a patch for [1], along with a couple of other issues I see such as:
ld.lld: error: undefined symbol: __bad_mask
>>> referenced by gpi.c
>>> dma/qcom/gpi.o:(gpi_update_reg) in archive
>>> drivers/built-in.a
>>> referenced by gpi.c
>>> dma/qcom/gpi.o:(gpi_update_reg) in archive
>>> drivers/built-in.a
[1]: https://lore.kernel.org/lkml/20201230154104.522605-1-arnd@kernel.org/
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> > Fixes: d0a3ac549f38 ("ubsan: enable for all*config builds")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> > lib/Kconfig.ubsan | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
> > index 8b635fd75fe4..e23873282ba7 100644
> > --- a/lib/Kconfig.ubsan
> > +++ b/lib/Kconfig.ubsan
> > @@ -122,6 +122,8 @@ config UBSAN_SIGNED_OVERFLOW
> >
> > config UBSAN_UNSIGNED_OVERFLOW
> > bool "Perform checking for unsigned arithmetic overflow"
> > + # clang hugely expands stack usage with -fsanitize=object-size
>
> This is the first time -fsanitize=object-size is mentioned. Typo?
Copy and paste issue from CONFIG_UBSAN_OBJECT_SIZE
> > + depends on !CC_IS_CLANG
> > depends on $(cc-option,-fsanitize=unsigned-integer-overflow)
> > help
> > This option enables -fsanitize=unsigned-integer-overflow which checks
> > --
> > 2.29.2
> >
^ permalink raw reply [relevance 99%]
* Re: [PATCH] mm/mremap: fix BUILD_BUG_ON() error in get_extent
@ 2021-01-04 22:36 99% ` Nathan Chancellor
2021-01-12 19:16 99% ` Nathan Chancellor
1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-04 22:36 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andrew Morton, Nick Desaulniers, Kirill A. Shutemov, Wei Yang,
Arnd Bergmann, Vlastimil Babka, Dmitry Safonov, Brian Geffon,
linux-mm, linux-kernel, clang-built-linux
On Wed, Dec 30, 2020 at 04:40:40PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> clang cannt evaluate this function argument at compile time
> when the function is not inlined, which leads to a link
> time failure:
>
> ld.lld: error: undefined symbol: __compiletime_assert_414
> >>> referenced by mremap.c
> >>> mremap.o:(get_extent) in archive mm/built-in.a
>
> Mark the function as __always_inline to avoid it.
>
> Fixes: 9ad9718bfa41 ("mm/mremap: calculate extent in one place")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> mm/mremap.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/mm/mremap.c b/mm/mremap.c
> index c5590afe7165..1cb464a07184 100644
> --- a/mm/mremap.c
> +++ b/mm/mremap.c
> @@ -336,8 +336,9 @@ enum pgt_entry {
> * valid. Else returns a smaller extent bounded by the end of the source and
> * destination pgt_entry.
> */
> -static unsigned long get_extent(enum pgt_entry entry, unsigned long old_addr,
> - unsigned long old_end, unsigned long new_addr)
> +static __always_inline unsigned long get_extent(enum pgt_entry entry,
> + unsigned long old_addr, unsigned long old_end,
> + unsigned long new_addr)
> {
> unsigned long next, extent, mask, size;
>
> --
> 2.29.2
>
I am in agreement with Vlastimil, I would rather see the BUILD_BUG()
dropped or converted into BUG() instead of papering over with
__always_inline. For what it's worth, I only see this build failure
with CONFIG_UBSAN_UNSIGNED_OVERFLOW, which you proposed disabling:
https://lore.kernel.org/lkml/20201230154749.746641-1-arnd@kernel.org/
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] ubsan: disable unsigned-integer-overflow sanitizer with clang
@ 2021-01-04 23:34 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-04 23:34 UTC (permalink / raw)
To: Andrew Morton
Cc: Marco Elver, Arnd Bergmann, Kees Cook, Arnd Bergmann,
Nick Desaulniers, George Popescu, Stephen Rothwell, LKML,
clang-built-linux
On Mon, Jan 04, 2021 at 03:33:33PM -0800, Andrew Morton wrote:
> On Mon, 4 Jan 2021 15:33:36 -0700 Nathan Chancellor <natechancellor@gmail.com> wrote:
>
> > > > +++ b/lib/Kconfig.ubsan
> > > > @@ -122,6 +122,8 @@ config UBSAN_SIGNED_OVERFLOW
> > > >
> > > > config UBSAN_UNSIGNED_OVERFLOW
> > > > bool "Perform checking for unsigned arithmetic overflow"
> > > > + # clang hugely expands stack usage with -fsanitize=object-size
> > >
> > > This is the first time -fsanitize=object-size is mentioned. Typo?
> >
> > Copy and paste issue from CONFIG_UBSAN_OBJECT_SIZE
>
> This?
Correct.
> --- a/lib/Kconfig.ubsan~ubsan-disable-unsigned-integer-overflow-sanitizer-with-clang-fix
> +++ a/lib/Kconfig.ubsan
> @@ -122,7 +122,7 @@ config UBSAN_SIGNED_OVERFLOW
>
> config UBSAN_UNSIGNED_OVERFLOW
> bool "Perform checking for unsigned arithmetic overflow"
> - # clang hugely expands stack usage with -fsanitize=object-size
> + # clang hugely expands stack usage with -fsanitize=unsigned-integer-overflow
> depends on !CC_IS_CLANG
> depends on $(cc-option,-fsanitize=unsigned-integer-overflow)
> help
> _
>
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] jffs2: fix use after free in jffs2_sum_write_data()
@ 2021-01-04 22:16 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-04 22:16 UTC (permalink / raw)
To: trix
Cc: dwmw2, richard, ndesaulniers, linux-mtd, linux-kernel, clang-built-linux
On Wed, Dec 30, 2020 at 06:56:04AM -0800, trix@redhat.com wrote:
> From: Tom Rix <trix@redhat.com>
>
> clang static analysis reports this problem
>
> fs/jffs2/summary.c:794:31: warning: Use of memory after it is freed
> c->summary->sum_list_head = temp->u.next;
> ^~~~~~~~~~~~
>
> In jffs2_sum_write_data(), in a loop summary data is handles a node at
> a time. When it has written out the node it is removed the summary list,
> and the node is deleted. In the corner case when a
> JFFS2_FEATURE_RWCOMPAT_COPY is seen, a call is made to
> jffs2_sum_disable_collecting(). jffs2_sum_disable_collecting() deletes
> the whole list which conflicts with the loop's deleting the list by parts.
>
> To preserve the old behavior of stopping the write midway, bail out of
> the loop after disabling summary collection.
>
> Fixes: 6171586a7ae5 ("[JFFS2] Correct handling of JFFS2_FEATURE_RWCOMPAT_COPY nodes.")
> Signed-off-by: Tom Rix <trix@redhat.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> fs/jffs2/summary.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/fs/jffs2/summary.c b/fs/jffs2/summary.c
> index be7c8a6a5748..4fe64519870f 100644
> --- a/fs/jffs2/summary.c
> +++ b/fs/jffs2/summary.c
> @@ -783,6 +783,8 @@ static int jffs2_sum_write_data(struct jffs2_sb_info *c, struct jffs2_eraseblock
> dbg_summary("Writing unknown RWCOMPAT_COPY node type %x\n",
> je16_to_cpu(temp->u.nodetype));
> jffs2_sum_disable_collecting(c->summary);
> + /* The above call removes the list, nothing more to do */
> + goto bail_rwcompat;
> } else {
> BUG(); /* unknown node in summary information */
> }
> @@ -794,6 +796,7 @@ static int jffs2_sum_write_data(struct jffs2_sb_info *c, struct jffs2_eraseblock
>
> c->summary->sum_num--;
> }
> + bail_rwcompat:
>
> jffs2_sum_reset_collected(c->summary);
>
> --
> 2.27.0
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH v3 2/2] Kbuild: implement support for DWARF v5
@ 2021-01-04 22:12 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-04 22:12 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Masahiro Yamada, Arvind Sankar, Jakub Jelinek, Fangrui Song,
Caroline Tice, clang-built-linux, Nick Clifton, Michal Marek,
Arnd Bergmann, Andrew Morton, Randy Dunlap, Changbin Du, peterz,
Thomas Gleixner, Krzysztof Kozlowski, linux-kbuild, linux-kernel,
linux-arch
On Thu, Dec 03, 2020 at 05:11:27PM -0800, Nick Desaulniers wrote:
> DWARF v5 is the latest standard of the DWARF debug info format.
>
> Feature detection of DWARF5 is onerous, especially given that we've
> removed $(AS), so we must query $(CC) for DWARF5 assembler directive
> support. GNU `as` only recently gained support for specifying
> -gdwarf-5.
>
> The DWARF version of a binary can be validated with:
> $ llvm-dwarfdump vmlinux | head -n 4 | grep version
> or
> $ readelf --debug-dump=info vmlinux 2>/dev/null | grep Version
>
> DWARF5 wins significantly in terms of size when mixed with compression
> (CONFIG_DEBUG_INFO_COMPRESSED).
>
> 363M vmlinux.clang12.dwarf5.compressed
> 434M vmlinux.clang12.dwarf4.compressed
> 439M vmlinux.clang12.dwarf2.compressed
> 457M vmlinux.clang12.dwarf5
> 536M vmlinux.clang12.dwarf4
> 548M vmlinux.clang12.dwarf2
>
> 515M vmlinux.gcc10.2.dwarf5.compressed
> 599M vmlinux.gcc10.2.dwarf4.compressed
> 624M vmlinux.gcc10.2.dwarf2.compressed
> 630M vmlinux.gcc10.2.dwarf5
> 765M vmlinux.gcc10.2.dwarf4
> 809M vmlinux.gcc10.2.dwarf2
>
> Though the quality of debug info is harder to quantify; size is not a
> proxy for quality.
>
> Jakub notes:
> All [GCC] 5.1 - 6.x did was start accepting -gdwarf-5 as experimental
> option that enabled some small DWARF subset (initially only a few
> DW_LANG_* codes newly added to DWARF5 drafts). Only GCC 7 (released
> after DWARF 5 has been finalized) started emitting DWARF5 section
> headers and got most of the DWARF5 changes in...
>
> Version check GCC so that we don't need to worry about the difference in
> command line args between GNU readelf and llvm-readelf/llvm-dwarfdump to
> validate the DWARF Version in the assembler feature detection script.
>
> Link: http://www.dwarfstd.org/doc/DWARF5.pdf
> Suggested-by: Arvind Sankar <nivedita@alum.mit.edu>
> Suggested-by: Jakub Jelinek <jakub@redhat.com>
> Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
> Suggested-by: Fangrui Song <maskray@google.com>
> Suggested-by: Caroline Tice <cmtice@google.com>
> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> Makefile | 1 +
> include/asm-generic/vmlinux.lds.h | 6 +++++-
> lib/Kconfig.debug | 14 ++++++++++++++
> scripts/test_dwarf5_support.sh | 9 +++++++++
> 4 files changed, 29 insertions(+), 1 deletion(-)
> create mode 100755 scripts/test_dwarf5_support.sh
>
> diff --git a/Makefile b/Makefile
> index 2430e1ee7c44..45231f6c1935 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -828,6 +828,7 @@ endif
>
> dwarf-version-$(CONFIG_DEBUG_INFO_DWARF2) := 2
> dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
> +dwarf-version-$(CONFIG_DEBUG_INFO_DWARF5) := 5
> DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y)
> ifneq ($(dwarf-version-y)$(LLVM_IAS),21)
> # Binutils 2.35+ required for -gdwarf-4+ support.
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index b2b3d81b1535..76ce62c77029 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -829,7 +829,11 @@
> .debug_types 0 : { *(.debug_types) } \
> /* DWARF 5 */ \
> .debug_macro 0 : { *(.debug_macro) } \
> - .debug_addr 0 : { *(.debug_addr) }
> + .debug_addr 0 : { *(.debug_addr) } \
> + .debug_line_str 0 : { *(.debug_line_str) } \
> + .debug_loclists 0 : { *(.debug_loclists) } \
> + .debug_rnglists 0 : { *(.debug_rnglists) } \
> + .debug_str_offsets 0 : { *(.debug_str_offsets) }
>
> /* Stabs debugging sections. */
> #define STABS_DEBUG \
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 04719294a7a3..987815771ad6 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -274,6 +274,20 @@ config DEBUG_INFO_DWARF4
> It makes the debug information larger, but it significantly
> improves the success of resolving variables in gdb on optimized code.
>
> +config DEBUG_INFO_DWARF5
> + bool "Generate DWARF Version 5 debuginfo"
> + depends on GCC_VERSION >= 70000 || CC_IS_CLANG
> + depends on $(success,$(srctree)/scripts/test_dwarf5_support.sh $(CC) $(CLANG_FLAGS))
> + help
> + Generate DWARF v5 debug info. Requires binutils 2.35, gcc 7.0+, and
> + gdb 8.0+. Changes to the structure of debug info in Version 5 allow
> + for around 15-18% savings in resulting image and debug info section sizes
> + as compared to DWARF Version 4. DWARF Version 5 standardizes previous
> + extensions such as accelerators for symbol indexing and the format for
> + fission (.dwo/.dwp) files. Users may not want to select this config if
> + they rely on tooling that has not yet been updated to support
> + DWARF Version 5.
> +
> endchoice # "DWARF version"
>
> config DEBUG_INFO_BTF
> diff --git a/scripts/test_dwarf5_support.sh b/scripts/test_dwarf5_support.sh
> new file mode 100755
> index 000000000000..156ad5ec4274
> --- /dev/null
> +++ b/scripts/test_dwarf5_support.sh
> @@ -0,0 +1,9 @@
> +#!/bin/sh
> +# SPDX-License-Identifier: GPL-2.0
> +
> +# Test that assembler accepts -gdwarf-5 and .file 0 directives, which were bugs
> +# in binutils < 2.35.
> +# https://sourceware.org/bugzilla/show_bug.cgi?id=25612
> +# https://sourceware.org/bugzilla/show_bug.cgi?id=25614
> +set -e
> +echo '.file 0 "filename"' | $* -Wa,-gdwarf-5 -c -x assembler -o /dev/null -
> --
> 2.29.2.576.ga3fc446d84-goog
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH v3 1/2] Kbuild: make DWARF version a choice
@ 2021-01-04 22:03 99% ` Nathan Chancellor
1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-04 22:03 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Masahiro Yamada, Arvind Sankar, Jakub Jelinek, Fangrui Song,
Caroline Tice, clang-built-linux, Nick Clifton, Michal Marek,
Andrew Morton, Randy Dunlap, peterz, Thomas Gleixner,
Krzysztof Kozlowski, linux-kbuild, linux-kernel
On Thu, Dec 03, 2020 at 05:11:26PM -0800, 'Nick Desaulniers' via Clang Built Linux wrote:
> Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice. Adds an
> explicit CONFIG_DEBUG_INFO_DWARF2, which is the default. Does so in a
> way that's forward compatible with existing configs, and makes adding
> future versions more straightforward.
>
> Suggested-by: Fangrui Song <maskray@google.com>
> Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> Makefile | 14 ++++++++------
> lib/Kconfig.debug | 21 ++++++++++++++++-----
> 2 files changed, 24 insertions(+), 11 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index a2ded5029084..2430e1ee7c44 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -826,12 +826,14 @@ else
> DEBUG_CFLAGS += -g
> endif
>
> -ifneq ($(LLVM_IAS),1)
> -KBUILD_AFLAGS += -Wa,-gdwarf-2
> -endif
> -
> -ifdef CONFIG_DEBUG_INFO_DWARF4
> -DEBUG_CFLAGS += -gdwarf-4
> +dwarf-version-$(CONFIG_DEBUG_INFO_DWARF2) := 2
> +dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4
> +DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y)
> +ifneq ($(dwarf-version-y)$(LLVM_IAS),21)
> +# Binutils 2.35+ required for -gdwarf-4+ support.
> +dwarf-aflag := $(call as-option,-Wa$(comma)-gdwarf-$(dwarf-version-y))
> +DEBUG_CFLAGS += $(dwarf-aflag)
> +KBUILD_AFLAGS += $(dwarf-aflag)
> endif
>
> ifdef CONFIG_DEBUG_INFO_REDUCED
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 0c7380e36370..04719294a7a3 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -256,14 +256,25 @@ config DEBUG_INFO_SPLIT
> to know about the .dwo files and include them.
> Incompatible with older versions of ccache.
>
> +choice
> + prompt "DWARF version"
> + help
> + Which version of DWARF debug info to emit.
> +
> +config DEBUG_INFO_DWARF2
> + bool "Generate DWARF Version 2 debuginfo"
> + help
> + Generate DWARF v2 debug info.
> +
> config DEBUG_INFO_DWARF4
> - bool "Generate dwarf4 debuginfo"
> + bool "Generate DWARF Version 4 debuginfo"
> depends on $(cc-option,-gdwarf-4)
> help
> - Generate dwarf4 debug info. This requires recent versions
> - of gcc and gdb. It makes the debug information larger.
> - But it significantly improves the success of resolving
> - variables in gdb on optimized code.
> + Generate DWARF v4 debug info. This requires gcc 4.5+ and gdb 7.0+.
> + It makes the debug information larger, but it significantly
> + improves the success of resolving variables in gdb on optimized code.
> +
> +endchoice # "DWARF version"
>
> config DEBUG_INFO_BTF
> bool "Generate BTF typeinfo"
> --
> 2.29.2.576.ga3fc446d84-goog
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] jffs2: fix use after free in jffs2_sum_write_data()
@ 2021-01-04 22:16 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-04 22:16 UTC (permalink / raw)
To: trix
Cc: richard, ndesaulniers, linux-kernel, clang-built-linux, linux-mtd, dwmw2
On Wed, Dec 30, 2020 at 06:56:04AM -0800, trix@redhat.com wrote:
> From: Tom Rix <trix@redhat.com>
>
> clang static analysis reports this problem
>
> fs/jffs2/summary.c:794:31: warning: Use of memory after it is freed
> c->summary->sum_list_head = temp->u.next;
> ^~~~~~~~~~~~
>
> In jffs2_sum_write_data(), in a loop summary data is handles a node at
> a time. When it has written out the node it is removed the summary list,
> and the node is deleted. In the corner case when a
> JFFS2_FEATURE_RWCOMPAT_COPY is seen, a call is made to
> jffs2_sum_disable_collecting(). jffs2_sum_disable_collecting() deletes
> the whole list which conflicts with the loop's deleting the list by parts.
>
> To preserve the old behavior of stopping the write midway, bail out of
> the loop after disabling summary collection.
>
> Fixes: 6171586a7ae5 ("[JFFS2] Correct handling of JFFS2_FEATURE_RWCOMPAT_COPY nodes.")
> Signed-off-by: Tom Rix <trix@redhat.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> fs/jffs2/summary.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/fs/jffs2/summary.c b/fs/jffs2/summary.c
> index be7c8a6a5748..4fe64519870f 100644
> --- a/fs/jffs2/summary.c
> +++ b/fs/jffs2/summary.c
> @@ -783,6 +783,8 @@ static int jffs2_sum_write_data(struct jffs2_sb_info *c, struct jffs2_eraseblock
> dbg_summary("Writing unknown RWCOMPAT_COPY node type %x\n",
> je16_to_cpu(temp->u.nodetype));
> jffs2_sum_disable_collecting(c->summary);
> + /* The above call removes the list, nothing more to do */
> + goto bail_rwcompat;
> } else {
> BUG(); /* unknown node in summary information */
> }
> @@ -794,6 +796,7 @@ static int jffs2_sum_write_data(struct jffs2_sb_info *c, struct jffs2_eraseblock
>
> c->summary->sum_num--;
> }
> + bail_rwcompat:
>
> jffs2_sum_reset_collected(c->summary);
>
> --
> 2.27.0
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [relevance 99%]
* [PATCH v2] powerpc: Handle .text.{hot,unlikely}.* in linker script
@ 2021-01-04 20:59 92% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-04 20:59 UTC (permalink / raw)
To: Michael Ellerman
Cc: Nick Desaulniers, linux-kernel, stable, clang-built-linux,
Paul Mackerras, Nathan Chancellor, linuxppc-dev
Commit eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input
sections") added ".text.unlikely.*" and ".text.hot.*" due to an LLVM
change [1].
After another LLVM change [2], these sections are seen in some PowerPC
builds, where there is a orphan section warning then build failure:
$ make -skj"$(nproc)" \
ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- LLVM=1 O=out \
distclean powernv_defconfig zImage.epapr
ld.lld: warning: kernel/built-in.a(panic.o):(.text.unlikely.) is being placed in '.text.unlikely.'
...
ld.lld: warning: address (0xc000000000009314) of section .text is not a multiple of alignment (256)
...
ERROR: start_text address is c000000000009400, should be c000000000008000
ERROR: try to enable LD_HEAD_STUB_CATCH config option
ERROR: see comments in arch/powerpc/tools/head_check.sh
...
Explicitly handle these sections like in the main linker script so
there is no more build failure.
[1]: https://reviews.llvm.org/D79600
[2]: https://reviews.llvm.org/D92493
Cc: stable@vger.kernel.org
Fixes: 83a092cf95f2 ("powerpc: Link warning for orphan sections")
Link: https://github.com/ClangBuiltLinux/linux/issues/1218
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
v1 -> v2:
* Add missing [1] and [2] references in commit message. Thanks to Sedat
Dilek for pointing it out!
arch/powerpc/kernel/vmlinux.lds.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index 0318ba436f34..8e0b1298bf19 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -85,7 +85,7 @@ SECTIONS
ALIGN_FUNCTION();
#endif
/* careful! __ftr_alt_* sections need to be close to .text */
- *(.text.hot TEXT_MAIN .text.fixup .text.unlikely .fixup __ftr_alt_* .ref.text);
+ *(.text.hot .text.hot.* TEXT_MAIN .text.fixup .text.unlikely .text.unlikely.* .fixup __ftr_alt_* .ref.text);
#ifdef CONFIG_PPC64
*(.tramp.ftrace.text);
#endif
base-commit: d8a4f20584d5906093a8fc6aa06622102a501095
--
2.30.0
^ permalink raw reply related [relevance 92%]
* Re: [PATCH] powerpc: Handle .text.{hot,unlikely}.* in linker script
@ 2021-01-04 20:57 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-04 20:57 UTC (permalink / raw)
To: Sedat Dilek
Cc: Nick Desaulniers, linux-kernel, stable, Clang-Built-Linux ML,
Paul Mackerras, linuxppc-dev
On Mon, Jan 04, 2021 at 09:55:20PM +0100, Sedat Dilek wrote:
> On Mon, Jan 4, 2021 at 9:49 PM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> >
> > Commit eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input
> > sections") added ".text.unlikely.*" and ".text.hot.*" due to an LLVM
> > change [1].
> >
> > After another LLVM change [2], these sections are seen in some PowerPC
> > builds, where there is a orphan section warning then build failure:
> >
>
> Looks like you forgot to add your references/links to [1] and [2].
Indeed, thank you for pointing that out! v2 coming shortly.
> Might be good to mention...?
>
> With CONFIG_LD_ORPHAN_WARN=y is enabled
Since this symbol is not user selectable, I do not really think it is
worth mentioning, plus PowerPC has had this enabled for a while :)
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* [PATCH] powerpc: Handle .text.{hot,unlikely}.* in linker script
@ 2021-01-04 20:48 94% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-04 20:48 UTC (permalink / raw)
To: Michael Ellerman
Cc: Nick Desaulniers, linux-kernel, stable, clang-built-linux,
Paul Mackerras, Nathan Chancellor, linuxppc-dev
Commit eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input
sections") added ".text.unlikely.*" and ".text.hot.*" due to an LLVM
change [1].
After another LLVM change [2], these sections are seen in some PowerPC
builds, where there is a orphan section warning then build failure:
$ make -skj"$(nproc)" \
ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- LLVM=1 O=out \
distclean powernv_defconfig zImage.epapr
ld.lld: warning: kernel/built-in.a(panic.o):(.text.unlikely.) is being placed in '.text.unlikely.'
...
ld.lld: warning: address (0xc000000000009314) of section .text is not a multiple of alignment (256)
...
ERROR: start_text address is c000000000009400, should be c000000000008000
ERROR: try to enable LD_HEAD_STUB_CATCH config option
ERROR: see comments in arch/powerpc/tools/head_check.sh
...
Explicitly handle these sections like in the main linker script so
there is no more build failure.
Cc: stable@vger.kernel.org
Fixes: 83a092cf95f2 ("powerpc: Link warning for orphan sections")
Link: https://github.com/ClangBuiltLinux/linux/issues/1218
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
arch/powerpc/kernel/vmlinux.lds.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index 0318ba436f34..8e0b1298bf19 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -85,7 +85,7 @@ SECTIONS
ALIGN_FUNCTION();
#endif
/* careful! __ftr_alt_* sections need to be close to .text */
- *(.text.hot TEXT_MAIN .text.fixup .text.unlikely .fixup __ftr_alt_* .ref.text);
+ *(.text.hot .text.hot.* TEXT_MAIN .text.fixup .text.unlikely .text.unlikely.* .fixup __ftr_alt_* .ref.text);
#ifdef CONFIG_PPC64
*(.tramp.ftrace.text);
#endif
base-commit: d8a4f20584d5906093a8fc6aa06622102a501095
--
2.30.0
^ permalink raw reply related [relevance 94%]
* Re: drivers/net/wireless/intel/iwlwifi/queue/tx.c:310:18: warning: result of comparison of constant 262140 with expression of type 'u16' (aka 'unsigned short') is always false
@ 2021-01-04 18:47 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2021-01-04 18:47 UTC (permalink / raw)
To: kernel test robot
Cc: Mordechay Goodstein, kbuild-all, clang-built-linux, linux-kernel,
Luca Coelho
On Sun, Jan 03, 2021 at 09:51:17AM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head: 3516bd729358a2a9b090c1905bd2a3fa926e24c6
> commit: 0cd1ad2d7fd41e0de4969fd1dd0aa846c99830d1 iwlwifi: move all bus-independent TX functions to common code
> date: 3 months ago
> config: powerpc-randconfig-r001-20210103 (attached as .config)
> compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 20670ba44066df0aae536822b7f7834ee3198c0d)
> reproduce (this is a W=1 build):
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # install powerpc cross compiling tool for clang build
> # apt-get install binutils-powerpc-linux-gnu
> # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0cd1ad2d7fd41e0de4969fd1dd0aa846c99830d1
> git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> git fetch --no-tags linus master
> git checkout 0cd1ad2d7fd41e0de4969fd1dd0aa846c99830d1
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
>
> All warnings (new ones prefixed by >>):
>
> >> drivers/net/wireless/intel/iwlwifi/queue/tx.c:310:18: warning: result of comparison of constant 262140 with expression of type 'u16' (aka 'unsigned short') is always false [-Wtautological-constant-out-of-range-compare]
> if (WARN_ON(len > PAGE_SIZE - sizeof(void *))) {
> ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> include/asm-generic/bug.h:188:25: note: expanded from macro 'WARN_ON'
> int __ret_warn_on = !!(condition); \
> ^~~~~~~~~
> include/linux/compiler.h:56:47: note: expanded from macro 'if'
> #define if(cond, ...) if ( __trace_if_var( !!(cond , ## __VA_ARGS__) ) )
> ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
> include/linux/compiler.h:58:52: note: expanded from macro '__trace_if_var'
> #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : __trace_if_value(cond))
> ^~~~
> >> drivers/net/wireless/intel/iwlwifi/queue/tx.c:310:18: warning: result of comparison of constant 262140 with expression of type 'u16' (aka 'unsigned short') is always false [-Wtautological-constant-out-of-range-compare]
> if (WARN_ON(len > PAGE_SIZE - sizeof(void *))) {
> ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> include/asm-generic/bug.h:188:25: note: expanded from macro 'WARN_ON'
> int __ret_warn_on = !!(condition); \
> ^~~~~~~~~
> include/linux/compiler.h:56:47: note: expanded from macro 'if'
> #define if(cond, ...) if ( __trace_if_var( !!(cond , ## __VA_ARGS__) ) )
> ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
> include/linux/compiler.h:58:86: note: expanded from macro '__trace_if_var'
> #define __trace_if_var(cond) (__builtin_constant_p(cond) ? (cond) : __trace_if_value(cond))
> ~~~~~~~~~~~~~~~~~^~~~~
> include/linux/compiler.h:69:3: note: expanded from macro '__trace_if_value'
> (cond) ? \
> ^~~~
> 2 warnings generated.
This warning happens due to PAGE_SIZE being 256K, which is larger than
u16.
$ rg "PPC_256K_PAGES|PPC_PAGE_SHIFT" .config
CONFIG_PPC_256K_PAGES=y
CONFIG_PPC_PAGE_SHIFT=18
On most configurations, which will use 64K or less, this check is valid.
I am not sure how it should be dealt with, aside from increasing len to
u32.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] i3c/master/mipi-i3c-hci: re-fix __maybe_unused attribute
@ 2020-12-30 21:43 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-30 21:43 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Arnd Bergmann, Arnd Bergmann, Nick Desaulniers, linux-kernel,
Nicolas Pitre, clang-built-linux, Boris Brezillon, linux-i3c
On Wed, Dec 30, 2020 at 10:40:53PM +0100, Alexandre Belloni wrote:
> On 30/12/2020 16:23:56-0500, Nicolas Pitre wrote:
> > On Wed, 30 Dec 2020, Arnd Bergmann wrote:
> >
> > > From: Arnd Bergmann <arnd@arndb.de>
> > >
> > > clang warns because the added __maybe_unused attribute is in
> > > the wrong place:
> > >
> > > drivers/i3c/master/mipi-i3c-hci/core.c:780:21: error: attribute declaration must precede definition [-Werror,-Wignored-attributes]
> > > static const struct __maybe_unused of_device_id i3c_hci_of_match[] = {
> > > ^
> > > include/linux/compiler_attributes.h:267:56: note: expanded
> > >
> > > Fixes: 95393f3e07ab ("i3c/master/mipi-i3c-hci: quiet maybe-unused variable warning")
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >
> > Acked-by: Nicolas Pitre <npitre@baylibre.com>
> >
> > This might be the 3rd patch from 3 different people fixing the same
> > thing. Looks like I3C maintainer is on vacation. Please feel free to
> > send this trivial fix upstream some other way.
> >
>
> Isn't it already upstream?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=95393f3e07ab53855b91881692a4a5b52dcdc03c
This patch is fixing that one, the attribute was added between the
struct type, causing a new warning for clang.
I sent a fix for this earlier too, I do not care which one goes in as
long as one does so:
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Cheers,
Nathan
--
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c
^ permalink raw reply [relevance 99%]
* Re: [PATCH] ASoC: fsl: fix -Wmaybe-uninitialized warning
2020-12-31 8:12 99% ` Nathan Chancellor
(?)
@ 2020-12-31 8:12 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-31 8:12 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Timur Tabi, Nicolin Chen, Mark Brown, Arnd Bergmann, Xiubo Li,
Fabio Estevam, Shengjiu Wang, Liam Girdwood, Jaroslav Kysela,
Takashi Iwai, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
NXP Linux Team, Nick Desaulniers, alsa-devel, linuxppc-dev,
linux-arm-kernel, linux-kernel, clang-built-linux
On Wed, Dec 30, 2020 at 04:44:15PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Clang points out a code path that returns an undefined value
> in an error case:
>
> sound/soc/fsl/imx-hdmi.c:165:6: error: variable 'ret' is used uninitialized whenever 'if' condition is true [-Werror,-Wsom
> etimes-uninitialized]
> if ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in)) {
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> sound/soc/fsl/imx-hdmi.c:212:9: note: uninitialized use occurs here
> return ret;
>
> The driver returns -EINVAL for other broken DT properties, so do
> it the same way here.
>
> Fixes: 6a5f850aa83a ("ASoC: fsl: Add imx-hdmi machine driver")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> sound/soc/fsl/imx-hdmi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/sound/soc/fsl/imx-hdmi.c b/sound/soc/fsl/imx-hdmi.c
> index 2c2a76a71940..ede4a9ad1054 100644
> --- a/sound/soc/fsl/imx-hdmi.c
> +++ b/sound/soc/fsl/imx-hdmi.c
> @@ -164,6 +164,7 @@ static int imx_hdmi_probe(struct platform_device *pdev)
>
> if ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in)) {
> dev_err(&pdev->dev, "Invalid HDMI DAI link\n");
> + ret = -EINVAL;
> goto fail;
> }
>
> --
> 2.29.2
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] ASoC: fsl: fix -Wmaybe-uninitialized warning
@ 2020-12-31 8:12 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-31 8:12 UTC (permalink / raw)
To: Arnd Bergmann
Cc: alsa-devel, linuxppc-dev, linux-kernel, Timur Tabi,
Arnd Bergmann, Xiubo Li, Shengjiu Wang, Sascha Hauer,
Takashi Iwai, Nick Desaulniers, Liam Girdwood, Jaroslav Kysela,
Nicolin Chen, clang-built-linux, Mark Brown, NXP Linux Team,
Pengutronix Kernel Team, Shawn Guo, Fabio Estevam,
linux-arm-kernel
On Wed, Dec 30, 2020 at 04:44:15PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Clang points out a code path that returns an undefined value
> in an error case:
>
> sound/soc/fsl/imx-hdmi.c:165:6: error: variable 'ret' is used uninitialized whenever 'if' condition is true [-Werror,-Wsom
> etimes-uninitialized]
> if ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in)) {
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> sound/soc/fsl/imx-hdmi.c:212:9: note: uninitialized use occurs here
> return ret;
>
> The driver returns -EINVAL for other broken DT properties, so do
> it the same way here.
>
> Fixes: 6a5f850aa83a ("ASoC: fsl: Add imx-hdmi machine driver")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> sound/soc/fsl/imx-hdmi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/sound/soc/fsl/imx-hdmi.c b/sound/soc/fsl/imx-hdmi.c
> index 2c2a76a71940..ede4a9ad1054 100644
> --- a/sound/soc/fsl/imx-hdmi.c
> +++ b/sound/soc/fsl/imx-hdmi.c
> @@ -164,6 +164,7 @@ static int imx_hdmi_probe(struct platform_device *pdev)
>
> if ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in)) {
> dev_err(&pdev->dev, "Invalid HDMI DAI link\n");
> + ret = -EINVAL;
> goto fail;
> }
>
> --
> 2.29.2
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] ASoC: fsl: fix -Wmaybe-uninitialized warning
@ 2020-12-31 8:12 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-31 8:12 UTC (permalink / raw)
To: Arnd Bergmann
Cc: alsa-devel, linuxppc-dev, linux-kernel, Timur Tabi,
Arnd Bergmann, Xiubo Li, Shengjiu Wang, Sascha Hauer,
Takashi Iwai, Nick Desaulniers, Liam Girdwood, Nicolin Chen,
clang-built-linux, Mark Brown, NXP Linux Team,
Pengutronix Kernel Team, Shawn Guo, Fabio Estevam,
linux-arm-kernel
On Wed, Dec 30, 2020 at 04:44:15PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Clang points out a code path that returns an undefined value
> in an error case:
>
> sound/soc/fsl/imx-hdmi.c:165:6: error: variable 'ret' is used uninitialized whenever 'if' condition is true [-Werror,-Wsom
> etimes-uninitialized]
> if ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in)) {
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> sound/soc/fsl/imx-hdmi.c:212:9: note: uninitialized use occurs here
> return ret;
>
> The driver returns -EINVAL for other broken DT properties, so do
> it the same way here.
>
> Fixes: 6a5f850aa83a ("ASoC: fsl: Add imx-hdmi machine driver")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> sound/soc/fsl/imx-hdmi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/sound/soc/fsl/imx-hdmi.c b/sound/soc/fsl/imx-hdmi.c
> index 2c2a76a71940..ede4a9ad1054 100644
> --- a/sound/soc/fsl/imx-hdmi.c
> +++ b/sound/soc/fsl/imx-hdmi.c
> @@ -164,6 +164,7 @@ static int imx_hdmi_probe(struct platform_device *pdev)
>
> if ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in)) {
> dev_err(&pdev->dev, "Invalid HDMI DAI link\n");
> + ret = -EINVAL;
> goto fail;
> }
>
> --
> 2.29.2
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] ASoC: fsl: fix -Wmaybe-uninitialized warning
@ 2020-12-31 8:12 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-31 8:12 UTC (permalink / raw)
To: Arnd Bergmann
Cc: alsa-devel, linuxppc-dev, linux-kernel, Timur Tabi,
Arnd Bergmann, Xiubo Li, Shengjiu Wang, Sascha Hauer,
Takashi Iwai, Nick Desaulniers, Liam Girdwood, Jaroslav Kysela,
Nicolin Chen, clang-built-linux, Mark Brown, NXP Linux Team,
Pengutronix Kernel Team, Shawn Guo, Fabio Estevam,
linux-arm-kernel
On Wed, Dec 30, 2020 at 04:44:15PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Clang points out a code path that returns an undefined value
> in an error case:
>
> sound/soc/fsl/imx-hdmi.c:165:6: error: variable 'ret' is used uninitialized whenever 'if' condition is true [-Werror,-Wsom
> etimes-uninitialized]
> if ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in)) {
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> sound/soc/fsl/imx-hdmi.c:212:9: note: uninitialized use occurs here
> return ret;
>
> The driver returns -EINVAL for other broken DT properties, so do
> it the same way here.
>
> Fixes: 6a5f850aa83a ("ASoC: fsl: Add imx-hdmi machine driver")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> sound/soc/fsl/imx-hdmi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/sound/soc/fsl/imx-hdmi.c b/sound/soc/fsl/imx-hdmi.c
> index 2c2a76a71940..ede4a9ad1054 100644
> --- a/sound/soc/fsl/imx-hdmi.c
> +++ b/sound/soc/fsl/imx-hdmi.c
> @@ -164,6 +164,7 @@ static int imx_hdmi_probe(struct platform_device *pdev)
>
> if ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in)) {
> dev_err(&pdev->dev, "Invalid HDMI DAI link\n");
> + ret = -EINVAL;
> goto fail;
> }
>
> --
> 2.29.2
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [relevance 99%]
* Re: [PATCH] i3c/master/mipi-i3c-hci: re-fix __maybe_unused attribute
@ 2020-12-30 21:43 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-30 21:43 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Nicolas Pitre, Arnd Bergmann, Nick Desaulniers, Boris Brezillon,
Arnd Bergmann, linux-i3c, linux-kernel, clang-built-linux
On Wed, Dec 30, 2020 at 10:40:53PM +0100, Alexandre Belloni wrote:
> On 30/12/2020 16:23:56-0500, Nicolas Pitre wrote:
> > On Wed, 30 Dec 2020, Arnd Bergmann wrote:
> >
> > > From: Arnd Bergmann <arnd@arndb.de>
> > >
> > > clang warns because the added __maybe_unused attribute is in
> > > the wrong place:
> > >
> > > drivers/i3c/master/mipi-i3c-hci/core.c:780:21: error: attribute declaration must precede definition [-Werror,-Wignored-attributes]
> > > static const struct __maybe_unused of_device_id i3c_hci_of_match[] = {
> > > ^
> > > include/linux/compiler_attributes.h:267:56: note: expanded
> > >
> > > Fixes: 95393f3e07ab ("i3c/master/mipi-i3c-hci: quiet maybe-unused variable warning")
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >
> > Acked-by: Nicolas Pitre <npitre@baylibre.com>
> >
> > This might be the 3rd patch from 3 different people fixing the same
> > thing. Looks like I3C maintainer is on vacation. Please feel free to
> > send this trivial fix upstream some other way.
> >
>
> Isn't it already upstream?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=95393f3e07ab53855b91881692a4a5b52dcdc03c
This patch is fixing that one, the attribute was added between the
struct type, causing a new warning for clang.
I sent a fix for this earlier too, I do not care which one goes in as
long as one does so:
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] KVM: arm64: Fix hyp_cpu_pm_{init,exit} __init annotation
@ 2020-12-29 22:34 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-29 22:34 UTC (permalink / raw)
To: Marc Zyngier; +Cc: kernel-team, kvmarm, linux-arm-kernel
On Wed, Dec 23, 2020 at 12:08:54PM +0000, Marc Zyngier wrote:
> The __init annotations on hyp_cpu_pm_{init,exit} are obviously incorrect,
> and the build system shouts at you if you enable DEBUG_SECTION_MISMATCH.
>
> Nothing really bad happens as we never execute that code outside of the
> init context, but we can't label the callers as __int either, as kvm_init
> isn't __init itself. Oh well.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> arch/arm64/kvm/arm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 6e637d2b4cfb..71a49eae9ea0 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -1574,12 +1574,12 @@ static struct notifier_block hyp_init_cpu_pm_nb = {
> .notifier_call = hyp_init_cpu_pm_notifier,
> };
>
> -static void __init hyp_cpu_pm_init(void)
> +static void hyp_cpu_pm_init(void)
> {
> if (!is_protected_kvm_enabled())
> cpu_pm_register_notifier(&hyp_init_cpu_pm_nb);
> }
> -static void __init hyp_cpu_pm_exit(void)
> +static void hyp_cpu_pm_exit(void)
> {
> if (!is_protected_kvm_enabled())
> cpu_pm_unregister_notifier(&hyp_init_cpu_pm_nb);
> --
> 2.29.2
>
> _______________________________________________
> kvmarm mailing list
> kvmarm@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [relevance 99%]
* Re: [PATCH] KVM: arm64: Fix section mismatches around hyp_cpu_pm_{init,exit}
2020-12-29 22:33 99% ` Nathan Chancellor
@ 2020-12-29 22:33 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-29 22:33 UTC (permalink / raw)
To: Marc Zyngier
Cc: Catalin Marinas, linux-kernel, clang-built-linux, Will Deacon,
kvmarm, linux-arm-kernel
On Tue, Dec 29, 2020 at 10:11:07PM +0000, Marc Zyngier wrote:
> On 2020-12-29 21:43, Nathan Chancellor wrote:
> > Commit fa8c3d65538a ("KVM: arm64: Keep nVHE EL2 vector installed")
> > inadvertently changed clang's inlining decisions around
> > hyp_cpu_pm_{init,exit}, causing the following section mismatch warnings:
> >
> > WARNING: modpost: vmlinux.o(.text+0x95c6c): Section mismatch in
> > reference from the function kvm_arch_init() to the function
> > .init.text:hyp_cpu_pm_exit()
> > The function kvm_arch_init() references
> > the function __init hyp_cpu_pm_exit().
> > This is often because kvm_arch_init lacks a __init
> > annotation or the annotation of hyp_cpu_pm_exit is wrong.
> >
> > WARNING: modpost: vmlinux.o(.text+0x97054): Section mismatch in
> > reference from the function init_subsystems() to the function
> > .init.text:hyp_cpu_pm_init()
> > The function init_subsystems() references
> > the function __init hyp_cpu_pm_init().
> > This is often because init_subsystems lacks a __init
> > annotation or the annotation of hyp_cpu_pm_init is wrong.
> >
> > Remove the __init annotation so that there are no warnings regardless of
> > how functions are inlined.
> >
> > Fixes: 1fcf7ce0c602 ("arm: kvm: implement CPU PM notifier")
> > Fixes: 06a71a24bae5 ("arm64: KVM: unregister notifiers in hyp mode
> > teardown path")
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1230
> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
>
> Hi Nathan,
>
> Already posted[1] last week.
>
> Thanks,
>
> M.
>
> [1] htps://lore.kernel.org/r/20201223120854.255347-1-maz@kernel.org
> --
> Jazz is not dead. It just smells funny...
Sorry for the duplicate, I am usually good at spotting that :(
Cheers,
Nathan
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [relevance 99%]
* Re: [PATCH] KVM: arm64: Fix hyp_cpu_pm_{init,exit} __init annotation
@ 2020-12-29 22:34 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-29 22:34 UTC (permalink / raw)
To: Marc Zyngier; +Cc: kernel-team, kvmarm, linux-arm-kernel
On Wed, Dec 23, 2020 at 12:08:54PM +0000, Marc Zyngier wrote:
> The __init annotations on hyp_cpu_pm_{init,exit} are obviously incorrect,
> and the build system shouts at you if you enable DEBUG_SECTION_MISMATCH.
>
> Nothing really bad happens as we never execute that code outside of the
> init context, but we can't label the callers as __int either, as kvm_init
> isn't __init itself. Oh well.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> arch/arm64/kvm/arm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 6e637d2b4cfb..71a49eae9ea0 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -1574,12 +1574,12 @@ static struct notifier_block hyp_init_cpu_pm_nb = {
> .notifier_call = hyp_init_cpu_pm_notifier,
> };
>
> -static void __init hyp_cpu_pm_init(void)
> +static void hyp_cpu_pm_init(void)
> {
> if (!is_protected_kvm_enabled())
> cpu_pm_register_notifier(&hyp_init_cpu_pm_nb);
> }
> -static void __init hyp_cpu_pm_exit(void)
> +static void hyp_cpu_pm_exit(void)
> {
> if (!is_protected_kvm_enabled())
> cpu_pm_unregister_notifier(&hyp_init_cpu_pm_nb);
> --
> 2.29.2
>
> _______________________________________________
> kvmarm mailing list
> kvmarm@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [relevance 99%]
* Re: [PATCH] KVM: arm64: Fix section mismatches around hyp_cpu_pm_{init,exit}
@ 2020-12-29 22:33 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-29 22:33 UTC (permalink / raw)
To: Marc Zyngier
Cc: Suzuki K Poulose, Catalin Marinas, linux-kernel,
clang-built-linux, James Morse, Julien Thierry, Will Deacon,
kvmarm, linux-arm-kernel
On Tue, Dec 29, 2020 at 10:11:07PM +0000, Marc Zyngier wrote:
> On 2020-12-29 21:43, Nathan Chancellor wrote:
> > Commit fa8c3d65538a ("KVM: arm64: Keep nVHE EL2 vector installed")
> > inadvertently changed clang's inlining decisions around
> > hyp_cpu_pm_{init,exit}, causing the following section mismatch warnings:
> >
> > WARNING: modpost: vmlinux.o(.text+0x95c6c): Section mismatch in
> > reference from the function kvm_arch_init() to the function
> > .init.text:hyp_cpu_pm_exit()
> > The function kvm_arch_init() references
> > the function __init hyp_cpu_pm_exit().
> > This is often because kvm_arch_init lacks a __init
> > annotation or the annotation of hyp_cpu_pm_exit is wrong.
> >
> > WARNING: modpost: vmlinux.o(.text+0x97054): Section mismatch in
> > reference from the function init_subsystems() to the function
> > .init.text:hyp_cpu_pm_init()
> > The function init_subsystems() references
> > the function __init hyp_cpu_pm_init().
> > This is often because init_subsystems lacks a __init
> > annotation or the annotation of hyp_cpu_pm_init is wrong.
> >
> > Remove the __init annotation so that there are no warnings regardless of
> > how functions are inlined.
> >
> > Fixes: 1fcf7ce0c602 ("arm: kvm: implement CPU PM notifier")
> > Fixes: 06a71a24bae5 ("arm64: KVM: unregister notifiers in hyp mode
> > teardown path")
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1230
> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
>
> Hi Nathan,
>
> Already posted[1] last week.
>
> Thanks,
>
> M.
>
> [1] htps://lore.kernel.org/r/20201223120854.255347-1-maz@kernel.org
> --
> Jazz is not dead. It just smells funny...
Sorry for the duplicate, I am usually good at spotting that :(
Cheers,
Nathan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [relevance 99%]
* Re: [PATCH] KVM: arm64: Fix section mismatches around hyp_cpu_pm_{init,exit}
@ 2020-12-29 22:33 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-29 22:33 UTC (permalink / raw)
To: Marc Zyngier
Cc: James Morse, Julien Thierry, Suzuki K Poulose, Catalin Marinas,
Will Deacon, linux-arm-kernel, kvmarm, clang-built-linux,
linux-kernel
On Tue, Dec 29, 2020 at 10:11:07PM +0000, Marc Zyngier wrote:
> On 2020-12-29 21:43, Nathan Chancellor wrote:
> > Commit fa8c3d65538a ("KVM: arm64: Keep nVHE EL2 vector installed")
> > inadvertently changed clang's inlining decisions around
> > hyp_cpu_pm_{init,exit}, causing the following section mismatch warnings:
> >
> > WARNING: modpost: vmlinux.o(.text+0x95c6c): Section mismatch in
> > reference from the function kvm_arch_init() to the function
> > .init.text:hyp_cpu_pm_exit()
> > The function kvm_arch_init() references
> > the function __init hyp_cpu_pm_exit().
> > This is often because kvm_arch_init lacks a __init
> > annotation or the annotation of hyp_cpu_pm_exit is wrong.
> >
> > WARNING: modpost: vmlinux.o(.text+0x97054): Section mismatch in
> > reference from the function init_subsystems() to the function
> > .init.text:hyp_cpu_pm_init()
> > The function init_subsystems() references
> > the function __init hyp_cpu_pm_init().
> > This is often because init_subsystems lacks a __init
> > annotation or the annotation of hyp_cpu_pm_init is wrong.
> >
> > Remove the __init annotation so that there are no warnings regardless of
> > how functions are inlined.
> >
> > Fixes: 1fcf7ce0c602 ("arm: kvm: implement CPU PM notifier")
> > Fixes: 06a71a24bae5 ("arm64: KVM: unregister notifiers in hyp mode
> > teardown path")
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1230
> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
>
> Hi Nathan,
>
> Already posted[1] last week.
>
> Thanks,
>
> M.
>
> [1] htps://lore.kernel.org/r/20201223120854.255347-1-maz@kernel.org
> --
> Jazz is not dead. It just smells funny...
Sorry for the duplicate, I am usually good at spotting that :(
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* [PATCH] KVM: arm64: Fix section mismatches around hyp_cpu_pm_{init, exit}
@ 2020-12-29 21:43 93% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-29 21:43 UTC (permalink / raw)
To: Marc Zyngier
Cc: Catalin Marinas, linux-kernel, clang-built-linux,
Nathan Chancellor, Will Deacon, kvmarm, linux-arm-kernel
Commit fa8c3d65538a ("KVM: arm64: Keep nVHE EL2 vector installed")
inadvertently changed clang's inlining decisions around
hyp_cpu_pm_{init,exit}, causing the following section mismatch warnings:
WARNING: modpost: vmlinux.o(.text+0x95c6c): Section mismatch in
reference from the function kvm_arch_init() to the function
.init.text:hyp_cpu_pm_exit()
The function kvm_arch_init() references
the function __init hyp_cpu_pm_exit().
This is often because kvm_arch_init lacks a __init
annotation or the annotation of hyp_cpu_pm_exit is wrong.
WARNING: modpost: vmlinux.o(.text+0x97054): Section mismatch in
reference from the function init_subsystems() to the function
.init.text:hyp_cpu_pm_init()
The function init_subsystems() references
the function __init hyp_cpu_pm_init().
This is often because init_subsystems lacks a __init
annotation or the annotation of hyp_cpu_pm_init is wrong.
Remove the __init annotation so that there are no warnings regardless of
how functions are inlined.
Fixes: 1fcf7ce0c602 ("arm: kvm: implement CPU PM notifier")
Fixes: 06a71a24bae5 ("arm64: KVM: unregister notifiers in hyp mode teardown path")
Link: https://github.com/ClangBuiltLinux/linux/issues/1230
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
arch/arm64/kvm/arm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 6e637d2b4cfb..71a49eae9ea0 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -1574,12 +1574,12 @@ static struct notifier_block hyp_init_cpu_pm_nb = {
.notifier_call = hyp_init_cpu_pm_notifier,
};
-static void __init hyp_cpu_pm_init(void)
+static void hyp_cpu_pm_init(void)
{
if (!is_protected_kvm_enabled())
cpu_pm_register_notifier(&hyp_init_cpu_pm_nb);
}
-static void __init hyp_cpu_pm_exit(void)
+static void hyp_cpu_pm_exit(void)
{
if (!is_protected_kvm_enabled())
cpu_pm_unregister_notifier(&hyp_init_cpu_pm_nb);
base-commit: 5c8fe583cce542aa0b84adc939ce85293de36e5e
--
2.30.0
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [relevance 94%]
* [PATCH] KVM: arm64: Fix section mismatches around hyp_cpu_pm_{init, exit}
@ 2020-12-29 21:43 93% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-29 21:43 UTC (permalink / raw)
To: Marc Zyngier
Cc: Suzuki K Poulose, Catalin Marinas, linux-kernel,
clang-built-linux, James Morse, Julien Thierry,
Nathan Chancellor, Will Deacon, kvmarm, linux-arm-kernel
Commit fa8c3d65538a ("KVM: arm64: Keep nVHE EL2 vector installed")
inadvertently changed clang's inlining decisions around
hyp_cpu_pm_{init,exit}, causing the following section mismatch warnings:
WARNING: modpost: vmlinux.o(.text+0x95c6c): Section mismatch in
reference from the function kvm_arch_init() to the function
.init.text:hyp_cpu_pm_exit()
The function kvm_arch_init() references
the function __init hyp_cpu_pm_exit().
This is often because kvm_arch_init lacks a __init
annotation or the annotation of hyp_cpu_pm_exit is wrong.
WARNING: modpost: vmlinux.o(.text+0x97054): Section mismatch in
reference from the function init_subsystems() to the function
.init.text:hyp_cpu_pm_init()
The function init_subsystems() references
the function __init hyp_cpu_pm_init().
This is often because init_subsystems lacks a __init
annotation or the annotation of hyp_cpu_pm_init is wrong.
Remove the __init annotation so that there are no warnings regardless of
how functions are inlined.
Fixes: 1fcf7ce0c602 ("arm: kvm: implement CPU PM notifier")
Fixes: 06a71a24bae5 ("arm64: KVM: unregister notifiers in hyp mode teardown path")
Link: https://github.com/ClangBuiltLinux/linux/issues/1230
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
arch/arm64/kvm/arm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 6e637d2b4cfb..71a49eae9ea0 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -1574,12 +1574,12 @@ static struct notifier_block hyp_init_cpu_pm_nb = {
.notifier_call = hyp_init_cpu_pm_notifier,
};
-static void __init hyp_cpu_pm_init(void)
+static void hyp_cpu_pm_init(void)
{
if (!is_protected_kvm_enabled())
cpu_pm_register_notifier(&hyp_init_cpu_pm_nb);
}
-static void __init hyp_cpu_pm_exit(void)
+static void hyp_cpu_pm_exit(void)
{
if (!is_protected_kvm_enabled())
cpu_pm_unregister_notifier(&hyp_init_cpu_pm_nb);
base-commit: 5c8fe583cce542aa0b84adc939ce85293de36e5e
--
2.30.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [relevance 93%]
* [PATCH] KVM: arm64: Fix section mismatches around hyp_cpu_pm_{init,exit}
@ 2020-12-29 21:43 93% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-29 21:43 UTC (permalink / raw)
To: Marc Zyngier
Cc: James Morse, Julien Thierry, Suzuki K Poulose, Catalin Marinas,
Will Deacon, linux-arm-kernel, kvmarm, clang-built-linux,
linux-kernel, Nathan Chancellor
Commit fa8c3d65538a ("KVM: arm64: Keep nVHE EL2 vector installed")
inadvertently changed clang's inlining decisions around
hyp_cpu_pm_{init,exit}, causing the following section mismatch warnings:
WARNING: modpost: vmlinux.o(.text+0x95c6c): Section mismatch in
reference from the function kvm_arch_init() to the function
.init.text:hyp_cpu_pm_exit()
The function kvm_arch_init() references
the function __init hyp_cpu_pm_exit().
This is often because kvm_arch_init lacks a __init
annotation or the annotation of hyp_cpu_pm_exit is wrong.
WARNING: modpost: vmlinux.o(.text+0x97054): Section mismatch in
reference from the function init_subsystems() to the function
.init.text:hyp_cpu_pm_init()
The function init_subsystems() references
the function __init hyp_cpu_pm_init().
This is often because init_subsystems lacks a __init
annotation or the annotation of hyp_cpu_pm_init is wrong.
Remove the __init annotation so that there are no warnings regardless of
how functions are inlined.
Fixes: 1fcf7ce0c602 ("arm: kvm: implement CPU PM notifier")
Fixes: 06a71a24bae5 ("arm64: KVM: unregister notifiers in hyp mode teardown path")
Link: https://github.com/ClangBuiltLinux/linux/issues/1230
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
arch/arm64/kvm/arm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 6e637d2b4cfb..71a49eae9ea0 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -1574,12 +1574,12 @@ static struct notifier_block hyp_init_cpu_pm_nb = {
.notifier_call = hyp_init_cpu_pm_notifier,
};
-static void __init hyp_cpu_pm_init(void)
+static void hyp_cpu_pm_init(void)
{
if (!is_protected_kvm_enabled())
cpu_pm_register_notifier(&hyp_init_cpu_pm_nb);
}
-static void __init hyp_cpu_pm_exit(void)
+static void hyp_cpu_pm_exit(void)
{
if (!is_protected_kvm_enabled())
cpu_pm_unregister_notifier(&hyp_init_cpu_pm_nb);
base-commit: 5c8fe583cce542aa0b84adc939ce85293de36e5e
--
2.30.0
^ permalink raw reply related [relevance 94%]
* [PATCH] mt76: Fix queue ID variable types after mcu queue split
@ 2020-12-29 21:15 83% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-29 21:15 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi
Cc: Ryder Lee, Kalle Valo, linux-wireless, netdev, linux-mediatek,
linux-kernel, clang-built-linux, Nathan Chancellor
Clang warns in both mt7615 and mt7915:
drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:271:9: warning: implicit
conversion from enumeration type 'enum mt76_mcuq_id' to different
enumeration type 'enum mt76_txq_id' [-Wenum-conversion]
txq = MT_MCUQ_FWDL;
~ ^~~~~~~~~~~~
drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:278:9: warning: implicit
conversion from enumeration type 'enum mt76_mcuq_id' to different
enumeration type 'enum mt76_txq_id' [-Wenum-conversion]
txq = MT_MCUQ_WA;
~ ^~~~~~~~~~
drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:282:9: warning: implicit
conversion from enumeration type 'enum mt76_mcuq_id' to different
enumeration type 'enum mt76_txq_id' [-Wenum-conversion]
txq = MT_MCUQ_WM;
~ ^~~~~~~~~~
3 warnings generated.
drivers/net/wireless/mediatek/mt76/mt7615/mcu.c:238:9: warning: implicit
conversion from enumeration type 'enum mt76_mcuq_id' to different
enumeration type 'enum mt76_txq_id' [-Wenum-conversion]
qid = MT_MCUQ_WM;
~ ^~~~~~~~~~
drivers/net/wireless/mediatek/mt76/mt7615/mcu.c:240:9: warning: implicit
conversion from enumeration type 'enum mt76_mcuq_id' to different
enumeration type 'enum mt76_txq_id' [-Wenum-conversion]
qid = MT_MCUQ_FWDL;
~ ^~~~~~~~~~~~
2 warnings generated.
Use the proper type for the queue ID variables to fix these warnings.
Additionally, rename the txq variable in mt7915_mcu_send_message to be
more neutral like mt7615_mcu_send_message.
Fixes: e637763b606b ("mt76: move mcu queues to mt76_dev q_mcu array")
Link: https://github.com/ClangBuiltLinux/linux/issues/1229
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 2 +-
drivers/net/wireless/mediatek/mt76/mt7915/mcu.c | 10 +++++-----
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
index a44b7766dec6..c13547841a4e 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
@@ -231,7 +231,7 @@ mt7615_mcu_send_message(struct mt76_dev *mdev, struct sk_buff *skb,
int cmd, int *seq)
{
struct mt7615_dev *dev = container_of(mdev, struct mt7615_dev, mt76);
- enum mt76_txq_id qid;
+ enum mt76_mcuq_id qid;
mt7615_mcu_fill_msg(dev, skb, cmd, seq);
if (test_bit(MT76_STATE_MCU_RUNNING, &dev->mphy.state))
diff --git a/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c
index 5fdd1a6d32ee..e211a2bd4d3c 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c
@@ -256,7 +256,7 @@ mt7915_mcu_send_message(struct mt76_dev *mdev, struct sk_buff *skb,
struct mt7915_dev *dev = container_of(mdev, struct mt7915_dev, mt76);
struct mt7915_mcu_txd *mcu_txd;
u8 seq, pkt_fmt, qidx;
- enum mt76_txq_id txq;
+ enum mt76_mcuq_id qid;
__le32 *txd;
u32 val;
@@ -268,18 +268,18 @@ mt7915_mcu_send_message(struct mt76_dev *mdev, struct sk_buff *skb,
seq = ++dev->mt76.mcu.msg_seq & 0xf;
if (cmd == -MCU_CMD_FW_SCATTER) {
- txq = MT_MCUQ_FWDL;
+ qid = MT_MCUQ_FWDL;
goto exit;
}
mcu_txd = (struct mt7915_mcu_txd *)skb_push(skb, sizeof(*mcu_txd));
if (test_bit(MT76_STATE_MCU_RUNNING, &dev->mphy.state)) {
- txq = MT_MCUQ_WA;
+ qid = MT_MCUQ_WA;
qidx = MT_TX_MCU_PORT_RX_Q0;
pkt_fmt = MT_TX_TYPE_CMD;
} else {
- txq = MT_MCUQ_WM;
+ qid = MT_MCUQ_WM;
qidx = MT_TX_MCU_PORT_RX_Q0;
pkt_fmt = MT_TX_TYPE_CMD;
}
@@ -326,7 +326,7 @@ mt7915_mcu_send_message(struct mt76_dev *mdev, struct sk_buff *skb,
if (wait_seq)
*wait_seq = seq;
- return mt76_tx_queue_skb_raw(dev, mdev->q_mcu[txq], skb, 0);
+ return mt76_tx_queue_skb_raw(dev, mdev->q_mcu[qid], skb, 0);
}
static void
base-commit: 5c8fe583cce542aa0b84adc939ce85293de36e5e
--
2.30.0
^ permalink raw reply related [relevance 83%]
* [PATCH] mt76: Fix queue ID variable types after mcu queue split
@ 2020-12-29 21:15 83% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-29 21:15 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi
Cc: Ryder Lee, netdev, linux-wireless, linux-kernel,
clang-built-linux, linux-mediatek, Nathan Chancellor, Kalle Valo
Clang warns in both mt7615 and mt7915:
drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:271:9: warning: implicit
conversion from enumeration type 'enum mt76_mcuq_id' to different
enumeration type 'enum mt76_txq_id' [-Wenum-conversion]
txq = MT_MCUQ_FWDL;
~ ^~~~~~~~~~~~
drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:278:9: warning: implicit
conversion from enumeration type 'enum mt76_mcuq_id' to different
enumeration type 'enum mt76_txq_id' [-Wenum-conversion]
txq = MT_MCUQ_WA;
~ ^~~~~~~~~~
drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:282:9: warning: implicit
conversion from enumeration type 'enum mt76_mcuq_id' to different
enumeration type 'enum mt76_txq_id' [-Wenum-conversion]
txq = MT_MCUQ_WM;
~ ^~~~~~~~~~
3 warnings generated.
drivers/net/wireless/mediatek/mt76/mt7615/mcu.c:238:9: warning: implicit
conversion from enumeration type 'enum mt76_mcuq_id' to different
enumeration type 'enum mt76_txq_id' [-Wenum-conversion]
qid = MT_MCUQ_WM;
~ ^~~~~~~~~~
drivers/net/wireless/mediatek/mt76/mt7615/mcu.c:240:9: warning: implicit
conversion from enumeration type 'enum mt76_mcuq_id' to different
enumeration type 'enum mt76_txq_id' [-Wenum-conversion]
qid = MT_MCUQ_FWDL;
~ ^~~~~~~~~~~~
2 warnings generated.
Use the proper type for the queue ID variables to fix these warnings.
Additionally, rename the txq variable in mt7915_mcu_send_message to be
more neutral like mt7615_mcu_send_message.
Fixes: e637763b606b ("mt76: move mcu queues to mt76_dev q_mcu array")
Link: https://github.com/ClangBuiltLinux/linux/issues/1229
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 2 +-
drivers/net/wireless/mediatek/mt76/mt7915/mcu.c | 10 +++++-----
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
index a44b7766dec6..c13547841a4e 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
@@ -231,7 +231,7 @@ mt7615_mcu_send_message(struct mt76_dev *mdev, struct sk_buff *skb,
int cmd, int *seq)
{
struct mt7615_dev *dev = container_of(mdev, struct mt7615_dev, mt76);
- enum mt76_txq_id qid;
+ enum mt76_mcuq_id qid;
mt7615_mcu_fill_msg(dev, skb, cmd, seq);
if (test_bit(MT76_STATE_MCU_RUNNING, &dev->mphy.state))
diff --git a/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c
index 5fdd1a6d32ee..e211a2bd4d3c 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c
@@ -256,7 +256,7 @@ mt7915_mcu_send_message(struct mt76_dev *mdev, struct sk_buff *skb,
struct mt7915_dev *dev = container_of(mdev, struct mt7915_dev, mt76);
struct mt7915_mcu_txd *mcu_txd;
u8 seq, pkt_fmt, qidx;
- enum mt76_txq_id txq;
+ enum mt76_mcuq_id qid;
__le32 *txd;
u32 val;
@@ -268,18 +268,18 @@ mt7915_mcu_send_message(struct mt76_dev *mdev, struct sk_buff *skb,
seq = ++dev->mt76.mcu.msg_seq & 0xf;
if (cmd == -MCU_CMD_FW_SCATTER) {
- txq = MT_MCUQ_FWDL;
+ qid = MT_MCUQ_FWDL;
goto exit;
}
mcu_txd = (struct mt7915_mcu_txd *)skb_push(skb, sizeof(*mcu_txd));
if (test_bit(MT76_STATE_MCU_RUNNING, &dev->mphy.state)) {
- txq = MT_MCUQ_WA;
+ qid = MT_MCUQ_WA;
qidx = MT_TX_MCU_PORT_RX_Q0;
pkt_fmt = MT_TX_TYPE_CMD;
} else {
- txq = MT_MCUQ_WM;
+ qid = MT_MCUQ_WM;
qidx = MT_TX_MCU_PORT_RX_Q0;
pkt_fmt = MT_TX_TYPE_CMD;
}
@@ -326,7 +326,7 @@ mt7915_mcu_send_message(struct mt76_dev *mdev, struct sk_buff *skb,
if (wait_seq)
*wait_seq = seq;
- return mt76_tx_queue_skb_raw(dev, mdev->q_mcu[txq], skb, 0);
+ return mt76_tx_queue_skb_raw(dev, mdev->q_mcu[qid], skb, 0);
}
static void
base-commit: 5c8fe583cce542aa0b84adc939ce85293de36e5e
--
2.30.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [relevance 83%]
* [PATCH] pinctrl: nomadik: Remove unused variable in nmk_gpio_dbg_show_one
@ 2020-12-29 20:47 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-29 20:47 UTC (permalink / raw)
To: Thomas Gleixner, Linus Walleij
Cc: linux-gpio, Nathan Chancellor, linux-kernel, linux-arm-kernel,
clang-built-linux
Clang warns:
drivers/pinctrl/nomadik/pinctrl-nomadik.c:952:8: warning: unused
variable 'wake' [-Wunused-variable]
bool wake;
^
1 warning generated.
There were two wake declarations added to nmk_gpio_dbg_show_one when
converting it to use irq_has_action but only one is used within its
scope. Remove the unused one so there is no more warning.
Fixes: f3925032d7fd ("pinctrl: nomadik: Use irq_has_action()")
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/pinctrl/nomadik/pinctrl-nomadik.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/pinctrl/nomadik/pinctrl-nomadik.c b/drivers/pinctrl/nomadik/pinctrl-nomadik.c
index d4ea10803fd9..abfe11c7b49f 100644
--- a/drivers/pinctrl/nomadik/pinctrl-nomadik.c
+++ b/drivers/pinctrl/nomadik/pinctrl-nomadik.c
@@ -949,7 +949,6 @@ static void nmk_gpio_dbg_show_one(struct seq_file *s,
} else {
int irq = chip->to_irq(chip, offset);
const int pullidx = pull ? 1 : 0;
- bool wake;
int val;
static const char * const pulls[] = {
"none ",
base-commit: 5c8fe583cce542aa0b84adc939ce85293de36e5e
--
2.30.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [relevance 99%]
* [PATCH] pinctrl: nomadik: Remove unused variable in nmk_gpio_dbg_show_one
@ 2020-12-29 20:47 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-29 20:47 UTC (permalink / raw)
To: Thomas Gleixner, Linus Walleij
Cc: linux-arm-kernel, linux-gpio, linux-kernel, clang-built-linux,
Nathan Chancellor
Clang warns:
drivers/pinctrl/nomadik/pinctrl-nomadik.c:952:8: warning: unused
variable 'wake' [-Wunused-variable]
bool wake;
^
1 warning generated.
There were two wake declarations added to nmk_gpio_dbg_show_one when
converting it to use irq_has_action but only one is used within its
scope. Remove the unused one so there is no more warning.
Fixes: f3925032d7fd ("pinctrl: nomadik: Use irq_has_action()")
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/pinctrl/nomadik/pinctrl-nomadik.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/pinctrl/nomadik/pinctrl-nomadik.c b/drivers/pinctrl/nomadik/pinctrl-nomadik.c
index d4ea10803fd9..abfe11c7b49f 100644
--- a/drivers/pinctrl/nomadik/pinctrl-nomadik.c
+++ b/drivers/pinctrl/nomadik/pinctrl-nomadik.c
@@ -949,7 +949,6 @@ static void nmk_gpio_dbg_show_one(struct seq_file *s,
} else {
int irq = chip->to_irq(chip, offset);
const int pullidx = pull ? 1 : 0;
- bool wake;
int val;
static const char * const pulls[] = {
"none ",
base-commit: 5c8fe583cce542aa0b84adc939ce85293de36e5e
--
2.30.0
^ permalink raw reply related [relevance 99%]
* Re: [PATCH 5.10 212/717] platform/x86: mlx-platform: Remove PSU EEPROM from MSN274x platform configuration
@ 2020-12-29 19:01 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-29 19:01 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, Vadim Pasternak, Hans de Goede, Sasha Levin
On Mon, Dec 28, 2020 at 01:43:30PM +0100, Greg Kroah-Hartman wrote:
> From: Vadim Pasternak <vadimp@nvidia.com>
>
> [ Upstream commit 912b341585e302ee44fc5a2733f7bcf505e2c86f ]
>
> Remove PSU EEPROM configuration for systems class equipped with
> Mellanox chip Spectrum and ATOM CPU - system types MSN274x. Till now
> all the systems from this class used few types of power units, all
> equipped with EEPROM device with address space two bytes. Thus, all
> these devices have been handled by EEPROM driver "24c02".
>
> There is a new requirement is to support power unit replacement by "off
> the shelf" device, matching electrical required parameters. Such device
> can be equipped with different EEPROM type, which could be one byte
> address space addressing or even could be not equipped with EEPROM.
> In such case "24c02" will not work.
>
> Fixes: ef08e14a3 ("platform/x86: mlx-platform: Add support for new msn274x system type")
> Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
> Link: https://lore.kernel.org/r/20201125101056.174708-3-vadimp@nvidia.com
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
> drivers/platform/x86/mlx-platform.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/platform/x86/mlx-platform.c b/drivers/platform/x86/mlx-platform.c
> index 623e7f737d4ab..598f445587649 100644
> --- a/drivers/platform/x86/mlx-platform.c
> +++ b/drivers/platform/x86/mlx-platform.c
> @@ -601,15 +601,13 @@ static struct mlxreg_core_data mlxplat_mlxcpld_msn274x_psu_items_data[] = {
> .label = "psu1",
> .reg = MLXPLAT_CPLD_LPC_REG_PSU_OFFSET,
> .mask = BIT(0),
> - .hpdev.brdinfo = &mlxplat_mlxcpld_psu[0],
> - .hpdev.nr = MLXPLAT_CPLD_PSU_MSNXXXX_NR,
> + .hpdev.nr = MLXPLAT_CPLD_NR_NONE,
> },
> {
> .label = "psu2",
> .reg = MLXPLAT_CPLD_LPC_REG_PSU_OFFSET,
> .mask = BIT(1),
> - .hpdev.brdinfo = &mlxplat_mlxcpld_psu[1],
> - .hpdev.nr = MLXPLAT_CPLD_PSU_MSNXXXX_NR,
> + .hpdev.nr = MLXPLAT_CPLD_NR_NONE,
> },
> };
>
> --
> 2.27.0
>
>
>
Please pick up eca6ba20f38c ("platform/x86: mlx-platform: remove an
unused variable") everywhere that this patch was applied to avoid
introducing a new clang warning.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH v2] arch/x86: Propagate $(CLANG_FLAGS) to $(REALMODE_FLAGS)
@ 2020-12-27 3:31 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-27 3:31 UTC (permalink / raw)
To: John Millikin
Cc: hpa, x86, linux-kernel, clang-built-linux, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, John Millikin
On Sat, Dec 26, 2020 at 05:41:25PM +0900, John Millikin wrote:
> When cross-compiling with Clang, the `$(CLANG_FLAGS)' variable
> contains additional flags needed to build C and assembly sources
> for the target platform. Normally this variable is automatically
> included in `$(KBUILD_CFLAGS)' by via the top-level Makefile.
>
> The x86 real-mode makefile builds `$(REALMODE_CFLAGS)' from a
> plain assignment and therefore drops the Clang flags. This causes
> Clang to not recognize x86-specific assembler directives:
>
> arch/x86/realmode/rm/header.S:36:1: error: unknown directive
> .type real_mode_header STT_OBJECT ; .size real_mode_header, .-real_mode_header
> ^
>
> Explicit propagation of `$(CLANG_FLAGS)' to `$(REALMODE_CFLAGS)',
> which is inherited by real-mode make rules, fixes cross-compilation
> with Clang for x86 targets.
>
> Relevant flags:
>
> * `--target' sets the target architecture when cross-compiling. This
> flag must be set for both compilation and assembly (`KBUILD_AFLAGS')
> to support architecture-specific assembler directives.
>
> * `-no-integrated-as' tells clang to assemble with GNU Assembler
> instead of its built-in LLVM assembler. This flag is set by default
> unless `LLVM_IAS=1' is set, because the LLVM assembler can't yet
> parse certain GNU extensions.
>
> Signed-off-by: John Millikin <john@john-millikin.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> Changes in v2:
> - Reworded the commit message to highlight that this is for
> cross-compilation.
> - Removed the `ifdef CONFIG_CC_IS_CLANG' guard.
>
> arch/x86/Makefile | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/x86/Makefile b/arch/x86/Makefile
> index 7116da3980be..412b849063ec 100644
> --- a/arch/x86/Makefile
> +++ b/arch/x86/Makefile
> @@ -33,6 +33,7 @@ REALMODE_CFLAGS += -ffreestanding
> REALMODE_CFLAGS += -fno-stack-protector
> REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), -Wno-address-of-packed-member)
> REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS), $(cc_stack_align4))
> +REALMODE_CFLAGS += $(CLANG_FLAGS)
> export REALMODE_CFLAGS
>
> # BITS is used as extension for files which are available in a 32 bit
> --
> 2.29.2
>
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] arch/x86: Propagate $(CLANG_FLAGS) to $(REALMODE_FLAGS)
@ 2020-12-26 7:53 97% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2020-12-26 7:53 UTC (permalink / raw)
To: hpa
Cc: John Millikin, x86, linux-kernel, clang-built-linux,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, John Millikin
On Fri, Dec 25, 2020 at 11:35:28PM -0800, hpa@zytor.com wrote:
> On December 25, 2020 11:29:30 PM PST, John Millikin <jmillikin@gmail.com> wrote:
> >When compiling with Clang, the `$(CLANG_FLAGS)' variable contains
> >additional flags needed to cross-compile C and Assembly sources:
I am not sure how or if others agree but it took me a second to realize
the purpose of this change was cross compiling even though I read the
commit message so I think it should be called out a bit more. I would
argue that it is not very common to see x86 cross compiled (I know
Stephen Rothwell does) :) x86 is one of the most tested architectures
for building with clang and we have see no recent failures in the boot
or realmode code.
> >* `-no-integrated-as' tells clang to assemble with GNU Assembler
> > instead of its built-in LLVM assembler. This flag is set by default
> > unless `LLVM_IAS=1' is set, because the LLVM assembler can't yet
> > parse certain GNU extensions.
> >
> >* `--target' sets the target architecture when cross-compiling. This
> > flag must be set for both compilation and assembly (`KBUILD_AFLAGS')
> > to support architecture-specific assembler directives.
> >
> >Signed-off-by: John Millikin <john@john-millikin.com>
> >---
> > arch/x86/Makefile | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> >diff --git a/arch/x86/Makefile b/arch/x86/Makefile
> >index 7116da3980be..725c65532482 100644
> >--- a/arch/x86/Makefile
> >+++ b/arch/x86/Makefile
> >@@ -33,6 +33,11 @@ REALMODE_CFLAGS += -ffreestanding
> > REALMODE_CFLAGS += -fno-stack-protector
> > REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS),
> >-Wno-address-of-packed-member)
> > REALMODE_CFLAGS += $(call __cc-option, $(CC), $(REALMODE_CFLAGS),
> >$(cc_stack_align4))
> >+
> >+ifdef CONFIG_CC_IS_CLANG
> >+REALMODE_CFLAGS += $(CLANG_FLAGS)
> >+endif
> >+
> > export REALMODE_CFLAGS
> >
> > # BITS is used as extension for files which are available in a 32 bit
>
> Why is CLANG_FLAGS non-null when unused? It would be better to centralize that.
It isn't.
$ rg "CLANG_FLAGS :=" Makefile
507:CLANG_FLAGS :=
$ rg "CLANG_FLAGS\t" Makefile
564:CLANG_FLAGS += --target=$(notdir $(CROSS_COMPILE:%-=%))
566:CLANG_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE))
570:CLANG_FLAGS += --gcc-toolchain=$(GCC_TOOLCHAIN)
573:CLANG_FLAGS += -no-integrated-as
575:CLANG_FLAGS += -Werror=unknown-warning-option
The ifdef can be dropped and unconditonally add CLANG_FLAGS to
REALMODE_CFLAGS, as is done in a few arch directories:
$ rg "\(CLANG_FLAGS\)" arch | cat
arch/s390/purgatory/Makefile:KBUILD_CFLAGS += $(CLANG_FLAGS)
arch/s390/Makefile:KBUILD_AFLAGS_DECOMPRESSOR := $(CLANG_FLAGS) -m64 -D__ASSEMBLY__
arch/s390/Makefile:KBUILD_CFLAGS_DECOMPRESSOR := $(CLANG_FLAGS) -m64 -O2
arch/powerpc/boot/Makefile:BOOTCFLAGS += $(CLANG_FLAGS)
arch/powerpc/boot/Makefile:BOOTAFLAGS += $(CLANG_FLAGS)
Cheers,
Nathan
^ permalink raw reply [relevance 97%]
* [PATCH] mfd: ab8500-debugfs: Remove extraneous curly brace
@ 2020-12-26 1:35 99% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-26 1:35 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linus Walleij, Lee Jones, Thomas Gleixner, linux-kernel,
Nathan Chancellor
Clang errors:
../drivers/mfd/ab8500-debugfs.c:1526:2: error: non-void function does
not return a value [-Werror,-Wreturn-type]
}
^
../drivers/mfd/ab8500-debugfs.c:1528:2: error: expected identifier or '('
return 0;
^
../drivers/mfd/ab8500-debugfs.c:1529:1: error: extraneous closing brace ('}')
}
^
3 errors generated.
The cleanup in ab8500_interrupts_show left a curly brace around, remove
it to fix the error.
Fixes: 886c8121659d ("mfd: ab8500-debugfs: Remove the racy fiddling with irq_desc")
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/mfd/ab8500-debugfs.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/mfd/ab8500-debugfs.c b/drivers/mfd/ab8500-debugfs.c
index a32039366a93..1cf84562351e 100644
--- a/drivers/mfd/ab8500-debugfs.c
+++ b/drivers/mfd/ab8500-debugfs.c
@@ -1521,7 +1521,6 @@ static int ab8500_interrupts_show(struct seq_file *s, void *p)
line + irq_first,
num_interrupts[line],
num_wake_interrupts[line]);
- }
seq_putc(s, '\n');
}
base-commit: 61d791365b72a89062fbbea69aa61479476da946
--
2.30.0.rc1
^ permalink raw reply related [relevance 99%]
* [PATCH] i3c/master/mipi-i3c-hci: Fix position of __maybe_unused in i3c_hci_of_match
@ 2020-12-22 2:59 98% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-22 2:59 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Nick Desaulniers, linux-kernel, Nicolas Pitre, clang-built-linux,
Nathan Chancellor, linux-i3c
Clang warns:
../drivers/i3c/master/mipi-i3c-hci/core.c:780:21: warning: attribute
declaration must precede definition [-Wignored-attributes]
static const struct __maybe_unused of_device_id i3c_hci_of_match[] = {
^
../include/linux/compiler_attributes.h:267:56: note: expanded from macro
'__maybe_unused'
#define __maybe_unused __attribute__((__unused__))
^
../include/linux/mod_devicetable.h:262:8: note: previous definition is
here
struct of_device_id {
^
1 warning generated.
'struct of_device_id' should not be split, as it is a type. Move the
__maybe_unused attribute after the static and const qualifiers so that
there are no warnings about this variable, period.
Fixes: 95393f3e07ab ("i3c/master/mipi-i3c-hci: quiet maybe-unused variable warning")
Link: https://github.com/ClangBuiltLinux/linux/issues/1221
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/i3c/master/mipi-i3c-hci/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i3c/master/mipi-i3c-hci/core.c b/drivers/i3c/master/mipi-i3c-hci/core.c
index 500abd27fb22..1b73647cc3b1 100644
--- a/drivers/i3c/master/mipi-i3c-hci/core.c
+++ b/drivers/i3c/master/mipi-i3c-hci/core.c
@@ -777,7 +777,7 @@ static int i3c_hci_remove(struct platform_device *pdev)
return 0;
}
-static const struct __maybe_unused of_device_id i3c_hci_of_match[] = {
+static const __maybe_unused struct of_device_id i3c_hci_of_match[] = {
{ .compatible = "mipi-i3c-hci", },
{},
};
base-commit: 95393f3e07ab53855b91881692a4a5b52dcdc03c
--
2.30.0.rc1
--
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c
^ permalink raw reply related [relevance 97%]
* Re: [PATCH 3/3] ibmvfc: use correlation token to tag commands
@ 2020-12-22 6:24 94% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-22 6:24 UTC (permalink / raw)
To: Tyrel Datwyler
Cc: martin.petersen, linux-scsi, linux-kernel, james.bottomley,
clang-built-linux, brking, linuxppc-dev
On Tue, Nov 17, 2020 at 12:50:31PM -0600, Tyrel Datwyler wrote:
> The vfcFrame correlation field is 64bit handle that is intended to trace
> I/O operations through both the client stack and VIOS stack when the
> underlying physical FC adapter supports tagging.
>
> Tag vfcFrames with the associated ibmvfc_event pointer handle.
>
> Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
> ---
> drivers/scsi/ibmvscsi/ibmvfc.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
> index 0cab4b852b48..3922441a117d 100644
> --- a/drivers/scsi/ibmvscsi/ibmvfc.c
> +++ b/drivers/scsi/ibmvscsi/ibmvfc.c
> @@ -1693,6 +1693,8 @@ static int ibmvfc_queuecommand_lck(struct scsi_cmnd *cmnd,
> vfc_cmd->iu.pri_task_attr = IBMVFC_SIMPLE_TASK;
> }
>
> + vfc_cmd->correlation = cpu_to_be64(evt);
> +
> if (likely(!(rc = ibmvfc_map_sg_data(cmnd, evt, vfc_cmd, vhost->dev))))
> return ibmvfc_send_event(evt, vhost, 0);
>
> @@ -2370,6 +2372,8 @@ static int ibmvfc_abort_task_set(struct scsi_device *sdev)
> tmf->iu.tmf_flags = IBMVFC_ABORT_TASK_SET;
> evt->sync_iu = &rsp_iu;
>
> + tmf->correlation = cpu_to_be64(evt);
> +
> init_completion(&evt->comp);
> rsp_rc = ibmvfc_send_event(evt, vhost, default_timeout);
> }
> --
> 2.27.0
>
This patch introduces a clang warning, is this intentional behavior?
$ make -skj"$(nproc)" ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- LLVM=1 O=out distclean ppc64le_defconfig drivers/scsi/ibmvscsi/ibmvfc.o
Using ../arch/powerpc/configs/ppc64_defconfig as base
Merging ../arch/powerpc/configs/le.config
#
# merged configuration written to .config (needs make)
#
../drivers/scsi/ibmvscsi/ibmvfc.c:1747:25: warning: incompatible pointer to integer conversion passing 'struct ibmvfc_event *' to parameter of type '__u64' (aka 'unsigned long long') [-Wint-conversion]
vfc_cmd->correlation = cpu_to_be64(evt);
^~~~~~~~~~~~~~~~
../include/linux/byteorder/generic.h:92:21: note: expanded from macro 'cpu_to_be64'
#define cpu_to_be64 __cpu_to_be64
^
../include/uapi/linux/byteorder/little_endian.h:37:52: note: expanded from macro '__cpu_to_be64'
#define __cpu_to_be64(x) ((__force __be64)__swab64((x)))
~~~~~~~~~^~~~
../include/uapi/linux/swab.h:133:12: note: expanded from macro '__swab64'
__fswab64(x))
^
../include/uapi/linux/swab.h:66:57: note: passing argument to parameter 'val' here
static inline __attribute_const__ __u64 __fswab64(__u64 val)
^
../drivers/scsi/ibmvscsi/ibmvfc.c:2421:22: warning: incompatible pointer to integer conversion passing 'struct ibmvfc_event *' to parameter of type '__u64' (aka 'unsigned long long') [-Wint-conversion]
tmf->correlation = cpu_to_be64(evt);
^~~~~~~~~~~~~~~~
../include/linux/byteorder/generic.h:92:21: note: expanded from macro 'cpu_to_be64'
#define cpu_to_be64 __cpu_to_be64
^
../include/uapi/linux/byteorder/little_endian.h:37:52: note: expanded from macro '__cpu_to_be64'
#define __cpu_to_be64(x) ((__force __be64)__swab64((x)))
~~~~~~~~~^~~~
../include/uapi/linux/swab.h:133:12: note: expanded from macro '__swab64'
__fswab64(x))
^
../include/uapi/linux/swab.h:66:57: note: passing argument to parameter 'val' here
static inline __attribute_const__ __u64 __fswab64(__u64 val)
^
2 warnings generated.
Cheers,
Nathan
^ permalink raw reply [relevance 94%]
* Re: [PATCH 3/3] ibmvfc: use correlation token to tag commands
@ 2020-12-22 6:24 94% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-22 6:24 UTC (permalink / raw)
To: Tyrel Datwyler
Cc: james.bottomley, martin.petersen, linux-scsi, linuxppc-dev,
linux-kernel, brking, clang-built-linux
On Tue, Nov 17, 2020 at 12:50:31PM -0600, Tyrel Datwyler wrote:
> The vfcFrame correlation field is 64bit handle that is intended to trace
> I/O operations through both the client stack and VIOS stack when the
> underlying physical FC adapter supports tagging.
>
> Tag vfcFrames with the associated ibmvfc_event pointer handle.
>
> Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
> ---
> drivers/scsi/ibmvscsi/ibmvfc.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
> index 0cab4b852b48..3922441a117d 100644
> --- a/drivers/scsi/ibmvscsi/ibmvfc.c
> +++ b/drivers/scsi/ibmvscsi/ibmvfc.c
> @@ -1693,6 +1693,8 @@ static int ibmvfc_queuecommand_lck(struct scsi_cmnd *cmnd,
> vfc_cmd->iu.pri_task_attr = IBMVFC_SIMPLE_TASK;
> }
>
> + vfc_cmd->correlation = cpu_to_be64(evt);
> +
> if (likely(!(rc = ibmvfc_map_sg_data(cmnd, evt, vfc_cmd, vhost->dev))))
> return ibmvfc_send_event(evt, vhost, 0);
>
> @@ -2370,6 +2372,8 @@ static int ibmvfc_abort_task_set(struct scsi_device *sdev)
> tmf->iu.tmf_flags = IBMVFC_ABORT_TASK_SET;
> evt->sync_iu = &rsp_iu;
>
> + tmf->correlation = cpu_to_be64(evt);
> +
> init_completion(&evt->comp);
> rsp_rc = ibmvfc_send_event(evt, vhost, default_timeout);
> }
> --
> 2.27.0
>
This patch introduces a clang warning, is this intentional behavior?
$ make -skj"$(nproc)" ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- LLVM=1 O=out distclean ppc64le_defconfig drivers/scsi/ibmvscsi/ibmvfc.o
Using ../arch/powerpc/configs/ppc64_defconfig as base
Merging ../arch/powerpc/configs/le.config
#
# merged configuration written to .config (needs make)
#
../drivers/scsi/ibmvscsi/ibmvfc.c:1747:25: warning: incompatible pointer to integer conversion passing 'struct ibmvfc_event *' to parameter of type '__u64' (aka 'unsigned long long') [-Wint-conversion]
vfc_cmd->correlation = cpu_to_be64(evt);
^~~~~~~~~~~~~~~~
../include/linux/byteorder/generic.h:92:21: note: expanded from macro 'cpu_to_be64'
#define cpu_to_be64 __cpu_to_be64
^
../include/uapi/linux/byteorder/little_endian.h:37:52: note: expanded from macro '__cpu_to_be64'
#define __cpu_to_be64(x) ((__force __be64)__swab64((x)))
~~~~~~~~~^~~~
../include/uapi/linux/swab.h:133:12: note: expanded from macro '__swab64'
__fswab64(x))
^
../include/uapi/linux/swab.h:66:57: note: passing argument to parameter 'val' here
static inline __attribute_const__ __u64 __fswab64(__u64 val)
^
../drivers/scsi/ibmvscsi/ibmvfc.c:2421:22: warning: incompatible pointer to integer conversion passing 'struct ibmvfc_event *' to parameter of type '__u64' (aka 'unsigned long long') [-Wint-conversion]
tmf->correlation = cpu_to_be64(evt);
^~~~~~~~~~~~~~~~
../include/linux/byteorder/generic.h:92:21: note: expanded from macro 'cpu_to_be64'
#define cpu_to_be64 __cpu_to_be64
^
../include/uapi/linux/byteorder/little_endian.h:37:52: note: expanded from macro '__cpu_to_be64'
#define __cpu_to_be64(x) ((__force __be64)__swab64((x)))
~~~~~~~~~^~~~
../include/uapi/linux/swab.h:133:12: note: expanded from macro '__swab64'
__fswab64(x))
^
../include/uapi/linux/swab.h:66:57: note: passing argument to parameter 'val' here
static inline __attribute_const__ __u64 __fswab64(__u64 val)
^
2 warnings generated.
Cheers,
Nathan
^ permalink raw reply [relevance 94%]
* [PATCH] i3c/master/mipi-i3c-hci: Fix position of __maybe_unused in i3c_hci_of_match
@ 2020-12-22 2:59 98% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-22 2:59 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Nick Desaulniers, Nicolas Pitre, linux-i3c, linux-kernel,
clang-built-linux, Nathan Chancellor
Clang warns:
../drivers/i3c/master/mipi-i3c-hci/core.c:780:21: warning: attribute
declaration must precede definition [-Wignored-attributes]
static const struct __maybe_unused of_device_id i3c_hci_of_match[] = {
^
../include/linux/compiler_attributes.h:267:56: note: expanded from macro
'__maybe_unused'
#define __maybe_unused __attribute__((__unused__))
^
../include/linux/mod_devicetable.h:262:8: note: previous definition is
here
struct of_device_id {
^
1 warning generated.
'struct of_device_id' should not be split, as it is a type. Move the
__maybe_unused attribute after the static and const qualifiers so that
there are no warnings about this variable, period.
Fixes: 95393f3e07ab ("i3c/master/mipi-i3c-hci: quiet maybe-unused variable warning")
Link: https://github.com/ClangBuiltLinux/linux/issues/1221
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/i3c/master/mipi-i3c-hci/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i3c/master/mipi-i3c-hci/core.c b/drivers/i3c/master/mipi-i3c-hci/core.c
index 500abd27fb22..1b73647cc3b1 100644
--- a/drivers/i3c/master/mipi-i3c-hci/core.c
+++ b/drivers/i3c/master/mipi-i3c-hci/core.c
@@ -777,7 +777,7 @@ static int i3c_hci_remove(struct platform_device *pdev)
return 0;
}
-static const struct __maybe_unused of_device_id i3c_hci_of_match[] = {
+static const __maybe_unused struct of_device_id i3c_hci_of_match[] = {
{ .compatible = "mipi-i3c-hci", },
{},
};
base-commit: 95393f3e07ab53855b91881692a4a5b52dcdc03c
--
2.30.0.rc1
^ permalink raw reply related [relevance 98%]
* Re: [PATCH] cpufreq: intel_pstate: remove obsolete functions
@ 2020-12-21 22:20 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-21 22:20 UTC (permalink / raw)
To: Lukas Bulwahn
Cc: Srinivas Pandruvada, Len Brown, Rafael J . Wysocki, Viresh Kumar,
linux-pm, Arnd Bergmann, Tom Rix, Nick Desaulniers,
clang-built-linux, kernel-janitors, linux-kernel
On Mon, Dec 21, 2020 at 06:13:20AM +0100, Lukas Bulwahn wrote:
> percent_fp() was used in intel_pstate_pid_reset(), which was removed in
> commit 9d0ef7af1f2d ("cpufreq: intel_pstate: Do not use PID-based P-state
> selection") and hence, percent_fp() is unused since then.
>
> percent_ext_fp() was last used in intel_pstate_update_perf_limits(), which
> was refactored in commit 1a4fe38add8b ("cpufreq: intel_pstate: Remove
> max/min fractions to limit performance"), and hence, percent_ext_fp() is
> unused since then.
>
> make CC=clang W=1 points us those unused functions:
>
> drivers/cpufreq/intel_pstate.c:79:23: warning: unused function 'percent_fp' [-Wunused-function]
> static inline int32_t percent_fp(int percent)
> ^
>
> drivers/cpufreq/intel_pstate.c:94:23: warning: unused function 'percent_ext_fp' [-Wunused-function]
> static inline int32_t percent_ext_fp(int percent)
> ^
>
> Remove those obsolete functions.
>
> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> applies cleanly on current master and next-20201221
>
> Srinivas, Len, Rafael, Viresh, please pick this minor non-urgent cleanup patch.
>
> drivers/cpufreq/intel_pstate.c | 10 ----------
> 1 file changed, 10 deletions(-)
>
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index 2a4db856222f..0e35dd247986 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -76,11 +76,6 @@ static inline int ceiling_fp(int32_t x)
> return ret;
> }
>
> -static inline int32_t percent_fp(int percent)
> -{
> - return div_fp(percent, 100);
> -}
> -
> static inline u64 mul_ext_fp(u64 x, u64 y)
> {
> return (x * y) >> EXT_FRAC_BITS;
> @@ -91,11 +86,6 @@ static inline u64 div_ext_fp(u64 x, u64 y)
> return div64_u64(x << EXT_FRAC_BITS, y);
> }
>
> -static inline int32_t percent_ext_fp(int percent)
> -{
> - return div_ext_fp(percent, 100);
> -}
> -
> /**
> * struct sample - Store performance sample
> * @core_avg_perf: Ratio of APERF/MPERF which is the actual average
> --
> 2.17.1
>
^ permalink raw reply [relevance 99%]
* Re: [PATCH] cpufreq: intel_pstate: remove obsolete functions
@ 2020-12-21 22:20 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-21 22:20 UTC (permalink / raw)
To: Lukas Bulwahn
Cc: Srinivas Pandruvada, Len Brown, Rafael J . Wysocki, Viresh Kumar,
linux-pm, Arnd Bergmann, Tom Rix, Nick Desaulniers,
clang-built-linux, kernel-janitors, linux-kernel
On Mon, Dec 21, 2020 at 06:13:20AM +0100, Lukas Bulwahn wrote:
> percent_fp() was used in intel_pstate_pid_reset(), which was removed in
> commit 9d0ef7af1f2d ("cpufreq: intel_pstate: Do not use PID-based P-state
> selection") and hence, percent_fp() is unused since then.
>
> percent_ext_fp() was last used in intel_pstate_update_perf_limits(), which
> was refactored in commit 1a4fe38add8b ("cpufreq: intel_pstate: Remove
> max/min fractions to limit performance"), and hence, percent_ext_fp() is
> unused since then.
>
> make CC=clang W=1 points us those unused functions:
>
> drivers/cpufreq/intel_pstate.c:79:23: warning: unused function 'percent_fp' [-Wunused-function]
> static inline int32_t percent_fp(int percent)
> ^
>
> drivers/cpufreq/intel_pstate.c:94:23: warning: unused function 'percent_ext_fp' [-Wunused-function]
> static inline int32_t percent_ext_fp(int percent)
> ^
>
> Remove those obsolete functions.
>
> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> applies cleanly on current master and next-20201221
>
> Srinivas, Len, Rafael, Viresh, please pick this minor non-urgent cleanup patch.
>
> drivers/cpufreq/intel_pstate.c | 10 ----------
> 1 file changed, 10 deletions(-)
>
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index 2a4db856222f..0e35dd247986 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -76,11 +76,6 @@ static inline int ceiling_fp(int32_t x)
> return ret;
> }
>
> -static inline int32_t percent_fp(int percent)
> -{
> - return div_fp(percent, 100);
> -}
> -
> static inline u64 mul_ext_fp(u64 x, u64 y)
> {
> return (x * y) >> EXT_FRAC_BITS;
> @@ -91,11 +86,6 @@ static inline u64 div_ext_fp(u64 x, u64 y)
> return div64_u64(x << EXT_FRAC_BITS, y);
> }
>
> -static inline int32_t percent_ext_fp(int percent)
> -{
> - return div_ext_fp(percent, 100);
> -}
> -
> /**
> * struct sample - Store performance sample
> * @core_avg_perf: Ratio of APERF/MPERF which is the actual average
> --
> 2.17.1
>
^ permalink raw reply [relevance 99%]
* Re: [djwong-xfs:realtime-rmap 245/249] fs/xfs/scrub/repair.c:2202:6: warning: variable 'is_free' is uninitialized when used here
@ 2020-12-21 22:19 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-21 22:19 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 4348 bytes --]
On Tue, Dec 22, 2020 at 03:22:03AM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git realtime-rmap
> head: 62eb0024d510607ecb04789e8b4f8c0975efb08b
> commit: f4188e5ab1984e1b140433a80f223ab4644801af [245/249] xfs: online repair of realtime file bmaps
> config: x86_64-randconfig-a011-20201217 (attached as .config)
> compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project cee1e7d14f4628d6174b33640d502bff3b54ae45)
> reproduce (this is a W=1 build):
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # install x86_64 cross compiling tool for clang build
> # apt-get install binutils-x86-64-linux-gnu
> # https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/commit/?id=f4188e5ab1984e1b140433a80f223ab4644801af
> git remote add djwong-xfs https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git
> git fetch --no-tags djwong-xfs realtime-rmap
> git checkout f4188e5ab1984e1b140433a80f223ab4644801af
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
>
> All warnings (new ones prefixed by >>):
>
> >> fs/xfs/scrub/repair.c:2202:6: warning: variable 'is_free' is uninitialized when used here [-Wuninitialized]
> if (is_free)
> ^~~~~~~
> fs/xfs/scrub/repair.c:2189:16: note: initialize the variable 'is_free' to silence this warning
> bool is_free;
> ^
> = 0
> 1 warning generated.
>
>
> vim +/is_free +2202 fs/xfs/scrub/repair.c
>
> 2173
> 2174 /*
> 2175 * Check if any part of this range of rt blocks is free, so that we don't
> 2176 * rebuild things with bad records. Returns -EFSCORRUPTED if bad.
> 2177 */
> 2178 int
> 2179 xrep_rtext_is_free(
> 2180 struct xfs_scrub *sc,
> 2181 xfs_rtblock_t rtbno,
> 2182 xfs_filblks_t len)
> 2183 {
> 2184 struct xfs_mount *mp = sc->mp;
> 2185 xfs_rtblock_t startext;
> 2186 xfs_rtblock_t endext;
> 2187 xfs_rtblock_t extcount;
> 2188 uint32_t mod;
> 2189 bool is_free;
> 2190 int error;
> 2191
> 2192 /* Convert rt blocks to rt extents. */
> 2193 startext = div_u64_rem(rtbno, mp->m_sb.sb_rextsize, &mod);
> 2194 endext = div_u64_rem(rtbno + len - 1, mp->m_sb.sb_rextsize, &mod);
> 2195
> 2196 /* Make sure this isn't free space. */
> 2197 extcount = endext - startext + 1;
> 2198 error = xfs_rtalloc_extent_is_free(mp, sc->tp, startext, extcount,
> 2199 &is_free);
> 2200 if (error)
> 2201 return error;
> > 2202 if (is_free)
> 2203 return -EFSCORRUPTED;
> 2204
> 2205 return 0;
> 2206 }
> 2207
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
>
This appears to be a false positive. From the config:
# CONFIG_XFS_RT is not set
which means xfs_rtalloc_extent_is_free evaluates to ENOSYS and we never
actually make it to that if statement evaluation; however, clang cannot
see this because it is doing simple static analysis at this stage of the
pipeline, not seeing that it will never have to use is_free in this
configuration. A simple reproducer:
$ cat test.c
#define func(a) 22
int main() {
int error;
_Bool is_free;
error = func(&is_free);
if (error)
return error;
if (is_free)
return -117;
return 0;
}
$ clang -Wuninitialized -fsyntax-only test.c
test.c:10:9: warning: variable 'is_free' is uninitialized when used here [-Wuninitialized]
if (is_free)
^~~~~~~
test.c:5:18: note: initialize the variable 'is_free' to silence this warning
_Bool is_free;
^
= 0
1 warning generated.
Obviously initializing is_free to false will avoid this warning, which
is probably the simplest fix.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] MAINTAINERS: Update email address for Sean Christopherson
@ 2020-12-19 6:47 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-19 6:47 UTC (permalink / raw)
To: Sean Christopherson
Cc: Paolo Bonzini, linux-kernel, Thomas Gleixner, Borislav Petkov,
Jarkko Sakkinen, Dave Hansen, Andy Lutomirski, Vitaly Kuznetsov,
Wanpeng Li, Jim Mattson, Joerg Roedel, kvm
On Thu, Nov 19, 2020 at 10:37:07AM -0800, Sean Christopherson wrote:
> From: Sean Christopherson <seanjc@google.com>
>
> Update my email address to one provided by my new benefactor.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Jarkko Sakkinen <jarkko@kernel.org>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
> Cc: Wanpeng Li <wanpengli@tencent.com>
> Cc: Jim Mattson <jmattson@google.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: kvm@vger.kernel.org
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> ---
> Resorted to sending this via a private dummy account as getting my corp
> email to play nice with git-sendemail has been further delayed, and I
> assume y'all are tired of getting bounces.
>
> .mailmap | 1 +
> MAINTAINERS | 2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/.mailmap b/.mailmap
> index 1e14566a3d56..a0d1685a165a 100644
> --- a/.mailmap
> +++ b/.mailmap
> @@ -287,6 +287,7 @@ Santosh Shilimkar <ssantosh@kernel.org>
> Sarangdhar Joshi <spjoshi@codeaurora.org>
> Sascha Hauer <s.hauer@pengutronix.de>
> S.Çağlar Onur <caglar@pardus.org.tr>
> +Sean Christopherson <seanjc@google.com> <sean.j.christopherson@intel.com>
> Sean Nyekjaer <sean@geanix.com> <sean.nyekjaer@prevas.dk>
> Sebastian Reichel <sre@kernel.org> <sebastian.reichel@collabora.co.uk>
> Sebastian Reichel <sre@kernel.org> <sre@debian.org>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4a34b25ecc1f..0478d9ef72fc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9662,7 +9662,7 @@ F: tools/testing/selftests/kvm/s390x/
>
> KERNEL VIRTUAL MACHINE FOR X86 (KVM/x86)
> M: Paolo Bonzini <pbonzini@redhat.com>
> -R: Sean Christopherson <sean.j.christopherson@intel.com>
> +R: Sean Christopherson <seanjc@google.com>
> R: Vitaly Kuznetsov <vkuznets@redhat.com>
> R: Wanpeng Li <wanpengli@tencent.com>
> R: Jim Mattson <jmattson@google.com>
> --
> 2.29.2.299.gdc1121823c-goog
>
Not sure how it happened but commit c2b1209d852f ("MAINTAINERS: Update
email address for Sean Christopherson") dropped the MAINTAINERS
hunk so it still shows your @intel.com address. I almost sent a patch
there before I realized there was a .mailmap entry while looking through
git history.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* [PATCH] KVM: SVM: Add register operand to vmsave call in sev_es_vcpu_load
@ 2020-12-19 6:37 89% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-19 6:37 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Tom Lendacky, Sean Christopherson, Vitaly Kuznetsov, Wanpeng Li,
Jim Mattson, Joerg Roedel, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, x86, kvm, linux-kernel, clang-built-linux,
Nick Desaulniers, Sami Tolvanen, Nathan Chancellor
When using LLVM's integrated assembler (LLVM_IAS=1) while building
x86_64_defconfig + CONFIG_KVM=y + CONFIG_KVM_AMD=y, the following build
error occurs:
$ make LLVM=1 LLVM_IAS=1 arch/x86/kvm/svm/sev.o
arch/x86/kvm/svm/sev.c:2004:15: error: too few operands for instruction
asm volatile(__ex("vmsave") : : "a" (__sme_page_pa(sd->save_area)) : "memory");
^
arch/x86/kvm/svm/sev.c:28:17: note: expanded from macro '__ex'
#define __ex(x) __kvm_handle_fault_on_reboot(x)
^
./arch/x86/include/asm/kvm_host.h:1646:10: note: expanded from macro '__kvm_handle_fault_on_reboot'
"666: \n\t" \
^
<inline asm>:2:2: note: instantiated into assembly here
vmsave
^
1 error generated.
This happens because LLVM currently does not support calling vmsave
without the fixed register operand (%rax for 64-bit and %eax for
32-bit). This will be fixed in LLVM 12 but the kernel currently supports
LLVM 10.0.1 and newer so this needs to be handled.
Add the proper register using the _ASM_AX macro, which matches the
vmsave call in vmenter.S.
Fixes: 861377730aa9 ("KVM: SVM: Provide support for SEV-ES vCPU loading")
Link: https://reviews.llvm.org/D93524
Link: https://github.com/ClangBuiltLinux/linux/issues/1216
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
arch/x86/kvm/svm/sev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index e57847ff8bd2..958370758ed0 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -2001,7 +2001,7 @@ void sev_es_vcpu_load(struct vcpu_svm *svm, int cpu)
* of which one step is to perform a VMLOAD. Since hardware does not
* perform a VMSAVE on VMRUN, the host savearea must be updated.
*/
- asm volatile(__ex("vmsave") : : "a" (__sme_page_pa(sd->save_area)) : "memory");
+ asm volatile(__ex("vmsave %%"_ASM_AX) : : "a" (__sme_page_pa(sd->save_area)) : "memory");
/*
* Certain MSRs are restored on VMEXIT, only save ones that aren't
--
2.30.0.rc0
^ permalink raw reply related [relevance 89%]
* Re: [PATCH v2] arm64: link with -z norelro for LLD or aarch64-elf
@ 2020-12-18 2:36 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-18 2:36 UTC (permalink / raw)
To: Nick Desaulniers
Cc: kernelci . org bot, Fāng-ruì Sòng, Will Deacon,
Quentin Perret, Catalin Marinas, Alan Modra, Peter Smith, stable,
linux-kernel, clang-built-linux, kernel-team, Ard Biesheuvel,
linux-arm-kernel
On Thu, Dec 17, 2020 at 04:24:32PM -0800, 'Nick Desaulniers' via Clang Built Linux wrote:
> With GNU binutils 2.35+, linking with BFD produces warnings for vmlinux:
> aarch64-linux-gnu-ld: warning: -z norelro ignored
>
> BFD can produce this warning when the target emulation mode does not
> support RELRO program headers, and -z relro or -z norelro is passed.
>
> Alan Modra clarifies:
> The default linker emulation for an aarch64-linux ld.bfd is
> -maarch64linux, the default for an aarch64-elf linker is
> -maarch64elf. They are not equivalent. If you choose -maarch64elf
> you get an emulation that doesn't support -z relro.
>
> The ARCH=arm64 kernel prefers -maarch64elf, but may fall back to
> -maarch64linux based on the toolchain configuration.
>
> LLD will always create RELRO program header regardless of target
> emulation.
>
> To avoid the above warning when linking with BFD, pass -z norelro only
> when linking with LLD or with -maarch64linux.
>
> Cc: Alan Modra <amodra@gmail.com>
> Cc: Fāng-ruì Sòng <maskray@google.com>
> Fixes: 3b92fa7485eb ("arm64: link with -z norelro regardless of CONFIG_RELOCATABLE")
> Reported-by: kernelci.org bot <bot@kernelci.org>
> Reported-by: Quentin Perret <qperret@google.com>
> Acked-by: Ard Biesheuvel <ardb@kernel.org>
> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> Changes V1 -> V2:
> * s/relocation types/program headers/
> * s/newer GNU binutils/GNU binutils 2.35+/
> * Pick up Ard's Ack.
>
> Note: maintainers may want to pick up the following tag:
>
> Fixes: 3bbd3db86470 ("arm64: relocatable: fix inconsistencies in linker script and options")
>
> or drop the existing fixes tag (this patch is more so in response to
> change to BFD to warn than fix a kernel regression, IMO, but I don't
> care). Either way, it would be good to fix this for the newly minted
> v5.10.y.
Should probably have
Cc: stable@vger.kernel.org
then.
> I'll probably be offline for the next two weeks for the holidays, so no
> promises on quick replies. Happy holidays+new year!
>
>
> arch/arm64/Makefile | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 6be9b3750250..90309208bb28 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -10,7 +10,7 @@
> #
> # Copyright (C) 1995-2001 by Russell King
>
> -LDFLAGS_vmlinux :=--no-undefined -X -z norelro
> +LDFLAGS_vmlinux :=--no-undefined -X
>
> ifeq ($(CONFIG_RELOCATABLE), y)
> # Pass --no-apply-dynamic-relocs to restore pre-binutils-2.27 behaviour
> @@ -115,16 +115,20 @@ KBUILD_CPPFLAGS += -mbig-endian
> CHECKFLAGS += -D__AARCH64EB__
> # Prefer the baremetal ELF build target, but not all toolchains include
> # it so fall back to the standard linux version if needed.
> -KBUILD_LDFLAGS += -EB $(call ld-option, -maarch64elfb, -maarch64linuxb)
> +KBUILD_LDFLAGS += -EB $(call ld-option, -maarch64elfb, -maarch64linuxb -z norelro)
> UTS_MACHINE := aarch64_be
> else
> KBUILD_CPPFLAGS += -mlittle-endian
> CHECKFLAGS += -D__AARCH64EL__
> # Same as above, prefer ELF but fall back to linux target if needed.
> -KBUILD_LDFLAGS += -EL $(call ld-option, -maarch64elf, -maarch64linux)
> +KBUILD_LDFLAGS += -EL $(call ld-option, -maarch64elf, -maarch64linux -z norelro)
> UTS_MACHINE := aarch64
> endif
>
> +ifeq ($(CONFIG_LD_IS_LLD), y)
> +KBUILD_LDFLAGS += -z norelro
> +endif
> +
> CHECKFLAGS += -D__aarch64__
>
> ifeq ($(CONFIG_DYNAMIC_FTRACE_WITH_REGS),y)
> --
> 2.29.2.684.gfbc64c5ab5-goog
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [relevance 99%]
* Re: [PATCH v2] arm64: link with -z norelro for LLD or aarch64-elf
@ 2020-12-18 2:36 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-18 2:36 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Catalin Marinas, Will Deacon, kernel-team, Peter Smith,
clang-built-linux, stable, Ard Biesheuvel,
Fāng-ruì Sòng, Quentin Perret, Alan Modra,
kernelci . org bot, linux-arm-kernel, linux-kernel
On Thu, Dec 17, 2020 at 04:24:32PM -0800, 'Nick Desaulniers' via Clang Built Linux wrote:
> With GNU binutils 2.35+, linking with BFD produces warnings for vmlinux:
> aarch64-linux-gnu-ld: warning: -z norelro ignored
>
> BFD can produce this warning when the target emulation mode does not
> support RELRO program headers, and -z relro or -z norelro is passed.
>
> Alan Modra clarifies:
> The default linker emulation for an aarch64-linux ld.bfd is
> -maarch64linux, the default for an aarch64-elf linker is
> -maarch64elf. They are not equivalent. If you choose -maarch64elf
> you get an emulation that doesn't support -z relro.
>
> The ARCH=arm64 kernel prefers -maarch64elf, but may fall back to
> -maarch64linux based on the toolchain configuration.
>
> LLD will always create RELRO program header regardless of target
> emulation.
>
> To avoid the above warning when linking with BFD, pass -z norelro only
> when linking with LLD or with -maarch64linux.
>
> Cc: Alan Modra <amodra@gmail.com>
> Cc: Fāng-ruì Sòng <maskray@google.com>
> Fixes: 3b92fa7485eb ("arm64: link with -z norelro regardless of CONFIG_RELOCATABLE")
> Reported-by: kernelci.org bot <bot@kernelci.org>
> Reported-by: Quentin Perret <qperret@google.com>
> Acked-by: Ard Biesheuvel <ardb@kernel.org>
> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> Changes V1 -> V2:
> * s/relocation types/program headers/
> * s/newer GNU binutils/GNU binutils 2.35+/
> * Pick up Ard's Ack.
>
> Note: maintainers may want to pick up the following tag:
>
> Fixes: 3bbd3db86470 ("arm64: relocatable: fix inconsistencies in linker script and options")
>
> or drop the existing fixes tag (this patch is more so in response to
> change to BFD to warn than fix a kernel regression, IMO, but I don't
> care). Either way, it would be good to fix this for the newly minted
> v5.10.y.
Should probably have
Cc: stable@vger.kernel.org
then.
> I'll probably be offline for the next two weeks for the holidays, so no
> promises on quick replies. Happy holidays+new year!
>
>
> arch/arm64/Makefile | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 6be9b3750250..90309208bb28 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -10,7 +10,7 @@
> #
> # Copyright (C) 1995-2001 by Russell King
>
> -LDFLAGS_vmlinux :=--no-undefined -X -z norelro
> +LDFLAGS_vmlinux :=--no-undefined -X
>
> ifeq ($(CONFIG_RELOCATABLE), y)
> # Pass --no-apply-dynamic-relocs to restore pre-binutils-2.27 behaviour
> @@ -115,16 +115,20 @@ KBUILD_CPPFLAGS += -mbig-endian
> CHECKFLAGS += -D__AARCH64EB__
> # Prefer the baremetal ELF build target, but not all toolchains include
> # it so fall back to the standard linux version if needed.
> -KBUILD_LDFLAGS += -EB $(call ld-option, -maarch64elfb, -maarch64linuxb)
> +KBUILD_LDFLAGS += -EB $(call ld-option, -maarch64elfb, -maarch64linuxb -z norelro)
> UTS_MACHINE := aarch64_be
> else
> KBUILD_CPPFLAGS += -mlittle-endian
> CHECKFLAGS += -D__AARCH64EL__
> # Same as above, prefer ELF but fall back to linux target if needed.
> -KBUILD_LDFLAGS += -EL $(call ld-option, -maarch64elf, -maarch64linux)
> +KBUILD_LDFLAGS += -EL $(call ld-option, -maarch64elf, -maarch64linux -z norelro)
> UTS_MACHINE := aarch64
> endif
>
> +ifeq ($(CONFIG_LD_IS_LLD), y)
> +KBUILD_LDFLAGS += -z norelro
> +endif
> +
> CHECKFLAGS += -D__aarch64__
>
> ifeq ($(CONFIG_DYNAMIC_FTRACE_WITH_REGS),y)
> --
> 2.29.2.684.gfbc64c5ab5-goog
>
^ permalink raw reply [relevance 99%]
* Re: [linux-next:master 6953/13205] drivers/dma/imx-dma.c:1048:20: warning: cast to smaller integer type 'enum imx_dma_type' from 'const void
@ 2020-12-12 20:03 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-12 20:03 UTC (permalink / raw)
To: Fabio Estevam
Cc: Souptick Joarder, kernel test robot, kbuild-all,
clang-built-linux, Linux Memory Management List, Vinod Koul
On Sat, Dec 12, 2020 at 12:40:22PM -0300, Fabio Estevam wrote:
> On Fri, Dec 11, 2020 at 11:54 AM Souptick Joarder <jrdr.linux@gmail.com> wrote:
>
> > of_device_get_match_data() returns void * which is assigned to enum
> > imx_dma_type type without extracting
> > the value. Anything wrong with the previous assignment ?
>
> The driver data is now passed via:
> imxdma->devtype = (enum imx_dma_type)of_device_get_match_data(&pdev->dev);
>
> There was nothing wrong with the previous assignment.
>
> The original driver used to run on non-DT platforms. Now it only runs
> on DT-platforms, which means we no longer need the platform data
> structure.
>
> Please note that this a W=1 clang warning. gcc does not complain about it.
Correct. The clang developers explicitly wanted this behavior so I moved
it under a new warning that could be disabled on regular builds but show
up on W=1 in case people wanted to fix these occurrences.
https://reviews.llvm.org/D72231
https://github.com/ClangBuiltLinux/linux/issues/887
82f2bc2fcc01 ("kbuild: Disable -Wpointer-to-enum-cast")
> Not sure how to make clang happy in this case.
Added a cast to unsigned long or uintptr_t before the cast to the enum
should fix it.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [linux-next:master 6953/13205] drivers/dma/imx-dma.c:1048:20: warning: cast to smaller integer type 'enum imx_dma_type' from 'const void
@ 2020-12-12 20:03 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-12 20:03 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 1263 bytes --]
On Sat, Dec 12, 2020 at 12:40:22PM -0300, Fabio Estevam wrote:
> On Fri, Dec 11, 2020 at 11:54 AM Souptick Joarder <jrdr.linux@gmail.com> wrote:
>
> > of_device_get_match_data() returns void * which is assigned to enum
> > imx_dma_type type without extracting
> > the value. Anything wrong with the previous assignment ?
>
> The driver data is now passed via:
> imxdma->devtype = (enum imx_dma_type)of_device_get_match_data(&pdev->dev);
>
> There was nothing wrong with the previous assignment.
>
> The original driver used to run on non-DT platforms. Now it only runs
> on DT-platforms, which means we no longer need the platform data
> structure.
>
> Please note that this a W=1 clang warning. gcc does not complain about it.
Correct. The clang developers explicitly wanted this behavior so I moved
it under a new warning that could be disabled on regular builds but show
up on W=1 in case people wanted to fix these occurrences.
https://reviews.llvm.org/D72231
https://github.com/ClangBuiltLinux/linux/issues/887
82f2bc2fcc01 ("kbuild: Disable -Wpointer-to-enum-cast")
> Not sure how to make clang happy in this case.
Added a cast to unsigned long or uintptr_t before the cast to the enum
should fix it.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH v2] mips: lib: uncached: fix non-standard usage of variable 'sp'
@ 2020-12-12 5:52 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-12 5:52 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: Anders Roxell, tsbogend, ndesaulniers, linux-mips, linux-kernel,
clang-built-linux
On Fri, Dec 11, 2020 at 07:54:07PM +0000, Maciej W. Rozycki wrote:
> On Fri, 11 Dec 2020, Anders Roxell wrote:
>
> > diff --git a/arch/mips/lib/uncached.c b/arch/mips/lib/uncached.c
> > index 09d5deea747f..f80a67c092b6 100644
> > --- a/arch/mips/lib/uncached.c
> > +++ b/arch/mips/lib/uncached.c
> > @@ -37,10 +37,12 @@
> > */
> > unsigned long run_uncached(void *func)
> > {
> > - register long sp __asm__("$sp");
> > register long ret __asm__("$2");
> > long lfunc = (long)func, ufunc;
> > long usp;
> > + long sp;
> > +
> > + __asm__("move %0, $sp" : "=r" (sp));
>
> I thought it might be better to make `sp' global instead, so that it's
> the compiler that chooses how to schedule accesses. Have you tried that?
>
> Maciej
This will not work, as the LLVM Mips backend does not support using $sp
as a global register variable:
https://github.com/llvm/llvm-project/commit/1440bb2a26ff13df1b29762658ee122cc0bc47ae
$ make -skj"$(nproc)" ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- LLVM=1 O=out \
distclean malta_kvm_guest_defconfig vmlinux
fatal error: error in backend: Invalid register name global variable
...
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [linux-next:master 12465/13205] ld.lld: error: undefined symbol: __compiletime_assert_323
@ 2020-12-12 5:36 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-12 5:36 UTC (permalink / raw)
To: kernel test robot
Cc: Kees Cook, kbuild-all, clang-built-linux,
Linux Memory Management List, Andrew Morton
On Sat, Dec 12, 2020 at 07:19:35AM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> head: 3cc2bd440f2171f093b3a8480a4b54d8c270ed38
> commit: ae56c5a72eadc2149cc49306c4a00e4c6e970384 [12465/13205] ubsan: enable for all*config builds
> config: mips-randconfig-r012-20201209 (attached as .config)
> compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 5ff35356f1af2bb92785b38c657463924d9ec386)
> reproduce (this is a W=1 build):
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # install mips cross compiling tool for clang build
> # apt-get install binutils-mips-linux-gnu
> # https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=ae56c5a72eadc2149cc49306c4a00e4c6e970384
> git remote add linux-next https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> git fetch --no-tags linux-next master
> git checkout ae56c5a72eadc2149cc49306c4a00e4c6e970384
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=mips
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
>
> Note: the linux-next/master HEAD 3cc2bd440f2171f093b3a8480a4b54d8c270ed38 builds fine.
> It may have been fixed somewhere.
>
> All errors (new ones prefixed by >>):
>
> >> ld.lld: error: undefined symbol: __compiletime_assert_323
> >>> referenced by mremap.c
> >>> mremap.o:(get_extent) in archive mm/built-in.a
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
Also filed here: https://github.com/ClangBuiltLinux/linux/issues/1212
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [linux-next:master 12465/13205] ld.lld: error: undefined symbol: __compiletime_assert_323
@ 2020-12-12 5:36 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-12 5:36 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 1966 bytes --]
On Sat, Dec 12, 2020 at 07:19:35AM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> head: 3cc2bd440f2171f093b3a8480a4b54d8c270ed38
> commit: ae56c5a72eadc2149cc49306c4a00e4c6e970384 [12465/13205] ubsan: enable for all*config builds
> config: mips-randconfig-r012-20201209 (attached as .config)
> compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 5ff35356f1af2bb92785b38c657463924d9ec386)
> reproduce (this is a W=1 build):
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # install mips cross compiling tool for clang build
> # apt-get install binutils-mips-linux-gnu
> # https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=ae56c5a72eadc2149cc49306c4a00e4c6e970384
> git remote add linux-next https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> git fetch --no-tags linux-next master
> git checkout ae56c5a72eadc2149cc49306c4a00e4c6e970384
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=mips
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
>
> Note: the linux-next/master HEAD 3cc2bd440f2171f093b3a8480a4b54d8c270ed38 builds fine.
> It may have been fixed somewhere.
>
> All errors (new ones prefixed by >>):
>
> >> ld.lld: error: undefined symbol: __compiletime_assert_323
> >>> referenced by mremap.c
> >>> mremap.o:(get_extent) in archive mm/built-in.a
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
Also filed here: https://github.com/ClangBuiltLinux/linux/issues/1212
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH 4.19-stable 4/5] spi: bcm2835aux: Fix use-after-free on unbind
@ 2020-12-08 20:28 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-08 20:28 UTC (permalink / raw)
To: Lukas Wunner
Cc: Sasha Levin, Greg Kroah-Hartman, Mark Brown, Sudip Mukherjee, stable
On Tue, Dec 08, 2020 at 06:11:45PM +0100, Lukas Wunner wrote:
> On Tue, Dec 08, 2020 at 08:47:39AM -0500, Sasha Levin wrote:
> > On Tue, Dec 08, 2020 at 08:32:41AM +0100, Lukas Wunner wrote:
> > > On Mon, Dec 07, 2020 at 05:49:01PM -0700, Nathan Chancellor wrote:
> > > > On Sun, Dec 06, 2020 at 01:31:03PM +0100, Lukas Wunner wrote:
> > > > > [ Upstream commit e13ee6cc4781edaf8c7321bee19217e3702ed481 ]
> > > > >
> > > > > bcm2835aux_spi_remove() accesses the driver's private data after calling
> > > > > spi_unregister_master() even though that function releases the last
> > > > > reference on the spi_master and thereby frees the private data.
> > > > >
> > > > > Fix by switching over to the new devm_spi_alloc_master() helper which
> > > > > keeps the private data accessible until the driver has unbound.
> > > > >
> > > > > Fixes: b9dd3f6d4172 ("spi: bcm2835aux: Fix controller unregister order")
> > > > > Signed-off-by: Lukas Wunner <lukas@wunner.de>
> > > > > Cc: <stable@vger.kernel.org> # v4.4+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation
> > > > > Cc: <stable@vger.kernel.org> # v4.4+: b9dd3f6d4172: spi: bcm2835aux: Fix controller unregister order
> > > > > Cc: <stable@vger.kernel.org> # v4.4+
> > > > > Link: https://lore.kernel.org/r/b290b06357d0c0bdee9cecc539b840a90630f101.1605121038.git.lukas@wunner.de
> > > > > Signed-off-by: Mark Brown <broonie@kernel.org>
> > > >
> > > > Please ensure that commit d853b3406903 ("spi: bcm2835aux: Restore err
> > > > assignment in bcm2835aux_spi_probe") is picked up with this patch in all
> > > > of the stable trees that it is applied to.
> > >
> > > That shouldn't be necessary as I've made sure that the backports to
> > > 4.19 and earlier do not exhibit the issue fixed by d853b3406903.
> > >
> > > However, nobody is perfect, so if I've missed anything, please let
> > > me know.
> >
> > Could we instead have the backports exhibit the issue (like they did
> > upstream) and then take d853b3406903 on top?
>
> The upstream commit e13ee6cc4781 did not apply cleanly to 4.19 and earlier,
> several adjustments were required. Could I have made it so that the fixup
> d853b3406903 would have still been required? Probably, but it seems a
> little silly to submit a known-bad patch.
>
> Thanks,
>
> Lukas
I did not really look at the actual patches themselves, just the fact
that I saw the commit title without my patch as a follow up in the
series. If your backport avoids the issue entirely, that is fine by me.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH 4.19-stable 4/5] spi: bcm2835aux: Fix use-after-free on unbind
@ 2020-12-08 0:49 99% ` Nathan Chancellor
0 siblings, 1 reply; 200+ results
From: Nathan Chancellor @ 2020-12-08 0:49 UTC (permalink / raw)
To: Lukas Wunner; +Cc: Greg Kroah-Hartman, Mark Brown, Sudip Mukherjee, stable
On Sun, Dec 06, 2020 at 01:31:03PM +0100, Lukas Wunner wrote:
> [ Upstream commit e13ee6cc4781edaf8c7321bee19217e3702ed481 ]
>
> bcm2835aux_spi_remove() accesses the driver's private data after calling
> spi_unregister_master() even though that function releases the last
> reference on the spi_master and thereby frees the private data.
>
> Fix by switching over to the new devm_spi_alloc_master() helper which
> keeps the private data accessible until the driver has unbound.
>
> Fixes: b9dd3f6d4172 ("spi: bcm2835aux: Fix controller unregister order")
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> Cc: <stable@vger.kernel.org> # v4.4+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation
> Cc: <stable@vger.kernel.org> # v4.4+: b9dd3f6d4172: spi: bcm2835aux: Fix controller unregister order
> Cc: <stable@vger.kernel.org> # v4.4+
> Link: https://lore.kernel.org/r/b290b06357d0c0bdee9cecc539b840a90630f101.1605121038.git.lukas@wunner.de
> Signed-off-by: Mark Brown <broonie@kernel.org>
Please ensure that commit d853b3406903 ("spi: bcm2835aux: Restore err
assignment in bcm2835aux_spi_probe") is picked up with this patch in all
of the stable trees that it is applied to.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH v8 00/16] Add support for Clang LTO
@ 2020-12-08 0:46 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-08 0:46 UTC (permalink / raw)
To: Sami Tolvanen
Cc: linux-arch, Kees Cook, Paul E. McKenney, Kernel Hardening,
Peter Zijlstra, Greg Kroah-Hartman, Masahiro Yamada,
linux-kbuild, Nick Desaulniers, LKML, Steven Rostedt, Jian Cai,
clang-built-linux, PCI, Josh Poimboeuf, Kristof Beyls,
Will Deacon, linux-arm-kernel
On Sun, Dec 06, 2020 at 12:09:31PM -0800, Sami Tolvanen wrote:
> Sure, looks good to me. However, I think we should also test for
> LLVM=1 to avoid possible further issues with mismatched toolchains
> instead of only checking for llvm-nm and llvm-ar.
It might still be worth testing for $(AR) and $(NM) because in theory, a
user could say 'make AR=ar LLVM=1'. Highly unlikely I suppose but worth
considering.
Cheers,
Nathan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [relevance 99%]
* Re: [PATCH v8 00/16] Add support for Clang LTO
@ 2020-12-08 0:46 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-08 0:46 UTC (permalink / raw)
To: Sami Tolvanen
Cc: Nick Desaulniers, Will Deacon, Masahiro Yamada, Steven Rostedt,
Josh Poimboeuf, Peter Zijlstra, Greg Kroah-Hartman,
Paul E. McKenney, Kees Cook, clang-built-linux, Kernel Hardening,
linux-arch, linux-arm-kernel, linux-kbuild, LKML, PCI, Jian Cai,
Kristof Beyls
On Sun, Dec 06, 2020 at 12:09:31PM -0800, Sami Tolvanen wrote:
> Sure, looks good to me. However, I think we should also test for
> LLVM=1 to avoid possible further issues with mismatched toolchains
> instead of only checking for llvm-nm and llvm-ar.
It might still be worth testing for $(AR) and $(NM) because in theory, a
user could say 'make AR=ar LLVM=1'. Highly unlikely I suppose but worth
considering.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH v8 00/16] Add support for Clang LTO
@ 2020-12-06 6:50 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-06 6:50 UTC (permalink / raw)
To: Sami Tolvanen
Cc: linux-arch, Kees Cook, Paul E. McKenney, Kernel Hardening,
Peter Zijlstra, Greg Kroah-Hartman, Masahiro Yamada,
linux-kbuild, Nick Desaulniers, LKML, Steven Rostedt, Jian Cai,
clang-built-linux, PCI, Josh Poimboeuf, Kristof Beyls,
Will Deacon, linux-arm-kernel
On Fri, Dec 04, 2020 at 02:52:41PM -0800, Sami Tolvanen wrote:
> On Thu, Dec 3, 2020 at 2:32 PM Nick Desaulniers <ndesaulniers@google.com> wrote:
> >
> > So I'd recommend to Sami to simply make the Kconfig also depend on
> > clang's integrated assembler (not just llvm-nm and llvm-ar).
>
> Sure, sounds good to me. What's the preferred way to test for this in Kconfig?
>
> It looks like actually trying to test if we have an LLVM assembler
> (e.g. using $(as-instr,.section
> ".linker-options","e",@llvm_linker_options)) doesn't work as Kconfig
> doesn't pass -no-integrated-as to clang here. I could do something
> simple like $(success,echo $(LLVM) $(LLVM_IAS) | grep -q "1 1").
>
> Thoughts?
>
> Sami
I think
depends on $(success,test $(LLVM_IAS) -eq 1)
should work, at least according to my brief test.
Cheers,
Nathan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [relevance 99%]
* Re: [PATCH v8 00/16] Add support for Clang LTO
@ 2020-12-06 6:50 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-06 6:50 UTC (permalink / raw)
To: Sami Tolvanen
Cc: Nick Desaulniers, Will Deacon, Masahiro Yamada, Steven Rostedt,
Josh Poimboeuf, Peter Zijlstra, Greg Kroah-Hartman,
Paul E. McKenney, Kees Cook, clang-built-linux, Kernel Hardening,
linux-arch, linux-arm-kernel, linux-kbuild, LKML, PCI, Jian Cai,
Kristof Beyls
On Fri, Dec 04, 2020 at 02:52:41PM -0800, Sami Tolvanen wrote:
> On Thu, Dec 3, 2020 at 2:32 PM Nick Desaulniers <ndesaulniers@google.com> wrote:
> >
> > So I'd recommend to Sami to simply make the Kconfig also depend on
> > clang's integrated assembler (not just llvm-nm and llvm-ar).
>
> Sure, sounds good to me. What's the preferred way to test for this in Kconfig?
>
> It looks like actually trying to test if we have an LLVM assembler
> (e.g. using $(as-instr,.section
> ".linker-options","e",@llvm_linker_options)) doesn't work as Kconfig
> doesn't pass -no-integrated-as to clang here. I could do something
> simple like $(success,echo $(LLVM) $(LLVM_IAS) | grep -q "1 1").
>
> Thoughts?
>
> Sami
I think
depends on $(success,test $(LLVM_IAS) -eq 1)
should work, at least according to my brief test.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH v8 00/16] Add support for Clang LTO
@ 2020-12-03 18:21 96% ` Nathan Chancellor
1 sibling, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-03 18:21 UTC (permalink / raw)
To: Sami Tolvanen
Cc: linux-arch, Kees Cook, Paul E. McKenney, Kernel Hardening,
Peter Zijlstra, Greg Kroah-Hartman, Masahiro Yamada,
linux-kbuild, Nick Desaulniers, LKML, Steven Rostedt,
clang-built-linux, PCI, Josh Poimboeuf, Will Deacon,
linux-arm-kernel
On Thu, Dec 03, 2020 at 09:07:30AM -0800, Sami Tolvanen wrote:
> On Thu, Dec 3, 2020 at 3:26 AM Will Deacon <will@kernel.org> wrote:
> >
> > Hi Sami,
> >
> > On Tue, Dec 01, 2020 at 01:36:51PM -0800, Sami Tolvanen wrote:
> > > This patch series adds support for building the kernel with Clang's
> > > Link Time Optimization (LTO). In addition to performance, the primary
> > > motivation for LTO is to allow Clang's Control-Flow Integrity (CFI)
> > > to be used in the kernel. Google has shipped millions of Pixel
> > > devices running three major kernel versions with LTO+CFI since 2018.
> > >
> > > Most of the patches are build system changes for handling LLVM
> > > bitcode, which Clang produces with LTO instead of ELF object files,
> > > postponing ELF processing until a later stage, and ensuring initcall
> > > ordering.
> > >
> > > Note that arm64 support depends on Will's memory ordering patches
> > > [1]. I will post x86_64 patches separately after we have fixed the
> > > remaining objtool warnings [2][3].
> >
> > I took this series for a spin, with my for-next/lto branch merged in but
> > I see a failure during the LTO stage with clang 11.0.5 because it doesn't
> > understand the '.arch_extension rcpc' directive we throw out in READ_ONCE().
>
> I just tested this with Clang 11.0.0, which I believe is the latest
> 11.x version, and the current Clang 12 development branch, and both
> work for me. Godbolt confirms that '.arch_extension rcpc' is supported
> by the integrated assembler starting with Clang 11 (the example fails
> with 10.0.1):
>
> https://godbolt.org/z/1csGcT
>
> What does running clang --version and ld.lld --version tell you?
11.0.5 is AOSP's clang, which is behind the upstream 11.0.0 release so
it is most likely the case that it is missing the patch that added rcpc.
I think that a version based on the development branch (12.0.0) is in
the works but I am not sure.
> > We actually check that this extension is available before using it in
> > the arm64 Kconfig:
> >
> > config AS_HAS_LDAPR
> > def_bool $(as-instr,.arch_extension rcpc)
> >
> > so this shouldn't happen. I then realised, I wasn't passing LLVM_IAS=1
> > on my Make command line; with that, then the detection works correctly
> > and the LTO step succeeds.
> >
> > Why is it necessary to pass LLVM_IAS=1 if LTO is enabled? I think it
> > would be _much_ better if this was implicit (or if LTO depended on it).
>
> Without LLVM_IAS=1, Clang uses two different assemblers when LTO is
> enabled: the external GNU assembler for stand-alone assembly, and
> LLVM's integrated assembler for inline assembly. as-instr tests the
> external assembler and makes an admittedly reasonable assumption that
> the test is also valid for inline assembly.
>
> I agree that it would reduce confusion in future if we just always
> enabled IAS with LTO. Nick, Nathan, any thoughts about this?
I am personally fine with that. As far as I am aware, we are in a fairly
good spot on arm64 and x86_64 when it comes to the integrated assembler.
Should we make it so that the user has to pass LLVM_IAS=1 explicitly or
we just make adding the no integrated assembler flag to CLANG_FLAGS
depend on not LTO (although that will require extra handling because
Kconfig is not available at that stage I think)?
Cheers,
Nathan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [relevance 96%]
* Re: [PATCH v8 00/16] Add support for Clang LTO
@ 2020-12-03 18:21 96% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-03 18:21 UTC (permalink / raw)
To: Sami Tolvanen
Cc: Will Deacon, Nick Desaulniers, Masahiro Yamada, Steven Rostedt,
Josh Poimboeuf, Peter Zijlstra, Greg Kroah-Hartman,
Paul E. McKenney, Kees Cook, clang-built-linux, Kernel Hardening,
linux-arch, linux-arm-kernel, linux-kbuild, LKML, PCI
On Thu, Dec 03, 2020 at 09:07:30AM -0800, Sami Tolvanen wrote:
> On Thu, Dec 3, 2020 at 3:26 AM Will Deacon <will@kernel.org> wrote:
> >
> > Hi Sami,
> >
> > On Tue, Dec 01, 2020 at 01:36:51PM -0800, Sami Tolvanen wrote:
> > > This patch series adds support for building the kernel with Clang's
> > > Link Time Optimization (LTO). In addition to performance, the primary
> > > motivation for LTO is to allow Clang's Control-Flow Integrity (CFI)
> > > to be used in the kernel. Google has shipped millions of Pixel
> > > devices running three major kernel versions with LTO+CFI since 2018.
> > >
> > > Most of the patches are build system changes for handling LLVM
> > > bitcode, which Clang produces with LTO instead of ELF object files,
> > > postponing ELF processing until a later stage, and ensuring initcall
> > > ordering.
> > >
> > > Note that arm64 support depends on Will's memory ordering patches
> > > [1]. I will post x86_64 patches separately after we have fixed the
> > > remaining objtool warnings [2][3].
> >
> > I took this series for a spin, with my for-next/lto branch merged in but
> > I see a failure during the LTO stage with clang 11.0.5 because it doesn't
> > understand the '.arch_extension rcpc' directive we throw out in READ_ONCE().
>
> I just tested this with Clang 11.0.0, which I believe is the latest
> 11.x version, and the current Clang 12 development branch, and both
> work for me. Godbolt confirms that '.arch_extension rcpc' is supported
> by the integrated assembler starting with Clang 11 (the example fails
> with 10.0.1):
>
> https://godbolt.org/z/1csGcT
>
> What does running clang --version and ld.lld --version tell you?
11.0.5 is AOSP's clang, which is behind the upstream 11.0.0 release so
it is most likely the case that it is missing the patch that added rcpc.
I think that a version based on the development branch (12.0.0) is in
the works but I am not sure.
> > We actually check that this extension is available before using it in
> > the arm64 Kconfig:
> >
> > config AS_HAS_LDAPR
> > def_bool $(as-instr,.arch_extension rcpc)
> >
> > so this shouldn't happen. I then realised, I wasn't passing LLVM_IAS=1
> > on my Make command line; with that, then the detection works correctly
> > and the LTO step succeeds.
> >
> > Why is it necessary to pass LLVM_IAS=1 if LTO is enabled? I think it
> > would be _much_ better if this was implicit (or if LTO depended on it).
>
> Without LLVM_IAS=1, Clang uses two different assemblers when LTO is
> enabled: the external GNU assembler for stand-alone assembly, and
> LLVM's integrated assembler for inline assembly. as-instr tests the
> external assembler and makes an admittedly reasonable assumption that
> the test is also valid for inline assembly.
>
> I agree that it would reduce confusion in future if we just always
> enabled IAS with LTO. Nick, Nathan, any thoughts about this?
I am personally fine with that. As far as I am aware, we are in a fairly
good spot on arm64 and x86_64 when it comes to the integrated assembler.
Should we make it so that the user has to pass LLVM_IAS=1 explicitly or
we just make adding the no integrated assembler flag to CLANG_FLAGS
depend on not LTO (although that will require extra handling because
Kconfig is not available at that stage I think)?
Cheers,
Nathan
^ permalink raw reply [relevance 96%]
* Re: [PATCH] x86, build: remove -m16 workaround for unsupported versions of GCC
@ 2020-12-01 3:51 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-12-01 3:51 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, David Woodhouse,
x86, H. Peter Anvin, linux-kernel, clang-built-linux
On Mon, Nov 30, 2020 at 05:13:06PM -0800, 'Nick Desaulniers' via Clang Built Linux wrote:
> A revert of the following two commits.
> commit de3accdaec88 ("x86, build: Build 16-bit code with -m16 where
> possible")
> commit a9cfccee6604 ("x86, build: Change code16gcc.h from a C header to
> an assembly header")
>
> Since commit 0bddd227f3dc ("Documentation: update for gcc 4.9
> requirement") the minimum supported version of GCC is gcc-4.9. It's now
> safe to remove this code.
>
> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> arch/x86/Makefile | 9 +--------
> arch/x86/boot/code16gcc.h | 12 ------------
> 2 files changed, 1 insertion(+), 20 deletions(-)
> delete mode 100644 arch/x86/boot/code16gcc.h
>
> diff --git a/arch/x86/Makefile b/arch/x86/Makefile
> index 1bf21746f4ce..7116da3980be 100644
> --- a/arch/x86/Makefile
> +++ b/arch/x86/Makefile
> @@ -24,14 +24,7 @@ endif
>
> # How to compile the 16-bit code. Note we always compile for -march=i386;
> # that way we can complain to the user if the CPU is insufficient.
> -#
> -# The -m16 option is supported by GCC >= 4.9 and clang >= 3.5. For
> -# older versions of GCC, include an *assembly* header to make sure that
> -# gcc doesn't play any games behind our back.
> -CODE16GCC_CFLAGS := -m32 -Wa,$(srctree)/arch/x86/boot/code16gcc.h
> -M16_CFLAGS := $(call cc-option, -m16, $(CODE16GCC_CFLAGS))
> -
> -REALMODE_CFLAGS := $(M16_CFLAGS) -g -Os -DDISABLE_BRANCH_PROFILING \
> +REALMODE_CFLAGS := -m16 -g -Os -DDISABLE_BRANCH_PROFILING \
> -Wall -Wstrict-prototypes -march=i386 -mregparm=3 \
> -fno-strict-aliasing -fomit-frame-pointer -fno-pic \
> -mno-mmx -mno-sse
> diff --git a/arch/x86/boot/code16gcc.h b/arch/x86/boot/code16gcc.h
> deleted file mode 100644
> index e19fd7536307..000000000000
> --- a/arch/x86/boot/code16gcc.h
> +++ /dev/null
> @@ -1,12 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0 */
> -#
> -# code16gcc.h
> -#
> -# This file is added to the assembler via -Wa when compiling 16-bit C code.
> -# This is done this way instead via asm() to make sure gcc does not reorder
> -# things around us.
> -#
> -# gcc 4.9+ has a real -m16 option so we can drop this hack long term.
> -#
> -
> - .code16gcc
> --
> 2.29.2.454.gaff20da3a2-goog
>
^ permalink raw reply [relevance 99%]
* Apply d853b3406903a7dc5b14eb5bada3e8cd677f66a2 to 5.4 and 5.9
@ 2020-11-30 1:40 99% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-30 1:40 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sasha Levin
Cc: stable, Mark Brown, Lukas Wunner, linux-spi
Hi Greg and Sasha,
Please apply commit d853b3406903 ("spi: bcm2835aux: Restore err
assignment in bcm2835aux_spi_probe") to linux-5.4.y and linux-5.9.y as a
fix for commit e13ee6cc4781 ("spi: bcm2835aux: Fix use-after-free on
unbind"). I did not realize that commit was tagged for stable so I did
not tag my fix accordingly, sorry for not noticing sooner.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH 17/19] mtd: rawnand: r852: Move the ECC initialization to ->attach_chip()
@ 2020-11-30 1:07 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-30 1:07 UTC (permalink / raw)
To: Miquel Raynal
Cc: Maxim Levitsky, Richard Weinberger, linux-mtd,
Vignesh Raghavendra, Tudor Ambarus
On Fri, Nov 13, 2020 at 01:34:22PM +0100, Miquel Raynal wrote:
> The probe function is only supposed to initialize the controller
> hardware but not the ECC engine. Indeed, we don't know anything about
> the NAND chip(s) at this stage. Let's move the logic initializing the
> ECC engine, even pretty simple, to the ->attach_chip() hook which gets
> called during nand_scan() routine, after the NAND chip discovery. As
> the previously mentioned logic is supposed to parse the DT for us, it
> is likely that the chip->ecc.* entries be overwritten. So let's avoid
> this by moving these lines to ->attach_chip().
>
> Fixes: d7157ff49a5b ("mtd: rawnand: Use the ECC framework user input parsing bits")
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Cc: Maxim Levitsky <maximlevitsky@gmail.com>
Just as a heads up, this patch was applied to mtd/fixes as
commit 7ef969a04228 ("mtd: rawnand: r852: Move the ECC
initialization to ->attach_chip()") but it appears to also be applied to
nand/next as commit 0c2b69f55132 ("mtd: rawnand: r852: Move the ECC
initialization to ->attach_chip()"), where due to its mismerged nature,
it causes a clang warning:
../drivers/mtd/nand/raw/r852.c:874:24: warning: variable 'dev' is uninitialized when used here [-Wuninitialized]
nand_controller_init(&dev->controller);
^~~
../drivers/mtd/nand/raw/r852.c:847:25: note: initialize the variable 'dev' to silence this warning
struct r852_device *dev;
^
= NULL
1 warning generated.
Cheers,
Nathan Chancellor
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [relevance 99%]
* Re: [PATCH v3] Compiler Attributes: remove CONFIG_ENABLE_MUST_CHECK
@ 2020-11-30 1:04 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-30 1:04 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Miguel Ojeda, Jason A . Donenfeld, Nick Desaulniers, Shuah Khan,
clang-built-linux, linux-kernel, linux-kselftest, netdev,
wireguard
On Sun, Nov 29, 2020 at 04:33:35AM +0900, Masahiro Yamada wrote:
> Revert commit cebc04ba9aeb ("add CONFIG_ENABLE_MUST_CHECK").
>
> A lot of warn_unused_result warnings existed in 2006, but until now
> they have been fixed thanks to people doing allmodconfig tests.
>
> Our goal is to always enable __must_check where appropriate, so this
> CONFIG option is no longer needed.
>
> I see a lot of defconfig (arch/*/configs/*_defconfig) files having:
>
> # CONFIG_ENABLE_MUST_CHECK is not set
>
> I did not touch them for now since it would be a big churn. If arch
> maintainers want to clean them up, please go ahead.
>
> While I was here, I also moved __must_check to compiler_attributes.h
> from compiler_types.h
>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> Acked-by: Jason A. Donenfeld <Jason@zx2c4.com>
Acked-by: Nathan Chancellor <natechancellor@gmail.com>
^ permalink raw reply [relevance 99%]
* Re: [stable 4.9] PANIC: double fault, error_code: 0x0 - clang boot failed on x86_64
@ 2020-11-28 5:41 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-28 5:41 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Naresh Kamboju, linux-stable, open list, lkft-triage,
Sasha Levin, clang-built-linux, x86
On Thu, Nov 26, 2020 at 07:39:33AM +0100, Greg Kroah-Hartman wrote:
> On Thu, Nov 26, 2020 at 10:14:43AM +0530, Naresh Kamboju wrote:
> > Linaro recently started building and testing with stable branches with clang.
> > Stable 4.9 branch kernel built with clang 10 boot crashed on x86 and qemu_x86.
> > We do not have base line results to compare with.
> >
> > steps to build and boot:
> > # build kernel with tuxmake
> > # sudo pip3 install -U tuxmake
> > # tuxmake --runtime docker --target-arch x86 --toolchain clang-10
> > --kconfig defconfig --kconfig-add
> > https://builds.tuxbuild.com/1kgtX7QEDmhvj6OfbZBdlGaEple/config
> > # boot qemu_x86_64
> > # /usr/bin/qemu-system-x86_64 -cpu host -enable-kvm -nographic -net
> > nic,model=virtio,macaddr=DE:AD:BE:EF:66:14 -net tap -m 1024 -monitor
> > none -kernel kernel/bzImage --append "root=/dev/sda rootwait
> > console=ttyS0,115200" -hda
> > rootfs/rpb-console-image-lkft-intel-corei7-64-20201022181159-3085.rootfs.ext4
> > -m 4096 -smp 4 -nographic
> >
> > Crash log:
> > ---------------
> > [ 14.121499] Freeing unused kernel memory: 1896K
> > [ 14.126962] random: fast init done
> > [ 14.206005] PANIC: double fault, error_code: 0x0
> > [ 14.210633] CPU: 1 PID: 1 Comm: systemd Not tainted 4.9.246-rc1 #2
> > [ 14.216809] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
> > 2.2 05/23/2018
> > [ 14.224196] task: ffff88026e2c0000 task.stack: ffffc90000020000
> > [ 14.230105] RIP: 0010:[<ffffffff8117ec2b>] [<ffffffff8117ec2b>]
> > proc_dostring+0x13b/0x1e0
> > [ 14.238374] RSP: 0018:000000000000000c EFLAGS: 00010297
> > [ 14.243676] RAX: 00005638939fb850 RBX: 000000000000000c RCX: 00005638939fb850
> > [ 14.250799] RDX: 000000000000000c RSI: 0000000000000000 RDI: 000000000000007f
> > [ 14.257925] RBP: ffffc90000023d98 R08: ffffc90000023ef8 R09: 00005638939fb850
> > [ 14.265049] R10: 0000000000000000 R11: ffffffff8117f9e0 R12: ffffffff82479cf0
> > [ 14.272171] R13: ffffc90000023ef8 R14: ffffc90000023dd8 R15: 000000000000007f
> > [ 14.279298] FS: 00007f57fbce8840(0000) GS:ffff880277880000(0000)
> > knlGS:0000000000000000
> > [ 14.287384] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 14.293120] CR2: fffffffffffffff8 CR3: 000000026d58a000 CR4: 0000000000360670
> > [ 14.300243] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > [ 14.307368] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > [ 14.314491] Stack:
> > [ 14.316504] Call Trace:
> > [ 14.318955] Code: c3 49 8b 10 31 f6 48 01 da 49 89 10 49 83 3e 00
> > 74 49 41 83 c7 ff 49 63 ff 4c 89 c9 0f 1f 40 00 48 39 fe 73 36 48 89
> > c8 48 89 dc <e8> b0 9d 3a 00 85 c0 0f 85 8c 00 00 00 84 d2 74 1f 80 fa
> > 0a 74
> > [ 14.338906] Kernel panic - not syncing: Machine halted.
> > [ 14.344123] CPU: 1 PID: 1 Comm: systemd Not tainted 4.9.246-rc1 #2
> > [ 14.350291] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
> > 2.2 05/23/2018
> > [ 14.357677] ffff880277888e80 ffffffff81518ae9 ffff880277888e98
> > ffffffff82971a10
> > [ 14.365129] 000000000000000f 0000000000000000 0000000000000086
> > ffffffff820c5d57
> > [ 14.372584] ffff880277888f08 ffffffff81175736 0000003000000008
> > ffff880277888f18
> > [ 14.380038] Call Trace:
> > [ 14.382481] <#DF> [ 14.384406] [<ffffffff81518ae9>] dump_stack+0xa9/0x100
> > [ 14.389641] [<ffffffff81175736>] panic+0xe6/0x2a0
> > [ 14.394432] [<ffffffff810c9911>] df_debug+0x31/0x40
> > [ 14.399389] [<ffffffff81096312>] do_double_fault+0x102/0x140
> > [ 14.405128] [<ffffffff81ccc987>] double_fault+0x27/0x30
> > [ 14.410440] [<ffffffff8117f9e0>] ? proc_put_long+0xc0/0xc0
> > [ 14.416004] [<ffffffff8117ec2b>] ? proc_dostring+0x13b/0x1e0
> > [ 14.421739] <EOE> [ 14.423703] Kernel Offset: disabled
> > [ 14.427209] ---[ end Kernel panic - not syncing: Machine halted.
> >
> > Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> >
> > full test log,
> > https://lkft.validation.linaro.org/scheduler/job/1978901#L916
> > https://lkft.validation.linaro.org/scheduler/job/1980839#L578
>
> Is the mainline 4.9 tree supposed to work with clang? I didn't think
> that upstream effort started until 4.19 or so.
>
> thanks,
>
> greg k-h
>
We have been building and boot testing the mainline 4.9 tree for quite
some time. This issue appears to be exposed by the rootfs that Linaro is
using for testing; ours is incredibly simple (prints the version string
then shuts down, there is no systemd or complex init).
Some initial notes, I am not sure how much time I will have to look at
this in the near future:
1. This does not happen with the same configuration file on
linux-4.14.y.
2. This happens with the latest version of clang on linux-4.9.y.
3. Bisecting v4.9 to v4.14 will be rather difficult because clang
support was backported to 4.9 somewhere in the 130s.
There could be a clang backport missing or a bug was unintentionally
fixed somewhere else.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [RESEND,PATCH] ARM: fix __div64_32() error when compiling with clang
@ 2020-11-23 18:16 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-23 18:16 UTC (permalink / raw)
To: Antony Yu
Cc: clang-built-linux, Nick Desaulniers, Russell King,
linux-arm-kernel, linux-kernel
On Mon, Nov 23, 2020 at 03:36:32PM +0800, Antony Yu wrote:
> __do_div64 clobbers the input register r0 in little endian system.
> According to the inline assembly document, if an input operand is
> modified, it should be tied to a output operand. This patch can
> prevent compilers from reusing r0 register after asm statements.
>
> Signed-off-by: Antony Yu <swpenim@gmail.com>
> ---
> arch/arm/include/asm/div64.h | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/div64.h b/arch/arm/include/asm/div64.h
> index 898e9c78a7e7..809efc51e90f 100644
> --- a/arch/arm/include/asm/div64.h
> +++ b/arch/arm/include/asm/div64.h
> @@ -39,9 +39,10 @@ static inline uint32_t __div64_32(uint64_t *n, uint32_t base)
> asm( __asmeq("%0", __xh)
> __asmeq("%1", "r2")
> __asmeq("%2", "r0")
> - __asmeq("%3", "r4")
> + __asmeq("%3", "r0")
> + __asmeq("%4", "r4")
> "bl __do_div64"
> - : "=r" (__rem), "=r" (__res)
> + : "=r" (__rem), "=r" (__res), "=r" (__n)
> : "r" (__n), "r" (__base)
> : "ip", "lr", "cc");
> *n = __res;
> --
> 2.23.0
>
I am not sure that I am qualified to review this (my assembly knowledge
is not the best) but your commit title mentions an error when compiling
with clang. What is the exact error, what configuration generates it,
and what version of clang? We have done fairly decent testing for
32-bit ARM, I would like to know what we are missing.
Cheers,
Nathan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [relevance 99%]
* Re: [RESEND,PATCH] ARM: fix __div64_32() error when compiling with clang
@ 2020-11-23 18:16 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-23 18:16 UTC (permalink / raw)
To: Antony Yu
Cc: Russell King, Nick Desaulniers, linux-arm-kernel, linux-kernel,
clang-built-linux
On Mon, Nov 23, 2020 at 03:36:32PM +0800, Antony Yu wrote:
> __do_div64 clobbers the input register r0 in little endian system.
> According to the inline assembly document, if an input operand is
> modified, it should be tied to a output operand. This patch can
> prevent compilers from reusing r0 register after asm statements.
>
> Signed-off-by: Antony Yu <swpenim@gmail.com>
> ---
> arch/arm/include/asm/div64.h | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/div64.h b/arch/arm/include/asm/div64.h
> index 898e9c78a7e7..809efc51e90f 100644
> --- a/arch/arm/include/asm/div64.h
> +++ b/arch/arm/include/asm/div64.h
> @@ -39,9 +39,10 @@ static inline uint32_t __div64_32(uint64_t *n, uint32_t base)
> asm( __asmeq("%0", __xh)
> __asmeq("%1", "r2")
> __asmeq("%2", "r0")
> - __asmeq("%3", "r4")
> + __asmeq("%3", "r0")
> + __asmeq("%4", "r4")
> "bl __do_div64"
> - : "=r" (__rem), "=r" (__res)
> + : "=r" (__rem), "=r" (__res), "=r" (__n)
> : "r" (__n), "r" (__base)
> : "ip", "lr", "cc");
> *n = __res;
> --
> 2.23.0
>
I am not sure that I am qualified to review this (my assembly knowledge
is not the best) but your commit title mentions an error when compiling
with clang. What is the exact error, what configuration generates it,
and what version of clang? We have done fairly decent testing for
32-bit ARM, I would like to know what we are missing.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH v7 00/17] Add support for Clang LTO
@ 2020-11-21 3:14 98% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-21 3:14 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-arch, Kees Cook, Paul E. McKenney, Kernel Hardening,
Peter Zijlstra, Greg Kroah-Hartman, Masahiro Yamada,
Linux Kbuild mailing list, Nick Desaulniers, LKML,
Steven Rostedt, clang-built-linux, PCI, Sami Tolvanen,
Josh Poimboeuf, Will Deacon, Linux ARM
On Fri, Nov 20, 2020 at 11:29:51AM +0100, Ard Biesheuvel wrote:
> On Thu, 19 Nov 2020 at 00:42, Nick Desaulniers <ndesaulniers@google.com> wrote:
> >
> > On Wed, Nov 18, 2020 at 2:07 PM Sami Tolvanen <samitolvanen@google.com> wrote:
> > >
> > > This patch series adds support for building the kernel with Clang's
> > > Link Time Optimization (LTO). In addition to performance, the primary
> > > motivation for LTO is to allow Clang's Control-Flow Integrity (CFI) to
> > > be used in the kernel. Google has shipped millions of Pixel devices
> > > running three major kernel versions with LTO+CFI since 2018.
> > >
> > > Most of the patches are build system changes for handling LLVM bitcode,
> > > which Clang produces with LTO instead of ELF object files, postponing
> > > ELF processing until a later stage, and ensuring initcall ordering.
> > >
> > > Note that v7 brings back arm64 support as Will has now staged the
> > > prerequisite memory ordering patches [1], and drops x86_64 while we work
> > > on fixing the remaining objtool warnings [2].
> > >
> > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/lto
> > > [2] https://lore.kernel.org/lkml/20201114004911.aip52eimk6c2uxd4@treble/
> > >
> > > You can also pull this series from
> > >
> > > https://github.com/samitolvanen/linux.git lto-v7
> >
> > Thanks for continuing to drive this series Sami. For the series,
> >
> > Tested-by: Nick Desaulniers <ndesaulniers@google.com>
> >
> > I did virtualized boot tests with the series applied to aarch64
> > defconfig without CONFIG_LTO, with CONFIG_LTO_CLANG, and a third time
> > with CONFIG_THINLTO. If you make changes to the series in follow ups,
> > please drop my tested by tag from the modified patches and I'll help
> > re-test. Some minor feedback on the Kconfig change, but I'll post it
> > off of that patch.
> >
>
> When you say 'virtualized" do you mean QEMU on x86? Or actual
> virtualization on an AArch64 KVM host?
>
> The distinction is important here, given the potential impact of LTO
> on things that QEMU simply does not model when it runs in TCG mode on
> a foreign host architecture.
I have booted this series on my Raspberry Pi 4 (ARCH=arm64 defconfig).
$ uname -r
5.10.0-rc4-00108-g830200082c74
$ zgrep LTO /proc/config.gz
CONFIG_LTO=y
CONFIG_ARCH_SUPPORTS_LTO_CLANG=y
CONFIG_ARCH_SUPPORTS_THINLTO=y
CONFIG_THINLTO=y
# CONFIG_LTO_NONE is not set
CONFIG_LTO_CLANG=y
# CONFIG_HID_WALTOP is not set
and I have taken that same kernel and booted it under QEMU with
'-enable-kvm' without any visible issues.
I have tested four combinations:
clang 12 @ f9f0a4046e11c2b4c130640f343e3b2b5db08c1:
* CONFIG_THINLTO=y
* CONFIG_THINLTO=n
clang 11.0.0
* CONFIG_THINLTO=y
* CONFIG_THINLTO=n
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Cheers,
Nathan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [relevance 98%]
* Re: [PATCH v7 00/17] Add support for Clang LTO
@ 2020-11-21 3:14 98% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-21 3:14 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Nick Desaulniers, Sami Tolvanen, Masahiro Yamada, Steven Rostedt,
Will Deacon, Josh Poimboeuf, Peter Zijlstra, Greg Kroah-Hartman,
Paul E. McKenney, Kees Cook, clang-built-linux, Kernel Hardening,
linux-arch, Linux ARM, Linux Kbuild mailing list, LKML, PCI
On Fri, Nov 20, 2020 at 11:29:51AM +0100, Ard Biesheuvel wrote:
> On Thu, 19 Nov 2020 at 00:42, Nick Desaulniers <ndesaulniers@google.com> wrote:
> >
> > On Wed, Nov 18, 2020 at 2:07 PM Sami Tolvanen <samitolvanen@google.com> wrote:
> > >
> > > This patch series adds support for building the kernel with Clang's
> > > Link Time Optimization (LTO). In addition to performance, the primary
> > > motivation for LTO is to allow Clang's Control-Flow Integrity (CFI) to
> > > be used in the kernel. Google has shipped millions of Pixel devices
> > > running three major kernel versions with LTO+CFI since 2018.
> > >
> > > Most of the patches are build system changes for handling LLVM bitcode,
> > > which Clang produces with LTO instead of ELF object files, postponing
> > > ELF processing until a later stage, and ensuring initcall ordering.
> > >
> > > Note that v7 brings back arm64 support as Will has now staged the
> > > prerequisite memory ordering patches [1], and drops x86_64 while we work
> > > on fixing the remaining objtool warnings [2].
> > >
> > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/lto
> > > [2] https://lore.kernel.org/lkml/20201114004911.aip52eimk6c2uxd4@treble/
> > >
> > > You can also pull this series from
> > >
> > > https://github.com/samitolvanen/linux.git lto-v7
> >
> > Thanks for continuing to drive this series Sami. For the series,
> >
> > Tested-by: Nick Desaulniers <ndesaulniers@google.com>
> >
> > I did virtualized boot tests with the series applied to aarch64
> > defconfig without CONFIG_LTO, with CONFIG_LTO_CLANG, and a third time
> > with CONFIG_THINLTO. If you make changes to the series in follow ups,
> > please drop my tested by tag from the modified patches and I'll help
> > re-test. Some minor feedback on the Kconfig change, but I'll post it
> > off of that patch.
> >
>
> When you say 'virtualized" do you mean QEMU on x86? Or actual
> virtualization on an AArch64 KVM host?
>
> The distinction is important here, given the potential impact of LTO
> on things that QEMU simply does not model when it runs in TCG mode on
> a foreign host architecture.
I have booted this series on my Raspberry Pi 4 (ARCH=arm64 defconfig).
$ uname -r
5.10.0-rc4-00108-g830200082c74
$ zgrep LTO /proc/config.gz
CONFIG_LTO=y
CONFIG_ARCH_SUPPORTS_LTO_CLANG=y
CONFIG_ARCH_SUPPORTS_THINLTO=y
CONFIG_THINLTO=y
# CONFIG_LTO_NONE is not set
CONFIG_LTO_CLANG=y
# CONFIG_HID_WALTOP is not set
and I have taken that same kernel and booted it under QEMU with
'-enable-kvm' without any visible issues.
I have tested four combinations:
clang 12 @ f9f0a4046e11c2b4c130640f343e3b2b5db08c1:
* CONFIG_THINLTO=y
* CONFIG_THINLTO=n
clang 11.0.0
* CONFIG_THINLTO=y
* CONFIG_THINLTO=n
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Cheers,
Nathan
^ permalink raw reply [relevance 98%]
* Re: [PATCH v7 02/17] kbuild: add support for Clang LTO
@ 2020-11-20 20:29 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-20 20:29 UTC (permalink / raw)
To: Kees Cook
Cc: linux-arch, Paul E. McKenney, Kernel Hardening, Peter Zijlstra,
Greg Kroah-Hartman, Masahiro Yamada, Linux Kbuild mailing list,
Nick Desaulniers, LKML, Steven Rostedt, clang-built-linux,
linux-pci, Sami Tolvanen, Josh Poimboeuf, Will Deacon, Linux ARM
On Fri, Nov 20, 2020 at 11:47:21AM -0800, Kees Cook wrote:
> On Fri, Nov 20, 2020 at 08:23:11AM -0800, Sami Tolvanen wrote:
> > Changing the ThinLTO config to a choice and moving it after the main
> > LTO config sounds like a good idea to me. I'll see if I can change
> > this in v8. Thanks!
>
> Originally, I thought this might be a bit ugly once GCC LTO is added,
> but this could be just a choice like we're done for the stack
> initialization. Something like an "LTO" choice of NONE, CLANG_FULL,
> CLANG_THIN, and in the future GCC, etc.
Having two separate choices might be a little bit cleaner though? One
for the compiler (LTO_CLANG versus LTO_GCC) and one for the type
(THINLTO versus FULLLTO). The type one could just have a "depends on
CC_IS_CLANG" to ensure it only showed up when needed.
Cheers,
Nathan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [relevance 99%]
* Re: [PATCH v7 02/17] kbuild: add support for Clang LTO
@ 2020-11-20 20:29 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-20 20:29 UTC (permalink / raw)
To: Kees Cook
Cc: Sami Tolvanen, Nick Desaulniers, Masahiro Yamada, Steven Rostedt,
Will Deacon, Josh Poimboeuf, Peter Zijlstra, Greg Kroah-Hartman,
Paul E. McKenney, clang-built-linux, Kernel Hardening,
linux-arch, Linux ARM, Linux Kbuild mailing list, LKML,
linux-pci
On Fri, Nov 20, 2020 at 11:47:21AM -0800, Kees Cook wrote:
> On Fri, Nov 20, 2020 at 08:23:11AM -0800, Sami Tolvanen wrote:
> > Changing the ThinLTO config to a choice and moving it after the main
> > LTO config sounds like a good idea to me. I'll see if I can change
> > this in v8. Thanks!
>
> Originally, I thought this might be a bit ugly once GCC LTO is added,
> but this could be just a choice like we're done for the stack
> initialization. Something like an "LTO" choice of NONE, CLANG_FULL,
> CLANG_THIN, and in the future GCC, etc.
Having two separate choices might be a little bit cleaner though? One
for the compiler (LTO_CLANG versus LTO_GCC) and one for the type
(THINLTO versus FULLLTO). The type one could just have a "depends on
CC_IS_CLANG" to ensure it only showed up when needed.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH] mhi: pci_generic: Fix implicit conversion warning
@ 2020-11-19 21:20 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-19 21:20 UTC (permalink / raw)
To: Loic Poulain; +Cc: manivannan.sadhasivam, hemantk, linux-arm-msm
On Thu, Nov 19, 2020 at 11:19:31AM +0100, Loic Poulain wrote:
> Fix the following warning with explicit cast:
>
> warning: implicit conversion from 'unsigned long long' to
> 'dma_addr_t' (aka 'unsigned int')
> mhi_cntrl->iova_stop = DMA_BIT_MASK(info->dma_data_width);
>
> Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
> Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> drivers/bus/mhi/pci_generic.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/bus/mhi/pci_generic.c b/drivers/bus/mhi/pci_generic.c
> index 17c6448..3337c6d 100644
> --- a/drivers/bus/mhi/pci_generic.c
> +++ b/drivers/bus/mhi/pci_generic.c
> @@ -411,7 +411,7 @@ static int mhi_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> mhi_cntrl = &mhi_pdev->mhi_cntrl;
> mhi_cntrl->cntrl_dev = &pdev->dev;
> mhi_cntrl->iova_start = 0;
> - mhi_cntrl->iova_stop = DMA_BIT_MASK(info->dma_data_width);
> + mhi_cntrl->iova_stop = (dma_addr_t)DMA_BIT_MASK(info->dma_data_width);
> mhi_cntrl->fw_image = info->fw;
> mhi_cntrl->edl_image = info->edl;
>
> --
> 2.7.4
>
^ permalink raw reply [relevance 99%]
* [PATCH v2 2/2] kbuild: Disable CONFIG_LD_ORPHAN_WARN for ld.lld 10.0.1
@ 2020-11-19 20:46 82% ` Nathan Chancellor
2020-11-19 20:46 82% ` Nathan Chancellor
2 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-19 20:46 UTC (permalink / raw)
To: Masahiro Yamada, Michal Marek, Kees Cook
Cc: linuxppc-dev, kernelci . org bot, linux-kbuild, Catalin Marinas,
Mark Brown, x86, Nick Desaulniers, Russell King, linux-kernel,
clang-built-linux, Arvind Sankar, Ingo Molnar, Borislav Petkov,
Thomas Gleixner, Will Deacon, Nathan Chancellor,
linux-arm-kernel
ld.lld 10.0.1 spews a bunch of various warnings about .rela sections,
along with a few others. Newer versions of ld.lld do not have these
warnings. As a result, do not add '--orphan-handling=warn' to
LDFLAGS_vmlinux if ld.lld's version is not new enough.
Link: https://github.com/ClangBuiltLinux/linux/issues/1187
Link: https://github.com/ClangBuiltLinux/linux/issues/1193
Reported-by: Arvind Sankar <nivedita@alum.mit.edu>
Reported-by: kernelci.org bot <bot@kernelci.org>
Reported-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
v1 -> v2:
* Add condition as a depends on line (Kees Cook)
* Capture output of "$* --version" to avoid invoking linker twice (Nick
Desaulniers)
* Improve documentation of script in comments (Nick Desaulniers)
* Pick up review tag from Kees
MAINTAINERS | 1 +
init/Kconfig | 5 +++++
scripts/lld-version.sh | 20 ++++++++++++++++++++
3 files changed, 26 insertions(+)
create mode 100755 scripts/lld-version.sh
diff --git a/MAINTAINERS b/MAINTAINERS
index e451dcce054f..e6f74f130ae1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4284,6 +4284,7 @@ B: https://github.com/ClangBuiltLinux/linux/issues
C: irc://chat.freenode.net/clangbuiltlinux
F: Documentation/kbuild/llvm.rst
F: scripts/clang-tools/
+F: scripts/lld-version.sh
K: \b(?i:clang|llvm)\b
CLEANCACHE API
diff --git a/init/Kconfig b/init/Kconfig
index 92c58b45abb8..b9037d6c5ab3 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -47,6 +47,10 @@ config CLANG_VERSION
int
default $(shell,$(srctree)/scripts/clang-version.sh $(CC))
+config LLD_VERSION
+ int
+ default $(shell,$(srctree)/scripts/lld-version.sh $(LD))
+
config CC_CAN_LINK
bool
default $(success,$(srctree)/scripts/cc-can-link.sh $(CC) $(CLANG_FLAGS) $(m64-flag)) if 64BIT
@@ -1351,6 +1355,7 @@ config LD_DEAD_CODE_DATA_ELIMINATION
config LD_ORPHAN_WARN
def_bool y
depends on ARCH_WANT_LD_ORPHAN_WARN
+ depends on !LD_IS_LLD || LLD_VERSION >= 110000
depends on $(ld-option,--orphan-handling=warn)
config SYSCTL
diff --git a/scripts/lld-version.sh b/scripts/lld-version.sh
new file mode 100755
index 000000000000..d70edb4d8a4f
--- /dev/null
+++ b/scripts/lld-version.sh
@@ -0,0 +1,20 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+#
+# Usage: $ ./scripts/lld-version.sh ld.lld
+#
+# Print the linker version of `ld.lld' in a 5 or 6-digit form
+# such as `100001' for ld.lld 10.0.1 etc.
+
+linker_string="$($* --version)"
+
+if ! ( echo $linker_string | grep -q LLD ); then
+ echo 0
+ exit 1
+fi
+
+VERSION=$(echo $linker_string | cut -d ' ' -f 2)
+MAJOR=$(echo $VERSION | cut -d . -f 1)
+MINOR=$(echo $VERSION | cut -d . -f 2)
+PATCHLEVEL=$(echo $VERSION | cut -d . -f 3)
+printf "%d%02d%02d\\n" $MAJOR $MINOR $PATCHLEVEL
--
2.29.2
^ permalink raw reply related [relevance 84%]
* [PATCH v2 1/2] kbuild: Hoist '--orphan-handling' into Kconfig
@ 2020-11-19 20:46 62% ` Nathan Chancellor
2020-11-19 20:46 82% ` Nathan Chancellor
2 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-19 20:46 UTC (permalink / raw)
To: Masahiro Yamada, Michal Marek, Kees Cook
Cc: linuxppc-dev, linux-kbuild, Catalin Marinas, x86,
Nick Desaulniers, Russell King, linux-kernel, clang-built-linux,
Arvind Sankar, Ingo Molnar, Borislav Petkov, Thomas Gleixner,
Will Deacon, Nathan Chancellor, linux-arm-kernel
Currently, '--orphan-handling=warn' is spread out across four different
architectures in their respective Makefiles, which makes it a little
unruly to deal with in case it needs to be disabled for a specific
linker version (in this case, ld.lld 10.0.1).
To make it easier to control this, hoist this warning into Kconfig and
the main Makefile so that disabling it is simpler, as the warning will
only be enabled in a couple places (main Makefile and a couple of
compressed boot folders that blow away LDFLAGS_vmlinx) and making it
conditional is easier due to Kconfig syntax. One small additional
benefit of this is saving a call to ld-option on incremental builds
because we will have already evaluated it for CONFIG_LD_ORPHAN_WARN.
To keep the list of supported architectures the same, introduce
CONFIG_ARCH_WANT_LD_ORPHAN_WARN, which an architecture can select to
gain this automatically after all of the sections are specified and size
asserted. A special thanks to Kees Cook for the help text on this
config.
Link: https://github.com/ClangBuiltLinux/linux/issues/1187
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
v1 -> v2:
* Change
ifeq ($(CONFIG_LD_ORPHAN_WARN),y)
to
ifdef CONFIG_LD_ORPHAN_WARN
to improve readability (Michael Ellerman)
* Separate conditions for CONFIG_LD_ORPHAN warn to improve
readability (Kees Cook)
* Pick up tags from Kees, Michael, and Nick
Makefile | 6 ++++++
arch/Kconfig | 9 +++++++++
arch/arm/Kconfig | 1 +
arch/arm/Makefile | 4 ----
arch/arm/boot/compressed/Makefile | 4 +++-
arch/arm64/Kconfig | 1 +
arch/arm64/Makefile | 4 ----
arch/powerpc/Kconfig | 1 +
arch/powerpc/Makefile | 1 -
arch/x86/Kconfig | 1 +
arch/x86/Makefile | 3 ---
arch/x86/boot/compressed/Makefile | 4 +++-
init/Kconfig | 5 +++++
13 files changed, 30 insertions(+), 14 deletions(-)
diff --git a/Makefile b/Makefile
index e2c3f65c4721..2c7116299f1f 100644
--- a/Makefile
+++ b/Makefile
@@ -984,6 +984,12 @@ ifeq ($(CONFIG_RELR),y)
LDFLAGS_vmlinux += --pack-dyn-relocs=relr
endif
+# We never want expected sections to be placed heuristically by the
+# linker. All sections should be explicitly named in the linker script.
+ifdef CONFIG_LD_ORPHAN_WARN
+LDFLAGS_vmlinux += --orphan-handling=warn
+endif
+
# Align the bit size of userspace programs with the kernel
KBUILD_USERCFLAGS += $(filter -m32 -m64 --target=%, $(KBUILD_CFLAGS))
KBUILD_USERLDFLAGS += $(filter -m32 -m64 --target=%, $(KBUILD_CFLAGS))
diff --git a/arch/Kconfig b/arch/Kconfig
index 56b6ccc0e32d..ba4e966484ab 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1028,6 +1028,15 @@ config HAVE_STATIC_CALL_INLINE
bool
depends on HAVE_STATIC_CALL
+config ARCH_WANT_LD_ORPHAN_WARN
+ bool
+ help
+ An arch should select this symbol once all linker sections are explicitly
+ included, size-asserted, or discarded in the linker scripts. This is
+ important because we never want expected sections to be placed heuristically
+ by the linker, since the locations of such sections can change between linker
+ versions.
+
source "kernel/gcov/Kconfig"
source "scripts/gcc-plugins/Kconfig"
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index fe2f17eb2b50..002e0cf025f5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -35,6 +35,7 @@ config ARM
select ARCH_USE_CMPXCHG_LOCKREF
select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
select ARCH_WANT_IPC_PARSE_VERSION
+ select ARCH_WANT_LD_ORPHAN_WARN
select BINFMT_FLAT_ARGVP_ENVP_ON_STACK
select BUILDTIME_TABLE_SORT if MMU
select CLONE_BACKWARDS
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 4d76eab2b22d..e15f76ca2887 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -16,10 +16,6 @@ LDFLAGS_vmlinux += --be8
KBUILD_LDFLAGS_MODULE += --be8
endif
-# We never want expected sections to be placed heuristically by the
-# linker. All sections should be explicitly named in the linker script.
-LDFLAGS_vmlinux += $(call ld-option, --orphan-handling=warn)
-
GZFLAGS :=-9
#KBUILD_CFLAGS +=-pipe
diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 47f001ca5499..e1567418a2b1 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -129,7 +129,9 @@ LDFLAGS_vmlinux += --no-undefined
# Delete all temporary local symbols
LDFLAGS_vmlinux += -X
# Report orphan sections
-LDFLAGS_vmlinux += $(call ld-option, --orphan-handling=warn)
+ifdef CONFIG_LD_ORPHAN_WARN
+LDFLAGS_vmlinux += --orphan-handling=warn
+endif
# Next argument is a linker script
LDFLAGS_vmlinux += -T
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1515f6f153a0..a6b5b7ef40ae 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -81,6 +81,7 @@ config ARM64
select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
select ARCH_WANT_FRAME_POINTERS
select ARCH_WANT_HUGE_PMD_SHARE if ARM64_4K_PAGES || (ARM64_16K_PAGES && !ARM64_VA_BITS_36)
+ select ARCH_WANT_LD_ORPHAN_WARN
select ARCH_HAS_UBSAN_SANITIZE_ALL
select ARM_AMBA
select ARM_ARCH_TIMER
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 5789c2d18d43..6a87d592bd00 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -28,10 +28,6 @@ LDFLAGS_vmlinux += --fix-cortex-a53-843419
endif
endif
-# We never want expected sections to be placed heuristically by the
-# linker. All sections should be explicitly named in the linker script.
-LDFLAGS_vmlinux += $(call ld-option, --orphan-handling=warn)
-
ifeq ($(CONFIG_ARM64_USE_LSE_ATOMICS), y)
ifneq ($(CONFIG_ARM64_LSE_ATOMICS), y)
$(warning LSE atomics not supported by binutils)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index e9f13fe08492..5181872f9452 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -152,6 +152,7 @@ config PPC
select ARCH_USE_QUEUED_SPINLOCKS if PPC_QUEUED_SPINLOCKS
select ARCH_WANT_IPC_PARSE_VERSION
select ARCH_WANT_IRQS_OFF_ACTIVATE_MM
+ select ARCH_WANT_LD_ORPHAN_WARN
select ARCH_WEAK_RELEASE_ACQUIRE
select BINFMT_ELF
select BUILDTIME_TABLE_SORT
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index a4d56f0a41d9..d9eb0da845e1 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -123,7 +123,6 @@ endif
LDFLAGS_vmlinux-y := -Bstatic
LDFLAGS_vmlinux-$(CONFIG_RELOCATABLE) := -pie
LDFLAGS_vmlinux := $(LDFLAGS_vmlinux-y)
-LDFLAGS_vmlinux += $(call ld-option,--orphan-handling=warn)
ifdef CONFIG_PPC64
ifeq ($(call cc-option-yn,-mcmodel=medium),y)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f6946b81f74a..fbf26e0f7a6a 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -100,6 +100,7 @@ config X86
select ARCH_WANT_DEFAULT_BPF_JIT if X86_64
select ARCH_WANTS_DYNAMIC_TASK_STRUCT
select ARCH_WANT_HUGE_PMD_SHARE
+ select ARCH_WANT_LD_ORPHAN_WARN
select ARCH_WANTS_THP_SWAP if X86_64
select BUILDTIME_TABLE_SORT
select CLKEVT_I8253
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 154259f18b8b..1bf21746f4ce 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -209,9 +209,6 @@ ifdef CONFIG_X86_64
LDFLAGS_vmlinux += -z max-page-size=0x200000
endif
-# We never want expected sections to be placed heuristically by the
-# linker. All sections should be explicitly named in the linker script.
-LDFLAGS_vmlinux += $(call ld-option, --orphan-handling=warn)
archscripts: scripts_basic
$(Q)$(MAKE) $(build)=arch/x86/tools relocs
diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
index ee249088cbfe..40b8fd375d52 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -61,7 +61,9 @@ KBUILD_LDFLAGS += $(call ld-option,--no-ld-generated-unwind-info)
# Compressed kernel should be built as PIE since it may be loaded at any
# address by the bootloader.
LDFLAGS_vmlinux := -pie $(call ld-option, --no-dynamic-linker)
-LDFLAGS_vmlinux += $(call ld-option, --orphan-handling=warn)
+ifdef CONFIG_LD_ORPHAN_WARN
+LDFLAGS_vmlinux += --orphan-handling=warn
+endif
LDFLAGS_vmlinux += -T
hostprogs := mkpiggy
diff --git a/init/Kconfig b/init/Kconfig
index c9446911cf41..92c58b45abb8 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1348,6 +1348,11 @@ config LD_DEAD_CODE_DATA_ELIMINATION
present. This option is not well tested yet, so use at your
own risk.
+config LD_ORPHAN_WARN
+ def_bool y
+ depends on ARCH_WANT_LD_ORPHAN_WARN
+ depends on $(ld-option,--orphan-handling=warn)
+
config SYSCTL
bool
base-commit: 09162bc32c880a791c6c0668ce0745cf7958f576
--
2.29.2
^ permalink raw reply related [relevance 62%]
* [PATCH v2 1/2] kbuild: Hoist '--orphan-handling' into Kconfig
@ 2020-11-19 20:46 62% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-19 20:46 UTC (permalink / raw)
To: Masahiro Yamada, Michal Marek, Kees Cook
Cc: linuxppc-dev, linux-kbuild, Catalin Marinas, x86,
Nick Desaulniers, Russell King, linux-kernel, clang-built-linux,
Arvind Sankar, Ingo Molnar, Borislav Petkov, Michael Ellerman,
Thomas Gleixner, Will Deacon, Nathan Chancellor,
linux-arm-kernel
Currently, '--orphan-handling=warn' is spread out across four different
architectures in their respective Makefiles, which makes it a little
unruly to deal with in case it needs to be disabled for a specific
linker version (in this case, ld.lld 10.0.1).
To make it easier to control this, hoist this warning into Kconfig and
the main Makefile so that disabling it is simpler, as the warning will
only be enabled in a couple places (main Makefile and a couple of
compressed boot folders that blow away LDFLAGS_vmlinx) and making it
conditional is easier due to Kconfig syntax. One small additional
benefit of this is saving a call to ld-option on incremental builds
because we will have already evaluated it for CONFIG_LD_ORPHAN_WARN.
To keep the list of supported architectures the same, introduce
CONFIG_ARCH_WANT_LD_ORPHAN_WARN, which an architecture can select to
gain this automatically after all of the sections are specified and size
asserted. A special thanks to Kees Cook for the help text on this
config.
Link: https://github.com/ClangBuiltLinux/linux/issues/1187
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
v1 -> v2:
* Change
ifeq ($(CONFIG_LD_ORPHAN_WARN),y)
to
ifdef CONFIG_LD_ORPHAN_WARN
to improve readability (Michael Ellerman)
* Separate conditions for CONFIG_LD_ORPHAN warn to improve
readability (Kees Cook)
* Pick up tags from Kees, Michael, and Nick
Makefile | 6 ++++++
arch/Kconfig | 9 +++++++++
arch/arm/Kconfig | 1 +
arch/arm/Makefile | 4 ----
arch/arm/boot/compressed/Makefile | 4 +++-
arch/arm64/Kconfig | 1 +
arch/arm64/Makefile | 4 ----
arch/powerpc/Kconfig | 1 +
arch/powerpc/Makefile | 1 -
arch/x86/Kconfig | 1 +
arch/x86/Makefile | 3 ---
arch/x86/boot/compressed/Makefile | 4 +++-
init/Kconfig | 5 +++++
13 files changed, 30 insertions(+), 14 deletions(-)
diff --git a/Makefile b/Makefile
index e2c3f65c4721..2c7116299f1f 100644
--- a/Makefile
+++ b/Makefile
@@ -984,6 +984,12 @@ ifeq ($(CONFIG_RELR),y)
LDFLAGS_vmlinux += --pack-dyn-relocs=relr
endif
+# We never want expected sections to be placed heuristically by the
+# linker. All sections should be explicitly named in the linker script.
+ifdef CONFIG_LD_ORPHAN_WARN
+LDFLAGS_vmlinux += --orphan-handling=warn
+endif
+
# Align the bit size of userspace programs with the kernel
KBUILD_USERCFLAGS += $(filter -m32 -m64 --target=%, $(KBUILD_CFLAGS))
KBUILD_USERLDFLAGS += $(filter -m32 -m64 --target=%, $(KBUILD_CFLAGS))
diff --git a/arch/Kconfig b/arch/Kconfig
index 56b6ccc0e32d..ba4e966484ab 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1028,6 +1028,15 @@ config HAVE_STATIC_CALL_INLINE
bool
depends on HAVE_STATIC_CALL
+config ARCH_WANT_LD_ORPHAN_WARN
+ bool
+ help
+ An arch should select this symbol once all linker sections are explicitly
+ included, size-asserted, or discarded in the linker scripts. This is
+ important because we never want expected sections to be placed heuristically
+ by the linker, since the locations of such sections can change between linker
+ versions.
+
source "kernel/gcov/Kconfig"
source "scripts/gcc-plugins/Kconfig"
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index fe2f17eb2b50..002e0cf025f5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -35,6 +35,7 @@ config ARM
select ARCH_USE_CMPXCHG_LOCKREF
select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
select ARCH_WANT_IPC_PARSE_VERSION
+ select ARCH_WANT_LD_ORPHAN_WARN
select BINFMT_FLAT_ARGVP_ENVP_ON_STACK
select BUILDTIME_TABLE_SORT if MMU
select CLONE_BACKWARDS
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 4d76eab2b22d..e15f76ca2887 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -16,10 +16,6 @@ LDFLAGS_vmlinux += --be8
KBUILD_LDFLAGS_MODULE += --be8
endif
-# We never want expected sections to be placed heuristically by the
-# linker. All sections should be explicitly named in the linker script.
-LDFLAGS_vmlinux += $(call ld-option, --orphan-handling=warn)
-
GZFLAGS :=-9
#KBUILD_CFLAGS +=-pipe
diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 47f001ca5499..e1567418a2b1 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -129,7 +129,9 @@ LDFLAGS_vmlinux += --no-undefined
# Delete all temporary local symbols
LDFLAGS_vmlinux += -X
# Report orphan sections
-LDFLAGS_vmlinux += $(call ld-option, --orphan-handling=warn)
+ifdef CONFIG_LD_ORPHAN_WARN
+LDFLAGS_vmlinux += --orphan-handling=warn
+endif
# Next argument is a linker script
LDFLAGS_vmlinux += -T
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1515f6f153a0..a6b5b7ef40ae 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -81,6 +81,7 @@ config ARM64
select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
select ARCH_WANT_FRAME_POINTERS
select ARCH_WANT_HUGE_PMD_SHARE if ARM64_4K_PAGES || (ARM64_16K_PAGES && !ARM64_VA_BITS_36)
+ select ARCH_WANT_LD_ORPHAN_WARN
select ARCH_HAS_UBSAN_SANITIZE_ALL
select ARM_AMBA
select ARM_ARCH_TIMER
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 5789c2d18d43..6a87d592bd00 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -28,10 +28,6 @@ LDFLAGS_vmlinux += --fix-cortex-a53-843419
endif
endif
-# We never want expected sections to be placed heuristically by the
-# linker. All sections should be explicitly named in the linker script.
-LDFLAGS_vmlinux += $(call ld-option, --orphan-handling=warn)
-
ifeq ($(CONFIG_ARM64_USE_LSE_ATOMICS), y)
ifneq ($(CONFIG_ARM64_LSE_ATOMICS), y)
$(warning LSE atomics not supported by binutils)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index e9f13fe08492..5181872f9452 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -152,6 +152,7 @@ config PPC
select ARCH_USE_QUEUED_SPINLOCKS if PPC_QUEUED_SPINLOCKS
select ARCH_WANT_IPC_PARSE_VERSION
select ARCH_WANT_IRQS_OFF_ACTIVATE_MM
+ select ARCH_WANT_LD_ORPHAN_WARN
select ARCH_WEAK_RELEASE_ACQUIRE
select BINFMT_ELF
select BUILDTIME_TABLE_SORT
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index a4d56f0a41d9..d9eb0da845e1 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -123,7 +123,6 @@ endif
LDFLAGS_vmlinux-y := -Bstatic
LDFLAGS_vmlinux-$(CONFIG_RELOCATABLE) := -pie
LDFLAGS_vmlinux := $(LDFLAGS_vmlinux-y)
-LDFLAGS_vmlinux += $(call ld-option,--orphan-handling=warn)
ifdef CONFIG_PPC64
ifeq ($(call cc-option-yn,-mcmodel=medium),y)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f6946b81f74a..fbf26e0f7a6a 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -100,6 +100,7 @@ config X86
select ARCH_WANT_DEFAULT_BPF_JIT if X86_64
select ARCH_WANTS_DYNAMIC_TASK_STRUCT
select ARCH_WANT_HUGE_PMD_SHARE
+ select ARCH_WANT_LD_ORPHAN_WARN
select ARCH_WANTS_THP_SWAP if X86_64
select BUILDTIME_TABLE_SORT
select CLKEVT_I8253
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 154259f18b8b..1bf21746f4ce 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -209,9 +209,6 @@ ifdef CONFIG_X86_64
LDFLAGS_vmlinux += -z max-page-size=0x200000
endif
-# We never want expected sections to be placed heuristically by the
-# linker. All sections should be explicitly named in the linker script.
-LDFLAGS_vmlinux += $(call ld-option, --orphan-handling=warn)
archscripts: scripts_basic
$(Q)$(MAKE) $(build)=arch/x86/tools relocs
diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
index ee249088cbfe..40b8fd375d52 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -61,7 +61,9 @@ KBUILD_LDFLAGS += $(call ld-option,--no-ld-generated-unwind-info)
# Compressed kernel should be built as PIE since it may be loaded at any
# address by the bootloader.
LDFLAGS_vmlinux := -pie $(call ld-option, --no-dynamic-linker)
-LDFLAGS_vmlinux += $(call ld-option, --orphan-handling=warn)
+ifdef CONFIG_LD_ORPHAN_WARN
+LDFLAGS_vmlinux += --orphan-handling=warn
+endif
LDFLAGS_vmlinux += -T
hostprogs := mkpiggy
diff --git a/init/Kconfig b/init/Kconfig
index c9446911cf41..92c58b45abb8 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1348,6 +1348,11 @@ config LD_DEAD_CODE_DATA_ELIMINATION
present. This option is not well tested yet, so use at your
own risk.
+config LD_ORPHAN_WARN
+ def_bool y
+ depends on ARCH_WANT_LD_ORPHAN_WARN
+ depends on $(ld-option,--orphan-handling=warn)
+
config SYSCTL
bool
base-commit: 09162bc32c880a791c6c0668ce0745cf7958f576
--
2.29.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [relevance 62%]
* [PATCH v2 2/2] kbuild: Disable CONFIG_LD_ORPHAN_WARN for ld.lld 10.0.1
@ 2020-11-19 20:46 82% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-19 20:46 UTC (permalink / raw)
To: Masahiro Yamada, Michal Marek, Kees Cook
Cc: linuxppc-dev, kernelci . org bot, linux-kbuild, Catalin Marinas,
Mark Brown, x86, Nick Desaulniers, Russell King, linux-kernel,
clang-built-linux, Arvind Sankar, Ingo Molnar, Borislav Petkov,
Michael Ellerman, Thomas Gleixner, Will Deacon,
Nathan Chancellor, linux-arm-kernel
ld.lld 10.0.1 spews a bunch of various warnings about .rela sections,
along with a few others. Newer versions of ld.lld do not have these
warnings. As a result, do not add '--orphan-handling=warn' to
LDFLAGS_vmlinux if ld.lld's version is not new enough.
Link: https://github.com/ClangBuiltLinux/linux/issues/1187
Link: https://github.com/ClangBuiltLinux/linux/issues/1193
Reported-by: Arvind Sankar <nivedita@alum.mit.edu>
Reported-by: kernelci.org bot <bot@kernelci.org>
Reported-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
v1 -> v2:
* Add condition as a depends on line (Kees Cook)
* Capture output of "$* --version" to avoid invoking linker twice (Nick
Desaulniers)
* Improve documentation of script in comments (Nick Desaulniers)
* Pick up review tag from Kees
MAINTAINERS | 1 +
init/Kconfig | 5 +++++
scripts/lld-version.sh | 20 ++++++++++++++++++++
3 files changed, 26 insertions(+)
create mode 100755 scripts/lld-version.sh
diff --git a/MAINTAINERS b/MAINTAINERS
index e451dcce054f..e6f74f130ae1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4284,6 +4284,7 @@ B: https://github.com/ClangBuiltLinux/linux/issues
C: irc://chat.freenode.net/clangbuiltlinux
F: Documentation/kbuild/llvm.rst
F: scripts/clang-tools/
+F: scripts/lld-version.sh
K: \b(?i:clang|llvm)\b
CLEANCACHE API
diff --git a/init/Kconfig b/init/Kconfig
index 92c58b45abb8..b9037d6c5ab3 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -47,6 +47,10 @@ config CLANG_VERSION
int
default $(shell,$(srctree)/scripts/clang-version.sh $(CC))
+config LLD_VERSION
+ int
+ default $(shell,$(srctree)/scripts/lld-version.sh $(LD))
+
config CC_CAN_LINK
bool
default $(success,$(srctree)/scripts/cc-can-link.sh $(CC) $(CLANG_FLAGS) $(m64-flag)) if 64BIT
@@ -1351,6 +1355,7 @@ config LD_DEAD_CODE_DATA_ELIMINATION
config LD_ORPHAN_WARN
def_bool y
depends on ARCH_WANT_LD_ORPHAN_WARN
+ depends on !LD_IS_LLD || LLD_VERSION >= 110000
depends on $(ld-option,--orphan-handling=warn)
config SYSCTL
diff --git a/scripts/lld-version.sh b/scripts/lld-version.sh
new file mode 100755
index 000000000000..d70edb4d8a4f
--- /dev/null
+++ b/scripts/lld-version.sh
@@ -0,0 +1,20 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+#
+# Usage: $ ./scripts/lld-version.sh ld.lld
+#
+# Print the linker version of `ld.lld' in a 5 or 6-digit form
+# such as `100001' for ld.lld 10.0.1 etc.
+
+linker_string="$($* --version)"
+
+if ! ( echo $linker_string | grep -q LLD ); then
+ echo 0
+ exit 1
+fi
+
+VERSION=$(echo $linker_string | cut -d ' ' -f 2)
+MAJOR=$(echo $VERSION | cut -d . -f 1)
+MINOR=$(echo $VERSION | cut -d . -f 2)
+PATCHLEVEL=$(echo $VERSION | cut -d . -f 3)
+printf "%d%02d%02d\\n" $MAJOR $MINOR $PATCHLEVEL
--
2.29.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [relevance 82%]
* [PATCH v2 2/2] kbuild: Disable CONFIG_LD_ORPHAN_WARN for ld.lld 10.0.1
@ 2020-11-19 20:46 82% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-19 20:46 UTC (permalink / raw)
To: Masahiro Yamada, Michal Marek, Kees Cook
Cc: Russell King, Catalin Marinas, Will Deacon, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, x86,
Nick Desaulniers, Arvind Sankar, linux-kernel, linux-kbuild,
linux-arm-kernel, linuxppc-dev, clang-built-linux,
Nathan Chancellor, kernelci . org bot, Mark Brown
ld.lld 10.0.1 spews a bunch of various warnings about .rela sections,
along with a few others. Newer versions of ld.lld do not have these
warnings. As a result, do not add '--orphan-handling=warn' to
LDFLAGS_vmlinux if ld.lld's version is not new enough.
Link: https://github.com/ClangBuiltLinux/linux/issues/1187
Link: https://github.com/ClangBuiltLinux/linux/issues/1193
Reported-by: Arvind Sankar <nivedita@alum.mit.edu>
Reported-by: kernelci.org bot <bot@kernelci.org>
Reported-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
v1 -> v2:
* Add condition as a depends on line (Kees Cook)
* Capture output of "$* --version" to avoid invoking linker twice (Nick
Desaulniers)
* Improve documentation of script in comments (Nick Desaulniers)
* Pick up review tag from Kees
MAINTAINERS | 1 +
init/Kconfig | 5 +++++
scripts/lld-version.sh | 20 ++++++++++++++++++++
3 files changed, 26 insertions(+)
create mode 100755 scripts/lld-version.sh
diff --git a/MAINTAINERS b/MAINTAINERS
index e451dcce054f..e6f74f130ae1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4284,6 +4284,7 @@ B: https://github.com/ClangBuiltLinux/linux/issues
C: irc://chat.freenode.net/clangbuiltlinux
F: Documentation/kbuild/llvm.rst
F: scripts/clang-tools/
+F: scripts/lld-version.sh
K: \b(?i:clang|llvm)\b
CLEANCACHE API
diff --git a/init/Kconfig b/init/Kconfig
index 92c58b45abb8..b9037d6c5ab3 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -47,6 +47,10 @@ config CLANG_VERSION
int
default $(shell,$(srctree)/scripts/clang-version.sh $(CC))
+config LLD_VERSION
+ int
+ default $(shell,$(srctree)/scripts/lld-version.sh $(LD))
+
config CC_CAN_LINK
bool
default $(success,$(srctree)/scripts/cc-can-link.sh $(CC) $(CLANG_FLAGS) $(m64-flag)) if 64BIT
@@ -1351,6 +1355,7 @@ config LD_DEAD_CODE_DATA_ELIMINATION
config LD_ORPHAN_WARN
def_bool y
depends on ARCH_WANT_LD_ORPHAN_WARN
+ depends on !LD_IS_LLD || LLD_VERSION >= 110000
depends on $(ld-option,--orphan-handling=warn)
config SYSCTL
diff --git a/scripts/lld-version.sh b/scripts/lld-version.sh
new file mode 100755
index 000000000000..d70edb4d8a4f
--- /dev/null
+++ b/scripts/lld-version.sh
@@ -0,0 +1,20 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+#
+# Usage: $ ./scripts/lld-version.sh ld.lld
+#
+# Print the linker version of `ld.lld' in a 5 or 6-digit form
+# such as `100001' for ld.lld 10.0.1 etc.
+
+linker_string="$($* --version)"
+
+if ! ( echo $linker_string | grep -q LLD ); then
+ echo 0
+ exit 1
+fi
+
+VERSION=$(echo $linker_string | cut -d ' ' -f 2)
+MAJOR=$(echo $VERSION | cut -d . -f 1)
+MINOR=$(echo $VERSION | cut -d . -f 2)
+PATCHLEVEL=$(echo $VERSION | cut -d . -f 3)
+printf "%d%02d%02d\\n" $MAJOR $MINOR $PATCHLEVEL
--
2.29.2
^ permalink raw reply related [relevance 83%]
* [PATCH v2 1/2] kbuild: Hoist '--orphan-handling' into Kconfig
@ 2020-11-19 20:46 62% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-19 20:46 UTC (permalink / raw)
To: Masahiro Yamada, Michal Marek, Kees Cook
Cc: Russell King, Catalin Marinas, Will Deacon, Michael Ellerman,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, x86,
Nick Desaulniers, Arvind Sankar, linux-kernel, linux-kbuild,
linux-arm-kernel, linuxppc-dev, clang-built-linux,
Nathan Chancellor
Currently, '--orphan-handling=warn' is spread out across four different
architectures in their respective Makefiles, which makes it a little
unruly to deal with in case it needs to be disabled for a specific
linker version (in this case, ld.lld 10.0.1).
To make it easier to control this, hoist this warning into Kconfig and
the main Makefile so that disabling it is simpler, as the warning will
only be enabled in a couple places (main Makefile and a couple of
compressed boot folders that blow away LDFLAGS_vmlinx) and making it
conditional is easier due to Kconfig syntax. One small additional
benefit of this is saving a call to ld-option on incremental builds
because we will have already evaluated it for CONFIG_LD_ORPHAN_WARN.
To keep the list of supported architectures the same, introduce
CONFIG_ARCH_WANT_LD_ORPHAN_WARN, which an architecture can select to
gain this automatically after all of the sections are specified and size
asserted. A special thanks to Kees Cook for the help text on this
config.
Link: https://github.com/ClangBuiltLinux/linux/issues/1187
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
v1 -> v2:
* Change
ifeq ($(CONFIG_LD_ORPHAN_WARN),y)
to
ifdef CONFIG_LD_ORPHAN_WARN
to improve readability (Michael Ellerman)
* Separate conditions for CONFIG_LD_ORPHAN warn to improve
readability (Kees Cook)
* Pick up tags from Kees, Michael, and Nick
Makefile | 6 ++++++
arch/Kconfig | 9 +++++++++
arch/arm/Kconfig | 1 +
arch/arm/Makefile | 4 ----
arch/arm/boot/compressed/Makefile | 4 +++-
arch/arm64/Kconfig | 1 +
arch/arm64/Makefile | 4 ----
arch/powerpc/Kconfig | 1 +
arch/powerpc/Makefile | 1 -
arch/x86/Kconfig | 1 +
arch/x86/Makefile | 3 ---
arch/x86/boot/compressed/Makefile | 4 +++-
init/Kconfig | 5 +++++
13 files changed, 30 insertions(+), 14 deletions(-)
diff --git a/Makefile b/Makefile
index e2c3f65c4721..2c7116299f1f 100644
--- a/Makefile
+++ b/Makefile
@@ -984,6 +984,12 @@ ifeq ($(CONFIG_RELR),y)
LDFLAGS_vmlinux += --pack-dyn-relocs=relr
endif
+# We never want expected sections to be placed heuristically by the
+# linker. All sections should be explicitly named in the linker script.
+ifdef CONFIG_LD_ORPHAN_WARN
+LDFLAGS_vmlinux += --orphan-handling=warn
+endif
+
# Align the bit size of userspace programs with the kernel
KBUILD_USERCFLAGS += $(filter -m32 -m64 --target=%, $(KBUILD_CFLAGS))
KBUILD_USERLDFLAGS += $(filter -m32 -m64 --target=%, $(KBUILD_CFLAGS))
diff --git a/arch/Kconfig b/arch/Kconfig
index 56b6ccc0e32d..ba4e966484ab 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1028,6 +1028,15 @@ config HAVE_STATIC_CALL_INLINE
bool
depends on HAVE_STATIC_CALL
+config ARCH_WANT_LD_ORPHAN_WARN
+ bool
+ help
+ An arch should select this symbol once all linker sections are explicitly
+ included, size-asserted, or discarded in the linker scripts. This is
+ important because we never want expected sections to be placed heuristically
+ by the linker, since the locations of such sections can change between linker
+ versions.
+
source "kernel/gcov/Kconfig"
source "scripts/gcc-plugins/Kconfig"
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index fe2f17eb2b50..002e0cf025f5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -35,6 +35,7 @@ config ARM
select ARCH_USE_CMPXCHG_LOCKREF
select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
select ARCH_WANT_IPC_PARSE_VERSION
+ select ARCH_WANT_LD_ORPHAN_WARN
select BINFMT_FLAT_ARGVP_ENVP_ON_STACK
select BUILDTIME_TABLE_SORT if MMU
select CLONE_BACKWARDS
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 4d76eab2b22d..e15f76ca2887 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -16,10 +16,6 @@ LDFLAGS_vmlinux += --be8
KBUILD_LDFLAGS_MODULE += --be8
endif
-# We never want expected sections to be placed heuristically by the
-# linker. All sections should be explicitly named in the linker script.
-LDFLAGS_vmlinux += $(call ld-option, --orphan-handling=warn)
-
GZFLAGS :=-9
#KBUILD_CFLAGS +=-pipe
diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 47f001ca5499..e1567418a2b1 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -129,7 +129,9 @@ LDFLAGS_vmlinux += --no-undefined
# Delete all temporary local symbols
LDFLAGS_vmlinux += -X
# Report orphan sections
-LDFLAGS_vmlinux += $(call ld-option, --orphan-handling=warn)
+ifdef CONFIG_LD_ORPHAN_WARN
+LDFLAGS_vmlinux += --orphan-handling=warn
+endif
# Next argument is a linker script
LDFLAGS_vmlinux += -T
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1515f6f153a0..a6b5b7ef40ae 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -81,6 +81,7 @@ config ARM64
select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
select ARCH_WANT_FRAME_POINTERS
select ARCH_WANT_HUGE_PMD_SHARE if ARM64_4K_PAGES || (ARM64_16K_PAGES && !ARM64_VA_BITS_36)
+ select ARCH_WANT_LD_ORPHAN_WARN
select ARCH_HAS_UBSAN_SANITIZE_ALL
select ARM_AMBA
select ARM_ARCH_TIMER
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 5789c2d18d43..6a87d592bd00 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -28,10 +28,6 @@ LDFLAGS_vmlinux += --fix-cortex-a53-843419
endif
endif
-# We never want expected sections to be placed heuristically by the
-# linker. All sections should be explicitly named in the linker script.
-LDFLAGS_vmlinux += $(call ld-option, --orphan-handling=warn)
-
ifeq ($(CONFIG_ARM64_USE_LSE_ATOMICS), y)
ifneq ($(CONFIG_ARM64_LSE_ATOMICS), y)
$(warning LSE atomics not supported by binutils)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index e9f13fe08492..5181872f9452 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -152,6 +152,7 @@ config PPC
select ARCH_USE_QUEUED_SPINLOCKS if PPC_QUEUED_SPINLOCKS
select ARCH_WANT_IPC_PARSE_VERSION
select ARCH_WANT_IRQS_OFF_ACTIVATE_MM
+ select ARCH_WANT_LD_ORPHAN_WARN
select ARCH_WEAK_RELEASE_ACQUIRE
select BINFMT_ELF
select BUILDTIME_TABLE_SORT
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index a4d56f0a41d9..d9eb0da845e1 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -123,7 +123,6 @@ endif
LDFLAGS_vmlinux-y := -Bstatic
LDFLAGS_vmlinux-$(CONFIG_RELOCATABLE) := -pie
LDFLAGS_vmlinux := $(LDFLAGS_vmlinux-y)
-LDFLAGS_vmlinux += $(call ld-option,--orphan-handling=warn)
ifdef CONFIG_PPC64
ifeq ($(call cc-option-yn,-mcmodel=medium),y)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f6946b81f74a..fbf26e0f7a6a 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -100,6 +100,7 @@ config X86
select ARCH_WANT_DEFAULT_BPF_JIT if X86_64
select ARCH_WANTS_DYNAMIC_TASK_STRUCT
select ARCH_WANT_HUGE_PMD_SHARE
+ select ARCH_WANT_LD_ORPHAN_WARN
select ARCH_WANTS_THP_SWAP if X86_64
select BUILDTIME_TABLE_SORT
select CLKEVT_I8253
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 154259f18b8b..1bf21746f4ce 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -209,9 +209,6 @@ ifdef CONFIG_X86_64
LDFLAGS_vmlinux += -z max-page-size=0x200000
endif
-# We never want expected sections to be placed heuristically by the
-# linker. All sections should be explicitly named in the linker script.
-LDFLAGS_vmlinux += $(call ld-option, --orphan-handling=warn)
archscripts: scripts_basic
$(Q)$(MAKE) $(build)=arch/x86/tools relocs
diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
index ee249088cbfe..40b8fd375d52 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -61,7 +61,9 @@ KBUILD_LDFLAGS += $(call ld-option,--no-ld-generated-unwind-info)
# Compressed kernel should be built as PIE since it may be loaded at any
# address by the bootloader.
LDFLAGS_vmlinux := -pie $(call ld-option, --no-dynamic-linker)
-LDFLAGS_vmlinux += $(call ld-option, --orphan-handling=warn)
+ifdef CONFIG_LD_ORPHAN_WARN
+LDFLAGS_vmlinux += --orphan-handling=warn
+endif
LDFLAGS_vmlinux += -T
hostprogs := mkpiggy
diff --git a/init/Kconfig b/init/Kconfig
index c9446911cf41..92c58b45abb8 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1348,6 +1348,11 @@ config LD_DEAD_CODE_DATA_ELIMINATION
present. This option is not well tested yet, so use at your
own risk.
+config LD_ORPHAN_WARN
+ def_bool y
+ depends on ARCH_WANT_LD_ORPHAN_WARN
+ depends on $(ld-option,--orphan-handling=warn)
+
config SYSCTL
bool
base-commit: 09162bc32c880a791c6c0668ce0745cf7958f576
--
2.29.2
^ permalink raw reply related [relevance 62%]
* Re: [PATCH v5] bus: mhi: Add MHI PCI support for WWAN modems
@ 2020-11-19 20:01 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-19 20:01 UTC (permalink / raw)
To: Loic Poulain
Cc: manivannan.sadhasivam, bbhatt, hemantk, linux-arm-msm,
bjorn.andersson, jhugo
On Wed, Oct 21, 2020 at 07:18:19PM +0200, Loic Poulain wrote:
> This is a generic MHI-over-PCI controller driver for MHI only devices
> such as QCOM modems. For now it supports registering of Qualcomm SDX55
> based PCIe modules. The MHI channels have been extracted from mhi
> downstream driver.
>
> This driver is for MHI-only devices which have all functionalities
> exposed through MHI channels and accessed by the corresponding MHI
> device drivers (no out-of-band communication).
>
> Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
> Reviewed-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
I see the following warning on 32-bit ARM with clang after this patch
appeared in -next:
drivers/bus/mhi/pci_generic.c:276:25: warning: implicit conversion from
'unsigned long long' to 'dma_addr_t' (aka 'unsigned int') changes value
from 18446744073709551615 to 4294967295 [-Wconstant-conversion]
mhi_cntrl->iova_stop = DMA_BIT_MASK(info->dma_data_width);
~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/dma-mapping.h:76:40: note: expanded from macro
'DMA_BIT_MASK'
#define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
^~~~~
1 warning generated.
An explicit cast to dma_addr_t would solve it but I am not sure if that
is proper or not.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* [PATCH] memory: tegra30-emc: Remove unnecessary of_node_put in tegra_emc_probe
@ 2020-11-19 19:52 97% Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-19 19:52 UTC (permalink / raw)
To: Krzysztof Kozlowski, Dmitry Osipenko
Cc: Thierry Reding, Jonathan Hunter, Nick Desaulniers, linux-kernel,
linux-tegra, clang-built-linux, Nathan Chancellor
Clang warns:
drivers/memory/tegra/tegra30-emc.c:1275:15: warning: variable 'np' is
uninitialized when used here [-Wuninitialized]
of_node_put(np);
^~
drivers/memory/tegra/tegra30-emc.c:1269:24: note: initialize the
variable 'np' to silence this warning
struct device_node *np;
^
= NULL
1 warning generated.
There does not need to be an of_node_put call in this error handling
block after the shuffling of the np assignment. Remove it so there is
no use of uninitialized memory.
Fixes: 5e00fd90183a ("memory: tegra30-emc: Continue probing if timings are missing in device-tree")
Link: https://github.com/ClangBuiltLinux/linux/issues/1203
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
drivers/memory/tegra/tegra30-emc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/memory/tegra/tegra30-emc.c b/drivers/memory/tegra/tegra30-emc.c
index 3488786da03b..93f9002d32ad 100644
--- a/drivers/memory/tegra/tegra30-emc.c
+++ b/drivers/memory/tegra/tegra30-emc.c
@@ -1271,10 +1271,8 @@ static int tegra_emc_probe(struct platform_device *pdev)
int err;
emc = devm_kzalloc(&pdev->dev, sizeof(*emc), GFP_KERNEL);
- if (!emc) {
- of_node_put(np);
+ if (!emc)
return -ENOMEM;
- }
emc->mc = devm_tegra_memory_controller_get(&pdev->dev);
if (IS_ERR(emc->mc))
base-commit: 5e00fd90183ab0103b9f403ce73cb8407ebeb145
--
2.29.2
^ permalink raw reply related [relevance 97%]
* Re: [PATCH] kbuild: Always link with '-z norelro'
@ 2020-11-19 19:33 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-19 19:33 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Dan Rue, Linus Walleij, Michal Marek, Fangrui Song,
Arnd Bergmann, Linux Kbuild mailing list, Catalin Marinas,
Masahiro Yamada, Alan Modra, Russell King, Jian Cai,
Florian Fainelli, Mark Brown, Linux ARM, Abbott Liu,
Andrey Ryabinin, Mike Rapoport, Will Deacon, Ard Biesheuvel,
LKML
On Wed, Nov 18, 2020 at 03:24:04PM -0800, Nick Desaulniers wrote:
> On Wed, Nov 18, 2020 at 3:07 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Thu, 19 Nov 2020 at 00:05, Nick Desaulniers <ndesaulniers@google.com> wrote:
> > >
> > > > > > > > To avoid playing whack-a-mole with different architectures over time,
> > > > > > > > hoist '-z norelro' into the main Makefile. This does not affect ld.bfd
> > > > > > > > because '-z norelro' is the default for it.
> > >
> > > Fangrui pointed out off list that this might need an ld-option wrapper
> > > for older versions of GNU binutils. Dan was showing me some build
> > > logs today, and I thought I spotted such warnings about `-z norelro
> > > will be ignored`.
> >
> > Does ld-option catch options that cause warnings but no errors?
>
> $ ld.bfd -z foo /dev/null
> ld.bfd: warning: -z foo ignored
> ld.bfd: warning: cannot find entry symbol _start; not setting start address
> ➜ echo $?
> 0
>
> Probably not. Can be a version check then (yuck); next is to find when
> ld.bfd supported `-z norelro`.
>
> commit 8c37241be3b1 in binutils looks like it.
> Date: Tue May 11 17:08:38 2004 +0000
>
> which looks like either
> 2004-05-17 19:46:23 +0000 (tag: binutils-2_15)
> or
> 2005-05-02 22:04:18 +0000 (tag: binutils-2_16)
>
> So I think that would be fine then, since the kernel only supports 2.23+.
>
> Though maybe it's
> commit 5fd104addfddb68844fb8df67be832ee98ad9888
> Emit a warning when -z relro is unsupported
>
> ld silently accepts -z relro and -z norelro for targets that lack the
> necessary GNU_RELRO support. This patch makes those targets emit a
> warning instead, and adds testsuite infrastructure to detect when
> relro is unsupported.
>
> So maybe then alpha and xtensa are getting new warnings (IIUC). If
> that's the case, then we might not be able to set `-z norelro`
> globally, and instead have to play whack a mole per architecture.
Sure, I can just submit the arch/arm patch that I had before this for
now and we can always revisit something like this later, if you feel it
is best.
Cheers,
Nathan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [relevance 99%]
* Re: [PATCH] kbuild: Always link with '-z norelro'
@ 2020-11-19 19:33 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-19 19:33 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Ard Biesheuvel, Masahiro Yamada, Michal Marek, Catalin Marinas,
Will Deacon, Russell King, Florian Fainelli, Arnd Bergmann,
Abbott Liu, Linus Walleij, Jian Cai, Andrey Ryabinin,
Mike Rapoport, Linux Kbuild mailing list, LKML, Linux ARM,
Fangrui Song, Dan Rue, Mark Brown, Alan Modra
On Wed, Nov 18, 2020 at 03:24:04PM -0800, Nick Desaulniers wrote:
> On Wed, Nov 18, 2020 at 3:07 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Thu, 19 Nov 2020 at 00:05, Nick Desaulniers <ndesaulniers@google.com> wrote:
> > >
> > > > > > > > To avoid playing whack-a-mole with different architectures over time,
> > > > > > > > hoist '-z norelro' into the main Makefile. This does not affect ld.bfd
> > > > > > > > because '-z norelro' is the default for it.
> > >
> > > Fangrui pointed out off list that this might need an ld-option wrapper
> > > for older versions of GNU binutils. Dan was showing me some build
> > > logs today, and I thought I spotted such warnings about `-z norelro
> > > will be ignored`.
> >
> > Does ld-option catch options that cause warnings but no errors?
>
> $ ld.bfd -z foo /dev/null
> ld.bfd: warning: -z foo ignored
> ld.bfd: warning: cannot find entry symbol _start; not setting start address
> ➜ echo $?
> 0
>
> Probably not. Can be a version check then (yuck); next is to find when
> ld.bfd supported `-z norelro`.
>
> commit 8c37241be3b1 in binutils looks like it.
> Date: Tue May 11 17:08:38 2004 +0000
>
> which looks like either
> 2004-05-17 19:46:23 +0000 (tag: binutils-2_15)
> or
> 2005-05-02 22:04:18 +0000 (tag: binutils-2_16)
>
> So I think that would be fine then, since the kernel only supports 2.23+.
>
> Though maybe it's
> commit 5fd104addfddb68844fb8df67be832ee98ad9888
> Emit a warning when -z relro is unsupported
>
> ld silently accepts -z relro and -z norelro for targets that lack the
> necessary GNU_RELRO support. This patch makes those targets emit a
> warning instead, and adds testsuite infrastructure to detect when
> relro is unsupported.
>
> So maybe then alpha and xtensa are getting new warnings (IIUC). If
> that's the case, then we might not be able to set `-z norelro`
> globally, and instead have to play whack a mole per architecture.
Sure, I can just submit the arch/arm patch that I had before this for
now and we can always revisit something like this later, if you feel it
is best.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH 2/2] kbuild: Disable CONFIG_LD_ORPHAN_WARN for ld.lld 10.0.1
2020-11-18 3:12 99% ` Nathan Chancellor
@ 2020-11-18 3:12 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-18 3:12 UTC (permalink / raw)
To: Kees Cook
Cc: Michal Marek, kernelci . org bot, linux-kbuild, Mark Brown,
Catalin Marinas, Masahiro Yamada, x86, Nick Desaulniers,
Russell King, linux-kernel, linuxppc-dev, Arvind Sankar,
Ingo Molnar, Borislav Petkov, clang-built-linux, Thomas Gleixner,
Will Deacon, linux-arm-kernel
On Tue, Nov 17, 2020 at 01:51:43PM -0800, Kees Cook wrote:
> On Fri, Nov 13, 2020 at 12:55:53PM -0700, Nathan Chancellor wrote:
> > config LD_ORPHAN_WARN
> > - def_bool ARCH_WANT_LD_ORPHAN_WARN && $(ld-option,--orphan-handling=warn)
> > + def_bool ARCH_WANT_LD_ORPHAN_WARN && $(ld-option,--orphan-handling=warn) && (!LD_IS_LLD || LLD_VERSION >= 110000)
>
> Readability nit-pick... I prefer separate "depends" lines to make things
> a little easier to parse, change, etc:
>
> config LD_ORPHAN_WARN
> def_bool y
> depends on ARCH_WANT_LD_ORPHAN_WARN
> depends on !LD_IS_LLD || LLD_VERSION >= 110000
> depends on $(ld-option,--orphan-handling=warn)
>
> Otherwise, yeah, looks good to me. With this and the other suggestions,
> please consider it:
>
> Reviewed-by: Kees Cook <keescook@chromium.org>
Thank you, I have updated it locally for v2!
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH 2/2] kbuild: Disable CONFIG_LD_ORPHAN_WARN for ld.lld 10.0.1
2020-11-18 3:12 80% ` Nathan Chancellor
@ 2020-11-18 3:12 80% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-18 3:12 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Michal Marek, Kees Cook, kernelci . org bot,
Linux Kbuild mailing list, Mark Brown, Catalin Marinas,
Masahiro Yamada, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Russell King, LKML, linuxppc-dev, Arvind Sankar, Ingo Molnar,
Borislav Petkov, clang-built-linux, Thomas Gleixner, Will Deacon,
Linux ARM
On Tue, Nov 17, 2020 at 11:41:15AM -0800, Nick Desaulniers wrote:
> On Fri, Nov 13, 2020 at 11:56 AM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> >
> > ld.lld 10.0.1 spews a bunch of various warnings about .rela sections,
> > along with a few others. Newer versions of ld.lld do not have these
> > warnings. As a result, do not add '--orphan-handling=warn' to
> > LDFLAGS_vmlinux if ld.lld's version is not new enough.
> >
> > Reported-by: Arvind Sankar <nivedita@alum.mit.edu>
> > Reported-by: kernelci.org bot <bot@kernelci.org>
> > Reported-by: Mark Brown <broonie@kernel.org>
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1187
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1193
> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> > ---
> > MAINTAINERS | 1 +
> > init/Kconfig | 6 +++++-
> > scripts/lld-version.sh | 20 ++++++++++++++++++++
> > 3 files changed, 26 insertions(+), 1 deletion(-)
> > create mode 100755 scripts/lld-version.sh
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 3da6d8c154e4..4b83d3591ec7 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -4284,6 +4284,7 @@ B: https://github.com/ClangBuiltLinux/linux/issues
> > C: irc://chat.freenode.net/clangbuiltlinux
> > F: Documentation/kbuild/llvm.rst
> > F: scripts/clang-tools/
> > +F: scripts/lld-version.sh
> > K: \b(?i:clang|llvm)\b
> >
> > CLEANCACHE API
> > diff --git a/init/Kconfig b/init/Kconfig
> > index a270716562de..40c9ca60ac1d 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -47,6 +47,10 @@ config CLANG_VERSION
> > int
> > default $(shell,$(srctree)/scripts/clang-version.sh $(CC))
> >
> > +config LLD_VERSION
> > + int
> > + default $(shell,$(srctree)/scripts/lld-version.sh $(LD))
> > +
> > config CC_CAN_LINK
> > bool
> > default $(success,$(srctree)/scripts/cc-can-link.sh $(CC) $(CLANG_FLAGS) $(m64-flag)) if 64BIT
> > @@ -1349,7 +1353,7 @@ config LD_DEAD_CODE_DATA_ELIMINATION
> > own risk.
> >
> > config LD_ORPHAN_WARN
> > - def_bool ARCH_WANT_LD_ORPHAN_WARN && $(ld-option,--orphan-handling=warn)
> > + def_bool ARCH_WANT_LD_ORPHAN_WARN && $(ld-option,--orphan-handling=warn) && (!LD_IS_LLD || LLD_VERSION >= 110000)
> >
> > config SYSCTL
> > bool
> > diff --git a/scripts/lld-version.sh b/scripts/lld-version.sh
> > new file mode 100755
> > index 000000000000..cc779f412e39
> > --- /dev/null
> > +++ b/scripts/lld-version.sh
> > @@ -0,0 +1,20 @@
> > +#!/bin/sh
> > +# SPDX-License-Identifier: GPL-2.0
> > +#
> > +# ld.lld-version ld.lld-command
>
> ^ it looks like this format was copied from scripts/gcc-version, but
> it's kind of curious/cryptic to me for a comment about usage. Is it
> necessary? A comment in the form:
>
> # Usage: ./scripts/lld-version.sh ld.lld
>
> Would be clearer to me.
>
> > +#
> > +# Print the linker version of `ld.lld-command' in a 5 or 6-digit form
> > +# such as `100001' for ld.lld 10.0.1 etc.
> > +
> > +linker="$*"
> > +
> > +if ! ( $linker --version | grep -q LLD ); then
> > + echo 0
> > + exit 1
> > +fi
> > +
> > +VERSION=$($linker --version | cut -d ' ' -f 2)
>
> This is going to invoke the linker potentially twice if it's LLD.
> Would it be nicer to capture the output of `$linker --version`, check
> which linker it is, then slice that up via `cut` to get the version?
>
> This version is fine to me, but if you're going to send a v2, that
> might be a nice slight cleanup. Otherwise,
>
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> Tested-by: Nick Desaulniers <ndesaulniers@google.com>
>
> (Please drop those tags if you modify this for v2 and I'll rereview/retest).
Below is the impending v2 if you wanted to give it an early test, I plan
to send it along formally Thursday morning with all of the addressed
feedback so far.
Cheers,
Nathan
======================================================================
From 1ef9b12daf2b19ed6687423483d5bb1f5cf82e13 Mon Sep 17 00:00:00 2001
From: Nathan Chancellor <natechancellor@gmail.com>
Date: Tue, 17 Nov 2020 20:11:26 -0700
Subject: [PATCH] kbuild: Disable CONFIG_LD_ORPHAN_WARN for ld.lld 10.0.1
ld.lld 10.0.1 spews a bunch of various warnings about .rela sections,
along with a few others. Newer versions of ld.lld do not have these
warnings. As a result, do not add '--orphan-handling=warn' to
LDFLAGS_vmlinux if ld.lld's version is not new enough.
Link: https://github.com/ClangBuiltLinux/linux/issues/1187
Link: https://github.com/ClangBuiltLinux/linux/issues/1193
Reported-by: Arvind Sankar <nivedita@alum.mit.edu>
Reported-by: kernelci.org bot <bot@kernelci.org>
Reported-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
MAINTAINERS | 1 +
init/Kconfig | 9 ++++++++-
scripts/lld-version.sh | 20 ++++++++++++++++++++
3 files changed, 29 insertions(+), 1 deletion(-)
create mode 100755 scripts/lld-version.sh
diff --git a/MAINTAINERS b/MAINTAINERS
index e451dcce054f..e6f74f130ae1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4284,6 +4284,7 @@ B: https://github.com/ClangBuiltLinux/linux/issues
C: irc://chat.freenode.net/clangbuiltlinux
F: Documentation/kbuild/llvm.rst
F: scripts/clang-tools/
+F: scripts/lld-version.sh
K: \b(?i:clang|llvm)\b
CLEANCACHE API
diff --git a/init/Kconfig b/init/Kconfig
index a270716562de..b9037d6c5ab3 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -47,6 +47,10 @@ config CLANG_VERSION
int
default $(shell,$(srctree)/scripts/clang-version.sh $(CC))
+config LLD_VERSION
+ int
+ default $(shell,$(srctree)/scripts/lld-version.sh $(LD))
+
config CC_CAN_LINK
bool
default $(success,$(srctree)/scripts/cc-can-link.sh $(CC) $(CLANG_FLAGS) $(m64-flag)) if 64BIT
@@ -1349,7 +1353,10 @@ config LD_DEAD_CODE_DATA_ELIMINATION
own risk.
config LD_ORPHAN_WARN
- def_bool ARCH_WANT_LD_ORPHAN_WARN && $(ld-option,--orphan-handling=warn)
+ def_bool y
+ depends on ARCH_WANT_LD_ORPHAN_WARN
+ depends on !LD_IS_LLD || LLD_VERSION >= 110000
+ depends on $(ld-option,--orphan-handling=warn)
config SYSCTL
bool
diff --git a/scripts/lld-version.sh b/scripts/lld-version.sh
new file mode 100755
index 000000000000..d70edb4d8a4f
--- /dev/null
+++ b/scripts/lld-version.sh
@@ -0,0 +1,20 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+#
+# Usage: $ ./scripts/lld-version.sh ld.lld
+#
+# Print the linker version of `ld.lld' in a 5 or 6-digit form
+# such as `100001' for ld.lld 10.0.1 etc.
+
+linker_string="$($* --version)"
+
+if ! ( echo $linker_string | grep -q LLD ); then
+ echo 0
+ exit 1
+fi
+
+VERSION=$(echo $linker_string | cut -d ' ' -f 2)
+MAJOR=$(echo $VERSION | cut -d . -f 1)
+MINOR=$(echo $VERSION | cut -d . -f 2)
+PATCHLEVEL=$(echo $VERSION | cut -d . -f 3)
+printf "%d%02d%02d\\n" $MAJOR $MINOR $PATCHLEVEL
--
2.29.2
^ permalink raw reply related [relevance 81%]
* Re: [PATCH 2/2] kbuild: Disable CONFIG_LD_ORPHAN_WARN for ld.lld 10.0.1
@ 2020-11-18 3:12 80% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-18 3:12 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Michal Marek, Kees Cook, kernelci . org bot,
Linux Kbuild mailing list, Mark Brown, Catalin Marinas,
Masahiro Yamada, maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Russell King, LKML, linuxppc-dev, Arvind Sankar, Ingo Molnar,
Borislav Petkov, clang-built-linux, Michael Ellerman,
Thomas Gleixner, Will Deacon, Linux ARM
On Tue, Nov 17, 2020 at 11:41:15AM -0800, Nick Desaulniers wrote:
> On Fri, Nov 13, 2020 at 11:56 AM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> >
> > ld.lld 10.0.1 spews a bunch of various warnings about .rela sections,
> > along with a few others. Newer versions of ld.lld do not have these
> > warnings. As a result, do not add '--orphan-handling=warn' to
> > LDFLAGS_vmlinux if ld.lld's version is not new enough.
> >
> > Reported-by: Arvind Sankar <nivedita@alum.mit.edu>
> > Reported-by: kernelci.org bot <bot@kernelci.org>
> > Reported-by: Mark Brown <broonie@kernel.org>
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1187
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1193
> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> > ---
> > MAINTAINERS | 1 +
> > init/Kconfig | 6 +++++-
> > scripts/lld-version.sh | 20 ++++++++++++++++++++
> > 3 files changed, 26 insertions(+), 1 deletion(-)
> > create mode 100755 scripts/lld-version.sh
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 3da6d8c154e4..4b83d3591ec7 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -4284,6 +4284,7 @@ B: https://github.com/ClangBuiltLinux/linux/issues
> > C: irc://chat.freenode.net/clangbuiltlinux
> > F: Documentation/kbuild/llvm.rst
> > F: scripts/clang-tools/
> > +F: scripts/lld-version.sh
> > K: \b(?i:clang|llvm)\b
> >
> > CLEANCACHE API
> > diff --git a/init/Kconfig b/init/Kconfig
> > index a270716562de..40c9ca60ac1d 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -47,6 +47,10 @@ config CLANG_VERSION
> > int
> > default $(shell,$(srctree)/scripts/clang-version.sh $(CC))
> >
> > +config LLD_VERSION
> > + int
> > + default $(shell,$(srctree)/scripts/lld-version.sh $(LD))
> > +
> > config CC_CAN_LINK
> > bool
> > default $(success,$(srctree)/scripts/cc-can-link.sh $(CC) $(CLANG_FLAGS) $(m64-flag)) if 64BIT
> > @@ -1349,7 +1353,7 @@ config LD_DEAD_CODE_DATA_ELIMINATION
> > own risk.
> >
> > config LD_ORPHAN_WARN
> > - def_bool ARCH_WANT_LD_ORPHAN_WARN && $(ld-option,--orphan-handling=warn)
> > + def_bool ARCH_WANT_LD_ORPHAN_WARN && $(ld-option,--orphan-handling=warn) && (!LD_IS_LLD || LLD_VERSION >= 110000)
> >
> > config SYSCTL
> > bool
> > diff --git a/scripts/lld-version.sh b/scripts/lld-version.sh
> > new file mode 100755
> > index 000000000000..cc779f412e39
> > --- /dev/null
> > +++ b/scripts/lld-version.sh
> > @@ -0,0 +1,20 @@
> > +#!/bin/sh
> > +# SPDX-License-Identifier: GPL-2.0
> > +#
> > +# ld.lld-version ld.lld-command
>
> ^ it looks like this format was copied from scripts/gcc-version, but
> it's kind of curious/cryptic to me for a comment about usage. Is it
> necessary? A comment in the form:
>
> # Usage: ./scripts/lld-version.sh ld.lld
>
> Would be clearer to me.
>
> > +#
> > +# Print the linker version of `ld.lld-command' in a 5 or 6-digit form
> > +# such as `100001' for ld.lld 10.0.1 etc.
> > +
> > +linker="$*"
> > +
> > +if ! ( $linker --version | grep -q LLD ); then
> > + echo 0
> > + exit 1
> > +fi
> > +
> > +VERSION=$($linker --version | cut -d ' ' -f 2)
>
> This is going to invoke the linker potentially twice if it's LLD.
> Would it be nicer to capture the output of `$linker --version`, check
> which linker it is, then slice that up via `cut` to get the version?
>
> This version is fine to me, but if you're going to send a v2, that
> might be a nice slight cleanup. Otherwise,
>
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> Tested-by: Nick Desaulniers <ndesaulniers@google.com>
>
> (Please drop those tags if you modify this for v2 and I'll rereview/retest).
Below is the impending v2 if you wanted to give it an early test, I plan
to send it along formally Thursday morning with all of the addressed
feedback so far.
Cheers,
Nathan
======================================================================
From 1ef9b12daf2b19ed6687423483d5bb1f5cf82e13 Mon Sep 17 00:00:00 2001
From: Nathan Chancellor <natechancellor@gmail.com>
Date: Tue, 17 Nov 2020 20:11:26 -0700
Subject: [PATCH] kbuild: Disable CONFIG_LD_ORPHAN_WARN for ld.lld 10.0.1
ld.lld 10.0.1 spews a bunch of various warnings about .rela sections,
along with a few others. Newer versions of ld.lld do not have these
warnings. As a result, do not add '--orphan-handling=warn' to
LDFLAGS_vmlinux if ld.lld's version is not new enough.
Link: https://github.com/ClangBuiltLinux/linux/issues/1187
Link: https://github.com/ClangBuiltLinux/linux/issues/1193
Reported-by: Arvind Sankar <nivedita@alum.mit.edu>
Reported-by: kernelci.org bot <bot@kernelci.org>
Reported-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
MAINTAINERS | 1 +
init/Kconfig | 9 ++++++++-
scripts/lld-version.sh | 20 ++++++++++++++++++++
3 files changed, 29 insertions(+), 1 deletion(-)
create mode 100755 scripts/lld-version.sh
diff --git a/MAINTAINERS b/MAINTAINERS
index e451dcce054f..e6f74f130ae1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4284,6 +4284,7 @@ B: https://github.com/ClangBuiltLinux/linux/issues
C: irc://chat.freenode.net/clangbuiltlinux
F: Documentation/kbuild/llvm.rst
F: scripts/clang-tools/
+F: scripts/lld-version.sh
K: \b(?i:clang|llvm)\b
CLEANCACHE API
diff --git a/init/Kconfig b/init/Kconfig
index a270716562de..b9037d6c5ab3 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -47,6 +47,10 @@ config CLANG_VERSION
int
default $(shell,$(srctree)/scripts/clang-version.sh $(CC))
+config LLD_VERSION
+ int
+ default $(shell,$(srctree)/scripts/lld-version.sh $(LD))
+
config CC_CAN_LINK
bool
default $(success,$(srctree)/scripts/cc-can-link.sh $(CC) $(CLANG_FLAGS) $(m64-flag)) if 64BIT
@@ -1349,7 +1353,10 @@ config LD_DEAD_CODE_DATA_ELIMINATION
own risk.
config LD_ORPHAN_WARN
- def_bool ARCH_WANT_LD_ORPHAN_WARN && $(ld-option,--orphan-handling=warn)
+ def_bool y
+ depends on ARCH_WANT_LD_ORPHAN_WARN
+ depends on !LD_IS_LLD || LLD_VERSION >= 110000
+ depends on $(ld-option,--orphan-handling=warn)
config SYSCTL
bool
diff --git a/scripts/lld-version.sh b/scripts/lld-version.sh
new file mode 100755
index 000000000000..d70edb4d8a4f
--- /dev/null
+++ b/scripts/lld-version.sh
@@ -0,0 +1,20 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+#
+# Usage: $ ./scripts/lld-version.sh ld.lld
+#
+# Print the linker version of `ld.lld' in a 5 or 6-digit form
+# such as `100001' for ld.lld 10.0.1 etc.
+
+linker_string="$($* --version)"
+
+if ! ( echo $linker_string | grep -q LLD ); then
+ echo 0
+ exit 1
+fi
+
+VERSION=$(echo $linker_string | cut -d ' ' -f 2)
+MAJOR=$(echo $VERSION | cut -d . -f 1)
+MINOR=$(echo $VERSION | cut -d . -f 2)
+PATCHLEVEL=$(echo $VERSION | cut -d . -f 3)
+printf "%d%02d%02d\\n" $MAJOR $MINOR $PATCHLEVEL
--
2.29.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [relevance 80%]
* Re: [PATCH 2/2] kbuild: Disable CONFIG_LD_ORPHAN_WARN for ld.lld 10.0.1
@ 2020-11-18 3:12 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-18 3:12 UTC (permalink / raw)
To: Kees Cook
Cc: Michal Marek, kernelci . org bot, linux-kbuild, Mark Brown,
Catalin Marinas, Masahiro Yamada, x86, Nick Desaulniers,
Russell King, linux-kernel, linuxppc-dev, Arvind Sankar,
Ingo Molnar, Borislav Petkov, clang-built-linux,
Michael Ellerman, Thomas Gleixner, Will Deacon, linux-arm-kernel
On Tue, Nov 17, 2020 at 01:51:43PM -0800, Kees Cook wrote:
> On Fri, Nov 13, 2020 at 12:55:53PM -0700, Nathan Chancellor wrote:
> > config LD_ORPHAN_WARN
> > - def_bool ARCH_WANT_LD_ORPHAN_WARN && $(ld-option,--orphan-handling=warn)
> > + def_bool ARCH_WANT_LD_ORPHAN_WARN && $(ld-option,--orphan-handling=warn) && (!LD_IS_LLD || LLD_VERSION >= 110000)
>
> Readability nit-pick... I prefer separate "depends" lines to make things
> a little easier to parse, change, etc:
>
> config LD_ORPHAN_WARN
> def_bool y
> depends on ARCH_WANT_LD_ORPHAN_WARN
> depends on !LD_IS_LLD || LLD_VERSION >= 110000
> depends on $(ld-option,--orphan-handling=warn)
>
> Otherwise, yeah, looks good to me. With this and the other suggestions,
> please consider it:
>
> Reviewed-by: Kees Cook <keescook@chromium.org>
Thank you, I have updated it locally for v2!
Cheers,
Nathan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [relevance 99%]
* Re: [PATCH 2/2] kbuild: Disable CONFIG_LD_ORPHAN_WARN for ld.lld 10.0.1
@ 2020-11-18 3:12 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-18 3:12 UTC (permalink / raw)
To: Kees Cook
Cc: Masahiro Yamada, Michal Marek, Russell King, Catalin Marinas,
Will Deacon, Michael Ellerman, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, x86, Nick Desaulniers, Arvind Sankar,
linux-kernel, linux-kbuild, linux-arm-kernel, linuxppc-dev,
clang-built-linux, kernelci . org bot, Mark Brown
On Tue, Nov 17, 2020 at 01:51:43PM -0800, Kees Cook wrote:
> On Fri, Nov 13, 2020 at 12:55:53PM -0700, Nathan Chancellor wrote:
> > config LD_ORPHAN_WARN
> > - def_bool ARCH_WANT_LD_ORPHAN_WARN && $(ld-option,--orphan-handling=warn)
> > + def_bool ARCH_WANT_LD_ORPHAN_WARN && $(ld-option,--orphan-handling=warn) && (!LD_IS_LLD || LLD_VERSION >= 110000)
>
> Readability nit-pick... I prefer separate "depends" lines to make things
> a little easier to parse, change, etc:
>
> config LD_ORPHAN_WARN
> def_bool y
> depends on ARCH_WANT_LD_ORPHAN_WARN
> depends on !LD_IS_LLD || LLD_VERSION >= 110000
> depends on $(ld-option,--orphan-handling=warn)
>
> Otherwise, yeah, looks good to me. With this and the other suggestions,
> please consider it:
>
> Reviewed-by: Kees Cook <keescook@chromium.org>
Thank you, I have updated it locally for v2!
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
* Re: [PATCH 2/2] kbuild: Disable CONFIG_LD_ORPHAN_WARN for ld.lld 10.0.1
@ 2020-11-18 3:12 80% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-18 3:12 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Masahiro Yamada, Michal Marek, Kees Cook, Russell King,
Catalin Marinas, Will Deacon, Michael Ellerman, Thomas Gleixner,
Ingo Molnar, Borislav Petkov,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT),
Arvind Sankar, LKML, Linux Kbuild mailing list, Linux ARM,
linuxppc-dev, clang-built-linux, kernelci . org bot, Mark Brown
On Tue, Nov 17, 2020 at 11:41:15AM -0800, Nick Desaulniers wrote:
> On Fri, Nov 13, 2020 at 11:56 AM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> >
> > ld.lld 10.0.1 spews a bunch of various warnings about .rela sections,
> > along with a few others. Newer versions of ld.lld do not have these
> > warnings. As a result, do not add '--orphan-handling=warn' to
> > LDFLAGS_vmlinux if ld.lld's version is not new enough.
> >
> > Reported-by: Arvind Sankar <nivedita@alum.mit.edu>
> > Reported-by: kernelci.org bot <bot@kernelci.org>
> > Reported-by: Mark Brown <broonie@kernel.org>
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1187
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1193
> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> > ---
> > MAINTAINERS | 1 +
> > init/Kconfig | 6 +++++-
> > scripts/lld-version.sh | 20 ++++++++++++++++++++
> > 3 files changed, 26 insertions(+), 1 deletion(-)
> > create mode 100755 scripts/lld-version.sh
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 3da6d8c154e4..4b83d3591ec7 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -4284,6 +4284,7 @@ B: https://github.com/ClangBuiltLinux/linux/issues
> > C: irc://chat.freenode.net/clangbuiltlinux
> > F: Documentation/kbuild/llvm.rst
> > F: scripts/clang-tools/
> > +F: scripts/lld-version.sh
> > K: \b(?i:clang|llvm)\b
> >
> > CLEANCACHE API
> > diff --git a/init/Kconfig b/init/Kconfig
> > index a270716562de..40c9ca60ac1d 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -47,6 +47,10 @@ config CLANG_VERSION
> > int
> > default $(shell,$(srctree)/scripts/clang-version.sh $(CC))
> >
> > +config LLD_VERSION
> > + int
> > + default $(shell,$(srctree)/scripts/lld-version.sh $(LD))
> > +
> > config CC_CAN_LINK
> > bool
> > default $(success,$(srctree)/scripts/cc-can-link.sh $(CC) $(CLANG_FLAGS) $(m64-flag)) if 64BIT
> > @@ -1349,7 +1353,7 @@ config LD_DEAD_CODE_DATA_ELIMINATION
> > own risk.
> >
> > config LD_ORPHAN_WARN
> > - def_bool ARCH_WANT_LD_ORPHAN_WARN && $(ld-option,--orphan-handling=warn)
> > + def_bool ARCH_WANT_LD_ORPHAN_WARN && $(ld-option,--orphan-handling=warn) && (!LD_IS_LLD || LLD_VERSION >= 110000)
> >
> > config SYSCTL
> > bool
> > diff --git a/scripts/lld-version.sh b/scripts/lld-version.sh
> > new file mode 100755
> > index 000000000000..cc779f412e39
> > --- /dev/null
> > +++ b/scripts/lld-version.sh
> > @@ -0,0 +1,20 @@
> > +#!/bin/sh
> > +# SPDX-License-Identifier: GPL-2.0
> > +#
> > +# ld.lld-version ld.lld-command
>
> ^ it looks like this format was copied from scripts/gcc-version, but
> it's kind of curious/cryptic to me for a comment about usage. Is it
> necessary? A comment in the form:
>
> # Usage: ./scripts/lld-version.sh ld.lld
>
> Would be clearer to me.
>
> > +#
> > +# Print the linker version of `ld.lld-command' in a 5 or 6-digit form
> > +# such as `100001' for ld.lld 10.0.1 etc.
> > +
> > +linker="$*"
> > +
> > +if ! ( $linker --version | grep -q LLD ); then
> > + echo 0
> > + exit 1
> > +fi
> > +
> > +VERSION=$($linker --version | cut -d ' ' -f 2)
>
> This is going to invoke the linker potentially twice if it's LLD.
> Would it be nicer to capture the output of `$linker --version`, check
> which linker it is, then slice that up via `cut` to get the version?
>
> This version is fine to me, but if you're going to send a v2, that
> might be a nice slight cleanup. Otherwise,
>
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> Tested-by: Nick Desaulniers <ndesaulniers@google.com>
>
> (Please drop those tags if you modify this for v2 and I'll rereview/retest).
Below is the impending v2 if you wanted to give it an early test, I plan
to send it along formally Thursday morning with all of the addressed
feedback so far.
Cheers,
Nathan
======================================================================
From 1ef9b12daf2b19ed6687423483d5bb1f5cf82e13 Mon Sep 17 00:00:00 2001
From: Nathan Chancellor <natechancellor@gmail.com>
Date: Tue, 17 Nov 2020 20:11:26 -0700
Subject: [PATCH] kbuild: Disable CONFIG_LD_ORPHAN_WARN for ld.lld 10.0.1
ld.lld 10.0.1 spews a bunch of various warnings about .rela sections,
along with a few others. Newer versions of ld.lld do not have these
warnings. As a result, do not add '--orphan-handling=warn' to
LDFLAGS_vmlinux if ld.lld's version is not new enough.
Link: https://github.com/ClangBuiltLinux/linux/issues/1187
Link: https://github.com/ClangBuiltLinux/linux/issues/1193
Reported-by: Arvind Sankar <nivedita@alum.mit.edu>
Reported-by: kernelci.org bot <bot@kernelci.org>
Reported-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
MAINTAINERS | 1 +
init/Kconfig | 9 ++++++++-
scripts/lld-version.sh | 20 ++++++++++++++++++++
3 files changed, 29 insertions(+), 1 deletion(-)
create mode 100755 scripts/lld-version.sh
diff --git a/MAINTAINERS b/MAINTAINERS
index e451dcce054f..e6f74f130ae1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4284,6 +4284,7 @@ B: https://github.com/ClangBuiltLinux/linux/issues
C: irc://chat.freenode.net/clangbuiltlinux
F: Documentation/kbuild/llvm.rst
F: scripts/clang-tools/
+F: scripts/lld-version.sh
K: \b(?i:clang|llvm)\b
CLEANCACHE API
diff --git a/init/Kconfig b/init/Kconfig
index a270716562de..b9037d6c5ab3 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -47,6 +47,10 @@ config CLANG_VERSION
int
default $(shell,$(srctree)/scripts/clang-version.sh $(CC))
+config LLD_VERSION
+ int
+ default $(shell,$(srctree)/scripts/lld-version.sh $(LD))
+
config CC_CAN_LINK
bool
default $(success,$(srctree)/scripts/cc-can-link.sh $(CC) $(CLANG_FLAGS) $(m64-flag)) if 64BIT
@@ -1349,7 +1353,10 @@ config LD_DEAD_CODE_DATA_ELIMINATION
own risk.
config LD_ORPHAN_WARN
- def_bool ARCH_WANT_LD_ORPHAN_WARN && $(ld-option,--orphan-handling=warn)
+ def_bool y
+ depends on ARCH_WANT_LD_ORPHAN_WARN
+ depends on !LD_IS_LLD || LLD_VERSION >= 110000
+ depends on $(ld-option,--orphan-handling=warn)
config SYSCTL
bool
diff --git a/scripts/lld-version.sh b/scripts/lld-version.sh
new file mode 100755
index 000000000000..d70edb4d8a4f
--- /dev/null
+++ b/scripts/lld-version.sh
@@ -0,0 +1,20 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+#
+# Usage: $ ./scripts/lld-version.sh ld.lld
+#
+# Print the linker version of `ld.lld' in a 5 or 6-digit form
+# such as `100001' for ld.lld 10.0.1 etc.
+
+linker_string="$($* --version)"
+
+if ! ( echo $linker_string | grep -q LLD ); then
+ echo 0
+ exit 1
+fi
+
+VERSION=$(echo $linker_string | cut -d ' ' -f 2)
+MAJOR=$(echo $VERSION | cut -d . -f 1)
+MINOR=$(echo $VERSION | cut -d . -f 2)
+PATCHLEVEL=$(echo $VERSION | cut -d . -f 3)
+printf "%d%02d%02d\\n" $MAJOR $MINOR $PATCHLEVEL
--
2.29.2
^ permalink raw reply related [relevance 80%]
* Re: [PATCH v3 1/7] compiler-clang: add build check for clang 10.0.1
@ 2020-11-18 2:31 99% ` Nathan Chancellor
0 siblings, 0 replies; 200+ results
From: Nathan Chancellor @ 2020-11-18 2:31 UTC (permalink / raw)
To: Nick Desaulniers, Andrew Morton
Cc: John Hubbard, jarkko.sakkinen, Andrey Konovalov,
Alexei Starovoitov, clang-built-linux, Daniel Borkmann,
Marco Elver, Jarkko Sakkinen, Kees Cook, LKML, Masahiro Yamada,
Miguel Ojeda, Sedat Dilek, Vincenzo Frascino, Will Deacon
On Tue, Nov 17, 2020 at 10:46:29AM -0800, Nick Desaulniers wrote:
> On Mon, Nov 16, 2020 at 7:04 PM John Hubbard <jhubbard@nvidia.com> wrote:
> >
> > Hi,
> >
> > I just ran into this and it's a real pain to figure out, because even
> > with the very latest Fedora 33 on my test machine, which provides clang
> > version 11.0.0:
>
> Hi John,
> Thanks for the report. The patch was picked up by AKPM and is in the -mm tree:
> https://ozlabs.org/~akpm/mmots/broken-out/compiler-clang-remove-version-check-for-bpf-tracing.patch
This should probably go to Linus as a regression fix in the next wave,
if that is possible.
Cheers,
Nathan
^ permalink raw reply [relevance 99%]
Results 1-200 of ~2565 next (older) | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2020-09-01 10:40 [PATCH 0/5] hw: Replace some impossible checks by assertions Philippe Mathieu-Daudé
2020-09-01 10:40 ` [PATCH 4/5] hw/ppc/ppc4xx_pci: Replace pointless warning by assert() Philippe Mathieu-Daudé
2021-01-11 1:11 82% ` Nathan Chancellor
2021-01-11 10:04 ` Philippe Mathieu-Daudé
2021-01-11 16:46 99% ` Nathan Chancellor
2020-10-21 17:18 [PATCH v5] bus: mhi: Add MHI PCI support for WWAN modems Loic Poulain
2020-11-19 20:01 99% ` Nathan Chancellor
2020-11-04 1:34 [PATCH v3 1/7] compiler-clang: add build check for clang 10.0.1 Jarkko Sakkinen
2020-11-17 3:04 ` John Hubbard
2020-11-17 18:46 ` Nick Desaulniers
2020-11-18 2:31 99% ` Nathan Chancellor
2020-11-12 18:38 [PATCH] kbuild: Always link with '-z norelro' Nathan Chancellor
2020-11-13 0:44 ` Nick Desaulniers
2020-11-13 0:53 ` Nathan Chancellor
2020-11-13 6:06 ` Ard Biesheuvel
2020-11-13 19:34 ` Nick Desaulniers
2020-11-18 23:05 ` Nick Desaulniers
2020-11-18 23:06 ` Ard Biesheuvel
2020-11-18 23:24 ` Nick Desaulniers
2020-11-19 19:33 99% ` Nathan Chancellor
2020-11-19 19:33 99% ` Nathan Chancellor
2020-11-13 12:34 [PATCH 00/19] Ensure good ECC settings Miquel Raynal
2020-11-13 12:34 ` [PATCH 17/19] mtd: rawnand: r852: Move the ECC initialization to ->attach_chip() Miquel Raynal
2020-11-30 1:07 99% ` Nathan Chancellor
2020-11-13 19:55 [PATCH 1/2] kbuild: Hoist '--orphan-handling' into Kconfig Nathan Chancellor
2020-11-13 19:55 ` [PATCH 2/2] kbuild: Disable CONFIG_LD_ORPHAN_WARN for ld.lld 10.0.1 Nathan Chancellor
2020-11-17 19:41 ` Nick Desaulniers
2020-11-18 3:12 81% ` Nathan Chancellor
2020-11-18 3:12 80% ` Nathan Chancellor
2020-11-18 3:12 80% ` Nathan Chancellor
2020-11-17 21:51 ` Kees Cook
2020-11-18 3:12 99% ` Nathan Chancellor
2020-11-18 3:12 99% ` Nathan Chancellor
2020-11-18 3:12 99% ` Nathan Chancellor
2020-11-19 20:46 62% ` [PATCH v2 1/2] kbuild: Hoist '--orphan-handling' into Kconfig Nathan Chancellor
2020-11-19 20:46 62% ` Nathan Chancellor
2020-11-19 20:46 62% ` Nathan Chancellor
2020-11-19 20:46 84% ` [PATCH v2 2/2] kbuild: Disable CONFIG_LD_ORPHAN_WARN for ld.lld 10.0.1 Nathan Chancellor
2020-11-19 20:46 83% ` Nathan Chancellor
2020-11-19 20:46 82% ` Nathan Chancellor
2020-11-17 18:50 [PATCH 1/3] ibmvfc: byte swap login_buf.resp values in attribute show functions Tyrel Datwyler
2020-11-17 18:50 ` [PATCH 3/3] ibmvfc: use correlation token to tag commands Tyrel Datwyler
2020-12-22 6:24 94% ` Nathan Chancellor
2020-12-22 6:24 94% ` Nathan Chancellor
2020-11-18 22:07 [PATCH v7 00/17] Add support for Clang LTO Sami Tolvanen
2020-11-18 22:07 ` [PATCH v7 02/17] kbuild: add " Sami Tolvanen
2020-11-18 23:48 ` Nick Desaulniers
2020-11-20 16:23 ` Sami Tolvanen
2020-11-20 19:47 ` Kees Cook
2020-11-20 20:29 99% ` Nathan Chancellor
2020-11-20 20:29 99% ` Nathan Chancellor
2020-11-18 23:42 ` [PATCH v7 00/17] Add " Nick Desaulniers
2020-11-20 10:29 ` Ard Biesheuvel
2020-11-21 3:14 98% ` Nathan Chancellor
2020-11-21 3:14 98% ` Nathan Chancellor
2020-11-19 10:19 [PATCH] mhi: pci_generic: Fix implicit conversion warning Loic Poulain
2020-11-19 21:20 99% ` Nathan Chancellor
2020-11-19 18:37 [PATCH] MAINTAINERS: Update email address for Sean Christopherson Sean Christopherson
2020-12-19 6:47 99% ` Nathan Chancellor
2020-11-19 19:52 97% [PATCH] memory: tegra30-emc: Remove unnecessary of_node_put in tegra_emc_probe Nathan Chancellor
2020-11-23 7:36 [RESEND,PATCH] ARM: fix __div64_32() error when compiling with clang Antony Yu
2020-11-23 18:16 99% ` Nathan Chancellor
2020-11-23 18:16 99% ` Nathan Chancellor
2020-11-26 4:44 [stable 4.9] PANIC: double fault, error_code: 0x0 - clang boot failed on x86_64 Naresh Kamboju
2020-11-26 6:39 ` Greg Kroah-Hartman
2020-11-28 5:41 99% ` Nathan Chancellor
2020-11-28 19:33 [PATCH v3] Compiler Attributes: remove CONFIG_ENABLE_MUST_CHECK Masahiro Yamada
2020-11-30 1:04 99% ` Nathan Chancellor
2020-11-30 1:40 99% Apply d853b3406903a7dc5b14eb5bada3e8cd677f66a2 to 5.4 and 5.9 Nathan Chancellor
2020-12-01 1:13 [PATCH] x86, build: remove -m16 workaround for unsupported versions of GCC Nick Desaulniers
2020-12-01 3:51 99% ` Nathan Chancellor
2020-12-01 21:36 [PATCH v8 00/16] Add support for Clang LTO Sami Tolvanen
2020-12-03 11:26 ` Will Deacon
2020-12-03 17:07 ` Sami Tolvanen
2020-12-03 18:21 96% ` Nathan Chancellor
2020-12-03 18:21 96% ` Nathan Chancellor
2020-12-03 18:22 ` Will Deacon
2020-12-03 22:32 ` Nick Desaulniers
2020-12-04 22:52 ` Sami Tolvanen
2020-12-06 6:50 99% ` Nathan Chancellor
2020-12-06 6:50 99% ` Nathan Chancellor
2020-12-06 20:09 ` Sami Tolvanen
2020-12-08 0:46 99% ` Nathan Chancellor
2020-12-08 0:46 99% ` Nathan Chancellor
2020-12-04 1:11 [PATCH v3 1/2] Kbuild: make DWARF version a choice Nick Desaulniers
2020-12-04 1:11 ` [PATCH v3 2/2] Kbuild: implement support for DWARF v5 Nick Desaulniers
2021-01-04 22:12 99% ` Nathan Chancellor
2021-01-04 22:03 99% ` [PATCH v3 1/2] Kbuild: make DWARF version a choice Nathan Chancellor
2020-12-06 12:31 [PATCH 4.19-stable 1/5] spi: Introduce device-managed SPI controller allocation Lukas Wunner
2020-12-06 12:31 ` [PATCH 4.19-stable 4/5] spi: bcm2835aux: Fix use-after-free on unbind Lukas Wunner
2020-12-08 0:49 99% ` Nathan Chancellor
2020-12-08 7:32 ` Lukas Wunner
2020-12-08 13:47 ` Sasha Levin
2020-12-08 17:11 ` Lukas Wunner
2020-12-08 20:28 99% ` Nathan Chancellor
2020-12-11 10:24 [PATCH v2] mips: lib: uncached: fix non-standard usage of variable 'sp' Anders Roxell
2020-12-11 19:54 ` Maciej W. Rozycki
2020-12-12 5:52 99% ` Nathan Chancellor
2020-12-11 13:46 [linux-next:master 6953/13205] drivers/dma/imx-dma.c:1048:20: warning: cast to smaller integer type 'enum imx_dma_type' from 'const void kernel test robot
2020-12-11 14:54 ` Souptick Joarder
2020-12-12 15:40 ` Fabio Estevam
2020-12-12 20:03 99% ` Nathan Chancellor
2020-12-12 20:03 99% ` Nathan Chancellor
2020-12-11 23:19 [linux-next:master 12465/13205] ld.lld: error: undefined symbol: __compiletime_assert_323 kernel test robot
2020-12-12 5:36 99% ` Nathan Chancellor
2020-12-12 5:36 99% ` Nathan Chancellor
2020-12-12 0:15 [PATCH 0/8] hw/ppc: Convert UIC device to QOM Peter Maydell
2020-12-12 0:15 ` [PATCH 4/8] hw/ppc/ppc440_bamboo: Drop use of ppcuic_init() Peter Maydell
2021-01-11 1:00 86% ` Nathan Chancellor
2020-12-16 10:44 [PATCH] ASoC: imx-hdmi: Fix warning of the uninitialized variable ret Shengjiu Wang
2021-01-12 18:19 99% ` Nathan Chancellor
2021-01-12 18:19 99% ` Nathan Chancellor
2021-01-12 18:19 99% ` Nathan Chancellor
2021-01-12 18:48 ` Mark Brown
2021-01-12 19:09 99% ` Nathan Chancellor
2021-01-12 19:09 99% ` Nathan Chancellor
2021-01-12 19:09 99% ` Nathan Chancellor
2020-12-17 21:07 [PATCH] arm64: link with -z norelro for LLD or aarch64-elf Nick Desaulniers
2020-12-18 0:24 ` [PATCH v2] " Nick Desaulniers
2020-12-18 2:36 99% ` Nathan Chancellor
2020-12-18 2:36 99% ` Nathan Chancellor
2020-12-19 6:37 89% [PATCH] KVM: SVM: Add register operand to vmsave call in sev_es_vcpu_load Nathan Chancellor
2020-12-20 16:54 UBSAN: object-size-mismatch in wg_xmit syzbot
2020-12-20 21:11 ` Jason A. Donenfeld
2020-12-21 9:14 ` Dmitry Vyukov
2020-12-21 11:23 ` Jason A. Donenfeld
2021-01-07 12:22 ` Dmitry Vyukov
2021-01-07 19:00 ` Jason A. Donenfeld
2021-01-07 19:06 ` Jeffrey Walton
2021-01-08 9:33 ` Dmitry Vyukov
2021-01-08 20:54 99% ` Nathan Chancellor
2020-12-21 5:13 [PATCH] cpufreq: intel_pstate: remove obsolete functions Lukas Bulwahn
2020-12-21 22:20 99% ` Nathan Chancellor
2020-12-21 22:20 99% ` Nathan Chancellor
2020-12-21 19:22 [djwong-xfs:realtime-rmap 245/249] fs/xfs/scrub/repair.c:2202:6: warning: variable 'is_free' is uninitialized when used here kernel test robot
2020-12-21 22:19 99% ` Nathan Chancellor
2020-12-22 2:59 97% [PATCH] i3c/master/mipi-i3c-hci: Fix position of __maybe_unused in i3c_hci_of_match Nathan Chancellor
2020-12-22 2:59 98% ` Nathan Chancellor
2020-12-23 12:08 [PATCH] KVM: arm64: Fix hyp_cpu_pm_{init,exit} __init annotation Marc Zyngier
2020-12-29 22:34 99% ` Nathan Chancellor
2020-12-29 22:34 99% ` Nathan Chancellor
2020-12-26 1:35 99% [PATCH] mfd: ab8500-debugfs: Remove extraneous curly brace Nathan Chancellor
2020-12-26 7:29 [PATCH] arch/x86: Propagate $(CLANG_FLAGS) to $(REALMODE_FLAGS) John Millikin
2020-12-26 7:35 ` hpa
2020-12-26 7:53 97% ` Nathan Chancellor
2020-12-26 8:41 ` [PATCH v2] " John Millikin
2020-12-27 3:31 99% ` Nathan Chancellor
2020-12-28 12:39 [PATCH 5.10 000/717] 5.10.4-rc1 review Greg Kroah-Hartman
2020-12-28 12:43 ` [PATCH 5.10 212/717] platform/x86: mlx-platform: Remove PSU EEPROM from MSN274x platform configuration Greg Kroah-Hartman
2020-12-29 19:01 99% ` Nathan Chancellor
2020-12-29 20:47 99% [PATCH] pinctrl: nomadik: Remove unused variable in nmk_gpio_dbg_show_one Nathan Chancellor
2020-12-29 20:47 99% ` Nathan Chancellor
2020-12-29 21:15 83% [PATCH] mt76: Fix queue ID variable types after mcu queue split Nathan Chancellor
2020-12-29 21:15 83% ` Nathan Chancellor
2020-12-29 21:43 94% [PATCH] KVM: arm64: Fix section mismatches around hyp_cpu_pm_{init, exit} Nathan Chancellor
2020-12-29 21:43 94% ` [PATCH] KVM: arm64: Fix section mismatches around hyp_cpu_pm_{init,exit} Nathan Chancellor
2020-12-29 21:43 93% ` [PATCH] KVM: arm64: Fix section mismatches around hyp_cpu_pm_{init, exit} Nathan Chancellor
2020-12-29 22:11 ` [PATCH] KVM: arm64: Fix section mismatches around hyp_cpu_pm_{init,exit} Marc Zyngier
2020-12-29 22:33 99% ` Nathan Chancellor
2020-12-29 22:33 99% ` Nathan Chancellor
2020-12-29 22:33 99% ` Nathan Chancellor
2020-12-30 14:56 [PATCH] jffs2: fix use after free in jffs2_sum_write_data() trix
2021-01-04 22:16 99% ` Nathan Chancellor
2021-01-04 22:16 99% ` Nathan Chancellor
2020-12-30 15:40 [PATCH] mm/mremap: fix BUILD_BUG_ON() error in get_extent Arnd Bergmann
2021-01-04 22:36 99% ` Nathan Chancellor
2021-01-12 19:16 99% ` Nathan Chancellor
2020-12-30 15:42 [PATCH] i3c/master/mipi-i3c-hci: re-fix __maybe_unused attribute Arnd Bergmann
2020-12-30 21:23 ` Nicolas Pitre
2020-12-30 21:40 ` Alexandre Belloni
2020-12-30 21:43 99% ` Nathan Chancellor
2020-12-30 21:43 99% ` Nathan Chancellor
2020-12-30 15:44 [PATCH] ASoC: fsl: fix -Wmaybe-uninitialized warning Arnd Bergmann
2020-12-31 8:12 99% ` Nathan Chancellor
2020-12-31 8:12 99% ` Nathan Chancellor
2020-12-31 8:12 99% ` Nathan Chancellor
2020-12-31 8:12 99% ` Nathan Chancellor
2020-12-30 15:47 [PATCH] ubsan: disable unsigned-integer-overflow sanitizer with clang Arnd Bergmann
2020-12-30 16:13 ` Marco Elver
2021-01-04 22:33 99% ` Nathan Chancellor
2021-01-04 23:33 ` Andrew Morton
2021-01-04 23:34 99% ` Nathan Chancellor
2021-01-05 9:25 ` Arnd Bergmann
2021-01-06 9:12 ` Arnd Bergmann
2021-01-06 21:38 99% ` Nathan Chancellor
2021-01-06 22:06 ` Arnd Bergmann
2021-01-07 3:34 87% ` Nathan Chancellor
2021-01-06 21:57 ` Kees Cook
2021-01-06 22:12 ` Arnd Bergmann
2021-01-07 16:09 ` Arnd Bergmann
2021-01-07 17:22 ` Kees Cook
2021-01-07 18:15 99% ` Nathan Chancellor
2020-12-31 21:28 [PATCH] percpu: fix clang modpost warning in pcpu_build_alloc_info() Dennis Zhou
2021-01-04 23:46 99% ` Nathan Chancellor
2021-01-03 1:51 drivers/net/wireless/intel/iwlwifi/queue/tx.c:310:18: warning: result of comparison of constant 262140 with expression of type 'u16' (aka 'unsigned short') is always false kernel test robot
2021-01-04 18:47 99% ` Nathan Chancellor
2021-01-04 12:18 [PATCH mips-next 0/4] MIPS: vmlinux.lds.S sections fix & cleanup Alexander Lobakin
2021-01-05 0:09 99% ` Nathan Chancellor
2021-01-04 20:48 93% [PATCH] powerpc: Handle .text.{hot,unlikely}.* in linker script Nathan Chancellor
2021-01-04 20:48 94% ` Nathan Chancellor
2021-01-04 20:55 ` Sedat Dilek
2021-01-04 20:57 99% ` Nathan Chancellor
2021-01-04 20:57 99% ` Nathan Chancellor
2021-01-04 20:59 92% ` [PATCH v2] " Nathan Chancellor
2021-01-04 20:59 92% ` Nathan Chancellor
2021-01-16 18:44 ` Segher Boessenkool
2021-01-16 18:52 99% ` Nathan Chancellor
2021-01-16 18:52 99% ` Nathan Chancellor
2021-01-05 5:58 [PATCH] docs: remove mention of ENABLE_MUST_CHECK Miguel Ojeda
2021-01-05 22:25 99% ` Nathan Chancellor
2021-01-05 20:15 96% [PATCH] MIPS: lantiq: Explicitly compare LTQ_EBU_PCC_ISTAT against 0 Nathan Chancellor
2021-01-05 20:18 89% [PATCH] MIPS: Use address-of operator on section symbols Nathan Chancellor
2021-01-05 20:21 [PATCH] cifs: check pointer before freeing trix
2021-01-05 22:25 99% ` Nathan Chancellor
2021-01-05 20:34 99% [PATCH] MIPS: c-r4k: Fix section mismatch for loongson2_sc_init Nathan Chancellor
2021-01-06 20:04 drivers/soc/litex/litex_soc_ctrl.c:143:34: warning: unused variable 'litex_soc_ctrl_of_match' kernel test robot
2021-01-11 12:30 ` Stafford Horne
2021-01-11 16:43 99% ` Nathan Chancellor
2021-01-06 20:07 [PATCH v2 mips-next 0/4] MIPS: vmlinux.lds.S sections fix & cleanup Alexander Lobakin
2021-01-06 20:08 ` [PATCH v2 mips-next 1/4] MIPS: vmlinux.lds.S: add missing PAGE_ALIGNED_DATA() section Alexander Lobakin
2021-01-06 20:08 ` [PATCH v2 mips-next 3/4] MIPS: vmlinux.lds.S: catch bad .got, .plt and .rel.dyn at link time Alexander Lobakin
2021-01-06 20:23 99% ` Nathan Chancellor
2021-01-07 0:17 [PATCH] x86: Treat R_386_PLT32 as R_386_PC32 Fangrui Song
2021-01-07 2:31 99% ` Nathan Chancellor
2021-01-07 6:21 [PATCH] kasan: remove redundant config option Walter Wu
2021-01-07 21:00 99% ` Nathan Chancellor
2021-01-07 21:00 99% ` Nathan Chancellor
2021-01-07 21:00 99% ` Nathan Chancellor
2021-01-07 11:57 [PATCH] SPI: Fix distinct pointer types warning for ARCH=MIPS Yanteng Si
2021-01-07 17:30 99% ` Nathan Chancellor
2021-01-07 12:33 [PATCH v4 mips-next 0/7] MIPS: vmlinux.lds.S sections fixes & cleanup Alexander Lobakin
2021-01-07 12:34 ` [PATCH v4 mips-next 1/7] MIPS: vmlinux.lds.S: add missing PAGE_ALIGNED_DATA() section Alexander Lobakin
2021-01-07 12:34 ` [PATCH v4 mips-next 2/7] MIPS: vmlinux.lds.S: add ".gnu.attributes" to DISCARDS Alexander Lobakin
2021-01-08 21:12 99% ` Nathan Chancellor
2021-01-07 12:35 ` [PATCH v4 mips-next 3/7] MIPS: properly stop .eh_frame generation Alexander Lobakin
2021-01-08 21:16 99% ` Nathan Chancellor
2021-01-08 21:10 99% ` [PATCH v4 mips-next 1/7] MIPS: vmlinux.lds.S: add missing PAGE_ALIGNED_DATA() section Nathan Chancellor
2021-01-07 13:20 ` [PATCH v4 mips-next 4/7] MIPS: vmlinux.lds.S: catch bad .rel.dyn at link time Alexander Lobakin
2021-01-07 13:20 ` [PATCH v4 mips-next 5/7] MIPS: vmlinux.lds.S: explicitly declare .got table Alexander Lobakin
2021-01-08 21:17 99% ` Nathan Chancellor
2021-01-07 13:20 ` [PATCH v4 mips-next 6/7] vmlinux.lds.h: catch compound literals into data and BSS Alexander Lobakin
2021-01-08 21:19 99% ` Nathan Chancellor
2021-01-07 13:21 ` [PATCH v4 mips-next 7/7] MIPS: select ARCH_WANT_LD_ORPHAN_WARN Alexander Lobakin
2021-01-08 21:19 99% ` Nathan Chancellor
2021-01-08 21:17 99% ` [PATCH v4 mips-next 4/7] MIPS: vmlinux.lds.S: catch bad .rel.dyn at link time Nathan Chancellor
2021-01-07 22:34 [PATCH] x86: efi: avoid BUILD_BUG_ON() for non-constant p4d_index Arnd Bergmann
2021-01-07 22:42 99% ` Nathan Chancellor
2021-01-15 18:23 ` Borislav Petkov
2021-01-15 18:32 99% ` Nathan Chancellor
2021-01-08 4:09 [PATCH v3] kasan: remove redundant config option Walter Wu
2021-01-08 4:16 99% ` Nathan Chancellor
2021-01-08 4:16 99% ` Nathan Chancellor
2021-01-08 4:16 99% ` Nathan Chancellor
2021-01-11 17:49 ` Andrey Konovalov
2021-01-11 18:59 99% ` Nathan Chancellor
2021-01-11 18:59 99% ` Nathan Chancellor
2021-01-11 18:59 99% ` Nathan Chancellor
2021-01-11 18:59 99% ` Nathan Chancellor
2021-01-11 19:03 ` Andrey Konovalov
2021-01-11 19:11 99% ` Nathan Chancellor
2021-01-11 19:11 99% ` Nathan Chancellor
2021-01-11 19:11 99% ` Nathan Chancellor
2021-01-11 19:11 99% ` Nathan Chancellor
2021-01-10 11:53 [PATCH v5 mips-next 0/9] MIPS: vmlinux.lds.S sections fixes & cleanup Alexander Lobakin
2021-01-10 11:56 ` [PATCH v5 mips-next 1/9] MIPS: vmlinux.lds.S: add missing PAGE_ALIGNED_DATA() section Alexander Lobakin
2021-01-10 11:56 ` [PATCH v5 mips-next 5/9] MIPS: vmlinux.lds.S: explicitly catch .rel.dyn symbols Alexander Lobakin
2021-01-11 1:28 99% ` Nathan Chancellor
2021-01-10 11:56 ` [PATCH v5 mips-next 8/9] vmlinux.lds.h: catch UBSAN's "unnamed data" into data Alexander Lobakin
2021-01-11 2:05 99% ` Nathan Chancellor
2021-01-10 14:21 [PATCH mips-fixes] MIPS: relocatable: fix possible boot hangup with KASLR enabled Alexander Lobakin
2021-01-11 5:21 99% ` Nathan Chancellor
2021-01-10 21:57 [PATCH] block/rnbd-clt: improve find_or_create_sess() return check trix
2021-01-11 5:14 99% ` Nathan Chancellor
2021-01-11 8:18 [PATCH] pgo: add clang's Profile Guided Optimization infrastructure Bill Wendling
2021-01-11 8:39 ` Sedat Dilek
2021-01-11 9:17 ` Bill Wendling
2021-01-11 9:57 ` Sedat Dilek
2021-01-11 18:28 99% ` Nathan Chancellor
2021-01-11 21:04 96% ` Nathan Chancellor
2021-01-11 18:06 79% [PATCH] bpf: Hoise pahole version checks into Kconfig Nathan Chancellor
2021-01-11 19:19 ` Masahiro Yamada
2021-01-11 19:34 99% ` Nathan Chancellor
2021-01-11 19:50 ` Masahiro Yamada
2021-01-11 20:00 99% ` Nathan Chancellor
2021-01-11 21:24 ` Andrii Nakryiko
2021-01-13 22:38 ` Andrii Nakryiko
2021-01-13 23:07 99% ` Nathan Chancellor
2021-01-11 22:09 [PATCH] USB: serial: mos7720: improve handling of a kmalloc failure in read_mos_reg() trix
2021-01-11 22:31 99% ` Nathan Chancellor
2021-01-12 5:31 [PATCH v3] pgo: add clang's Profile Guided Optimization infrastructure Bill Wendling
2021-01-12 9:10 ` kernel test robot
2021-01-12 17:22 99% ` Nathan Chancellor
2021-01-13 6:19 ` [PATCH v4] " Bill Wendling
2021-01-13 20:55 97% ` Nathan Chancellor
2021-01-12 15:46 [PATCH] ARM: fix link warning with XIP + frame-pointer Arnd Bergmann
2021-01-12 16:27 99% ` Nathan Chancellor
2021-01-12 16:27 99% ` Nathan Chancellor
2021-01-12 19:12 98% [PATCH] dmaengine: qcom: Always inline gpi_update_reg Nathan Chancellor
2021-01-12 19:20 upstream build error (12) syzbot
2021-01-12 19:40 99% ` Nathan Chancellor
2021-01-12 20:32 99% ` Nathan Chancellor
2021-01-12 20:29 [PATCH] [v2] ubsan: disable unsigned-overflow check for i386 Arnd Bergmann
2021-01-13 0:05 99% ` Nathan Chancellor
2021-01-12 20:55 95% [PATCH] ubsan: Implement __ubsan_handle_alignment_assumption Nathan Chancellor
2021-01-12 21:15 ` Nick Desaulniers
2021-01-12 21:37 99% ` Nathan Chancellor
2021-01-12 21:53 ` Nick Desaulniers
2021-01-12 22:06 99% ` Nathan Chancellor
2021-01-13 0:12 93% ` [PATCH v2] " Nathan Chancellor
2021-01-13 0:39 ` [PATCH] " kernel test robot
2021-01-13 1:31 99% ` Nathan Chancellor
2021-01-12 22:48 [PATCH] compiler.h: Raise minimum version of GCC to 5.1 for arm64 Will Deacon
2021-01-12 23:06 99% ` Nathan Chancellor
2021-01-12 23:06 99% ` Nathan Chancellor
2021-01-13 0:32 [PATCH v4 0/3] Kbuild: DWARF v5 support Nick Desaulniers
2021-01-13 0:32 ` [PATCH v4 1/3] Remove $(cc-option,-gdwarf-4) dependency from CONFIG_DEBUG_INFO_DWARF4 Nick Desaulniers
2021-01-13 17:48 99% ` Nathan Chancellor
2021-01-13 0:32 ` [PATCH v4 2/3] Kbuild: make DWARF version a choice Nick Desaulniers
2021-01-13 17:51 99% ` Nathan Chancellor
2021-01-13 0:32 ` [PATCH v4 3/3] Kbuild: implement support for DWARF v5 Nick Desaulniers
2021-01-13 17:55 99% ` Nathan Chancellor
2021-01-13 9:04 [Qemu-devel][PATCH] x86/cpu: Use max host physical address if -cpu max option is applied Yang Weijiang
2021-01-24 21:08 99% ` Nathan Chancellor
2021-01-25 5:41 ` Yang Weijiang
2021-01-25 7:10 99% ` Nathan Chancellor
2021-01-25 10:42 ` Paolo Bonzini
2021-01-25 18:19 99% ` Nathan Chancellor
2021-01-13 18:57 47% Backports of eff8728fe69880d3f7983bec3fb6cea4c306261f for 4.4 to 5.4 Nathan Chancellor
2021-01-14 0:34 86% [PATCH] Documentation/llvm: Add a section about supported architectures Nathan Chancellor
2021-01-14 1:19 ` Nick Desaulniers
2021-01-14 2:05 ` Nick Desaulniers
2021-01-14 2:23 99% ` Nathan Chancellor
2021-01-14 0:40 99% [PATCH] MAINTAINERS: Add a couple more files to the Clang/LLVM section Nathan Chancellor
2021-01-14 17:16 99% ` [PATCH v2] MAINTAINERS: Add compiler-clang.h " Nathan Chancellor
2021-01-14 4:24 [PATCH v2] kbuild: check the minimum compiler version in Kconfig Masahiro Yamada
2021-01-14 7:54 ` Ilie Halip
2021-01-14 9:20 ` Masahiro Yamada
2021-01-14 16:49 99% ` Nathan Chancellor
2021-01-14 17:07 99% ` Nathan Chancellor
2021-01-14 17:34 86% [PATCH] MIPS: Compare __SYNC_loongson3_war against 0 Nathan Chancellor
2021-01-14 18:07 [PATCH v3] kbuild: check the minimum compiler version in Kconfig Masahiro Yamada
2021-01-14 18:23 99% ` Nathan Chancellor
2021-01-14 18:19 drivers/iio/accel/adxl372.c:949:3: warning: converting the result of '<<' to a boolean always evaluates to true kernel test robot
2021-01-14 18:24 99% ` Nathan Chancellor
2021-01-14 21:18 [PATCH] module: Ignore _GLOBAL_OFFSET_TABLE_ when warning for undefined symbols Jessica Yu
2021-01-15 19:52 ` [PATCH v3] " Fangrui Song
2021-01-15 19:55 99% ` Nathan Chancellor
2021-01-14 21:30 [PATCH] ubifs: replay: Fix high stack usage, again Arnd Bergmann
2021-01-15 18:38 99% ` Nathan Chancellor
2021-01-15 18:38 99% ` Nathan Chancellor
2021-01-14 22:24 [PATCH] objtool: Don't fail on missing symbol table Josh Poimboeuf
2021-01-14 22:32 99% ` Nathan Chancellor
2021-01-15 12:26 [PATCH 5.10 000/103] 5.10.8-rc1 review Greg Kroah-Hartman
2021-01-15 12:28 ` [PATCH 5.10 086/103] regmap: debugfs: Fix a memory leak when calling regmap_attach_dev Greg Kroah-Hartman
2021-01-15 20:18 ` Pavel Machek
2021-01-15 20:22 99% ` Nathan Chancellor
2021-01-15 12:27 [PATCH 5.4 00/62] 5.4.90-rc1 review Greg Kroah-Hartman
2021-01-15 12:28 ` [PATCH 5.4 40/62] spi: spi-geni-qcom: Fix geni_spi_isr() NULL dereference in timeout case Greg Kroah-Hartman
2021-01-16 18:48 99% ` Nathan Chancellor
2021-01-15 19:13 [PATCH] mips: vdso: fix DWARF2 warning Anders Roxell
2021-01-15 19:28 99% ` Nathan Chancellor
2021-01-15 19:26 91% [PATCH] MIPS: VDSO: Use CLANG_FLAGS instead of filtering out '--target=' Nathan Chancellor
2021-01-15 21:06 [PATCH v5 0/3] Kbuild: DWARF v5 support Nick Desaulniers
2021-01-15 21:06 ` [PATCH v5 2/3] Kbuild: make DWARF version a choice Nick Desaulniers
2021-01-20 20:40 99% ` Nathan Chancellor
2021-01-18 13:54 [STABLE BACKPORT 4.4.y, 4.9.y and 4.14.y] compiler.h: Raise minimum version of GCC to 5.1 for arm64 Will Deacon
2021-01-19 22:15 ` Nick Desaulniers
2021-01-19 23:29 99% ` Nathan Chancellor
2021-01-19 13:17 [PATCH v4 0/2] xor-neon: Remove GCC warn & pragmas Adrian Ratiu
2021-01-19 13:17 ` [PATCH v4 1/2] arm: lib: xor-neon: remove unnecessary GCC < 4.6 warning Adrian Ratiu
2021-01-19 21:54 97% ` Nathan Chancellor
2021-01-19 21:54 95% ` Nathan Chancellor
2021-01-21 5:27 [PATCH bpf-next v3] samples/bpf: Update build procedure for manually compiling LLVM and Clang Tiezhu Yang
2021-01-21 5:36 99% ` Nathan Chancellor
2021-01-21 8:08 ` Andrii Nakryiko
2021-01-21 14:23 99% ` Nathan Chancellor
2021-01-21 16:01 [PATCH] MAINTAINERS: adjust to clang-version.sh removal Lukas Bulwahn
2021-01-21 16:16 99% ` Nathan Chancellor
2021-01-21 16:16 99% ` Nathan Chancellor
2021-01-21 21:48 96% [PATCH] mm/zswap: Add return value in zswap_frontswap_load Nathan Chancellor
2021-01-22 1:41 arch/riscv/kernel/vdso/vdso-syms.S:2: Error: junk at end of line, first unrecognized character is `@' kernel test robot
2021-01-22 7:08 99% ` Nathan Chancellor
2021-01-22 14:11 [PATCH 4.14 00/50] 4.14.217-rc1 review Greg Kroah-Hartman
2021-01-22 15:02 ` Naresh Kamboju
2021-01-22 15:08 ` Greg Kroah-Hartman
2021-01-22 15:13 ` Naresh Kamboju
2021-01-22 15:36 ` Will Deacon
2021-01-22 15:42 99% ` Nathan Chancellor
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.