From nobody Thu Nov 6 08:36:11 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1537865899008114.9550475675536; Tue, 25 Sep 2018 01:58:19 -0700 (PDT) Received: from localhost ([::1]:51717 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g4jAg-0005ue-0r for importer@patchew.org; Tue, 25 Sep 2018 04:58:18 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47381) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g4j7o-0003Hj-DT for qemu-devel@nongnu.org; Tue, 25 Sep 2018 04:55:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g4j7l-0000Bc-50 for qemu-devel@nongnu.org; Tue, 25 Sep 2018 04:55:20 -0400 Received: from mout.kundenserver.de ([212.227.126.130]:52205) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g4j7k-0000B3-Rj for qemu-devel@nongnu.org; Tue, 25 Sep 2018 04:55:17 -0400 Received: from localhost.localdomain ([78.238.229.36]) by mrelayeu.kundenserver.de (mreue011 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MplHR-1fPZH41FIj-00qAfr; Tue, 25 Sep 2018 10:55:07 +0200 From: Laurent Vivier To: qemu-devel@nongnu.org Date: Tue, 25 Sep 2018 10:54:31 +0200 Message-Id: <20180925085432.3791-5-laurent@vivier.eu> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20180925085432.3791-1-laurent@vivier.eu> References: <20180925085432.3791-1-laurent@vivier.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:NHSvVWPesnYgKS+DomRkRM5J4YNtyV3v0NYg8M4eelFtYAMBPMA QWMRLmonUMN38kTLg21CsGPUVBzgkvhwKhzp3k0SQ29Mz14/8tSjgCbKWAZswCmbsXCYUxY B1ur4QL7JKEUienBhC+NDHaWVUEu/vUpdKwHK2vRBE0qU/2uUHc7P5tdAkXcI9P6RRvxxQ4 RQhTS8gnYMyeDfT4yKrAQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:PspBHH92UJ4=:uATAEFRpRDY21eb4n8qzZ8 lYuus6Y6KIV8kp31OD5WbSKIBwlvsuzmxjWpOLY0D0Ld0oVTzEaixs14SY6AfvOXfjswzDn6r R64pz/VSAaykr7ULDHaIVQvJlI2UFqvOkfZuhSSIzL3Uex+8AN0rtcqgvQHsGPnqIYw4PhsEw iqQC59qQhT3I6R8I5B5QUZz7yzjqRptBdxOF80Qey9L3+BqTBzLLPMIv0M6owLKxBRs0VACyD hl86KGgD+wQ0AiNQKmyuf5iJEo90X6KBoFnSq+m2hGtNo1MUeKnz3g/4w5zqW60A7kQ9rcKin Rh7Rm9d8rrjVespAeHH/bu9q3DNZ/+XGOl8ShPJxI9raywXVS0oiW1raVbZSoyT0QkvwHYN5f FaJj9QQvynq5eTn3B17Gkn1rQqW9RzzCgGCwFT8+B3FEROgDuArLNQFBD4o7aaUIoIe0D9Y/u RhaPtP/CsGlkTLbDGsqOl4G2O+gl/V72tdCkXg1XVk3WNOTJipTud5CkWWWiQlMY3rgQdKucg alvg8flNhozt0FAIhcuxlju0/kb/liljZv7smL7Hvbzc8o62f3DBAJxzRgLMiJbOZXTmgflKI 1Sg7+Pc6hIZ0E9rgx4fo4xkNqgObHz0QvdH0pwg2t+yXtFOaNUgv6iVburyrOa/DAMkHzNifh Fu5d133y2Q2iMSl9YYHpMIvliJF6Gdkgm6CdKkQBNETN2tnyNUiJo5NxE+R63NN2l718YIBo0 E8htXiMru+T69mGt X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.126.130 Subject: [Qemu-devel] [PULL 4/5] linux-user: write(fd, NULL, 0) parity with linux's treatment of same X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tony Garnock-Jones , Riku Voipio , Laurent Vivier , Tony Garnock-Jones Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 From: Tony Garnock-Jones Bring linux-user write(2) handling into line with linux for the case of a 0-byte write with a NULL buffer. Based on a patch originally written by Zhuowei Zhang. Addresses https://bugs.launchpad.net/qemu/+bug/1716292. >From Zhuowei Zhang's patch (https://lists.gnu.org/archive/html/qemu-devel/= 2017-09/msg08073.html): Linux returns success for the special case of calling write with a zero-length NULL buffer: compiling and running int main() { ssize_t ret =3D write(STDOUT_FILENO, NULL, 0); fprintf(stderr, "write returned %ld\n", ret); return 0; } gives "write returned 0" when run directly, but "write returned -1" in QEMU. This commit checks for this situation and returns success if found. Subsequent discussion raised the following questions (and my answers): - Q. Should TARGET_NR_read pass through to safe_read in this situation too? A. I'm wary of changing unrelated code to the specific problem I'm addressing. TARGET_NR_read is already consistent with Linux for this case. - Q. Do pread64/pwrite64 need to be changed similarly? A. Experiment suggests not: both linux and linux-user yield -1 for NULL 0-length reads/writes. Signed-off-by: Tony Garnock-Jones Reviewed-by: Philippe Mathieu-Daud=C3=A9 Reviewed-by: Laurent Vivier Message-Id: <20180908182205.GB409@mornington.dcs.gla.ac.uk> Signed-off-by: Laurent Vivier --- linux-user/syscall.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/linux-user/syscall.c b/linux-user/syscall.c index 58fb967499..019af632df 100644 --- a/linux-user/syscall.c +++ b/linux-user/syscall.c @@ -6772,6 +6772,9 @@ static abi_long do_syscall1(void *cpu_env, int num, a= bi_long arg1, } return ret; case TARGET_NR_write: + if (arg2 =3D=3D 0 && arg3 =3D=3D 0) { + return get_errno(safe_write(arg1, 0, 0)); + } if (!(p =3D lock_user(VERIFY_READ, arg2, arg3, 1))) return -TARGET_EFAULT; if (fd_trans_target_to_host_data(arg1)) { --=20 2.17.1