All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Duggan <aduggan@synaptics.com>
To: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: <linux-input@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<benjamin.tissoires@redhat.com>, <jkosina@suse.cz>
Subject: Re: NULL pointer dereference in i2c-hid
Date: Thu, 11 Dec 2014 10:40:05 -0800	[thread overview]
Message-ID: <5489E505.3050903@synaptics.com> (raw)
In-Reply-To: <2128690.c90ERDd9ZP@xps13>

On 12/11/2014 10:16 AM, Gabriele Mazzotta wrote:
> On Thursday 11 December 2014 16:03:07 Mika Westerberg wrote:
>> On Thu, Dec 11, 2014 at 10:58:01AM +0200, Mika Westerberg wrote:
>>> On Wed, Dec 10, 2014 at 06:04:51PM +0100, Gabriele Mazzotta wrote:
>>>> my laptop uses a touchpad that needs hid-rmi along with i2c-hid to work.
>>>> i2c-hid and hid-rmi can be loaded and unloaded independelty from each
>>>> other, however since 34f439e4afcd ("HID: i2c-hid: add runtime PM support")
>>>> if I unload hid-rmi and after it I also unload i2c-hid, I get a NULL
>>>> pointer dereference.
>>> I'll look into this.
>>>
>>> I can reproduce this easily with i2c-hid + hid-multitouch following your
>>> directions.
>> Can you try the below patch?
>>
>> I think we shouldn't free buffers yet in ->stop() because we need the
>> command buffer sending power commands to the device. Also it seems that
>> ->start() re-allocates buffers anyway if maximum size increases.
>>
>> It shouldn't even leak memory as we release buffers at ->remove()
>> anyway.
>>
>> diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
>> index 62cec01937ea..68a8c938feea 100644
>> --- a/drivers/hid/i2c-hid/i2c-hid.c
>> +++ b/drivers/hid/i2c-hid/i2c-hid.c
>> @@ -705,12 +705,7 @@ static int i2c_hid_start(struct hid_device *hid)
>>   
>>   static void i2c_hid_stop(struct hid_device *hid)
>>   {
>> -	struct i2c_client *client = hid->driver_data;
>> -	struct i2c_hid *ihid = i2c_get_clientdata(client);
>> -
>>   	hid->claimed = 0;
>> -
>> -	i2c_hid_free_buffers(ihid);
>>   }
>>   
>>   static int i2c_hid_open(struct hid_device *hid)
> Yes, it works, thanks.
>
> This change seems to also prevent kernel ooops when I unload either
> i2c-hid or i2c-designware-platform while the touchpad is in use,
> thing that is likely to happen because of the other bug I reported.
>
> Speaking of it, does any of you have any suggestion on how to debug it?
I was able to reproduce the initial issue by unloading hid-rmi and 
i2c-hid while holding my fingers on the touchpad. Mika's patch fixes it 
for me.

For the original bug, you can modprobe i2c-hid debug=1 and we can see 
what data the touchpad is reporting. That might help narrowing down if 
it's noise which the touchpad thinks are fingers or if there is a 
problem with the I2C lines causing spurious interrupts.

Andrew

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Duggan <aduggan@synaptics.com>
To: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
	benjamin.tissoires@redhat.com, jkosina@suse.cz
Subject: Re: NULL pointer dereference in i2c-hid
Date: Thu, 11 Dec 2014 10:40:05 -0800	[thread overview]
Message-ID: <5489E505.3050903@synaptics.com> (raw)
In-Reply-To: <2128690.c90ERDd9ZP@xps13>

