Project

General

Profile

Actions

Bug #1876

open

devfs in jail + logging out from console(ttyv1+) -> panic

Added by qhwt.dfly about 14 years ago. Updated over 2 years ago.

Status:
New
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Hi.
This is 100% reproducible(but only tried on x86_64). If you're running
a jail and using devfs inside the jail directory

/etc/fstab:
  devfs        /pbulk/1/dev    devfs    rw,jail    0    0

and login to console (other window than ttyv0), then logout from it,
the kernel panics. `uname -a' says:

  $ uname -a
  DragonFly atom64 2.7-DEVELOPMENT DragonFly v2.7.3.1288.g81c25-DEVELOPMENT #0: Sun Oct 17 00:23:28 JST 2010     y0netan1@atom64:/usr/obj/ATOM64  x86_64

  panic: assertion: vp->v_sysref.refcnt > 0 && (vp->v_flag & (VFREE|VINACTIVE)) == 0 in vref
  mp_lock = 00000003; cpuid = 3
  Trace beginning at frame 0xffffffe0535088f8
  panic() at panic+0x239
  panic() at panic+0x239
  vref() at vref+0x3e
  vrevoke() at vrevoke+0x73
  ttyclosesession() at ttyclosesession+0xc4
  exit1() at exit1+0x391
  kern_wait() at kern_wait
  syscall2() at syscall2+0x3a7
  Xfast_syscall() at Xfast_syscall+0xbf

vp->v_sysref.refcnt contained 0xc0000000, which attracted my attention.

(kgdb) bt
                :
#14 0xffffffff802a80e7 in panic (fmt=0xffffffff804cf8ea "assertion: %s in %s")
    at /usr/src/sys/kern/kern_shutdown.c:782
#15 0xffffffff803149cb in vref (vp=<value optimized out>)
    at /usr/src/sys/kern/vfs_lock.c:271
#16 0xffffffff803123e0 in vrevoke (vp=<value optimized out>,
    cred=0xffffffe004426810) at /usr/src/sys/kern/vfs_subr.c:1322               
#17 0xffffffff802e4422 in ttyclosesession (sp=0xffffffe052f083c0, dorevoke=1)       at /usr/src/sys/kern/tty.c:364                                              
#18 0xffffffff80293eae in exit1 (rv=0) at /usr/src/sys/kern/kern_exit.c:437
#19 0xffffffff802941a7 in sys_exit (uap=0xffffffe053508b48)
    at /usr/src/sys/kern/kern_exit.c:121
#20 0xffffffff804b20ce in syscall2 (frame=0xffffffe053508bf8)
    at /usr/src/sys/platform/pc64/x86_64/trap.c:1164
#21 0xffffffff804aa4bf in Xfast_syscall ()
    at /usr/src/sys/platform/pc64/x86_64/exception.S:305
#22 0x000000000000002b in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

(kgdb) fr 15
#15 0xffffffff803149cb in vref (vp=<value optimized out>)
    at /usr/src/sys/kern/vfs_lock.c:271
271  KKASSERT(vp->v_sysref.refcnt > 0 &&
(kgdb) p vp
$1 = <value optimized out>
(kgdb) up
#16 0xffffffff803123e0 in vrevoke (vp=<value optimized out>,
    cred=0xffffffe004426810) at /usr/src/sys/kern/vfs_subr.c:1322
1322    vref(vqn);
(kgdb) p vqn
$2 = (struct vnode *) 0xffffffe0534be000
(kgdb) down
#15 0xffffffff803149cb in vref (vp=<value optimized out>)
    at /usr/src/sys/kern/vfs_lock.c:271
271  KKASSERT(vp->v_sysref.refcnt > 0 &&
(kgdb) p/x $2->v_sysref
$3 = {rbnode = {rbe_left = 0x0, rbe_right = 0x0,
    rbe_parent = 0xffffffe0534be210, rbe_color = 0x0}, sysid = 0x525,
  refcnt = 0xc0000000, flags = 0x2, srclass = 0xffffffff806a3b00}
Actions #1

Updated by ftigeot about 14 years ago

On Sun, Oct 17, 2010 at 08:41:38AM +0900, YONETANI Tomokazu wrote:

This is 100% reproducible(but only tried on x86_64). If you're running
a jail and using devfs inside the jail directory
/etc/fstab:
devfs /pbulk/1/dev devfs rw,jail 0 0

and login to console (other window than ttyv0), then logout from it,
panic: assertion: vp->v_sysref.refcnt > 0 && (vp->v_flag & (VFREE|VINACTIVE)) == 0 in vref

This looks superficially similar to issue 1791 (devfs in chroot)

http://bugs.dragonflybsd.org/issue1791

Actions #2

Updated by qhwt.dfly about 14 years ago

On Sun, Oct 17, 2010 at 08:41:38AM +0900, YONETANI Tomokazu wrote:

This is 100% reproducible(but only tried on x86_64). If you're running
a jail and using devfs inside the jail directory
/etc/fstab:
devfs /pbulk/1/dev devfs rw,jail 0 0

and login to console (other window than ttyv0), then logout from it,
the kernel panics. `uname -a' says:

A small addition: if I login from the console (ttyv0 this time) and
start pbulk program inside a GNU screen session,
$ screen bulkbuild

detach it,
(ctrl-A d)

reattach to it,
$ screen -r

detach it again,
(ctrl-A d)
then logout from the console and the kernel panics too. If I log into
this machine via ssh and do the same thing, the kernel won't panic,
so this may be specific to ttyvN.

Actions #3

Updated by dillon about 14 years ago

:
:On Sun, Oct 17, 2010 at 08:41:38AM +0900, YONETANI Tomokazu wrote:
:> This is 100% reproducible(but only tried on x86_64). If you're running
:> a jail and using devfs inside the jail directory
:> /etc/fstab:
:> devfs /pbulk/1/dev devfs rw,jail 0 0
:>
:> and login to console (other window than ttyv0), then logout from it,
:> the kernel panics. `uname -a' says:
:
:A small addition: if I login from the console (ttyv0 this time) and
:start pbulk program inside a GNU screen session,
: $ screen bulkbuild
:
:detach it,
: (ctrl-A d)
:
:reattach to it,
: $ screen -r
:
:detach it again,
: (ctrl-A d)
:then logout from the console and the kernel panics too. If I log into
:this machine via ssh and do the same thing, the kernel won't panic,
: so this may be specific to ttyvN.

Could you upload a kernel core to leaf showing the panic?

-Matt
Matthew Dillon
<>

Actions #4

Updated by qhwt.dfly about 14 years ago

On 10/18/10 04:18 AM, Matthew Dillon wrote:

Could you upload a kernel core to leaf showing the panic?

Oops, I forgot to mention before going to sleep.
It's in ~y0netan1/crash on leaf as kern.11 and vmcore.11 .

Best Regards.

Actions #5

Updated by tuxillo over 13 years ago

I'm having exactly the same issue in x86_64 as of v2.11.0.587.g81b795-DEVELOPMENT.
Going to upload a core to leaf as spoken with alexh.

Actions #6

Updated by tuxillo over 2 years ago

  • Description updated (diff)
  • Assignee changed from 0 to tuxillo
Actions #7

Updated by tuxillo over 2 years ago

  • Description updated (diff)
Actions

Also available in: Atom PDF