[RFC] linux-2.6.22-rc2. SLUB report[kzalloc(0)]
Hi. There is a BUG message from SLUB during boot process: -- May 21 05:39:10 midgard kernel: [ 31.177484] BUG: at include/linux/slub_def.h:77 kmalloc_index() May 21 05:39:10 midgard kernel: [ 31.178355] [] show_trace_log_lvl+0x1a/0x30 May 21 05:39:10 midgard kernel: [ 31.179263] [] show_trace +0x12/0x20 May 21 05:39:10 midgard kernel: [ 31.180177] [] dump_stack +0x16/0x20 May 21 05:39:10 midgard kernel: [ 31.181094] [] get_slab +0x1cd/0x260 May 21 05:39:10 midgard kernel: [ 31.182024] [] __kmalloc_track_caller+0x19/0xa0 May 21 05:39:10 midgard kernel: [ 31.183019] [] __kzalloc +0x19/0x50 May 21 05:39:10 midgard kernel: [ 31.184012] [] usb_get_configuration+0x9de/0x11c0 [usbcore] May 21 05:39:10 midgard kernel: [ 31.185115] [] usb_new_device+0x17/0x190 [usbcore] May 21 05:39:10 midgard kernel: [ 31.186181] [] hub_thread +0x79a/0xfd0 [usbcore] May 21 05:39:10 midgard kernel: [ 31.187185] [] kthread +0x42/0x70 May 21 05:39:10 midgard kernel: [ 31.188190] [] kernel_thread_helper+0x7/0x10 -- kzalloc(0, GFP_KERNEL) occurs in drivers/usb/core/config.c in usb_get_configuration function. I already wrote about this slub bug report and offered a patch(http://www.uwsg.iu.edu/hypermail/linux/kernel/0705.1/0154.html). I don't know, may be it is not major thing, if it is, just ignore it. I just think, that -- length = ncfg * sizeof(struct usb_host_config); dev->config = kzalloc(length, GFP_KERNEL); -- isn't clear, because ncfg - in my case - is 0 and I suppose, that size of the leastest slab cache can become(in future) smaller than sizeof(struct usb_host_config). Thanks for attention. -- Dan Kruchinin <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/ I have the following message after kernel compilation: --- ... WARNING: init/built-in.o - Section mismatch: reference to .init.text: from .text between 'rest_init' (at offset 0x11e) and 'try_name' ... ... WARNING: drivers/dma/async_tx.o - Section mismatch: reference to .init.data: from .data after 'channel_table' (at offset 0x20) WARNING: drivers/dma/async_tx.o - Section mismatch: reference to .init.data: from .data after 'channel_table' (at offset 0x24) WARNING: drivers/dma/async_tx.o - Section mismatch: reference to .init.data: from .data after 'channel_table' (at offset 0x28) WARNING: drivers/dma/async_tx.o - Section mismatch: reference to .init.data: from .data after 'channel_table' (at offset 0x2c) WARNING: drivers/dma/async_tx.o - Section mismatch: reference to .init.data: from .data after 'channel_table' (at offset 0x30) WARNING: drivers/dma/async_tx.o - Section mismatch: reference to .init.data: from .data after 'channel_table' (at offset 0x34) WARNING: drivers/dma/async_tx.o - Section mismatch: reference to .init.data: from .data after 'channel_table' (at offset 0x38) WARNING: drivers/dma/async_tx.o - Section mismatch: reference to .init.data: from .data after 'channel_table' (at offset 0x3c) WARNING: drivers/dma/async_tx.o - Section mismatch: reference to .init.data: from .data after 'channel_table' (at offset 0x40) WARNING: drivers/dma/async_tx.o - Section mismatch: reference to .init.data: from .data after 'channel_table' (at offset 0x44) -- Dan Kruchinin. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -mm] drivers/usb/core/config.c: kzalloc(0,..)
The following patch fixes such SLUB report(when someone tries to allocate 0 bytes): -- May 8 00:19:15 midgard kernel: [ 21.933467] BUG: at include/linux/slub_def.h:88 kmalloc_index() May 8 00:19:15 midgard kernel: [ 21.933470] [show_registers+410/736] show_trace_log_lvl+0x1a/0x30 May 8 00:19:15 midgard kernel: [ 21.933478] [print_trace_warning_symbol+50/64] show_trace+0x12/0x20 May 8 00:19:15 midgard kernel: [ 21.933482] [fixup_irqs+38/192] dump_stack+0x16/0x20 May 8 00:19:15 midgard kernel: [ 21.933485] [do_lookup+195/400] get_slab+0x213/0x230 May 8 00:19:15 midgard kernel: [ 21.933489] [do_lookup+309/400] __kmalloc_track_caller+0x15/0x40 May 8 00:19:15 midgard kernel: [ 21.933493] [__vunmap+25/240] __kzalloc+0x19/0x50 May 8 00:19:15 midgard kernel: [ 21.933498] [] usb_parse_configuration+0x85e/0xe70 [usbcore] May 8 00:19:15 midgard kernel: [ 21.933520] [] usb_get_configuration+0x12b/0x450 [usbcore] May 8 00:19:15 midgard kernel: [ 21.933535] [] usb_new_device+0x17/0x1c0 [usbcore] May 8 00:19:15 midgard kernel: [ 21.933550] [] hub_thread+0x79a/0xfd0 [usbcore] May 8 00:19:15 midgard kernel: [ 21.933564] [run_posix_cpu_timers+1218/2064] kthread+0x42/0x70 May 8 00:19:15 midgard kernel: [ 21.933569] [math_error+87/240] kernel_thread_helper+0x7/0x10 May 8 00:19:15 midgard kernel: [ 21.933572] === -- The problem was in drivers/usb/core/config.c in function usb_parse_interface: --- num_ep = num_ep_orig = alt->desc.bNumEndpoints; ... len = sizeof(struct usb_host_endpoint) * num_ep; alt->endpoint = kzalloc(len, GFP_KERNEL); --- num_ep can be 0, as it was in my case, so following patch makes this situation more obvious and clear. -- diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c index bfb3731..4db6b21 100644 --- a/drivers/usb/core/config.c +++ b/drivers/usb/core/config.c @@ -185,7 +185,10 @@ static int usb_parse_interface(struct device *ddev, int cfgno, num_ep = USB_MAXENDPOINTS; } - len = sizeof(struct usb_host_endpoint) * num_ep; + len = sizeof(struct usb_host_endpoint); + if (num_ep > 0) + len *= num_ep; + alt->endpoint = kzalloc(len, GFP_KERNEL); if (!alt->endpoint) return -ENOMEM; ------- Dan Kruchinin. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [PATCH -mm] drivers/usb/core/config.c: kzalloc(0, ..)
On 5/8/07, Randy Dunlap <[EMAIL PROTECTED]> wrote: On Tue, 8 May 2007 11:57:07 -0400 (EDT) Alan Stern wrote: > On Tue, 8 May 2007, Greg KH wrote: > > > > The problem was in drivers/usb/core/config.c in function > > > usb_parse_interface: > > > --- > > > num_ep = num_ep_orig = alt->desc.bNumEndpoints; > > > ... > > > len = sizeof(struct usb_host_endpoint) * num_ep; > > > alt->endpoint = kzalloc(len, GFP_KERNEL); > > > --- > > > > > > num_ep can be 0, as it was in my case, so following patch makes this > > > situation more obvious > > > and clear. > > How about instead just doing: > > + num_ep = max(num_ep, 1); > len = sizeof(struct usb_host_endpoint) * num_ep; > > Also, wasn't it true at one point that it was legal to call kmalloc() with > a length of 0? ISTR seeing somewhere that it's true for regular malloc(). kmalloc(0) was legal with CONFIG_SLAB=y. However, there is now something called SLUB, which just returned an error when size == 0. SLUB works correctly with kmalloc(0) too, but it calls WARN_ON_ONCE(size == 0); in include/linux/slub_def.h: kmalloc_index. btw: as I know when kmalloc(0) both slub and slab allocate the smallest possible size. Can this size be smaller than sizeof(struct usb_host_endpoint)? If it is, may it be a problem? thanks. Dan Kruchinin. It has recently been modified to mirror the SLAB behavior but also do a stack dump so that "bad" callers can be fixed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how to purposfully fragment memory?
On 3/20/07, Chris Friesen <[EMAIL PROTECTED]> wrote: Asgard wrote: > btw, can you describe your aim in details? I'm doing some work on a network device driver. We were having jumbo frame issues after being up for a month or so because it couldn't allocate enough contiguous memory. We've got a new code path now that doesn't need large contiguous allocations, so I'd like to demonstrate it by forcing the system to become severely fragmented. Chris and by the way, you can try to use void split_page(struct page *page, unsigned int order) function, but keep in mind, that it's not recommended to use it in drivers: /* * split_page takes a non-compound higher-order page, and splits it into * n (1
Re: menuconfig issue (checklist) in 2.6.20.7 & 2.6.21-rc7 ?
laration of function ' print_item' scripts/kconfig/lxdialog/checklist.c:192: warning: implicit declaration of function ' print_arrows' scripts/kconfig/lxdialog/checklist.c:195: warning: implicit declaration of function ' print_buttons' scripts/kconfig/lxdialog/checklist.c:197: warning: implicit declaration of function ' wnoutrefresh' scripts/kconfig/lxdialog/checklist.c:199: warning: implicit declaration of function ' doupdate' scripts/kconfig/lxdialog/checklist.c:202: warning: implicit declaration of function ' wgetch' scripts/kconfig/lxdialog/checklist.c:210: error: 'KEY_UP' undeclared (first use in th is function) scripts/kconfig/lxdialog/checklist.c:210: error: 'KEY_DOWN' undeclared (first use in this function) scripts/kconfig/lxdialog/checklist.c:220: error: 'FALSE' undeclared (first use in thi s function) scripts/kconfig/lxdialog/checklist.c:221: warning: implicit declaration of function ' scrollok' scripts/kconfig/lxdialog/checklist.c:222: warning: implicit declaration of function ' wscrl' scripts/kconfig/lxdialog/checklist.c:232: warning: implicit declaration of function ' wrefresh' scripts/kconfig/lxdialog/checklist.c:293: warning: implicit declaration of function ' delwin' scripts/kconfig/lxdialog/checklist.c:297: error: 'KEY_LEFT' undeclared (first use in this function) scripts/kconfig/lxdialog/checklist.c:298: error: 'KEY_RIGHT' undeclared (first use in this function) scripts/kconfig/lxdialog/checklist.c:310: warning: implicit declaration of function ' on_key_esc' scripts/kconfig/lxdialog/checklist.c:312: error: 'KEY_RESIZE' undeclared (first use i n this function) make[1]: *** [scripts/kconfig/lxdialog/checklist.o] Error 1 make: *** [menuconfig] Error 2 ~Akula2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ you should install ncurses library: ---> scripts/kconfig/lxdialog/dialog.h:32:20: error: curses.h: No such file ---> or directory good luck. Dan Kruchinin. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc7-mm1: Oops and Gnome desktop freezes
f Call Trace: [] show_trace_log_lvl+0x1a/0x30 [] show_stack_log_lvl+0x9b/0xaa [] show_registers+0x1b6/0x288 [] die+0xe7/0x1fc [] do_page_fault+0x429/0x4f8 [] error_code+0x71/0x78 [] __handle_mm_fault+0x12f/0x5fc [] do_page_fault+0x1fe/0x4f8 [] error_code+0x71/0x78 === INFO: lockdep is turned off. Code: 00 00 8b 45 d0 ba 03 00 00 00 e8 9d fa fb ff ba 04 00 00 00 89 45 bc 89 d8 e8 8e fa fb ff b9 00 04 00 00 8b 75 bc 89 45 b8 89 c7 a5 8b 45 bc ba 03 00 00 00 e8 dc fa fb ff 8b 45 b8 ba 04 00 EIP: [] __do_fault+0x17a/0x301 SS:ESP 0068:d7ad9ea8 note: smart[4687] exited with preempt_count 2 BUG: scheduling while atomic: smart/0x1002/4687 INFO: lockdep is turned off. [] show_trace_log_lvl+0x1a/0x30 [] show_trace+0x12/0x14 [] dump_stack+0x16/0x18 [] __sched_text_start+0x71/0x553 [] __cond_resched+0x28/0x3f [] cond_resched+0x29/0x34 [] down_read+0x1d/0x50 [] exit_mm+0x2b/0xc3 [] do_exit+0x1f8/0x744 [] die+0x1d6/0x1fc [] do_page_fault+0x429/0x4f8 [] error_code+0x71/0x78 [] __handle_mm_fault+0x12f/0x5fc [] do_page_fault+0x1fe/0x4f8 [] error_code+0x71/0x78 === - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ I have just the same tracing, but my gnome desktop works pretty good until I launch some application which "eats" much mem, like evince or firefox. After it my X server automatically restarts . Dan Kruchinin. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc7-mm2
g-fb_check_var.patch +s3fb-driver-fixes.patch +vmlfb-framebuffer-driver-for-intel-vermilion-range.patch +nvidiafb-rivafb-switch-to-pci_get-refcounting.patch +pm2fb-3dlabs-permedia-2v-reference-board-added.patch +pm2fb-permedia-2v-memory-clock-setting.patch +pm2fb-pixclock-setting-restriction.patch +nvidiafb-prevent-triggering-of-softlockup.patch fbdev bugstomp -cfq-debugging-stuff.patch Dropped due to rejects All 1993 patches: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/patch-list - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ I have troubles with rtc on my macbook with mm2: [126588.386116] rtc: lost some interrupts at 1024Hz. [126588.404842] rtc: lost some interrupts at 1024Hz. [126588.423566] rtc: lost some interrupts at 1024Hz. [126588.442292] rtc: lost some interrupts at 1024Hz. [126588.461016] rtc: lost some interrupts at 1024Hz. [126588.479741] rtc: lost some interrupts at 1024Hz. [126588.498466] rtc: lost some interrupts at 1024Hz. [126588.517198] rtc: lost some interrupts at 1024Hz. [126588.535923] rtc: lost some interrupts at 1024Hz. [126588.554643] rtc: lost some interrupts at 1024Hz. cat /proc/sys/dev/rtc/max-user-freq 64 On 2.6.20 there wasn't such problem. Thanks. Dan Kruchinin. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.21-rc7-mm2 suspend bug. [kernel/kthread.c]
00:00:1c.0[A] -> GSI 17 (level, low) -> IRQ 17 Apr 29 23:31:16 midgard kernel: [18014366.895025] ACPI: PCI Interrupt :00:1c.1[B] -> GSI 16 (level, low) -> IRQ 16 Apr 29 23:31:16 midgard kernel: [18014366.895039] PCI: Enabling device :00:1d.0 ( -> 0001) Apr 29 23:31:16 midgard kernel: [18014366.895042] ACPI: PCI Interrupt :00:1d.0[A] -> GSI 21 (level, low) -> IRQ 21 Apr 29 23:31:16 midgard kernel: [18014366.895104] usb usb1: root hub lost power or was reset Apr 29 23:31:16 midgard kernel: [18014366.895141] PCI: Enabling device :00:1d.1 ( -> 0001) Apr 29 23:31:16 midgard kernel: [18014366.895144] ACPI: PCI Interrupt :00:1d.1[B] -> GSI 19 (level, low) -> IRQ 19 Apr 29 23:31:16 midgard kernel: [18014366.895204] usb usb2: root hub lost power or was reset Apr 29 23:31:16 midgard kernel: [18014366.895237] PCI: Enabling device :00:1d.2 ( -> 0001) Apr 29 23:31:16 midgard kernel: [18014366.895240] ACPI: PCI Interrupt :00:1d.2[C] -> GSI 18 (level, low) -> IRQ 18 Apr 29 23:31:16 midgard kernel: [18014366.895299] usb usb3: root hub lost power or was reset Apr 29 23:31:16 midgard kernel: [18014366.895328] PCI: Enabling device :00:1d.3 ( -> 0001) Apr 29 23:31:16 midgard kernel: [18014366.895331] ACPI: PCI Interrupt :00:1d.3[D] -> GSI 16 (level, low) -> IRQ 16 Apr 29 23:31:16 midgard kernel: [18014366.895391] usb usb4: root hub lost power or was reset Apr 29 23:31:16 midgard kernel: [18014366.909854] PCI: Enabling device :00:1d.7 ( -> 0002) Apr 29 23:31:16 midgard kernel: [18014366.909857] ACPI: PCI Interrupt :00:1d.7[A] -> GSI 21 (level, low) -> IRQ 21 Apr 29 23:31:16 midgard kernel: [18014366.910032] ACPI: PCI Interrupt :00:1f.1[A] -> GSI 18 (level, low) -> IRQ 18 Apr 29 23:31:16 midgard kernel: [18014366.924871] ACPI: PCI Interrupt :00:1f.2[B] -> GSI 19 (level, low) -> IRQ 19 Apr 29 23:31:16 midgard kernel: [18014366.939965] sky2 eth0: enabling interface Apr 29 23:31:16 midgard kernel: [18014366.941763] sky2 eth0: ram buffer 48K Apr 29 23:31:16 midgard kernel: [18014367.006976] ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[19] MMIO=[9000-97ff] Max Packet=[2048] IR/IT contexts=[8/8] ... --- Thanks. Dan Kruchinin. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc7-mm2 suspend bug. [kernel/kthread.c]
On 4/30/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: [Please don't drop addresses from the CC list] On Sunday, 29 April 2007 22:46, Dan Kruchinin wrote: > On 4/30/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > Hi, > > > > On Sunday, 29 April 2007 21:51, Dan Kruchinin wrote: > > > Hi all. > > > > > > There is a problem on my macbook core duo with suspend. > > > after suspending when i'm trying to 'wake up' my notebook, it seems > > > that it works, but i don't see anything at my monitor. So i have to > > > reboot it to continue my work. > > > > What exactly do you do to suspend? > > > > Rafael > > > > > > > --- > > > Apr 29 23:31:16 midgard kernel: [140594.900856] BUG: at > > > kernel/kthread.c:166 kthread_bind() > > > Apr 29 23:31:16 midgard kernel: [140594.900870] [] > > > _cpu_down+0x16b/0x250 > > > Apr 29 23:31:16 midgard kernel: [140594.900893] [] > > > disable_nonboot_cpus+0x60/0xf0 > > > Apr 29 23:31:16 midgard kernel: [140594.900903] [] > > > enter_state+0x22a/0x240 > > > Apr 29 23:31:16 midgard kernel: [140594.900913] [] > > > state_store+0xbd/0xd0 > > > Apr 29 23:31:16 midgard kernel: [140594.900920] [] > > > state_store+0x0/0xd0 > > > Apr 29 23:31:16 midgard kernel: [140594.900927] [] > > > subsys_attr_store+0x29/0x40 > > > Apr 29 23:31:16 midgard kernel: [140594.900937] [] > > > sysfs_write_file+0xd4/0x160 > > > Apr 29 23:31:16 midgard kernel: [140594.900948] [] > > > vfs_write+0xa6/0x160 > > > Apr 29 23:31:16 midgard kernel: [140594.900958] [] > > > sysfs_write_file+0x0/0x160 > > > Apr 29 23:31:16 midgard kernel: [140594.900966] [] > > > sys_write+0x41/0x70 > > > Apr 29 23:31:16 midgard kernel: [140594.900974] [] > > > sys_dup2+0xeb/0x120 > > > Apr 29 23:31:16 midgard kernel: [140594.900984] [] > > > sysenter_past_esp+0x5f/0x85 > > > Apr 29 23:31:16 midgard kernel: [140594.900999] === > > > --- > > > > > > dmesg output: > > > > > > > > > Apr 29 23:31:16 midgard kernel: [140594.788697] Suspending device vtcon0 > > > Apr 29 23:31:16 midgard kernel: [140594.788700] Suspending device platform > > > Apr 29 23:31:16 midgard kernel: [140594.788704] Disabling non-boot CPUs ... > > > Apr 29 23:31:16 midgard kernel: [140594.900464] CPU 1 is now offline > > > Apr 29 23:31:16 midgard kernel: [140594.900469] SMP alternatives: > > > switching to UP code > > > Apr 29 23:31:16 midgard kernel: [140594.900856] BUG: at > > > kernel/kthread.c:166 kthread_bind() > > > Apr 29 23:31:16 midgard kernel: [140594.900870] [] > > > _cpu_down+0x16b/0x250 > > > Apr 29 23:31:16 midgard kernel: [140594.900893] [] > > > disable_nonboot_cpus+0x60/0xf0 > > > Apr 29 23:31:16 midgard kernel: [140594.900903] [] > > > enter_state+0x22a/0x240 > > > Apr 29 23:31:16 midgard kernel: [140594.900913] [] > > > state_store+0xbd/0xd0 > > > Apr 29 23:31:16 midgard kernel: [140594.900920] [] > > > state_store+0x0/0xd0 > > > Apr 29 23:31:16 midgard kernel: [140594.900927] [] > > > subsys_attr_store+0x29/0x40 > > > Apr 29 23:31:16 midgard kernel: [140594.900937] [] > > > sysfs_write_file+0xd4/0x160 > > > Apr 29 23:31:16 midgard kernel: [140594.900948] [] > > > vfs_write+0xa6/0x160 > > > Apr 29 23:31:16 midgard kernel: [140594.900958] [] > > > sysfs_write_file+0x0/0x160 > > > Apr 29 23:31:16 midgard kernel: [140594.900966] [] > > > sys_write+0x41/0x70 > > > Apr 29 23:31:16 midgard kernel: [140594.900974] [] > > > sys_dup2+0xeb/0x120 > > > Apr 29 23:31:16 midgard kernel: [140594.900984] [] > > > sysenter_past_esp+0x5f/0x85 > > > Apr 29 23:31:16 midgard kernel: [140594.900999] === > > > Apr 29 23:31:16 midgard kernel: [140594.902843] CPU1 is down > > > Apr 29 23:31:16 midgard kernel: [18014366.415769] Enabling non-boot CPUs ... > > > Apr 29 23:31:16 midgard kernel: [18014366.426999] SMP alternatives: > > > switching to SMP code > > > Apr 29 23:31:16 midgard kernel: [18014366.427165] Booting processor 1/1 eip 3000 > > > Apr 29 23:31:16 midgard kernel: [18014366.436913] Initializing CPU#1 > > > Apr 29 23:31:16 midgard kernel: [18014366.509141] Calibrating delay > > > using timer specific routine.. 3994.69 BogoMIPS (lpj=7989390) > > > Apr 29 23:31:1
[RFC BUG?] dereference PAGE_OFFSET address (rc7-mm2)
Hi.
I don't know why, but when I'm dereferencing PAGE_OFFSET(0xC000 on
x86) address from user space on rc7-mm2 I don't receive SIGSEGV signal
and there is no any core dump.
btw: on poor rc-7 all is ok.
test_code:
---
#include
#include
#include
#include
#include
#include
#include
#include
#define PAGE_OFFSET 0xC000
static void _error(const char *msg)
{
int errcode = errno;
fprintf(stderr, "ERROR:\n--> %s [%s]\n", msg, strerror(errcode));
exit(EXIT_FAILURE);
}
int main(void)
{
int pid;
struct rlimit rl;
int status;
printf("Trying to cause ELF core dump...\n");
rl.rlim_cur = rl.rlim_max = 0x1000;
if(setrlimit(RLIMIT_CORE, &rl) < 0)
_error("setrlim error!");
if((pid = fork()) < 0)
_error("fork error!");
else if(pid == 0) {
*((long*) PAGE_OFFSET ) = 0; /* trying to dereference kernel start
address */
_exit(EXIT_SUCCESS);
}
if(waitpid(pid, &status, 0) < 0)
_error("waitpid error!");
if(WCOREDUMP(status))
printf("All is ok. We receive SIGSEGV and core dump has occured.\n");
else
printf("All is bad. We don't receive SIGSEGV and core dump hasn't
occured. (WHY?!)\n"); /* here I just get SIGCHLD, this means that
child process have made it's work success... */
exit(EXIT_SUCCESS);
}
---
[EMAIL PROTECTED] uname -a
Linux midgard 2.6.21-rc7-mm2 #5 SMP Wed May 2 04:15:09 MSD 2007 i686 GNU/Linux
[EMAIL PROTECTED] ./a.out
Trying to cause ELF core dump...
All is bad. We don't receive SIGSEGV and core dump hasn't occured. (WHY?!)
---
[EMAIL PROTECTED] uname -a
Linux midgard 2.6.21-rc7 #5 SMP Wed May 2 02:11:50 MSD 2007 i686 GNU/Linux
[EMAIL PROTECTED] ./a.out
Trying to cause ELF core dump...
All is ok. We receive SIGSEGV and core dump has occured.
With best regards.
Dan Kruchinin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
