Re: Locking IOCTL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Praveen,

On Mon, Nov 14, 2011 at 11:22 PM, Praveen kumar <chatpravi@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux