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).