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]

Message-ID: <alpine.LNX.2.00.1701261944160.23370@nippy.intranet>
Date:   Thu, 26 Jan 2017 19:47:48 +1100 (AEDT)
From:   Finn Thain <fthain@...egraphics.com.au>
To:     Michael Schmitz <schmitzmic@...il.com>
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

On Mon, 23 Jan 2017, Michael Schmitz wrote:

> 
> Am 21.01.2017 um 20:37 schrieb Finn Thain:
> 
> > 
> > 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)?

Sure, why not?

> How much overhead and latency would polling for DMA completion add?
> 

A polled DMA transfer should be faster than PDMA (i.e. mac_scsi, g_NCR5380 
etc). mac_scsi gets about 0.5 MBps from PDMA with sg_tablesize == 1, and I 
hope that DMA could get twice that (notwithstanding dumb hardware design). 

This would imply CPU overhead that is half of that which mac_scsi incurs. 
That's the best case, but I see no reason to expect worse performance than 
PDMA gets.

> atari_irq_pending(IRQ_MFP_FSCSI) should show the interrupt pending 
> condition if you want to poll for it.

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.)

But if that is impossible, we just have to detect the short DMA that might 
result from an undesired interrupt.

> That's actually given me another idea to pursue - if we can ensure the 
> IDE interrupt handler is always run first,

There are no interrupts from the ATA driver you're testing, right? If you 
would re-introduce them, the whole polled DMA idea is moot.

> 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.
> 

The ATA driver will never have to cope with a spurious interrupt under my 
simplifying assumptions discussed earlier, so the spurious interrupt 
question seems to belong to some alternative approach...

> 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.
> 

... "Both ways"? I don't follow. I don't see how IDE can share the FDC and 
SCSI interrupt line without sharing the stdma.c locking scheme. What is 
the alternative approach (i.e not polled DMA) that you alude to?

--