Re: smb related problem

From: Takanori Saneto <sanewo_at_ba2.so-net.ne.jp>
Date: Wed, 20 Jun 2007 23:24:01 +0900
I tired the patch and got another panic, with slightly different backtrace
as follows:

smb_co_lock: recursive lock for object 0
panic: recursive lock for object 0xc1b87d80
KDB: enter: panic
[thread pid 644 tid 100050 ]
Stopped at    kdb_enter+0x33: leave
db> bt
Tracing pid 644 tid 100050 td 0xc1a41c00
kdb_enter(c062139e, c0675e80,c1b85615,cc3ada44,cc3ada44,...) at
kdb_enter+0x33
panic(x1b85615,c1b87d80,0,cc3adb98,cc3ada64,...) at panic+0x7e
smb_share_lock(c1b87d80,2,c1a41c00,c1b69600,c1a68a00,...) at smb_share_lock
smb_co_gone(c1a68a00,cc3ad98,c1a14c00,c,c1a41c00,...) at smb_co_gone+0x3a
smb_co_gone(c1b69600,cc3ad98,cc3adb98,cc3adabc,c1b69600,...) at
smb_co_gone+0x5e
smb_sm_lookup(cc3adae8,cc3adb24,cc3adb98,cc3adb40,c199041c,...) at
smb_sm_lookup+0x186
smb_usr_lookup(c1990400,cc3adb98,cc3adba4,cc3adba0,cc3adba0,...) at
smb_usr_lookup+0x95
nsmb_dev_ioctl(c1b69900,82fc6e6a,c1990400,3,c1a41c00,...) at
nsmb_dev_ioctl+0x1d6
giant_ioctl(c1b69900,82fc6e6a,c1990400,3,c1a41c00,...) at giant_ioctl+0x51
devfs_ioctl_f(c1a69b40,82fc6e6a,c1990400,c18eb800,c1a41c00,...) at
devfs_ioctl_f+0x5d
kern_ioctl(c1a44e00,4,82fc6e6a,c1990400,535e95,...) at kern_ioctl+0x9d
ioctl(c1a41c00,cc3adcf8,c,cc3add38,c,...) at ioctl+0xbd
syscall(cc398d38) at syscall+0x1fd
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (54, FreeBSD ELF32, ioctl), eip = 0x2814f047, esp = 0xbfbfe55c,
ebp = 0xbfbfe888 ---
db>


2007/6/19, John Baldwin <jhb_at_freebsd.org>:
>
> On Sunday 17 June 2007 06:27:46 am Takanori Saneto wrote:
> > OK, here it is:
> >
> > smb_co_lock: recursive lock for object 1
> > panic: recursive lock for object 0xc1b3e600
> > KDB: enter: panic
> > [thread pid 592 tid 100032 ]
> > Stopped at    kdb_enter+0x32: leave
> > db> bt
> > Tracing pid 592 tid 100032 td 0xc1a44e00
> > kdb_enter(c060f652, c066e920,c1b89b5a,cc398a70,cc398a70,...) at
> > kdb_enter+0x32
> > panic(x1b89b5a,c1b3e600,1,c1bc0638,cc398ab0,...) at panic+0xc4
> > smb_share_lock(c1b3e600,2,c1a44e00,c,c1a44e00,...) at smb_share_lock
> > smb_co_gone(c1bc0600,cc398ba4,cc398ba4,cc398ac8,c1bc0600,...) at
> > smb_co_gone+0x3a
> > smb_sm_lookup(cc398af4,cc398b30,cc398ba4,cc398b4c,c199041c,...) at
> > smb_sm_lookup+0x16b
> > smb_usr_lookup(c1990400,cc398ba4,cc398bb0,cc398bac,c060ac51,...) at
> > smb_usr_lookup+0x95
> > nsmb_dev_ioctl(c1b5b100,82fc6e6a,c1990400,3,c1a44e00,...) at
> > nsmb_dev_ioctl+0x1d6
>
> Hmm, ok.  Try this maybe:
>
> Index: smb_conn.c
> ===================================================================
> RCS file: /usr/cvs/src/sys/netsmb/smb_conn.c,v
> retrieving revision 1.18
> diff -u -r1.18 smb_conn.c
> --- smb_conn.c  6 Nov 2006 13:42:06 -0000       1.18
> +++ smb_conn.c  18 Jun 2007 22:12:33 -0000
> _at__at_ -212,8 +212,11 _at__at_
>         error = smb_smb_treeconnect(ssp, scred);
>         if (error == 0)
>                 vcspec->ssp = ssp;
> -       else
> +       else {
> +               smb_vc_put(vcp, scred);
> +               vcp = NULL;
>                 smb_share_put(ssp, scred);
> +       }
> out:
>         smb_sm_unlockvclist(td);
>         if (error == 0)
> _at__at_ -351,6 +354,7 _at__at_
>         if (smb_co_lockstatus(cp, td) == LK_EXCLUSIVE &&
>             (flags & LK_CANRECURSE) == 0) {
>                 SMBERROR("recursive lock for object %d\n", cp->co_level);
> +               panic("recursive lock for object %p", cp);
>                 return 0;
>         }
>         return lockmgr(&cp->co_lock, flags, &cp->co_interlock, td);
>
>
> --
> John Baldwin
>
Received on Wed Jun 20 2007 - 12:24:02 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:12 UTC