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 <[email protected]>
---
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:
>> 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:
> >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.
>
> 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:
>> Hi,
>>
>> On Mon, 21 Mar 2011, Dmitry Torokhov wrote:
>>> 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.
>>
>> 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 <[email protected]>
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 <[email protected]>
---
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