Re: [PATCH v2 2/3] pack-bitmap: fix memory leak if `load_bitmap_entries_v1` failed
- From
lidongyan <502024330056@smail.nju.edu.cn>
- Date
- May 22, 2025, 15:15 UTC
- Message-ID
- <457DC23C-A052-416A-B181-A1EC48AD91A1@smail.nju.edu.cn>
- In-Reply-To
- <aC5nxa0uTb+ieiML@nand.local>
2025年5月22日 07:54,Taylor Blau <me@ttaylorr.com> 写道:
Show 12 quoted lines
> > On Tue, May 20, 2025 at 09:23:09AM +0000, Taylor Blau via GitGitGadget wrote: >> Signed-off-by: Taylor Blau <me@ttaylorr.com> > > This commit forges my Signed-off-by, but I am happy with the result > here. > > I do think the series is structured a little awkwardly as a result of > adding this patch to it. That this and the previous patch have the > subject "pack-bitmap: fix memory leak if `load_bitmap_entries_v1` > failed" make the series not quite as clear as it could be. >
Agreed. I’ve definitely learned a lot about how to write commit messages and cover letters through this process
Show 22 quoted lines
> I think there are a couple of things going on: > > - This patch is a bug fix that could be applied independently of the > first one. The rationale there would be that we shouldn't be leaking > the EWAH bitmaps in 'b->bitmaps', but we are as a result of NULL'ing > the pointer in the "failed" label. That patch can stand alone. > > - The first patch (yours) is no longer fixing a leak, at least after > this patch. But it does delay reading the bitmap until we have > validated its XOR offset for sanity, which is a good thing mostly > from a performance perspective. > > I would probably swap the two patches around so that yours applies on > top of mine, and then rewords the patch message in yours to reflect that > it is no longer fixing a leak. > > That all said, if you feel strongly that the structure is fine/better > as-is, I'd be more than happy to discuss it further. > > Thanks, > Taylor >
I think I can do this in third version, and I have to submit patch v3 after we decide if patch v2 3/3 in this series should live or not.