I cannot see how dropping io_request_lock in loopback can be race safe.
The lock is protecting the base filesystem at the point the code goes
recursive. Dropping the lock so loopback can acquire it has got to
leave a race window. This problem will affect any code that recurses
in I/O, is loopback the only one? Three solutions spring to mind.
1) Instead of a global io_request_lock, have per device io locks,
treating loopback as a device. Assumes that recursion never occurs
on the same device. Would probably need locks on common structures
as well, e.g. buffer cache. I don't know enough about the
filesystem code to say if this would work, any experts care to
comment?
2) Gerard's suggestion of moving ll_rw_block into the loopback strategy
routine. Would fix loopback but leaves any other recursive code
with locks vulnerable.
3) Introduce a modified lock type that can be obtained more than once
by the same code path so it can be used recursively. A count takes
care of recursion but identifying the same code path is tricky. A
combination of pid and cpu number should be unique as long as kernel
processes do not migrate between cpus with the lock held. Has the
advantage of being usable anywhere that kernel code has to recurse
with a lock held, not just in I/O.
Comments?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu