2002-09-06 15:44:20

by Adam J. Richter

[permalink] [raw]
Subject: Patch?: linux-2.5.33/drivers/block/loop.c update

The followingp patch is the latest version of my loop.c
updates.

This version makes device backed loop devices work even
when the bio_alloc in the IO path returns NULL (i.e., under
memory pressure). When a loop device is configured, a page
(or q->hardsect_size if that is bigger) is preallocated for
use in case of memory allocation failure. If memory allocation
failure occurs in the IO path, the bio is submitted using this
reservd area, one page at a time. The advantage of this approach
is that is possible to allow bio producers to submit very big
transfers without needing to reserve so much memory for backup.

Because /dev/loop now can handle the memory allocation
failures, I have changed the memory allocation in the IO path
to be non-blocking.

I have tested this with the bio allocation code changed
to always fail. I tested the following cases:

plain encrypted
device X
file on ext2 X X
file on tmpfs X X

I have not yet tested it on an encrypted device because
Linux 2.5.32 and .33 cause the computers' keyboard not work on
every machine that I've tried them on, and the arrangement that
I use for testing an encrypted device requires me to enter a
password on a keyboard before networking has come up. I may
fiddling with setting up anotehr way to test that case, although
I'd rather devote that energy to tracking down the keyboard
problem.

The other new changes are basically just clean ups.

There are now separate q->make_request_fn and
loop_handler functions for file-backed and device-backed
cases. Besides pulling somre branches and subroutine calls
out of the IO path, this also makes it easier to read.

The variables that were previously named "bio" have been
renamed to "loop_bio" if they are used only as a bio for /dev/loop/nnn,
or "dev_bio" when they are used only as a bio for the underlying
hardware device that the loop is mounted on. In the few cases
where a bio variable could be used either way under different
circumstances, its name remains "bio". I think this makes the
code much easier to undertstand and maintain.

--
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."


Attachments:
(No filename) (2.30 kB)
loop.diff (47.76 kB)
Download all attachments

2002-09-09 12:16:56

by Adam J. Richter

[permalink] [raw]
Subject: Re: Patch?: linux-2.5.33/drivers/block/loop.c update

Here is an update to my loop.c changes.

Herbert Riedel reported memory corruption typically of single
bytes when using a loop device backed by a file on an XFS filesystem
on a multiprocessor. I believe was due to lo_aops_send doing its call
to flush_dcache_page before writing to the effected memory rather than
after, which is what my new patch does. Herbert says that he may not
have time to retest for a little while, so I thought I ought to post
this update in case anyone else wants to comment or test.

Also in this version, <linux/loop.h> exports loop_iv_t, which
Herbert requested to simplify cryptoapi maintenance.

--
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."


Attachments:
(No filename) (898.00 B)
loop.diff (49.20 kB)
Download all attachments

2002-09-09 20:21:03

by Herbert Valerio Riedel

[permalink] [raw]
Subject: Re: Patch?: linux-2.5.33/drivers/block/loop.c update

On Mon, 2002-09-09 at 14:20, Adam J. Richter wrote:
> have time to retest for a little while, so I thought I ought to post
> this update in case anyone else wants to comment or test.

I've integrated adam's loop.diff into

http://www.kernel.org/pub/linux/kernel/crypto/v2.5/patch-int-2.5.33.2.bz2

in case anyone wants an all-in-one patch...

regards,
--
Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840
Email: [email protected] / Finger [email protected] for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F
4142