NetBSD Problem Report #55280

From www@netbsd.org  Wed May 20 05:39:15 2020
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-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 294B21A9227
	for <gnats-bugs@gnats.NetBSD.org>; Wed, 20 May 2020 05:39:15 +0000 (UTC)
Message-Id: <20200520053914.2ECB31A9228@mollari.NetBSD.org>
Date: Wed, 20 May 2020 05:39:14 +0000 (UTC)
From: netbsd@eq.cz
Reply-To: netbsd@eq.cz
To: gnats-bugs@NetBSD.org
Subject: panic: kernel diagnostic assertion "c->c_magic == CALLOUT_MAGIC" failed
X-Send-Pr-Version: www-1.0

>Number:         55280
>Category:       kern
>Synopsis:       panic: kernel diagnostic assertion "c->c_magic == CALLOUT_MAGIC" failed
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed May 20 05:40:00 +0000 2020
>Last-Modified:  Wed May 20 09:40:02 +0000 2020
>Originator:     rudolf
>Release:        netbsd-8
>Organization:
>Environment:
NetBSD 8.2_STABLE amd64
>Description:
With kernel compiled on 2020-05-18 from a fresh netbsd-8 branch and with older userland from the same branch, probably compiled in February, I've encountered the following panic:

panic: kernel diagnostic assertion "c->c_magic == CALLOUT_MAGIC" failed: file "/usr/src/sys/kern/kern_timeout.c", line 474 
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x140
ch_voltag_convert_in() at netbsd:ch_voltag_convert_in
callout_halt() at netbsd:callout_halt+0x1fa
linux_cancel_delayed_work_callout() at netbsd:linux_cancel_delayed_work_callout+0x46
linux_cancel_delayed_work_sync() at netbsd:linux_cancel_delayed_work_sync+0xa2
__i915_add_request() at netbsd:__i915_add_request+0x186
i915_gem_do_execbuffer.isra.24() at netbsd:i915_gem_do_execbuffer.isra.24+0xf5a
i915_gem_execbuffer2() at netbsd:i915_gem_execbuffer2+0xc5
drm_ioctl() at netbsd:drm_ioctl+0x12e
sys_ioctl() at netbsd:sys_ioctl+0x101
syscall() at netbsd:syscall+0x1d8
--- syscall (number 54) ---
733942eff14a:
cpu0: End traceback...
uvm_fault(0xfffffe841864a300, 0x0, 2) -> e

fatal page fault in supervisor mode
dumping to dev 20,1 (offset=2152151, size=4170107):
trap type 6 code 0x2 rip 0xffffffff808f64cb cs 0x8 rflags 0x10286 cr2 0x84 ilevel 0x8 rsp 0xffff80013df78dd0
dump curlwp 0xfffffe8414979a00 pid 4701.12 lowest kstack 0xffff80013df742c0
Skipping crash dump on recursive panic
panic: wddump: polled command has been queued
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x140
snprintf() at netbsd:snprintf
wddump() at netbsd:wddump+0x295
cgd_dumpblocks() at netbsd:cgd_dumpblocks+0x89
dk_dump() at netbsd:dk_dump+0x16d
dump_header_flush() at netbsd:dump_header_flush+0x53
dump_header_addbytes() at netbsd:dump_header_addbytes+0x40
dump_header_addseg() at netbsd:dump_header_addseg+0x1e
dump_seg_iter() at netbsd:dump_seg_iter+0xd2
cpu_dump() at netbsd:cpu_dump+0x6a
dodumpsys() at netbsd:dodumpsys+0xfb
dumpsys() at netbsd:dumpsys+0x1d
vpanic() at netbsd:vpanic+0x149
ch_voltag_convert_in() at netbsd:ch_voltag_convert_in
callout_halt() at netbsd:callout_halt+0x1fa
linux_cancel_delayed_work_callout() at netbsd:linux_cancel_delayed_work_callout+0x46
linux_cancel_delayed_work_sync() at netbsd:linux_cancel_delayed_work_sync+0xa2
__i915_add_request() at netbsd:__i915_add_request+0x186
i915_gem_do_execbuffer.isra.24() at netbsd:i915_gem_do_execbuffer.isra.24+0xf5a
i915_gem_execbuffer2() at netbsd:i915_gem_execbuffer2+0xc5
drm_ioctl() at netbsd:drm_ioctl+0x12e
sys_ioctl() at netbsd:sys_ioctl+0x101
syscall() at netbsd:syscall+0x1d8
--- syscall (number 54) ---
733942eff14a:
cpu0: End traceback...
rebooting...

>How-To-Repeat:

>Fix:

>Audit-Trail:
From: coypu@sdf.org
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/55280: panic: kernel diagnostic assertion "c->c_magic ==
 CALLOUT_MAGIC" failed
Date: Wed, 20 May 2020 09:36:59 +0000

 Hmm. I was about to note that the functions in this backtrace are the
 same ones affected by CVE-2019-0155 / CVE-2019-0154.

 It seems that I haven't applied the fix to netbsd-8, though.

Home	PR Database Search