So the week started so slow due to the holidays that I thought I might
not have any reason to do an rc2 at all, but by the end of the week I
did end up getting a smattering of pull requests, so here we are. It's
tiny, even smaller than usual for an rc2, and honestly, I'd expect
that trend to continue for rc3. A lot of people are still off for
another week on a well-deserved winter holiday, and so I suspect
things will continue to be fairly quiet.
Anyway, last week saw mainly some nvme fixes, some i915 drm work, and
some kvm fixes (and kvm testing fixes). See below for the full
shortlog, and if you're not still in a food coma from the holidays,
please do give this all a good testing.
Linus
---
Adam Vodopjan (1):
ata: ahci: Fix PCS quirk application for suspend
Adamos Ttofari (1):
KVM: x86: ioapic: Fix level-triggered EOI and userspace I/OAPIC
reconfigure race
Adrian Freund (1):
ACPI: resource: do IRQ override on Lenovo 14ALC7
Andrzej Hajda (1):
drm/i915: fix TLB invalidation for Gen12.50 video and compute engines
Arnd Bergmann (1):
x86/calldepth: Fix incorrect init section references
Artem Egorkine (2):
ALSA: line6: correct midi status byte when receiving data from podxt
ALSA: line6: fix stack overflow in line6_midi_transmit
Bhaskar Chowdhury (1):
kconfig: Add static text for search information in help menu
Chengming Zhou (1):
perf/core: Fix cgroup events tracking
Chris Chiu (1):
ALSA: hda/realtek: Apply dual codec fixup for Dell Latitude laptops
Christoph Hellwig (9):
nvme: fix setting the queue depth in nvme_alloc_io_tag_set
nvme-pci: update sqsize when adjusting the queue depth
docs, nvme: add a feature and quirk policy document
nvme: fix the NVME_CMD_EFFECTS_CSE_MASK definition
nvmet: use NVME_CMD_EFFECTS_CSUPP instead of open coding it
nvmet: set the LBCC bit for commands that modify data
nvmet: don't defer passthrough commands with trivial effects to
the workqueue
nvme: also return I/O command effects from nvme_command_effects
nvme: consult the CSE log page for unprivileged passthrough
Colin Ian King (1):
perf/x86/amd: fix potential integer overflow on shift of a int
David Woodhouse (3):
KVM: x86/xen: Use kvm_read_guest_virt() instead of open-coding it badly
KVM: x86/xen: Add KVM_XEN_INVALID_GPA and KVM_XEN_INVALID_GFN to uapi
KVM: x86/xen: Documentation updates and clarifications
Erik Schumacher (1):
ACPI: resource: do IRQ override on XMG Core 15
Hans de Goede (2):
ACPI: resource: Add Asus ExpertBook B2502 to Asus quirks
ACPI: video: Fix Apple GMUX backlight detection
Jani Nikula (2):
drm/i915/dsi: add support for ICL+ native MIPI GPIO sequence
drm/i915/dsi: fix MIPI_BKLT_EN_1 native GPIO index
Jens Axboe (3):
io_uring: finish waiting before flushing overflow entries
io_uring/cancel: re-grab ctx mutex after finishing wait
io_uring: check for valid register opcode earlier
John Harrison (1):
drm/i915/uc: Fix two issues with over-size firmware files
Jun ASAKA (1):
kbuild: add a missing line for help message
Keith Busch (2):
nvme-pci: fix mempool alloc size
nvme-pci: fix page size checks
Klaus Jensen (1):
nvme-pci: fix doorbell buffer value endianness
Lai Jiangshan (2):
kvm: Remove the unused macro KVM_MMU_READ_{,UN}LOCK()
kvm: x86/mmu: Remove duplicated "be split" in spte.h
Like Xu (1):
KVM: x86/pmu: Prevent zero period event from being repeatedly released
Linus Torvalds (1):
Linux 6.2-rc2
Lucas De Marchi (1):
drm/i915: Remove __maybe_unused from mtl_info
Lukas Bulwahn (1):
MAINTAINERS: adjust entry after renaming the vmx hyperv files
Mario Limonciello (5):
ACPI: video: Allow GPU drivers to report no panels
drm/amd/display: Report to ACPI video if no panels were found
ACPI: video: Don't enable fallback path for creating ACPI
backlight by default
ACPI: x86: s2idle: Force AMD GUID/_REV 2 on HP Elitebook 865
ACPI: x86: s2idle: Stop using AMD specific codepath for Rembrandt+
Masahiro Yamada (5):
arch: fix broken BuildID for arm64 and riscv
.gitignore: ignore *.rpm
kbuild: rpm-pkg: add libelf-devel as alternative for BuildRequires
kbuild: sort single-targets alphabetically again
fixdep: remove unneeded <stdarg.h> inclusion
Masami Hiramatsu (Google) (2):
x86/kprobes: Fix kprobes instruction boudary check with CONFIG_RETHUNK
x86/kprobes: Fix optprobe optimization check with CONFIG_RETHUNK
Mathieu Desnoyers (1):
futex: Fix futex_waitv() hrtimer debug object leak on kcalloc error
Matthew Auld (1):
drm/i915: improve the catch-all evict to handle lock contention
Mel Gorman (1):
rtmutex: Add acquire semantics for rtmutex lock acquisition slow path
Michal Luczaj (2):
KVM: x86/xen: Fix memory leak in kvm_xen_write_hypercall_page()
KVM: x86/xen: Simplify eventfd IOCTLs
Namhyung Kim (1):
perf/core: Call LSM hook after copying perf_event_attr
Oliver Upton (2):
KVM: arm64: selftests: Don't identity map the ucall MMIO hole
KVM: selftests: Mark correct page as mapped in virt_map()
Paolo Bonzini (5):
KVM: selftests: document the default implementation of
vm_vaddr_populate_bitmap
KVM: x86/xen: Fix SRCU/RCU usage in readers of evtchn_ports
KVM: x86: fix deadlock for KVM_XEN_EVTCHN_RESET
Documentation: kvm: clarify SRCU locking order
KVM: selftests: restore special vmmcall code layout needed by the harness
Peng Hao (1):
KVM: x86: Simplify kvm_apic_hw_enabled
Peter Zijlstra (1):
perf: Fix use-after-free in error path
Ravi Bangoria (1):
perf core: Return error pointer if inherit_event() fails to find pmu_ctx
Sagi Grimberg (1):
nvme-auth: fix smatch warning complaints
Samuel Holland (1):
kbuild: Fix running modpost with musl libc
Sean Christopherson (22):
KVM: x86: Sanity check inputs to kvm_handle_memory_failure()
KVM: selftests: Zero out valid_bank_mask for "all" case in
Hyper-V IPI test
KVM: nVMX: Document that ignoring memory failures for VMCLEAR is
deliberate
KVM: nVMX: Properly expose ENABLE_USR_WAIT_PAUSE control to L1
KVM: nVMX: Don't stuff secondary execution control if it's not supported
KVM: x86/mmu: Don't attempt to map leaf if target TDP MMU SPTE is frozen
KVM: x86/mmu: Map TDP MMU leaf SPTE iff target level is reached
KVM: x86/mmu: Re-check under lock that TDP MMU SP hugepage is disallowed
KVM: x86/mmu: Don't install TDP MMU SPTE if SP has unexpected level
KVM: selftests: Define literal to asm constraint in aarch64 as
unsigned long
KVM: selftests: Delete dead code in x86_64/vmx_tsc_adjust_test.c
KVM: selftests: Fix divide-by-zero bug in memslot_perf_test
KVM: selftests: Use pattern matching in .gitignore
KVM: selftests: Fix a typo in x86-64's kvm_get_cpu_address_width()
KVM: selftests: Rename UNAME_M to ARCH_DIR, fill explicitly for x86
KVM: selftests: Use proper function prototypes in probing code
KVM: selftests: Probe -no-pie with actual CFLAGS used to compile
KVM: selftests: Explicitly disable builtins for mem*() overrides
KVM: selftests: Include lib.mk before consuming $(CC)
KVM: selftests: Disable "gnu-variable-sized-type-not-at-end" warning
KVM: selftests: Use magic value to signal ucall_alloc() failure
KVM: Delete extra block of "};" in the KVM API documentation
Stefan Metzmacher (1):
uapi:io_uring.h: allow linux/time_types.h to be skipped
Takashi Iwai (1):
ALSA: hda/hdmi: Static PCM mapping again with AMD HDMI codecs
Vitaly Kuznetsov (1):
KVM: x86: hyper-v: Fix 'using uninitialized value' Coverity warning
Yanjun Zhang (1):
nvme: fix multipath crash caused by flush request when blktrace is enabled
YoungJun.park (1):
kunit: alloc_string_stream_fragment error handling bug fix
Yu Kuai (1):
block, bfq: fix uaf for bfqq in bfq_exit_icq_bfqq
Below is the list of build error/warning regressions/improvements in
v6.2-rc2[1] compared to v6.1[2].
Summarized:
- build errors: +10/-13
- build warnings: +13/-10
JFYI, when comparing v6.2-rc2[1] to v6.2-rc1[3], the summaries are:
- build errors: +0/-1
- build warnings: +0/-0
Happy fixing! ;-)
Thanks to the linux-next team for providing the build service.
[1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/88603b6dc419445847923fcb7fe5080067a30f98/ (all 152 configs)
[2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/830b3c68c1fb1e9176028d02ef86f3cf76aa2476/ (all 152 configs)
[3] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/1b929c02afd37871d5afb9d498426f83432e71c2/ (all 152 configs)
*** ERRORS ***
10 error regressions:
+ /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c: error: the frame size of 2224 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]: => 7082:1
+ /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/display_mode_vba_314.c: error: the frame size of 2208 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]: => 7127:1
+ /kisskb/src/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c: error: array subscript 2 is above array bounds of 'u32[2]' {aka 'unsigned int[2]'} [-Werror=array-bounds]: => 641:28
+ /kisskb/src/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c: error: array subscript 3 is above array bounds of 'u32[2]' {aka 'unsigned int[2]'} [-Werror=array-bounds]: => 641:28
+ /kisskb/src/include/linux/bitfield.h: error: call to '__field_overflow' declared with attribute error: value doesn't fit into mask: => 151:3
+ /kisskb/src/include/linux/compiler_types.h: error: call to '__compiletime_assert_263' declared with attribute error: Unsupported access size for {READ,WRITE}_ONCE().: => 358:45
+ /kisskb/src/include/linux/fortify-string.h: error: '__builtin_memcpy' offset [0, 127] is out of the bounds [0, 0] [-Werror=array-bounds]: => 57:33
+ /kisskb/src/include/linux/fortify-string.h: error: '__builtin_memset' pointer overflow between offset [28, 898293814] and size [-898293787, -1] [-Werror=array-bounds]: => 59:33
+ /kisskb/src/kernel/kcsan/kcsan_test.c: error: the frame size of 1680 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 257:1
+ {standard input}: Error: unknown pseudo-op: `.cfi_def_c': => 1718
13 error improvements:
- /kisskb/src/arch/sh/include/asm/io.h: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]: 239:34 =>
- /kisskb/src/drivers/infiniband/hw/qib/qib_wc_x86_64.c: error: 'X86_VENDOR_AMD' undeclared (first use in this function): 149:37 =>
- /kisskb/src/drivers/infiniband/hw/qib/qib_wc_x86_64.c: error: 'struct cpuinfo_um' has no member named 'x86_vendor': 149:22 =>
- /kisskb/src/drivers/infiniband/hw/qib/qib_wc_x86_64.c: error: control reaches end of non-void function [-Werror=return-type]: 150:1 =>
- /kisskb/src/drivers/infiniband/sw/rdmavt/qp.c: error: 'struct cpuinfo_um' has no member named 'x86_cache_size': 88:22 =>
- /kisskb/src/drivers/infiniband/sw/rdmavt/qp.c: error: control reaches end of non-void function [-Werror=return-type]: 89:1 =>
- /kisskb/src/drivers/infiniband/sw/rdmavt/qp.c: error: implicit declaration of function '__copy_user_nocache' [-Werror=implicit-function-declaration]: 100:2 =>
- /kisskb/src/drivers/net/ethernet/marvell/prestera/prestera_flower.c: error: 'rule' is used uninitialized [-Werror=uninitialized]: 480:34 =>
- {standard input}: Error: displacement to undefined symbol .L377 overflows 12-bit field: 2286 =>
- {standard input}: Error: displacement to undefined symbol .L378 overflows 8-bit field : 2302 =>
- {standard input}: Error: displacement to undefined symbol .L382 overflows 8-bit field : 2213 =>
- {standard input}: Error: pcrel too far: 2274, 2232, 2204, 2217, 2293, 2248, 2206, 2229, 2261, 2221, 2215, 2247, 2262, 2216, 2209, 2249, 2231, 2259 =>
- {standard input}: Error: unknown pseudo-op: `.l': 2305 =>
*** WARNINGS ***
13 warning regressions:
+ modpost: WARNING: modpost: "__ndelay" [drivers/gpio/gpio-latch.ko] has no CRC!: => N/A
+ modpost: WARNING: modpost: "__udelay" [drivers/iio/adc/max11410.ko] has no CRC!: => N/A
+ modpost: WARNING: modpost: "__udelay" [drivers/input/keyboard/tegra-kbc.ko] has no CRC!: => N/A
+ modpost: WARNING: modpost: "__udelay" [drivers/mfd/axp20x.ko] has no CRC!: => N/A
+ modpost: WARNING: modpost: "__udelay" [drivers/mmc/host/sunplus-mmc.ko] has no CRC!: => N/A
+ modpost: WARNING: modpost: "__udelay" [drivers/net/ethernet/renesas/rswitch_drv.ko] has no CRC!: => N/A
+ modpost: WARNING: modpost: "__udelay" [drivers/net/wireless/mediatek/mt76/mt7996/mt7996e.ko] has no CRC!: => N/A
+ modpost: WARNING: modpost: "__udelay" [drivers/net/wireless/realtek/rtw89/rtw89_8852b.ko] has no CRC!: => N/A
+ modpost: WARNING: modpost: "__udelay" [drivers/phy/renesas/r8a779f0-ether-serdes.ko] has no CRC!: => N/A
+ modpost: WARNING: modpost: "__udelay" [drivers/ptp/ptp_idt82p33.ko] has no CRC!: => N/A
+ modpost: WARNING: modpost: "__udelay" [drivers/usb/fotg210/fotg210.ko] has no CRC!: => N/A
+ modpost: WARNING: modpost: "__udelay" [fs/xfs/xfs.ko] has no CRC!: => N/A
+ modpost: WARNING: modpost: "empty_zero_page" [net/rxrpc/rxperf.ko] has no CRC!: => N/A
10 warning improvements:
- modpost: WARNING: modpost: "__ashldi3" [lib/zstd/zstd_compress.ko] has no CRC!: N/A =>
- modpost: WARNING: modpost: "__udelay" [drivers/net/can/pch_can.ko] has no CRC!: N/A =>
- modpost: WARNING: modpost: "__udelay" [drivers/net/ethernet/fealnx.ko] has no CRC!: N/A =>
- modpost: WARNING: modpost: "__udelay" [drivers/net/ethernet/smsc/smc911x.ko] has no CRC!: N/A =>
- modpost: WARNING: modpost: "__udelay" [drivers/net/pcs/pcs-altera-tse.ko] has no CRC!: N/A =>
- modpost: WARNING: modpost: "__udelay" [drivers/usb/host/fotg210-hcd.ko] has no CRC!: N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o: section mismatch in reference: qed_mfw_ext_maps (section: .data) -> qed_mfw_legacy_bb_100g (section: .init.rodata): N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o: section mismatch in reference: qed_mfw_legacy_maps (section: .data) -> qed_mfw_legacy_bb_100g (section: .init.rodata): N/A =>
- modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o: section mismatch in reference: qede_forced_speed_maps (section: .data) -> qede_forced_speed_100000 (section: .init.rodata): N/A =>
- modpost: WARNING: modpost: vmlinux.o: section mismatch in reference: __trace_event_discard_commit (section: .text.unlikely) -> initcall_level_names (section: .init.data): N/A =>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Sun, Jan 01, 2023 at 02:01:04PM -0800, Linus Torvalds wrote:
> So the week started so slow due to the holidays that I thought I might
> not have any reason to do an rc2 at all, but by the end of the week I
> did end up getting a smattering of pull requests, so here we are. It's
> tiny, even smaller than usual for an rc2, and honestly, I'd expect
> that trend to continue for rc3. A lot of people are still off for
> another week on a well-deserved winter holiday, and so I suspect
> things will continue to be fairly quiet.
>
> Anyway, last week saw mainly some nvme fixes, some i915 drm work, and
> some kvm fixes (and kvm testing fixes). See below for the full
> shortlog, and if you're not still in a food coma from the holidays,
> please do give this all a good testing.
>
Build results:
total: 155 pass: 151 fail: 4
Failed builds:
powerpc:allmodconfig
sh:defconfig
sh:shx3_defconfig
xtensa:allmodconfig
Qemu test results:
total: 500 pass: 498 fail: 2
Failed tests:
arm:xilinx-zynq-a9:multi_v7_defconfig:usb0:mem128:net,default:zynq-zc702:rootfs
arm:xilinx-zynq-a9:multi_v7_defconfig:usb0:mem128:zynq-zed:rootfs
Same as last week, so I won't go into details for the above failures.
One detail to mention, though, is that sh:rts7751r2dplus_defconfig
no longer builds with older versions of binutils (2.32). Trying to
do so results in the following build error.
`.exit.text' referenced in section `__bug_table' of drivers/char/hw_random/core.o:
defined in discarded section `.exit.text' of drivers/char/hw_random/core.o
To make this more interesting, kernels older than v5.10 do not boot
(at least not in qemu) when images are built with binutils 2.27 or newer.
That is why I had used binutils 2.32 in the first place.
I didn't bother tracking this down but switched to binutils 2.39 when
building v5.10+ images.
Guenter
[ Adding Jason in case he has any ideas, and seeing if sh maintainer
emails are still valid, and Arnd in case they aren't ]
On Mon, Jan 2, 2023 at 2:57 PM Guenter Roeck <[email protected]> wrote:
>
> One detail to mention, though, is that sh:rts7751r2dplus_defconfig
> no longer builds with older versions of binutils (2.32). Trying to
> do so results in the following build error.
>
> `.exit.text' referenced in section `__bug_table' of drivers/char/hw_random/core.o:
> defined in discarded section `.exit.text' of drivers/char/hw_random/core.o
>
> To make this more interesting, kernels older than v5.10 do not boot
> (at least not in qemu) when images are built with binutils 2.27 or newer.
> That is why I had used binutils 2.32 in the first place.
>
> I didn't bother tracking this down but switched to binutils 2.39 when
> building v5.10+ images.
I have to admit that I can't really see myself carding deeply about
SH, but somebody else may. I don't think I've gotten an arch/sh pull
in a couple of years.
That said, I also don't see anything wrong with the arch/sh version of
BUG() and friends, so I don't see why this would hit arch/sh and not
somebody else.
I _assume_ it is the BUG_ON() in hwrng_modexit() that triggers this:
static void __exit hwrng_modexit(void)
{
mutex_lock(&rng_mutex);
BUG_ON(current_rng);
kfree(rng_buffer);
...
but again, I don't see what's special about sh here apart from maybe
"not well maintained binutils support".
Does removing the BUG_ON() fix the build?
None of this is at all new, though. Funky.
Linus
On Mon, Jan 02, 2023 at 04:21:41PM -0800, Linus Torvalds wrote:
> [ Adding Jason in case he has any ideas, and seeing if sh maintainer
> emails are still valid, and Arnd in case they aren't ]
>
> On Mon, Jan 2, 2023 at 2:57 PM Guenter Roeck <[email protected]> wrote:
> >
> > One detail to mention, though, is that sh:rts7751r2dplus_defconfig
> > no longer builds with older versions of binutils (2.32). Trying to
> > do so results in the following build error.
> >
> > `.exit.text' referenced in section `__bug_table' of drivers/char/hw_random/core.o:
> > defined in discarded section `.exit.text' of drivers/char/hw_random/core.o
> >
> > To make this more interesting, kernels older than v5.10 do not boot
> > (at least not in qemu) when images are built with binutils 2.27 or newer.
> > That is why I had used binutils 2.32 in the first place.
> >
> > I didn't bother tracking this down but switched to binutils 2.39 when
> > building v5.10+ images.
>
> I have to admit that I can't really see myself carding deeply about
> SH, but somebody else may. I don't think I've gotten an arch/sh pull
> in a couple of years.
>
> That said, I also don't see anything wrong with the arch/sh version of
> BUG() and friends, so I don't see why this would hit arch/sh and not
> somebody else.
>
> I _assume_ it is the BUG_ON() in hwrng_modexit() that triggers this:
>
> static void __exit hwrng_modexit(void)
> {
> mutex_lock(&rng_mutex);
> BUG_ON(current_rng);
> kfree(rng_buffer);
> ...
>
> but again, I don't see what's special about sh here apart from maybe
> "not well maintained binutils support".
>
> Does removing the BUG_ON() fix the build?
>
It does, but it wasn't changed recently. Bisect results:
# bad: [88603b6dc419445847923fcb7fe5080067a30f98] Linux 6.2-rc2
# good: [c8451c141e07a8d05693f6c8d0e418fbb4b68bb7] Merge tag 'acpi-6.2-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect start 'HEAD' 'c8451c141e07'
# bad: [8b41948296b76588f5ebaf7cbc5be5c803ece70a] Merge tag 'drm-fixes-2023-01-01' of git://anongit.freedesktop.org/drm/drm
git bisect bad 8b41948296b76588f5ebaf7cbc5be5c803ece70a
# bad: [6a5e25fc3e0b94301734e8abb1d311a1e02d360d] fixdep: remove unneeded <stdarg.h> inclusion
git bisect bad 6a5e25fc3e0b94301734e8abb1d311a1e02d360d
# bad: [9c9b55a59416a87fc73c479d78cb3218076dbc30] kbuild: add a missing line for help message
git bisect bad 9c9b55a59416a87fc73c479d78cb3218076dbc30
# bad: [99cb0d917ffa1ab628bb67364ca9b162c07699b1] arch: fix broken BuildID for arm64 and riscv
git bisect bad 99cb0d917ffa1ab628bb67364ca9b162c07699b1
# good: [da8daff9405e55baa1f797b77a7c629a89f4d764] kconfig: Add static text for search information in help menu
git bisect good da8daff9405e55baa1f797b77a7c629a89f4d764
# first bad commit: [99cb0d917ffa1ab628bb67364ca9b162c07699b1] arch: fix broken BuildID for arm64 and riscv
... and reverting commit 99cb0d917ff indeed fixes the problem.
Copying those involved for comments.
Guenter
On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <[email protected]> wrote:
>
> ... and reverting commit 99cb0d917ff indeed fixes the problem.
Hmm. My gut feel is that this just exposes some bug in binutils.
That said, maybe that commit should not have added its own /DISCARDS/
thing, and instead just added that "*(.note.GNU-stack)" to the general
/DISCARDS/ thing that is defined by the
#define DISCARDS ..
a little bit later, so that we only end up with one single DISCARD
list. Something like this (broken patch on purpose):
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -897,5 +897,4 @@
*/
#define NOTES \
- /DISCARD/ : { *(.note.GNU-stack) } \
.notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
BOUNDED_SECTION_BY(.note.*, _notes) \
@@ -1016,4 +1015,5 @@
#define DISCARDS \
/DISCARD/ : { \
+ *(.note.GNU-stack) \
EXIT_DISCARDS \
EXIT_CALL \
But maybe that DISCARDS macrop ends up being used too late?
It really shouldn't matter, but here we are, with a build problem with
some random old binutils on an odd platform..
Linus
On Mon, Jan 02, 2023 at 06:13:09PM -0800, Linus Torvalds wrote:
> On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <[email protected]> wrote:
> >
> > ... and reverting commit 99cb0d917ff indeed fixes the problem.
>
> Hmm. My gut feel is that this just exposes some bug in binutils.
>
May well be, but it would be an architecture specific bug. The problem
is not seen when building an x86 image with binutils 2.32. Of course it
might affect other architectures.
> That said, maybe that commit should not have added its own /DISCARDS/
> thing, and instead just added that "*(.note.GNU-stack)" to the general
> /DISCARDS/ thing that is defined by the
>
> #define DISCARDS ..
>
> a little bit later, so that we only end up with one single DISCARD
> list. Something like this (broken patch on purpose):
>
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -897,5 +897,4 @@
> */
> #define NOTES \
> - /DISCARD/ : { *(.note.GNU-stack) } \
> .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
> BOUNDED_SECTION_BY(.note.*, _notes) \
> @@ -1016,4 +1015,5 @@
> #define DISCARDS \
> /DISCARD/ : { \
> + *(.note.GNU-stack) \
> EXIT_DISCARDS \
> EXIT_CALL \
>
I don't know if and how it affects arm64 and riscv, but the above fixes
the problem for sh.
> But maybe that DISCARDS macrop ends up being used too late?
>
DISCARDS is the very first entry in SECTIONS. NOTES is part of RO_DATA
and comes much later.
> It really shouldn't matter, but here we are, with a build problem with
> some random old binutils on an odd platform..
The one we know of. I could try to compile all architectures with
binutils 2.32, but I don't really want to do that if I can avoid it.
Guenter
On Mon, Jan 02, 2023 at 07:57:04PM -0800, Guenter Roeck wrote:
> On Mon, Jan 02, 2023 at 06:13:09PM -0800, Linus Torvalds wrote:
> > On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <[email protected]> wrote:
> > >
> > > ... and reverting commit 99cb0d917ff indeed fixes the problem.
> >
> > Hmm. My gut feel is that this just exposes some bug in binutils.
> >
> May well be, but it would be an architecture specific bug. The problem
> is not seen when building an x86 image with binutils 2.32. Of course it
> might affect other architectures.
It is likely a generic binutils bug, as I have seen it with PowerPC and
s390. I assume it comes down to how architectures have written their
linker scripts. I did some initial investigation yesterday and reported
my findings on Masahiro's patch thread:
https://lore.kernel.org/[email protected]/
I have seen at least three separate threads now with this issue, perhaps
it is just worth reverting the patch now and submitting a fixed version?
2.35.2 is Debian stable's binutils version so this will likely impact a
lot of CIs.
Cheers,
Nathan
> > That said, maybe that commit should not have added its own /DISCARDS/
> > thing, and instead just added that "*(.note.GNU-stack)" to the general
> > /DISCARDS/ thing that is defined by the
> >
> > #define DISCARDS ..
> >
> > a little bit later, so that we only end up with one single DISCARD
> > list. Something like this (broken patch on purpose):
> >
> > --- a/include/asm-generic/vmlinux.lds.h
> > +++ b/include/asm-generic/vmlinux.lds.h
> > @@ -897,5 +897,4 @@
> > */
> > #define NOTES \
> > - /DISCARD/ : { *(.note.GNU-stack) } \
> > .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
> > BOUNDED_SECTION_BY(.note.*, _notes) \
> > @@ -1016,4 +1015,5 @@
> > #define DISCARDS \
> > /DISCARD/ : { \
> > + *(.note.GNU-stack) \
> > EXIT_DISCARDS \
> > EXIT_CALL \
> >
>
> I don't know if and how it affects arm64 and riscv, but the above fixes
> the problem for sh.
>
> > But maybe that DISCARDS macrop ends up being used too late?
> >
>
> DISCARDS is the very first entry in SECTIONS. NOTES is part of RO_DATA
> and comes much later.
>
> > It really shouldn't matter, but here we are, with a build problem with
> > some random old binutils on an odd platform..
>
> The one we know of. I could try to compile all architectures with
> binutils 2.32, but I don't really want to do that if I can avoid it.
>
> Guenter
On 03.01.23 05:26, Nathan Chancellor wrote:
> On Mon, Jan 02, 2023 at 07:57:04PM -0800, Guenter Roeck wrote:
>> On Mon, Jan 02, 2023 at 06:13:09PM -0800, Linus Torvalds wrote:
>>> On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <[email protected]> wrote:
>>>>
>>>> ... and reverting commit 99cb0d917ff indeed fixes the problem.
>>>
>>> Hmm. My gut feel is that this just exposes some bug in binutils.
>>>
>> May well be, but it would be an architecture specific bug. The problem
>> is not seen when building an x86 image with binutils 2.32. Of course it
>> might affect other architectures.
>
> It is likely a generic binutils bug, as I have seen it with PowerPC and
> s390. I assume it comes down to how architectures have written their
> linker scripts. I did some initial investigation yesterday and reported
> my findings on Masahiro's patch thread:
>
> https://lore.kernel.org/[email protected]/
>
> I have seen at least three separate threads now with this issue, perhaps
> it is just worth reverting the patch now and submitting a fixed version?
> 2.35.2 is Debian stable's binutils version so this will likely impact a
> lot of CIs.
If someone wants to go down that route, it might be wise to also revert
the two patches 99cb0d917ff mentions with Fixes: tags, as otherwise the
regression it was supposed to fix (which at least impacts ARM64 kernel
rpm builds on Fedora -- and thus maybe some CI systems, too) will come back.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
>>> That said, maybe that commit should not have added its own /DISCARDS/
>>> thing, and instead just added that "*(.note.GNU-stack)" to the general
>>> /DISCARDS/ thing that is defined by the
>>>
>>> #define DISCARDS ..
>>>
>>> a little bit later, so that we only end up with one single DISCARD
>>> list. Something like this (broken patch on purpose):
>>>
>>> --- a/include/asm-generic/vmlinux.lds.h
>>> +++ b/include/asm-generic/vmlinux.lds.h
>>> @@ -897,5 +897,4 @@
>>> */
>>> #define NOTES \
>>> - /DISCARD/ : { *(.note.GNU-stack) } \
>>> .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
>>> BOUNDED_SECTION_BY(.note.*, _notes) \
>>> @@ -1016,4 +1015,5 @@
>>> #define DISCARDS \
>>> /DISCARD/ : { \
>>> + *(.note.GNU-stack) \
>>> EXIT_DISCARDS \
>>> EXIT_CALL \
>>>
>>
>> I don't know if and how it affects arm64 and riscv, but the above fixes
>> the problem for sh.
>>
>>> But maybe that DISCARDS macrop ends up being used too late?
>>>
>>
>> DISCARDS is the very first entry in SECTIONS. NOTES is part of RO_DATA
>> and comes much later.
>>
>>> It really shouldn't matter, but here we are, with a build problem with
>>> some random old binutils on an odd platform..
>>
>> The one we know of. I could try to compile all architectures with
>> binutils 2.32, but I don't really want to do that if I can avoid it.
>>
>> Guenter
On Tue, 3 Jan 2023 at 03:13, Linus Torvalds
<[email protected]> wrote:
>
> On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <[email protected]> wrote:
> >
> > ... and reverting commit 99cb0d917ff indeed fixes the problem.
>
> Hmm. My gut feel is that this just exposes some bug in binutils.
>
> That said, maybe that commit should not have added its own /DISCARDS/
> thing, and instead just added that "*(.note.GNU-stack)" to the general
> /DISCARDS/ thing that is defined by the
>
> #define DISCARDS ..
>
> a little bit later, so that we only end up with one single DISCARD
> list. Something like this (broken patch on purpose):
>
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -897,5 +897,4 @@
> */
> #define NOTES \
> - /DISCARD/ : { *(.note.GNU-stack) } \
> .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
> BOUNDED_SECTION_BY(.note.*, _notes) \
> @@ -1016,4 +1015,5 @@
> #define DISCARDS \
> /DISCARD/ : { \
> + *(.note.GNU-stack) \
> EXIT_DISCARDS \
> EXIT_CALL \
>
> But maybe that DISCARDS macrop ends up being used too late?
>
Masahiro's v1 did something like this, and it caused an issue on
RISC-V, which is why we ended up with this approach instead.
> It really shouldn't matter, but here we are, with a build problem with
> some random old binutils on an odd platform..
>
AIUI, the way ld.bfd used to combine output sections may also affect
the /DISCARD/ pseudo-section, and so introducing it much earlier
results in these discards to be interpreted in a different order.
The purpose of this change is to prevent .note.GNU-stack from deciding
the section type of the .notes output section, and so keeping it in
its own section should be sufficient. E.g.,
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -896,7 +896,7 @@
* Otherwise, the type of .notes section would become PROGBITS
instead of NOTES.
*/
#define NOTES \
- /DISCARD/ : { *(.note.GNU-stack) } \
+ .note.GNU-stack : { *(.note.GNU-stack) } \
.notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
BOUNDED_SECTION_BY(.note.*, _notes) \
} NOTES_HEADERS \
The .note.GNU-stack has zero size, so the result should be the same.
On Tue, Jan 03, 2023 at 11:58:48AM +0100, Ard Biesheuvel wrote:
> On Tue, 3 Jan 2023 at 03:13, Linus Torvalds
> <[email protected]> wrote:
> >
> > On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <[email protected]> wrote:
> > >
> > > ... and reverting commit 99cb0d917ff indeed fixes the problem.
> >
> > Hmm. My gut feel is that this just exposes some bug in binutils.
> >
> > That said, maybe that commit should not have added its own /DISCARDS/
> > thing, and instead just added that "*(.note.GNU-stack)" to the general
> > /DISCARDS/ thing that is defined by the
> >
> > #define DISCARDS ..
> >
> > a little bit later, so that we only end up with one single DISCARD
> > list. Something like this (broken patch on purpose):
> >
> > --- a/include/asm-generic/vmlinux.lds.h
> > +++ b/include/asm-generic/vmlinux.lds.h
> > @@ -897,5 +897,4 @@
> > */
> > #define NOTES \
> > - /DISCARD/ : { *(.note.GNU-stack) } \
> > .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
> > BOUNDED_SECTION_BY(.note.*, _notes) \
> > @@ -1016,4 +1015,5 @@
> > #define DISCARDS \
> > /DISCARD/ : { \
> > + *(.note.GNU-stack) \
> > EXIT_DISCARDS \
> > EXIT_CALL \
> >
> > But maybe that DISCARDS macrop ends up being used too late?
> >
>
> Masahiro's v1 did something like this, and it caused an issue on
> RISC-V, which is why we ended up with this approach instead.
FWIW, I gave this one a go & it didn't produce the link failures that
Masahiro's v1 did on RISC-V...
> > It really shouldn't matter, but here we are, with a build problem with
> > some random old binutils on an odd platform..
> >
>
> AIUI, the way ld.bfd used to combine output sections may also affect
> the /DISCARD/ pseudo-section, and so introducing it much earlier
> results in these discards to be interpreted in a different order.
>
> The purpose of this change is to prevent .note.GNU-stack from deciding
> the section type of the .notes output section, and so keeping it in
> its own section should be sufficient. E.g.,
>
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -896,7 +896,7 @@
> * Otherwise, the type of .notes section would become PROGBITS
> instead of NOTES.
> */
> #define NOTES \
> - /DISCARD/ : { *(.note.GNU-stack) } \
> + .note.GNU-stack : { *(.note.GNU-stack) } \
> .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
> BOUNDED_SECTION_BY(.note.*, _notes) \
> } NOTES_HEADERS \
>
> The .note.GNU-stack has zero size, so the result should be the same.
...and this one doesn't move DISCARDS around either, so also shouldn't
hit that issue. Famous last words, so I did run it through a config that
produced the link failures before & it was fine.
On Tue, Jan 03, 2023 at 11:58:48AM +0100, Ard Biesheuvel wrote:
> On Tue, 3 Jan 2023 at 03:13, Linus Torvalds
> <[email protected]> wrote:
> >
> > On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <[email protected]> wrote:
> > >
> > > ... and reverting commit 99cb0d917ff indeed fixes the problem.
> >
> > Hmm. My gut feel is that this just exposes some bug in binutils.
> >
> > That said, maybe that commit should not have added its own /DISCARDS/
> > thing, and instead just added that "*(.note.GNU-stack)" to the general
> > /DISCARDS/ thing that is defined by the
> >
> > #define DISCARDS ..
> >
> > a little bit later, so that we only end up with one single DISCARD
> > list. Something like this (broken patch on purpose):
> >
> > --- a/include/asm-generic/vmlinux.lds.h
> > +++ b/include/asm-generic/vmlinux.lds.h
> > @@ -897,5 +897,4 @@
> > */
> > #define NOTES \
> > - /DISCARD/ : { *(.note.GNU-stack) } \
> > .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
> > BOUNDED_SECTION_BY(.note.*, _notes) \
> > @@ -1016,4 +1015,5 @@
> > #define DISCARDS \
> > /DISCARD/ : { \
> > + *(.note.GNU-stack) \
> > EXIT_DISCARDS \
> > EXIT_CALL \
> >
> > But maybe that DISCARDS macrop ends up being used too late?
> >
>
> Masahiro's v1 did something like this, and it caused an issue on
> RISC-V, which is why we ended up with this approach instead.
>
> > It really shouldn't matter, but here we are, with a build problem with
> > some random old binutils on an odd platform..
> >
>
> AIUI, the way ld.bfd used to combine output sections may also affect
> the /DISCARD/ pseudo-section, and so introducing it much earlier
> results in these discards to be interpreted in a different order.
>
> The purpose of this change is to prevent .note.GNU-stack from deciding
> the section type of the .notes output section, and so keeping it in
> its own section should be sufficient. E.g.,
>
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -896,7 +896,7 @@
> * Otherwise, the type of .notes section would become PROGBITS
> instead of NOTES.
> */
> #define NOTES \
> - /DISCARD/ : { *(.note.GNU-stack) } \
> + .note.GNU-stack : { *(.note.GNU-stack) } \
> .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
> BOUNDED_SECTION_BY(.note.*, _notes) \
> } NOTES_HEADERS \
>
> The .note.GNU-stack has zero size, so the result should be the same.
The above fixes the problem for sh.
Guenter
On Tue, Jan 03, 2023 at 11:58:48AM +0100, Ard Biesheuvel wrote:
> On Tue, 3 Jan 2023 at 03:13, Linus Torvalds
> <[email protected]> wrote:
> >
> > On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <[email protected]> wrote:
> > >
> > > ... and reverting commit 99cb0d917ff indeed fixes the problem.
> >
> > Hmm. My gut feel is that this just exposes some bug in binutils.
> >
> > That said, maybe that commit should not have added its own /DISCARDS/
> > thing, and instead just added that "*(.note.GNU-stack)" to the general
> > /DISCARDS/ thing that is defined by the
> >
> > #define DISCARDS ..
> >
> > a little bit later, so that we only end up with one single DISCARD
> > list. Something like this (broken patch on purpose):
> >
> > --- a/include/asm-generic/vmlinux.lds.h
> > +++ b/include/asm-generic/vmlinux.lds.h
> > @@ -897,5 +897,4 @@
> > */
> > #define NOTES \
> > - /DISCARD/ : { *(.note.GNU-stack) } \
> > .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
> > BOUNDED_SECTION_BY(.note.*, _notes) \
> > @@ -1016,4 +1015,5 @@
> > #define DISCARDS \
> > /DISCARD/ : { \
> > + *(.note.GNU-stack) \
> > EXIT_DISCARDS \
> > EXIT_CALL \
> >
> > But maybe that DISCARDS macrop ends up being used too late?
> >
>
> Masahiro's v1 did something like this, and it caused an issue on
> RISC-V, which is why we ended up with this approach instead.
>
> > It really shouldn't matter, but here we are, with a build problem with
> > some random old binutils on an odd platform..
> >
>
> AIUI, the way ld.bfd used to combine output sections may also affect
> the /DISCARD/ pseudo-section, and so introducing it much earlier
> results in these discards to be interpreted in a different order.
>
> The purpose of this change is to prevent .note.GNU-stack from deciding
> the section type of the .notes output section, and so keeping it in
> its own section should be sufficient. E.g.,
This appears to work for me. It fixes the build failures that
ClangBuiltLinux's CI reported and I still see a build ID for arm64's
vmlinux:
Tested-by: Nathan Chancellor <[email protected]>
I will throw this into the ClangBuiltLinux CI to make sure there are no
additional surprises but I do not expect to find anything.
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -896,7 +896,7 @@
> * Otherwise, the type of .notes section would become PROGBITS
> instead of NOTES.
> */
> #define NOTES \
> - /DISCARD/ : { *(.note.GNU-stack) } \
> + .note.GNU-stack : { *(.note.GNU-stack) } \
> .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
> BOUNDED_SECTION_BY(.note.*, _notes) \
> } NOTES_HEADERS \
>
> The .note.GNU-stack has zero size, so the result should be the same.
On Tue, Jan 3, 2023 at 2:59 AM Ard Biesheuvel <[email protected]> wrote:
>
> The purpose of this change is to prevent .note.GNU-stack from deciding
> the section type of the .notes output section, and so keeping it in
> its own section should be sufficient. E.g.,
>
> - /DISCARD/ : { *(.note.GNU-stack) } \
> + .note.GNU-stack : { *(.note.GNU-stack) } \
This seems to work for everybody, so let's go with this. Masahiro?
Linus
Ard Biesheuvel <[email protected]> writes:
> On Tue, 3 Jan 2023 at 03:13, Linus Torvalds
> <[email protected]> wrote:
>>
>> On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <[email protected]> wrote:
>> >
>> > ... and reverting commit 99cb0d917ff indeed fixes the problem.
>>
>> Hmm. My gut feel is that this just exposes some bug in binutils.
...
>> It really shouldn't matter, but here we are, with a build problem with
>> some random old binutils on an odd platform..
>>
>
> AIUI, the way ld.bfd used to combine output sections may also affect
> the /DISCARD/ pseudo-section, and so introducing it much earlier
> results in these discards to be interpreted in a different order.
>
> The purpose of this change is to prevent .note.GNU-stack from deciding
> the section type of the .notes output section, and so keeping it in
> its own section should be sufficient. E.g.,
>
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -896,7 +896,7 @@
> * Otherwise, the type of .notes section would become PROGBITS
> instead of NOTES.
> */
> #define NOTES \
> - /DISCARD/ : { *(.note.GNU-stack) } \
> + .note.GNU-stack : { *(.note.GNU-stack) } \
> .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
> BOUNDED_SECTION_BY(.note.*, _notes) \
> } NOTES_HEADERS \
This also fixes errors seen in the powerpc build with binutils <= 2.35.
Tested-by: Michael Ellerman <[email protected]> (powerpc)
cheers
On Wed, Jan 4, 2023 at 3:34 AM Linus Torvalds
<[email protected]> wrote:
>
> On Tue, Jan 3, 2023 at 2:59 AM Ard Biesheuvel <[email protected]> wrote:
> >
> > The purpose of this change is to prevent .note.GNU-stack from deciding
> > the section type of the .notes output section, and so keeping it in
> > its own section should be sufficient. E.g.,
> >
> > - /DISCARD/ : { *(.note.GNU-stack) } \
> > + .note.GNU-stack : { *(.note.GNU-stack) } \
>
> This seems to work for everybody, so let's go with this. Masahiro?
>
> Linus
Sorry for the delay, I completely missed this thread.
Tested-by: Masahiro Yamada <[email protected]>
It works for me, but the comment block above should be
changed accordingly, for example:
/*
- * Discard .note.GNU-stack, which is emitted as PROGBITS by the compiler.
+ * Separte note.GNU-stack, which is emitted as PROGBITS by the compiler.
* Otherwise, the type of .notes section would become PROGBITS
instead of NOTES.
*/
This change, however, leaves an empty .note.GNU-stack section in vmlinux.
I personally prefer discarding .note.GNU-stack entirely because
GNU linker does not leave empty .note.GNU-stack when linking
user-space programs.
Because I did not notice the discussion was happening in this thread,
I submitted a different approach for fixing s390, and it was quickly merged:
https://lore.kernel.org/lkml/[email protected]/
This approach requires RUNTIME_DISCARD_EXIT for each architecture, though.
I do not know how Michael will fix powerpc.
While I was looking into this issue,
I noticed the real issue is,
how to discard sections is up to arch maintainers.
[1] Most architectures discard .exit.* sections at run-time.
Just run
git grep EXIT_TEXT
or
find . -name vmlinux.lds.S | xargs grep "at runtime"
[2] If .exit.* is allocated, then later discarded, it is kept.
(the first occurrence wins, in other words,
the sections defined in /DISCARD/ are not necessarily discarded)
[3] Despite the fact of [1], many architectures forget to
define RUNTIME_DISCARD_EXIT.
They still work because they put DISCARD
at the end of their linker scripts.
[4] arm64 puts DISCARD at the beginning of the linker
script, and defines RUNTIME_DISCARD_EXIT because otherwise
.exit* are discarded due to the "first wins" rule.
[5] If we really want to discard more sections, we often end
up with moving DISCARD up, and at this point, we realize
that RUNTIME_DISCARD_EXIT is missing.
I think it is unreadable (and fragile)
to keep/discard sections depending on the particular
order in the linker scripts.
Is there any better approach to make sure to discard
sections defined in DISCARDS?
--
Best Regards
Masahiro Yamada
On Tue, 3 Jan 2023 11:58:48 +0100 Ard Biesheuvel <[email protected]> wrote:
> On Tue, 3 Jan 2023 at 03:13, Linus Torvalds
> <[email protected]> wrote:
> >
> > On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <[email protected]> wrote:
> > >
[...]
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -896,7 +896,7 @@
> * Otherwise, the type of .notes section would become PROGBITS
> instead of NOTES.
> */
> #define NOTES \
> - /DISCARD/ : { *(.note.GNU-stack) } \
> + .note.GNU-stack : { *(.note.GNU-stack) } \
> .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
> BOUNDED_SECTION_BY(.note.*, _notes) \
> } NOTES_HEADERS \
>
> The .note.GNU-stack has zero size, so the result should be the same.
>
This also fixes ARCH=um build error on my system.
Tested-by: SeongJae Park <[email protected]>
Thanks,
SJ
Hi Masahiro,
On Wed, 11 Jan 2023 03:39:58 +0900 Masahiro Yamada <[email protected]> wrote:
> On Tue, Jan 10, 2023 at 9:32 AM SeongJae Park <[email protected]> wrote:
> >
> > On Tue, 3 Jan 2023 11:58:48 +0100 Ard Biesheuvel <[email protected]> wrote:
> >
> > > On Tue, 3 Jan 2023 at 03:13, Linus Torvalds
> > > <[email protected]> wrote:
> > > >
> > > > On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <[email protected]> wrote:
> > > > >
> > [...]
> > > --- a/include/asm-generic/vmlinux.lds.h
> > > +++ b/include/asm-generic/vmlinux.lds.h
> > > @@ -896,7 +896,7 @@
> > > * Otherwise, the type of .notes section would become PROGBITS
> > > instead of NOTES.
> > > */
> > > #define NOTES \
> > > - /DISCARD/ : { *(.note.GNU-stack) } \
> > > + .note.GNU-stack : { *(.note.GNU-stack) } \
> > > .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
> > > BOUNDED_SECTION_BY(.note.*, _notes) \
> > > } NOTES_HEADERS \
> > >
> > > The .note.GNU-stack has zero size, so the result should be the same.
> > >
> >
> > This also fixes ARCH=um build error on my system.
> >
> > Tested-by: SeongJae Park <[email protected]>
>
>
>
> I am able to build ARCH=um defconfig at least.
>
> Can you provide the steps to reproduce the build error?
I do the build for kunit test, like below.
mkdir ../kunit.out
echo "
CONFIG_KUNIT=y
CONFIG_DAMON=y
CONFIG_DAMON_KUNIT_TEST=y
CONFIG_DAMON_VADDR=y
CONFIG_DAMON_VADDR_KUNIT_TEST=y
CONFIG_DEBUG_FS=y
CONFIG_DAMON_DBGFS=y
CONFIG_DAMON_DBGFS_KUNIT_TEST=y
CONFIG_DAMON_PADDR=y" > ../kunit.out/.kunitconfig
./tools/testsing/kunit/kunit.py run --build_dir ../kunit.out
[19:12:37] Configuring KUnit Kernel ...
[19:12:37] Building KUnit Kernel ...
Populating config with:
$ make ARCH=um O=../kunit.out/ olddefconfig
Building with:
$ make ARCH=um O=../kunit.out/ --jobs=36
ERROR:root:`.exit.text' referenced in section `.uml.exitcall.exit' of arch/um/drivers/virtio_uml.o: defined in discarded section `.exit.text' of arch/um/drivers/virtio_uml.o
collect2: error: ld returned 1 exit status
make[2]: *** [/home/sjpark/linux/scripts/Makefile.vmlinux:34: vmlinux] Error 1
make[1]: *** [/home/sjpark/linux/Makefile:1252: vmlinux] Error 2
make: *** [Makefile:242: __sub-make] Error 2
Thanks,
SJ
>
>
>
>
> --
> Best Regards
> Masahiro Yamada
On Tue, Jan 10, 2023 at 9:32 AM SeongJae Park <[email protected]> wrote:
>
> On Tue, 3 Jan 2023 11:58:48 +0100 Ard Biesheuvel <[email protected]> wrote:
>
> > On Tue, 3 Jan 2023 at 03:13, Linus Torvalds
> > <[email protected]> wrote:
> > >
> > > On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <[email protected]> wrote:
> > > >
> [...]
> > --- a/include/asm-generic/vmlinux.lds.h
> > +++ b/include/asm-generic/vmlinux.lds.h
> > @@ -896,7 +896,7 @@
> > * Otherwise, the type of .notes section would become PROGBITS
> > instead of NOTES.
> > */
> > #define NOTES \
> > - /DISCARD/ : { *(.note.GNU-stack) } \
> > + .note.GNU-stack : { *(.note.GNU-stack) } \
> > .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
> > BOUNDED_SECTION_BY(.note.*, _notes) \
> > } NOTES_HEADERS \
> >
> > The .note.GNU-stack has zero size, so the result should be the same.
> >
>
> This also fixes ARCH=um build error on my system.
>
> Tested-by: SeongJae Park <[email protected]>
I am able to build ARCH=um defconfig at least.
Can you provide the steps to reproduce the build error?
--
Best Regards
Masahiro Yamada
On Tue, Jan 03, 2023 at 11:58:48AM +0100, Ard Biesheuvel wrote:
> On Tue, 3 Jan 2023 at 03:13, Linus Torvalds
> <[email protected]> wrote:
> >
> > On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <[email protected]> wrote:
> > >
> > > ... and reverting commit 99cb0d917ff indeed fixes the problem.
> >
> > Hmm. My gut feel is that this just exposes some bug in binutils.
> >
> > That said, maybe that commit should not have added its own /DISCARDS/
> > thing, and instead just added that "*(.note.GNU-stack)" to the general
> > /DISCARDS/ thing that is defined by the
> >
> > #define DISCARDS ..
> >
> > a little bit later, so that we only end up with one single DISCARD
> > list. Something like this (broken patch on purpose):
> >
> > --- a/include/asm-generic/vmlinux.lds.h
> > +++ b/include/asm-generic/vmlinux.lds.h
> > @@ -897,5 +897,4 @@
> > */
> > #define NOTES \
> > - /DISCARD/ : { *(.note.GNU-stack) } \
> > .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
> > BOUNDED_SECTION_BY(.note.*, _notes) \
> > @@ -1016,4 +1015,5 @@
> > #define DISCARDS \
> > /DISCARD/ : { \
> > + *(.note.GNU-stack) \
> > EXIT_DISCARDS \
> > EXIT_CALL \
> >
> > But maybe that DISCARDS macrop ends up being used too late?
> >
>
> Masahiro's v1 did something like this, and it caused an issue on
> RISC-V, which is why we ended up with this approach instead.
>
> > It really shouldn't matter, but here we are, with a build problem with
> > some random old binutils on an odd platform..
> >
>
> AIUI, the way ld.bfd used to combine output sections may also affect
> the /DISCARD/ pseudo-section, and so introducing it much earlier
> results in these discards to be interpreted in a different order.
>
> The purpose of this change is to prevent .note.GNU-stack from deciding
> the section type of the .notes output section, and so keeping it in
> its own section should be sufficient. E.g.,
>
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -896,7 +896,7 @@
> * Otherwise, the type of .notes section would become PROGBITS
> instead of NOTES.
> */
> #define NOTES \
> - /DISCARD/ : { *(.note.GNU-stack) } \
> + .note.GNU-stack : { *(.note.GNU-stack) } \
> .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
> BOUNDED_SECTION_BY(.note.*, _notes) \
> } NOTES_HEADERS \
>
> The .note.GNU-stack has zero size, so the result should be the same.
+Greg +Nick
This also fixes Build ID on arm64 for stable 5.15, 5.10, and 5.4
which has been broken since backport of:
0d362be5b142 ("Makefile: link with -z noexecstack --no-warn-rwx-segments")
Discussed here:
https://lore.kernel.org/stable/3df32572ec7016e783d37e185f88495831671f5d.1671143628.git.tom.saeger@oracle.com/
https://lore.kernel.org/stable/[email protected]/
Perhaps add:
Cc: <[email protected]> # 5.15, 5.10, 5.4
for stable 5.15, 5.10, 5.4
Tested-by: Tom Saeger <[email protected]>
On Wed, Jan 11, 2023 at 4:14 AM SeongJae Park <[email protected]> wrote:
>
> Hi Masahiro,
>
> On Wed, 11 Jan 2023 03:39:58 +0900 Masahiro Yamada <[email protected]> wrote:
>
> > On Tue, Jan 10, 2023 at 9:32 AM SeongJae Park <[email protected]> wrote:
> > >
> > > On Tue, 3 Jan 2023 11:58:48 +0100 Ard Biesheuvel <[email protected]> wrote:
> > >
> > > > On Tue, 3 Jan 2023 at 03:13, Linus Torvalds
> > > > <[email protected]> wrote:
> > > > >
> > > > > On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <[email protected]> wrote:
> > > > > >
> > > [...]
> > > > --- a/include/asm-generic/vmlinux.lds.h
> > > > +++ b/include/asm-generic/vmlinux.lds.h
> > > > @@ -896,7 +896,7 @@
> > > > * Otherwise, the type of .notes section would become PROGBITS
> > > > instead of NOTES.
> > > > */
> > > > #define NOTES \
> > > > - /DISCARD/ : { *(.note.GNU-stack) } \
> > > > + .note.GNU-stack : { *(.note.GNU-stack) } \
> > > > .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
> > > > BOUNDED_SECTION_BY(.note.*, _notes) \
> > > > } NOTES_HEADERS \
> > > >
> > > > The .note.GNU-stack has zero size, so the result should be the same.
> > > >
> > >
> > > This also fixes ARCH=um build error on my system.
> > >
> > > Tested-by: SeongJae Park <[email protected]>
> >
> >
> >
> > I am able to build ARCH=um defconfig at least.
> >
> > Can you provide the steps to reproduce the build error?
>
> I do the build for kunit test, like below.
>
> mkdir ../kunit.out
> echo "
> CONFIG_KUNIT=y
>
> CONFIG_DAMON=y
> CONFIG_DAMON_KUNIT_TEST=y
>
> CONFIG_DAMON_VADDR=y
> CONFIG_DAMON_VADDR_KUNIT_TEST=y
>
> CONFIG_DEBUG_FS=y
> CONFIG_DAMON_DBGFS=y
> CONFIG_DAMON_DBGFS_KUNIT_TEST=y
> CONFIG_DAMON_PADDR=y" > ../kunit.out/.kunitconfig
> ./tools/testsing/kunit/kunit.py run --build_dir ../kunit.out
> [19:12:37] Configuring KUnit Kernel ...
> [19:12:37] Building KUnit Kernel ...
> Populating config with:
> $ make ARCH=um O=../kunit.out/ olddefconfig
> Building with:
> $ make ARCH=um O=../kunit.out/ --jobs=36
> ERROR:root:`.exit.text' referenced in section `.uml.exitcall.exit' of arch/um/drivers/virtio_uml.o: defined in discarded section `.exit.text' of arch/um/drivers/virtio_uml.o
> collect2: error: ld returned 1 exit status
> make[2]: *** [/home/sjpark/linux/scripts/Makefile.vmlinux:34: vmlinux] Error 1
> make[1]: *** [/home/sjpark/linux/Makefile:1252: vmlinux] Error 2
> make: *** [Makefile:242: __sub-make] Error 2
>
>
> Thanks,
> SJ
>
I did not see the error, though.
The test seems to have succeeded.
masahiro@zoe:~/ref/linux(master)$ cat ../kunit.out/.kunitconfig
CONFIG_KUNIT=y
CONFIG_DAMON=y
CONFIG_DAMON_KUNIT_TEST=y
CONFIG_DAMON_VADDR=y
CONFIG_DAMON_VADDR_KUNIT_TEST=y
CONFIG_DEBUG_FS=y
CONFIG_DAMON_DBGFS=y
CONFIG_DAMON_DBGFS_KUNIT_TEST=y
CONFIG_DAMON_PADDR=y
masahiro@zoe:~/ref/linux(master)$ ./tools/testing/kunit/kunit.py run
--build_dir ../kunit.out
[18:05:19] Configuring KUnit Kernel ...
Regenerating .config ...
Populating config with:
$ make ARCH=um O=../kunit.out olddefconfig
[18:05:22] Building KUnit Kernel ...
Populating config with:
$ make ARCH=um O=../kunit.out olddefconfig
Building with:
$ make ARCH=um O=../kunit.out --jobs=16
[18:05:47] Starting KUnit Kernel (1/1)...
[18:05:47] ============================================================
[18:05:47] ==================== damon (9 subtests) ====================
[18:05:47] [PASSED] damon_test_target
[18:05:47] [PASSED] damon_test_regions
[18:05:47] [PASSED] damon_test_aggregate
[18:05:47] [PASSED] damon_test_split_at
[18:05:47] [PASSED] damon_test_merge_two
[18:05:47] [PASSED] damon_test_merge_regions_of
[18:05:47] [PASSED] damon_test_split_regions_of
[18:05:47] [PASSED] damon_test_ops_registration
[18:05:47] [PASSED] damon_test_set_regions
[18:05:47] ====================== [PASSED] damon ======================
[18:05:47] ============== damon-operations (6 subtests) ===============
[18:05:47] [PASSED] damon_test_three_regions_in_vmas
[18:05:47] [PASSED] damon_test_apply_three_regions1
[18:05:47] [PASSED] damon_test_apply_three_regions2
[18:05:47] [PASSED] damon_test_apply_three_regions3
[18:05:47] [PASSED] damon_test_apply_three_regions4
[18:05:47] [PASSED] damon_test_split_evenly
[18:05:47] ================ [PASSED] damon-operations =================
[18:05:47] ================= damon-dbgfs (3 subtests) =================
[18:05:47] [PASSED] damon_dbgfs_test_str_to_ints
[18:05:47] [PASSED] damon_dbgfs_test_set_targets
[18:05:47] [PASSED] damon_dbgfs_test_set_init_regions
[18:05:47] =================== [PASSED] damon-dbgfs ===================
[18:05:47] ============================================================
[18:05:47] Testing complete. Ran 18 tests: passed: 18
[18:05:47] Elapsed time: 28.194s total, 3.017s configuring, 25.058s
building, 0.086s running
--
Best Regards
Masahiro Yamada
On Mon, 23 Jan 2023 18:09:27 +0900 Masahiro Yamada <[email protected]> wrote:
> On Wed, Jan 11, 2023 at 4:14 AM SeongJae Park <[email protected]> wrote:
> >
> > Hi Masahiro,
> >
> > On Wed, 11 Jan 2023 03:39:58 +0900 Masahiro Yamada <[email protected]> wrote:
> >
> > > On Tue, Jan 10, 2023 at 9:32 AM SeongJae Park <[email protected]> wrote:
> > > >
> > > > On Tue, 3 Jan 2023 11:58:48 +0100 Ard Biesheuvel <[email protected]> wrote:
> > > >
> > > > > On Tue, 3 Jan 2023 at 03:13, Linus Torvalds
> > > > > <[email protected]> wrote:
> > > > > >
> > > > > > On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <[email protected]> wrote:
> > > > > > >
> > > > [...]
> > > > > --- a/include/asm-generic/vmlinux.lds.h
> > > > > +++ b/include/asm-generic/vmlinux.lds.h
> > > > > @@ -896,7 +896,7 @@
> > > > > * Otherwise, the type of .notes section would become PROGBITS
> > > > > instead of NOTES.
> > > > > */
> > > > > #define NOTES \
> > > > > - /DISCARD/ : { *(.note.GNU-stack) } \
> > > > > + .note.GNU-stack : { *(.note.GNU-stack) } \
> > > > > .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
> > > > > BOUNDED_SECTION_BY(.note.*, _notes) \
> > > > > } NOTES_HEADERS \
> > > > >
> > > > > The .note.GNU-stack has zero size, so the result should be the same.
> > > > >
> > > >
> > > > This also fixes ARCH=um build error on my system.
> > > >
> > > > Tested-by: SeongJae Park <[email protected]>
> > >
> > >
> > >
> > > I am able to build ARCH=um defconfig at least.
> > >
> > > Can you provide the steps to reproduce the build error?
> >
> > I do the build for kunit test, like below.
> >
> > mkdir ../kunit.out
> > echo "
> > CONFIG_KUNIT=y
> >
> > CONFIG_DAMON=y
> > CONFIG_DAMON_KUNIT_TEST=y
> >
> > CONFIG_DAMON_VADDR=y
> > CONFIG_DAMON_VADDR_KUNIT_TEST=y
> >
> > CONFIG_DEBUG_FS=y
> > CONFIG_DAMON_DBGFS=y
> > CONFIG_DAMON_DBGFS_KUNIT_TEST=y
> > CONFIG_DAMON_PADDR=y" > ../kunit.out/.kunitconfig
> > ./tools/testsing/kunit/kunit.py run --build_dir ../kunit.out
> > [19:12:37] Configuring KUnit Kernel ...
> > [19:12:37] Building KUnit Kernel ...
> > Populating config with:
> > $ make ARCH=um O=../kunit.out/ olddefconfig
> > Building with:
> > $ make ARCH=um O=../kunit.out/ --jobs=36
> > ERROR:root:`.exit.text' referenced in section `.uml.exitcall.exit' of arch/um/drivers/virtio_uml.o: defined in discarded section `.exit.text' of arch/um/drivers/virtio_uml.o
> > collect2: error: ld returned 1 exit status
> > make[2]: *** [/home/sjpark/linux/scripts/Makefile.vmlinux:34: vmlinux] Error 1
> > make[1]: *** [/home/sjpark/linux/Makefile:1252: vmlinux] Error 2
> > make: *** [Makefile:242: __sub-make] Error 2
> >
> >
> > Thanks,
> > SJ
> >
>
>
> I did not see the error, though.
>
> The test seems to have succeeded.
>
>
>
>
> masahiro@zoe:~/ref/linux(master)$ cat ../kunit.out/.kunitconfig
> CONFIG_KUNIT=y
>
> CONFIG_DAMON=y
> CONFIG_DAMON_KUNIT_TEST=y
>
> CONFIG_DAMON_VADDR=y
> CONFIG_DAMON_VADDR_KUNIT_TEST=y
>
> CONFIG_DEBUG_FS=y
> CONFIG_DAMON_DBGFS=y
> CONFIG_DAMON_DBGFS_KUNIT_TEST=y
> CONFIG_DAMON_PADDR=y
> masahiro@zoe:~/ref/linux(master)$ ./tools/testing/kunit/kunit.py run
> --build_dir ../kunit.out
> [18:05:19] Configuring KUnit Kernel ...
> Regenerating .config ...
> Populating config with:
> $ make ARCH=um O=../kunit.out olddefconfig
> [18:05:22] Building KUnit Kernel ...
> Populating config with:
> $ make ARCH=um O=../kunit.out olddefconfig
> Building with:
> $ make ARCH=um O=../kunit.out --jobs=16
> [18:05:47] Starting KUnit Kernel (1/1)...
> [18:05:47] ============================================================
> [18:05:47] ==================== damon (9 subtests) ====================
> [18:05:47] [PASSED] damon_test_target
> [18:05:47] [PASSED] damon_test_regions
> [18:05:47] [PASSED] damon_test_aggregate
> [18:05:47] [PASSED] damon_test_split_at
> [18:05:47] [PASSED] damon_test_merge_two
> [18:05:47] [PASSED] damon_test_merge_regions_of
> [18:05:47] [PASSED] damon_test_split_regions_of
> [18:05:47] [PASSED] damon_test_ops_registration
> [18:05:47] [PASSED] damon_test_set_regions
> [18:05:47] ====================== [PASSED] damon ======================
> [18:05:47] ============== damon-operations (6 subtests) ===============
> [18:05:47] [PASSED] damon_test_three_regions_in_vmas
> [18:05:47] [PASSED] damon_test_apply_three_regions1
> [18:05:47] [PASSED] damon_test_apply_three_regions2
> [18:05:47] [PASSED] damon_test_apply_three_regions3
> [18:05:47] [PASSED] damon_test_apply_three_regions4
> [18:05:47] [PASSED] damon_test_split_evenly
> [18:05:47] ================ [PASSED] damon-operations =================
> [18:05:47] ================= damon-dbgfs (3 subtests) =================
> [18:05:47] [PASSED] damon_dbgfs_test_str_to_ints
> [18:05:47] [PASSED] damon_dbgfs_test_set_targets
> [18:05:47] [PASSED] damon_dbgfs_test_set_init_regions
> [18:05:47] =================== [PASSED] damon-dbgfs ===================
> [18:05:47] ============================================================
> [18:05:47] Testing complete. Ran 18 tests: passed: 18
> [18:05:47] Elapsed time: 28.194s total, 3.017s configuring, 25.058s
> building, 0.086s running
Thank you for sharing your results. I think it may depend on the compiler
version, because I use a quite old compiler.
$ gcc --version
gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
Thanks,
SJ
[...]
On Mon, 23 Jan 2023 18:27:32 +0000 SeongJae Park <[email protected]> wrote:
> On Mon, 23 Jan 2023 18:09:27 +0900 Masahiro Yamada <[email protected]> wrote:
>
> > On Wed, Jan 11, 2023 at 4:14 AM SeongJae Park <[email protected]> wrote:
> > >
> > > Hi Masahiro,
> > >
> > > On Wed, 11 Jan 2023 03:39:58 +0900 Masahiro Yamada <[email protected]> wrote:
> > >
> > > > On Tue, Jan 10, 2023 at 9:32 AM SeongJae Park <[email protected]> wrote:
> > > > >
> > > > > On Tue, 3 Jan 2023 11:58:48 +0100 Ard Biesheuvel <[email protected]> wrote:
> > > > >
> > > > > > On Tue, 3 Jan 2023 at 03:13, Linus Torvalds
> > > > > > <[email protected]> wrote:
> > > > > > >
> > > > > > > On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <[email protected]> wrote:
> > > > > > > >
> > > > > [...]
> > > > > > --- a/include/asm-generic/vmlinux.lds.h
> > > > > > +++ b/include/asm-generic/vmlinux.lds.h
> > > > > > @@ -896,7 +896,7 @@
> > > > > > * Otherwise, the type of .notes section would become PROGBITS
> > > > > > instead of NOTES.
> > > > > > */
> > > > > > #define NOTES \
> > > > > > - /DISCARD/ : { *(.note.GNU-stack) } \
> > > > > > + .note.GNU-stack : { *(.note.GNU-stack) } \
> > > > > > .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
> > > > > > BOUNDED_SECTION_BY(.note.*, _notes) \
> > > > > > } NOTES_HEADERS \
> > > > > >
> > > > > > The .note.GNU-stack has zero size, so the result should be the same.
> > > > > >
> > > > >
> > > > > This also fixes ARCH=um build error on my system.
> > > > >
> > > > > Tested-by: SeongJae Park <[email protected]>
> > > >
> > > >
> > > >
> > > > I am able to build ARCH=um defconfig at least.
> > > >
> > > > Can you provide the steps to reproduce the build error?
> > >
> > > I do the build for kunit test, like below.
> > >
> > > mkdir ../kunit.out
> > > echo "
> > > CONFIG_KUNIT=y
> > >
> > > CONFIG_DAMON=y
> > > CONFIG_DAMON_KUNIT_TEST=y
> > >
> > > CONFIG_DAMON_VADDR=y
> > > CONFIG_DAMON_VADDR_KUNIT_TEST=y
> > >
> > > CONFIG_DEBUG_FS=y
> > > CONFIG_DAMON_DBGFS=y
> > > CONFIG_DAMON_DBGFS_KUNIT_TEST=y
> > > CONFIG_DAMON_PADDR=y" > ../kunit.out/.kunitconfig
> > > ./tools/testsing/kunit/kunit.py run --build_dir ../kunit.out
> > > [19:12:37] Configuring KUnit Kernel ...
> > > [19:12:37] Building KUnit Kernel ...
> > > Populating config with:
> > > $ make ARCH=um O=../kunit.out/ olddefconfig
> > > Building with:
> > > $ make ARCH=um O=../kunit.out/ --jobs=36
> > > ERROR:root:`.exit.text' referenced in section `.uml.exitcall.exit' of arch/um/drivers/virtio_uml.o: defined in discarded section `.exit.text' of arch/um/drivers/virtio_uml.o
> > > collect2: error: ld returned 1 exit status
> > > make[2]: *** [/home/sjpark/linux/scripts/Makefile.vmlinux:34: vmlinux] Error 1
> > > make[1]: *** [/home/sjpark/linux/Makefile:1252: vmlinux] Error 2
> > > make: *** [Makefile:242: __sub-make] Error 2
> > >
[...]
>
> Thank you for sharing your results. I think it may depend on the compiler
> version, because I use a quite old compiler.
>
> $ gcc --version
> gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
I'm still getting the failure on my setup with latest mainline. Could we merge
the fix for now? Or, was there some updates that I was missing?
Thanks,
SJ
[...]
On Tue, Feb 7, 2023 at 7:56 AM SeongJae Park <[email protected]> wrote:
>
> On Mon, 23 Jan 2023 18:27:32 +0000 SeongJae Park <[email protected]> wrote:
>
> > On Mon, 23 Jan 2023 18:09:27 +0900 Masahiro Yamada <[email protected]> wrote:
> >
> > > On Wed, Jan 11, 2023 at 4:14 AM SeongJae Park <[email protected]> wrote:
> > > >
> > > > Hi Masahiro,
> > > >
> > > > On Wed, 11 Jan 2023 03:39:58 +0900 Masahiro Yamada <[email protected]> wrote:
> > > >
> > > > > On Tue, Jan 10, 2023 at 9:32 AM SeongJae Park <[email protected]> wrote:
> > > > > >
> > > > > > On Tue, 3 Jan 2023 11:58:48 +0100 Ard Biesheuvel <[email protected]> wrote:
> > > > > >
> > > > > > > On Tue, 3 Jan 2023 at 03:13, Linus Torvalds
> > > > > > > <[email protected]> wrote:
> > > > > > > >
> > > > > > > > On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <[email protected]> wrote:
> > > > > > > > >
> > > > > > [...]
> > > > > > > --- a/include/asm-generic/vmlinux.lds.h
> > > > > > > +++ b/include/asm-generic/vmlinux.lds.h
> > > > > > > @@ -896,7 +896,7 @@
> > > > > > > * Otherwise, the type of .notes section would become PROGBITS
> > > > > > > instead of NOTES.
> > > > > > > */
> > > > > > > #define NOTES \
> > > > > > > - /DISCARD/ : { *(.note.GNU-stack) } \
> > > > > > > + .note.GNU-stack : { *(.note.GNU-stack) } \
> > > > > > > .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \
> > > > > > > BOUNDED_SECTION_BY(.note.*, _notes) \
> > > > > > > } NOTES_HEADERS \
> > > > > > >
> > > > > > > The .note.GNU-stack has zero size, so the result should be the same.
> > > > > > >
> > > > > >
> > > > > > This also fixes ARCH=um build error on my system.
> > > > > >
> > > > > > Tested-by: SeongJae Park <[email protected]>
> > > > >
> > > > >
> > > > >
> > > > > I am able to build ARCH=um defconfig at least.
> > > > >
> > > > > Can you provide the steps to reproduce the build error?
> > > >
> > > > I do the build for kunit test, like below.
> > > >
> > > > mkdir ../kunit.out
> > > > echo "
> > > > CONFIG_KUNIT=y
> > > >
> > > > CONFIG_DAMON=y
> > > > CONFIG_DAMON_KUNIT_TEST=y
> > > >
> > > > CONFIG_DAMON_VADDR=y
> > > > CONFIG_DAMON_VADDR_KUNIT_TEST=y
> > > >
> > > > CONFIG_DEBUG_FS=y
> > > > CONFIG_DAMON_DBGFS=y
> > > > CONFIG_DAMON_DBGFS_KUNIT_TEST=y
> > > > CONFIG_DAMON_PADDR=y" > ../kunit.out/.kunitconfig
> > > > ./tools/testsing/kunit/kunit.py run --build_dir ../kunit.out
> > > > [19:12:37] Configuring KUnit Kernel ...
> > > > [19:12:37] Building KUnit Kernel ...
> > > > Populating config with:
> > > > $ make ARCH=um O=../kunit.out/ olddefconfig
> > > > Building with:
> > > > $ make ARCH=um O=../kunit.out/ --jobs=36
> > > > ERROR:root:`.exit.text' referenced in section `.uml.exitcall.exit' of arch/um/drivers/virtio_uml.o: defined in discarded section `.exit.text' of arch/um/drivers/virtio_uml.o
> > > > collect2: error: ld returned 1 exit status
> > > > make[2]: *** [/home/sjpark/linux/scripts/Makefile.vmlinux:34: vmlinux] Error 1
> > > > make[1]: *** [/home/sjpark/linux/Makefile:1252: vmlinux] Error 2
> > > > make: *** [Makefile:242: __sub-make] Error 2
> > > >
> [...]
> >
> > Thank you for sharing your results. I think it may depend on the compiler
> > version, because I use a quite old compiler.
> >
> > $ gcc --version
> > gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
>
> I'm still getting the failure on my setup with latest mainline. Could we merge
> the fix for now? Or, was there some updates that I was missing?
>
>
> Thanks,
> SJ
>
> [...]
Sorry for delay. I submitted a patch.
https://lore.kernel.org/all/[email protected]/
--
Best Regards
Masahiro Yamada