On 2001-09-25, "peter k." <spam-goes-to-dev-null@xxxxxxx> wrote:
> yesterday i configured my box to use swap over loop-AES....
> if i cat /dev/zero > blah now on another loop-AES encrypted device (not
> on the swap device of course) "__alloc_pages: 0-order allocation failed
> (gfp=0x20/0) from c882256e" starts and keeps appearing when the kernel
> wants to start swapping until it panics within the process of the loop
> device i was cat'ing to....i guess this error is caused by loop-AES
Funny, I was just about to post about something similar...
I've found that I cannot use the latest loop-AES on 2.4.9 (at least) with a
partition-backed loop device larger than 2 GB. The stock loop driver in
2.4.9 works fine with large (dozens of GBs) loop devices, but the loop-AES
driver causes kernel panics. Using loop-AES, losetup'ing (with or without
encryption) a 10-20 GB partition and then trying to mke2fs /dev/loop0 will
result in a panic. A 2 GB partition is rock solid. A 2.2 GB partition
will successfully mkfs and mount, but then trying to dd if=/dev/zero
of=/mnt/testfile will cause a panic once the file passes the 2 GB mark.
The one log entry that manages to be syslogged is:
Sep 25 11:49:14 rover kernel: __alloc_pages: 0-order allocation failed.
Here's an oops hand-copied and run through ksymoops (and unfortunately
line-wrapped a bit):
unable to handle kernel paging request at virtual address fffffffc
*pde = 00001063
EIP: 0010:[<c01103c3>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010017
eax: c0435948 ebx: 00000000 ecx: 00000001 edx: c043594c
esi: c0435948 edi: fffffff8 ebp: c96fbdac esp: c96fbd90
ds: 0018 es: 0018 ss: 0018
Process loop0 (pid: 145, stackpage=c96fb000)
Stack: c0435900 c0435948 00000002 c043594c 00000001 00000086 00000003 \
00000001
c012d7bb cb3f28c0 c96d9000 d091a3b7 c0435900 00000001 cb3f28c0 \
c14694e0
c0187a7d cb3f28c0 00000001 c14694e0 00000002 c146a060 c02c5460 \
c019329a
Call Trace: [<c012d7bb>] [<d091a3b7>] [<c0187a7d>] [<c019329a>] \
[<c0197948>]
[<c0194af7>] [<c01978e0>] [<c0107cef>] [<c0107e4e>] [<c0106b94>] \
[<d091cc06>]
[<d091bee8>] [<d091ad62>] [<c0105454>]
Code: 8b 4f 04 8b 1b 8b 01 85 45 fc 74 51 31 c0 9c 5e fa c7 01 00
>>EIP; c01103c2 <__wake_up+32/a8> <=====
Trace; c012d7ba <end_buffer_io_sync+3e/48>
Trace; d091a3b6 <[loop]loop_end_io_transfer_wr+2a/5c>
Trace; c0187a7c <end_that_request_first+60/bc>
Trace; c019329a <ide_end_request+5a/90>
Trace; c0197948 <ide_dma_intr+68/a8>
Trace; c0194af6 <ide_intr+fa/150>
Trace; c01978e0 <ide_dma_intr+0/a8>
Trace; c0107cee <handle_IRQ_event+2e/58>
Trace; c0107e4e <do_IRQ+6e/b0>
Trace; c0106b94 <ret_from_intr+0/6>
Trace; d091cc06 <[loop]aes_encrypt+836/ff0>
Trace; d091bee8 <[loop]transfer_aes+1f8/250>
Trace; d091ad62 <[loop]loop_thread+2da/438>
Trace; c0105454 <kernel_thread+28/38>
Code; c01103c2 <__wake_up+32/a8>
0000000000000000 <_EIP>:
Code; c01103c2 <__wake_up+32/a8> <=====
0: 8b 4f 04 mov 0x4(%edi),%ecx <=====
Code; c01103c4 <__wake_up+34/a8>
3: 8b 1b mov (%ebx),%ebx
Code; c01103c6 <__wake_up+36/a8>
5: 8b 01 mov (%ecx),%eax
Code; c01103c8 <__wake_up+38/a8>
7: 85 45 fc test %eax,0xfffffffc(%ebp)
Code; c01103cc <__wake_up+3c/a8>
a: 74 51 je 5d <_EIP+0x5d> c011041e \
<__wake_up+8e/a8>
Code; c01103ce <__wake_up+3e/a8>
c: 31 c0 xor %eax,%eax
Code; c01103d0 <__wake_up+40/a8>
e: 9c pushf
Code; c01103d0 <__wake_up+40/a8>
f: 5e pop %esi
Code; c01103d2 <__wake_up+42/a8>
10: fa cli
Code; c01103d2 <__wake_up+42/a8>
11: c7 01 00 00 00 00 movl $0x0,(%ecx)
This is a laptop running 2.4.9 stock, ne2000-clone pcmcia NIC, no APM or
other stuff enabled, plus loop-AES-v1.4d and patched util-linux 2.11i.
I'll test 2.2.19 as soon as I can, but since the stock loop.c driver in 2.4
doesn't cause this, I expect results to be the same :(
--
Hank Leininger <hlein@xxxxxxxxxxxxxxxxxxxx>
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
