Bug #1885
closed
Panic when mounting a jailed devfs with jail devfs.conf entries
0%
Description
In devfs_rules.c, struct "devfs_rule_ioctl" member "rule_type" is tested as an
integer, but is a bitmask. So when both DEVFS_RULE_NAME and DEVFS_RULE_JAIL are
set, the member "name" in newly created devfs_rule is set to NULL.
Later, devfs_rule_checkname() is called, and the kernel will panic in
devfs_resolve_name_path().
See diff for a partial correction (len==0 and invalid name or linkname pointers
need to be handled elsewhere).
By the way, /dev/rc.d/devfs seems to be called too early in the boot process:
it does nothing. But calling it later (manually) works.
Files
Updated by alexh about 14 years ago
Thanks, I've fixed it in dd8bea0af652195d5c6e9d7fb6cea41a29cb7999. Was some
leftover from the time where those fields were not bit fields.
Regarding /etc/rc.d/devfs, it works just fine as far as I can tell. I just tried
it again adding a 'link bpf0 bpFOO' to the defaults/devfs.conf and it worked
fine.
Thanks,
Alex Hornung
Updated by fanch about 14 years ago
Hi Alex,
And thanks for having fixed it.
For the second part, I've added 'link bpf0 bpFOO' to my /etc/devfs.conf and
it worked too. But adding the same line between "jail yes" and "jail no" does
nothing.
/etc/fstab :
devfs /jail/root/dev devfs rw,jail 0 0
Unmounting and remounting this jailed devfs does nothing.
Re-running /etc/rc.d/devfs (or "devfsctl -a -f /etc/devfs.conf") add the
missing link, but only when the jailed devfs is already mounted.
Unmount and remount, and the link is lost. It seems the jail devfs
configuration is kept only when jailed devfs are mounted.
Regards,
Updated by alexh about 14 years ago
I'll take a look at it next week or with a bit of luck tonight or tomorrow. I
had a short glance at the code and didn't find any reason why this would be
happen. It seems that the rules should stick around.
Cheers,
Alex
Updated by alexh about 14 years ago
So far I've only seen that it is not about jails or not (which makes sense) but
rather only about whether the rule was added before mounting or after.
It shouldn't be happening, of course, and I'm not quite sure yet why it happens,
since rules should be checked on each devfs_allocp.
Updated by alexh about 14 years ago
This is really weird. The rules are there when it's mounted, and they are
checked. There was an issue before with rule_check_apply being called too early
but I fixed that in
http://leaf.dragonflybsd.org/~alexh/0001-devfs-Properly-check-rules-on-
allocp.patch
(Now) on mount the rules get checked, they match the name, the action is
taken... but no result can be seen :? I'm quite puzzled right now. Over the next
few days I'll have another look to find out what really is going on.
Updated by alexh about 14 years ago
Thank you very much for your bug report.
Commits 951cde0415725e26217dd3939611aee9f8404b43 and
84dcbb7594edee2f15bdaa91d1ca7de55c6a7d58 fix this issue.
The first commit makes sure that the node is in the topology before checking the
rules which is necessary since the rule checking verifies the parent node.
The second commit fixes mount_devfs which was unconditionally clearing the rules
of a mountpoint after mounting it. According to the man page (and hence my
original intentions) this should only happen when the mountpoint was already
mounted.
Cheers,
Alex Hornung