linux内核错误：BUG: unable to handle kernel paging request at virtual address

内核版本2.6.18

使用内核中的AES加密算法对数据进行加解密，编写函数如下，

int mycipher_test(char *alg,int encflag,char *code,char *key)，其中第一个参数alg是AES加密算法的标志，第二个参数

encflag是判断加密还是解密，第三个参数code是要加解密的数据，第四个参数key是密钥。

该函数以模块的方式编译进内核。

具体代码如下：


C/C++ code

int mycipher_test(char *alg,int encflag,char *code,char *key)
{    

    int ret,keylen,codelen;

        struct scatterlist sg;

        char *result;

    struct crypto_tfm *tfm;


        keylen = 16;

        codelen = strlen(code);
    
         /*限制传入的数据是16字节，因为AES加密算法要求加密数据的长度为16字节整数倍*/
    if(codelen!=16){
        return -1;

    }
    

       /* Allocate transform for AES ECB mode */     

       tfm = crypto_alloc_tfm(alg,0);



    if(IS_ERR(tfm)) {

    
        printk("<1>failed to load transform for aes ECB mode !\n");

              return -1;


    }

        /*设置加密密钥*/
    ret = crypto_cipher_setkey(tfm,key,keylen);

    if(ret) {
        printk("<1>failed to setkey \n");
              goto failed1;
    }



    sg_init_one(&sg,code,16);//?

    switch(encflag){

    
        case 0:/*加密*/
                [color=#FF00FF]ret = crypto_cipher_encrypt(tfm,&sg,&sg,16);[/color]//可能出错处
                if(ret) {

                    printk("<1>encrypt failed \n");

                    goto failed1;

                }

            crypto_free_tfm(tfm);

            return 0;    

            break;


        case 1:/*解密*/

                [color=#FF00FF]ret = crypto_cipher_decrypt(tfm,&sg,&sg,16);[/color]//可能出错处
                         if(ret) {

                        printk("<1>dencrypt failed \n");

                        goto failed1;

                         }
            crypto_free_tfm(tfm);
            return 0;
            break;


        default:
            printk("error\n");
            return -1;


    }


failed1:

    crypto_free_tfm(tfm);

       return -1;


}

在内核中，当调用该函数，对数据进行加解密时，出现如下错误：


BUG: unable to handle kernel paging request at virtual address 0000120c
 printing eip:
c101b0d2
*pde = 16cc1067
Oops: 0000 [#1]
SMP 
Modules linked in: autofs4 hidp rfcomm l2cap bluetooth sunrpc ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink iptable_filter ip_tables ip6t_REJECT xt_tcpudp ip6table_filter ip6_tables x_tables acpiphp video sbs i2c_ec button battery asus_acpi ac aes ipv6 lp snd_ens1371 sg gameport snd_rawmidi snd_ac97_codec snd_ac97_bus snd_seq_dummy floppy i2c_piix4 snd_seq_oss pcspkr snd_seq_midi_event i2c_core snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm pcnet32 snd_timer snd soundcore mii snd_page_alloc parport_pc parport serio_raw ide_cd cdrom dm_snapshot dm_zero dm_mirror dm_mod mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd
CPU: 0
EIP: 0060:[<c101b0d2>] Not tainted VLI
EFLAGS: 00010212 (2.6.18.1 #82) 
EIP is at kmap_atomic+0x1b/0x7f
eax: 00000001 ebx: 00000007 ecx: c1cc2840 edx: 00000000
esi: 00000010 edi: d718fdac ebp: 00000010 esp: d718fd10
ds: 007b es: 007b ss: 0068
Process firefox-bin (pid: 4309, ti=d718f000 task=c0a03870 task.ti=d718f000)
Stack: d718fd4c c10c1f9e d404d000 c10c2553 d718fd7c d672a800 00000010 00000003 
  d404d000 d718fd9c c1cc2840 c1350761 00000010 00000010 0000084e d718fd9c 
  c1cc2840 00000000 00000010 00000010 0000084e c10c21e7 0000084e d718fdac 
Call Trace:
 [<c10c1f9e>] scatterwalk_map+0x2c/0x34
 [<c10c2553>] crypt+0xbd/0x1f1
 [<c10c21e7>] ecb_process+0x0/0x4b
 [<c10c273c>] ecb_decrypt+0x33/0x38
 [<e0a5b42e>] aes_decrypt+0x0/0xf62 [aes]
 [<c10c21e7>] ecb_process+0x0/0x4b
 [<c10c213e>] setkey+0x24/0x27
 [<c10c32ae>] mycipher_test+0x10e/0x150
 [<c118e7ce>] sock_recvmsg+0x162/0x19b
 [<c103334d>] autoremove_wake_function+0x0/0x2d
 [<c11eae0b>] schedule+0x907/0x9b4
 [<c1057bef>] find_extend_vma+0x12/0x49
 [<c1036067>] get_futex_key+0x40/0xd0
 [<c118fdfe>] sys_recvfrom+0xcf/0x137
 [<c1037092>] do_futex+0x20d/0xabc
 [<c10d31d1>] vsnprintf+0x419/0x457
 [<c1026b6d>] current_fs_time+0x4a/0x55
 [<c107b5fe>] touch_atime+0x60/0x92
 [<c107028f>] pipe_readv+0x315/0x321
 [<c118fe7f>] sys_recv+0x19/0x1d
 [<c11902aa>] sys_socketcall+0x117/0x19e
 [<c1003d0b>] syscall_call+0x7/0xb
Code: 01 00 00 c1 e8 0c c1 e0 05 03 05 10 06 38 c1 c3 53 89 c1 89 e0 89 d3 25 00 f0 ff ff ff 40 14 8b 01 c1 e8 1e 8b 14 85 ac e6 2b c1 <8b> 82 0c 12 00 00 05 80 37 00 00 39 c2 74 08 5b 89 c8 e9 b0 8c 
EIP: [<c101b0d2>] kmap_atomic+0x1b/0x7f SS:ESP 0068:d718fd10


这个错误困扰很久了，请各位大侠赐教。

http://deshunfan.blog.163.com/blog/static/34244101201010134010593/

谢谢 ch_984326013，
这个我已经看过了，仍然无法解决问题。

似乎是在进行高端内存映射时出问题的.

首先仔细检查你自己写的代码是否有问题, 再google或者向linux kenrel邮件列表提部是否是kernel bug.
2.6.18的kernel有点老.

感谢zmlovelx ，能否具体点

感谢wenxy1，
代码已经检查n遍了，但是始终找不到错在哪。
另外，我也参考过内核中的加密例子以及802.11加密的例子，加密的那部分代码跟自己的都基本一样。
不知道是不是内核版本的问题，换个新版本的试试。

你的那条错误打印消息，为啥在3.0内核中找不到呢？我找到下面的消息，（来自LDD3）
你检查下你的代码是不是在调用kmap_atomic()的时候不是原子上下文

void *kmap_atomic(struct page *page, enum km_type type);
void kunmap_atomic(void *addr, enum km_type type);
The high-performance version of kmap; the resulting mappings can be held only by atomic code. For drivers, type should be KM_USER0, KM_USER1, KM_IRQ0, or KM_IRQ1.

kmap_atomic is a high-performance form of kmap. Each architecture maintains a small list of slots (dedicated page table entries) for atomic kmaps; a caller of kmap_atomic must tell the system which of those slots to use in the type argument. The only slots that make sense for drivers are KM_USER0 and KM_USER1 (for code running directly from a call from user space), and KM_IRQ0 and KM_IRQ1 (for interrupt handlers). Note that atomic kmaps must be handled atomically; your code cannot sleep while holding one. Note also that nothing in the kernel keeps two functions from trying to use the same slot and interfering with each other (although there is a unique set of slots for each CPU). In practice, contention for atomic kmap slots seems to not be a problem.

cqbamboo，你好
能不能讲一下，如何发现3.0内核没有错误打印信息？