All of lore.kernel.org
 help / color / mirror / Atom feed
* 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-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-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
                   ` (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

* 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, &current->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, &current->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.