From owner-freebsd-fs@freebsd.org Mon Sep 26 13:36:44 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3721BE88AC for ; Mon, 26 Sep 2016 13:36:44 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:d250:99ff:fe57:4030]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7628C15BA; Mon, 26 Sep 2016 13:36:43 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (localhost [IPv6:::1]) by chez.mckusick.com (8.15.2/8.15.2) with ESMTP id u8QDagnu056294; Mon, 26 Sep 2016 06:36:42 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201609261336.u8QDagnu056294@chez.mckusick.com> From: Kirk McKusick To: Andy Turner , Konstantin Belousov Subject: Re: [Bug 212168] [panic] [UFS] use-after-free panic (0xdeadc0dedeadc0de) cc: freebsd-fs@FreeBSD.org In-reply-to: X-URL: http://WWW.McKusick.COM/ Reply-To: Kirk McKusick MIME-Version: 1.0 Content-ID: <56270.1474896967.0@chez.mckusick.com> Date: Mon, 26 Sep 2016 06:36:42 -0700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 13:36:44 -0000 > From: bugzilla-noreply@freebsd.org > To: freebsd-fs@FreeBSD.org > Subject: [Bug 212168] [panic] [UFS] use-after-free panic (0xdeadc0dedead= c0de) > Date: Sun, 25 Sep 2016 19:37:15 +0000 > = > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212168 My current theory is that some other ARM subsystem is allocating a piece of memory of the same size as one of the soft updates dependencies. The memory is freed by that subsystem and allocated by soft updates. While soft updates is using it the other ARM subsystem frees it a second time causing the dependency to be trashed. To test this theory, I have changed the soft updates allocator to keep its own private pool of structures (e.g., once allocated it is never returned). Since I have not created separate zones, it is still possible that it will get a piece of memory that will later be trashed, but that is much less likely. If the problem persists, I'll take the added step of creating zones. The patch is attached. Hopefully Andy can check it out if his latest fix fails to correct the problem. Kirk McKusick