LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Is this a preempt issue in drivers/input/evdev.c
@ 2007-05-12 3:18 Yin,Fengwei
2007-05-12 5:05 ` Dmitry Torokhov
0 siblings, 1 reply; 3+ messages in thread
From: Yin,Fengwei @ 2007-05-12 3:18 UTC (permalink / raw)
To: linux-kernel
Hi,
When open/close evdev, the code is as following to handle multi-client
operation:
static int evdev_release(...)
{
...
if (!--evdev->open) {
<------------preempted
if (evdev->exist)
input_close_device(...);
else
evdev_free(evdev);
}
return 0;
}
static int evdev_open(...)
{
...
if (!evdev->open++ && evdev->exist){
errror = input_open_device(...);
if (error) {
...
}
}
...
return 0;
}
So if the evdev_release() is preempted at the point marked by another
process which will open the evdev, which will make operation sequence
like:
--evdev->open in evdev_release()
-----> preempted
evdev->open++ and input_open_devie()
<----- reschedule
input_close_device()
Should we introduce a mutex here? Or do I miss something? Thanks.
Regards
Yin, Fengwei
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Is this a preempt issue in drivers/input/evdev.c
2007-05-12 3:18 Is this a preempt issue in drivers/input/evdev.c Yin,Fengwei
@ 2007-05-12 5:05 ` Dmitry Torokhov
2007-05-13 18:12 ` Jens Axboe
0 siblings, 1 reply; 3+ messages in thread
From: Dmitry Torokhov @ 2007-05-12 5:05 UTC (permalink / raw)
To: Yin,Fengwei; +Cc: linux-kernel
Hi,
On Friday 11 May 2007 23:18, Yin,Fengwei wrote:
>
> So if the evdev_release() is preempted at the point marked by another
> process which will open the evdev, which will make operation sequence
> like:
>
> --evdev->open in evdev_release()
> -----> preempted
> evdev->open++ and input_open_devie()
> <----- reschedule
> input_close_device()
>
> Should we introduce a mutex here? Or do I miss something? Thanks.
>
Locking is completely absent in evdev. There was a patch introducing
locking in recent -mm's but it got dropped. I need to refresh it.
--
Dmitry
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Is this a preempt issue in drivers/input/evdev.c
2007-05-12 5:05 ` Dmitry Torokhov
@ 2007-05-13 18:12 ` Jens Axboe
0 siblings, 0 replies; 3+ messages in thread
From: Jens Axboe @ 2007-05-13 18:12 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Yin,Fengwei, linux-kernel
On Sat, May 12 2007, Dmitry Torokhov wrote:
> Hi,
>
> On Friday 11 May 2007 23:18, Yin,Fengwei wrote:
> >
> > So if the evdev_release() is preempted at the point marked by another
> > process which will open the evdev, which will make operation sequence
> > like:
> >
> > --evdev->open in evdev_release()
> > -----> preempted
> > evdev->open++ and input_open_devie()
> > <----- reschedule
> > input_close_device()
> >
> > Should we introduce a mutex here? Or do I miss something? Thanks.
> >
>
> Locking is completely absent in evdev. There was a patch introducing
> locking in recent -mm's but it got dropped. I need to refresh it.
How did stuff like that ever get merged, btw? I still have a completely
trivially oopsable rmmod psmouse problem, I hope it'll get fixed for
2.6.22.
--
Jens Axboe
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-05-13 18:13 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-05-12 3:18 Is this a preempt issue in drivers/input/evdev.c Yin,Fengwei
2007-05-12 5:05 ` Dmitry Torokhov
2007-05-13 18:12 ` Jens Axboe
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).