Re: [PATCH v2 07/11] reftable/stack: fix stale lock when dying
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Dec 11, 2023, 09:08 UTC
- Message-ID
- <ZXbRoDh7j18olBDx@tanuki>
- In-Reply-To
- <ZXOXpQstse8CdI7J@nand.local>
On Fri, Dec 08, 2023 at 05:24:37PM -0500, Taylor Blau wrote:
Show 25 quoted lines
> On Fri, Dec 08, 2023 at 03:53:23PM +0100, Patrick Steinhardt wrote:
> > When starting a transaction via `reftable_stack_init_addition()`, we
> > create a lockfile for the reftable stack itself which we'll write the
> > new list of tables to. But if we terminate abnormally e.g. via a call to
> > `die()`, then we do not remove the lockfile. Subsequent executions of
> > Git which try to modify references will thus fail with an out-of-date
> > error.
> >
> > Fix this bug by registering the lock as a `struct tempfile`, which
> > ensures automatic cleanup for us.
>
> Makes sense.
>
> > @@ -475,7 +471,7 @@ static int reftable_stack_init_addition(struct reftable_addition *add,
> > goto done;
> > }
> > if (st->config.default_permissions) {
> > - if (chmod(add->lock_file_name.buf, st->config.default_permissions) < 0) {
> > + if (chmod(lock_file_name.buf, st->config.default_permissions) < 0) {
>
> Hmm. Would we want to use add->lock_file->filename.buf here instead? I
> don't think that it matters (other than that the lockfile's pathname is
> absolute). But it arguably makes it clearer to readers that we're
> touching calling chmod() on the lockfile here, and hardens us against
> the contents of the temporary strbuf changing.It doesn't make much of a difference, but I can see how this might make things a bit clearer to the reader. Will change.
Patrick