linux-next: Tree for March 10

linux-next: Tree for March 10

[Stephen Rothwell]

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

Hi all,

Changes since 20090306:

Moved trees:
	I have the driver-core tree (and the usb tree that depends
on it) to near the end of the merge list to see if it accumulates many
conflicts (since it contains infrastructure changes).  It seems to have
inherited 2 conflicts (v4l-dvb, net) and a build failure (acpi).

Undropped tree:
	rr

The tracing tree gained build failure for which I reverted a commit.

The xfs tree gained a build failure, so I have used the version from
next-20090306.

The ieee1394 tree lost its conflict.

The sound tree gained a conflict against the arm tree.

The rr tree lost a conflict and build failures.

The input tree gained build failure, so I used the version from
next-20090306.

The md tree gained a conflict against Linus' tree and a build failure, so
I used the version from next-20090306.

The lblnet tree gained a conflict against Linus' tree.

The driver-core tree gained a build failure due to a conflict with the
crypto tree.  I have applied a patch to the crypto tree for today.

----------------------------------------------------------------------------

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 (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES) and i386, sparc and sparc64 defconfig.
These builds also have CONFIG_ENABLE_WARN_DEPRECATED,
CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 133 trees (counting Linus' and 18 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 arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging dwmw2/master
Merging arm/devel
CONFLICT (content): Merge conflict in arch/arm/mach-at91/gpio.c
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging mips/mips-for-linux-next
Merging parisc/master
Merging powerpc/next
Merging 4xx/next
Merging galak/next
Merging pxa/for-next
CONFLICT (rename/modify): Merge conflict in arch/arm/plat-pxa/dma.c
Merging s390/features
Merging sh/master
Merging sparc/master
Merging x86/auto-x86-next
CONFLICT (content): Merge conflict in arch/powerpc/include/asm/elf.h
Merging xtensa/master
Merging tip-core/auto-core-next
CONFLICT (content): Merge conflict in lib/Kconfig.debug
Merging cpus4096/auto-cpus4096-next
Merging tracing/auto-tracing-next
CONFLICT (content): Merge conflict in arch/x86/Kconfig
CONFLICT (delete/modify): block/blktrace.c deleted in tracing/auto-tracing-next and modified in HEAD. Version HEAD of block/blktrace.c left in tree.
CONFLICT (content): Merge conflict in kernel/irq/handle.c
$ git rm -f block/blktrace.c
Applying: tracing: blktrace merge fix
Merging genirq/auto-genirq-next
CONFLICT (content): Merge conflict in kernel/irq/handle.c
Merging safe-poison-pointers/auto-safe-poison-pointers-next
Merging sched/auto-sched-next
CONFLICT (content): Merge conflict in lib/Makefile
Merging stackprotector/auto-stackprotector-next
Merging timers/auto-timers-next
[master]: created 2747afb: "Revert "tracing: current tip/master can't enable ftrace""
Merging pci/linux-next
CONFLICT (content): Merge conflict in drivers/pci/pcie/portdrv_pci.c
Merging quilt/device-mapper
Merging hid/for-next
Merging quilt/i2c
CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-mpc.c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
CONFLICT (content): Merge conflict in Documentation/kernel-parameters.txt
Merging v4l-dvb/master
Merging quota/for_next
Merging jfs/next
Merging kbuild/master
Merging quilt/ide
Merging libata/NEXT
Merging nfs/linux-next
Merging xfs/master
$ git reset --hard HEAD^
Merging xfs/master from next-20090306
Merging infiniband/for-next
Merging acpi/test
Merging nfsd/nfsd-next
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
Merging dlm/next
Merging scsi/master
Merging ocfs2/linux-next
Merging ext4/next
CONFLICT (content): Merge conflict in fs/ext4/inode.c
Merging async_tx/next
Merging udf/for_next
Merging net/master
CONFLICT (content): Merge conflict in drivers/net/wireless/iwlwifi/iwl3945-base.c
CONFLICT (content): Merge conflict in drivers/net/wireless/rt2x00/rt73usb.c
Merging wireless/master
Merging mtd/master
Merging crypto/master
Merging vfs/for-next
Merging sound/for-next
CONFLICT (content): Merge conflict in arch/arm/mach-shark/include/mach/io.h
CONFLICT (content): Merge conflict in sound/soc/pxa/pxa2xx-i2s.c
Merging cpufreq/next
CONFLICT (content): Merge conflict in arch/x86/include/asm/timer.h
Merging v9fs/for-next
CONFLICT (content): Merge conflict in net/9p/protocol.c
Merging quilt/rr
CONFLICT (content): Merge conflict in arch/powerpc/kernel/irq.c
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/cpufreq/powernow-k8.c
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/cpufreq/speedstep-ich.c
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/cpufreq/speedstep-lib.c
CONFLICT (delete/modify): arch/x86/mach-default/setup.c deleted in HEAD and modified in quilt/rr. Version quilt/rr of arch/x86/mach-default/setup.c left in tree.
CONFLICT (delete/modify): arch/x86/mach-voyager/setup.c deleted in HEAD and modified in quilt/rr. Version quilt/rr of arch/x86/mach-voyager/setup.c left in tree.
CONFLICT (content): Merge conflict in drivers/firmware/dcdbas.c
CONFLICT (content): Merge conflict in drivers/hid/hid-core.c
CONFLICT (content): Merge conflict in drivers/media/video/saa7134/saa7134-core.c
CONFLICT (content): Merge conflict in drivers/media/video/saa7134/saa7134.h
CONFLICT (content): Merge conflict in drivers/net/virtio_net.c
CONFLICT (content): Merge conflict in kernel/module.c
$ git rm -f arch/x86/mach-default/setup.c
$ git rm -f arch/x86/mach-voyager/setup.c
Applying: rr: x86 irqaction merge fixup
Merging cifs/master
Merging mmc/next
Merging gfs2/master
Merging input/next
$ git reset --hard HEAD^
Merging input/next from next-20090306
Merging bkl-removal/bkl-removal
Merging ubifs/linux-next
Merging lsm/for-next
Merging block/for-next
Merging embedded/master
Merging firmware/master
CONFLICT (content): Merge conflict in firmware/Makefile
CONFLICT (content): Merge conflict in firmware/WHENCE
CONFLICT (content): Merge conflict in sound/isa/Kconfig
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
CONFLICT (content): Merge conflict in include/linux/rcupdate.h
CONFLICT (content): Merge conflict in include/linux/slub_def.h
CONFLICT (content): Merge conflict in mm/slob.c
CONFLICT (content): Merge conflict in mm/slub.c
Merging uclinux/for-next
Merging md/for-next
CONFLICT (content): Merge conflict in include/linux/dmaengine.h
$ git reset --hard HEAD^
Merging md/for-next from next-20090306
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
CONFLICT (content): Merge conflict in drivers/gpu/drm/drm_proc.c
Merging voltage/for-next
Merging security-testing/next
Merging lblnet/master
CONFLICT (content): Merge conflict in Documentation/feature-removal-schedule.txt
Merging quilt/ttydev
Merging agp/agp-next
Merging kmemcheck/auto-kmemcheck-next
CONFLICT (content): Merge conflict in MAINTAINERS
CONFLICT (content): Merge conflict in arch/x86/Kconfig
CONFLICT (content): Merge conflict in arch/x86/mm/init_32.c
CONFLICT (content): Merge conflict in arch/x86/mm/init_64.c
CONFLICT (content): Merge conflict in kernel/trace/ring_buffer.c
CONFLICT (content): Merge conflict in mm/Makefile
Merging generic-ipi/auto-generic-ipi-next
Merging oprofile/auto-oprofile-next
Merging fastboot/auto-fastboot-next
Merging sparseirq/auto-sparseirq-next
Merging iommu/auto-iommu-next
Merging uwb/for-upstream
Merging watchdog/master
CONFLICT (content): Merge conflict in drivers/watchdog/orion5x_wdt.c
CONFLICT (content): Merge conflict in drivers/watchdog/rc32434_wdt.c
Merging proc/proc
CONFLICT (content): Merge conflict in security/selinux/hooks.c
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
CONFLICT (add/add): Merge conflict in drivers/scsi/osd/osd_initiator.c
Merging fatfs/master
Merging fuse/for-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging audit/for-next
Merging squashfs/master
Merging omap/for-next
Merging quilt/aoe
Merging kmemleak/kmemleak
CONFLICT (content): Merge conflict in Documentation/kernel-parameters.txt
CONFLICT (content): Merge conflict in MAINTAINERS
CONFLICT (content): Merge conflict in include/linux/percpu.h
CONFLICT (content): Merge conflict in include/linux/slab.h
CONFLICT (content): Merge conflict in init/main.c
CONFLICT (content): Merge conflict in kernel/module.c
CONFLICT (content): Merge conflict in lib/Kconfig.debug
CONFLICT (content): Merge conflict in mm/slab.c
CONFLICT (content): Merge conflict in mm/slob.c
CONFLICT (content): Merge conflict in mm/slub.c
CONFLICT (content): Merge conflict in mm/vmalloc.c
Merging quilt/driver-core
CONFLICT (content): Merge conflict in drivers/media/video/v4l2-device.c
CONFLICT (content): Merge conflict in drivers/net/wimax/i2400m/usb-notif.c
CONFLICT (content): Merge conflict in drivers/sh/maple/maple.c
Applying: acpi: update thermal for bus_id removal
Applying: crypto: remove pr_fmt for now
Merging quilt/usb
Merging quilt/staging
Merging scsi-post-merge/master

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

Re: linux-next: Tree for March 10

[Wim Van Sebroeck]

Hi Stephen,

> Merging watchdog/master
> CONFLICT (content): Merge conflict in drivers/watchdog/orion5x_wdt.c
> CONFLICT (content): Merge conflict in drivers/watchdog/rc32434_wdt.c

I redid the linux-2.6-watchdog-next tree. Should be fixed next time.

Kind regards,
Wim.

Re: linux-next: Tree for March 10

[Stephen Rothwell]

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

Hi Wim,

On Tue, 10 Mar 2009 10:33:24 +0100 Wim Van Sebroeck <wim@iguana.be> wrote:
>
> > Merging watchdog/master
> > CONFLICT (content): Merge conflict in drivers/watchdog/orion5x_wdt.c
> > CONFLICT (content): Merge conflict in drivers/watchdog/rc32434_wdt.c
> 
> I redid the linux-2.6-watchdog-next tree. Should be fixed next time.

Thanks.  I could see that they were just continuations of patches that
went into Linus' tree, so was not worried about them.

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

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

Next 10: Badness at mm/allocpercpu.c:123

[Sachin P. Sant]

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

While booting Next 20090310 on a powerpc box (Power6 9117-MMA)
i observed the following badness :

[    0.339662] ------------[ cut here ]------------
[    0.339666] Badness at mm/allocpercpu.c:123
[    0.339670] NIP: c0000000001129dc LR: c0000000001129b8 CTR: 0000000000000000
[    0.339676] REGS: c0000000fe1efa10 TRAP: 0700   Not tainted  (2.6.29-rc7-next-20090310)
[    0.339681] MSR: 8000000000029032 <EE,ME,CE,IR,DR>  CR: 24000024  XER: 20000002
[    0.339695] TASK = c0000000fe1dd3d0[1] 'swapper' THREAD: c0000000fe1ec000 CPU: 0
[    0.339701] GPR00: 0000000000000001 c0000000fe1efc90 c000000000948660 c0000000fe019000
[    0.339711] GPR04: 0000000000000000 0000000000000000 c0000000fe019080 c00000000122e980
[    0.339721] GPR08: 0000000000000000 c000000001467dec c0000000fe0e2610 c0000000fe1dd3d0
[    0.339732] GPR12: 0000000044000022 c000000000a22300 c000000000733ad0 c00000000065e0c5
[    0.339742] GPR16: 0000000003c33a08 0000000000000000 c000000000733a08 0000000002f1fc90
[    0.339752] GPR20: c000000000733a20 c000000000679b30 0000000000000000 0000000002f1fc90
[    0.339763] GPR24: 0000000000000000 0000000000000000 c000000000670ccd 0000000000000001
[    0.339773] GPR28: c0000000fe019000 0000000000000080 c0000000008cb908 0000000000000100
[    0.339788] NIP [c0000000001129dc] .__alloc_percpu+0x7c/0x244
[    0.339793] LR [c0000000001129b8] .__alloc_percpu+0x58/0x244
[    0.339798] Call Trace:
[    0.339801] [c0000000fe1efc90] [c0000000001129b8] .__alloc_percpu+0x58/0x244 (unreliable)
[    0.339810] [c0000000fe1efdc0] [c00000000007ce84] .__create_workqueue_key+0x74/0x2a0
[    0.339819] [c0000000fe1efe70] [c000000000716990] .cpuset_init_smp+0x78/0xa4
[    0.339827] [c0000000fe1eff00] [c000000000700334] .kernel_init+0x16c/0x224
[    0.339834] [c0000000fe1eff90] [c00000000002adc8] .kernel_thread+0x54/0x70
[    0.339839] Instruction dump:
[    0.339843] 3863007f 78630624 4bffb94d 60000000 2bbd0008 7c7c1b78 40fd0030 e93e8010
[    0.339856] 80090000 7c000034 5400d97e 78000020 <0b000000> 2fa00000 41fe0010 e93e8010

I have attached the dmesg log here.

Next 20090306 had the same problem, while 20090305 did not.

Thanks
-Sachin

-- 

---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------


[-- Attachment #2: dmesg_next_20090310 --]
[-- Type: text/plain, Size: 12751 bytes --]

Using 006299d6 bytes for initrd buffer
Please wait, loading kernel...
Allocated 01600000 bytes for kernel @ 03500000
   Elf64 kernel loaded...
Loading ramdisk...
ramdisk loaded 006299d6 @ 01600000
OF stdout device is: /vdevice/vty@30000000
Hypertas detected, assuming LPAR !
command line: root=/dev/sda5 sysrq=1 insmod=sym53c8xx insmod=ipr crashkernel=512M-:256M  
memory layout at init:
  alloc_bottom : 00000000049c0000
  alloc_top    : 0000000008000000
  alloc_top_hi : 0000000008000000
  rmo_top      : 0000000008000000
  ram_top      : 0000000008000000
Looking for displays
instantiating rtas at 0x00000000074e0000 ... done
boot cpu hw idx 0000000000000000
starting cpu hw idx 0000000000000002... done
copying OF device tree ...
Building dt strings...
Building dt structure...
Device tree strings 0x0000000004bd0000 -> 0x0000000004bd15d3
Device tree struct  0x0000000004be0000 -> 0x0000000004c00000
Calling quiesce ...
returning from prom_init
[    0.000000] Crash kernel location must be 0x2000000
[    0.000000] Reserving 256MB of memory at 32MB for crashkernel (System RAM: 4096MB)
[    0.000000] Phyp-dump disabled at boot time
[    0.000000] Using pSeries machine description
[    0.000000] Using 1TB segments
[    0.000000] Found initrd at 0xc000000001600000:0xc000000001c299d6
[    0.000000] console [udbg0] enabled
[    0.000000] Partition configured for 4 cpus.
[    0.000000] CPU maps initialized for 2 threads per core
[    0.000000] Starting Linux PPC64 #1 SMP Tue Mar 10 17:25:05 IST 2009
[    0.000000] -----------------------------------------------------
[    0.000000] ppc64_pft_size                = 0x1a
[    0.000000] physicalMemorySize            = 0x100000000
[    0.000000] htab_hash_mask                = 0x7ffff
[    0.000000] -----------------------------------------------------
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.29-rc7-next-20090310 (root@llm62) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #1 SMP Tue Mar 10 17:25:05 IST 2009
[    0.000000] [boot]0012 Setup Arch
[    0.000000] EEH: No capable adapters found
[    0.000000] PPC64 nvram contains 15360 bytes
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000000 -> 0x00010000
[    0.000000]   Normal   0x00010000 -> 0x00010000
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[1] active PFN ranges
[    0.000000]     0: 0x00000000 -> 0x00010000
[    0.000000] [boot]0015 Setup Done
[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 65448
[    0.000000] Policy zone: DMA
[    0.000000] Kernel command line: root=/dev/sda5 sysrq=1 insmod=sym53c8xx insmod=ipr crashkernel=512M-:256M  
[    0.000000] NR_IRQS:512
[    0.000000] [boot]0020 XICS Init
[    0.000000] [boot]0021 XICS Done
[    0.000000] PID hash table entries: 4096 (order: 12, 32768 bytes)
[    0.000000] clocksource: timebase mult[7d0000] shift[22] registered
[    0.000054] Console: colour dummy device 80x25
[    0.000086] console handover: boot [udbg0] -> real [hvc0]
[    0.000113] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.000118] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.000121] ... MAX_LOCK_DEPTH:          48
[    0.000124] ... MAX_LOCKDEP_KEYS:        8191
[    0.000128] ... CLASSHASH_SIZE:          4096
[    0.000132] ... MAX_LOCKDEP_ENTRIES:     8192
[    0.000135] ... MAX_LOCKDEP_CHAINS:      16384
[    0.000139] ... CHAINHASH_SIZE:          8192
[    0.000142]  memory used by lock dependency info: 4607 kB
[    0.000146]  per task-struct memory footprint: 1920 bytes
[    0.000476] Dentry cache hash table entries: 524288 (order: 6, 4194304 bytes)
[    0.001534] Inode-cache hash table entries: 262144 (order: 5, 2097152 bytes)
[    0.002663] allocated 2621440 bytes of page_cgroup
[    0.002667] please try cgroup_disable=memory option if you don't want
[    0.002672] freeing bootmem node 0
[    0.079853] Memory: 3864320k/4194304k available (7552k kernel code, 329984k reserved, 1984k data, 10855k bss, 384k init)
[    0.080373] Calibrating delay loop... 1022.36 BogoMIPS (lpj=5111808)
[    0.330475] Security Framework initialized
[    0.330481] SELinux:  Disabled at boot.
[    0.330541] Mount-cache hash table entries: 4096
[    0.333232] Initializing cgroup subsys ns
[    0.333237] Initializing cgroup subsys cpuacct
[    0.333242] Initializing cgroup subsys memory
[    0.333251] Initializing cgroup subsys devices
[    0.333257] Initializing cgroup subsys freezer
[    0.334039] Processor 1 found.
[    0.338524] Processor 2 found.
[    0.339010] Processor 3 found.
[    0.339021] Brought up 4 CPUs
[    0.339662] ------------[ cut here ]------------
[    0.339666] Badness at mm/allocpercpu.c:123
[    0.339670] NIP: c0000000001129dc LR: c0000000001129b8 CTR: 0000000000000000
[    0.339676] REGS: c0000000fe1efa10 TRAP: 0700   Not tainted  (2.6.29-rc7-next-20090310)
[    0.339681] MSR: 8000000000029032 <EE,ME,CE,IR,DR>  CR: 24000024  XER: 20000002
[    0.339695] TASK = c0000000fe1dd3d0[1] 'swapper' THREAD: c0000000fe1ec000 CPU: 0
[    0.339701] GPR00: 0000000000000001 c0000000fe1efc90 c000000000948660 c0000000fe019000 
[    0.339711] GPR04: 0000000000000000 0000000000000000 c0000000fe019080 c00000000122e980 
[    0.339721] GPR08: 0000000000000000 c000000001467dec c0000000fe0e2610 c0000000fe1dd3d0 
[    0.339732] GPR12: 0000000044000022 c000000000a22300 c000000000733ad0 c00000000065e0c5 
[    0.339742] GPR16: 0000000003c33a08 0000000000000000 c000000000733a08 0000000002f1fc90 
[    0.339752] GPR20: c000000000733a20 c000000000679b30 0000000000000000 0000000002f1fc90 
[    0.339763] GPR24: 0000000000000000 0000000000000000 c000000000670ccd 0000000000000001 
[    0.339773] GPR28: c0000000fe019000 0000000000000080 c0000000008cb908 0000000000000100 
[    0.339788] NIP [c0000000001129dc] .__alloc_percpu+0x7c/0x244
[    0.339793] LR [c0000000001129b8] .__alloc_percpu+0x58/0x244
[    0.339798] Call Trace:
[    0.339801] [c0000000fe1efc90] [c0000000001129b8] .__alloc_percpu+0x58/0x244 (unreliable)
[    0.339810] [c0000000fe1efdc0] [c00000000007ce84] .__create_workqueue_key+0x74/0x2a0
[    0.339819] [c0000000fe1efe70] [c000000000716990] .cpuset_init_smp+0x78/0xa4
[    0.339827] [c0000000fe1eff00] [c000000000700334] .kernel_init+0x16c/0x224
[    0.339834] [c0000000fe1eff90] [c00000000002adc8] .kernel_thread+0x54/0x70
[    0.339839] Instruction dump:
[    0.339843] 3863007f 78630624 4bffb94d 60000000 2bbd0008 7c7c1b78 40fd0030 e93e8010 
[    0.339856] 80090000 7c000034 5400d97e 78000020 <0b000000> 2fa00000 41fe0010 e93e8010 
[    0.348162] net_namespace: 2160 bytes
[    0.348476] NET: Registered protocol family 16
[    0.348532] IBM eBus Device Driver
[    0.352290] PCI: Probing PCI hardware
[    0.354439] bio: create slab <bio-0> at 0
[    0.355321] SCSI subsystem initialized
[    0.355468] usbcore: registered new interface driver usbfs
[    0.355500] usbcore: registered new interface driver hub
[    0.355577] usbcore: registered new device driver usb
[    0.380869] NET: Registered protocol family 2
[    0.470537] IP route cache hash table entries: 32768 (order: 2, 262144 bytes)
[    0.471080] TCP established hash table entries: 131072 (order: 5, 2097152 bytes)
[    0.471514] TCP bind hash table entries: 65536 (order: 5, 3670016 bytes)
[    0.473611] TCP: Hash tables configured (established 131072 bind 65536)
[    0.473618] TCP reno registered
[    0.500558] NET: Registered protocol family 1
[    0.500632] Unpacking initramfs... done
[    0.645207] Freeing initrd memory: 6310k freed
[    0.658465] IOMMU table initialized, virtual merging enabled
[    0.659595] ====[ backtrace testing ]===========
[    0.659599] Testing a backtrace from process context.
[    0.659603] The following trace is a kernel self test and not a bug!
[    0.659607] Call Trace:
[    0.659613] [c0000000fe1efc70] [c000000000011608] .show_stack+0x6c/0x16c (unreliable)
[    0.659622] [c0000000fe1efd20] [c0000000000a6758] .backtrace_regression_test+0x44/0x134
[    0.659630] [c0000000fe1efe10] [c000000000009254] .do_one_initcall+0x80/0x1a4
[    0.659638] [c0000000fe1eff00] [c000000000700370] .kernel_init+0x1a8/0x224
[    0.659645] [c0000000fe1eff90] [c00000000002adc8] .kernel_thread+0x54/0x70
[    0.659650] Testing a backtrace from irq context.
[    0.659654] The following trace is a kernel self test and not a bug!
[    0.659664] Call Trace:
[    0.659668] [c000000001f9fcf0] [c000000000011608] .show_stack+0x6c/0x16c (unreliable)
[    0.659676] [c000000001f9fda0] [c0000000000a66f0] .backtrace_test_irq_callback+0x18/0x3c
[    0.659684] [c000000001f9fe20] [c00000000006bfa0] .tasklet_action+0x100/0x1d0
[    0.659691] [c000000001f9fec0] [c00000000006ce20] .__do_softirq+0xe8/0x1f8
[    0.659698] [c000000001f9ff90] [c00000000002ac04] .call_do_softirq+0x14/0x24
[    0.659704] [c0000000fe257db0] [c00000000000d4fc] .do_softirq+0x90/0x110
[    0.659711] [c0000000fe257e50] [c00000000006c49c] .ksoftirqd+0xbc/0x18c
[    0.659718] [c0000000fe257f00] [c000000000081cec] .kthread+0x80/0xcc
[    0.659725] [c0000000fe257f90] [c00000000002adc8] .kernel_thread+0x54/0x70
[    0.659733] Testing a saved backtrace.
[    0.659736] The following trace is a kernel self test and not a bug!
[    0.659741]  [<c0000000000a680c>] .backtrace_regression_test+0xf8/0x134
[    0.659747]  [<c000000000009254>] .do_one_initcall+0x80/0x1a4
[    0.659753]  [<c000000000700370>] .kernel_init+0x1a8/0x224
[    0.659759]  [<c00000000002adc8>] .kernel_thread+0x54/0x70
[    0.659764] ====[ end of backtrace testing ]====
[    0.659795] audit: initializing netlink socket (disabled)
[    0.659810] type=2000 audit(1236686641.658:1): initialized
[    0.679339] Kprobe smoke test started
[    0.890631] Kprobe smoke test passed successfully
[    0.890700] rcu-torture:--- Start of test: nreaders=8 nfakewriters=4 stat_interval=0 verbose=0 test_no_idle_hz=0 shuffle_interval=3 stutter=5 irqreader=1
[    0.891677] HugeTLB registered 16 MB page size, pre-allocated 0 pages
[    0.891682] HugeTLB registered 16 GB page size, pre-allocated 0 pages
[    0.892086] VFS: Disk quotas dquot_6.5.2
[    0.892203] Dquot-cache hash table entries: 8192 (order 0, 65536 bytes)
[    0.892884] msgmni has been set to 7556
[    0.893258] alg: No test for stdrng (krng)
[    0.893329] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
[    0.893335] io scheduler noop registered
[    0.893339] io scheduler anticipatory registered
[    0.893343] io scheduler deadline registered
[    0.893396] io scheduler cfq registered (default)
[    0.893490] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    0.893495] rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
[    0.895965] Generic RTC Driver v1.07
[    0.895999] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    0.896309] input: Macintosh mouse button emulation as /devices/virtual/input/input0
[    0.896362] Uniform Multi-Platform E-IDE driver
[    0.896423] ide-gd driver 1.18
[    0.896625] ibmvscsi 30000002: SRP_VERSION: 16.a
[    0.896717] scsi0 : IBM POWER Virtual SCSI Adapter 1.5.8
[    0.896983] ibmvscsi 30000002: partner initialization complete
[    0.896991] ibmvscsi 30000002: sent SRP login
[    0.897062] ibmvscsi 30000002: SRP_LOGIN succeeded
[    0.897104] ibmvscsi 30000002: host srp version: 16.a, host partition VIO (1), OS 3, max io 1048576
[    0.910829] scsi 0:0:1:0: Direct-Access     AIX      VDASD            0001 PQ: 0 ANSI: 3
[    0.911151] scsi 0:0:2:0: CD-ROM            AIX      VOPTA                 PQ: 0 ANSI: 4
[    0.966517] ibmvfc: IBM Virtual Fibre Channel Driver version: 1.0.4 (November 14, 2008)
[    0.966616] scsi 0:0:1:0: Attached scsi generic sg0 type 0
[    0.966661] scsi 0:0:2:0: Attached scsi generic sg1 type 5
[    0.966739] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    0.966793] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    0.966835] uhci_hcd: USB Universal Host Controller Interface driver
[    1.000469] mice: PS/2 mouse device common for all mice
[    1.040547] EDAC MC: Ver: 2.1.0 Mar 10 2009
[    1.041711] usbcore: registered new interface driver hiddev
[    1.041743] usbcore: registered new interface driver usbhid
[    1.041749] usbhid: v2.6:USB HID core driver
[    1.042399] TCP cubic registered
[    1.042405] NET: Registered protocol family 15
[    1.042574] registered taskstats version 1
[    1.042745] Freeing unused kernel memory: 384k freed
doing fast boot
[    1.074740] SysRq : Changing Loglevel
[    1.074747] Loglevel set to 1
FATAL: Module ibmvscsic not found.
Creating device nodes with udev
Boot logging started on /dev/hvc0(/dev/console) at Tue Mar 10 12:04:02 2009

