[Qemu-devel] utimensat trouble on mips

[Qemu-devel] utimensat trouble on mips

[Johannes Schauer]

Hi,

I am following up on threads started here [1] and here [2]. I'm not
subscribed to qemu-devel so please dont forget to CC me.

About a year ago, Kenneth Johansson reported [1], that trying to do a
debian debootstrap using qemu user emulation will fail due to the
following error:

/bin/tar: ./postinst: Cannot utime: Level 2 not synchronized

Lisandro had a very similar issue [2]:

/usr/bin/touch: setting times of `tito': Level 2 not synchronized

Since I was also interested in bootstrapping debian using qemu user mode
emulation at some point I tracked down the error to the usage of
utimensat which results in a ENOSYS error (being translated to
EL2NSYNC).

Here is a quick and dirty C snippet that allows to reproduce the issue:

-%<-----------------------------------------
#include <stdio.h>
#include <sys/stat.h>
#include <fcntl.h>

int main()
{
    int ret, fd, dir;

    dir = open(".", O_RDONLY);
    fd = open("./foobar", O_WRONLY|O_CREAT, 0666);
    ret = utimensat(dir, "./foobar", NULL, 0);
    perror("utimensat");

    return 0;
}
----------------------------------------->%-

To see how different architectures behave when executing this, I
compiled it natively and crosscompiled it for arm and mips. I statically
compiled it to avoid shared library troubles. Because of binfmt support
I do not prepend qemu-mips or qemu-arm in the following.

$ gcc -Wall -static utimensat.c
$ file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.18, not stripped
$ ./a.out
utimensat: Success
$ arm-linux-gnueabi-gcc -Wall -static utimensat.c
$ file a.out
a.out: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.6.18, not stripped
$ ./a.out
utimensat: Success
$ mips-linux-gnu-gcc -Wall -static utimensat.c
$ file a.out
a.out: ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, for GNU/Linux 2.6.18, with unknown capability 0x41000000 = 0xf676e75, with unknown capability 0x10000 = 0x70401, not stripped
$ ./a.out
utimensat: Level 2 not synchronized
$ mipsel-linux-gnu-gcc -Wall -static utimensat.c
$ file a.out
a.out: ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, for GNU/Linux 2.6.18, with unknown capability 0xf41 = 0x756e6700, with unknown capability 0x70100 = 0x1040000, not stripped
$ ./a.out
utimensat: Level 2 not synchronized

As one can see the error only shows on mips. It also occurs when
natively compiling above snippet on mips and it also occurs when using a
natively compiled `touch` binary for mips from the debian coreutils
package.

Now my questions are:

* why is this happening with mips?
* Whose fault is it?
* is it a qemu bug?
* should I open a bugreport about this issue?
* why was nobody else complaining about it, given that this is an issue
  for over a year now?

thank you

cheers, josch

[1] http://lists.gnu.org/archive/html/qemu-devel/2010-05/msg00116.html
[2] http://lists.gnu.org/archive/html/qemu-devel/2011-07/msg00102.html

Re: [Qemu-devel] utimensat trouble on mips

[Peter Maydell]

On 5 July 2011 13:07, Johannes Schauer <j.schauer@email.de> wrote:
> About a year ago, Kenneth Johansson reported [1], that trying to do a
> debian debootstrap using qemu user emulation will fail due to the
> following error:
>
> /bin/tar: ./postinst: Cannot utime: Level 2 not synchronized

This is the result of issues 1. and 2. listed by Wesley in this
email:
 http://lists.nongnu.org/archive/html/qemu-devel/2011-07/msg00313.html

> Now my questions are:
>
> * why is this happening with mips?

Because the particular bit of QEMU code which was wrongly returning
the host ENOSYS rather than the guest ENOSYS happened to be
MIPS-specific.

> * is it a qemu bug?

Yes.

> * why was nobody else complaining about it, given that this is an issue
>  for over a year now?

I imagine because not very many people use QEMU for MIPS in
linux-user mode. Often with QEMU things work OK at the point
they were last tested, but new guest features (like this new
syscall) can cause breakage.

-- PMM