aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2014-09-03Merge branch 'rcu/urgent' of ↵Ingo Molnar2-12/+12
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into core/urgent Pull an RCU fix from Paul E. McKenney: "This series contains a single commit fixing an initialization bug reported by Amit Shah and fixed by Pranith Kumar (and tested by Amit). This bug results in a boot-time hang in callback-offloaded configurations where callbacks were posted before the offloading ('rcuo') kthreads were created." Signed-off-by: Ingo Molnar <[email protected]>
2014-09-03powerpc/kvm/cma: Fix panic introduces by signed shift operationLaurent Dufour1-2/+2
fc95ca7284bc54953165cba76c3228bd2cdb9591 introduces a memset in kvmppc_alloc_hpt since the general CMA doesn't clear the memory it allocates. However, the size argument passed to memset is computed from a signed value and its signed bit is extended by the cast the compiler is doing. This lead to extremely large size value when dealing with order value >= 31, and almost all the memory following the allocated space is cleaned. As a consequence, the system is panicing and may even fail spawning the kdump kernel. This fix makes use of an unsigned value for the memset's size argument to avoid sign extension. Among this fix, another shift operation which may lead to signed extended value too is also fixed. Cc: Alexey Kardashevskiy <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Alexander Graf <[email protected]> Cc: Aneesh Kumar K.V <[email protected]> Cc: Joonsoo Kim <[email protected]> Cc: Benjamin Herrenschmidt <[email protected]> Signed-off-by: Laurent Dufour <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2014-09-03Merge branch 'vmwgfx-fixes-3.17' of ↵Dave Airlie2-7/+7
git://people.freedesktop.org/~thomash/linux into drm-fixes Two vmwgfx fixes, marked for stable as well * 'vmwgfx-fixes-3.17' of git://people.freedesktop.org/~thomash/linux: drm/vmwgfx: Fix a potential infinite spin waiting for fifo idle drm/vmwgfx: Fix an incorrect OOM return value
2014-09-03PEFILE: Relax the check on the length of the PKCS#7 certDavid Howells1-16/+33
Relax the check on the length of the PKCS#7 cert as it appears that the PE file wrapper size gets rounded up to the nearest 8. The debugging output looks like this: PEFILE: ==> verify_pefile_signature() PEFILE: ==> pefile_parse_binary() PEFILE: checksum @ 110 PEFILE: header size = 200 PEFILE: cert = 968 @547be0 [68 09 00 00 00 02 02 00 30 82 09 56 ] PEFILE: sig wrapper = { 968, 200, 2 } PEFILE: Signature data not PKCS#7 The wrapper is the first 8 bytes of the hex dump inside []. This indicates a length of 0x968 bytes, including the wrapper header - so 0x960 bytes of payload. The ASN.1 wrapper begins [ ... 30 82 09 56 ]. That indicates an object of size 0x956 - a four byte discrepency, presumably just padding for alignment purposes. So we just check that the ASN.1 container is no bigger than the payload and reduce the recorded size appropriately. Whilst we're at it, allow shorter PKCS#7 objects that manage to squeeze within 127 or 255 bytes. It's just about conceivable if no X.509 certs are included in the PKCS#7 message. Reported-by: Vivek Goyal <[email protected]> Signed-off-by: David Howells <[email protected]> Acked-by: Vivek Goyal <[email protected]> Acked-by: Peter Jones <[email protected]> Signed-off-by: James Morris <[email protected]>
2014-09-03KEYS: Fix use-after-free in assoc_array_gc()David Howells1-1/+1
An edit script should be considered inaccessible by a function once it has called assoc_array_apply_edit() or assoc_array_cancel_edit(). However, assoc_array_gc() is accessing the edit script just after the gc_complete: label. Reported-by: Andreea-Cristina Bernat <[email protected]> Signed-off-by: David Howells <[email protected]> Reviewed-by: Andreea-Cristina Bernat <[email protected]> cc: [email protected] cc: [email protected] Cc: [email protected] Signed-off-by: James Morris <[email protected]>
2014-09-03KEYS: Fix public_key asymmetric key subtype nameDavid Howells1-0/+1
The length of the name of an asymmetric key subtype must be stored in struct asymmetric_key_subtype::name_len so that it can be matched by a search for "<subkey_name>:<partial_fingerprint>". Fix the public_key subtype to have name_len set. Signed-off-by: David Howells <[email protected]> Signed-off-by: James Morris <[email protected]>
2014-09-03KEYS: Increase root_maxkeys and root_maxbytes sizesSteve Dickson1-2/+2
Now that NFS client uses the kernel key ring facility to store the NFSv4 id/gid mappings, the defaults for root_maxkeys and root_maxbytes need to be substantially increased. These values have been soak tested: https://bugzilla.redhat.com/show_bug.cgi?id=1033708#c73 Signed-off-by: Steve Dickson <[email protected]> Signed-off-by: David Howells <[email protected]> Signed-off-by: James Morris <[email protected]>
2014-09-03cpufreq: intel_pstate: Remove unneeded variableGabriele Mazzotta1-4/+0
It should have been removed with commit d1b6848590af ("cpufreq / intel_pstate: Optimize intel_pstate_set_policy") Signed-off-by: Gabriele Mazzotta <[email protected]> Acked-by: Viresh Kumar <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2014-09-03powercap / RAPL: change domain detection messageJacob Pan1-4/+3
Many CPUs do not support complete set of RAPL domains, as a result this detection failed message is very misleading and can be annoying. [ 5.082632] intel_rapl: RAPL domain core detection failed [ 5.088370] intel_rapl: RAPL domain uncore detection failed So lower the warning message to info and only print out the RAPL domains that are supported. Signed-off-by: Jacob Pan <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2014-09-03powercap / RAPL: add support for CPU model 0x3fJason Baron1-0/+1
I've confirmed that monitoring the package power usage as well as setting power limits appear to be working as expected. Supports the package and dram domains. Tested aginst cpu: Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz Signed-off-by: Jason Baron <[email protected]> Acked-by: Jacob Pan <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2014-09-03PM / domains: Make generic_pm_domain.name constGeert Uytterhoeven1-1/+1
Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2014-09-03PM / sleep: Fix test_suspend= command line optionRafael J. Wysocki3-13/+21
After commit d431cbc53cb7 (PM / sleep: Simplify sleep states sysfs interface code) the pm_states[] array is not populated initially, which causes setup_test_suspend() to always fail and the suspend testing during boot doesn't work any more. Fix the problem by using pm_labels[] instead of pm_states[] in setup_test_suspend() and storing a pointer to the label of the sleep state to test rather than the number representing it, because the connection between the state numbers and labels is only established by suspend_set_ops(). Fixes: d431cbc53cb7 (PM / sleep: Simplify sleep states sysfs interface code) Reported-by: Srinivas Pandruvada <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2014-09-02platform/x86: toshiba: re-enable acpi hotkeys after suspend to diskBenjamin Tissoires1-1/+8
On the Toshiba Tecra Z40, after a suspend-to-disk, some FN hotkeys driven by toshiba_acpi are not functional. Calling the ACPI object ENAB on resume makes them back alive. Signed-off-by: Benjamin Tissoires <[email protected]> Acked-by: Matthew Garrett <[email protected]> Signed-off-by: Darren Hart <[email protected]>
2014-09-02Merge remote-tracking branches 'asoc/fix/axi', 'asoc/fix/cs4265', ↵Mark Brown9-15/+24
'asoc/fix/da732x', 'asoc/fix/omap', 'asoc/fix/rsnd', 'asoc/fix/rt5640', 'asoc/fix/rt5677', 'asoc/fix/simple' and 'asoc/fix/tegra' into asoc-linus
2014-09-02Merge remote-tracking branch 'asoc/fix/core' into asoc-linusMark Brown2-2/+2
2014-09-02ideapad-laptop: Constify DMI table for real!Mathias Krause1-2/+2
This is a follow-up patch to commit 49458e83082d ("ideapad-laptop: Constify DMI table and other r/o variables") to do what its commit message says. The actual commit differs from the patch posted at https://www.mail-archive.com/[email protected]/msg05340.html significantly, probably due to a bad merge conflict resolution. Fix up the mess and constify the DMI table for real and fix the bogus double-const of ideapad_rfk_data[]. Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Mathias Krause <[email protected]> Cc: Matthew Garrett <[email protected]> Cc: Ike Panhc <[email protected]> Signed-off-by: Darren Hart <[email protected]>
2014-09-02aio: add missing smp_rmb() in read_events_ringJeff Moyer1-0/+6
We ran into a case on ppc64 running mariadb where io_getevents would return zeroed out I/O events. After adding instrumentation, it became clear that there was some missing synchronization between reading the tail pointer and the events themselves. This small patch fixes the problem in testing. Thanks to Zach for helping to look into this, and suggesting the fix. Signed-off-by: Jeff Moyer <[email protected]> Signed-off-by: Benjamin LaHaise <[email protected]> Cc: [email protected]
2014-09-02ARM: ux500: disable msp2 node on SnowballLinus Walleij1-1/+0
Analogous to commit 8858d88a25142544843869f0cd3e6654aa7b4aec that fixed commit 70b41abc151f9 "ARM: ux500: move MSP pin control to the device tree" accidentally activated MSP2, giving rise to a boot scroll scream as the kernel attempts to probe a driver for it and fails to obtain DMA channel 14. For some reason I forgot to fix this on the Snowball. Fix this up by marking the node disabled again. Cc: Lee Jones <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Tested-by: Kevin Hilman <[email protected]> Signed-off-by: Kevin Hilman <[email protected]>
2014-09-02Revert "leds: convert blink timer to workqueue"Jiri Kosina3-14/+14
This reverts commit 8b37e1bef5a6b60e949e28a4db3006e4b00bd758. It's broken as it changes led_blink_set() in a way that it can now sleep (while synchronously waiting for workqueue to be cancelled). That's a problem, because it's possible that this function gets called from atomic context (tpt_trig_timer() takes a readlock and thus disables preemption). This has been brought up 3 weeks ago already [1] but no proper fix has materialized, and I keep seeing the problem since 3.17-rc1. [1] https://lkml.org/lkml/2014/8/16/128 BUG: sleeping function called from invalid context at kernel/workqueue.c:2650 in_atomic(): 1, irqs_disabled(): 0, pid: 2335, name: wpa_supplicant 5 locks held by wpa_supplicant/2335: #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c7c92>] rtnl_lock+0x12/0x20 #1: (&wdev->mtx){+.+.+.}, at: [<ffffffffc06e649c>] cfg80211_mgd_wext_siwessid+0x5c/0x180 [cfg80211] #2: (&local->mtx){+.+.+.}, at: [<ffffffffc0817dea>] ieee80211_prep_connection+0x17a/0x9a0 [mac80211] #3: (&local->chanctx_mtx){+.+.+.}, at: [<ffffffffc08081ed>] ieee80211_vif_use_channel+0x5d/0x2a0 [mac80211] #4: (&trig->leddev_list_lock){.+.+..}, at: [<ffffffffc081e68c>] tpt_trig_timer+0xec/0x170 [mac80211] CPU: 0 PID: 2335 Comm: wpa_supplicant Not tainted 3.17.0-rc3 #1 Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008 ffff8800360b5a50 ffff8800751f76d8 ffffffff8159e97f ffff8800360b5a30 ffff8800751f76e8 ffffffff810739a5 ffff8800751f77b0 ffffffff8106862f ffffffff810685d0 0aa2209200000000 ffff880000000004 ffff8800361c59d0 Call Trace: [<ffffffff8159e97f>] dump_stack+0x4d/0x66 [<ffffffff810739a5>] __might_sleep+0xe5/0x120 [<ffffffff8106862f>] flush_work+0x5f/0x270 [<ffffffff810685d0>] ? mod_delayed_work_on+0x80/0x80 [<ffffffff810945ca>] ? mark_held_locks+0x6a/0x90 [<ffffffff81068a5f>] ? __cancel_work_timer+0x6f/0x100 [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [<ffffffff81068a6b>] __cancel_work_timer+0x7b/0x100 [<ffffffff81068b0e>] cancel_delayed_work_sync+0xe/0x10 [<ffffffff8147cf3b>] led_blink_set+0x1b/0x40 [<ffffffffc081e6b0>] tpt_trig_timer+0x110/0x170 [mac80211] [<ffffffffc081ecdd>] ieee80211_mod_tpt_led_trig+0x9d/0x160 [mac80211] [<ffffffffc07e4278>] __ieee80211_recalc_idle+0x98/0x140 [mac80211] [<ffffffffc07e59ce>] ieee80211_idle_off+0xe/0x10 [mac80211] [<ffffffffc0804e5b>] ieee80211_add_chanctx+0x3b/0x220 [mac80211] [<ffffffffc08062e4>] ieee80211_new_chanctx+0x44/0xf0 [mac80211] [<ffffffffc080838a>] ieee80211_vif_use_channel+0x1fa/0x2a0 [mac80211] [<ffffffffc0817df8>] ieee80211_prep_connection+0x188/0x9a0 [mac80211] [<ffffffffc081c246>] ieee80211_mgd_auth+0x256/0x2e0 [mac80211] [<ffffffffc07eab33>] ieee80211_auth+0x13/0x20 [mac80211] [<ffffffffc06cb006>] cfg80211_mlme_auth+0x106/0x270 [cfg80211] [<ffffffffc06ce085>] cfg80211_conn_do_work+0x155/0x3b0 [cfg80211] [<ffffffffc06cf670>] cfg80211_connect+0x3f0/0x540 [cfg80211] [<ffffffffc06e6148>] cfg80211_mgd_wext_connect+0x158/0x1f0 [cfg80211] [<ffffffffc06e651e>] cfg80211_mgd_wext_siwessid+0xde/0x180 [cfg80211] [<ffffffffc06e36c0>] ? cfg80211_wext_giwessid+0x50/0x50 [cfg80211] [<ffffffffc06e36dd>] cfg80211_wext_siwessid+0x1d/0x40 [cfg80211] [<ffffffff81584d0c>] ioctl_standard_iw_point+0x14c/0x3e0 [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [<ffffffff8158502a>] ioctl_standard_call+0x8a/0xd0 [<ffffffff81584fa0>] ? ioctl_standard_iw_point+0x3e0/0x3e0 [<ffffffff81584b76>] wireless_process_ioctl.constprop.10+0xb6/0x100 [<ffffffff8158521d>] wext_handle_ioctl+0x5d/0xb0 [<ffffffff814cfb29>] dev_ioctl+0x329/0x620 [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [<ffffffff8149c7f2>] sock_ioctl+0x142/0x2e0 [<ffffffff811b0140>] do_vfs_ioctl+0x300/0x520 [<ffffffff815a67fb>] ? sysret_check+0x1b/0x56 [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [<ffffffff811b03e1>] SyS_ioctl+0x81/0xa0 [<ffffffff815a67d6>] system_call_fastpath+0x1a/0x1f wlan0: send auth to 00:0b:6b:3c:8c:e4 (try 1/3) wlan0: authenticated wlan0: associate with 00:0b:6b:3c:8c:e4 (try 1/3) wlan0: RX AssocResp from 00:0b:6b:3c:8c:e4 (capab=0x431 status=0 aid=2) wlan0: associated IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready cfg80211: Calling CRDA for country: NA wlan0: Limiting TX power to 27 (27 - 0) dBm as advertised by 00:0b:6b:3c:8c:e4 ================================= [ INFO: inconsistent lock state ] 3.17.0-rc3 #1 Not tainted --------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. swapper/0/0 [HC0[0]:SC1[1]:HE1:SE0] takes: ((&(&led_cdev->blink_work)->work)){+.?...}, at: [<ffffffff810685d0>] flush_work+0x0/0x270 {SOFTIRQ-ON-W} state was registered at: [<ffffffff81094dbe>] __lock_acquire+0x30e/0x1a30 [<ffffffff81096c81>] lock_acquire+0x91/0x110 [<ffffffff81068608>] flush_work+0x38/0x270 [<ffffffff81068a6b>] __cancel_work_timer+0x7b/0x100 [<ffffffff81068b0e>] cancel_delayed_work_sync+0xe/0x10 [<ffffffff8147cf3b>] led_blink_set+0x1b/0x40 [<ffffffffc081e6b0>] tpt_trig_timer+0x110/0x170 [mac80211] [<ffffffffc081ecdd>] ieee80211_mod_tpt_led_trig+0x9d/0x160 [mac80211] [<ffffffffc07e4278>] __ieee80211_recalc_idle+0x98/0x140 [mac80211] [<ffffffffc07e59ce>] ieee80211_idle_off+0xe/0x10 [mac80211] [<ffffffffc0804e5b>] ieee80211_add_chanctx+0x3b/0x220 [mac80211] [<ffffffffc08062e4>] ieee80211_new_chanctx+0x44/0xf0 [mac80211] [<ffffffffc080838a>] ieee80211_vif_use_channel+0x1fa/0x2a0 [mac80211] [<ffffffffc0817df8>] ieee80211_prep_connection+0x188/0x9a0 [mac80211] [<ffffffffc081c246>] ieee80211_mgd_auth+0x256/0x2e0 [mac80211] [<ffffffffc07eab33>] ieee80211_auth+0x13/0x20 [mac80211] [<ffffffffc06cb006>] cfg80211_mlme_auth+0x106/0x270 [cfg80211] [<ffffffffc06ce085>] cfg80211_conn_do_work+0x155/0x3b0 [cfg80211] [<ffffffffc06cf670>] cfg80211_connect+0x3f0/0x540 [cfg80211] [<ffffffffc06e6148>] cfg80211_mgd_wext_connect+0x158/0x1f0 [cfg80211] [<ffffffffc06e651e>] cfg80211_mgd_wext_siwessid+0xde/0x180 [cfg80211] [<ffffffffc06e36dd>] cfg80211_wext_siwessid+0x1d/0x40 [cfg80211] [<ffffffff81584d0c>] ioctl_standard_iw_point+0x14c/0x3e0 [<ffffffff8158502a>] ioctl_standard_call+0x8a/0xd0 [<ffffffff81584b76>] wireless_process_ioctl.constprop.10+0xb6/0x100 [<ffffffff8158521d>] wext_handle_ioctl+0x5d/0xb0 [<ffffffff814cfb29>] dev_ioctl+0x329/0x620 [<ffffffff8149c7f2>] sock_ioctl+0x142/0x2e0 [<ffffffff811b0140>] do_vfs_ioctl+0x300/0x520 [<ffffffff811b03e1>] SyS_ioctl+0x81/0xa0 [<ffffffff815a67d6>] system_call_fastpath+0x1a/0x1f irq event stamp: 493416 hardirqs last enabled at (493416): [<ffffffff81068a5f>] __cancel_work_timer+0x6f/0x100 hardirqs last disabled at (493415): [<ffffffff81067e9f>] try_to_grab_pending+0x1f/0x160 softirqs last enabled at (493408): [<ffffffff81053ced>] _local_bh_enable+0x1d/0x50 softirqs last disabled at (493409): [<ffffffff81054c75>] irq_exit+0xa5/0xb0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock((&(&led_cdev->blink_work)->work)); <Interrupt> lock((&(&led_cdev->blink_work)->work)); *** DEADLOCK *** 2 locks held by swapper/0/0: #0: (((&tpt_trig->timer))){+.-...}, at: [<ffffffff810b4c50>] call_timer_fn+0x0/0x180 #1: (&trig->leddev_list_lock){.+.?..}, at: [<ffffffffc081e68c>] tpt_trig_timer+0xec/0x170 [mac80211] stack backtrace: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.17.0-rc3 #1 Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008 ffffffff8246eb30 ffff88007c203b00 ffffffff8159e97f ffffffff81a194c0 ffff88007c203b50 ffffffff81599c29 0000000000000001 ffffffff00000001 ffff880000000000 0000000000000006 ffffffff81a194c0 ffffffff81093ad0 Call Trace: <IRQ> [<ffffffff8159e97f>] dump_stack+0x4d/0x66 [<ffffffff81599c29>] print_usage_bug+0x1f4/0x205 [<ffffffff81093ad0>] ? check_usage_backwards+0x140/0x140 [<ffffffff810944d3>] mark_lock+0x223/0x2b0 [<ffffffff81094d60>] __lock_acquire+0x2b0/0x1a30 [<ffffffff81096c81>] lock_acquire+0x91/0x110 [<ffffffff810685d0>] ? mod_delayed_work_on+0x80/0x80 [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211] [<ffffffff81068608>] flush_work+0x38/0x270 [<ffffffff810685d0>] ? mod_delayed_work_on+0x80/0x80 [<ffffffff810945ca>] ? mark_held_locks+0x6a/0x90 [<ffffffff81068a5f>] ? __cancel_work_timer+0x6f/0x100 [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211] [<ffffffff8109469d>] ? trace_hardirqs_on_caller+0xad/0x1c0 [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211] [<ffffffff81068a6b>] __cancel_work_timer+0x7b/0x100 [<ffffffff81068b0e>] cancel_delayed_work_sync+0xe/0x10 [<ffffffff8147cf3b>] led_blink_set+0x1b/0x40 [<ffffffffc081e6b0>] tpt_trig_timer+0x110/0x170 [mac80211] [<ffffffff810b4cc5>] call_timer_fn+0x75/0x180 [<ffffffff810b4c50>] ? process_timeout+0x10/0x10 [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211] [<ffffffff810b50ac>] run_timer_softirq+0x1fc/0x2f0 [<ffffffff81054805>] __do_softirq+0x115/0x2e0 [<ffffffff81054c75>] irq_exit+0xa5/0xb0 [<ffffffff810049b3>] do_IRQ+0x53/0xf0 [<ffffffff815a74af>] common_interrupt+0x6f/0x6f <EOI> [<ffffffff8147b56e>] ? cpuidle_enter_state+0x6e/0x180 [<ffffffff8147b732>] cpuidle_enter+0x12/0x20 [<ffffffff8108bba0>] cpu_startup_entry+0x330/0x360 [<ffffffff8158fb51>] rest_init+0xc1/0xd0 [<ffffffff8158fa90>] ? csum_partial_copy_generic+0x170/0x170 [<ffffffff81af3ff2>] start_kernel+0x44f/0x45a [<ffffffff81af399c>] ? set_init_arg+0x53/0x53 [<ffffffff81af35ad>] x86_64_start_reservations+0x2a/0x2c [<ffffffff81af36a0>] x86_64_start_kernel+0xf1/0xf4 Cc: Vincent Donnefort <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: Tejun Heo <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Bryan Wu <[email protected]>
2014-09-02i2c: at91: add bound checking on SMBus block length bytesMarek Roszko1-4/+24
The driver was not bound checking the received length byte to ensure it was within the the buffer size that is allocated for SMBus blocks. This resulted in buffer overflows whenever an invalid length byte was received. It also failed to ensure the length byte was not zero. If it received zero, it would end up in an infinite loop as the at91_twi_read_next_byte function returned immediately without allowing RHR to be read to clear the RXRDY interrupt. Tested agaisnt a SMBus compliant battery. Signed-off-by: Marek Roszko <[email protected]> Acked-by: Ludovic Desroches <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Cc: [email protected]
2014-09-02i2c: rk3x: fix bug that cause transfer fails in master receive modeaddy ke1-0/+4
In rk3x SOC, the I2C controller can receive/transmit up to 32 bytes data in one chunk, so the size of data to be write/read to/from TXDATAx/RXDATAx must be less than or equal 32 bytes at a time. Tested on rk3288-pinky board, elan receive 158 bytes data. Signed-off-by: Addy Ke <[email protected]> Acked-by: Max Schwarz <[email protected]> Reviewed-by: Doug Anderson <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Cc: [email protected]
2014-09-02i2c: at91: Fix a race condition during signal handling in at91_do_twi_xfer.Simon Lindgren1-2/+2
There is a race condition in at91_do_twi_xfer when signals arrive. If a signal is recieved while waiting for a transfer to complete wait_for_completion_interruptible_timeout() will return -ERESTARTSYS. This is not handled correctly resulting in interrupts still being enabled and a transfer being in flight when we return. Symptoms include a range of oopses and bus lockups. Oopses can happen when the transfer completes because the interrupt handler will corrupt the stack. If a new transfer is started before the interrupt fires the controller will start a new transfer in the middle of the old one, resulting in confused slaves and a locked bus. To avoid this, use wait_for_completion_io_timeout instead so that we don't have to deal with gracefully shutting down the transfer and disabling the interrupts. Signed-off-by: Simon Lindgren <[email protected]> Acked-by: Ludovic Desroches <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Cc: [email protected]
2014-09-02i2c: mv64xxx: continue probe when clock-frequency is missingChen-Yu Tsai1-2/+1
The "clock-frequency" DT property is listed as optional, However, the current code stores the return value of of_property_read_u32 in the return code of mv64xxx_of_config, but then forgets to clear it after setting the default value of "clock-frequency". It is then passed out to the main probe function, resulting in a probe failure when "clock-frequency" is missing. This patch checks and then throws away the return value of of_property_read_u32, instead of storing it and having to clear it afterwards. This issue was discovered after the property was removed from all sunxi DTs. Fixes: 4c730a06c19bb ("i2c: mv64xxx: Set bus frequency to 100kHz if clock-frequency is not provided") Signed-off-by: Chen-Yu Tsai <[email protected]> Cc: [email protected] Acked-by: Andrew Lunn <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2014-09-02i2c: rcar: fix MNR interrupt handlingSergei Shtylyov1-6/+9
Sometimes the MNR and MST interrupts happen simultaneously (stop automatically follows NACK, according to the manuals) and in such case the ID_NACK flag isn't set since the MST interrupt handling precedes MNR and all interrupts are cleared and disabled then, so that MNR interrupt is never noticed -- this causes NACK'ed transfers to be falsely reported as successful. Exchanging MNR and MST handlers fixes this issue, however the MNR bit somehow gets set again even after being explicitly cleared, so I decided to completely suppress handling of all disabled interrupts (which is a good thing anyway)... Signed-off-by: Sergei Shtylyov <[email protected]> Cc: [email protected] Signed-off-by: Wolfram Sang <[email protected]>
2014-09-02drm/i915: Fix lock dropping in intel_tv_detect()Ville Syrjälä1-3/+7
When intel_tv_detect() fails to do load detection it would forget to drop the locks and clean up the acquire context. Fix it up. This is a regression from: commit 208bf9fdcd3575aa4a5d48b3e0295f7cdaf6fc44 Author: Ville Syrjälä <[email protected]> Date: Mon Aug 11 13:15:35 2014 +0300 drm/i915: Fix locking for intel_enable_pipe_a() v2: Make the code more readable (Chris) v3: Drop WARN_ON(type < 0) (Chris) Cc: [email protected] Cc: Tibor Billes <[email protected]> Reported-by: Tibor Billes <[email protected]> Tested-by: Tibor Billes <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]>
2014-09-02Merge tag 'kvm-s390-master-20140902' of ↵Paolo Bonzini1-2/+4
git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into kvm-master
2014-09-02KVM: s390/mm: Fix guest storage key corruption in ptep_set_access_flagsChristian Borntraeger1-0/+1
commit 0944fe3f4a32 ("s390/mm: implement software referenced bits") triggered another paging/storage key corruption. There is an unhandled invalid->valid pte change where we have to set the real storage key from the pgste. When doing paging a guest page might be swapcache or swap and when faulted in it might be read-only and due to a parallel scan old. An do_wp_page will make it writeable and young. Due to software reference tracking this page was invalid and now becomes valid. Signed-off-by: Christian Borntraeger <[email protected]> Acked-by: Martin Schwidefsky <[email protected]> Cc: [email protected] # v3.12+
2014-09-02KVM: s390/mm: Fix storage key corruption during swappingChristian Borntraeger1-2/+3
Since 3.12 or more precisely commit 0944fe3f4a32 ("s390/mm: implement software referenced bits") guest storage keys get corrupted during paging. This commit added another valid->invalid translation for page tables - namely ptep_test_and_clear_young. We have to transfer the storage key into the pgste in that case. Signed-off-by: Christian Borntraeger <[email protected]> Acked-by: Martin Schwidefsky <[email protected]> Cc: [email protected] # v3.12+
2014-09-02gpio: move varargs hack outside #ifdef GPIOLIBLinus Walleij1-45/+60
commit 39b2bbe3d715cf5013b5c48695ccdd25bd3bf120 "gpio: add flags argument to gpiod_get*() functions" added a dynamic flags argument to all the GPIOD getter functions, however this did not cover the stubs so when people used gpiod stubs to compile out descriptor code, compilation failed. Solve this by: - Also rename all the stub functions __gpiod_* - Moving the vararg hack outside of #ifdef CONFIG_GPIOLIB so these will always be available. Reviewed-by: Alexandre Courbot <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2014-09-02f2fs: reposition unlock_new_inode to prevent accessing invalid inodeChao Yu2-16/+6
As the race condition on the inode cache, following scenario can appear: [Thread a] [Thread b] ->f2fs_mkdir ->f2fs_add_link ->__f2fs_add_link ->init_inode_metadata failed here ->gc_thread_func ->f2fs_gc ->do_garbage_collect ->gc_data_segment ->f2fs_iget ->iget_locked ->wait_on_inode ->unlock_new_inode ->move_data_page ->make_bad_inode ->iput When we fail in create/symlink/mkdir/mknod/tmpfile, the new allocated inode should be set as bad to avoid being accessed by other thread. But in above scenario, it allows f2fs to access the invalid inode before this inode was set as bad. This patch fix the potential problem, and this issue was found by code review. change log from v1: o Add condition judgment in gc_data_segment() suggested by Changman Lee. o use iget_failed to simplify code. Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]>
2014-09-02ALSA: hda - Fix COEF setups for ALC1150 codecTakashi Iwai1-0/+2
ALC1150 codec seems to need the COEF- and PLL-setups just like its compatible ALC882 codec. Some machines (e.g. SunMicro X10SAT) show the problem like too low output volumes unless the COEF setup is applied. Reported-and-tested-by: Dana Goyette <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2014-09-02xfs: trim eofblocks before collapse rangeBrian Foster1-2/+9
xfs_collapse_file_space() currently writes back the entire file undergoing collapse range to settle things down for the extent shift algorithm. While this prevents changes to the extent list during the collapse operation, the writeback itself is not enough to prevent unnecessary collapse failures. The current shift algorithm uses the extent index to iterate the in-core extent list. If a post-eof delalloc extent persists after the writeback (e.g., a prior zero range op where the end of the range aligns with eof can separate the post-eof blocks such that they are not written back and converted), xfs_bmap_shift_extents() becomes confused over the encoded br_startblock value and fails the collapse. As with the full writeback, this is a temporary fix until the algorithm is improved to cope with a volatile extent list and avoid attempts to shift post-eof extents. Signed-off-by: Brian Foster <[email protected]> Reviewed-by: Dave Chinner <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Dave Chinner <[email protected]>
2014-09-02xfs: xfs_file_collapse_range is delalloc challengedDave Chinner1-0/+13
If we have delalloc extents on a file before we run a collapse range opertaion, we sync the range that we are going to collapse to convert delalloc extents in that region to real extents to simplify the shift operation. However, the shift operation then assumes that the extent list is not going to change as it iterates over the extent list moving things about. Unfortunately, this isn't true because we can't hold the ILOCK over all the operations. We can prevent new IO from modifying the extent list by holding the IOLOCK, but that doesn't prevent writeback from running.... And when writeback runs, it can convert delalloc extents is the range of the file prior to the region being collapsed, and this changes the indexes of all the extents in the file. That causes the collapse range operation to Go Bad. The right fix is to rewrite the extent shift operation not to be dependent on the extent list not changing across the entire operation, but this is a fairly significant piece of work to do. Hence, as a short-term workaround for the problem, sync the entire file before starting a collapse operation to remove all delalloc ranges from the file and so avoid the problem of concurrent writeback changing the extent list. Diagnosed-and-Reported-by: Brian Foster <[email protected]> Signed-off-by: Dave Chinner <[email protected]> Reviewed-by: Brian Foster <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Dave Chinner <[email protected]>
2014-09-02xfs: don't log inode unless extent shift makes extent modificationsBrian Foster1-8/+10
The file collapse mechanism uses xfs_bmap_shift_extents() to collapse all subsequent extents down into the specified, previously punched out, region. This function performs some validation, such as whether a sufficient hole exists in the target region of the collapse, then shifts the remaining exents downward. The exit path of the function currently logs the inode unconditionally. While we must log the inode (and abort) if an error occurs and the transaction is dirty, the initial validation paths can generate errors before the transaction has been dirtied. This creates an unnecessary filesystem shutdown scenario, as the caller will cancel a transaction that has been marked dirty. Modify xfs_bmap_shift_extents() to OR the logflags bits as modifications are made to the inode bmap. Only log the inode in the exit path if logflags has been set. This ensures we only have to cancel a dirty transaction if modifications have been made and prevents an unnecessary filesystem shutdown otherwise. Signed-off-by: Brian Foster <[email protected]> Reviewed-by: Dave Chinner <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Dave Chinner <[email protected]>
2014-09-02xfs: use ranged writeback and invalidation for direct IODave Chinner1-4/+6
Now we are not doing silly things with dirtying buffers beyond EOF and using invalidation correctly, we can finally reduce the ranges of writeback and invalidation used by direct IO to match that of the IO being issued. Bring the writeback and invalidation ranges back to match the generic direct IO code - this will greatly reduce the perturbation of cached data when direct IO and buffered IO are mixed, but still provide the same buffered vs direct IO coherency behaviour we currently have. Signed-off-by: Dave Chinner <[email protected]> Reviewed-by: Brian Foster <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Dave Chinner <[email protected]>
2014-09-02xfs: don't zero partial page cache pages during O_DIRECT writesDave Chinner1-1/+9
Similar to direct IO reads, direct IO writes are using truncate_pagecache_range to invalidate the page cache. This is incorrect due to the sub-block zeroing in the page cache that truncate_pagecache_range() triggers. This patch fixes things by using invalidate_inode_pages2_range instead. It preserves the page cache invalidation, but won't zero any pages. cc: [email protected] Signed-off-by: Dave Chinner <[email protected]> Reviewed-by: Brian Foster <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Dave Chinner <[email protected]>
2014-09-02xfs: don't zero partial page cache pages during O_DIRECT writesChris Mason1-1/+10
xfs is using truncate_pagecache_range to invalidate the page cache during DIO reads. This is different from the other filesystems who only invalidate pages during DIO writes. truncate_pagecache_range is meant to be used when we are freeing the underlying data structs from disk, so it will zero any partial ranges in the page. This means a DIO read can zero out part of the page cache page, and it is possible the page will stay in cache. buffered reads will find an up to date page with zeros instead of the data actually on disk. This patch fixes things by using invalidate_inode_pages2_range instead. It preserves the page cache invalidation, but won't zero any pages. [dchinner: catch error and warn if it fails. Comment.] cc: [email protected] Signed-off-by: Chris Mason <[email protected]> Reviewed-by: Dave Chinner <[email protected]> Reviewed-by: Brian Foster <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Dave Chinner <[email protected]>
2014-09-02xfs: don't dirty buffers beyond EOFDave Chinner1-0/+61
generic/263 is failing fsx at this point with a page spanning EOF that cannot be invalidated. The operations are: 1190 mapwrite 0x52c00 thru 0x5e569 (0xb96a bytes) 1191 mapread 0x5c000 thru 0x5d636 (0x1637 bytes) 1192 write 0x5b600 thru 0x771ff (0x1bc00 bytes) where 1190 extents EOF from 0x54000 to 0x5e569. When the direct IO write attempts to invalidate the cached page over this range, it fails with -EBUSY and so any attempt to do page invalidation fails. The real question is this: Why can't that page be invalidated after it has been written to disk and cleaned? Well, there's data on the first two buffers in the page (1k block size, 4k page), but the third buffer on the page (i.e. beyond EOF) is failing drop_buffers because it's bh->b_state == 0x3, which is BH_Uptodate | BH_Dirty. IOWs, there's dirty buffers beyond EOF. Say what? OK, set_buffer_dirty() is called on all buffers from __set_page_buffers_dirty(), regardless of whether the buffer is beyond EOF or not, which means that when we get to ->writepage, we have buffers marked dirty beyond EOF that we need to clean. So, we need to implement our own .set_page_dirty method that doesn't dirty buffers beyond EOF. This is messy because the buffer code is not meant to be shared and it has interesting locking issues on the buffer dirty bits. So just copy and paste it and then modify it to suit what we need. Note: the solutions the other filesystems and generic block code use of marking the buffers clean in ->writepage does not work for XFS. It still leaves dirty buffers beyond EOF and invalidations still fail. Hence rather than play whack-a-mole, this patch simply prevents those buffers from being dirtied in the first place. cc: <[email protected]> Signed-off-by: Dave Chinner <[email protected]> Reviewed-by: Brian Foster <[email protected]> Signed-off-by: Dave Chinner <[email protected]>
2014-09-02ACPI / EC: Add msi quirk for Clevo W350etqLan Tianyu1-0/+4
Clevo W350etq's EC will not produce GPE interrupt some time after booting. The ACPI notify event won't trigger when the issue takes place. After debugging, adding msi quirk for the machine can fix the issue. This patch is to add msi quirk for the machine. Link: https://bugzilla.kernel.org/show_bug.cgi?id=77431 Reported-and-tested-by: [email protected] Signed-off-by: Lan Tianyu <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2014-09-02ACPI / video: Disable native_backlight on HP ENVY 15 Notebook PCHans de Goede1-0/+11
Link: https://bugs.freedesktop.org/show_bug.cgi?id=81515 Reported-and-tested-by: Hohahiu <[email protected]> Cc: 3.16+ <[email protected]> # 3.16+ Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2014-09-02ACPI / video: Add a disable_native_backlight quirkHans de Goede1-0/+30
Some laptops have a working acpi_video backlight control, and using native backlight on these causes a regression where backlight control does not work when userspace is not handling brightness key events. Disable native_backlight on these to fix this. Link: https://bugzilla.kernel.org/show_bug.cgi?id=81691 Reported-and-tested-by: Andre Müller <[email protected]> Cc: 3.16+ <[email protected]> # 3.16+ Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2014-09-02ACPI / video: Fix use_native_backlight selection logicHans de Goede1-2/+2
Commit 751109aad583 ("ACPI / video: Change the default for video.use_native_backlight to 1") has changed the default for use_native_backlight from 0 to 1, but instead of changing use_native_backlight_dmi to true, and leaving use_native_backlight_param at -1, it has changed use_native_backlight_param to 1. This causes acpi_video_use_native_backlight() to always think that a value was specified through the param, making it impossible to add a dmi based quirk to force 0 now that the default is 1. This fixes this by restoring the use_native_backlight_param default to -1, and instead setting the use_native_backlight_dmi default to true. Fixes: 751109aad583 (ACPI / video: Change the default for video.use_native_backlight to 1) Cc: 3.16+ <[email protected]> # 3.16+ Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2014-09-02ACPICA: ACPI 5.1: Add support for runtime validation of _DSD package.Mika Westerberg1-0/+39
Adds ACPICA kernel runtime support to validate contents/format of the _DSD package, similar to the iASL support. Ported by Mika Westerberg. Signed-off-by: Mika Westerberg <[email protected]> Signed-off-by: Bob Moore <[email protected]> Signed-off-by: Lv Zheng <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2014-09-01Merge branch 'irq-urgent-for-linus' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq handling fixlet from Thomas Gleixner: "Just an export for an interrupt flow handler which is now used in gpio modules" * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irq: Export handle_fasteoi_irq
2014-09-01ASoC: simple-card: Fix bug of wrong decrement DT node's refcountXiubo Li1-0/+8
DAI links's cpu_of_node's and codec_of_node's refcounts shouldn't be decremented immediately at the end of the probe() fucntion. Because we will still use them before the audio card is removed. Signed-off-by: Xiubo Li <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2014-09-01Revert "arm64: cpuinfo: print info for all CPUs"Will Deacon1-18/+22
It turns out that vendors are relying on the format of /proc/cpuinfo, and we've even spotted out-of-tree hacks attempting to make it look identical to the format used by arch/arm/. That means we can't afford to churn this interface in mainline, so revert the recent reformatting of the file for arm64 pending discussions on the list to find out what people actually want. This reverts commit d7a49086f263164a2c4c178eb76412d48cd671d7. Acked-by: Mark Rutland <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2014-09-01drm/i915: handle G45/GM45 pulse detection connected state.Dave Airlie1-18/+37
In the HPD pulse handler we check for long pulses if the port is actually connected, however we do that for IBX, but we use the pulse handling code on GM45 systems as well, so we need to use a diffent check. This patch refactors the digital port connected check out of the g4x detection path and reuses it in the hpd pulse path. Fixes: http://lkml.kernel.org/r/[email protected] Reported-by: Mike Galbraith <[email protected]> Signed-off-by: Dave Airlie <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Acked-by: Imre Deak <[email protected]> Signed-off-by: Jani Nikula <[email protected]>
2014-09-01ALSA: hda - Fix digital mic on Acer Aspire 3830TGTakashi Iwai1-1/+8
Acer Aspire 3830TG with CX20588 codec has a digital built-in mic that has the same problem like many others, the inverted signal in stereo. Apply the same fixup to this machine, too. Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2014-09-01arm64: fix bug for reloading FPSIMD state after cpu power offLeo Yan1-0/+1
Now arm64 defers reloading FPSIMD state, but this optimization also introduces the bug after cpu resume back from low power mode. The reason is after the cpu has been powered off, s/w need set the cpu's fpsimd_last_state to NULL so that it will force to reload FPSIMD state for the thread, otherwise there has the chance to meet the condition for both the task's fpsimd_state.cpu field contains the id of the current cpu, and the cpu's fpsimd_last_state per-cpu variable points to the task's fpsimd_state, so finally kernel will skip to reload the context during it return back to userland. Acked-by: Ard Biesheuvel <[email protected]> Reviewed-by: Catalin Marinas <[email protected]> Signed-off-by: Leo Yan <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2014-09-01drm/vmwgfx: Fix a potential infinite spin waiting for fifo idleThomas Hellstrom1-1/+2
The code waiting for fifo idle was incorrect and could possibly spin forever under certain circumstances. Signed-off-by: Thomas Hellstrom <[email protected]> Reported-by: Mark Sheldon <[email protected]> Reviewed-by: Jakob Bornecrantz <[email protected]> Reivewed-by: Mark Sheldon <[email protected]> Cc: <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.