Re: linux-next: Tree for March 10 (crypto & NLATTR)

[Randy Dunlap]

Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20090306:
> 
> 
> The driver-core tree gained a build failure due to a conflict with the
> crypto tree.  I have applied a patch to the crypto tree for today.

I had several (4 of 50) randconfig builds fail with:

lib/built-in.o: In function `__nla_reserve_nohdr':
(.text+0xd08d): undefined reference to `skb_put'
lib/built-in.o: In function `__nla_reserve':
(.text+0xd121): undefined reference to `skb_put'
lib/built-in.o: In function `nla_append':
(.text+0xd493): undefined reference to `skb_put'

which happens with CONFIG_NET=n, CONFIG_CRYPTO=y, CONFIG_CRYPTO_ZLIB=[my].

CRYPTO_ZLIB selects NLATTR, but obviously the build of nlattr.c fails
when CONFIG_NET=n.  Should CRYPTO_ZLIB depend on NET?
Please don't say that CRYPTO_ZLIB should select NET.


-- 
~Randy

[PATCH -next] staging/p9auth: fix dependency/build error

[Randy Dunlap]

From: Randy Dunlap <randy.dunlap@oracle.com>

Fix p9auth dependency/build failure.  It needs to depend on
CRYPTO.

p9auth.c:(.text+0x107297): undefined reference to `crypto_alloc_base'
p9auth.c:(.text+0x1073d4): undefined reference to `crypto_destroy_tfm'

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
 drivers/staging/p9auth/Kconfig |    1 +
 1 file changed, 1 insertion(+)

--- linux-next-20090310.orig/drivers/staging/p9auth/Kconfig
+++ linux-next-20090310/drivers/staging/p9auth/Kconfig
@@ -1,6 +1,7 @@
 config PLAN9AUTH
 	tristate "Plan 9 style capability device implementation"
 	default n
+	depends on CRYPTO
 	help
 	  This module implements the Plan 9 style capability device.
 

Re: linux-next: Tree for March 10 (crypto & NLATTR)

[Geert Uytterhoeven]

On Tue, Mar 10, 2009 at 19:57, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> Stephen Rothwell wrote:
>> Changes since 20090306:
>>
>>
>> The driver-core tree gained a build failure due to a conflict with the
>> crypto tree.  I have applied a patch to the crypto tree for today.
>
> I had several (4 of 50) randconfig builds fail with:
>
> lib/built-in.o: In function `__nla_reserve_nohdr':
> (.text+0xd08d): undefined reference to `skb_put'
> lib/built-in.o: In function `__nla_reserve':
> (.text+0xd121): undefined reference to `skb_put'
> lib/built-in.o: In function `nla_append':
> (.text+0xd493): undefined reference to `skb_put'
>
> which happens with CONFIG_NET=n, CONFIG_CRYPTO=y, CONFIG_CRYPTO_ZLIB=[my].
>
> CRYPTO_ZLIB selects NLATTR, but obviously the build of nlattr.c fails
> when CONFIG_NET=n.  Should CRYPTO_ZLIB depend on NET?
> Please don't say that CRYPTO_ZLIB should select NET.

