* Re: mmotm 2009-04-24-18-14 uploaded - NVidia indigestion
[not found] <200904250133.n3P1XBJn006790@imap1.linux-foundation.org>
@ 2009-04-25 3:06 ` Valdis.Kletnieks
2009-04-25 5:24 ` Nick Piggin
2009-04-25 3:52 ` mmotm 2009-04-24-18-14 uploaded - pulseaudio causes BUG Valdis.Kletnieks
1 sibling, 1 reply; 10+ messages in thread
From: Valdis.Kletnieks @ 2009-04-25 3:06 UTC (permalink / raw)
To: Andrew Morton, Nick Piggin; +Cc: linux-kernel, mm-commits
[-- Attachment #1: Type: text/plain, Size: 2708 bytes --]
On Fri, 24 Apr 2009 18:14:22 PDT, akpm@linux-foundation.org said:
> The mm-of-the-moment snapshot 2009-04-24-18-14 has been uploaded to
>
> http://userweb.kernel.org/~akpm/mmotm/
This jumped out and asked if I wanted SLQB as the default allocator (even
though I've had SLAB defined for ages). I said to myself "what the heck"
and accepted the change...
Tried to build the NVidia binary, and it choked during config on something
that will likely give a *lot* of programs indigestion.
The test program:
#include <linux/autoconf.h>
#if defined(CONFIG_XEN) && defined(CONFIG_XEN_INTERFACE_VERSION) && !defined(__XEN_INTERFACE_VERSION__)
#define __XEN_INTERFACE_VERSION__ CONFIG_XEN_INTERFACE_VERSION
#endif
#include <linux/version.h>
#include <linux/utsname.h>
int main() {
if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0)) {
return 0;
} else {
return 1;
}
}
The command line:
cc -D__KERNEL__ -DKBUILD_BASENAME="#conftest23112" -DKBUILD_MODNAME="#conftest23112" -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.4.0/include -I/lib/modules/2.6.30-rc3-mmotm0424/source/include/asm-x86_64/mach-default -I/lib/modules/2.6.30-rc3-mmotm0424/source/include/asm-x86/mach-default -I/lib/modules/2.6.30-rc3-mmotm0424/source/arch/x86/include/asm/mach-default -I/lib/modules/2.6.30-rc3-mmotm0424/build/include2 -I/lib/modules/2.6.30-rc3-mmotm0424/build/include -I/lib/modules/2.6.30-rc3-mmotm0424/source/include -I/lib/modules/2.6.30-rc3-mmotm0424/source/arch/x86/include -o conftest23112 conftest23112.c
and the joy it got me:
In file included from /lib/modules/2.6.30-rc3-mmotm0424/build/include/linux/slab.h:161,
from /lib/modules/2.6.30-rc3-mmotm0424/build/include/linux/percpu.h:5,
from /lib/modules/2.6.30-rc3-mmotm0424/build/include/linux/sched.h:76,
from /lib/modules/2.6.30-rc3-mmotm0424/build/include/linux/utsname.h:35,
from conftest2465.c:6:
/lib/modules/2.6.30-rc3-mmotm0424/build/include/linux/slqb_def.h: In function ‘kmalloc_slab’:
/lib/modules/2.6.30-rc3-mmotm0424/build/include/linux/slqb_def.h:240: error: size of array ‘type name’ is negative
Why does utsname.h care about SLAB versus SLUB? (Looks to me like somebody
forgot to add a #include to slqb_def.h for all the headers it needed, and
it choked. Interestingly enough, line 240 reads:
BUILD_BUG_ON(!__builtin_constant_p(size));
but I didn't think this was the way BUILD_BUG_ON worked?
Changed back to SLAB, and things built just fine after that...
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mmotm 2009-04-24-18-14 uploaded - pulseaudio causes BUG
[not found] <200904250133.n3P1XBJn006790@imap1.linux-foundation.org>
2009-04-25 3:06 ` mmotm 2009-04-24-18-14 uploaded - NVidia indigestion Valdis.Kletnieks
@ 2009-04-25 3:52 ` Valdis.Kletnieks
2009-04-25 4:41 ` Andrew Morton
1 sibling, 1 reply; 10+ messages in thread
From: Valdis.Kletnieks @ 2009-04-25 3:52 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, mm-commits
[-- Attachment #1: Type: text/plain, Size: 5410 bytes --]
On Fri, 24 Apr 2009 18:14:22 PDT, akpm@linux-foundation.org said:
> The mm-of-the-moment snapshot 2009-04-24-18-14 has been uploaded to
>
> http://userweb.kernel.org/~akpm/mmotm/
Seeing this consistently and repeatably when trying to start pulseaudio:
[ 70.686993] BUG: unable to handle kernel NULL pointer dereference at 00000000000000c8
[ 70.687012] IP: [<ffffffff80294d0a>] balance_dirty_pages_ratelimited_nr+0x20/0x2e3
[ 70.687012] PGD 7db07067 PUD 7a1c2067 PMD 0
[ 70.687012] Oops: 0000 [#1] PREEMPT SMP
[ 70.687012] last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda1/start
[ 70.687012] CPU 0
[ 70.687012] Modules linked in: [last unloaded: scsi_wait_scan]
[ 70.687012] Pid: 2109, comm: pulseaudio Not tainted 2.6.30-rc3-mmotm0424 #2 Latitude D820
[ 70.687012] RIP: 0010:[<ffffffff80294d0a>] [<ffffffff80294d0a>] balance_dirty_pages_ratelimited_nr+0x20/0x2e3
[ 70.687012] RSP: 0000:ffff88007ebcdd28 EFLAGS: 00010296
[ 70.687012] RAX: ffff8800010ca100 RBX: 0000000000000000 RCX: 0000000000000035
[ 70.687012] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
[ 70.687012] RBP: ffff88007ebcddd8 R08: 5900000000000000 R09: 0000000000000000
[ 70.687012] R10: ffffffff80ab9f30 R11: ffff88007ebcdd58 R12: 0000000000000008
[ 70.687012] R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001
[ 70.687012] FS: 00007fb7f4a017e0(0000) GS:ffff8800010d8000(0000) knlGS:0000000000000000
[ 70.687012] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 70.687012] CR2: 00000000000000c8 CR3: 000000007ea1f000 CR4: 00000000000006e0
[ 70.687012] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 70.687012] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 70.687012] Process pulseaudio (pid: 2109, threadinfo ffff88007ebcc000, task ffff88007e85e140)
[ 70.687012] Stack:
[ 70.687012] 0000000000000000 0000000000000001 ffff88007ebcdd58 ffffffff8065244d
[ 70.687012] ffff88007ebcdd58 ffff88007d913d80 ffff88007ebcdd88 ffffffff802cbe06
[ 70.687012] ffff88007e8e86d8 ffff88007e8e86d8 ffff88007e22f440 0000000000000000
[ 70.687012] Call Trace:
[ 70.687012] [<ffffffff8065244d>] ? sub_preempt_count+0x35/0x48
[ 70.687012] [<ffffffff802cbe06>] ? mnt_drop_write+0x108/0x128
[ 70.687012] [<ffffffff802c735c>] ? file_update_time+0xbd/0xf4
[ 70.687012] [<ffffffff802a4244>] __do_fault+0x2d2/0x315
[ 70.687012] [<ffffffff802a44ec>] handle_mm_fault+0x265/0x598
[ 70.687012] [<ffffffff80250090>] ? down_read_trylock+0x3f/0x4b
[ 70.687012] [<ffffffff806522f7>] ? do_page_fault+0x107/0x228
[ 70.687012] [<ffffffff80652403>] do_page_fault+0x213/0x228
[ 70.687012] [<ffffffff8065037f>] page_fault+0x1f/0x30
[ 70.687012] Code: 5e 5f 5b 41 5c 41 5d 41 5e c9 c3 55 48 89 e5 41 57 41 56 41 55 49 89 f5 41 54 41 bc 08 00 00 00 53 48 89 fb 48 81 ec
88 00 00 00 <48> 8b 87 c8 00 00 00 bf 01 00 00 00 83 b8 68 01 00 00 00 4c 0f
[ 70.687012] RIP [<ffffffff80294d0a>] balance_dirty_pages_ratelimited_nr+0x20/0x2e3
[ 70.687012] RSP <ffff88007ebcdd28>
[ 70.687012] CR2: 00000000000000c8
[ 71.492293] ---[ end trace 3270cbac9ba6a165 ]---
The tail end of 'strace pulseaudio -vvvv':
open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK) = 15
close(14) = 0
ioctl(15, AGPIOC_ACQUIRE or APM_IOC_STANDBY, 0x7fffb11a9c00) = 0
fcntl(15, F_GETFL) = 0x8802 (flags O_RDWR|O_NONBLOCK|O_LARGEFILE)
ioctl(15, AGPIOC_INFO, 0x7fffb11a9bfc) = 0
ioctl(15, AGPIOC_SETUP, 0x7fffb11a9bf8) = 0
mmap(NULL, 4096, PROT_READ, MAP_SHARED, 15, 0x80000000) = 0x7f3ea91a2000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 15, 0x81000000) = 0x7f3ea91a1000
fcntl(15, F_GETFL) = 0x8802 (flags O_RDWR|O_NONBLOCK|O_LARGEFILE)
fcntl(15, F_SETFL, O_RDWR|O_LARGEFILE) = 0
open("/dev/snd/controlC0", O_RDONLY) = 14
close(14) = 0
stat("/usr/share/alsa/alsa.conf", {st_mode=S_IFREG|0644, st_size=8940, ...}) = 0
open("/dev/snd/controlC0", O_RDONLY) = 14
close(14) = 0
open("/dev/snd/controlC0", O_RDWR) = 14
ioctl(14, USBDEVFS_CONTROL, 0x7fffb11a9eec) = 0
ioctl(14, USBDEVFS_CONNECTINFO, 0x7fffb11a9f90) = 0
ioctl(14, 0xffffffffc008551a, 0x77a640) = 0
ioctl(15, 0xc2604110, 0x7fffb11aa040) = 0
ioctl(15, 0xc2604110, 0x7fffb11aa040) = 0
ioctl(15, 0xc2604110, 0x7fffb11aa040) = 0
ioctl(15, 0xc2604110, 0x7fffb11a9d90) = 0
ioctl(15, 0xc2604110, 0x7fffb11a9d30) = 0
ioctl(15, 0xc2604110, 0x7fffb11a9d30) = 0
ioctl(15, 0xc2604110, 0x7fffb11a9ad0) = 0
ioctl(15, 0xc2604110, 0x7fffb11a9ad0) = 0
ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
write(2, "D: alsa-util.c: Maximum hw buffer"..., 49D: alsa-util.c: Maximum hw buffer size is 371 ms
) = 49
ioctl(15, 0xc2604110, 0x7fffb11a9ad0) = 0
ioctl(15, 0xc2604110, 0x7fffb11a9ab0) = 0
ioctl(15, 0xc2604110, 0x7fffb11a9ab0) = 0
ioctl(15, 0xc2604110, 0x7fffb11a9f80) = 0
ioctl(15, 0xc2604110, 0x7fffb11a9f50) = 0
ioctl(15, 0xc2604110, 0x7fffb11a9f50) = 0
ioctl(15, 0xc2604110, 0x7fffb11a9f80) = 0
ioctl(15, 0xc2604111, 0x7fffb11a9f80) = 0
ioctl(15, 0xc0884113, 0x7fffb11a9ed0) = 0
+++ killed by SIGKILL +++
Not sure what pulseaudio is doing with its page faults that causes it.
I won't have a chance to bisect this until tomorrow....
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mmotm 2009-04-24-18-14 uploaded - pulseaudio causes BUG
2009-04-25 3:52 ` mmotm 2009-04-24-18-14 uploaded - pulseaudio causes BUG Valdis.Kletnieks
@ 2009-04-25 4:41 ` Andrew Morton
0 siblings, 0 replies; 10+ messages in thread
From: Andrew Morton @ 2009-04-25 4:41 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: linux-kernel, Nick Piggin
On Fri, 24 Apr 2009 23:52:13 -0400 Valdis.Kletnieks@vt.edu wrote:
> On Fri, 24 Apr 2009 18:14:22 PDT, akpm@linux-foundation.org said:
> > The mm-of-the-moment snapshot 2009-04-24-18-14 has been uploaded to
> >
> > http://userweb.kernel.org/~akpm/mmotm/
>
> Seeing this consistently and repeatably when trying to start pulseaudio:
>
> [ 70.686993] BUG: unable to handle kernel NULL pointer dereference at 00000000000000c8
> [ 70.687012] IP: [<ffffffff80294d0a>] balance_dirty_pages_ratelimited_nr+0x20/0x2e3
> [ 70.687012] PGD 7db07067 PUD 7a1c2067 PMD 0
> [ 70.687012] Oops: 0000 [#1] PREEMPT SMP
> [ 70.687012] last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda1/start
> [ 70.687012] CPU 0
> [ 70.687012] Modules linked in: [last unloaded: scsi_wait_scan]
> [ 70.687012] Pid: 2109, comm: pulseaudio Not tainted 2.6.30-rc3-mmotm0424 #2 Latitude D820
> [ 70.687012] RIP: 0010:[<ffffffff80294d0a>] [<ffffffff80294d0a>] balance_dirty_pages_ratelimited_nr+0x20/0x2e3
> [ 70.687012] RSP: 0000:ffff88007ebcdd28 EFLAGS: 00010296
> [ 70.687012] RAX: ffff8800010ca100 RBX: 0000000000000000 RCX: 0000000000000035
> [ 70.687012] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
> [ 70.687012] RBP: ffff88007ebcddd8 R08: 5900000000000000 R09: 0000000000000000
> [ 70.687012] R10: ffffffff80ab9f30 R11: ffff88007ebcdd58 R12: 0000000000000008
> [ 70.687012] R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001
> [ 70.687012] FS: 00007fb7f4a017e0(0000) GS:ffff8800010d8000(0000) knlGS:0000000000000000
> [ 70.687012] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 70.687012] CR2: 00000000000000c8 CR3: 000000007ea1f000 CR4: 00000000000006e0
> [ 70.687012] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 70.687012] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 70.687012] Process pulseaudio (pid: 2109, threadinfo ffff88007ebcc000, task ffff88007e85e140)
> [ 70.687012] Stack:
> [ 70.687012] 0000000000000000 0000000000000001 ffff88007ebcdd58 ffffffff8065244d
> [ 70.687012] ffff88007ebcdd58 ffff88007d913d80 ffff88007ebcdd88 ffffffff802cbe06
> [ 70.687012] ffff88007e8e86d8 ffff88007e8e86d8 ffff88007e22f440 0000000000000000
> [ 70.687012] Call Trace:
> [ 70.687012] [<ffffffff8065244d>] ? sub_preempt_count+0x35/0x48
> [ 70.687012] [<ffffffff802cbe06>] ? mnt_drop_write+0x108/0x128
> [ 70.687012] [<ffffffff802c735c>] ? file_update_time+0xbd/0xf4
> [ 70.687012] [<ffffffff802a4244>] __do_fault+0x2d2/0x315
> [ 70.687012] [<ffffffff802a44ec>] handle_mm_fault+0x265/0x598
> [ 70.687012] [<ffffffff80250090>] ? down_read_trylock+0x3f/0x4b
> [ 70.687012] [<ffffffff806522f7>] ? do_page_fault+0x107/0x228
> [ 70.687012] [<ffffffff80652403>] do_page_fault+0x213/0x228
> [ 70.687012] [<ffffffff8065037f>] page_fault+0x1f/0x30
> [ 70.687012] Code: 5e 5f 5b 41 5c 41 5d 41 5e c9 c3 55 48 89 e5 41 57 41 56 41 55 49 89 f5 41 54 41 bc 08 00 00 00 53 48 89 fb 48 81 ec
> 88 00 00 00 <48> 8b 87 c8 00 00 00 bf 01 00 00 00 83 b8 68 01 00 00 00 4c 0f
> [ 70.687012] RIP [<ffffffff80294d0a>] balance_dirty_pages_ratelimited_nr+0x20/0x2e3
> [ 70.687012] RSP <ffff88007ebcdd28>
> [ 70.687012] CR2: 00000000000000c8
> [ 71.492293] ---[ end trace 3270cbac9ba6a165 ]---
>
> The tail end of 'strace pulseaudio -vvvv':
>
> open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK) = 15
> close(14) = 0
> ioctl(15, AGPIOC_ACQUIRE or APM_IOC_STANDBY, 0x7fffb11a9c00) = 0
> fcntl(15, F_GETFL) = 0x8802 (flags O_RDWR|O_NONBLOCK|O_LARGEFILE)
> ioctl(15, AGPIOC_INFO, 0x7fffb11a9bfc) = 0
> ioctl(15, AGPIOC_SETUP, 0x7fffb11a9bf8) = 0
> mmap(NULL, 4096, PROT_READ, MAP_SHARED, 15, 0x80000000) = 0x7f3ea91a2000
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 15, 0x81000000) = 0x7f3ea91a1000
> fcntl(15, F_GETFL) = 0x8802 (flags O_RDWR|O_NONBLOCK|O_LARGEFILE)
> fcntl(15, F_SETFL, O_RDWR|O_LARGEFILE) = 0
> open("/dev/snd/controlC0", O_RDONLY) = 14
> close(14) = 0
> stat("/usr/share/alsa/alsa.conf", {st_mode=S_IFREG|0644, st_size=8940, ...}) = 0
> open("/dev/snd/controlC0", O_RDONLY) = 14
> close(14) = 0
> open("/dev/snd/controlC0", O_RDWR) = 14
> ioctl(14, USBDEVFS_CONTROL, 0x7fffb11a9eec) = 0
> ioctl(14, USBDEVFS_CONNECTINFO, 0x7fffb11a9f90) = 0
> ioctl(14, 0xffffffffc008551a, 0x77a640) = 0
> ioctl(15, 0xc2604110, 0x7fffb11aa040) = 0
> ioctl(15, 0xc2604110, 0x7fffb11aa040) = 0
> ioctl(15, 0xc2604110, 0x7fffb11aa040) = 0
> ioctl(15, 0xc2604110, 0x7fffb11a9d90) = 0
> ioctl(15, 0xc2604110, 0x7fffb11a9d30) = 0
> ioctl(15, 0xc2604110, 0x7fffb11a9d30) = 0
> ioctl(15, 0xc2604110, 0x7fffb11a9ad0) = 0
> ioctl(15, 0xc2604110, 0x7fffb11a9ad0) = 0
> ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
> write(2, "D: alsa-util.c: Maximum hw buffer"..., 49D: alsa-util.c: Maximum hw buffer size is 371 ms
> ) = 49
> ioctl(15, 0xc2604110, 0x7fffb11a9ad0) = 0
> ioctl(15, 0xc2604110, 0x7fffb11a9ab0) = 0
> ioctl(15, 0xc2604110, 0x7fffb11a9ab0) = 0
> ioctl(15, 0xc2604110, 0x7fffb11a9f80) = 0
> ioctl(15, 0xc2604110, 0x7fffb11a9f50) = 0
> ioctl(15, 0xc2604110, 0x7fffb11a9f50) = 0
> ioctl(15, 0xc2604110, 0x7fffb11a9f80) = 0
> ioctl(15, 0xc2604111, 0x7fffb11a9f80) = 0
> ioctl(15, 0xc0884113, 0x7fffb11a9ed0) = 0
> +++ killed by SIGKILL +++
>
> Not sure what pulseaudio is doing with its page faults that causes it.
> I won't have a chance to bisect this until tomorrow....
Sound drivers install their own vm_operations.fault() handlers. I
assume that mm-close-page_mkwrite-races-try-3.patch is causing core MM
to call calling balance_dirty_pages() due to a fault against a sounds
device, which is somewhat wrong.
This might plug things up, but I didn't put a lot of thought into it.
--- a/mm/memory.c~mm-close-page_mkwrite-races-try-3-fix
+++ a/mm/memory.c
@@ -2129,7 +2129,8 @@ unlock:
set_page_dirty(dirty_page);
unlock_page(dirty_page);
page_cache_release(dirty_page);
- balance_dirty_pages_ratelimited(mapping);
+ if (mapping)
+ balance_dirty_pages_ratelimited(mapping);
}
}
return ret;
@@ -2769,7 +2770,7 @@ out:
page_mkwrite = 1;
unlock_page(dirty_page);
put_page(dirty_page);
- if (page_mkwrite)
+ if (page_mkwrite && mapping)
balance_dirty_pages_ratelimited(mapping);
} else {
unlock_page(vmf.page);
_
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mmotm 2009-04-24-18-14 uploaded - NVidia indigestion
2009-04-25 3:06 ` mmotm 2009-04-24-18-14 uploaded - NVidia indigestion Valdis.Kletnieks
@ 2009-04-25 5:24 ` Nick Piggin
2009-04-27 18:45 ` Valdis.Kletnieks
0 siblings, 1 reply; 10+ messages in thread
From: Nick Piggin @ 2009-04-25 5:24 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: Andrew Morton, linux-kernel, mm-commits
On Fri, Apr 24, 2009 at 11:06:40PM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 24 Apr 2009 18:14:22 PDT, akpm@linux-foundation.org said:
> > The mm-of-the-moment snapshot 2009-04-24-18-14 has been uploaded to
> >
> > http://userweb.kernel.org/~akpm/mmotm/
>
> This jumped out and asked if I wanted SLQB as the default allocator (even
> though I've had SLAB defined for ages). I said to myself "what the heck"
> and accepted the change...
Heh, it was a sneaky trick to get more testing before merging. Worked
well :)
> Tried to build the NVidia binary, and it choked during config on something
> that will likely give a *lot* of programs indigestion.
>
> The test program:
>
> #include <linux/autoconf.h>
> #if defined(CONFIG_XEN) && defined(CONFIG_XEN_INTERFACE_VERSION) && !defined(__XEN_INTERFACE_VERSION__)
> #define __XEN_INTERFACE_VERSION__ CONFIG_XEN_INTERFACE_VERSION
> #endif
> #include <linux/version.h>
> #include <linux/utsname.h>
> int main() {
> if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0)) {
> return 0;
> } else {
> return 1;
> }
> }
>
> The command line:
>
> cc -D__KERNEL__ -DKBUILD_BASENAME="#conftest23112" -DKBUILD_MODNAME="#conftest23112" -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.4.0/include -I/lib/modules/2.6.30-rc3-mmotm0424/source/include/asm-x86_64/mach-default -I/lib/modules/2.6.30-rc3-mmotm0424/source/include/asm-x86/mach-default -I/lib/modules/2.6.30-rc3-mmotm0424/source/arch/x86/include/asm/mach-default -I/lib/modules/2.6.30-rc3-mmotm0424/build/include2 -I/lib/modules/2.6.30-rc3-mmotm0424/build/include -I/lib/modules/2.6.30-rc3-mmotm0424/source/include -I/lib/modules/2.6.30-rc3-mmotm0424/source/arch/x86/include -o conftest23112 conftest23112.c
>
> and the joy it got me:
>
> In file included from /lib/modules/2.6.30-rc3-mmotm0424/build/include/linux/slab.h:161,
> from /lib/modules/2.6.30-rc3-mmotm0424/build/include/linux/percpu.h:5,
> from /lib/modules/2.6.30-rc3-mmotm0424/build/include/linux/sched.h:76,
> from /lib/modules/2.6.30-rc3-mmotm0424/build/include/linux/utsname.h:35,
> from conftest2465.c:6:
> /lib/modules/2.6.30-rc3-mmotm0424/build/include/linux/slqb_def.h: In function ???kmalloc_slab???:
> /lib/modules/2.6.30-rc3-mmotm0424/build/include/linux/slqb_def.h:240: error: size of array ???type name??? is negative
>
> Why does utsname.h care about SLAB versus SLUB? (Looks to me like somebody
> forgot to add a #include to slqb_def.h for all the headers it needed, and
> it choked. Interestingly enough, line 240 reads:
>
> BUILD_BUG_ON(!__builtin_constant_p(size));
>
> but I didn't think this was the way BUILD_BUG_ON worked?
Yeah BUILD_BUG_ON does work like that. I can't for the life of me
understand why it triggered though. Is anything in your external
code calling kmalloc_slab directly?
What's the preprocessor output look like?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mmotm 2009-04-24-18-14 uploaded - NVidia indigestion
2009-04-25 5:24 ` Nick Piggin
@ 2009-04-27 18:45 ` Valdis.Kletnieks
2009-04-28 6:15 ` Nick Piggin
0 siblings, 1 reply; 10+ messages in thread
From: Valdis.Kletnieks @ 2009-04-27 18:45 UTC (permalink / raw)
To: Nick Piggin; +Cc: Andrew Morton, linux-kernel, mm-commits
[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]
On Sat, 25 Apr 2009 07:24:34 +0200, Nick Piggin said:
> > #include <linux/version.h>
> > #include <linux/utsname.h>
> > int main() {
> > if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0)) {
> > return 0;
> > } else {
> > return 1;
> > }
> Yeah BUILD_BUG_ON does work like that. I can't for the life of me
> understand why it triggered though. Is anything in your external
> code calling kmalloc_slab directly?
See above - I didn't think LINUX_VERSION_CODE cared about kmalloc, but
I could be wrong on this. ;)
> What's the preprocessor output look like?
The problem appears to be that if you only include version.h and utsname.h,
and *don't* actually reference kmalloc_slab, it doesn't know that the size_t
is actually a constant, so it whinges. Most modules end up doing at least
one kmalloc(), so kmalloc() and kmalloc_slab() get inlined, the constant 'size'
gets propogated, and life is good. If you *don't* call kmalloc(), bad things
happen. ;)
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mmotm 2009-04-24-18-14 uploaded - NVidia indigestion
2009-04-27 18:45 ` Valdis.Kletnieks
@ 2009-04-28 6:15 ` Nick Piggin
2009-04-28 16:01 ` Valdis.Kletnieks
0 siblings, 1 reply; 10+ messages in thread
From: Nick Piggin @ 2009-04-28 6:15 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: Andrew Morton, linux-kernel, mm-commits
On Mon, Apr 27, 2009 at 02:45:15PM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Sat, 25 Apr 2009 07:24:34 +0200, Nick Piggin said:
>
> > > #include <linux/version.h>
> > > #include <linux/utsname.h>
> > > int main() {
> > > if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0)) {
> > > return 0;
> > > } else {
> > > return 1;
> > > }
>
> > Yeah BUILD_BUG_ON does work like that. I can't for the life of me
> > understand why it triggered though. Is anything in your external
> > code calling kmalloc_slab directly?
>
> See above - I didn't think LINUX_VERSION_CODE cared about kmalloc, but
> I could be wrong on this. ;)
>
> > What's the preprocessor output look like?
>
> The problem appears to be that if you only include version.h and utsname.h,
> and *don't* actually reference kmalloc_slab, it doesn't know that the size_t
> is actually a constant, so it whinges. Most modules end up doing at least
> one kmalloc(), so kmalloc() and kmalloc_slab() get inlined, the constant 'size'
> gets propogated, and life is good. If you *don't* call kmalloc(), bad things
> happen. ;)
Hmm, yes if you build without -O, then it appears like the compiler
trips over this. I wouldn't be unhappy with just removing the BUILD_BUG_ON,
but shouldn't the module be using -O[s2]?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mmotm 2009-04-24-18-14 uploaded - NVidia indigestion
2009-04-28 6:15 ` Nick Piggin
@ 2009-04-28 16:01 ` Valdis.Kletnieks
2009-04-29 7:03 ` Nick Piggin
2009-04-30 10:36 ` Nick Piggin
0 siblings, 2 replies; 10+ messages in thread
From: Valdis.Kletnieks @ 2009-04-28 16:01 UTC (permalink / raw)
To: Nick Piggin; +Cc: Andrew Morton, linux-kernel, mm-commits
[-- Attachment #1: Type: text/plain, Size: 687 bytes --]
On Tue, 28 Apr 2009 08:15:57 +0200, Nick Piggin said:
Here's the code (pretty much *all* the code):
> #include <linux/version.h>
> #include <linux/utsname.h>
> int main() {
> if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0)) {
> return 0;
> } else {
> return 1;
> }
> }
> Hmm, yes if you build without -O, then it appears like the compiler
> trips over this. I wouldn't be unhappy with just removing the BUILD_BUG_ON,
> but shouldn't the module be using -O[s2]?
It's a little autoconfig chunk from vendor code that determines if we're
building on a sane/recent kernel. Not the sort of thing you'd expect to
need to invoke the frikking optimizer for program *correctness* :)
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mmotm 2009-04-24-18-14 uploaded - NVidia indigestion
2009-04-28 16:01 ` Valdis.Kletnieks
@ 2009-04-29 7:03 ` Nick Piggin
2009-04-30 10:36 ` Nick Piggin
1 sibling, 0 replies; 10+ messages in thread
From: Nick Piggin @ 2009-04-29 7:03 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: Andrew Morton, linux-kernel, mm-commits
On Tue, Apr 28, 2009 at 12:01:21PM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 28 Apr 2009 08:15:57 +0200, Nick Piggin said:
>
> Here's the code (pretty much *all* the code):
>
> > #include <linux/version.h>
> > #include <linux/utsname.h>
> > int main() {
> > if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0)) {
> > return 0;
> > } else {
> > return 1;
> > }
> > }
>
> > Hmm, yes if you build without -O, then it appears like the compiler
> > trips over this. I wouldn't be unhappy with just removing the BUILD_BUG_ON,
> > but shouldn't the module be using -O[s2]?
>
> It's a little autoconfig chunk from vendor code that determines if we're
> building on a sane/recent kernel. Not the sort of thing you'd expect to
> need to invoke the frikking optimizer for program *correctness* :)
The kernel I think has for a long time required -O to compile correctly
because some things marked inline have had to be inlined for correctness.
This might have changed now that we have __always_inline, but anyway.
But I'll just get rid of that BUILD_BUG_ON.
Thanks,
Nick
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mmotm 2009-04-24-18-14 uploaded - NVidia indigestion
2009-04-28 16:01 ` Valdis.Kletnieks
2009-04-29 7:03 ` Nick Piggin
@ 2009-04-30 10:36 ` Nick Piggin
2009-04-30 11:03 ` Pekka Enberg
1 sibling, 1 reply; 10+ messages in thread
From: Nick Piggin @ 2009-04-30 10:36 UTC (permalink / raw)
To: Valdis.Kletnieks, Pekka Enberg; +Cc: Andrew Morton, linux-kernel
On Tue, Apr 28, 2009 at 12:01:21PM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 28 Apr 2009 08:15:57 +0200, Nick Piggin said:
>
> Here's the code (pretty much *all* the code):
>
> > #include <linux/version.h>
> > #include <linux/utsname.h>
> > int main() {
> > if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0)) {
> > return 0;
> > } else {
> > return 1;
> > }
> > }
>
> > Hmm, yes if you build without -O, then it appears like the compiler
> > trips over this. I wouldn't be unhappy with just removing the BUILD_BUG_ON,
> > but shouldn't the module be using -O[s2]?
>
> It's a little autoconfig chunk from vendor code that determines if we're
> building on a sane/recent kernel. Not the sort of thing you'd expect to
> need to invoke the frikking optimizer for program *correctness* :)
>
>
Pekka, can you apply this please?
Thanks,
Nick
--
SLQB: fix compile without optmisations
SLQB fails to build without -O, which causes some external code to trip
over. This BUILD_BUG_ON isn't so useful anyway because it is trivial to
follow that size will be constant, looking at the callers.
Signed-off-by: Nick Piggin <npiggin@suse.de>
---
Index: linux-2.6/include/linux/slqb_def.h
===================================================================
--- linux-2.6.orig/include/linux/slqb_def.h 2009-04-29 20:35:45.000000000 +1000
+++ linux-2.6/include/linux/slqb_def.h 2009-04-29 21:25:40.000000000 +1000
@@ -237,8 +238,6 @@ static __always_inline struct kmem_cache
{
int index;
- BUILD_BUG_ON(!__builtin_constant_p(size));
-
index = kmalloc_index(size);
if (unlikely(index == 0))
return ZERO_SIZE_PTR;
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: mmotm 2009-04-24-18-14 uploaded - NVidia indigestion
2009-04-30 10:36 ` Nick Piggin
@ 2009-04-30 11:03 ` Pekka Enberg
0 siblings, 0 replies; 10+ messages in thread
From: Pekka Enberg @ 2009-04-30 11:03 UTC (permalink / raw)
To: Nick Piggin; +Cc: Valdis.Kletnieks, Andrew Morton, linux-kernel
On Thu, 2009-04-30 at 12:36 +0200, Nick Piggin wrote:
> On Tue, Apr 28, 2009 at 12:01:21PM -0400, Valdis.Kletnieks@vt.edu wrote:
> > On Tue, 28 Apr 2009 08:15:57 +0200, Nick Piggin said:
> >
> > Here's the code (pretty much *all* the code):
> >
> > > #include <linux/version.h>
> > > #include <linux/utsname.h>
> > > int main() {
> > > if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0)) {
> > > return 0;
> > > } else {
> > > return 1;
> > > }
> > > }
> >
> > > Hmm, yes if you build without -O, then it appears like the compiler
> > > trips over this. I wouldn't be unhappy with just removing the BUILD_BUG_ON,
> > > but shouldn't the module be using -O[s2]?
> >
> > It's a little autoconfig chunk from vendor code that determines if we're
> > building on a sane/recent kernel. Not the sort of thing you'd expect to
> > need to invoke the frikking optimizer for program *correctness* :)
> >
> >
>
> Pekka, can you apply this please?
Applied, thanks!
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2009-04-30 11:03 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <200904250133.n3P1XBJn006790@imap1.linux-foundation.org>
2009-04-25 3:06 ` mmotm 2009-04-24-18-14 uploaded - NVidia indigestion Valdis.Kletnieks
2009-04-25 5:24 ` Nick Piggin
2009-04-27 18:45 ` Valdis.Kletnieks
2009-04-28 6:15 ` Nick Piggin
2009-04-28 16:01 ` Valdis.Kletnieks
2009-04-29 7:03 ` Nick Piggin
2009-04-30 10:36 ` Nick Piggin
2009-04-30 11:03 ` Pekka Enberg
2009-04-25 3:52 ` mmotm 2009-04-24-18-14 uploaded - pulseaudio causes BUG Valdis.Kletnieks
2009-04-25 4:41 ` Andrew Morton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome