From owner-freebsd-current@FreeBSD.ORG Fri Jul 4 09:32:57 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 775E5397; Fri, 4 Jul 2014 09:32:57 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F1C35248C; Fri, 4 Jul 2014 09:32:56 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s649WpkQ040614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Jul 2014 12:32:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s649WpkQ040614 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s649WpXu040613; Fri, 4 Jul 2014 12:32:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 4 Jul 2014 12:32:51 +0300 From: Konstantin Belousov To: Adrian Chadd Subject: Re: EDEADLK from fcntl(F_SETFL) ? Message-ID: <20140704093251.GF93733@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZJM0Iyk369AH1/Ez" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 09:32:57 -0000 --ZJM0Iyk369AH1/Ez Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 03, 2014 at 07:15:51PM -0700, Adrian Chadd wrote: > Hi, >=20 > I'm currently testing this out. It seems to be working out alright. >=20 > adrian@test3:~/work/freebsd % svn diff stable/10/src/sys/kern/ >=20 > Index: stable/10/src/sys/kern/kern_lockf.c >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > --- stable/10/src/sys/kern/kern_lockf.c (revision 267627) >=20 > +++ stable/10/src/sys/kern/kern_lockf.c (working copy) >=20 > @@ -1425,6 +1425,14 @@ >=20 > if (lockf_debug & 1) >=20 > lf_print("lf_setlock: deadlock", lock); >=20 > #endif >=20 > + >=20 > + /* >=20 > + * If the lock isn't waiting, return EAGAIN >=20 > + * rather than EDEADLK. >=20 > + */ >=20 > + if (((lock->lf_flags & F_WAIT) =3D=3D 0) && >=20 > + (error =3D=3D EDEADLK)) >=20 > + error =3D EAGAIN; >=20 > lf_free_lock(lock); >=20 > goto out; >=20 > } >=20 > On 3 July 2014 17:45, Adrian Chadd wrote: > > Hi! > > > > I've seen sqlite3 crap out due to "disk IO error". It looks like the > > F_SETFL path is returning EDEADLK when it shouldn't be - only the > > "wait" version of this should be. > > > > The kernel code looks to be: > > > > lf_setlock() -> lf_add_outgoing() -> lf_add_edge() -> graph_add_edge() > > -> EDEADLK > > > > .. and lf_setlock() will return an error from lf_add_outgoing() > > without checking if it's (a) EDEADLK, and (b) whether we're going to > > sleep or not. > > > > So, sqlite3 trips up on this. I'm sure other things do. What should > > the correct thing be? It looks like EWOULDBLOCK is the correct value > > to return for F_SETFL failing, not EDEADLK. > > > > What do those-who-know-POSIX-standards-better-than-I think? I doubt that the patch is correct. If there is an issue in kernel, the patch only hides it. Note that lf_setlock() first calls lf_getblock() to verify that there is no contending lock on the range, and if there is a conflicting lock, the very first statement inside the if() checks for F_WAIT. Either you get a real deadlock, or there is a bug elsewere. --ZJM0Iyk369AH1/Ez Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTtnTCAAoJEJDCuSvBvK1B74IP/is4vn246sDcNmV3K1UdObpM WwEz7QUMdP5y4mssxFYtgquxqa+ynNqAxcDk8Dq5H9BKobjV6A5UT69rZcxQAsyC 8Py5zx5rXPEPuHuh+20hSe3h/hhoZaygnUOz1nNAAHxpamTctxwqZmPvzYEWoS0Q P6Ztoc6z1JxZsUcXERLECKMLnbSqpRa45mfdB59NwlJSei2tGvaN9zJSe8BbJGat p23s0ObsxFUVX7izDyaJFsZpmHA+o1z6YW48+Gs+eyE9wkEsyuPfkN+uTO9ZIiGL tES/jrZcNWUzMd+6Mdq99dRMHrzCAEU5BpqoDX9sUUN45BErtI/Ul18+7w1Yjb9e dBv1NnpO0Gy2emJS+05ecNMJArbKcvLoEjrleHyH6kob0t9l4G2HbR08Oy9CwxL0 uk6ugNgyw1l5TTgkJLP3ewbo+9ngSWyh/USsoOCTj7rMWIQBP/2iPykc/6+HW1Vw 9swbq822tIJI9HeuIZUp0Ssa9yz6TCokiA9Wv1AqXhJ/PaFb2I4I9j5Z47NbxpYG ofCHyPM2RBsRat6oJQF0dGksag36Pqrw37Twt38yu7fxuKpJS3GIs2RDrY1BgeZQ 7FywjcJzgx6TgRjSRoRK5APQnNC81Qo1fqdr0Btw40Jk/FgNw4+4+9g1CO5ARhui EHRXS4DEX/0svZmTar9D =ucwR -----END PGP SIGNATURE----- --ZJM0Iyk369AH1/Ez--