On Sun, Mar 15, 2015 at 06:08:11PM -0400, Jeff Layton wrote: > Could you run gdb against nfsd.ko and do a: > > list *(nfsd4_process_open2+0x1de) > > I'd be interesting to see where it crashed. My suspicion would be > trying to lock the cl->cl_lock, but I can't tell for sure (and from > where). That's deep inside the spinlock assembly code, but if I got back far enough I get here: (gdb) l *(nfsd4_process_open2+0x1c6) 0xffffffff813c6026 is in nfsd4_process_open2 (../fs/nfsd/nfs4state.c:3238). 3233 stp->st_stateowner = nfs4_get_stateowner(&oo->oo_owner); 3234 get_nfs4_file(fp); 3235 stp->st_stid.sc_file = fp; 3236 stp->st_access_bmap = 0; 3237 stp->st_deny_bmap = 0; 3238 stp->st_openstp = NULL; 3239 spin_lock(&oo->oo_owner.so_client->cl_lock); 3240 list_add(&stp->st_perstateowner, &oo->oo_owner.so_stateids); 3241 spin_lock(&fp->fi_lock); 3242 list_add(&stp->st_perfile, &fp->fi_stateids); -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
