Locking IOCTL

[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 <dhylands at gmail.com> wrote:

> Hi Praveen,
>
> On Mon, Nov 14, 2011 at 11:22 PM, Praveen kumar <chatpravi at gmail.com>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20111115/27572f5c/attachment-0001.html