hello,
I have a doubt regarding user space threads and device drivers
implementation issue.
I have a device driver for /dev/skn
It implements basic driver operations skn_open,skn_release, skn_ioctl.
I am storing something into struct file*filp->private_data.
As this is not shared across processes I am not doing any locking
stuff while accessing or putting anything into it.
Will There be a race condition in a multithreaded program in the ioctl
call on smp kernel accessing filp->private_data.
S.Kartikeyan
On 2005/04/27 17:05, k8 s <[email protected]> wrote:
> I am storing something into struct file*filp->private_data.
> As this is not shared across processes I am not doing any locking
> stuff while accessing or putting anything into it.
You're talking about kernel variables, aren't you? Kernel memory is
shared among all processes, i.e. you _do_ need locking.
Max
But i am sharing something in file->private_data which is a private
variable to the process(that is passed to the device driver
functions). Isn't it?
SK
On 4/27/05, Max Kellermann <[email protected]> wrote:
> On 2005/04/27 17:05, k8 s <[email protected]> wrote:
> > I am storing something into struct file*filp->private_data.
> > As this is not shared across processes I am not doing any locking
> > stuff while accessing or putting anything into it.
>
> You're talking about kernel variables, aren't you? Kernel memory is
> shared among all processes, i.e. you _do_ need locking.
>
> Max
>
>
> I am storing something into struct file*filp->private_data.
> As this is not shared across processes I am not doing any locking
> stuff while accessing or putting anything into it.
>
> Will There be a race condition in a multithreaded program in the ioctl
> call on smp kernel accessing filp->private_data.
If you are only accessing ->private_date in an ioctl() method, you have
lucked out: straight ioctl() remains protected by the big kernel lock,
and you will not have concurrent accesses.
That said, it's not that hard for you to add the proper locking yourself
and have code which will be robust in the future. Why not do it right?
There's lots of information in LDD3 (http://lwn.net/Kernel/LDD3/) and
elsewhere on how to do that.
jon
Jonathan Corbet
Executive editor, LWN.net
[email protected]
On Wed, 27 Apr 2005, k8 s wrote:
> hello,
>
> I have a doubt regarding user space threads and device drivers
> implementation issue.
>
> I have a device driver for /dev/skn
> It implements basic driver operations skn_open,skn_release, skn_ioctl.
>
> I am storing something into struct file*filp->private_data.
> As this is not shared across processes I am not doing any locking
> stuff while accessing or putting anything into it.
>
> Will There be a race condition in a multithreaded program in the ioctl
> call on smp kernel accessing filp->private_data.
>
Of course. But that's not the only race. You need to make certain that
any shared resource (your driver) only allows a single execution-
thread anywhere there is shared data or the hardware itself. This
is generally accomplished with semaphore(s), a.k.a, down() and up().
Note that each open() call provides its own 'struct file' pointer.
The kernel won't get them mixed up. You can use your private-data
pointer available in this structure in each open() and use that
for private data in each access. You can free such private data
in a close(). But, that's just the obvious stuff. User-mode threads
share open files!
That means that your driver has no way of isolating such access
except by using semaphores.
> S.Kartikeyan
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
k8 s wrote:
> But i am sharing something in file->private_data which is a private
> variable to the process(that is passed to the device driver
> functions). Isn't it?
How do you make sure that there is only one process accessing the file?
If you open a file and then fork another process, both have access to
the file using the same file descriptor.
You might want to do precisely this for a number of reasons, like having
one process that send commands to a device while the other receives
status information...
--
Paulo Marques - http://www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
On Wed, Apr 27, 2005 at 09:00:58PM +0530, k8 s wrote:
> But i am sharing something in file->private_data which is a private
> variable to the process(that is passed to the device driver
> functions). Isn't it?
It is not. It is private to struct file. Not to process. And any number
of things (starting with fork()) will give several processes references to
the same struct file. As soon as it had returned from ->open(), it should
be considered externally visible and potentially shared until ->release()
is called.