Re: [v3.11][Regression] HID: hyperv: convert alloc+memcpy to memdup

[Joseph Salisbury <joseph.salisbury@canonical.com>]

On 09/24/2013 05:29 AM, Jiri Kosina wrote:
> On Mon, 16 Sep 2013, Joseph Salisbury wrote:
>
>>>> Can you explain a little further?  Mark commit a4a23f6 as bad?  An
>>>> initial bisect already reported that was the first bad commit, so it
>>>> can't be marked bad.  The oops on memcpy() happens after commit a4a23f6
>>>> is reverted.  The oops on memcpy() did not happen before a4a23f6 was
>>>> committed, so I assume this new oops was introduced by a change later.
>>>>
>>>> Right now I'm bisecting down the oops on memcpy() by updating the bisect
>>>> with good or bad, depending if the test kernel hit the oops.  I then
>>>> revert a4a23f6, so that revert is the HEAD of the tree each time before
>>>> building the kernel again(As long as the commit spit out by bisect is
>>>> after when a4a23f6 was introduced).
>>> Yep.  Please continue bisecting the memcpy() oops.
>>>
>>> kmemdup() is just a kzalloc() followed by a memcpy().  When we split it
>>> apart by reverting the patch then we would expect the oops to move to
>>> the memcpy() part.  Somehow "desc" is a bogus pointer, but I don't
>>> immediately see how that is possible.
>>>
>>> regards,
>>> dan carpenter
>> Thanks for the details.  We'll continue the bisect and let you know how
>> it goes.
> Did this please yield any useful result?
>
> Thanks,
>
Thanks for following up, Jiri.  It's been a little tricky narrowing this
one down.  We bisected a couple of times, and both bisects indicated the
following commits as the first bad:

commit b1a1442a23776756b254b69786848a94d92445ba
Author: Jiri Kosina <jkosina@suse.cz>
Date: Mon Jun 3 11:27:48 2013 +0200

    HID: core: fix reporting of raw events

However, reverting this commit does not stop the system from locking up,
when the wireless trackpad is connected.  I was thinking of maybe using
a brute force method and pulling out all the HID changes, added in
3.11-rc1 to ensure the bug goes away.  Then add a group back in at a
time to narrow down the commit that introduced this.  The bisect should
have done this, but I'm not sure why it didn't.  It would be greatly
appreciated if you had any other suggestions on tracking down the cause?

Thanks,

Joe