Bummer, my fault (commit e9cc8bddaea3944fabfebb968bc88d603239beed,
netlink: Move netlink attribute parsing support to lib).

Obviously I was only worried about crypto/zlib.c needing nlattr.c
without pulling in the whole networking code, not about nlattr.c
itself needing networking functionality. But still, how could I have
missed this compile failure?

Does it sound sane to protect the routines that do call skb_put() by
#ifdef CONFIG_NET?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: linux-next: Tree for March 10 (crypto & NLATTR)

[Randy Dunlap]

Geert Uytterhoeven wrote:
> On Tue, Mar 10, 2009 at 19:57, Randy Dunlap <randy.dunlap@oracle.com> wrote:
>> Stephen Rothwell wrote:
>>> Changes since 20090306:
>>>
>>>
>>> The driver-core tree gained a build failure due to a conflict with the
>>> crypto tree.  I have applied a patch to the crypto tree for today.
>> I had several (4 of 50) randconfig builds fail with:
>>
>> lib/built-in.o: In function `__nla_reserve_nohdr':
>> (.text+0xd08d): undefined reference to `skb_put'
>> lib/built-in.o: In function `__nla_reserve':
>> (.text+0xd121): undefined reference to `skb_put'
>> lib/built-in.o: In function `nla_append':
>> (.text+0xd493): undefined reference to `skb_put'
>>
>> which happens with CONFIG_NET=n, CONFIG_CRYPTO=y, CONFIG_CRYPTO_ZLIB=[my].
>>
>> CRYPTO_ZLIB selects NLATTR, but obviously the build of nlattr.c fails
>> when CONFIG_NET=n.  Should CRYPTO_ZLIB depend on NET?
>> Please don't say that CRYPTO_ZLIB should select NET.
> 
> Bummer, my fault (commit e9cc8bddaea3944fabfebb968bc88d603239beed,
> netlink: Move netlink attribute parsing support to lib).
> 
> Obviously I was only worried about crypto/zlib.c needing nlattr.c
> without pulling in the whole networking code, not about nlattr.c
> itself needing networking functionality. But still, how could I have
> missed this compile failure?
> 
> Does it sound sane to protect the routines that do call skb_put() by
> #ifdef CONFIG_NET?

I'll have to let David or Herbert answer that.  From my quick look
at the code, I don't see much use for nlattr.c when CONFIG_NET
is not enabled.

-- 
~Randy

Re: linux-next: Tree for March 10 (crypto & NLATTR)

[David Miller]

From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Tue, 10 Mar 2009 13:08:31 -0700

> I'll have to let David or Herbert answer that.  From my quick look
> at the code, I don't see much use for nlattr.c when CONFIG_NET
> is not enabled.

We want to use the netlink attribute parsers even in non-networking
code, that's what he's trying to do here.

Re: linux-next: Tree for March 10 (crypto & NLATTR)

[Herbert Xu]

On Tue, Mar 10, 2009 at 01:17:00PM -0700, David Miller wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
> Date: Tue, 10 Mar 2009 13:08:31 -0700
> 
> > I'll have to let David or Herbert answer that.  From my quick look
> > at the code, I don't see much use for nlattr.c when CONFIG_NET
> > is not enabled.
> 
> We want to use the netlink attribute parsers even in non-networking
> code, that's what he's trying to do here.

OK the nlattr construction code really wants to depend on NET
because they're skb-oriented.  We could either move them back
or just wrap them in ifdef CONFIG_NET.

I think the latter is probably the simplest.

How does this patch look? And Randy, does it fix the problem for
you?

nlattr: Fix build error with NET off

We moved the netlink attribute support from net to lib in order
for it to be available for general consumption.  However, parts
of the code (the bits that we don't need :) really depends on
NET because the target object is sk_buff.

This patch fixes this by wrapping them in CONFIG_NET.

Some EXPORTs have been moved to make this work.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/lib/nlattr.c b/lib/nlattr.c
index 56c3ce7..80009a2 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -281,6 +281,7 @@ int nla_strcmp(const struct nlattr *nla, const char *str)
 	return d;
 }
 
