LinuxQuestions.org - Kernel Pannic when Using Virtual Machine Manager

I am using Centos 6.5 + Xen. I want to deny open file using vi, gedit. I want to detect pathname of file. If this pathname is vm and using program such as gedit, vi. This will be deny.
I get inode number of each pathname. When I rebuild complete, I reboot and using new kernel. I view log in /var/log/message, I see
BUG: unable to handle kernel paging request at ffff880067006785
Jun 13 04:44:19 localhost kernel: IP: [<ffffffff81350b50>] xen_swiotlb_unmap_sg_attrs+0x30/0x70
Jun 13 04:44:19 localhost kernel: PGD 1a0d067 PUD 3fe30067 PMD 0
Jun 13 04:44:19 localhost kernel: Oops: 0000 [#2] SMP
Jun 13 04:44:19 localhost kernel: Modules linked in: fuse ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables xen_pciback xen_gntalloc autofs4 bridge stp llc ipv6 ext3 jbd xen_acpi_processor xen_netback xen_blkback uinput iTCO_wdt iTCO_vendor_support freq_table mperf coretemp microcode pcspkr sg i2c_i801 lpc_ich mfd_core snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc e1000e ptp pps_core ext4(F) jbd2(F) mbcache(F) sd_mod(F) crc_t10dif(F) firewire_ohci(F) firewire_core(F) crc_itu_t(F) ata_piix(F) pata_acpi(F) ata_generic(F) pata_marvell(F) usb_storage(F) i915(F) drm_kms_helper(F) drm(F) i2c_algo_bit(F) i2c_core(F) video(F) dm_mirror(F) dm_region_hash(F) dm_log(F) dm_mod(F)
Jun 13 04:44:19 localhost kernel: CPU: 1 PID: 2408 Comm: Xorg Tainted: GF D W 3.10.5 #11
Jun 13 04:44:19 localhost kernel: Hardware name: /DG33BU, BIOS DPP3510J.86A.0293.2007.1002.1519 10/02/2007
Jun 13 04:44:19 localhost kernel: task: ffff880004846080 ti: ffff88002e4fe000 task.ti: ffff88002e4fe000
Jun 13 04:44:19 localhost kernel: RIP: e030:[<ffffffff81350b50>] [<ffffffff81350b50>] xen_swiotlb_unmap_sg_attrs+0x30/0x70
Jun 13 04:44:19 localhost kernel: RSP: e02b:ffff88002e4ffc68 EFLAGS: 00010202
Jun 13 04:44:19 localhost kernel: RAX: ffffffff81350b20 RBX: 0000000000000000 RCX: 0000000000000000
Jun 13 04:44:19 localhost kernel: RDX: 0000000000000004 RSI: ffff88006700676d RDI: ffff880039c82098
Jun 13 04:44:19 localhost kernel: RBP: ffff88002e4ffc98 R08: 0000000000000000 R09: 000000000000e200
Jun 13 04:44:19 localhost kernel: R10: ffff88002e4ffe08 R11: 0000000000000246 R12: 0000000000000004
Jun 13 04:44:19 localhost kernel: R13: 0000000000000000 R14: ffff880039c82098 R15: ffff88006700676d
Jun 13 04:44:19 localhost kernel: FS: 00007f3c30684920(0000) GS:ffff88003fa80000(0000) knlGS:0000000000000000
Jun 13 04:44:19 localhost kernel: CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
Jun 13 04:44:19 localhost kernel: CR2: ffff880067006785 CR3: 0000000039833000 CR4: 0000000000002660
Jun 13 04:44:19 localhost kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jun 13 04:44:19 localhost kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Jun 13 04:44:19 localhost kernel: Stack:
Jun 13 04:44:19 localhost kernel: ffff880004912800 ffff8800049e4000 0000000000000001 ffff88003908fcc0
Jun 13 04:44:19 localhost kernel: ffff880004912800 0000000000000082 ffff88002e4ffcc8 ffffffffa00e44f5
Jun 13 04:44:19 localhost kernel: ffff88003908fcc0 ffff8800049e4000 ffff880004fe3668 ffff880004912800
Jun 13 04:44:19 localhost kernel: Call Trace:
Jun 13 04:44:19 localhost kernel: [<ffffffffa00e44f5>] i915_gem_gtt_finish_object+0x85/0x100 [i915]
Jun 13 04:44:19 localhost kernel: [<ffffffffa00dd41e>] i915_gem_object_unbind+0xae/0x180 [i915]
Jun 13 04:44:19 localhost kernel: [<ffffffffa00ddc23>] i915_gem_free_object+0x53/0x170 [i915]
Jun 13 04:44:19 localhost kernel: [<ffffffffa0058c2a>] drm_gem_object_free+0x2a/0x40 [drm]
Jun 13 04:44:19 localhost kernel: [<ffffffffa0059636>] drm_gem_handle_delete+0xf6/0x180 [drm]
Jun 13 04:44:19 localhost kernel: [<ffffffff8116dcf1>] ? free_pages_and_swap_cache+0x21/0xe0
Jun 13 04:44:19 localhost kernel: [<ffffffffa00596ea>] drm_gem_close_ioctl+0x2a/0x30 [drm]
Jun 13 04:44:19 localhost kernel: [<ffffffffa00574d1>] drm_ioctl+0x3f1/0x600 [drm]
Jun 13 04:44:19 localhost kernel: [<ffffffffa00596c0>] ? drm_gem_handle_delete+0x180/0x180 [drm]
Jun 13 04:44:19 localhost kernel: [<ffffffff811819a6>] ? kmem_cache_free+0x126/0x420
Jun 13 04:44:19 localhost kernel: [<ffffffffa005e240>] ? drm_vm_close_locked+0xa0/0xb0 [drm]
Jun 13 04:44:19 localhost kernel: [<ffffffff811a642a>] do_vfs_ioctl+0x8a/0x370
Jun 13 04:44:19 localhost kernel: [<ffffffff811a67b1>] SyS_ioctl+0xa1/0xb0
Jun 13 04:44:19 localhost kernel: [<ffffffff815a50d9>] system_call_fastpath+0x16/0x1b
Jun 13 04:44:19 localhost kernel: Code: 57 41 56 41 55 41 54 53 48 83 ec 08 66 66 66 66 90 83 f9 03 49 89 fe 41 89 d4 41 89 cd 74 41 31 db 85 d2 49 89 f7 7e 29 0f 1f 00 <41> 8b 57 18 49 8b 77 10 44 89 e9 4c 89 f7 83 c3 01 e8 9a fe ff
Jun 13 04:44:19 localhost kernel: RIP [<ffffffff81350b50>] xen_swiotlb_unmap_sg_attrs+0x30/0x70
Jun 13 04:44:19 localhost kernel: RSP <ffff88002e4ffc68>
Jun 13 04:44:19 localhost kernel: CR2: ffff880067006785
Jun 13 04:44:19 localhost kernel: ---[ end trace a158cc18dc45fd0e ]---

I think have a error when I try to get inode number using kernel_path(const char __user*)...
This is function when I get inode number:
unsigned long get_inode_number_vm_file_open(const char *pathname) {

struct path path;
int res = kern_path(pathname, LOOKUP_FOLLOW, &path);
if(res == 0) {
return path.dentry->d_inode->i_ino;
printk(KERN_INFO "OPEN: inode number pathname: %s: %d\n", pathname, path.dentry->d_inode->i_ino);

}

return -1;
}

I can't find error, I do not have resolve. Please help me