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

Re: [PATCH] t3429: try to protect against a potential racy todo file problem

From
SZEDER Gábor <szeder.dev@gmail.com>
Date
Nov 25, 2019, 13:18 UTC
Message-ID
<20191125131833.GD23183@szeder.dev>
In-Reply-To
<20191124211021.GB23183@szeder.dev>
On Sun, Nov 24, 2019 at 10:10:21PM +0100, SZEDER Gábor wrote:
Show 25 quoted lines
> To notice a changed todo file the sequencer stores the file's stat
> data in its 'struct todo_list' instance, and compares it with the
> file's current stat data after 'reword', 'squash' and 'exec'
> instructions.  If the two stat data doesn't match, it re-reads the
> todo file.
> 
> Sounds simple, but there are some subtleties going on here:
> 
>   - The 'struct todo_list' holds the stat data from the time when the
>     todo file was last read.
> 
>   - This stat data in 'struct todo_list' is not updated when the
>     sequencer itself writes the todo file.
> 
>   - Before executing each instruction during an interactive rebase,
>     the sequencer always updates the todo file by removing the
>     just-about-to-be-executed instruction.  This changes the file's
>     size and inode [1].
> 
> Consequently, when the sequencer looks at the stat data after a
> 'reword', 'squash' or 'exec' instruction, it most likely finds that
> they differ, even when the user didn't modify the todo list at all!
> This is not an issue in practice, it just wastes a few cycles on
> re-reading the todo list that matches what the sequencer already has
> in memory anyway.

It can be much more than just a few cycles, because the total number of parsed instructions from all the todo file re-reads can go quadratic with the number of rebased commits.

The simple test below runs 'git rebase -i -x' on 1000 commits, which takes over 14seconds to run. If it doesn't re-read the todo file at all (I simply deleted the whole condition block checking the stat data and re-reading) it runs for only ~2.5secs.

Just another angle to consider...
  ---  >8  ---
test_expect_success 'test' '
	num_commits=1000 &&
	test_commit_bulk --filename=file $num_commits &&
	/usr/bin/time -f "Elapsed time: %e" \
		git rebase -i --root -x true 2>out &&
	grep "Executing: true" out >actual &&
	test_line_count = $num_commits actual &&
	# show the elapsed time
	tail -n2 out
'
  ---  >8  ---
Previous: SZEDER GáborNext: Phillip Wood
Message 11 of 16 in “git 2.24: git revert <commit1> <commit2> requires extra '--continue'?”
  1. Brian NorrisNov 22, 2019
  2. SZEDER GáborNov 23, 2019
  3. Phillip WoodNov 23, 2019
  4. sequencer: don't re-read todo for revert and cherry-pickSZEDER Gábor, Nov 23, 2019
  5. Johannes SchindelinNov 23, 2019
  6. Junio C HamanoNov 24, 2019
  7. Phillip WoodNov 24, 2019
  8. t3429: try to protect against a potential racy todo file problemSZEDER Gábor, Nov 24, 2019
  9. Junio C HamanoNov 25, 2019
  10. SZEDER GáborNov 25, 2019
  11. SZEDER GáborNov 25, 2019
  12. Phillip WoodNov 25, 2019
  13. SZEDER GáborNov 25, 2019
  14. Phillip WoodNov 25, 2019
  15. Junio C HamanoNov 25, 2019
  16. Phillip WoodNov 25, 2019

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.