+#ifdef CONFIG_NET
 /**
  * __nla_reserve - reserve room for attribute on the skb
  * @skb: socket buffer to reserve room on
@@ -305,6 +306,7 @@ struct nlattr *__nla_reserve(struct sk_buff *skb, int attrtype, int attrlen)
 
 	return nla;
 }
+EXPORT_SYMBOL(__nla_reserve);
 
 /**
  * __nla_reserve_nohdr - reserve room for attribute without header
@@ -325,6 +327,7 @@ void *__nla_reserve_nohdr(struct sk_buff *skb, int attrlen)
 
 	return start;
 }
+EXPORT_SYMBOL(__nla_reserve_nohdr);
 
 /**
  * nla_reserve - reserve room for attribute on the skb
@@ -345,6 +348,7 @@ struct nlattr *nla_reserve(struct sk_buff *skb, int attrtype, int attrlen)
 
 	return __nla_reserve(skb, attrtype, attrlen);
 }
+EXPORT_SYMBOL(nla_reserve);
 
 /**
  * nla_reserve_nohdr - reserve room for attribute without header
@@ -363,6 +367,7 @@ void *nla_reserve_nohdr(struct sk_buff *skb, int attrlen)
 
 	return __nla_reserve_nohdr(skb, attrlen);
 }
+EXPORT_SYMBOL(nla_reserve_nohdr);
 
 /**
  * __nla_put - Add a netlink attribute to a socket buffer
@@ -382,6 +387,7 @@ void __nla_put(struct sk_buff *skb, int attrtype, int attrlen,
 	nla = __nla_reserve(skb, attrtype, attrlen);
 	memcpy(nla_data(nla), data, attrlen);
 }
+EXPORT_SYMBOL(__nla_put);
 
 /**
  * __nla_put_nohdr - Add a netlink attribute without header
@@ -399,6 +405,7 @@ void __nla_put_nohdr(struct sk_buff *skb, int attrlen, const void *data)
 	start = __nla_reserve_nohdr(skb, attrlen);
 	memcpy(start, data, attrlen);
 }
+EXPORT_SYMBOL(__nla_put_nohdr);
 
 /**
  * nla_put - Add a netlink attribute to a socket buffer
@@ -418,6 +425,7 @@ int nla_put(struct sk_buff *skb, int attrtype, int attrlen, const void *data)
 	__nla_put(skb, attrtype, attrlen, data);
 	return 0;
 }
+EXPORT_SYMBOL(nla_put);
 
 /**
  * nla_put_nohdr - Add a netlink attribute without header
@@ -436,6 +444,7 @@ int nla_put_nohdr(struct sk_buff *skb, int attrlen, const void *data)
 	__nla_put_nohdr(skb, attrlen, data);
 	return 0;
 }
+EXPORT_SYMBOL(nla_put_nohdr);
 
 /**
  * nla_append - Add a netlink attribute without header or padding
@@ -454,20 +463,13 @@ int nla_append(struct sk_buff *skb, int attrlen, const void *data)
 	memcpy(skb_put(skb, attrlen), data, attrlen);
 	return 0;
 }
+EXPORT_SYMBOL(nla_append);
+#endif
 
 EXPORT_SYMBOL(nla_validate);
 EXPORT_SYMBOL(nla_parse);
 EXPORT_SYMBOL(nla_find);
 EXPORT_SYMBOL(nla_strlcpy);
-EXPORT_SYMBOL(__nla_reserve);
-EXPORT_SYMBOL(__nla_reserve_nohdr);
-EXPORT_SYMBOL(nla_reserve);
-EXPORT_SYMBOL(nla_reserve_nohdr);
-EXPORT_SYMBOL(__nla_put);
-EXPORT_SYMBOL(__nla_put_nohdr);
-EXPORT_SYMBOL(nla_put);
-EXPORT_SYMBOL(nla_put_nohdr);
 EXPORT_SYMBOL(nla_memcpy);
 EXPORT_SYMBOL(nla_memcmp);
 EXPORT_SYMBOL(nla_strcmp);
-EXPORT_SYMBOL(nla_append);

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Next 10: Badness at mm/allocpercpu.c:123

[Sachin P. Sant]

Sachin P. Sant wrote:
> While booting Next 20090310 on a powerpc box (Power6 9117-MMA)
> i observed the following badness :
>
> [    0.339662] ------------[ cut here ]------------
> [    0.339666] Badness at mm/allocpercpu.c:123
> [    0.339670] NIP: c0000000001129dc LR: c0000000001129b8 CTR: 
> 0000000000000000
> [    0.339676] REGS: c0000000fe1efa10 TRAP: 0700   Not tainted  
> (2.6.29-rc7-next-20090310)
> [    0.339681] MSR: 8000000000029032 <EE,ME,CE,IR,DR>  CR: 24000024  
> XER: 20000002
> [    0.339695] TASK = c0000000fe1dd3d0[1] 'swapper' THREAD: 
> c0000000fe1ec000 CPU: 0
> [    0.339701] GPR00: 0000000000000001 c0000000fe1efc90 
> c000000000948660 c0000000fe019000
> [    0.339711] GPR04: 0000000000000000 0000000000000000 
> c0000000fe019080 c00000000122e980
> [    0.339721] GPR08: 0000000000000000 c000000001467dec 
> c0000000fe0e2610 c0000000fe1dd3d0
> [    0.339732] GPR12: 0000000044000022 c000000000a22300 
> c000000000733ad0 c00000000065e0c5
> [    0.339742] GPR16: 0000000003c33a08 0000000000000000 
> c000000000733a08 0000000002f1fc90
> [    0.339752] GPR20: c000000000733a20 c000000000679b30 
> 0000000000000000 0000000002f1fc90
> [    0.339763] GPR24: 0000000000000000 0000000000000000 
> c000000000670ccd 0000000000000001
> [    0.339773] GPR28: c0000000fe019000 0000000000000080 
> c0000000008cb908 0000000000000100
> [    0.339788] NIP [c0000000001129dc] .__alloc_percpu+0x7c/0x244
> [    0.339793] LR [c0000000001129b8] .__alloc_percpu+0x58/0x244
> [    0.339798] Call Trace:
> [    0.339801] [c0000000fe1efc90] [c0000000001129b8] 
> .__alloc_percpu+0x58/0x244 (unreliable)
> [    0.339810] [c0000000fe1efdc0] [c00000000007ce84] 
> .__create_workqueue_key+0x74/0x2a0
> [    0.339819] [c0000000fe1efe70] [c000000000716990] 
> .cpuset_init_smp+0x78/0xa4
> [    0.339827] [c0000000fe1eff00] [c000000000700334] 
> .kernel_init+0x16c/0x224
> [    0.339834] [c0000000fe1eff90] [c00000000002adc8] 
> .kernel_thread+0x54/0x70
> [    0.339839] Instruction dump:
> [    0.339843] 3863007f 78630624 4bffb94d 60000000 2bbd0008 7c7c1b78 
> 40fd0030 e93e8010
> [    0.339856] 80090000 7c000034 5400d97e 78000020 <0b000000> 2fa00000 
> 41fe0010 e93e8010
>
> I have attached the dmesg log here.
>
> Next 20090306 had the same problem, while 20090305 did not.
I see that this WARN_ON was introduced by the following patch from Tejun.

http://lkml.org/lkml/2009/2/18/56

Should i be worried about this warning ?

Thanks
-Sachin


-- 

---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------

[GIT PATCH tj-percpu] percpu: fix spurious alignment WARN in legacy SMP percpu allocator

[Tejun Heo]

Impact: remove spurious WARN on legacy SMP percpu allocator

Commit f2a8205c4ef1af917d175c36a4097ae5587791c8 incorrectly added too
tight WARN_ON_ONCE() on alignments for UP and legacy SMP percpu
allocator.  Commit e317603694bfd17b28a40de9d65e1a4ec12f816e fixed it
for UP but legacy SMP allocator was forgotten.  Fix it.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Sachin P. Sant <sachinp@in.ibm.com>
---

Oops, that was a stupid omission.  This patch should fix it.  Ingo,
please pull from the following git vector to receive the first first
four patches from the use-dynamic-percpu-allocator-by-default patchset
(without the actual conversion which can disrupt archs) + this patch.
I moved the actual conversion patch into #tj-percpu-exp branch, so the
pull should be safe.

  git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git tj-percpu

Thanks.

 mm/allocpercpu.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/mm/allocpercpu.c b/mm/allocpercpu.c
index 3653c57..1882923 100644
--- a/mm/allocpercpu.c
+++ b/mm/allocpercpu.c
@@ -120,7 +120,7 @@ void *__alloc_percpu(size_t size, size_t align)
 	 * on it.  Larger alignment should only be used for module
 	 * percpu sections on SMP for which this path isn't used.
 	 */
-	WARN_ON_ONCE(align > __alignof__(unsigned long long));
+	WARN_ON_ONCE(align > SMP_CACHE_BYTES);
 
 	if (unlikely(!pdata))
 		return NULL;
-- 
1.6.0.2

[RESEND GIT PATCH tj-percpu] percpu: fix spurious alignment WARN in legacy SMP percpu allocator

[Tejun Heo]

Impact: remove spurious WARN on legacy SMP percpu allocator

Commit f2a8205c4ef1af917d175c36a4097ae5587791c8 incorrectly added too
tight WARN_ON_ONCE() on alignments for UP and legacy SMP percpu
allocator.  Commit e317603694bfd17b28a40de9d65e1a4ec12f816e fixed it
for UP but legacy SMP allocator was forgotten.  Fix it.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Sachin P. Sant <sachinp@in.ibm.com>
---
(RESEND: cc'ing Ingo. :-)

Oops, that was a stupid omission.  This patch should fix it.  Ingo,
please pull from the following git vector to receive the first first
four patches from the use-dynamic-percpu-allocator-by-default patchset
(without the actual conversion which can disrupt archs) + this patch.
I moved the actual conversion patch into #tj-percpu-exp branch, so the
pull should be safe.

  git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git tj-percpu

Thanks.

 mm/allocpercpu.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/mm/allocpercpu.c b/mm/allocpercpu.c
index 3653c57..1882923 100644
--- a/mm/allocpercpu.c
+++ b/mm/allocpercpu.c
@@ -120,7 +120,7 @@ void *__alloc_percpu(size_t size, size_t align)
 	 * on it.  Larger alignment should only be used for module
 	 * percpu sections on SMP for which this path isn't used.
 	 */
-	WARN_ON_ONCE(align > __alignof__(unsigned long long));
+	WARN_ON_ONCE(align > SMP_CACHE_BYTES);
 
 	if (unlikely(!pdata))
 		return NULL;
-- 
1.6.0.2

Re: [RESEND GIT PATCH tj-percpu] percpu: fix spurious alignment WARN in legacy SMP percpu allocator

[Sachin P. Sant]

Tejun Heo wrote:
> Impact: remove spurious WARN on legacy SMP percpu allocator
>
> Commit f2a8205c4ef1af917d175c36a4097ae5587791c8 incorrectly added too
> tight WARN_ON_ONCE() on alignments for UP and legacy SMP percpu
> allocator.  Commit e317603694bfd17b28a40de9d65e1a4ec12f816e fixed it
> for UP but legacy SMP allocator was forgotten.  Fix it.
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Reported-by: Sachin P. Sant <sachinp@in.ibm.com>
> ---
Thanks. The patch fixes the warning.

Tested-by : Sachin Sant <sachinp@in.ibm.com>


-- 

---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------

RE: Next 10: Badness at mm/allocpercpu.c:123

[AA]

[-- Attachment #1.1: Type: text/plain, Size: 594 bytes --]


Hi all

 

I am newer to linux.

My board is MPC750+MPC106, and  I use MAPB for MPC106.

 

Due to 106 datasheet, 

0x8000,0000 -- 0xFC00,0000   for PCI memory space.

 

As you know, user space is 0~0xbfff,ffff (3G). 

0xc000,0000 ~ 0xffff,ffff(1G) is for kernel.

 

And my question is:

1) where should I map this address space to ?

2) user application can access this address space directly?

 

 

 

