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:	Tue, 04 Aug 2015 13:58:44 +0200
From:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:	Peter Hurley <peter@...leysoftware.com>
CC:	John Ogness <john.ogness@...utronix.de>,
	linux-kernel@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Tony Lindgren <tony@...mide.com>, linux-omap@...r.kernel.org,
	nsekhar@...com, nm@...com, linux-serial@...r.kernel.org,
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
Subject: Re: [PATCH 3/3] serial: 8250: omap: restore registers on shutdown

On 08/03/2015 09:32 PM, Peter Hurley wrote:

>> You mean a function in 8250-dma API which does what I did just here
>> with the wait_event() and the wake_up in the callback? That way I could
>> move the termios_wait into the dma struct instead of keeping in the
>> omap specific part. I am also not sure if OMAP is the only one that may
>> hang here or the other people just didn't notice it yet.
> 
> Exactly; and we need to fix DMA wrt x_char anyway.
> 
> Going back to the dmaengine api, I think something like this might work
> (as a first approximation):
> 
> 	dma_sync_wait(dma->txchan, dma->tx_cookie);
> 	dmaengine_pause(dma->txchan);
> 
> 	/* remainder of set_termios */
> 
> 	dmaengine_resume(dma->txchan);
> 
> We could require 8250 core dma to support pause/resume.

I would prefer the waitqueue approach.
You can't do this while holding the port lock. The lock is taken with
irqs off so may not see the transfer completing.
Why do you pause the channel? It may not work without an active
descriptor and a start without "resume" should work. Also you must
ensure that DMA's complete callback does not start another transfer if
there is something queued up (that is why I had the tx_running dance).
I am not sure if a transfer that is active and then paused will not
trigger the hang bug if we change the termios in between.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