Page MenuHomeFreeBSD

Make linux(4) create /dev/shm.
ClosedPublic

Authored by trasz on May 21 2019, 12:29 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Apr 17, 7:28 PM
Unknown Object (File)
Wed, Apr 17, 7:05 PM
Unknown Object (File)
Feb 28 2024, 5:32 PM
Unknown Object (File)
Feb 26 2024, 2:46 AM
Unknown Object (File)
Feb 12 2024, 3:32 AM
Unknown Object (File)
Jan 31 2024, 5:05 PM
Unknown Object (File)
Dec 23 2023, 3:53 AM
Unknown Object (File)
Dec 7 2023, 4:03 AM
Subscribers

Details

Summary

Make linux(4) create /dev/shm. Linux applications often expect
a tmpfs to be mounted there, and because they like to verify it's
actually a mountpoint, a symlink won't do.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 24360
Build 23182: arc lint + arc unit

Event Timeline

linux_common is not used in i386

I would prefer put common code to the compat/linux/linux.c and put linux_dev_shm_destroy/linux_dev_shm_create decl to the linux.h

linux_common is not used in i386

What do you mean? Or, ask another way, where should I call it from to make it work for i386?

linux_common is not used in i386

What do you mean? Or, ask another way, where should I call it from to make it work for i386?

in linux_elf_modevent() in i386/linux/linux_sysvec.c

Also call stuff for i386.

This revision is now accepted and ready to land.May 23 2019, 6:55 PM

Please also bump OSVERSION so the creation of /compat/linux/dev/shm can be made conditional in emulators/linux_base-c[67]

as far as I understand we can create /dev/fd same way?

This is a bit hacky, even for my standards, so I've come up with this as an alternative: https://reviews.freebsd.org/D20411.

I have no objection

Further, I am not familiar enough with the devfs machinery to effectively review (previously I would not have suspected make_dev as the way to create a devfs directory), but I support the intent / effect of this change.

kib added inline comments.
sys/compat/linux/linux.c
538

I suggest "shm/.placeholder" or "shm/.dummy". Might also make sense to change mode to 0.

540

\n at the EoL

sys/compat/linux/linux.c
538

Ah I see now. What about shm/.mountpoint in that case?

Apply comments from kib@ and emaste@.

This revision now requires review to proceed.Oct 28 2019, 9:16 PM
sys/i386/linux/linux_sysvec.c
1009 ↗(On Diff #63735)

So if both 64 and 32bit linix.ko are loaded, one of them would print an error. If another one is unloaded before the module that printed an error, the node is destroyed. Which raises the next question, did you actually tried it ? I wonder what happens to the system when devfs directory goes away while being used as mount point (I have no idea and curious).

Well, they don't print an error. I'm not quite sure why, but I've tested both scenarios - kldloading linux.ko and then linux64.ko, and the other way around; same with kldunloading.

As for what happens when the devfs goes away - you're left with a mount point that's not accessible with full path. You can unmount it just fine, though. And we depend on that behaviour for reroot.

Well, they don't print an error. I'm not quite sure why, but I've tested both scenarios - kldloading linux.ko and then linux64.ko, and the other way around; same with kldunloading.

Then there must be a bug either in the testing methodology or in the code, right ? Ensure that the make_dev line is executed in both cases.

In D20333#484720, @kib wrote:

Well, they don't print an error. I'm not quite sure why, but I've tested both scenarios - kldloading linux.ko and then linux64.ko, and the other way around; same with kldunloading.

Then there must be a bug either in the testing methodology or in the code, right ? Ensure that the make_dev line is executed in both cases.

I'm not sure how it works, but there seems to be some magic that makes sure it gets called in the right circumstances. Existing code already depends on it - eg linux_osd_jail_register() is called in the exact same way.

On amd64 the code is in linux_common.ko, not linux.ko and linux64.ko. So the directory is created/destroyed when linux_common is loaded/unloaded.

This revision was not accepted when it landed; it landed in state Needs Review.Nov 6 2019, 8:53 PM
This revision was automatically updated to reflect the committed changes.