From owner-freebsd-fs@FreeBSD.ORG Mon Sep 3 10:39:05 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7CAA61065674; Mon, 3 Sep 2012 10:39:05 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:150:6101::4]) by mx1.freebsd.org (Postfix) with ESMTP id AC5FB8FC17; Mon, 3 Sep 2012 10:39:04 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.2]) by mail.vx.sk (Postfix) with ESMTP id 588DF43230; Mon, 3 Sep 2012 12:39:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk by core.vx.sk (amavisd-new, unix socket) with LMTP id fGua5wD52vks; Mon, 3 Sep 2012 12:38:57 +0200 (CEST) Received: from [10.9.8.1] (188-167-78-15.dynamic.chello.sk [188.167.78.15]) by mail.vx.sk (Postfix) with ESMTPSA id 937534320A; Mon, 3 Sep 2012 12:38:57 +0200 (CEST) Message-ID: <504488C1.9040803@FreeBSD.org> Date: Mon, 03 Sep 2012 12:38:57 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <504428EB.4020702@shatow.net> <504430F9.8000105@shatow.net> <5044482D.90602@shatow.net> <5044556C.3020208@shatow.net> In-Reply-To: <5044556C.3020208@shatow.net> X-Enigmail-Version: 1.4.4 Content-Type: multipart/mixed; boundary="------------090307020801000706040405" Cc: freebsd-fs@freebsd.org Subject: Re: Panic in zfs_freebsd_getattr -> zfs_fuid_table_load - avl_find() succeeded inside avl_add() [ACL, 9.1-PRERELEASE] [SOLVED] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 10:39:05 -0000 This is a multi-part message in MIME format. --------------090307020801000706040405 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Pawel, what do you think of the attached patch? It does the alloc/free more the "illumos" way and also enhances readability. Cheers, mm On 3.9.2012 8:59, Bryan Drewery wrote: > On 9/3/2012 1:03 AM, Bryan Drewery wrote: >> On 9/2/2012 11:24 PM, Bryan Drewery wrote: >>>> On Sep 2, 2012 8:51 PM, "Bryan Drewery" >>> > wrote: >>>> >>>> Running 9.1-PRERELEASE currently. >>>> >>>> Just set this server up, imported the pool from OpenIndiana 151 I >>>> believe it was. >>>> >>>> When I access (simply `ls`) certain files/directories, the system >>>> panics. These files have ACL properties set on them from the Solaris >>>> system. >>>> >>>> This system has 32gb of ram and only 8gb swap setup, so I do not >>>> currently have a kernel core dump. It's also practically a production >>>> machine, so I do not have much leeway in testing on it. >>>> >>>> backtrace: >>>> >>>> >From running ls(1): >>>> >>>> panic: avl_find() succeeded inside avl_add() >> I removed my seat belt and made this PANIC into a return; I don't know >> the impact of this, but I am able to access the files now. >> >> I'm looking for what duplicated entries there are. Any advice on this >> would be appreciated. >> >> I'll avoid clearing the ACL properties for now. > I've solved this and now have a working system. > > r230454 [1] fixes this. It had a MFC of 1 week but never made it to > 9-STABLE. > > Please MFC this! > > OTOH, the change looks wrong, but I don't know enough to say that for > certain. > > > Why change kd_name to size 1, and then use strcpy(). Looks like an easy > overflow. > > [1] http://lists.freebsd.org/pipermail/svn-src-head/2012-January/033707.html > > >> >>>> avl_add+0x4b >>>> zfs_fuid_table_load+0x198 >>>> zfs_fuid_init+0x12c >>>> zfs_fuid_find_by_idx+0xc7 >>>> zfs_fuid_map_id+0x19 >>>> zfs_groupmember+0x16 >>>> zfs_zaccess_aces_check+0x196 >>>> zfs_zaccess+0xc6 >>>> zfs_freebsd_getattr+0x1c1 >>>> vn_stat+0x6a >>>> kern_statat_vnhook+0xf9 >>>> kern_statat+0x15 >>>> sys_lstat+0x2a >>>> amd64_syscall+0x540 >>>> >>>> At first I thought this was related to MAC / ugidfw, but I am able to >>>> reproduce with those not compiled in. FWIW, here is a backtrace from >>>> having that enabled: >>>> >>>> panic: avl_find() succeeded inside avl_add() >>>> avl_add+0x4b >>>> zfs_fuid_table_load+0x198 >>>> zfs_fuid_init+0x12c >>>> zfs_fuid_find_by_idx+0xc7 >>>> zfs_fuid_map_id+0x19 >>>> zfs_groupmember+0x16 >>>> zfs_zaccess_aces_check+0x196 >>>> zfs_zaccess+0xc6 >>>> zfs_freebsd_getattr+0x1c1 >>>> ugidfw_check_vp+0x6c >>>> mac_vnode_check_stat+0xa7 >>>> vn_stat+0x39 >>>> kern_statat_vnhook+0xf9 >>>> kern_statat+0x15 >>>> sys_stat+0x2a >>>> amd64_syscall+0x540 >>>> >>>> >>>> Is there some easy way to clear these ACL properties on the files? I do >>>> not need them. >>>> >>>> Any suggestions on how I might fix this or debug this further? >>>> >>>> >>>> Bryan -- Martin Matuska FreeBSD committer http://blog.vx.sk --------------090307020801000706040405 Content-Type: text/plain; charset=windows-1250; name="sid.h.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="sid.h.patch" SW5kZXg6IHN5cy9jZGRsL2NvbXBhdC9vcGVuc29sYXJpcy9zeXMvc2lkLmgKPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gc3lzL2NkZGwvY29tcGF0L29wZW5zb2xhcmlzL3N5cy9zaWQuaAkocmV2aXNp b24gMjM5NzcwKQorKysgc3lzL2NkZGwvY29tcGF0L29wZW5zb2xhcmlzL3N5cy9zaWQuaAko d29ya2luZyBjb3B5KQpAQCAtMzAsNyArMzAsOCBAQAogI2RlZmluZQlfT1BFTlNPTEFSSVNf U1lTX1NJRF9IXwogCiB0eXBlZGVmIHN0cnVjdCBrc2lkZG9tYWluIHsKLQljaGFyCWtkX25h bWVbMV07CS8qIERvbWFpbiBwYXJ0IG9mIFNJRCAqLworCWNoYXIJKmtkX25hbWU7CS8qIERv bWFpbiBwYXJ0IG9mIFNJRCAqLworCXVpbnRfdAlrZF9sZW47CiB9IGtzaWRkb21haW5fdDsK IHR5cGVkZWYgdm9pZAlrc2lkX3Q7CiAKQEAgLTM4LDggKzM5LDEyIEBACiBrc2lkX2xvb2t1 cGRvbWFpbihjb25zdCBjaGFyICpkb21haW4pCiB7CiAJa3NpZGRvbWFpbl90ICprZDsKKwlz aXplX3QgbGVuOwogCi0Ja2QgPSBrbWVtX2FsbG9jKHNpemVvZigqa2QpICsgc3RybGVuKGRv bWFpbiksIEtNX1NMRUVQKTsKKwlsZW4gPSBzdHJsZW4oZG9tYWluKSArIDE7CisJa2QgPSBr bWVtX2FsbG9jKHNpemVvZigqa2QpLCBLTV9TTEVFUCk7CisJa2QtPmtkX2xlbiA9ICh1aW50 X3QpbGVuOworCWtkLT5rZF9uYW1lID0ga21lbV9hbGxvYyhsZW4sIEtNX1NMRUVQKTsKIAlz dHJjcHkoa2QtPmtkX25hbWUsIGRvbWFpbik7CiAJcmV0dXJuIChrZCk7CiB9CkBAIC00OCw2 ICs1Myw3IEBACiBrc2lkZG9tYWluX3JlbGUoa3NpZGRvbWFpbl90ICprZCkKIHsKIAorCWtt ZW1fZnJlZShrZC0+a2RfbmFtZSwga2QtPmtkX2xlbik7CiAJa21lbV9mcmVlKGtkLCBzaXpl b2YoKmtkKSk7CiB9CiAK --------------090307020801000706040405--