Project

General

Profile

Actions

Bug #593

open

cmlb causes panic in xdf

Added by Albert Lee over 10 years ago. Updated over 10 years ago.

Status:
New
Priority:
Normal
Assignee:
Category:
kernel
Start date:
2010-12-30
Due date:
% Done:

0%

Estimated time:
Difficulty:
Tags:
Gerrit CR:

Description

After replacing the second PV disk (xvdb) or adding additional disks to system running as a Xen domU, the system panics when I/O to the second disk is attempted (reading the fdisk table).

[2]> $C
fffffffffbc9f6f0 kmdb_enter+0xb()
fffffffffbc9f710 debug_enter+0x38(fffffffffbc10a88)
fffffffffbc9f7e0 panicsys+0x497(fffffffffb9598f8, ffffff00068014a0, 
fffffffffbc9f7f0, 1)
ffffff00068013e0 vpanic+0x15c()
ffffff00068014d0 panic+0x94()
ffffff0006801550 die+0x10f(e, ffffff0006801670, ffffff098c43effc, 2)
ffffff0006801660 trap+0x1791(ffffff0006801670, ffffff098c43effc, 2)
ffffff0006801670 0xfffffffffb80020b()
ffffff0006801790 gnttab_grant_foreign_access_ref+0x27(ffffffff, 0, a9560, 0)
ffffff00068017d0 xdf`gs_grant+0x5b(ffffff018cae78a0, a9560)
ffffff0006801850 xdf`xdf_process_rreq+0x1d6(ffffff01940b8000, ffffff018fa45240, 
ffffff0194daa120)
ffffff00068018a0 xdf`xdf_io_start+0xa8(ffffff01940b8000)
ffffff0006801920 xdf`xdf_lb_rdwr+0xeb(ffffff018fe990c8, 0, 0, 0, 0, 0)
ffffff0006801a50 cmlb`cmlb_read_fdisk+0x8e(ffffff01946ab000, 0, 0)
ffffff0006801aa0 cmlb`cmlb_dkio_set_ext_part+0x48(ffffff01946ab000, 8047b84, 
100005, 0)
ffffff0006801b20 cmlb`cmlb_ioctl+0x163(ffffff01946ab000, c100000050, 42e, 
8047b84, 100005, ffffff0195414f18, ffffff0006801d54, 0)
ffffff0006801c30 xdf`xdf_ioctl+0x41c(c100000050, 42e, 8047b84, 100005, 
ffffff0195414f18, ffffff0006801d54)
ffffff0006801c70 cdev_ioctl+0x45(c100000050, 42e, 8047b84, 100005, 
ffffff0195414f18, ffffff0006801d54)   
ffffff0006801cb0 specfs`spec_ioctl+0x5a(ffffff019791dd00, 42e, 8047b84, 100005, 
ffffff0195414f18, ffffff0006801d54, 0)
ffffff0006801d30 fop_ioctl+0x7b(ffffff019791dd00, 42e, 8047b84, 100005, 
ffffff0195414f18, ffffff0006801d54, 0)
ffffff0006801e30 ioctl+0x18e(5, 42e, 8047b84)
ffffff0006801ec0 dtrace_systrace_syscall32+0x11a(5, 42e, 8047b84, 1c3, 1, 0)
ffffff0006801f10 sys_syscall32+0x13e()

[2]> ffffff018cae78a0::print ge_slot_t
{
    gs_vreq_link = {
        list_next = 0xffffff018f525f08
        list_prev = 0xffffff018f525f08
    }
    gs_vreq = 0xffffff018f525ee8
    gs_oeid = 0
    gs_isread = 0x1
    gs_ghead = 0xffffffff
    gs_ngrefs = 0xc
    gs_ge = [ 0x31, 0x193, 0x192, 0x19a, 0x18f, 0x1a2, 0x6c, 0x190, 0x19e, 0x19c
, 0x19d ]
}

    263 
    264 static grant_ref_t
    265 gs_grant(ge_slot_t *gs, mfn_t mfn)
    266 {
    267     grant_ref_t gr = gnttab_claim_grant_reference(&gs->gs_ghead);
    268 
    269     ASSERT(gr != -1);
    270     ASSERT(gs->gs_ngrefs < BLKIF_MAX_SEGMENTS_PER_REQUEST);
    271     gs->gs_ge[gs->gs_ngrefs++] = gr;
    272     gnttab_grant_foreign_access_ref(gr, gs->gs_oeid, mfn, !gs->gs_isread);
    273 
    274     return (gr);
    275 }
    276 

[2]> gs_grant::dis
xdf`gs_grant:                   pushq  %rbp
xdf`gs_grant+1:                 movq   %rsp,%rbp
xdf`gs_grant+4:                 subq   $0x10,%rsp
xdf`gs_grant+8:                 movq   %rdi,-0x8(%rbp)
xdf`gs_grant+0xc:               movq   %rsi,-0x10(%rbp)
xdf`gs_grant+0x10:              pushq  %rbx
xdf`gs_grant+0x11:              pushq  %r12
xdf`gs_grant+0x13:              pushq  %r13
xdf`gs_grant+0x15:              subq   $0x8,%rsp
xdf`gs_grant+0x19:              movq   %rsi,%r13
xdf`gs_grant+0x1c:              movq   %rdi,%r12
xdf`gs_grant+0x1f:              addq   $0x20,%rdi
xdf`gs_grant+0x23:              call   +0x3df5c50       <gnttab_claim_grant_refe
rence>
xdf`gs_grant+0x28:              movl   %eax,%ebx
xdf`gs_grant+0x2a:              movl   0x24(%r12),%ecx
xdf`gs_grant+0x2f:              leal   0x1(%rcx),%eax
xdf`gs_grant+0x32:              movl   %eax,0x24(%r12)
xdf`gs_grant+0x37:              movslq %ecx,%r8
xdf`gs_grant+0x3a:              movl   %ebx,0x28(%r12,%r8,4)
xdf`gs_grant+0x3f:              cmpl   $0x0,0x1c(%r12)
xdf`gs_grant+0x45:              sete   %al
xdf`gs_grant+0x48:              movzbl %al,%ecx
xdf`gs_grant+0x4b:              movzwl 0x18(%r12),%esi
xdf`gs_grant+0x51:              movl   %ebx,%edi
xdf`gs_grant+0x53:              movq   %r13,%rdx
xdf`gs_grant+0x56:              
call   +0x3df578d       <gnttab_grant_foreign_access_ref>
xdf`gs_grant+0x5b:              movl   %ebx,%eax
xdf`gs_grant+0x5d:              addq   $0x8,%rsp
xdf`gs_grant+0x61:              popq   %r13
xdf`gs_grant+0x63:              popq   %r12
xdf`gs_grant+0x65:              popq   %rbx
xdf`gs_grant+0x66:              leave  
xdf`gs_grant+0x67:              ret    

The condition of gs would've triggered both asserts if they were present.


Related issues

Related to illumos gate - Bug #606: xdf should not panic on zero-size I/ONewAlbert Lee2011-01-06

Actions
Actions

Also available in: Atom PDF