aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2012-09-19Merge tag 'rpmsg-3.6-fix' of ↵Linus Torvalds1-3/+3
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg Pull rpmsg fix from Ohad Ben-Cohen: "A quick rpmsg fix from Fernando, fixing two buggy invocations of dma_free_coherent" * tag 'rpmsg-3.6-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg: rpmsg: fix dma_free_coherent dev parameter
2012-09-19Merge tag 'md-3.6-fixes' of git://neil.brown.name/mdLinus Torvalds2-2/+10
Pull md fixes from NeilBrown: "3 fixes for md in 3.6. One reverts a recent patch which turns out to not be such a good idea. Other two fix minor bugs with the new (since 3.3) 'replacement' code and have been tagged for -stable." * tag 'md-3.6-fixes' of git://neil.brown.name/md: md: make sure metadata is updated when spares are activated or removed. md/raid5: fix calculate of 'degraded' when a replacement becomes active. Revert "md/raid5: For odirect-write performance, do not set STRIPE_PREREAD_ACTIVE."
2012-09-19Merge branch 'for-3.6-fixes' of ↵Linus Torvalds2-46/+42
git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq Pull workqueue / powernow-k8 fix from Tejun Heo: "This is the fix for the bug where cpufreq/powernow-k8 was tripping BUG_ON() in try_to_wake_up_local() by migrating workqueue worker to a different CPU. https://bugzilla.kernel.org/show_bug.cgi?id=47301 As discussed, the fix is now two parts - one to reimplement work_on_cpu() so that it doesn't create a new kthread each time and the actual fix which makes powernow-k8 use work_on_cpu() instead of performing manual migration. While pretty late in the merge cycle, both changes are on the safer side. Jiri and I verified two existing users of work_on_cpu() and Duncan confirmed that the powernow-k8 fix survived about 18 hours of testing." * 'for-3.6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: cpufreq/powernow-k8: workqueue user shouldn't migrate the kworker to another CPU workqueue: reimplement work_on_cpu() using system_wq
2012-09-19Revert "input: ab8500-ponkey: Create AB8500 domain IRQ mapping"Dmitry Torokhov1-2/+2
This reverts commit ca3b3faf9bee4dc5df4f10eae2d1e48f7de0a8ad. There was a plan to place ab8500_irq_get_virq() calls in each AB8500 child device prior to requesting an IRQ, but as we're no longer using Device Tree to collect our IRQ numbers, it's actually better to allow the core to do this during device registration time. So the IRQ number we pull from its resource has already been converted to a virtual IRQ. Signed-off-by: Lee Jones <[email protected]> Acked-by: Linus Walleij <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
2012-09-19Merge tag 'v3.6-rc5' into for-linusDmitry Torokhov8163-201037/+469646
Sync with mainline so that I can revert an input patch that came in through another subsystem tree.
2012-09-19cpufreq/powernow-k8: workqueue user shouldn't migrate the kworker to another CPUTejun Heo1-29/+34
powernowk8_target() runs off a per-cpu work item and if the cpufreq_policy->cpu is different from the current one, it migrates the kworker to the target CPU by manipulating current->cpus_allowed. The function migrates the kworker back to the original CPU but this is still broken. Workqueue concurrency management requires the kworkers to stay on the same CPU and powernowk8_target() ends up triggerring BUG_ON(rq != this_rq()) in try_to_wake_up_local() if it contends on fidvid_mutex and sleeps. It is unclear why this bug is being reported now. Duncan says it appeared to be a regression of 3.6-rc1 and couldn't reproduce it on 3.5. Bisection seemed to point to 63d95a91 "workqueue: use @pool instead of @gcwq or @cpu where applicable" which is an non-functional change. Given that the reproduce case sometimes took upto days to trigger, it's easy to be misled while bisecting. Maybe something made contention on fidvid_mutex more likely? I don't know. This patch fixes the bug by using work_on_cpu() instead if @pol->cpu isn't the same as the current one. The code assumes that cpufreq_policy->cpu is kept online by the caller, which Rafael tells me is the case. stable: ed48ece27c ("workqueue: reimplement work_on_cpu() using system_wq") should be applied before this; otherwise, the behavior could be horrible. Signed-off-by: Tejun Heo <[email protected]> Reported-by: Duncan <[email protected]> Tested-by: Duncan <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Cc: Andreas Herrmann <[email protected]> Cc: [email protected] Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47301
2012-09-19workqueue: reimplement work_on_cpu() using system_wqTejun Heo1-17/+8
The existing work_on_cpu() implementation is hugely inefficient. It creates a new kthread, execute that single function and then let the kthread die on each invocation. Now that system_wq can handle concurrent executions, there's no advantage of doing this. Reimplement work_on_cpu() using system_wq which makes it simpler and way more efficient. stable: While this isn't a fix in itself, it's needed to fix a workqueue related bug in cpufreq/powernow-k8. AFAICS, this shouldn't break other existing users. Signed-off-by: Tejun Heo <[email protected]> Acked-by: Jiri Kosina <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Bjorn Helgaas <[email protected]> Cc: Len Brown <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Cc: [email protected]
2012-09-19perf/x86: Fix Intel Ivy Bridge supportStephane Eranian3-1/+39
This patch updates the existing Intel IvyBridge (model 58) support with proper PEBS event constraints. It cannot reuse the same as SandyBridge because some events (0xd3) are specific to IvyBridge. Also there is no UOPS_DISPATCHED.THREAD on IVB, so do not populate the PERF_COUNT_HW_STALLED_CYCLES_BACKEND mapping. Signed-off-by: Stephane Eranian <[email protected]> Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/20120910230701.GA5898@quad Signed-off-by: Ingo Molnar <[email protected]>
2012-09-19linux/kernel.h: Fix warning seen with W=1 due to change in DIV_ROUND_CLOSESTGuenter Roeck1-1/+1
After commit b6d86d3d (Fix DIV_ROUND_CLOSEST to support negative dividends), the following warning is seen if the kernel is compiled with W=1 (-Wextra): warning: comparison of unsigned expression >= 0 is always true The warning is due to the test '((typeof(x))-1) >= 0', which is used to detect if the variable type is unsigned. Research on the web suggests that the warning disappears if '>' instead of '>=' is used for the comparison. Tests after changing the macro along that line show that the warning is gone, and that the result is still correct: i=-4: DIV_ROUND_CLOSEST(i, 2)=-2 i=-3: DIV_ROUND_CLOSEST(i, 2)=-2 i=-2: DIV_ROUND_CLOSEST(i, 2)=-1 i=-1: DIV_ROUND_CLOSEST(i, 2)=-1 i=0: DIV_ROUND_CLOSEST(i, 2)=0 i=1: DIV_ROUND_CLOSEST(i, 2)=1 i=2: DIV_ROUND_CLOSEST(i, 2)=1 i=3: DIV_ROUND_CLOSEST(i, 2)=2 i=4: DIV_ROUND_CLOSEST(i, 2)=2 Code size is the same as before. Signed-off-by: Guenter Roeck <[email protected]> Tested-by: Mauro Carvalho Chehab <[email protected]> Acked-by: Jean Delvare <[email protected]>
2012-09-19md: make sure metadata is updated when spares are activated or removed.NeilBrown1-1/+5
It isn't always necessary to update the metadata when spares are removed as the presence-or-not of a spare isn't really important to the integrity of an array. Also activating a spare doesn't always require updating the metadata as the update on 'recovery-completed' is usually sufficient. However the introduction of 'replacement' devices have made these transitions sometimes more important. For example the 'Replacement' flag isn't cleared until the original device is removed, so we need to ensure a metadata update after that 'spare' is removed. So set MD_CHANGE_DEVS whenever a spare is activated or removed, to complement the current situation where it is set when a spare is added or a device is failed (or a number of other less common situations). This is suitable for -stable as out-of-data metadata could lead to data corruption. This is only relevant for 3.3 and later 9when 'replacement' as introduced. Cc: [email protected] Signed-off-by: NeilBrown <[email protected]>
2012-09-19md/raid5: fix calculate of 'degraded' when a replacement becomes active.NeilBrown1-0/+4
When a replacement device becomes active, we mark the device that it replaces as 'faulty' so that it can subsequently get removed. However 'calc_degraded' only pays attention to the primary device, not the replacement, so the array appears to become degraded, which is wrong. So teach 'calc_degraded' to consider any replacement if a primary device is faulty. This is suitable for -stable as an incorrect 'degraded' value can confuse md and could lead to data corruption. This is only relevant for 3.3 and later. Cc: [email protected] Reported-by: Robin Hill <[email protected]> Reported-by: John Drescher <[email protected]> Signed-off-by: NeilBrown <[email protected]>
2012-09-19Revert "md/raid5: For odirect-write performance, do not set ↵NeilBrown1-1/+1
STRIPE_PREREAD_ACTIVE." This reverts commit 895e3c5c58a80bb9e4e05d9ac38b4f30e0f97d80. While this patch seemed like a good idea and did help some workloads, it hurts other workloads. Large sequential O_DIRECT writes were faster, Small random O_DIRECT writes were slower. Other changes (batching RAID5 writes) have improved the sequential writes using a different mechanism, so the net result of this patch is definitely negative. So revert it. Reported-by: Shaohua Li <[email protected]> Tested-by: Jianpeng Ma <[email protected]> Signed-off-by: NeilBrown <[email protected]>
2012-09-18iwlwifi: don't double free the interrupt in failure pathEmmanuel Grumbach1-0/+1
When the driver can't get the HW ready, we would release the interrupt twice which made the kernel complain loudly. Cc: [email protected] Reported-by: Brian Cockrell <[email protected]> Tested-by: Brian Cockrell <[email protected]> Signed-off-by: Emmanuel Grumbach <[email protected]> Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2012-09-18cfg80211: fix possible circular lock on reg_regdb_search()Luis R. Rodriguez1-3/+9
When call_crda() is called we kick off a witch hunt search for the same regulatory domain on our internal regulatory database and that work gets kicked off on a workqueue, this is done while the cfg80211_mutex is held. If that workqueue kicks off it will first lock reg_regdb_search_mutex and later cfg80211_mutex but to ensure two CPUs will not contend against cfg80211_mutex the right thing to do is to have the reg_regdb_search() wait until the cfg80211_mutex is let go. The lockdep report is pasted below. cfg80211: Calling CRDA to update world regulatory domain ====================================================== [ INFO: possible circular locking dependency detected ] 3.3.8 #3 Tainted: G O ------------------------------------------------------- kworker/0:1/235 is trying to acquire lock: (cfg80211_mutex){+.+...}, at: [<816468a4>] set_regdom+0x78c/0x808 [cfg80211] but task is already holding lock: (reg_regdb_search_mutex){+.+...}, at: [<81646828>] set_regdom+0x710/0x808 [cfg80211] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (reg_regdb_search_mutex){+.+...}: [<800a8384>] lock_acquire+0x60/0x88 [<802950a8>] mutex_lock_nested+0x54/0x31c [<81645778>] is_world_regdom+0x9f8/0xc74 [cfg80211] -> #1 (reg_mutex#2){+.+...}: [<800a8384>] lock_acquire+0x60/0x88 [<802950a8>] mutex_lock_nested+0x54/0x31c [<8164539c>] is_world_regdom+0x61c/0xc74 [cfg80211] -> #0 (cfg80211_mutex){+.+...}: [<800a77b8>] __lock_acquire+0x10d4/0x17bc [<800a8384>] lock_acquire+0x60/0x88 [<802950a8>] mutex_lock_nested+0x54/0x31c [<816468a4>] set_regdom+0x78c/0x808 [cfg80211] other info that might help us debug this: Chain exists of: cfg80211_mutex --> reg_mutex#2 --> reg_regdb_search_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(reg_regdb_search_mutex); lock(reg_mutex#2); lock(reg_regdb_search_mutex); lock(cfg80211_mutex); *** DEADLOCK *** 3 locks held by kworker/0:1/235: #0: (events){.+.+..}, at: [<80089a00>] process_one_work+0x230/0x460 #1: (reg_regdb_work){+.+...}, at: [<80089a00>] process_one_work+0x230/0x460 #2: (reg_regdb_search_mutex){+.+...}, at: [<81646828>] set_regdom+0x710/0x808 [cfg80211] stack backtrace: Call Trace: [<80290fd4>] dump_stack+0x8/0x34 [<80291bc4>] print_circular_bug+0x2ac/0x2d8 [<800a77b8>] __lock_acquire+0x10d4/0x17bc [<800a8384>] lock_acquire+0x60/0x88 [<802950a8>] mutex_lock_nested+0x54/0x31c [<816468a4>] set_regdom+0x78c/0x808 [cfg80211] Reported-by: Felix Fietkau <[email protected]> Tested-by: Felix Fietkau <[email protected]> Cc: [email protected] Signed-off-by: Luis R. Rodriguez <[email protected]> Reviewed-by: Johannes Berg <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2012-09-18Bluetooth: Fix not removing power_off delayed workVinicius Costa Gomes1-0/+2
For example, when a usb reset is received (I could reproduce it running something very similar to this[1] in a loop) it could be that the device is unregistered while the power_off delayed work is still scheduled to run. Backtrace: WARNING: at lib/debugobjects.c:261 debug_print_object+0x7c/0x8d() Hardware name: To Be Filled By O.E.M. ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x26 Modules linked in: nouveau mxm_wmi btusb wmi bluetooth ttm coretemp drm_kms_helper Pid: 2114, comm: usb-reset Not tainted 3.5.0bt-next #2 Call Trace: [<ffffffff8124cc00>] ? free_obj_work+0x57/0x91 [<ffffffff81058f88>] warn_slowpath_common+0x7e/0x97 [<ffffffff81059035>] warn_slowpath_fmt+0x41/0x43 [<ffffffff8124ccb6>] debug_print_object+0x7c/0x8d [<ffffffff8106e3ec>] ? __queue_work+0x259/0x259 [<ffffffff8124d63e>] ? debug_check_no_obj_freed+0x6f/0x1b5 [<ffffffff8124d667>] debug_check_no_obj_freed+0x98/0x1b5 [<ffffffffa00aa031>] ? bt_host_release+0x10/0x1e [bluetooth] [<ffffffff810fc035>] kfree+0x90/0xe6 [<ffffffffa00aa031>] bt_host_release+0x10/0x1e [bluetooth] [<ffffffff812ec2f9>] device_release+0x4a/0x7e [<ffffffff8123ef57>] kobject_release+0x11d/0x154 [<ffffffff8123ed98>] kobject_put+0x4a/0x4f [<ffffffff812ec0d9>] put_device+0x12/0x14 [<ffffffffa009472b>] hci_free_dev+0x22/0x26 [bluetooth] [<ffffffffa0280dd0>] btusb_disconnect+0x96/0x9f [btusb] [<ffffffff813581b4>] usb_unbind_interface+0x57/0x106 [<ffffffff812ef988>] __device_release_driver+0x83/0xd6 [<ffffffff812ef9fb>] device_release_driver+0x20/0x2d [<ffffffff813582a7>] usb_driver_release_interface+0x44/0x7b [<ffffffff81358795>] usb_forced_unbind_intf+0x45/0x4e [<ffffffff8134f959>] usb_reset_device+0xa6/0x12e [<ffffffff8135df86>] usbdev_do_ioctl+0x319/0xe20 [<ffffffff81203244>] ? avc_has_perm_flags+0xc9/0x12e [<ffffffff812031a0>] ? avc_has_perm_flags+0x25/0x12e [<ffffffff81050101>] ? do_page_fault+0x31e/0x3a1 [<ffffffff8135eaa6>] usbdev_ioctl+0x9/0xd [<ffffffff811126b1>] vfs_ioctl+0x21/0x34 [<ffffffff81112f7b>] do_vfs_ioctl+0x408/0x44b [<ffffffff81208d45>] ? file_has_perm+0x76/0x81 [<ffffffff8111300f>] sys_ioctl+0x51/0x76 [<ffffffff8158db22>] system_call_fastpath+0x16/0x1b [1] http://cpansearch.perl.org/src/DPAVLIN/Biblio-RFID-0.03/examples/usbreset.c Signed-off-by: Vinicius Costa Gomes <[email protected]> Cc: [email protected] Signed-off-by: Gustavo Padovan <[email protected]>
2012-09-18Bluetooth: Fix freeing uninitialized delayed worksAndrei Emeltchenko1-1/+1
When releasing L2CAP socket which is in BT_CONFIG state l2cap_chan_close invokes l2cap_send_disconn_req which cancel delayed works which are only set in BT_CONNECTED state with l2cap_ertm_init. Add state check before cancelling those works. ... [ 9668.574372] [21085] l2cap_sock_release: sock cd065200, sk f073e800 [ 9668.574399] [21085] l2cap_sock_shutdown: sock cd065200, sk f073e800 [ 9668.574411] [21085] l2cap_chan_close: chan f073ec00 state BT_CONFIG sk f073e800 [ 9668.574421] [21085] l2cap_send_disconn_req: chan f073ec00 conn ecc16600 [ 9668.574441] INFO: trying to register non-static key. [ 9668.574443] the code is fine but needs lockdep annotation. [ 9668.574446] turning off the locking correctness validator. [ 9668.574450] Pid: 21085, comm: obex-client Tainted: G O 3.5.0+ #57 [ 9668.574452] Call Trace: [ 9668.574463] [<c10a64b3>] __lock_acquire+0x12e3/0x1700 [ 9668.574468] [<c10a44fb>] ? trace_hardirqs_on+0xb/0x10 [ 9668.574476] [<c15e4f60>] ? printk+0x4d/0x4f [ 9668.574479] [<c10a6e38>] lock_acquire+0x88/0x130 [ 9668.574487] [<c1059740>] ? try_to_del_timer_sync+0x60/0x60 [ 9668.574491] [<c1059790>] del_timer_sync+0x50/0xc0 [ 9668.574495] [<c1059740>] ? try_to_del_timer_sync+0x60/0x60 [ 9668.574515] [<f8aa1c23>] l2cap_send_disconn_req+0xe3/0x160 [bluetooth] ... Signed-off-by: Andrei Emeltchenko <[email protected]> Signed-off-by: Gustavo Padovan <[email protected]>
2012-09-18Bluetooth: mgmt: Fix enabling LE while powered offAndrzej Kaczmarek1-0/+10
When new BT USB adapter is plugged in it's configured while still being powered off (HCI_AUTO_OFF flag is set), thus Set LE will only set dev_flags but won't write changes to controller. As a result it's not possible to start device discovery session on LE controller as it uses interleaved discovery which requires LE Supported Host flag in extended features. This patch ensures HCI Write LE Host Supported is sent when Set Powered is called to power on controller and clear HCI_AUTO_OFF flag. Signed-off-by: Andrzej Kaczmarek <[email protected]> Cc: [email protected] Acked-by: Johan Hedberg <[email protected]> Signed-off-by: Gustavo Padovan <[email protected]>
2012-09-18Bluetooth: mgmt: Fix enabling SSP while powered offAndrzej Kaczmarek1-0/+6
When new BT USB adapter is plugged in it's configured while still being powered off (HCI_AUTO_OFF flag is set), thus Set SSP will only set dev_flags but won't write changes to controller. As a result remote devices won't use Secure Simple Pairing with our device due to SSP Host Support flag disabled in extended features and may also reject SSP attempt from our side (with possible fallback to legacy pairing). This patch ensures HCI Write Simple Pairing Mode is sent when Set Powered is called to power on controller and clear HCI_AUTO_OFF flag. Signed-off-by: Andrzej Kaczmarek <[email protected]> Cc: [email protected] Acked-by: Johan Hedberg <[email protected]> Signed-off-by: Gustavo Padovan <[email protected]>
2012-09-18xfs: stop the sync worker before xfs_unmountfsBen Myers1-0/+1
Cancel work of the xfs_sync_worker before teardown of the log in xfs_unmountfs. This prevents occasional crashes on unmount like so: PID: 21602 TASK: ee9df060 CPU: 0 COMMAND: "kworker/0:3" #0 [c5377d28] crash_kexec at c0292c94 #1 [c5377d80] oops_end at c07090c2 #2 [c5377d98] no_context at c06f614e #3 [c5377dbc] __bad_area_nosemaphore at c06f6281 #4 [c5377df4] bad_area_nosemaphore at c06f629b #5 [c5377e00] do_page_fault at c070b0cb #6 [c5377e7c] error_code (via page_fault) at c070892c EAX: f300c6a8 EBX: f300c6a8 ECX: 000000c0 EDX: 000000c0 EBP: c5377ed0 DS: 007b ESI: 00000000 ES: 007b EDI: 00000001 GS: ffffad20 CS: 0060 EIP: c0481ad0 ERR: ffffffff EFLAGS: 00010246 #7 [c5377eb0] atomic64_read_cx8 at c0481ad0 #8 [c5377ebc] xlog_assign_tail_lsn_locked at f7cc7c6e [xfs] #9 [c5377ed4] xfs_trans_ail_delete_bulk at f7ccd520 [xfs] #10 [c5377f0c] xfs_buf_iodone at f7ccb602 [xfs] #11 [c5377f24] xfs_buf_do_callbacks at f7cca524 [xfs] #12 [c5377f30] xfs_buf_iodone_callbacks at f7cca5da [xfs] #13 [c5377f4c] xfs_buf_iodone_work at f7c718d0 [xfs] #14 [c5377f58] process_one_work at c024ee4c #15 [c5377f98] worker_thread at c024f43d #16 [c5377fbc] kthread at c025326b #17 [c5377fe8] kernel_thread_helper at c070e834 PID: 26653 TASK: e79143b0 CPU: 3 COMMAND: "umount" #0 [cde0fda0] __schedule at c0706595 #1 [cde0fe28] schedule at c0706b89 #2 [cde0fe30] schedule_timeout at c0705600 #3 [cde0fe94] __down_common at c0706098 #4 [cde0fec8] __down at c0706122 #5 [cde0fed0] down at c025936f #6 [cde0fee0] xfs_buf_lock at f7c7131d [xfs] #7 [cde0ff00] xfs_freesb at f7cc2236 [xfs] #8 [cde0ff10] xfs_fs_put_super at f7c80f21 [xfs] #9 [cde0ff1c] generic_shutdown_super at c0333d7a #10 [cde0ff38] kill_block_super at c0333e0f #11 [cde0ff48] deactivate_locked_super at c0334218 #12 [cde0ff58] deactivate_super at c033495d #13 [cde0ff68] mntput_no_expire at c034bc13 #14 [cde0ff7c] sys_umount at c034cc69 #15 [cde0ffa0] sys_oldumount at c034ccd4 #16 [cde0ffb0] system_call at c0707e66 commit 11159a05 added this to xfs_log_unmount and needs to be cleaned up at a later date. Signed-off-by: Ben Myers <[email protected]> Reviewed-by: Dave Chinner <[email protected]> Reviewed-by: Mark Tinguely <[email protected]>
2012-09-18cifs: fix return value in cifsConvertToUTF16Jeff Layton1-1/+1
This function returns the wrong value, which causes the callers to get the length of the resulting pathname wrong when it contains non-ASCII characters. This seems to fix https://bugzilla.samba.org/show_bug.cgi?id=6767 Cc: <[email protected]> Reported-by: Baldvin Kovacs <[email protected]> Reported-and-Tested-by: Nicolas Lefebvre <[email protected]> Signed-off-by: Jeff Layton <[email protected]> Signed-off-by: Steve French <[email protected]>
2012-09-18e1000: Small packets may get corrupted during padding by HWTushar Dave1-0/+11
On PCI/PCI-X HW, if packet size is less than ETH_ZLEN, packets may get corrupted during padding by HW. To WA this issue, pad all small packets manually. Signed-off-by: Tushar Dave <[email protected]> Tested-by: Aaron Brown <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-09-18xfrm: fix a read lock imbalance in make_blackholeLi RongQing1-1/+1
if xfrm_policy_get_afinfo returns 0, it has already released the read lock, xfrm_policy_put_afinfo should not be called again. Signed-off-by: Li RongQing <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-09-18tcp: fix regression in urgent data handlingEric Dumazet1-3/+2
Stephan Springl found that commit 1402d366019fed "tcp: introduce tcp_try_coalesce" introduced a regression for rlogin It turns out problem comes from TCP urgent data handling and a change in behavior in input path. rlogin sends two one-byte packets with URG ptr set, and when next data frame is coalesced, we lack sk_data_ready() calls to wakeup consumer. Signed-off-by: Eric Dumazet <[email protected]> Reported-by: Stephan Springl <[email protected]> Cc: Alexander Duyck <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-09-18net: fix memory leak on oom with zerocopyMichael S. Tsirkin1-1/+1
If orphan flags fails, we don't free the skb on receive, which leaks the skb memory. Return value was also wrong: netif_receive_skb is supposed to return NET_RX_DROP, not ENOMEM. Signed-off-by: Michael S. Tsirkin <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-09-18netxen: check for root bus in netxen_mask_aer_correctableNikolay Aleksandrov1-0/+4
Add a check if pdev->bus->self == NULL (root bus). When attaching a netxen NIC to a VM it can be on the root bus and the guest would crash in netxen_mask_aer_correctable() because of a NULL pointer dereference if CONFIG_PCIEAER is present. Signed-off-by: Nikolay Aleksandrov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-09-18hwmon: (applesmc) Bump max waitParag Warudkar1-2/+2
A heavy-load test on a MacBookPro6,1 is still showing a substantial amount of read errors. Increasing the maximum wait time to 128 ms resolves the issue. Signed-off-by: Parag Warudkar <[email protected]> Signed-off-by: Henrik Rydberg <[email protected]> Signed-off-by: Guenter Roeck <[email protected]>
2012-09-18hwmon: (ad7314) Add 'name' sysfs attributeGuenter Roeck1-0/+8
The 'name' sysfs attribute is mandatory for hwmon devices, but was missing in this driver. Cc: Jonathan Cameron <[email protected]> Cc: [email protected] Signed-off-by: Guenter Roeck <[email protected]> Acked-by: Jean Delvare <[email protected]> Acked-by: Jonathan Cameron <[email protected]>
2012-09-18bnx2x: fix rx checksum validation for IPv6Michal Schmidt1-5/+7
Commit d6cb3e41 "bnx2x: fix checksum validation" caused a performance regression for IPv6. Rx checksum offload does not work. IPv6 packets are passed to the stack with CHECKSUM_NONE. The hardware obviously cannot perform IP checksum validation for IPv6, because there is no checksum in the IPv6 header. This should not prevent us from setting CHECKSUM_UNNECESSARY. Tested on BCM57711. Signed-off-by: Michal Schmidt <[email protected]> Acked-by: Eric Dumazet <[email protected]> Acked-by: Eilon Greenstein <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-09-18xfrm_user: return error pointer instead of NULL #2Mathias Krause1-2/+4
When dump_one_policy() returns an error, e.g. because of a too small buffer to dump the whole xfrm policy, xfrm_policy_netlink() returns NULL instead of an error pointer. But its caller expects an error pointer and therefore continues to operate on a NULL skbuff. Signed-off-by: Mathias Krause <[email protected]> Acked-by: Steffen Klassert <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-09-18xfrm_user: return error pointer instead of NULLMathias Krause1-2/+4
When dump_one_state() returns an error, e.g. because of a too small buffer to dump the whole xfrm state, xfrm_state_netlink() returns NULL instead of an error pointer. But its callers expect an error pointer and therefore continue to operate on a NULL skbuff. This could lead to a privilege escalation (execution of user code in kernel context) if the attacker has CAP_NET_ADMIN and is able to map address 0. Signed-off-by: Mathias Krause <[email protected]> Acked-by: Steffen Klassert <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-09-18ipv6: use DST_* macro to set obselete fieldNicolas Dichtel1-3/+3
Signed-off-by: Nicolas Dichtel <[email protected]> Acked-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-09-18ipv6: use net->rt_genid to check dst validityNicolas Dichtel3-29/+12
IPv6 dst should take care of rt_genid too. When a xfrm policy is inserted or deleted, all dst should be invalidated. To force the validation, dst entries should be created with ->obsolete set to DST_OBSOLETE_FORCE_CHK. This was already the case for all functions calling ip6_dst_alloc(), except for ip6_rt_copy(). As a consequence, we can remove the specific code in inet6_connection_sock. Signed-off-by: Nicolas Dichtel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-09-18xfrm: invalidate dst on policy insertion/deletionNicolas Dichtel2-0/+2
When a policy is inserted or deleted, all dst should be recalculated. Signed-off-by: Nicolas Dichtel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-09-18netns: move net->ipv4.rt_genid to net->rt_genidNicolas Dichtel3-8/+12
This commit prepares the use of rt_genid by both IPv4 and IPv6. Initialization is left in IPv4 part. Signed-off-by: Nicolas Dichtel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-09-18net: rt_cache_flush() cleanupEric Dumazet1-17/+2
We dont use jhash anymore since route cache removal, so we can get rid of get_random_bytes() calls for rt_genid changes. Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-09-18ipv4/route: arg delay is useless in rt_cache_flush()Nicolas Dichtel7-35/+22
Since route cache deletion (89aef8921bfbac22f), delay is no more used. Remove it. Signed-off-by: Nicolas Dichtel <[email protected]> Acked-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2012-09-18Merge tag 'hwspinlock-3.6-fix' of ↵Linus Torvalds1-1/+2
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock Pull hwspinlock fix from Ohad Ben-Cohen: "A single hwspinlock fix by Wei Yongjun, which prevents potential NULL dereferences" * tag 'hwspinlock-3.6-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock: hwspinlock/core: move the dereference below the NULL test
2012-09-18vfs: dcache: use DCACHE_DENTRY_KILLED instead of DCACHE_DISCONNECTED in d_kill()Miklos Szeredi2-2/+4
IBM reported a soft lockup after applying the fix for the rename_lock deadlock. Commit c83ce989cb5f ("VFS: Fix the nfs sillyrename regression in kernel 2.6.38") was found to be the culprit. The nfs sillyrename fix used DCACHE_DISCONNECTED to indicate that the dentry was killed. This flag can be set on non-killed dentries too, which results in infinite retries when trying to traverse the dentry tree. This patch introduces a separate flag: DCACHE_DENTRY_KILLED, which is only set in d_kill() and makes try_to_ascend() test only this flag. IBM reported successful test results with this patch. Signed-off-by: Miklos Szeredi <[email protected]> Cc: Trond Myklebust <[email protected]> Cc: [email protected] Signed-off-by: Linus Torvalds <[email protected]>
2012-09-18Merge tag 'imx-fixes' of git://git.pengutronix.de/git/imx/linux-2.6 into fixesOlof Johansson3-2/+4
From Sascha Hauer: ARM i.MX: Two fixes for i.MX - armadillo5x0 board broken since v3.5 (stable material) - i.MX25 Architecture broken since v3.6-rc1 * tag 'imx-fixes' of git://git.pengutronix.de/git/imx/linux-2.6: ARM i.MX25: Make timer irq work again ARM: imx: armadillo5x0: Fix illegal register access
2012-09-18ARM i.MX25: Make timer irq work againSascha Hauer2-1/+2
Since i.MX has SPARSE_IRQ enabled the i.MX25 timer is broken. This is because the internal irqs now start at an offset of NR_IRQS_LEGACY. The patch fixed this up, but missed the i.MX25 timer which used a hardcoded value instead of a define. This patch introduces a define for the timer irq and uses it. This is broken since introduced with 3.6-rc1: | commit 8842a9e2869cae14bbb8184004a42fc3070587fb | Author: Shawn Guo <[email protected]> | Date: Thu Jun 14 11:16:14 2012 +0800 | | ARM: imx: enable SPARSE_IRQ for imx platform Signed-off-by: Sascha Hauer <[email protected]> Acked-by: Shawn Guo <[email protected]>
2012-09-18ARM: imx: armadillo5x0: Fix illegal register accessFabio Estevam1-1/+2
Since commit eb92044eb (ARM i.MX3: Make ccm base address a variable ) it is necessary to pass the CCM register base as a variable. Fix the CCM register access in mach-armadillo5x0 by passing mx3_ccm_base and avoid illegal accesses. Also applies to v3.5 Reported-by: Arnd Bergmann <[email protected]> Signed-off-by: Fabio Estevam <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: Sascha Hauer <[email protected]> Cc: [email protected]
2012-09-18Merge tag 'at91-fixes' of git://github.com/at91linux/linux-at91 into fixesOlof Johansson5-0/+21
From Nicolas Ferre: Modify AT91 device tree files for making the GPIO interrupts work. * tag 'at91-fixes' of git://github.com/at91linux/linux-at91: ARM: at91: fix missing #interrupt-cells on gpio-controller
2012-09-18Merge branch 'fixes' of ↵Olof Johansson1-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas: ARM: shmobile: kzm9g: bugfix: correct mmcif interrupt settings
2012-09-18Merge branch 'v3.6-samsung-fixes-3' of ↵Olof Johansson1-4/+6
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into fixes * 'v3.6-samsung-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung: ARM: SAMSUNG: Use spin_lock_{irqsave,irqrestore} in clk_set_rate ARM: SAMSUNG: use spin_lock_irqsave() in clk_set_parent
2012-09-18[SCSI] hpsa: fix handling of protocol errorStephen M. Cameron1-1/+2
If a command status of CMD_PROTOCOL_ERR is received, this information should be conveyed to the SCSI mid layer, not dropped on the floor. CMD_PROTOCOL_ERR may be received from the Smart Array for any commands destined for an external RAID controller such as a P2000, or commands destined for tape drives or CD/DVD-ROM drives, if for instance a cable is disconnected. This mostly affects multipath configurations, as disconnecting a cable on a non-multipath configuration is not going to do anything good regardless of whether CMD_PROTOCOL_ERR is handled correctly or not. Not handling CMD_PROTOCOL_ERR correctly in a multipath configaration involving external RAID controllers may cause data corruption, so this is quite a serious bug. This bug should not normally cause a problem for direct attached disk storage. Signed-off-by: Stephen M. Cameron <[email protected]> Cc: [email protected] Signed-off-by: James Bottomley <[email protected]>
2012-09-18cciss: fix handling of protocol errorStephen M. Cameron1-0/+1
If a command completes with a status of CMD_PROTOCOL_ERR, this information should be conveyed to the SCSI mid layer, not dropped on the floor. Unlike a similar bug in the hpsa driver, this bug only affects tape drives and CD and DVD ROM drives in the cciss driver, and to induce it, you have to disconnect (or damage) a cable, so it is not a very likely scenario (which would explain why the bug has gone undetected for the last 10 years.) Signed-off-by: Stephen M. Cameron <[email protected]> Cc: [email protected] Signed-off-by: Jens Axboe <[email protected]>
2012-09-18blk: add an upper sanity check on partition addingAlan Cox1-1/+1
65536 should be ludicrous anyway but without it we overflow the memory computation doing the allocation and badness occurs. Signed-off-by: Alan Cox <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2012-09-18sh: Fix up TIF_NOTIFY_RESUME sans TIF_SIGPENDING handling.Al Viro2-2/+2
As Al notes, we missed a TIF_NOTIFY_RESUME check which caused any handlers without TIF_SIGPENDING also set to skip the notification: Looks like while it is in the relevant masks *and* checked in do_notify_resume() both on 32bit and 64bit variants since commit ab99c733ae73cce31f2a2434f7099564e5a73d95 ("sh: Make syscall tracer use tracehook notifiers, add TIF_NOTIFY_RESUME.") they are actually *not* reached without simulataneous SIGPENDING, since the actual glue in the callers had not been updated back then and still checks for _TIF_SIGPENDING alone when deciding whether to hit do_notify_resume() or not. Reported-by: Nobuhiro Iwamatsu <[email protected]> Signed-off-by: Al Viro <[email protected]> Tested-by: Nobuhiro Iwamatsu <[email protected]> Signed-off-by: Paul Mundt <[email protected]>
2012-09-18sh: pfc: Release spinlock in sh_pfc_gpio_request_enable() error pathLaurent Pinchart1-1/+2
The sh_pfc_gpio_request_enable() function acquires a spinlock but fails to release it before returning if the requested mux type is not supported. Fix this. Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Paul Mundt <[email protected]>
2012-09-18DMA: PL330: Check the pointer returned by kzallocSachin Kamat1-0/+5
kzalloc could return NULL. Hence add a check to avoid NULL pointer dereference. Signed-off-by: Sachin Kamat <[email protected]> Acked-by: Jassi Brar <[email protected]> Cc: Stable <[email protected]> Signed-off-by: Vinod Koul <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.