From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from secure.elehost.com (secure.elehost.com [185.209.179.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B1C7D1420B3 for ; Tue, 27 Feb 2024 14:28:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.209.179.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709044107; cv=none; b=n9N+h4/VsRu2CLxb79rbYJfeuCG7FBZsbtg+BoCYe4fpzLW03EFLwjxpZSW/9v+PuRPkfz4l1YJnnXPthkp4/1leLAHdqF1Sh9mNMhs4nK/pl798J22aJIdY82azrAUtDZFK1ZxqU/kFqWCcC3TgiKECoxzyYPPDA5+ICiKdRxM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709044107; c=relaxed/simple; bh=5RyLl3/mWFVOZFD5U8Xb8WPh5s1F3/lpASTyEmMM9lg=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=K0kcd6/DHIEGPqSucwOn5DYoTU5uMZQa4WdooTcDpZ50UlxVfhj8406xUOuqVLG4TgQ2aE/xIL7WkZSSIEJfX9a18kIJAX7qvl3+pC8Pe2zkrMusPZC1qS9PIs8JZwjCp8ODHVccR218WetN6j/aeUB7RuNs7TgEGj/CsxgSmd4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=nexbridge.com; spf=pass smtp.mailfrom=nexbridge.com; arc=none smtp.client-ip=185.209.179.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=nexbridge.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=nexbridge.com X-Virus-Scanned: Debian amavisd-new at secure.elehost.com Received: from Mazikeen (cpebc4dfb928313-cmbc4dfb928310.cpe.net.cable.rogers.com [99.228.251.108] (may be forged)) (authenticated bits=0) by secure.elehost.com (8.15.2/8.15.2/Debian-22ubuntu3) with ESMTPSA id 41RESIXJ2358013 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Feb 2024 14:28:19 GMT Reply-To: From: To: "'Patrick Steinhardt'" Cc: , "=?iso-8859-1?Q?'Torsten_B=F6gershausen'?=" , References: <01bd01da681a$b8d70a70$2a851f50$@nexbridge.com> <01be01da681e$0c349090$249db1b0$@nexbridge.com> <20240225191954.GA28646@tb-raspi4> <01ca01da682a$5f6a7b60$1e3f7220$@nexbridge.com> <5e807c1c-20a0-407b-9fc2-acd38521ba45@gmail.com> <02c501da6986$cb7c5c30$62751490$@nexbridge.com> In-Reply-To: Subject: RE: [BUG] 2.44.0 t7704.9 Fails on NonStop ia64 Date: Tue, 27 Feb 2024 09:28:13 -0500 Organization: Nexbridge Inc. Message-ID: <02e401da6989$35fd7510$a1f85f30$@nexbridge.com> Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-ca Thread-Index: AQH6KeHXK3ktIx6cNmAt1sL267+NoQLej1jbAXwNbRICuPECnQG1wVidALQjrBACyRMfnQHUWAXlsG3nkOA= On Tuesday, February 27, 2024 9:22 AM, Patrick Steinhardt wrote: >On Tue, Feb 27, 2024 at 09:10:55AM -0500, rsbecker@nexbridge.com wrote: >> On Tuesday, February 27, 2024 3:46 AM, Patrick Steinhardt wrote: >> >On Mon, Feb 26, 2024 at 03:32:14PM +0000, Phillip Wood wrote: >> >> Hi Randal >> >> >> >> [cc'ing Patrick for the reftable writer] >> >> >> >> > 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()? >> > >> >It already does starting with 85a8c899ce (reftable: handle >> >interrupted >> writes, 2023-12-11): >> > >> >``` >> >static ssize_t reftable_fd_write(void *arg, const void *data, size_t sz) { >> > int *fdp = (int *)arg; >> > return write_in_full(*fdp, data, sz); } >> >> Unfortunately, this fix is included in what I am testing but does not >> impact the issue I am seeing one way or another, but thank you. > >I didn't expect it to :) The mentioned commit only fixes things with the reftable backend, which is not tested by default. I assume that >you didn't run tests with GIT_TEST_DEFAULT_REF_FORMAT=reftable, and thus >t7704 wouldn't use the reftable code in the first place. That is correct, I did not. Thanks.