Ingo Rohloff <rohloff@in.tum.de> writes:
>
> If lo_open doesn't call the cipher lock function and
> lo_release doesn't call the cipher unlock function, the issue
> is resolved. (So code gets deleted in the patch.)
I think it would be better if the low level module stays locked also while the
control fd is open. That would match the semantics of most other devices.
Right fix probably is to call ->lock twice in loop_set_status()
[Also the locking is not SMP safe, but that's a different issue, for the e.g. ->lock
would need to be replaced with a struct module *owner and also some other locking]
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/