* Re: [PATCH v5 0/4] history: add squash subcommand to fold a range
From: Matt Hunter @ 2026-06-30 2:55 UTC (permalink / raw)
To: phillip.wood, Harald Nordgren
Cc: Patrick Steinhardt, Harald Nordgren via GitGitGadget, git
In-Reply-To: <dff9378a-267f-4b49-bee4-615b4bf75abb@gmail.com>
Hi!
I haven't experimented much with the new 'git history' commands, but
this discussion caught my eye and wanted to chime in. (aka: please
forgive my stupid questions)
Note: I have built and am testing with v6 of this topic.
On Mon Jun 29, 2026 at 3:48 PM EDT, Phillip Wood wrote:
> On 29/06/2026 19:03, Harald Nordgren wrote:
>>> So instead of
>>>
>>> # This is the combination of 4 commits
>>> # This is the first commit message
>>> Base subject
>>>
>>> Base body
>>>
>>> # This is the second commit message
>>> # Another subject
>>>
>>> # Another body
>>>
>>> # This is the third commit message
>>> # fixup! Base subject
>>>
>>> # This is the fourth commit message
>>> # amend! Another subject
>>> A better subject
>>>
>>> A better body
>>>
>>> We'd have
>>>
>>> # This is the combination of 4 commits
>>> # 123 Base subject
>>> # 456 Another subject
>>> # 789 fixup! Base subject
>>> # abc amend! Another subject
>>>
>>> Base Subject
>>>
>>> Base Body
>>>
>>> Another subject
>>>
>>> Another Body
>>
>> I think this makes it a lot harder to read. If every commit body was
>> always just a single paragraph it could make sense, but it's generally
>> not. Look at the commits in this series, with no delimiter of where
>> one commit message ends and the next one starts, it would be very
>> confusing.
>
> You've trimmed the line where I said
>
> >> Possibly with a comment before each message saying where it came
> >> from.
>
> So I'm not against adding a comment before each message, but I do think
> we should omit any messages that would be commented out completely. If
> you look at the rebase example above you can see there is a mass of
> comments between the two pieces of text that make up the new message.
> That makes it hard to see what is actually going to be included in the
> new message.
I agree with this idea as well. And letting fixup! messages completely
fall out makes more sense here than I want to say in git rebase. The
commented list of commits at the top is a nice compromise for the todo
list you would have seen had you run 'git rebase -i' instead, and a
glance at the list would confirm that the fixup!s you thought you
included _actually are_ in the squash range.
I assume the same treatment would _not_ be completely given to squash!
messages, since there is at least some expectation that they carry an
additional remark that the author might want to reword into the base
commit?
>
> Thanks
> Phillip
Given the above, and how 'git rebase' usually works, I'm suprised that
--reedit-message isn't the default behavior. This may be my bias
towards rebase showing... Perhaps the typical use of this command is to
just work fast, and expect a follow up 'git history reword' if needed -
when the original just needs a little extra context?
This is probably a larger question, since (according to the man page) it
affects the other 'git history' commands as well. When I run
'git history ...' and discover that I made a mistake after inspecting
the results, is there a fool-proof way to undo the change and return to
the previous state? My first thought was to run 'git reset --hard ...',
but the default behavior of --update-refs (moving other branches) can
make this more complicated.
Thanks
^ permalink raw reply
* Re: [PATCH] builtin/history: unuse the commit buffer after use
From: Kaartic Sivaraam @ 2026-06-30 3:43 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: Git mailing list
In-Reply-To: <ai_KWo9o1Fhc6OFs@pks.im>
Hi Patrick,
On 15/06/26 15:18, Patrick Steinhardt wrote:
> Huh, curious. That seems to hint that we're missing test coverage for
> this specific scenario, as our test suite doesn't detect this leak.
>
Indeed. The tricky thing is (as mentioned in another thread), this is
happening only when we get a commit not cached in the commit slab. Once
we get an idea on how certain commits get cached in the commit slab
while others don't, we can write a test case that would catch this leak.
>
> So this doesn't really read specific at all, and I would have expected
> us to hit this leak. Puzzling.
>
Yeah. My bad with the commit message. The leak is not happening always.
That is a reason we may not have caught this in the test suite.
>> I must mention that I also noticed the following comment in `commit_tree_ext`:
>>
>> » /* We retain authorship of the original commit. */
>> » original_message = repo_logmsg_reencode(repo, commit_with_message, NULL, NULL);
>>
>> ... but I'm not quite sure why we don't unuse the buffer after its purpose is
>> done. Kindly englighten me in case I missed something.
>
> Did you maybe confuse "authorship" with "ownership" while reading the
> comment? The comment only mentions that we retain the original "Author"
> commit metadata, it doesn't refer to ownership of the underlying
> objects.
>
Got it. Thank you for the correction!
--
Sivaraam
PS: Sorry about the delay in response. Was stuck with some personal work.
^ permalink raw reply
* Re: [PATCH] builtin/history: unuse the commit buffer after use
From: Kaartic Sivaraam @ 2026-06-30 3:45 UTC (permalink / raw)
To: Jeff King; +Cc: Git mailing list, Patrick Steinhardt
In-Reply-To: <20260615172946.GD91269@coredump.intra.peff.net>
Hi Peff,
On 15/06/26 22:59, Jeff King wrote:
> On Mon, Jun 15, 2026 at 11:48:10AM +0200, Patrick Steinhardt wrote:
>> Huh, curious. That seems to hint that we're missing test coverage for
>> this specific scenario, as our test suite doesn't detect this leak.
>
> I think it will only leak when the commit object has an "encoding"
> header. See below.
>
I'm quite sure this is not about the commit with the encoding header.
More below.
> The first paragraph is accurate here. We'd generally just get a pointer
> to the buffer cached in the slab, because no re-encoding occurs. And in
> that case you _don't_ need to call unuse_commit_buffer(), because you
> have a read-only copy, and the slab cache will hold it forever[1].
> Calling the unuse function will be a noop.
>
> But when we _do_ re-encode, then you get a new buffer which must be
> freed. And that is when you have to call the unuse function. And the
> reason it is "unuse" and not just "free" is that you don't necessarily
> know which you have, but that function figures it out (and frees it only
> if necessary).
>
> So what the patch is doing is correct, but the explanation is a little
> confused. We see the leak only when re-encoding, so we'd probably want a
> test case that triggers that. Which I assume implies rewriting a commit
> that was previously generated with an encoding header.
>
Thank you very much for these insights! It has been helpful but on
further digging I think this is not about reencoding. On testing and
digging further, the leak appears to be happening when the commit that
is being reworded we get is a freshly allocated buffer from
repo_get_commit_buffer. I'm still trying to figure out how specific
commits get cached in the slab while other commits don't. I'll update
this thread shortly once I get an idea about the same.
Meanwhile, if anyone knows offhand about this, kindly chime in.
> Now back to that [1] note. Even if we didn't re-encode, we'll still hold
> onto that buffer forever. It's not a "leak" in the traditional sense
> because it's still referenced in the commit slab cache. But if you are
> going to walk over a million commits (like git-log does), you probably
> don't want to hold a million commit messages in memory at once.
>
> For that you'd want to call free_commit_buffer() when you know you're
> totally done with it (again, like git-log does after it finishes showing
> the commit). That might be the case here in commit_tree_ext(), or it
> might happen later (I'm not familiar with the git-history code).
>
> But note that you need to do _both_ the unuse and free calls. If we did
> re-encode, the former is needed to free the newly allocated buffer. The
> latter only drops the original buffer in the cache.
>
From my understanding, I think we may not need free_commit_buffer for
the following reasons:
- The leak was only being reported when the commit did not come
from the commit slab.
- We are not going to be reading too many commit objects into memory in
this code path. Hence freeing the commit in the slab isn't strictly
necessary.
Kindly correct me if I missed something, though.
To conclude, I think the change that the patch proposes if fine but the
commit message definitely needs updation.
--
Sivaraam
^ permalink raw reply
* Re: [RFC] clone: allow sparse-checkout paths to be specified during clone
From: Pushkar Singh @ 2026-06-30 4:02 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, ps
In-Reply-To: <CALE2CrTVVQF4rGhGG-9kmjweFHHYw+xnPU6Jtt=QmHpq7L6P2w@mail.gmail.com>
Hi,
Just a gentle ping in case this RFC got buried.
If anyone has any thoughts on the proposal, I'd be happy to hear them.
I'd mainly like to know whether this seems worth pursuing, or whether
I should move on to another idea.
Thanks,
Pushkar
^ permalink raw reply
* Re: [PATCH] builtin/history: unuse the commit buffer after use
From: Jeff King @ 2026-06-30 5:26 UTC (permalink / raw)
To: Kaartic Sivaraam; +Cc: Git mailing list, Patrick Steinhardt
In-Reply-To: <317d0f7b-469f-4456-8808-506e17de264d@gmail.com>
On Tue, Jun 30, 2026 at 09:15:49AM +0530, Kaartic Sivaraam wrote:
> > So what the patch is doing is correct, but the explanation is a little
> > confused. We see the leak only when re-encoding, so we'd probably want a
> > test case that triggers that. Which I assume implies rewriting a commit
> > that was previously generated with an encoding header.
> >
>
> Thank you very much for these insights! It has been helpful but on further
> digging I think this is not about reencoding. On testing and digging
> further, the leak appears to be happening when the commit that is being
> reworded we get is a freshly allocated buffer from repo_get_commit_buffer.
> I'm still trying to figure out how specific commits get cached in the slab
> while other commits don't. I'll update this thread shortly once I get an
> idea about the same.
>
> Meanwhile, if anyone knows offhand about this, kindly chime in.
The most likely cause of an uncached commit buffer is that we loaded the
commit from the commit-graph (and thus never opened the object in the
first place, so there was nothing to cache).
I suppose it is also possible that we might create a commit struct and
then before ever calling parse_commit() on it, ask to see the commit
msg. And thus we never looked at either the commit graph nor the object
itself.
We'd also refuse to cache if save_commit_buffer is disabled (since
that's the point of that flag). If that were the case I'd expect it to
be set consistently within a given program.
So my guess is probably the commit graph, but it could be that the
command tries to format unparsed commits (which is _not_ a bug or error,
but would trigger the situation where we hand back a freshly allocated
buffer).
I suspect the leak could _also_ be caused by re-encoding, but yeah, the
root cause is "repo_logmsg_reencode gave us an allocated string", and
that can happen when re-encoding is necessary, or when we did not have a
cached buffer in the first place.
> > But note that you need to do _both_ the unuse and free calls. If we did
> > re-encode, the former is needed to free the newly allocated buffer. The
> > latter only drops the original buffer in the cache.
>
> From my understanding, I think we may not need free_commit_buffer for the
> following reasons:
>
> - The leak was only being reported when the commit did not come
> from the commit slab.
> - We are not going to be reading too many commit objects into memory in
> this code path. Hence freeing the commit in the slab isn't strictly
> necessary.
>
> Kindly correct me if I missed something, though.
It depends on the definition of "too many" here. ;) Probably nobody will
notice if you keep a dozen in memory, but they may if the command
happens to get thousands of commits as input. That's not likely, but if
there's an easy moment where the program can say "ah, I am done with
commit X, let's free any resources associated with it" then I think it
is worth doing.
If there isn't such an easy moment, it is probably not that big a deal
to leave it as-is. It's a rare case when somebody would notice at all,
and if you think over the implications above, a repo with an up-to-date
commit graph won't have very many cached entries in the first place.
> To conclude, I think the change that the patch proposes if fine but the
> commit message definitely needs updation.
Yep. Whether we should be calling free_commit_buffer() or not is really
an orthogonal question to the leak. If we want to do something about it,
it would be a separate patch anyway.
-Peff
^ permalink raw reply
* Re: [RFC] clone: allow sparse-checkout paths to be specified during clone
From: Jeff King @ 2026-06-30 5:32 UTC (permalink / raw)
To: Pushkar Singh; +Cc: git, Junio C Hamano, ps
In-Reply-To: <CALE2CrTVVQF4rGhGG-9kmjweFHHYw+xnPU6Jtt=QmHpq7L6P2w@mail.gmail.com>
On Mon, Jun 22, 2026 at 05:05:06PM +0530, Pushkar Singh wrote:
> Currently, the workflow for this is:
>
> git clone --sparse <repo>
> cd <repo>
> git sparse-checkout set <paths>
>
> While this works as intended, it feels somewhat cumbersome, especially
> for someone who is new to Git or not familiar with sparse-checkout
> workflows.
>
> Personally, I do not think of the problem as:
> "I need to initialize sparse-checkout and then configure pathspecs."
>
> Instead, I usually think:
> "I only want to clone these directories from the repository."
>
> With that in mind, I was wondering if it would make sense to allow
> sparse-checkout patterns to be specified directly during clone.
I haven't ever really used sparse-checkout, so I don't have much of an
opinion. IIRC the sparseness is contained in a patterns file, so I'd
have expected the first level of fix to be "you can provide that file at
clone time, rather than afterwards". But maybe nobody really touches
that file manually, and they just use the sparse-checkout helper. Like I
said, I don't have any experience. :)
You might try cc-ing folks who worked on sparse checkouts, especially
Stolee.
One final thought from a non-sparse-checkout user: you're coming at it
from the point of view of ergonomics (it is annoying to clone and then
set up sparsity separately) but there is also a performance question. If
the clone knows which paths are of interest, would that make it possible
to request a partial clone of the specific paths?
I think probably not in practice, because most servers have path-based
filters disabled (because they're expensive and work against bitmaps).
So the strategy is usually more like "don't ask for any blobs at all,
and then let checkout lazy-load them as we increase the sparse
checkout". But I'm also not really a partial-clone user, either. ;)
-Peff
^ permalink raw reply
* Re: [PATCH] builtin/history: unuse the commit buffer after use
From: Jeff King @ 2026-06-30 5:38 UTC (permalink / raw)
To: Kaartic Sivaraam; +Cc: Patrick Steinhardt, Git mailing list
In-Reply-To: <94b0bed5-c86a-4291-b958-52f09faebd29@gmail.com>
On Tue, Jun 30, 2026 at 09:13:28AM +0530, Kaartic Sivaraam wrote:
> On 15/06/26 15:18, Patrick Steinhardt wrote:
> > Huh, curious. That seems to hint that we're missing test coverage for
> > this specific scenario, as our test suite doesn't detect this leak.
> >
>
> Indeed. The tricky thing is (as mentioned in another thread), this is
> happening only when we get a commit not cached in the commit slab. Once we
> get an idea on how certain commits get cached in the commit slab while
> others don't, we can write a test case that would catch this leak.
Try:
make SANITIZE=leak
cd t
GIT_TEST_COMMIT_GRAPH=1 ./t3451-history-reword.sh -v -i
That shows off the leak. It's possible we should be running the LSan
tests in CI with more feature flags enabled, but I suspect it's just as
likely to miss a case as to add one (i.e., there might be a leak when we
_don't_ use the commit graph). We could do both, but the combinatorics
get expensive.
You could add a specific test that builds a commit graph and runs a
history-reword. That would show off the fix, but it's so specific that I
find it a bit unlikely that it would catch a useful regression in the
future.
So I dunno. I would be content with showing the commands above in the
commit message.
-Peff
^ permalink raw reply
* Re: [PATCH] meson: wire up USE_NSEC build knob
From: Jeff King @ 2026-06-30 5:43 UTC (permalink / raw)
To: Patrick Steinhardt
Cc: D. Ben Knoble, git, brian m . carlson, Junio C Hamano,
Ramsay Jones
In-Reply-To: <akIL6oJgUv8J8SB2@pks.im>
On Mon, Jun 29, 2026 at 08:08:42AM +0200, Patrick Steinhardt wrote:
> > True, but AFAICT it probably is safe these days, at least one some
> > platforms.
>
> Hm. That makes me wonder whether it is the completely wrong approach to
> make this a build option then. If it works on some systems and only on
> some filesystems, then a build option is just too coarse-grained. A
> distro wouldn't really be able to ever enable the option, unless it knew
> that repositories will only ever exist on a filesystem that works. Which
> I guess is an assumption that no distro can make.
>
> So instead, I wonder whether we should treat this the same as for
> example "core.ignoreCase", where we only use nanosecond resolution when
> opted in by the user. Ideally, if we had a way to detect brokenness, we
> could even make git-init(1) set it automatically.
Yeah, this came up earlier in the thread. It would be nice if we could
set it automatically, but I'm not sure we have a good way of testing a
particular filesystem. I think the sequence is:
1. stat() a file, getting nanoseconds
2. somehow flush the kernel's in-core inode cache
3. stat() it again and compare
Step 2 is the tricky part. ;) It's not only not portable, but probably
something that would annoy users if we did it for every repo creation.
It would also be nice if we could actually verify that the sequence
above _does_ show the problem. I was not able to come up with a failing
instance on my modern Linux machine (even going as far as unmounting and
re-mounting for step 2).
But I do agree in general that it should be a config flag and not a
build option. Run-time flags are more friendly to users when there is no
good reason to avoid them.
-Peff
^ permalink raw reply
* Re: [PATCH] builtin/history: unuse the commit buffer after use
From: Jeff King @ 2026-06-30 5:50 UTC (permalink / raw)
To: Kaartic Sivaraam; +Cc: Patrick Steinhardt, Git mailing list
In-Reply-To: <20260630053825.GC2495216@coredump.intra.peff.net>
On Tue, Jun 30, 2026 at 01:38:25AM -0400, Jeff King wrote:
> Try:
>
> make SANITIZE=leak
> cd t
> GIT_TEST_COMMIT_GRAPH=1 ./t3451-history-reword.sh -v -i
Of course that made me curious how a full run of the test suite would
react to that flag. We get a few failures of t345x tests, but they all
look like the same leak discussed here.
t4014 also fails, but with a unique leak. I don't think it's the same
thing; it looks like we may leak the slab from init_topo_walk().
-Peff
^ permalink raw reply
* [PATCH 0/2] small leak fix in format-patch
From: Jeff King @ 2026-06-30 6:39 UTC (permalink / raw)
To: git; +Cc: Karthik Nayak, Patrick Steinhardt
This fixes a leak I found while discussing an unrelated leak in another
thread[1]. As a bonus, this fixes some minor recent breakage of
leak-reporting when running the test suite under prove. The patches can
be split into separate topics if we want.
[1/2]: t: move LSan errors from stdout to stderr
[2/2]: format-patch: fix leak of rev_info in prepare_bases()
builtin/log.c | 1 +
t/test-lib.sh | 6 +++---
2 files changed, 4 insertions(+), 3 deletions(-)
-Peff
[1] https://lore.kernel.org/git/20260630055026.GE2495216@coredump.intra.peff.net/
^ permalink raw reply
* [PATCH 1/2] t: move LSan errors from stdout to stderr
From: Jeff King @ 2026-06-30 6:41 UTC (permalink / raw)
To: git; +Cc: Karthik Nayak, Patrick Steinhardt
In-Reply-To: <20260630063944.GA3733670@coredump.intra.peff.net>
When we find LSan errors, we dump them via "say_color", which goes to
stdout. This is mostly harmless, since stdout and stderr tend to go to
the same place (either the user's terminal, or to the ".out" file with
--verbose-log).
But when running under a TAP harness like prove, they are split and
stdout is interpreted as TAP output. Historically even this was fine, as
the extra lines on stdout would be ignored. But since 389c83025d (t: let
prove fail when parsing invalid TAP output, 2026-06-04) we instruct the
TAP reader to complain, and a leaking test will result in complaints
like this (this is a real leak which we have yet to fix):
$ GIT_TEST_COMMIT_GRAPH=1 make SANITIZE=leak test
[...]
Test Summary Report
-------------------
t4014-format-patch.sh (Wstat: 256 (exited 1) Tests: 226 Failed: 30)
Failed tests: 197-226
Non-zero exit status: 1
Parse errors: Unknown TAP token: ""
Unknown TAP token: "================================================================="
Unknown TAP token: "==git==3693658==ERROR: LeakSanitizer: detected memory leaks"
Unknown TAP token: ""
Unknown TAP token: "Direct leak of 200 byte(s) in 1 object(s) allocated from:"
Displayed the first 5 of 1531 TAP syntax errors.
Re-run prove with the -p option to see them all.
You still see the failing tests, so it's mostly just an annoyance. We
can fix it by redirecting to stderr (actually descriptor 4, which is our
verbose-respecting variant). I confirmed manually that the output still
appears with --verbose-log, and even with a single-test "-i
--verbose-only=197" going to the terminal.
Signed-off-by: Jeff King <peff@peff.net>
---
t/test-lib.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index ceefb99bff..d390c53ec1 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -1217,14 +1217,14 @@ check_test_results_san_file_ () {
then
return
fi &&
- say_color error "$(cat "$TEST_RESULTS_SAN_FILE".*)" &&
+ say_color >&4 error "$(cat "$TEST_RESULTS_SAN_FILE".*)" &&
if test "$test_failure" = 0
then
- say "Our logs revealed a memory leak, exit non-zero!" &&
+ say >&4 "Our logs revealed a memory leak, exit non-zero!" &&
invert_exit_code=t
else
- say "Our logs revealed a memory leak..."
+ say >&4 "Our logs revealed a memory leak..."
fi
}
--
2.55.0.346.g83d0ea82e4
^ permalink raw reply related
* [PATCH 2/2] format-patch: fix leak of rev_info in prepare_bases()
From: Jeff King @ 2026-06-30 6:43 UTC (permalink / raw)
To: git; +Cc: Karthik Nayak, Patrick Steinhardt
In-Reply-To: <20260630063944.GA3733670@coredump.intra.peff.net>
In prepare_bases() we do a custom revision walk, separate from the main
format-patch walk. After we finish, we fail to call release_revisions(),
possibly leaking its contents.
We failed to notice it so far because the revision machinery doesn't
always allocate. But at least one case can trigger the leak: if a commit
graph is present, then the topo-walk allocates revs.topo_walk_info and
some associated data structures. You can see it in the test suite by
running:
make SANITIZE=leak
cd t
GIT_TEST_COMMIT_GRAPH=1 ./t4014-format-patch.sh
which yields many entries like:
==git==3687620==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 200 byte(s) in 1 object(s) allocated from:
#0 0x7f4ccba185cb in malloc ../../../../src/libsanitizer/lsan/lsan_interceptors.cpp:74
#1 0x55cd452cdd0b in do_xmalloc wrapper.c:55
#2 0x55cd452cdd9d in xmalloc wrapper.c:76
#3 0x55cd45255473 in init_topo_walk revision.c:3845
#4 0x55cd45255bef in prepare_revision_walk revision.c:4017
#5 0x55cd44ffec40 in prepare_bases builtin/log.c:1872
#6 0x55cd450010ec in cmd_format_patch builtin/log.c:2439
The un-released rev_info has been there since the code was added in
fa2ab86d18 (format-patch: add '--base' option to record base tree info,
2016-04-26), but back then we didn't even have a way to release rev_info
resources! The actual leak probably started around f0d9cc4196
(revision.c: begin refactoring --topo-order logic, 2018-11-01), but it's
hard to bisect because there were so many other unrelated leaks back
then.
So I'm not sure exactly when the leak started beyond "long ago", but it
is easy-ish to find now (since we've plugged all those other leaks) and
the solution is clear.
I didn't add a new test since we can demonstrate it with the existing
ones, but it does require tweaking a test variable. We might consider
ways to get more automatic leak-checking coverage there, but I think it
should be done outside of this fix.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin/log.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/builtin/log.c b/builtin/log.c
index d027ce1e0b..350b35c556 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1888,6 +1888,7 @@ static void prepare_bases(struct base_tree_info *bases,
bases->nr_patch_id++;
}
clear_commit_base(&commit_base);
+ release_revisions(&revs);
}
static void print_bases(struct base_tree_info *bases, FILE *file)
--
2.55.0.346.g83d0ea82e4
^ permalink raw reply related
* Re: [PATCH] builtin/history: unuse the commit buffer after use
From: Jeff King @ 2026-06-30 6:44 UTC (permalink / raw)
To: Kaartic Sivaraam; +Cc: Patrick Steinhardt, Git mailing list
In-Reply-To: <20260630055026.GE2495216@coredump.intra.peff.net>
On Tue, Jun 30, 2026 at 01:50:26AM -0400, Jeff King wrote:
> t4014 also fails, but with a unique leak. I don't think it's the same
> thing; it looks like we may leak the slab from init_topo_walk().
Fixed over in
https://lore.kernel.org/git/20260630063944.GA3733670@coredump.intra.peff.net/.
I think it can be handled independently of your fix here. You might also
run afoul of the prove TAP-output thing fixed in that thread.
-Peff
^ permalink raw reply
page: | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox