Page MenuHomeFreeBSD

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

Authored by trasz on May 21 2019, 12:29 PM.

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
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

trasz created this revision.May 21 2019, 12:29 PM

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

trasz updated this revision to Diff 57633.May 21 2019, 3:11 PM

Move stuff around.

trasz added a comment.May 21 2019, 3:12 PM

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

trasz updated this revision to Diff 57758.May 23 2019, 12:22 PM

Also call stuff for i386.

dchagin accepted this revision.May 23 2019, 6:55 PM
This revision is now accepted and ready to land.May 23 2019, 6:55 PM
tijl added a comment.May 24 2019, 8:21 AM

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?

trasz added a comment.May 25 2019, 7:40 PM

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

emaste added a subscriber: emaste.Thu, Oct 24, 2:30 PM

I have no objection

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 a subscriber: kib.Thu, Oct 24, 2:53 PM
kib added inline comments.
sys/compat/linux/linux.c
538 ↗(On Diff #57758)

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

540 ↗(On Diff #57758)

\n at the EoL

emaste added inline comments.Thu, Oct 24, 3:59 PM
sys/compat/linux/linux.c
538 ↗(On Diff #57758)

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

trasz updated this revision to Diff 63735.Mon, Oct 28, 9:16 PM

Apply comments from kib@ and emaste@.

This revision now requires review to proceed.Mon, Oct 28, 9:16 PM
trasz marked 3 inline comments as done.Mon, Oct 28, 9:19 PM
kib added inline comments.Tue, Oct 29, 8:07 AM
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.

kib added a comment.Tue, Oct 29, 3:05 PM

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.

trasz added a comment.Wed, Oct 30, 9:39 PM
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.

tijl added a comment.Thu, Oct 31, 9:32 AM

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.Wed, Nov 6, 8:53 PM
This revision was automatically updated to reflect the committed changes.