Bug 194995

Summary:	lsof -i panics system
Product:	Base System	Reporter:	mwlucas
Component:	kern	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Closed FIXED
Severity:	Affects Some People	CC:	emaste, ler, mjg
Priority:	---
Version:	CURRENT
Hardware:	amd64
OS:	Any
See Also:	https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194974

Description mwlucas 2014-11-13 16:05:09 UTC

This might be related to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194974, but it's a different panic message, so I opened a new PR. I figure the awesome power of bugzilla will let you chain PRs together if needed.

Fresh world & kernel, latest official packages:

FreeBSD storm 11.0-CURRENT FreeBSD 11.0-CURRENT #7 r274435: Wed Nov 12 11:30:04 EST 2014     mwlucas@storm:/usr/obj/usr/src/sys/GENERIC  amd64

;pkg info lsof
lsof-4.88,8
Name           : lsof
Version        : 4.88,8
Installed on   : Wed Nov 12 10:27:44 EST 2014
Origin         : sysutils/lsof
Architecture   : freebsd:11:x86:64
Prefix         : /usr/local
Categories     : sysutils
Maintainer     : ler@lerctr.org
WWW            : http://people.freebsd.org/~abe/
Comment        : Lists information about open files (similar to fstat(1))
Annotations    :
        repo_type      : binary
        repository     : FreeBSD
Flat size      : 223KiB
Description    :
Lsof (LiSt Open Files) lists information about files that are open by the
running processes.  An open file may be a regular file, a directory, a block
special file, a character special file, an executing text reference, a
library, a stream or a network file (Internet socket, NFS file or Unix domain
socket).

See also fstat(1) in the base system.

WWW: http://people.freebsd.org/~abe/


Run "lsof -i" and CPU usage starts to climb. In 15-30 seconds I get a panic. I haven't done this for a while, so let me know if I kgdb'd wrong or you want more info.

storm/var/crash;kgdb /usr/obj/usr/src/sys/GENERIC/kernel.debug vmcore.0
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
panic: virtual address 0xfffff810840fc985 not covered by the DMAP
cpuid = 5
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe085d6aa610
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe085d6aa6c0
vpanic() at vpanic+0x189/frame 0xfffffe085d6aa740
kassert_panic() at kassert_panic+0x139/frame 0xfffffe085d6aa7b0
memrw() at memrw+0x163/frame 0xfffffe085d6aa810
giant_read() at giant_read+0x5b/frame 0xfffffe085d6aa850
devfs_read_f() at devfs_read_f+0xca/frame 0xfffffe085d6aa8b0
dofileread() at dofileread+0x95/frame 0xfffffe085d6aa900
kern_readv() at kern_readv+0x68/frame 0xfffffe085d6aa950
sys_read() at sys_read+0x63/frame 0xfffffe085d6aa9a0
amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe085d6aaab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe085d6aaab0
--- syscall (3, FreeBSD ELF64, sys_read), rip = 0x800b793aa, rsp = 0x7fffffffe238, rbp = 0x7fffffffe280 ---
KDB: enter: panic

Reading symbols from /boot/kernel/zfs.ko.symbols...done.
Loaded symbols for /boot/kernel/zfs.ko.symbols
Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
Loaded symbols for /boot/kernel/opensolaris.ko.symbols
Reading symbols from /boot/kernel/ipmi.ko.symbols...done.
Loaded symbols for /boot/kernel/ipmi.ko.symbols
Reading symbols from /boot/kernel/smbus.ko.symbols...done.
Loaded symbols for /boot/kernel/smbus.ko.symbols
Reading symbols from /boot/kernel/ums.ko.symbols...done.
Loaded symbols for /boot/kernel/ums.ko.symbols
#0  doadump (textdump=0) at pcpu.h:219
219     pcpu.h: No such file or directory.
        in pcpu.h
(kgdb)

Comment 1 Larry Rosenman freebsd_committer

2014-11-13 16:21:00 UTC

let me know if I need to get Vic involved....

Larry Rosenman
Maintainer, sysutils/lsof

Comment 2 Ed Maste freebsd_committer

2014-11-13 21:27:36 UTC

> let me know if I need to get Vic involved....

Will do; at this point I think it's not likely.

Comment 3 Mateusz Guzik freebsd_committer

2014-11-13 21:29:40 UTC

While clearly the kernel should not panic, why is lsof reading kernel memory?

What interfaces (if any) are missing?

Comment 4 Larry Rosenman freebsd_committer

2014-11-13 21:31:17 UTC

As to why lsof is reading kernel memory, there are TONS of messages on various lists over the last few years.

Vic has said he'd use interfaces, but no one (tmk) has written what he needs.

Comment 5 commit-hook freebsd_committer

2015-01-03 01:29:10 UTC

A commit references this bug:

Author: kib
Date: Sat Jan  3 01:28:59 UTC 2015
New revision: 276600
URL: https://svnweb.freebsd.org/changeset/base/276600

Log:
  For /dev/mem and /dev/kmem accesses, avoid asserting that addresses
  are within direct map.  We want to return error instead of panicing.

  PR:	194995
  Sponsored by:	The FreeBSD Foundation

Changes:
  head/sys/amd64/amd64/mem.c
  head/sys/amd64/include/vmparam.h

Comment 6 Glen Barber freebsd_committer

2015-07-08 18:32:09 UTC

To originators/assignees of this PR:

A commit to the tree references this PR, however the PR is still in a non-closed state.

Please review this PR and close as appropriate, or if closing the PR requires a merge to stable/10, please let re@ know as soon as possible.

Thank you.

Glen

Comment 7 mwlucas 2015-07-08 21:52:39 UTC

This sure seems fixed now. Cannot reproduce on any of my systems.

Now to see if I can close a bugzilla PR. :-)