Help with a loop device bug

[David Marshall]

I applied the 2.3.42 version of the International kernel patches to a
2.3.99-test1-ac9 kernel. The only real rejects were related to 
the relative block stuff which was done around February, and I ignored
that for now, at least. Aside from about half a dozen other problems I
had to fix, including a "L_OBJS" substituted for an "LX_OBJS" in a
Makefile, there's one that's really vexing me.

The bug I'm not understanding is related to a -ETXTBSY which is
returned from loop_clr_fd(). When I use losetup (yes, it's the
included version) to attach a loop device to another file, then when I
try to detach the loop device the kernel still thinks that the file is
busy and will return -ETXTBSY the *next* time that get_write_access()
is called.

Example:

# losetup -e none /dev/loop0 foobar
# losetup -d /dev/loop0
# losetup -e none /dev/loop0 foobar
foobar: Text file busy

The -ETXTBSY comes from fs/namei.c's get_write_access(), and that's
called by loop_set_fd() in loop.c. Apparently get_write_access()
thinks that the write count is less than 0.

One of the problems which I kludged around was adding an #undef for
QUEUE_EMPTY to drivers/block/loop.c before it loads linux/blk.h. For
some reason, QUEUE_EMPTY was never getting defined because GCC thought
it was defined, causing GCC to complain when it was used in the 
INIT_REQUEST macro. (I don't understand that one either.) I don't see
how that particular problem would cause this particular bug, though.

Has anyone gotten the patch-int-2.3.42 to work with the 2.4.0test1*
kernels, or is there a newer version of this patch hidden on the net
somewhere?

Thanks.