git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Martin Ågren" <martin.agren@gmail.com>
Cc: Michael Haggerty <mhagger@alum.mit.edu>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH v3 1/3] refs/files-backend: add longer-scoped copy of string to list
Date: Tue, 05 Sep 2017 19:02:55 +0900	[thread overview]
Message-ID: <xmqq60cxcvjk.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: CAN0heSqa8OnPnkd1xbyZ=QN9qg_8OaxBYnwzOZDDA3g+uGE71g@mail.gmail.com

Martin Ågren <martin.agren@gmail.com> writes:

> On 30 August 2017 at 04:52, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> v3 looks good to me. Thanks!
>>
>> Reviewed-by: Michael Haggerty <mhagger@alum.mit.edu>
>
> Thank _you_ for very helpful feedback on the earlier versions.
>
> Martin

Yes, the earlier attempt was sort-of barking up a wrong tree.  

Once we step back and observe other users of affected_refnames and
realize that the list is meant to to point at a refname field of an
existing instance of another structure by borrowing, the blame
shifts from files_transaction_prepare() to the real culprit.
Michael's review gave us a very good "let's step back a bit" that
made the huge improvement between v1 and v2/v3.

I wonder if we should be tightening the use of affected_refnames
even further, though.  

It is may be sufficient to make sure that we do not throw anything
that we would need to free as part of destroying affected_refnames
into the string list, purely from the "leak prevention" perspective.

But stepping back a bit, the reason why the string list exists in
the first place is to make sure we do not touch the same ref twice
in a single transaction, the set of all possible updates in the
single transaction exists somewhere, and each of these updates know
what ref it wants to update.  

And that is recorded in transaction->updates[]->refname no?

So it seems to me that logically any and all string that is
registered in affected_refnames list must be the refname field of
a ref_update structure in the transaction.

And from that point of view, doesn't split_head_update() wants a
similar fix?  It attempts to insert "HEAD", makes sure it hasn't
been inserted and then hangs a new update transaction as its util.
It is not wrong per-se from purely leak-prevention point of view,
as that "HEAD" is a literal string we woudn't even want to free,
but from logical/"what each data means" point of view, it still
feels wrong.



  reply	other threads:[~2017-09-05 10:03 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-25 18:49 [PATCH 1/2] refs/files-backend: duplicate strings added to affected_refnames Martin Ågren
2017-08-25 18:49 ` [PATCH 2/2] refs/files-backend: fix memory leak in lock_ref_for_update Martin Ågren
2017-08-25 21:00 ` [PATCH 1/2] refs/files-backend: duplicate strings added to affected_refnames Junio C Hamano
2017-08-26 10:16   ` Martin Ågren
2017-08-28  8:06     ` Michael Haggerty
2017-08-28 10:09       ` Martin Ågren
2017-08-28 20:32         ` [PATCH v2 1/2] refs/files-backend: add longer-scoped copy of string to list Martin Ågren
2017-08-29  8:33           ` Michael Haggerty
2017-08-28 20:32         ` [PATCH v2 2/2] refs/files-backend: fix memory leak in lock_ref_for_update Martin Ågren
2017-08-29  8:39           ` Michael Haggerty
2017-08-29 10:41             ` Martin Ågren
2017-08-29 17:18               ` [PATCH v3 1/3] refs/files-backend: add longer-scoped copy of string to list Martin Ågren
2017-08-30  2:52                 ` Michael Haggerty
2017-08-30 18:02                   ` Martin Ågren
2017-09-05 10:02                     ` Junio C Hamano [this message]
2017-09-05 17:24                       ` Martin Ågren
2017-09-05 20:36                         ` Jeff King
2017-09-05 21:26                           ` Junio C Hamano
2017-09-06 18:12                             ` Martin Ågren
2017-09-06 19:52                               ` Junio C Hamano
2017-09-06 23:45                               ` Jeff King
2017-09-09  6:57                               ` [PATCH v4 0/4] Rerolling ma/split-symref-update-fix Martin Ågren
2017-09-09  6:57                                 ` [PATCH v4 1/4] refs/files-backend: add longer-scoped copy of string to list Martin Ågren
2017-09-09  6:57                                 ` [PATCH v4 2/4] refs/files-backend: fix memory leak in lock_ref_for_update Martin Ågren
2017-09-09  6:57                                 ` [PATCH v4 3/4] refs/files-backend: correct return value " Martin Ågren
2017-09-09  6:57                                 ` [PATCH v4 4/4] refs/files-backend: add `refname`, not "HEAD", to list Martin Ågren
2017-09-09 10:47                                 ` [PATCH v4 0/4] Rerolling ma/split-symref-update-fix Jeff King
2017-09-05  8:45                 ` [PATCH v3 1/3] refs/files-backend: add longer-scoped copy of string to list Jeff King
2017-09-05  9:03                   ` Michael Haggerty
2017-09-05  9:04                     ` Jeff King
2017-08-29 17:18               ` [PATCH v3 2/3] refs/files-backend: fix memory leak in lock_ref_for_update Martin Ågren
2017-09-05  8:47                 ` Jeff King
2017-09-05 17:28                   ` Martin Ågren
2017-08-29 17:18               ` [PATCH v3 3/3] refs/files-backend: correct return value " Martin Ågren

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq60cxcvjk.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=martin.agren@gmail.com \
    --cc=mhagger@alum.mit.edu \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).