Re: [PATCH] thinkpad-acpi: fix potential suspend blocking issue

[Henrique de Moraes Holschuh <hmh@hmh.eng.br>]

On Wed, 06 Mar 2013, Oleg Nesterov wrote:
> On 03/05, Henrique de Moraes Holschuh wrote:
> > On Tue, 05 Mar 2013, Mandeep Singh Baines wrote:
> > > This mutex seems wrong. Its held the entire time the kthread is
> > > running. I think its used to synchronize on the exit of the kthread. A
> > > completion would more appropriate in that case.
> >
> > From the top of the driver source:
> >
> > /* Acquired while the poller kthread is running, use to sync start/stop */
> > static struct mutex hotkey_thread_mutex;
> 
> I simply can't understand what this "sync start/stop" means...
> 
> Ignoring hotkey_kthread(), the only user is
> 
> 	static void hotkey_poll_stop_sync(void)
> 	{
> 		if (tpacpi_hotkey_task) {
> 			kthread_stop(tpacpi_hotkey_task);
> 			tpacpi_hotkey_task = NULL;
> 			mutex_lock(&hotkey_thread_mutex);
> 			/* at this point, the thread did exit */
> 			mutex_unlock(&hotkey_thread_mutex);
> 		}
> 	}
> 
> And I simply do not understand the comment. This thread has already exited
> when kthread_stop() returns (OK, it can be running do_exit() paths but this
> doesn't matter). So this mutex_lock() buys nothing afaics.

It was added due to an oops, waaaaay back then.  If it is not needed
anymore, and there is zero chance of the kthread still being active when
hotkey_poll_stop_sync() ends, hotkey_thread_mutex can be simply removed.

Note that hotkey_thread_data_mutex is still required.

> As for serializing with hotkey_poll_setup/etc, looks like this code relies
> on hotkey_mutex.
> 
> So I think hotkey_thread_mutex can be simply removed?

Looks like it, if the current semanthics of ktread_stop() are syncronous.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh