linux-next: Tree for December 1

linux-next: Tree for December 1

[Stephen Rothwell]

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

Hi all,

Changes since 20091130:

The origin tree gained a build failure for which I reverted a commit.
Ingo also reported another build failure for which I applied his patch.

The pxa tree lost its build failure.

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

The net tree gained a conflict against the wireless-current tree.

The mtd tree gained a conflict against the pxa tree.

The pcmcia tree lost 2 conflicts but gained another against the arm tree.

The trivial tree lost a conflict.

The percpu tree gained a conflict against the slab tree.

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

I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/v2.6/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 - this fails its final link) 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 154 trees (counting Linus' and 21 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 fixes/fixes
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 quilt/driver-core.current
Merging quilt/tty.current
Merging quilt/usb.current
Merging quilt/staging.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 ide-curent/master
Merging dwmw2/master
[master c298b36] Revert "FS-Cache: Handle pages pending storage that get evicted under OOM conditions"
Merging arm/devel
Merging davinci/davinci-next
Merging msm/for-next
Merging omap/for-next
Merging pxa/for-next
Merging samsung/next-samsung
Merging avr32/avr32-arch
CONFLICT (content): Merge conflict in arch/avr32/mach-at32ap/include/mach/cpu.h
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
CONFLICT (content): Merge conflict in arch/m68k/include/asm/ptrace.h
Merging microblaze/next
Merging mips/mips-for-linux-next
CONFLICT (content): Merge conflict in arch/mips/Kconfig
CONFLICT (content): Merge conflict in arch/mips/Makefile
CONFLICT (content): Merge conflict in arch/mips/include/asm/ftrace.h
CONFLICT (add/add): Merge conflict in arch/mips/kernel/ftrace.c
CONFLICT (add/add): Merge conflict in arch/mips/kernel/mcount.S
CONFLICT (content): Merge conflict in drivers/net/au1000_eth.c
CONFLICT (content): Merge conflict in drivers/staging/octeon/ethernet.c
CONFLICT (content): Merge conflict in scripts/recordmcount.pl
Merging parisc/next
Merging powerpc/next
CONFLICT (content): Merge conflict in drivers/serial/of_serial.c
Merging 4xx/next
Merging 52xx-and-virtex/next
Merging galak/next
Merging s390/features
Merging sh/master
Merging sparc/master
Merging xtensa/master
[master 6f607ee] Revert "powerpc/mm: Fix bug in pagetable cache cleanup with CONFIG_PPC_SUBPAGE_PROT"
Merging ceph/for-next
Merging cifs/master
Merging configfs/linux-next
Merging ecryptfs/next
Merging ext3/for_next
CONFLICT (content): Merge conflict in fs/cifs/dir.c
Merging ext4/next
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging jfs/next
Merging logfs/master
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging squashfs/master
Merging udf/for_next
Merging v9fs/for-next
Merging ubifs/linux-next
Merging xfs/master
Merging reiserfs-bkl/reiserfs/kill-bkl
Merging vfs/for-next
Merging pci/linux-next
Merging hid/for-next
Merging quilt/i2c
Merging bjdooks-i2c/next-i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
Merging kbuild/for-next
Merging kconfig/for-next
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
CONFLICT (content): Merge conflict in drivers/pci/hotplug/acpiphp_glue.c
Merging ieee1394/for-next
CONFLICT (content): Merge conflict in drivers/media/dvb/firewire/firedtv-1394.c
CONFLICT (content): Merge conflict in drivers/media/dvb/firewire/firedtv-avc.c
CONFLICT (add/add): Merge conflict in drivers/media/dvb/firewire/firedtv-fw.c
CONFLICT (content): Merge conflict in drivers/media/dvb/firewire/firedtv.h
Merging ubi/linux-next
Merging kvm/linux-next
Merging dlm/next
Merging scsi/master
Merging async_tx/next
Merging net/master
CONFLICT (content): Merge conflict in net/mac80211/ht.c
CONFLICT (delete/modify): net/wireless/wext.c deleted in net/master and modified in HEAD. Version HEAD of net/wireless/wext.c left in tree.
$ git rm -f net/wireless/wext.c
Applying: wext: merg fixup
Merging wireless/master
Merging mtd/master
CONFLICT (content): Merge conflict in drivers/mtd/devices/m25p80.c
CONFLICT (content): Merge conflict in drivers/mtd/nand/pxa3xx_nand.c
Merging crypto/master
Merging sound/for-next
Applying: ASoC: tlv320dac33: Change RT wq to singlethread wq
Merging cpufreq/next
CONFLICT (content): Merge conflict in include/acpi/processor.h
Merging quilt/rr
CONFLICT (content): Merge conflict in arch/arm/kernel/vmlinux.lds.S
Applying: modpost: autoconf.h has moved to include/generated
Applying: staging: fix a silly typo
Applying: wireless: fix for mismerge
Merging mmc/next
Merging tmio-mmc/linux-next
Merging input/next
Merging lsm/for-next
Merging block/for-next
Merging quilt/device-mapper
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
CONFLICT (content): Merge conflict in drivers/mtd/maps/pcmciamtd.c
CONFLICT (content): Merge conflict in drivers/net/pcmcia/fmvj18x_cs.c
CONFLICT (content): Merge conflict in drivers/net/pcmcia/nmclan_cs.c
CONFLICT (content): Merge conflict in drivers/net/wireless/ray_cs.c
CONFLICT (content): Merge conflict in drivers/pcmcia/Makefile
CONFLICT (content): Merge conflict in drivers/pcmcia/sa1100_h3600.c
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
CONFLICT (content): Merge conflict in drivers/platform/x86/thinkpad_acpi.c
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging voltage/for-next
CONFLICT (content): Merge conflict in drivers/mfd/Kconfig
CONFLICT (content): Merge conflict in drivers/mfd/Makefile
Merging security-testing/next
CONFLICT (content): Merge conflict in Documentation/dontdiff
Merging lblnet/master
Merging agp/agp-next
Merging uwb/for-upstream
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
CONFLICT (content): Merge conflict in Documentation/video4linux/gspca.txt
Merging audit/for-next
Merging quilt/aoe
Merging suspend/linux-next
Merging bluetooth/master
Merging fsnotify/for-next
CONFLICT (content): Merge conflict in arch/x86/ia32/ia32entry.S
CONFLICT (content): Merge conflict in arch/x86/include/asm/unistd_32.h
CONFLICT (content): Merge conflict in arch/x86/include/asm/unistd_64.h
CONFLICT (content): Merge conflict in arch/x86/kernel/syscall_table_32.S
CONFLICT (content): Merge conflict in fs/afs/write.c
CONFLICT (content): Merge conflict in fs/cifs/dir.c
CONFLICT (content): Merge conflict in fs/ubifs/file.c
CONFLICT (content): Merge conflict in include/asm-generic/fcntl.h
CONFLICT (content): Merge conflict in net/socket.c
Merging irda/for-next
Merging hwlat/for-linus
CONFLICT (content): Merge conflict in drivers/misc/Makefile
Merging drbd/for-jens
Merging catalin/for-next
Merging alacrity/linux-next
CONFLICT (content): Merge conflict in include/linux/Kbuild
CONFLICT (content): Merge conflict in lib/Kconfig
Merging i7core_edac/linux_next
Applying: i7core_edac: do not export static functions
Merging devicetree/next-devicetree
Merging spi/next-spi
Merging limits/writable_limits
Merging omap_dss2/for-next
Merging tip/auto-latest
CONFLICT (content): Merge conflict in arch/x86/kernel/kgdb.c
CONFLICT (content): Merge conflict in kernel/Makefile
CONFLICT (content): Merge conflict in kernel/irq/chip.c
CONFLICT (content): Merge conflict in kernel/printk.c
CONFLICT (content): Merge conflict in scripts/recordmcount.pl
Merging edac-amd/for-next
Merging oprofile/for-next
Merging percpu/for-next
CONFLICT (content): Merge conflict in arch/powerpc/platforms/pseries/hvCall.S
CONFLICT (content): Merge conflict in arch/x86/kvm/svm.c
CONFLICT (content): Merge conflict in kernel/softlockup.c
CONFLICT (content): Merge conflict in mm/slab.c
Applying: percpu: merge fixup for variable renaming
Merging workqueues/for-next
CONFLICT (content): Merge conflict in init/Kconfig
CONFLICT (content): Merge conflict in kernel/sched.c
Merging sfi/sfi-test
Merging asm-generic/next
Merging hwpoison/hwpoison
Merging sysctl/master
CONFLICT (content): Merge conflict in net/ipv6/addrconf.c
CONFLICT (content): Merge conflict in net/sctp/sysctl.c
Merging quilt/driver-core
Merging quilt/tty
Merging quilt/usb
CONFLICT (content): Merge conflict in arch/arm/plat-mxc/Makefile
Merging quilt/staging
CONFLICT (content): Merge conflict in drivers/staging/Kconfig
CONFLICT (content): Merge conflict in drivers/staging/Makefile
CONFLICT (content): Merge conflict in drivers/staging/comedi/drivers/ni_labpc_cs.c
CONFLICT (content): Merge conflict in drivers/staging/comedi/drivers/ni_mio_cs.c
Merging scsi-post-merge/master
Applying: slow-work: Fix build bug in the !CONFIG_MODULES case

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

Re: linux-next: Tree for December 1

[Michal Simek]

Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20091130:
> 
> The origin tree gained a build failure for which I reverted a commit.
> Ingo also reported another build failure for which I applied his patch.
> 
> The pxa tree lost its build failure.
> 
> The powerpc tree gained a build failure for which I reverted a commit.
> 
> The net tree gained a conflict against the wireless-current tree.
> 
> The mtd tree gained a conflict against the pxa tree.
> 
> The pcmcia tree lost 2 conflicts but gained another against the arm tree.
> 
> The trivial tree lost a conflict.
> 
> The percpu tree gained a conflict against the slab tree.


It seems to me that percpu has more other troubles too.
Look at boolog below for Microblaze with MMU.

I haven't look at that problem deeper but I will.
Any suggestion what could be wrong?

Problems started in linux-next from November 27.
You can look at logs.
http://www.monstr.eu/wiki/doku.php?id=log:log

Thanks,
Michal

early_printk_console is enabled at 0x84000000
Ramdisk addr 0x00000003, FDT at 0x9099c414
Linux version 2.6.32-rc8-next-20091201 (monstr@monstr.eu) (gcc version 
4.1.2) #1 Tue Dec 1 09:34:15 CET 2009
setup_cpuinfo: initialising
setup_cpuinfo: Using full CPU PVR support
setup_memory: max_mapnr: 0x10000
setup_memory: min_low_pfn: 0x90000
setup_memory: max_low_pfn: 0xa0000
On node 0 totalpages: 65536
free_area_init_node: node 0, pgdat c02cc768, node_mem_map c09a1000
   Normal zone: 512 pages used for memmap
   Normal zone: 0 pages reserved
   Normal zone: 65024 pages, LIFO batch:15
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
Kernel command line: console=ttyUL0,115200
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 249600k/262144k available
Hierarchical RCU implementation.
NR_IRQS:32
xlnx,xps-intc-1.00.a #0 at 0xd0000000, num_irq=9, edge=0x100
xlnx,xps-timer-1.00.a #0 at 0xd0004000, irq=3
microblaze_timer_set_mode: shutdown
microblaze_timer_set_mode: periodic
Calibrating delay loop... 119.19 BogoMIPS (lpj=595968)
Mount-cache hash table entries: 512
------------[ cut here ]------------
WARNING: at include/linux/percpu.h:157 __create_workqueue_key+0x1c0/0x1d0()
Modules linked in:

Stack:
   cf831f1c c0033694 00000000 00000000 c022dac0 c0013f40 c022836c c022dac0
   0000009d c0029814 0001ffff c0973e20 cf8032e4 00000000 00000000 c022dad8
   c002980c 00000000 c02d68f8 c02e6218 00000000 00000000 c022dad8 c02d5860
Call Trace:

[<c0033694>] atomic_notifier_chain_register+0x40/0x64
[<c0013f40>] warn_slowpath_null+0xc/0x20
[<c0029814>] __create_workqueue_key+0x1c0/0x1d0
[<c002980c>] __create_workqueue_key+0x1b8/0x1d0
[<c02d68f8>] spawn_softlockup_task+0x0/0xc0
[<c02d5860>] init_workqueues+0x48/0xa0
[<c02ce104>] kernel_init+0x0/0x184
[<c02ce148>] kernel_init+0x44/0x184
[<c02ce170>] kernel_init+0x6c/0x184
[<c00023a0>] kernel_thread_helper+0xc/0x20
[<c0002394>] kernel_thread_helper+0x0/0x20

---[ end trace 139ce121c98e96c9 ]---
NET: Registered protocol family 16
bio: create slab <bio-0> at 0
Switching to clocksource microblaze_clocksource
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 5, 163840 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
NET: Registered protocol family 1
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Slow work thread pool: Starting up
Slow work thread pool: Ready
msgmni has been set to 487
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
84000000.serial: ttyUL0 at MMIO 0x84000003 (irq = 8) is a uartlite
console [ttyUL0] enabled
brd: module loaded
TCP cubic registered
NET: Registered protocol family 17
Freeing unused kernel memory: 6801k freed
Mounting proc:
Mounting var:
Populating /var:
Running local start scripts.
Mounting sysfs:
Setting hostname:
Setting up interface lo:
Setting up interface eth0:
BUG: failure at kernel/workqueue.c:431/process_one_work()!
Kernel panic - not syncing: BUG!
Rebooting in 120 seconds..timeout


> 
> ----------------------------------------------------------------------------
> 
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> (patches at http://www.kernel.org/pub/linux/kernel/v2.6/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 - this fails its final link) 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 154 trees (counting Linus' and 21 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.
> 


-- 
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663

problems in linux-next (Was: Re: linux-next: Tree for December 1)

[Stephen Rothwell]

cc'ing the percpu and workqueue folks ...

On Tue, 01 Dec 2009 09:42:10 +0100 Michal Simek <michal.simek@petalogix.com> wrote:
> 
> It seems to me that percpu has more other troubles too.
> Look at boolog below for Microblaze with MMU.

Or may the workqueue additions?

> I haven't look at that problem deeper but I will.
> Any suggestion what could be wrong?
> 
> Problems started in linux-next from November 27.
> You can look at logs.
> http://www.monstr.eu/wiki/doku.php?id=log:log
> 
> Thanks,
> Michal
> 
> early_printk_console is enabled at 0x84000000
> Ramdisk addr 0x00000003, FDT at 0x9099c414
> Linux version 2.6.32-rc8-next-20091201 (monstr@monstr.eu) (gcc version 
> 4.1.2) #1 Tue Dec 1 09:34:15 CET 2009
> setup_cpuinfo: initialising
> setup_cpuinfo: Using full CPU PVR support
> setup_memory: max_mapnr: 0x10000
> setup_memory: min_low_pfn: 0x90000
> setup_memory: max_low_pfn: 0xa0000
> On node 0 totalpages: 65536
> free_area_init_node: node 0, pgdat c02cc768, node_mem_map c09a1000
>    Normal zone: 512 pages used for memmap
>    Normal zone: 0 pages reserved
>    Normal zone: 65024 pages, LIFO batch:15
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
> Kernel command line: console=ttyUL0,115200
> PID hash table entries: 1024 (order: 0, 4096 bytes)
> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> Memory: 249600k/262144k available
> Hierarchical RCU implementation.
> NR_IRQS:32
> xlnx,xps-intc-1.00.a #0 at 0xd0000000, num_irq=9, edge=0x100
> xlnx,xps-timer-1.00.a #0 at 0xd0004000, irq=3
> microblaze_timer_set_mode: shutdown
> microblaze_timer_set_mode: periodic
> Calibrating delay loop... 119.19 BogoMIPS (lpj=595968)
> Mount-cache hash table entries: 512
> ------------[ cut here ]------------
> WARNING: at include/linux/percpu.h:157 __create_workqueue_key+0x1c0/0x1d0()
> Modules linked in:
> 
> Stack:
>    cf831f1c c0033694 00000000 00000000 c022dac0 c0013f40 c022836c c022dac0
>    0000009d c0029814 0001ffff c0973e20 cf8032e4 00000000 00000000 c022dad8
>    c002980c 00000000 c02d68f8 c02e6218 00000000 00000000 c022dad8 c02d5860
> Call Trace:
> 
> [<c0033694>] atomic_notifier_chain_register+0x40/0x64
> [<c0013f40>] warn_slowpath_null+0xc/0x20
> [<c0029814>] __create_workqueue_key+0x1c0/0x1d0
> [<c002980c>] __create_workqueue_key+0x1b8/0x1d0
> [<c02d68f8>] spawn_softlockup_task+0x0/0xc0
> [<c02d5860>] init_workqueues+0x48/0xa0
> [<c02ce104>] kernel_init+0x0/0x184
> [<c02ce148>] kernel_init+0x44/0x184
> [<c02ce170>] kernel_init+0x6c/0x184
> [<c00023a0>] kernel_thread_helper+0xc/0x20
> [<c0002394>] kernel_thread_helper+0x0/0x20
> 
> ---[ end trace 139ce121c98e96c9 ]---
> NET: Registered protocol family 16
> bio: create slab <bio-0> at 0
> Switching to clocksource microblaze_clocksource
> NET: Registered protocol family 2
> IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
> TCP established hash table entries: 8192 (order: 4, 65536 bytes)
> TCP bind hash table entries: 8192 (order: 5, 163840 bytes)
> TCP: Hash tables configured (established 8192 bind 8192)
> TCP reno registered
> NET: Registered protocol family 1
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> RPC: Registered tcp NFSv4.1 backchannel transport module.
> Slow work thread pool: Starting up
> Slow work thread pool: Ready
> msgmni has been set to 487
> io scheduler noop registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> 84000000.serial: ttyUL0 at MMIO 0x84000003 (irq = 8) is a uartlite
> console [ttyUL0] enabled
> brd: module loaded
> TCP cubic registered
> NET: Registered protocol family 17
> Freeing unused kernel memory: 6801k freed
> Mounting proc:
> Mounting var:
> Populating /var:
> Running local start scripts.
> Mounting sysfs:
> Setting hostname:
> Setting up interface lo:
> Setting up interface eth0:
> BUG: failure at kernel/workqueue.c:431/process_one_work()!
> Kernel panic - not syncing: BUG!
> Rebooting in 120 seconds..timeout
> 
> -- 
> Michal Simek, Ing. (M.Eng)
> PetaLogix - Linux Solutions for a Reconfigurable World
> w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663


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

Re: linux-next: Tree for December 1

[Mark Brown]

On Tue, Dec 01, 2009 at 07:03:01PM +1100, Stephen Rothwell wrote:

> Merging sound/for-next
> Applying: ASoC: tlv320dac33: Change RT wq to singlethread wq

According to this the sound tree should be being merged into the next
tree but when I look in the master branch of your git I'm not seeing any
sign of it - am I missing something here?  The head of your master
branch that I see is 16aa56906ae11bfdb145676a5fb5c5f43394148d "Add
linux-next specific files for 20091201".

The same thing happened yesterday.

Re: linux-next: Tree for December 1

[Takashi Iwai]

At Tue, 1 Dec 2009 10:29:01 +0000,
Mark Brown wrote:
> 
> On Tue, Dec 01, 2009 at 07:03:01PM +1100, Stephen Rothwell wrote:
> 
> > Merging sound/for-next
> > Applying: ASoC: tlv320dac33: Change RT wq to singlethread wq
> 
> According to this the sound tree should be being merged into the next
> tree but when I look in the master branch of your git I'm not seeing any
> sign of it - am I missing something here?  The head of your master
> branch that I see is 16aa56906ae11bfdb145676a5fb5c5f43394148d "Add
> linux-next specific files for 20091201".
> 
> The same thing happened yesterday.

Stephen, please drop that specific patch from your tree (if it's really
applied).  It's been already in sound git tree, so the build should be
OK now without it.


thanks,

Takashi

Re: linux-next: Tree for December 1

[Stephen Rothwell]

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

Hi Mark,

On Tue, 1 Dec 2009 10:29:01 +0000 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
>
> On Tue, Dec 01, 2009 at 07:03:01PM +1100, Stephen Rothwell wrote:
> 
> > Merging sound/for-next
> > Applying: ASoC: tlv320dac33: Change RT wq to singlethread wq
> 
> According to this the sound tree should be being merged into the next
> tree but when I look in the master branch of your git I'm not seeing any
> sign of it - am I missing something here?  The head of your master
> branch that I see is 16aa56906ae11bfdb145676a5fb5c5f43394148d "Add
> linux-next specific files for 20091201".
> 
> The same thing happened yesterday.

Thanks for letting me know.  A bug in my procedures.  It will be fixed
tomorrow, sorry for the inconvenience.

Because the above patch is no longer needed all the changes in the sound
tree have been applied in the merge of the crypto tree, so all the
changes are there, just not very obvious.

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

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

Re: linux-next: Tree for December 1

[Stephen Rothwell]

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

Hi Takashi,

On Tue, 01 Dec 2009 11:43:46 +0100 Takashi Iwai <tiwai@suse.de> wrote:
>
> Stephen, please drop that specific patch from your tree (if it's really
> applied).  It's been already in sound git tree, so the build should be
> OK now without it.

Yeah, that is what I missed yesterday.  I will not try to apply it
tomorrow so everything should be well again.

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

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

Re: problems in linux-next (Was: Re: linux-next: Tree for December 1)

[Tejun Heo]

Hello,

On 12/01/2009 07:03 PM, Stephen Rothwell wrote:
>> WARNING: at include/linux/percpu.h:157 __create_workqueue_key+0x1c0/0x1d0()
>> Modules linked in:

Argh... The warning is about requested alignment larger than
SMP_CACHE_BYTES.  93fba1c02ec10870a9d41085ef036b6a44cb0234 aligns cwqs
to 8 bytes and later one will push it to 128 bytes so that color codes
for flushes can be put there too.  As the number of cwqs will be
significantly reduced and cwq is supposed to be aligned to cacheline
anyway, 128 byte alignment in itself isn't too bad and percpu
allocator can handle it just fine.

The problem is that on UP configurations.  Percpu memory allocator
becomes a simple wrapper around kmalloc and there's no way to specify
larger alignment when requesting memory from kmalloc.

It would be best if there's a clean way to allocate memory with
alignment larger than SMP_CACHE_BYTES.  If not, I think I'll add a
separate cache for cwqs on UP so that the alignment requirement can be
met.  Is there any way to get better aligned memory without creating a
separate cache or allocating larger memory and aligning by chopping
off?

Thanks.

-- 
tejun

Re: problems in linux-next (Was: Re: linux-next: Tree for December 1)

[Christoph Lameter]

On Tue, 1 Dec 2009, Tejun Heo wrote:

> The problem is that on UP configurations.  Percpu memory allocator
> becomes a simple wrapper around kmalloc and there's no way to specify
> larger alignment when requesting memory from kmalloc.

There is usually no point in aligning in UP. Alignment is typically done
for smp configurations to limit cache line bouncing and control cache line
use/

> It would be best if there's a clean way to allocate memory with
> alignment larger than SMP_CACHE_BYTES.  If not, I think I'll add a
> separate cache for cwqs on UP so that the alignment requirement can be
> met.  Is there any way to get better aligned memory without creating a
> separate cache or allocating larger memory and aligning by chopping
> off?

Simply drop the alignment for UP?

Re: problems in linux-next (Was: Re: linux-next: Tree for December 1)

[Ingo Molnar]

* Christoph Lameter <cl@linux-foundation.org> wrote:

> On Tue, 1 Dec 2009, Tejun Heo wrote:
> 
> > The problem is that on UP configurations.  Percpu memory allocator 
> > becomes a simple wrapper around kmalloc and there's no way to 
> > specify larger alignment when requesting memory from kmalloc.
> 
> There is usually no point in aligning in UP. Alignment is typically 
> done for smp configurations to limit cache line bouncing and control 
> cache line use/

There is a natural minimum alignment for UP and it's smaller than the 
cache-line size: machine word size. All our allocators (except bootmem) 
align to machine word so there's no need to specify this explicitly.

Larger alignment than that just wastes memory - which waste UP systems 
can afford the least.

	Ingo

[PATCH -next] media/radio/miro: depends on SND

[Randy Dunlap]

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

miropcm20 uses ALSA (snd_) interfaces from the SND_MIRO
driver, so it should depend on SND.
(selecting SND_MIRO when CONFIG_SND is not enabled is a
problem.)

drivers/built-in.o: In function `vidioc_s_ctrl':
radio-miropcm20.c:(.text+0x227499): undefined reference to `snd_aci_cmd'
drivers/built-in.o: In function `vidioc_s_frequency':
radio-miropcm20.c:(.text+0x227574): undefined reference to `snd_aci_cmd'
radio-miropcm20.c:(.text+0x227588): undefined reference to `snd_aci_cmd'
drivers/built-in.o: In function `pcm20_init':
radio-miropcm20.c:(.init.text+0x2a784): undefined reference to `snd_aci_get_aci'

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

--- linux-next-20091201.orig/drivers/media/radio/Kconfig
+++ linux-next-20091201/drivers/media/radio/Kconfig
@@ -197,7 +197,7 @@ config RADIO_MAESTRO
 
 config RADIO_MIROPCM20
 	tristate "miroSOUND PCM20 radio"
-	depends on ISA && VIDEO_V4L2
+	depends on ISA && VIDEO_V4L2 && SND
 	select SND_MIRO
 	---help---
 	  Choose Y here if you have this FM radio card. You also need to enable

[PATCH -next] kmsg_dump: fix build for CONFIG_PRINTK=n

[Randy Dunlap]

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

kmsg_dump() fails to build when CONFIG_PRINTK=n; provide stubs
for the kmsg_dump*() functions when CONFIG_PRINTK=n.

kernel/printk.c: In function 'kmsg_dump':
kernel/printk.c:1501: error: 'log_buf_len' undeclared (first use in this function)
kernel/printk.c:1502: error: 'logged_chars' undeclared (first use in this function)
kernel/printk.c:1506: error: 'log_buf' undeclared (first use in this function)

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Simon Kagstrom <simon.kagstrom@netinsight.net>
---
 include/linux/kmsg_dump.h |   16 ++++++++++++++++
 kernel/printk.c           |    2 +-
 2 files changed, 17 insertions(+), 1 deletion(-)

--- linux-next-20091201.orig/kernel/printk.c
+++ linux-next-20091201/kernel/printk.c
@@ -1406,7 +1406,6 @@ bool printk_timed_ratelimit(unsigned lon
 	return false;
 }
 EXPORT_SYMBOL(printk_timed_ratelimit);
-#endif
 
 static DEFINE_SPINLOCK(dump_list_lock);
 static LIST_HEAD(dump_list);
@@ -1525,3 +1524,4 @@ void kmsg_dump(enum kmsg_dump_reason rea
 		dumper->dump(dumper, reason, s1, l1, s2, l2);
 	spin_unlock_irqrestore(&dump_list_lock, flags);
 }
+#endif
--- linux-next-20091201.orig/include/linux/kmsg_dump.h
+++ linux-next-20091201/include/linux/kmsg_dump.h
@@ -35,10 +35,26 @@ struct kmsg_dumper {
 	int registered;
 };
 
+#ifdef CONFIG_PRINTK
 void kmsg_dump(enum kmsg_dump_reason reason);
 
 int kmsg_dump_register(struct kmsg_dumper *dumper);
 
 int kmsg_dump_unregister(struct kmsg_dumper *dumper);
+#else
+static inline void kmsg_dump(enum kmsg_dump_reason reason)
+{
+}
+
+static inline int kmsg_dump_register(struct kmsg_dumper *dumper)
+{
+	return -EINVAL;
+}
+
+static inline int kmsg_dump_unregister(struct kmsg_dumper *dumper)
+{
+	return -EINVAL;
+}
+#endif
 
 #endif /* _LINUX_KMSG_DUMP_H */

Re: problems in linux-next (Was: Re: linux-next: Tree for December 1)

[Tejun Heo]

Hello,

On 12/02/2009 01:01 AM, Ingo Molnar wrote:
>>> The problem is that on UP configurations.  Percpu memory allocator 
>>> becomes a simple wrapper around kmalloc and there's no way to 
>>> specify larger alignment when requesting memory from kmalloc.
>>
>> There is usually no point in aligning in UP. Alignment is typically 
>> done for smp configurations to limit cache line bouncing and control 
>> cache line use/
> 
> There is a natural minimum alignment for UP and it's smaller than the 
> cache-line size: machine word size. All our allocators (except bootmem) 
> align to machine word so there's no need to specify this explicitly.
> 
> Larger alignment than that just wastes memory - which waste UP systems 
> can afford the least.

This isn't usual alignment.  struct work_struct has one data fields
which is overloaded for two purposes.  Lower few bits are used to
carry flags while upper bits are used to point to sruct
cpu_workqueue_struct.  So, the number of available bits for flags are
determined by the alignment of cpu_workqueue_struct.  Memory usage for
cwqs isn't a big concern here.  Many workqueues will go away.  I think
we'll end up with less than half of what we have today while we'll
continue to have large number of works.

I'll just create alloc_cwq function which forces the alignment on UP.

Thanks.

-- 
tejun

Re: problems in linux-next (Was: Re: linux-next: Tree for December 1)

[Tejun Heo]

Hello,

On 12/01/2009 07:03 PM, Stephen Rothwell wrote:
> cc'ing the percpu and workqueue folks ...
> 
> On Tue, 01 Dec 2009 09:42:10 +0100 Michal Simek <michal.simek@petalogix.com> wrote:
>>
>> It seems to me that percpu has more other troubles too.
>> Look at boolog below for Microblaze with MMU.
> 
> Or may the workqueue additions?

The wq changes need to be rebased due to scheduler related bits.  I'm
backing them out for now.  I'll fix this problem before pushing the
series out again.

Thanks.

-- 
tejun

Re: problems in linux-next (Was: Re: linux-next: Tree for December 1)

[Stephen Rothwell]

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

Hi Tejun,

On Wed, 02 Dec 2009 14:40:29 +0900 Tejun Heo <tj@kernel.org> wrote:
>
> The wq changes need to be rebased due to scheduler related bits.  I'm
> backing them out for now.  I'll fix this problem before pushing the
> series out again.

OK, thanks for letting me know.

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

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

Re: problems in linux-next (Was: Re: linux-next: Tree for December 1)

[Tejun Heo]

Hello,

It will look like the following.

Thanks.

=========================================================================
Subject: workqueue: update cwq alignement

work->data field is used for two purposes.  It points to cwq it's
queued on and the lower bits are used for flags.  Currently, two bits
are reserved which is always safe as 4 byte alignment is guaranteed on
every architecture.  However, future changes will need more flag bits.

On SMP, the percpu allocator is capable of honoring larger alignment
(there are other users which depend on it) and larger alignment works
just fine.  On UP, percpu allocator is a thin wrapper around
kzalloc/kfree() and don't honor alignment request.

This patch introduces WORK_STRUCT_FLAG_BITS, aligns cwqs accordingly
and implements alloc/free_cwqs() which guarantees the alignment both
on SMP and UP.  On SMP, simply wrapping percpu allocator is enouhg.
On UP, extra space is allocated so that cwq can be aligned and the
original pointer can be stored after it which is used in the free
path.

While at it, as cwqs are now forced aligned, make sure the resulting
alignment is at least equal to or larger than that of long long.

Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>
---
 include/linux/workqueue.h |    4 ++-
 kernel/workqueue.c        |   58 ++++++++++++++++++++++++++++++++++++++++++----
 2 files changed, 56 insertions(+), 6 deletions(-)

Index: work/include/linux/workqueue.h
===================================================================
--- work.orig/include/linux/workqueue.h
+++ work/include/linux/workqueue.h
@@ -29,7 +29,9 @@ enum {
 	WORK_STRUCT_PENDING	= 1 << WORK_STRUCT_PENDING_BIT,
 	WORK_STRUCT_STATIC	= 1 << WORK_STRUCT_STATIC_BIT,
 
-	WORK_STRUCT_FLAG_MASK	= 3UL,
+	WORK_STRUCT_FLAG_BITS	= 2,
+
+	WORK_STRUCT_FLAG_MASK	= (1UL << WORK_STRUCT_FLAG_BITS) - 1,
 	WORK_STRUCT_WQ_DATA_MASK = ~WORK_STRUCT_FLAG_MASK,
 };
 
Index: work/kernel/workqueue.c
===================================================================
--- work.orig/kernel/workqueue.c
+++ work/kernel/workqueue.c
@@ -46,7 +46,9 @@
 
 /*
  * The per-CPU workqueue (if single thread, we always use the first
- * possible cpu).
+ * possible cpu).  The lower WORK_STRUCT_FLAG_BITS of
+ * work_struct->data are used for flags and thus cwqs need to be
+ * aligned at two's power of the number of flag bits.
  */
 struct cpu_workqueue_struct {
 
@@ -58,7 +60,7 @@ struct cpu_workqueue_struct {
 
 	struct workqueue_struct *wq;		/* I: the owning workqueue */
 	struct task_struct	*thread;
-} ____cacheline_aligned;
+} __attribute__((aligned(1 << WORK_STRUCT_FLAG_BITS)));
 
 /*
  * The externally visible workqueue abstraction is an array of
@@ -932,6 +934,44 @@ int current_is_keventd(void)
 
 }
 
+static struct cpu_workqueue_struct *alloc_cwqs(void)
+{
+	const size_t size = sizeof(struct cpu_workqueue_struct);
+	const size_t align = __alignof__(struct cpu_workqueue_struct);
+	struct cpu_workqueue_struct *cwqs;
+#ifndef CONFIG_SMP
+	void *ptr;
+
+	/*
+	 * On UP, percpu allocator doesn't honor alignment parameter
+	 * and simply uses arch-dependent default.  Allocate enough
+	 * room to align cwq and put an extra pointer at the end
+	 * pointing back to the originally allocated pointer which
+	 * will be used for free.
+	 */
+	ptr = __alloc_percpu(size + align + sizeof(void *), 1);
+	cwqs = PTR_ALIGN(ptr, align);
+	*(void **)per_cpu_ptr(cwqs + 1, 0) = ptr;
+#else
+	/* On SMP, percpu allocator can do it itself */
+	cwqs = __alloc_percpu(size, align);
+#endif
+	/* just in case, make sure it's actually aligned */
+	BUG_ON(!IS_ALIGNED((unsigned long)cwqs, align));
+	return cwqs;
+}
+
+static void free_cwqs(struct cpu_workqueue_struct *cwqs)
+{
+#ifndef CONFIG_SMP
+	/* on UP, the pointer to free is stored right after the cwq */
+	if (cwqs)
+		free_percpu(*(void **)per_cpu_ptr(cwqs + 1, 0));
+#else
+	free_percpu(cwqs);
+#endif
+}
+
 static int create_workqueue_thread(struct cpu_workqueue_struct *cwq, int cpu)
 {
 	struct workqueue_struct *wq = cwq->wq;
@@ -977,7 +1017,7 @@ struct workqueue_struct *__create_workqu
 	if (!wq)
 		goto err;
 
-	wq->cpu_wq = alloc_percpu(struct cpu_workqueue_struct);
+	wq->cpu_wq = alloc_cwqs();
 	if (!wq->cpu_wq)
 		goto err;
 
@@ -1023,7 +1063,7 @@ struct workqueue_struct *__create_workqu
 	return wq;
 err:
 	if (wq) {
-		free_percpu(wq->cpu_wq);
+		free_cwqs(wq->cpu_wq);
 		kfree(wq);
 	}
 	return NULL;
@@ -1074,7 +1114,7 @@ void destroy_workqueue(struct workqueue_
 	for_each_possible_cpu(cpu)
 		cleanup_workqueue_thread(get_cwq(cpu, wq));
 
-	free_percpu(wq->cpu_wq);
+	free_cwqs(wq->cpu_wq);
 	kfree(wq);
 }
 EXPORT_SYMBOL_GPL(destroy_workqueue);
@@ -1163,6 +1203,14 @@ EXPORT_SYMBOL_GPL(work_on_cpu);
 
 void __init init_workqueues(void)
 {
+	/*
+	 * cwqs are forced aligned according to WORK_STRUCT_FLAG_BITS.
+	 * Make sure that the alignment isn't lower than that of
+	 * unsigned long long.
+	 */
+	BUILD_BUG_ON(__alignof__(struct cpu_workqueue_struct) <
+		     __alignof__(unsigned long long));
+
 	singlethread_cpu = cpumask_first(cpu_possible_mask);
 	hotcpu_notifier(workqueue_cpu_callback, 0);
 	keventd_wq = create_workqueue("events");

Re: [PATCH -next] kmsg_dump: fix build for CONFIG_PRINTK=n

[Simon Kagstrom]

On Tue, 01 Dec 2009 10:52:02 -0800
Randy Dunlap <randy.dunlap@oracle.com> wrote:

> From: Randy Dunlap <randy.dunlap@oracle.com>
> 
> kmsg_dump() fails to build when CONFIG_PRINTK=n; provide stubs
> for the kmsg_dump*() functions when CONFIG_PRINTK=n.
> 
> kernel/printk.c: In function 'kmsg_dump':
> kernel/printk.c:1501: error: 'log_buf_len' undeclared (first use in this function)
> kernel/printk.c:1502: error: 'logged_chars' undeclared (first use in this function)
> kernel/printk.c:1506: error: 'log_buf' undeclared (first use in this function)
> 
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>

Acked-by: Simon Kagstrom <simon.kagstrom@netinsight.net>

David/Artem: Will you take Randys patch
(http://lkml.org/lkml/2009/12/1/313) into your tree as well?

// Simon

> Cc: Simon Kagstrom <simon.kagstrom@netinsight.net>
> ---
>  include/linux/kmsg_dump.h |   16 ++++++++++++++++
>  kernel/printk.c           |    2 +-
>  2 files changed, 17 insertions(+), 1 deletion(-)
> 
> --- linux-next-20091201.orig/kernel/printk.c
> +++ linux-next-20091201/kernel/printk.c
> @@ -1406,7 +1406,6 @@ bool printk_timed_ratelimit(unsigned lon
>  	return false;
>  }
>  EXPORT_SYMBOL(printk_timed_ratelimit);
> -#endif
>  
>  static DEFINE_SPINLOCK(dump_list_lock);
>  static LIST_HEAD(dump_list);
> @@ -1525,3 +1524,4 @@ void kmsg_dump(enum kmsg_dump_reason rea
>  		dumper->dump(dumper, reason, s1, l1, s2, l2);
>  	spin_unlock_irqrestore(&dump_list_lock, flags);
>  }
> +#endif
> --- linux-next-20091201.orig/include/linux/kmsg_dump.h
> +++ linux-next-20091201/include/linux/kmsg_dump.h
> @@ -35,10 +35,26 @@ struct kmsg_dumper {
>  	int registered;
>  };
>  
> +#ifdef CONFIG_PRINTK
>  void kmsg_dump(enum kmsg_dump_reason reason);
>  
>  int kmsg_dump_register(struct kmsg_dumper *dumper);
>  
>  int kmsg_dump_unregister(struct kmsg_dumper *dumper);
> +#else
> +static inline void kmsg_dump(enum kmsg_dump_reason reason)
> +{
> +}
> +
> +static inline int kmsg_dump_register(struct kmsg_dumper *dumper)
> +{
> +	return -EINVAL;
> +}
> +
> +static inline int kmsg_dump_unregister(struct kmsg_dumper *dumper)
> +{
> +	return -EINVAL;
> +}
> +#endif
>  
>  #endif /* _LINUX_KMSG_DUMP_H */

Re: problems in linux-next (Was: Re: linux-next: Tree for December 1)

[Michal Simek]

Hi Tejun,

Tejun Heo wrote:
> Hello,
> 
> It will look like the following.

I have problem to apply your patch against Stephens next tree. Which tree do you use?

Thanks,
Michal

[monstr@notebook linux-next]$ git reset --hard next-20091201
HEAD is now at 16aa569 Add linux-next specific files for 20091201
[monstr@notebook linux-next]$ git-am < problems\ in\ linux-next\ \(Was\:\ Re\:\ linux-next\:\ Tree\
for\ December\ 1\).eml
previous dotest directory .dotest still exists but mbox given.
[monstr@notebook linux-next]$ rm -rf .dotest/
[monstr@notebook linux-next]$ git-am < problems\ in\ linux-next\ \(Was\:\ Re\:\ linux-next\:\ Tree\
for\ December\ 1\).eml
Applying problems in linux-next (Was: Re: linux-next: Tree for December 1)
error: patch failed: include/linux/workqueue.h:29
error: include/linux/workqueue.h: patch does not apply
error: patch failed: kernel/workqueue.c:46
error: kernel/workqueue.c: patch does not apply
Patch failed at 0001.
When you have resolved this problem run "git-am --resolved".
If you would prefer to skip this patch, instead run "git-am --skip".


[monstr@notebook linux-next]$ git-am < problems\ in\ linux-next\ \(Was\:\ Re\:\ linux-next\:\ Tree\
for\ December\ 1\).eml
Applying problems in linux-next (Was: Re: linux-next: Tree for December 1)
error: patch failed: include/linux/workqueue.h:29
error: include/linux/workqueue.h: patch does not apply
error: patch failed: kernel/workqueue.c:46
error: kernel/workqueue.c: patch does not apply
Patch failed at 0001.
When you have resolved this problem run "git-am --resolved".
If you would prefer to skip this patch, instead run "git-am --skip".



> 
> Thanks.
> 
> =========================================================================
> Subject: workqueue: update cwq alignement
> 
> work->data field is used for two purposes.  It points to cwq it's
> queued on and the lower bits are used for flags.  Currently, two bits
> are reserved which is always safe as 4 byte alignment is guaranteed on
> every architecture.  However, future changes will need more flag bits.
> 
> On SMP, the percpu allocator is capable of honoring larger alignment
> (there are other users which depend on it) and larger alignment works
> just fine.  On UP, percpu allocator is a thin wrapper around
> kzalloc/kfree() and don't honor alignment request.
> 
> This patch introduces WORK_STRUCT_FLAG_BITS, aligns cwqs accordingly
> and implements alloc/free_cwqs() which guarantees the alignment both
> on SMP and UP.  On SMP, simply wrapping percpu allocator is enouhg.
> On UP, extra space is allocated so that cwq can be aligned and the
> original pointer can be stored after it which is used in the free
> path.
> 
> While at it, as cwqs are now forced aligned, make sure the resulting
> alignment is at least equal to or larger than that of long long.
> 
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Cc: Christoph Lameter <cl@linux-foundation.org>
> Cc: Ingo Molnar <mingo@elte.hu>
> ---
>  include/linux/workqueue.h |    4 ++-
>  kernel/workqueue.c        |   58 ++++++++++++++++++++++++++++++++++++++++++----
>  2 files changed, 56 insertions(+), 6 deletions(-)
> 
> Index: work/include/linux/workqueue.h
> ===================================================================
> --- work.orig/include/linux/workqueue.h
> +++ work/include/linux/workqueue.h
> @@ -29,7 +29,9 @@ enum {
>  	WORK_STRUCT_PENDING	= 1 << WORK_STRUCT_PENDING_BIT,
>  	WORK_STRUCT_STATIC	= 1 << WORK_STRUCT_STATIC_BIT,
>  
> -	WORK_STRUCT_FLAG_MASK	= 3UL,
> +	WORK_STRUCT_FLAG_BITS	= 2,
> +
> +	WORK_STRUCT_FLAG_MASK	= (1UL << WORK_STRUCT_FLAG_BITS) - 1,
>  	WORK_STRUCT_WQ_DATA_MASK = ~WORK_STRUCT_FLAG_MASK,
>  };
>  
> Index: work/kernel/workqueue.c
> ===================================================================
> --- work.orig/kernel/workqueue.c
> +++ work/kernel/workqueue.c
> @@ -46,7 +46,9 @@
>  
>  /*
>   * The per-CPU workqueue (if single thread, we always use the first
> - * possible cpu).
> + * possible cpu).  The lower WORK_STRUCT_FLAG_BITS of
> + * work_struct->data are used for flags and thus cwqs need to be
> + * aligned at two's power of the number of flag bits.
>   */
>  struct cpu_workqueue_struct {
>  
> @@ -58,7 +60,7 @@ struct cpu_workqueue_struct {
>  
>  	struct workqueue_struct *wq;		/* I: the owning workqueue */
>  	struct task_struct	*thread;
> -} ____cacheline_aligned;
> +} __attribute__((aligned(1 << WORK_STRUCT_FLAG_BITS)));
>  
>  /*
>   * The externally visible workqueue abstraction is an array of
> @@ -932,6 +934,44 @@ int current_is_keventd(void)
>  
>  }
>  
> +static struct cpu_workqueue_struct *alloc_cwqs(void)
> +{
> +	const size_t size = sizeof(struct cpu_workqueue_struct);
> +	const size_t align = __alignof__(struct cpu_workqueue_struct);
> +	struct cpu_workqueue_struct *cwqs;
> +#ifndef CONFIG_SMP
> +	void *ptr;
> +
> +	/*
> +	 * On UP, percpu allocator doesn't honor alignment parameter
> +	 * and simply uses arch-dependent default.  Allocate enough
> +	 * room to align cwq and put an extra pointer at the end
> +	 * pointing back to the originally allocated pointer which
> +	 * will be used for free.
> +	 */
> +	ptr = __alloc_percpu(size + align + sizeof(void *), 1);
> +	cwqs = PTR_ALIGN(ptr, align);
> +	*(void **)per_cpu_ptr(cwqs + 1, 0) = ptr;
> +#else
> +	/* On SMP, percpu allocator can do it itself */
> +	cwqs = __alloc_percpu(size, align);
> +#endif
> +	/* just in case, make sure it's actually aligned */
> +	BUG_ON(!IS_ALIGNED((unsigned long)cwqs, align));
> +	return cwqs;
> +}
> +
> +static void free_cwqs(struct cpu_workqueue_struct *cwqs)
> +{
> +#ifndef CONFIG_SMP
> +	/* on UP, the pointer to free is stored right after the cwq */
> +	if (cwqs)
> +		free_percpu(*(void **)per_cpu_ptr(cwqs + 1, 0));
> +#else
> +	free_percpu(cwqs);
> +#endif
> +}
> +
>  static int create_workqueue_thread(struct cpu_workqueue_struct *cwq, int cpu)
>  {
>  	struct workqueue_struct *wq = cwq->wq;
> @@ -977,7 +1017,7 @@ struct workqueue_struct *__create_workqu
>  	if (!wq)
>  		goto err;
>  
> -	wq->cpu_wq = alloc_percpu(struct cpu_workqueue_struct);
> +	wq->cpu_wq = alloc_cwqs();
>  	if (!wq->cpu_wq)
>  		goto err;
>  
> @@ -1023,7 +1063,7 @@ struct workqueue_struct *__create_workqu
>  	return wq;
>  err:
>  	if (wq) {
> -		free_percpu(wq->cpu_wq);
> +		free_cwqs(wq->cpu_wq);
>  		kfree(wq);
>  	}
>  	return NULL;
> @@ -1074,7 +1114,7 @@ void destroy_workqueue(struct workqueue_
>  	for_each_possible_cpu(cpu)
>  		cleanup_workqueue_thread(get_cwq(cpu, wq));
>  
> -	free_percpu(wq->cpu_wq);
> +	free_cwqs(wq->cpu_wq);
>  	kfree(wq);
>  }
>  EXPORT_SYMBOL_GPL(destroy_workqueue);
> @@ -1163,6 +1203,14 @@ EXPORT_SYMBOL_GPL(work_on_cpu);
>  
>  void __init init_workqueues(void)
>  {
> +	/*
> +	 * cwqs are forced aligned according to WORK_STRUCT_FLAG_BITS.
> +	 * Make sure that the alignment isn't lower than that of
> +	 * unsigned long long.
> +	 */
> +	BUILD_BUG_ON(__alignof__(struct cpu_workqueue_struct) <
> +		     __alignof__(unsigned long long));
> +
>  	singlethread_cpu = cpumask_first(cpu_possible_mask);
>  	hotcpu_notifier(workqueue_cpu_callback, 0);
>  	keventd_wq = create_workqueue("events");


-- 
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663

Re: problems in linux-next (Was: Re: linux-next: Tree for December 1)

[Tejun Heo]

On 12/02/2009 08:19 PM, Michal Simek wrote:
> I have problem to apply your patch against Stephens next tree. Which tree do you use?

Oh.. this is still WIP and on top of whole lot of other patches.  I'll
let you know once the series is done.

Thanks.

-- 
tejun

Re: problems in linux-next (Was: Re: linux-next: Tree for December 1)

[Christoph Lameter]

On Wed, 2 Dec 2009, Tejun Heo wrote:

> This isn't usual alignment.  struct work_struct has one data fields
> which is overloaded for two purposes.  Lower few bits are used to
> carry flags while upper bits are used to point to sruct
> cpu_workqueue_struct.  So, the number of available bits for flags are
> determined by the alignment of cpu_workqueue_struct.  Memory usage for

The default mininum slab alignment in UP is 8 bytes which means you can
use 3 bits. And as far as I can see only the lower two bits are used. You
still have one bit leftover. (current upstream that is did not check if
you modified it).

Re: problems in linux-next (Was: Re: linux-next: Tree for December 1)

[Tejun Heo]

On 12/02/2009 11:55 PM, Christoph Lameter wrote:
> On Wed, 2 Dec 2009, Tejun Heo wrote:
> 
>> This isn't usual alignment.  struct work_struct has one data fields
>> which is overloaded for two purposes.  Lower few bits are used to
>> carry flags while upper bits are used to point to sruct
>> cpu_workqueue_struct.  So, the number of available bits for flags are
>> determined by the alignment of cpu_workqueue_struct.  Memory usage for
> 
> The default mininum slab alignment in UP is 8 bytes which means you can
> use 3 bits. And as far as I can see only the lower two bits are used. You
> still have one bit leftover. (current upstream that is did not check if
> you modified it).

For colored workqueue flushing, it ends up using more than three bits.
I haven't decided it fully yet but total of six or seven depending on
how many colors are used.  So, we need forced alignment anyway.

Thanks.

-- 
tejun

Re: problems in linux-next (Was: Re: linux-next: Tree for December 1)

[Christoph Lameter]

On Thu, 3 Dec 2009, Tejun Heo wrote:

> For colored workqueue flushing, it ends up using more than three bits.
> I haven't decided it fully yet but total of six or seven depending on
> how many colors are used.  So, we need forced alignment anyway.

If it is that much then why not stick it into the structure? It only makes
sense to use the flags in the address if you otherwise do not touch the
structure.

Re: problems in linux-next (Was: Re: linux-next: Tree for December 1)

[Tejun Heo]

Hello,

On 12/03/2009 07:24 AM, Christoph Lameter wrote:
> On Thu, 3 Dec 2009, Tejun Heo wrote:
> 
>> For colored workqueue flushing, it ends up using more than three bits.
>> I haven't decided it fully yet but total of six or seven depending on
>> how many colors are used.  So, we need forced alignment anyway.
> 
> If it is that much then why not stick it into the structure?

There'll only be a handful of cwqs but a lot of works.  Adding a flags
field to work_struct might not hurt too much but all the code to
handle it is already there except for alignment on UP, so I'm a bit
reluctant to enlarge work_struct just for it.

> It only makes sense to use the flags in the address if you otherwise
> do not touch the structure.

work_struct isn't being changed at all.  What gets aligned is
cpu_workqueue_struct which allows more bits for flags in work_struct.

Thanks.

-- 
tejun