From owner-freebsd-current@freebsd.org Sat Feb 24 18:41:16 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B062F023C4 for ; Sat, 24 Feb 2018 18:41:16 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B35E270D3A for ; Sat, 24 Feb 2018 18:41:15 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-qt0-x22e.google.com with SMTP id m13so9692947qtg.13 for ; Sat, 24 Feb 2018 10:41:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Bh+dXEnj+sCZpAT2ZlXOUIH6AHwYmreKnF3//o8T114=; b=i5rB/hCjcpPf3SVAbaiOeQvmgMDw3Q6lfx2XFIhFy9O8vKSRCAMTJxgWmNwmBpzdbc jwGb0+H0/jya2/xB4T521wBYAgqUwk9R1Uysh/pX+80ZIBT9FjpoNURTEZ3Z8wqx5oKi 21yi6l2tXbz3SdpG92YFWSlKwcbgyx4tZSY4eN/yjVgJXqAPZZ3tDTUmg3Rd6IqRSCP7 6rPscpWuQo9Vxb2VuLrwO2UTSU6syK5fPfgpLd/nnXpaC0byMUqEx49Lpme057Yh4z8J lBWGaf2kBEE1KdQyulJHuYm5sj3nHJZYgJTlehcpdo8Bmjdim01ZqUJzzuH0s32yv5pC u9dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Bh+dXEnj+sCZpAT2ZlXOUIH6AHwYmreKnF3//o8T114=; b=YTMp2GEZaxman/pFiPXsNS+zrEKSItKTzwl3sE85Zfc21IiEqYnpwh0UZPYiI4LBay BirVy62YgDXrAGrDbrcPS9Uexl0rlRWGVX2/ZzfB/sApr30BbSqkf3gC7Udy+BsDw1DQ SQ8wNBwnmQsJFYNkWg23vDMIgsqMTj6XXsBpfp7j2lZEE95hSvslcJuFFm4HnRu2Xb30 dJXTIzWUwvJQVOI8WkF/EbDmw536WQ3rMWSn00nZwvOWIw1WpPw/EuuRv60/DMuoInGa jOT9E2NQCQlx9RArZjpeoyY5bCsYjUDsmQS4dVzwlQmu6OSzB9rPZ3fnem2uu5HE/+WM +Lmg== X-Gm-Message-State: APf1xPB9Gt6K45eNo1JN+joIKfnyRfPICwxhqpztxy6zXqbe0YPJbQra 6qNPjq8sJujx93LbMYnlCgrDU5H8j/khYG2CwrGE4w== X-Google-Smtp-Source: AG47ELsiuhsSbFaTLxZeJcLwXvILAdYxEnBef8hhno1u4IqYtV4kOHNxWink5XocN02dzV7Jyr/v6B030GZ9M/f664k= X-Received: by 10.237.58.7 with SMTP id n7mr9259081qte.194.1519497675220; Sat, 24 Feb 2018 10:41:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.52.4 with HTTP; Sat, 24 Feb 2018 10:41:14 -0800 (PST) In-Reply-To: <20180212085852.GA94212@kib.kiev.ua> References: <20180212085852.GA94212@kib.kiev.ua> From: Ryan Stone Date: Sat, 24 Feb 2018 13:41:14 -0500 Message-ID: Subject: Re: Panic in prison_alloc() on boot To: Konstantin Belousov Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Feb 2018 18:41:16 -0000 Sorry for the late reply. Panicking this system is a bit painful, but I found some time to do it today. Strangely, it's actually cred that is NULL, not cred->cr_prison: (kgdb) p cred $7 = (struct ucred *) 0x0 (kgdb) disassemble Dump of assembler code for function prison_allow: 0xffffffff80ac33e0 <+0>: push %rbp 0xffffffff80ac33e1 <+1>: mov %rsp,%rbp => 0xffffffff80ac33e4 <+4>: mov 0x30(%rdi),%rax 0xffffffff80ac33e8 <+8>: and 0xf8(%rax),%esi 0xffffffff80ac33ee <+14>: mov %esi,%eax 0xffffffff80ac33f0 <+16>: pop %rbp 0xffffffff80ac33f1 <+17>: retq End of assembler dump. (kgdb) info reg $rdi rdi 0x0 0 However, if I go up a frame, things look fine? (kgdb) up #13 0xffffffff82c22531 in nullfs_mount (mp=0xfffff801a483d000) at /usr/src/sys/fs/nullfs/null_vfsops.c:88 88 if (!prison_allow(td->td_ucred, PR_ALLOW_MOUNT_NULLFS)) (kgdb) p td->td_ucred $8 = (struct ucred *) 0xfffff801854c1700 This appears to be a miscompilation, but I've blown away /usr/obj/usr/src multiple times and rebuilt and got this same error every time. But looking at the disassembly, something is definitely wrong: 0xffffffff82c22517 <+23>: mov %gs:0x0,%r14 0xffffffff82c22520 <+32>: mov 0x150(%r14),%rdi 0xffffffff82c22527 <+39>: mov $0x100,%esi 0xffffffff82c2252c <+44>: callq 0xffffffff80ac33e0 => 0xffffffff82c22531 <+49>: test %eax,%eax (kgdb) p &((struct thread*)0)->td_ucred $10 = (struct ucred **) 0x158 It uses offset 0x150 to get the cred, but the debug info claims that td_ucred is at offset 0x158. If I print out the pointer at that offset, it looks reasonable: (kgdb) p *td->td_ucred $11 = {cr_ref = 107, cr_uid = 0, cr_ruid = 0, cr_svuid = 0, cr_ngroups = 1, cr_rgid = 0, cr_svgid = 0, cr_uidinfo = 0xfffff80106617000, cr_ruidinfo = 0xfffff80106617000, cr_prison = 0xffffffff8187cb70 , cr_loginclass = 0xfffff8019fa43b00, cr_flags = 0, cr_pspare2 = {0x0, 0x0}, cr_label = 0x0, cr_audit = {ai_auid = 4294967295, ai_mask = {am_success = 0, am_failure = 0}, ai_termid = {at_port = 0, at_type = 4, at_addr = {0, 0, 0, 0}}, ai_asid = 0, ai_flags = 0}, cr_groups = 0xfffff801854c179c, cr_agroups = 16, cr_smallgroups = {0 }} I'm really at a loss at to what to try next. Build with MAKEOBJDIRPREFIX set to something else to get rid of any lingering possibility of an issue in my objdir, I guess?