[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <F1F6C959961EA744BBD5B8EEF8B8FEA16DDCBD9FFF@BGMAIL02.nvidia.com>
Date: Mon, 23 Sep 2013 17:19:58 +0530
From: Manoj Chourasia <mchourasia@...dia.com>
To: Peter Wu <lekensteyn@...il.com>, Jiri Kosina <jkosina@...e.cz>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] hidraw: correctly deallocate memory on device disconnect
Hi Jiri,
What is the final proposed fix for this issue?
Thanks
-Manoj
-----Original Message-----
From: Peter Wu [mailto:lekensteyn@...il.com]
Sent: Tuesday, August 20, 2013 7:44 PM
To: Jiri Kosina
Cc: Manoj Chourasia; linux-kernel@...r.kernel.org
Subject: Re: [PATCH] hidraw: correctly deallocate memory on device disconnect
On Friday 09 August 2013 11:31:15 Jiri Kosina wrote:
> On Mon, 22 Jul 2013, Manoj Chourasia wrote:
> > This is mail is in regard to your commit for hidaw devices. We were
> > seeing kernel crashes while connect and disconnect a hidraw device
> > and we were hitting rb tree corruption in vmalloc and kernel was
> > crashing because of null pointer de-reference. Later we figure out
> > that was because the hid device disconnect is freeing memory which
> > later got access by hidraw_read and hid_write.
>
> Now applied, thanks Manoj, thanks Peter.
I just noticed an issue with this patch, after playing with some receivers I saw 8 hidraw device nodes. Every USB receiver creates two hidraw nodes, one for the receiver and one for the paired device.
UPower seems to keep the file descriptor open which prevents the hidraw device from being removed. Shouldn't the implementation of hidraw be changed to separate open file descriptors from the actual HID devices? That should allow /dev/hidrawX devices to get removed whenever a HID device is gone.
Regards,
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists