[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <375E373B4157DC49B89CEAE588F836F50FE455C5@SHSMSX102.ccr.corp.intel.com>
Date: Thu, 20 Dec 2012 12:13:07 +0000
From: "Xiao, Jin" <jin.xiao@...el.com>
To: 'Alan Cox' <alan@...rguk.ukuu.org.uk>
CC: "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"mingo@...e.hu" <mingo@...e.hu>,
"a.p.zijlstra@...llo.nl" <a.p.zijlstra@...llo.nl>,
"rusty@...tcorp.com.au" <rusty@...tcorp.com.au>,
"Douglas, William" <william.douglas@...el.com>,
"sboyd@...eaurora.org" <sboyd@...eaurora.org>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"jslaby@...e.cz" <jslaby@...e.cz>,
"Pillet, VincentX" <vincentx.pillet@...el.com>
Subject: RE: [PATCH] n_gsm.c: add tx_lock in gsm_send
Alan,
Thanks. But the comment makes me confused. As we see, gsm->output is called by gsm_data_kick too, and it's in the tx_lock...
Best regards,
Jin Xiao
> From: xiaojin <jin.xiao@...el.com>
> Date: Wed, 19 Dec 2012 11:53:43 +0800
> Subject: [PATCH] n_gsm.c: add tx_lock in gsm_send
>
> All the call to gsm->output should be in the tx_lock, that could avoid
> potential race from MUX level. But we have no tx_lock in gsm_send.
>
> This patch is to add tx_lock in gsm_send.
gsm->output calls the transmit method of the underlying tty driver. We
can't do that with interrupts off as some drivers expect to be able to sleep in their output paths.
Alan
--
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