Jeff Garzik wrote: > Brian King wrote: >> @@ -4573,7 +4567,7 @@ static void ata_host_init(struct ata_por >> host->max_lun = 1; >> host->max_channel = 1; >> host->unique_id = ata_unique_id++; >> - host->max_cmd_len = 12; >> + host->max_cmd_len = ATAPI_CDB_LEN; >> > > > Have you audited the code paths to ensure that a CDB of length 15 is > _NEVER_ sent, before ata_scsi_dev_config() is called? Yes. I don't see any problems. slave_configure is called before any upper layer drivers are attached and before anything shows up in sysfs, so that limits us to libata initiated commands issued as part of the port probe process and scsi core initiated commands issued as part of device scanning. All the commands libata issues as part of the port probe process are issued through ata_exec_internal, which does not go through scsi core, so there is no protection there today. scsi core only issues inquiry and report luns commands as part of scanning, both of which are not an issue. > The current code intentionally uses the minimum -- 12 -- and then raises > it if both device and host are capable of more. Actually, the current code does not allow for an ata host to limit the max CDB length. ata_host_init initializes host->max_cmd_len to 12, then ata_dev_configure zeroes out ap->host->max_cmd_len, then sets it to the maximum CDB length supported by any of the devices on that host. The obvious followup patch to this one would be to change all the users of libata to have them initialize scsi_host_template->max_cmd_len and remove that code from ata_host_init. -- Brian King eServer Storage I/O IBM Linux Technology Center - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
