Bug #1876

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

Added by qhwt.dfly over 3 years ago. Updated over 2 years ago.

Status:NewStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

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}

History

#1 Updated by ftigeot over 3 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

#2 Updated by qhwt.dfly over 3 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.

#3 Updated by dillon over 3 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
<>

#4 Updated by qhwt.dfly over 3 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.

#5 Updated by tuxillo over 2 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.

Also available in: Atom PDF