Hi,
I think the time has come again, to start a discussion
about the way locking is done in drivers/block/loop.c
Assume we use an unmodified kernel and plug in an
encryption module (lets say a twofish.o module).
Then we do the following:
dd if=/dev/zero of=foo bs=1024 count=1024
losetup -e twofish /dev/loop0 foo
mke2fs /dev/loop0
rmmod twofish
mount /dev/loop0 /mnt
-> funny doesn't work...
What happened:
losetup doesn't lock "twofish.o", because the following
functions are called in the following order:
lo_open
no encryption module defined yet, so no locking is done
loop_set_status
calls loop_init_xfer, which will lock twofish.o once
lo_release
encryption module is unlocked
I think this is simply wrong, because
a) People don't expect this.
b) People probably don't want this.
c) A correct locking scheme will make the code
in loop_unregister_transfer quite useless, because
it will ensure that loop_unregister_transfer is only
called from a module that isn't used by any loop device.
My patch simply removes the locking/unlocking from lo_open
and lo_release.
(I left in the code in loop_unregister_transfer because
this makes the change in code as small as possible and
the code doesn't hurt even if I think it's obsolete.)
The result is that an encryption module is locked as many times
as there are loop devices using it.
The module will be locked as soon as "loop_set_status" is called
and it will be unlocked when "loop_clr_fd" is called.
So the number of locks on the encryption module corresponds to the
number of loop devices using the encryption module...
Please can someone help me get this patch into the kernel...
(I tried at least 3 times and have failed so far...)
so long
Ingo Rohloff
This archive was generated by hypermail 2b29 : Mon Jul 15 2002 - 22:00:25 EST