From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 18:29:36 2015 Return-Path: Delivered-To: freebsd-current@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFA7C41D; Sun, 14 Jun 2015 18:29:36 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id ADCEA1DA; Sun, 14 Jun 2015 18:29:36 +0000 (UTC) (envelope-from jenkins-admin@freebsd.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id BC7DEB6C; Sun, 14 Jun 2015 18:29:36 +0000 (UTC) Date: Sun, 14 Jun 2015 18:29:35 +0000 (GMT) From: jenkins-admin@freebsd.org To: tijl@FreeBSD.org, sjg@FreeBSD.org, tuexen@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@freebsd.org Message-ID: <1464662440.25.1434306576644.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <745634641.23.1434295786878.JavaMail.jenkins@jenkins-9.freebsd.org> References: <745634641.23.1434295786878.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD - Build #2867 - Still Failing MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 18:29:36 -0000 FreeBSD_HEAD - Build #2867 - Still Failing: Check console output at https://jenkins.freebsd.org/job/FreeBSD_HEAD/2867/ to view the results. From owner-freebsd-current@FreeBSD.ORG Sun Jun 14 19:00:19 2015 Return-Path: Delivered-To: freebsd-current@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C75E9D6A; Sun, 14 Jun 2015 19:00:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 695B2BA8; Sun, 14 Jun 2015 19:00:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t5EJ0D7N098395 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 14 Jun 2015 22:00:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t5EJ0D7N098395 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t5EJ0D0p098394; Sun, 14 Jun 2015 22:00:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 14 Jun 2015 22:00:13 +0300 From: Konstantin Belousov To: Jeremie Le Hen Cc: freebsd-current@freebsd.org, trasz@freebsd.org, Konstantin Belousov , alc@freebsd.org Subject: Re: panic when RACCT_RSS still > 0 when struct racct destroyed Message-ID: <20150614190013.GS2080@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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: Sun, 14 Jun 2015 19:00:20 -0000 On Sun, Jun 14, 2015 at 02:53:48PM +0200, Jeremie Le Hen wrote: > Sorry for the early sending in the previous email. > > Hi all, > > I keep getting the following panic from time to time: > % panic: destroying non-empty racct: 1142784 allocated for resource 4 > % > % cpuid = 1 > % KDB: stack backtrace: > % db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00e6240630 > % vpanic() at vpanic+0x189/frame 0xfffffe00e62406b0 > % kassert_panic() at kassert_panic+0x132/frame 0xfffffe00e6240720 > % racct_destroy() at racct_destroy+0x96/frame 0xfffffe00e6240750 > % uifree() at uifree+0x5e/frame 0xfffffe00e6240770 > % crfree() at crfree+0x48/frame 0xfffffe00e6240790 > % thread_wait() at thread_wait+0x8e/frame 0xfffffe00e62407b0 > % proc_reap() at proc_reap+0x40e/frame 0xfffffe00e6240800 > % proc_to_reap() at proc_to_reap+0x332/frame 0xfffffe00e6240850 > % kern_wait6() at kern_wait6+0x1f7/frame 0xfffffe00e62408f0 > % sys_wait4() at sys_wait4+0x73/frame 0xfffffe00e6240ae0 > % amd64_syscall() at amd64_syscall+0x27f/frame 0xfffffe00e6240bf0 > % Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe00e6240bf0 > > I had already reported this two years ago, but we couldn't find a solution: > https://lists.freebsd.org/pipermail/freebsd-current/2013-June/042528.html > > Note that since then I spotted an instance of this which wasn't for a > jailed process. > > > I made a bit more research today on RACCT_RSS throughout the kernel > source. It is only set using racct_set() from > - vmspace_container_set() but it only zero a couple of resources > - vm_daemon() > > The first question, do you guys (kib, alc) think there could be a bug, > or rather a race, in there? > > > The other solution where the RSS resource can be modified is through: > - racct_proc_ucred_changed() > - racct_move() > - racct_proc_fork() > > I think this is pretty much the surface through which the bug can arise. > > > In the thread pointed above, Edward advised me to create a rctl rule > to cause the uidinfo to be held, but this can happen with various > users (the last one with user 2 in the root jail). > Any idea what I could do to narrow the issue? vm_daemon() only runs periodically. What does ensure that rss accounting is reset to zero on the process exit ?