linux-kernel - Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 27 Jan 2017 12:41:50 +1100 (AEDT)
From:   Finn Thain <fthain@...egraphics.com.au>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
cc:     Michael Schmitz <schmitzmic@...il.com>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Tejun Heo <tj@...nel.org>,
        "linux-ide@...r.kernel.org" <linux-ide@...r.kernel.org>,
        Linux/m68k <linux-m68k@...ts.linux-m68k.org>,
        Linux Kernel Development <linux-kernel@...r.kernel.org>,
        Andreas Schwab <schwab@...ux-m68k.org>
Subject: Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support

On Thu, 26 Jan 2017, Geert Uytterhoeven wrote:

> Hi Finn,
> 
> On Thu, Jan 26, 2017 at 9:47 AM, Finn Thain <fthain@...egraphics.com.au> 
> wrote:
> > The difficulty will be arranging for disabled FDC & IDE interrupt 
> > sources during SCSI DMA, and disabled SCSI & IDE interrupt sources 
> > during FDC DMA. (Not all 5380 interrupts can be disabled; no idea 
> > about the IDE device or WD1772 FDC.)
> 
> IDE interrupts are disabled at the device level. Unfortunately some hard 
> drives (e.g. Western Digital Caviar) didn't honour the ATA disable IRQ 
> bit, so they caused an interrupt deadlock if you probed for them on 
> Amiga with the IDE interrupt enabled. The problem didn't show up on PC 
> because they had no shared interrupts, while on A4000 the IDE interrupt 
> is shared with Zorro Ethernet, which was still enabled.
> 
> That was fixed (in 1995 or 1996?) by disabling the IDE interrupt at the 
> IRQ controller level.
> 

As I undersand it, masking these interrupts at the IRQ controller level 
won't work because these interrupt sources are all logically-OR'd together 
to generate the input that is to be polled during DMA. (And accessing the 
individual device registers is impossible during DMA!)

Anyway, the end result is that both IDE and SCSI have the potential to 
(occasionally) mess up the DMA polling during and FDC or SCSI transfer. 

For SCSI, I believe that we can detect this when it happens (by checking 
the sector count registers in the DMA chip) and return the SCSI command 
with an error result, so that the mid-layer will retry it.

I don't know how it would be handled in the case of an FDC transfer but I 
presume that a similar mechanism is available in the block layer.

-- 

> Gr{oetje,eeting}s,
> 
>                         Geert
>