Re: Locking IOCTL

2011-11-15 Thread Dave Hylands
Hi Praveen,

On Tue, Nov 15, 2011 at 4:23 AM, Praveen kumar  wrote:
> The driver is opened by multiple processes, One such process is a
> diagnostics.
> Where I am checking sanity of some of the registers if I make ioctl open for
> all the processes.It can screw
> up my diagnostics check.(write some values to registers). This is basic
> reason I am using lock to my ioctl.

So "locking the data" means that you should create a lock for the data
registers in question.

You should acquire the lock around writing the values to the
registers, and presumably around reading them.

Acquiring the lock is about accessing the registers, not calling the
ioctl, even if today the only place that you access the registers is
from the ioctl. What happens if down the road you decide to add some
type of monitoring thread and it needs to access the registers? It's
not in an ioctl, so acquiring some type of ioctl lock is misleading.
The data that the lock is tied to is the registers, so make the code
work that way.

Also, som paths through the ioctl might not need to access the
registers, so you don't need or want to acquire the lock for those
cases.

-- 
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Locking IOCTL

2011-11-15 Thread Tirtha Ghosh
Which kernel version are u using???

As far as I know, before 2.6.36, ioctl calls used to hold BKL, so no need
to have separate locking mechanism.

If you are using unlocked_ioctl (after 36 kernel) then you need to take
care of locking. Now, what kind of lock you want to use, depends on your
requirement. It could be code lock or data lock..




On Tue, Nov 15, 2011 at 5:53 PM, Praveen kumar  wrote:

> The driver is opened by multiple processes, One such process is a
> diagnostics.
> Where I am checking sanity of some of the registers if I make ioctl open
> for all the processes.It can screw
> up my diagnostics check.(write some values to registers). This is basic
> reason I am using lock to my ioctl.
>
> Thanks
> Praveen
>
>
> On Tue, Nov 15, 2011 at 1:28 PM, Dave Hylands  wrote:
>
>> Hi Praveen,
>>
>> On Mon, Nov 14, 2011 at 11:22 PM, Praveen kumar 
>> wrote:
>> >
>> > Hi All,
>> > I have a situation where I have to lock the ioctl provided in my
>> driver. I
>> > have a uni processor (ARM) system.
>> > I am using Mutex as the lock for my ioctl.
>> > DEFINE_MUTEX(&lock_ioctl);
>> > MyIoctl()
>> > {
>> > Mutex_lock(&lock_ioctl);
>> > Switch(){
>> > ...
>> > }
>> > Mutex_unlock(&lock_ioctl);
>> > return 0;
>> > }
>> > I just wanted to know am I using the best lock available for the
>> situation
>> > aor do I have any flaw in my implementation???
>> >
>> > And from LKD I  read that "*lock the data not the code*" and which I am
>> > literally doing so ?? any comments on this ?
>>
>> By creatiing something called lock_ioctl, I'd say you're locking the code.
>>
>> Locking the data means that lets suppose you have some data structure
>> which requires mutual exclusion. Then I'd create a lock associated
>> with that data structure (and probably the lock would be a member of
>> the data structure), and anytime I needed to manipulate/access the
>> data structure (in an atomic manner), I'd acquire the lock.
>>
>> > I have interrupts in my driver which is nothing to do with the lock.I am
>> > taking care that where ever I return in my ioctl the lock is released.
>>
>> What are you locking? Does every single ioctl really need to acquire
>> the lock? Why?
>>
>> --
>> Dave Hylands
>> Shuswap, BC, Canada
>> http://www.davehylands.com
>>
>
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Locking IOCTL

2011-11-15 Thread Praveen kumar
The driver is opened by multiple processes, One such process is a
diagnostics.
Where I am checking sanity of some of the registers if I make ioctl open
for all the processes.It can screw
up my diagnostics check.(write some values to registers). This is basic
reason I am using lock to my ioctl.

Thanks
Praveen

On Tue, Nov 15, 2011 at 1:28 PM, Dave Hylands  wrote:

> Hi Praveen,
>
> On Mon, Nov 14, 2011 at 11:22 PM, Praveen kumar 
> wrote:
> >
> > Hi All,
> > I have a situation where I have to lock the ioctl provided in my driver.
> I
> > have a uni processor (ARM) system.
> > I am using Mutex as the lock for my ioctl.
> > DEFINE_MUTEX(&lock_ioctl);
> > MyIoctl()
> > {
> > Mutex_lock(&lock_ioctl);
> > Switch(){
> > ...
> > }
> > Mutex_unlock(&lock_ioctl);
> > return 0;
> > }
> > I just wanted to know am I using the best lock available for the
> situation
> > aor do I have any flaw in my implementation???
> >
> > And from LKD I  read that "*lock the data not the code*" and which I am
> > literally doing so ?? any comments on this ?
>
> By creatiing something called lock_ioctl, I'd say you're locking the code.
>
> Locking the data means that lets suppose you have some data structure
> which requires mutual exclusion. Then I'd create a lock associated
> with that data structure (and probably the lock would be a member of
> the data structure), and anytime I needed to manipulate/access the
> data structure (in an atomic manner), I'd acquire the lock.
>
> > I have interrupts in my driver which is nothing to do with the lock.I am
> > taking care that where ever I return in my ioctl the lock is released.
>
> What are you locking? Does every single ioctl really need to acquire
> the lock? Why?
>
> --
> Dave Hylands
> Shuswap, BC, Canada
> http://www.davehylands.com
>
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Locking IOCTL

2011-11-14 Thread Dave Hylands
Hi Praveen,

On Mon, Nov 14, 2011 at 11:22 PM, Praveen kumar  wrote:
>
> Hi All,
> I have a situation where I have to lock the ioctl provided in my driver. I
> have a uni processor (ARM) system.
> I am using Mutex as the lock for my ioctl.
> DEFINE_MUTEX(&lock_ioctl);
> MyIoctl()
> {
> Mutex_lock(&lock_ioctl);
> Switch(){
> ...
> }
> Mutex_unlock(&lock_ioctl);
> return 0;
> }
> I just wanted to know am I using the best lock available for the situation
> aor do I have any flaw in my implementation???
>
> And from LKD I  read that "*lock the data not the code*" and which I am
> literally doing so ?? any comments on this ?

By creatiing something called lock_ioctl, I'd say you're locking the code.

Locking the data means that lets suppose you have some data structure
which requires mutual exclusion. Then I'd create a lock associated
with that data structure (and probably the lock would be a member of
the data structure), and anytime I needed to manipulate/access the
data structure (in an atomic manner), I'd acquire the lock.

> I have interrupts in my driver which is nothing to do with the lock.I am
> taking care that where ever I return in my ioctl the lock is released.

What are you locking? Does every single ioctl really need to acquire
the lock? Why?

-- 
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Locking IOCTL

2011-11-14 Thread Praveen kumar
 Hi All,
I have a situation where I have to lock the ioctl provided in my driver. I
have a uni processor (ARM) system.
I am using Mutex as the lock for my ioctl.
DEFINE_MUTEX(&lock_ioctl);
MyIoctl()
{
Mutex_lock(&lock_ioctl);
Switch(){
...
}
Mutex_unlock(&lock_ioctl);
return 0;
}
I just wanted to know am I using the best lock available for the situation
aor do I have any flaw in my implementation???

And from LKD I  read that "*lock the data not the code*" and which I am
literally doing so ?? any comments on this ?

I have interrupts in my driver which is nothing to do with the lock.I am
taking care that where ever I return in my ioctl the lock is released.

Thanks ,
Praveen
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies