From nobody Mon Aug 30 14:30:18 2021 X-Original-To: freebsd-fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6189417989D9 for ; Mon, 30 Aug 2021 14:30:41 +0000 (UTC) (envelope-from freebsd-fs@m.gmane-mx.org) Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Gyt5r4c0Wz4mjB for ; Mon, 30 Aug 2021 14:30:40 +0000 (UTC) (envelope-from freebsd-fs@m.gmane-mx.org) Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1mKiIy-0007e5-RE for freebsd-fs@freebsd.org; Mon, 30 Aug 2021 16:30:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-fs@freebsd.org From: Johannes Totz Subject: Re: ZFS on high-latency devices Date: Mon, 30 Aug 2021 15:30:18 +0100 Message-ID: References: List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.0.3 Content-Language: en-GB In-Reply-To: X-Rspamd-Queue-Id: 4Gyt5r4c0Wz4mjB X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=jo-t.de (policy=none); spf=pass (mx1.freebsd.org: domain of freebsd-fs@m.gmane-mx.org designates 116.202.254.214 as permitted sender) smtp.mailfrom=freebsd-fs@m.gmane-mx.org X-Spamd-Result: default: False [0.10 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[jo-t.de : SPF not aligned (relaxed), No valid DKIM,none]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[johannes@jo-t.de,freebsd-fs@m.gmane-mx.org]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:116.202.0.0/16, country:DE]; FROM_NEQ_ENVFROM(0.00)[johannes@jo-t.de,freebsd-fs@m.gmane-mx.org]; FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[]; RCVD_COUNT_TWO(0.00)[2] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On 28/08/2021 04:37, Peter Jeremy wrote: > On 2021-Aug-20 00:16:28 +0100, Johannes Totz wrote: >> Do you have geli included in those perf tests? Any difference if you >> leave it out? > > Yes, I mentioned geli (and I also have IPSEC, which I forgot to > mention). I haven't tried taking them out but dd(1) tests suggest > they aren't a problem. > >> What's making the throughout slow? zfs issuing a bunch of small writes >> and then trying to read something (unrelated)? Is there just not enough >> data to be written to saturate the link? > > At least from eyeballing gstat, there are basically no reads involved > in the zfs recv. The problem seems to be that writes aren't evenly > spread across all the vdevs, combined with very long delays associated > with flushing snapshots. I have considered instrumenting ggate{c,d} > to see if I can identify any issues. Hm... that makes me wonder: what's your pool layout? Is the ggate vdev the only one, or is it a mirror member (and the others are local)? >> Totally random thought: there used to be a vdev cache (not sure if >> that's still around) that would inflate read requests to hopefully drag >> in more data that might be useful soon. > > ZFS includes that functionality itself. > >> Have you tried hastd? > > I haven't but hastd also uses GEOM_GATE so I wouldn't expect > significantly different behaviour. I wouldn't have expected geom-gate to have much of an impact here but instead what happens with the requests once they are in user mode, ie how they are send across the wire. Looks like hastd does something fancy here (I've never used it myself). But I wonder now... ggatec does not support flush requests. Have you patched it already? How does zfs behave (or change its behaviour) if BIO_FLUSH succeeds? From nobody Tue Aug 31 08:59:26 2021 X-Original-To: freebsd-fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id EA1A717A99F3 for ; Tue, 31 Aug 2021 08:59:34 +0000 (UTC) (envelope-from alexander.lochmann@tu-dortmund.de) Received: from unimail.uni-dortmund.de (mx1.hrz.uni-dortmund.de [129.217.128.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "unimail.tu-dortmund.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GzLjL0m2rz3D6t for ; Tue, 31 Aug 2021 08:59:33 +0000 (UTC) (envelope-from alexander.lochmann@tu-dortmund.de) Received: from [192.168.113.101] ([129.217.43.48]) (authenticated bits=0) by unimail.uni-dortmund.de (8.17.1/8.17.1) with ESMTPSA id 17V8xQfr017384 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT); Tue, 31 Aug 2021 10:59:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tu-dortmund.de; s=unimail; t=1630400366; bh=IWuUAcYiVcgyYgbLdgbVnPiqF4v0tjZU89uvo5NzNYc=; h=To:Cc:References:From:Subject:Date:In-Reply-To; b=Fq6BO2s25t4RM4fJllZU7lRqq45DL7F8kJrwmJdvkSec2hOdeRlCf3QCzKRzdUA6m SEO3BuRoDGJk8KmW7RinkXCtduPUEMjY8q3q318X7F24ZgQjp62ahWLSFf/fTstvEW kGvTwC+9M67z93HdOUxTgy2plXvPsjxmBPWiqXzo= To: Konstantin Belousov Cc: freebsd-fs , Horst Schirmeier References: <55f3661e-2173-793e-4834-bbcd79d3d99e@tu-dortmund.de> <380bdcc8-bede-2a64-8e5e-031552231d82@tu-dortmund.de> <46649402-d28a-6f81-f0a8-39180b681f4c@tu-dortmund.de> From: Alexander Lochmann Subject: Re: Various unprotected accesses to buf and vnode Message-ID: Date: Tue, 31 Aug 2021 10:59:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TrAMUIRx3yG1tw1cZYcEB1sM5XQ6fCWrv" X-Rspamd-Queue-Id: 4GzLjL0m2rz3D6t X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tu-dortmund.de header.s=unimail header.b=Fq6BO2s2; dmarc=none; spf=pass (mx1.freebsd.org: domain of alexander.lochmann@tu-dortmund.de designates 129.217.128.51 as permitted sender) smtp.mailfrom=alexander.lochmann@tu-dortmund.de X-Spamd-Result: default: False [-7.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[129.217.128.51:from]; R_SPF_ALLOW(-0.20)[+ip4:129.217.128.0/24]; HAS_ATTACHMENT(0.00)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[129.217.128.51:from]; DKIM_TRACE(0.00)[tu-dortmund.de:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; ASN(0.00)[asn:680, ipnet:129.217.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[tu-dortmund.de:s=unimail]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; DMARC_NA(0.00)[tu-dortmund.de]; DWL_DNSWL_LOW(-1.00)[tu-dortmund.de:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TrAMUIRx3yG1tw1cZYcEB1sM5XQ6fCWrv Content-Type: multipart/mixed; boundary="kshoIbYCUKWHwEeU7Nzqi78mBDHA0VuOS"; protected-headers="v1" From: Alexander Lochmann To: Konstantin Belousov Cc: freebsd-fs , Horst Schirmeier Message-ID: Subject: Re: Various unprotected accesses to buf and vnode References: <55f3661e-2173-793e-4834-bbcd79d3d99e@tu-dortmund.de> <380bdcc8-bede-2a64-8e5e-031552231d82@tu-dortmund.de> <46649402-d28a-6f81-f0a8-39180b681f4c@tu-dortmund.de> In-Reply-To: --kshoIbYCUKWHwEeU7Nzqi78mBDHA0VuOS Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 29.08.21 00:29, Konstantin Belousov wrote: > Ok, I see some call sequences (?), but again all of them are ffs_write(= ) > (one is ext2_write) calling into cluster_write(). There the buffer loc= k > is owned. >=20 > Show me the specific call sequence where it is not. Who owns the buffer lock at that point? Has its ownership been transferred to the kernel? Do you know where the buffer lock is acquired? According to our data, the buffer lock of the current accessed buffer is not owned. Otherwise, there would an entry like this 'EMBSAME(buf.b_lock[w])'. So in all of those call sequences the buffer lock is not acquired. However, I'd not rule out that our tooling could be broken as well. > Ah, yes, the calls from lookup and open would be with the shared lock. > Still, we lock the vnode interlock to avoid double-allocating the v_obj= ect > object, so it is fine. Some mode of the vnode lock is required nonethe= less, > because otherwise we might miss reclaim which guarantees that v_object = > is freed. >=20 I see. Does this rule apply to all fields for which the vnode lock is the designated lock? =46rom a different angle: The documentation says about bo_object: ''v' is the vnode lock which embeds the bufobj.'. Does 'the vnode lock' mean a specific lock, or a group of locks? --=20 Technische Universit=C3=A4t Dortmund Alexander Lochmann PGP key: 0xBC3EF6FD Otto-Hahn-Str. 16 phone: +49.231.7556141 D-44227 Dortmund fax: +49.231.7556116 http://ess.cs.tu-dortmund.de/Staff/al --kshoIbYCUKWHwEeU7Nzqi78mBDHA0VuOS-- --TrAMUIRx3yG1tw1cZYcEB1sM5XQ6fCWrv Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEElhZsUHzVP0dbkjCRWT7tBbw+9v0FAmEt724FAwAAAAAACgkQWT7tBbw+9v1b xRAAqUWm+2aCjYoj0iNxaI4E9njrOPn6IQbWgtggp3wmqUq8csTvwyTEiBXtrJGFDwL62B0M4m9C jjCvGZsIAXW5+VGy5B8CZQ2FzasC2L6GamLejjLAFIhG5fSDpjVCNU9DipdziLPutK+CQcL4/9Xi U9iyAmGwIdt8ps4FE7sKS0gD3ndvYUHbZZOtn2lPlxZNIpnd7xaQJuSFpMaFW8RVE1cm4ZYtVvle Ylh5lTkjehogSzFhV6Wv2pMTubX+j4N7JvOE9nZKh8iHc0kuKmF5HNXW5d3vesuIJNAK0Wg5ZKDu 9072JrhnE6Ll6DNySXRBTXFQMDwt4YDT9yt1wE8d4yS+OfAu7c8O2Bs/taNpiJ057fw0odmi1/jK CUu+5Urvix6mnmcJrdeYV1wBer2o2Wm6Irm2Qm4wZ3ouaxi/MkJKGkSPtwhh9SoG2eMx4jY4a+Eg O9zFdHiKsI+rfr9sQytn7avmMIgPCep6oDMe44x8/jF2V+DULm1lAZzvsQyRxAoDenGzQ0BiDib9 NpqiGLTUScKRcOsTxnoQ/5zMayvbODwnKyEDAlmWvMXmUbDvc1e0Vw38ucBWYdZmRGc11aKwC/zw +8jiDKhjD2z7e3BTeTN8Kc8q/CTFboumbaHv299ZqeC29iQIVAnQNEkp3xZQ/z/JHmaW9LWaioxO 9BQ= =bTT2 -----END PGP SIGNATURE----- --TrAMUIRx3yG1tw1cZYcEB1sM5XQ6fCWrv-- From nobody Tue Aug 31 14:44:42 2021 X-Original-To: freebsd-fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 43CA617B22D5 for ; Tue, 31 Aug 2021 14:44:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GzVMr756Vz4fp2 for ; Tue, 31 Aug 2021 14:44:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 17VEig9u094413 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 31 Aug 2021 17:44:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 17VEig9u094413 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 17VEigaB094412; Tue, 31 Aug 2021 17:44:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 31 Aug 2021 17:44:42 +0300 From: Konstantin Belousov To: Alexander Lochmann Cc: freebsd-fs , Horst Schirmeier Subject: Re: Various unprotected accesses to buf and vnode Message-ID: References: <55f3661e-2173-793e-4834-bbcd79d3d99e@tu-dortmund.de> <380bdcc8-bede-2a64-8e5e-031552231d82@tu-dortmund.de> <46649402-d28a-6f81-f0a8-39180b681f4c@tu-dortmund.de> List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4GzVMr756Vz4fp2 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Aug 31, 2021 at 10:59:26AM +0200, Alexander Lochmann wrote: > On 29.08.21 00:29, Konstantin Belousov wrote: > > Ok, I see some call sequences (?), but again all of them are ffs_write() > > (one is ext2_write) calling into cluster_write(). There the buffer lock > > is owned. > > > > Show me the specific call sequence where it is not. > Who owns the buffer lock at that point? Has its ownership been > transferred to the kernel? > Do you know where the buffer lock is acquired? > > According to our data, the buffer lock of the current accessed buffer is > not owned. Otherwise, there would an entry like this > 'EMBSAME(buf.b_lock[w])'. > So in all of those call sequences the buffer lock is not acquired. > However, I'd not rule out that our tooling could be broken as well. Buffer is locked inside UFS_BALLOC(), which returns it to the ffs_write() use. > > > Ah, yes, the calls from lookup and open would be with the shared lock. > > Still, we lock the vnode interlock to avoid double-allocating the v_object > > object, so it is fine. Some mode of the vnode lock is required nonetheless, > > because otherwise we might miss reclaim which guarantees that v_object > > is freed. > > > I see. Does this rule apply to all fields for which the vnode lock is > the designated lock? Which rule? We just need to provide some mutual exclusion rules, while satisfying the requirements of the lock hierarchy ordering to avoid deadlock. If we can guarantee that specific field is always modified while owning the vnode lock exclusively, fine. If we only own the vnode lock shared, typically vnode interlock provides the exclusivity for access. Read e.g. sys/ufs/ufs/inode.h gerald comment above struct inode definition. It provides more detailed exposure. > From a different angle: > The documentation says about bo_object: ''v' is the vnode lock which > embeds the bufobj.'. > Does 'the vnode lock' mean a specific lock, or a group of locks? Vnode lock is a lock obtained with vn_lock(). It is up to filesystem to implement VOP_LOCK() which locks the vnode. Default VOP_LOCK() locks vp->v_vnlock, which again by default points to &vp->v_lock. There are several special cases. For instance, for FFS and snapshot vnodes, v_vnlock points to the snapdata->sn_lock (snapdata is unique per FFS mount). For nullfs non-reclaimed vnodes, v_vnlock points to the lower vnode lock. From nobody Wed Sep 1 04:46:00 2021 X-Original-To: fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3085E17AA4BF for ; Wed, 1 Sep 2021 04:46:04 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Gzs2N12FYz4Qtw for ; Wed, 1 Sep 2021 04:46:04 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id C6A0B23AD4 for ; Wed, 1 Sep 2021 04:46:03 +0000 (UTC) (envelope-from avg@FreeBSD.org) To: freebsd-fs From: Andriy Gapon Subject: kernel crash from zpool create -o version=13 Message-ID: Date: Wed, 1 Sep 2021 07:46:00 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.13.0 List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N Just a quick check before I dig into it. Is this something that could have been fixed recently in OpenZFS? Seems like a NULL pointer in zfs_mknode -> zfs_aclset_common. fault virtual address = 0x4 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80370f2e stack pointer = 0x28:0xfffffe01f24272a0 frame pointer = 0x28:0xfffffe01f2427450 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 = 27002 (zpool) trap number = 12 panic: page fault cpuid = 3 time = 1630470367 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff805c328b = db_trace_self_wrapper+0x2b/frame 0xfffffe01f2426e60 kdb_backtrace() at 0xffffffff80889b17 = kdb_backtrace+0x37/frame 0xfffffe01f2426f10 vpanic() at 0xffffffff80846aa8 = vpanic+0x188/frame 0xfffffe01f2426f70 panic() at 0xffffffff808466c3 = panic+0x43/frame 0xfffffe01f2426fd0 trap_fatal() at 0xffffffff80b33905 = trap_fatal+0x375/frame 0xfffffe01f2427030 trap_pfault() at 0xffffffff80b339e0 = trap_pfault+0x80/frame 0xfffffe01f24270a0 trap() at 0xffffffff80b32fc1 = trap+0x271/frame 0xfffffe01f24271b0 trap_check() at 0xffffffff80b33d39 = trap_check+0x29/frame 0xfffffe01f24271d0 calltrap() at 0xffffffff80b0f3a8 = calltrap+0x8/frame 0xfffffe01f24271d0 --- trap 0xc, rip = 0xffffffff80370f2e, rsp = 0xfffffe01f24272a0, rbp = 0xfffffe01f2427450 --- zfs_aclset_common() at 0xffffffff80370f2e = zfs_aclset_common+0x5e/frame 0xfffffe01f2427450 zfs_mknode() at 0xffffffff803894f3 = zfs_mknode+0xb43/frame 0xfffffe01f2427580 zfs_create_fs() at 0xffffffff8038cc60 = zfs_create_fs+0x590/frame 0xfffffe01f24276e0 dsl_pool_create() at 0xffffffff8041f6df = dsl_pool_create+0x2af/frame 0xfffffe01f2427740 spa_create() at 0xffffffff80450986 = spa_create+0x6f6/frame 0xfffffe01f2427800 zfs_ioc_pool_create() at 0xffffffff804c101b = zfs_ioc_pool_create+0x1fb/frame 0xfffffe01f2427880 zfsdev_ioctl_common() at 0xffffffff804bbea6 = zfsdev_ioctl_common+0x306/frame 0xfffffe01f2427900 zfsdev_ioctl() at 0xffffffff8036b49c = zfsdev_ioctl+0xfc/frame 0xfffffe01f2427940 devfs_ioctl() at 0xffffffff80718aef = devfs_ioctl+0xcf/frame 0xfffffe01f24279a0 VOP_IOCTL_APV() at 0xffffffff80bb5bd2 = VOP_IOCTL_APV+0x92/frame 0xfffffe01f24279c0 VOP_IOCTL() at 0xffffffff8092a6d4 = VOP_IOCTL+0x34/frame 0xfffffe01f2427a10 vn_ioctl() at 0xffffffff809259b0 = vn_ioctl+0xc0/frame 0xfffffe01f2427b00 devfs_ioctl_f() at 0xffffffff80718fde = devfs_ioctl_f+0x1e/frame 0xfffffe01f2427b20 fo_ioctl() at 0xffffffff808ae30b = fo_ioctl+0xb/frame 0xfffffe01f2427b30 kern_ioctl() at 0xffffffff808ae2a1 = kern_ioctl+0x1d1/frame 0xfffffe01f2427b80 sys_ioctl() at 0xffffffff808ae022 = sys_ioctl+0x132/frame 0xfffffe01f2427c50 syscallenter() at 0xffffffff80b34529 = syscallenter+0x159/frame 0xfffffe01f2427ca0 amd64_syscall() at 0xffffffff80b34205 = amd64_syscall+0x15/frame 0xfffffe01f2427d30 fast_syscall_common() at 0xffffffff80b0fcce = fast_syscall_common+0xf8/frame 0xfffffe01f2427d30 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8004ca3ba, rsp = 0x7fffffffbb28, rbp = 0x7fffffffbb90 --- -- Andriy Gapon From nobody Wed Sep 1 08:03:22 2021 X-Original-To: fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9366F17B5198 for ; Wed, 1 Sep 2021 08:03:25 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GzxQ53GShz4dHn; Wed, 1 Sep 2021 08:03:25 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 093B125362; Wed, 1 Sep 2021 08:03:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) From: Andriy Gapon To: freebsd-fs , Mateusz Guzik References: Subject: Re: kernel crash from zpool create -o version=13 Message-ID: <19dca56a-c2b0-c7d2-4d00-ac4497d17cbb@FreeBSD.org> Date: Wed, 1 Sep 2021 11:03:22 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.13.0 List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N On 01/09/2021 07:46, Andriy Gapon wrote: > > Just a quick check before I dig into it. > Is this something that could have been fixed recently in OpenZFS? > Seems like a NULL pointer in zfs_mknode -> zfs_aclset_common. The crash is in this piece of code: 1176 if (zp->z_zfsvfs->z_replay == B_FALSE) { 1177 ASSERT_VOP_IN_SEQC(ZTOV(zp)); 1178 } (kgdb) p zp->z_vnode $2 = (vnode_t *) 0x0 It seems that this is to be expected when zfs_mknode is called with IS_ROOT_NODE. > fault virtual address   = 0x4 > fault code              = supervisor read data, page not present > instruction pointer     = 0x20:0xffffffff80370f2e > stack pointer           = 0x28:0xfffffe01f24272a0 > frame pointer           = 0x28:0xfffffe01f2427450 > 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         = 27002 (zpool) > trap number             = 12 > panic: page fault > cpuid = 3 > time = 1630470367 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff805c328b = db_trace_self_wrapper+0x2b/frame > 0xfffffe01f2426e60 > kdb_backtrace() at 0xffffffff80889b17 = kdb_backtrace+0x37/frame 0xfffffe01f2426f10 > vpanic() at 0xffffffff80846aa8 = vpanic+0x188/frame 0xfffffe01f2426f70 > panic() at 0xffffffff808466c3 = panic+0x43/frame 0xfffffe01f2426fd0 > trap_fatal() at 0xffffffff80b33905 = trap_fatal+0x375/frame 0xfffffe01f2427030 > trap_pfault() at 0xffffffff80b339e0 = trap_pfault+0x80/frame 0xfffffe01f24270a0 > trap() at 0xffffffff80b32fc1 = trap+0x271/frame 0xfffffe01f24271b0 > trap_check() at 0xffffffff80b33d39 = trap_check+0x29/frame 0xfffffe01f24271d0 > calltrap() at 0xffffffff80b0f3a8 = calltrap+0x8/frame 0xfffffe01f24271d0 > --- trap 0xc, rip = 0xffffffff80370f2e, rsp = 0xfffffe01f24272a0, rbp = > 0xfffffe01f2427450 --- > zfs_aclset_common() at 0xffffffff80370f2e = zfs_aclset_common+0x5e/frame > 0xfffffe01f2427450 > zfs_mknode() at 0xffffffff803894f3 = zfs_mknode+0xb43/frame 0xfffffe01f2427580 > zfs_create_fs() at 0xffffffff8038cc60 = zfs_create_fs+0x590/frame > 0xfffffe01f24276e0 > dsl_pool_create() at 0xffffffff8041f6df = dsl_pool_create+0x2af/frame > 0xfffffe01f2427740 > spa_create() at 0xffffffff80450986 = spa_create+0x6f6/frame 0xfffffe01f2427800 > zfs_ioc_pool_create() at 0xffffffff804c101b = zfs_ioc_pool_create+0x1fb/frame > 0xfffffe01f2427880 > zfsdev_ioctl_common() at 0xffffffff804bbea6 = zfsdev_ioctl_common+0x306/frame > 0xfffffe01f2427900 > zfsdev_ioctl() at 0xffffffff8036b49c = zfsdev_ioctl+0xfc/frame 0xfffffe01f2427940 > devfs_ioctl() at 0xffffffff80718aef = devfs_ioctl+0xcf/frame 0xfffffe01f24279a0 > VOP_IOCTL_APV() at 0xffffffff80bb5bd2 = VOP_IOCTL_APV+0x92/frame 0xfffffe01f24279c0 > VOP_IOCTL() at 0xffffffff8092a6d4 = VOP_IOCTL+0x34/frame 0xfffffe01f2427a10 > vn_ioctl() at 0xffffffff809259b0 = vn_ioctl+0xc0/frame 0xfffffe01f2427b00 > devfs_ioctl_f() at 0xffffffff80718fde = devfs_ioctl_f+0x1e/frame 0xfffffe01f2427b20 > fo_ioctl() at 0xffffffff808ae30b = fo_ioctl+0xb/frame 0xfffffe01f2427b30 > kern_ioctl() at 0xffffffff808ae2a1 = kern_ioctl+0x1d1/frame 0xfffffe01f2427b80 > sys_ioctl() at 0xffffffff808ae022 = sys_ioctl+0x132/frame 0xfffffe01f2427c50 > syscallenter() at 0xffffffff80b34529 = syscallenter+0x159/frame 0xfffffe01f2427ca0 > amd64_syscall() at 0xffffffff80b34205 = amd64_syscall+0x15/frame 0xfffffe01f2427d30 > fast_syscall_common() at 0xffffffff80b0fcce = fast_syscall_common+0xf8/frame > 0xfffffe01f2427d30 > --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8004ca3ba, rsp = > 0x7fffffffbb28, rbp = 0x7fffffffbb90 --- > -- Andriy Gapon From nobody Wed Sep 1 09:49:33 2021 X-Original-To: fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0B1FD178CCE6 for ; Wed, 1 Sep 2021 09:49:37 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Gzzmc6v2wz3PH4; Wed, 1 Sep 2021 09:49:36 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 5C19925E60; Wed, 1 Sep 2021 09:49:36 +0000 (UTC) (envelope-from avg@freebsd.org) From: Andriy Gapon To: Mateusz Guzik , Ryan Moeller Cc: freebsd-fs References: <19dca56a-c2b0-c7d2-4d00-ac4497d17cbb@FreeBSD.org> Subject: Re: kernel crash from zpool create -o version=13 Message-ID: <83ff27b8-17dc-eb0c-0a12-fb21debeb881@FreeBSD.org> Date: Wed, 1 Sep 2021 12:49:33 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.13.0 List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N On 01/09/2021 12:40, Mateusz Guzik wrote: > On 9/1/21, Andriy Gapon wrote: >> On 01/09/2021 07:46, Andriy Gapon wrote: >>> >>> Just a quick check before I dig into it. >>> Is this something that could have been fixed recently in OpenZFS? >>> Seems like a NULL pointer in zfs_mknode -> zfs_aclset_common. >> >> The crash is in this piece of code: >> 1176 if (zp->z_zfsvfs->z_replay == B_FALSE) { >> 1177 ASSERT_VOP_IN_SEQC(ZTOV(zp)); >> 1178 } >> >> (kgdb) p zp->z_vnode >> $2 = (vnode_t *) 0x0 >> >> It seems that this is to be expected when zfs_mknode is called with >> IS_ROOT_NODE. >> > > I concur. I don't know why this place was not patched. > > Someone else(tm) should do the honors. I added a quick patch of checking that ZTOV(zp) is not NULL and that helped with creating a filesystem. But there is still a problem when creating a(nother) directory in such an old version filesystem (forced by the old pool version): VNASSERT failed: ({ seqc_t __seqc = (_vp->v_seqc); __builtin_expect((__seqc & 1), 0); }) not true at sys/contrib/openzfs/module/os/freebsd/zfs/zfs_acl.c:1177 (zfs_aclset_common) 0xfffff8008a4fa7a0: type VDIR usecount 1, writecount 0, refcount 1 seqc users 0 mountedhere 0 hold count flags () flags () lock type zfs: EXCL by thread 0xfffff801d8efd000 (pid 14130, zfs, tid 101094) panic: condition seqc_in_modify(_vp->v_seqc) not met at /usr/devel/git/trant/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_acl.c:1177 (zfs_aclset_common) cpuid = 5 time = 1630486427 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff805c328b = db_trace_self_wrapper+0x2b/frame 0xfffffe01bb1544d0 kdb_backtrace() at 0xffffffff80889b17 = kdb_backtrace+0x37/frame 0xfffffe01bb154580 vpanic() at 0xffffffff80846aa8 = vpanic+0x188/frame 0xfffffe01bb1545e0 panic() at 0xffffffff808466c3 = panic+0x43/frame 0xfffffe01bb154640 zfs_aclset_common() at 0xffffffff80371525 = zfs_aclset_common+0x645/frame 0xfffffe01bb154800 zfs_mknode() at 0xffffffff80389503 = zfs_mknode+0xb43/frame 0xfffffe01bb154930 zfs_mkdir() at 0xffffffff8037debc = zfs_mkdir+0x33c/frame 0xfffffe01bb1549e0 zfs_freebsd_mkdir() at 0xffffffff803833f7 = zfs_freebsd_mkdir+0x57/frame 0xfffffe01bb154a10 VOP_MKDIR_APV() at 0xffffffff80bb6c6c = VOP_MKDIR_APV+0x9c/frame 0xfffffe01bb154a30 VOP_MKDIR() at 0xffffffff809237fd = VOP_MKDIR+0x2d/frame 0xfffffe01bb154a70 kern_mkdirat() at 0xffffffff80923673 = kern_mkdirat+0xb3/frame 0xfffffe01bb154c40 sys_mkdir() at 0xffffffff809235b8 = sys_mkdir+0x18/frame 0xfffffe01bb154c50 syscallenter() at 0xffffffff80b34529 = syscallenter+0x159/frame 0xfffffe01bb154ca0 amd64_syscall() at 0xffffffff80b34205 = amd64_syscall+0x15/frame 0xfffffe01bb154d30 fast_syscall_common() at 0xffffffff80b0fcce = fast_syscall_common+0xf8/frame 0xfffffe01bb154d30 >>> fault virtual address = 0x4 >>> fault code = supervisor read data, page not present >>> instruction pointer = 0x20:0xffffffff80370f2e >>> stack pointer = 0x28:0xfffffe01f24272a0 >>> frame pointer = 0x28:0xfffffe01f2427450 >>> 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 = 27002 (zpool) >>> trap number = 12 >>> panic: page fault >>> cpuid = 3 >>> time = 1630470367 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at 0xffffffff805c328b = >>> db_trace_self_wrapper+0x2b/frame >>> 0xfffffe01f2426e60 >>> kdb_backtrace() at 0xffffffff80889b17 = kdb_backtrace+0x37/frame >>> 0xfffffe01f2426f10 >>> vpanic() at 0xffffffff80846aa8 = vpanic+0x188/frame 0xfffffe01f2426f70 >>> panic() at 0xffffffff808466c3 = panic+0x43/frame 0xfffffe01f2426fd0 >>> trap_fatal() at 0xffffffff80b33905 = trap_fatal+0x375/frame >>> 0xfffffe01f2427030 >>> trap_pfault() at 0xffffffff80b339e0 = trap_pfault+0x80/frame >>> 0xfffffe01f24270a0 >>> trap() at 0xffffffff80b32fc1 = trap+0x271/frame 0xfffffe01f24271b0 >>> trap_check() at 0xffffffff80b33d39 = trap_check+0x29/frame >>> 0xfffffe01f24271d0 >>> calltrap() at 0xffffffff80b0f3a8 = calltrap+0x8/frame 0xfffffe01f24271d0 >>> --- trap 0xc, rip = 0xffffffff80370f2e, rsp = 0xfffffe01f24272a0, rbp = >>> 0xfffffe01f2427450 --- >>> zfs_aclset_common() at 0xffffffff80370f2e = zfs_aclset_common+0x5e/frame >>> 0xfffffe01f2427450 >>> zfs_mknode() at 0xffffffff803894f3 = zfs_mknode+0xb43/frame >>> 0xfffffe01f2427580 >>> zfs_create_fs() at 0xffffffff8038cc60 = zfs_create_fs+0x590/frame >>> 0xfffffe01f24276e0 >>> dsl_pool_create() at 0xffffffff8041f6df = dsl_pool_create+0x2af/frame >>> 0xfffffe01f2427740 >>> spa_create() at 0xffffffff80450986 = spa_create+0x6f6/frame >>> 0xfffffe01f2427800 >>> zfs_ioc_pool_create() at 0xffffffff804c101b = >>> zfs_ioc_pool_create+0x1fb/frame >>> 0xfffffe01f2427880 >>> zfsdev_ioctl_common() at 0xffffffff804bbea6 = >>> zfsdev_ioctl_common+0x306/frame >>> 0xfffffe01f2427900 >>> zfsdev_ioctl() at 0xffffffff8036b49c = zfsdev_ioctl+0xfc/frame >>> 0xfffffe01f2427940 >>> devfs_ioctl() at 0xffffffff80718aef = devfs_ioctl+0xcf/frame >>> 0xfffffe01f24279a0 >>> VOP_IOCTL_APV() at 0xffffffff80bb5bd2 = VOP_IOCTL_APV+0x92/frame >>> 0xfffffe01f24279c0 >>> VOP_IOCTL() at 0xffffffff8092a6d4 = VOP_IOCTL+0x34/frame >>> 0xfffffe01f2427a10 >>> vn_ioctl() at 0xffffffff809259b0 = vn_ioctl+0xc0/frame 0xfffffe01f2427b00 >>> devfs_ioctl_f() at 0xffffffff80718fde = devfs_ioctl_f+0x1e/frame >>> 0xfffffe01f2427b20 >>> fo_ioctl() at 0xffffffff808ae30b = fo_ioctl+0xb/frame 0xfffffe01f2427b30 >>> kern_ioctl() at 0xffffffff808ae2a1 = kern_ioctl+0x1d1/frame >>> 0xfffffe01f2427b80 >>> sys_ioctl() at 0xffffffff808ae022 = sys_ioctl+0x132/frame >>> 0xfffffe01f2427c50 >>> syscallenter() at 0xffffffff80b34529 = syscallenter+0x159/frame >>> 0xfffffe01f2427ca0 >>> amd64_syscall() at 0xffffffff80b34205 = amd64_syscall+0x15/frame >>> 0xfffffe01f2427d30 >>> fast_syscall_common() at 0xffffffff80b0fcce = >>> fast_syscall_common+0xf8/frame >>> 0xfffffe01f2427d30 >>> --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8004ca3ba, rsp = >>> 0x7fffffffbb28, rbp = 0x7fffffffbb90 --- >>> >> >> >> -- >> Andriy Gapon >> > > -- Andriy Gapon From nobody Wed Sep 1 13:10:53 2021 X-Original-To: freebsd-fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1F1BF179E28B for ; Wed, 1 Sep 2021 13:11:02 +0000 (UTC) (envelope-from alexander.lochmann@tu-dortmund.de) Received: from unimail.uni-dortmund.de (mx1.hrz.uni-dortmund.de [129.217.128.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "unimail.tu-dortmund.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H04F16FQ4z3Ldr for ; Wed, 1 Sep 2021 13:11:01 +0000 (UTC) (envelope-from alexander.lochmann@tu-dortmund.de) Received: from [129.217.43.37] (kalamos.cs.uni-dortmund.de [129.217.43.37]) (authenticated bits=0) by unimail.uni-dortmund.de (8.17.1/8.17.1) with ESMTPSA id 181DArre022506 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT); Wed, 1 Sep 2021 15:10:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tu-dortmund.de; s=unimail; t=1630501853; bh=Kl2Ngfb49otDAjAOnin+0dmimRh4DtF4XS18j9mVw7g=; h=To:Cc:References:From:Subject:Date:In-Reply-To; b=dto8G686ZN1M4H1OV8P83OZ27/YhebN2cdIcCtwsnwiPJd7f4JQK2rlTPoEp9XRhq YEH4NUxMBMO2h6Y/6uUULDaEHgmlW2xqg2kXb/bvMStDhmYxVGr+DaDiqZPJaL0rap AcZ7iKzJiFc9RNLZSzNXTA9p+L6PeJFXUQ626sdQ= To: Konstantin Belousov Cc: freebsd-fs , Horst Schirmeier References: <55f3661e-2173-793e-4834-bbcd79d3d99e@tu-dortmund.de> <380bdcc8-bede-2a64-8e5e-031552231d82@tu-dortmund.de> <46649402-d28a-6f81-f0a8-39180b681f4c@tu-dortmund.de> From: Alexander Lochmann Subject: Re: Various unprotected accesses to buf and vnode Message-ID: Date: Wed, 1 Sep 2021 15:10:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="04TxWz7gO8SglOxkkiEWFPFYUunGc16dc" X-Rspamd-Queue-Id: 4H04F16FQ4z3Ldr X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --04TxWz7gO8SglOxkkiEWFPFYUunGc16dc Content-Type: multipart/mixed; boundary="WfgMYjAh9e85p3j6EnDfzFPMssO4F8VSz"; protected-headers="v1" From: Alexander Lochmann To: Konstantin Belousov Cc: freebsd-fs , Horst Schirmeier Message-ID: Subject: Re: Various unprotected accesses to buf and vnode References: <55f3661e-2173-793e-4834-bbcd79d3d99e@tu-dortmund.de> <380bdcc8-bede-2a64-8e5e-031552231d82@tu-dortmund.de> <46649402-d28a-6f81-f0a8-39180b681f4c@tu-dortmund.de> In-Reply-To: --WfgMYjAh9e85p3j6EnDfzFPMssO4F8VSz Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 31.08.21 16:44, Konstantin Belousov wrote: >> So in all of those call sequences the buffer lock is not acquired. >> However, I'd not rule out that our tooling could be broken as well. > Buffer is locked inside UFS_BALLOC(), which returns it to the ffs_write= () > use. I took a deep dive into our data, and had a closer look at two samples. In both cases the b_lock is not acquired. Since the debug information seems to be damaged, I had to use 'objdump -S' to translate the pc of the unguarded memory access to a source code position. It seems to be vp->v_lasta =3D bp->b_blkno; in https://thasos.cs.tu-dortmund.de/freebsd-lockdoc/lockdoc-v13.0-0.6/source= /sys/kern/vfs_cluster.c#L802. It was release in binsfree() and bq_insert(): https://thasos.cs.tu-dortmund.de/freebsd-lockdoc/latest/source/sys/kern/v= fs_bio.c#L1537 https://thasos.cs.tu-dortmund.de/freebsd-lockdoc/latest/source/sys/kern/v= fs_bio.c#L1977 Right before the entry that records the unlock, there was a memory access recorded including the stracketrace. I assume that memory access belongs to the unlock operation, and translated the stacktrace. For binsfree(): /opt/kernel/freebsd/src/sys/sys/lockdoc.h:104 /opt/kernel/freebsd/src/sys/kern/kern_lock.c:247 (inlined by) /opt/kernel/freebsd/src/sys/kern/kern_lock.c:1408 /opt/kernel/freebsd/src/sys/sys/lockmgr.h:107 (inlined by) /opt/kernel/freebsd/src/sys/kern/vfs_bio.c:1537 /opt/kernel/freebsd/src/sys/kern/vfs_bio.c:2437 /opt/kernel/freebsd/src/sys/kern/vfs_cluster.c:775 /opt/kernel/freebsd/src/sys/ufs/ffs/ffs_vnops.c:894 /opt/kernel/freebsd/obj/lockdoc-kernproc/vnode_if.c:1108 /opt/kernel/freebsd/obj/lockdoc-kernproc/./vnode_if.h:569 (inlined by) /opt/kernel/freebsd/src/sys/kern/vfs_vnops.c:1093 /opt/kernel/freebsd/src/sys/kern/vfs_vnops.c:1158 /opt/kernel/freebsd/src/sys/kern/vfs_vnops.c:1276 /opt/kernel/freebsd/src/sys/kern/vfs_vnops.c:1398 /opt/kernel/freebsd/src/sys/sys/file.h:327 (inlined by) /opt/kernel/freebsd/src/sys/kern/sys_generic.c:564 /opt/kernel/freebsd/src/sys/kern/sys_generic.c:491 /opt/kernel/freebsd/src/sys/i386/i386/../../kern/subr_syscall.c:189 For bq_insert(): /opt/kernel/freebsd/src/sys/sys/lockdoc.h:104 /opt/kernel/freebsd/src/sys/kern/kern_lock.c:247 (inlined by) /opt/kernel/freebsd/src/sys/kern/kern_lock.c:1408 /opt/kernel/freebsd/src/sys/sys/lockmgr.h:107 (inlined by) /opt/kernel/freebsd/src/sys/kern/vfs_bio.c:1977 /opt/kernel/freebsd/src/sys/kern/vfs_bio.c:1552 /opt/kernel/freebsd/src/sys/kern/vfs_bio.c:2437 /opt/kernel/freebsd/src/sys/kern/vfs_cluster.c:775 /opt/kernel/freebsd/src/sys/ufs/ffs/ffs_vnops.c:894 /opt/kernel/freebsd/obj/lockdoc-kernproc/vnode_if.c:1108 /opt/kernel/freebsd/obj/lockdoc-kernproc/./vnode_if.h:569 (inlined by) /opt/kernel/freebsd/src/sys/kern/vfs_vnops.c:1093 /opt/kernel/freebsd/src/sys/kern/vfs_vnops.c:1158 /opt/kernel/freebsd/src/sys/kern/vfs_vnops.c:1276 /opt/kernel/freebsd/src/sys/kern/vfs_vnops.c:1398 /opt/kernel/freebsd/src/sys/sys/file.h:327 (inlined by) /opt/kernel/freebsd/src/sys/kern/sys_generic.c:564 /opt/kernel/freebsd/src/sys/kern/sys_generic.c:491 /opt/kernel/freebsd/src/sys/i386/i386/../../kern/subr_syscall.c:189 > Read e.g. sys/ufs/ufs/inode.h gerald comment above struct inode definit= ion. > It provides more detailed exposure. Aaah. Thx. This is about the struct inode. So I assume it also applies for a vnode belonging to an inode. Am I right?> Vnode lock is a lock obtained with vn_lock(). It is up to filesystem > to implement VOP_LOCK() which locks the vnode. >=20 > Default VOP_LOCK() locks vp->v_vnlock, which again by default points > to &vp->v_lock. >=20 > There are several special cases. For instance, for FFS and snapshot vn= odes, > v_vnlock points to the snapdata->sn_lock (snapdata is unique per FFS mo= unt). > For nullfs non-reclaimed vnodes, v_vnlock points to the lower vnode loc= k. >=20 Thx! Is this written down somewhere? --=20 Technische Universit=C3=A4t Dortmund Alexander Lochmann PGP key: 0xBC3EF6FD Otto-Hahn-Str. 16 phone: +49.231.7556141 D-44227 Dortmund fax: +49.231.7556116 http://ess.cs.tu-dortmund.de/Staff/al --WfgMYjAh9e85p3j6EnDfzFPMssO4F8VSz-- --04TxWz7gO8SglOxkkiEWFPFYUunGc16dc Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEElhZsUHzVP0dbkjCRWT7tBbw+9v0FAmEve90FAwAAAAAACgkQWT7tBbw+9v0+ Kw//eUQMK0XnS1gE8LdLDDImOqyN+/Avb+UnWNtia+npz8t3+kVNex25pTb6/yFJyHCbZTLelZYs NAA+uGnuYyAK1D67v5R8KSrKjof39DRbXErD1OfkTnyTm9lrJyqx7mCult+9XfDivAPBEOfN+qBT gACsguJ5jDmaqS4Wb6W8xk2ga/1LbrfNdYmavWHK7Pc2oQdaUapN927t5gREqlasfHN5Cj7Rp2i9 pmHgJmrHjf+X14uyiUGYsoMBBHeRgVf4Ow523PTHv3hO0ZFxbuam9AZxoM+48dowWRoVvAsbIGX0 ebKdAMZ84aPATOmdypK5D7GJajuMwM718Bg4oBYjuH/jrriBS4fRIn6hq9pDFsr4J5dQaErAi1CH YTxQ+PlRFok6NUMOQs0bXFNK2cTD5UR2u/Nrt/DVmZn2rWiFviT+BD8WV6FV7eYvzqii5ReKiT+7 0Wa4y1TWfYEM1qDWiA7B5NOlNNp/Bxn8NpTL9r2KrQrR/uoXADSN8lTLP0JcSGsN0GjRgVJ0AN6P D3MNsgqyQ3MNyb3QCbE6npZjR0SquGoqvITZvSewpzpycb7Z/0U3UBTNxiOFSgdyVmK0zEMN6CAx ZVqqx4mZ3wA5lw84AkN2TeQyFoFvzWCGSxI2nC9Ld594EU3O5hJxtvOIaa2NYOY1KJ1wKxrYT7zm b9Y= =z0tu -----END PGP SIGNATURE----- --04TxWz7gO8SglOxkkiEWFPFYUunGc16dc-- From nobody Thu Sep 2 04:16:21 2021 X-Original-To: freebsd-fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E40B117AADC5 for ; Thu, 2 Sep 2021 04:16:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H0SKw4Kwpz3mPG for ; Thu, 2 Sep 2021 04:16:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 1824GLi1056881 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 2 Sep 2021 07:16:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 1824GLi1056881 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 1824GLbL056880; Thu, 2 Sep 2021 07:16:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 2 Sep 2021 07:16:21 +0300 From: Konstantin Belousov To: Alexander Lochmann Cc: freebsd-fs , Horst Schirmeier Subject: Re: Various unprotected accesses to buf and vnode Message-ID: References: <55f3661e-2173-793e-4834-bbcd79d3d99e@tu-dortmund.de> <380bdcc8-bede-2a64-8e5e-031552231d82@tu-dortmund.de> <46649402-d28a-6f81-f0a8-39180b681f4c@tu-dortmund.de> List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4H0SKw4Kwpz3mPG X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, Sep 01, 2021 at 03:10:53PM +0200, Alexander Lochmann wrote: > On 31.08.21 16:44, Konstantin Belousov wrote: > >> So in all of those call sequences the buffer lock is not acquired. > >> However, I'd not rule out that our tooling could be broken as well. > > Buffer is locked inside UFS_BALLOC(), which returns it to the ffs_write() > > use. > I took a deep dive into our data, and had a closer look at two samples. > In both cases the b_lock is not acquired. > > Since the debug information seems to be damaged, I had to use 'objdump > -S' to translate the pc of the unguarded memory access to a source code > position. > It seems to be vp->v_lasta = bp->b_blkno; in > https://thasos.cs.tu-dortmund.de/freebsd-lockdoc/lockdoc-v13.0-0.6/source/sys/kern/vfs_cluster.c#L802. > > It was release in binsfree() and bq_insert(): > https://thasos.cs.tu-dortmund.de/freebsd-lockdoc/latest/source/sys/kern/vfs_bio.c#L1537 > https://thasos.cs.tu-dortmund.de/freebsd-lockdoc/latest/source/sys/kern/vfs_bio.c#L1977 Ah, it is bp->b_blkno access after the b*write() functions were called to write out and release the buffer, right. I put the patch to fix this into https://reviews.freebsd.org/D31780 Please remind me what attributions to use for 'Reported by:' tagline. > > Read e.g. sys/ufs/ufs/inode.h gerald comment above struct inode definition. > > It provides more detailed exposure. > Aaah. Thx. This is about the struct inode. So I assume it also applies > for a vnode belonging to an inode. Am I right?> Vnode lock is a lock > obtained with vn_lock(). It is up to filesystem When needed, yes, it is a reasonable locking strategy. But I am not sure that we actually use for any of the struct vnode fields proper, Something closer to it is for v_writecount, but formally it is under the vnode interlock. Although I do not think we ever modify it without holding vnode lock, in some mode. > > to implement VOP_LOCK() which locks the vnode. > > > > Default VOP_LOCK() locks vp->v_vnlock, which again by default points > > to &vp->v_lock. > > > > There are several special cases. For instance, for FFS and snapshot vnodes, > > v_vnlock points to the snapdata->sn_lock (snapdata is unique per FFS mount). > > For nullfs non-reclaimed vnodes, v_vnlock points to the lower vnode lock. > > > Thx! Is this written down somewhere? No, but it is rather clear from the code. From nobody Thu Sep 2 07:34:39 2021 X-Original-To: freebsd-fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4CF4617B5C12 for ; Thu, 2 Sep 2021 07:34:42 +0000 (UTC) (envelope-from alexander.lochmann@tu-dortmund.de) Received: from unimail.uni-dortmund.de (mx1.hrz.uni-dortmund.de [129.217.128.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "unimail.tu-dortmund.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H0XkV0S3nz3gyW for ; Thu, 2 Sep 2021 07:34:41 +0000 (UTC) (envelope-from alexander.lochmann@tu-dortmund.de) Received: from [192.168.111.103] (p4fd975b9.dip0.t-ipconnect.de [79.217.117.185]) (authenticated bits=0) by unimail.uni-dortmund.de (8.17.1/8.17.1) with ESMTPSA id 1827YeEO028280 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT); Thu, 2 Sep 2021 09:34:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tu-dortmund.de; s=unimail; t=1630568080; bh=UKOxn8kvWkw8UCmkfUd0LY8HnwJ9k40suZ1ff/OCftE=; h=To:Cc:References:From:Subject:Date:In-Reply-To; b=jLIYb0IPliqtsrlrYf12sKiPHkD9ueJnqymyPTTi+1LKlSJib9u+hlBaveVtZy803 QVTdXYvyLKE7y/QYILMPP4b7y1OYI6iIMMLjSBw5+dQWUDxpuAYZLO/Dk0Rk90wF2M dM4ZJvTQUCBZbSy/9to6gyuJEbFEnsFC+gAYhtP8= To: Konstantin Belousov Cc: freebsd-fs , Horst Schirmeier References: <55f3661e-2173-793e-4834-bbcd79d3d99e@tu-dortmund.de> <380bdcc8-bede-2a64-8e5e-031552231d82@tu-dortmund.de> <46649402-d28a-6f81-f0a8-39180b681f4c@tu-dortmund.de> From: Alexander Lochmann Subject: Re: Various unprotected accesses to buf and vnode Message-ID: <6640b87e-cc47-589b-40a6-7f181d3f077f@tu-dortmund.de> Date: Thu, 2 Sep 2021 09:34:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-DE-1901 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4H0XkV0S3nz3gyW X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 02.09.21 06:16, Konstantin Belousov wrote: > Ah, it is bp->b_blkno access after the b*write() functions were called > to write out and release the buffer, right. I put the patch to fix this > into https://reviews.freebsd.org/D31780 > > Please remind me what attributions to use for 'Reported by:' tagline. Last time it was '[...] issue was reported by Alexander Lochmann , who found the problem by performing lock analysis using LockDoc, see https://doi.org/10.1145/3302424.3303948.' > >>> Read e.g. sys/ufs/ufs/inode.h gerald comment above struct inode definition. >>> It provides more detailed exposure. >> Aaah. Thx. This is about the struct inode. So I assume it also applies >> for a vnode belonging to an inode. Am I right?> Vnode lock is a lock >> obtained with vn_lock(). It is up to filesystem > When needed, yes, it is a reasonable locking strategy. But I am not > sure that we actually use for any of the struct vnode fields proper, > Something closer to it is for v_writecount, but formally it is under the > vnode interlock. Although I do not think we ever modify it without holding > vnode lock, in some mode. Can this locking strategy be applied to a vnode for any other filesystem, ntfs for example? If so: Shouldn't it be written down in vnode.h? -- Technische Universität Dortmund Alexander Lochmann PGP key: 0xBC3EF6FD Otto-Hahn-Str. 16 phone: +49.231.7556141 D-44227 Dortmund fax: +49.231.7556116 http://ess.cs.tu-dortmund.de/Staff/al From nobody Thu Sep 2 12:22:48 2021 X-Original-To: fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5612717A02C3 for ; Thu, 2 Sep 2021 12:22:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H0g6w1rDgz4cP9 for ; Thu, 2 Sep 2021 12:22:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 2805618BC9 for ; Thu, 2 Sep 2021 12:22:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 182CMmDt028150 for ; Thu, 2 Sep 2021 12:22:48 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 182CMmHU028149 for fs@FreeBSD.org; Thu, 2 Sep 2021 12:22:48 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 258208] [zfs] locks up when using rollback or destroy on both 13.0-RELEASE & sysutils/openzfs port Date: Thu, 02 Sep 2021 12:22:48 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258208 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Sep 2 21:43:26 2021 X-Original-To: fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4870417981C3 for ; Thu, 2 Sep 2021 21:43:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H0vYp1V9Dz3tpG for ; Thu, 2 Sep 2021 21:43:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 113372065F for ; Thu, 2 Sep 2021 21:43:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 182LhQHk089922 for ; Thu, 2 Sep 2021 21:43:26 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 182LhQn8089921 for fs@FreeBSD.org; Thu, 2 Sep 2021 21:43:26 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 258208] [zfs] locks up when using rollback or destroy on both 13.0-RELEASE & sysutils/openzfs port Date: Thu, 02 Sep 2021 21:43:26 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258208 Mark Millard changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marklmi26-fbsd@yahoo.com --- Comment #2 from Mark Millard --- In a simpler context I do not see the problem for destroy (so: compare/cont= rast with your context). Context: # zpool status pool: zopt0 state: ONLINE scan: scrub repaired 0B in 00:01:35 with 0 errors on Sat Jun 19 18:23:07 = 2021 config: NAME STATE READ WRITE CKSUM zopt0 ONLINE 0 0 0 nda0p3 ONLINE 0 0 0 errors: No known data errors # uname -apKU FreeBSD CA72_16Gp_ZFS 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #4 releng/13.0-n244760-940681634ee1-dirty: Mon Aug 30 11:35:45 PDT 2021=20=20= =20=20 root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm= 64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300139 1300139 Destroy related activity (of prior cross-build materials): # zfs list | grep amd64 zopt0/BUILDs/13S-amd64-nodbg-clang 7.72G 167G 7.72G=20 /usr/obj/BUILDs/13S-amd64-nodbg-clang zopt0/BUILDs/13_0R-amd64-nodbg-clang 7.81G 167G 7.81G=20 /usr/obj/BUILDs/13_0R-amd64-nodbg-clang zopt0/BUILDs/main-amd64-nodbg-clang 7.98G 167G 7.98G=20 /usr/obj/BUILDs/main-amd64-nodbg-clang zopt0/DESTDIRs/13_0R-amd64-poud 96K 167G 96K=20 /usr/obj/DESTDIRs/13_0R-amd64-poud zopt0/DESTDIRs/main-amd64-poud 96K 167G 96K=20 /usr/obj/DESTDIRs/main-amd64-poud # zfs destroy -vrRf zopt0/DESTDIRs/main-amd64-poud=20 will destroy zopt0/DESTDIRs/main-amd64-poud # zfs destroy -vrRf zopt0/DESTDIRs/13_0R-amd64-poud=20 will destroy zopt0/DESTDIRs/13_0R-amd64-poud # zfs destroy -vrRf zopt0/BUILDs/main-amd64-nodbg-clang will destroy zopt0/BUILDs/main-amd64-nodbg-clang # zfs destroy -vrRf zopt0/BUILDs/13_0R-amd64-nodbg-clang will destroy zopt0/BUILDs/13_0R-amd64-nodbg-clang # zfs destroy -vrRf zopt0/BUILDs/13S-amd64-nodbg-clang will destroy zopt0/BUILDs/13S-amd64-nodbg-clang # zfs list | grep amd64 # (I added the blank lines to make reading easier.) --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Sep 3 04:40:49 2021 X-Original-To: fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6E05817A1D53 for ; Fri, 3 Sep 2021 04:40:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H14qP2VRkz3pDs for ; Fri, 3 Sep 2021 04:40:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 3CB7A25D35 for ; Fri, 3 Sep 2021 04:40:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 1834en2N026388 for ; Fri, 3 Sep 2021 04:40:49 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1834enWV026387 for fs@FreeBSD.org; Fri, 3 Sep 2021 04:40:49 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 254282] 13.0-RC2: NFS export from nullfs mount doesn't work as of 13.0 Date: Fri, 03 Sep 2021 04:40:49 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: felix@palmen-it.de X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254282 --- Comment #6 from Felix Palmen --- Finally remembered to test that, and well, turns out I was wrong: The 'late' option *is* required. /var/jail/builder/(src|obj) are ZFS datasets and without 'late', the system tries to mount the nullfs before ZFS datasets are mounted. Still I have doubts that's really the issue, because, as mentioned above, restarting of NFS-related services doesn't solve the issue either. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Sep 3 05:04:48 2021 X-Original-To: fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C791317AD1A0 for ; Fri, 3 Sep 2021 05:04:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H15M45Dr4z4RLc for ; Fri, 3 Sep 2021 05:04:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 9C57D2669A for ; Fri, 3 Sep 2021 05:04:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 18354mxt040315 for ; Fri, 3 Sep 2021 05:04:48 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 18354mja040314 for fs@FreeBSD.org; Fri, 3 Sep 2021 05:04:48 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 258208] [zfs] locks up when using rollback or destroy on both 13.0-RELEASE & sysutils/openzfs port Date: Fri, 03 Sep 2021 05:04:48 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: avg@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258208 --- Comment #3 from Andriy Gapon --- Please attach full procstat -kk -a output. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sat Sep 4 15:08:59 2021 X-Original-To: freebsd-fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9C75B179CF8A for ; Sat, 4 Sep 2021 15:09:13 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670056.outbound.protection.outlook.com [40.107.67.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H1yjz6gH5z3hqY for ; Sat, 4 Sep 2021 15:09:11 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GEDzQj9ArOlfAby0xOlUJNX5ziEXkumAU7wBRsGUMJmgUGmq5ttVYspZhhumpvT2hpGyu0gqsZwLM0zP/augHn7kRkKyfIzWV0OZxt9nXqSZYRP4eNYzI/yv02fhwjpva8+wNujVh4Q9w5nz2j4aGk/uz7Nd7xBvnRUXxkwNzxkti/TqTEOf7g3GU5uZIq2biDAPvciynh6QvE9/oCQTsxqwFOOs9YJujJr5a5yyowyfoJ0swbi8AOn3eOZfTk0J62VLlvpqQT85aYOW6PigNebDBMPavppP3LKgVHY6ixXyXq4BfleZfPkBevlIW6TSk5zEYVVXFCDg/xmb0uPnKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lnvd3RjZtukIRzmQ9INvg6W5U5Fnd/v1nRW5m+LVDQo=; b=QGgAyte3yDvLAR5ZIuH4ILYsVyqmWX38ZdBv6SoHWzWEAR0wXpkkx9cWEzol+bsLYkyMZcji5OIjYM1BKpPK65yY5PnVACCCTeqUD/Y168d4/q2TZuTgG6DOWuOjMHud7doW03PL7Ud93T4F4//WACTBQj7GhqP+zJFnp1vLWiud2dc+vJj4lhoSV3kdfy3A9G7kyj2m6ZTT7q1A6NQSv0OPMI0DNqfd3APsfkfnwTm9q0ba7lTl5EGhiRgpyknjKGcdLWyEkZVqUyZ8HIo6QzwETLcNCBonmwMeLfXmgHwIY/Vo9GCTJmQq1BXgXc/cq8XA8ZC6kFq7S0IUxKSP7g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lnvd3RjZtukIRzmQ9INvg6W5U5Fnd/v1nRW5m+LVDQo=; b=pHcom4E+ip7cuJQvUWsVguVdazm79ptq9/VnB3xhqRMQ0G+LM5ouxLmkM9acuXNgQAwRtcZ3poNIgq3JwWpF0iJprHVCseN4tBDBdWPsf9ejoYxaBTabKLM/FV2jYsuxY1wYUKTVh/js+3z9DXWif0l6Kj100GoCZ8i6Vl7OFLRz3wxZTHGSQ92jzN5xremtsk9Vfr5MGWUijzFkiGWfSdYfP6oiCQVdVgc6JCj0KbMdZ/1tpCf6SMuOZ4N8OpkIdz6x/wKtGN739Ku1NwRMKJSQSo29NMGLtZ4kNyuYfooarqqBee0AVWh68ZnEzLQ1dsUPP1ebqbcZPn2kYyA3EA== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQBPR0101MB1059.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:12::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.22; Sat, 4 Sep 2021 15:09:04 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::55aa:8e71:343f:dc14]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::55aa:8e71:343f:dc14%7]) with mapi id 15.20.4478.024; Sat, 4 Sep 2021 15:08:59 +0000 From: Rick Macklem To: FreeBSD Filesystems Subject: should copy_file_range(2) have a non-Linux flag? Thread-Topic: should copy_file_range(2) have a non-Linux flag? Thread-Index: AQHXoZ2atZkOov8MxkOHToRY1sDFZQ== Date: Sat, 4 Sep 2021 15:08:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 9519e6c3-d03b-a4a1-ee5e-9eb61c1d16e0 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 547970b4-8486-45da-8c74-08d96fb5ec35 x-ms-traffictypediagnostic: YQBPR0101MB1059: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kEntPR05oRhNrXcF14qsZ20HF3/5o3WLYY1HAl4uHSQn/NhziBCmSIa5OxPGp6I1oGn3XIbas6UsfAGZLADKxbjwcwsEptZg9/kPxjJAgVpD8wyIqlVAf8CNJPaYdHrK3pGw5OCgPOM6ctnlp3KadGnBSKx/bdbaKro4NBWc1Bqrnm9RShwx0r6PNYZm97RsxtY3SdsZOhYZzJ3Xg7VqZkLMbl/Kc1P8064Bhd1+1KogNsvJNfO/7iYhL0JgobREBkytiYVne7quIRUZgtMQ2o5oC7W9DYD10Sl82KWj65nRr8mOoN8gb26B4mKoiIZnQYpiIoyAZbnmuL5uEXqTDgK6rFVTiadmvduW9/l4HUBWqju1nm71E1OAGqIjbp1ScBOj7kgXZGRLUqWe4iBP/HJd9OteRBdN5LDs0TVqCAqwqIpAmGgvPEZE2D+o4jrIccL99OQMsXfJAOCV/Cqm+3keorf6vzkExooS/0r74tWwkZGd1xH7VOCTmpvkumSmPdckmf9G7STqukFMnke7oRkse+L8tfMyvi01KbfNFoTyowBXc2pfGLzGGV4BSuRslgZrghDqy+OYC+NAAOGjSM2E1D39C/1FGCqnDouzjhNQ9YkhO7SFupe28iGEAvm6Uqa476OG+x+AojWuC9vgnRah0fnWvM2isKwMqcqSjcz53nbMWZHjeJJKYbjvXxWT1Y71hHylfTREncXGk8851mtlrJ2wIzUTtj+l3LpaLHKUYBT0t3m+oHfyQglvcRyHl8QJRv1uCEWkGSy++UU4BSvM+7xIIRiHO1C+JsIQDmY= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(346002)(39850400004)(376002)(366004)(136003)(396003)(55016002)(122000001)(38100700002)(33656002)(186003)(7696005)(8676002)(316002)(9686003)(86362001)(4744005)(52536014)(91956017)(966005)(76116006)(66446008)(8936002)(64756008)(38070700005)(478600001)(6916009)(71200400001)(5660300002)(2906002)(6506007)(66476007)(66946007)(66556008);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?FNGGTgZx16fG2bwrWxc3JH24yP16ah+idOf6/NOsFWtXDN8rzNTBy8mEJG?= =?iso-8859-1?Q?QJTyokkuY3RGnJm2ua27t7ynzebAm9n+UsK2jJ2ZUqNREQhGxihU1yMCfl?= =?iso-8859-1?Q?GoIfxMqWQe4GgpjxkRm/gmnbk+xv/qyW3DuUbhYpAvPTTXmBHxT7nxCfOT?= =?iso-8859-1?Q?+bZR5513roVZ/3eEnNemW7GUDOHU1g3LFU/HBfcss6MrMqt31b30Pc3l+B?= =?iso-8859-1?Q?3hdEaZB4z7t+lfJLtudxTLOwnItU9ygiyC41/2kDbIYjFCljB8CZ3Bq41V?= =?iso-8859-1?Q?6k6+1lGNMGEXf/GvUm8qOlDYfpRdL3Yno9BI/BN2Cf/Rql6WSUjSRMfI5/?= =?iso-8859-1?Q?nh6niOC2wiwm4yZG5XOAHg12UoaJb5QB+QbrYlCbSUTYohZd/uX3U1JwQp?= =?iso-8859-1?Q?hrUaDaqd+kDCCjy2VWXU9Vcexpmmy5QBT8RiKIcVM6ZrQkRemDWgMXp+Bj?= =?iso-8859-1?Q?Uf64u3x2Ae7thferrWkKb93Ob0uhVJd2nAvOwmfAtERTpQme1C2vgjhbT7?= =?iso-8859-1?Q?edydRBb5rsXFM68mpZ8Klo+K6D6TH+7sepfnNPuUvlepm3dP8gnlB1e+TC?= =?iso-8859-1?Q?ibXEKP8+SK2Q9gP1dPiwfRJDQ3+JR13MXD82kyqRPS3Spw/XJUBvyxeJpT?= =?iso-8859-1?Q?JleCMpFDp7Ho+JJjx6xv4aLRNCv3Xm4MuN699D/q2abR5Ghd8xEQsYF9gf?= =?iso-8859-1?Q?moQnxO8QbSSb6mV5wZzvX3F3TkEZWKSHhUZ+4RyU2DPRAxIk2wix4h/4PH?= =?iso-8859-1?Q?nGsbBrg/yU6SbMQp/C/yraN4QSC9NbCyINjxB6rpiCcBBnh5f61FpKwYfJ?= =?iso-8859-1?Q?3i01Is8dAFZqRtFc9DWhuk5oGS0NWbbd+jxWBPybGrLhfzObM6uuRIbcrY?= =?iso-8859-1?Q?kjhc4MneQMAyb7Fkzo76gBqtbU03zsRNhdqOq1Q939LM0274wG/XlZJ8lJ?= =?iso-8859-1?Q?l8jf1UcrMYXBwZT94NRskinyUwxb+UT3w3o2Vy4uWTbraE8SZcguD15QUt?= =?iso-8859-1?Q?iHQFKFtBcAyLdpDYYML64jqkygELr/dG17HrQR3T5im14+0lLKfMAtWyUw?= =?iso-8859-1?Q?GSL2A1+KiQJZKgfaGgTrtNuoPcCiHgHnsksaJqs2qtLdbaOr+eDfqFpC45?= =?iso-8859-1?Q?H0XyVFtZgmBUBGGcaNlsfwqDQ9v19g60v6T6D7wHKkmWQ4IJEdYx3cclcG?= =?iso-8859-1?Q?8VRPlJ6Aag8oFBDB/ygEVfXVgVmo0yOfYctO2Oo93qLjCCvqtfNpm2R6DC?= =?iso-8859-1?Q?m9w1/AQs/KQeWI/4kKm9hQ+xNxSAJ2CahvK7TItqG7ATQLHSvKJkLs/Msz?= =?iso-8859-1?Q?wdk4cKBR9piiwhstzTvKu0HLIIzwOJVtDhyhMtvD8CvvP8KKhS8JXZ9vKI?= =?iso-8859-1?Q?9Fzmk64LEzQSZFPMqze3wEX1ieWCB/PkW/lYFEasYOaEBaceuk+DU=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 547970b4-8486-45da-8c74-08d96fb5ec35 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2021 15:08:59.0942 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5qpxmtPr/rSz/ZhdyGpQCedZxlq9DUEV4riemo6eWzo90s57TnlSq5ds5xJt80vD8vh+5dVta0gjQNmrdkmsdQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB1059 X-Rspamd-Queue-Id: 4H1yjz6gH5z3hqY X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector2 header.b=pHcom4E+; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.56 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-5.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; RCVD_IN_DNSWL_NONE(0.00)[40.107.67.56:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.67.56:from] X-ThisMailContainsUnwantedMimeParts: N Hi,=0A= =0A= I just proposed a patch for VOP_COPY_FILE_RANGE(9)=0A= that adds a kernel only flag to specify "return after 1second=0A= with a partial copy". I'd like to use it for the NFSv4.2 server,=0A= so that the RPC replies in a reasonable time frame.=0A= https://reviews.freebsd.org/D31829=0A= =0A= The question that came up is...=0A= "should this flag be visible to userland?"=0A= =0A= The only argument I can think of against doing this is=0A= that it makes the syscall non-Linux compatible.=0A= (Also, the NFS server requirement seems a bit of an oddball=0A= and I'm not sure an application would want this capability?)=0A= =0A= Do you think this flag should be exposed to userland (ie the syscall)?=0A= =0A= rick=0A= From nobody Sun Sep 5 16:29:00 2021 X-Original-To: fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0601F17A757D for ; Sun, 5 Sep 2021 16:29:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H2cRc6j6gz3rPW for ; Sun, 5 Sep 2021 16:29:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id C2755699E for ; Sun, 5 Sep 2021 16:29:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 185GT0Fn043190 for ; Sun, 5 Sep 2021 16:29:00 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 185GT0ww043189 for fs@FreeBSD.org; Sun, 5 Sep 2021 16:29:00 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 257768] Corrupt UDF disk image can cause crash when mounted. Date: Sun, 05 Sep 2021 16:29:00 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: grahamperrin@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257768 Graham Perrin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |grahamperrin@gmail.com --- Comment #2 from Graham Perrin --- Comparably interesting: bug 244342 and seven other UFS-related kernel panic bugs that were reported by Neeraj on 2020-02-23 --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Sep 5 21:00:47 2021 X-Original-To: fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5DDB417BD307 for ; Sun, 5 Sep 2021 21:00:48 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H2kTC2Nw4z4q1y for ; Sun, 5 Sep 2021 21:00:47 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 19CDC12375 for ; Sun, 5 Sep 2021 21:00:47 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 185L0lkA093651 for ; Sun, 5 Sep 2021 21:00:47 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 185L0ltF093649 for fs@FreeBSD.org; Sun, 5 Sep 2021 21:00:47 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202109052100.185L0ltF093649@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: fs@FreeBSD.org Subject: Problem reports for fs@FreeBSD.org that need special attention Date: Sun, 5 Sep 2021 21:00:47 +0000 List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="16308756470.EfeEDD.91407" Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: Y --16308756470.EfeEDD.91407 Date: Sun, 5 Sep 2021 21:00:47 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 211491 | System hangs after "Uptime" on reboot with ZFS Open | 221909 | [ZFS] Add a sysctl to toggle send_corrupt_data Open | 237067 | ZFS: Crash in vdev_dtl_reassess when using GELI w Open | 240831 | zfs: Panic during snapshot on 12.1-STABLE r352648 Open | 243973 | [zfs] rollback segmentation fault Open | 244656 | zfs: resilver doesn't provide enough information Open | 244692 | gjournal: Does not support TRIM Open | 244899 | [PATCH] zfs: xattr on a symlink target > 136 caus Open | 251035 | ZFS: Allow 64 bit ZFS to support 32 bit ioctls (W 9 problems total for which you should take action. --16308756470.EfeEDD.91407--