lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list] 
Message-ID: <20090111183600.GA2728@ds20.borg.net>
Date:	Sun, 11 Jan 2009 18:36:00 +0000
From:	Thorsten Kranzkowski <dl8bcu@...bcu.de>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-mm@...ck.org, klausman@...warzvogel.de
Subject: Re: WARNING in vmap_page_range on alpha since 2.6.28

On Sun, Jan 11, 2009 at 03:18:55PM +0100, Tobias Klausmann wrote:
> Hi! 
> 
> I've stumbled across this WARNING: when booting 2.6.28 + patch
> on my alpha. This happens consistently (i.e. on every boot) and
> keeps happening while the machine is booted:
> 
> ------------[ cut here ]------------
> WARNING: at mm/vmalloc.c:104 vmap_page_range+0x1b8/0x320()
> Modules linked in:
> fffffc007f03b968 0000000000000003 fffffc0000377e48 fffffffc00002000 
>        fffffffc00008000 0000000000000003 6761705f70616d76 2b65676e61725f65 
>        78302f3862317830 0000000000303233 fffffc00006f0828 0000000000000000 
>        fffffc00006efcd8 fffffc00006efcd8 fffffc00006f0830 0000000000000000 
>        0000000000000000 fffffc00006efd18 0000000000000001 00000000000200d2 
>        0000000000000000 0000000000000000 0000000000000001 0000000000000044 
> Trace:
> [<fffffc0000377e48>] vmap_page_range+0x1b8/0x320
> [<fffffc0000379288>] __vmalloc_area_node+0xb8/0x1b0
> [<fffffc0000377fe4>] map_vm_area+0x34/0x60
> [<fffffc0000379320>] __vmalloc_area_node+0x150/0x1b0
> [<fffffc00003792cc>] __vmalloc_area_node+0xfc/0x1b0
> [<fffffc00004da5d4>] agp_add_bridge+0x1a4/0x610
> [<fffffc00005d2858>] agp_amdk7_probe+0x17c/0x2ec
> [<fffffc000049627c>] pci_device_probe+0x8c/0xc0
> [<fffffc00004ff1b8>] driver_probe_device+0xa8/0x230
> [<fffffc00004ff41c>] __driver_attach+0xdc/0xe0
> [<fffffc00004fe698>] bus_for_each_dev+0x78/0xd0
> [<fffffc00004ff340>] __driver_attach+0x0/0xe0
> [<fffffc00004fef5c>] driver_attach+0x2c/0x40
> [<fffffc00004fdccc>] bus_add_driver+0x28c/0x340
> [<fffffc00004ff6e4>] driver_register+0x94/0x1d0
> [<fffffc00004965e4>] __pci_register_driver+0x64/0xf0
> [<fffffc0000310084>] do_one_initcall+0x34/0x1e0
> [<fffffc00003db60c>] proc_register+0x6c/0x280
> [<fffffc00003db5f0>] proc_register+0x50/0x280
> [<fffffc00003db9bc>] create_proc_entry+0x7c/0x100
> [<fffffc000035597c>] register_irq_proc+0xbc/0xe0
> [<fffffc0000355a14>] init_irq_proc+0x74/0xa0
> [<fffffc0000311158>] kernel_thread+0x28/0x90
> [<fffffc0000310d84>] entSys+0xa4/0xc0
> 
> ---[ end trace 9863e03dd539368c ]---


I see similar traces:

------------[ cut here ]------------
WARNING: at /export/data/scm/linux-2.6/mm/vmalloc.c:104 vmap_page_range+0x1c4/0x264()
Modules linked in:
fffffc007e303ae8 0000000000000000 fffffc00003823e0 fffffffc00188000 
       fffffc0000aee000 fffffc0000a57ac0 6761705f70616d76 2b65676e61725f65 
       78302f3463317830 0000000000343632 fffffc0000a58fc8 00000000000200d2 
       0000000000000000 0000000000000000 0000000000000001 0000000000000044 
       fffffc0000a57c00 0000000000000000 0000000000000000 00000000000200d2 
       ffffffffffe80000 0000000000000001 0000000000000000 fffffffc00000000 
Trace:
[<fffffc00003823e0>] vmap_page_range+0x1c4/0x264
[<fffffc0000381e0c>] alloc_pages_node+0x38/0x4c
[<fffffc00003824b4>] map_vm_area+0x34/0x58
[<fffffc0000382628>] __vmalloc_area_node+0x150/0x18c
[<fffffc00006e1bc8>] dm_ctl_ioctl+0x1c8/0x38c
[<fffffc00006dfe08>] dev_status+0x0/0x70
[<fffffc00003a14d8>] vfs_ioctl+0x3c/0xd0
[<fffffc00003a1ac4>] do_vfs_ioctl+0x558/0x5a8
[<fffffc00003a1b78>] sys_ioctl+0x64/0xa8
[<fffffc0000337708>] do_softirq+0x58/0x70
[<fffffc000031a404>] smp_percpu_timer_interrupt+0xa4/0xf0
[<fffffc00003a1b50>] sys_ioctl+0x3c/0xa8
[<fffffc0000310fa4>] entSys+0xa4/0xc0

