From owner-freebsd-arch@FreeBSD.ORG  Fri Jul  4 02:15:53 2014
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@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 85653FDA;
 Fri,  4 Jul 2014 02:15:53 +0000 (UTC)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com
 [IPv6:2607:f8b0:400d:c04::230])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (verified OK))
 by mx1.freebsd.org (Postfix) with ESMTPS id 38A6D2FD2;
 Fri,  4 Jul 2014 02:15:53 +0000 (UTC)
Received: by mail-qg0-f48.google.com with SMTP id q108so978506qgd.35
 for <multiple recipients>; Thu, 03 Jul 2014 19:15:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :content-type; bh=6Xf3dUxrEe1WEzLSgdxviXehCkjBjCGH+DjycS/q0Zw=;
 b=Pd0ZN9NMnuADpBTLMMH5XcBaywNps0tM75YXyDQBZUlHCwrqI9q5iN2LVaMfKFY7nf
 9UEzurQPOLx+4ceWi4++ipTT1PoQ1YaJU4rMvRL5mCbTvRveXyZ7LIJpo/ONZy3iioSe
 md95TBnc4CErefHKjD5srRSL4Utwe3MzeTjxWykzi8+rviou5fXfzibxjXuM/kZpOKbV
 NEvjIk7oC4UpGN3dy9RSwXMYyle83NC/hhErblxWHlwg7DL4ild7xqZRFBoKo9ph3V7+
 BG+Md6O9t86QBERGzTYTMfqDeTo3gM5E4Gph5azZ33cpO0ac9jAR88EiULqnQdml+dS0
 nUXw==
MIME-Version: 1.0
X-Received: by 10.140.34.195 with SMTP id l61mr12942350qgl.87.1404440152051;
 Thu, 03 Jul 2014 19:15:52 -0700 (PDT)
Received: by 10.224.202.193 with HTTP; Thu, 3 Jul 2014 19:15:51 -0700 (PDT)
In-Reply-To: <CAJ-Vmo=szh6rk5s1H5mZXQZwvm2YZjBK5LQkLoOOZyQT6yhMjw@mail.gmail.com>
References: <CAJ-Vmo=szh6rk5s1H5mZXQZwvm2YZjBK5LQkLoOOZyQT6yhMjw@mail.gmail.com>
Date: Thu, 3 Jul 2014 19:15:51 -0700
Message-ID: <CAJ-VmonS6r2tbNtk73iAeJCSUJfqDc=WY8B2Y6SDKNsQajb3PA@mail.gmail.com>
Subject: Re: EDEADLK from fcntl(F_SETFL) ?
From: Adrian Chadd <adrian.chadd@gmail.com>
To: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>,
 freebsd-current <freebsd-current@freebsd.org>
Content-Type: text/plain; charset=UTF-8
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch/>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Jul 2014 02:15:53 -0000

Hi,

I'm currently testing this out. It seems to be working out alright.

adrian@test3:~/work/freebsd % svn diff stable/10/src/sys/kern/

Index: stable/10/src/sys/kern/kern_lockf.c

===================================================================

--- stable/10/src/sys/kern/kern_lockf.c (revision 267627)

+++ stable/10/src/sys/kern/kern_lockf.c (working copy)

@@ -1425,6 +1425,14 @@

                        if (lockf_debug & 1)

                                lf_print("lf_setlock: deadlock", lock);

 #endif

+

+                       /*

+                        * If the lock isn't waiting, return EAGAIN

+                        * rather than EDEADLK.

+                        */

+                       if (((lock->lf_flags & F_WAIT) == 0) &&

+                           (error == EDEADLK))

+                               error = EAGAIN;

                        lf_free_lock(lock);

                        goto out;

                }

On 3 July 2014 17:45, Adrian Chadd <adrian.chadd@gmail.com> 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?
>
> Thanks!
>
>
>
> -a