unionfs: workaround underlying FS failing to respect cn_namelen

[jah]

Summary

unionfs_mkshadowdir() may be invoked on a non-leaf pathname component
during lookup, in which case the NUL terminator of the pathname buffer
will be well beyond the end of the current component. cn_namelen in
this case will still (correctly) indicate the length of only the
current component, but ZFS in particular does not currently respect
cn_namelen, leading to the creation on inacessible files with slashes
in their names. Work around this behavior by temporarily NUL-
terminating the current pathname component for the call to VOP_MKDIR().

PR: 275871
Reported by: Karlo Miličević <[e-mail]>
Tested by: Karlo Miličević <[e-mail]>
MFC after: 2 weeks

[jah]

Also filed https://github.com/openzfs/zfs/issues/15705, as I think that would benefit OpenZFS as well.

[jah]

Putting this on hold, as I'm evaluating a less-hacky approach.

[jah]

Sadly my attempt at something less hacky didn't really improve things.

[jah]

Update comment

[olce]

OK as a workaround. Hopefully, we'll get OpenZFS fixed soon. If you don't plan to, I may try to submit a patch upstream, since it seems no one has proposed any change in https://github.com/openzfs/zfs/issues/15705.

[jah]

In D43818#999955, @olce wrote:

OK as a workaround. Hopefully, we'll get OpenZFS fixed soon. If you don't plan to, I may try to submit a patch upstream, since it seems no one has proposed any change in https://github.com/openzfs/zfs/issues/15705.

Actually I've been thinking of doing exactly that, although it depends on how much time I get away from $work over the next few weeks. But that does remind me: speaking of things we'd both like to see, what do you want to do about https://reviews.freebsd.org/D40850 and the constellation of associated changes? I just gave that review a kick.

[olce]

In D43818#1000015, @jah wrote:

Actually I've been thinking of doing exactly that, although it depends on how much time I get away from $work over the next few weeks.

I just wanted to make sure that someone was going to push a solution upstream so that we don't stay with such workarounds for ages. So, great (and I don't need to intervene).

But that does remind me: speaking of things we'd both like to see, what do you want to do about https://reviews.freebsd.org/D40850 and the constellation of associated changes? I just gave that review a kick.

Answered there.

Thanks.