Hi Mukesh,
On Fri, Apr 19, 2019 at 12:17:44PM +0530, Mukesh Ojha wrote:
For some reason my last mail did not get delivered, sending it again.Are you saying that there are 2 threads sharing the same file
On 4/18/2019 11:55 AM, Mukesh Ojha wrote:
On 4/18/2019 7:13 AM, dmitry.torokhov@xxxxxxxxx wrote:
Hi Mukesh,Lets say an example where i am creating input device quite frequently
On Mon, Apr 15, 2019 at 03:35:51PM +0530, Mukesh Ojha wrote:
Hi Dmitry,uinput_release() should be called when last file handle to the uinput
Can you please have a look at this patch ? as this seems to reproducing
quite frequently
Thanks,
Mukesh
On 4/10/2019 1:29 PM, Mukesh Ojha wrote:
uinput_destroy_device() gets called from two places. In one place,
uinput_ioctl_handler() where it is protected under a lock
udev->mutex but there is no protection on udev device from freeing
inside uinput_release().
instance is being dropped, so there should be no other users and thus we
can't be racing with anyone.
[ÂÂ 97.836603] input: syz0 as /devices/virtual/input/input262
[ÂÂ 97.845589] input: syz0 as /devices/virtual/input/input261
[ÂÂ 97.849415] input: syz0 as /devices/virtual/input/input263
[ÂÂ 97.856479] input: syz0 as /devices/virtual/input/input264
[ÂÂ 97.936128] input: syz0 as /devices/virtual/input/input265
e.g input265
while input265 gets created [1] and handlers are getting registered on
that device*fput* gets called on
that device as user space got to know that input265 is created and its
reference is still 1(rare but possible).
descriptor, one issuing the registration ioctl while the other closing
the same fd?
Thanks.