Nate Lawson wrote: > Søren Schmidt wrote: > >> Nate Lawson wrote: >> >>> I took a quick look at this ATA panic. The exact same one occurs for >>> Ceri. A quick dissassemble shows that the testb is the check for the >>> DMA flag at the very end of ata_generic_transaction(). The bug >>> appears to be that this may be a PIO request (since the DMA check is >>> outside the switch() statement). The fix is to make sure it's a DMA >>> request before dereferencing an element of the DMA struct. Try the >>> attached patch. >> >> >> No, the fix is to make sure there is a valid ch->dma pointer, the >> below is the correct fix. >> >> --- ata-lowlevel.c 5 Aug 2004 21:13:41 -0000 1.41 >> +++ ata-lowlevel.c 6 Aug 2004 22:31:16 -0000 >> _at__at_ -295,7 +295,7 _at__at_ >> } >> >> /* request finish here */ >> - if (ch->dma->flags & ATA_DMA_LOADED) >> + if (ch->dma && ch->dma->flags & ATA_DMA_LOADED) >> ch->dma->unload(ch); >> return ATA_OP_FINISHED; >> } > > > Thanks. Under what circumstances is a request generated with ATA_R_DMA > set in the flags but where the channel's dma struct has not been allocated? It should not happen on normal and correct use, but since drivers are responsible for setting the flags, there is potential for error situations, and we want to catch those as well instead of panic'ing. Better safe than sorry as they say... -SørenReceived on Sat Aug 07 2004 - 09:55:43 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:05 UTC