-----Original Message----- From: Jiri Slaby [mailto:jirisl...@gmail.com] On Behalf Of Jiri Slaby Sent: Friday, March 01, 2013 5:10 PM To: Bi, Chao Cc: Greg Kroah-Hartman; linux-kernel@vger.kernel.org; ML netdev; Pillet, VincentX Subject: Re: [PATCH] n_gsm: Add Mutex to avoid race when net destroy
On 03/01/2013 09:51 AM, channing wrote: >> It should stop the queue and schedule a workqueue to lock the mutex, >> unregister the hetdev and reset dlci->net. (Or maybe just call >> muxnet_put with the lock held.) > > Thanks, Jiri, you're right, I didn't notice that in validation because > DEBUG_ATOMIC_SLEEP is not enabled in my platform :( Now I'm trying to > work out the workqueue solution, when it finished I'll re-submit for > review. What do you mean by "call muxnet_put with lock held"? do you > mean to use spin lock instead of mutex? No, I mean, in the newly added scheduled work, to lock the mutex and simply call muxnet_put. That should fix it, right? [chao] Yes, that's to only move muxnet_put to scheduled work with mutex protected, and the rest of gsm_mux_net_start_xmit() Is kept unchanged, and they are not in mutex lock. It could avoid race of net_free(). I'm not sure if it's safe enough, I mean if dlci->net is released before STATS(net) in gsm_mux_net_start_xmit(), will STATS(net) access unreliable data? -- js suse labs