---[ end trace a7919e7f17c0a725 ]---
------------[ cut here ]------------
WARNING: at /export/data/scm/linux-2.6/mm/vmalloc.c:104 vmap_page_range+0x1c4/0x264()
Modules linked in:
fffffc007e303ae8 0000000000000000 fffffc00003823e0 fffffffc00190000 
       fffffc0000aee000 fffffc0000a57ac0 6761705f70616d76 2b65676e61725f65 
       78302f3463317830 0000000000343632 fffffc0000a58fc8 00000000000200d2 
       0000000000000000 0000000000000000 0000000000000001 0000000000000044 
       fffffc0000a57c00 0000000000000000 0000000000000000 00000000000200d2 
       ffffffffffe80000 0000000000000001 0000000000000000 fffffffc00000000 
Trace:
[<fffffc00003823e0>] vmap_page_range+0x1c4/0x264
[<fffffc0000381e0c>] alloc_pages_node+0x38/0x4c
[<fffffc00003824b4>] map_vm_area+0x34/0x58
[<fffffc0000382628>] __vmalloc_area_node+0x150/0x18c
[<fffffc00006e1bc8>] dm_ctl_ioctl+0x1c8/0x38c
[<fffffc00006dfe08>] dev_status+0x0/0x70
[<fffffc00003a14d8>] vfs_ioctl+0x3c/0xd0
[<fffffc00003a1ac4>] do_vfs_ioctl+0x558/0x5a8
[<fffffc00003a1b78>] sys_ioctl+0x64/0xa8
[<fffffc0000392bf8>] sys_write+0x64/0x9c
[<fffffc00003a1b50>] sys_ioctl+0x3c/0xa8
[<fffffc0000310fa4>] entSys+0xa4/0xc0

---[ end trace a7919e7f17c0a725 ]---



For me they are occurring during invocation of 'lvm vgchange -a y'. 
The first call also fails, i.e. '0 volume groups activated',
while a second call succeeds and activates both of the VGs it should handle.

The traces above were taken from dmesg. They are not the first ones as there
are quite a lot of them  (perhaps one for every block device checked by
the lvm tool?) and so the initial ones already escaped the message buffer.


> Here's a full dmesg:
> http://eric.schwarzvogel.de/~klausman/kernel/2.6.28/alpha/dmesg_post_boot.txt
> 
> Note that it happens again later in the same dmesg. The messages
> always mention page allocation at the top of the trace.
> 
> The patch mentioned above is commit
> 1684f5ddd4c0c754f52c78eaa2c5c69ad09fb18c which fixes compilation
> on alpha (see http://bugzilla.kernel.org/show_bug.cgi?id=12289)
> The patch I used is here:
> http://eric.schwarzvogel.de/~klausman/kernel/2.6.28/alpha/pci.patch

this is my local fix to this build problem:


diff --git a/arch/alpha/include/asm/core_tsunami.h b/arch/alpha/include/asm/core_tsunami.h
index 58d4fe4..8e39ecf 100644
--- a/arch/alpha/include/asm/core_tsunami.h
+++ b/arch/alpha/include/asm/core_tsunami.h
@@ -2,7 +2,6 @@
 #define __ALPHA_TSUNAMI__H__
 
 #include <linux/types.h>
-#include <linux/pci.h>
 #include <asm/compiler.h>
 
 /*


I think some of the other core_*.h files need it, too.
 
> Here's my config:
> http://eric.schwarzvogel.de/~klausman/kernel/2.6.28/alpha/config.txt
> shortened by grep ^C:
> http://eric.schwarzvogel.de/~klausman/kernel/2.6.28/alpha/config-shortened.txt
> 
> The normal console output (catched via serial console) is here:
> http://eric.schwarzvogel.de/~klausman/kernel/2.6.28/alpha/console_output.txt
> 
> The machine in question is a Samsung UP1500. CPU is EV68AL on an
> ALI chipset (ali15x3). 

DS20, dual EV6
 
> Last kernel to work perfectly is a vanilla 2.6.27.10.
> 
> Before I dig into a rather time-consuming bisect, I'd like to
> hear informed opinions :)




bye,
Thorsten

-- 
| Thorsten Kranzkowski        Internet: dl8bcu@...bcu.de                      |
| Mobile: ++49 170 1876134       Snail: Kiebitzstr. 14, 49324 Melle, Germany  |
| Ampr: dl8bcu@...lj.#rpl.deu.eu, dl8bcu@...vin.dl8bcu.ampr.org [44.130.8.19] |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