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

H. Nikolaus Schaller hns at goldelico.com
Thu Nov 28 14:48:46 CET 2019


> Am 28.11.2019 um 14:29 schrieb Maarten ter Huurne <maarten at treewalker.org>:
> 
> On Thursday, 28 November 2019 13:33:17 CET H. Nikolaus Schaller wrote:
>> Hi Vincenzo,
>> 
>>> Am 28.11.2019 um 13:21 schrieb Vincenzo Frascino
>>> <vincenzo.frascino at arm.com>:> 
>>> [...]
>>> The the lib that provides the gettimeofday() changes accordingly
>>> with vdso_data. 5.4 and 4.19 have 2 different vdso libraries as
>>> well.
>> 
>> Yes, that is what I have assumed what happens. How do these libs go
>> into an existing and working root-file-system with Debian Stretch?
> 
> I'm a novice when it comes to vDSO, so someone please correct me if I'm 
> wrong.
> 
> From what I read vDSO is a library in the sense that it exports ELF 
> symbols that applications and other libraries (libc in particular) can 
> use, but it is not a file on disk.

Ah, ok. This would mean that the libc providing the gettimeofday()
should be able to find out a modified changed vdso_data format by
inspecting these ELF symbols.

> 
> As such, which rootfs you use shouldn't matter, since the vDSO is not in 
> the rootfs. Instead, it is contained in the kernel image. Searching for 
> "linux-vdso.so.1" on packages.debian.org indeed returns no hits.
> 
> There is a check in arch/mips/vdso/Makefile that disables vDSO on MIPS 
> when building the kernel with binutils < 2.25. I don't know if that is 
> in any way related to this issue.

What still does not fit into the picture is the errno = 1 i.e. EPERM.
Maybe I have to study the libc code that tries to read the ELF symbols
you have mentioned. It may fail for unknown reasons.

BR and thanks,
Nikolaus


More information about the Letux-kernel mailing list