Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AMDGPU general protection fault with LTO #1374

Closed
aruhier opened this issue May 14, 2021 · 28 comments
Closed

AMDGPU general protection fault with LTO #1374

aruhier opened this issue May 14, 2021 · 28 comments
Assignees
Labels
[ARCH] x86_64 This bug impacts ARCH=x86_64 [BUG] linux A bug that should be fixed in the mainline kernel. [FEATURE] LTO Related to building the kernel with LLVM Link Time Optimization [FIXED][LINUX] 5.13 This bug was fixed in Linux 5.13

Comments

@aruhier
Copy link

aruhier commented May 14, 2021

Hello,
I'm using linux-xanmod 5.12, and tried clang with thinlto. It boots but when the amdgpu driver loads, I get a general protection fault. Same with full LTO. However it runs fine without LTO.

Xanmod is using a multigen LRU, but disabling it gives the same error (so I can try with a vanilla kernel, but I don't think that's the issue here).

Logs: 5.12.3-2.log
Config: kernel-config-5.12.3-x86_64.txt

CPU: Ryzen 5950x
GPU: AMD 6800xt
LLVM: 12
Distribution: Gentoo, using genkernel 4.2.1.

@nathanchance
Copy link
Member

Please do try a vanilla kernel first if it is not too difficult. Some custom kernels have a lot of out of tree patches, which can make things more complicated to debug.

@aruhier
Copy link
Author

aruhier commented May 14, 2021

Makes sense. I just did, and same error.

Logs: 5.12.3-vanilla.log
Config: kernel-config-5.12.3-vanilla-x86_64.txt
Build logs: genkernel-vanilla.log

@nathanchance
Copy link
Member

Your build command is a little odd:

COMMAND: nice -n15 make -j30 ARCH='x86' AS='/usr/lib/llvm/12/bin/llvm-as' AR='/usr/lib/llvm/12/bin/llvm-ar' CC='/usr/lib/llvm/12/bin/clang' LD='ld.lld' NM='/usr/lib/llvm/12/bin/llvm-nm' OBJCOPY='x86_64-pc-linux-gnu-objcopy' OBJDUMP='x86_64-pc-linux-gnu-objdump' READELF='x86_64-pc-linux-gnu-readelf' STRIP='x86_64-pc-linux-gnu-strip' HOSTAR='x86_64-pc-linux-gnu-ar' HOSTCC='x86_64-pc-linux-gnu-gcc' HOSTCXX='x86_64-pc-linux-gnu-g++' HOSTLD='ld.lld' bzImage

I do not see LLVM_IAS=1 anywhere, which is a little odd, since that is a dependency of HAS_LTO_CLANG. I guess genkernel does not have support for that explicitly but I am guessing you could add LLVM_IAS=1 to your MAKEOPTS. AS='/usr/lib/llvm/12/bin/llvm-as' does not work for selecting the integrated assembler for two reasons:

  1. $(AS) was removed in commit aa824e0c962b ("kbuild: remove AS variable").
  2. llvm-as converts LLVM IR to LLVM bitcode (.ll -> .bc), it will not work in this context.

I have no idea if this is actually related to your issue, just a general observation.

It may be worth reporting this to amd-gfx@lists.freedesktop.org to see if anyone else can reproduce it.

cc @samitolvanen

@nickdesaulniers
Copy link
Member

from the initial log:

