[ENBD] Problem with enbd 2.2.27

[Peter T. Breuer]

"A month of sundays ago Richard Sharpe wrote:"
> >network trace (interesting as it is!).  Compile with "make DEBUG=1" (or
> >2) and you will get very complete debugging traces in the syslogs of the
> >two machines.
> 
> Well, I wonder if the nbd.o loadable module is SMP safe? I wonder this

To be frank, I have no means of testing. My sole SMP machine is a production
server on which I cannot make tests. I will rectify that sometime next week by
getting a personal smp testbed. In theory, everything should be OK, because
the driver code has been checked by stephen tweedie sometime in the distant
past .. but things may have drifted since then.

The code does use semaphores to protect the nbd queue.  That is the only
shared kernel resource.  Requests are taken off the kernel queue and
placed on the private driver queue with semaphore protection.  The
individual slave clients come into the kernel and grab a request from
the private queue using its semaphore.  They place it on their own (length
1) queue.  From then on each client process has its own queue to manage
and SMP doesn't come back into the picture until the original request
has end_io run on it.  I don't know what the kernel does to help or
protect that operation against SMP.

> because I was running the client on an SMP machine, and when I swapped them
> around so that the client was on my uP machine, it worked OK, but whenever
> I run the client on the SMP machine, it fails.

Did you recompile the module? Silly question, I know! (smp and non-smp
compiled modules are binary distinct. Compiling without -DSMP will
null out the kernel lock code).

In any case, debugging traces from the driver or the clients would
probably let me see an smp problem (make DEBUG=2).

Peter