aarch64-linux-user master: inconsistent pwrite behaviour
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Hello,
I am running aarch64-linux-user from master, commit 20d6c7312f1b812
And I've found the following inconsistent emulation of pwrite() call when buf==NULL and len=0.
Minimal reproducible sample is the following:
#define _GNU_SOURCE
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <string.h>
/*
System | Result
-------
Native x86_64 4.12.14 | pwrite ret = 0
Native aarch64 4.4.159 | pwrite ret = 0
qemu-aarch64 at x86_64 | pwrite ret = -1
( 20d6c7312f1b8 ) |
*/
int main(int argc, char** argv) {
int fd = open("test.dat", O_CREAT | O_RDWR, 0644);
if (fd < 0) {
perror("open");
return 1;
}
int ret = fallocate(fd, 0, 0, 1000);
if (ret < 0) {
perror(
return 1;
}
ssize_t ret_pwrite = pwrite(fd, NULL, 0, 0);
printf("pwrite ret = %ld\n", ret_pwrite);
close(fd);
return 0;
}
Please note, that the same binary executable prints different output at native aarch64 platform and under aarch64-linux-user
Changed in qemu: | |
status: | Fix Committed → Fix Released |
This seems related to commit 58cfa6c2e6eb51b 23cc98f8, where this was fixed for the write() syscall. In that commit message the author writes "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." That doesn't match your results, though, and looking at the source both write and pwrite syscalls go through the vfs_write() function, so their behaviour for a NULL/0 buffer should be identical.