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:   Mon, 23 Jan 2017 21:04:50 +1300
From:   Michael Schmitz <schmitzmic@...il.com>
To:     Finn Thain <fthain@...egraphics.com.au>
Cc:     Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Tejun Heo <tj@...nel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.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

Hi Finn,

Am 21.01.2017 um 20:37 schrieb Finn Thain:

>> The MFP interrupt in question is the same as the one used by IDE 
>> (wired-OR of IDE, FDC and SCSI), so we would still have to figure out 
>> where the interrupt originated.
> 
> I thought you said the driver you're testing does not use any interrupt -- 
> I was assuming that only atari_scsi and ataflop drivers share the 
> interupt.

My mistake - I was considering options to allow IDE to share the
interrupt, without the complexities of the old locking scheme.

> 
>> Polling instead of taking the interrupt does not change that fundamental 
>> problem (unless I'm missing something).
>>
> 
> Actually, the fundamental problem you are describing is partly solved. By 
> polling for DMA completion with local irqs disabled, we mostly avoid the 
> need for the stdma.c "lock" because FDC/SCSI/IDE interrupt handlers can 
> never interfere with a FDC/SCSI DMA process that might be underway.

I hadn't considered that. Can PDMA for Falcon SCSI coexist with
interrupt-using DMA for TT SCSI in the same driver (i.e. as runtime
options)? How much overhead and latency would polling for DMA completion
add?

>> Maybe the DMA address register can be used to check for DMA completion 
>> ... it's used to check for residual or lost bytes anyway so that appears 
>> to work. And the FDC driver does use the same strategy to check if 
>> enough track data have been read.
>>
>> Leaves the case where DMA hasn't completed but may have been aborted by 
>> a NCR5380 interrupt. I suppose we can detect that by checking for any 
>> change in the DMA address while repeatedly reading the DMA address 
>> register. No change means the DMA has got stuck. Not exactly pretty but 
>> all I can come up with.
>>
> 
> We don't have to poll any DMA registers (and I don't believe that it is 
> viable to do so). I was talking about polling for end of DMA by polling 
> for the interrupt (as per docs) but with local irqs disabled for the 
> duration of the transfer (which provides exlusive access to the DMA chip).

atari_irq_pending(IRQ_MFP_FSCSI) should show the interrupt pending
condition if you want to poll for it. That's actually given me another
idea to pursue - if we can ensure the IDE interrupt handler is always
run first, and check whether the interrupt is still pending when the
SCSI or floppy interrupt handler runs and DMA has been in progress, we
should be able to avoid calling the respective handlers unnecessarily.

(The output of atari_irq_pending() does not directly reflect the status
of the MFP IRQ inputs - that would require testing bits in
st_mfp.par_dt_reg instead. )

> I don't think the IDE/ATA driver needs to be included. atari_scsi and 
> ataflop would though (if both drivers need DMA transfers).

If we manage to separate interrupt sharing from DMA access locking, IDE
would not need to take part in the locking. I'm assuming that IDE can
cope with spurious interrupts and won't get confused by a SCSI interrupt.

>>> For example, the 5380 SCSI bus reset interrupt is not maskable, which 
>>> could affect FDC transfers. If this terminated the polling for DMA 
>>> completion, the FDC driver then has to access the FDC registers and 
>>> confirm that the transfer was not terminated early.
>>>
>>
>> We'll have to make sure FDC and SCSI don't clash in their DMA and 
>> interrupt use.
>>
> 
> The point I was trying to make above is that stdma lock only gets you so 
> far: if SCSI or FDC generate an interrupt that can't be disabled, it could 
> mess up the interrupt polling (and the interrupt polling is a necessary 
> consequence of IDE operating without stdma lock). This would lead to a 
> short transfer (which could be easily detected).

Point taken - that problem still remains but is already being detected
(though not properly handled IIRC),

> So the chips clash in their interrupt line use (rarely). The drivers need 
> not clash at all.
> 
> Anyway, we seem to be talking past each other somewhat. I suggest we start 
> coding and discuss actual patches ... unless you can convince me that this 
> won't work ...

I think it could work both ways - polling for DMA completion or avoiding
to call the SCSI interrupt handler the interrupt was caused by IDE only.
But it's indeed time to put that to the test.

Cheers,

	Michael