Re: Loop Encryption

Andrew E. Mileski (aem@netcom.ca)
Mon, 2 Jun 1997 14:40:06 -0400 (EDT)

> > > Using BH_Protected seems to work for the loop driver - buffers for the
> > > requests it creates cannot be freed until the loop driver is finished
> > > with them [or so I'm led to believe by the ramdisk driver].
> >
> > If that's all you want, then use b_count instead. It has the
> > advantage that two concurrent processes trying to pin the buffer in
> > memory won't conflict with each other.
>
> Thanks for the suggestion, but using b_count doesn't work in this case.
> There must be something else that BH_Protected does <shrug>

Apologies to Stephen Tweedie - he is entirely right about what b_count
does and what BH_Protected does. It seems keeping buffers from being freed
is not my problem with the loop driver.

It appears there are two possible deadlocks caused by the loop driver.
1) Running out of requests
2) Running out of buffers.
The only way to solve these is to let a loop request complete, which
can mean it needs to allocate more requests and buffers :-/

There are kludges for these in fs/buffer.c and drivers/block/ll_rw_blk.c
but they only really handle the case when a loop device is associated to
a non-loop device.

Patient: "Doctor! Doctor! It hurts when I do this..."
Doctor : "Then don't do that."

It seems to me that the _logical_ solution is to re-write the loop request
handler. It should be smart enough to handle requests to loop devices
associated to loop devices, completely on it's own without making buffer
requests.

As always, suggestion and commets are welcomed.

P.S. Is it me, or is get_request() in drivers/block/ll_rw_blk.c
particularly complex for the simple job it does (with interrupts
disabled I might add)?

--
Andrew E. Mileski   mailto:aem@netcom.ca
Linux Plug-and-Play Hardware Support http://www.redhat.com/linux-info/pnp/
XFree86 Matrox Team http://www.bf.rmit.edu.au/~ajv/xf86-matrox.html
Ottawa-Carleton Linux User's Group (OCLUG) http://www.storm.ca/~linux/