* linux-next: Tree for April 24 @ 2009-04-24 5:04 Stephen Rothwell 2009-04-24 6:55 ` Next April 24 : BUG: lock held at task exit time! Sachin Sant ` (3 more replies) 0 siblings, 4 replies; 18+ messages in thread From: Stephen Rothwell @ 2009-04-24 5:04 UTC (permalink / raw) To: linux-next; +Cc: LKML [-- Attachment #1: Type: text/plain, Size: 6784 bytes --] Hi all, I have added a tree that contains only simple build fixes for Linus' tree. It currently contains: lib: find_next_bit.o needed by a module only, move it from lib to obj powerpc: fix for long standing bug noticed by gcc 4.4.0 This is just an experiment for now and I am not sure if I should push these fixes directly to Linus ... Changes since 20090423: New tree: fixes The acpi tree gained a build failure for which I reverted a commit. ---------------------------------------------------------------------------- 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 135 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 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 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 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 Merging s390/features Merging sh/master Merging sparc/master Merging x86/auto-x86-next Merging xtensa/master Merging configfs/linux-next Merging ext4/next Merging fatfs/master Merging fuse/for-next Merging gfs2/master Merging jfs/next Merging nfs/linux-next Merging nfsd/nfsd-next Merging nilfs2/for-next Merging ocfs2/linux-next Merging squashfs/master Merging v9fs/for-next CONFLICT (content): Merge conflict in net/9p/protocol.c Merging ubifs/linux-next Merging xfs/master Merging tip-core/auto-core-next Merging cpus4096/auto-cpus4096-next Merging tracing/auto-tracing-next Merging genirq/auto-genirq-next Merging safe-poison-pointers/auto-safe-poison-pointers-next Merging sched/auto-sched-next Merging stackprotector/auto-stackprotector-next Merging timers/auto-timers-next Merging pci/linux-next Merging quilt/device-mapper Merging hid/for-next Merging quilt/i2c Merging quilt/jdelvare-hwmon Merging quilt/kernel-doc Merging v4l-dvb/master Merging quota/for_next Merging kbuild/master Merging ide/for-next Merging libata/NEXT Merging infiniband/for-next Merging acpi/test Merging ieee1394/for-next Merging ubi/linux-next Merging kvm/master Merging dlm/next Merging scsi/master Merging async_tx/next Merging udf/for_next Merging net/master Merging wireless/master CONFLICT (content): Merge conflict in drivers/net/wireless/rndis_wlan.c CONFLICT (content): Merge conflict in include/linux/mmc/sdio_ids.h CONFLICT (content): Merge conflict in net/mac80211/pm.c [master ad362c6] Revert "rfkill: remove user_claim stuff" Merging mtd/master Merging crypto/master Merging vfs/for-next Merging sound/for-next Merging cpufreq/next Merging quilt/rr CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c Merging cifs/master Merging mmc/next Merging input/next Merging bkl-removal/bkl-removal Merging lsm/for-next Merging block/for-next Merging embedded/master Merging firmware/master Merging pcmcia/master Merging battery/master Merging leds/for-mm Merging backlight/for-mm 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 Merging security-testing/next Merging lblnet/master Merging quilt/ttydev CONFLICT (content): Merge conflict in drivers/usb/serial/cypress_m8.c CONFLICT (content): Merge conflict in drivers/usb/serial/option.c CONFLICT (content): Merge conflict in drivers/usb/serial/sierra.c CONFLICT (content): Merge conflict in drivers/usb/serial/usb-serial.c Merging agp/agp-next 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 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 Merging audit/for-next Merging omap/for-next Merging quilt/aoe Merging kmemleak/kmemleak CONFLICT (content): Merge conflict in lib/Kconfig.debug Merging suspend/linux-next Merging quilt/driver-core Merging quilt/usb Merging quilt/staging Merging scsi-post-merge/master [master 15570ec] Revert "ACPI/i915: build fix" [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Next April 24 : BUG: lock held at task exit time! 2009-04-24 5:04 linux-next: Tree for April 24 Stephen Rothwell @ 2009-04-24 6:55 ` Sachin Sant 2009-04-24 7:55 ` Stephen Rothwell 2009-04-24 7:12 ` Next April 24: [S390] allmodconfig build failure (trace/events) Sachin Sant ` (2 subsequent siblings) 3 siblings, 1 reply; 18+ messages in thread From: Sachin Sant @ 2009-04-24 6:55 UTC (permalink / raw) To: Stephen Rothwell; +Cc: linux-next, LKML, linuxppc-dev, Ingo Molnar, peterz [-- Attachment #1: Type: text/plain, Size: 1233 bytes --] While booting today's next tree on a powerpc box [ power 6 blade] observed the following : khelper used greatest stack depth: 10176 bytes left ===================================== [ BUG: lock held at task exit time! ] ------------------------------------- khelper/21 is exiting with locks still held! 2 locks held by khelper/21: #0: (rcu_read_lock){.+.+.+}, at: [<c0000000001382fc>] .check_unsafe_exec+0x44/0x148 #1: (rcu_read_lock){.+.+.+}, at: [<c000000000138368>] .check_unsafe_exec+0xb0/0x148 stack backtrace: Call Trace: [c000000044483cf0] [c000000000011a54] .show_stack+0x6c/0x16c (unreliable) [c000000044483da0] [c00000000009ae14] .debug_check_no_locks_held+0x98/0xb4 [c000000044483e20] [c000000000073b1c] .do_exit+0x758/0x7b0 [c000000044483f00] [c0000000000853d8] .____call_usermodehelper+0x170/0x174 [c000000044483f90] [c00000000002bd8c] .kernel_thread+0x54/0x70 net_namespace: 2000 bytes Complete dmesg attached. Let me know if you need any other info. I will try yesterday's next tree to check if this problem can be recreated. Thanks -Sachin -- --------------------------------- Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India --------------------------------- [-- Attachment #2: dmesg_next0424 --] [-- Type: text/plain, Size: 12730 bytes --] Using pSeries machine description Page orders: linear mapping = 16, virtual = 16, io = 12, vmemmap = 24 Using 1TB segments Found initrd at 0xc000000003600000:0xc000000003bebc74 console [udbg0] enabled Partition configured for 8 cpus. CPU maps initialized for 2 threads per core (thread shift is 1) Starting Linux PPC64 #2 SMP Fri Apr 24 11:30:39 IST 2009 ----------------------------------------------------- ppc64_pft_size = 0x19 physicalMemorySize = 0x80000000 htab_hash_mask = 0x3ffff ----------------------------------------------------- Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 2.6.30-rc3-next-20090424 (root@mjs22lp5) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #2 SMP Fri Apr 24 11:30:39 IST 2009 [boot]0012 Setup Arch Node 0 Memory: 0x8000000-0x46000000 Node 1 Memory: 0x0-0x8000000 0x46000000-0x80000000 EEH: No capable adapters found PPC64 nvram contains 15360 bytes Using shared processor idle loop Zone PFN ranges: DMA 0x00000000 -> 0x00008000 Normal 0x00008000 -> 0x00008000 Movable zone start PFN for each node early_node_map[3] active PFN ranges 1: 0x00000000 -> 0x00000800 0: 0x00000800 -> 0x00004600 1: 0x00004600 -> 0x00008000 On node 0 totalpages: 15872 DMA zone: 22 pages used for memmap DMA zone: 0 pages reserved DMA zone: 15850 pages, LIFO batch:1 On node 1 totalpages: 16896 DMA zone: 44 pages used for memmap DMA zone: 0 pages reserved DMA zone: 16852 pages, LIFO batch:1 [boot]0015 Setup Done Built 2 zonelists in Node order, mobility grouping on. Total pages: 32702 Policy zone: DMA Kernel command line: root=/dev/sda3 sysrq=1 Experimental hierarchical RCU implementation. RCU-based detection of stalled CPUs is enabled. Experimental hierarchical RCU init done. NR_IRQS:512 [boot]0020 XICS Init [boot]0021 XICS Done pic: no ISA interrupt controller PID hash table entries: 4096 (order: 12, 32768 bytes) time_init: decrementer frequency = 512.000000 MHz time_init: processor frequency = 4005.000000 MHz clocksource: timebase mult[7d0000] shift[22] registered clockevent: decrementer mult[8312] shift[16] cpu[0] Console: colour dummy device 80x25 console handover: boot [udbg0] -> real [hvc0] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES: 8 ... MAX_LOCK_DEPTH: 48 ... MAX_LOCKDEP_KEYS: 8191 ... CLASSHASH_SIZE: 4096 ... MAX_LOCKDEP_ENTRIES: 8192 ... MAX_LOCKDEP_CHAINS: 16384 ... CHAINHASH_SIZE: 8192 memory used by lock dependency info: 4607 kB per task-struct memory footprint: 1920 bytes allocated 1310720 bytes of page_cgroup please try cgroup_disable=memory option if you don't want freeing bootmem node 0 freeing bootmem node 1 Memory: 2035200k/2097152k available (8448k kernel code, 67136k reserved, 1216k data, 8988k bss, 448k init) ODEBUG: 0 of 0 active objects replaced ODEBUG: selftest passed Calibrating delay loop... 1021.95 BogoMIPS (lpj=510976) Security Framework initialized SELinux: Initializing. SELinux: Starting in permissive mode Dentry cache hash table entries: 262144 (order: 5, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 4, 1048576 bytes) Mount-cache hash table entries: 4096 Initializing cgroup subsys ns Initializing cgroup subsys cpuacct Initializing cgroup subsys memory Initializing cgroup subsys devices Initializing cgroup subsys freezer irq: irq 2 on host null mapped to virtual irq 16 Testing tracer nop: PASSED clockevent: decrementer mult[8312] shift[16] cpu[1] Processor 1 found. clockevent: decrementer mult[8312] shift[16] cpu[2] Processor 2 found. clockevent: decrementer mult[8312] shift[16] cpu[3] Processor 3 found. Brought up 4 CPUs Node 0 CPUs: 0-3 Node 1 CPUs: CPU0 attaching sched-domain: domain 0: span 0-1 level SIBLING groups: 0 1 domain 1: span 0-3 level CPU groups: 0-1 2-3 domain 2: span 0-3 level NODE groups: 0-3 (__cpu_power = 2048) CPU1 attaching sched-domain: domain 0: span 0-1 level SIBLING groups: 1 0 domain 1: span 0-3 level CPU groups: 0-1 2-3 domain 2: span 0-3 level NODE groups: 0-3 (__cpu_power = 2048) CPU2 attaching sched-domain: domain 0: span 2-3 level SIBLING groups: 2 3 domain 1: span 0-3 level CPU groups: 2-3 0-1 domain 2: span 0-3 level NODE groups: 0-3 (__cpu_power = 2048) CPU3 attaching sched-domain: domain 0: span 2-3 level SIBLING groups: 3 2 domain 1: span 0-3 level CPU groups: 2-3 0-1 domain 2: span 0-3 level NODE groups: 0-3 (__cpu_power = 2048) khelper used greatest stack depth: 10176 bytes left ===================================== [ BUG: lock held at task exit time! ] ------------------------------------- khelper/21 is exiting with locks still held! 2 locks held by khelper/21: #0: (rcu_read_lock){.+.+.+}, at: [<c0000000001382fc>] .check_unsafe_exec+0x44/0x148 #1: (rcu_read_lock){.+.+.+}, at: [<c000000000138368>] .check_unsafe_exec+0xb0/0x148 stack backtrace: Call Trace: [c000000044483cf0] [c000000000011a54] .show_stack+0x6c/0x16c (unreliable) [c000000044483da0] [c00000000009ae14] .debug_check_no_locks_held+0x98/0xb4 [c000000044483e20] [c000000000073b1c] .do_exit+0x758/0x7b0 [c000000044483f00] [c0000000000853d8] .____call_usermodehelper+0x170/0x174 [c000000044483f90] [c00000000002bd8c] .kernel_thread+0x54/0x70 net_namespace: 2000 bytes NET: Registered protocol family 16 IBM eBus Device Driver PCI: Probing PCI hardware PCI: Probing PCI hardware done bio: create slab <bio-0> at 0 SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb NetLabel: Initializing NetLabel: domain hash size = 128 NetLabel: protocols = UNLABELED CIPSOv4 NetLabel: unlabeled traffic allowed by default Failed to register trace events module notifier NET: Registered protocol family 2 IP route cache hash table entries: 16384 (order: 1, 131072 bytes) TCP established hash table entries: 65536 (order: 4, 1048576 bytes) TCP bind hash table entries: 65536 (order: 5, 3670016 bytes) TCP: Hash tables configured (established 65536 bind 65536) TCP reno registered NET: Registered protocol family 1 checking if image is initramfs... rootfs image is initramfs; unpacking... Freeing initrd memory: 6063k freed irq: irq 655360 on host null mapped to virtual irq 17 irq: irq 655362 on host null mapped to virtual irq 18 IOMMU table initialized, virtual merging enabled irq: irq 655364 on host null mapped to virtual irq 19 irq: irq 655365 on host null mapped to virtual irq 20 irq: irq 589825 on host null mapped to virtual irq 21 RTAS daemon started audit: initializing netlink socket (disabled) type=2000 audit(1240553894.305:1): initialized Kprobe smoke test started Kprobe smoke test passed successfully HugeTLB registered 16 MB page size, pre-allocated 0 pages HugeTLB registered 16 GB page size, pre-allocated 0 pages VFS: Disk quotas dquot_6.5.2 Dquot-cache hash table entries: 8192 (order 0, 65536 bytes) Btrfs loaded msgmni has been set to 3984 SELinux: Registering netfilter hooks alg: No test for stdrng (krng) io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) pci_hotplug: PCI Hot Plug PCI Core version: 0.5 rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1 vio_register_driver: driver hvc_console registering HVSI: registered 0 devices Linux agpgart interface v0.103 Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled brd: module loaded Uniform Multi-Platform E-IDE driver ide-gd driver 1.18 vio_register_driver: driver ibmvscsi registering ibmvscsi 30000002: SRP_VERSION: 16.a scsi0 : IBM POWER Virtual SCSI Adapter 1.5.8 ibmvscsi 30000002: partner initialization complete ibmvscsi 30000002: sent SRP login ibmvscsi 30000002: SRP_LOGIN succeeded ibmvscsi 30000002: host srp version: 16.a, host partition 06-1C12A (1), OS 3, max io 262144 scsi 0:0:1:0: Direct-Access AIX VDASD 0001 PQ: 0 ANSI: 3 scsi 0:0:2:0: CD-ROM AIX VOPTA PQ: 0 ANSI: 4 ibmvfc: IBM Virtual Fibre Channel Driver version: 1.0.5 (March 19, 2009) vio_register_driver: driver ibmvfc registering st: Version 20081215, fixed bufsize 32768, s/g segs 256 Driver 'st' needs updating - please use bus_type methods osst :I: Tape driver with OnStream support version 0.99.4 osst :I: $Id: osst.c,v 1.73 2005/01/01 21:13:34 wriede Exp $ Driver 'osst' needs updating - please use bus_type methods Driver 'sd' needs updating - please use bus_type methods Driver 'sr' needs updating - please use bus_type methods sr0: scsi-1 drive Uniform CD-ROM driver Revision: 3.20 sd 0:0:1:0: [sda] 33554432 512-byte hardware sectors: (17.1 GB/16.0 GiB) sd 0:0:1:0: [sda] Write Protect is off sd 0:0:1:0: [sda] Mode Sense: 17 00 00 08 sd 0:0:1:0: [sda] Cache data unavailable sd 0:0:1:0: [sda] Assuming drive cache: write through sr 0:0:2:0: Attached scsi CD-ROM sr0 sd 0:0:1:0: [sda] Cache data unavailable sd 0:0:1:0: [sda] Assuming drive cache: write through sda:<5>sd 0:0:1:0: Attached scsi generic sg0 type 0 sr 0:0:2:0: Attached scsi generic sg1 type 5 ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver uhci_hcd: USB Universal Host Controller Interface driver mice: PS/2 mouse device common for all mice sda1 sda2 sda3 sda4 <<6>usbcore: registered new interface driver hiddev usbcore: registered new interface driver usbhid usbhid: v2.6:USB HID core driver TCP bic registered Initializing XFRM netlink socket NET: Registered protocol family 17 registered taskstats version 1 Running tests on trace events: Testing event kfree_skb: sda5 sda6 > sd 0:0:1:0: [sda] Attached SCSI disk OK Testing event kmem_cache_free: OK Testing event kfree: OK Testing event kmem_cache_alloc_node: OK Testing event kmalloc_node: OK Testing event kmem_cache_alloc: OK Testing event kmalloc: OK Testing event irq_handler_exit: OK Testing event softirq_exit: OK Testing event softirq_entry: OK Testing event irq_handler_entry: OK Testing event lock_release: OK Testing event lock_acquire: OK Testing event sched_signal_send: OK Testing event sched_process_fork: OK Testing event sched_process_wait: OK Testing event sched_process_exit: OK Testing event sched_process_free: OK Testing event sched_migrate_task: OK Testing event sched_switch: OK Testing event sched_wakeup_new: OK Testing event sched_wakeup: OK Testing event sched_wait_task: OK Testing event sched_kthread_stop_ret: OK Testing event sched_kthread_stop: OK Running tests on trace event systems: Testing event system skb: OK Testing event system kmem: OK Testing event system irq: OK Testing event system lockdep: OK Testing event system sched: OK Running tests on all trace events: Testing all events: OK Freeing unused kernel memory: 448k freed SysRq : Changing Loglevel Loglevel set to 1 udevd version 128 started scsi_id used greatest stack depth: 9104 bytes left vol_id used greatest stack depth: 8432 bytes left kjournald starting. Commit interval 5 seconds EXT3 FS on sda3, internal journal EXT3-fs: mounted filesystem with writeback data mode. stty used greatest stack depth: 8096 bytes left mount used greatest stack depth: 7504 bytes left udevd version 128 started drivers/net/ibmveth.c: ibmveth: IBM i/pSeries Virtual Ethernet Driver 1.03 vio_register_driver: driver ibmveth registering IBM eHEA ethernet device driver (Release EHEA_0100) irq: irq 590080 on host null mapped to virtual irq 256 ehea: eth2: Jumbo frames are enabled ehea: eth2 -> logical port id #9 ehea: eth3: Jumbo frames are enabled ehea: eth3 -> logical port id #10 modprobe used greatest stack depth: 7200 bytes left Adding 2096320k swap on /dev/sda5. Priority:-1 extents:1 across:2096320k device-mapper: uevent: version 1.0.3 device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel@redhat.com loop: module loaded kjournald starting. Commit interval 5 seconds EXT3 FS on sda2, internal journal EXT3-fs: mounted filesystem with writeback data mode. kjournald starting. Commit interval 5 seconds EXT3-fs warning: maximal mount count reached, running e2fsck is recommended EXT3 FS on sda6, internal journal EXT3-fs: mounted filesystem with writeback data mode. mv used greatest stack depth: 7008 bytes left ehea: eth2: Physical port up irq: irq 775 on host null mapped to virtual irq 263 ehea: External switch port is backup port irq: irq 776 on host null mapped to virtual irq 264 NET: Registered protocol family 10 lo: Disabled Privacy Extensions modprobe used greatest stack depth: 6752 bytes left eth2: no IPv6 routers present less used greatest stack depth: 6336 bytes left ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Next April 24 : BUG: lock held at task exit time! 2009-04-24 6:55 ` Next April 24 : BUG: lock held at task exit time! Sachin Sant @ 2009-04-24 7:55 ` Stephen Rothwell 2009-04-24 11:55 ` Hugh Dickins 0 siblings, 1 reply; 18+ messages in thread From: Stephen Rothwell @ 2009-04-24 7:55 UTC (permalink / raw) To: Sachin Sant Cc: linux-next, LKML, linuxppc-dev, Ingo Molnar, peterz, Hugh Dickins, Al Viro, Oleg Nesterov [-- Attachment #1: Type: text/plain, Size: 1607 bytes --] Hi Sachin, On Fri, 24 Apr 2009 12:25:41 +0530 Sachin Sant <sachinp@in.ibm.com> wrote: > > While booting today's next tree on a powerpc box [ power 6 blade] > observed the following : > > khelper used greatest stack depth: 10176 bytes left > > ===================================== > [ BUG: lock held at task exit time! ] > ------------------------------------- > khelper/21 is exiting with locks still held! > 2 locks held by khelper/21: > #0: (rcu_read_lock){.+.+.+}, at: [<c0000000001382fc>] > .check_unsafe_exec+0x44/0x148 > #1: (rcu_read_lock){.+.+.+}, at: [<c000000000138368>] > .check_unsafe_exec+0xb0/0x148 > > stack backtrace: > Call Trace: > [c000000044483cf0] [c000000000011a54] .show_stack+0x6c/0x16c (unreliable) > [c000000044483da0] [c00000000009ae14] .debug_check_no_locks_held+0x98/0xb4 > [c000000044483e20] [c000000000073b1c] .do_exit+0x758/0x7b0 > [c000000044483f00] [c0000000000853d8] .____call_usermodehelper+0x170/0x174 > [c000000044483f90] [c00000000002bd8c] .kernel_thread+0x54/0x70 > net_namespace: 2000 bytes > > Complete dmesg attached. Let me know if you need any other info. I will > try yesterday's next > tree to check if this problem can be recreated. Almost certainly commit 874a9e18f25c86dbc199ad32ddd9ca44d25290e8 ("check_unsafe_exec: s/lock_task_sighand/rcu_read_lock/") which has a typo (two locks instead of lock/unlock) as pointed out by Hugh Dickins (<Pine.LNX.4.64.0904240526080.15735@blonde.anvils> on LKML). -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Next April 24 : BUG: lock held at task exit time! 2009-04-24 7:55 ` Stephen Rothwell @ 2009-04-24 11:55 ` Hugh Dickins 2009-04-24 14:04 ` Al Viro 0 siblings, 1 reply; 18+ messages in thread From: Hugh Dickins @ 2009-04-24 11:55 UTC (permalink / raw) To: Stephen Rothwell Cc: peterz, LKML, Oleg Nesterov, linuxppc-dev, linux-next, Al Viro, Ingo Molnar On Fri, 24 Apr 2009, Stephen Rothwell wrote: > On Fri, 24 Apr 2009 12:25:41 +0530 Sachin Sant <sachinp@in.ibm.com> wrote: > > > > While booting today's next tree on a powerpc box [ power 6 blade] > > observed the following : > > > > khelper used greatest stack depth: 10176 bytes left > > > > ===================================== > > [ BUG: lock held at task exit time! ] > > ------------------------------------- > > khelper/21 is exiting with locks still held! > > 2 locks held by khelper/21: > > #0: (rcu_read_lock){.+.+.+}, at: [<c0000000001382fc>] > > .check_unsafe_exec+0x44/0x148 > > #1: (rcu_read_lock){.+.+.+}, at: [<c000000000138368>] > > .check_unsafe_exec+0xb0/0x148 > > > > stack backtrace: > > Call Trace: > > [c000000044483cf0] [c000000000011a54] .show_stack+0x6c/0x16c (unreliable) > > [c000000044483da0] [c00000000009ae14] .debug_check_no_locks_held+0x98/0xb4 > > [c000000044483e20] [c000000000073b1c] .do_exit+0x758/0x7b0 > > [c000000044483f00] [c0000000000853d8] .____call_usermodehelper+0x170/0x174 > > [c000000044483f90] [c00000000002bd8c] .kernel_thread+0x54/0x70 > > net_namespace: 2000 bytes > > > > Complete dmesg attached. Let me know if you need any other info. I will > > try yesterday's next > > tree to check if this problem can be recreated. > > Almost certainly commit 874a9e18f25c86dbc199ad32ddd9ca44d25290e8 > ("check_unsafe_exec: s/lock_task_sighand/rcu_read_lock/") which has a > typo (two locks instead of lock/unlock) as pointed out by Hugh Dickins > (<Pine.LNX.4.64.0904240526080.15735@blonde.anvils> on LKML). Indeed, thanks for the headsup Stephen. My own config gives, not Sachin's message (or not still visibly on screen anyway), but an outright panic. Shame that leaked out into the big world, we'd all have preferred a quiet fixup! Here's a patch, which I'll also send as reply to the relevant thread. [PATCH] check_unsafe_exec: rcu_read_unlock Fix typo in previous commit: second rcu_read_lock should be rcu_read_unlock. Signed-off-by: Hugh Dickins <hugh@veritas.com> --- fs/exec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- 2.6.30-rc3-next-20090424/fs/exec.c 2009-04-24 12:23:43.000000000 +0100 +++ linux/fs/exec.c 2009-04-24 12:26:10.000000000 +0100 @@ -1043,7 +1043,7 @@ int check_unsafe_exec(struct linux_binpr if (t->fs == p->fs) n_fs++; } - rcu_read_lock(); + rcu_read_unlock(); if (p->fs->users > n_fs) { bprm->unsafe |= LSM_UNSAFE_SHARE; ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Next April 24 : BUG: lock held at task exit time! 2009-04-24 11:55 ` Hugh Dickins @ 2009-04-24 14:04 ` Al Viro 2009-04-24 14:11 ` Stephen Rothwell 0 siblings, 1 reply; 18+ messages in thread From: Al Viro @ 2009-04-24 14:04 UTC (permalink / raw) To: Hugh Dickins Cc: Stephen Rothwell, Sachin Sant, linux-next, LKML, linuxppc-dev, Ingo Molnar, peterz, Oleg Nesterov On Fri, Apr 24, 2009 at 12:55:44PM +0100, Hugh Dickins wrote: > Indeed, thanks for the headsup Stephen. My own config gives, not > Sachin's message (or not still visibly on screen anyway), but an > outright panic. Shame that leaked out into the big world, we'd > all have preferred a quiet fixup! Here's a patch, which I'll > also send as reply to the relevant thread. Applied, will fold on reorder (since Ingo is asking for what will amount to reorder anyway). ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Next April 24 : BUG: lock held at task exit time! 2009-04-24 14:04 ` Al Viro @ 2009-04-24 14:11 ` Stephen Rothwell 0 siblings, 0 replies; 18+ messages in thread From: Stephen Rothwell @ 2009-04-24 14:11 UTC (permalink / raw) To: Al Viro Cc: peterz, LKML, Oleg Nesterov, linuxppc-dev, linux-next, Hugh Dickins, Ingo Molnar [-- Attachment #1.1: Type: text/plain, Size: 309 bytes --] Hi Al, On Fri, 24 Apr 2009 15:04:45 +0100 Al Viro <viro@ZenIV.linux.org.uk> wrote: > > Applied, will fold on reorder (since Ingo is asking for what will amount > to reorder anyway). Thanks. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --] [-- Attachment #2: Type: text/plain, Size: 146 bytes --] _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ^ permalink raw reply [flat|nested] 18+ messages in thread
* Next April 24: [S390] allmodconfig build failure (trace/events) 2009-04-24 5:04 linux-next: Tree for April 24 Stephen Rothwell 2009-04-24 6:55 ` Next April 24 : BUG: lock held at task exit time! Sachin Sant @ 2009-04-24 7:12 ` Sachin Sant 2009-04-24 7:25 ` Ingo Molnar [not found] ` <20090424150456.ff35e4ea.sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org> 2009-04-26 13:20 ` linux-next: Tree for April 24 Benny Halevy 3 siblings, 1 reply; 18+ messages in thread From: Sachin Sant @ 2009-04-24 7:12 UTC (permalink / raw) To: linux-s390; +Cc: linux-next, LKML, Heiko Carstens, Ingo Molnar Today's next tree build(s390 allmodconfig) failed with kernel/built-in.o: In function `trace_softirq_entry' include/trace/events/irq.h:42: undefined reference to `__tracepoint_softirq_entry' include/trace/events/irq.h:42: undefined reference to `__tracepoint_softirq_entry' kernel/built-in.o: In function `trace_softirq_exit': include/trace/events/irq.h:48: undefined reference to `__tracepoint_softirq_exit' include/trace/events/irq.h:48: undefined reference to `__tracepoint_softirq_exit' Thanks -Sachin -- --------------------------------- Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India --------------------------------- ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Next April 24: [S390] allmodconfig build failure (trace/events) 2009-04-24 7:12 ` Next April 24: [S390] allmodconfig build failure (trace/events) Sachin Sant @ 2009-04-24 7:25 ` Ingo Molnar 2009-04-24 8:41 ` Heiko Carstens 0 siblings, 1 reply; 18+ messages in thread From: Ingo Molnar @ 2009-04-24 7:25 UTC (permalink / raw) To: Sachin Sant, Steven Rostedt, Frédéric Weisbecker Cc: linux-s390, linux-next, LKML, Heiko Carstens, Ingo Molnar * Sachin Sant <sachinp@in.ibm.com> wrote: > Today's next tree build(s390 allmodconfig) failed with > > kernel/built-in.o: In function `trace_softirq_entry' > include/trace/events/irq.h:42: undefined reference to > `__tracepoint_softirq_entry' > include/trace/events/irq.h:42: undefined reference to > `__tracepoint_softirq_entry' > kernel/built-in.o: In function `trace_softirq_exit': > include/trace/events/irq.h:48: undefined reference to > `__tracepoint_softirq_exit' > include/trace/events/irq.h:48: undefined reference to > `__tracepoint_softirq_exit' Hm, that's weird - s390 does not build kernel/softirq.o? Hm, it does - softirq.o is an obj-y object. Ingo ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Next April 24: [S390] allmodconfig build failure (trace/events) 2009-04-24 7:25 ` Ingo Molnar @ 2009-04-24 8:41 ` Heiko Carstens 2009-04-29 9:51 ` Sachin Sant 0 siblings, 1 reply; 18+ messages in thread From: Heiko Carstens @ 2009-04-24 8:41 UTC (permalink / raw) To: Ingo Molnar Cc: Sachin Sant, Steven Rostedt, Frédéric Weisbecker, linux-s390, linux-next, LKML, Ingo Molnar On Fri, 24 Apr 2009 09:25:33 +0200 Ingo Molnar <mingo@elte.hu> wrote: > > * Sachin Sant <sachinp@in.ibm.com> wrote: > > > Today's next tree build(s390 allmodconfig) failed with > > > > kernel/built-in.o: In function `trace_softirq_entry' > > include/trace/events/irq.h:42: undefined reference to > > `' > > include/trace/events/irq.h:42: undefined reference to > > `__tracepoint_softirq_entry' > > kernel/built-in.o: In function `trace_softirq_exit': > > include/trace/events/irq.h:48: undefined reference to > > `__tracepoint_softirq_exit' > > include/trace/events/irq.h:48: undefined reference to > > `__tracepoint_softirq_exit' > > Hm, that's weird - s390 does not build kernel/softirq.o? Hm, it does > - softirq.o is an obj-y object. s390 does build kernel/softirq.o. However it's anything but obvious to me how the tracepoint infrastructure works. Too many #ifdefs, #define's and #undefine's... I would expect that struct __tracepoint_softirq_entry somehow gets defined via one of the TRACE_FORMAT macros, no? kernel/softirq.i has these parts wrt. __tracepoint_softirq_entry: # 42 "include/trace/events/irq.h" extern struct tracepoint __tracepoint_softirq_entry; static inline __attribute__((always_inline)) void trace_softirq_entry(struc t softirq_action *h, struct softirq_action *vec) { if (__builtin_expect(!!(__tracepoint_softirq_entry.state), 0)) do { void **it _func; do { } while (0); it_func = ({ typeof((&__tracepoint_softirq_entry)->funcs) _________p1 = (*(volatile typeof((&__tracepoi nt_softirq_entry)->funcs) *)&((&__tracepoint_softirq_entry)->funcs)); do { } while(0); (_________p1); }); if (it_func) { do { (( void(*)(struct softirq_action *h, struct softirq_action *vec))(*it_func))(h, vec); } while (*(++it_func)); } do { } while (0); } while (0); } static inline __attribute__((always_inline)) int register_trace_softirq_entry(void (*probe)(struct softirq_action *h, struct softirq_action *vec)) { return tracepoint_probe_register("softirq_entry", (void *)probe); } static inline __attribute __((always_inline)) int unregister_trace_softirq_entry(void (*probe)(struct softirq_action *h, struct softirq_action *vec)) { re turn tracepoint_probe_unregister("softirq_entry", (void *)probe); }; extern struct tracepoint __tracepoint_softirq_exit; static inline __attribute__((always_inline)) void trace_softirq_exit(struct softirq_action *h, struct softirq_action *vec) { if (__builtin_expect(!!(__tracepoint_softirq_exit.state), 0)) do { void **it_fu nc; do { } while (0); it_func = ({ typeof((&__tracepoint_softirq_exit)->funcs) _________p1 = (*(volatile typeof((&__tracepoint_s oftirq_exit)->funcs) *)&((&__tracepoint_softirq_exit)->funcs)); do { } while(0); (_________p1); }); if (it_func) { do { ((void(* )(struct softirq_action *h, struct softirq_action *vec))(*it_func))(h, vec); } while (*(++it_func)); } do { } while (0); } while (0); } static inline __attribute__((always_inline)) int register_trace_softirq_exit(void (*probe)(struct softirq_action *h, str uct softirq_action *vec)) { return tracepoint_probe_register("softirq_exit", (void *)probe); } static inline __attribute__((alwa ys_inline)) int unregister_trace_softirq_exit(void (*probe)(struct softirq_action *h, struct softirq_action *vec)) { return trac epoint_probe_unregister("softirq_exit", (void *)probe); }; __do_softirq looks like below. So I would expect some header file include dependency? Dunno... void __do_softirq(void) { struct softirq_action *h; __u32 pending; int max_restart = 10; int cpu; pending = ((*((struct _lowcore *) 0)).softirq_pending); account_system_vtime(((struct task_struct *const)(*((struct _lowcore *) 0)).current_task)); __local_bh_disable((unsigned long)__builtin_return_address(0)); do { ((struct task_struct *const)(*((struct _lowcore *) 0)).current_task)->softirq_context++; } while (0); cpu = ((*((struct _lowcore *) 0)).cpu_nr); restart: (((*((struct _lowcore *) 0)).softirq_pending) = (0)); do { trace_hardirqs_on(); raw_local_irq_enable(); } while (0); h = softirq_vec; do { if (pending & 1) { int prev_count = (current_thread_info()->preempt_count); trace_softirq_entry(h, softirq_vec); h->action(h); trace_softirq_exit(h, softirq_vec); if (__builtin_expect(!!(prev_count != (current_thread_info()->preempt_count)), 0)) { printk("<3>" "huh, entered softirq %td %s %p" "with preempt_count %08x," " exited with %08x?\n", h - softirq_vec, softirq_to_name[h - softirq_vec], h->action, prev_count, (current_thread_info()->preempt_count)); (current_thread_info()->preempt_count) = prev_count; } rcu_bh_qsctr_inc(cpu); } h++; pending >>= 1; } while (pending); do { raw_local_irq_disable(); trace_hardirqs_off(); } while (0); pending = ((*((struct _lowcore *) 0)).softirq_pending); if (pending && --max_restart) goto restart; if (pending) wakeup_softirqd(); do { ((struct task_struct *const)(*((struct _lowcore *) 0)).current_task)->softirq_context--; } while (0); account_system_vtime(((struct task_struct *const)(*((struct _lowcore *) 0)).current_task)); _local_bh_enable(); } ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Next April 24: [S390] allmodconfig build failure (trace/events) 2009-04-24 8:41 ` Heiko Carstens @ 2009-04-29 9:51 ` Sachin Sant 2009-04-29 11:51 ` Heiko Carstens 0 siblings, 1 reply; 18+ messages in thread From: Sachin Sant @ 2009-04-29 9:51 UTC (permalink / raw) To: Heiko Carstens, Ingo Molnar Cc: Steven Rostedt, Frédéric Weisbecker, linux-s390, linux-next, LKML Heiko Carstens wrote: > On Fri, 24 Apr 2009 09:25:33 +0200 > Ingo Molnar <mingo@elte.hu> wrote: > > >> * Sachin Sant <sachinp@in.ibm.com> wrote: >> >> >>> Today's next tree build(s390 allmodconfig) failed with >>> >>> kernel/built-in.o: In function `trace_softirq_entry' >>> include/trace/events/irq.h:42: undefined reference to >>> `' >>> include/trace/events/irq.h:42: undefined reference to >>> `__tracepoint_softirq_entry' >>> kernel/built-in.o: In function `trace_softirq_exit': >>> include/trace/events/irq.h:48: undefined reference to >>> `__tracepoint_softirq_exit' >>> include/trace/events/irq.h:48: undefined reference to >>> `__tracepoint_softirq_exit' >>> >> Hm, that's weird - s390 does not build kernel/softirq.o? Hm, it does >> - softirq.o is an obj-y object. >> > > s390 does build kernel/softirq.o. However it's anything but obvious to > me how the tracepoint infrastructure works. Too many #ifdefs, #define's > and #undefine's... > > I would expect that struct __tracepoint_softirq_entry somehow gets > defined via one of the TRACE_FORMAT macros, no? Today's next tree also has this failure. Any solution for this problem ? Thanks -Sachin -- --------------------------------- Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India --------------------------------- ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Next April 24: [S390] allmodconfig build failure (trace/events) 2009-04-29 9:51 ` Sachin Sant @ 2009-04-29 11:51 ` Heiko Carstens 2009-04-29 12:04 ` Ingo Molnar 2009-04-29 12:09 ` Steven Rostedt 0 siblings, 2 replies; 18+ messages in thread From: Heiko Carstens @ 2009-04-29 11:51 UTC (permalink / raw) To: Sachin Sant Cc: Ingo Molnar, Steven Rostedt, Frédéric Weisbecker, linux-s390, linux-next, LKML On Wed, 29 Apr 2009 15:21:39 +0530 Sachin Sant <sachinp@in.ibm.com> wrote: > Heiko Carstens wrote: > > On Fri, 24 Apr 2009 09:25:33 +0200 > > Ingo Molnar <mingo@elte.hu> wrote: > >> * Sachin Sant <sachinp@in.ibm.com> wrote: > >>> Today's next tree build(s390 allmodconfig) failed with > >>> > >>> kernel/built-in.o: In function `trace_softirq_entry' > >>> include/trace/events/irq.h:42: undefined reference to > >>> `' > >>> include/trace/events/irq.h:42: undefined reference to > >>> `__tracepoint_softirq_entry' > >>> kernel/built-in.o: In function `trace_softirq_exit': > >>> include/trace/events/irq.h:48: undefined reference to > >>> `__tracepoint_softirq_exit' > >>> include/trace/events/irq.h:48: undefined reference to > >>> `__tracepoint_softirq_exit' > >>> > >> Hm, that's weird - s390 does not build kernel/softirq.o? Hm, it does > >> - softirq.o is an obj-y object. > > > > s390 does build kernel/softirq.o. However it's anything but obvious to > > me how the tracepoint infrastructure works. Too many #ifdefs, #define's > > and #undefine's... > > > > I would expect that struct __tracepoint_softirq_entry somehow gets > > defined via one of the TRACE_FORMAT macros, no? > Today's next tree also has this failure. Any solution for this problem ? Ingo, could you pick up the patch below please? Subject: [PATCH] tracing: fix compile error From: Heiko Carstens <heiko.carstens@de.ibm.com> "tracing: create automated trace defines" causes this compile error on s390: kernel/built-in.o: In function `__do_softirq': (.text+0x1c680): undefined reference to `__tracepoint_softirq_entry' This happens because the definitions of the softirq tracepoints were moved from kernel/softirq.c to kernel/irq/handle.c. Since s390 doesn't support generic hardirqs handle.c doesn't get compiled and the definitions are missing. So move the tracepoints to softirq.c again. Reported-by: Sachin Sant <sachinp@in.ibm.com> Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> --- kernel/irq/handle.c | 2 -- kernel/softirq.c | 2 ++ 2 files changed, 2 insertions(+), 2 deletions(-) Index: linux-next/kernel/irq/handle.c =================================================================== --- linux-next.orig/kernel/irq/handle.c +++ linux-next/kernel/irq/handle.c @@ -18,8 +18,6 @@ #include <linux/rculist.h> #include <linux/hash.h> #include <linux/bootmem.h> - -#define CREATE_TRACE_POINTS #include <trace/events/irq.h> #include "internals.h" Index: linux-next/kernel/softirq.c =================================================================== --- linux-next.orig/kernel/softirq.c +++ linux-next/kernel/softirq.c @@ -24,6 +24,8 @@ #include <linux/ftrace.h> #include <linux/smp.h> #include <linux/tick.h> + +#define CREATE_TRACE_POINTS #include <trace/events/irq.h> #include <asm/irq.h> ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Next April 24: [S390] allmodconfig build failure (trace/events) 2009-04-29 11:51 ` Heiko Carstens @ 2009-04-29 12:04 ` Ingo Molnar 2009-04-29 12:09 ` Steven Rostedt 1 sibling, 0 replies; 18+ messages in thread From: Ingo Molnar @ 2009-04-29 12:04 UTC (permalink / raw) To: Heiko Carstens Cc: Sachin Sant, Steven Rostedt, Frédéric Weisbecker, linux-s390, linux-next, LKML * Heiko Carstens <heiko.carstens@de.ibm.com> wrote: > On Wed, 29 Apr 2009 15:21:39 +0530 > Sachin Sant <sachinp@in.ibm.com> wrote: > > Heiko Carstens wrote: > > > On Fri, 24 Apr 2009 09:25:33 +0200 > > > Ingo Molnar <mingo@elte.hu> wrote: > > >> * Sachin Sant <sachinp@in.ibm.com> wrote: > > >>> Today's next tree build(s390 allmodconfig) failed with > > >>> > > >>> kernel/built-in.o: In function `trace_softirq_entry' > > >>> include/trace/events/irq.h:42: undefined reference to > > >>> `' > > >>> include/trace/events/irq.h:42: undefined reference to > > >>> `__tracepoint_softirq_entry' > > >>> kernel/built-in.o: In function `trace_softirq_exit': > > >>> include/trace/events/irq.h:48: undefined reference to > > >>> `__tracepoint_softirq_exit' > > >>> include/trace/events/irq.h:48: undefined reference to > > >>> `__tracepoint_softirq_exit' > > >>> > > >> Hm, that's weird - s390 does not build kernel/softirq.o? Hm, it does > > >> - softirq.o is an obj-y object. > > > > > > s390 does build kernel/softirq.o. However it's anything but obvious to > > > me how the tracepoint infrastructure works. Too many #ifdefs, #define's > > > and #undefine's... > > > > > > I would expect that struct __tracepoint_softirq_entry somehow gets > > > defined via one of the TRACE_FORMAT macros, no? > > Today's next tree also has this failure. Any solution for this problem ? > > Ingo, could you pick up the patch below please? applied, thanks Heiko! Ingo ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Next April 24: [S390] allmodconfig build failure (trace/events) 2009-04-29 11:51 ` Heiko Carstens 2009-04-29 12:04 ` Ingo Molnar @ 2009-04-29 12:09 ` Steven Rostedt 1 sibling, 0 replies; 18+ messages in thread From: Steven Rostedt @ 2009-04-29 12:09 UTC (permalink / raw) To: Heiko Carstens Cc: Sachin Sant, Ingo Molnar, Frédéric Weisbecker, linux-s390, linux-next, LKML On Wed, 29 Apr 2009, Heiko Carstens wrote: > > Subject: [PATCH] tracing: fix compile error > > From: Heiko Carstens <heiko.carstens@de.ibm.com> > > "tracing: create automated trace defines" causes this compile error on s390: > > kernel/built-in.o: In function `__do_softirq': > (.text+0x1c680): undefined reference to `__tracepoint_softirq_entry' > > This happens because the definitions of the softirq tracepoints were moved > from kernel/softirq.c to kernel/irq/handle.c. Since s390 doesn't support > generic hardirqs handle.c doesn't get compiled and the definitions are > missing. > So move the tracepoints to softirq.c again. Nice catch! Acked-by: Steven Rostedt <rostedt@goodmis.org> -- Steve ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <20090424150456.ff35e4ea.sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>]
* Re: linux-next: Tree for April 24 (p54 build error) [not found] ` <20090424150456.ff35e4ea.sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org> @ 2009-04-24 17:56 ` Randy Dunlap 2009-04-24 20:47 ` linux-next: Tree for April 24 (p54 build error) (and pull request: wireless-next-2.6 2009-04-24) Christian Lamparter 0 siblings, 1 reply; 18+ messages in thread From: Randy Dunlap @ 2009-04-24 17:56 UTC (permalink / raw) To: Stephen Rothwell Cc: linux-next-u79uwXL29TY76Z2rM5mHXA, LKML, linux-wireless-u79uwXL29TY76Z2rM5mHXA drivers/net/wireless/p54/p54.h:193: error: array type has incomplete element type struct p54_led_dev definition is controlled by #ifdef CONFIG_P54_LEDS (is not set) but the struct declaration is controlled by #ifdef CONFIG_MAC80211_LEDS (=y) -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: linux-next: Tree for April 24 (p54 build error) (and pull request: wireless-next-2.6 2009-04-24) 2009-04-24 17:56 ` linux-next: Tree for April 24 (p54 build error) Randy Dunlap @ 2009-04-24 20:47 ` Christian Lamparter [not found] ` <200904242247.15042.chunkeey-S0/GAf8tV78@public.gmane.org> 0 siblings, 1 reply; 18+ messages in thread From: Christian Lamparter @ 2009-04-24 20:47 UTC (permalink / raw) To: Randy Dunlap; +Cc: Stephen Rothwell, linux-next, LKML, linux-wireless, davem On Friday 24 April 2009 19:56:27 Randy Dunlap wrote: > > drivers/net/wireless/p54/p54.h:193: error: array type has incomplete element type > > struct p54_led_dev definition is controlled by > #ifdef CONFIG_P54_LEDS (is not set) > > but the struct declaration is controlled by > #ifdef CONFIG_MAC80211_LEDS (=y) > meh, [p54: more SoftLED updates] broke it ( dce072580e095d1fb7be59a1be30dc0e8307821b ) this also affects "pull request: wireless-next-2.6 2009-04-24" and the current wireless-testing! however the patches on the linux-wireless are all fine?! (see: http://osdir.com/ml/linux-wireless/2009-03/msg01240.html ) I guess there was merge conflict with [p54: more SoftLED updates] and [p54: replace MAC80211_LEDS with P54_LEDS in p54.h] ? Regards, Chr --- In case someone want to fix it manually... here's the undo: --- diff --git a/drivers/net/wireless/p54/p54.h b/drivers/net/wireless/p54/p54.h index 7fda1a9..db3df94 100644 --- a/drivers/net/wireless/p54/p54.h +++ b/drivers/net/wireless/p54/p54.h @@ -189,10 +189,10 @@ struct p54_common { unsigned long *used_rxkeys; /* LED management */ -#ifdef CONFIG_MAC80211_LEDS +#ifdef CONFIG_P54_LEDS struct p54_led_dev leds[4]; struct delayed_work led_work; -#endif /* CONFIG_MAC80211_LEDS */ +#endif /* CONFIG_P54_LEDS */ u16 softled_state; /* bit field of glowing LEDs */ /* statistics */ ^ permalink raw reply related [flat|nested] 18+ messages in thread
[parent not found: <200904242247.15042.chunkeey-S0/GAf8tV78@public.gmane.org>]
* Re: linux-next: Tree for April 24 (p54 build error) (and pull request: wireless-next-2.6 2009-04-24) [not found] ` <200904242247.15042.chunkeey-S0/GAf8tV78@public.gmane.org> @ 2009-04-30 18:30 ` John W. Linville 0 siblings, 0 replies; 18+ messages in thread From: John W. Linville @ 2009-04-30 18:30 UTC (permalink / raw) To: Christian Lamparter Cc: Randy Dunlap, Stephen Rothwell, linux-next-u79uwXL29TY76Z2rM5mHXA, LKML, linux-wireless-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q If you want patches to be noticed and applied, it would be most helpful if you could submit them in a regular and recognizable way. http://linux.yyz.us/patch-format.html John On Fri, Apr 24, 2009 at 10:47:14PM +0200, Christian Lamparter wrote: > On Friday 24 April 2009 19:56:27 Randy Dunlap wrote: > > > > drivers/net/wireless/p54/p54.h:193: error: array type has incomplete element type > > > > struct p54_led_dev definition is controlled by > > #ifdef CONFIG_P54_LEDS (is not set) > > > > but the struct declaration is controlled by > > #ifdef CONFIG_MAC80211_LEDS (=y) > > > meh, [p54: more SoftLED updates] broke it > ( dce072580e095d1fb7be59a1be30dc0e8307821b ) > > this also affects "pull request: wireless-next-2.6 2009-04-24" > > and the current wireless-testing! > > however the patches on the linux-wireless are all fine?! > (see: http://osdir.com/ml/linux-wireless/2009-03/msg01240.html ) > > I guess there was merge conflict with [p54: more SoftLED updates] > and [p54: replace MAC80211_LEDS with P54_LEDS in p54.h] ? > > Regards, > Chr > --- > In case someone want to fix it manually... here's the undo: > --- > diff --git a/drivers/net/wireless/p54/p54.h b/drivers/net/wireless/p54/p54.h > index 7fda1a9..db3df94 100644 > --- a/drivers/net/wireless/p54/p54.h > +++ b/drivers/net/wireless/p54/p54.h > @@ -189,10 +189,10 @@ struct p54_common { > unsigned long *used_rxkeys; > > /* LED management */ > -#ifdef CONFIG_MAC80211_LEDS > +#ifdef CONFIG_P54_LEDS > struct p54_led_dev leds[4]; > struct delayed_work led_work; > -#endif /* CONFIG_MAC80211_LEDS */ > +#endif /* CONFIG_P54_LEDS */ > u16 softled_state; /* bit field of glowing LEDs */ > > /* statistics */ > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- John W. Linville Someday the world will need a hero, and you linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: linux-next: Tree for April 24 2009-04-24 5:04 linux-next: Tree for April 24 Stephen Rothwell ` (2 preceding siblings ...) [not found] ` <20090424150456.ff35e4ea.sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org> @ 2009-04-26 13:20 ` Benny Halevy 2009-04-27 4:21 ` Stephen Rothwell 3 siblings, 1 reply; 18+ messages in thread From: Benny Halevy @ 2009-04-26 13:20 UTC (permalink / raw) To: Stephen Rothwell; +Cc: linux-next, LKML On Apr. 24, 2009, 8:04 +0300, Stephen Rothwell <sfr@canb.auug.org.au> wrote: > Hi all, > > I have added a tree that contains only simple build fixes for Linus' > tree. It currently contains: > > lib: find_next_bit.o needed by a module only, move it from lib to obj Thanks Stephan! I've already sent this patch directly to Linus (and while at it, correcting its subject) It's committed as a5422a5111811401f7756345e4c237ff06cf6d1e in Linus' tree. Benny > powerpc: fix for long standing bug noticed by gcc 4.4.0 > > This is just an experiment for now and I am not sure if I should push > these fixes directly to Linus ... > > Changes since 20090423: > > New tree: > fixes > > The acpi tree gained a build failure for which I reverted a commit. > > ---------------------------------------------------------------------------- > > 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 135 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. > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: linux-next: Tree for April 24 2009-04-26 13:20 ` linux-next: Tree for April 24 Benny Halevy @ 2009-04-27 4:21 ` Stephen Rothwell 0 siblings, 0 replies; 18+ messages in thread From: Stephen Rothwell @ 2009-04-27 4:21 UTC (permalink / raw) To: Benny Halevy; +Cc: linux-next, LKML [-- Attachment #1: Type: text/plain, Size: 429 bytes --] Hi Benny, On Sun, 26 Apr 2009 16:20:36 +0300 Benny Halevy <bhalevy@panasas.com> wrote: > > I've already sent this patch directly to Linus (and while at it, > correcting its subject) > It's committed as a5422a5111811401f7756345e4c237ff06cf6d1e > in Linus' tree. Thanks. I have removed it from my fixes tree. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2009-04-30 18:30 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-04-24 5:04 linux-next: Tree for April 24 Stephen Rothwell 2009-04-24 6:55 ` Next April 24 : BUG: lock held at task exit time! Sachin Sant 2009-04-24 7:55 ` Stephen Rothwell 2009-04-24 11:55 ` Hugh Dickins 2009-04-24 14:04 ` Al Viro 2009-04-24 14:11 ` Stephen Rothwell 2009-04-24 7:12 ` Next April 24: [S390] allmodconfig build failure (trace/events) Sachin Sant 2009-04-24 7:25 ` Ingo Molnar 2009-04-24 8:41 ` Heiko Carstens 2009-04-29 9:51 ` Sachin Sant 2009-04-29 11:51 ` Heiko Carstens 2009-04-29 12:04 ` Ingo Molnar 2009-04-29 12:09 ` Steven Rostedt [not found] ` <20090424150456.ff35e4ea.sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org> 2009-04-24 17:56 ` linux-next: Tree for April 24 (p54 build error) Randy Dunlap 2009-04-24 20:47 ` linux-next: Tree for April 24 (p54 build error) (and pull request: wireless-next-2.6 2009-04-24) Christian Lamparter [not found] ` <200904242247.15042.chunkeey-S0/GAf8tV78@public.gmane.org> 2009-04-30 18:30 ` John W. Linville 2009-04-26 13:20 ` linux-next: Tree for April 24 Benny Halevy 2009-04-27 4:21 ` Stephen Rothwell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).