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 <chatpravi@xxxxxxxxx> 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
PraveenOn Tue, Nov 15, 2011 at 1:28 PM, Dave Hylands <dhylands@xxxxxxxxx> wrote:
Hi Praveen,
By creatiing something called lock_ioctl, I'd say you're locking the code.
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 ?
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.
What are you locking? Does every single ioctl really need to acquire
> 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.
the lock? Why?
--
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
