vfs: Add some assertions around various name length limits

[markj]

Summary

There is some code in UFS and devfs that assumes that one can safely
copy a name component into a buffer of size MAXNAMLEN or SPECNAMELEN,
respectively, while the limit on name components is NAME_MAX. All of
these constants are equal, but one may try changing them (I know that
OneFS has done this, for instance). Add a seatbelt to help catch cases
where this isn't done correctly.

Reported by: Alexey Kulaev <[e-mail]>

[kib]

Can you show what do you mean by devfs reference? SPECNAMELEN was only bumped very recently, before 2019 it was 63 bytes.

SPECNAMELEN actually means the whole path from the devfs root to the special node, including all intermediate directories, if any. This is the path stored in struct cdev, and supported e.g. by devfs_fqpn().

[markj]

In D29431#659347, @kib wrote:

Can you show what do you mean by devfs reference? SPECNAMELEN was only bumped very recently, before 2019 it was 63 bytes.

SPECNAMELEN actually means the whole path from the devfs root to the special node, including all intermediate directories, if any. This is the path stored in struct cdev, and supported e.g. by devfs_fqpn().

I was indeed looking at devfs_fqpn(), but I see now that we have sufficient checking there. I was just looking for other examples where we copy a name component into a buffer as in, e.g., ufs_whiteout().

I will just remove the SPECNAMELEN reference, since as you not it is a maximum for the whole path rather than a name component.

[markj]

Limit the check to MAXNAMLEN. I will edit the commit message to remove message
of devfs.