[ENBD] 2.4.32 write & m_r problem

[Peter T. Breuer]

"Also sprach Anders Blomdell:"
> Does that imply that 2.4.32 of yesterday is not the the same 2.4.32 as 
> today?

I'll take the opportunity to comment on yesterday's work.

After Arne Wiebalck located the problem he has been chasing to lie
somewhere in do_srv_write in enbd-server, I reverted the routine to an
interpolated version that has the older loop structure.

In fact, I ditched the current codebase, took the last CVS entry for all
code, reverted the routine, and then diffed the result with the current
non-CVS code.  I then tested the result and proceeded to apply all
changes since then one by one, testing after each.

I added first the recent fixes to Makefile, enbd-maketest and so on,
then I added in header changes for alarm.h that provide microsecond
timeout functions, and then added in the functions.

I then tested a change in enbd-client which uses the (finer) timeout to
break out of a fcntl lock grab attempt on a shared memory portion (the
story here is that my brief observations under kernel 2.6 show userspace
locks on shared memory gradually going comatose). Previously there was
no way of breaking the lock attempt.

I tested first using the old second-grained timeout then the new
microsecond grain.  Both worked.  Then I shifted all the old
second-grained alarms to use the microsecond-grained alarm calls instead
at bottom, and retested.  All OK. The change is between using alarm(2)
and setitimer(2), and the man page says they cannot live together, so
it is one or the other.

Today I will try and shift the fairly adhoc fcntl locking code in
enbd-client to go through one of the more standard (in enbd) locking
abstractions in lock.c or sem.c instead, testing to look for changes.  I
am trying to isolate fcntl usage since it seems currently problematic in
kernel 2.6 . Then I'll look again atteh 2.6.3 kernel later today.

Peter