From: Junio C Hamano <gitster@pobox.com>
To: Brandon Casey <casey@nrlssc.navy.mil>
Cc: "Linus Torvalds" <torvalds@linux-foundation.org>,
"Git Mailing List" <git@vger.kernel.org>,
"Alex Riesen" <raa.lkml@gmail.com>,
"Kristian Høgsberg" <krh@redhat.com>
Subject: Re: [PATCH 2/2] close_lock_file(): new function in the lockfile API
Date: Wed, 16 Jan 2008 15:19:34 -0800 [thread overview]
Message-ID: <7vtzldmk8p.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0801161443340.31161@torch.nrlssc.navy.mil> (Brandon Casey's message of "Wed, 16 Jan 2008 14:46:23 -0600 (CST)")
Brandon Casey <casey@nrlssc.navy.mil> writes:
> My patch does this, though I understand it may take some time to review.
>
> I left the lk->fd unmodified when close() failed in case the caller
> would like to include it in an error message.
But that would bring us back to the same double-close issue,
wouldn't it?
if (close_lock_file(lock))
die("Oops, failed to close fd %d", lock->fd);
is not enough. You need to do:
if (close_lock_file(lock)) {
int fd = lock->fd;
lock->fd = -1;
die("Oops, failed to close fd %d", fd);
}
to avoid atexit handler closing the lock->fd.
Worse yet, a careless caller may do:
close_lock_file(lock);
... do something that opens a new fd, perhaps for
... mmaping a packfile in
rollback_lock_file(lock);
... Oops, we cannot mmap the packfile.
next prev parent reply other threads:[~2008-01-16 23:21 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-11 22:11 git-commit fatal: Out of memory? mmap failed: Bad file descriptor Brandon Casey
2008-01-11 22:18 ` Charles Bailey
2008-01-12 4:56 ` Jeff King
2008-01-11 22:19 ` Marco Costalba
2008-01-11 22:47 ` Brandon Casey
2008-01-11 23:48 ` Junio C Hamano
2008-01-12 0:43 ` Brandon Casey
2008-01-12 1:08 ` Junio C Hamano
2008-01-12 20:16 ` Alex Riesen
2008-01-14 23:22 ` Brandon Casey
2008-01-15 2:42 ` Brandon Casey
2008-01-15 5:42 ` Linus Torvalds
2008-01-15 17:26 ` Brandon Casey
2008-01-15 17:36 ` Linus Torvalds
2008-01-15 18:27 ` Brandon Casey
2008-01-15 18:50 ` Linus Torvalds
2008-01-15 19:43 ` Brandon Casey
2008-01-15 20:00 ` Kristian Høgsberg
2008-01-15 20:27 ` Brandon Casey
2008-01-15 20:39 ` Brandon Casey
2008-01-15 20:09 ` Linus Torvalds
2008-01-15 20:20 ` Linus Torvalds
2008-01-15 23:10 ` Junio C Hamano
2008-01-16 1:27 ` Junio C Hamano
2008-01-16 2:11 ` Brandon Casey
2008-01-16 19:00 ` [PATCH 1/2] Document lockfile API Junio C Hamano
2008-01-16 19:05 ` [PATCH 2/2] close_lock_file(): new function in the " Junio C Hamano
2008-01-16 20:08 ` Linus Torvalds
2008-01-16 20:36 ` Junio C Hamano
2008-01-16 20:46 ` Brandon Casey
2008-01-16 21:57 ` Junio C Hamano
2008-01-16 22:46 ` Brandon Casey
2008-01-16 22:55 ` Junio C Hamano
2008-01-16 23:08 ` Brandon Casey
2008-01-16 23:16 ` Brandon Casey
2008-01-16 23:19 ` Junio C Hamano [this message]
2008-01-16 23:28 ` Brandon Casey
2008-01-16 7:53 ` git-commit fatal: Out of memory? mmap failed: Bad file descriptor Johannes Sixt
2008-01-15 12:21 ` Junio C Hamano
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=7vtzldmk8p.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=casey@nrlssc.navy.mil \
--cc=git@vger.kernel.org \
--cc=krh@redhat.com \
--cc=raa.lkml@gmail.com \
--cc=torvalds@linux-foundation.org \
/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.
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).