Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

O_TMPFILE test failing #217

Closed
cazfi opened this issue Oct 12, 2023 · 10 comments · Fixed by #219
Closed

O_TMPFILE test failing #217

cazfi opened this issue Oct 12, 2023 · 10 comments · Fixed by #219

Comments

@cazfi
Copy link

cazfi commented Oct 12, 2023

I have O_TMPFILE test failing. More precisely, it's the "errno == 0" assert that fails. Likely the problem is that you don't have as strict checks for whether it's even supposed to work as actual tests are:

/* open() with O_TMPFILE; this hasn't been supported in Linux for very long
 * (>= 3.11), so check that it works in the testbed only if it also works
 * in the "normal" file system. */
fd = g_open("/tmp", O_TMPFILE|O_RDWR, 0644);
if (fd >= 0) {
    close(fd);
    errno = 0;
    fd = g_open("/dev", O_TMPFILE|O_RDWR, 0644);
    g_assert_cmpint(errno, ==, 0);
    g_assert_cmpint(fd, >, 0);
    g_assert_cmpint(write(fd, "hello", 5), ==, 5);
    close(fd);
} else {
    g_printf("(Skipping O_TMPFILE test, not supported on this kernel: %m) ");
}
@martinpitt
Copy link
Owner

So you are saying yuo have a system where this fails with ENOSYS? But why does the first g_open() succeed then? That's precisely what the else branch is meant to do.. How does it fail exactly? the g_assert_cmpint should print the actual value.

@cazfi
Copy link
Author

cazfi commented Oct 12, 2023

EOPNOTSUPP, I think:

assertion failed (errno == 0): (95 == 0)

@martinpitt
Copy link
Owner

OK, so your kernel supports O_TMPFILE in general (in /tmp/, and the mocked /dev usually lives in /tmp/. So I can't make sense of this yet...

@benzea
Copy link
Collaborator

benzea commented Oct 12, 2023

Or it means that the redirection is not working and it opened the real /dev? e.g. LD_PRELOAD not having kicked in?

@martinpitt
Copy link
Owner

Possibly, but I'd expect an EPERM/EACCESS then, as the user is hopefully not allowed to write into /dev

❱❱❱ strace -e openat touch /etc/foo
openat(AT_FDCWD, "/etc/foo", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = -1 EACCES (Permission denied)

@martinpitt
Copy link
Owner

Either way, @cazfi please let me know some details here --- OS, build environment, how you built, and please run the whole thing through strace -fvvs1024 -o /tmp/trace. Thanks!

@cazfi
Copy link
Author

cazfi commented Oct 16, 2023

the mocked /dev usually lives in /tmp/.

It might be that "usually" is the key word here. This is a NixOS build, so things might live in unusual places.

@martinpitt
Copy link
Owner

Ah, NixOS! Do you have $TMPDIR or $TEMPDIR set in that environment? Could you try a build with replacing the "/tmp" with g_get_tmp_dir()?

@cazfi
Copy link
Author

cazfi commented Nov 21, 2023

I don't have that particular setup any more, and on other kind of setups I have everything works.

@martinpitt
Copy link
Owner

OK, thanks for reporting back. I'll commit the g_get_tmpdir() thing, can't hurt.

martinpitt added a commit that referenced this issue Nov 21, 2023
This ensures that the emulated /dev (which is created in
`g_get_tmp_dir()` via `DirUtils.make_tmp()` and the feature check are
done in the same directory. If `$TMPDIR` is set, that may not be the
case.

Fixes #217
martinpitt added a commit that referenced this issue Nov 21, 2023
This ensures that the emulated /dev (which is created in
`g_get_tmp_dir()` via `DirUtils.make_tmp()` and the feature check are
done in the same directory. If `$TMPDIR` is set, that may not be the
case.

Fixes #217
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants