zsh-workers
 help / color / mirror / code / Atom feed
From: Vincent Lefevre <vincent@vinc17.org>
To: zsh-workers@sunsite.dk
Subject: Re: [PATCH] history locking with fcntl
Date: Thu, 1 Jan 2009 05:01:19 +0100	[thread overview]
Message-ID: <20090101040119.GC2137@prunille.vinc17.org> (raw)
In-Reply-To: <20080505012551.GC11804@blorf.net>

On 2008-05-04 18:25:51 -0700, Wayne Davison wrote:
> On Mon, Apr 21, 2008 at 03:19:37PM +0200, Vincent Lefevre wrote:
> > Note that since out has been closed, tmpfile is no longer locked.
> > The target file isn't locked either.
> 
> The target file was locked prior to the rename (since that's the only
> file my code is locking -- the HISTFILE itself).  So, the rename does
> essentially unlock the HISTFILE as far as fcntl() is concerned.

I've looked again at the current zsh code (which corresponds to your
patch). This is incorrect.

As I've said, there's a fclose() that has the effect to unlock the file:

        if (fclose(out) < 0 && ret >= 0)
            ret = -1;

Indeed, out is a stream associated with fd, which corresponds to the
history file in general (there's also a case of a tmp file, let's
forget this one). And according to the Linux fclose() man page, the
fclose() function closes the underlying file descriptor:

    The fclose() function will flush the stream pointed to by fp
    (writing any buffered output data using fflush(3)) and close
    the underlying file descriptor.

As a file descriptor associated with the file has been closed, the
file is no longer locked by the process, according to the Linux
fcntl(2) man page:

    As well as being removed by an explicit F_UNLCK, record locks
    are automatically released when the process terminates or if
    it closes _any_ file descriptor referring to a file on which
    locks are held.

So, there's a possible race condition, in particular knowning the
fact that preemption at system calls are more likely to occur. If
  1. the kernel preempts the process (A) at the end of the close()
     [the system call used by fclose()] or just before the rename(),
  2. another process (B) locks the history file,
  3. B is preempted,
  4. (A) does the rename,
then bad things can happen.

In my patch, I did a fflush() instead of fclose() to avoid removing
the lock at this time, and I did the fclose() after the rename().

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)


  reply	other threads:[~2009-01-01  4:01 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-15 15:31 Vincent Lefevre
2008-04-17  9:40 ` Peter Stephenson
2008-04-17 13:58   ` Bart Schaefer
2008-04-18  0:49     ` Vincent Lefevre
2008-04-18  1:24       ` Bart Schaefer
2008-04-17 16:23 ` Wayne Davison
2008-04-17 16:35   ` Peter Stephenson
2008-04-18  0:59   ` Vincent Lefevre
2008-04-19  2:31     ` Wayne Davison
2008-04-19  5:23       ` Bart Schaefer
2008-04-19 18:35         ` Wayne Davison
2008-04-21 13:19       ` Vincent Lefevre
2008-05-05  1:25         ` Wayne Davison
2009-01-01  4:01           ` Vincent Lefevre [this message]
2009-01-01  4:12             ` Vincent Lefevre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090101040119.GC2137@prunille.vinc17.org \
    --to=vincent@vinc17.org \
    --cc=zsh-workers@sunsite.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).