Bartlomiej Zolnierkiewicz wrote: > On Friday 18 July 2008, Alan Cox wrote: >> On Fri, 18 Jul 2008 09:06:12 +0200 >> David Müller <dave.mueller@xxxxxx> wrote: >> >>> The "pata_oldpiix" driver in linux-2.6.26 is calling its "set_dmamode" >>> routine also locally, but under different preconditions as the >>> corresponding call in libata-core.c. This may cause an "out-of-array >>> bounds" access in "oldpiix_set_dmamode". >> This looks wrong adev->dma_mode should never be invalid at this point. >> Are you not confusing dma_mask and dma_mode. Can you provide the >> backtraces of the failing case and the actual chip variant you are using ? >> >> Either way the fix is not in oldpiix if this is appearing as 0xFF but in >> the core code so NAK > > ->dma_mode == 0xff means that DMA is unsupported by a given device > and according to the core code it is a valid ->dma_mode setting. > > This may want to be changed in the future but as the things are right > now David's patch is correct and fixes a real bug. Please UNNAK. Alan, David's patch is correct. 0xff indicates unsupported transfer mode (mainly because 0x00 is valid PIO mode). ->set_pio/dmamode won't see it as libata-core won't call them if unsupported but qc_issue will see it. Can you please unnak? -- tejun -- 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
