On 2/28/08, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote: > > For most of unsupported commands, it will be aborted by drive. > > However, for some unsupported commands, it may not. I suspect these > > bad commands are the new ones in ATA8 issued to some drives with old > > firmware. For instance, can you try command 0x5E (Trusted Send PIO > > data out) with sector count set to 1 and see what happens? > > > Well the kernel as of 2.6.24 defaults to blocking treacherous computing > commands 8) > Whether a command is "treacherous" really depends. For instance, command 0x5E is treacherous for PATA drives not supporting it but is good on security drives supporting it. In a perfect world, host would know what exact command to issue. But in reality, Identify Device may not show every feature set supported, which is the scenario I run into. I have to use the "try and see" approach on some drives where I tripped on the IRQ disabling problem. > > > The blame is probably on drives which should have aborted these > > commands. But the reality is that libata will handle variety of drives > > including the ones with old firmware. So the question here is whether > > libata PATA code can be more fault tolerate. It seems the weakest link > > is on PATA PIO since I have not been able to reproduce the IRQ > > disabling problem on DMA operations. > > > If you send crap to a drive you will get junk as a result. Only the > superuser can do this so that behaviour is fine. The superuser can also > crash the machine a million other ways. End users cannot send arbitary > commands to the drive. > > Ditto they may know that an "unsupported" command for their ATA version > is actually a vendor private command for the specific drive they have. > I agree with you and Jeff that we can not prevent superuser from corrupting the system. What I want to understand more is if there's room to harden PATA PIO code in libata. For instance, when I set wrong data transfer direction in DMA read, I got command timeout, which to me is a more graceful failure than IRQ disabling. I'm not sure if the difference of failure mode between PIO and DMA is caused by controller or software. If the cause is software, it would be nice to close the gap. Thanks, Fajun -- 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
