git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 2/3] refs/files-backend: stop setting errno from lock_ref_oid_basic

From
Junio C Hamano <gitster@pobox.com>
Date
Apr 29, 2021, 01:55 UTC
Message-ID
<xmqqa6pham83.fsf@gitster.g>
In-Reply-To
<CAFQ2z_O=4sUjh1wk6nRijp9Gz2eeqX4=EY+Q-OTi9ppb9ikg3g@mail.gmail.com>
Han-Wen Nienhuys <hanwen@google.com> writes:
Show 11 quoted lines
> On Wed, Apr 28, 2021 at 6:20 AM Junio C Hamano <gitster@pobox.com> wrote:
>> > These calls do I/O and therefore clobber errno. They are not inspecting the
>> > incoming errno.
>>
>> Hmph, are you saying that these calls do I/O and always the I/O
>> would fail?  A system call that is successfull don't touch errno;
>> only the calls that resulted in failure do.
>
> I'm saying that callers cannot reliably observe the errno result of
> lock_ref_oid_basic, because it might be clobbered by a failing
> follow-up call.

Sorry, I still do not quite get it. For example, you cite that a call to lock_ref_oid_basic() in files_create_symref() is followed by create_symref_locked() that may clobber errno when the latter fails.

But a failing lock_ref_oid_basic() would yield NULL and causes the caller to leave, before calling create_symref_locked() and letting it clobber errno, and the caller of files_create_symref() can observe, when it returns -1 to signal an error, the errno left by lock_ref_oid_basic(), no? I would understand it if no caller of files_create_symref() cares what is in errno when it receives negative return to signal a failure, though.

And when lock_ref_oid_basic() did not fail, create_symref_locked() calls helpers that can fail (e.g. fdopen_lock_file()) and result in errno getting updated to record how it failed (this is also reported to the user via "error(... strerror(errno))").

So a caller of files_create_symref() may not be able to tell between lock_ref_oid_basic() and create_symref_locked() which one caused the files_create_symref() call to fail, but in either case it should be able to inspect errno to learn what kind of error we got from the underlying system, no?

Previous: Han-Wen NienhuysNext: Han-Wen Nienhuys
Message 9 of 11 in “refs: remove EINVAL specification from the errno sideband in read_raw_ref_fn”
  1. refs: remove EINVAL specification from the errno sideband in read_raw_ref_fnHan-Wen Nienhuys via GitGitGadget, Apr 23, 2021
  2. Jeff KingApr 23, 2021
  3. Han-Wen NienhuysApr 23, 2021
  4. 0/3 refs: cleanup errno sideband ref related functions.Han-Wen Nienhuys via GitGitGadget, Apr 23, 2021
  5. 1/3 refs: remove EINVAL specification from the errno sideband in read_raw_ref_fnHan-Wen Nienhuys via GitGitGadget, Apr 23, 2021
  6. 2/3 refs/files-backend: stop setting errno from lock_ref_oid_basicHan-Wen Nienhuys via GitGitGadget, Apr 23, 2021
  7. Junio C HamanoApr 28, 2021
  8. Han-Wen NienhuysApr 28, 2021
  9. Junio C HamanoApr 29, 2021
  10. Han-Wen NienhuysApr 29, 2021
  11. 3/3 refs: make errno output explicit for read_raw_ref_fnHan-Wen Nienhuys via GitGitGadget, Apr 23, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.