lkml.org 
[lkml]   [2004]   [Feb]   [19]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
FromJan Rychter <>
SubjectRe: Oopsing cryptoapi (or loop device?) on 2.6.*
DateWed, 18 Feb 2004 13:40:34 -0800
>>>>> "Jari" == Jari Ruusu <jariruusu@users.sourceforge.net>:
 Jari> Jan Rychter wrote: Do you mind doing a a quick grep:
 >>
 Jari> cd /path/to/your/kernel/source grep "Jari Ruusu"
 Jari> drivers/block/loop.c
 >>
 Jari> If you see my name there, your kerneli.org cryptoapi enabled
 Jari> kernel is running same loop code I wrote years ago. Those
 Jari> loop-jari-something patches that you find on the net, are just
 Jari> copies of old loop-AES code.
 >>
 >> No, it is not running this code. The code that works well for me is
 >> the external cryptoapi (as modules) with last update in Feb 2002.

 Jari> Then you are running loop that fails in few seconds using my
 Jari> tests.

I guess I am just lucky, because that hasn't failed me in years. I think
I can live with that for now.

 >> How do you get a file-backed encrypted filesystem to work under
 >> Linux 2.4.24?

Looking at the (lack of) answers to my question, I gather there is no
clear-cut answer, or rather that the answer is "you don't".

 Jari> Writable file backed loops received death sentence when GFP_NOFS
 Jari> was introduced to kernel, and they have been on death row since
 Jari> then. The best way is to set up partition backed loop using
 Jari> loop-AES. Mainline loop is still prone to deadlock, both file
 Jari> backed and device backed.

Is everyone aware of these issues?

And, just wondering -- if loop-AES works so much better, why hasn't it
been included in the kernel?

--J.
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-03-22 13:01    [from the cache]
©2003-2008