Messages in this thread | | | Date | Tue, 26 Sep 2006 22:41:46 +1000 | From | Nick Piggin <> | Subject | Re: Bad page state with x86_64 |
| |
Andreas Block wrote: > Hi, > > the following problem occurs with a driver "pa_drv" written by myself > under x84_64. Code works fine under x86_32 and with small modifications > also under ppc. Problem also occurs under 2.6.15-1.2054_FC5. > > > Bad page state in process 'pa_test' > page:ffff810000869000 flags:0x0100000000000414 mapping:0000000000000000 > mapcount:0 count:0 > Trying to fix it up, but a reboot is needed > Backtrace: > > Call Trace: > [<ffffffff802642a4>] bad_page+0x4e/0x78 > [<ffffffff80264591>] free_hot_cold_page+0x73/0xff > [<ffffffff8026c24e>] unmap_vmas+0x440/0x756 > [<ffffffff8026f8f7>] unmap_region+0xb9/0x12c > [<ffffffff802705eb>] do_munmap+0x1fd/0x27a > [<ffffffff8043ed3d>] __down_write_nested+0x34/0x9e > [<ffffffff802706a8>] sys_munmap+0x40/0x5a > [<ffffffff80222508>] cstar_do_call+0x1b/0x65 > > ----------- [cut here ] --------- [please bite here ] --------- > Kernel BUG at include/linux/mm.h:300 > invalid opcode: 0000 [1] SMP > CPU 0 > Modules linked in: pa_drv_k26 radeon drm autofs4 hidp nfs lockd nfs_acl > rfcomm l2cap bluetooth sunrpc dm_mirror dm_mod video button battery > asus_acpi ac ipv6 lp parport_pc parport floppy nvram snd_intel8x0 > snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_oss > snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss > snd_pcm ehci_hcd ohci1394 ieee1394 ohci_hcd snd_timer snd soundcore > i2c_nforce2 forcedeth i2c_core pcspkr snd_page_alloc ext3 jbd sata_nv > libata sd_mod scsi_mod > Pid: 2722, comm: pa_test Tainted: G B 2.6.18 #1 > RIP: 0010:[<ffffffff802647e7>] [<ffffffff802647e7>] __free_pages+0x7/0x2b > RSP: 0018:ffff8100064cfea0 EFLAGS: 00010246 > RAX: 0000000000000000 RBX: ffff810012729ac0 RCX: 000000000000003f > RDX: 000000000001fff0 RSI: 0000000000000005 RDI: ffff810000869000 > RBP: 0000000000005001 R08: 000000000804b02c R09: 00000000fff5a218 > R10: 0000000000005001 R11: 0000000000005001 R12: 0000000000000000 > R13: 0000000000005001 R14: ffff81001f534320 R15: ffff810012729ac0 > FS: 00002acba44ea340(0000) GS:ffffffff8061f000(0063) > knlGS:00000000f7faf6b0 > CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b > CR2: 00000000f7fb1000 CR3: 000000000714e000 CR4: 00000000000006e0 > Process pa_test (pid: 2722, threadinfo ffff8100064ce000, task > ffff81000aaaa100) > Stack: ffffffff885071b2 ffff810012729ac0 ffffffff885071e5 0000000000000000 > ffffffff88507373 0000000000000000 0000000000000000 0000000000000000 > 0000000000000000 0000000000000000 0000000000000000 0000000000005001 > Call Trace: > [<ffffffff885071b2>] :pa_drv_k26:pa_free_local_buffer+0x1b/0x3b > [<ffffffff885071e5>] :pa_drv_k26:pa_destroy_local+0x13/0x17 > [<ffffffff88507373>] :pa_drv_k26:pa_ioctl_unlocked+0x166/0x272 > [<ffffffff802ad503>] compat_sys_ioctl+0xc5/0x2b2 > [<ffffffff80222508>] cstar_do_call+0x1b/0x65 > > > Code: 0f 0b 68 8e f5 46 80 c2 2c 01 90 ff 4f 08 0f 94 c0 84 c0 74 > RIP [<ffffffff802647e7>] __free_pages+0x7/0x2b > RSP <ffff8100064cfea0> > > > I've a stripped down example, which reproduces the problem shown below. > I'll happily sent an archive containing, code of driver, library and > test application to anybody, who likes to spend a look at it or attach > it to a mail to this list, if I'm allowed to do so. > > Note: I'm not blaming the kernel to be buggy. It may well be, that the > source of the problem sits between my keyboard and my chair, but I'd be > very grateful for any advice on what I'm doing wrong, if so.
It is freeing a PageReserved page. You should ensure to balance your reference counting on *each* page (or allocate a compound page and treat it as a single one). When you map pages into userspace via nopage or remap_pfn_range, you need to increment their count, which gets decremented by the VM when they are unmapped.
-- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |