path: root/kernel
AgeCommit message (Collapse)AuthorFilesLines
2014-05-03Merge branch 'irq-urgent-for-linus' of ↵Linus Torvalds2-0/+12
git:// Pull irq fixes from Thomas Gleixner: "This udpate delivers: - A fix for dynamic interrupt allocation on x86 which is required to exclude the GSI interrupts from the dynamic allocatable range. This was detected with the newfangled tablet SoCs which have GPIOs and therefor allocate a range of interrupts. The MSI allocations already excluded the GSI range, so we never noticed before. - The last missing set_irq_affinity() repair, which was delayed due to testing issues - A few bug fixes for the armada SoC interrupt controller - A memory allocation fix for the TI crossbar interrupt controller - A trivial kernel-doc warning fix" * 'irq-urgent-for-linus' of git:// irqchip: irq-crossbar: Not allocating enough memory irqchip: armanda: Sanitize set_irq_affinity() genirq: x86: Ensure that dynamic irq allocation does not conflict linux/interrupt.h: fix new kernel-doc warnings irqchip: armada-370-xp: Fix releasing of MSIs irqchip: armada-370-xp: implement the ->check_device() msi_chip operation irqchip: armada-370-xp: fix invalid cast of signed value into unsigned variable
2014-05-03Merge branch 'timers-urgent-for-linus' of ↵Linus Torvalds2-1/+23
git:// Pull timer fixes from Thomas Gleixner: "This update brings along: - Two fixes for long standing bugs in the hrtimer code, one which prevents remote enqueuing and the other preventing arbitrary delays after a interrupt hang was detected - A fix in the timer wheel which prevents math overflow - A fix for a long standing issue with the architected ARM timer related to the C3STOP mechanism. - A trivial compile fix for nspire SoC clocksource" * 'timers-urgent-for-linus' of git:// timer: Prevent overflow in apply_slack hrtimer: Prevent remote enqueue of leftmost timers hrtimer: Prevent all reprogramming if hang detected clocksource: nspire: Fix compiler warning clocksource: arch_arm_timer: Fix age-old arch timer C3STOP detection issue
2014-05-03Merge tag 'trace-fixes-v3.15-rc3' of ↵Linus Torvalds1-1/+1
git:// Pull tracing fix from Steven Rostedt: "This is a small fix where the trigger code used the wrong rcu_dereference(). It required rcu_dereference_sched() instead of the normal rcu_dereference(). It produces a nasty RCU lockdep splat due to the incorrect rcu notation" Acked-by: Paul E. McKenney <> * tag 'trace-fixes-v3.15-rc3' of git:// tracing: Use rcu_dereference_sched() for trace event triggers
2014-05-02tracing: Use rcu_dereference_sched() for trace event triggersSteven Rostedt (Red Hat)1-1/+1
As trace event triggers are now part of the mainline kernel, I added my trace event trigger tests to my test suite I run on all my kernels. Now these tests get run under different config options, and one of those options is CONFIG_PROVE_RCU, which checks under lockdep that the rcu locking primitives are being used correctly. This triggered the following splat: =============================== [ INFO: suspicious RCU usage. ] 3.15.0-rc2-test+ #11 Not tainted ------------------------------- kernel/trace/trace_events_trigger.c:80 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 4 locks held by swapper/1/0: #0: ((&(&j_cdbs->work)->timer)){..-...}, at: [<ffffffff8104d2cc>] call_timer_fn+0x5/0x1be #1: (&(&pool->lock)->rlock){-.-...}, at: [<ffffffff81059856>] __queue_work+0x140/0x283 #2: (&p->pi_lock){-.-.-.}, at: [<ffffffff8106e961>] try_to_wake_up+0x2e/0x1e8 #3: (&rq->lock){-.-.-.}, at: [<ffffffff8106ead3>] try_to_wake_up+0x1a0/0x1e8 stack backtrace: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.15.0-rc2-test+ #11 Hardware name: /DG965MQ, BIOS MQ96510J.86A.0372.2006.0605.1717 06/05/2006 0000000000000001 ffff88007e083b98 ffffffff819f53a5 0000000000000006 ffff88007b0942c0 ffff88007e083bc8 ffffffff81081307 ffff88007ad96d20 0000000000000000 ffff88007af2d840 ffff88007b2e701c ffff88007e083c18 Call Trace: <IRQ> [<ffffffff819f53a5>] dump_stack+0x4f/0x7c [<ffffffff81081307>] lockdep_rcu_suspicious+0x107/0x110 [<ffffffff810ee51c>] event_triggers_call+0x99/0x108 [<ffffffff810e8174>] ftrace_event_buffer_commit+0x42/0xa4 [<ffffffff8106aadc>] ftrace_raw_event_sched_wakeup_template+0x71/0x7c [<ffffffff8106bcbf>] ttwu_do_wakeup+0x7f/0xff [<ffffffff8106bd9b>] ttwu_do_activate.constprop.126+0x5c/0x61 [<ffffffff8106eadf>] try_to_wake_up+0x1ac/0x1e8 [<ffffffff8106eb77>] wake_up_process+0x36/0x3b [<ffffffff810575cc>] wake_up_worker+0x24/0x26 [<ffffffff810578bc>] insert_work+0x5c/0x65 [<ffffffff81059982>] __queue_work+0x26c/0x283 [<ffffffff81059999>] ? __queue_work+0x283/0x283 [<ffffffff810599b7>] delayed_work_timer_fn+0x1e/0x20 [<ffffffff8104d3a6>] call_timer_fn+0xdf/0x1be^M [<ffffffff8104d2cc>] ? call_timer_fn+0x5/0x1be [<ffffffff81059999>] ? __queue_work+0x283/0x283 [<ffffffff8104d823>] run_timer_softirq+0x1a4/0x22f^M [<ffffffff8104696d>] __do_softirq+0x17b/0x31b^M [<ffffffff81046d03>] irq_exit+0x42/0x97 [<ffffffff81a08db6>] smp_apic_timer_interrupt+0x37/0x44 [<ffffffff81a07a2f>] apic_timer_interrupt+0x6f/0x80 <EOI> [<ffffffff8100a5d8>] ? default_idle+0x21/0x32 [<ffffffff8100a5d6>] ? default_idle+0x1f/0x32 [<ffffffff8100ac10>] arch_cpu_idle+0xf/0x11 [<ffffffff8107b3a4>] cpu_startup_entry+0x1a3/0x213 [<ffffffff8102a23c>] start_secondary+0x212/0x219 The cause is that the triggers are protected by rcu_read_lock_sched() but the data is dereferenced with rcu_dereference() which expects it to be protected with rcu_read_lock(). The proper reference should be rcu_dereference_sched(). Cc: Tom Zanussi <> Cc: # 3.14+ Signed-off-by: Steven Rostedt <>
2014-05-01Merge tag 'fixes-for-linus' of ↵Linus Torvalds1-3/+0
git:// Pull module fixes from Rusty Russell: "Fixed one missing place for the new taint flag, and remove a warning giving only false positives (now we finally figured out why)" * tag 'fixes-for-linus' of git:// module: remove warning about waiting module removal. Fix: tracing: use 'E' instead of 'X' for unsigned module taint flag
2014-04-30timer: Prevent overflow in apply_slackJiri Bohac1-1/+1
On architectures with sizeof(int) < sizeof (long), the computation of mask inside apply_slack() can be undefined if the computed bit is > 32. E.g. with: expires = 0xffffe6f5 and slack = 25, we get: expires_limit = 0x20000000e bit = 33 mask = (1 << 33) - 1 /* undefined */ On x86, mask becomes 1 and and the slack is not applied properly. On s390, mask is -1, expires is set to 0 and the timer fires immediately. Use 1UL << bit to solve that issue. Suggested-by: Deborah Townsend <> Signed-off-by: Jiri Bohac <> Cc: Link: Signed-off-by: Thomas Gleixner <>
2014-04-30hrtimer: Prevent remote enqueue of leftmost timersLeon Ma1-0/+5
If a cpu is idle and starts an hrtimer which is not pinned on that same cpu, the nohz code might target the timer to a different cpu. In the case that we switch the cpu base of the timer we already have a sanity check in place, which determines whether the timer is earlier than the current leftmost timer on the target cpu. In that case we enqueue the timer on the current cpu because we cannot reprogram the clock event device on the target. If the timers base is already the target CPU we do not have this sanity check in place so we enqueue the timer as the leftmost timer in the target cpus rb tree, but we cannot reprogram the clock event device on the target cpu. So the timer expires late and subsequently prevents the reprogramming of the target cpu clock event device until the previously programmed event fires or a timer with an earlier expiry time gets enqueued on the target cpu itself. Add the same target check as we have for the switch base case and start the timer on the current cpu if it would become the leftmost timer on the target. [ tglx: Rewrote subject and changelog ] Signed-off-by: Leon Ma <> Link: Cc: Signed-off-by: Thomas Gleixner <>
2014-04-30hrtimer: Prevent all reprogramming if hang detectedStuart Hayes1-0/+17
If the last hrtimer interrupt detected a hang it sets hang_detected=1 and programs the clock event device with a delay to let the system make progress. If hang_detected == 1, we prevent reprogramming of the clock event device in hrtimer_reprogram() but not in hrtimer_force_reprogram(). This can lead to the following situation: hrtimer_interrupt() hang_detected = 1; program ce device to Xms from now (hang delay) We have two timers pending: T1 expires 50ms from now T2 expires 5s from now Now T1 gets canceled, which causes hrtimer_force_reprogram() to be invoked, which in turn programs the clock event device to T2 (5 seconds from now). Any hrtimer_start after that will not reprogram the hardware due to hang_detected still being set. So we effectivly block all timers until the T2 event fires and cleans up the hang situation. Add a check for hang_detected to hrtimer_force_reprogram() which prevents the reprogramming of the hang delay in the hardware timer. The subsequent hrtimer_interrupt will resolve all outstanding issues. [ tglx: Rewrote subject and changelog and fixed up the comment in hrtimer_force_reprogram() ] Signed-off-by: Stuart Hayes <> Link: Cc: Signed-off-by: Thomas Gleixner <>
2014-04-28Merge tag 'trace-fixes-v3.15-rc2' of ↵Linus Torvalds2-23/+7
git:// 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:// ftrace/module: Hardcode ftrace_module_init() call into load_module()
2014-04-28ftrace/module: Hardcode ftrace_module_init() call into load_module()Steven Rostedt (Red Hat)2-23/+7
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: Reported-by: Takao Indoh <> Acked-by: Rusty Russell <> Cc: # 2.6.38+ Signed-off-by: Steven Rostedt <>
2014-04-28genirq: x86: Ensure that dynamic irq allocation does not conflictThomas Gleixner2-0/+12
On x86 the allocation of irq descriptors may allocate interrupts which are in the range of the GSI interrupts. That's wrong as those interrupts are hardwired and we don't have the irq domain translation like PPC. So one of these interrupts can be hooked up later to one of the devices which are hard wired to it and the io_apic init code for that particular interrupt line happily reuses that descriptor with a completely different configuration so hell breaks lose. Inside x86 we allocate dynamic interrupts from above nr_gsi_irqs, except for a few usage sites which have not yet blown up in our face for whatever reason. But for drivers which need an irq range, like the GPIO drivers, we have no limit in place and we don't want to expose such a detail to a driver. To cure this introduce a function which an architecture can implement to impose a lower bound on the dynamic interrupt allocations. Implement it for x86 and set the lower bound to nr_gsi_irqs, which is the end of the hardwired interrupt space, so all dynamic allocations happen above. That not only allows the GPIO driver to work sanely, it also protects the bogus callsites of create_irq_nr() in hpet, uv, irq_remapping and htirq code. They need to be cleaned up as well, but that's a separate issue. Reported-by: Jin Yao <> Signed-off-by: Thomas Gleixner <> Tested-by: Mika Westerberg <> Cc: Mathias Nyman <> Cc: Linus Torvalds <> Cc: Grant Likely <> Cc: H. Peter Anvin <> Cc: Rafael J. Wysocki <> Cc: Andy Shevchenko <> Cc: Krogerus Heikki <> Cc: Linus Walleij <> Link: Signed-off-by: Thomas Gleixner <>
2014-04-28module: remove warning about waiting module removal.Rusty Russell1-3/+0
We remove the waiting module removal in commit 3f2b9c9cdf38 (September 2013), but it turns out that modprobe in kmod (< version 16) was asking for waiting module removal. No one noticed since modprobe would check for 0 usage immediately before trying to remove the module, and the race is unlikely. However, it means that anyone running old (but not ancient) kmod versions is hitting the printk designed to see if anyone was running "rmmod -w". All reports so far have been false positives, so remove the warning. Fixes: 3f2b9c9cdf389e303b2273679af08aab5f153517 Reported-by: Valerio Vanni <> Cc: Elliott, Robert (Server Storage) <> Cc: Acked-by: Lucas De Marchi <> Signed-off-by: Rusty Russell <>
2014-04-27Merge branch 'irq-urgent-for-linus' of ↵Linus Torvalds1-11/+6
git:// Pull irq fixes from Thomas Gleixner: "A slighlty large fix for a subtle issue in the CPU hotplug code of certain ARM SoCs, where the not yet online cpu needs to setup the cpu local timer and needs to set the interrupt affinity to itself. Setting interrupt affinity to a not online cpu is prohibited and therefor the timer interrupt ends up on the wrong cpu, which leads to nasty complications. The SoC folks tried to hack around that in the SoC code in some more than nasty ways. The proper solution is to have a way to enforce the affinity setting to a not online cpu. The core patch to the genirq code provides that facility and the follow up patches make use of it in the GIC interrupt controller and the exynos timer driver. The change to the core code has no implications to existing users, except for the rename of the locked function and therefor the necessary fixup in mips/cavium. Aside of that, no runtime impact is possible, as none of the existing interrupt chips implements anything which depends on the force argument of the irq_set_affinity() callback" * 'irq-urgent-for-linus' of git:// clocksource: Exynos_mct: Register clock event after request_irq() clocksource: Exynos_mct: Use irq_force_affinity() in cpu bringup irqchip: Gic: Support forced affinity setting genirq: Allow forcing cpu affinity of interrupts
2014-04-21PM / suspend: Make cpuidle work in the "freeze" stateRafael J. Wysocki1-0/+3
The "freeze" system sleep state introduced by commit 7e73c5ae6e79 (PM: Introduce suspend state PM_SUSPEND_FREEZE) requires cpuidle to be functional when freeze_enter() is executed to work correctly (that is, to be able to save any more energy than runtime idle), but that is impossible after commit 8651f97bd951d (PM / cpuidle: System resume hang fix with cpuidle) which caused cpuidle to be paused in dpm_suspend_noirq() and resumed in dpm_resume_noirq(). To avoid that problem, add cpuidle_resume() and cpuidle_pause() to the beginning and the end of freeze_enter(), respectively. Reported-by: Zhang Rui <> Signed-off-by: Rafael J. Wysocki <> Reviewed-by: Preeti U Murthy <>
2014-04-19Merge branch 'sched-urgent-for-linus' of ↵Linus Torvalds4-11/+32
git:// Pull scheduler fixes from Ingo Molnar: "Two fixes: - a SCHED_DEADLINE task selection fix - a sched/numa related lockdep splat fix" * 'sched-urgent-for-linus' of git:// sched: Check for stop task appearance when balancing happens sched/numa: Fix task_numa_free() lockdep splat
2014-04-18Merge git:// Torvalds1-0/+2
Pull more networking fixes from David Miller: 1) Fix mlx4_en_netpoll implementation, it needs to schedule a NAPI context, not synchronize it. From Chris Mason. 2) Ipv4 flow input interface should never be zero, it should be LOOPBACK_IFINDEX instead. From Cong Wang and Julian Anastasov. 3) Properly configure MAC to PHY connection in mvneta devices, from Thomas Petazzoni. 4) sys_recv should use SYSCALL_DEFINE. From Jan Glauber. 5) Tunnel driver ioctls do not use the correct namespace, fix from Nicolas Dichtel. 6) Fix memory leak on seccomp filter attach, from Kees Cook. 7) Fix lockdep warning for nested vlans, from Ding Tianhong. 8) Crashes can happen in SCTP due to how the auth_enable value is managed, fix from Vlad Yasevich. 9) Wireless fixes from John W Linville and co. * git:// (45 commits) net: sctp: cache auth_enable per endpoint tg3: update rx_jumbo_pending ring param only when jumbo frames are enabled vlan: Fix lockdep warning when vlan dev handle notification seccomp: fix memory leak on filter attach isdn: icn: buffer overflow in icn_command() ip6_tunnel: use the right netns in ioctl handler sit: use the right netns in ioctl handler ip_tunnel: use the right netns in ioctl handler net: use SYSCALL_DEFINEx for sys_recv net: mdio-gpio: Add support for separate MDI and MDO gpio pins net: mdio-gpio: Add support for active low gpio pins net: mdio-gpio: Use devm_ functions where possible ipv4, route: pass 0 instead of LOOPBACK_IFINDEX to fib_validate_source() ipv4, fib: pass LOOPBACK_IFINDEX instead of 0 to flowi4_iif mlx4_en: don't use napi_synchronize inside mlx4_en_netpoll net: mvneta: properly configure the MAC <-> PHY connection in all situations net: phy: add minimal support for QSGMII PHY sfc:On MCDI timeout, issue an FLR (and mark MCDI to fail-fast) mwifiex: fix hung task on command timeout mwifiex: process event before command response ...
2014-04-18kernel/watchdog.c:touch_softlockup_watchdog(): use raw_cpu_write()Andrew Morton1-1/+5
Fix: BUG: using __this_cpu_write() in preemptible [00000000] code: systemd-udevd/497 caller is __this_cpu_preempt_check+0x13/0x20 CPU: 3 PID: 497 Comm: systemd-udevd Tainted: G W 3.15.0-rc1 #9 Hardware name: Hewlett-Packard HP EliteBook 8470p/179B, BIOS 68ICF Ver. F.02 04/27/2012 Call Trace: check_preemption_disabled+0xe1/0xf0 __this_cpu_preempt_check+0x13/0x20 touch_nmi_watchdog+0x28/0x40 Reported-by: Luis Henriques <> Tested-by: Luis Henriques <> Cc: Eric Piel <> Cc: Robert Moore <> Cc: Lv Zheng <> Cc: "Rafael J. Wysocki" <> Cc: Len Brown <> Cc: Christoph Lameter <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <>
2014-04-18Merge tag 'trace-fixes-v3.15-rc1' of ↵Linus Torvalds2-6/+16
git:// Pull tracing fixes from Steven Rostedt: "This contains two fixes. The first is to remove a duplication of creating debugfs files that already exist and causes an error report to be printed due to the failure of the second creation. The second is a memory leak fix that was introduced in 3.14" * tag 'trace-fixes-v3.15-rc1' of git:// tracing/uprobes: Fix uprobe_cpu_buffer memory leak tracing: Do not try to recreated toplevel set_ftrace_* files
2014-04-17Merge branch 'timers-urgent-for-linus' of ↵Linus Torvalds2-2/+5
git:// Pull timer fixes from Thomas Gleixner: "Viresh unearthed the following three hickups in the timer/timekeeping code: - Negated check for the result of a clock event selection - A missing early exit in the jiffies update path which causes update_wall_time to be called for nothing causing lock contention and wasted cycles in the timer interrupt - Checking a variable in the NOHZ code enable code for true which can only be set by that very code after the check succeeds. That results in a rock solid runtime disablement of that feature" * 'timers-urgent-for-linus' of git:// tick-sched: Check tick_nohz_enabled in tick_nohz_switch_to_nohz() tick-sched: Don't call update_wall_time() when delta is lesser than tick_period tick-common: Fix wrong check in tick_check_replacement()
2014-04-17genirq: Allow forcing cpu affinity of interruptsThomas Gleixner1-11/+6
The current implementation of irq_set_affinity() refuses rightfully to route an interrupt to an offline cpu. But there is a special case, where this is actually desired. Some of the ARM SoCs have per cpu timers which require setting the affinity during cpu startup where the cpu is not yet in the online mask. If we can't do that, then the local timer interrupt for the about to become online cpu is routed to some random online cpu. The developers of the affected machines tried to work around that issue, but that results in a massive mess in that timer code. We have a yet unused argument in the set_affinity callbacks of the irq chips, which I added back then for a similar reason. It was never required so it got not used. But I'm happy that I never removed it. That allows us to implement a sane handling of the above scenario. So the affected SoC drivers can add the required force handling to their interrupt chip, switch the timer code to irq_force_affinity() and things just work. This does not affect any existing user of irq_set_affinity(). Tagged for stable to allow a simple fix of the affected SoC clock event drivers. Reported-and-tested-by: Krzysztof Kozlowski <> Signed-off-by: Thomas Gleixner <> Cc: Kyungmin Park <> Cc: Marek Szyprowski <> Cc: Bartlomiej Zolnierkiewicz <> Cc: Tomasz Figa <>, Cc: Daniel Lezcano <>, Cc: Kukjin Kim <> Cc:, Cc: Link: Signed-off-by: Thomas Gleixner <>
2014-04-17tracing/uprobes: Fix uprobe_cpu_buffer memory leakzhangwei(Jovi)1-0/+6
Forgot to free uprobe_cpu_buffer percpu page in uprobe_buffer_disable(). Link: Cc: # v3.14+ Acked-by: Namhyung Kim <> Signed-off-by: zhangwei(Jovi) <> Signed-off-by: Steven Rostedt <>
2014-04-17sched: Check for stop task appearance when balancing happensKirill Tkhai3-5/+16
We need to do it like we do for the other higher priority classes.. Signed-off-by: Kirill Tkhai <> Cc: Michael wang <> Cc: Sasha Levin <> Signed-off-by: Peter Zijlstra <> Link: Signed-off-by: Ingo Molnar <>
2014-04-16Merge branch 'core-urgent-for-linus' of ↵Linus Torvalds1-10/+9
git:// Pull locking fixes from Ingo Molnar: "liblockdep fixes and mutex debugging fixes" * 'core-urgent-for-linus' of git:// locking/mutex: Fix debug_mutexes tools/liblockdep: Add proper versioning to the shared obj tools/liblockdep: Ignore asmlinkage and visible
2014-04-16tracing: Do not try to recreated toplevel set_ftrace_* filesSteven Rostedt (Red Hat)1-6/+10
With the restructing of the function tracer working with instances, the "top level" buffer is a bit special, as the function tracing is mapped to the same set of filters. This is done by using a "global_ops" descriptor and having the "set_ftrace_filter" and "set_ftrace_notrace" map to it. When an instance is created, it creates the same files but its for the local instance and not the global_ops. The issues is that the local instance creation shares some code with the global instance one and we end up trying to create th top level "set_ftrace_*" files twice, and on boot up, we get an error like this: Could not create debugfs 'set_ftrace_filter' entry Could not create debugfs 'set_ftrace_notrace' entry The reason they failed to be created was because they were created twice, and the second time gives this error as you can not create the same file twice. Reported-by: Borislav Petkov <> Signed-off-by: Steven Rostedt <>
2014-04-16seccomp: fix memory leak on filter attachKees Cook1-0/+2
This sets the correct error code when final filter memory is unavailable, and frees the raw filter no matter what. unreferenced object 0xffff8800d6ea4000 (size 512): comm "sshd", pid 278, jiffies 4294898315 (age 46.653s) hex dump (first 32 bytes): 21 00 00 00 04 00 00 00 15 00 01 00 3e 00 00 c0 !...........>... 06 00 00 00 00 00 00 00 21 00 00 00 00 00 00 00 ........!....... backtrace: [<ffffffff8151414e>] kmemleak_alloc+0x4e/0xb0 [<ffffffff811a3a40>] __kmalloc+0x280/0x320 [<ffffffff8110842e>] prctl_set_seccomp+0x11e/0x3b0 [<ffffffff8107bb6b>] SyS_prctl+0x3bb/0x4a0 [<ffffffff8152ef2d>] system_call_fastpath+0x1a/0x1f [<ffffffffffffffff>] 0xffffffffffffffff Reported-by: Masami Ichikawa <> Signed-off-by: Kees Cook <> Tested-by: Masami Ichikawa <> Acked-by: Daniel Borkmann <> Signed-off-by: David S. Miller <>
2014-04-15Merge git:// Torvalds1-9/+8
Pull networking fixes from David Miller: 1) Fix BPF filter validation of netlink attribute accesses, from Mathias Kruase. 2) Netfilter conntrack generation seqcount not initialized properly, from Andrey Vagin. 3) Fix comparison mask computation on big-endian in nft_cmp_fast(), from Patrick McHardy. 4) Properly limit MTU over ipv6, from Eric Dumazet. 5) Fix seccomp system call argument population on 32-bit, from Daniel Borkmann. 6) skb_network_protocol() should not use hard-coded ETH_HLEN, instead skb->mac_len needs to be used. From Vlad Yasevich. 7) We have several cases of using socket based communications to implement a tunnel. For example, some tunnels are encapsulations over UDP so we use an internal kernel UDP socket to do the transmits. These tunnels should behave just like other software devices and pass the packets on down to the next layer. Most importantly we want the top-level socket (eg TCP) that created the traffic to be charged for the SKB memory. However, once you get into the IP output path, we have code that assumed that whatever was attached to skb->sk is an IP socket. To keep the top-level socket being charged for the SKB memory, whilst satisfying the needs of the IP output path, we now pass in an explicit 'sk' argument. From Eric Dumazet. 8) ping_init_sock() leaks group info, from Xiaoming Wang. * git:// (33 commits) cxgb4: use the correct max size for firmware flash qlcnic: Fix MSI-X initialization code ip6_gre: don't allow to remove the fb_tunnel_dev ipv4: add a sock pointer to dst->output() path. ipv4: add a sock pointer to ip_queue_xmit() driver/net: cosa driver uses udelay incorrectly at86rf230: fix __at86rf230_read_subreg function at86rf230: remove check if AVDD settled net: cadence: Add architecture dependencies net: Start with correct mac_len in skb_network_protocol Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer" cxgb4: Save the correct mac addr for hw-loopback connections in the L2T net: filter: seccomp: fix wrong decoding of BPF_S_ANC_SECCOMP_LD_W seccomp: fix populating a0-a5 syscall args in 32-bit x86 BPF qlcnic: Do not disable SR-IOV when VFs are assigned to VMs qlcnic: Fix QLogic application/driver interface for virtual NIC configuration qlcnic: Fix PVID configuration on eSwitch port. qlcnic: Fix max ring count calculation qlcnic: Fix to send INIT_NIC_FUNC as first mailbox. qlcnic: Fix panic due to uninitialzed delayed_work struct in use. ...
2014-04-15tick-sched: Check tick_nohz_enabled in tick_nohz_switch_to_nohz()Viresh Kumar1-1/+1
Since commit d689fe222 (NOHZ: Check for nohz active instead of nohz enabled) the tick_nohz_switch_to_nohz() function returns because it checks for the tick_nohz_active flag. This can't be set, because the function itself sets it. Undo the change in tick_nohz_switch_to_nohz(). Signed-off-by: Viresh Kumar <> Cc: Cc: Cc: Cc: Cc: <> # 3.13+ Link: Signed-off-by: Thomas Gleixner <>
2014-04-15tick-sched: Don't call update_wall_time() when delta is lesser than tick_periodViresh Kumar1-0/+3
In tick_do_update_jiffies64() we are processing ticks only if delta is greater than tick_period. This is what we are supposed to do here and it broke a bit with this patch: commit 47a1b796 (tick/timekeeping: Call update_wall_time outside the jiffies lock) With above patch, we might end up calling update_wall_time() even if delta is found to be smaller that tick_period. Fix this by returning when the delta is less than tick period. [ tglx: Made it a 3 liner and massaged changelog ] Signed-off-by: Viresh Kumar <> Cc: Cc: Cc: Cc: Cc: John Stultz <> Cc: <> # v3.14+ Link: Signed-off-by: Thomas Gleixner <>
2014-04-15tick-common: Fix wrong check in tick_check_replacement()Viresh Kumar1-1/+1
tick_check_replacement() returns if a replacement of clock_event_device is possible or not. It does this as the first check: if (tick_check_percpu(curdev, newdev, smp_processor_id())) return false; Thats wrong. tick_check_percpu() returns true when the device is useable. Check for false instead. [ tglx: Massaged changelog ] Signed-off-by: Viresh Kumar <> Cc: <> # v3.11+ Cc: Cc: Cc: Cc: Link: Signed-off-by: Thomas Gleixner <>
2014-04-14user namespace: fix incorrect memory barriersMikulas Patocka1-6/+5
smp_read_barrier_depends() can be used if there is data dependency between the readers - i.e. if the read operation after the barrier uses address that was obtained from the read operation before the barrier. In this file, there is only control dependency, no data dependecy, so the use of smp_read_barrier_depends() is incorrect. The code could fail in the following way: * the cpu predicts that idx < entries is true and starts executing the body of the for loop * the cpu fetches map->extent[0].first and map->extent[0].count * the cpu fetches map->nr_extents * the cpu verifies that idx < extents is true, so it commits the instructions in the body of the for loop The problem is that in this scenario, the cpu read map->extent[0].first and map->nr_extents in the wrong order. We need a full read memory barrier to prevent it. Signed-off-by: Mikulas Patocka <> Cc: Signed-off-by: Linus Torvalds <>
2014-04-14seccomp: fix populating a0-a5 syscall args in 32-bit x86 BPFDaniel Borkmann1-9/+8
Linus reports that on 32-bit x86 Chromium throws the following seccomp resp. audit log messages: audit: type=1326 audit(1397359304.356:28108): auid=500 uid=500 gid=500 ses=2 subj=unconfined_u:unconfined_r:chrome_sandbox_t:s0-s0:c0.c1023 pid=3677 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 syscall=172 compat=0 ip=0xb2dd9852 code=0x30000 audit: type=1326 audit(1397359304.356:28109): auid=500 uid=500 gid=500 ses=2 subj=unconfined_u:unconfined_r:chrome_sandbox_t:s0-s0:c0.c1023 pid=3677 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 syscall=5 compat=0 ip=0xb2dd9852 code=0x50000 These audit messages are being triggered via audit_seccomp() through __secure_computing() in seccomp mode (BPF) filter with seccomp return codes 0x30000 (== SECCOMP_RET_TRAP) and 0x50000 (== SECCOMP_RET_ERRNO) during filter runtime. Moreover, Linus reports that x86_64 Chromium seems fine. The underlying issue that explains this is that the implementation of populate_seccomp_data() is wrong. Our seccomp data structure sd that is being shared with user ABI is: struct seccomp_data { int nr; __u32 arch; __u64 instruction_pointer; __u64 args[6]; }; Therefore, a simple cast to 'unsigned long *' for storing the value of the syscall argument via syscall_get_arguments() is just wrong as on 32-bit x86 (or any other 32bit arch), it would result in storing a0-a5 at wrong offsets in args[] member, and thus i) could leak stack memory to user space and ii) tampers with the logic of seccomp BPF programs that read out and check for syscall arguments: syscall_get_arguments(task, regs, 0, 1, (unsigned long *) &sd->args[0]); Tested on 32-bit x86 with Google Chrome, unfortunately only via remote test machine through slow ssh X forwarding, but it fixes the issue on my side. So fix it up by storing args in type correct variables, gcc is clever and optimizes the copy away in other cases, e.g. x86_64. Fixes: bd4cf0ed331a ("net: filter: rework/optimize internal BPF interpreter's instruction set") Reported-and-bisected-by: Linus Torvalds <> Signed-off-by: Daniel Borkmann <> Signed-off-by: Alexei Starovoitov <> Cc: Linus Torvalds <> Cc: Eric Paris <> Cc: James Morris <> Cc: Kees Cook <> Signed-off-by: David S. Miller <>
2014-04-12futex: update documentation for ordering guaranteesDavidlohr Bueso1-9/+23
Commits 11d4616bd07f ("futex: revert back to the explicit waiter counting code") and 69cd9eba3886 ("futex: avoid race between requeue and wake") changed some of the finer details of how we think about futexes. One was a late fix and the other a consequence of overlooking the whole requeuing logic. The first change caused our documentation to be incorrect, and the second made us aware that we need to explicitly add more details to it. Signed-off-by: Davidlohr Bueso <> Signed-off-by: Linus Torvalds <>
2014-04-12Merge branch 'for-linus' of ↵Linus Torvalds2-9/+3
git:// Pull vfs updates from Al Viro: "The first vfs pile, with deep apologies for being very late in this window. Assorted cleanups and fixes, plus a large preparatory part of iov_iter work. There's a lot more of that, but it'll probably go into the next merge window - it *does* shape up nicely, removes a lot of boilerplate, gets rid of locking inconsistencie between aio_write and splice_write and I hope to get Kent's direct-io rewrite merged into the same queue, but some of the stuff after this point is having (mostly trivial) conflicts with the things already merged into mainline and with some I want more testing. This one passes LTP and xfstests without regressions, in addition to usual beating. BTW, readahead02 in ltp syscalls testsuite has started giving failures since "mm/readahead.c: fix readahead failure for memoryless NUMA nodes and limit readahead pages" - might be a false positive, might be a real regression..." * 'for-linus' of git:// (63 commits) missing bits of "splice: fix racy pipe->buffers uses" cifs: fix the race in cifs_writev() ceph_sync_{,direct_}write: fix an oops on ceph_osdc_new_request() failure kill generic_file_buffered_write() ocfs2_file_aio_write(): switch to generic_perform_write() ceph_aio_write(): switch to generic_perform_write() xfs_file_buffered_aio_write(): switch to generic_perform_write() export generic_perform_write(), start getting rid of generic_file_buffer_write() generic_file_direct_write(): get rid of ppos argument btrfs_file_aio_write(): get rid of ppos kill the 5th argument of generic_file_buffered_write() kill the 4th argument of __generic_file_aio_write() lustre: don't open-code kernel_recvmsg() ocfs2: don't open-code kernel_recvmsg() drbd: don't open-code kernel_recvmsg() constify blk_rq_map_user_iov() and friends lustre: switch to kernel_sendmsg() ocfs2: don't open-code kernel_sendmsg() take iov_iter stuff to mm/iov_iter.c process_vm_access: tidy up a bit ...
2014-04-12Merge tag 'trace-3.15-v2' of ↵Linus Torvalds8-335/+289
git:// Pull more tracing updates from Steven Rostedt: "This includes the final patch to clean up and fix the issue with the design of tracepoints and how a user could register a tracepoint and have that tracepoint not be activated but no error was shown. The design was for an out of tree module but broke in tree users. The clean up was to remove the saving of the hash table of tracepoint names such that they can be enabled before they exist (enabling a module tracepoint before that module is loaded). This added more complexity than needed. The clean up was to remove that code and just enable tracepoints that exist or fail if they do not. This removed a lot of code as well as the complexity that it brought. As a side effect, instead of registering a tracepoint by its name, the tracepoint needs to be registered with the tracepoint descriptor. This removes having to duplicate the tracepoint names that are enabled. The second patch was added that simplified the way modules were searched for. This cleanup required changes that were in the 3.15 queue as well as some changes that were added late in the 3.14-rc cycle. This final change waited till the two were merged in upstream and then the change was added and full tests were run. Unfortunately, the test found some errors, but after it was already submitted to the for-next branch and not to be rebased. Sparse errors were detected by Fengguang Wu's bot tests, and my internal tests discovered that the anonymous union initialization triggered a bug in older gcc compilers. Luckily, there was a bugzilla for the gcc bug which gave a work around to the problem. The third and fourth patch handled the sparse error and the gcc bug respectively. A final patch was tagged along to fix a missing documentation for the README file" * tag 'trace-3.15-v2' of git:// tracing: Add missing function triggers dump and cpudump to README tracing: Fix anonymous unions in struct ftrace_event_call tracepoint: Fix sparse warnings in tracepoint.c tracepoint: Simplify tracepoint module search tracepoint: Use struct pointer instead of name hash for reg/unreg tracepoints
2014-04-12Merge git:// Torvalds5-54/+149
Pull audit updates from Eric Paris. * git:// (28 commits) AUDIT: make audit_is_compat depend on CONFIG_AUDIT_COMPAT_GENERIC audit: renumber AUDIT_FEATURE_CHANGE into the 1300 range audit: do not cast audit_rule_data pointers pointlesly AUDIT: Allow login in non-init namespaces audit: define audit_is_compat in kernel internal header kernel: Use RCU_INIT_POINTER(x, NULL) in audit.c sched: declare pid_alive as inline audit: use uapi/linux/audit.h for AUDIT_ARCH declarations syscall_get_arch: remove useless function arguments audit: remove stray newline from audit_log_execve_info() audit_panic() call audit: remove stray newlines from audit_log_lost messages audit: include subject in login records audit: remove superfluous new- prefix in AUDIT_LOGIN messages audit: allow user processes to log from another PID namespace audit: anchor all pid references in the initial pid namespace audit: convert PPIDs to the inital PID namespace. pid: get pid_t ppid of task in init_pid_ns audit: rename the misleading audit_get_context() to audit_take_context() audit: Add generic compat syscall support audit: Add CONFIG_HAVE_ARCH_AUDITSYSCALL ...
2014-04-12missing bits of "splice: fix racy pipe->buffers uses"Al Viro2-3/+3
that commit has fixed only the parts of that mess in fs/splice.c itself; there had been more in several other ->splice_read() instances... Signed-off-by: Al Viro <>
2014-04-11locking/mutex: Fix debug_mutexesPeter Zijlstra1-10/+9
debug_mutex_unlock() would bail when !debug_locks and forgets to actually unlock. Reported-by: "Michael L. Semon" <> Reported-by: "Kirill A. Shutemov" <> Reported-by: Valdis Kletnieks <> Fixes: 6f008e72cd11 ("locking/mutex: Fix debug checks") Tested-by: Dave Jones <> Cc: Jason Low <> Signed-off-by: Peter Zijlstra <> Link: Signed-off-by: Ingo Molnar <>
2014-04-11sched/numa: Fix task_numa_free() lockdep splatMike Galbraith2-6/+16
Sasha reported that lockdep claims that the following commit: made numa_group.lock interrupt unsafe: 156654f491dd ("sched/numa: Move task_numa_free() to __put_task_struct()") While I don't see how that could be, given the commit in question moved task_numa_free() from one irq enabled region to another, the below does make both gripes and lockups upon gripe with numa=fake=4 go away. Reported-by: Sasha Levin <> Fixes: 156654f491dd ("sched/numa: Move task_numa_free() to __put_task_struct()") Signed-off-by: Mike Galbraith <> Signed-off-by: Peter Zijlstra <> Cc: Cc: Cc: Cc: Dave Jones <> Link: Signed-off-by: Ingo Molnar <>
2014-04-10tracing: Add missing function triggers dump and cpudump to READMESteven Rostedt (Red Hat)1-0/+2
The debugfs tracing README file lists all the function triggers except for dump and cpudump. These should be added too. Signed-off-by: Steven Rostedt <>
2014-04-09tracing: Fix anonymous unions in struct ftrace_event_callMathieu Desnoyers1-2/+4
gcc <= 4.5.x has significant limitations with respect to initialization of anonymous unions within structures. They need to be surrounded by brackets, _and_ they need to be initialized in the same order in which they appear in the structure declaration. Link: Link: Signed-off-by: Mathieu Desnoyers <> Signed-off-by: Steven Rostedt <>
2014-04-09futex: avoid race between requeue and wakeLinus Torvalds1-0/+5
Jan Stancek reported: "pthread_cond_broadcast/4-1.c testcase from openposix testsuite (LTP) occasionally fails, because some threads fail to wake up. Testcase creates 5 threads, which are all waiting on same condition. Main thread then calls pthread_cond_broadcast() without holding mutex, which calls: futex(uaddr1, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, uaddr2, ..) This immediately wakes up single thread A, which unlocks mutex and tries to wake up another thread: futex(uaddr2, FUTEX_WAKE_PRIVATE, 1) If thread A manages to call futex_wake() before any waiters are requeued for uaddr2, no other thread is woken up" The ordering constraints for the hash bucket waiter counting are that the waiter counts have to be incremented _before_ getting the spinlock (because the spinlock acts as part of the memory barrier), but the "requeue" operation didn't honor those rules, and nobody had even thought about that case. This fairly simple patch just increments the waiter count for the target hash bucket (hb2) when requeing a futex before taking the locks. It then decrements them again after releasing the lock - the code that actually moves the futex(es) between hash buckets will do the additional required waiter count housekeeping. Reported-and-tested-by: Jan Stancek <> Acked-by: Davidlohr Bueso <> Cc: Peter Zijlstra <> Cc: Thomas Gleixner <> Cc: # 3.14 Signed-off-by: Linus Torvalds <>
2014-04-09tracepoint: Fix sparse warnings in tracepoint.cMathieu Desnoyers1-2/+4
Fix the following sparse warnings: CHECK kernel/tracepoint.c kernel/tracepoint.c:184:18: warning: incorrect type in assignment (different address spaces) kernel/tracepoint.c:184:18: expected struct tracepoint_func *tp_funcs kernel/tracepoint.c:184:18: got struct tracepoint_func [noderef] <asn:4>*funcs kernel/tracepoint.c:216:18: warning: incorrect type in assignment (different address spaces) kernel/tracepoint.c:216:18: expected struct tracepoint_func *tp_funcs kernel/tracepoint.c:216:18: got struct tracepoint_func [noderef] <asn:4>*funcs kernel/tracepoint.c:392:24: error: return expression in void function CC kernel/tracepoint.o kernel/tracepoint.c: In function tracepoint_module_going: kernel/tracepoint.c:491:6: warning: symbol 'syscall_regfunc' was not declared. Should it be static? kernel/tracepoint.c:508:6: warning: symbol 'syscall_unregfunc' was not declared. Should it be static? Link: Signed-off-by: Mathieu Desnoyers <> Signed-off-by: Steven Rostedt <>
2014-04-08tracepoint: Simplify tracepoint module searchSteven Rostedt (Red Hat)1-5/+4
Instead of copying the num_tracepoints and tracepoints_ptrs from the module structure to the tp_mod structure, which only uses it to find the module associated to tracepoints of modules that are coming and going, simply copy the pointer to the module struct to the tracepoint tp_module structure. Also removed un-needed brackets around an if statement. Link: Acked-by: Mathieu Desnoyers <> Signed-off-by: Steven Rostedt <>
2014-04-08tracepoint: Use struct pointer instead of name hash for reg/unreg tracepointsMathieu Desnoyers6-331/+280
Register/unregister tracepoint probes with struct tracepoint pointer rather than tracepoint name. This change, which vastly simplifies tracepoint.c, has been proposed by Steven Rostedt. It also removes 8.8kB (mostly of text) to the vmlinux size. From this point on, the tracers need to pass a struct tracepoint pointer to probe register/unregister. A probe can now only be connected to a tracepoint that exists. Moreover, tracers are responsible for unregistering the probe before the module containing its associated tracepoint is unloaded. text data bss dec hex filename 10443444 4282528 10391552 25117524 17f4354 vmlinux.orig 10434930 4282848 10391552 25109330 17f2352 vmlinux Link: CC: Ingo Molnar <> CC: Frederic Weisbecker <> CC: Andrew Morton <> CC: Frank Ch. Eigler <> CC: Johannes Berg <> Signed-off-by: Mathieu Desnoyers <> [ SDR - fixed return val in void func in tracepoint_module_going() ] Signed-off-by: Steven Rostedt <>
2014-04-07Merge branch 'akpm' (incoming from Andrew)Linus Torvalds21-117/+155
Merge second patch-bomb from Andrew Morton: - the rest of MM - zram updates - zswap updates - exit - procfs - exec - wait - crash dump - lib/idr - rapidio - adfs, affs, bfs, ufs - cris - Kconfig things - initramfs - small amount of IPC material - percpu enhancements - early ioremap support - various other misc things * emailed patches from Andrew Morton <>: (156 commits) MAINTAINERS: update Intel C600 SAS driver maintainers fs/ufs: remove unused ufs_super_block_third pointer fs/ufs: remove unused ufs_super_block_second pointer fs/ufs: remove unused ufs_super_block_first pointer fs/ufs/super.c: add __init to init_inodecache() doc/kernel-parameters.txt: add early_ioremap_debug arm64: add early_ioremap support arm64: initialize pgprot info earlier in boot x86: use generic early_ioremap mm: create generic early_ioremap() support x86/mm: sparse warning fix for early_memremap lglock: map to spinlock when !CONFIG_SMP percpu: add preemption checks to __this_cpu ops vmstat: use raw_cpu_ops to avoid false positives on preemption checks slub: use raw_cpu_inc for incrementing statistics net: replace __this_cpu_inc in route.c with raw_cpu_inc modules: use raw_cpu_write for initialization of per cpu refcount. mm: use raw_cpu ops for determining current NUMA node percpu: add raw_cpu_ops slub: fix leak of 'name' in sysfs_slab_add ...
2014-04-07lglock: map to spinlock when !CONFIG_SMPJosh Triplett1-1/+2
When the system has only one CPU, lglock is effectively a spinlock; map it directly to spinlock to eliminate the indirection and duplicate code. In addition to removing overhead, this drops 1.6k of code with a defconfig modified to have !CONFIG_SMP, and 1.1k with a minimal config. Signed-off-by: Josh Triplett <> Cc: Rusty Russell <> Cc: Michal Marek <> Cc: Thomas Gleixner <> Cc: David Howells <> Cc: "H. Peter Anvin" <> Cc: Nick Piggin <> Cc: Peter Zijlstra <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <>
2014-04-07modules: use raw_cpu_write for initialization of per cpu refcount.Christoph Lameter1-1/+1
The initialization of a structure is not subject to synchronization. The use of __this_cpu would trigger a false positive with the additional preemption checks for __this_cpu ops. So simply disable the check through the use of raw_cpu ops. Trace: __this_cpu_write operation in preemptible [00000000] code: modprobe/286 caller is __this_cpu_preempt_check+0x38/0x60 CPU: 3 PID: 286 Comm: modprobe Tainted: GF 3.12.0-rc4+ #187 Call Trace: dump_stack+0x4e/0x82 check_preemption_disabled+0xec/0x110 __this_cpu_preempt_check+0x38/0x60 load_module+0xcfd/0x2650 SyS_init_module+0xa6/0xd0 tracesys+0xe1/0xe6 Signed-off-by: Christoph Lameter <> Acked-by: Ingo Molnar <> Acked-by: Rusty Russell <> Cc: Tejun Heo <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <>
2014-04-07kernel: use macros from compiler.h instead of __attribute__((...))Gideon Israel Dsouza13-21/+34
To increase compiler portability there is <linux/compiler.h> which provides convenience macros for various gcc constructs. Eg: __weak for __attribute__((weak)). I've replaced all instances of gcc attributes with the right macro in the kernel subsystem. Signed-off-by: Gideon Israel Dsouza <> Cc: "Rafael J. Wysocki" <> Cc: Ingo Molnar <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <>
2014-04-07kernel/panic.c: display reason at end + pr_emergFabian Frederick1-7/+6
Currently, booting without initrd specified on 80x25 screen gives a call trace followed by atkbd : Spurious ACK. Original message ("VFS: Unable to mount root fs") is not available. Of course this could happen in other situations... This patch displays panic reason after call trace which could help lot of people even if it's not the very last line on screen. Also, convert all panic.c printk(KERN_EMERG to pr_emerg( [ missed a couple of pr_ conversions] Signed-off-by: Fabian Frederick <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <>
2014-04-07hung_task: check the value of "sysctl_hung_task_timeout_sec"Liu Hua1-0/+6
As sysctl_hung_task_timeout_sec is unsigned long, when this value is larger then LONG_MAX/HZ, the function schedule_timeout_interruptible in watchdog will return immediately without sleep and with print : schedule_timeout: wrong timeout value ffffffffffffff83 and then the funtion watchdog will call schedule_timeout_interruptible again and again. The screen will be filled with "schedule_timeout: wrong timeout value ffffffffffffff83" This patch does some check and correction in sysctl, to let the function schedule_timeout_interruptible allways get the valid parameter. Signed-off-by: Liu Hua <> Tested-by: Satoru Takeuchi <> Cc: <> [3.4+] Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <>