From owner-freebsd-fs@FreeBSD.ORG Fri Jul 19 10:30:29 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 83AD6D48; Fri, 19 Jul 2013 10:30:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2654AF3A; Fri, 19 Jul 2013 10:30:28 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6JAUPGc027572; Fri, 19 Jul 2013 13:30:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6JAUPGc027572 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6JAUPxH027549; Fri, 19 Jul 2013 13:30:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 19 Jul 2013 13:30:25 +0300 From: Konstantin Belousov To: Andriy Gapon Subject: Re: Deadlock in nullfs/zfs somewhere Message-ID: <20130719103025.GJ5991@kib.kiev.ua> References: <51E59FD9.4020103@FreeBSD.org> <51E67F54.9080800@FreeBSD.org> <51E7B686.4090509@FreeBSD.org> <20130718112814.GA5991@kib.kiev.ua> <51E7F05A.5020609@FreeBSD.org> <20130718185215.GE5991@kib.kiev.ua> <51E91277.3070309@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WHG05yakhlzm8Hk1" Content-Disposition: inline In-Reply-To: <51E91277.3070309@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-fs@FreeBSD.org, Adrian Chadd X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 10:30:29 -0000 --WHG05yakhlzm8Hk1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 19, 2013 at 01:18:31PM +0300, Andriy Gapon wrote: > on 18/07/2013 21:52 Konstantin Belousov said the following: > > There is VFS method VFS_SUSP_CLEAN, called when the suspension is > > lifted. UFS uses it to clean the back-queue of work which were > > not performed during the suspend, mostly inactivate the postponed > > inactive vnodes. ZFS probably does not need it, since it does > > not check for MNTK_SUSPEND, but if it starts care, there is a place > > to put the code. >=20 > I will keep this in mind. >=20 > > On the other hand, I believe that your patch is notoriously incomplete, > > because there should be a lot of threads which mutate ZFS mounts state > > and which do not call vn_start_write() around the mutations. I.e. > > all ZFS top-level code which calls into ZFS ops and which is not > > coming from VFS. >=20 > I agree. What I am trying to fix right now is VFS<->ZFS interaction. I = think > that ZFS<->ZFS should already be fine - it's protected by internal ZFS lo= cking. > OTOH, perhaps my understanding of what you said is incomplete or incorrec= t, > because VFS suspension mechanism is completely unknown to me yet. >=20 I think that you should satisfy the VFS invariants, and prevent mutators =66rom operating on the filesystem when MNTK_SUSPEND is set, for the case mutators are running outside the context where VFS could call vn_start_write() around. --WHG05yakhlzm8Hk1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR6RVAAAoJEJDCuSvBvK1Bjq4P/2tWXpxKdyvuEJiqeer5wEsm DfErzv7U3fE9tDE0XNUgzDroXTWEQATJr3brdxUTpOvBVcQYKGWVR2jEAavZaWz9 YIH8tbat783yjiem0mvULlNRUJ7QRY12yPLMzetJkgmZAt3ocH4P6k+aHgqyisVu InzNL+Ekc1+0uD4AqEShuueQ2raypLUnY8B7FfAM6APcSO4ARvo8O8Z808hjXk4g cO8VGwvwwFxVT8j+7Woocs0pypRXyQkIhR6xVeBjst81VOzPdvvut8Ic9EH0nOdu 62YPkq4zwGQnyNLoYlWWYMYqNoA1D8AyzPpnmrT2PlVI6lZ3uBcRTRVIKxoQ37b9 h8zIrkHZK7f0o/f8X77VDVlFgzxQst637CjtDio+t9FKWYh5fG3DnR5kFqetXM6G uRuGjn2f2YLKfL2om2bYNdb0CQePdwhehnnegiIA/atAnPGHY6+YZTLi/CTD1Aal 3RwGChQuVsFecZuhlCdaEAeiWMCj+e2wuJEnkX5zzwrWc93t7QYUqBPMXLvYEcEy RwSlm2oN1HO3NX5q7vn9bWlRCyiYQILB4iGC5TIEM8RxYI46kQC8/+NVnIP5AC+n JzWd7cS99E8QdCBkr1DLmEa8H9dQMAtpJegeN6pILtzh56DmASFtXgcKo58PkIHj S8rrSKhnP9Cu5faDKVS2 =9m4K -----END PGP SIGNATURE----- --WHG05yakhlzm8Hk1--