Re: [RFC PATCH 1/2] reftable: remove the "return_block" abstraction

From: Han-Wen Nienhuys <hanwen@google.com>
Date: Apr 25, 2022, 09:57 UTC
Message-ID: <CAFQ2z_O7ytx=AsXuJbYnOdMwT0u03sMP-ZjRRjt4HFn48HT-2g@mail.gmail.com>
In-Reply-To: <RFC-patch-1.2-76ed86bf88c-20220415T101740Z-avarab@gmail.com>

On Fri, Apr 15, 2022 at 12:21 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

Show 8 quoted lines

>
> This abstraction added in 1214aa841bc (reftable: add blocksource, an
> abstraction for random access reads, 2021-10-07) has the caller
> provide a "blockp->data", so there's not point in having the vtable
> have a custom free() function.
>
> In addition this had what looked like a poor man's SANITIZE=address
> doing a memset() to 0xff just before the data was free'd.

Show 6 quoted lines

>  void reftable_block_done(struct reftable_block *blockp)
>  {
> -       struct reftable_block_source source = blockp->source;
> -       if (blockp && source.ops)
> -               source.ops->return_block(source.arg, blockp);
> +       FREE_AND_NULL(blockp->data);

My thinking here is that we could mmap the reftable file to do reads. In that case, discarding the block would imply decreasing a refcount somewhere, rather than deallocating memory.

-- 
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.