Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753446AbaGGNjT (ORCPT ); Mon, 7 Jul 2014 09:39:19 -0400 Received: from mail-wg0-f41.google.com ([74.125.82.41]:45849 "EHLO mail-wg0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752563AbaGGNjR (ORCPT ); Mon, 7 Jul 2014 09:39:17 -0400 Date: Mon, 7 Jul 2014 15:38:55 +0200 From: Olivier Sobrie To: David Laight Cc: Jan Dumon , "linux-usb@vger.kernel.org" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 2/2] hso: fix deadlock when receiving bursts of data Message-ID: <20140707133855.GA13365@hposo> Reply-To: Olivier Sobrie References: <1404723967-24245-1-git-send-email-olivier@sobrie.be> <1404723967-24245-2-git-send-email-olivier@sobrie.be> <063D6719AE5E284EB5DD2968C1650D6D1726D5E9@AcuExch.aculab.com> <20140707104220.GA31340@hposo> <063D6719AE5E284EB5DD2968C1650D6D1726D772@AcuExch.aculab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1726D772@AcuExch.aculab.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/