On 12/11/2014 10:16 AM, Gabriele Mazzotta wrote:
> On Thursday 11 December 2014 16:03:07 Mika Westerberg wrote:
>> On Thu, Dec 11, 2014 at 10:58:01AM +0200, Mika Westerberg wrote:
>>> On Wed, Dec 10, 2014 at 06:04:51PM +0100, Gabriele Mazzotta wrote:
>>>> my laptop uses a touchpad that needs hid-rmi along with i2c-hid to work.
>>>> i2c-hid and hid-rmi can be loaded and unloaded independelty from each
>>>> other, however since 34f439e4afcd ("HID: i2c-hid: add runtime PM support")
>>>> if I unload hid-rmi and after it I also unload i2c-hid, I get a NULL
>>>> pointer dereference.
>>> I'll look into this.
>>>
>>> I can reproduce this easily with i2c-hid + hid-multitouch following your
>>> directions.
>> Can you try the below patch?
>>
>> I think we shouldn't free buffers yet in ->stop() because we need the
>> command buffer sending power commands to the device. Also it seems that
>> ->start() re-allocates buffers anyway if maximum size increases.
>>
>> It shouldn't even leak memory as we release buffers at ->remove()
>> anyway.
>>
>> diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
>> index 62cec01937ea..68a8c938feea 100644
>> --- a/drivers/hid/i2c-hid/i2c-hid.c
>> +++ b/drivers/hid/i2c-hid/i2c-hid.c
>> @@ -705,12 +705,7 @@ static int i2c_hid_start(struct hid_device *hid)
>>   
>>   static void i2c_hid_stop(struct hid_device *hid)
>>   {
>> -	struct i2c_client *client = hid->driver_data;
>> -	struct i2c_hid *ihid = i2c_get_clientdata(client);
>> -
>>   	hid->claimed = 0;
>> -
>> -	i2c_hid_free_buffers(ihid);
>>   }
>>   
>>   static int i2c_hid_open(struct hid_device *hid)
> Yes, it works, thanks.
>
> This change seems to also prevent kernel ooops when I unload either
> i2c-hid or i2c-designware-platform while the touchpad is in use,
> thing that is likely to happen because of the other bug I reported.
>
> Speaking of it, does any of you have any suggestion on how to debug it?
I was able to reproduce the initial issue by unloading hid-rmi and 
i2c-hid while holding my fingers on the touchpad. Mika's patch fixes it 
for me.

For the original bug, you can modprobe i2c-hid debug=1 and we can see 
what data the touchpad is reporting. That might help narrowing down if 
it's noise which the touchpad thinks are fingers or if there is a 
problem with the I2C lines causing spurious interrupts.

Andrew

  reply	other threads:[~2014-12-11 18:41 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-10 17:04 NULL pointer dereference in i2c-hid Gabriele Mazzotta
2014-12-10 17:04 ` Gabriele Mazzotta
2014-12-11  8:58 ` Mika Westerberg
2014-12-11 14:03   ` Mika Westerberg
2014-12-11 18:16     ` Gabriele Mazzotta
2014-12-11 18:40       ` Andrew Duggan [this message]
2014-12-11 18:40         ` Andrew Duggan
2014-12-11 19:11         ` Gabriele Mazzotta
2014-12-11 19:21           ` Andrew Duggan
2014-12-11 19:21             ` Andrew Duggan
2014-12-11 19:40             ` Gabriele Mazzotta
2014-12-11 20:46               ` Andrew Duggan
2014-12-11 20:46                 ` Andrew Duggan
2014-12-11 21:17                 ` Gabriele Mazzotta
2014-12-11 21:34                   ` Andrew Duggan
2014-12-11 21:34                     ` Andrew Duggan
2014-12-11 21:57                     ` Gabriele Mazzotta
2014-12-12  0:26                       ` Andrew Duggan
2014-12-12  0:26                         ` Andrew Duggan
2014-12-12  8:12                         ` Gabriele Mazzotta
2014-12-12 19:12                           ` Andrew Duggan
2014-12-12 19:12                             ` Andrew Duggan
2014-12-24 23:53                             ` Gabriele Mazzotta
2015-01-08 23:58                               ` Andrew Duggan
2015-01-08 23:58                                 ` Andrew Duggan
2015-01-09  8:04                                 ` Gabriele Mazzotta
2015-01-10  0:29                                   ` Andrew Duggan
2015-01-10  0:29                                     ` Andrew Duggan
2015-01-10  1:18                                     ` Gabriele Mazzotta
2015-02-22 21:37                                     ` Gabriele Mazzotta
2015-02-24  0:30                                       ` Andrew Duggan
2015-02-24  0:30                                         ` Andrew Duggan
2014-12-11 18:41       ` Benjamin Tissoires
2014-12-11 19:25         ` Gabriele Mazzotta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5489E505.3050903@synaptics.com \
    --to=aduggan@synaptics.com \
    --cc=benjamin.tissoires@redhat.com \
    --cc=gabriele.mzt@gmail.com \
    --cc=jkosina@suse.cz \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.