git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: git@vger.kernel.org, sandals@crustytoothpaste.net, gitster@pobox.com
Subject: Re: [PATCH 3/3] reftable: prevent 'update_index' changes after header write
Date: Fri, 17 Jan 2025 10:29:21 +0100	[thread overview]
Message-ID: <Z4oi55XewgX2deTm@pks.im> (raw)
In-Reply-To: <20250117-461-corrupted-reftable-followup-v1-3-70ee605ae3fe@gmail.com>

On Fri, Jan 17, 2025 at 08:59:14AM +0100, Karthik Nayak wrote:
> diff --git a/reftable/writer.c b/reftable/writer.c
> index 740c98038eaf883258bef4988f78977ac7e4a75a..c602b873543790e36178f797ed9f98112671f97f 100644
> --- a/reftable/writer.c
> +++ b/reftable/writer.c
> @@ -182,6 +182,13 @@ int reftable_writer_new(struct reftable_writer **out,
>  void reftable_writer_set_limits(struct reftable_writer *w, uint64_t min,
>  				uint64_t max)
>  {
> +	/*
> +	 * The limits shouldn't be modified post writing the first block, else
> +	 * it would cause a mismatch between the header and the footer.
> +	 */

Can we make this *even* stricter? I think that this is something that is
easy to do wrong, and the fact that it only triggers in some situations
of misuse may easily make tests miss this issue. So ideally, we should
assert that `set_limits()` is always called before queueing any records
to the writer. This would make us error out in all situations where the
calling order is wrong.

There are two ways I can see us doing that:

  - Detect any state written by `writer_add_record()` and error out if
    it's set when `reftable_writer_set_limits()` is called.

  - Adapt `reftable_writer_new()` so that it takes the update indices as
    input and drop `reftable_writer_set_limits()` altogether.

The latter might be preferable as you basically want to set limits in
all (most?) situations anyway.

> +	if (w->next)
> +		BUG("update index modified after writing first block");

Let's not use BUG, but rather return a `REFTABLE_API_ERROR` error. It
requires a bit more plumbing because we'll also hvae to adapt all
callers to handle errors. But on the one hand we don't want to die in
library code. And on the other hand we don't want to keep on adding more
dependencies on "git-compat-util.h".

Patrick

  reply	other threads:[~2025-01-17  9:29 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-17  7:59 [PATCH 0/3] refs: small followups to the migration corruption fix Karthik Nayak
2025-01-17  7:59 ` [PATCH 1/3] refs: mark `ref_transaction_update_reflog()` as static Karthik Nayak
2025-01-17  9:29   ` Patrick Steinhardt
2025-01-20 11:17     ` Karthik Nayak
2025-01-17  7:59 ` [PATCH 2/3] refs: use 'uint64_t' for 'ref_update.index' Karthik Nayak
2025-01-17  7:59 ` [PATCH 3/3] reftable: prevent 'update_index' changes after header write Karthik Nayak
2025-01-17  9:29   ` Patrick Steinhardt [this message]
2025-01-20 11:47     ` Karthik Nayak
2025-01-20 12:18       ` Karthik Nayak
2025-01-21  3:34 ` [PATCH v2 0/3] refs: small followups to the migration corruption fix Karthik Nayak
2025-01-21  3:34   ` [PATCH v2 1/3] refs: mark `ref_transaction_update_reflog()` as static Karthik Nayak
2025-01-21  3:34   ` [PATCH v2 2/3] refs: use 'uint64_t' for 'ref_update.index' Karthik Nayak
2025-01-21  3:34   ` [PATCH v2 3/3] reftable: prevent 'update_index' changes after adding records Karthik Nayak
2025-01-21  6:56     ` Patrick Steinhardt
2025-01-21 11:44       ` Karthik Nayak
2025-01-22  5:35   ` [PATCH v3 0/3] refs: small followups to the migration corruption fix Karthik Nayak
2025-01-22  5:35     ` [PATCH v3 1/3] refs: mark `ref_transaction_update_reflog()` as static Karthik Nayak
2025-01-22  5:35     ` [PATCH v3 2/3] refs: use 'uint64_t' for 'ref_update.index' Karthik Nayak
2025-01-22  5:35     ` [PATCH v3 3/3] reftable: prevent 'update_index' changes after adding records Karthik Nayak
2025-01-22 12:12       ` Patrick Steinhardt
2025-01-22 17:50         ` Junio C Hamano
2025-01-22 21:57           ` Junio C Hamano
2025-02-01  2:24       ` undefined behavior in unit tests, was " Jeff King
2025-02-01 10:33         ` Phillip Wood
2025-02-03  5:41           ` Patrick Steinhardt
2025-02-03 14:11             ` Junio C Hamano
2025-02-03 15:37           ` Jeff King
2025-02-03  5:40         ` Patrick Steinhardt
2025-02-03 15:20         ` Karthik Nayak
2025-02-03 15:38           ` Jeff King

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=Z4oi55XewgX2deTm@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=karthik.188@gmail.com \
    --cc=sandals@crustytoothpaste.net \
    /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).