From owner-freebsd-fs@freebsd.org Mon Aug 8 22:48:19 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 82967BB3DE5; Mon, 8 Aug 2016 22:48:19 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 4738E12D7; Mon, 8 Aug 2016 22:48:19 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi0-x231.google.com with SMTP id 4so256900020oih.2; Mon, 08 Aug 2016 15:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=5UumD63tkY36vKyctmT9/WrEk+ij11xWL4z4+zw77tg=; b=EoT/aiBjXIeL9dESvwgyfLe7Il2pDs6F3sB7Z9pqcXO4h9GN20sF/AcctzxcPFuFyS tRD5oYMq8PMABqafNiYRbbof3YkTLR/kgXQ3Uvps/C715tbfAlNYEZ0/WzR050fP5Uz8 uYbjV0eO+NDCfzsT9ek6j83d5joVLspemzYEgN5Pilu77Z73EJGyB4Dbdwodu3WUX7TH IciYf1edUiQiAUy1tTWjiC1jEU3APJDGk9Wq7C0CXFw4Z9mPeatL5wBlHO8v0QoehM9d xIep/UYg1iUX9p/W6CKkoWVtiS9dV4pZi4wy8JXsP7rCPjC1S2BO5+OGodTXyNbJzDn2 Xptg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=5UumD63tkY36vKyctmT9/WrEk+ij11xWL4z4+zw77tg=; b=fa7P7WYqweevrX/TmSc1UjmH6qB10bymp4+KtefNog7p8jOaopSOttZNeHdiPndoSl JU2Bfa3WdxmlIc5+rjkZgHJOijKW4GLIVdJwpWhI9IhuJEq1ndhsTIfYRdkC00YEUs4n lstzLg0bIuUR2jKZ+vw615eot5h/8cLL5GiXgHsQbmKPROw4xOoPQ7mTxVz4z2HvVVmm qkM38rQIX2OApjcfAWUMAt1OFVvDaMQDgYYiTI428rfdWNQTGMj3c0riIfl5YyI9oAMn GKAzX9Pjh7q3+mXHo1z/oQKNLrFSgg+kGAg/v81k/xEdWK4wl60SHwbzlt9hwf9OtxJi 3Bfg== X-Gm-Message-State: AEkoouvsLeduBxhDL2qIgj/9JwMAMOqPeCsdnYKGLFeT8Dx4qsCSGPVLUDUAZZtY8TX9Qcj8EYDi8xSRSUFo+A== X-Received: by 10.157.32.195 with SMTP id x61mr1531490ota.10.1470696498284; Mon, 08 Aug 2016 15:48:18 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.202.196.149 with HTTP; Mon, 8 Aug 2016 15:48:17 -0700 (PDT) In-Reply-To: <4bb4d0c0-fdbb-ed8c-1a47-0e789d777c1a@FreeBSD.org> References: <3f79e88d-a519-0c8d-f16a-7c83460a37c1@FreeBSD.org> <04a12279-ab01-5f5c-d8d3-5571db07c229@FreeBSD.org> <4bb4d0c0-fdbb-ed8c-1a47-0e789d777c1a@FreeBSD.org> From: Alan Somers Date: Mon, 8 Aug 2016 16:48:17 -0600 X-Google-Sender-Auth: 943pNaoiqTErGnrXMF9O_s2T26A Message-ID: Subject: Re: some [big] changes to ZPL (ZFS<->VFS ) To: Andriy Gapon Cc: FreeBSD Filesystems , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 22:48:19 -0000 On r303834 I can no longer reproduce the problem. -Alan On Sat, Aug 6, 2016 at 5:05 AM, Andriy Gapon wrote: > On 05/08/2016 23:31, Alan Somers wrote: >> I'm not certain it's related, but on a head build at r303767 I see a >> LOR and a reproducible panic that involve the snapdir code. > > Alan, > > thank you very much for the clear report and for the very easy > reproduction scenario. I am not sure how I missed this simple and > severe bug. > Please try r303791, it should fix the problem. > > I believe that the LOR is not new and been there since we started using > distinct tags for .zfs special vnodes. > >> First, the LOR: >> $ zpool destroy foo >> >> lock order reversal: >> 1st 0xfffff800404c8b78 zfs (zfs) @ >> /usr/home/alans/freebsd/head/sys/kern/vfs_mount.c:1244 >> 2nd 0xfffff800404c85f0 zfs_gfs (zfs_gfs) @ >> /usr/home/alans/freebsd/head/sys/cddl/contrib/opensolaris/uts/common/fs/gfs.c:484 >> stack backtrace: >> #0 0xffffffff80aa90b0 at witness_debugger+0x70 >> #1 0xffffffff80aa8fa4 at witness_checkorder+0xe54 >> #2 0xffffffff80a22072 at __lockmgr_args+0x4c2 >> #3 0xffffffff80af8e7c at vop_stdlock+0x3c >> #4 0xffffffff81018880 at VOP_LOCK1_APV+0xe0 >> #5 0xffffffff80b19f2a at _vn_lock+0x9a >> #6 0xffffffff821b9c53 at gfs_file_create+0x73 >> #7 0xffffffff821b9cfd at gfs_dir_create+0x1d >> #8 0xffffffff8228aa07 at zfsctl_mknode_snapdir+0x47 >> #9 0xffffffff821ba1a5 at gfs_dir_lookup+0x185 >> #10 0xffffffff821ba68d at gfs_vop_lookup+0x1d >> #11 0xffffffff82289a42 at zfsctl_root_lookup+0xf2 >> #12 0xffffffff8228a8c3 at zfsctl_umount_snapshots+0x83 >> #13 0xffffffff822a1d2b at zfs_umount+0x7b >> #14 0xffffffff80b02a14 at dounmount+0x6f4 >> #15 0xffffffff80b0228d at sys_unmount+0x35d >> #16 0xffffffff80ebbb7b at amd64_syscall+0x2db >> #17 0xffffffff80e9b72b at Xfast_syscall+0xfb >> >> >> Here's the panic: >> $ zpool create testpool da0 >> $ touch /testpool/testfile >> $ zfs snapshot testpool@testsnap >> $ cd /testpool/.zfs/snapshots >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 2; apic id = 04 >> fault virtual address = 0x8 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff80b19f1c >> stack pointer = 0x28:0xfffffe0b54bf7430 >> frame pointer = 0x28:0xfffffe0b54bf74a0 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 966 (bash) >> trap number = 12 >> panic: page fault >> cpuid = 2 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0b54bf6fc0 >> vpanic() at vpanic+0x182/frame 0xfffffe0b54bf7040 >> panic() at panic+0x43/frame 0xfffffe0b54bf70a0 >> trap_fatal() at trap_fatal+0x351/frame 0xfffffe0b54bf7100 >> trap_pfault() at trap_pfault+0x1fd/frame 0xfffffe0b54bf7160 >> trap() at trap+0x284/frame 0xfffffe0b54bf7370 >> calltrap() at calltrap+0x8/frame 0xfffffe0b54bf7370 >> --- trap 0xc, rip = 0xffffffff80b19f1c, rsp = 0xfffffe0b54bf7440, rbp >> = 0xfffffe0b54bf74a0 --- >> _vn_lock() at _vn_lock+0x8c/frame 0xfffffe0b54bf74a0 >> zfs_lookup() at zfs_lookup+0x50d/frame 0xfffffe0b54bf7540 >> zfs_freebsd_lookup() at zfs_freebsd_lookup+0x91/frame 0xfffffe0b54bf7680 >> VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xda/frame 0xfffffe0b54bf76b0 >> vfs_cache_lookup() at vfs_cache_lookup+0xd6/frame 0xfffffe0b54bf7710 >> VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xda/frame 0xfffffe0b54bf7740 >> lookup() at lookup+0x5a2/frame 0xfffffe0b54bf77d0 >> namei() at namei+0x5b2/frame 0xfffffe0b54bf7890 >> kern_statat() at kern_statat+0xa8/frame 0xfffffe0b54bf7a40 >> sys_stat() at sys_stat+0x2d/frame 0xfffffe0b54bf7ae0 >> amd64_syscall() at amd64_syscall+0x2db/frame 0xfffffe0b54bf7bf0 >> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0b54bf7bf0 >> >> >> I can provide core files, test scripts, whatever you need. Thanks for >> tackling this difficult problem. >> >> -Alan >> >> On Fri, Aug 5, 2016 at 12:36 AM, Andriy Gapon wrote: >>> On 03/08/2016 17:25, Andriy Gapon wrote: >>>> Another change that was not strictly required and which is probably too >>>> intrusive is killing the support for case insensitive operations. My >>>> thinking was that FreeBSD VFS does not provide support for those anyway. >>>> But I'll probably restore the code, at least in the bottom half of the >>>> ZPL, before committing the change. >>> >>> It turned out that most of the removed code was dead anyway and it took >>> just a few lines of code to restore support for case-insensitive >>> filesystems. Filesystems with mixed case sensitivity behave exactly the >>> same as case-sensitive filesystem as it has always been the case on FreeBSD. >>> >>> Anyway the big change has just been committed: >>> https://svnweb.freebsd.org/changeset/base/303763 >>> Please test away. >>> >>> Another note is that the filesystem name cache is now disabled for case >>> insensitive filesystems and filesystems with normalization other than >>> none. That may hurt the lookup performance, but should ensure >>> correctness of operations. >>> >>> -- >>> Andriy Gapon >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > -- > Andriy Gapon