* Linux 5.18-rc4 @ 2022-04-24 22:22 Linus Torvalds 2022-04-25 7:32 ` Build regressions/improvements in v5.18-rc4 Geert Uytterhoeven ` (3 more replies) 0 siblings, 4 replies; 17+ messages in thread From: Linus Torvalds @ 2022-04-24 22:22 UTC (permalink / raw) To: Linux Kernel Mailing List Fairly slow and calm week - which makes me just suspect that the other shoe will drop at some point. But maybe things are just going really well this release. It's bound to happen _occasionally_, after all. It's not only a fairly small set of commits, the diffstat is pretty small and flat too. The biggest single patch is literally killing off a zombie file that had already been deleted - well, renamed, really - once, but it didn't know to stay dead, and was resurrected by a merge mistake. The changes are sprinkled all over, they just aren't all that big: arch updates (sound being the bulk of it, but "bulk" really is fairly misleading), some driver updates, a couple of filesystem fixes, memory management, networking, and some tooling (mainly a couple of selftests). Scroll through the shortlog below for an overview of the changes. Linus --- Ahmad Fatoum (1): ASoC: fsl_sai: fix 1:1 bclk:mclk ratio support Ajye Huang (1): ASoC: Intel: sof_rt5682: Add support for max98360a speaker amp on SSP2 Alaa Mohamed (1): xen: Convert kmap() to kmap_local_page() Aleksandr Nogikh (1): kcov: don't generate a warning on vm_insert_page()'s failure Alexey Kardashevskiy (2): KVM: PPC: Fix TCE handling for VFIO powerpc/perf: Fix 32bit compile Alistair Popple (1): mm/mmu_notifier.c: fix race in mmu_interval_notifier_remove() Allen-KH Cheng (1): spi: spi-mtk-nor: initialize spi controller after resume Andy Chi (1): ALSA: hda/realtek: Enable mute/micmute LEDs and limit mic boost on EliteBook 845/865 G9 Anup Patel (1): RISC-V: mm: Fix set_satp_mode() for platform not having Sv57 Arun Ramadoss (1): net: phy: LAN937x: added PHY_POLL_CABLE_TEST flag Athira Rajeev (2): powerpc/perf: Fix power9 event alternatives powerpc/perf: Fix power10 event alternatives Atish Patra (2): RISC-V: KVM: Remove 's' & 'u' as valid ISA extension RISC-V: KVM: Restrict the extensions that can be disabled Bang Li (1): ARC: remove redundant READ_ONCE() in cmpxchg loop Bjorn Andersson (2): Revert "drm: of: Properly try all possible cases for bridge/panel detection" Revert "drm: of: Lookup if child node has panel or bridge" Chao Song (1): ASoC: Intel: soc-acpi: correct device endpoints for max98373 Christian Brauner (2): fs: fix acl translation fs: unset MNT_WRITE_HOLD on failure Christian König (2): drm/radeon: fix logic inversion in radeon_sync_resv drm/amdgpu: partial revert "remove ctx->lock" v2 Christophe JAILLET (3): ASoC: soc-pcm: use GFP_KERNEL when the code is sleepable ASoC: codecs: Fix an error handling path in (rx|tx|va)_macro_probe() ARC: Remove a redundant memset() Christophe Leroy (1): mm, hugetlb: allow for "high" userspace addresses Coly Li (2): bcache: put bch_bio_map() back to correct location in journal_write_unlocked() bcache: fix wrong bdev parameter when calling bio_alloc_clone() in do_bio_hook() Darrick J. Wong (1): ext4: fix fallocate to use file_modified to update permissions consistently Dave Jiang (6): dmaengine: idxd: fix device cleanup on disable dmaengine: idxd: match type for retries var in idxd_enqcmds() dmaengine: idxd: fix retry value to be constant for duration of function call dmaengine: idxd: add RO check for wq max_batch_size write dmaengine: idxd: add RO check for wq max_transfer_size write dmaengine: idxd: skip clearing device context when device is read-only Dave Stevenson (2): drm/panel/raspberrypi-touchscreen: Avoid NULL deref if not initialised drm/panel/raspberrypi-touchscreen: Initialise the bridge in prepare David Ahern (3): xfrm: Pass flowi_oif or l3mdev as oif to xfrm_dst_lookup l3mdev: l3mdev_master_upper_ifindex_by_index_rcu should be using netdev_master_upper_dev_get_rcu net: Handle l3mdev in ip_tunnel_init_flow David Howells (1): rxrpc: Restore removed timer deletion Dmitry Baryshkov (1): drm/msm: Revert "drm/msm: Stop using iommu_present()" Duoming Zhou (2): arch: xtensa: platforms: Fix deadlock in rs_close() drivers: net: hippi: Fix deadlock in rr_close() Eric Dumazet (4): net/sched: cls_u32: fix netns refcount changes in u32_change() net/sched: cls_u32: fix possible leak in u32_init_knode() ipv6: make ip6_rt_gc_expire an atomic_t netlink: reset network and mac headers in netlink_dump() Gongjun Song (1): ALSA: hda: intel-dsp-config: Add RaptorLake PCI IDs Guilherme Amadio (1): perf clang: Fix header include for LLVM >= 14 Guo Ren (1): xtensa: patch_text: Fixup last cpu should be master Hangbin Liu (1): net/packet: fix packet_sock xmit return value checking Hans de Goede (1): Documentation/ABI: sysfs-fs-erofs: Fix Sphinx errors Haowen Bai (1): cifs: Use kzalloc instead of kmalloc/memset Heiner Kallweit (2): ASoC: soc-core: add debugfs_prefix member to snd_soc_component_driver ASoC: meson: aiu: fix duplicate debugfs directory error Herve Codina (1): dmaengine: dw-edma: Fix unaligned 64bit access Hongyu Jin (1): erofs: fix use-after-free of on-stack io[] Horatiu Vultur (1): net: lan966x: Make sure to release ptp interrupt Hui Wang (2): ASoC: cs35l41: Add one more variable in the debug log ASoC: cs35l41: Fix a shift-out-of-bounds warning found by UBSAN Ido Schimmel (2): selftests: mlxsw: vxlan_flooding: Prevent flooding of unwanted packets selftests: mlxsw: vxlan_flooding_ipv6: Prevent flooding of unwanted packets Jens Axboe (1): io_uring: free iovec if file assignment fails Jianglei Nie (1): ice: Fix memory leak in ice_get_orom_civd_data() Jiapeng Chong (1): dmaengine: dw-edma: Fix inconsistent indenting José Roberto de Souza (1): drm/i915/display/psr: Unset enable_psr2_sel_fetch if other checks in intel_psr2_config_valid() fails Julia Lawall (1): ARC: fix typos in comments Kai Vehmanen (2): ALSA: hda/hdmi: fix warning about PCM count when used with SOF ALSA: hda/hdmi: add HDMI codec VID for Raptorlake-P Karol Herbst (1): dma-buf-map: remove renamed header file Ken Kurematsu (1): arm64: fix typos in comments Kevin Groeneveld (1): dmaengine: imx-sdma: fix init of uart scripts Kevin Hao (1): net: stmmac: Use readl_poll_timeout_atomic() in atomic state Krzysztof Kozlowski (2): ARC: dts: align SPI NOR node name with dtschema nfc: MAINTAINERS: add Bug entry Kurt Kanzenbach (1): net: dsa: hellcreek: Calculate checksums in tagger Leo Yan (2): perf script: Always allow field 'data_src' for auxtrace perf report: Set PERF_SAMPLE_DATA_SRC bit for Arm SPE event Like Xu (1): KVM: x86/pmu: Update AMD PMC sample period to fix guest NMI-watchdog Linus Torvalds (3): Revert "fs/pipe: use kvcalloc to allocate a pipe_buffer array" kvmalloc: use vmalloc_huge for vmalloc allocations Linux 5.18-rc4 Lucas De Marchi (1): ALSA: hda/i915: Fix one too many pci_dev_put() Maciej Fijalkowski (2): ice: xsk: check if Rx ring was filled up to the end ice: allow creating VFs for !CONFIG_NET_SWITCHDEV Manasi Navare (1): drm/i915/display/vrr: Reset VRR capable property on a long hpd Manuel Ullmann (1): net: atlantic: invert deep par in pm functions, preventing null derefs Mario Limonciello (1): gpio: Request interrupts after IRQ is initialized Mark Brown (1): ASoC: atmel: Remove system clock tree configuration for at91sam9g20ek Matthew Wilcox (Oracle) (2): tools: Add kmem_cache_alloc_lru() XArray: Disallow sibling entries of nodes Matthias Schiffer (1): spi: cadence-quadspi: fix incorrect supports_op() return value Maurizio Avogadro (1): ALSA: usb-audio: add mapping for MSI MAG X570S Torpedo MAX. Mauro Carvalho Chehab (3): ASoC: Intel: sof_es8336: support a separate gpio to control headphone ASoC: Intel: sof_es8336: add a quirk for headset at mic1 port ASoC: Intel: sof_es8336: Add a quirk for Huawei Matebook D15 Max Filippov (1): xtensa: fix a7 clobbering in coprocessor context load/store Miaoqian Lin (6): ASoC: rk817: Use devm_clk_get() in rk817_platform_probe ASoC: msm8916-wcd-digital: Check failure for devm_snd_soc_register_component dmaengine: imx-sdma: Fix error checking in sdma_event_remap Input: omap4-keypad - fix pm_runtime_get_sync() error checking drm/vc4: Use pm_runtime_resume_and_get to fix pm_runtime_get_sync() usage arm/xen: Fix some refcount leaks Michael Ellerman (1): powerpc/time: Always set decrementer in timer_interrupt() Mika Westerberg (1): spi: intel: Add support for Raptor Lake-S SPI serial flash Mikulas Patocka (1): x86: __memcpy_flushcache: fix wrong alignment if size > 2^32 Miles Chen (1): sound/oss/dmasound: fix 'dmasound_setup' defined but not used Mingwei Zhang (2): KVM: SVM: Flush when freeing encrypted pages even on SME_COHERENT CPUs KVM: SEV: add cache flush to solve SEV cache incoherency issues Muchun Song (1): arm64: mm: fix p?d_leaf() Nadav Amit (1): userfaultfd: mark uffd_wp regardless of VM_WRITE flag Namjae Jeon (3): ksmbd: remove filename in ksmbd_file ksmbd: increment reference count of parent fp ksmbd: set fixed sector size to FS_SECTOR_SIZE_INFORMATION Naoya Horiguchi (1): mm/hwpoison: fix race between hugetlb free/demotion and memory_failure_hugetlb() Nathan Chancellor (1): arm64: Improve HAVE_DYNAMIC_FTRACE_WITH_REGS selection for clang Nicholas Piggin (1): mm/vmalloc: huge vmalloc backing pages should be split rather than compound Nico Pache (1): oom_kill.c: futex: delay the OOM reaper to allow time for proper futex cleanup Nicolas Dichtel (1): doc/ip-sysctl: add bc_forwarding Oliver Hartkopp (1): can: isotp: stop timeout monitoring when no first frame was sent Paolo Bonzini (2): kvm: selftests: do not use bitfields larger than 32-bits for PTEs kvm: selftests: introduce and use more page size-related constants Paolo Valerio (1): openvswitch: fix OOB access in reserve_sfa_size() Paulo Alcantara (2): cifs: fix NULL ptr dereference in refresh_mounts() cifs: use correct lock type in cifs_reconnect() Pavel Begunkov (1): io_uring: fix leaks on IOPOLL and CQE_SKIP Peilin Ye (2): ip6_gre: Avoid updating tunnel->tun_hlen in __gre6_xmit() ip6_gre: Fix skb_under_panic in __gre6_xmit() Peter Ujfalusi (2): ASoC: topology: Correct error handling in soc_tplg_dapm_widget_create() ASoC: SOF: topology: Fix memory leak of scontrol->name Pierre-Louis Bossart (3): ASoC: rt711/5682: check if bus is active before deferred jack detection ASoC: SOF: topology: cleanup dailinks on widget unload ASoC: Intel: sof_es8336: simplify speaker gpio naming Randy Dunlap (3): cpuidle: riscv: support non-SMP config RISC-V: cpuidle: fix Kconfig select for RISCV_SBI_CPUIDLE sparc: cacheflush_32.h needs struct page Richard Fitzgerald (2): ASoC: simple-card-utils: Avoid NULL deref in asoc_simple_set_tdm() firmware: cs_dsp: Fix overrun of unterminated control name string Rob Herring (1): arm_pmu: Validate single/group leader events Rolf Eike Beer (1): arc: drop definitions of pgd_index() and pgd_offset{, _k}() entirely Ronnie Sahlberg (1): cifs: destage any unwritten data to the server before calling copychunk_write Sabrina Dubroca (1): esp: limit skb_page_frag_refill use to a single page Sasha Neftin (3): igc: Fix infinite loop in release_swfw_sync igc: Fix BUG: scheduling while atomic e1000e: Fix possible overflow in LTR decoding Sean Christopherson (9): KVM: x86: Don't re-acquire SRCU lock in complete_emulated_io() KVM: RISC-V: Use kvm_vcpu.srcu_idx, drop RISC-V's unnecessary copy KVM: Add helpers to wrap vcpu->srcu_idx and yell if it's abused KVM: Initialize debugfs_dentry when a VM is created to avoid NULL deref KVM: x86: Tag APICv DISABLE inhibit, not ABSENT, if APICv is disabled KVM: nVMX: Defer APICv updates while L2 is active until L1 is active KVM: x86: Pend KVM_REQ_APICV_UPDATE during vCPU creation to fix a race KVM: x86: Skip KVM_GUESTDBG_BLOCKIRQ APICv update if APICv is disabled KVM: SVM: Simplify and harden helper to flush SEV guest page(s) Sergey Matyukevich (2): ARC: entry: fix syscall_trace_exit argument ARC: atomic: cleanup atomic-llsc definitions Shakeel Butt (1): memcg: sync flush only if periodic flush is delayed Shelby Heffron (1): Input: add Marine Navigation Keycodes Shubhrajyoti Datta (1): EDAC/synopsys: Read the error count from the correct register Sidhartha Kumar (4): selftest/vm: verify mmap addr in mremap_test selftest/vm: verify remap destination address in mremap_test selftest/vm: support xfail in mremap_test selftest/vm: add skip support to mremap_test Song Liu (2): vmalloc: replace VM_NO_HUGE_VMAP with VM_ALLOW_HUGE_VMAP page_alloc: use vmalloc_huge for large system hash Srinivas Kandagatla (1): ASoC: codecs: wcd934x: do not switch off SIDO Buck when codec is in use Stephen Hemminger (1): net: restore alpha order to Ethernet devices in config Sukadev Bhattiprolu (1): powerpc: Update MAINTAINERS for ibmvnic and VAS Tadeusz Struk (1): ext4: limit length to bitmap_maxbytes - blocksize in punch_hole Takashi Iwai (1): ALSA: usb-audio: Clear MIDI port active flag after draining Theodore Ts'o (3): ext4: fix overhead calculation to account for the reserved gdt blocks ext4: force overhead calculation if the s_overhead_cluster makes no sense ext4: update the cached overhead value in the superblock Thomas Huth (1): KVM: selftests: Silence compiler warning in the kvm_page_table_test Thomas Richter (1): perf test: Fix error message for test case 71 on s390, where it is not supported Tim Crawford (1): ALSA: hda/realtek: Add quirk for Clevo NP70PNP Tom Rix (2): scsi: sr: Do not leak information in ioctl KVM: SPDX style and spelling fixes Tony Lu (1): net/smc: Fix sock leak when release after smc_shutdown() Tudor Ambarus (1): spi: atmel-quadspi: Fix the buswidth adjustment between spi-mem and controller Vincenzo Frascino (1): MAINTAINERS: add Vincenzo Frascino to KASAN reviewers Vinicius Costa Gomes (1): igc: Fix suspending when PTM is active Vinod Koul (1): dt-bindings: dmaengine: qcom: gpi: Add minItems for interrupts Vladimir Oltean (1): net: mscc: ocelot: fix broken IP multicast flooding Wanpeng Li (1): x86/kvm: Preserve BSP MSR_KVM_POLL_CONTROL across suspend/resume Wojciech Drewek (1): ice: fix crash in switchdev mode Xiaomeng Tong (4): codecs: rt5682s: fix an incorrect NULL check on list iterator ASoC: soc-dapm: fix two incorrect uses of list iterator ASoC: rt5682: fix an incorrect NULL check on list iterator dma: at_xdmac: fix a missing check on list iterator Xu Yu (1): mm/memory-failure.c: skip huge_zero_page in memory_failure() Ye Bin (4): ext4: fix symlink file size not match to file content ext4: fix bug_on in start_this_handle during umount filesystem ext4: fix use-after-free in ext4_search_dir jbd2: fix a potential race while discarding reserved buffers after an abort Yu Liao (1): ASoC: SOF: topology: Fix memory leak in sof_control_load() Zack Rusin (1): drm/vmwgfx: Fix gem refcounting and memory evictions Zhang Rui (1): perf/x86/cstate: Add SAPPHIRERAPIDS_X CPU support Zheng Bin (1): drm/vc4: Fix build error when CONFIG_DRM_VC4=y && CONFIG_RASPBERRYPI_FIRMWARE=m Zheyu Ma (3): ASoC: wm8731: Disable the regulator when probing fails Input: cypress-sf - register a callback to disable the regulators ata: pata_marvell: Check the 'bmdma_addr' beforing reading Zhipeng Xie (1): perf/core: Fix perf_mmap fail when CONFIG_PERF_USE_VMALLOC enabled kuyo chang (1): sched/pelt: Fix attach_entity_load_avg() corner case suresh kumar (1): bonding: do not discard lowest hash bit for non layer3+4 hashing wangjianjian (C) (1): ext4, doc: fix incorrect h_reserved size zhangqilong (1): dmaengine: mediatek:Fix PM usage reference leak of mtk_uart_apdma_alloc_chan_resources ^ permalink raw reply [flat|nested] 17+ messages in thread
* Build regressions/improvements in v5.18-rc4 2022-04-24 22:22 Linux 5.18-rc4 Linus Torvalds @ 2022-04-25 7:32 ` Geert Uytterhoeven 2022-04-25 7:42 ` Geert Uytterhoeven 2022-04-25 9:50 ` Linux 5.18-rc4 Sudip Mukherjee ` (2 subsequent siblings) 3 siblings, 1 reply; 17+ messages in thread From: Geert Uytterhoeven @ 2022-04-25 7:32 UTC (permalink / raw) To: linux-kernel Below is the list of build error/warning regressions/improvements in v5.18-rc4[1] compared to v5.17[2]. Summarized: - build errors: +28/-5 - build warnings: +19/-16 JFYI, when comparing v5.18-rc4[1] to v5.18-rc3[3], the summaries are: - build errors: +6/-7 - build warnings: +14/-1 Happy fixing! ;-) Thanks to the linux-next team for providing the build service. [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/af2d861d4cd2a4da5137f795ee3509e6f944a25b/ (all 96 configs) [2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/f443e374ae131c168a065ea1748feac6b2e76613/ (all 96 configs) [3] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/b2d229d4ddb17db541098b83524d901257e93845/ (all 96 configs) *** ERRORS *** 28 error regressions: + /kisskb/src/arch/m68k/include/asm/bitops.h: error: array subscript 2 is above array bounds of 'long unsigned int[1]' [-Werror=array-bounds]: => 329:20 + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: .cfi_endproc without corresponding .cfi_startproc: => 32 + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: bad or irreducible absolute expression: => 16 + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: junk at end of line, first unrecognized character is `:': => 16 + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: no such instruction: `be 0x100(%sr2,%r0)': => 29 + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: no such instruction: `ldi 0,%r20': => 30 + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: no such instruction: `ldw 0(%sp),%r31': => 26 + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ble 0x100(%sr2,%r0)': => 51, 46 + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ldi 0,%r25': => 44 + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ldi 1,%r25': => 49 + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ldi 173,%r20': => 50, 45 + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.callinfo': => 40 + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.entry': => 41 + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.exit': => 54 + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.proc': => 39 + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.procend': => 55 + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.stringz': => 76 + /kisskb/src/arch/sparc/kernel/irq_32.c: error: array subscript [16, 79] is outside array bounds of 'struct tt_entry[1]' [-Werror=array-bounds]: => 263:14, 258:14, 262:14, 259:14, 261:46 + /kisskb/src/drivers/gpu/drm/r128/r128_cce.c: error: case label does not reduce to an integer constant: => 417:2, 418:2 + /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/media/platform/nxp/imx-pxp.h: error: initializer element is not constant: => 582:38 + /kisskb/src/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c: error: case label does not reduce to an integer constant: => 4917:4 + /kisskb/src/drivers/scsi/aacraid/commsup.c: error: case label does not reduce to an integer constant: => 1983:2 + /kisskb/src/drivers/usb/typec/tcpm/tcpm.c: error: case label does not reduce to an integer constant: => 4724:3 + /kisskb/src/fs/xfs/xfs_buf.h: error: initializer element is not constant: => 46:23 + error: page_alloc.c: undefined reference to `vmalloc_huge': => .init.text+0x13de), .init.text+0x1458), .init.text+0x1466) 5 error improvements: - /kisskb/src/drivers/vfio/pci/vfio_pci_rdwr.c: error: assignment makes pointer from integer without a cast [-Werror=int-conversion]: 317:9, 324:9 => - /kisskb/src/drivers/vfio/pci/vfio_pci_rdwr.c: error: implicit declaration of function 'ioport_map' [-Werror=implicit-function-declaration]: 317:11 => - /kisskb/src/drivers/vfio/pci/vfio_pci_rdwr.c: error: implicit declaration of function 'ioport_unmap' [-Werror=implicit-function-declaration]: 338:15 => - error: arch/powerpc/kvm/book3s_64_entry.o: relocation truncated to fit: R_PPC64_REL14 (stub) against symbol `machine_check_common' defined in .text section in arch/powerpc/kernel/head_64.o: (.text+0x3e4) => - error: arch/powerpc/kvm/book3s_64_entry.o: relocation truncated to fit: R_PPC64_REL14 (stub) against symbol `system_reset_common' defined in .text section in arch/powerpc/kernel/head_64.o: (.text+0x3ec) => *** WARNINGS *** 19 warning regressions: + /kisskb/src/arch/m68k/include/asm/string.h: warning: '__builtin_memset' offset [0, 11] is out of the bounds [0, 0] [-Warray-bounds]: => 68:25 + /kisskb/src/drivers/net/ethernet/i825xx/sun3_82586.c: warning: array subscript 1 is above array bounds of 'volatile struct transmit_cmd_struct *[1]' [-Warray-bounds]: => 989:108, 989:122 + /kisskb/src/drivers/scsi/mpt3sas/mpt3sas_base.c: warning: array subscript 'Mpi2SasIOUnitPage1_t {aka struct _MPI2_CONFIG_PAGE_SASIOUNIT_1}[0]' is partly outside array bounds of 'unsigned char[20]' [-Warray-bounds]: => 5403:43, 5400:40, 5396:40 + modpost: WARNING: modpost: EXPORT symbol "___rw_read_enter" [vmlinux] version generation failed, symbol will not be versioned.: => N/A + modpost: WARNING: modpost: EXPORT symbol "___rw_read_exit" [vmlinux] version generation failed, symbol will not be versioned.: => N/A + modpost: WARNING: modpost: EXPORT symbol "___rw_read_try" [vmlinux] version generation failed, symbol will not be versioned.: => N/A + modpost: WARNING: modpost: EXPORT symbol "___rw_write_enter" [vmlinux] version generation failed, symbol will not be versioned.: => N/A + modpost: WARNING: modpost: EXPORT symbol "__ashldi3" [vmlinux] version generation failed, symbol will not be versioned.: => N/A + modpost: WARNING: modpost: EXPORT symbol "__ashrdi3" [vmlinux] version generation failed, symbol will not be versioned.: => N/A + modpost: WARNING: modpost: EXPORT symbol "__copy_1page" [vmlinux] version generation failed, symbol will not be versioned.: => N/A + modpost: WARNING: modpost: EXPORT symbol "__divdi3" [vmlinux] version generation failed, symbol will not be versioned.: => N/A + modpost: WARNING: modpost: EXPORT symbol "__lshrdi3" [vmlinux] version generation failed, symbol will not be versioned.: => N/A + modpost: WARNING: modpost: EXPORT symbol "__muldi3" [vmlinux] version generation failed, symbol will not be versioned.: => N/A + modpost: WARNING: modpost: EXPORT symbol "__ndelay" [vmlinux] version generation failed, symbol will not be versioned.: => N/A + modpost: WARNING: modpost: EXPORT symbol "__udelay" [vmlinux] version generation failed, symbol will not be versioned.: => N/A + modpost: WARNING: modpost: EXPORT symbol "_mcount" [vmlinux] version generation failed, symbol will not be versioned.: => N/A + modpost: WARNING: modpost: EXPORT symbol "bzero_1page" [vmlinux] version generation failed, symbol will not be versioned.: => N/A + modpost: WARNING: modpost: EXPORT symbol "empty_zero_page" [vmlinux] version generation failed, symbol will not be versioned.: => N/A + modpost: WARNING: modpost: vmlinux.o(.text.unlikely+0x45d4): Section mismatch in reference from the function __trace_event_discard_commit() to the variable .init.data:initcall_level_names: => N/A 16 warning improvements: - modpost: WARNING: modpost: EXPORT symbol "___rw_read_enter" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "___rw_read_exit" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "___rw_read_try" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "___rw_write_enter" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "__ashldi3" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "__ashrdi3" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "__copy_1page" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "__divdi3" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "__lshrdi3" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "__muldi3" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "__ndelay" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "__udelay" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "_mcount" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "bzero_1page" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "empty_zero_page" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: vmlinux.o(.text.unlikely+0x4530): Section mismatch in reference from the function __trace_event_discard_commit() to the variable .init.data:initcall_level_names: 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] 17+ messages in thread
* Re: Build regressions/improvements in v5.18-rc4 2022-04-25 7:32 ` Build regressions/improvements in v5.18-rc4 Geert Uytterhoeven @ 2022-04-25 7:42 ` Geert Uytterhoeven 0 siblings, 0 replies; 17+ messages in thread From: Geert Uytterhoeven @ 2022-04-25 7:42 UTC (permalink / raw) To: linux-kernel Cc: Song Liu, Christoph Hellwig, Rik van Riel, sparclinux, Philipp Zabel, Mauro Carvalho Chehab, Shawn Guo, Sascha Hauer, linux-media On Mon, 25 Apr 2022, Geert Uytterhoeven wrote: > JFYI, when comparing v5.18-rc4[1] to v5.18-rc3[3], the summaries are: > - build errors: +6/-7 + /kisskb/src/drivers/media/platform/nxp/imx-pxp.h: error: initializer element is not constant: => 582:38 powerpc-gcc5/powerpc-allmodconfig Seen before, looks like one more large 32-bit constant with bit 31 set lacking the "U" suffix. + error: arch/sparc/kernel/head_32.o: relocation truncated to fit: R_SPARC_WDISP22 against `.init.text': => (.head.text+0x5040), (.head.text+0x5100) + error: arch/sparc/kernel/head_32.o: relocation truncated to fit: R_SPARC_WDISP22 against symbol `leon_smp_cpu_startup' defined in .text section in arch/sparc/kernel/trampoline_32.o: => (.init.text+0xa4) + error: arch/sparc/kernel/process_32.o: relocation truncated to fit: R_SPARC_WDISP22 against `.text': => (.fixup+0xc), (.fixup+0x4) + error: arch/sparc/kernel/signal_32.o: relocation truncated to fit: R_SPARC_WDISP22 against `.text': => (.fixup+0x4), (.fixup+0x10), (.fixup+0x34), (.fixup+0x1c), (.fixup+0x28) sparc64/sparc-allmodconfig + error: page_alloc.c: undefined reference to `vmalloc_huge': => .init.text+0x1458), .init.text+0x13de), .init.text+0x1466) sh4-gcc10/se7619_defconfig m68k-gcc8/m5272c3_defconfig m68k-gcc11/m5272c3_defconfig Anything with CONFIG_MMU=n, I guess. vmalloc_huge() is provided by mm/vmalloc.c, which is not compiled if CONFIG_MMU=n. > [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/af2d861d4cd2a4da5137f795ee3509e6f944a25b/ (all 96 configs) > [3] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/b2d229d4ddb17db541098b83524d901257e93845/ (all 96 configs) 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] 17+ messages in thread
* Re: Linux 5.18-rc4 2022-04-24 22:22 Linux 5.18-rc4 Linus Torvalds 2022-04-25 7:32 ` Build regressions/improvements in v5.18-rc4 Geert Uytterhoeven @ 2022-04-25 9:50 ` Sudip Mukherjee 2022-04-25 21:27 ` Andrew Morton 2022-04-25 15:03 ` Guenter Roeck 2022-04-27 17:59 ` Ammar Faizi 3 siblings, 1 reply; 17+ messages in thread From: Sudip Mukherjee @ 2022-04-25 9:50 UTC (permalink / raw) To: Linus Torvalds; +Cc: Linux Kernel Mailing List, Andrew Morton, linux-mm Hi Linus, On Sun, Apr 24, 2022 at 03:22:59PM -0700, Linus Torvalds wrote: > Fairly slow and calm week - which makes me just suspect that the other > shoe will drop at some point. > > But maybe things are just going really well this release. It's bound > to happen _occasionally_, after all. My last night's mainline build failed for arm. Build was with af2d861d4cd2 ("Linux 5.18-rc4"). imxrt_defconfig -> failed lpc18xx_defconfig -> failed mps2_defconfig -> failed stm32_defconfig -> failed vf610m4_defconfig -> failed arm-linux-gnueabi-ld: mm/page_alloc.o: in function `alloc_large_system_hash': page_alloc.c:(.init.text+0xe7c): undefined reference to `vmalloc_huge' -- Regards Sudip ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Linux 5.18-rc4 2022-04-25 9:50 ` Linux 5.18-rc4 Sudip Mukherjee @ 2022-04-25 21:27 ` Andrew Morton 2022-04-25 21:42 ` Linus Torvalds 0 siblings, 1 reply; 17+ messages in thread From: Andrew Morton @ 2022-04-25 21:27 UTC (permalink / raw) To: Sudip Mukherjee Cc: Linus Torvalds, Linux Kernel Mailing List, linux-mm, Song Liu On Mon, 25 Apr 2022 10:50:57 +0100 Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote: > Hi Linus, > > On Sun, Apr 24, 2022 at 03:22:59PM -0700, Linus Torvalds wrote: > > Fairly slow and calm week - which makes me just suspect that the other > > shoe will drop at some point. > > > > But maybe things are just going really well this release. It's bound > > to happen _occasionally_, after all. > > My last night's mainline build failed for arm. > Build was with af2d861d4cd2 ("Linux 5.18-rc4"). > > imxrt_defconfig -> failed > lpc18xx_defconfig -> failed > mps2_defconfig -> failed > stm32_defconfig -> failed > vf610m4_defconfig -> failed > > arm-linux-gnueabi-ld: mm/page_alloc.o: in function `alloc_large_system_hash': > page_alloc.c:(.init.text+0xe7c): undefined reference to `vmalloc_huge' Thanks. oops. We broke nommu. From: Andrew Morton <akpm@linux-foundation.org> Subject: mm/nommu.c: provide vmalloc_huge() for CONFIG_MMU=n Fixes: f2edd118d02dd ("page_alloc: use vmalloc_huge for large system hash") Reported-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Cc: Song Liu <song@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> --- mm/nommu.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/mm/nommu.c~a +++ a/mm/nommu.c @@ -226,6 +226,12 @@ void *vmalloc(unsigned long size) } EXPORT_SYMBOL(vmalloc); +void *vmalloc_huge(unsigned long size, gfp_t gfp_mask) +{ + return vmalloc(size); +} +EXPORT_SYMBOL(vmalloc_huge); + /* * vzalloc - allocate virtually contiguous memory with zero fill * _ I don't see any point in copy-n-pasting the kerneldoc over. Perhaps we should just delete all the copy-n-paste kerneldoc from nommu.c and say "go look at the MMU version of this function". ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Linux 5.18-rc4 2022-04-25 21:27 ` Andrew Morton @ 2022-04-25 21:42 ` Linus Torvalds 0 siblings, 0 replies; 17+ messages in thread From: Linus Torvalds @ 2022-04-25 21:42 UTC (permalink / raw) To: Andrew Morton Cc: Sudip Mukherjee, Linux Kernel Mailing List, Linux-MM, Song Liu On Mon, Apr 25, 2022 at 2:27 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > From: Andrew Morton <akpm@linux-foundation.org> > Subject: mm/nommu.c: provide vmalloc_huge() for CONFIG_MMU=n Note, should already be fixed differently (with an alias) by https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0fc74d820a012550be006ba82dd8f1e3fe6fa9f7 although when I looked at the random collection of vmalloc things it did make me go "hmm". It might be a better long-term idea to only implement the very generic low-level function in mm/vmalloc.c and mm/nommu.c (ie the __vmalloc_node_range() function) and then move all the random wrapper functions into mm/util.c. Because right now we effectively duplicate all those wrapper functions, which is kind of ugly. Linus ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Linux 5.18-rc4 2022-04-24 22:22 Linux 5.18-rc4 Linus Torvalds 2022-04-25 7:32 ` Build regressions/improvements in v5.18-rc4 Geert Uytterhoeven 2022-04-25 9:50 ` Linux 5.18-rc4 Sudip Mukherjee @ 2022-04-25 15:03 ` Guenter Roeck 2022-04-27 17:59 ` Ammar Faizi 3 siblings, 0 replies; 17+ messages in thread From: Guenter Roeck @ 2022-04-25 15:03 UTC (permalink / raw) To: Linus Torvalds; +Cc: Linux Kernel Mailing List On Sun, Apr 24, 2022 at 03:22:59PM -0700, Linus Torvalds wrote: > Fairly slow and calm week - which makes me just suspect that the other > shoe will drop at some point. > > But maybe things are just going really well this release. It's bound > to happen _occasionally_, after all. > > It's not only a fairly small set of commits, the diffstat is pretty > small and flat too. The biggest single patch is literally killing off > a zombie file that had already been deleted - well, renamed, really - > once, but it didn't know to stay dead, and was resurrected by a merge > mistake. > > The changes are sprinkled all over, they just aren't all that big: > arch updates (sound being the bulk of it, but "bulk" really is fairly > misleading), some driver updates, a couple of filesystem fixes, memory > management, networking, and some tooling (mainly a couple of > selftests). > Build results: total: 151 pass: 131 fail: 20 Failed builds: arm:allnoconfig arm:tinyconfig h8300:allnoconfig h8300:tinyconfig h8300:edosk2674_defconfig h8300:h8300h-sim_defconfig h8300:h8s-sim_defconfig m68k:allnoconfig m68k:tinyconfig m68k_nommu:m5272c3_defconfig m68k_nommu:m5307c3_defconfig m68k_nommu:m5249evb_defconfig m68k_nommu:m5407c3_defconfig riscv32:allnoconfig riscv32:tinyconfig riscv:allnoconfig riscv:tinyconfig s390:allmodconfig sh:allnoconfig sh:tinyconfig Qemu test results: total: 489 pass: 486 fail: 3 Failed tests: arm:mps2-an385:mps2_defconfig:mps2-an385:initrd mcf5208evb:m5208:m5208evb_defconfig:initrd xtensa:de212:kc705-nommu:nommu_kc705_defconfig As far as I can see this is all due to error: page_alloc.c: undefined reference to `vmalloc_huge' as already reported. Guenter ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Linux 5.18-rc4 2022-04-24 22:22 Linux 5.18-rc4 Linus Torvalds ` (2 preceding siblings ...) 2022-04-25 15:03 ` Guenter Roeck @ 2022-04-27 17:59 ` Ammar Faizi 2022-04-27 18:31 ` Linus Torvalds 3 siblings, 1 reply; 17+ messages in thread From: Ammar Faizi @ 2022-04-27 17:59 UTC (permalink / raw) To: Linus Torvalds, Linux Kernel Mailing List Cc: Al Viro, Eric Biederman, Kees Cook, linux-fsdevel, linux-mm, linux-kernel, gwml On 4/25/22 5:22 AM, Linus Torvalds wrote: > Fairly slow and calm week - which makes me just suspect that the other > shoe will drop at some point. > > But maybe things are just going really well this release. It's bound > to happen _occasionally_, after all. + fs/exec.c maintainers. Testing Linux 5.18-rc4 on my laptop, it has been running for 2 days. Got the following lockdep splat this night. I don't have the reproducer. If you need more information, feel free to let me know. [78140.503644] ====================================================== [78140.503646] WARNING: possible circular locking dependency detected [78140.503648] 5.18.0-rc4-superb-owl-00006-gd615b5416f8a #12 Tainted: G W [78140.503650] ------------------------------------------------------ [78140.503651] preconv/111629 is trying to acquire lock: [78140.503653] ffff88834d633248 (&ctx->lock){+.+.}-{2:2}, at: update_file_ctx+0x19/0xe0 [78140.503663] but task is already holding lock: [78140.503664] ffff888103d80458 (&newf->file_lock){+.+.}-{2:2}, at: iterate_fd+0x34/0x150 [78140.503669] which lock already depends on the new lock. [78140.503671] the existing dependency chain (in reverse order) is: [78140.503672] -> #4 (&newf->file_lock){+.+.}-{2:2}: [78140.503675] _raw_spin_lock+0x2f/0x40 [78140.503679] seq_show+0x72/0x280 [78140.503681] seq_read_iter+0x125/0x3c0 [78140.503684] seq_read+0xd0/0xe0 [78140.503686] vfs_read+0xf5/0x2f0 [78140.503688] ksys_read+0x58/0xb0 [78140.503690] do_syscall_64+0x3d/0x90 [78140.503693] entry_SYSCALL_64_after_hwframe+0x44/0xae [78140.503695] -> #3 (&p->alloc_lock){+.+.}-{2:2}: [78140.503699] _raw_spin_lock+0x2f/0x40 [78140.503700] newseg+0x25b/0x360 [78140.503703] ipcget+0x3fb/0x480 [78140.503705] __x64_sys_shmget+0x48/0x50 [78140.503708] do_syscall_64+0x3d/0x90 [78140.503710] entry_SYSCALL_64_after_hwframe+0x44/0xae [78140.503713] -> #2 (&new->lock){+.+.}-{2:2}: [78140.503716] _raw_spin_lock+0x2f/0x40 [78140.503718] ipc_addid+0xb3/0x700 [78140.503720] newseg+0x238/0x360 [78140.503722] ipcget+0x3fb/0x480 [78140.503724] __x64_sys_shmget+0x48/0x50 [78140.503727] do_syscall_64+0x3d/0x90 [78140.503729] entry_SYSCALL_64_after_hwframe+0x44/0xae [78140.503731] -> #1 (lock#3){+.+.}-{2:2}: [78140.503735] local_lock_acquire+0x1d/0x70 [78140.503738] __radix_tree_preload+0x38/0x150 [78140.503740] idr_preload+0xa/0x40 [78140.503743] aa_alloc_secid+0x15/0xb0 [78140.503745] aa_label_alloc+0x6c/0x1b0 [78140.503747] aa_label_merge+0x52/0x430 [78140.503750] update_file_ctx+0x3f/0xe0 [78140.503752] aa_file_perm+0x56e/0x5c0 [78140.503754] common_file_perm+0x70/0xd0 [78140.503756] security_mmap_file+0x4b/0xd0 [78140.503759] vm_mmap_pgoff+0x50/0x150 [78140.503761] elf_map+0x9f/0x120 [78140.503763] load_elf_binary+0x521/0xc80 [78140.503767] bprm_execve+0x39f/0x660 [78140.503769] do_execveat_common+0x1d0/0x220 [78140.503771] __x64_sys_execveat+0x3d/0x50 [78140.503773] do_syscall_64+0x3d/0x90 [78140.503775] entry_SYSCALL_64_after_hwframe+0x44/0xae [78140.503777] -> #0 (&ctx->lock){+.+.}-{2:2}: [78140.503780] __lock_acquire+0x1573/0x2ce0 [78140.503783] lock_acquire+0xbd/0x190 [78140.503785] _raw_spin_lock+0x2f/0x40 [78140.503787] update_file_ctx+0x19/0xe0 [78140.503788] aa_file_perm+0x56e/0x5c0 [78140.503790] match_file+0x78/0x90 [78140.503792] iterate_fd+0xae/0x150 [78140.503794] aa_inherit_files+0xbe/0x170 [78140.503796] apparmor_bprm_committing_creds+0x50/0x80 [78140.503798] security_bprm_committing_creds+0x1d/0x30 [78140.503800] begin_new_exec+0x3c5/0x450 [78140.503802] load_elf_binary+0x269/0xc80 [78140.503804] bprm_execve+0x39f/0x660 [78140.503806] do_execveat_common+0x1d0/0x220 [78140.503808] __x64_sys_execve+0x36/0x40 [78140.503809] do_syscall_64+0x3d/0x90 [78140.503812] entry_SYSCALL_64_after_hwframe+0x44/0xae [78140.503815] other info that might help us debug this: [78140.503816] Chain exists of: &ctx->lock --> &p->alloc_lock --> &newf->file_lock [78140.503820] Possible unsafe locking scenario: [78140.503821] CPU0 CPU1 [78140.503823] ---- ---- [78140.503824] lock(&newf->file_lock); [78140.503826] lock(&p->alloc_lock); [78140.503828] lock(&newf->file_lock); [78140.503830] lock(&ctx->lock); [78140.503832] *** DEADLOCK *** [78140.503833] 3 locks held by preconv/111629: [78140.503835] #0: ffff888111b62550 (&sig->cred_guard_mutex){+.+.}-{3:3}, at: bprm_execve+0x39/0x660 [78140.503840] #1: ffff888111b625e8 (&sig->exec_update_lock){++++}-{3:3}, at: exec_mmap+0x4e/0x250 [78140.503844] #2: ffff888103d80458 (&newf->file_lock){+.+.}-{2:2}, at: iterate_fd+0x34/0x150 [78140.503849] stack backtrace: [78140.503851] CPU: 3 PID: 111629 Comm: preconv Tainted: G W 5.18.0-rc4-superb-owl-00006-gd615b5416f8a #12 6fd282a37da6f0e0172ecfa29689f3d250476a2b [78140.503855] Hardware name: HP HP Laptop 14s-dq2xxx/87FD, BIOS F.15 09/15/2021 [78140.503856] Call Trace: [78140.503858] <TASK> [78140.503860] dump_stack_lvl+0x5a/0x74 [78140.503863] check_noncircular+0xd3/0xe0 [78140.503866] ? register_lock_class+0x35/0x2a0 [78140.503870] __lock_acquire+0x1573/0x2ce0 [78140.503872] ? prepend_path+0x375/0x410 [78140.503876] ? d_absolute_path+0x48/0x80 [78140.503879] ? aa_path_name+0x132/0x470 [78140.503883] ? lock_is_held_type+0xd0/0x130 [78140.503886] lock_acquire+0xbd/0x190 [78140.503888] ? update_file_ctx+0x19/0xe0 [78140.503892] _raw_spin_lock+0x2f/0x40 [78140.503894] ? update_file_ctx+0x19/0xe0 [78140.503896] update_file_ctx+0x19/0xe0 [78140.503899] aa_file_perm+0x56e/0x5c0 [78140.503904] ? aa_inherit_files+0x170/0x170 [78140.503906] match_file+0x78/0x90 [78140.503909] iterate_fd+0xae/0x150 [78140.503912] aa_inherit_files+0xbe/0x170 [78140.503915] apparmor_bprm_committing_creds+0x50/0x80 [78140.503918] security_bprm_committing_creds+0x1d/0x30 [78140.503921] begin_new_exec+0x3c5/0x450 [78140.503924] load_elf_binary+0x269/0xc80 [78140.503928] ? lock_release+0x1ee/0x260 [78140.503930] ? bprm_execve+0x399/0x660 [78140.503933] bprm_execve+0x39f/0x660 [78140.503936] do_execveat_common+0x1d0/0x220 [78140.503940] __x64_sys_execve+0x36/0x40 [78140.503942] do_syscall_64+0x3d/0x90 [78140.503946] entry_SYSCALL_64_after_hwframe+0x44/0xae [78140.503948] RIP: 0033:0x7f700a8ea33b [78140.503954] Code: Unable to access opcode bytes at RIP 0x7f700a8ea311. [78140.503955] RSP: 002b:00007fff315e7db8 EFLAGS: 00000246 ORIG_RAX: 000000000000003b [78140.503958] RAX: ffffffffffffffda RBX: 00007fff315e7dc0 RCX: 00007f700a8ea33b [78140.503960] RDX: 000056419e9ea7e0 RSI: 000056419e9e9160 RDI: 00007fff315e7dc0 [78140.503962] RBP: 00007fff315e7f60 R08: 0000000000000008 R09: 0000000000000000 [78140.503964] R10: 0000000000000001 R11: 0000000000000246 R12: 000056419e9ea760 [78140.503965] R13: 000056419e9e9160 R14: 00007fff315e9eb4 R15: 00007fff315e9ebc [78140.503971] </TASK> -- Ammar Faizi ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Linux 5.18-rc4 2022-04-27 17:59 ` Ammar Faizi @ 2022-04-27 18:31 ` Linus Torvalds [not found] ` <87r1414y5v.fsf@email.froward.int.ebiederm.org> 0 siblings, 1 reply; 17+ messages in thread From: Linus Torvalds @ 2022-04-27 18:31 UTC (permalink / raw) To: Ammar Faizi, John Johansen, James Morris, LSM List Cc: Linux Kernel Mailing List, Al Viro, Eric Biederman, Kees Cook, linux-fsdevel, Linux-MM, gwml This looks like it might be AppArmor-related. Adding AppArmor and security module people to the participants. Sorry for top-posting and quoting the whole thing, but this is really just bringing in more people to the discussion. So on the exec path we have apparmor_bprm_committing_creds() -> aa_inherit_files() -> iterate_fd (takes files->file_lock) -> aa_file_perm -> update_file_ctx (takes aa_file_ctx->lock) which gives us that file_lock -> ctx lock order. All within AppArmor. And then we apparently _also_ have the reverse ctx lock -> file_lock order by way of 'alloc_lock', which is the 'task_lock()' thing That one is a horror to decode and I didn't, but seems to go through ipcget -> newseg.. Anybody? Linus On Wed, Apr 27, 2022 at 11:00 AM Ammar Faizi <ammarfaizi2@gnuweeb.org> wrote: > > On 4/25/22 5:22 AM, Linus Torvalds wrote: > > Fairly slow and calm week - which makes me just suspect that the other > > shoe will drop at some point. > > > > But maybe things are just going really well this release. It's bound > > to happen _occasionally_, after all. > > + fs/exec.c maintainers. > > Testing Linux 5.18-rc4 on my laptop, it has been running for 2 days. Got > the following lockdep splat this night. I don't have the reproducer. If > you need more information, feel free to let me know. > > [78140.503644] ====================================================== > [78140.503646] WARNING: possible circular locking dependency detected > [78140.503648] 5.18.0-rc4-superb-owl-00006-gd615b5416f8a #12 Tainted: G W > [78140.503650] ------------------------------------------------------ > [78140.503651] preconv/111629 is trying to acquire lock: > [78140.503653] ffff88834d633248 (&ctx->lock){+.+.}-{2:2}, at: update_file_ctx+0x19/0xe0 > [78140.503663] > but task is already holding lock: > [78140.503664] ffff888103d80458 (&newf->file_lock){+.+.}-{2:2}, at: iterate_fd+0x34/0x150 > [78140.503669] > which lock already depends on the new lock. > > [78140.503671] > the existing dependency chain (in reverse order) is: > [78140.503672] > -> #4 (&newf->file_lock){+.+.}-{2:2}: > [78140.503675] _raw_spin_lock+0x2f/0x40 > [78140.503679] seq_show+0x72/0x280 > [78140.503681] seq_read_iter+0x125/0x3c0 > [78140.503684] seq_read+0xd0/0xe0 > [78140.503686] vfs_read+0xf5/0x2f0 > [78140.503688] ksys_read+0x58/0xb0 > [78140.503690] do_syscall_64+0x3d/0x90 > [78140.503693] entry_SYSCALL_64_after_hwframe+0x44/0xae > [78140.503695] > -> #3 (&p->alloc_lock){+.+.}-{2:2}: > [78140.503699] _raw_spin_lock+0x2f/0x40 > [78140.503700] newseg+0x25b/0x360 > [78140.503703] ipcget+0x3fb/0x480 > [78140.503705] __x64_sys_shmget+0x48/0x50 > [78140.503708] do_syscall_64+0x3d/0x90 > [78140.503710] entry_SYSCALL_64_after_hwframe+0x44/0xae > [78140.503713] > -> #2 (&new->lock){+.+.}-{2:2}: > [78140.503716] _raw_spin_lock+0x2f/0x40 > [78140.503718] ipc_addid+0xb3/0x700 > [78140.503720] newseg+0x238/0x360 > [78140.503722] ipcget+0x3fb/0x480 > [78140.503724] __x64_sys_shmget+0x48/0x50 > [78140.503727] do_syscall_64+0x3d/0x90 > [78140.503729] entry_SYSCALL_64_after_hwframe+0x44/0xae > [78140.503731] > -> #1 (lock#3){+.+.}-{2:2}: > [78140.503735] local_lock_acquire+0x1d/0x70 > [78140.503738] __radix_tree_preload+0x38/0x150 > [78140.503740] idr_preload+0xa/0x40 > [78140.503743] aa_alloc_secid+0x15/0xb0 > [78140.503745] aa_label_alloc+0x6c/0x1b0 > [78140.503747] aa_label_merge+0x52/0x430 > [78140.503750] update_file_ctx+0x3f/0xe0 > [78140.503752] aa_file_perm+0x56e/0x5c0 > [78140.503754] common_file_perm+0x70/0xd0 > [78140.503756] security_mmap_file+0x4b/0xd0 > [78140.503759] vm_mmap_pgoff+0x50/0x150 > [78140.503761] elf_map+0x9f/0x120 > [78140.503763] load_elf_binary+0x521/0xc80 > [78140.503767] bprm_execve+0x39f/0x660 > [78140.503769] do_execveat_common+0x1d0/0x220 > [78140.503771] __x64_sys_execveat+0x3d/0x50 > [78140.503773] do_syscall_64+0x3d/0x90 > [78140.503775] entry_SYSCALL_64_after_hwframe+0x44/0xae > [78140.503777] > -> #0 (&ctx->lock){+.+.}-{2:2}: > [78140.503780] __lock_acquire+0x1573/0x2ce0 > [78140.503783] lock_acquire+0xbd/0x190 > [78140.503785] _raw_spin_lock+0x2f/0x40 > [78140.503787] update_file_ctx+0x19/0xe0 > [78140.503788] aa_file_perm+0x56e/0x5c0 > [78140.503790] match_file+0x78/0x90 > [78140.503792] iterate_fd+0xae/0x150 > [78140.503794] aa_inherit_files+0xbe/0x170 > [78140.503796] apparmor_bprm_committing_creds+0x50/0x80 > [78140.503798] security_bprm_committing_creds+0x1d/0x30 > [78140.503800] begin_new_exec+0x3c5/0x450 > [78140.503802] load_elf_binary+0x269/0xc80 > [78140.503804] bprm_execve+0x39f/0x660 > [78140.503806] do_execveat_common+0x1d0/0x220 > [78140.503808] __x64_sys_execve+0x36/0x40 > [78140.503809] do_syscall_64+0x3d/0x90 > [78140.503812] entry_SYSCALL_64_after_hwframe+0x44/0xae > [78140.503815] > other info that might help us debug this: > > [78140.503816] Chain exists of: > &ctx->lock --> &p->alloc_lock --> &newf->file_lock > > [78140.503820] Possible unsafe locking scenario: > > [78140.503821] CPU0 CPU1 > [78140.503823] ---- ---- > [78140.503824] lock(&newf->file_lock); > [78140.503826] lock(&p->alloc_lock); > [78140.503828] lock(&newf->file_lock); > [78140.503830] lock(&ctx->lock); > [78140.503832] > *** DEADLOCK *** > > [78140.503833] 3 locks held by preconv/111629: > [78140.503835] #0: ffff888111b62550 (&sig->cred_guard_mutex){+.+.}-{3:3}, at: bprm_execve+0x39/0x660 > [78140.503840] #1: ffff888111b625e8 (&sig->exec_update_lock){++++}-{3:3}, at: exec_mmap+0x4e/0x250 > [78140.503844] #2: ffff888103d80458 (&newf->file_lock){+.+.}-{2:2}, at: iterate_fd+0x34/0x150 > [78140.503849] > stack backtrace: > [78140.503851] CPU: 3 PID: 111629 Comm: preconv Tainted: G W 5.18.0-rc4-superb-owl-00006-gd615b5416f8a #12 6fd282a37da6f0e0172ecfa29689f3d250476a2b > [78140.503855] Hardware name: HP HP Laptop 14s-dq2xxx/87FD, BIOS F.15 09/15/2021 > [78140.503856] Call Trace: > [78140.503858] <TASK> > [78140.503860] dump_stack_lvl+0x5a/0x74 > [78140.503863] check_noncircular+0xd3/0xe0 > [78140.503866] ? register_lock_class+0x35/0x2a0 > [78140.503870] __lock_acquire+0x1573/0x2ce0 > [78140.503872] ? prepend_path+0x375/0x410 > [78140.503876] ? d_absolute_path+0x48/0x80 > [78140.503879] ? aa_path_name+0x132/0x470 > [78140.503883] ? lock_is_held_type+0xd0/0x130 > [78140.503886] lock_acquire+0xbd/0x190 > [78140.503888] ? update_file_ctx+0x19/0xe0 > [78140.503892] _raw_spin_lock+0x2f/0x40 > [78140.503894] ? update_file_ctx+0x19/0xe0 > [78140.503896] update_file_ctx+0x19/0xe0 > [78140.503899] aa_file_perm+0x56e/0x5c0 > [78140.503904] ? aa_inherit_files+0x170/0x170 > [78140.503906] match_file+0x78/0x90 > [78140.503909] iterate_fd+0xae/0x150 > [78140.503912] aa_inherit_files+0xbe/0x170 > [78140.503915] apparmor_bprm_committing_creds+0x50/0x80 > [78140.503918] security_bprm_committing_creds+0x1d/0x30 > [78140.503921] begin_new_exec+0x3c5/0x450 > [78140.503924] load_elf_binary+0x269/0xc80 > [78140.503928] ? lock_release+0x1ee/0x260 > [78140.503930] ? bprm_execve+0x399/0x660 > [78140.503933] bprm_execve+0x39f/0x660 > [78140.503936] do_execveat_common+0x1d0/0x220 > [78140.503940] __x64_sys_execve+0x36/0x40 > [78140.503942] do_syscall_64+0x3d/0x90 > [78140.503946] entry_SYSCALL_64_after_hwframe+0x44/0xae > [78140.503948] RIP: 0033:0x7f700a8ea33b > [78140.503954] Code: Unable to access opcode bytes at RIP 0x7f700a8ea311. > [78140.503955] RSP: 002b:00007fff315e7db8 EFLAGS: 00000246 ORIG_RAX: 000000000000003b > [78140.503958] RAX: ffffffffffffffda RBX: 00007fff315e7dc0 RCX: 00007f700a8ea33b > [78140.503960] RDX: 000056419e9ea7e0 RSI: 000056419e9e9160 RDI: 00007fff315e7dc0 > [78140.503962] RBP: 00007fff315e7f60 R08: 0000000000000008 R09: 0000000000000000 > [78140.503964] R10: 0000000000000001 R11: 0000000000000246 R12: 000056419e9ea760 > [78140.503965] R13: 000056419e9e9160 R14: 00007fff315e9eb4 R15: 00007fff315e9ebc > [78140.503971] </TASK> > > -- > Ammar Faizi ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <87r1414y5v.fsf@email.froward.int.ebiederm.org>]
* Re: Linux 5.18-rc4 [not found] ` <87r1414y5v.fsf@email.froward.int.ebiederm.org> @ 2022-06-06 18:28 ` Linus Torvalds 2022-06-06 19:19 ` John Johansen 0 siblings, 1 reply; 17+ messages in thread From: Linus Torvalds @ 2022-06-06 18:28 UTC (permalink / raw) To: Eric W. Biederman Cc: Ammar Faizi, John Johansen, James Morris, LSM List, Linux Kernel Mailing List, Al Viro, Kees Cook, <linux-fsdevel@vger.kernel.org>, Linux-MM, gwml On Mon, Jun 6, 2022 at 8:19 AM Eric W. Biederman <ebiederm@xmission.com> wrote: > Has anyone looked into this lock ordering issues? The deadlock is > >> [78140.503821] CPU0 CPU1 > >> [78140.503823] ---- ---- > >> [78140.503824] lock(&newf->file_lock); > >> [78140.503826] lock(&p->alloc_lock); > >> [78140.503828] lock(&newf->file_lock); > >> [78140.503830] lock(&ctx->lock); and the alloc_lock -> file_lock on CPU1 is trivial - it's seq_show() in fs/proc/fd.c: task_lock(task); files = task->files; if (files) { unsigned int fd = proc_fd(m->private); spin_lock(&files->file_lock); and that looks all normal. But the other chains look painful. I do see the IPC code doing ugly things, in particular I detest this code: task_lock(current); list_add(&shp->shm_clist, ¤t->sysvshm.shm_clist); task_unlock(current); where it is using the task lock to protect the shm_clist list. Nasty. And it's doing that inside the shm_ids.rwsem lock _and_ inside the shp->shm_perm.lock. So the IPC code has newseg() doing shmget -> ipcget(): down_write(ids->rwsem) -> newseg(): ipc_addid gets perm->lock task_lock(current) so you have ids->rwsem -> perm->lock -> alloc_lock there. So now we have that ids->rwsem -> ipcperm->lock -> alloc_lock -> file_lock when you put those sequences together. But I didn't figure out what the security subsystem angle is and how that then apparently mixes things up with execve. Yes, newseg() is doing that error = security_shm_alloc(&shp->shm_perm); while holding rwsem, but I can't see how that matters. From the lockdep output, rwsem doesn't actually seem to be part of the whole sequence. It *looks* like we have apparmour ctx->lock --> radix_tree_preloads.lock --> ipcperm->lock and apparently that's called under the file_lock somewhere, completing the circle. I guess the execve component is that begin_new_exec -> security_bprm_committing_creds -> apparmor_bprm_committing_creds -> aa_inherit_files -> iterate_fd -> *takes file_lock* match_file -> aa_file_perm -> update_file_ctx *takes ctx->lock* so that's how you get file_lock -> ctx->lock. So you have: SHMGET: ipcperm->lock -> alloc_lock /proc: alloc_lock -> file_lock apparmor_bprm_committing_creds: file_lock -> ctx->lock and then all you need is ctx->lock -> ipcperm->lock but I didn't find that part. I suspect that part is that both Apparmor and IPC use the idr local lock. Linus ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Linux 5.18-rc4 2022-06-06 18:28 ` Linus Torvalds @ 2022-06-06 19:19 ` John Johansen 2022-06-06 19:47 ` Linus Torvalds 2022-06-06 20:23 ` Matthew Wilcox 0 siblings, 2 replies; 17+ messages in thread From: John Johansen @ 2022-06-06 19:19 UTC (permalink / raw) To: Linus Torvalds, Eric W. Biederman Cc: Ammar Faizi, James Morris, LSM List, Linux Kernel Mailing List, Al Viro, Kees Cook, linux-fsdevel, Linux-MM, gwml On 6/6/22 11:28, Linus Torvalds wrote: > On Mon, Jun 6, 2022 at 8:19 AM Eric W. Biederman <ebiederm@xmission.com> wrote: >> Has anyone looked into this lock ordering issues? > > The deadlock is > >>>> [78140.503821] CPU0 CPU1 >>>> [78140.503823] ---- ---- >>>> [78140.503824] lock(&newf->file_lock); >>>> [78140.503826] lock(&p->alloc_lock); >>>> [78140.503828] lock(&newf->file_lock); >>>> [78140.503830] lock(&ctx->lock); > > and the alloc_lock -> file_lock on CPU1 is trivial - it's seq_show() > in fs/proc/fd.c: > > task_lock(task); > files = task->files; > if (files) { > unsigned int fd = proc_fd(m->private); > > spin_lock(&files->file_lock); > > and that looks all normal. > > But the other chains look painful. > > I do see the IPC code doing ugly things, in particular I detest this code: > > task_lock(current); > list_add(&shp->shm_clist, ¤t->sysvshm.shm_clist); > task_unlock(current); > > where it is using the task lock to protect the shm_clist list. Nasty. > > And it's doing that inside the shm_ids.rwsem lock _and_ inside the > shp->shm_perm.lock. > > So the IPC code has newseg() doing > > shmget -> > ipcget(): > down_write(ids->rwsem) -> > newseg(): > ipc_addid gets perm->lock > task_lock(current) > > so you have > > ids->rwsem -> perm->lock -> alloc_lock > > there. > > So now we have that > > ids->rwsem -> ipcperm->lock -> alloc_lock -> file_lock > > when you put those sequences together. > > But I didn't figure out what the security subsystem angle is and how > that then apparently mixes things up with execve. > > Yes, newseg() is doing that > > error = security_shm_alloc(&shp->shm_perm); > > while holding rwsem, but I can't see how that matters. From the > lockdep output, rwsem doesn't actually seem to be part of the whole > sequence. > > It *looks* like we have > > apparmour ctx->lock --> > radix_tree_preloads.lock --> > ipcperm->lock > > and apparently that's called under the file_lock somewhere, completing > the circle. > > I guess the execve component is that > > begin_new_exec -> > security_bprm_committing_creds -> > apparmor_bprm_committing_creds -> > aa_inherit_files -> > iterate_fd -> *takes file_lock* > match_file -> > aa_file_perm -> > update_file_ctx *takes ctx->lock* > > so that's how you get file_lock -> ctx->lock. > yes > So you have: > > SHMGET: > ipcperm->lock -> alloc_lock > /proc: > alloc_lock -> file_lock > apparmor_bprm_committing_creds: > file_lock -> ctx->lock > > and then all you need is ctx->lock -> ipcperm->lock but I didn't find that part. > yeah that is the part I got stuck on, before being pulled away from this > I suspect that part is that both Apparmor and IPC use the idr local lock. > bingo, apparmor moved its secids allocation from a custom radix tree to idr in 99cc45e48678 apparmor: Use an IDR to allocate apparmor secids and ipc is using the idr for its id allocation as well I can easily lift the secid() allocation out of the ctx->lock but that would still leave it happening under the file_lock and not fix the problem. I think the quick solution would be for apparmor to stop using idr, reverting back at least temporarily to the custom radix tree. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Linux 5.18-rc4 2022-06-06 19:19 ` John Johansen @ 2022-06-06 19:47 ` Linus Torvalds 2022-06-06 20:23 ` Matthew Wilcox 1 sibling, 0 replies; 17+ messages in thread From: Linus Torvalds @ 2022-06-06 19:47 UTC (permalink / raw) To: John Johansen, Thomas Gleixner Cc: Eric W. Biederman, Ammar Faizi, James Morris, LSM List, Linux Kernel Mailing List, Al Viro, Kees Cook, linux-fsdevel, Linux-MM, gwml On Mon, Jun 6, 2022 at 12:19 PM John Johansen <john.johansen@canonical.com> wrote: > > > I suspect that part is that both Apparmor and IPC use the idr local lock. > > bingo, > > apparmor moved its secids allocation from a custom radix tree to idr in > > 99cc45e48678 apparmor: Use an IDR to allocate apparmor secids > > and ipc is using the idr for its id allocation as well The thing is, I'm not entirely convinced you can deadlock on a local lock. A local lock is per-cpu, so one CPU holding that lock won't actually block another CPU holding it. Even on RT, I think. I *think* local locks are useful for lockdep not because of any lock chains they introduce, but because of how lockdep catches irq mis-use (where they *can* deadlock). But I may be entirely wrong, and maybe that lock chain through the local lock actually does matter. Let's bring in people who actually know what they are doing, rather than my wild speculation. Thomas? Linus ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Linux 5.18-rc4 2022-06-06 19:19 ` John Johansen 2022-06-06 19:47 ` Linus Torvalds @ 2022-06-06 20:23 ` Matthew Wilcox 2022-06-06 21:00 ` John Johansen 1 sibling, 1 reply; 17+ messages in thread From: Matthew Wilcox @ 2022-06-06 20:23 UTC (permalink / raw) To: John Johansen Cc: Linus Torvalds, Eric W. Biederman, Ammar Faizi, James Morris, LSM List, Linux Kernel Mailing List, Al Viro, Kees Cook, linux-fsdevel, Linux-MM, gwml On Mon, Jun 06, 2022 at 12:19:36PM -0700, John Johansen wrote: > > I suspect that part is that both Apparmor and IPC use the idr local lock. > > > bingo, > > apparmor moved its secids allocation from a custom radix tree to idr in > > 99cc45e48678 apparmor: Use an IDR to allocate apparmor secids > > and ipc is using the idr for its id allocation as well > > I can easily lift the secid() allocation out of the ctx->lock but that > would still leave it happening under the file_lock and not fix the problem. > I think the quick solution would be for apparmor to stop using idr, reverting > back at least temporarily to the custom radix tree. How about moving forward to the XArray that doesn't use that horrid prealloc gunk? Compile tested only. diff --git a/security/apparmor/include/secid.h b/security/apparmor/include/secid.h index 48ff1ddecad5..278dff5ecd1f 100644 --- a/security/apparmor/include/secid.h +++ b/security/apparmor/include/secid.h @@ -31,6 +31,4 @@ int aa_alloc_secid(struct aa_label *label, gfp_t gfp); void aa_free_secid(u32 secid); void aa_secid_update(u32 secid, struct aa_label *label); -void aa_secids_init(void); - #endif /* __AA_SECID_H */ diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c index 900bc540656a..9dfb4e4631da 100644 --- a/security/apparmor/lsm.c +++ b/security/apparmor/lsm.c @@ -1857,8 +1857,6 @@ static int __init apparmor_init(void) { int error; - aa_secids_init(); - error = aa_setup_dfa_engine(); if (error) { AA_ERROR("Unable to setup dfa engine\n"); diff --git a/security/apparmor/secid.c b/security/apparmor/secid.c index ce545f99259e..3b08942db1f6 100644 --- a/security/apparmor/secid.c +++ b/security/apparmor/secid.c @@ -13,9 +13,9 @@ #include <linux/errno.h> #include <linux/err.h> #include <linux/gfp.h> -#include <linux/idr.h> #include <linux/slab.h> #include <linux/spinlock.h> +#include <linux/xarray.h> #include "include/cred.h" #include "include/lib.h" @@ -29,8 +29,7 @@ */ #define AA_FIRST_SECID 2 -static DEFINE_IDR(aa_secids); -static DEFINE_SPINLOCK(secid_lock); +static DEFINE_XARRAY_FLAGS(aa_secids, XA_FLAGS_LOCK_IRQ | XA_FLAGS_TRACK_FREE); /* * TODO: allow policy to reserve a secid range? @@ -47,9 +46,9 @@ void aa_secid_update(u32 secid, struct aa_label *label) { unsigned long flags; - spin_lock_irqsave(&secid_lock, flags); - idr_replace(&aa_secids, label, secid); - spin_unlock_irqrestore(&secid_lock, flags); + xa_lock_irqsave(&aa_secids, flags); + __xa_store(&aa_secids, secid, label, 0); + xa_unlock_irqrestore(&aa_secids, flags); } /** @@ -58,13 +57,7 @@ void aa_secid_update(u32 secid, struct aa_label *label) */ struct aa_label *aa_secid_to_label(u32 secid) { - struct aa_label *label; - - rcu_read_lock(); - label = idr_find(&aa_secids, secid); - rcu_read_unlock(); - - return label; + return xa_load(&aa_secids, secid); } int apparmor_secid_to_secctx(u32 secid, char **secdata, u32 *seclen) @@ -126,19 +119,16 @@ int aa_alloc_secid(struct aa_label *label, gfp_t gfp) unsigned long flags; int ret; - idr_preload(gfp); - spin_lock_irqsave(&secid_lock, flags); - ret = idr_alloc(&aa_secids, label, AA_FIRST_SECID, 0, GFP_ATOMIC); - spin_unlock_irqrestore(&secid_lock, flags); - idr_preload_end(); + xa_lock_irqsave(&aa_secids, flags); + ret = __xa_alloc(&aa_secids, &label->secid, label, + XA_LIMIT(AA_FIRST_SECID, INT_MAX), gfp); + xa_unlock_irqrestore(&aa_secids, flags); if (ret < 0) { label->secid = AA_SECID_INVALID; return ret; } - AA_BUG(ret == AA_SECID_INVALID); - label->secid = ret; return 0; } @@ -150,12 +140,7 @@ void aa_free_secid(u32 secid) { unsigned long flags; - spin_lock_irqsave(&secid_lock, flags); - idr_remove(&aa_secids, secid); - spin_unlock_irqrestore(&secid_lock, flags); -} - -void aa_secids_init(void) -{ - idr_init_base(&aa_secids, AA_FIRST_SECID); + xa_lock_irqsave(&aa_secids, flags); + __xa_erase(&aa_secids, secid); + xa_unlock_irqrestore(&aa_secids, flags); } ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: Linux 5.18-rc4 2022-06-06 20:23 ` Matthew Wilcox @ 2022-06-06 21:00 ` John Johansen 2022-06-13 22:48 ` Matthew Wilcox 0 siblings, 1 reply; 17+ messages in thread From: John Johansen @ 2022-06-06 21:00 UTC (permalink / raw) To: Matthew Wilcox Cc: Linus Torvalds, Eric W. Biederman, Ammar Faizi, James Morris, LSM List, Linux Kernel Mailing List, Al Viro, Kees Cook, linux-fsdevel, Linux-MM, gwml On 6/6/22 13:23, Matthew Wilcox wrote: > On Mon, Jun 06, 2022 at 12:19:36PM -0700, John Johansen wrote: >>> I suspect that part is that both Apparmor and IPC use the idr local lock. >>> >> bingo, >> >> apparmor moved its secids allocation from a custom radix tree to idr in >> >> 99cc45e48678 apparmor: Use an IDR to allocate apparmor secids >> >> and ipc is using the idr for its id allocation as well >> >> I can easily lift the secid() allocation out of the ctx->lock but that >> would still leave it happening under the file_lock and not fix the problem. >> I think the quick solution would be for apparmor to stop using idr, reverting >> back at least temporarily to the custom radix tree. > > How about moving forward to the XArray that doesn't use that horrid > prealloc gunk? Compile tested only. > I'm not very familiar with XArray but it does seem like a good fit. We do try to keep the secid allocation dense, ideally no holes. Wrt the current locking issue I want to hear what Thomas has to say. Regardless I am looking into whether we should just switch to XArrays going forward. > > diff --git a/security/apparmor/include/secid.h b/security/apparmor/include/secid.h > index 48ff1ddecad5..278dff5ecd1f 100644 > --- a/security/apparmor/include/secid.h > +++ b/security/apparmor/include/secid.h > @@ -31,6 +31,4 @@ int aa_alloc_secid(struct aa_label *label, gfp_t gfp); > void aa_free_secid(u32 secid); > void aa_secid_update(u32 secid, struct aa_label *label); > > -void aa_secids_init(void); > - > #endif /* __AA_SECID_H */ > diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c > index 900bc540656a..9dfb4e4631da 100644 > --- a/security/apparmor/lsm.c > +++ b/security/apparmor/lsm.c > @@ -1857,8 +1857,6 @@ static int __init apparmor_init(void) > { > int error; > > - aa_secids_init(); > - > error = aa_setup_dfa_engine(); > if (error) { > AA_ERROR("Unable to setup dfa engine\n"); > diff --git a/security/apparmor/secid.c b/security/apparmor/secid.c > index ce545f99259e..3b08942db1f6 100644 > --- a/security/apparmor/secid.c > +++ b/security/apparmor/secid.c > @@ -13,9 +13,9 @@ > #include <linux/errno.h> > #include <linux/err.h> > #include <linux/gfp.h> > -#include <linux/idr.h> > #include <linux/slab.h> > #include <linux/spinlock.h> > +#include <linux/xarray.h> > > #include "include/cred.h" > #include "include/lib.h" > @@ -29,8 +29,7 @@ > */ > #define AA_FIRST_SECID 2 > > -static DEFINE_IDR(aa_secids); > -static DEFINE_SPINLOCK(secid_lock); > +static DEFINE_XARRAY_FLAGS(aa_secids, XA_FLAGS_LOCK_IRQ | XA_FLAGS_TRACK_FREE); > > /* > * TODO: allow policy to reserve a secid range? > @@ -47,9 +46,9 @@ void aa_secid_update(u32 secid, struct aa_label *label) > { > unsigned long flags; > > - spin_lock_irqsave(&secid_lock, flags); > - idr_replace(&aa_secids, label, secid); > - spin_unlock_irqrestore(&secid_lock, flags); > + xa_lock_irqsave(&aa_secids, flags); > + __xa_store(&aa_secids, secid, label, 0); > + xa_unlock_irqrestore(&aa_secids, flags); > } > > /** > @@ -58,13 +57,7 @@ void aa_secid_update(u32 secid, struct aa_label *label) > */ > struct aa_label *aa_secid_to_label(u32 secid) > { > - struct aa_label *label; > - > - rcu_read_lock(); > - label = idr_find(&aa_secids, secid); > - rcu_read_unlock(); > - > - return label; > + return xa_load(&aa_secids, secid); > } > > int apparmor_secid_to_secctx(u32 secid, char **secdata, u32 *seclen) > @@ -126,19 +119,16 @@ int aa_alloc_secid(struct aa_label *label, gfp_t gfp) > unsigned long flags; > int ret; > > - idr_preload(gfp); > - spin_lock_irqsave(&secid_lock, flags); > - ret = idr_alloc(&aa_secids, label, AA_FIRST_SECID, 0, GFP_ATOMIC); > - spin_unlock_irqrestore(&secid_lock, flags); > - idr_preload_end(); > + xa_lock_irqsave(&aa_secids, flags); > + ret = __xa_alloc(&aa_secids, &label->secid, label, > + XA_LIMIT(AA_FIRST_SECID, INT_MAX), gfp); > + xa_unlock_irqrestore(&aa_secids, flags); > > if (ret < 0) { > label->secid = AA_SECID_INVALID; > return ret; > } > > - AA_BUG(ret == AA_SECID_INVALID); > - label->secid = ret; > return 0; > } > > @@ -150,12 +140,7 @@ void aa_free_secid(u32 secid) > { > unsigned long flags; > > - spin_lock_irqsave(&secid_lock, flags); > - idr_remove(&aa_secids, secid); > - spin_unlock_irqrestore(&secid_lock, flags); > -} > - > -void aa_secids_init(void) > -{ > - idr_init_base(&aa_secids, AA_FIRST_SECID); > + xa_lock_irqsave(&aa_secids, flags); > + __xa_erase(&aa_secids, secid); > + xa_unlock_irqrestore(&aa_secids, flags); > } ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Linux 5.18-rc4 2022-06-06 21:00 ` John Johansen @ 2022-06-13 22:48 ` Matthew Wilcox 2022-06-21 20:27 ` John Johansen 0 siblings, 1 reply; 17+ messages in thread From: Matthew Wilcox @ 2022-06-13 22:48 UTC (permalink / raw) To: John Johansen Cc: Linus Torvalds, Eric W. Biederman, Ammar Faizi, James Morris, LSM List, Linux Kernel Mailing List, Al Viro, Kees Cook, linux-fsdevel, Linux-MM, gwml On Mon, Jun 06, 2022 at 02:00:33PM -0700, John Johansen wrote: > On 6/6/22 13:23, Matthew Wilcox wrote: > > On Mon, Jun 06, 2022 at 12:19:36PM -0700, John Johansen wrote: > >>> I suspect that part is that both Apparmor and IPC use the idr local lock. > >>> > >> bingo, > >> > >> apparmor moved its secids allocation from a custom radix tree to idr in > >> > >> 99cc45e48678 apparmor: Use an IDR to allocate apparmor secids > >> > >> and ipc is using the idr for its id allocation as well > >> > >> I can easily lift the secid() allocation out of the ctx->lock but that > >> would still leave it happening under the file_lock and not fix the problem. > >> I think the quick solution would be for apparmor to stop using idr, reverting > >> back at least temporarily to the custom radix tree. > > > > How about moving forward to the XArray that doesn't use that horrid > > prealloc gunk? Compile tested only. > > > > I'm not very familiar with XArray but it does seem like a good fit. We do try > to keep the secid allocation dense, ideally no holes. Wrt the current locking > issue I want to hear what Thomas has to say. Regardless I am looking into > whether we should just switch to XArrays going forward. Nothing from Thomas ... shall we just go with this? Do you want a commit message, etc for the patch? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Linux 5.18-rc4 2022-06-13 22:48 ` Matthew Wilcox @ 2022-06-21 20:27 ` John Johansen 2022-07-13 9:37 ` Ammar Faizi 0 siblings, 1 reply; 17+ messages in thread From: John Johansen @ 2022-06-21 20:27 UTC (permalink / raw) To: Matthew Wilcox Cc: Linus Torvalds, Eric W. Biederman, Ammar Faizi, James Morris, LSM List, Linux Kernel Mailing List, Al Viro, Kees Cook, linux-fsdevel, Linux-MM, gwml On 6/13/22 15:48, Matthew Wilcox wrote: > On Mon, Jun 06, 2022 at 02:00:33PM -0700, John Johansen wrote: >> On 6/6/22 13:23, Matthew Wilcox wrote: >>> On Mon, Jun 06, 2022 at 12:19:36PM -0700, John Johansen wrote: >>>>> I suspect that part is that both Apparmor and IPC use the idr local lock. >>>>> >>>> bingo, >>>> >>>> apparmor moved its secids allocation from a custom radix tree to idr in >>>> >>>> 99cc45e48678 apparmor: Use an IDR to allocate apparmor secids >>>> >>>> and ipc is using the idr for its id allocation as well >>>> >>>> I can easily lift the secid() allocation out of the ctx->lock but that >>>> would still leave it happening under the file_lock and not fix the problem. >>>> I think the quick solution would be for apparmor to stop using idr, reverting >>>> back at least temporarily to the custom radix tree. >>> >>> How about moving forward to the XArray that doesn't use that horrid >>> prealloc gunk? Compile tested only. >>> >> >> I'm not very familiar with XArray but it does seem like a good fit. We do try >> to keep the secid allocation dense, ideally no holes. Wrt the current locking >> issue I want to hear what Thomas has to say. Regardless I am looking into >> whether we should just switch to XArrays going forward. > > Nothing from Thomas ... shall we just go with this? Do you want a > commit message, etc for the patch? Hey Matthew, I have done testing with this and the patch looks good. We will certainly go this route going forward so a commit message, would be good. As for fixing the issue in current kernels. I am not opposed to pulling this back as fixes for 99cc45e48678 apparmor: Use an IDR to allocate apparmor secids but I would like some other peoples opinions on doing that, because we don't understand why we are getting the current lock splat, and without understanding it is a fix by avoiding the issue rather than being sure the actual issue is fixed. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Linux 5.18-rc4 2022-06-21 20:27 ` John Johansen @ 2022-07-13 9:37 ` Ammar Faizi 0 siblings, 0 replies; 17+ messages in thread From: Ammar Faizi @ 2022-07-13 9:37 UTC (permalink / raw) To: John Johansen, Matthew Wilcox Cc: Linus Torvalds, Eric W. Biederman, Ammar Faizi, Al Viro, James Morris, LSM List, Linux Kernel Mailing List, Kees Cook, linux-fsdevel, Linux-MM, GNU/Weeb Mailing List On 6/22/22 3:27 AM, John Johansen wrote: > 99cc45e48678 apparmor: Use an IDR to allocate apparmor secids > > but I would like some other peoples opinions on doing that, because we > don't understand why we are getting the current lock splat, and without > understanding it is a fix by avoiding the issue rather than being sure > the actual issue is fixed. Update from me: I can't reproduce the splat in 5.19.0-rc4. Not sure if it's already fixed though, since it happened randomly and I didn't realize what action provoked the splat. I am running Ubuntu 22.04 for my daily desktop activity. I'll keep my lockdep on and will send you update if it's still triggering. -- Ammar Faizi ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2022-07-13 9:37 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-04-24 22:22 Linux 5.18-rc4 Linus Torvalds 2022-04-25 7:32 ` Build regressions/improvements in v5.18-rc4 Geert Uytterhoeven 2022-04-25 7:42 ` Geert Uytterhoeven 2022-04-25 9:50 ` Linux 5.18-rc4 Sudip Mukherjee 2022-04-25 21:27 ` Andrew Morton 2022-04-25 21:42 ` Linus Torvalds 2022-04-25 15:03 ` Guenter Roeck 2022-04-27 17:59 ` Ammar Faizi 2022-04-27 18:31 ` Linus Torvalds [not found] ` <87r1414y5v.fsf@email.froward.int.ebiederm.org> 2022-06-06 18:28 ` Linus Torvalds 2022-06-06 19:19 ` John Johansen 2022-06-06 19:47 ` Linus Torvalds 2022-06-06 20:23 ` Matthew Wilcox 2022-06-06 21:00 ` John Johansen 2022-06-13 22:48 ` Matthew Wilcox 2022-06-21 20:27 ` John Johansen 2022-07-13 9:37 ` Ammar Faizi
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.