From owner-freebsd-stable@freebsd.org Tue Aug 1 22:13:33 2017 Return-Path: Delivered-To: freebsd-stable@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 0BC6CDBEB03 for ; Tue, 1 Aug 2017 22:13:33 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [IPv6:2001:1440:5001:1::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "uucp.dinoex.sub.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8A9A46B4D7 for ; Tue, 1 Aug 2017 22:13:32 +0000 (UTC) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.sub.de [194.45.71.2]) by uucp.dinoex.sub.de (8.15.2/8.14.9) with ESMTPS id v71MD7C4058061 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 2 Aug 2017 00:13:07 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-MDaemon-Deliver-To: Received: from citylink.dinoex.sub.org (uucp@localhost) by uucp.dinoex.sub.de (8.15.2/8.14.9/Submit) with UUCP id v71MD7pQ058060 for freebsd-stable@FreeBSD.ORG; Wed, 2 Aug 2017 00:13:07 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.15.2/8.15.2) with ESMTP id v71LFSCu013767 for ; Tue, 1 Aug 2017 23:15:29 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: from gate.oper.dinoex.org (gate-e [192.168.98.2]) by gate.oper.dinoex.org (8.15.2/8.15.2) with ESMTP id v71LEDvJ013453 for ; Tue, 1 Aug 2017 23:14:14 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) Received: (from news@localhost) by gate.oper.dinoex.org (8.15.2/8.15.2/Submit) id v71LECSF013447 for freebsd-stable@FreeBSD.ORG; Tue, 1 Aug 2017 23:14:12 +0200 (CEST) (envelope-from li-fbsd@citylink.dinoex.sub.org) X-Authentication-Warning: gate.oper.dinoex.org: news set sender to li-fbsd@citylink.dinoex.sub.org using -f From: Peter Subject: 11.1-RELEASE: panic! acl_from_aces: a_type is 0x4000 Date: Tue, 1 Aug 2017 22:59:00 +0200 Organization: even some more stinky socks Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 1 Aug 2017 20:59:00 -0000 (UTC) Injection-Info: oper.dinoex.de; logging-data="70848"; mail-complaints-to="usenet@citylink.dinoex.sub.org" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:51.0) Gecko/20100101 Firefox/51.0 SeaMonkey/2.48 X-Mozilla-News-Host: news://localhost:119 Sender: li-fbsd@citylink.dinoex.sub.org To: freebsd-stable@FreeBSD.ORG X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 194.45.71.2; Sender-helo: uucp.dinoex.sub.de; ) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (uucp.dinoex.sub.de [194.45.71.2]); Wed, 02 Aug 2017 00:13:08 +0200 (CEST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 22:13:33 -0000 This is mostly for the search engines, so others running into it may find it easier to solve. While updating some ports via "portupgrade", I got this panic: Panic String: acl_from_aces: a_type is 0x4000 The phenomen was reproducible; it appeared while creating a backup package from the "glib" port. I checked readability of all concerned files, did a scrub on the pool, but found no errors! As I was busy with other issues, I then neglected the matter and simply deleted and reinstalled that port. A couple days later, working on a different installation, I got the exact same panic at the exact same point, while updating the "glib" port. This time I looked closer into the matter. According to "truss", the panic appears while "pkg" calls __acl_get_link() on a specific file. That file is readable. The directory tree can be searched. But it is not possible to do "ls -l" on the directory -> panic! It is possible to send+recv the Filesystem: the error gets transported to the new filesystem! (From ZFS view it seems to be legal payload; only from FreeBSD file-handling view it is reason for panic.) Finally, the file can be copied, unlinked, and recreated. I did a thorough search and found a dozen other files on the system with the same issue. REMEDY: ------- It seems that such flaws can lure undetected on a system for an indefinite time. The only way to find them seems read all inode data, via something like #find -x `mount -t zfs | awk '{print $3}'` -type d -exec ls -la {} \; ROOT CAUSE: ----------- Not fully clear. It may be related to hardware (memory) flaws.