All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Atneya Nair <atneya@google.com>,
	 git@vger.kernel.org, jeffhost@microsoft.com,  me@ttaylorr.com,
	 nasamuffin@google.com,  Tanay Abhra <tanayabh@gmail.com>,
	 Glen Choo <glencbz@gmail.com>
Subject: Re: [RFC PATCH 2/3] Make ce_compare_gitlink thread-safe
Date: Tue, 05 Mar 2024 17:58:09 -0800	[thread overview]
Message-ID: <xmqqzfvcunny.fsf@gitster.g> (raw)
In-Reply-To: <20240306012323.GA3817803@coredump.intra.peff.net> (Jeff King's message of "Tue, 5 Mar 2024 20:23:23 -0500")

Jeff King <peff@peff.net> writes:

> There is one more, I think: if you _do_ free the allocated string to
> avoid the leak you mention, then some other code which was relying on
> the lifetime of that string to be effectively infinite will now have a
> user-after-free.

Ah, yes, you're right.  I completely forgot about that shallow copy.

> A few other things to note, looking at this code:
>
>   - isn't kvi->path in the same boat? We do not duplicate it at all, so
>     it seems like the shallow copy made in the configset could cause a
>     user-after-free.
>
>   - the "fix" I showed above hits your point 2: now we are making a lot
>     more copies of that string. I will note that we're already making a
>     lot of copies of the kvi struct in the first place, so unless you
>     have really long pathnames, it probably isn't a big difference.
>
>     But it possibly could make sense to have the configset own a single
>     duplicate string, and then let the kvi structs it holds point to
>     that string. But IMHO all of this should be details of the configset
>     code, and the main config-iteration code should not have to worry
>     about this at all. I.e., I think kvi_from_source() should not be
>     duplicating anything in the first place.

Thanks for a detailed write-up.

  reply	other threads:[~2024-03-06  1:58 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-05  1:21 [RFC PATCH 0/3] Parallel submodule status Atneya Nair
2024-03-05  1:21 ` [RFC PATCH 1/3] Make read_gitfile and resolve_gitfile thread safe Atneya Nair
2024-03-05  2:22   ` Junio C Hamano
2024-03-05  4:29   ` Eric Sunshine
2024-03-12 20:38     ` Atneya Nair
2024-03-06  8:13   ` Jean-Noël Avila
2024-03-06 16:57     ` Junio C Hamano
2024-03-12 20:44       ` Atneya Nair
2024-03-05  1:21 ` [RFC PATCH 2/3] Make ce_compare_gitlink thread-safe Atneya Nair
2024-03-05 17:08   ` Junio C Hamano
2024-03-05 18:53     ` Junio C Hamano
2024-03-06  1:23       ` Jeff King
2024-03-06  1:58         ` Junio C Hamano [this message]
2024-03-12 22:13         ` Atneya Nair
2024-03-12 22:15     ` Atneya Nair
2024-03-13 17:51       ` Junio C Hamano
2024-03-05  1:21 ` [RFC PATCH 3/3] Preload submodule state in refresh_index Atneya Nair

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=xmqqzfvcunny.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=atneya@google.com \
    --cc=git@vger.kernel.org \
    --cc=glencbz@gmail.com \
    --cc=jeffhost@microsoft.com \
    --cc=me@ttaylorr.com \
    --cc=nasamuffin@google.com \
    --cc=peff@peff.net \
    --cc=tanayabh@gmail.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.