Hi,
Could you point me where to go next?
> *panic_thread$<thread !grep t_procp
t_procp = 0xffffff092fa02728
> 0xffffff092fa02728::print proc_t p_cred | ::print cred_t
{
cr_ref = 0x2
cr_uid = 0
cr_gid = 0xfffe
cr_ruid = 0
cr_rgid = 0
cr_suid = 0
cr_sgid = 0
cr_priv = {
crprivs = [
{
pbits = [ 0x20000, 0x38800000, 0 ]
},
{
pbits = [ 0x20000, 0x38800000, 0 ]
},
{
pbits = [ 0x20000, 0x38800000, 0 ]
},
{
pbits = [ 0xffffffff, 0xffffffff, 0xffffffff ]
},
]
crpriv_flags = 0
}
cr_projid = 0
cr_zone = zone0
cr_label = 0
cr_klpd = 0
cr_ksid = 0
cr_grps = 0xffffff0ad3f94900
}
> *panic_thread::findstack
stack pointer for thread ffffff0940d271e0: ffffff003de350e0
ffffff003de35140 mpt_check_dma_handle+0x20()
ffffff003de351d0 mpt_start_cmd+0x468()
ffffff003de35230 mpt_accept_pkt+0x12b()
ffffff003de35270 mpt_accept_txwq_and_pkt+0x48()
ffffff003de352c0 mpt_scsi_start+0x152()
ffffff003de35300 scsi_transport+0xb5()
ffffff003de35370 sd_start_cmds+0x6d()
ffffff003de353c0 sd_core_iostart+0x1a0()
ffffff003de35400 0xffffff090fdee500()
ffffff003de35450 intr_thread_prolog+0x2a()
ffffff003de354a0 do_interrupt+0xa3()
ffffff003de354b0 _sys_rtt_ints_disabled+8()
ffffff003de35610 mutex_enter+0x10()
ffffff003de35690 zfs_lookup+0xd0()
ffffff003de35730 fop_lookup+0xed()
ffffff003de35780 0xf0()
ffffff003de357f0 dnlc_lookup+0x124()
ffffff003de35870 zfs_lookup+0xde()
ffffff003de358a0 fpregset_to_fxsave+0x25()
ffffff003de358d0 setfpregs+0x45()
ffffff003de35900 restorecontext+0x12f()
ffffff003de35ec0 getsetcontext32+0x12d()
ffffff003de35f10 sys_syscall32+0xff()
> 0xffffff092fa02728::pfiles
FD TYPE VNODE INFO
0 SOCK ffffff0942328800 socket: AF_INET 0.0.0.0 21
3 DOOR ffffff09426a4180
/zones/backup3/root/var/run/name_service_door [door to 'nscd'
(proc=ffffff0940f47010)]
5 REG ffffff0941a5da00 /zones/backup3/root/etc/passwd
6 REG ffffff093fa66c40 /zones/backup3/root/etc/group
On Fri, Feb 12, 2010 at 4:17 PM, Piotr Jasiukajtis <estseg at gmail.com> wrote:
> Hi,
>
> Seems like it was caused by the ftp daemon from a non global zone.
> Opened files by the process:
> /var/run/name_service_door
> /etc/passwd
> /etc/group
>
> On Mon, Feb 8, 2010 at 11:32 AM, ?<Casper.Dik at sun.com> wrote:
>>
>>>Hi,
>>>
>>>I've got this on b129 (with dedup enabled).
>>>Is it a known issue?
>>>
>>>> ::regs
>>>%rax = 0x0000000000000000 ? ? ? ? ? ? ? ? %r9 ?= 0xffffff003de35cf0
>>>%rbx = 0x0000000000000000 ? ? ? ? ? ? ? ? %r10 = 0xffffff0910223400
>>>%rcx = 0x0000000400000008 ? ? ? ? ? ? ? ? %r11 = 0x0000000000000000
>>>%rdx = 0xffffff0ad3f94900 ? ? ? ? ? ? ? ? %r12 = 0x0000000400000008
>>>%rsi = 0xffffff003de35cb0 ? ? ? ? ? ? ? ? %r13 = 0xffffff0ad3f94900
>>>%rdi = 0xfffffffffbbb0470 ? ? ? ? ? ? ? ? %r14 = 0xffffff090080d000
>>>%r8 ?= 0xffffff003de35c00 ? ? ? ? ? ? ? ? %r15 = 0x0000000000000000
>>>
>>>%rip = 0xfffffffffb85b540 vpanic
>>>%rbp = 0xffffff003de35ce0
>>>%rsp = 0xffffff003de35bf8
>>>%rflags = 0x00000246
>>> ?id=0 vip=0 vif=0 ac=0 vm=0 rf=0 nt=0 iopl=0x0
>>> ?status=<of,df,IF,tf,sf,ZF,af,PF,cf>
>>>
>>> ? ? ? ? ? ? ? ? ? ? ? ?%cs = 0x0030 ? ?%ds = 0x004b ? ?%es = 0x004b
>>>%trapno = 0x0 ? ? ? ? ? %fs = 0x0000 ? ?%gs = 0x01c3
>>> ? %err = 0x0
>>>> $C
>>>ffffff003de35ce0 vpanic()
>>>ffffff003de35d30 vmem_hash_delete+0xd1(ffffff090080d000,
>>>ffffff0ad3f94900, 400000008)
>>>ffffff003de35d80 vmem_xfree+0x40(ffffff090080d000, ffffff0ad3f94900,
>>>400000008)
>>>ffffff003de35db0 vmem_free+0x29(ffffff090080d000, ffffff0ad3f94900,
>>>400000008)
>>>ffffff003de35dd0 kmem_free+0x217(ffffff0ad3f94900, 400000008)
>>>ffffff003de35df0 crgrprele+0x36(ffffff0ad3f94900)
>>>ffffff003de35e10 crfree+0x6a(ffffff0942e62480)
>>>ffffff003de35e40 crset+0x36(ffffff092fa02728, ffffff0941e47128)
>>>ffffff003de35ec0 seteuid+0x19e(0)
>>>ffffff003de35f10 sys_syscall32+0xff()
>>>
>>
>>
>> No, it's not a "known issue" in that sense that we know that some part of
>> the code plays loose and fast with the credential references but we
>> haven't quite figured it out yet.
>>
>> If you can forward use the core dump that might be helpful.
>>
>> One additional problem is that "cred_t" used to include all the groups as
>> part of the cred_t proper but as of build 129 the groups are allocated in
>> a different structure. ?Before build 129 a bad credential reference count
>> wouldn't be detected but in build 129, the crgrp_t is freed and a second
>> free or use after free will typically cause a panic.
>>
>> We've seen panics in build 130 and this panic in build 129 adds a little
>> bit of information.
>>
>> Casper
>>
>>
>
>
>
> --
> Piotr Jasiukajtis | estibi | SCA OS0072
> http://estseg.blogspot.com
>
--
Piotr Jasiukajtis | estibi | SCA OS0072
http://estseg.blogspot.com
