一个段错误的问题[已解决]

weily0000

最近在写一个设备驱动，希望对每一个bio结构中的数据段的数据进行读出，我参考了前面OstrichFly兄的《写一个块设备驱动》一文
我利用bio_for_each_segment()这个宏
具体代码片段如下：

int j;
void *iovec_mem;
void *dsk_mem;
truct bio_vec *bvec;

bio_for_each_segment(bvec,mbio, j);
{
        printk("get %d bytes data\n", bvec->bv_len);
        iovec_mem = kmap(bvec->bv_page) + bvec->bv_offset;
        memcpy(dsk_mem, iovec_mem, bvec->bv_len);
        kunmap(bvec->bv_page);
        printk("Data: %s",(char *)dsk_mem);
}

模块编译可以通过，而且可以正常加载，而且我对生成的文件格式化成ext3文件系统，就当我挂在文件系统的时候报 段错误，而rmmod卸载模块的时候，显示模块在使用中。

望指教，谢谢了：）一

[ 本帖最后由 weily0000 于 2009-2-19 15:33 编辑 ]

Godbach

具体的报错信息是什么？

weily0000

原帖由 Godbach 于 2009-2-18 22:57 发表
具体的报错信息是什么？

谢谢回复：）
下面是dmesg出来的信息如下：

[  267.561265] BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
[  267.561289] printing eip: c0120fa8 *pde = 00000000
[  267.561444] Oops: 0000 [#1] SMP
[  267.561540] Modules linked in: cdpdev3 rfcomm l2cap bluetooth ppdev cpufreq_userspace cpufreq_conservative cpufreq_powersave cpufreq_ondemand cpufreq_stats freq_table sbs sbshc dock video output battery iptable_filter ip_tables x_tables ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi scsi_transport_iscsi lp snd_ens1371 gameport ipv6 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd shpchp parport_pc serio_raw button soundcore i2c_piix4 container parport pci_hotplug ac snd_page_alloc intel_agp i2c_core pcspkr evdev psmouse agpgart ext3 jbd mbcache sr_mod cdrom ata_generic sg sd_mod pata_acpi floppy pcnet32 mii mptspi mptscsih ehci_hcd mptbase scsi_transport_spi uhci_hcd usbcore ata_piix libata scsi_mod thermal processor fan fbcon tileblit font bitblit softcursor fuse
[  267.561720]
[  267.561796] Pid: 6041, comm: mount Not tainted (2.6.24-21-generic #1)
[  267.561812] EIP: 0060:[<c0120fa8>] EFLAGS: 00210246 CPU: 0
[  267.562144] EIP is at kmap+0x8/0x60
[  267.562167] EAX: 00000000 EBX: 00000000 ECX: 00200046 EDX: ee4c8000
[  267.562187] ESI: 00000001 EDI: eea3ad00 EBP: eef5b5bc ESP: ee4c9b34
[  267.562199]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[  267.562232] Process mount (pid: 6041, ti=ee4c8000 task=ef0be000 task.ti=ee4c8000)
[  267.562249] Stack: eea3ad00 f0bf6620 f0bf6978 c15def40 00000001 ef356180 0fe00000 00000002
[  267.562310]        00000000 ef356180 c0208d95 c1609100 00000000 ee0d85c0 c010336e ef0be1f0
[  267.562320]        00000041 ef5e5f14 d8cb5000 00000105 00000002 00000000 df9dd428 0fe00000
[  267.562334] Call Trace:
[  267.562477]  [<f0bf6620>] make_request+0x160/0x1b0 [cdpdev3]
[  267.562730]  [<c0208d95>] generic_make_request+0x235/0x4d0
[  267.562745]  [<c010336e>] __switch_to+0x9e/0x150
[  267.562760]  [<c01b34eb>] __find_get_block+0xab/0x1c0
[  267.562772]  [<c020909c>] submit_bio+0x6c/0x100
[  267.562780]  [<c01b362c>] __getblk+0x2c/0x2b0
[  267.562788]  [<c01b6c21>] bio_alloc_bioset+0x81/0x150
[  267.562797]  [<c01b5b70>] end_buffer_write_sync+0x0/0x70
[  267.562809]  [<c01b2d97>] submit_bh+0xd7/0x120
[  267.562816]  [<c01b4fe4>] sync_dirty_buffer+0x44/0xe0
[  267.562824]  [<f09cc808>] ext3_commit_super+0x48/0x80 [ext3]
[  267.562873]  [<f09cd24a>] ext3_setup_super+0xda/0x1e0 [ext3]
[  267.562931]  [<c01a3dbc>] d_alloc+0x17c/0x1a0
[  267.562939]  [<c01bc86f>] inotify_d_instantiate+0xf/0x40
[  267.562947]  [<c01a3c1d>] d_instantiate+0x3d/0x60
[  267.562955]  [<f09cf6a0>] ext3_fill_super+0x1010/0x17e0 [ext3]
[  267.562983]  [<c0219cdf>] snprintf+0x1f/0x30
[  267.562991]  [<c01d0d4c>] disk_name+0x3c/0xc0
[  267.563001]  [<c01940e2>] get_sb_bdev+0x102/0x130
[  267.563013]  [<f09cc610>] ext3_get_sb+0x20/0x30 [ext3]
[  267.563027]  [<f09ce690>] ext3_fill_super+0x0/0x17e0 [ext3]
[  267.563042]  [<c0193a94>] vfs_kern_mount+0xa4/0x120
[  267.563052]  [<c0193b6d>] do_kern_mount+0x3d/0xe0
[  267.563059]  [<c01a9027>] do_mount+0x5d7/0x700
[  267.563070]  [<c01a7d83>] mntput_no_expire+0x13/0x70
[  267.563077]  [<c016d90f>] find_lock_page+0x2f/0xb0
[  267.563086]  [<c016fe56>] filemap_fault+0x216/0x420
[  267.563095]  [<c012103d>] kunmap_atomic+0x3d/0xb0
[  267.563111]  [<c0172fb0>] __alloc_pages+0x60/0x3a0
[  267.563119]  [<c01b8578>] __blkdev_put+0x158/0x160
[  267.563134]  [<c01a7950>] copy_mount_options+0x40/0x140
[  267.563143]  [<c01a9767>] sys_mount+0x77/0xb0
[  267.563151]  [<c01043b2>] sysenter_past_esp+0x6b/0xa9
[  267.563199]  =======================
[  267.563221] Code: 74 01 c3 83 3d a4 54 4d c0 02 75 f6 89 d0 90 8d 74 26 00 e9 ab 99 05 00 8d 74 26 00 8d bc 27 00 00 00 00 53 89 c3 e8 68 9f 1f 00 <8b> 03 c1 e8 1e 69 c0 80 07 00 00 05 00 4d 3f c0 2b 80 0c 07 00
[  267.563339] EIP: [<c0120fa8>] kmap+0x8/0x60 SS:ESP 0068:ee4c9b34
[  267.563515] ---[ end trace 63a3b880b33b578f ]---

其中有一句是说：BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000，是哪个指针的问题？

Godbach

其中有一句是说：BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000，是哪个指针的问题？

这句的意思就是你的程序里肯定存在对指针的非法引用，而且应该是引用了空指针。检查一下如果程序中有申请和释放内存的地方，是否没有判断申请是否成功就进行了引用，或者释放之后还在引用。

weily0000

原帖由 Godbach 于 2009-2-19 09:14 发表


这句的意思就是你的程序里肯定存在对指针的非法引用，而且应该是引用了空指针。检查一下如果程序中有申请和释放内存的地方，是否没有判断申请是否成功就进行了引用，或者释放之后还在引用。

汗，我定义了两个空指针，都没有为它申请空间过，我再看看吧。谢谢啦~

Godbach

原帖由 weily0000 于 2009-2-19 09:26 发表


汗，我定义了两个空指针，都没有为它申请空间过，我再看看吧。谢谢啦~

确认一下这两个没有申请空间是否后来指向了有效的地址空间，不申请也没有关系，关键看你操作他们的时候他们指向的是否是有效的地址空间。

weily0000

原帖由 Godbach 于 2009-2-19 09:55 发表


确认一下这两个没有申请空间是否后来指向了有效的地址空间，不申请也没有关系，关键看你操作他们的时候他们指向的是否是有效的地址空间。

恩，已经解决了，确实是指针的问题，而且我前面多了一个“;”号，改了之后没有这个问题了，非常感谢

Godbach

原帖由 weily0000 于 2009-2-19 13:17 发表


恩，已经解决了，确实是指针的问题，而且我前面多了一个“;”号，改了之后没有这个问题了，非常感谢

内核中引起OOPS的大部分都是因为指针操作的问题。所以内核中一定要仔细的操作指针。

weily0000

原帖由 Godbach 于 2009-2-19 13:52 发表

内核中引起OOPS的大部分都是因为指针操作的问题。所以内核中一定要仔细的操作指针。

下次会注意的：），多谢指教

Godbach

原帖由 weily0000 于 2009-2-19 15:34 发表


下次会注意的：），多谢指教

共同学习，一起交流。:wink: