Return EINVAL for userland CCBs with CAM_UNLOCKED set

[markj]

Summary

Userland cannot correctly set CAM_UNLOCKED; it is internal to the
implementation and not defined in the CAM spec. Thus, return EINVAL if
it's set in the CAMIOCOMMAND or CAMIOQUEUE argument.

I also noticed that some error paths in the CAMIOQUEUE handler don't
free the request or relock the periph, so fix that too.

[mav]

It looks fine, except this flag is probably not the only one that should be banned.

[markj]

In D9869#203728, @mav wrote:

It looks fine, except this flag is probably not the only one that should be banned.

I looked for others, but didn't see any obvious candidates. Many CCB flags appear to have no handling at all in the kernel, and most of the rest appear to be used in some way by camcontrol.

[ken]

I agree with mav. This looks good, there might be other flags that we should ban as well if they come in from user land. But this is a good start.

[markmi_dsl-only.net]

-r314624 prevented a PowerMac G5 so-called "Quad Core" from competing
its boot (of -r314687): CAM status: Command timeout's. Reverting the two
files fixed it. See, e.g.,

https://lists.freebsd.org/pipermail/svn-src-head/2017-March/097981.html

[markj]

In D9869#204621, @markmi_dsl-only.net wrote:

-r314624 prevented a PowerMac G5 so-called "Quad Core" from competing
its boot (of -r314687): CAM status: Command timeout's. Reverting the two
files fixed it. See, e.g.,

https://lists.freebsd.org/pipermail/svn-src-head/2017-March/097981.html

This turned out to be apparently unrelated to the commit.