Hi,
I'm very new to kernel development. I'm implementing a mechanism in the CIFS
VFS client to ensure that the maximum number of outstanding requests is not
exceeded. To do this I'm using a semaphore. It works for a while, but
eventually (while doing some torture tests that send/receive many > 10MB
files simultaneously by multiple threads) my computer freezes. The logs show
the message "bad: scheduling while atomic!" followed by a trace. I'm
guessing this is where the problem is. So my question is, if my semaphore is
causing that error, what possible things could be triggering it? Could it be
an interrupt while waiting to acquire the semaphore? I'm using the
down_interruptible() to acquire and up() to release.
Thanks,
James
On Tue, 14 Sep 2004 15:25:24 +1000
James Roper <[email protected]> wrote:
> [] So my question is, if my semaphore is
> causing that error, what possible things could be triggering it? Could it be
> an interrupt while waiting to acquire the semaphore? I'm using the
> down_interruptible() to acquire and up() to release.
You have to use spinlocks to provide a mutual exclusion to interrupts.
However, a process on CPU cannot sleep while holding a spinlock. So,
sometimes it's needed to create a derivative locking scheme, based
on spinlocks. A common trick is to combine semaphores and spinlocks.
I cannot be more specific without knowing your code.
-- Pete
On Tue, 14 Sep 2004 15:25:24 +1000
James Roper <[email protected]> wrote:
>
> [] So my question is, if my semaphore is
> causing that error, what possible things could be triggering it?
> Could it be an interrupt while waiting to acquire the semaphore?
> I'm using the down_interruptible() to acquire and up() to release.
>
You use downXXX() and upXXX() to serialize user-access to your
driver in the usual APIs like read() and write().
You need to use spin-locks to protect critical sections
from being changed by interrupts. You need to do this
even if you are using downXXX() and upXXX(). Basically
downXXX() will cause a semaphore-contender to sleep. You
can't do this in an interrupt.
Any code in an ISR or on the timer-queue must never
execute downXXX(). It is possible, under extremely
strange circumstances to execute upXXX() from an
interrupt because it doesn't sleep, only releases
the lock (if the resource is locked). You don't
design anything to do this, though. It can be used
as a work-around to release a resource that was acquired
by a task that hung or died.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
Note 96.31% of all statistics are fiction.