[PATCH] input: tsc2005: fix locking issue

Commit 0b950d3 (Input: tsc2005 - add open/close) introduced a
locking issue with the ESD watchdog: __tsc2005_disable() is calling
cancel_delayed_work_sync() with mutex held, and the work also needs the
same mutex.

Fix the problem by using cancel_delayed_work() on disable. If
the ESD work was running it will check if the device is closed
or suspended, and in that case it will do nothing and skip
re-arming. cancel_delayed_work_sync() is still needed when the module
is removed.

Signed-off-by: Aaro Koskinen <redacted>
---
 drivers/input/touchscreen/tsc2005.c |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/drivers/input/touchscreen/tsc2005.c b/drivers/input/touchscreen/tsc2005.c
index 8742061..3a15587 100644
--- a/drivers/input/touchscreen/tsc2005.c
+++ b/drivers/input/touchscreen/tsc2005.c

@@ -345,7 +345,7 @@ static void __tsc2005_disable(struct tsc2005 *ts)
 	disable_irq(ts->spi->irq);
 	del_timer_sync(&ts->penup_timer);
 
-	cancel_delayed_work_sync(&ts->esd_work);
+	cancel_delayed_work(&ts->esd_work);
 
 	enable_irq(ts->spi->irq);
 }

@@ -479,6 +479,12 @@ static void tsc2005_esd_work(struct work_struct *work)
 
 	mutex_lock(&ts->mutex);
 
+	/* The device has been just closed or suspended. */
+	if (!ts->opened || ts->suspended) {
+		mutex_unlock(&ts->mutex);
+		return;
+	}
+
 	if (time_is_after_jiffies(ts->last_valid_interrupt +
 				  msecs_to_jiffies(ts->esd_timeout)))
 		goto out;

@@ -685,6 +691,7 @@ static int __devexit tsc2005_remove(struct spi_device *spi)
 
 	free_irq(ts->spi->irq, ts);
 	input_unregister_device(ts->idev);
+	cancel_delayed_work_sync(&ts->esd_work);
 	kfree(ts);
 
 	spi_set_drvdata(spi, NULL);

-- 
1.5.6.5

On Mon, Mar 21, 2011 at 06:24:10PM +0200, Aaro Koskinen wrote:

Commit 0b950d3 (Input: tsc2005 - add open/close) introduced a
locking issue with the ESD watchdog: __tsc2005_disable() is calling
cancel_delayed_work_sync() with mutex held, and the work also needs the
same mutex.

Fix the problem by using cancel_delayed_work() on disable. If
the ESD work was running it will check if the device is closed
or suspended, and in that case it will do nothing and skip
re-arming. cancel_delayed_work_sync() is still needed when the module
is removed.

Hmm, indeed. However, instead of moving cancel_delayed_work_sync() to
remove maybe we should use mutex_trylock() in tsc2005_esd_work()?
If trylock fails that means that device is in the middle of open/close
transition. We should just reschedule the work and get out of there.
 
Thanks.

-- 
Dmitry

Hi,

On Mon, 21 Mar 2011, Dmitry Torokhov wrote:

On Mon, Mar 21, 2011 at 06:24:10PM +0200, Aaro Koskinen wrote:

quoted

Commit 0b950d3 (Input: tsc2005 - add open/close) introduced a
locking issue with the ESD watchdog: __tsc2005_disable() is calling
cancel_delayed_work_sync() with mutex held, and the work also needs the
same mutex.

Fix the problem by using cancel_delayed_work() on disable. If
the ESD work was running it will check if the device is closed
or suspended, and in that case it will do nothing and skip
re-arming. cancel_delayed_work_sync() is still needed when the module
is removed.

Hmm, indeed. However, instead of moving cancel_delayed_work_sync() to
remove maybe we should use mutex_trylock() in tsc2005_esd_work()?
If trylock fails that means that device is in the middle of open/close
transition. We should just reschedule the work and get out of there.

But I guess the reschedule should not happen if we are in the middle of
close/disable? And without the mutex we cannot know that.

A.

On Tue, Mar 22, 2011 at 04:59:02PM +0200, Aaro Koskinen wrote:

Hi,

On Mon, 21 Mar 2011, Dmitry Torokhov wrote:

quoted

