Bug #1661


panic on password entry mount smb filesystem

Added by vsrinivas about 14 years ago. Updated about 2 years ago.

In Progress
VFS subsystem
Target version:
Start date:
Due date:
% Done:


Estimated time:



When attempting to mount an SMB filesystem, I get a 'Fatal trap 12: page fault
while in kernel mode' after the password is requested by mount_smbfs. Tested on
a daily snapshot from 1/23/2010.

# mount_smbfs -I //guest@ /mnt

With a 1/23/2010 GENERIC kernel, the backtrace:

prison_remote_ip(c17131d0,cc759cd0) at prison_remote_ip+0x1b
tcp_usr_connect(c16b5f00,cc759cd0,c17131d0,0,ca2c2d64) at tcp_usr_connect+0x8f
netmsg_pru_connect(cc759c28,c06d4ee0,c06d5278,ca3c3d84,c03c7e5f) at
netmsg_service(cc759c28,c06d4ee0,ff800000) at netmsg_service+0x58
tcpmsg_service_loop(0,0,0,0,0) at tcpmsg_service_loop+0x1d
lwkt_exit() at lwkt_exit

I can upload a coredump and vmcore if needed,


Actions #1

Updated by vsrinivas about 14 years ago

(kgdb) bt
#0  _get_mycpu (di=0xc069af40) at ./machine/thread.h:83
#1  md_dumpsys (di=0xc069af40)
    at /usr/src/sys/platform/pc32/i386/dump_machdep.c:264
#2  0xc031db66 in dumpsys () at /usr/src/sys/kern/kern_shutdown.c:838
#3  0xc031e0e1 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:387
#4  0xc031e202 in panic (fmt=0xc058779e "from debugger")
    at /usr/src/sys/kern/kern_shutdown.c:744
#5  0xc0172685 in db_panic (addr=-1070527193, have_addr=0, count=-1, 
    modif=0xca29abb0 "") at /usr/src/sys/ddb/db_command.c:448
#6  0xc0172cfa in db_command () at /usr/src/sys/ddb/db_command.c:344
#7  db_command_loop () at /usr/src/sys/ddb/db_command.c:470
#8  0xc01752c8 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:71
#9  0xc0524da8 in kdb_trap (type=12, code=0, regs=0xca29accc)
    at /usr/src/sys/platform/pc32/i386/db_interface.c:152
#10 0xc0536790 in trap_fatal (frame=0xca29accc, eva=<value optimized out>)
    at /usr/src/sys/platform/pc32/i386/trap.c:1129
#11 0xc0536ab7 in trap (frame=0xca29accc)
    at /usr/src/sys/platform/pc32/i386/trap.c:413
#12 0xc0526187 in calltrap ()
    at /usr/src/sys/platform/pc32/i386/exception.s:785
#13 0xc0310d27 in prison_remote_ip (td=0x0, ip=0xcc753cd0)
    at /usr/src/sys/kern/kern_jail.c:404
#14 0xc03cd4a2 in tcp_usr_connect (so=0xc16b5f00, nam=0xcc753cd0, 
    td=0xc17131d0) at /usr/src/sys/netinet/tcp_usrreq.c:474
#15 0xc0351f04 in netmsg_pru_connect (msg=0xcc753c28)
    at /usr/src/sys/kern/uipc_msg.c:486
#16 0xc0395fe8 in netmsg_service (msg=0xcc753c28, mpsafe_mode=1, mplocked=0)
    at /usr/src/sys/net/netisr.c:310
#17 0xc03c7e5f in tcpmsg_service_loop (dummy=0x0)
    at /usr/src/sys/netinet/tcp_subr.c:410
#18 0xc0326251 in lwkt_deschedule_self (td=Cannot access memory at address 0x8
    at /usr/src/sys/kern/lwkt_thread.c:243
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Actions #2

Updated by dillon about 14 years ago

:#13 0xc0310d27 in prison_remote_ip (td=3D0x0, ip=3D0xcc753cd0)
: at /usr/src/sys/kern/kern_jail.c:404
:#14 0xc03cd4a2 in tcp_usr_connect (so=3D0xc16b5f00, nam=3D0xcc753cd0,=20
: td=3D0xc17131d0) at /usr/src/sys/netinet/tcp_usrreq.c:474
:#15 0xc0351f04 in netmsg_pru_connect (msg=3D0xcc753c28)
: at /usr/src/sys/kern/uipc_msg.c:486
:#16 0xc0395fe8 in netmsg_service (msg=3D0xcc753c28, mpsafe_mode=3D1, mplock=

Hmm. Looks like the thread has a NULL td_ucred. My guess is that smbfs is making the connection itself from a maintainance kernel thread.
Try this patch.

diff --git a/sys/kern/kern_jail.c b/sys/kern/kern_jail.c
index f867b9d..6c61867 100644
--- a/sys/kern/kern_jail.c
+++ b/sys/kern/kern_jail.c
@@ -399,7 +399,7 @@ prison_remote_ip(struct thread *td, struct sockaddr *ip)
     struct sockaddr_in6 *ip6 = (struct sockaddr_in6 *)ip;
     struct prison *pr;

-    if (td == NULL || td->td_proc == NULL)
+    if (td == NULL || td->td_proc == NULL || td->td_ucred == NULL)
     if ((pr = td->td_ucred->cr_prison) == NULL)

Actions #3

Updated by tuxillo about 9 years ago

  • Description updated (diff)
  • Category set to VFS subsystem
  • Status changed from New to In Progress
  • Assignee deleted (0)
  • Target version set to 4.2


Actions #4

Updated by notapipe over 7 years ago

I confirm this bug under DragonFly 4.6.0, can be reproduced reliably

Fatal trap 9: general protection fault while in kernel mode
CPU3 stopping CPUs:
dscheck(vn2): b_count 2 is not on a sector boundary (ssize 512)
Stopped at [...]

Actions #5

Updated by tuxillo almost 3 years ago

  • Target version changed from 4.2 to 6.0
Actions #6

Updated by tuxillo about 2 years ago

  • Description updated (diff)

Also available in: Atom PDF