git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v5] alloc: fix dangling pointer in alloc_state cleanup

From
ノウラ | Flare <nouraellm@gmail.com>
Date
Sep 5, 2025, 17:47 UTC
Message-ID
<44ae54a6-ba49-40e7-b519-15c12cca0404@gmail.com>
In-Reply-To
<xmqqecsl55gk.fsf@gitster.g>
On 05/09/2025 16:39, Junio C Hamano wrote:
Show 22 quoted lines
> ノウラ | Flare <nouraellm@gmail.com> writes:
>
>> By *s I am referring to *s_ so a sanity check with: if (!*s_) return;
> Because we
>
> 	s = *s_;
>
> upfront, exactly because we do want the code to segfault if the
> caller passes NULL to the function (so s_ that is NULL will cause a
> NULL dereference right there), after that happens checking the NULL
> ness of s and *s_ is equivalent.
>
> And the whole point of doing "s = *s_" upfront is because readers
> can easily get confused when they have to deal with double pointers.
> The only reason why we pass the address of the pointer variable is
> so that we can assign NULL to it at the very end, and before we can
> do so, we want to be able inspect the innards of alloc_state object.
> By dereferencing s_ early into s, the code can work with the object
> itself without having to worry about following double pointer, so
> even though if (!*s_) and if (!s) may be equivalent, writing the
> latter is more in line with the whole reason why we have a variable
> 's' that is separate from 's_'.
I see your point, but I previously wrote we could lean more towards
Strict contract enforcement instead of defensive programming
Which would keep if (!s) return; instead of if (!s_ || !*s_) return;
In any case, I believe we all now agree on if (!s) return;
Pushing it right now.
Happy w-e y'all!
Previous: Junio C HamanoNext: Jeff King
Message 25 of 28 in “reset slab_alloc and state fields in clear_alloc_state()”
  1. reset slab_alloc and state fields in clear_alloc_state()ノウラ | Flare via GitGitGadget, Aug 26, 2025
  2. Junio C HamanoAug 27, 2025
  3. alloc: fix dangling pointer in alloc_state cleanupノウラ | Flare via GitGitGadget, Aug 27, 2025
  4. Torsten BögershausenAug 28, 2025
  5. Junio C HamanoAug 28, 2025
  6. Junio C HamanoAug 28, 2025
  7. alloc: fix dangling pointer in alloc_state cleanupノウラ | Flare via GitGitGadget, Aug 29, 2025
  8. Jeff KingSep 3, 2025
  9. Junio C HamanoSep 3, 2025
  10. alloc: fix dangling pointer in alloc_state cleanupノウラ | Flare via GitGitGadget, Sep 3, 2025
  11. Junio C HamanoSep 4, 2025
  12. ノウラ | FlareSep 4, 2025
  13. Junio C HamanoSep 4, 2025
  14. alloc: fix dangling pointer in alloc_state cleanupノウラ | Flare via GitGitGadget, Sep 4, 2025
  15. Junio C HamanoSep 4, 2025
  16. Jeff KingSep 4, 2025
  17. Junio C HamanoSep 4, 2025
  18. ノウラ | FlareSep 5, 2025
  19. Jeff KingSep 5, 2025
  20. ノウラ | FlareSep 5, 2025
  21. ノウラ | FlareSep 5, 2025
  22. ノウラ | FlareSep 5, 2025
  23. ノウラ | FlareSep 5, 2025
  24. Junio C HamanoSep 5, 2025
  25. ノウラ | FlareSep 5, 2025
  26. Jeff KingSep 5, 2025
  27. alloc: fix dangling pointer in alloc_state cleanupノウラ | Flare via GitGitGadget, Sep 5, 2025
  28. Junio C HamanoSep 5, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.