blob: c50e154db663659b9737ba9342a71a65d9e56d9a (
plain) (
blame)
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
|
socket: 0.815
mistranslation: 0.768
semantic: 0.637
user-level: 0.579
device: 0.551
kernel: 0.535
network: 0.424
boot: 0.362
graphic: 0.355
architecture: 0.337
performance: 0.329
x86: 0.256
risc-v: 0.244
i386: 0.222
vnc: 0.192
debug: 0.167
peripherals: 0.162
KVM: 0.149
arm: 0.149
virtual: 0.142
ppc: 0.133
permissions: 0.128
VMM: 0.111
TCG: 0.105
hypervisor: 0.097
PID: 0.097
register: 0.073
assembly: 0.049
files: 0.047
linux-user emulation of setsockopt ignores optlen
setsockopt always treats the argument as a 4-byte int. This breaks timeout options (for which it's an 8- or 16-byte timeval structure, depending on word size) and possibly other socket options. int is probably a safe default, but options whose values are other types need special-case conversion code.
Agreed; we would ideally be more careful to return ENOTSUP for options we don't know we handle correctly. It would be useful if you said which particular options you were interested in and provided a test case...
I mentioned the timeout options (send/receive timeout) which are the
ones I was interested in.
We fixed our setsockopt emulation to correctly convert timeval parameters for SO_RCVTIMEO and SO_SNDTIMEO back in 2013.
|
