bad: scheduling while atomic!

I'm seeing tonnes of this with UP preempt in 2.5.71. The following is just one case which I've been able to track down:

bad: scheduling while atomic! (00000250 0 8 mtdblockd)
[<c02372d0>] (schedule+0x0/0x490) from [<c0335fd0>] (mtd_blktrans_thread+0x220/0x258)
r7 = 00000000 r6 = C0109FBC r5 = C0108000 r4 = C0109FB8
[<c0335db0>] (mtd_blktrans_thread+0x0/0x258) from [<c0224554>] (kernel_thread+0x40/0x48)
bad: scheduling while atomic! (00000251 0 8 mtdblockd)
[<c02372d0>] (schedule+0x0/0x490) from [<c0335fd0>] (mtd_blktrans_thread+0x220/0x258)
r7 = 00000000 r6 = C0109FBC r5 = C0108000 r4 = C0109FB8
[<c0335db0>] (mtd_blktrans_thread+0x0/0x258) from [<c0224554>] (kernel_thread+0x40/0x48)
bad: scheduling while atomic! (00000252 0 8 mtdblockd)
[<c02372d0>] (schedule+0x0/0x490) from [<c0335fd0>] (mtd_blktrans_thread+0x220/0x258)
r7 = 00000000 r6 = C0109FBC r5 = C0108000 r4 = C0109FB8
[<c0335db0>] (mtd_blktrans_thread+0x0/0x258) from [<c0224554>] (kernel_thread+0x40/0x48)

(The extra numbers are: preempt_count, kernel_locked, pid and comm).

This instance seems to be caused by the following code in drivers/mtd/mtd_blkdevs.c:

         while (!tr->blkcore_priv->exiting) {
                 spin_lock_irq(rq->queue_lock);
 ...
                 spin_unlock_irq(rq->queue_lock);
 ...
                 spin_lock_irq(rq->queue_lock);
 ...
         }

It would be useful if we could balance the spin_locks with the spin_unlocks. 8)

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

How about this mindless guess?

Jörn

It's just what we asked for, but not what we want!
-- anonymous

--- linux-2.5.71/drivers/mtd/mtd_blkdevs.c~mtd_spinlocks	2003-06-15 16:05:05.000000000 +0200
+++ linux-2.5.71/drivers/mtd/mtd_blkdevs.c	2003-06-15 16:19:43.000000000 +0200
@@ -93,14 +93,13 @@
 	recalc_sigpending();
 	spin_unlock_irq(&current->sighand->siglock);
 
+	spin_lock_irq(rq->queue_lock);
 	while (!tr->blkcore_priv->exiting) {
 		struct request *req;
 		struct mtd_blktrans_dev *dev;
 		int res = 0;
 		DECLARE_WAITQUEUE(wait, current);
 
-		spin_lock_irq(rq->queue_lock);
-
 		req = elv_next_request(rq);
 
 		if (!req) {
@@ -112,6 +111,7 @@
 			schedule();
 			remove_wait_queue(&tr->blkcore_priv->thread_wq, &wait);
 
+			spin_lock_irq(rq->queue_lock);
 			continue;
 		}

I can see how that could be considered appropriate. There are a handful of other such trivia in CVS which want to go to Linus shortly -- I assume that includes your afs partitioning fix?

dwmw2

Yes, although I was considering sending that one myself. If you're due to do another sync up, feel free to include that.

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Well, given the 'NFTL aborts if add_mtd_blktrans functions exists, rather calling it and aborting only it it returns non-zero' bug, I suppose I am due such ;)

dwmw2