Bug 240874
| Summary: | Linuxulator: unimplemented Linux syscalls: inotify_init{,1} | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Bjoern A. Zeeb <bz> |
| Component: | kern | Assignee: | freebsd-emulation (Nobody) <emulation> |
| Status: | Open --- | ||
| Severity: | Affects Only Me | CC: | arrowd, damjan.jov, dchagin, emaste, fernape, freebsd, kevans, osa, vedran |
| Priority: | --- | ||
| Version: | CURRENT | ||
| Hardware: | amd64 | ||
| OS: | Any | ||
| Bug Depends on: | |||
| Bug Blocks: | 247219 | ||
|
Description
Bjoern A. Zeeb
2019-09-27 15:01:31 UTC
(In reply to Bjoern A. Zeeb from comment #0) Heh, we just implemented memfd_create in terms of shm_open2. I'll take a look at implementing the Linux syscall version- it should be fairly simple now that we implement everything it needs. A commit references this bug: Author: kevans Date: Mon Jun 29 03:09:16 UTC 2020 New revision: 362769 URL: https://svnweb.freebsd.org/changeset/base/362769 Log: linuxolator: implement memfd_create syscall This effectively mirrors our libc implementation, but with minor fudging -- name needs to be copied in from userspace, so we just copy it straight into stack-allocated memfd_name into the correct position rather than allocating memory that needs to be cleaned up. The sealing-related fcntl(2) commands, F_GET_SEALS and F_ADD_SEALS, have also been implemented now that we support them. Note that this implementation is still not quite at feature parity w.r.t. the actual Linux version; some caveats, from my foggy memory: - Need to implement SHM_GROW_ON_WRITE, default for memfd (in progress) - LTP wants the memfd name exposed to fdescfs - Linux allows open() of an fdescfs fd with O_TRUNC to truncate after dup. (?) Interested parties can install and run LTP from ports (devel/linux-ltp) to confirm any fixes. PR: 240874 Reviewed by: kib, trasz Differential Revision: https://reviews.freebsd.org/D21845 Changes: head/sys/amd64/linux/linux_dummy.c head/sys/amd64/linux32/linux32_dummy.c head/sys/arm64/linux/linux_dummy.c head/sys/compat/linux/linux.c head/sys/compat/linux/linux.h head/sys/compat/linux/linux_file.c head/sys/compat/linux/linux_file.h head/sys/i386/linux/linux_dummy.c I'm facing the problem as Bjoern. I have a closed source Linux binary that calls inotify_* functions. We do have libinotify-kqueue - a usermode library that implements inotify interface in terms of kevent/kqueue one. However, there seem to be no way to easily hook it into Linuxulator, because inotify_* are syscalls on Linux. (In reply to Gleb Popov from comment #3) (In reply to Gleb Popov from comment #3) hmm, I'll take a look at the libinotify-kqueue library code, I suspected that it was not so easy to implement inotify* on top of the kqueue/kevent, however someone did it. Could you please check 228115? (In reply to Gleb Popov from comment #3) Hi Gleb, Did you try with the instructions at https://github.com/libinotify-kqueue/libinotify-kqueue under "Building under linuxolator (FreeBSD 13+)"? (In reply to Fernando Apesteguía from comment #5) Oh, I didn't think the preloading trick will work for these functions. Thanks for the hint, I'll keep this in mind. (In reply to Gleb Popov from comment #6) Are you saying your app statically linked to libc, or makes direct inotify_* system calls without going through libc? (In reply to Damjan Jovanovic from comment #7) Not sure about direct syscalls, but it is certainly linked to libc dynamically. I believe preloading is a way to go. (In reply to Fernando Apesteguía from comment #5) I see that libinotify is already Ports and available as a package. Would it be possible to also have something like linux-c7-libinotify so it is more easily installable? |