Re: [PATCH v2 2/3] pack-bitmap: fix memory leak if `load_bitmap_entries_v1` failed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2025年5月22日 07:54,Taylor Blau <me@xxxxxxxxxxxx> 写道:
> 
> On Tue, May 20, 2025 at 09:23:09AM +0000, Taylor Blau via GitGitGadget wrote:
>> Signed-off-by: Taylor Blau <me@xxxxxxxxxxxx>
> 
> 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

> 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. 




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux