linux-next: Tree for July 9

linux-next: Tree for July 9

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 11681 bytes --]

Hi all,

Changes since next-20080708:

Temporarily dropped tree: ttydev (since it would not import on top of any
tree I have)

The x86 tree lost a conflict against the ftrace tree.

The ide tree gained 2 conflicts against Linus' tree.

The nfs tree gained a conflict against Linus' tree.

The acpi tree lost 5 conflicts against various trees but gained another
against the x86 tree.

The net tree lost 2 conflicts against the x86 wireless-current trees.

I have also applied the following patches for known problems (I assume
that these will be merged into their appropriate trees shortly):

	linux-next: zero based percpu build error on s390
	sparc64: sysdev API change fallout

I no longer needed to revert the commits from the mmc tree.
----------------------------------------------------------------------------

I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(patches at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups, it is also built with powerpc allnoconfig,
44x_defconfig and allyesconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

We are up to 104 trees (counting Linus' and 14 trees of patches pending for
Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
Dunlap for doing many randconfig builds.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging powerpc-merge/merge
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sparc-current/master
Merging sound-current/for-linus
Merging arm-current/master
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/usb.current
CONFLICT (content): Merge conflict in drivers/usb/core/hcd.c
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-2.6.26
Merging quilt/driver-core
Merging quilt/usb
CONFLICT (content): Merge conflict in drivers/usb/core/hub.c
Merging tip-core/auto-core-next
CONFLICT (content): Merge conflict in lib/vsprintf.c
Merging cpus4096/auto-cpus4096-next
Merging ftrace/auto-ftrace-next
Merging genirq/auto-genirq-next
Merging safe-poison-pointers/auto-safe-poison-pointers-next
Merging sched/auto-sched-next
CONFLICT (content): Merge conflict in kernel/Makefile
CONFLICT (content): Merge conflict in kernel/sched.c
CONFLICT (content): Merge conflict in kernel/sched_rt.c
Merging stackprotector/auto-stackprotector-next
Merging timers/auto-timers-next
Merging x86/auto-x86-next
CONFLICT (content): Merge conflict in arch/x86/kernel/entry_32.S
CONFLICT (content): Merge conflict in arch/x86/kernel/process_32.c
CONFLICT (content): Merge conflict in arch/x86/kernel/process_64.c
CONFLICT (content): Merge conflict in drivers/base/topology.c
CONFLICT (content): Merge conflict in include/asm-x86/irqflags.h
Merging pci/linux-next
CONFLICT (content): Merge conflict in arch/sparc64/kernel/pci.c
CONFLICT (delete/modify): arch/x86/kernel/setup_64.c deleted in HEAD and modified in pci/linux-next. Version pci/linux-next of arch/x86/kernel/setup_64.c left in tree.
CONFLICT (content): Merge conflict in arch/x86/pci/irq.c
CONFLICT (content): Merge conflict in arch/x86/pci/pci.h
CONFLICT (content): Merge conflict in include/linux/device.h
Applying pci: usb fixup 1
Applying pci: include linux/pm_wakeup.h for device_set_wakeup_capable
Merging quilt/device-mapper
Merging hid/mm
Merging quilt/i2c
CONFLICT (content): Merge conflict in drivers/i2c/i2c-core.c
Merging quilt/kernel-doc
Merging avr32/avr32-arch
Merging v4l-dvb/stable
CONFLICT (content): Merge conflict in drivers/media/video/Kconfig
Applying v4l-dvb: class_for_each_device API change fallout
Merging s390/features
CONFLICT (content): Merge conflict in drivers/s390/block/dasd.c
CONFLICT (content): Merge conflict in drivers/s390/block/dasd_eckd.c
CONFLICT (content): Merge conflict in drivers/s390/block/dasd_fba.c
CONFLICT (content): Merge conflict in drivers/s390/char/tape_core.c
CONFLICT (content): Merge conflict in drivers/s390/cio/device_fsm.c
CONFLICT (content): Merge conflict in drivers/s390/cio/qdio.c
CONFLICT (content): Merge conflict in drivers/s390/net/claw.c
CONFLICT (content): Merge conflict in drivers/s390/net/ctcm_main.c
CONFLICT (content): Merge conflict in drivers/s390/net/lcs.c
CONFLICT (content): Merge conflict in drivers/s390/net/netiucv.c
Merging sh/master
Merging jfs/next
Merging kbuild/master
Created commit 1ffa3ad: Revert "kconfig: normalize int/hex values"
Merging quilt/ide
CONFLICT (content): Merge conflict in drivers/ide/arm/palm_bk3710.c
CONFLICT (content): Merge conflict in drivers/ide/pci/it8213.c
Merging libata/NEXT
Merging nfs/linux-next
CONFLICT (content): Merge conflict in net/sunrpc/rpcb_clnt.c
Merging xfs/master
Merging infiniband/for-next
Merging acpi/test
CONFLICT (rename/modify): Merge conflict in arch/x86/mm/srat_32.c
CONFLICT (content): Merge conflict in arch/x86/kernel/process.c
CONFLICT (content): Merge conflict in drivers/acpi/processor_throttling.c
CONFLICT (content): Merge conflict in drivers/acpi/sleep/main.c
CONFLICT (content): Merge conflict in drivers/pci/pci.c
CONFLICT (content): Merge conflict in drivers/pci/pci.h
CONFLICT (content): Merge conflict in include/acpi/acpi_bus.h
Merging blackfin/for-linus
Merging nfsd/nfsd-next
CONFLICT (content): Merge conflict in net/sunrpc/svc.c
Merging ieee1394/for-next
Merging hwmon/testing
Merging ubi/master
Merging kvm/master
Merging dlm/next
Merging scsi/master
CONFLICT (content): Merge conflict in drivers/s390/scsi/zfcp_aux.c
CONFLICT (content): Merge conflict in drivers/s390/scsi/zfcp_def.h
Applying scsi: fix fallout from the class_find_device API change
Applying scsi: fix fallout from KOBJ_NAME_LEN removal
Merging ia64/test
Merging tests/master
CONFLICT (content): Merge conflict in lib/Kconfig.debug
Merging ocfs2/linux-next
Merging selinux/for-akpm
Merging quilt/m68k
Merging powerpc/powerpc-next
CONFLICT (content): Merge conflict in drivers/macintosh/mediabay.c
Applying powerpc: fix automatic merge of pgtable-ppc64.h
Merging lblnet/master
Merging ext4/next
Merging 4xx/next
Merging async_tx/next
Merging udf/for_next
Merging security-testing/next
Merging net/master
CONFLICT (content): Merge conflict in Documentation/powerpc/booting-without-of.txt
CONFLICT (content): Merge conflict in drivers/net/fs_enet/fs_enet-main.c
CONFLICT (content): Merge conflict in drivers/pci/pci-acpi.c
Merging sparc/master
Merging galak/powerpc-next
Merging mtd/master
Merging wireless/master
Merging crypto/master
Merging vfs/vfs-2.6.25
Merging sound/master
Merging arm/devel
CONFLICT (content): Merge conflict in arch/arm/kernel/time.c
CONFLICT (content): Merge conflict in arch/arm/mach-at91/board-yl-9200.c
Merging cpufreq/next
CONFLICT (content): Merge conflict in drivers/cpufreq/cpufreq.c
Merging v9fs/for-next
Merging quilt/rr
CONFLICT (content): Merge conflict in drivers/char/hvc_console.h
CONFLICT (content): Merge conflict in kernel/stop_machine.c
Merging cifs/master
Merging mmc/next
Merging gfs2/master
Merging input/next
Merging semaphore/semaphore
Merging semaphore-removal/semaphore-removal
CONFLICT (content): Merge conflict in drivers/net/ps3_gelic_wireless.c
CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_attr.c
CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_def.h
CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_mbx.c
CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_mid.c
CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_os.c
Merging bkl-removal/bkl-removal
CONFLICT (content): Merge conflict in fs/nfs/file.c
Merging trivial/next
CONFLICT (content): Merge conflict in include/linux/securebits.h
Merging ubifs/for_andrew
Merging lsm/for-next
Merging block/for-next
Merging embedded/master
Merging firmware/master
CONFLICT (content): Merge conflict in drivers/atm/Makefile
CONFLICT (content): Merge conflict in drivers/char/ip2/ip2main.c
CONFLICT (content): Merge conflict in drivers/media/dvb/ttpci/Makefile
CONFLICT (delete/modify): drivers/usb/serial/ti_fw_3410.h deleted in firmware/master and modified in HEAD. Version HEAD of drivers/usb/serial/ti_fw_3410.h left in tree.
CONFLICT (delete/modify): drivers/usb/serial/ti_fw_5052.h deleted in firmware/master and modified in HEAD. Version HEAD of drivers/usb/serial/ti_fw_5052.h left in tree.
CONFLICT (content): Merge conflict in drivers/usb/serial/ti_usb_3410_5052.c
CONFLICT (content): Merge conflict in include/linux/firmware.h
CONFLICT (content): Merge conflict in sound/pci/Kconfig
CONFLICT (content): Merge conflict in sound/pci/maestro3.c
CONFLICT (content): Merge conflict in sound/pci/ymfpci/ymfpci_main.c
Merging pcmcia/master
Merging battery/master
CONFLICT (content): Merge conflict in drivers/power/Kconfig
CONFLICT (content): Merge conflict in drivers/power/Makefile
Merging leds/for-mm
Merging backlight/for-mm
CONFLICT (content): Merge conflict in drivers/video/backlight/Kconfig
CONFLICT (content): Merge conflict in drivers/video/backlight/Makefile
Merging kgdb/kgdb-next
Merging slab/for-next
Merging m68knommu/for-next
Merging uclinux/for-next
Merging md/for-next
Merging cris/for-next
Merging kmemcheck/auto-kmemcheck-next
CONFLICT (content): Merge conflict in arch/x86/mm/Makefile
CONFLICT (content): Merge conflict in include/asm-x86/pgtable.h
CONFLICT (content): Merge conflict in kernel/sysctl.c
Merging generic-ipi/auto-generic-ipi-next
CONFLICT (content): Merge conflict in arch/powerpc/mm/slice.c
CONFLICT (content): Merge conflict in arch/s390/kernel/time.c
CONFLICT (content): Merge conflict in arch/x86/kvm/vmx.c
CONFLICT (content): Merge conflict in init/main.c
CONFLICT (content): Merge conflict in net/iucv/iucv.c
CONFLICT (content): Merge conflict in virt/kvm/kvm_main.c
Applying generic-ipi: powerpc fallout fixes
Merging mips/mips-for-linux-next
Merging mfd/for-next
CONFLICT (content): Merge conflict in MAINTAINERS
Merging hdlc/hdlc-next
CONFLICT (content): Merge conflict in drivers/net/wan/cosa.c
CONFLICT (content): Merge conflict in drivers/net/wan/hdlc_fr.c
CONFLICT (content): Merge conflict in drivers/net/wan/pc300_drv.c
Applying linux-next: zero based percpu build error on s390
Applying sparc64: sysdev API change fallout

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: Tree for July 9

[Liam Girdwood]

On Wed, 2008-07-09 at 18:30 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since next-20080708:
> 

I've not seen the voltage regulator framework in linux-next yet. It's in
Andrews quilt series and I did get the automated email from Andrew a
while back stating it was either merged or in another subsystem tree.

Just wondering whether I'll see it in linux-next before the merge
window.

Thanks

Liam

Re: linux-next: Tree for July 9

[Heiko Carstens]

On Wed, Jul 09, 2008 at 06:30:47PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since next-20080708:
> 
> Temporarily dropped tree: ttydev (since it would not import on top of any
> tree I have)
> 
> The x86 tree lost a conflict against the ftrace tree.
> 
> The ide tree gained 2 conflicts against Linus' tree.
> 
> The nfs tree gained a conflict against Linus' tree.
> 
> The acpi tree lost 5 conflicts against various trees but gained another
> against the x86 tree.
> 
> The net tree lost 2 conflicts against the x86 wireless-current trees.
> 
> I have also applied the following patches for known problems (I assume
> that these will be merged into their appropriate trees shortly):
> 
> 	linux-next: zero based percpu build error on s390

Ingo, will you merge/pick this patch up? The original patch which causes
the problems came in via one of your git trees. Patch in question is

"Zero based percpu: infrastructure to rebase the per cpu area to zero"

Thanks.

Re: linux-next: Tree for July 9

[Alan Cox]

On Wed, 9 Jul 2008 18:30:47 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Changes since next-20080708:
> 
> Temporarily dropped tree: ttydev (since it would not import on top of any
> tree I have)

I can make no sense of this as it applies cleanly on top of your tree.

Alan

Re: linux-next: Tree for July 9

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2388 bytes --]

Hi Alan,

On Wed, 9 Jul 2008 15:59:57 +0100 Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> On Wed, 9 Jul 2008 18:30:47 +1000
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Temporarily dropped tree: ttydev (since it would not import on top of any
> > tree I have)
> 
> I can make no sense of this as it applies cleanly on top of your tree.

And so it does, sorry.  I noticed in previous emails that you said you
had based the ttydev series on the firmware tree, so I tried to apply it
there and it failed.  I am still tired after Monday's attempt to build
the linux-next tree failed (not because of ttydev since I never got that
far :-().

I assume that you were never informed about how I work with quilt series
and I am sorry for that.  Here it is:

I collect the series in the morning (my time) and then import it into a
branch of its own based on the commit id in the BASE or NEXT-BASE comment
at the top of the series file.  Because the developer has chosen whee the
branch is based, the patches should always apply cleanly.  This branch
then gets merged into that days linux-next at some point.

So, I need a series based on something that is *not* linux-next itself
(otherwise merging the branch will pull in all of the previous version of
linux-next - bad :-)). It can be based on something that is merged into
linux-next (either named in a NEXT-BASE comment or a SHA1 if the base
tree is never rebased).  If this causes me to fix up merge conflicts,
then that is fine (up to a point, of course) what I can't do easily is
fix up when a patch will not apply in the middle of a series.

Therefore, you should pick a nice stable place to base your tree on.
This base can change from day to day and some do. 

Remember that you have to get your series of patches into Linus' tree
eventually and when you do that, all the things in linux-next may not
have been merged yet (or much more may have been).  Part of what
linux-next is for is to take what you intend to send to Linus and try to
merge it with all the other stuff that is headed his way to see how much
of a mess we get into - and in some cases to change things so that we
minimise that mess.

Hope this is helpful.  If not, please note what time it is here :-)

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: Tree for July 9

