Bug 194995 - lsof -i panics system
Summary: lsof -i panics system
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
Depends on:
Reported: 2014-11-13 16:05 UTC by mwlucas
Modified: 2015-07-08 21:52 UTC (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
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
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

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
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

  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

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.

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. :-)