[Letux-kernel] MIPS: bug: gettimeofday syscall broken on CI20 board?

H. Nikolaus Schaller hns at goldelico.com
Wed Nov 13 14:48:12 CET 2019


> Am 12.11.2019 um 12:37 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> On Monday 11. November 2019 16.52.25 H. Nikolaus Schaller wrote:
>> Hi Paul,
>> looks as if there is nobody active on linux-mips or the mipscreator list...
> 
> I did chat with Ralf Baechle a while back on IRC, but I think he is a very 
> busy person.
> 
>> Do you see a similar effect on your CI20?
>> 
>> Or do you have an idea how to track it down?
> 
> I haven't tried a recent kernel on the CI20 in the last few weeks because I've 
> been using it as my main working machine. There may be some complicating 
> issues with the CI20 that might affect things like DHCP, though: there is some 
> odd behaviour with MAC identifiers where it assigns a new one every time it 
> boots. This is documented on the eLinux wiki:
> 
> https://www.elinux.org/CI20_upstream#Ethernet_MAC_Address
> 
> [...]
> 
>>> I have done some strace and the first significant difference
>>> is that with v5.4-rc6 there is no gettimeofday syscall.
>>> 
>>> Another symptom pointing in the same direction is that
>>> after manually assigning an IP address I can run ping
>>> but get strange time values.
>>> 
>>> So it may be that
>>> 
>>> 24640f233b46 mips: Add support for generic vDSO
>>> 
>>> did break gettimeofday when used with latest Debian Stretch
>>> libraries. I tried to git revert but there are conflicts.
>>> 
>>> Just a side-note: both kernels work with Debian Jessie,
>>> which likely has an older gettimeofday wrapper that
>>> is not influenced by some subtle change.
> 
> I can imagine that some system call and C library incompatibility might have 
> arisen. For various other reasons, I have been looking at things like these, 
> and I did stray into vDSO territory having seen the term mentioned a few 
> times. Unless I am mistaken, it is a way of accessing kernel functionality 
> from user space and can be used to implement some system calls as normal 
> functions accessing kernel resources:
> 
> https://en.wikipedia.org/wiki/VDSO

Also helpful:

http://man7.org/linux/man-pages/man7/vdso.7.html

> 
> https://web.archive.org/web/20190927141756/https://www.linuxjournal.com/content/creating-vdso-colonels-other-chicken
> 
> Interestingly, the second article above talks about gettimeofday as being a 
> candidate for this technology. So it is possible that the later kernel no 
> longer has gettimeofday as a system call, but the C library still expects one.

Yes, that is likely the reason.

The strace doesn't show gettimeofday() system calls:

ioctl(6, SIOCGIFHWADDR, {ifr_name="eth0", ifr_hwaddr=1e:e2:4e:82:c1:d5}) = 0
close(6)                                = 0
setsockopt(5, SOL_PACKET, PACKET_AUXDATA, [1], 4) = 0
setsockopt(5, SOL_SOCKET, SO_ATTACH_FILTER, "\v\0\0\0\204\307kU", 8) = 0
fcntl64(5, F_SETFD, FD_CLOEXEC)         = 0
socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP) = 6
setsockopt(6, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(6, {sa_family=AF_INET, sin_port=htons(68), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
fcntl64(6, F_SETFD, FD_CLOEXEC)         = 0
getpid()                                = 1531
uname({sysname="Linux", nodename="letux", ...}) = 0
time(NULL)                              = 1478193445
getpid()                                = 1531
send(3, "<30>Nov  3 17:17:25 dhclient[153"..., 101, MSG_NOSIGNAL) = 101
write(5, "\377\377\377\377\377\377\36\342N\202\301\325\10\0E\20\1H\0\0\0\0\200\0219\226\0\0\0\0\377\377"..., 342) = 342
write(2, "../../../../lib/isc/unix/time.c:"..., 37../../../../lib/isc/unix/time.c:200: ) = 37
write(2, "Operation not permitted", 23Operation not permitted) = 23

But the source code (I hope it is the right one) shows the
call at line 199:

http://users.isc.org/~each/doxygen/bind9/isc_2unix_2time_8c-source.html

00197 
00198         if (gettimeofday(&tv, NULL) == -1) {
00199                 isc__strerror(errno, strbuf, sizeof(strbuf));
00200                 UNEXPECTED_ERROR(__FILE__, __LINE__, "%s", strbuf);
00201                 return (ISC_R_UNEXPECTED);
00202         }
00203 

So either the dhclient for MIPS on Debian 9.9 isn't using the latest system
libraries or the VDSO implementation is broken (endianness, address offsets?).

The same Debian 9.9 and kernel built from same kernel tree works on ARM.

So an alternative could be my kernel build system for MIPS doesn't properly cross-compile
the vDSO and breaks gettimeofday() operation.

Some more citations from man:

"When you compile the kernel, it will automatically compile and link the vDSO code for you."
"When tracing systems calls with strace(1), symbols (system calls) that are exported by the vDSO will not appear in the trace output."

All this is consistent with this problem.

Unfortunately it is not possible to turn it off any more and force the system
libs to use a real system call.

BR,
Nikolaus





More information about the Letux-kernel mailing list