From owner-freebsd-current@FreeBSD.ORG Fri Mar 20 09:52:12 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E5674B8; Fri, 20 Mar 2015 09:52:12 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (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 DAC981DF; Fri, 20 Mar 2015 09:52:11 +0000 (UTC) Received: by wgbcc7 with SMTP id cc7so84671660wgb.0; Fri, 20 Mar 2015 02:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=oKMlXH5KecNR32lFYRx9KzrXAYPovxcyh6Tvbko+1sY=; b=kYoaxidB6EabFdBCyXedylfcvXRfbFYcvuCdQPJxZke+VxdjltI1uAZgqUXxuVPQ0g w6e21rCUPmVxeuCRnLhJkPKxAJT0RB5k3J2l3Np26I1ThZ5rDYJlH+IOvgB8ShcDQ1nT Mdco16yoFf2/EQq6lWeFcI9F1JWS90T2dhNJPGU+jdLkIJNNDOEM8VhIQFjYYYUcc5Uk SeBU+PMNvQ0qOnMEXy6fic1vwTKu4sWL+3zUQHRx2kIL9jU6gSqyvkrO+ENZNbAIp6m4 ntD2Z4iuBS+Xo9Z57MmR0UxVezmpX1M7YNzqYGZ2xrYHW5jvVXd2HUc2hCpOKWOxSAdU ocsw== X-Received: by 10.180.187.19 with SMTP id fo19mr23511197wic.2.1426845130192; Fri, 20 Mar 2015 02:52:10 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id md2sm2237396wic.19.2015.03.20.02.52.08 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 20 Mar 2015 02:52:09 -0700 (PDT) Date: Fri, 20 Mar 2015 10:52:06 +0100 From: Mateusz Guzik To: Konstantin Belousov Subject: Re: Build failed in Jenkins: FreeBSD_HEAD-tests2 #854 Message-ID: <20150320095206.GA27736@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Konstantin Belousov , jenkins-admin@freebsd.org, freebsd-current@freebsd.org References: <615255742.14.1426582002157.JavaMail.jenkins@jenkins-9.freebsd.org> <812621580.0.1426817304110.JavaMail.jenkins@jenkins-9.freebsd.org> <20150320022026.GA10296@dft-labs.eu> <20150320093451.GN2379@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150320093451.GN2379@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, jenkins-admin@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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: Fri, 20 Mar 2015 09:52:12 -0000 On Fri, Mar 20, 2015 at 11:34:51AM +0200, Konstantin Belousov wrote: > On Fri, Mar 20, 2015 at 03:20:26AM +0100, Mateusz Guzik wrote: > > On Fri, Mar 20, 2015 at 02:08:23AM +0000, jenkins-admin@freebsd.org wrote: > > > lib/libc/sys/setrlimit_test:setrlimit_nproc -> maxproc limit exceeded by uid 977 (pid 29170); see tuning(7) and login.conf(5) > > > passed [0.551s] > > > lib/libc/sys/setrlimit_test:setrlimit_perm -> panic: mutex process lock not owned at /builds/FreeBSD_HEAD/sys/kern/kern_prot.c:1974 > > > cpuid = 1 > > > KDB: stack backtrace: > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe009749a8e0 > > > vpanic() at vpanic+0x189/frame 0xfffffe009749a960 > > > panic() at panic+0x43/frame 0xfffffe009749a9c0 > > > __mtx_assert() at __mtx_assert+0xc2/frame 0xfffffe009749a9d0 > > > proc_set_cred() at proc_set_cred+0x36/frame 0xfffffe009749a9f0 > > > fork1() at fork1+0x27e/frame 0xfffffe009749aac0 > > > sys_fork() at sys_fork+0x1f/frame 0xfffffe009749aae0 > > > amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe009749abf0 > > > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe009749abf0 > > > --- syscall (0, FreeBSD ELF64, nosys), rip = 0x8019c216a, rsp = 0x7fffffffc2d8, rbp = 0x7fffffffc340 --- > > > KDB: enter: panic > > > [ thread pid 660 tid 100065 ] > > > Stopped at kdb_enter+0x3e: movq $0,kdb_why > > > > Weird, I'll look at that. > > This is due to p_ucred not initialized on allocation of struc proc. > The member is not in p_startzero/p_endzero region, so it contains > garbage at the stage of the fork where proc_set_cred() is called, > while the function makes assertion based on the p_ucred content. Yes I figured, but proc_init left me quite puzzled: static int proc_init(void *mem, int size, int flags) { struct proc *p; p = (struct proc *)mem; SDT_PROBE(proc, kernel, init, entry, p, size, flags, 0, 0); p->p_sched = (struct p_sched *)&p[1]; bzero(&p->p_mtx, sizeof(struct mtx)); mtx_init(&p->p_mtx, "process lock", NULL, MTX_DEF | MTX_DUPOK); We bzero only the first mutex to make sure mtx_init works? mtx_init(&p->p_slock, "process slock", NULL, MTX_SPIN); mtx_init(&p->p_statmtx, "pstatl", NULL, MTX_SPIN); mtx_init(&p->p_itimmtx, "pitiml", NULL, MTX_SPIN); mtx_init(&p->p_profmtx, "pprofl", NULL, MTX_SPIN); How about these? So the trivial fix would be to move p_ucred or explicitely NULL it here. All these mtx_init calls would use MTX_NEW flag and bzero could be eliminated. I'll commit a quick fix shortly. I'm really confused what's the purpose of checking for double initialisation of locks. I'm not aware of any actual bug caught by this, on the other hand I'm aware of quite a few cases where bzero or M_ZERO were used just to make sure mtx_init passes. So preferably I would just get rid of such a check and effectively make the behaviour as if MTX_NEW is always used. -- Mateusz Guzik