general protection fault, maybe for address 0xffffb80d81b6b5d8: 0000 [#1] PREEMPT SMP NOPTI
RIP: 0010:dcn30_update_bw_bounding_box+0x33/0x530 [amdgpu]
RSP: 0018:ffffb80d81b6b5d8 EFLAGS: 00010296

so some bad stack access in dcn30_update_bw_bounding_box perhaps? @aruhier can you provide the output of llvm-objdump -Dr --disassemble-symbols=dcn30_update_bw_bounding_box vmlinux in another file attachment?

@nickdesaulniers nickdesaulniers added [BUG] Untriaged Something isn't working [FEATURE] LTO Related to building the kernel with LLVM Link Time Optimization [ARCH] x86_64 This bug impacts ARCH=x86_64 labels May 14, 2021
@aruhier
Copy link
Author

aruhier commented May 15, 2021

Your build command is a little odd:

COMMAND: nice -n15 make -j30 ARCH='x86' AS='/usr/lib/llvm/12/bin/llvm-as' AR='/usr/lib/llvm/12/bin/llvm-ar' CC='/usr/lib/llvm/12/bin/clang' LD='ld.lld' NM='/usr/lib/llvm/12/bin/llvm-nm' OBJCOPY='x86_64-pc-linux-gnu-objcopy' OBJDUMP='x86_64-pc-linux-gnu-objdump' READELF='x86_64-pc-linux-gnu-readelf' STRIP='x86_64-pc-linux-gnu-strip' HOSTAR='x86_64-pc-linux-gnu-ar' HOSTCC='x86_64-pc-linux-gnu-gcc' HOSTCXX='x86_64-pc-linux-gnu-g++' HOSTLD='ld.lld' bzImage

I do not see LLVM_IAS=1 anywhere, which is a little odd, since that is a dependency of HAS_LTO_CLANG. I guess genkernel does not have support for that explicitly but I am guessing you could add LLVM_IAS=1 to your MAKEOPTS. AS='/usr/lib/llvm/12/bin/llvm-as' does not work for selecting the integrated assembler for two reasons:

1. `$(AS)` was removed in commit [aa824e0c962b](https://git.kernel.org/linus/aa824e0c962b532d5073cbb41b2efcd6f5e72bae) ("kbuild: remove AS variable").

2. `llvm-as` converts LLVM IR to LLVM bitcode (`.ll` -> `.bc`), it will not work in this context.

I have no idea if this is actually related to your issue, just a general observation.

It may be worth reporting this to amd-gfx@lists.freedesktop.org to see if anyone else can reproduce it.

cc @samitolvanen

I do, I export LLVM=1 LLVM_IAS=1. Without it, I cannot enable LTO.

@aruhier
Copy link
Author

aruhier commented May 15, 2021

from the initial log:

general protection fault, maybe for address 0xffffb80d81b6b5d8: 0000 [#1] PREEMPT SMP NOPTI
RIP: 0010:dcn30_update_bw_bounding_box+0x33/0x530 [amdgpu]
RSP: 0018:ffffb80d81b6b5d8 EFLAGS: 00010296

so some bad stack access in dcn30_update_bw_bounding_box perhaps? @aruhier can you provide the output of llvm-objdump -Dr --disassemble-symbols=dcn30_update_bw_bounding_box vmlinux in another file attachment?

Sorry, I'm really not used to tweak with LLVM binaries, so I'm probably not going to be able to adapt too much the commands you give me.
So:

llvm-objdump -Dr --disassemble-symbols=dcn30_update_bw_bounding_box vmlinuz-5.12.3-x86_64
vmlinuz-5.12.3-x86_64:	file format coff-x86-64

llvm-objdump: warning: 'vmlinuz-5.12.3-x86_64': failed to disassemble missing symbol dcn30_update_bw_bounding_box

Which is probably not what you want. However I executed it on the amdgpu module: amdgpu.log

Edit: sorry, for that I had to recompile my kernel again, as I cleaned my modules (I won't again do it for the next steps of the debugging). To make your debug easier, here's the log of the panic of this kernel and module: 5.12.3-vanilla.log

@nickdesaulniers
Copy link
Member

RIP: 0010:dcn30_update_bw_bounding_box+0x33/0x530 [amdgpu]
00000000002efc90 <dcn30_update_bw_bounding_box>:

$ python -c 'print(hex(0x2efc90+0x33))'
0x2efcc3

2efcc3: 0f 29 84 24 f0 00 00 00 movaps %xmm0, 240(%rsp)
May 14 14:25:38 tour-anthony kernel: RSP: 0018:ffffb80d81b6b5d8 EFLAGS: 00010296

So again, we're using SSE/SIMD instructions that require 16B aligned operands. If the stack was 0xffffb80d81b6b5d8, then 0xffffb80d81b6b5d8 + 240 is 0xffffb80d81b6b6c8 which is obviously not a multiple of 16B. This mentions that movaps will GP fault on misaligned operands. So this is the same symptom as #735 .

So my next line of investigation is:

  • is the compilation unit that defines dcn30_update_bw_bounding_box not being compiled with correct flags, or
  • LTO is dropping the alignment flags (we've seen this kind of issues many times before with LTO).

It looks like dcn30_update_bw_bounding_box is defined in drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c.
drivers/gpu/drm/amd/display/dc/dcn30/Makefile looks correct on first glance, though it may be better to verify precisely how the compiler is invoked. In fact, I don't see how -mstack-alignment=8 gets encoded in IR; if so, that would be bad for LTO and a bug in LLVM.

@aruhier can you provide the output of your build invocation with V=1 added to the end of the command line args to the invocation of make? I'm pretty certain it's LTO dropping -mstack-alignment=8, but would like to confirm.

@samitolvanen
Copy link
Member

I'm pretty certain it's LTO dropping -mstack-alignment=8, but would like to confirm.

We do have this in arch/x86/Makefile:

ifdef CONFIG_LTO_CLANG
KBUILD_LDFLAGS  += -plugin-opt=-code-model=kernel \
                   -plugin-opt=-stack-alignment=$(if $(CONFIG_X86_32),4,8)
endif

Might not work correctly, of course.

@aruhier
Copy link
Author

aruhier commented May 17, 2021

Here is the full log of the build: genkernel-vanilla.log.gz

I looked at drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c, which seems to be built with -mstack-alignment=8:

/usr/lib/llvm/12/bin/clang -Wp,-MMD,drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/.dcn30_resource.o.d -nostdinc -isystem /usr/lib/llvm/12/bin/../../../../lib/clang/12.0.0/include -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -Qunused-arguments -fmacro-prefix-map=./= -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu89 -Werror=unknown-warning-option -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=none -m64 -mno-80387 -mstack-alignment=8 -mtune=generic -mno-red-zone -mcmodel=kernel -DCONFIG_X86_X32_ABI -Wno-sign-compare -fno-asynchronous-unwind-tables -mretpoline-external-thunk -fno-delete-null-pointer-checks -Wno-frame-address -Wno-address-of-packed-member -O2 -Wframe-larger-than=1024 -fstack-protector-strong -Wno-format-invalid-specifier -Wno-gnu -mno-global-merge -Wno-unused-const-variable -fomit-frame-pointer -fno-lto -flto=thin -fsplit-lto-unit -fvisibility=hidden -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-array-bounds -fno-strict-overflow -fno-stack-check -Werror=date-time -Werror=incompatible-pointer-types -Wno-initializer-overrides -Wno-format -Wno-sign-compare -Wno-format-zero-length -Wno-pointer-to-enum-cast -Wno-tautological-constant-out-of-range-compare -I./drivers/gpu/drm/amd/amdgpu/../pm/inc/ -I./drivers/gpu/drm/amd/amdgpu/../include/asic_reg -I./drivers/gpu/drm/amd/amdgpu/../include -I./drivers/gpu/drm/amd/amdgpu/../pm/swsmu -I./drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11 -I./drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu12 -I./drivers/gpu/drm/amd/amdgpu/../pm/powerplay -I./drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr -I./drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr -I./drivers/gpu/drm/amd/amdgpu/../display/dc/inc/ -I./drivers/gpu/drm/amd/amdgpu/../display/dc/inc/hw -I./drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr -I./drivers/gpu/drm/amd/amdgpu/../display/modules/inc -I./drivers/gpu/drm/amd/amdgpu/../display/modules/freesync -I./drivers/gpu/drm/amd/amdgpu/../display/modules/color -I./drivers/gpu/drm/amd/amdgpu/../display/modules/info_packet -I./drivers/gpu/drm/amd/amdgpu/../display/modules/power -I./drivers/gpu/drm/amd/amdgpu/../display/dmub/inc -I./drivers/gpu/drm/amd/amdgpu/../display/modules/hdcp -DBUILD_FEATURE_TIMING_SYNC=0 -I./drivers/gpu/drm/amd/amdgpu/../display/dc -I./drivers/gpu/drm/amd/amdgpu/../include/asic_reg -I./drivers/gpu/drm/amd/amdgpu/../include -I./drivers/gpu/drm/amd/amdgpu/../amdgpu -I./drivers/gpu/drm/amd/amdgpu/../pm/inc -I./drivers/gpu/drm/amd/amdgpu/../acp/include -I./drivers/gpu/drm/amd/amdgpu/../display -I./drivers/gpu/drm/amd/amdgpu/../display/include -I./drivers/gpu/drm/amd/amdgpu/../display/dc -I./drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm -I./drivers/gpu/drm/amd/amdgpu/../amdkfd -msse -msse2 -DMODULE -DKBUILD_BASENAME='"dcn30_resource"' -DKBUILD_MODNAME='"amdgpu"' -D__KBUILD_MODNAME=kmod_amdgpu -c -o drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.o drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c

@nickdesaulniers
Copy link
Member

nickdesaulniers commented May 17, 2021

@samitolvanen is KBUILD_LDFLAGS used for modules, or just vmlinux?

I don't think so, from the provided log:

ld.lld -m elf_x86_64 --thinlto-cache-dir=.thinlto-cache -mllvm -import-instr-limit=5   -r -o drivers/gpu/drm/amd/amdgpu/amdgpu.lto.o  --whole-archive drivers/gpu/drm/amd/amdgpu/amdgpu.o
ld.lld -r -m elf_x86_64 --thinlto-cache-dir=.thinlto-cache -mllvm -import-instr-limit=5 --build-id=sha1  -T scripts/module.lds -o drivers/gpu/drm/amd/amdgpu/amdgpu.ko drivers/gpu/drm/amd/amdgpu/amdgpu.lto.o drivers/gpu/drm/amd/amdgpu/amdgpu.mod.o

I looked at drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c, which seems to be built with -mstack-alignment=8:

Indeed.

@nathanchance
Copy link
Member

@samitolvanen
Copy link
Member

The linker flags used for .lto.o come from ld_flags in scripts/Makefile.lib, which defines it as:

ld_flags       = $(KBUILD_LDFLAGS) $(ldflags-y) $(LDFLAGS_$(@F))

Based on the log, it definitely looks like something isn't defined correctly there.

@nathanchance
Copy link
Member

nathanchance commented May 17, 2021

KBUILD_LDFLAGS is getting clobbered in arch/x86/Makefile with :=

...

ifdef CONFIG_LTO_CLANG
KBUILD_LDFLAGS	+= -plugin-opt=-code-model=kernel \
		   -plugin-opt=-stack-alignment=$(if $(CONFIG_X86_32),4,8)
endif

...

KBUILD_LDFLAGS := -m elf_$(UTS_MACHINE)

...

I'll draft up a patch and have @aruhier test it before sending it along.

@aruhier
Copy link
Author

aruhier commented May 18, 2021

Sure, thanks!

@nickdesaulniers
Copy link
Member

good find, looks like the review of b33fff0 (v5.12-rc1) missed that, from 587af64 (v5.9-rc1). Pretty tricky thing to catch anyways.

@nickdesaulniers nickdesaulniers added [BUG] linux A bug that should be fixed in the mainline kernel. and removed [BUG] Untriaged Something isn't working labels May 18, 2021
@nathanchance
Copy link
Member

@aruhier please apply this and see if resolves your issue!

https://gist.github.com/nathanchance/f4d3f4ef1b523b60e9bd3359ccb1a57c/raw/257b21295510cc00b5c7dbed02c9c79930a29304/0001-x86-Fix-location-of-plugin-opt-flags.patch

Additionally, please provide me with an email address if you would like a proper Reported-by tag :)

@nickdesaulniers @samitolvanen if you have any suggestions for the wording, let me know.

@nathanchance
Copy link
Member

I will also stick a Cc: stable@vger.kernel.org on there since LTO landed in 5.12.

@aruhier
Copy link
Author

aruhier commented May 18, 2021

I'll test it in ~12h, thanks a lot for this patch!
For the email address, you can use the one from my github profile.

@samitolvanen
Copy link
Member

The patch looks good to me, but would it be better to just change the := to += to avoid similar issues in future? There should be no need to clear KBUILD_LDFLAGS here.

@nathanchance
Copy link
Member

I'll test it in ~12h, thanks a lot for this patch!

Thank you for reporting it :)

For the email address, you can use the one from my github profile.

Sounds good, I have updated the patch now. Once you test it and confirm it works, I will add a Tested-by: tag as well.

@nickdesaulniers
Copy link
Member

nickdesaulniers commented May 18, 2021

yeah, resetting KBUILD_LDFLAGS seems like a mistake TBH; not sure if that changes the Fixes tag.

@nathanchance
Copy link
Member

The patch looks good to me, but would it be better to just change the := to += to avoid similar issues in future? There should be no need to clear KBUILD_LDFLAGS here.

Sure, I can change the := at the same time as moving the flags down. 587af64 moved all of the LDFLAGS to the same area so I figured that is probably worth keeping. The main Makefile provides an empty KBUILD_LDFLAGS so := is not necessary (same thing with LDFLAGS_vmlinux but that probably warrants a follow up patch).

@nathanchance
Copy link
Member

@aruhier
Copy link
Author

aruhier commented May 18, 2021

Patch has been updated: https://gist.githubusercontent.com/nathanchance/f4d3f4ef1b523b60e9bd3359ccb1a57c/raw/248b039a9fa4cf969b33f6048c7e761af9dca683/0001-x86-Fix-location-of-plugin-opt-flags.patch

Built today on 5.12.4, it runs great 🎉
Thanks again!

PS: I don't know if you want to close this issue once the patch is sent or not, so I let it open but feel free to close it.

@nathanchance
Copy link
Member

Patch submitted: https://lore.kernel.org/r/20210518190106.60935-1-nathan@kernel.org/

PS: I don't know if you want to close this issue once the patch is sent or not, so I let it open but feel free to close it.

We will close the issue when this patch is merged into Linus's tree. Thanks again for the report and testing!

@nathanchance
Copy link
Member

@nathanchance nathanchance added [PATCH] Accepted A submitted patch has been accepted upstream and removed [PATCH] Submitted A patch has been submitted for review labels May 19, 2021
@nathanchance
Copy link
Member

Merged into mainline: https://git.kernel.org/torvalds/c/0024430e920f

This should be backported to stable automatically.

@nathanchance nathanchance added [FIXED][LINUX] 5.13 This bug was fixed in Linux 5.13 and removed [PATCH] Accepted A submitted patch has been accepted upstream labels May 23, 2021
roxell pushed a commit to roxell/linux that referenced this issue May 24, 2021
Commit b33fff0 ("x86, build: allow LTO to be selected") added a
couple of '-plugin-opt=' flags to KBUILD_LDFLAGS because the code model
and stack alignment are not stored in LLVM bitcode. However, these flags
were added to KBUILD_LDFLAGS prior to the emulation flag assignment,
which uses ':=', so they were overwritten and never added to $(LD)
invocations. The absence of these flags caused misalignment issues in
the AMDGPU driver when compiling with CONFIG_LTO_CLANG, resulting in
general protection faults.

Shuffle the assignment below the initial one so that the flags are
properly passed along and all of the linker flags stay together.

At the same time, avoid any future issues with clobbering flags by
changing the emulation flag assignment to '+=' since KBUILD_LDFLAGS is
already defined with ':=' in the main Makefile before being exported for
modification here as a result of commit ce99d0b ("kbuild: clear
LDFLAGS in the top Makefile").

Cc: stable@vger.kernel.org
Fixes: b33fff0 ("x86, build: allow LTO to be selected")
Link: ClangBuiltLinux#1374
Reported-by: Anthony Ruhier <aruhier@mailbox.org>
Tested-by: Anthony Ruhier <aruhier@mailbox.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210518190106.60935-1-nathan@kernel.org
@FireBurn
Copy link

woodsts pushed a commit to woodsts/linux-stable that referenced this issue May 26, 2021
commit 0024430 upstream.

Commit b33fff0 ("x86, build: allow LTO to be selected") added a
couple of '-plugin-opt=' flags to KBUILD_LDFLAGS because the code model
and stack alignment are not stored in LLVM bitcode.

However, these flags were added to KBUILD_LDFLAGS prior to the
emulation flag assignment, which uses ':=', so they were overwritten
and never added to $(LD) invocations.

The absence of these flags caused misalignment issues in the
AMDGPU driver when compiling with CONFIG_LTO_CLANG, resulting in
general protection faults.

Shuffle the assignment below the initial one so that the flags are
properly passed along and all of the linker flags stay together.

At the same time, avoid any future issues with clobbering flags by
changing the emulation flag assignment to '+=' since KBUILD_LDFLAGS is
already defined with ':=' in the main Makefile before being exported for
modification here as a result of commit:

  ce99d0b ("kbuild: clear LDFLAGS in the top Makefile")

Fixes: b33fff0 ("x86, build: allow LTO to be selected")
Reported-by: Anthony Ruhier <aruhier@mailbox.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Tested-by: Anthony Ruhier <aruhier@mailbox.org>
Cc: stable@vger.kernel.org
Link: ClangBuiltLinux/linux#1374
Link: https://lore.kernel.org/r/20210518190106.60935-1-nathan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
peyo-hd pushed a commit to peyo-hd/kernel_arpi that referenced this issue Jun 12, 2021
Commit b33fff0 ("x86, build: allow LTO to be selected") added a
couple of '-plugin-opt=' flags to KBUILD_LDFLAGS because the code model
and stack alignment are not stored in LLVM bitcode.

However, these flags were added to KBUILD_LDFLAGS prior to the
emulation flag assignment, which uses ':=', so they were overwritten
and never added to $(LD) invocations.

The absence of these flags caused misalignment issues in the
AMDGPU driver when compiling with CONFIG_LTO_CLANG, resulting in
general protection faults.

Shuffle the assignment below the initial one so that the flags are
properly passed along and all of the linker flags stay together.

At the same time, avoid any future issues with clobbering flags by
changing the emulation flag assignment to '+=' since KBUILD_LDFLAGS is
already defined with ':=' in the main Makefile before being exported for
modification here as a result of commit:

  ce99d0b ("kbuild: clear LDFLAGS in the top Makefile")

Fixes: b33fff0 ("x86, build: allow LTO to be selected")
Reported-by: Anthony Ruhier <aruhier@mailbox.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Tested-by: Anthony Ruhier <aruhier@mailbox.org>
Cc: stable@vger.kernel.org
Link: ClangBuiltLinux/linux#1374
Link: https://lore.kernel.org/r/20210518190106.60935-1-nathan@kernel.org
(cherry picked from commit 0024430)
Bug: 187129171
Signed-off-by: Connor O'Brien <connoro@google.com>
Change-Id: I9f9c056829483f341251cc7407d0029c05e8b503
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[ARCH] x86_64 This bug impacts ARCH=x86_64 [BUG] linux A bug that should be fixed in the mainline kernel. [FEATURE] LTO Related to building the kernel with LLVM Link Time Optimization [FIXED][LINUX] 5.13 This bug was fixed in Linux 5.13
Projects
None yet
Development

No branches or pull requests

5 participants