On Sun, Feb 10, 2008 at 02:38:46PM +0100, Bartlomiej Zolnierkiewicz wrote: > The OOPS is most likely (again) my fault - I was rushing out to push out > the fix and memset() line didn't get converted. The new patch works fine for me. > I prepared the new patch, documented it and started looking into SCSI > build breakage... and I no longer feel comfortable with the hack :( > > It seems that fixing IDE properly will be easier than auditing the whole > SCSI for all the weird assumptions on rq->cmd[] size (James?) so I'm back > to the code, in the meantime here's the updated patch: Yeah, this is quite nasty. I'll attach the patch below which just rejects a command in scsi_setup_blk_pc_cmnd if it's too large for the scsi_cmnd cmnd array. This is probably enough but I haven't audited all of the scsi code yet. But as James said this is too much of a memory vastage to put it into the tree. Long-term the Panasas folks have looked into killing the scsi_cmnd.cmnd filed entirely and make the struct request.cmd field dynamically sized which would solve your problem, but probably won't be ready for 2.6.25. Index: linux-2.6/drivers/scsi/scsi_lib.c =================================================================== --- linux-2.6.orig/drivers/scsi/scsi_lib.c 2008-02-10 07:49:50.000000000 +0100 +++ linux-2.6/drivers/scsi/scsi_lib.c 2008-02-10 15:19:42.000000000 +0100 @@ -1129,7 +1129,12 @@ int scsi_setup_blk_pc_cmnd(struct scsi_d req->buffer = NULL; } - BUILD_BUG_ON(sizeof(req->cmd) > sizeof(cmd->cmnd)); + if (req->cmd_len > sizeof(cmd->cmnd)) { + scsi_release_buffers(cmd); + scsi_put_command(cmd); + return BLKPREP_KILL; + } + memcpy(cmd->cmnd, req->cmd, sizeof(cmd->cmnd)); cmd->cmd_len = req->cmd_len; if (!req->data_len) - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html