_________________________________________________________________
梦幻K图，百变造型，让你的照片与众不同，快来MClub试试吧！
http://club.msn.cn/?form=3

[-- Attachment #1.2: Type: text/html, Size: 840 bytes --]

[-- Attachment #2: Type: text/plain, Size: 146 bytes --]

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

where should I map 0x8000,0000 ~ 0xfc00,0000 to ?

[AA]

[-- Attachment #1.1: Type: text/plain, Size: 559 bytes --]


Hi all
 I am newer to linux.
 
 My board is MPC750+MPC106, and I use MAPB for MPC106.
 Due to 106 datasheet, 
 0x8000,0000 -- 0xFC00,0000 for PCI memory space.
 
 As you know, user space is 0~0xbfff,ffff (3G). 
 0xc000,0000 ~ 0xffff,ffff(1G) is for kernel.

 And my question is:
 1) where should I map this address space to ?
 2) user application can access this address space directly?
 
 
_________________________________________________________________
梦幻K图，百变造型，让你的照片与众不同，快来MClub试试吧！
http://club.msn.cn/?form=3

[-- Attachment #1.2: Type: text/html, Size: 789 bytes --]

[-- Attachment #2: Type: text/plain, Size: 146 bytes --]

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [RESEND GIT PATCH tj-percpu] percpu: fix spurious alignment WARN in legacy SMP percpu allocator

[Ingo Molnar]

* Tejun Heo <tj@kernel.org> wrote:

> Impact: remove spurious WARN on legacy SMP percpu allocator
> 
> Commit f2a8205c4ef1af917d175c36a4097ae5587791c8 incorrectly added too
> tight WARN_ON_ONCE() on alignments for UP and legacy SMP percpu
> allocator.  Commit e317603694bfd17b28a40de9d65e1a4ec12f816e fixed it
> for UP but legacy SMP allocator was forgotten.  Fix it.
> 
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Reported-by: Sachin P. Sant <sachinp@in.ibm.com>
> ---
> (RESEND: cc'ing Ingo. :-)
> 
> Oops, that was a stupid omission.  This patch should fix it.  Ingo,
> please pull from the following git vector to receive the first first
> four patches from the use-dynamic-percpu-allocator-by-default patchset
> (without the actual conversion which can disrupt archs) + this patch.
> I moved the actual conversion patch into #tj-percpu-exp branch, so the
> pull should be safe.
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git tj-percpu
> 
> Thanks.

Pulled into tip:core/percpu, thanks a lot Tejun!

	Ingo

Re: linux-next: Tree for March 10 (crypto & NLATTR)

[Geert Uytterhoeven]

On Wed, 11 Mar 2009, Herbert Xu wrote:
> On Tue, Mar 10, 2009 at 01:17:00PM -0700, David Miller wrote:
> > From: Randy Dunlap <randy.dunlap@oracle.com>
> > Date: Tue, 10 Mar 2009 13:08:31 -0700
> > 
> > > I'll have to let David or Herbert answer that.  From my quick look
> > > at the code, I don't see much use for nlattr.c when CONFIG_NET
> > > is not enabled.
> > 
> > We want to use the netlink attribute parsers even in non-networking
> > code, that's what he's trying to do here.
> 
> OK the nlattr construction code really wants to depend on NET
> because they're skb-oriented.  We could either move them back
> or just wrap them in ifdef CONFIG_NET.
> 
> I think the latter is probably the simplest.
> 
> How does this patch look? And Randy, does it fix the problem for
> you?
> 
> nlattr: Fix build error with NET off
> 
> We moved the netlink attribute support from net to lib in order
> for it to be available for general consumption.  However, parts
> of the code (the bits that we don't need :) really depends on
> NET because the target object is sk_buff.
> 
> This patch fixes this by wrapping them in CONFIG_NET.
> 
> Some EXPORTs have been moved to make this work.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Thanks for taking care of this!

Tested-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>

> diff --git a/lib/nlattr.c b/lib/nlattr.c
> index 56c3ce7..80009a2 100644
> --- a/lib/nlattr.c
> +++ b/lib/nlattr.c
> @@ -281,6 +281,7 @@ int nla_strcmp(const struct nlattr *nla, const char *str)
>  	return d;
>  }
>  
> +#ifdef CONFIG_NET
>  /**
>   * __nla_reserve - reserve room for attribute on the skb
>   * @skb: socket buffer to reserve room on
> @@ -305,6 +306,7 @@ struct nlattr *__nla_reserve(struct sk_buff *skb, int attrtype, int attrlen)
>  
>  	return nla;
>  }
> +EXPORT_SYMBOL(__nla_reserve);
>  
>  /**
>   * __nla_reserve_nohdr - reserve room for attribute without header
> @@ -325,6 +327,7 @@ void *__nla_reserve_nohdr(struct sk_buff *skb, int attrlen)
>  
>  	return start;
>  }
> +EXPORT_SYMBOL(__nla_reserve_nohdr);
>  
>  /**
>   * nla_reserve - reserve room for attribute on the skb
> @@ -345,6 +348,7 @@ struct nlattr *nla_reserve(struct sk_buff *skb, int attrtype, int attrlen)
>  
>  	return __nla_reserve(skb, attrtype, attrlen);
>  }
> +EXPORT_SYMBOL(nla_reserve);
>  
>  /**
>   * nla_reserve_nohdr - reserve room for attribute without header
> @@ -363,6 +367,7 @@ void *nla_reserve_nohdr(struct sk_buff *skb, int attrlen)
>  
>  	return __nla_reserve_nohdr(skb, attrlen);
>  }
> +EXPORT_SYMBOL(nla_reserve_nohdr);
>  
>  /**
>   * __nla_put - Add a netlink attribute to a socket buffer
> @@ -382,6 +387,7 @@ void __nla_put(struct sk_buff *skb, int attrtype, int attrlen,
>  	nla = __nla_reserve(skb, attrtype, attrlen);
>  	memcpy(nla_data(nla), data, attrlen);
>  }
> +EXPORT_SYMBOL(__nla_put);
>  
>  /**
>   * __nla_put_nohdr - Add a netlink attribute without header
> @@ -399,6 +405,7 @@ void __nla_put_nohdr(struct sk_buff *skb, int attrlen, const void *data)
>  	start = __nla_reserve_nohdr(skb, attrlen);
>  	memcpy(start, data, attrlen);
>  }
> +EXPORT_SYMBOL(__nla_put_nohdr);
>  
>  /**
>   * nla_put - Add a netlink attribute to a socket buffer
> @@ -418,6 +425,7 @@ int nla_put(struct sk_buff *skb, int attrtype, int attrlen, const void *data)
>  	__nla_put(skb, attrtype, attrlen, data);
>  	return 0;
>  }
> +EXPORT_SYMBOL(nla_put);
>  
>  /**
>   * nla_put_nohdr - Add a netlink attribute without header
> @@ -436,6 +444,7 @@ int nla_put_nohdr(struct sk_buff *skb, int attrlen, const void *data)
>  	__nla_put_nohdr(skb, attrlen, data);
>  	return 0;
>  }
> +EXPORT_SYMBOL(nla_put_nohdr);
>  
>  /**
>   * nla_append - Add a netlink attribute without header or padding
> @@ -454,20 +463,13 @@ int nla_append(struct sk_buff *skb, int attrlen, const void *data)
>  	memcpy(skb_put(skb, attrlen), data, attrlen);
>  	return 0;
>  }
> +EXPORT_SYMBOL(nla_append);
> +#endif
>  
>  EXPORT_SYMBOL(nla_validate);
>  EXPORT_SYMBOL(nla_parse);
>  EXPORT_SYMBOL(nla_find);
>  EXPORT_SYMBOL(nla_strlcpy);
> -EXPORT_SYMBOL(__nla_reserve);
> -EXPORT_SYMBOL(__nla_reserve_nohdr);
> -EXPORT_SYMBOL(nla_reserve);
> -EXPORT_SYMBOL(nla_reserve_nohdr);
> -EXPORT_SYMBOL(__nla_put);
> -EXPORT_SYMBOL(__nla_put_nohdr);
> -EXPORT_SYMBOL(nla_put);
> -EXPORT_SYMBOL(nla_put_nohdr);
>  EXPORT_SYMBOL(nla_memcpy);
>  EXPORT_SYMBOL(nla_memcmp);
>  EXPORT_SYMBOL(nla_strcmp);
> -EXPORT_SYMBOL(nla_append);

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:    +32 (0)2 700 8453
Fax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010

Re: linux-next: Tree for March 10 (crypto & NLATTR)

[Randy Dunlap]

Herbert Xu wrote:
> On Tue, Mar 10, 2009 at 01:17:00PM -0700, David Miller wrote:
>> From: Randy Dunlap <randy.dunlap@oracle.com>
>> Date: Tue, 10 Mar 2009 13:08:31 -0700
>>
>>> I'll have to let David or Herbert answer that.  From my quick look
>>> at the code, I don't see much use for nlattr.c when CONFIG_NET
>>> is not enabled.
>> We want to use the netlink attribute parsers even in non-networking
>> code, that's what he's trying to do here.
> 
> OK the nlattr construction code really wants to depend on NET
> because they're skb-oriented.  We could either move them back
> or just wrap them in ifdef CONFIG_NET.
> 
> I think the latter is probably the simplest.
> 
> How does this patch look? And Randy, does it fix the problem for
> you?
> 
> nlattr: Fix build error with NET off
> 
> We moved the netlink attribute support from net to lib in order
> for it to be available for general consumption.  However, parts
> of the code (the bits that we don't need :) really depends on
> NET because the target object is sk_buff.
> 
> This patch fixes this by wrapping them in CONFIG_NET.
> 
> Some EXPORTs have been moved to make this work.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Tested-by: Randy Dunlap <randy.dunlap@oracle.com>

Thanks.

> diff --git a/lib/nlattr.c b/lib/nlattr.c
> index 56c3ce7..80009a2 100644
> --- a/lib/nlattr.c
> +++ b/lib/nlattr.c
> @@ -281,6 +281,7 @@ int nla_strcmp(const struct nlattr *nla, const char *str)
>  	return d;
>  }
>  
> +#ifdef CONFIG_NET
>  /**
>   * __nla_reserve - reserve room for attribute on the skb
>   * @skb: socket buffer to reserve room on
> @@ -305,6 +306,7 @@ struct nlattr *__nla_reserve(struct sk_buff *skb, int attrtype, int attrlen)
>  
>  	return nla;
>  }
> +EXPORT_SYMBOL(__nla_reserve);
>  
>  /**
>   * __nla_reserve_nohdr - reserve room for attribute without header
> @@ -325,6 +327,7 @@ void *__nla_reserve_nohdr(struct sk_buff *skb, int attrlen)
>  
>  	return start;
>  }
> +EXPORT_SYMBOL(__nla_reserve_nohdr);
>  
>  /**
>   * nla_reserve - reserve room for attribute on the skb
> @@ -345,6 +348,7 @@ struct nlattr *nla_reserve(struct sk_buff *skb, int attrtype, int attrlen)
>  
>  	return __nla_reserve(skb, attrtype, attrlen);
>  }
> +EXPORT_SYMBOL(nla_reserve);
>  
>  /**
>   * nla_reserve_nohdr - reserve room for attribute without header
> @@ -363,6 +367,7 @@ void *nla_reserve_nohdr(struct sk_buff *skb, int attrlen)
>  
>  	return __nla_reserve_nohdr(skb, attrlen);
>  }
> +EXPORT_SYMBOL(nla_reserve_nohdr);
>  
>  /**
>   * __nla_put - Add a netlink attribute to a socket buffer
> @@ -382,6 +387,7 @@ void __nla_put(struct sk_buff *skb, int attrtype, int attrlen,
>  	nla = __nla_reserve(skb, attrtype, attrlen);
>  	memcpy(nla_data(nla), data, attrlen);
>  }
> +EXPORT_SYMBOL(__nla_put);
>  
>  /**
>   * __nla_put_nohdr - Add a netlink attribute without header
> @@ -399,6 +405,7 @@ void __nla_put_nohdr(struct sk_buff *skb, int attrlen, const void *data)
>  	start = __nla_reserve_nohdr(skb, attrlen);
>  	memcpy(start, data, attrlen);
>  }
> +EXPORT_SYMBOL(__nla_put_nohdr);
>  
>  /**
>   * nla_put - Add a netlink attribute to a socket buffer
> @@ -418,6 +425,7 @@ int nla_put(struct sk_buff *skb, int attrtype, int attrlen, const void *data)
>  	__nla_put(skb, attrtype, attrlen, data);
>  	return 0;
>  }
> +EXPORT_SYMBOL(nla_put);
>  
>  /**
>   * nla_put_nohdr - Add a netlink attribute without header
> @@ -436,6 +444,7 @@ int nla_put_nohdr(struct sk_buff *skb, int attrlen, const void *data)
>  	__nla_put_nohdr(skb, attrlen, data);
>  	return 0;
>  }
> +EXPORT_SYMBOL(nla_put_nohdr);
>  
>  /**
>   * nla_append - Add a netlink attribute without header or padding
> @@ -454,20 +463,13 @@ int nla_append(struct sk_buff *skb, int attrlen, const void *data)
>  	memcpy(skb_put(skb, attrlen), data, attrlen);
>  	return 0;
>  }
> +EXPORT_SYMBOL(nla_append);
> +#endif
>  
>  EXPORT_SYMBOL(nla_validate);
>  EXPORT_SYMBOL(nla_parse);
>  EXPORT_SYMBOL(nla_find);
>  EXPORT_SYMBOL(nla_strlcpy);
> -EXPORT_SYMBOL(__nla_reserve);
> -EXPORT_SYMBOL(__nla_reserve_nohdr);
> -EXPORT_SYMBOL(nla_reserve);
> -EXPORT_SYMBOL(nla_reserve_nohdr);
> -EXPORT_SYMBOL(__nla_put);
> -EXPORT_SYMBOL(__nla_put_nohdr);
> -EXPORT_SYMBOL(nla_put);
> -EXPORT_SYMBOL(nla_put_nohdr);
>  EXPORT_SYMBOL(nla_memcpy);
>  EXPORT_SYMBOL(nla_memcmp);
>  EXPORT_SYMBOL(nla_strcmp);
> -EXPORT_SYMBOL(nla_append);
> 
> Thanks,


-- 
~Randy