The kernel should not be validating -trusted- userland inputs. Root is allowed to scrag the disk, violate limits, and/or crash his own machine.
A simple example is requiring userland, when submitting ATA taskfiles via an ioctl, to specify the data phase (pio read, dma write, no-data, etc.). If the data phase is specified incorrectly, you kill the OS driver's ATA host wwtate machine, and the results are very unpredictable. Since this is a trusted operation, requiring CAP_RAW_IO, it's up to userland to get the required details right (just like following a spec).
That's unfortunate for those using ATA. A command submitted from userland
Required, since one cannot know the data phase of vendor-specific commands.
to the SCSI drivers I've written that causes a protocol violation will be detected, result in appropriate recovery, and a nice diagnostic that can be used to diagnose the problem. Part of this is because I cannot know if the protocol violation stems from a target defect, the input from the user or, for that matter, from the kernel. The main reason is for robustness
Well, * the target is not _issuing_ commands, * any user issuing incorrect commands/cdbs is not your bug, * and kernel code issuing incorrect cmands/cdbs isn't your bug either
Particularly, checking whether the kernel is doing something wrong, or wrong, just wastes cycles. That's not a scalable way to code... if every driver and Linux subsystem did that, things would be unbearable slow.
Jeff
- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