[Rafael J. Wysocki]

On Wednesday, 9 of July 2008, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since next-20080708:
> 
> Temporarily dropped tree: ttydev (since it would not import on top of any
> tree I have)
> 
> The x86 tree lost a conflict against the ftrace tree.
> 
> The ide tree gained 2 conflicts against Linus' tree.
> 
> The nfs tree gained a conflict against Linus' tree.
> 
> The acpi tree lost 5 conflicts against various trees but gained another
> against the x86 tree.
> 
> The net tree lost 2 conflicts against the x86 wireless-current trees.
> 
> I have also applied the following patches for known problems (I assume
> that these will be merged into their appropriate trees shortly):
> 
> 	linux-next: zero based percpu build error on s390
> 	sparc64: sysdev API change fallout
> 
> I no longer needed to revert the commits from the mmc tree.
> ----------------------------------------------------------------------------

With this tree (and several previous ones, it appears) my quad core test
box's CPU is detected as one core.  With 2.6.26-rc9 four cores are
detected as appropriate.

dmesg from the failing kernel (today's linux-next) is at:
http://www.sisk.pl/kernel/debug/20080709/dmesg-20080709.log

dmesg from a non-failing kernel (2.6.26-rc9) is at:
http://www.sisk.pl/kernel/debug/20080709/dmesg-rc9.log

.config is at: http://www.sisk.pl/kernel/debug/20080709/next-config

I'll bisect tomorrow.

Thanks,
Rafael

Re: linux-next: Tree for July 9 (kmemcheck: Caught 8-bit read from freed memory (ffff880127c120e8))

[Rafael J. Wysocki]

On Thursday, 10 of July 2008, Rafael J. Wysocki wrote:
> On Wednesday, 9 of July 2008, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Changes since next-20080708:
> > 
> > Temporarily dropped tree: ttydev (since it would not import on top of any
> > tree I have)
> > 
> > The x86 tree lost a conflict against the ftrace tree.
> > 
> > The ide tree gained 2 conflicts against Linus' tree.
> > 
> > The nfs tree gained a conflict against Linus' tree.
> > 
> > The acpi tree lost 5 conflicts against various trees but gained another
> > against the x86 tree.
> > 
> > The net tree lost 2 conflicts against the x86 wireless-current trees.
> > 
> > I have also applied the following patches for known problems (I assume
> > that these will be merged into their appropriate trees shortly):
> > 
> > 	linux-next: zero based percpu build error on s390
> > 	sparc64: sysdev API change fallout
> > 
> > I no longer needed to revert the commits from the mmc tree.
> > ----------------------------------------------------------------------------
> 
> With this tree (and several previous ones, it appears) my quad core test
> box's CPU is detected as one core.  With 2.6.26-rc9 four cores are
> detected as appropriate.
> 
> dmesg from the failing kernel (today's linux-next) is at:
> http://www.sisk.pl/kernel/debug/20080709/dmesg-20080709.log
> 
> dmesg from a non-failing kernel (2.6.26-rc9) is at:
> http://www.sisk.pl/kernel/debug/20080709/dmesg-rc9.log
> 
> .config is at: http://www.sisk.pl/kernel/debug/20080709/next-config

Ah, I see.  kmemcheck has detected a problem and disabled the secondary
CPUs:

kmemcheck: Caught 8-bit read from freed memory (ffff880127c120e8)
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiffffffffffffffffffffffffffffffff
                                        ^

Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.26-rc9-next #37
RIP: 0010:[<ffffffff802b5ac0>]  [<ffffffff802b5ac0>] check_poison_obj+0x90/0x210
RSP: 0018:ffffffff806c1e08  EFLAGS: 00010293
RAX: 000000000000006b RBX: 0000000000000000 RCX: ffffffff802b820e
RDX: 0000000000000000 RSI: ffff880127c120e0 RDI: ffff880127c01480
RBP: ffffffff806c1e48 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000001 R11: 0000000000000040 R12: ffff880127c120e8
R13: 0000000000000040 R14: 0000000000000000 R15: 000000000000003f
FS:  0000000000000000(0000) GS:ffffffff806b8f40(0000) knlGS:0000000000000000
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffff880127c101b8 CR3: 0000000000201000 CR4: 00000000000006a0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
 [<ffffffff802b647c>] cache_alloc_debugcheck_after+0x1ac/0x1f0
 [<ffffffff802b7fac>] kmem_cache_alloc+0x9c/0x140
 [<ffffffff802b820e>] do_tune_cpucache+0x2e/0x2d0
 [<ffffffff802b862b>] enable_cpucache+0x3b/0xb0
 [<ffffffff806e4caa>] kmem_cache_init+0x3ca/0x4c0
 [<ffffffff806c8ece>] start_kernel+0x27e/0x4c0
 [<ffffffff806c827c>] x86_64_start_reservations+0x7c/0xc0
 [<ffffffff806c83b6>] x86_64_start_kernel+0xf6/0x100
 [<ffffffffffffffff>] 0xffffffffffffffff
Calibrating delay loop (skipped), value calculated using timer frequency.. <6>5015.24 BogoMIPS (lpj=10030484)
Security Framework initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
selinux_register_security:  Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
using C1E aware idle routine
ACPI: Core revision 20080609
CPU0: AMD Phenom(tm) 9850 Quad-Core Processor stepping 03
Using local APIC timer interrupts.
APIC timer calibration result 12538092
Detected 12.538 MHz APIC timer.
kmemcheck: "Bugs, beware!"
kmemcheck: Limiting number of CPUs to 1.

Thanks,
Rafael

Re: linux-next: Tree for July 9 (kmemcheck: Caught 8-bit read from freed memory (ffff880127c120e8))

[Vegard Nossum]

On Thu, Jul 10, 2008 at 12:25 AM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> On Thursday, 10 of July 2008, Rafael J. Wysocki wrote:
>> With this tree (and several previous ones, it appears) my quad core test
>> box's CPU is detected as one core.  With 2.6.26-rc9 four cores are
>> detected as appropriate.
>>
>> dmesg from the failing kernel (today's linux-next) is at:
>> http://www.sisk.pl/kernel/debug/20080709/dmesg-20080709.log
>>
>> dmesg from a non-failing kernel (2.6.26-rc9) is at:
>> http://www.sisk.pl/kernel/debug/20080709/dmesg-rc9.log
>>
>> .config is at: http://www.sisk.pl/kernel/debug/20080709/next-config
>
> Ah, I see.  kmemcheck has detected a problem and disabled the secondary
> CPUs:
>
> kmemcheck: Caught 8-bit read from freed memory (ffff880127c120e8)
> iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiffffffffffffffffffffffffffffffff
>                                        ^
>
> Modules linked in:
> Pid: 0, comm: swapper Not tainted 2.6.26-rc9-next #37
> RIP: 0010:[<ffffffff802b5ac0>]  [<ffffffff802b5ac0>] check_poison_obj+0x90/0x210
> RSP: 0018:ffffffff806c1e08  EFLAGS: 00010293
> RAX: 000000000000006b RBX: 0000000000000000 RCX: ffffffff802b820e
> RDX: 0000000000000000 RSI: ffff880127c120e0 RDI: ffff880127c01480
> RBP: ffffffff806c1e48 R08: 0000000000000001 R09: 0000000000000001
> R10: 0000000000000001 R11: 0000000000000040 R12: ffff880127c120e8
> R13: 0000000000000040 R14: 0000000000000000 R15: 000000000000003f
> FS:  0000000000000000(0000) GS:ffffffff806b8f40(0000) knlGS:0000000000000000
> CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> CR2: ffff880127c101b8 CR3: 0000000000201000 CR4: 00000000000006a0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
>  [<ffffffff802b647c>] cache_alloc_debugcheck_after+0x1ac/0x1f0
>  [<ffffffff802b7fac>] kmem_cache_alloc+0x9c/0x140
>  [<ffffffff802b820e>] do_tune_cpucache+0x2e/0x2d0
>  [<ffffffff802b862b>] enable_cpucache+0x3b/0xb0
>  [<ffffffff806e4caa>] kmem_cache_init+0x3ca/0x4c0
>  [<ffffffff806c8ece>] start_kernel+0x27e/0x4c0
>  [<ffffffff806c827c>] x86_64_start_reservations+0x7c/0xc0
>  [<ffffffff806c83b6>] x86_64_start_kernel+0xf6/0x100
>  [<ffffffffffffffff>] 0xffffffffffffffff
> Calibrating delay loop (skipped), value calculated using timer frequency.. <6>5015.24 BogoMIPS (lpj=10030484)
> Security Framework initialized
> SELinux:  Initializing.
> SELinux:  Starting in permissive mode
> selinux_register_security:  Registering secondary module capability
> Capability LSM initialized as secondary
> Mount-cache hash table entries: 256
> CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
> CPU: L2 Cache: 512K (64 bytes/line)
> CPU: Physical Processor ID: 0
> CPU: Processor Core ID: 0
> using C1E aware idle routine
> ACPI: Core revision 20080609
> CPU0: AMD Phenom(tm) 9850 Quad-Core Processor stepping 03
> Using local APIC timer interrupts.
> APIC timer calibration result 12538092
> Detected 12.538 MHz APIC timer.
> kmemcheck: "Bugs, beware!"
> kmemcheck: Limiting number of CPUs to 1.

Hm.

No, they're not disabled because an error was detected. They're always
disabled unless you explicitly allow the SMP+kmemcheck combination in
config. But this combination sucks at the moment because it means
halting all the CPUs on the system for every kernel-mode memory
dereference on any CPU!

Also, the error report is bogus. We should make kmemcheck depend on
!CONFIG_DEBUG_SLAB && !CONFIG_SLUB_DEBUG_ON for now, because these
modes interfere with the checking that kmemcheck does.

(Just think of it -- if SLUB wants to check whether the padding was
overwritten, it *will* have to make a read from the padding area. And
kmemcheck will not differentiate between reads from the allocator vs.
reads from the rest of the kernel. And in every other case, this read
would be a real error.)

That said, we *might* be able to do a kmemcheck_off()/kmemcheck_on()
thing around the special code. Maybe a kmemcheck_read()  which
bypasses the checking for a single read.

But I really do think kmemcheck and slab/slub debugging should be
mutually exclusive. They do essentially the same thing, except that
kmemcheck is much more eager and detects problems right where they
happen (though sometimes too eagerly too; the false positives).

Thanks for trying it out :-D


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036

Re: linux-next: Tree for July 9 (kmemcheck: Caught 8-bit read from freed memory (ffff880127c120e8))

[Pekka Enberg]

Hi Vegard,

On Thu, Jul 10, 2008 at 10:19 AM, Vegard Nossum <vegard.nossum@gmail.com> wrote:
> Also, the error report is bogus. We should make kmemcheck depend on
> !CONFIG_DEBUG_SLAB && !CONFIG_SLUB_DEBUG_ON for now, because these
> modes interfere with the checking that kmemcheck does.

Agreed.

On Thu, Jul 10, 2008 at 10:19 AM, Vegard Nossum <vegard.nossum@gmail.com> wrote:
> That said, we *might* be able to do a kmemcheck_off()/kmemcheck_on()
> thing around the special code. Maybe a kmemcheck_read()  which
> bypasses the checking for a single read.
>
> But I really do think kmemcheck and slab/slub debugging should be
> mutually exclusive. They do essentially the same thing, except that
> kmemcheck is much more eager and detects problems right where they
> happen (though sometimes too eagerly too; the false positives).

I'm not so sure about this. You ought to be able to compile-in SLUB
debugging and kmemcheck support but only enable one of them at
run-time.

                         Pekka