On Mon, Mar 21, 2011 at 06:24:10PM +0200, Aaro Koskinen wrote:

quoted

Commit 0b950d3 (Input: tsc2005 - add open/close) introduced a
locking issue with the ESD watchdog: __tsc2005_disable() is calling
cancel_delayed_work_sync() with mutex held, and the work also needs the
same mutex.

Fix the problem by using cancel_delayed_work() on disable. If
the ESD work was running it will check if the device is closed
or suspended, and in that case it will do nothing and skip
re-arming. cancel_delayed_work_sync() is still needed when the module
is removed.

Hmm, indeed. However, instead of moving cancel_delayed_work_sync() to
remove maybe we should use mutex_trylock() in tsc2005_esd_work()?
If trylock fails that means that device is in the middle of open/close
transition. We should just reschedule the work and get out of there.

But I guess the reschedule should not happen if we are in the middle of
close/disable? And without the mutex we cannot know that.

It should be OK to reschedule even as we enabling/disabling because
cancel_delayed_work_sync() handles re-arming works so even if ESD work
is being executed at the time we closing the device it will be killed
off completely.

Thanks.

-- 
Dmitry

Hi,

On Tue, 22 Mar 2011, Dmitry Torokhov wrote:

On Tue, Mar 22, 2011 at 04:59:02PM +0200, Aaro Koskinen wrote:

quoted

Hi,

On Mon, 21 Mar 2011, Dmitry Torokhov wrote:

quoted

On Mon, Mar 21, 2011 at 06:24:10PM +0200, Aaro Koskinen wrote:

quoted

Commit 0b950d3 (Input: tsc2005 - add open/close) introduced a
locking issue with the ESD watchdog: __tsc2005_disable() is calling
cancel_delayed_work_sync() with mutex held, and the work also needs the
same mutex.

Fix the problem by using cancel_delayed_work() on disable. If
the ESD work was running it will check if the device is closed
or suspended, and in that case it will do nothing and skip
re-arming. cancel_delayed_work_sync() is still needed when the module
is removed.

Hmm, indeed. However, instead of moving cancel_delayed_work_sync() to
remove maybe we should use mutex_trylock() in tsc2005_esd_work()?
If trylock fails that means that device is in the middle of open/close
transition. We should just reschedule the work and get out of there.

But I guess the reschedule should not happen if we are in the middle of
close/disable? And without the mutex we cannot know that.

It should be OK to reschedule even as we enabling/disabling because
cancel_delayed_work_sync() handles re-arming works so even if ESD work
is being executed at the time we closing the device it will be killed
off completely.

Ok, so here's an updated version:

From: Aaro Koskinen <redacted>
Subject: [PATCH] input: tsc2005: fix locking issue

Commit 0b950d3 (Input: tsc2005 - add open/close) introduced a
locking issue with the ESD watchdog: __tsc2005_disable() is calling
cancel_delayed_work_sync() with mutex held, and the work also needs the
same mutex.

Fix the problem by using mutex_trylock() in tsc2005_esd_work(). If the
mutex is taken, we know we are in the middle of disable or enable and
the watchdog check can be skipped.

Signed-off-by: Aaro Koskinen <redacted>
---
 drivers/input/touchscreen/tsc2005.c |   12 +++++++++++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/drivers/input/touchscreen/tsc2005.c b/drivers/input/touchscreen/tsc2005.c
index 03e4968..cf244be 100644
--- a/drivers/input/touchscreen/tsc2005.c
+++ b/drivers/input/touchscreen/tsc2005.c

@@ -477,7 +477,17 @@ static void tsc2005_esd_work(struct work_struct *work)
 	int error;
 	u16 r;

-	mutex_lock(&ts->mutex);
+	if (!mutex_trylock(&ts->mutex)) {
+		/*
+		 * If the mutex is taken, it means that disable or enable is in
+		 * progress. In that case just reschedule the work. If the work
+		 * is not needed, it will be canceled by disable.
+		 */
+		schedule_delayed_work(&ts->esd_work,
+			round_jiffies_relative(
+				msecs_to_jiffies(ts->esd_timeout)));
+		return;
+	}

 	if (time_is_after_jiffies(ts->last_valid_interrupt +
 				  msecs_to_jiffies(ts->esd_timeout)))

-- 
1.5.6.5