NetBSD Problem Report #57226
From taca@back-street.net Sun Feb 12 18:06:31 2023
Return-Path: <taca@back-street.net>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 12A301A9239
for <gnats-bugs@gnats.NetBSD.org>; Sun, 12 Feb 2023 18:06:31 +0000 (UTC)
Message-Id: <20230212171152.6402DB37F@edge.back-street.net>
Date: Mon, 13 Feb 2023 02:11:52 +0900 (JST)
From: taca@back-street.net
Reply-To: taca@back-street.net
To: gnats-bugs@NetBSD.org
Subject: NetBSD 10_BETA kernel crash
X-Send-Pr-Version: 3.95
>Number: 57226
>Category: kern
>Synopsis: NetBSD 10_BETA kernel crash
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: kern-bug-people
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Feb 12 18:10:01 +0000 2023
>Closed-Date: Wed Jun 28 00:56:31 +0000 2023
>Last-Modified: Wed Jun 28 00:56:31 +0000 2023
>Originator: Takahiro Kambe
>Release: NetBSD 10.0_BETA
>Organization:
Takahiro Kambe
>Environment:
System: NetBSD edge.back-street.net 10.0_BETA NetBSD 10.0_BETA (GENERIC) #8: Sun Feb 12 14:46:56 JST 2023 taca@edge.back-street.net:/data/netbsd-10/amd64/obj/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:
NetBSD 10.0_BETA kernel crash while building packages using
pkg_comp1 (loopback file system?).
It crash with DIAGNOSTIC kernel but it also crash witout DIAGNOSTIC.
Last time, savecore(8) failed to complete saving crash dump.
savecore: check_kmem:429: kvm_read msgbuf: _kvm_kvatop(ffffa30127ad6000)
savecore: reboot after panic: kernel diagnostic assertion "c->c_cpu->cc_lwp == curlwp || c->c_cpu->cc_active != c" failed: file "/data/netbsd/src/sys/kern/kern_timeout.c", line 381 running callout 0xffff924a790ff4c0: c_func (0xffffffff80dea0a3) c_flags (0x100) destroyed from 0xffffffff80e34fc9
savecore: system went down at Mon Feb 13 01:47:55 2023
savecore: writing core to /data/crash/netbsd.50.core
savecore: writing kernel to /data/crash/netbsd.50
savecore: kvm_read ksyms: _kvm_kvatop(8031090500000000)
savecore: (null): Bad address
Here is dmesg:
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013,
2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2023
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 10.0_BETA (GENERIC) #8: Sun Feb 12 14:46:56 JST 2023
taca@edge.back-street.net:/data/netbsd-10/amd64/obj/sys/arch/amd64/compile/GENERIC
total memory = 4095 MB
avail memory = 3935 MB
timecounter: Timecounters tick every 10.000 msec
Kernelized RAIDframe activated
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
mainbus0 (root)
ACPI: RSDP 0x00000000000F6A00 000024 (v02 PTLTD )
ACPI: XSDT 0x00000000BFEEE7E9 00005C (v01 INTEL 440BX 06040000 VMW 01324272)
ACPI: FACP 0x00000000BFEFEE73 0000F4 (v04 INTEL 440BX 06040000 PTL 000F4240)
ACPI: DSDT 0x00000000BFEEEAE7 01038C (v01 PTLTD Custom 06040000 MSFT 03000001)
ACPI: FACS 0x00000000BFEFFFC0 000040
ACPI: BOOT 0x00000000BFEEEABF 000028 (v01 PTLTD $SBFTBL$ 06040000 LTP 00000001)
ACPI: APIC 0x00000000BFEEEA29 000096 (v01 PTLTD ? APIC 06040000 LTP 00000000)
ACPI: MCFG 0x00000000BFEEE9ED 00003C (v01 PTLTD $PCITBL$ 06040000 LTP 00000001)
ACPI: SRAT 0x00000000BFEEE8E5 000108 (v02 VMWARE MEMPLUG 06040000 VMW 00000001)
ACPI: HPET 0x00000000BFEEE8AD 000038 (v01 VMWARE VMW HPET 06040000 VMW 00000001)
ACPI: WAET 0x00000000BFEEE885 000028 (v01 VMWARE VMW WAET 06040000 VMW 00000001)
ACPI: 1 ACPI AML tables successfully acquired and loaded
ioapic0 at mainbus0 apid 3: pa 0xfec00000, version 0x20, 24 pins
cpu0 at mainbus0 apid 0
cpu0: Use lfence to serialize rdtsc
cpu0: Intel(R) Core(TM) i7-8700B CPU @ 3.20GHz, id 0x906ea
cpu0: node 0, package 0, core 0, smt 0
cpu1 at mainbus0 apid 1
cpu1: Intel(R) Core(TM) i7-8700B CPU @ 3.20GHz, id 0x906ea
cpu1: node 0, package 0, core 1, smt 0
cpu2 at mainbus0 apid 2
cpu2: Intel(R) Core(TM) i7-8700B CPU @ 3.20GHz, id 0x906ea
cpu2: node 0, package 0, core 2, smt 0
cpu3 at mainbus0 apid 4
cpu3: Intel(R) Core(TM) i7-8700B CPU @ 3.20GHz, id 0x906ea
cpu3: node 0, package 1, core 0, smt 0
cpu4 at mainbus0 apid 5
cpu4: Intel(R) Core(TM) i7-8700B CPU @ 3.20GHz, id 0x906ea
cpu4: node 0, package 1, core 1, smt 0
cpu5 at mainbus0 apid 6
cpu5: Intel(R) Core(TM) i7-8700B CPU @ 3.20GHz, id 0x906ea
cpu5: node 0, package 1, core 2, smt 0
acpi0 at mainbus0: Intel ACPICA 20221020
acpi0: X/RSDT: OemId <INTEL ,440BX ,06040000>, AslId <VMW ,01324272>
acpi0: MCFG: segment 0, bus 0-127, address 0x00000000f0000000
acpi0: SCI interrupting at int 9
acpi0: fixed power button present
timecounter: Timecounter "ACPI-Fast" frequency 3579545 Hz quality 1000
hpet0 at acpi0: high precision event timer (mem 0xfed00000-0xfed00400)
timecounter: Timecounter "hpet0" frequency 14318180 Hz quality 2000
attimer1 at acpi0 (TIME, PNP0100): io 0x40-0x43 irq 0
pcppi1 at acpi0 (SPKR, PNP0800): io 0x61
spkr0 at pcppi1: PC Speaker
wsbell0 at spkr0 mux 1
midi0 at pcppi1: PC speaker
sysbeep0 at pcppi1
pckbc1 at acpi0 (KBC, PNP0303) (kbd port): io 0x60,0x64 irq 1
pckbc2 at acpi0 (MOUS, VMW0003) (aux port): irq 12
acpiacad0 at acpi0 (ACAD, ACPI0003-1): ACPI AC Adapter
ACPI: Enabled 2 GPEs in block 00 to 0F
attimer1: attached to pcppi1
pckbd0 at pckbc1 (kbd slot)
pckbc1: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard
pms0 at pckbc1 (aux slot)
pckbc1: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pci0 at mainbus0 bus 0: configuration mode 1
pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
pchb0 at pci0 dev 0 function 0: Intel 82443BX Host Bridge/Controller (rev. 0x01)
ppb0 at pci0 dev 1 function 0: Intel 82443BX AGP Interface (rev. 0x01)
pci1 at ppb0 bus 1
pci1: i/o space, memory space enabled
pcib0 at pci0 dev 7 function 0: Intel 82371AB (PIIX4) PCI-ISA Bridge (rev. 0x08)
piixide0 at pci0 dev 7 function 1: Intel 82371AB IDE controller (PIIX4) (rev. 0x01)
piixide0: bus-master DMA support present
piixide0: primary channel configured to compatibility mode
piixide0: primary channel interrupting at ioapic0 pin 14
atabus0 at piixide0 channel 0
piixide0: secondary channel configured to compatibility mode
piixide0: secondary channel interrupting at ioapic0 pin 15
atabus1 at piixide0 channel 1
piixpm0 at pci0 dev 7 function 3: Intel 82371AB (PIIX4) Power Management Controller (rev. 0x08)
timecounter: Timecounter "piixpm0" frequency 3579545 Hz quality 1000
piixpm0: 24-bit timer
piixpm0: SMBus disabled
VMware Virtual Machine Communication Interface (miscellaneous system, revision 0x10) at pci0 dev 7 function 7 not configured
vga0 at pci0 dev 15 function 0: VMware Virtual SVGA II (rev. 0x00)
wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation), using wskbd0
wsmux1: connecting to wsdisplay0
drm at vga0 not configured
mpt0 at pci0 dev 16 function 0: Symbios Logic 53c1020/53c1030 (rev. 0x01)
mpt0: applying 1030 quirk
mpt0: interrupting at ioapic0 pin 17
scsibus0 at mpt0: 16 targets, 8 luns per target
ppb1 at pci0 dev 17 function 0: VMware Virtual PCI Bridge (rev. 0x02)
pci2 at ppb1 bus 2
pci2: i/o space, memory space enabled, rd/line, wr/inv ok
uhci0 at pci2 dev 0 function 0: VMware Virtual UHCI (rev. 0x00)
uhci0: interrupting at ioapic0 pin 18
usb0 at uhci0: USB revision 1.0
wm0 at pci2 dev 1 function 0, 64-bit DMA: Intel i82545EM 1000BASE-T Ethernet (rev. 0x01)
wm0: interrupting at ioapic0 pin 19
wm0: 32-bit 66MHz PCI bus
wm0: 256 words (8 address bits) MicroWire EEPROM
wm0: Ethernet address 00:0c:29:0d:00:c1
wm0: 0x2<LOCK_EECD>
makphy0 at wm0 phy 1: Marvell 88E1011 Gigabit PHY, rev. 3
makphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
eap0 at pci2 dev 2 function 0: Ensoniq AudioPCI 97 (rev. 0x02)
eap0: interrupting at ioapic0 pin 16
eap0: ac97: Crystal CS4297A codec; no 3D stereo
audio0 at eap0: playback, capture, full duplex, independent
audio0: slinear_le:16 2ch 48000Hz, blk 1920 bytes (10ms) for playback
audio0: slinear_le:16 2ch 48000Hz, blk 1920 bytes (10ms) for recording
spkr1 at audio0: PC Speaker (synthesized)
wsbell1 at spkr1 mux 1
midi1 at eap0: AudioPCI MIDI UART
ehci0 at pci2 dev 3 function 0: VMware Virtual EHCI (rev. 0x00)
ehci0: 32-bit DMA
ehci0: interrupting at ioapic0 pin 17
ehci0: EHCI version 1.0
ehci0: Using DMA subregion for control data structures
usb1 at ehci0: USB revision 2.0
ahcisata0 at pci2 dev 5 function 0: VMware AHCI (rev. 0x00)
ahcisata0: 64-bit DMA
ahcisata0: AHCI revision 1.30, 30 ports, 32 slots, CAP 0xc1341f1d<SAM,ISS=0x3=Gen3,SCLO,SNCQ,S64A>
ahcisata0: interrupting at msi0 vec 0
atabus2 at ahcisata0 channel 0
atabus3 at ahcisata0 channel 1
atabus4 at ahcisata0 channel 2
atabus5 at ahcisata0 channel 3
atabus6 at ahcisata0 channel 4
atabus7 at ahcisata0 channel 5
atabus8 at ahcisata0 channel 6
atabus9 at ahcisata0 channel 7
atabus10 at ahcisata0 channel 8
atabus11 at ahcisata0 channel 9
atabus12 at ahcisata0 channel 10
atabus13 at ahcisata0 channel 11
atabus14 at ahcisata0 channel 12
atabus15 at ahcisata0 channel 13
atabus16 at ahcisata0 channel 14
atabus17 at ahcisata0 channel 15
atabus18 at ahcisata0 channel 16
atabus19 at ahcisata0 channel 17
atabus20 at ahcisata0 channel 18
atabus21 at ahcisata0 channel 19
atabus22 at ahcisata0 channel 20
atabus23 at ahcisata0 channel 21
atabus24 at ahcisata0 channel 22
atabus25 at ahcisata0 channel 23
atabus26 at ahcisata0 channel 24
atabus27 at ahcisata0 channel 25
atabus28 at ahcisata0 channel 26
atabus29 at ahcisata0 channel 27
atabus30 at ahcisata0 channel 28
atabus31 at ahcisata0 channel 29
ppb2 at pci0 dev 21 function 0: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb2: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci3 at ppb2 bus 3
pci3: i/o space, memory space enabled, rd/line, wr/inv ok
xhci0 at pci3 dev 0 function 0: VMware product 0779 (rev. 0x00)
xhci0: 64-bit DMA
xhci0: interrupting at msix1 vec 0
xhci0: xHCI version 1.0
usb2 at xhci0: USB revision 3.1
usb3 at xhci0: USB revision 2.0
ppb3 at pci0 dev 21 function 1: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb3: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci4 at ppb3 bus 4
pci4: i/o space, memory space enabled, rd/line, wr/inv ok
ppb4 at pci0 dev 21 function 2: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb4: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci5 at ppb4 bus 5
pci5: i/o space, memory space enabled, rd/line, wr/inv ok
ppb5 at pci0 dev 21 function 3: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb5: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci6 at ppb5 bus 6
pci6: i/o space, memory space enabled, rd/line, wr/inv ok
ppb6 at pci0 dev 21 function 4: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb6: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci7 at ppb6 bus 7
pci7: i/o space, memory space enabled, rd/line, wr/inv ok
ppb7 at pci0 dev 21 function 5: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb7: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci8 at ppb7 bus 8
pci8: i/o space, memory space enabled, rd/line, wr/inv ok
ppb8 at pci0 dev 21 function 6: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb8: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci9 at ppb8 bus 9
pci9: i/o space, memory space enabled, rd/line, wr/inv ok
ppb9 at pci0 dev 21 function 7: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb9: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci10 at ppb9 bus 10
pci10: i/o space, memory space enabled, rd/line, wr/inv ok
ppb10 at pci0 dev 22 function 0: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb10: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci11 at ppb10 bus 11
pci11: i/o space, memory space enabled, rd/line, wr/inv ok
nvme0 at pci11 dev 0 function 0: VMware NVMe (rev. 0x00)
nvme0: NVMe 1.3
nvme0: for admin queue interrupting at msix2 vec 0
nvme0: VMware Virtual NVMe Disk, firmware 1.3, serial VMware NVME_0000
nvme0: for io queue 1 interrupting at msix2 vec 1 affinity to cpu0
nvme0: for io queue 2 interrupting at msix2 vec 2 affinity to cpu1
nvme0: for io queue 3 interrupting at msix2 vec 3 affinity to cpu2
nvme0: for io queue 4 interrupting at msix2 vec 4 affinity to cpu3
nvme0: for io queue 5 interrupting at msix2 vec 5 affinity to cpu4
nvme0: for io queue 6 interrupting at msix2 vec 6 affinity to cpu5
ppb11 at pci0 dev 22 function 1: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb11: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci12 at ppb11 bus 12
pci12: i/o space, memory space enabled, rd/line, wr/inv ok
ppb12 at pci0 dev 22 function 2: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb12: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci13 at ppb12 bus 13
pci13: i/o space, memory space enabled, rd/line, wr/inv ok
ppb13 at pci0 dev 22 function 3: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb13: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci14 at ppb13 bus 14
pci14: i/o space, memory space enabled, rd/line, wr/inv ok
ppb14 at pci0 dev 22 function 4: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb14: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci15 at ppb14 bus 15
pci15: i/o space, memory space enabled, rd/line, wr/inv ok
ppb15 at pci0 dev 22 function 5: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb15: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci16 at ppb15 bus 16
pci16: i/o space, memory space enabled, rd/line, wr/inv ok
ppb16 at pci0 dev 22 function 6: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb16: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci17 at ppb16 bus 17
pci17: i/o space, memory space enabled, rd/line, wr/inv ok
ppb17 at pci0 dev 22 function 7: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb17: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci18 at ppb17 bus 18
pci18: i/o space, memory space enabled, rd/line, wr/inv ok
ppb18 at pci0 dev 23 function 0: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb18: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci19 at ppb18 bus 19
pci19: i/o space, memory space enabled, rd/line, wr/inv ok
ppb19 at pci0 dev 23 function 1: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb19: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci20 at ppb19 bus 20
pci20: i/o space, memory space enabled, rd/line, wr/inv ok
ppb20 at pci0 dev 23 function 2: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb20: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci21 at ppb20 bus 21
pci21: i/o space, memory space enabled, rd/line, wr/inv ok
ppb21 at pci0 dev 23 function 3: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb21: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci22 at ppb21 bus 22
pci22: i/o space, memory space enabled, rd/line, wr/inv ok
ppb22 at pci0 dev 23 function 4: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb22: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci23 at ppb22 bus 23
pci23: i/o space, memory space enabled, rd/line, wr/inv ok
ppb23 at pci0 dev 23 function 5: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb23: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci24 at ppb23 bus 24
pci24: i/o space, memory space enabled, rd/line, wr/inv ok
ppb24 at pci0 dev 23 function 6: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb24: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci25 at ppb24 bus 25
pci25: i/o space, memory space enabled, rd/line, wr/inv ok
ppb25 at pci0 dev 23 function 7: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb25: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci26 at ppb25 bus 26
pci26: i/o space, memory space enabled, rd/line, wr/inv ok
ppb26 at pci0 dev 24 function 0: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb26: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci27 at ppb26 bus 27
pci27: i/o space, memory space enabled, rd/line, wr/inv ok
ppb27 at pci0 dev 24 function 1: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb27: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci28 at ppb27 bus 28
pci28: i/o space, memory space enabled, rd/line, wr/inv ok
ppb28 at pci0 dev 24 function 2: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb28: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci29 at ppb28 bus 29
pci29: i/o space, memory space enabled, rd/line, wr/inv ok
ppb29 at pci0 dev 24 function 3: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb29: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci30 at ppb29 bus 30
pci30: i/o space, memory space enabled, rd/line, wr/inv ok
ppb30 at pci0 dev 24 function 4: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb30: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci31 at ppb30 bus 31
pci31: i/o space, memory space enabled, rd/line, wr/inv ok
ppb31 at pci0 dev 24 function 5: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb31: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci32 at ppb31 bus 32
pci32: i/o space, memory space enabled, rd/line, wr/inv ok
ppb32 at pci0 dev 24 function 6: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb32: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci33 at ppb32 bus 33
pci33: i/o space, memory space enabled, rd/line, wr/inv ok
ppb33 at pci0 dev 24 function 7: VMware Virtual PCI Express Root Port (rev. 0x01)
ppb33: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x32 @ 5.0GT/s
pci34 at ppb33 bus 34
pci34: i/o space, memory space enabled, rd/line, wr/inv ok
isa0 at pcib0
acpicpu0 at cpu0: ACPI CPU
acpicpu0: C1: HLT, lat 0 us, pow 0 mW
vmt0 at cpu0
vmt0: UUID: 564d84b1-112f-8f8b-0e66-1d7e7d8d9d84
acpicpu1 at cpu1: ACPI CPU
acpicpu2 at cpu2: ACPI CPU
acpicpu3 at cpu3: ACPI CPU
acpicpu4 at cpu4: ACPI CPU
acpicpu5 at cpu5: ACPI CPU
timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
timecounter: Timecounter "TSC" frequency 3192026000 Hz quality 3000
uhub0 at usb2acpiacad0: AC adapter online.
: NetBSD (0x0000) xHCI root hub (0x0000), class 9/0, rev 3.00/1.00, addr 0
uhub0: 4 ports with 4 removable, self powered
uhub1 at usb3: NetBSD (0x0000) xHCI root hub (0x0000), class 9/0, rev 2.00/1.00, addr 0
uhub1: 4 ports with 4 removable, self powered
scsibus0: waiting 2 seconds for devices to settle...
uhub2 at usb0: NetBSD (0x0000) UHCI root hub (0x0000), class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
atapibus0 at atabus1: 2 targets
uhub3 at usb1: NetBSD (0x0000) EHCI root hub (0x0000), class 9/0, rev 2.00/1.00, addr 1
uhub3: 6 ports with 6 removable, self powered
cd0 at atapibus0 drive 0: <VMware Virtual IDE CDROM Drive, 10000000000000000001, 00000001> cdrom removable
cd0: 32-bit data port
cd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 2 (Ultra/33)
cd0(piixide0:1:0): using PIO mode 4, Ultra-DMA mode 2 (Ultra/33) (using DMA)
IPsec: Initialized Security Association Processing.
ahcisata0 port 0: device present, speed: 6.0Gb/s
wd0 at atabus2 drive 0
wd0: <VMware Virtual SATA Hard Drive>
wd0: drive supports 255-sector PIO transfers, LBA48 addressing
wd0: 49152 MB, 106522 cyl, 15 head, 63 sec, 512 bytes/sect x 100663296 sectors
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100), NCQ (32 tags)
wd0(ahcisata0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100) (using DMA), NCQ (31 tags)
uhidev0 at uhub1 port 1 configuration 1 interface 0
uhidev0: VMware (0x0e0f) VMware Virtual USB Mouse (0x0003), rev 1.10/1.02, addr 1, iclass 3/0
ums0 at uhidev0: 16 buttons, W and Z dirs
wsmouse1 at ums0 mux 0
uhidev1 at uhub1 port 1 configuration 1 interface 1
uhidev1: VMware (0x0e0f) VMware Virtual USB Mouse (0x0003), rev 1.10/1.02, addr 1, iclass 3/0
ums1 at uhidev1: 16 buttons, W and Z dirs
wsmouse2 at ums1 mux 0
uhub4 at uhub1 port 3: VMware, Inc. (0x0e0f) VMware Virtual USB Hub (0x0002), class 9/0, rev 1.10/1.00, addr 2
uhub4: 7 ports with 7 removable, self powered
uhub5 at uhub1 port 4: VMware, Inc. (0x0e0f) VMware Virtual USB Hub (0x0002), class 9/0, rev 2.00/1.00, addr 3
uhub5: 7 ports with 7 removable, self powered
uhub6 at uhub2 port 2: VMware, Inc. (0x0e0f) VMware Virtual USB Hub (0x0002), class 9/0, rev 1.10/1.00, addr 2
uhub6: 7 ports with 7 removable, self powered
sd0 at scsibus0 target 0 lun 0: <VMware,, VMware Virtual S, 1.0> disk fixed
sd0: 320 GB, 41773 cyl, 255 head, 63 sec, 512 bytes/sect x 671088640 sectors
sd0: sync (6.25ns offset 127), 16-bit (320.000MB/s) transfers, tagged queueing
swwdog0: software watchdog initialized
boot device: wd0
root on wd0a dumps on wd0b
root file system type: ffs
kern.module.path=/stand/amd64/10.0/modules
>How-To-Repeat:
Build many packages using pkg_comp1.
>Fix:
>Release-Note:
>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/57226: NetBSD 10_BETA kernel crash
Date: Mon, 13 Feb 2023 10:28:43 +0100
On Sun, Feb 12, 2023 at 06:10:01PM +0000, taca@back-street.net wrote:
> savecore: reboot after panic: kernel diagnostic assertion "c->c_cpu->cc_lwp == curlwp || c->c_cpu->cc_active != c" failed: file "/data/netbsd/src/sys/kern/kern_timeout.c", line 381 running callout 0xffff924a790ff4c0: c_func (0xffffffff80dea0a3) c_flags (0x100) destroyed from 0xffffffff80e34fc9
Can you use gdb (or addr2line) to identify the two functions mentioned
in the panic? Something like
gdb> list *(0xffffffff80dea0a3)
gdb> list *(0xffffffff80e34fc9)
should do it.
Martin
From: Takahiro Kambe <taca@back-street.net>
To: gnats-bugs@netbsd.org, martin@duskware.de
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: kern/57226: NetBSD 10_BETA kernel crash
Date: Mon, 13 Feb 2023 22:04:29 +0900 (JST)
In message <20230213093003.040721A923A@mollari.NetBSD.org>
on Mon, 13 Feb 2023 09:30:03 +0000 (UTC),
Martin Husemann <martin@duskware.de> wrote:
> On Sun, Feb 12, 2023 at 06:10:01PM +0000, taca@back-street.net wrote:
> > savecore: reboot after panic: kernel diagnostic assertion "c->c_cpu->cc_lwp == curlwp || c->c_cpu->cc_active != c" failed: file "/data/netbsd/src/sys/kern/kern_timeout.c", line 381 running callout 0xffff924a790ff4c0: c_func (0xffffffff80dea0a3) c_flags (0x100) destroyed from 0xffffffff80e34fc9
>
> Can you use gdb (or addr2line) to identify the two functions mentioned
> in the panic? Something like
>
> gdb> list *(0xffffffff80dea0a3)
> gdb> list *(0xffffffff80e34fc9)
>
> should do it.
As I wrote, savecore(8) failed to readable core by gdb.
I'll check it next time.
--
神戸 隆博 / Takahiro Kambe
From: Martin Husemann <martin@duskware.de>
To: Takahiro Kambe <taca@back-street.net>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/57226: NetBSD 10_BETA kernel crash
Date: Mon, 13 Feb 2023 16:03:22 +0100
On Mon, Feb 13, 2023 at 10:04:29PM +0900, Takahiro Kambe wrote:
> > Can you use gdb (or addr2line) to identify the two functions mentioned
> > in the panic? Something like
> >
> > gdb> list *(0xffffffff80dea0a3)
> > gdb> list *(0xffffffff80e34fc9)
> >
> > should do it.
> As I wrote, savecore(8) failed to readable core by gdb.
You do not need a kernel core dump for that, just the /netbsd you were
using at the time of the crash (or even better: the netbsd.gdb version
if you happen to have that in your kernel build directory).
Martin
From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, taca@back-street.net
Subject: re: kern/57226: NetBSD 10_BETA kernel crash
Date: Tue, 14 Feb 2023 05:13:21 +1100
this looks like the same problem ghc94 was triggering for others,
see the thread here:
https://mail-index.netbsd.org/tech-kern/2023/02/05/msg028704.html
.mrg.
From: Takahiro Kambe <taca@back-street.net>
To: martin@duskware.de
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/57226: NetBSD 10_BETA kernel crash
Date: Tue, 14 Feb 2023 14:18:41 +0900 (JST)
In message <20230213150322.GB4036@mail.duskware.de>
on Mon, 13 Feb 2023 16:03:22 +0100,
Martin Husemann <martin@duskware.de> wrote:
> You do not need a kernel core dump for that, just the /netbsd you were
> using at the time of the crash (or even better: the netbsd.gdb version
> if you happen to have that in your kernel build directory).
Oh. I see. Here it is.
>> > Can you use gdb (or addr2line) to identify the two functions mentioned
>> > in the panic? Something like
>> >
>> > gdb> list *(0xffffffff80dea0a3)
(gdb) list *(0xffffffff80dea0a3)
0xffffffff80dea0a3 is in itimer_callout (/data/netbsd/src/sys/kern/kern_time.c:834).
829 * N.B. A delay in processing this callout causes multiple
830 * SIGALRM calls to be compressed into one.
831 */
832 static void
833 itimer_callout(void *arg)
834 {
835 uint64_t last_val, next_val, interval, now_ns;
836 struct timespec now, next;
837 struct itimer * const it = arg;
838 int backwards;
>> > gdb> list *(0xffffffff80e34fc9)
(gdb) list *(0xffffffff80e34fc9)
0xffffffff80e34fc9 is in timerfd_fop_close (/data/netbsd/src/sys/kern/sys_timerfd.c:194).
189
190 itimer_lock();
191 itimer_poison(&tfd->tfd_itimer);
192 itimer_fini(&tfd->tfd_itimer); /* drops itimer lock */
193
194 cv_destroy(&tfd->tfd_read_wait);
195
196 seldestroy(&tfd->tfd_read_sel);
197
198 kmem_free(tfd, sizeof(*tfd));
--
Takahiro Kambe <taca@back-street.net>
From: Takahiro Kambe <taca@back-street.net>
To: mrg@eterna.com.au
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/57226: NetBSD 10_BETA kernel crash
Date: Wed, 15 Feb 2023 01:22:01 +0900 (JST)
In message <29596.1676312001@splode.eterna.com.au>
on Tue, 14 Feb 2023 05:13:21 +1100,
matthew green <mrg@eterna.com.au> wrote:
> this looks like the same problem ghc94 was triggering for others,
> see the thread here:
>
> https://mail-index.netbsd.org/tech-kern/2023/02/05/msg028704.html
Sure, it is!
--
Takahiro Kambe <taca@back-street.net>
From: Takahiro Kambe <taca@back-street.net>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/57226: NetBSD 10_BETA kernel crash
Date: Wed, 15 Feb 2023 22:51:06 +0900 (JST)
Now I got crash dump. Is there any thing to check?
--
Takahiro Kambe <taca@back-street.net>
From: Jason Thorpe <thorpej@me.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org,
gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org,
taca@back-street.net
Subject: Re: kern/57226: NetBSD 10_BETA kernel crash
Date: Fri, 17 Feb 2023 11:33:18 -0800
> On Feb 14, 2023, at 8:25 AM, Takahiro Kambe <taca@back-street.net> =
wrote:
>=20
> The following reply was made to PR kern/57226; it has been noted by =
GNATS.
>=20
> From: Takahiro Kambe <taca@back-street.net>
> To: mrg@eterna.com.au
> Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
> gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
> Subject: Re: kern/57226: NetBSD 10_BETA kernel crash
> Date: Wed, 15 Feb 2023 01:22:01 +0900 (JST)
>=20
> In message <29596.1676312001@splode.eterna.com.au>
> on Tue, 14 Feb 2023 05:13:21 +1100,
> matthew green <mrg@eterna.com.au> wrote:
>> this looks like the same problem ghc94 was triggering for others,
>> see the thread here:
>>=20
>> https://mail-index.netbsd.org/tech-kern/2023/02/05/msg028704.html
> Sure, it is!
Taca =E2=80=94 can you reproduce this at-will?
-- thorpej
From: Takahiro Kambe <taca@back-street.net>
To: thorpej@me.com
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/57226: NetBSD 10_BETA kernel crash
Date: Sat, 18 Feb 2023 11:03:23 +0900 (JST)
In message <93384B5B-A032-46DA-AE2D-8D196925048F@me.com>
on Fri, 17 Feb 2023 11:33:18 -0800,
Jason Thorpe <thorpej@me.com> wrote:
>>> this looks like the same problem ghc94 was triggering for others,
>>> see the thread here:
>>>
>>> https://mail-index.netbsd.org/tech-kern/2023/02/05/msg028704.html
>> Sure, it is!
>
> Taca ― can you reproduce this at-will?
No.
It happens some works on pkg_comp1 environment, operations on loopback
filesystems.
--
Takahiro Kambe <taca@back-street.net>
From: PHO <pho@cielonegro.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/57226: NetBSD 10_BETA kernel crash
Date: Sun, 25 Jun 2023 21:38:03 +0900
I think I found the cause (after a painful debugging session spanning 48
hours):
https://github.com/NetBSD/src/commit/dfe928e33245062241b936a0232d5f6b6a3e98a6
https://github.com/NetBSD/src/commit/736fd5151124eaf2b5de1e6b5f4f0d6c71edd445
I'm currently testing it to see if the problem has really gone away.
From: Taylor R Campbell <riastradh@NetBSD.org>
To: PHO <pho@cielonegro.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/57226: NetBSD 10_BETA kernel crash
Date: Sun, 25 Jun 2023 13:34:57 +0000
> Date: Sun, 25 Jun 2023 21:38:03 +0900
> From: PHO <pho@cielonegro.org>
>=20
> I think I found the cause (after a painful debugging session spanning 48=
=20
> hours):
>=20
> The culprit was callout_halt(). "(c->c_flags & CALLOUT_FIRED) !=3D 0" was=
n't
> the correct way to check if a callout is running. It failed to wait for a
> running callout to finish in the following scenario:
>=20
> 1. cpu0 initializes a callout and schedules it.
> 2. cpu0 invokes callout_softlock() and fires the callout, setting the flag
> CALLOUT_FIRED.
> 3. The callout invokes callout_schedule() to re-schedule itself.
> 4. callout_schedule_locked() clears the flag CALLOUT_FIRED, and releases
> the lock.
> 5. Before the lock is re-acquired by callout_softlock(), cpu1 decides to
> destroy the callout. It first invokes callout_halt() to make sure the
> callout finishes running.
> 6. But since CALLOUT_FIRED has been cleared, callout_halt() thinks it's n=
ot
> running and therefore returns without invoking callout_wait().
> 7. cpu1 proceeds to invoke callout_destroy() while it's still running on
> cpu0. callout_destroy() detects that and panics.
Unfortunately, I don't think this can be the culprit, because:
1. Every path to callout_destroy, in itimer_fini, goes through
itimer_poison.
2. itimer_poison will, under the itimer lock:
(a) set it->it_dying,
(b) callout_halt and wait for any concurrent itimer_callout
3. itimer_callout will not reschedule itself if it->it_dying is set,
i.e., if there's any other threads that could potentially be in the
callout_halt in step 2(b). Nor will any other thread schedule the
callout if it->it_dying is set. And this decision is made under
the lock correctly to synchronize with itimer_poison.
It is part of the API contract that the callout can't be concurrently
rescheduled in order for callout_halt to guarantee that the callout is
no longer running.
As far as I can tell, kern_time.c satisfies that requirement of the
contract. If kern_time.c failed to satisfy that part of the contract,
we would probably see some other kasserts firing about it->it_dying.
So I'm afraid this change will paper over the symptom without fixing
the underlying problem.
From: PHO <pho@cielonegro.org>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/57226: NetBSD 10_BETA kernel crash
Date: Mon, 26 Jun 2023 00:10:04 +0900
On 6/25/23 22:34, Taylor R Campbell wrote:
>
> Unfortunately, I don't think this can be the culprit, because:
>
> 1. Every path to callout_destroy, in itimer_fini, goes through
> itimer_poison.
>
> 2. itimer_poison will, under the itimer lock:
> (a) set it->it_dying,
> (b) callout_halt and wait for any concurrent itimer_callout
>
> 3. itimer_callout will not reschedule itself if it->it_dying is set,
> i.e., if there's any other threads that could potentially be in the
> callout_halt in step 2(b). Nor will any other thread schedule the
> callout if it->it_dying is set. And this decision is made under
> the lock correctly to synchronize with itimer_poison.
But what I found with a bunch of debugging logs is that:
1. cpu0 calls timerfd_create() to initialize an itimer.
2. The same CPU calls timerfd_settime() to schedule the timer.
3. After some ticks itimer_callout() gets invoked. It re-schedules the
callout because it's not dying yet.
4. itimer_callout() releases the itimer lock right before returning.
5. But before itimer_callout() returns and callout_softclock()
re-acquires the callout lock, cpu1 calls timerfd_destroy().
6. cpu1 can acquire the itimer lock (because it's now released), and
calls itimer_poison(). It marks the itimer as dying, but it's too late.
itimer_poison() invokes callout_halt(), which returns without waiting
for the callout to finish because c->c_flags no longer contains
CALLOUT_FIRED. The flag has been cleared on the step 3.
7. cpu1 then calls itimer_fini(), which in turn calls callout_destroy().
cpu0 is still in callout_softclock() and trying to lock the callout,
which makes cpu1 panic.
> It is part of the API contract that the callout can't be concurrently
> rescheduled in order for callout_halt to guarantee that the callout is
> no longer running.
>
> As far as I can tell, kern_time.c satisfies that requirement of the
> contract. If kern_time.c failed to satisfy that part of the contract,
> we would probably see some other kasserts firing about it->it_dying.
>
> So I'm afraid this change will paper over the symptom without fixing
> the underlying problem.
Then kern_time.c indeed fails to satisfy the contract, doesn't it? It's
because the itimer lock is released upon entering and exiting
itimer_callout(). Of course we cannot keep it locked during these
points, so I think the contract is basically unsatisfiable.
From: PHO <pho@cielonegro.org>
To: gnats-bugs@NetBSD.org, Taylor R Campbell <riastradh@NetBSD.org>
Cc:
Subject: Re: kern/57226: NetBSD 10_BETA kernel crash
Date: Mon, 26 Jun 2023 00:38:24 +0900
Okay I confirmed my patches can solve, or at least work around the
issue. I have two additional patches in addition to ones I previously
posted:
https://github.com/NetBSD/src/commit/e6dc9c6f299dd975fdc3e0b9f6ff01e071da6c3c
https://github.com/NetBSD/src/commit/d29213298b81609ed88a0fdb804163d339559f19
Steps to reproduce:
1. From pkgsrc remove lang/ghc94/hacks.mk
2. Build ghc94 and install it.
3. cd ../../converters/pandoc && make install
Without my patches the kernel always crashes before it finishes building
Pandoc. 100% reproducible. After applying the patches I can successfully
build it.
But of course I need input from riastradh@. I won't commit them without
his approval. (Sorry Taylor, I don't actually know your pronouns.)
From: Taylor R Campbell <riastradh@NetBSD.org>
To: PHO <pho@cielonegro.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/57226: NetBSD 10_BETA kernel crash
Date: Sun, 25 Jun 2023 18:37:12 +0000
This is a multi-part message in MIME format.
--=_QSVhpQW7wL2t2ZyM0lNb6kI+m4HN6cIl
Content-Transfer-Encoding: quoted-printable
> Date: Mon, 26 Jun 2023 00:10:04 +0900
> From: PHO <pho@cielonegro.org>
>=20
> But what I found with a bunch of debugging logs is that:
>=20
> 1. cpu0 calls timerfd_create() to initialize an itimer.
>=20
> 2. The same CPU calls timerfd_settime() to schedule the timer.
>=20
> 3. After some ticks itimer_callout() gets invoked. It re-schedules the=20
> callout because it's not dying yet.
>=20
> 4. itimer_callout() releases the itimer lock right before returning.
>=20
> 5. But before itimer_callout() returns and callout_softclock()=20
> re-acquires the callout lock, cpu1 calls timerfd_destroy().
>=20
> 6. cpu1 can acquire the itimer lock (because it's now released), and=20
> calls itimer_poison(). It marks the itimer as dying, but it's too late.=20
> itimer_poison() invokes callout_halt(), which returns without waiting=20
> for the callout to finish because c->c_flags no longer contains=20
> CALLOUT_FIRED. The flag has been cleared on the step 3.
>=20
> 7. cpu1 then calls itimer_fini(), which in turn calls callout_destroy().=
=20
> cpu0 is still in callout_softclock() and trying to lock the callout,=20
> which makes cpu1 panic.
Ah! I understand. The problem is that there is a window between:
/* itimer_callout */
if (!it->it_dying)
callout_schedule(&it->it_ch, ...); /* (A) */
itimer_unlock(it);
return;
/* callout_softclock */
cc->cc_active =3D NULL; /* (B) */
During that time, between (A) and (B), it->it_ch doesn't have
CALLOUT_FIRED set because callout_schedule clears it at (A).
So if another CPU calls itimer_poison and then itimer_fini,
itimer_poison won't wait for (B) to have happened, and itimer_fini can
run before (B), in which case callout_destroy crashes.
The bug is that callout_halt fails to wait for (B).
Nice work! I agree this is the right analysis and correct solution.
Couple nits:
> callout(9): Obtain the lock before checking if a callout is destroyable
>=20
> One cannot safely observe the state of a callout without holding its lock,
> because c->c_flags and c->c_cpu might be getting mutated somewhere else.
Did you observe this to be necessary to fix the problem, or do you
have a theory for why this should be necessary? I don't think it
should be. I think if anything, it should be under #ifdef DEBUG (but
I'm not sure we should keep it at all). The comment you deleted in
this change,
/*
* It's not necessary to lock in order to see the correct value
* of c->c_flags. If the callout could potentially have been
* running, the current thread should have stopped it.
*/
correctly reflects the callout(9) API contract, so if there is any
race here, it is either a bug in callout(9) or a user error -- and we
want to detect it and fail noisily in either case, not suppress it by
taking a lock.
In the other change, which I think is the only one that should be
needed to solve the problem:
> @@ -593,7 +592,7 @@ callout_wait(callout_impl_t *c, void *interlock, kmut=
ex_t *lock)
> * - the callout itself has called callout_halt() (nice!)
> */
> cc =3D c->c_cpu;
I think you need to make sure to load c->c_cpu exactly once here, not
once in callout_wait and then once again in
callout_running_somewhere_else.
It's possible that one can prove it is OK to reload c->c_cpu twice,
but let's keep the change minimal.
In fact for now I would suggest just inlining it in callout_halt so
that the fix is a one-line change to start, and to pull up, and then
we can tidy it up afterward with no-functional-change commits.
> - if (__predict_true(cc->cc_active !=3D c || cc->cc_lwp =3D=3D l))
> + if (__predict_false(!callout_running_somewhere_else(c)))
This should stay __predict_true. Callouts are supposed to be quick,
so by the time we've reloaded c->c_cpu from memory, it may have
changed again, even though the caller already determined
callout_running_somewhere_else returned true.
(Attached are the changes I reviewed, for audit trail.)
--=_QSVhpQW7wL2t2ZyM0lNb6kI+m4HN6cIl
Content-Type: text/plain; charset="ISO-8859-1"; name="736fd5151124eaf2b5de1e6b5f4f0d6c71edd445"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="736fd5151124eaf2b5de1e6b5f4f0d6c71edd445.patch"
From 736fd5151124eaf2b5de1e6b5f4f0d6c71edd445 Mon Sep 17 00:00:00 2001
From: PHO <pho@cielonegro.org>
Date: Sun, 25 Jun 2023 20:15:44 +0900
Subject: [PATCH] callout(9): Fix panic() in callout_destroy() (kern/57226)
The culprit was callout_halt(). "(c->c_flags & CALLOUT_FIRED) !=3D 0" wasn't
the correct way to check if a callout is running. It failed to wait for a
running callout to finish in the following scenario:
1. cpu0 initializes a callout and schedules it.
2. cpu0 invokes callout_softlock() and fires the callout, setting the flag
CALLOUT_FIRED.
3. The callout invokes callout_schedule() to re-schedule itself.
4. callout_schedule_locked() clears the flag CALLOUT_FIRED, and releases
the lock.
5. Before the lock is re-acquired by callout_softlock(), cpu1 decides to
destroy the callout. It first invokes callout_halt() to make sure the
callout finishes running.
6. But since CALLOUT_FIRED has been cleared, callout_halt() thinks it's not
running and therefore returns without invoking callout_wait().
7. cpu1 proceeds to invoke callout_destroy() while it's still running on
cpu0. callout_destroy() detects that and panics.
---
sys/kern/kern_timeout.c | 26 +++++++++++++++++++-------
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/sys/kern/kern_timeout.c b/sys/kern/kern_timeout.c
index 8c2b180c6dae..210f24dc942b 100644
--- a/sys/kern/kern_timeout.c
+++ b/sys/kern/kern_timeout.c
@@ -191,6 +191,7 @@ static struct callout_cpu ccb;
#ifndef CRASH /* _KERNEL */
static void callout_softclock(void *);
static void callout_wait(callout_impl_t *, void *, kmutex_t *);
+static bool callout_running_somewhere_else(callout_impl_t *);
=20
static struct callout_cpu callout_cpu0 __cacheline_aligned;
static void *callout_sih __read_mostly;
@@ -375,7 +376,7 @@ callout_destroy(callout_t *cs)
KASSERTMSG((c->c_flags & CALLOUT_PENDING) =3D=3D 0,
"pending callout %p: c_func (%p) c_flags (%#x) destroyed from %p",
c, c->c_func, c->c_flags, __builtin_return_address(0));
- KASSERTMSG(c->c_cpu->cc_lwp =3D=3D curlwp || c->c_cpu->cc_active !=3D c,
+ KASSERTMSG(!callout_running_somewhere_else(c),
"running callout %p: c_func (%p) c_flags (%#x) destroyed from %p",
c, c->c_func, c->c_flags, __builtin_return_address(0));
c->c_magic =3D 0;
@@ -543,7 +544,6 @@ callout_halt(callout_t *cs, void *interlock)
{
callout_impl_t *c =3D (callout_impl_t *)cs;
kmutex_t *lock;
- int flags;
=20
KASSERT(c->c_magic =3D=3D CALLOUT_MAGIC);
KASSERT(!cpu_intr_p());
@@ -553,11 +553,10 @@ callout_halt(callout_t *cs, void *interlock)
lock =3D callout_lock(c);
SDT_PROBE4(sdt, kernel, callout, halt,
c, c->c_func, c->c_arg, c->c_flags);
- flags =3D c->c_flags;
- if ((flags & CALLOUT_PENDING) !=3D 0)
+ if ((c->c_flags & CALLOUT_PENDING) !=3D 0)
CIRCQ_REMOVE(&c->c_list);
- c->c_flags =3D flags & ~(CALLOUT_PENDING|CALLOUT_FIRED);
- if (__predict_false(flags & CALLOUT_FIRED)) {
+ c->c_flags &=3D ~(CALLOUT_PENDING|CALLOUT_FIRED);
+ if (__predict_false(callout_running_somewhere_else(c))) {
callout_wait(c, interlock, lock);
return true;
}
@@ -593,7 +592,7 @@ callout_wait(callout_impl_t *c, void *interlock, kmutex=
_t *lock)
* - the callout itself has called callout_halt() (nice!)
*/
cc =3D c->c_cpu;
- if (__predict_true(cc->cc_active !=3D c || cc->cc_lwp =3D=3D l))
+ if (__predict_false(!callout_running_somewhere_else(c)))
break;
=20
/* It's running - need to wait for it to complete. */
@@ -770,6 +769,19 @@ callout_ack(callout_t *cs)
mutex_spin_exit(lock);
}
=20
+/*
+ * Check if the callout is currently running on an LWP that isn't curlwp.
+ */
+static bool
+callout_running_somewhere_else(callout_impl_t *c)
+{
+ struct callout_cpu *cc =3D c->c_cpu;
+
+ KASSERT(mutex_owned(cc->cc_lock));
+
+ return cc->cc_active =3D=3D c && cc->cc_lwp !=3D curlwp;
+}
+
/*
* callout_hardclock:
*
--=_QSVhpQW7wL2t2ZyM0lNb6kI+m4HN6cIl
Content-Type: text/plain; charset="ISO-8859-1"; name="dfe928e33245062241b936a0232d5f6b6a3e98a6"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="dfe928e33245062241b936a0232d5f6b6a3e98a6.patch"
From dfe928e33245062241b936a0232d5f6b6a3e98a6 Mon Sep 17 00:00:00 2001
From: PHO <pho@cielonegro.org>
Date: Sun, 25 Jun 2023 20:28:31 +0900
Subject: [PATCH] callout(9): Obtain the lock before checking if a callout is
destroyable
One cannot safely observe the state of a callout without holding its lock,
because c->c_flags and c->c_cpu might be getting mutated somewhere else.
---
sys/kern/kern_timeout.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/sys/kern/kern_timeout.c b/sys/kern/kern_timeout.c
index 3f3338a67872..8c2b180c6dae 100644
--- a/sys/kern/kern_timeout.c
+++ b/sys/kern/kern_timeout.c
@@ -364,17 +364,14 @@ void
callout_destroy(callout_t *cs)
{
callout_impl_t *c =3D (callout_impl_t *)cs;
-
+#if defined(KDTRACE_HOOKS) || defined(DIAGNOSTIC)
+ kmutex_t *lock =3D callout_lock(c);
+#endif
SDT_PROBE1(sdt, kernel, callout, destroy, cs);
=20
KASSERTMSG(c->c_magic =3D=3D CALLOUT_MAGIC,
"callout %p: c_magic (%#x) !=3D CALLOUT_MAGIC (%#x)",
c, c->c_magic, CALLOUT_MAGIC);
- /*
- * It's not necessary to lock in order to see the correct value
- * of c->c_flags. If the callout could potentially have been
- * running, the current thread should have stopped it.
- */
KASSERTMSG((c->c_flags & CALLOUT_PENDING) =3D=3D 0,
"pending callout %p: c_func (%p) c_flags (%#x) destroyed from %p",
c, c->c_func, c->c_flags, __builtin_return_address(0));
@@ -382,6 +379,10 @@ callout_destroy(callout_t *cs)
"running callout %p: c_func (%p) c_flags (%#x) destroyed from %p",
c, c->c_func, c->c_flags, __builtin_return_address(0));
c->c_magic =3D 0;
+
+#if defined(KDTRACE_HOOKS) || defined(DIAGNOSTIC)
+ mutex_spin_exit(lock);
+#endif
}
=20
/*
@@ -654,12 +655,12 @@ callout_bind(callout_t *cs, struct cpu_info *ci)
struct callout_cpu *cc;
kmutex_t *lock;
=20
- KASSERT((c->c_flags & CALLOUT_PENDING) =3D=3D 0);
- KASSERT(c->c_cpu->cc_active !=3D c);
KASSERT(c->c_magic =3D=3D CALLOUT_MAGIC);
KASSERT((c->c_flags & CALLOUT_MPSAFE) !=3D 0);
=20
lock =3D callout_lock(c);
+ KASSERT(c->c_cpu->cc_active !=3D c);
+ KASSERT((c->c_flags & CALLOUT_PENDING) =3D=3D 0);
cc =3D ci->ci_data.cpu_callout;
c->c_flags |=3D CALLOUT_BOUND;
if (c->c_cpu !=3D cc) {
--=_QSVhpQW7wL2t2ZyM0lNb6kI+m4HN6cIl--
From: PHO <pho@cielonegro.org>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/57226: NetBSD 10_BETA kernel crash
Date: Mon, 26 Jun 2023 11:16:48 +0900
This is a multi-part message in MIME format.
--------------AgangFOrsVYnJOd1CKoUL0ht
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
On 6/26/23 03:37, Taylor R Campbell wrote:
> Nice work! I agree this is the right analysis and correct solution.
Thanks!
> Couple nits:
>
>> callout(9): Obtain the lock before checking if a callout is destroyable
>>
>> One cannot safely observe the state of a callout without holding its lock,
>> because c->c_flags and c->c_cpu might be getting mutated somewhere else.
>
> Did you observe this to be necessary to fix the problem, or do you
> have a theory for why this should be necessary? I don't think it
> should be. I think if anything, it should be under #ifdef DEBUG (but
> I'm not sure we should keep it at all). The comment you deleted in
> this change,
>
> /*
> * It's not necessary to lock in order to see the correct value
> * of c->c_flags. If the callout could potentially have been
> * running, the current thread should have stopped it.
> */
>
> correctly reflects the callout(9) API contract, so if there is any
> race here, it is either a bug in callout(9) or a user error -- and we
> want to detect it and fail noisily in either case, not suppress it by
> taking a lock.
In fact it's my early speculation. I initially thought callout_destroy()
was reading stale values. So no objection to withdrawing the change.
> In the other change, which I think is the only one that should be
> needed to solve the problem:
>
>> @@ -593,7 +592,7 @@ callout_wait(callout_impl_t *c, void *interlock, kmutex_t *lock)
>> * - the callout itself has called callout_halt() (nice!)
>> */
>> cc = c->c_cpu;
>
> I think you need to make sure to load c->c_cpu exactly once here, not
> once in callout_wait and then once again in
> callout_running_somewhere_else.
>
> It's possible that one can prove it is OK to reload c->c_cpu twice,
> but let's keep the change minimal.
>
> In fact for now I would suggest just inlining it in callout_halt so
> that the fix is a one-line change to start, and to pull up, and then
> we can tidy it up afterward with no-functional-change commits.
Alright. Done.
>> - if (__predict_true(cc->cc_active != c || cc->cc_lwp == l))
>> + if (__predict_false(!callout_running_somewhere_else(c)))
>
> This should stay __predict_true. Callouts are supposed to be quick,
> so by the time we've reloaded c->c_cpu from memory, it may have
> changed again, even though the caller already determined
> callout_running_somewhere_else returned true.
Got it. That makes sense.
So I'm re-running the Pandoc test with updated patches (also attached to
this mail):
https://github.com/NetBSD/src/commit/e7da905b63a9bb35670066afe9aeb72c7c6351a6
https://github.com/NetBSD/src/commit/4ca3e49d3f3e3b59345b076b15a2eb212b256a65
https://github.com/NetBSD/src/commit/785e80aa567aabe0f4a9749dacd48a80681d4aac
It's going to take a while. When it finishes (or dies) I will inform you.
--------------AgangFOrsVYnJOd1CKoUL0ht
Content-Type: text/x-patch; charset=UTF-8;
name="0001-callout-9-Fix-panic-in-callout_destroy-kern-57226.patch"
Content-Disposition: attachment;
filename*0="0001-callout-9-Fix-panic-in-callout_destroy-kern-57226.patch"
Content-Transfer-Encoding: base64
RnJvbSBlN2RhOTA1YjYzYTliYjM1NjcwMDY2YWZlOWFlYjcyYzdjNjM1MWE2IE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBQSE8gPHBob0BjaWVsb25lZ3JvLm9yZz4KRGF0ZTog
U3VuLCAyNSBKdW4gMjAyMyAyMDoxNTo0NCArMDkwMApTdWJqZWN0OiBbUEFUQ0ggMS8zXSBj
YWxsb3V0KDkpOiBGaXggcGFuaWMoKSBpbiBjYWxsb3V0X2Rlc3Ryb3koKSAoa2Vybi81NzIy
NikKClRoZSBjdWxwcml0IHdhcyBjYWxsb3V0X2hhbHQoKS4gIihjLT5jX2ZsYWdzICYgQ0FM
TE9VVF9GSVJFRCkgIT0gMCIgd2Fzbid0CnRoZSBjb3JyZWN0IHdheSB0byBjaGVjayBpZiBh
IGNhbGxvdXQgaXMgcnVubmluZy4gSXQgZmFpbGVkIHRvIHdhaXQgZm9yIGEKcnVubmluZyBj
YWxsb3V0IHRvIGZpbmlzaCBpbiB0aGUgZm9sbG93aW5nIHNjZW5hcmlvOgoKMS4gY3B1MCBp
bml0aWFsaXplcyBhIGNhbGxvdXQgYW5kIHNjaGVkdWxlcyBpdC4KMi4gY3B1MCBpbnZva2Vz
IGNhbGxvdXRfc29mdGxvY2soKSBhbmQgZmlyZXMgdGhlIGNhbGxvdXQsIHNldHRpbmcgdGhl
IGZsYWcKICAgQ0FMTE9VVF9GSVJFRC4KMy4gVGhlIGNhbGxvdXQgaW52b2tlcyBjYWxsb3V0
X3NjaGVkdWxlKCkgdG8gcmUtc2NoZWR1bGUgaXRzZWxmLgo0LiBjYWxsb3V0X3NjaGVkdWxl
X2xvY2tlZCgpIGNsZWFycyB0aGUgZmxhZyBDQUxMT1VUX0ZJUkVELCBhbmQgcmVsZWFzZXMK
ICAgdGhlIGxvY2suCjUuIEJlZm9yZSB0aGUgbG9jayBpcyByZS1hY3F1aXJlZCBieSBjYWxs
b3V0X3NvZnRsb2NrKCksIGNwdTEgZGVjaWRlcyB0bwogICBkZXN0cm95IHRoZSBjYWxsb3V0
LiBJdCBmaXJzdCBpbnZva2VzIGNhbGxvdXRfaGFsdCgpIHRvIG1ha2Ugc3VyZSB0aGUKICAg
Y2FsbG91dCBmaW5pc2hlcyBydW5uaW5nLgo2LiBCdXQgc2luY2UgQ0FMTE9VVF9GSVJFRCBo
YXMgYmVlbiBjbGVhcmVkLCBjYWxsb3V0X2hhbHQoKSB0aGlua3MgaXQncyBub3QKICAgcnVu
bmluZyBhbmQgdGhlcmVmb3JlIHJldHVybnMgd2l0aG91dCBpbnZva2luZyBjYWxsb3V0X3dh
aXQoKS4KNy4gY3B1MSBwcm9jZWVkcyB0byBpbnZva2UgY2FsbG91dF9kZXN0cm95KCkgd2hp
bGUgaXQncyBzdGlsbCBydW5uaW5nIG9uCiAgIGNwdTAuIGNhbGxvdXRfZGVzdHJveSgpIGRl
dGVjdHMgdGhhdCBhbmQgcGFuaWNzLgotLS0KIHN5cy9rZXJuL2tlcm5fdGltZW91dC5jIHwg
MTAgKysrKystLS0tLQogMSBmaWxlIGNoYW5nZWQsIDUgaW5zZXJ0aW9ucygrKSwgNSBkZWxl
dGlvbnMoLSkKCmRpZmYgLS1naXQgYS9zeXMva2Vybi9rZXJuX3RpbWVvdXQuYyBiL3N5cy9r
ZXJuL2tlcm5fdGltZW91dC5jCmluZGV4IDNmMzMzOGE2Nzg3Li5lNmUzMTgxMzg5NiAxMDA2
NDQKLS0tIGEvc3lzL2tlcm4va2Vybl90aW1lb3V0LmMKKysrIGIvc3lzL2tlcm4va2Vybl90
aW1lb3V0LmMKQEAgLTU0Miw3ICs1NDIsNyBAQCBjYWxsb3V0X2hhbHQoY2FsbG91dF90ICpj
cywgdm9pZCAqaW50ZXJsb2NrKQogewogCWNhbGxvdXRfaW1wbF90ICpjID0gKGNhbGxvdXRf
aW1wbF90ICopY3M7CiAJa211dGV4X3QgKmxvY2s7Ci0JaW50IGZsYWdzOworCXN0cnVjdCBj
YWxsb3V0X2NwdSAqY2M7CiAKIAlLQVNTRVJUKGMtPmNfbWFnaWMgPT0gQ0FMTE9VVF9NQUdJ
Qyk7CiAJS0FTU0VSVCghY3B1X2ludHJfcCgpKTsKQEAgLTU1MiwxMSArNTUyLDExIEBAIGNh
bGxvdXRfaGFsdChjYWxsb3V0X3QgKmNzLCB2b2lkICppbnRlcmxvY2spCiAJbG9jayA9IGNh
bGxvdXRfbG9jayhjKTsKIAlTRFRfUFJPQkU0KHNkdCwga2VybmVsLCBjYWxsb3V0LCBoYWx0
LAogCSAgICBjLCBjLT5jX2Z1bmMsIGMtPmNfYXJnLCBjLT5jX2ZsYWdzKTsKLQlmbGFncyA9
IGMtPmNfZmxhZ3M7Ci0JaWYgKChmbGFncyAmIENBTExPVVRfUEVORElORykgIT0gMCkKKwlp
ZiAoKGMtPmNfZmxhZ3MgJiBDQUxMT1VUX1BFTkRJTkcpICE9IDApCiAJCUNJUkNRX1JFTU9W
RSgmYy0+Y19saXN0KTsKLQljLT5jX2ZsYWdzID0gZmxhZ3MgJiB+KENBTExPVVRfUEVORElO
R3xDQUxMT1VUX0ZJUkVEKTsKLQlpZiAoX19wcmVkaWN0X2ZhbHNlKGZsYWdzICYgQ0FMTE9V
VF9GSVJFRCkpIHsKKwljLT5jX2ZsYWdzICY9IH4oQ0FMTE9VVF9QRU5ESU5HfENBTExPVVRf
RklSRUQpOworCWNjID0gYy0+Y19jcHU7CisJaWYgKF9fcHJlZGljdF9mYWxzZShjYy0+Y2Nf
YWN0aXZlID09IGMgJiYgY2MtPmNjX2x3cCAhPSBjdXJsd3ApKSB7CiAJCWNhbGxvdXRfd2Fp
dChjLCBpbnRlcmxvY2ssIGxvY2spOwogCQlyZXR1cm4gdHJ1ZTsKIAl9Ci0tIAoyLjM5LjAK
Cg==
--------------AgangFOrsVYnJOd1CKoUL0ht
Content-Type: text/x-patch; charset=UTF-8;
name="0002-callout-9-Tidy-up-the-condition-for-callout-is-runni.patch"
Content-Disposition: attachment;
filename*0="0002-callout-9-Tidy-up-the-condition-for-callout-is-runni.pa";
filename*1="tch"
Content-Transfer-Encoding: base64
RnJvbSA0Y2EzZTQ5ZDNmM2UzYjU5MzQ1YjA3NmIxNWEyZWIyMTJiMjU2YTY1IE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBQSE8gPHBob0BjaWVsb25lZ3JvLm9yZz4KRGF0ZTog
TW9uLCAyNiBKdW4gMjAyMyAxMDo0Njo1MSArMDkwMApTdWJqZWN0OiBbUEFUQ0ggMi8zXSBj
YWxsb3V0KDkpOiBUaWR5IHVwIHRoZSBjb25kaXRpb24gZm9yICJjYWxsb3V0IGlzIHJ1bm5p
bmcKIG9uIGFub3RoZXIgTFdQIgoKTm8gZnVuY3Rpb25hbCBjaGFuZ2VzLgotLS0KIHN5cy9r
ZXJuL2tlcm5fdGltZW91dC5jIHwgMTkgKysrKysrKysrKysrKystLS0tLQogMSBmaWxlIGNo
YW5nZWQsIDE0IGluc2VydGlvbnMoKyksIDUgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEv
c3lzL2tlcm4va2Vybl90aW1lb3V0LmMgYi9zeXMva2Vybi9rZXJuX3RpbWVvdXQuYwppbmRl
eCBlNmUzMTgxMzg5Ni4uYzBhZGZlMDVjZmMgMTAwNjQ0Ci0tLSBhL3N5cy9rZXJuL2tlcm5f
dGltZW91dC5jCisrKyBiL3N5cy9rZXJuL2tlcm5fdGltZW91dC5jCkBAIC0yNjIsNiArMjYy
LDE3IEBAIGNhbGxvdXRfbG9jayhjYWxsb3V0X2ltcGxfdCAqYykKIAl9CiB9CiAKKy8qCisg
KiBDaGVjayBpZiB0aGUgY2FsbG91dCBpcyBjdXJyZW50bHkgcnVubmluZyBvbiBhbiBMV1Ag
dGhhdCBpc24ndCBjdXJsd3AuCisgKi8KK3N0YXRpYyBpbmxpbmUgYm9vbAorY2FsbG91dF9y
dW5uaW5nX3NvbWV3aGVyZV9lbHNlKGNhbGxvdXRfaW1wbF90ICpjLCBzdHJ1Y3QgY2FsbG91
dF9jcHUgKmNjKQoreworCUtBU1NFUlQoYy0+Y19jcHUgPT0gY2MpOworCisJcmV0dXJuIGNj
LT5jY19hY3RpdmUgPT0gYyAmJiBjYy0+Y2NfbHdwICE9IGN1cmx3cDsKK30KKwogLyoKICAq
IGNhbGxvdXRfc3RhcnR1cDoKICAqCkBAIC0zNzgsNyArMzg5LDcgQEAgY2FsbG91dF9kZXN0
cm95KGNhbGxvdXRfdCAqY3MpCiAJS0FTU0VSVE1TRygoYy0+Y19mbGFncyAmIENBTExPVVRf
UEVORElORykgPT0gMCwKIAkgICAgInBlbmRpbmcgY2FsbG91dCAlcDogY19mdW5jICglcCkg
Y19mbGFncyAoJSN4KSBkZXN0cm95ZWQgZnJvbSAlcCIsCiAJICAgIGMsIGMtPmNfZnVuYywg
Yy0+Y19mbGFncywgX19idWlsdGluX3JldHVybl9hZGRyZXNzKDApKTsKLQlLQVNTRVJUTVNH
KGMtPmNfY3B1LT5jY19sd3AgPT0gY3VybHdwIHx8IGMtPmNfY3B1LT5jY19hY3RpdmUgIT0g
YywKKwlLQVNTRVJUTVNHKCFjYWxsb3V0X3J1bm5pbmdfc29tZXdoZXJlX2Vsc2UoYywgYy0+
Y19jcHUpLAogCSAgICAicnVubmluZyBjYWxsb3V0ICVwOiBjX2Z1bmMgKCVwKSBjX2ZsYWdz
ICglI3gpIGRlc3Ryb3llZCBmcm9tICVwIiwKIAkgICAgYywgYy0+Y19mdW5jLCBjLT5jX2Zs
YWdzLCBfX2J1aWx0aW5fcmV0dXJuX2FkZHJlc3MoMCkpOwogCWMtPmNfbWFnaWMgPSAwOwpA
QCAtNTQyLDcgKzU1Myw2IEBAIGNhbGxvdXRfaGFsdChjYWxsb3V0X3QgKmNzLCB2b2lkICpp
bnRlcmxvY2spCiB7CiAJY2FsbG91dF9pbXBsX3QgKmMgPSAoY2FsbG91dF9pbXBsX3QgKilj
czsKIAlrbXV0ZXhfdCAqbG9jazsKLQlzdHJ1Y3QgY2FsbG91dF9jcHUgKmNjOwogCiAJS0FT
U0VSVChjLT5jX21hZ2ljID09IENBTExPVVRfTUFHSUMpOwogCUtBU1NFUlQoIWNwdV9pbnRy
X3AoKSk7CkBAIC01NTUsOCArNTY1LDcgQEAgY2FsbG91dF9oYWx0KGNhbGxvdXRfdCAqY3Ms
IHZvaWQgKmludGVybG9jaykKIAlpZiAoKGMtPmNfZmxhZ3MgJiBDQUxMT1VUX1BFTkRJTkcp
ICE9IDApCiAJCUNJUkNRX1JFTU9WRSgmYy0+Y19saXN0KTsKIAljLT5jX2ZsYWdzICY9IH4o
Q0FMTE9VVF9QRU5ESU5HfENBTExPVVRfRklSRUQpOwotCWNjID0gYy0+Y19jcHU7Ci0JaWYg
KF9fcHJlZGljdF9mYWxzZShjYy0+Y2NfYWN0aXZlID09IGMgJiYgY2MtPmNjX2x3cCAhPSBj
dXJsd3ApKSB7CisJaWYgKF9fcHJlZGljdF9mYWxzZShjYWxsb3V0X3J1bm5pbmdfc29tZXdo
ZXJlX2Vsc2UoYywgYy0+Y19jcHUpKSkgewogCQljYWxsb3V0X3dhaXQoYywgaW50ZXJsb2Nr
LCBsb2NrKTsKIAkJcmV0dXJuIHRydWU7CiAJfQpAQCAtNTkyLDcgKzYwMSw3IEBAIGNhbGxv
dXRfd2FpdChjYWxsb3V0X2ltcGxfdCAqYywgdm9pZCAqaW50ZXJsb2NrLCBrbXV0ZXhfdCAq
bG9jaykKIAkJICogLSB0aGUgY2FsbG91dCBpdHNlbGYgaGFzIGNhbGxlZCBjYWxsb3V0X2hh
bHQoKSAobmljZSEpCiAJCSAqLwogCQljYyA9IGMtPmNfY3B1OwotCQlpZiAoX19wcmVkaWN0
X3RydWUoY2MtPmNjX2FjdGl2ZSAhPSBjIHx8IGNjLT5jY19sd3AgPT0gbCkpCisJCWlmIChf
X3ByZWRpY3RfdHJ1ZSghY2FsbG91dF9ydW5uaW5nX3NvbWV3aGVyZV9lbHNlKGMsIGNjKSkp
CiAJCQlicmVhazsKIAogCQkvKiBJdCdzIHJ1bm5pbmcgLSBuZWVkIHRvIHdhaXQgZm9yIGl0
IHRvIGNvbXBsZXRlLiAqLwotLSAKMi4zOS4wCgo=
--------------AgangFOrsVYnJOd1CKoUL0ht
Content-Type: text/x-patch; charset=UTF-8;
name="0003-callout-9-Delete-the-unused-member-cc_cancel-from-st.patch"
Content-Disposition: attachment;
filename*0="0003-callout-9-Delete-the-unused-member-cc_cancel-from-st.pa";
filename*1="tch"
Content-Transfer-Encoding: base64
RnJvbSA3ODVlODBhYTU2N2FhYmUwZjRhOTc0OWRhY2Q0OGE4MDY4MWQ0YWFjIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBQSE8gPHBob0BjaWVsb25lZ3JvLm9yZz4KRGF0ZTog
U3VuLCAyNSBKdW4gMjAyMyAyMDo0Njo1MiArMDkwMApTdWJqZWN0OiBbUEFUQ0ggMy8zXSBj
YWxsb3V0KDkpOiBEZWxldGUgdGhlIHVudXNlZCBtZW1iZXIgY2NfY2FuY2VsIGZyb20KIHN0
cnVjdCBjYWxsb3V0X2NwdQoKSSBzZWUgbm8gcmVhc29uIHdoeSBpdCBzaG91bGQgYmUgdGhl
cmUsIGFuZCBiZWxpZXZlIGl0cyBhIGxlZnRvdmVyIGZyb20Kc29tZSBvbGQgY29kZS4KLS0t
CiBzeXMva2Vybi9rZXJuX3RpbWVvdXQuYyB8IDEyIC0tLS0tLS0tLS0tLQogMSBmaWxlIGNo
YW5nZWQsIDEyIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3N5cy9rZXJuL2tlcm5fdGlt
ZW91dC5jIGIvc3lzL2tlcm4va2Vybl90aW1lb3V0LmMKaW5kZXggYzBhZGZlMDVjZmMuLjEw
Y2EyMDg2OWFlIDEwMDY0NAotLS0gYS9zeXMva2Vybi9rZXJuX3RpbWVvdXQuYworKysgYi9z
eXMva2Vybi9rZXJuX3RpbWVvdXQuYwpAQCAtMTc0LDcgKzE3NCw2IEBAIHN0cnVjdCBjYWxs
b3V0X2NwdSB7CiAJdV9pbnQJCWNjX3RpY2tzOwogCWx3cF90CQkqY2NfbHdwOwogCWNhbGxv
dXRfaW1wbF90CSpjY19hY3RpdmU7Ci0JY2FsbG91dF9pbXBsX3QJKmNjX2NhbmNlbDsKIAlz
dHJ1Y3QgZXZjbnQJY2NfZXZfbGF0ZTsKIAlzdHJ1Y3QgZXZjbnQJY2NfZXZfYmxvY2s7CiAJ
c3RydWN0IGNhbGxvdXRfY2lyY3EgY2NfdG9kbzsJCS8qIFdvcmtsaXN0ICovCkBAIC01MDcs
NyArNTA2LDYgQEAgYm9vbAogY2FsbG91dF9zdG9wKGNhbGxvdXRfdCAqY3MpCiB7CiAJY2Fs
bG91dF9pbXBsX3QgKmMgPSAoY2FsbG91dF9pbXBsX3QgKiljczsKLQlzdHJ1Y3QgY2FsbG91
dF9jcHUgKmNjOwogCWttdXRleF90ICpsb2NrOwogCWJvb2wgZXhwaXJlZDsKIApAQCAtNTIw
LDE2ICs1MTgsNiBAQCBjYWxsb3V0X3N0b3AoY2FsbG91dF90ICpjcykKIAlleHBpcmVkID0g
KChjLT5jX2ZsYWdzICYgQ0FMTE9VVF9GSVJFRCkgIT0gMCk7CiAJYy0+Y19mbGFncyAmPSB+
KENBTExPVVRfUEVORElOR3xDQUxMT1VUX0ZJUkVEKTsKIAotCWNjID0gYy0+Y19jcHU7Ci0J
aWYgKGNjLT5jY19hY3RpdmUgPT0gYykgewotCQkvKgotCQkgKiBUaGlzIGlzIGZvciBub24t
TVBTQUZFIGNhbGxvdXRzIG9ubHkuICBUbyBzeW5jaHJvbml6ZQotCQkgKiBlZmZlY3RpdmVs
eSB3ZSBtdXN0IGJlIGNhbGxlZCB3aXRoIGtlcm5lbF9sb2NrIGhlbGQuCi0JCSAqIEl0J3Mg
YWxzbyB0YWtlbiBpbiBjYWxsb3V0X3NvZnRjbG9jay4KLQkJICovCi0JCWNjLT5jY19jYW5j
ZWwgPSBjOwotCX0KLQogCVNEVF9QUk9CRTUoc2R0LCBrZXJuZWwsIGNhbGxvdXQsIHN0b3As
CiAJICAgIGMsIGMtPmNfZnVuYywgYy0+Y19hcmcsIGMtPmNfZmxhZ3MsIGV4cGlyZWQpOwog
Ci0tIAoyLjM5LjAKCg==
--------------AgangFOrsVYnJOd1CKoUL0ht--
From: PHO <pho@cielonegro.org>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/57226: NetBSD 10_BETA kernel crash
Date: Mon, 26 Jun 2023 13:36:00 +0900
On 6/26/23 11:16, PHO wrote:
> So I'm re-running the Pandoc test with updated patches (also attached to
> this mail):
>
> https://github.com/NetBSD/src/commit/e7da905b63a9bb35670066afe9aeb72c7c6351a6
> https://github.com/NetBSD/src/commit/4ca3e49d3f3e3b59345b076b15a2eb212b256a65
> https://github.com/NetBSD/src/commit/785e80aa567aabe0f4a9749dacd48a80681d4aac
>
> It's going to take a while. When it finishes (or dies) I will inform you.
The test completed. It could build the entire dependency tree of Pandoc
and the kernel didn't crash. Yay \o/
From: Taylor R Campbell <riastradh@NetBSD.org>
To: PHO <pho@cielonegro.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/57226: NetBSD 10_BETA kernel crash
Date: Tue, 27 Jun 2023 00:15:39 +0000
> Date: Mon, 26 Jun 2023 11:16:48 +0900
> From: PHO <pho@cielonegro.org>
>
> So I'm re-running the Pandoc test with updated patches (also attached to
> this mail):
Great, thanks! LGTM! Let's get the committed and pulled up!
Thanks again for digging into this! Great work.
From: PHO <pho@cielonegro.org>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/57226: NetBSD 10_BETA kernel crash
Date: Tue, 27 Jun 2023 12:50:45 +0900
On 6/27/23 09:15, Taylor R Campbell wrote:
>> Date: Mon, 26 Jun 2023 11:16:48 +0900
>> From: PHO <pho@cielonegro.org>
>>
>> So I'm re-running the Pandoc test with updated patches (also attached to
>> this mail):
>
> Great, thanks! LGTM! Let's get the committed and pulled up!
>
> Thanks again for digging into this! Great work.
Committed. I'm now testing it in the netbsd-10 branch, and when it
completes I'll submit a pullup request. Thank you for your help.
State-Changed-From-To: open->pending-pullups
State-Changed-By: pho@NetBSD.org
State-Changed-When: Tue, 27 Jun 2023 17:20:20 +0000
State-Changed-Why:
Pullup requested, #219
State-Changed-From-To: pending-pullups->closed
State-Changed-By: pho@NetBSD.org
State-Changed-When: Wed, 28 Jun 2023 00:56:31 +0000
State-Changed-Why:
Pull-up done
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2023
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home