Re: loop-AES 1.4d crypto swap => __alloc_pages: 0-order allocation failed (gfp=0x20/0) from c882256e

[Hank Leininger <hlein@progressive-comp.com>]

On Tue, 25 Sep 2001, Jari Ruusu wrote:

> Hank Leininger wrote:
> > 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
[snip]
> Can both of you try this patch, and try to repeat the problem.
[snip]
> -+        bh->b_page = alloc_page(GFP_ATOMIC);
> ++        bh->b_page = alloc_page(GFP_NOIO);

This seems to help, but I still get oops's.  The "losetup; mke2fs" test
of a 23GB partition now gets further than it did before--instead of
dying while inode tables are written, it dies while writing superblocks
/ FS accounting information.  Interestingly this time it did *not* log a
'0-order allocation' error first.  The oops was very similar, but not
identical; here it is:

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: c04a1de8   ebx: 00000000   ecx: 00000001   edx: c04a1dec
esi: c04a1de8   edi: fffffff8   ebp: cedabdac   esp: c96fbd90
ds: 0018   es: 0018   ss: 0018
Process loop0 (pid: 138, stackpage=c96fb000)
Stack: c04a1da0 c04a1de8 00000002 c04a1dec 00000001 00000086 00000003 00000001
       c012d7bb c1d68e60 ced5e000 d091a3b7 c04a1da0 00000001 c1d68e60 c1466380
       c0187a7d c1d68e60 00000001 c1466380 00000082 c146a060 c02c5460 c019329a
Call Trace: [<c012d7bb>] [<d091a3b7>] [<c0187a7d>] [<c019329a>] [<c0197948>]
   [<c0194af7>] [<c01978e0>] [<c0107cef>] [<c0107e4e>] [<c0106b94>] [<d091d21b>]
   [<d091bee8>] [<d091a4d9>] [<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; d091d21a <[loop]aes_encrypt+e4a/ff0>
Trace; d091bee8 <[loop]transfer_aes+1f8/250>
Trace; d091a4d8 <[loop]loop_get_buffer+b4/154>
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)

I'll save you some diff'ing:

-eax: c0435948   ebx: 00000000   ecx: 00000001   edx: c043594c
-esi: c0435948   edi: fffffff8   ebp: c96fbdac   esp: c96fbd90
+eax: c04a1de8   ebx: 00000000   ecx: 00000001   edx: c04a1dec
+esi: c04a1de8   edi: fffffff8   ebp: cedabdac   esp: c96fbd90

-Trace; d091cc06 <[loop]aes_encrypt+836/ff0>
+Trace; d091d21a <[loop]aes_encrypt+e4a/ff0>

-Trace; d091ad62 <[loop]loop_thread+2da/438>
+Trace; d091a4d8 <[loop]loop_get_buffer+b4/154>


Hank Leininger <hlein@progressive-comp.com>
E407 AEF4 761E D39C D401  D4F4 22F8 EF11 861A A6F1


Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/