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
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
