Return EINVAL for userland CCBs with CAM_UNLOCKED set
ClosedPublic
Actions

Authored by markj on Mar 2 2017, 7:19 PM.

Details

Reviewers

ken
mav

Commits

rS314624: Reject userland CCBs that have CAM_UNLOCKED set.

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.

Diff Detail

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 7866
Build 8006: arc lint + arc unit

Event Timeline

markj updated this revision to Diff 25911.Mar 2 2017, 7:19 PM

markj retitled this revision from to Return EINVAL for userland CCBs with CAM_UNLOCKED set.

markj edited the test plan for this revision. (Show Details)

markj updated this object.

markj added reviewers: mav, ken.Mar 2 2017, 7:21 PM

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

This revision is now accepted and ready to land.Mar 2 2017, 7:27 PM

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.

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.

Closed by commit rS314624: Reject userland CCBs that have CAM_UNLOCKED set. (authored by markj). · Explain WhyMar 3 2017, 8:52 PM

This revision was automatically updated to reflect the committed changes.

-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

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.

Revision Contents
Changeset List

Path

Size

sys/

cam/

scsi/

scsi_pass.c

36 lines

Diff 25911

View Options

Return EINVAL for userland CCBs with CAM_UNLOCKED setClosedPublicActions