- 29 Apr, 2014 18 commits
-
-
Sam Ravnborg authored
Fix following warnings: leon_pci_grpci1.c:104:5: warning: symbol 'grpci1_map_irq' was not declared. Should it be static? leon_pci_grpci1.c:420:6: warning: symbol 'grpci1_hw_init' was not declared. Should it be static? + a lot of these: leon_pci_grpci1.c:693:18: warning: incorrect type in argument 1 (different address spaces) Added missing static to definitions. Added __iomem annotations Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Hellstrom <daniel@gaisler.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Sam Ravnborg authored
Fix following warnings: tadpole.c:21:6: warning: symbol 'cpu_pwr_save' was not declared. Should it be static? tadpole.c:101:13: warning: symbol 'clock_stop_probe' was not declared. Should it be static? This actually revealed that cpu_pwr_save is only assigned. It was left static with a TODO comment for now - this should be cleaned up later. Signed-off-by:
-
Sam Ravnborg authored
Fix following warning: devices.c:114:13: warning: symbol 'device_scan' was not declared. Should it be static? Add prototype to asm/setup.h Signed-off-by:
-
Sam Ravnborg authored
Fix following sparc32 warning: cpu.c:430:29: warning: symbol 'cpuinfo_op' was not declared. Should it be static? Fix following sparc64 warnings: cpu.c:364:14: warning: symbol 'dcache_parity_tl1_occurred' was not declared. Should it be static? cpu.c:365:14: warning: symbol 'icache_parity_tl1_occurred' was not declared. Should it be static? Rearrange asm/cpu.h to share more stuff between sparc32 and sparc64. Added missing include to cpu.c of kernel.h Signed-off-by:
-
Sam Ravnborg authored
Fix following warnings: windows.c:16:6: warning: symbol 'flush_user_windows' was not declared. Should it be static? windows.c:109:6: warning: symbol 'try_to_clear_window_buffer' was not declared. Should it be static? Add missing include of cacheflush.h + add declaration of try_to_clear_window_buffer in kernel.h Signed-off-by:
-
Sam Ravnborg authored
Fix following warnings: setup_32.c:106:15: warning: symbol 'cmdline_memory_size' was not declared. Should it be static? setup_32.c:270:16: warning: symbol 'fake_swapper_regs' was not declared. Should it be static? setup_32.c:368:55: warning: Using plain integer as NULL pointer Add missing declaration of cmdline_memory_size and remove the local one in init_32.c fake_swapper_regs was only used locally - so defined static. When replacing 0 with NULL also add a few spaces around operators Signed-off-by:
-
Sam Ravnborg authored
Fix following warnings: ioport.c:189:38: warning: Using plain integer as NULL pointer ioport.c:78:25: warning: symbol 'sparc_iomap' was not declared. Should it be static? ioport.c:403:20: warning: symbol 'sbus_dma_ops' was not declared. Should it be static? ioport.c:684:39: warning: Using plain integer as NULL pointer Add one missing prototype, and use NULL. sbus_dma_ops declared static. Signed-off-by:
-
Sam Ravnborg authored
Fix following warnings: signal_32.c:62:17: warning: symbol 'do_sigreturn' was not declared. Should it be static? signal_32.c:126:17: warning: symbol 'do_rt_sigreturn' was not declared. Should it be static? signal_32.c:344:39: warning: incorrect type in initializer (different address spaces) signal_32.c:344:39: expected struct __siginfo_fpu_t [usertype] *fp signal_32.c:344:39: got void [noderef] <asn:1>*[assigned] tail signal_32.c:346:45: warning: incorrect type in argument 2 (different address spaces) signal_32.c:346:45: expected struct __siginfo_fpu_t [noderef] [usertype] <asn:1>*fpu signal_32.c:346:45: got struct __siginfo_fpu_t [usertype] *fp signal_32.c:352:41: warning: incorrect type in initializer (different address spaces) signal_32.c:352:41: expected struct __siginfo_rwin_t [usertype] *rwp signal_32.c:352:41: got void [noderef] <asn:1>*[assigned] tail signal_32.c:354:48: warning: incorrect type in argument 2 (different address spaces) signal_32.c:354:48: expected struct __siginfo_rwin_t [noderef] [usertype] <asn:1>*rwin signal_32.c:354:48: got struct __siginfo_rwin_t [usertype] *rwp signal_32.c:509:6: warning: symbol 'do_notify_resume' was not declared. Should it be static? signal_32.c:520:16: warning: symbol 'do_sys_sigstack' was not declared. Should it be static? Add missing prototypes and annotate two variables with __user. Signed-off-by:
-
Sam Ravnborg authored
Fix following warnings: process_32.c:67:6: warning: symbol 'arch_cpu_idle' was not declared. Should it be static? process_32.c:257:16: warning: symbol 'sparc_do_fork' was not declared. Should it be static? process_32.c:411:5: warning: symbol 'dump_fpu' was not declared. Should it be static? Add missing includes and add one missing prototype. Signed-off-by:
-
Sam Ravnborg authored
Fix following warnings: irq_32.c:239:5: warning: symbol 'sparc_floppy_request_irq' was not declared. Should it be static? irq_32.c:294:24: warning: symbol 'fdc_status' was not declared. Should it be static? irq_32.c:297:6: warning: symbol 'pdma_vaddr' was not declared. Should it be static? irq_32.c:300:15: warning: symbol 'pdma_size' was not declared. Should it be static? irq_32.c:303:14: warning: symbol 'doing_pdma' was not declared. Should it be static? irq_32.c:306:6: warning: symbol 'pdma_base' was not declared. Should it be static? irq_32.c:309:15: warning: symbol 'pdma_areasize' was not declared. Should it be static? irq_32.c:317:6: warning: symbol 'sparc_floppy_irq' was not declared. Should it be static? The floppy parts were all added to iasm/setup.h - no other header files looked obvious. floppy_32.h was not an option as this file can only be included once from the floppy driver. Signed-off-by:
-
Sam Ravnborg authored
Fix following warnings: sun4d_irq.c:146:6: warning: symbol 'sun4d_handler_irq' was not declared. Should it be static? sun4d_irq.c:239:17: warning: symbol 'sun4d_irq' was not declared. Should it be static? sun4d_irq.c:288:14: warning: symbol '_sun4d_build_device_irq' was not declared. Should it be static? sun4d_irq.c:323:14: warning: symbol 'sun4d_build_device_irq' was not declared. Should it be static? sun4d_irq.c:386:14: warning: symbol 'sun4d_build_timer_irq' was not declared. Should it be static? sun4d_irq.c:482:13: warning: symbol 'sun4d_init_sbi_irq' was not declared. Should it be static? Apply static when applicable, otherwise add prototype Signed-off-by:
-
Sam Ravnborg authored
Fix following warnings: sun4m_irq.c:308:6: warning: symbol 'sun4m_nmi' was not declared. Should it be static? sun4m_irq.c:396:28: warning: incorrect type in assignment (different address spaces) sun4m_irq.c:396:28: expected unsigned int volatile *extern [addressable] [toplevel] master_l10_counter sun4d_irq.c:469:28: warning: incorrect type in assignment (different address spaces) sun4d_irq.c:469:28: expected unsigned int volatile *extern [addressable] [toplevel] master_l10_counter master_l10_counter is a pointer to __iomem - add annotations. Signed-off-by:
-
Sam Ravnborg authored
Fix following warning: traps_32.c:47:6: error: symbol 'die_if_kernel' redeclared with different type - different modifiers Add __noreturn to both definition and declaration Signed-off-by:
-
Sam Ravnborg authored
Fix following warnings: srmmu.c:870:13: warning: symbol 'srmmu_paging_init' was not declared. Should it be static? iommu.c:430:13: warning: symbol 'ld_mmu_iommu' was not declared. Should it be static? leon_mm.c:21:5: warning: symbol 'srmmu_swprobe_trace' was not declared. Should it be static? Add proper prototypes or define static to fix them. Signed-off-by:
-
Sam Ravnborg authored
Fix following warnings: srmmu.c:78:5: warning: symbol 'flush_page_for_dma_global' was not declared. Should it be static? srmmu.c:85:5: warning: symbol 'viking_mxcc_present' was not declared. Should it be static? srmmu.c:103:6: warning: symbol 'srmmu_nocache_bitmap' was not declared. Should it be static? srmmu.c:176:24: warning: Using plain integer as NULL pointer srmmu.c:731:46: warning: Using plain integer as NULL pointer srmmu.c:731:46: warning: Using plain integer as NULL pointer srmmu.c:731:46: warning: Using plain integer as NULL pointer srmmu.c:870:13: warning: symbol 'srmmu_paging_init' was not declared. Should it be static? Add proper prototypes in mm_32.h and drop local prototype in init_32.c Replace 0 with NULL Signed-off-by:
-
Sam Ravnborg authored
Fix following warning: init_32.c:112:22: warning: symbol 'bootmem_init' was not declared. Should it be static? Fix by adding a proper prototype in pgtable_32.h and drop the local prototype in srmmu.c Signed-off-by:
-
Sam Ravnborg authored
Fix following warning: fault_32.c:38:24: error: symbol 'unhandled_fault' redeclared with different type - different modifiers When this warning was fixed several new warnings popped up - fix them too. Signed-off-by:
-
Sam Ravnborg authored
This file will be used for more than just srmmu stuff, so the old name was misleading. Signed-off-by:
-
- 28 Apr, 2014 22 commits
-
-
Linus Torvalds authored
Merge tag 'trace-fixes-v3.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace Pull ftrace bugfix from Steven Rostedt: "Takao Indoh reported that he was able to cause a ftrace bug while loading a module and enabling function tracing at the same time. He uncovered a race where the module when loaded will convert the calls to mcount into nops, and expects the module's text to be RW. But when function tracing is enabled, it will convert all kernel text (core and module) from RO to RW to convert the nops to calls to ftrace to record the function. After the convertion, it will convert all the text back from RW to RO. The issue is, it will also convert the module's text that is loading. If it converts it to RO before ftrace does its conversion, it will cause ftrace to fail and require a reboot to fix it again. This patch moves the ftrace module update that converts calls to mcount into nops to be done when the module state is still MODULE_STATE_UNFORMED. This will ignore the module when the text is being converted from RW back to RO" * tag 'trace-fixes-v3.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: ftrace/module: Hardcode ftrace_module_init() call into load_module()
-
git://git.secretlab.ca/git/linuxLinus Torvalds authored
Pull devicetree bug fixes from Grant Likely: "These are some important bug fixes that need to get into v3.15. This branch contains a pair of important bug fixes for the DT code: - Fix some incorrect binding property names before they enter common usage - Fix bug where some platform devices will be unable to get their interrupt number when they depend on an interrupt controller that is not available at device creation time. This is a problem causing mainline to fail on a number of ARM platforms" * tag 'dt-for-linus' of git://git.secretlab.ca/git/linux: of/irq: do irq resolution in platform_get_irq of: selftest: add deferred probe interrupt test dt: Fix binding typos in clock-names and interrupt-names -
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpcLinus Torvalds authored
Pull powerpc fixes from Ben Herrenschmidt: "Here is a bunch of post-merge window fixes that have been accumulating in patchwork while I was on vacation or buried under other stuff last week. We have the now usual batch of LE fixes from Anton (sadly some new stuff that went into this merge window had endian issues, we'll try to make sure we do better next time) Some fixes and cleanups to the new 24x7 performance monitoring stuff (mostly typos and cleaning up printk's) A series of fixes for an issue with our runlatch bit, which wasn't set properly for offlined threads/cores and under KVM, causing potentially some counters to misbehave along with possible power management issues. A fix for kexec nasty race where the new kernel wouldn't "see" the secondary processors having reached back into firmware in time. And finally a few other misc (and pretty simple) bug fixes" * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: (33 commits) powerpc/4xx: Fix section mismatch in ppc4xx_pci.c ppc/kvm: Clear the runlatch bit of a vcpu before napping ppc/kvm: Set the runlatch bit of a CPU just before starting guest ppc/powernv: Set the runlatch bits correctly for offline cpus powerpc/pseries: Protect remove_memory() with device hotplug lock powerpc: Fix error return in rtas_flash module init powerpc: Bump BOOT_COMMAND_LINE_SIZE to 2048 powerpc: Bump COMMAND_LINE_SIZE to 2048 powerpc: Rename duplicate COMMAND_LINE_SIZE define powerpc/perf/hv-24x7: Catalog version number is be64, not be32 powerpc/perf/hv-24x7: Remove [static 4096], sparse chokes on it powerpc/perf/hv-24x7: Use (unsigned long) not (u32) values when calling plpar_hcall_norets() powerpc/perf/hv-gpci: Make device attr static powerpc/perf/hv_gpci: Probe failures use pr_debug(), and padding reduced powerpc/perf/hv_24x7: Probe errors changed to pr_debug(), padding fixed powerpc/mm: Fix tlbie to add AVAL fields for 64K pages powerpc/powernv: Fix little endian issues in OPAL dump code powerpc/powernv: Create OPAL sglist helper functions and fix endian issues powerpc/powernv: Fix little endian issues in OPAL error log code powerpc/powernv: Fix little endian issues with opal_do_notifier calls ...
-
Linus Torvalds authored
BUG_ON() is a big hammer, and should be used _only_ if there is some major corruption that you cannot possibly recover from, making it imperative that the current process (and possibly the whole machine) be terminated with extreme prejudice. The trivial sanity check in the vmacache code is *not* such a fatal error. Recovering from it is absolutely trivial, and using BUG_ON() just makes it harder to debug for no actual advantage. To make matters worse, the placement of the BUG_ON() (only if the range check matched) actually makes it harder to hit the sanity check to begin with, so _if_ there is a bug (and we just got a report from Srivatsa Bhat that this can indeed trigger), it is harder to debug not just because the machine is possibly dead, but because we don't have better coverage. BUG_ON() must *die*. Maybe we should add a checkpatch warning for it, because it is simply just about the worst thing you can ever do if you hit some "this cannot happen" situation. Reported-by:
Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Cc: Davidlohr Bueso <davidlohr@hp.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Steven Rostedt (Red Hat) authored
A race exists between module loading and enabling of function tracer. CPU 1 CPU 2 ----- ----- load_module() module->state = MODULE_STATE_COMING register_ftrace_function() mutex_lock(&ftrace_lock); ftrace_startup() update_ftrace_function(); ftrace_arch_code_modify_prepare() set_all_module_text_rw(); <enables-ftrace> ftrace_arch_code_modify_post_process() set_all_module_text_ro(); [ here all module text is set to RO, including the module that is loading!! ] blocking_notifier_call_chain(MODULE_STATE_COMING); ftrace_init_module() [ tries to modify code, but it's RO, and fails! ftrace_bug() is called] When this race happens, ftrace_bug() will produces a nasty warning and all of the function tracing features will be disabled until reboot. The simple solution is to treate module load the same way the core kernel is treated at boot. To hardcode the ftrace function modification of converting calls to mcount into nops. This is done in init/main.c there's no reason it could not be done in load_module(). This gives a better control of the changes and doesn't tie the state of the module to its notifiers as much. Ftrace is special, it needs to be treated as such. The reason this would work, is that the ftrace_module_init() would be called while the module is in MODULE_STATE_UNFORMED, which is ignored by the set_all_module_text_ro() call. Link: http://lkml.kernel.org/r/1395637826-3312-1-git-send-email-indou.takao@jp.fujitsu.comReported-by:Takao Indoh <indou.takao@jp.fujitsu.com> Acked-by:
Rusty Russell <rusty@rustcorp.com.au> Cc: stable@vger.kernel.org # 2.6.38+ Signed-off-by:
Steven Rostedt <rostedt@goodmis.org>
-
Alistair Popple authored
This patch fixes this section mismatch: WARNING: vmlinux.o(.text+0x1efc4): Section mismatch in reference from the function apm821xx_pciex_init_port_hw() to the function .init.text:ppc4xx_pciex_wait_on_sdr.isra.9() The function apm821xx_pciex_init_port_hw() references the function __init ppc4xx_pciex_wait_on_sdr.isra.9(). This is often because apm821xx_pciex_init_port_hw lacks a __init annotation or the annotation of ppc4xx_pciex_wait_on_sdr.isra.9 is wrong. apm821xx_pciex_init_port_hw is only referenced by a struct in __initdata, so it should be safe to add __init to apm821xx_pciex_init_port_hw. Signed-off-by:
Alistair Popple <alistair@popple.id.au> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Preeti U Murthy authored
When the guest cedes the vcpu or the vcpu has no guest to run it naps. Clear the runlatch bit of the vcpu before napping to indicate an idle cpu. Signed-off-by:
Preeti U Murthy <preeti@linux.vnet.ibm.com> Acked-by:
Paul Mackerras <paulus@samba.org> Reviewed-by:
-
Preeti U Murthy authored
The secondary threads in the core are kept offline before launching guests in kvm on powerpc: "371fefd6:KVM: PPC: Allow book3s_hv guests to use SMT processor modes." Hence their runlatch bits are cleared. When the secondary threads are called in to start a guest, their runlatch bits need to be set to indicate that they are busy. The primary thread has its runlatch bit set though, but there is no harm in setting this bit once again. Hence set the runlatch bit for all threads before they start guest. Signed-off-by:
-
Preeti U Murthy authored
Up until now we have been setting the runlatch bits for a busy CPU and clearing it when a CPU enters idle state. The runlatch bit has thus been consistent with the utilization of a CPU as long as the CPU is online. However when a CPU is hotplugged out the runlatch bit is not cleared. It needs to be cleared to indicate an unused CPU. Hence this patch has the runlatch bit cleared for an offline CPU just before entering an idle state and sets it immediately after it exits the idle state. Signed-off-by:
-
Li Zhong authored
While testing memory hot-remove, I found following dead lock: Process #1141 is drmgr, trying to remove some memory, i.e. memory499. It holds the memory_hotplug_mutex, and blocks when trying to remove file "online" under dir memory499, in kernfs_drain(), at wait_event(root->deactivate_waitq, atomic_read(&kn->active) == KN_DEACTIVATED_BIAS); Process #1120 is trying to online memory499 by echo 1 > memory499/online In .kernfs_fop_write, it uses kernfs_get_active() to increase &kn->active, thus blocking process #1141. While itself is blocked later when trying to acquire memory_hotplug_mutex, which is held by process The backtrace of both processes are shown below: [<c000000001b18600>] 0xc000000001b18600 [<c000000000015044>] .__switch_to+0x144/0x200 [<c000000000263ca4>] .online_pages+0x74/0x7b0 [<c00000000055b40c>] .memory_subsys_online+0x9c/0x150 [<c00000000053cbe8>] .device_online+0xb8/0x120 [<c00000000053cd04>] .online_store+0xb4/0xc0 [<c000000000538ce4>] .dev_attr_store+0x64/0xa0 [<c00000000030f4ec>] .sysfs_kf_write+0x7c/0xb0 [<c00000000030e574>] .kernfs_fop_write+0x154/0x1e0 [<c000000000268450>] .vfs_write+0xe0/0x260 [<c000000000269144>] .SyS_write+0x64/0x110 [<c000000000009ffc>] syscall_exit+0x0/0x7c [<c000000001b18600>] 0xc000000001b18600 [<c000000000015044>] .__switch_to+0x144/0x200 [<c00000000030be14>] .__kernfs_remove+0x204/0x300 [<c00000000030d428>] .kernfs_remove_by_name_ns+0x68/0xf0 [<c00000000030fb38>] .sysfs_remove_file_ns+0x38/0x60 [<c000000000539354>] .device_remove_attrs+0x54/0xc0 [<c000000000539fd8>] .device_del+0x158/0x250 [<c00000000053a104>] .device_unregister+0x34/0xa0 [<c00000000055bc14>] .unregister_memory_section+0x164/0x170 [<c00000000024ee18>] .__remove_pages+0x108/0x4c0 [<c00000000004b590>] .arch_remove_memory+0x60/0xc0 [<c00000000026446c>] .remove_memory+0x8c/0xe0 [<c00000000007f9f4>] .pseries_remove_memblock+0xd4/0x160 [<c00000000007fcfc>] .pseries_memory_notifier+0x27c/0x290 [<c0000000008ae6cc>] .notifier_call_chain+0x8c/0x100 [<c0000000000d858c>] .__blocking_notifier_call_chain+0x6c/0xe0 [<c00000000071ddec>] .of_property_notify+0x7c/0xc0 [<c00000000071ed3c>] .of_update_property+0x3c/0x1b0 [<c0000000000756cc>] .ofdt_write+0x3dc/0x740 [<c0000000002f60fc>] .proc_reg_write+0xac/0x110 [<c000000000268450>] .vfs_write+0xe0/0x260 [<c000000000269144>] .SyS_write+0x64/0x110 [<c000000000009ffc>] syscall_exit+0x0/0x7c This patch uses lock_device_hotplug() to protect remove_memory() called in pseries_remove_memblock(), which is also stated before function remove_memory(): * NOTE: The caller must call lock_device_hotplug() to serialize hotplug * and online/offline operations before this call, as required by * try_offline_node(). */ void __ref remove_memory(int nid, u64 start, u64 size) With this lock held, the other process(#1120 above) trying to online the memory block will retry the system call when calling lock_device_hotplug_sysfs(), and finally find No such device error. Signed-off-by:Li Zhong <zhong@linux.vnet.ibm.com> Signed-off-by:
-
Anton Blanchard authored
module_init should return 0 or a negative errno. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
-
Anton Blanchard authored
Bump the boot wrapper BOOT_COMMAND_LINE_SIZE to match the kernel. Signed-off-by:
-
Anton Blanchard authored
I've had a report that the current limit is too small for an automated network based installer. Bump it. Signed-off-by:
-
Anton Blanchard authored
We have two definitions of COMMAND_LINE_SIZE, one for the kernel and one for the boot wrapper. I assume this is so the boot wrapper can be self sufficient and not rely on kernel headers. Having two defines with the same name is confusing, I just updated the wrong one when trying to bump it. Make the boot wrapper define unique by calling it BOOT_COMMAND_LINE_SIZE. Signed-off-by:
-
Cody P Schafer authored
The catalog version number was changed from a be32 (with proceeding 32bits of padding) to a be64, update the code to treat it as a be64 Signed-off-by:
Cody P Schafer <cody@linux.vnet.ibm.com> Signed-off-by:
-
Cody P Schafer authored
Signed-off-by:
-
Cody P Schafer authored
Signed-off-by:
-
Cody P Schafer authored
Signed-off-by:
-
Cody P Schafer authored
fixup for "powerpc/perf: Add support for the hv gpci (get performance counter info) interface". Makes the "not enabled" message less awful (and hidden unless debugging). Signed-off-by:
-
Cody P Schafer authored
fixup for "powerpc/perf: Add support for the hv 24x7 interface" Makes the "not enabled" message less awful (and hides it in most cases). Signed-off-by:
-
Aneesh Kumar K.V authored
The if condition check was based on a draft ISA doc. Remove the same. Signed-off-by:
Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by:
-
Anton Blanchard authored
Signed-off-by:
-
