From: Phillip Wood Date: Mon, 26 Feb 2024 15:32:14 GMT Subject: Re: [BUG] 2.44.0 t7704.9 Fails on NonStop ia64 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: > 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(). > 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