All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Jonathan Tan <jonathantanmy@google.com>
Cc: gitgitgadget@gmail.com, git@vger.kernel.org, hanwen@google.com,
	avarab@gmail.com, hanwenn@gmail.com
Subject: Re: [PATCH] fixup! propagate errno from failing read
Date: Wed, 18 Aug 2021 15:19:01 -0700	[thread overview]
Message-ID: <YR2HVU4KBCihqoYZ@google.com> (raw)
In-Reply-To: <20210817161419.3606302-1-jonathantanmy@google.com>

Hi,

Jonathan Tan wrote:
> Han-Wen Nienhuys wrote:

>> diff --git a/refs/files-backend.c b/refs/files-backend.c
>> index 0d96eeba61b..f546cc3cc3d 100644
>> --- a/refs/files-backend.c
>> +++ b/refs/files-backend.c
>> @@ -454,6 +454,7 @@ stat_ref:
>>  	}
>>  	strbuf_reset(&sb_contents);
>>  	if (strbuf_read(&sb_contents, fd, 256) < 0) {
>> +		myerr = errno;
>>  		close(fd);
>>  		goto out;
>>  	}
>
> Reviewed-by: Jonathan Tan <jonathantanmy@google.com>
>
> Thanks - a straightforward fixup. (I don't think we need the errno from
> close() in this case.)

This looks good as far as it goes, but how do we know this has covered
all the code paths?  Let's see.

The only nonobvious paths are

 stat_ref:
	/*
	 * We might have to loop back here to avoid a race
	 * condition: first we lstat() the file, then we try
	 * to read it as a link or as a file.  But if somebody
	 * changes the type of the file (file <-> directory
	 * <-> symlink) between the lstat() and reading, then
	 * we don't want to report that as an error but rather
	 * try again starting with the lstat().
	 *
	 * We'll keep a count of the retries, though, just to avoid
	 * any confusing situation sending us into an infinite loop.
	 */

	if (remaining_retries-- <= 0)
		goto out;

and

	ret = parse_loose_ref_contents(buf, oid, referent, type, &myerr);

 out:
	if (ret && !myerr)
		BUG("returning non-zero %d, should have set myerr!", ret);

For the 'stat_ref' case, we have to check that whenever we 'goto
stat_ref', we set myerr moments before.  Fortunately, that is the
case.

For the 'fall through into out' case, we have the check the
parse_loose_ref_contents always sets *failure_errno on error.  That is
also the case.

So this indeed covers all our cases, and the BUG now correctly
reflects an invariant we can count on.  Thanks for the fix, and thanks
for looking it over.

Sincerely,
Jonathan

  reply	other threads:[~2021-08-18 22:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-17 12:31 [PATCH] fixup! propagate errno from failing read Han-Wen Nienhuys via GitGitGadget
2021-08-17 16:14 ` Jonathan Tan
2021-08-18 22:19   ` Jonathan Nieder [this message]
2021-08-17 22:38 ` Junio C Hamano
2021-08-18  9:00   ` Han-Wen Nienhuys
2021-08-18 18:30     ` Junio C Hamano
2021-08-19  0:11       ` Junio C Hamano
2021-08-19  9:01       ` Han-Wen Nienhuys
2021-08-19  3:55 ` Jeff King
2021-08-19  5:01   ` [PATCH] t3200: refactor symlink test Carlo Marcelo Arenas Belón
2021-08-19  5:51     ` Eric Sunshine
2021-08-19  7:52     ` [PATCH v2] t3200: refactor symlink test from hn/refs-errno-cleanup Carlo Marcelo Arenas Belón
2021-08-19 20:26       ` Junio C Hamano
2021-08-19 20:26       ` 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=YR2HVU4KBCihqoYZ@google.com \
    --to=jrnieder@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=hanwen@google.com \
    --cc=hanwenn@gmail.com \
    --cc=jonathantanmy@google.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.