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
| ||
|
Date: Sat, 8 Aug 2015 10:57:54 +0100 From: Russell King - ARM Linux <linux@....linux.org.uk> To: Sebastian Andrzej Siewior <bigeasy@...utronix.de> Cc: Peter Hurley <peter@...leysoftware.com>, Vinod Koul <vinod.koul@...el.com>, Dan Williams <dan.j.williams@...el.com>, dmaengine@...r.kernel.org, linux-kernel@...r.kernel.org, nsekhar@...com, linux-omap@...r.kernel.org, linux-serial@...r.kernel.org, john.ogness@...utronix.de, Peter Ujfalusi <peter.ujfalusi@...com> Subject: Re: [PATCH 1/3] tty: serial: 8250_omap: do not use RX DMA if pause is not supported On Sat, Aug 08, 2015 at 11:32:05AM +0200, Sebastian Andrzej Siewior wrote: > This might not happen at all. At 115200 I *never* encouraged this. Once > the FIFO is filled with less than RX-trigger size than the UART sends > the time-out interrupt and the DMA *never* completes. Careful with statements like that, they have a habbit of backfiring :) It just needs the right timing - you need a character sequence which has a pause long enough to trigger the timeout, but short enough to get characters in between the UART deciding to report a timeout, and the DMA being terminated. You'll then be in the situation where the UART is receiving characters and using the DMA, but you've been interrupted to handle the RX timeout event. Whether the UART resets the IIR in that situation to indicate something other than a RX timeout, I'm not sure - if it doesn't, then there's a race there (which from your behaviour at faster rates seems likely.) The more loaded the system, the longer an IRQ may take to be serviced (especially if there are interrupt handlers which aren't fast) and the bigger the window is for that to happen. I've seen some long service times with USB with HID in older kernels (milliseconds), but that seems to have been fixed now - longest IRQ handling I'm now seeing is around 500us. Given 115200 baud, the character time is 87us, that's probably more than enough if you get the timing just right. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists