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

Re: [BUG] 2.44.0 t7704.9 Fails on NonStop ia64

From
PWPhillip Wood <phillip.wood123@gmail.com>
Date
Feb 26, 2024, 15:32 UTC
Message-ID
<5e807c1c-20a0-407b-9fc2-acd38521ba45@gmail.com>
In-Reply-To
<01ca01da682a$5f6a7b60$1e3f7220$@nexbridge.com>
Hi Randal
[cc'ing Patrick for the reftable writer]
On 25/02/2024 20:36, rsbecker@nexbridge.com wrote:
Show 10 quoted lines
> On Sunday, February 25, 2024 2:20 PM, Torsten Bögershausen wrote:
>> On Sun, Feb 25, 2024 at 02:08:35PM -0500, rsbecker@nexbridge.com wrote:
>>> On Sunday, February 25, 2024 1:45 PM, I wrote:
>>>> To: git@vger.kernel.org
>> But I think that this should be used:
>> write_in_full()
> 
> My mailer autocorrected, yes, xwrite. write_in_full() would be safe,
> although a bit redundant since xwrite() does similar things and is used by
> write_in_full().

Note that unlike write_in_full(), xwrite() does not guarantee to write the whole buffer passed to it. In general unless a caller is writing a single byte or writing less than PIPE_BUF bytes to a pipe it should use write_in_full().

Show 6 quoted lines
> The question is which call is bad? The cruft stuff is
> relatively new and I don't know the code.
> 
>>> reftable/writer.c:              int n = w->write(w->write_arg, zeroed,
>>> w->pending_padding);
>>> reftable/writer.c:      n = w->write(w->write_arg, data, len);

Neither of these appear to check for short writes and reftable_fd_write() is a thin wrapper around write(). Maybe reftable_fd_write() should be using write_in_full()?

>>> run-command.c:                  len = write(io->fd, io->u.out.buf,
This call to write() looks correct as it is in the io pump loop.
>>> t/helper/test-path-utils.c:                     if (write(1, buffer,
> count)
>>> < 0) >>> t/helper/test-windows-named-pipe.c:             write(1, buf, nbr);
>>> t/helper/test-windows-named-pipe.c:             write(1, buf, nbr);
In principle these all look like they are prone to short writes.
>>> trace2/tr2_dst.c:       bytes = write(fd, buf_line->buf, buf_line->len);
This caller explicitly says it prefers short writes over retrying
Best Wishes
Phillip
Previous: rsbecker@nexbridge.comNext: rsbecker@nexbridge.com
Message 5 of 15 in “[BUG] 2.44.0 t7704.9 Fails on NonStop ia64”
  1. rsbecker@nexbridge.comFeb 25, 2024
  2. rsbecker@nexbridge.comFeb 25, 2024
  3. Torsten BögershausenFeb 25, 2024
  4. rsbecker@nexbridge.comFeb 25, 2024
  5. Phillip WoodFeb 26, 2024
  6. rsbecker@nexbridge.comFeb 26, 2024
  7. Phillip WoodFeb 26, 2024
  8. rsbecker@nexbridge.comFeb 26, 2024
  9. rsbecker@nexbridge.comFeb 26, 2024
  10. phillip.wood123@gmail.comFeb 26, 2024
  11. Patrick SteinhardtFeb 27, 2024
  12. phillip.wood123@gmail.comFeb 27, 2024
  13. rsbecker@nexbridge.comFeb 27, 2024
  14. Patrick SteinhardtFeb 27, 2024
  15. rsbecker@nexbridge.comFeb 27, 2024

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.