linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Linux 6.2-rc2
@ 2023-01-01 22:01 Linus Torvalds
  2023-01-02 10:20 ` Build regressions/improvements in v6.2-rc2 Geert Uytterhoeven
  2023-01-02 22:56 ` Linux 6.2-rc2 Guenter Roeck
  0 siblings, 2 replies; 24+ messages in thread
From: Linus Torvalds @ 2023-01-01 22:01 UTC (permalink / raw)
  To: Linux Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Build regressions/improvements in v6.2-rc2
  2023-01-01 22:01 Linux 6.2-rc2 Linus Torvalds
@ 2023-01-02 10:20 ` Geert Uytterhoeven
  2023-01-02 22:56 ` Linux 6.2-rc2 Guenter Roeck
  1 sibling, 0 replies; 24+ messages in thread
From: Geert Uytterhoeven @ 2023-01-02 10:20 UTC (permalink / raw)
  To: linux-kernel

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 -- geert@linux-m68k.org

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Linux 6.2-rc2
  2023-01-01 22:01 Linux 6.2-rc2 Linus Torvalds
  2023-01-02 10:20 ` Build regressions/improvements in v6.2-rc2 Geert Uytterhoeven
@ 2023-01-02 22:56 ` Guenter Roeck
  2023-01-03  0:21   ` Linus Torvalds
  1 sibling, 1 reply; 24+ messages in thread
From: Guenter Roeck @ 2023-01-02 22:56 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Linux 6.2-rc2
  2023-01-02 22:56 ` Linux 6.2-rc2 Guenter Roeck
@ 2023-01-03  0:21   ` Linus Torvalds
  2023-01-03  1:45     ` Guenter Roeck
  0 siblings, 1 reply; 24+ messages in thread
From: Linus Torvalds @ 2023-01-03  0:21 UTC (permalink / raw)
  To: Guenter Roeck, Jason A. Donenfeld, Yoshinori Sato, Rich Felker,
	Arnd Bergmann
  Cc: Linux Kernel Mailing List

