Thanks Adrian for the reply. So a syscall will not interrupt the local CPU?
If my kernel thread does a spin_lock() to lock the structure and if a
syscall happens right after that will it interrupt the kernel thrread
and try to spin_lock too?
a syscall is an exception (a software interrupt); if you use spin_lock() in your kernel thread you will just be protecting your data structure; the system call (the exception) has nothing to do with that structure, until the system call handler is called (the ioctl routine, in your case); if your ioctl routine uses the same structure than you should protect it using a spinlock also
please note that when a system call is made, first there is an analysis of the system call arguments (registers), then a switch to kernel (supervisor) mode then a search for the proper system call handler routine; this is the exception (software interrupt) handler; as long as it doesn't access the protected structure (and it never does, unless you were mangling with the sys_call_table structure) nothing bad ( a.k.a. inconsistency due to lack of synchronization) will ever happen
when the ioctl routine is finally executed, there is no exception context; you are in kernel mode, in process context; the kernel simply executes the ioctl routine on behalf of the process that requested it through the proper system call; the syncrhonization methods that I have mentioned in the previous mail (spinlock, semaphore, preempt_disable) will work fine here
you should definitely consult chapter 9 of Linux Kernel Development 2nd Edition by Robert Love; it presents all the kernel synchronization methods and their advantages/disadvantages quite clearly
Razvan
P.S.: I apologize to you and to the members of this discussion list for not sending the previous message to everyone (I did a "Reply" instead of "Reply to all" and only you received it)
On 7/3/06, Adrian - Razvan Deaconescu <razvand@xxxxxxxxx > wrote:
> On 7/3/06, mzubair <mzubair173@xxxxxxxxx> wrote:
>
> > Hi,
> >
> > I have a data structure which is used in a kernel thread and in my
> > ioctl function. I know for interrupts I need to use spin_lock_irqsave
> > to disable interrupts but what about syscalls (ie. exceptions)?
>
>
> syscalls are handled inside the kernel code; that means that if it is
> possible to access a particular piece of data both with your kernel thread
> and your system call handler, you should synchronize it (you could for
> example, use a spinlock, semaphore or preempt_disable - it should work fine,
> because the system call handler is process context)
>
>
> > When the kernel thread accesses the data structure, should it also
> > disable interrupts so that my user program doesnt send a syscall at
> > that particular point in time?
>
>
> you may want to disable interrupts when accessing your data structure with
> your kernel thread only in the case where the interrupt request handler also
> accesses the structure; this could lead to inconsistency if the handler
> interrupts the kernel thread when it was accessing the data structure
>
> in your case, however, you use the data structure in process context (both
> the kernel thread and the ioctl routine - although called through a system
> call - work in process context); so it will suffice to use one of the things
> I mentioned above (spinlock, semaphore, preempt_disable); on a single
> processor system a spinlock is compiled away and thus has the same effect as
> preempt_disable; a semaphore is useful if you have to sleep in the
> synchronized region (accessing user space data or trying to allocate memory)
> or if it is fairly large; it does incur some overhead though; if the
> synchronized region has no "sleeping problems" and it isn't large, I suggest
> using a spinlock (no irqsave is necessary as you _don't_ access the data
> from within an interrupt handler)
>
> > thanks
>
>
> Hope this helps!
> Razvan
>
>
> --
> Computers don't make mistakes... What they do they do on purpose!
--
Computers don't make mistakes... What they do they do on purpose!
