netdev - Re: [PATCH 2/2] hso: fix deadlock when receiving bursts of data

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, 7 Jul 2014 15:38:55 +0200
From:	Olivier Sobrie <olivier@...rie.be>
To:	David Laight <David.Laight@...LAB.COM>
Cc:	Jan Dumon <j.dumon@...ion.com>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] hso: fix deadlock when receiving bursts of data

On Mon, Jul 07, 2014 at 12:55:44PM +0000, David Laight wrote:
> From: Olivier Sobrie 
> > Hi David,
> > 
> > On Mon, Jul 07, 2014 at 09:13:53AM +0000, David Laight wrote:
> > > From: Olivier Sobrie
> > > > When the module sends bursts of data, sometimes a deadlock happens in
> > > > the hso driver when the tty buffer doesn't get the chance to be flushed
> > > > quickly enough.
> > > >
> > > > To avoid this, first, we remove the endless while loop in
> > > > put_rx_bufdata() which is the root cause of the deadlock.
> > > > Secondly, when there is no room anymore in the tty buffer, we set up a
> > > > timer of 100 msecs to give a chance to the upper layer to flush the tty
> > > > buffer and make room for new data.
> > >
> > > What is the timer for?
> > > You need to get the sending code woken up by the urb completion.
> > 
> > In put_rxbuf_data() (which can be called under irq disabled),
> > tty_flip_buffer_push() is called and schedules a push of the tty buffer.
> > When the buffer is full, I give some time to the above layer in order
> > to flush it.
> > The timer is used to recall put_rxbuf_data_and_resubmit_bulk_urb()
> > later in order to read the remaining data stored in
> > "urb->transfer_buffer" and then to resubmit the urb to receive more data
> > from the gsm module.
> > I don't understand what you mean by "getting the sending code woken up".
> > Calling tty_port_tty_wakeup()?? We are in the receive path...
> 
> Sorry, it isn't at all clear from the general description whether you
> are referring to the transmit or receive path.
> 
> 'flush' can mean all sorts of things ...
> 
> In either case a 100ms delay to data doesn't seem right at all.

An option to avoid the delay, is to replace the timer by a workqueue
and to schedule work in put_rxbuf_data_and_resubmit_bulk_urb()
when put_rxbuf_data() returns something greater than 0.
If you have better ideas, let me know.

Thanks,

-- 
Olivier
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html