Page MenuHomeFreeBSD

linuxolator: implement memfd_create syscall
Needs ReviewPublic

Authored by kevans on Sep 30 2019, 2:07 AM.



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.

Suggestions on reducing the duplication would be nice... all of these constants match, and I would expect that Linux will never break that.

Diff Detail

rS FreeBSD src repository
Lint Skipped
Unit Tests Skipped
Build Status
Buildable 26800

Event Timeline

kevans created this revision.Sep 30 2019, 2:07 AM
kib added a comment.Sep 30 2019, 2:21 PM

I dislike the reliance on equal FreeBSD and Linux flags values. Please use LINUX_MFD_XXX constants in linuxolator. You may add _Static_asserts that they are equal and avoid translating the current flags, but I do not think that it is sustainable in long run.

kevans updated this revision to Diff 62772.EditedSep 30 2019, 9:46 PM

I waffled on things like this, and I think I ended up with a solution like this...

Generalize translation of 32-bit bit fields for Linux <-> BSD. Push these into a new structure that can describe a wide array of situations (ranging from these are mutually exclusive O_ACCMODE fields to more simplistic single-bit values). This approach was inspired by similar stuff that we (theoretically) do in qemu, but that we don't do in practice.

This gives us a different way to express these mappings that's perhaps a little less error-prone, as the same data is used in both directions of the translation. It also lets us de-clutter some sections of translations that, to me, distract from the implementation.

Some of the follow-up to move other stuff to this can be found in this diff: -- there are likely other spots that could see some benefit.

(Edit to add)
Note that this patch is a WIP... It doesn't yet observe the proper semantics for, e.g., enumerated values rather than actual bit masks.

kib added a comment.Oct 1 2019, 4:53 PM

I think you need to provide some explanation how your l/b bits functions are supposed to work.


Why do you need U suffix ?


I think '34' above actually needs the U suffix since the shift moves into the sign bit, you get undef behavior otherwise.

kevans added inline comments.Oct 1 2019, 4:57 PM

Admittedly, I took the definitions as-is from the Linux headers for this where they are equally as pointless.


Whoops, will fix.