[ENBD] 2.5.46 update

[Peter T. Breuer]

"A month of sundays ago Tad Kollar wrote:"
> 1. In nbd_ioctl(), it goes to the case MY_NBD_ACK: under:
> // PTB these are all always local ioctls
>          switch (cmd)
> 
> 2. Calls:
> err = nbd_ack (slot, (char*)arg);

OK. Well, that's the final part of the cycle. It's reporting that it
treated the request OK remotely.

> 3. In nbd_ack, gets to the success: label and calls:
> nbd_commit (slot, req);

This takes the request out of the slot it's on, and ..

> 4. In nbd_commit, gets down to:
> nbd_end_request_lock (req);

 .. reports to the kernel that it was happy.

> 5. And dies there. That's as deep as I've gone so far...

OK. That is very good.

Now, is this a lockup, or an oops? No - scratch that. Are you running
SMP? If not, then the fact that there's a spinlock ther is immaterial.
If you are running SMP, then the spinlock may be the problem. 

If you are on SMP, can you change the call of nbd_end_request_lock to be
just nbd_end_request?  Or even better, replace the call in enbd.h to
give some warning, thus ..

  static void nbd_end_request_lock(struct request *req) {

    // PTB the kernel has only 2 queues, read and write, and it uses
    // the cmd field to determine to which the req belongs. We add a
    // seqno to it in nbd_do_req, so we reestablish it here.
    static void rq_set_seqno(struct request *, int);

    rq_set_seqno(req, 0); // PTB Zero extra seqno info
+   if (spin_trylock(req->q->queue_lock) != 0) {
+       printk(KERN_ALERT "nbd: end_request_lock called with lock held!\n");
+   } else {
+       spin_unlock(req->q->queue_lock);
+   }
    end_request_lock( req, !req->errors );
  }
 
If you are not running SMP, then perhaps locks have started working on
non-SMP machines!  No, they're still vacuous on non-SMP.

And are you running a preemptible kernel? That's another kettle of
fish.

You know ... you might have to instrument every line of end_request.





Peter