On Fri, Oct 18, 2013 at 05:56:41PM +0530, Mushtaq Khan wrote:
> Hi,
>
> In kernel driver, using Semaphore to block on resources (Descriptors and
> memory).
> Semaphore is initialized in locking state using call "init_MTEX_LOCKED()",
> when resources are not available process calls down_interruptible() and
> blocks. Once resources are freed up() is called, and blocked process is
> unblocked. up() is called from interrupt context which frees resources on
> receiving ACK-Interrupt.
> Following is the code snippet for blocking:
> do {
> ret = down_interruptible(sem)
> if (ret == 0) {
> break;
> } else {
> printk("Semaphore is not acquired try again\n");
> continue;
> }
> } while (1);
>
> While loop is used to make sure down_interrptible() is called until process
> acquires the semaphore. If process receives signal, process unblocks from
> down_interrptible() without acquiring the semaphore.
> Issue am seeing is once signal is received under the blocking state, again
> trying to acquire semaphore using down_interruptible() return value is
> always non-zero and process is looping in while loop.
Yes. This happens because there is a signal pending for the calling
thread. If you follow the down_interruptible() code path, you see that
the first thing in the loop in __down_common (kernel/semaphore.c) is
that signal_pending_state() is called to see if there is a pending
signal, and if so, it immediately returns -EINTR.
Using down_interruptible() in the method above is ill-advised. It's
expected that if you are interrupted, you will propagate that
'interrupted' condition to your caller (and eventually back out to
usermode).
Josh
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