[ 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 <linux@roeck-us.net> 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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Linux 6.2-rc2
  2023-01-03  0:21   ` Linus Torvalds
@ 2023-01-03  1:45     ` Guenter Roeck
  2023-01-03  2:13       ` Linus Torvalds
  0 siblings, 1 reply; 24+ messages in thread
From: Guenter Roeck @ 2023-01-03  1:45 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Jason A. Donenfeld, Yoshinori Sato, Rich Felker, Arnd Bergmann,
	Linux Kernel Mailing List, Masahiro Yamada, Palmer Dabbelt,
	Ard Biesheuvel

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 <linux@roeck-us.net> 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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Linux 6.2-rc2
  2023-01-03  1:45     ` Guenter Roeck
@ 2023-01-03  2:13       ` Linus Torvalds
  2023-01-03  3:57         ` Guenter Roeck
  2023-01-03 10:58         ` Ard Biesheuvel
  0 siblings, 2 replies; 24+ messages in thread
From: Linus Torvalds @ 2023-01-03  2:13 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Jason A. Donenfeld, Yoshinori Sato, Rich Felker, Arnd Bergmann,
	Linux Kernel Mailing List, Masahiro Yamada, Palmer Dabbelt,
	Ard Biesheuvel

On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <linux@roeck-us.net> 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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Linux 6.2-rc2
  2023-01-03  2:13       ` Linus Torvalds
@ 2023-01-03  3:57         ` Guenter Roeck
  2023-01-03  4:26           ` Nathan Chancellor
  2023-01-03 10:58         ` Ard Biesheuvel
  1 sibling, 1 reply; 24+ messages in thread
From: Guenter Roeck @ 2023-01-03  3:57 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Jason A. Donenfeld, Yoshinori Sato, Rich Felker, Arnd Bergmann,
	Linux Kernel Mailing List, Masahiro Yamada, Palmer Dabbelt,
	Ard Biesheuvel

On Mon, Jan 02, 2023 at 06:13:09PM -0800, Linus Torvalds wrote:
> On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <linux@roeck-us.net> 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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Linux 6.2-rc2
  2023-01-03  3:57         ` Guenter Roeck
@ 2023-01-03  4:26           ` Nathan Chancellor
  2023-01-03  9:14             ` Thorsten Leemhuis
  0 siblings, 1 reply; 24+ messages in thread
From: Nathan Chancellor @ 2023-01-03  4:26 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Linus Torvalds, Jason A. Donenfeld, Yoshinori Sato, Rich Felker,
	Arnd Bergmann, Linux Kernel Mailing List, Masahiro Yamada,
	Palmer Dabbelt, Ard Biesheuvel

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 <linux@roeck-us.net> 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/Y7Jal56f6UBh1abE@dev-arch.thelio-3990X/

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Linux 6.2-rc2
  2023-01-03  4:26           ` Nathan Chancellor
@ 2023-01-03  9:14             ` Thorsten Leemhuis
  0 siblings, 0 replies; 24+ messages in thread
From: Thorsten Leemhuis @ 2023-01-03  9:14 UTC (permalink / raw)
  To: Nathan Chancellor, Guenter Roeck
  Cc: Linus Torvalds, Jason A. Donenfeld, Yoshinori Sato, Rich Felker,
	Arnd Bergmann, Linux Kernel Mailing List, Masahiro Yamada,
	Palmer Dabbelt, Ard Biesheuvel

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 <linux@roeck-us.net> 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/Y7Jal56f6UBh1abE@dev-arch.thelio-3990X/
> 
> 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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Linux 6.2-rc2
  2023-01-03  2:13       ` Linus Torvalds
  2023-01-03  3:57         ` Guenter Roeck
@ 2023-01-03 10:58         ` Ard Biesheuvel
  2023-01-03 11:45           ` Conor Dooley
                             ` (6 more replies)
  1 sibling, 7 replies; 24+ messages in thread
From: Ard Biesheuvel @ 2023-01-03 10:58 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Guenter Roeck, Jason A. Donenfeld, Yoshinori Sato, Rich Felker,
	Arnd Bergmann, Linux Kernel Mailing List, Masahiro Yamada,
	Palmer Dabbelt

On Tue, 3 Jan 2023 at 03:13, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <linux@roeck-us.net> 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.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Linux 6.2-rc2
  2023-01-03 10:58         ` Ard Biesheuvel
@ 2023-01-03 11:45           ` Conor Dooley
  2023-01-03 12:22           ` Guenter Roeck
                             ` (5 subsequent siblings)
  6 siblings, 0 replies; 24+ messages in thread
From: Conor Dooley @ 2023-01-03 11:45 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Linus Torvalds, Guenter Roeck, Jason A. Donenfeld,
	Yoshinori Sato, Rich Felker, Arnd Bergmann,
	Linux Kernel Mailing List, Masahiro Yamada, Palmer Dabbelt

[-- Attachment #1: Type: text/plain, Size: 3298 bytes --]

On Tue, Jan 03, 2023 at 11:58:48AM +0100, Ard Biesheuvel wrote:
> On Tue, 3 Jan 2023 at 03:13, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <linux@roeck-us.net> 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.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Linux 6.2-rc2
  2023-01-03 10:58         ` Ard Biesheuvel
  2023-01-03 11:45           ` Conor Dooley
@ 2023-01-03 12:22           ` Guenter Roeck
  2023-01-03 18:26           ` Nathan Chancellor
                             ` (4 subsequent siblings)
  6 siblings, 0 replies; 24+ messages in thread
From: Guenter Roeck @ 2023-01-03 12:22 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Linus Torvalds, Jason A. Donenfeld, Yoshinori Sato, Rich Felker,
	Arnd Bergmann, Linux Kernel Mailing List, Masahiro Yamada,
	Palmer Dabbelt

On Tue, Jan 03, 2023 at 11:58:48AM +0100, Ard Biesheuvel wrote:
> On Tue, 3 Jan 2023 at 03:13, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <linux@roeck-us.net> 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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Linux 6.2-rc2
  2023-01-03 10:58         ` Ard Biesheuvel
  2023-01-03 11:45           ` Conor Dooley
  2023-01-03 12:22           ` Guenter Roeck
@ 2023-01-03 18:26           ` Nathan Chancellor
  2023-01-03 18:34           ` Linus Torvalds
                             ` (3 subsequent siblings)
  6 siblings, 0 replies; 24+ messages in thread
From: Nathan Chancellor @ 2023-01-03 18:26 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Linus Torvalds, Guenter Roeck, Jason A. Donenfeld,
	Yoshinori Sato, Rich Felker, Arnd Bergmann,
	Linux Kernel Mailing List, Masahiro Yamada, Palmer Dabbelt

On Tue, Jan 03, 2023 at 11:58:48AM +0100, Ard Biesheuvel wrote:
> On Tue, 3 Jan 2023 at 03:13, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <linux@roeck-us.net> 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 <nathan@kernel.org>

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.

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Linux 6.2-rc2
  2023-01-03 10:58         ` Ard Biesheuvel
                             ` (2 preceding siblings ...)
  2023-01-03 18:26           ` Nathan Chancellor
@ 2023-01-03 18:34           ` Linus Torvalds
  2023-01-05 13:44             ` Masahiro Yamada
  2023-01-04 10:34           ` Michael Ellerman
                             ` (2 subsequent siblings)
  6 siblings, 1 reply; 24+ messages in thread
From: Linus Torvalds @ 2023-01-03 18:34 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Guenter Roeck, Jason A. Donenfeld, Yoshinori Sato, Rich Felker,
	Arnd Bergmann, Linux Kernel Mailing List, Masahiro Yamada,
	Palmer Dabbelt

On Tue, Jan 3, 2023 at 2:59 AM Ard Biesheuvel <ardb@kernel.org> 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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Linux 6.2-rc2
  2023-01-03 10:58         ` Ard Biesheuvel
                             ` (3 preceding siblings ...)
  2023-01-03 18:34           ` Linus Torvalds
@ 2023-01-04 10:34           ` Michael Ellerman
  2023-01-10  0:32           ` SeongJae Park
  2023-01-13 14:59           ` Tom Saeger
  6 siblings, 0 replies; 24+ messages in thread
From: Michael Ellerman @ 2023-01-04 10:34 UTC (permalink / raw)
  To: Ard Biesheuvel, Linus Torvalds
  Cc: Guenter Roeck, Jason A. Donenfeld, Yoshinori Sato, Rich Felker,
	Arnd Bergmann, Linux Kernel Mailing List, Masahiro Yamada,
	Palmer Dabbelt, linuxppc-dev

Ard Biesheuvel <ardb@kernel.org> writes:
> On Tue, 3 Jan 2023 at 03:13, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <linux@roeck-us.net> 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 <mpe@ellerman.id.au> (powerpc)

cheers

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Linux 6.2-rc2
  2023-01-03 18:34           ` Linus Torvalds
@ 2023-01-05 13:44             ` Masahiro Yamada
  0 siblings, 0 replies; 24+ messages in thread
From: Masahiro Yamada @ 2023-01-05 13:44 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Ard Biesheuvel, Guenter Roeck, Jason A. Donenfeld,
	Yoshinori Sato, Rich Felker, Arnd Bergmann,
	Linux Kernel Mailing List, Palmer Dabbelt

On Wed, Jan 4, 2023 at 3:34 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Tue, Jan 3, 2023 at 2:59 AM Ard Biesheuvel <ardb@kernel.org> 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 <masahiroy@kernel.org>



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/20230105031306.1455409-1-masahiroy@kernel.org/

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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Linux 6.2-rc2
  2023-01-03 10:58         ` Ard Biesheuvel
                             ` (4 preceding siblings ...)
  2023-01-04 10:34           ` Michael Ellerman
@ 2023-01-10  0:32           ` SeongJae Park
  2023-01-10 18:39             ` Masahiro Yamada
  2023-01-13 14:59           ` Tom Saeger
  6 siblings, 1 reply; 24+ messages in thread
From: SeongJae Park @ 2023-01-10  0:32 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Linus Torvalds, Guenter Roeck, Jason A. Donenfeld,
	Yoshinori Sato, Rich Felker, Arnd Bergmann,
	Linux Kernel Mailing List, Masahiro Yamada, Palmer Dabbelt,
	SeongJae Park

On Tue, 3 Jan 2023 11:58:48 +0100 Ard Biesheuvel <ardb@kernel.org> wrote:

> On Tue, 3 Jan 2023 at 03:13, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <linux@roeck-us.net> 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 <sj@kernel.org>


Thanks,
SJ

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Linux 6.2-rc2
  2023-01-10  0:32           ` SeongJae Park
@ 2023-01-10 18:39             ` Masahiro Yamada
  2023-01-10 19:14               ` SeongJae Park
  0 siblings, 1 reply; 24+ messages in thread
From: Masahiro Yamada @ 2023-01-10 18:39 UTC (permalink / raw)
  To: SeongJae Park
  Cc: Ard Biesheuvel, Linus Torvalds, Guenter Roeck,
	Jason A. Donenfeld, Yoshinori Sato, Rich Felker, Arnd Bergmann,
	Linux Kernel Mailing List, Palmer Dabbelt

On Tue, Jan 10, 2023 at 9:32 AM SeongJae Park <sj@kernel.org> wrote:
>
> On Tue, 3 Jan 2023 11:58:48 +0100 Ard Biesheuvel <ardb@kernel.org> wrote:
>
> > On Tue, 3 Jan 2023 at 03:13, Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
> > >
> > > On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <linux@roeck-us.net> 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 <sj@kernel.org>



I am able to build ARCH=um defconfig at least.

Can you provide the steps to reproduce the build error?




--
Best Regards
Masahiro Yamada

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Linux 6.2-rc2
  2023-01-10 18:39             ` Masahiro Yamada
@ 2023-01-10 19:14               ` SeongJae Park
  2023-01-23  9:09                 ` Masahiro Yamada
  0 siblings, 1 reply; 24+ messages in thread
From: SeongJae Park @ 2023-01-10 19:14 UTC (permalink / raw)
  To: Masahiro Yamada
  Cc: SeongJae Park, Ard Biesheuvel, Linus Torvalds, Guenter Roeck,
	Jason A. Donenfeld, Yoshinori Sato, Rich Felker, Arnd Bergmann,
	Linux Kernel Mailing List, Palmer Dabbelt

Hi Masahiro,

On Wed, 11 Jan 2023 03:39:58 +0900 Masahiro Yamada <masahiroy@kernel.org> wrote:

> On Tue, Jan 10, 2023 at 9:32 AM SeongJae Park <sj@kernel.org> wrote:
> >
> > On Tue, 3 Jan 2023 11:58:48 +0100 Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > > On Tue, 3 Jan 2023 at 03:13, Linus Torvalds
> > > <torvalds@linux-foundation.org> wrote:
> > > >
> > > > On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <linux@roeck-us.net> 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 <sj@kernel.org>
> 
> 
> 
> 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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Linux 6.2-rc2
  2023-01-03 10:58         ` Ard Biesheuvel
                             ` (5 preceding siblings ...)
  2023-01-10  0:32           ` SeongJae Park
@ 2023-01-13 14:59           ` Tom Saeger
  6 siblings, 0 replies; 24+ messages in thread
From: Tom Saeger @ 2023-01-13 14:59 UTC (permalink / raw)
  To: Ard Biesheuvel, Greg Kroah-Hartman, Nick Desaulniers
  Cc: Linus Torvalds, Guenter Roeck, Jason A. Donenfeld,
	Yoshinori Sato, Rich Felker, Arnd Bergmann,
	Linux Kernel Mailing List, Masahiro Yamada, Palmer Dabbelt,
	stable

On Tue, Jan 03, 2023 at 11:58:48AM +0100, Ard Biesheuvel wrote:
> On Tue, 3 Jan 2023 at 03:13, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <linux@roeck-us.net> 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/cover.1670358255.git.tom.saeger@oracle.com/

Perhaps add:

Cc: <stable@vger.kernel.org> # 5.15, 5.10, 5.4

for stable 5.15, 5.10, 5.4
Tested-by: Tom Saeger <tom.saeger@oracle.com>

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Linux 6.2-rc2
  2023-01-10 19:14               ` SeongJae Park
@ 2023-01-23  9:09                 ` Masahiro Yamada
  2023-01-23 18:27                   ` SeongJae Park
  0 siblings, 1 reply; 24+ messages in thread
From: Masahiro Yamada @ 2023-01-23  9:09 UTC (permalink / raw)
  To: SeongJae Park
  Cc: Ard Biesheuvel, Linus Torvalds, Guenter Roeck,
	Jason A. Donenfeld, Yoshinori Sato, Rich Felker, Arnd Bergmann,
	Linux Kernel Mailing List, Palmer Dabbelt

On Wed, Jan 11, 2023 at 4:14 AM SeongJae Park <sj@kernel.org> wrote:
>
> Hi Masahiro,
>
> On Wed, 11 Jan 2023 03:39:58 +0900 Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> > On Tue, Jan 10, 2023 at 9:32 AM SeongJae Park <sj@kernel.org> wrote:
> > >
> > > On Tue, 3 Jan 2023 11:58:48 +0100 Ard Biesheuvel <ardb@kernel.org> wrote:
> > >
> > > > On Tue, 3 Jan 2023 at 03:13, Linus Torvalds
> > > > <torvalds@linux-foundation.org> wrote:
> > > > >
> > > > > On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <linux@roeck-us.net> 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 <sj@kernel.org>
> >
> >
> >
> > 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

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Linux 6.2-rc2
  2023-01-23  9:09                 ` Masahiro Yamada
@ 2023-01-23 18:27                   ` SeongJae Park
  2023-02-06 22:56                     ` SeongJae Park
  0 siblings, 1 reply; 24+ messages in thread
From: SeongJae Park @ 2023-01-23 18:27 UTC (permalink / raw)
  To: Masahiro Yamada
  Cc: SeongJae Park, Ard Biesheuvel, Linus Torvalds, Guenter Roeck,
	Jason A. Donenfeld, Yoshinori Sato, Rich Felker, Arnd Bergmann,
	Linux Kernel Mailing List, Palmer Dabbelt

On Mon, 23 Jan 2023 18:09:27 +0900 Masahiro Yamada <masahiroy@kernel.org> wrote:

> On Wed, Jan 11, 2023 at 4:14 AM SeongJae Park <sj@kernel.org> wrote:
> >
> > Hi Masahiro,
> >
> > On Wed, 11 Jan 2023 03:39:58 +0900 Masahiro Yamada <masahiroy@kernel.org> wrote:
> >
> > > On Tue, Jan 10, 2023 at 9:32 AM SeongJae Park <sj@kernel.org> wrote:
> > > >
> > > > On Tue, 3 Jan 2023 11:58:48 +0100 Ard Biesheuvel <ardb@kernel.org> wrote:
> > > >
> > > > > On Tue, 3 Jan 2023 at 03:13, Linus Torvalds
> > > > > <torvalds@linux-foundation.org> wrote:
> > > > > >
> > > > > > On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <linux@roeck-us.net> 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 <sj@kernel.org>
> > >
> > >
> > >
> > > 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

[...]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Linux 6.2-rc2
  2023-01-23 18:27                   ` SeongJae Park
@ 2023-02-06 22:56                     ` SeongJae Park
  2023-02-08  1:27                       ` Masahiro Yamada
  0 siblings, 1 reply; 24+ messages in thread
From: SeongJae Park @ 2023-02-06 22:56 UTC (permalink / raw)
  To: SeongJae Park
  Cc: Masahiro Yamada, Ard Biesheuvel, Linus Torvalds, Guenter Roeck,
	Jason A. Donenfeld, Yoshinori Sato, Rich Felker, Arnd Bergmann,
	Linux Kernel Mailing List, Palmer Dabbelt

On Mon, 23 Jan 2023 18:27:32 +0000 SeongJae Park <sj@kernel.org> wrote:

> On Mon, 23 Jan 2023 18:09:27 +0900 Masahiro Yamada <masahiroy@kernel.org> wrote:
> 
> > On Wed, Jan 11, 2023 at 4:14 AM SeongJae Park <sj@kernel.org> wrote:
> > >
> > > Hi Masahiro,
> > >
> > > On Wed, 11 Jan 2023 03:39:58 +0900 Masahiro Yamada <masahiroy@kernel.org> wrote:
> > >
> > > > On Tue, Jan 10, 2023 at 9:32 AM SeongJae Park <sj@kernel.org> wrote:
> > > > >
> > > > > On Tue, 3 Jan 2023 11:58:48 +0100 Ard Biesheuvel <ardb@kernel.org> wrote:
> > > > >
> > > > > > On Tue, 3 Jan 2023 at 03:13, Linus Torvalds
> > > > > > <torvalds@linux-foundation.org> wrote:
> > > > > > >
> > > > > > > On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <linux@roeck-us.net> 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 <sj@kernel.org>
> > > >
> > > >
> > > >
> > > > 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

[...]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Linux 6.2-rc2
  2023-02-06 22:56                     ` SeongJae Park
@ 2023-02-08  1:27                       ` Masahiro Yamada
  0 siblings, 0 replies; 24+ messages in thread
From: Masahiro Yamada @ 2023-02-08  1:27 UTC (permalink / raw)
  To: SeongJae Park
  Cc: Ard Biesheuvel, Linus Torvalds, Guenter Roeck,
	Jason A. Donenfeld, Yoshinori Sato, Rich Felker, Arnd Bergmann,
	Linux Kernel Mailing List, Palmer Dabbelt

On Tue, Feb 7, 2023 at 7:56 AM SeongJae Park <sj@kernel.org> wrote:
>
> On Mon, 23 Jan 2023 18:27:32 +0000 SeongJae Park <sj@kernel.org> wrote:
>
> > On Mon, 23 Jan 2023 18:09:27 +0900 Masahiro Yamada <masahiroy@kernel.org> wrote:
> >
> > > On Wed, Jan 11, 2023 at 4:14 AM SeongJae Park <sj@kernel.org> wrote:
> > > >
> > > > Hi Masahiro,
> > > >
> > > > On Wed, 11 Jan 2023 03:39:58 +0900 Masahiro Yamada <masahiroy@kernel.org> wrote:
> > > >
> > > > > On Tue, Jan 10, 2023 at 9:32 AM SeongJae Park <sj@kernel.org> wrote:
> > > > > >
> > > > > > On Tue, 3 Jan 2023 11:58:48 +0100 Ard Biesheuvel <ardb@kernel.org> wrote:
> > > > > >
> > > > > > > On Tue, 3 Jan 2023 at 03:13, Linus Torvalds
> > > > > > > <torvalds@linux-foundation.org> wrote:
> > > > > > > >
> > > > > > > > On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck <linux@roeck-us.net> 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 <sj@kernel.org>
> > > > >
> > > > >
> > > > >
> > > > > 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/20230207164156.537378-1-masahiroy@kernel.org/


-- 
Best Regards
Masahiro Yamada

^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2023-02-08  1:28 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-01 22:01 Linux 6.2-rc2 Linus Torvalds
2023-01-02 10:20 ` Build regressions/improvements in v6.2-rc2 Geert Uytterhoeven
2023-01-02 22:56 ` Linux 6.2-rc2 Guenter Roeck
2023-01-03  0:21   ` Linus Torvalds
2023-01-03  1:45     ` Guenter Roeck
2023-01-03  2:13       ` Linus Torvalds
2023-01-03  3:57         ` Guenter Roeck
2023-01-03  4:26           ` Nathan Chancellor
2023-01-03  9:14             ` Thorsten Leemhuis
2023-01-03 10:58         ` Ard Biesheuvel
2023-01-03 11:45           ` Conor Dooley
2023-01-03 12:22           ` Guenter Roeck
2023-01-03 18:26           ` Nathan Chancellor
2023-01-03 18:34           ` Linus Torvalds
2023-01-05 13:44             ` Masahiro Yamada
2023-01-04 10:34           ` Michael Ellerman
2023-01-10  0:32           ` SeongJae Park
2023-01-10 18:39             ` Masahiro Yamada
2023-01-10 19:14               ` SeongJae Park
2023-01-23  9:09                 ` Masahiro Yamada
2023-01-23 18:27                   ` SeongJae Park
2023-02-06 22:56                     ` SeongJae Park
2023-02-08  1:27                       ` Masahiro Yamada
2023-01-13 14:59           ` Tom Saeger

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).