1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
|
debug: 0.994
semantic: 0.993
arm: 0.991
assembly: 0.989
virtual: 0.989
performance: 0.988
architecture: 0.988
risc-v: 0.986
graphic: 0.986
register: 0.985
mistranslation: 0.985
device: 0.983
hypervisor: 0.982
peripherals: 0.982
vnc: 0.981
PID: 0.980
user-level: 0.979
boot: 0.973
ppc: 0.972
permissions: 0.966
socket: 0.964
VMM: 0.963
kernel: 0.962
network: 0.951
TCG: 0.950
KVM: 0.949
files: 0.943
x86: 0.826
i386: 0.801
aarch64-linux-user master: inconsistent pwrite behaviour
Hello,
I am running aarch64-linux-user from master, commit 20d6c7312f1b812bb9c750f4087f69ac8485cc90
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("fallocate");
return 1;
}
ssize_t ret_pwrite = pwrite(fd, NULL, 0, 0);
printf("pwrite ret = %ld\n", ret_pwrite);
close(fd);
return 0;
}
This seems related to commit 58cfa6c2e6eb51b23cc98f8, 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.
strace from an aarch64 machine:
pwrite64(3, NULL, 0, 0) = 0
strace from QEMU:
32029 pwrite64(3,0,0,0,4797560,0) = -1 errno=14 (Bad address)
Do you know how to fix it?
It should be a patch pretty similar to commit 58cfa6c2e6eb51b23cc98f8, but in the pwrite64 codepath. Slightly complicated by needing to deal with the offset possibly being in two input arguments, but basically the same thing.
It would be great if you could fix it.
Also, there are probably should exist POSIX conformance test suites around the world. As far as I understand, this particular issue could be found by running such a test under qemu-linux-user. I mean what if there are other similar issues?
We run the Linux Test Project LTP test suite. However I think it may not cover this corner case. (It's also possible I missed it last time I went through our failure results -- it's a lot of analysis effort to disentangle "QEMU bug" from "QEMU missing feature that's impracticably hard to implement" from "test case bug", and sometimes tests roll up multiple tests into a single test binary that include things from several of those cases, which means that it's harder to notice when something that should have passed did not.)
I've also check qemu-arm with the same test code. Surprisingly, I see correct result:
pwrite ret = 0
Proposed patch at https://patchwork.ozlabs.org/patch/1022092/
NB: my guess is that your pwrite on 32-bit arm test is behaving like that because it isn't going via the pwrite64 syscall, or possibly because glibc there is dealing with the NULL special case early. Use QEMU's -strace argument (or strace on real h/w) to see what libc is actually turning that pwrite() function call into at the syscall level.
Commit now in QEMU master as 2bd3f8998e1e7dcd9afc29fab25. This will be in the next release: QEMU 4.0.
Thank you!
пт, 18 янв. 2019 г. в 19:36, Peter Maydell <email address hidden>:
>
> Commit now in QEMU master as 2bd3f8998e1e7dcd9afc29fab25. This will be
> in the next release: QEMU 4.0.
>
>
> ** Changed in: qemu
> Status: In Progress => Fix Committed
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1810433
>
> Title:
> aarch64-linux-user master: inconsistent pwrite behaviour
>
> Status in QEMU:
> Fix Committed
>
> Bug description:
> Hello,
>
> I am running aarch64-linux-user from master, commit
> 20d6c7312f1b812bb9c750f4087f69ac8485cc90
>
> 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("fallocate");
> 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
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/qemu/+bug/1810433/+subscriptions
--
With best regards,
Matwey V. Kornilov
|