AgeCommit message (Collapse)AuthorFilesLines
2013-06-20Linux 3.4.50v3.4.50Greg Kroah-Hartman1-1/+1
2013-06-20powerpc: Fix missing/delayed calls to irq_workBenjamin Herrenschmidt1-1/+1
commit 230b3034793247f61e6a0b08c44cf415f6d92981 upstream. When replaying interrupts (as a result of the interrupt occurring while soft-disabled), in the case of the decrementer, we are exclusively testing for a pending timer target. However we also use decrementer interrupts to trigger the new "irq_work", which in this case would be missed. This change the logic to force a replay in both cases of a timer boundary reached and a decrementer interrupt having actually occurred while disabled. The former test is still useful to catch cases where a CPU having been hard-disabled for a long time completely misses the interrupt due to a decrementer rollover. Signed-off-by: Benjamin Herrenschmidt <> Tested-by: Steven Rostedt <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-20powerpc: Fix stack overflow crash in resume_kernel when ftracingMichael Ellerman2-3/+3
commit 0e37739b1c96d65e6433998454985de994383019 upstream. It's possible for us to crash when running with ftrace enabled, eg: Bad kernel stack pointer bffffd12 at c00000000000a454 cpu 0x3: Vector: 300 (Data Access) at [c00000000ffe3d40] pc: c00000000000a454: resume_kernel+0x34/0x60 lr: c00000000000335c: performance_monitor_common+0x15c/0x180 sp: bffffd12 msr: 8000000000001032 dar: bffffd12 dsisr: 42000000 If we look at current's stack (paca->__current->stack) we see it is equal to c0000002ecab0000. Our stack is 16K, and comparing to paca->kstack (c0000002ecab3e30) we can see that we have overflowed our kernel stack. This leads to us writing over our struct thread_info, and in this case we have corrupted thread_info->flags and set _TIF_EMULATE_STACK_STORE. Dumping the stack we see: 3:mon> t c0000002ecab0000 [c0000002ecab0000] c00000000002131c .performance_monitor_exception+0x5c/0x70 [c0000002ecab0080] c00000000000335c performance_monitor_common+0x15c/0x180 --- Exception: f01 (Performance Monitor) at c0000000000fb2ec .trace_hardirqs_off+0x1c/0x30 [c0000002ecab0370] c00000000016fdb0 .trace_graph_entry+0xb0/0x280 (unreliable) [c0000002ecab0410] c00000000003d038 .prepare_ftrace_return+0x98/0x130 [c0000002ecab04b0] c00000000000a920 .ftrace_graph_caller+0x14/0x28 [c0000002ecab0520] c0000000000d6b58 .idle_cpu+0x18/0x90 [c0000002ecab05a0] c00000000000a934 .return_to_handler+0x0/0x34 [c0000002ecab0620] c00000000001e660 .timer_interrupt+0x160/0x300 [c0000002ecab06d0] c0000000000025dc decrementer_common+0x15c/0x180 --- Exception: 901 (Decrementer) at c0000000000104d4 .arch_local_irq_restore+0x74/0xa0 [c0000002ecab09c0] c0000000000fe044 .trace_hardirqs_on+0x14/0x30 (unreliable) [c0000002ecab0fb0] c00000000016fe3c .trace_graph_entry+0x13c/0x280 [c0000002ecab1050] c00000000003d038 .prepare_ftrace_return+0x98/0x130 [c0000002ecab10f0] c00000000000a920 .ftrace_graph_caller+0x14/0x28 [c0000002ecab1160] c0000000000161f0 .__ppc64_runlatch_on+0x10/0x40 [c0000002ecab11d0] c00000000000a934 .return_to_handler+0x0/0x34 --- Exception: 901 (Decrementer) at c0000000000104d4 .arch_local_irq_restore+0x74/0xa0 ... and so on __ppc64_runlatch_on() is called from RUNLATCH_ON in the exception entry path. At that point the irq state is not consistent, ie. interrupts are hard disabled (by the exception entry), but the paca soft-enabled flag may be out of sync. This leads to the local_irq_restore() in trace_graph_entry() actually enabling interrupts, which we do not want. Because we have not yet reprogrammed the decrementer we immediately take another decrementer exception, and recurse. The fix is twofold. Firstly make sure we call DISABLE_INTS before calling RUNLATCH_ON. The badly named DISABLE_INTS actually reconciles the irq state in the paca with the hardware, making it safe again to call local_irq_save/restore(). Although that should be sufficient to fix the bug, we also mark the runlatch routines as notrace. They are called very early in the exception entry and we are asking for trouble tracing them. They are also fairly uninteresting and tracing them just adds unnecessary overhead. [ This regression was introduced by fe1952fc0afb9a2e4c79f103c08aef5d13db1873 "powerpc: Rework runlatch code" by myself --BenH ] Signed-off-by: Michael Ellerman <> Signed-off-by: Benjamin Herrenschmidt <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-20ceph: fix statvfs fr_sizeSage Weil2-2/+7
commit 92a49fb0f79f3300e6e50ddf56238e70678e4202 upstream. Different versions of glibc are broken in different ways, but the short of it is that for the time being, frsize should == bsize, and be used as the multiple for the blocks, free, and available fields. This mirrors what is done for NFS. The previous reporting of the page size for frsize meant that newer glibc and df would report a very small value for the fs size. Fixes Signed-off-by: Sage Weil <> Reviewed-by: Greg Farnum <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-20libceph: wrap auth methods in a mutexSage Weil2-22/+58
commit e9966076cdd952e19f2dd4854cd719be0d7cbebc upstream. The auth code is called from a variety of contexts, include the mon_client (protected by the monc's mutex) and the messenger callbacks (currently protected by nothing). Avoid chaos by protecting all auth state with a mutex. Nothing is blocking, so this should be simple and lightweight. Signed-off-by: Sage Weil <> Reviewed-by: Alex Elder <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-20libceph: wrap auth ops in wrapper functionsSage Weil6-36/+84
commit 27859f9773e4a0b2042435b13400ee2c891a61f4 upstream. Use wrapper functions that check whether the auth op exists so that callers do not need a bunch of conditional checks. Simplifies the external interface. Signed-off-by: Sage Weil <> Reviewed-by: Alex Elder <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-20libceph: add update_authorizer auth methodSage Weil5-1/+38
commit 0bed9b5c523d577378b6f83eab5835fe30c27208 upstream. Currently the messenger calls out to a get_authorizer con op, which will create a new authorizer if it doesn't yet have one. In the meantime, when we rotate our service keys, the authorizer doesn't get updated. Eventually it will be rejected by the server on a new connection attempt and get invalidated, and we will then rebuild a new authorizer, but this is not ideal. Instead, if we do have an authorizer, call a new update_authorizer op that will verify that the current authorizer is using the latest secret. If it is not, we will build a new one that does. This avoids the transient failure. This fixes one of the sorry sequence of events for bug Signed-off-by: Sage Weil <> Reviewed-by: Alex Elder <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-20libceph: fix authorizer invalidationSage Weil1-1/+1
commit 4b8e8b5d78b8322351d44487c1b76f7e9d3412bc upstream. We were invalidating the authorizer by removing the ticket handler entirely. This was effective in inducing us to request a new authorizer, but in the meantime it mean that any authorizer we generated would get a new and initialized handler with secret_id=0, which would always be rejected by the server side with a confusing error message: auth: could not find secret_id=0 cephx: verify_authorizer could not get service secret for service osd secret_id=0 Instead, simply clear the validity field. This will still induce the auth code to request a new secret, but will let us continue to use the old ticket in the meantime. The messenger code will probably continue to fail, but the exponential backoff will kick in, and eventually the we will get a new (hopefully more valid) ticket from the mon and be able to continue. Signed-off-by: Sage Weil <> Reviewed-by: Alex Elder <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-20libceph: clear messenger auth_retry flag when we authenticateSage Weil1-2/+1
commit 20e55c4cc758e4dccdfd92ae8e9588dd624b2cd7 upstream. We maintain a counter of failed auth attempts to allow us to retry once before failing. However, if the second attempt succeeds, the flag isn't cleared, which makes us think auth failed again later when the connection resets for other reasons (like a socket error). This is one part of the sorry sequence of events in bug Signed-off-by: Sage Weil <> Reviewed-by: Alex Elder <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-20x86: Fix typo in kexec register clearingKees Cook1-1/+1
commit c8a22d19dd238ede87aa0ac4f7dbea8da039b9c1 upstream. Fixes a typo in register clearing code. Thanks to PaX Team for fixing this originally, and James Troup for pointing it out. Signed-off-by: Kees Cook <> Link: Cc: PaX Team <> Signed-off-by: H. Peter Anvin <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-20mm: migration: add migrate_entry_wait_huge()Naoya Horiguchi3-6/+22
commit 30dad30922ccc733cfdbfe232090cf674dc374dc upstream. When we have a page fault for the address which is backed by a hugepage under migration, the kernel can't wait correctly and do busy looping on hugepage fault until the migration finishes. As a result, users who try to kick hugepage migration (via soft offlining, for example) occasionally experience long delay or soft lockup. This is because pte_offset_map_lock() can't get a correct migration entry or a correct page table lock for hugepage. This patch introduces migration_entry_wait_huge() to solve this. Signed-off-by: Naoya Horiguchi <> Reviewed-by: Rik van Riel <> Reviewed-by: Wanpeng Li <> Reviewed-by: Michal Hocko <> Cc: Mel Gorman <> Cc: Andi Kleen <> Cc: KOSAKI Motohiro <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-20md/raid1: consider WRITE as successful only if at least one non-Faulty and ↵Alex Lyakas2-2/+22
non-rebuilding drive completed it. commit 3056e3aec8d8ba61a0710fb78b2d562600aa2ea7 upstream. Without that fix, the following scenario could happen: - RAID1 with drives A and B; drive B was freshly-added and is rebuilding - Drive A fails - WRITE request arrives to the array. It is failed by drive A, so r1_bio is marked as R1BIO_WriteError, but the rebuilding drive B succeeds in writing it, so the same r1_bio is marked as R1BIO_Uptodate. - r1_bio arrives to handle_write_finished, badblocks are disabled, md_error()->error() does nothing because we don't fail the last drive of raid1 - raid_end_bio_io() calls call_bio_endio() - As a result, in call_bio_endio(): if (!test_bit(R1BIO_Uptodate, &r1_bio->state)) clear_bit(BIO_UPTODATE, &bio->bi_flags); this code doesn't clear the BIO_UPTODATE flag, and the whole master WRITE succeeds, back to the upper layer. So we returned success to the upper layer, even though we had written the data onto the rebuilding drive only. But when we want to read the data back, we would not read from the rebuilding drive, so this data is lost. [neilb - applied identical change to raid10 as well] This bug can result in lost data, so it is suitable for any -stable kernel. Signed-off-by: Alex Lyakas <> Signed-off-by: NeilBrown <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-20swap: avoid read_swap_cache_async() race to deadlock while waiting on ↵Rafael Aquini1-1/+17
discard I/O completion commit cbab0e4eec299e9059199ebe6daf48730be46d2b upstream. read_swap_cache_async() can race against get_swap_page(), and stumble across a SWAP_HAS_CACHE entry in the swap map whose page wasn't brought into the swapcache yet. This transient swap_map state is expected to be transitory, but the actual placement of discard at scan_swap_map() inserts a wait for I/O completion thus making the thread at read_swap_cache_async() to loop around its -EEXIST case, while the other end at get_swap_page() is scheduled away at scan_swap_map(). This can leave the system deadlocked if the I/O completion happens to be waiting on the CPU waitqueue where read_swap_cache_async() is busy looping and !CONFIG_PREEMPT. This patch introduces a cond_resched() call to make the aforementioned read_swap_cache_async() busy loop condition to bail out when necessary, thus avoiding the subtle race window. Signed-off-by: Rafael Aquini <> Acked-by: Johannes Weiner <> Acked-by: KOSAKI Motohiro <> Acked-by: Hugh Dickins <> Cc: Shaohua Li <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-20drm/i915: prefer VBT modes for SVDO-LVDS over EDIDDaniel Vetter1-4/+6
commit c3456fb3e4712d0448592af3c5d644c9472cd3c1 upstream. In commit 53d3b4d7778daf15900867336c85d3f8dd70600c Author: Egbert Eich <> Date: Tue Jun 4 17:13:21 2013 +0200 drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC Egbert Eich fixed a long-standing bug where we simply used a non-working i2c controller to read the EDID for SDVO-LVDS panels. Unfortunately some machines seem to not be able to cope with the mode provided in the EDID. Specifically they seem to not be able to cope with a 4x pixel mutliplier instead of a 2x one, which seems to have been worked around by slightly changing the panels native mode in the VBT so that the dotclock is just barely above 50MHz. Since it took forever to notice the breakage it's fairly safe to assume that at least for SDVO-LVDS panels the VBT contains fairly sane data. So just switch around the order and use VBT modes first. v2: Also add EDID modes just in case, and spell Egbert correctly. v3: Elaborate a bit more about what's going on on Chris' machine. Bugzilla: Reported-and-tested-by: Chris Wilson <> Cc: Egbert Eich <> Signed-off-by: Daniel Vetter <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-20cciss: fix broken mutex usage in ioctlStephen M. Cameron1-16/+16
commit 03f47e888daf56c8e9046c674719a0bcc644eed5 upstream. If a new logical drive is added and the CCISS_REGNEWD ioctl is invoked (as is normal with the Array Configuration Utility) the process will hang as below. It attempts to acquire the same mutex twice, once in do_ioctl() and once in cciss_unlocked_open(). The BKL was recursive, the mutex isn't. Linux version 3.10.0-rc2 (scameron@localhost.localdomain) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) ) #1 SMP Fri May 24 14:32:12 CDT 2013 [...] acu D 0000000000000001 0 3246 3191 0x00000080 Call Trace: schedule+0x29/0x70 schedule_preempt_disabled+0xe/0x10 __mutex_lock_slowpath+0x17b/0x220 mutex_lock+0x2b/0x50 cciss_unlocked_open+0x2f/0x110 [cciss] __blkdev_get+0xd3/0x470 blkdev_get+0x5c/0x1e0 register_disk+0x182/0x1a0 add_disk+0x17c/0x310 cciss_add_disk+0x13a/0x170 [cciss] cciss_update_drive_info+0x39b/0x480 [cciss] rebuild_lun_table+0x258/0x370 [cciss] cciss_ioctl+0x34f/0x470 [cciss] do_ioctl+0x49/0x70 [cciss] __blkdev_driver_ioctl+0x28/0x30 blkdev_ioctl+0x200/0x7b0 block_ioctl+0x3c/0x40 do_vfs_ioctl+0x89/0x350 SyS_ioctl+0xa1/0xb0 system_call_fastpath+0x16/0x1b This mutex usage was added into the ioctl path when the big kernel lock was removed. As it turns out, these paths are all thread safe anyway (or can easily be made so) and we don't want ioctl() to be single threaded in any case. Signed-off-by: Stephen M. Cameron <> Cc: Jens Axboe <> Cc: Mike Miller <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-20reboot: rigrate shutdown/reboot to boot cpuRobin Holt1-3/+26
commit cf7df378aa4ff7da3a44769b7ff6e9eef1a9f3db upstream. We recently noticed that reboot of a 1024 cpu machine takes approx 16 minutes of just stopping the cpus. The slowdown was tracked to commit f96972f2dc63 ("kernel/sys.c: call disable_nonboot_cpus() in kernel_restart()"). The current implementation does all the work of hot removing the cpus before halting the system. We are switching to just migrating to the boot cpu and then continuing with shutdown/reboot. This also has the effect of not breaking x86's command line parameter for specifying the reboot cpu. Note, this code was shamelessly copied from arch/x86/kernel/reboot.c with bits removed pertaining to the reboot_cpu command line parameter. Signed-off-by: Robin Holt <> Tested-by: Shawn Guo <> Cc: "Srivatsa S. Bhat" <> Cc: H. Peter Anvin <> Cc: Thomas Gleixner <> Cc: Ingo Molnar <> Cc: Russ Anderson <> Cc: Robin Holt <> Cc: Russell King <> Cc: Guan Xuetao <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-20CPU hotplug: provide a generic helper to disable/enable CPU hotplugSrivatsa S. Bhat2-32/+27
commit 16e53dbf10a2d7e228709a7286310e629ede5e45 upstream. There are instances in the kernel where we would like to disable CPU hotplug (from sysfs) during some important operation. Today the freezer code depends on this and the code to do it was kinda tailor-made for that. Restructure the code and make it generic enough to be useful for other usecases too. Signed-off-by: Srivatsa S. Bhat <> Signed-off-by: Robin Holt <> Cc: H. Peter Anvin <> Cc: Thomas Gleixner <> Cc: Ingo Molnar <> Cc: Russ Anderson <> Cc: Robin Holt <> Cc: Russell King <> Cc: Guan Xuetao <> Cc: Shawn Guo <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-20ath9k: Use minstrel rate control by defaultSujith Manoharan4-9/+9
commit 5efac94999ff218e0101f67a059e44abb4b0b523 upstream. The ath9k rate control algorithm has various architectural issues that make it a poor fit in scenarios like congested environments etc. An example: Change the default to minstrel which is more robust in such cases. The ath9k RC code is left in the driver for now, maybe it can be removed altogether later on. Signed-off-by: Sujith Manoharan <> Cc: Jouni Malinen <> Cc: Linus Torvalds <> Signed-off-by: John W. Linville <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-20ath9k: Disable PowerSave by defaultSujith Manoharan1-2/+1
commit 531671cb17af07281e6f28c1425f754346e65c41 upstream. Almost all the DMA issues which have plagued ath9k (in station mode) for years are related to PS. Disabling PS usually "fixes" the user's connection stablility. Reports of DMA problems are still trickling in and are sitting in the kernel bugzilla. Until the PS code in ath9k is given a thorough review, disbale it by default. The slight increase in chip power consumption is a small price to pay for improved link stability. Signed-off-by: Sujith Manoharan <> Signed-off-by: John W. Linville <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-20Bluetooth: Fix mgmt handling of power on failuresJohan Hedberg4-1/+28
commit 96570ffcca0b872dc8626e97569d2697f374d868 upstream. If hci_dev_open fails we need to ensure that the corresponding mgmt_set_powered command gets an appropriate response. This patch fixes the missing response by adding a new mgmt_set_powered_failed function that's used to indicate a power on failure to mgmt. Since a situation with the device being rfkilled may require special handling in user space the patch uses a new dedicated mgmt status code for this. Signed-off-by: Johan Hedberg <> Acked-by: Marcel Holtmann <> Signed-off-by: Gustavo Padovan <> Signed-off-by: John W. Linville <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-20drm/gma500/cdv: Unpin framebuffer on crtc disablePatrik Jakobsson1-0/+14
commit 22e7c385a80d771aaf3a15ae7ccea3b0686bbe10 upstream. The framebuffer needs to be unpinned in the crtc->disable callback because of previous pinning in psb_intel_pipe_set_base(). This will fix a memory leak where the framebuffer was released but not unpinned properly. This patch only affects Cedarview. Bugzilla: Bugzilla: Reviewed-by: Daniel Vetter <> Signed-off-by: Patrik Jakobsson <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-20drm/gma500/psb: Unpin framebuffer on crtc disablePatrik Jakobsson1-0/+14
commit 820de86a90089ee607d7864538c98a23b503c846 upstream. The framebuffer needs to be unpinned in the crtc->disable callback because of previous pinning in psb_intel_pipe_set_base(). This will fix a memory leak where the framebuffer was released but not unpinned properly. This patch only affects Poulsbo. Bugzilla: Bugzilla: Reviewed-by: Daniel Vetter <> Signed-off-by: Patrik Jakobsson <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-20drivers/rtc/rtc-twl.c: fix missing device_init_wakeup() when booted with ↵Tony Lindgren1-0/+1
device tree commit 24b8256a1fb28d357bc6fa09184ba29b4255ba5c upstream. When booted in legacy mode device_init_wakeup() gets called by drivers/mfd/twl-core.c when the children are initialized. However, when booted using device tree, the children are created with of_platform_populate() instead add_children(). This means that the RTC driver will not have device_init_wakeup() set, and we need to call it from the driver probe like RTC drivers typically do. Without this we cannot test PM wake-up events on omaps for cases where there may not be any physical wake-up event. Signed-off-by: Tony Lindgren <> Reported-by: Kevin Hilman <> Cc: Alessandro Zummo <> Cc: Jingoo Han <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-20ceph: ceph_pagelist_append might sleep while atomicJim Schutt3-61/+89
commit 39be95e9c8c0b5668c9f8806ffe29bf9f4bc0f40 upstream. Ceph's encode_caps_cb() worked hard to not call __page_cache_alloc() while holding a lock, but it's spoiled because ceph_pagelist_addpage() always calls kmap(), which might sleep. Here's the result: [13439.295457] ceph: mds0 reconnect start [13439.300572] BUG: sleeping function called from invalid context at include/linux/highmem.h:58 [13439.309243] in_atomic(): 1, irqs_disabled(): 0, pid: 12059, name: kworker/1:1 . . . [13439.376225] Call Trace: [13439.378757] [<ffffffff81076f4c>] __might_sleep+0xfc/0x110 [13439.384353] [<ffffffffa03f4ce0>] ceph_pagelist_append+0x120/0x1b0 [libceph] [13439.391491] [<ffffffffa0448fe9>] ceph_encode_locks+0x89/0x190 [ceph] [13439.398035] [<ffffffff814ee849>] ? _raw_spin_lock+0x49/0x50 [13439.403775] [<ffffffff811cadf5>] ? lock_flocks+0x15/0x20 [13439.409277] [<ffffffffa045e2af>] encode_caps_cb+0x41f/0x4a0 [ceph] [13439.415622] [<ffffffff81196748>] ? igrab+0x28/0x70 [13439.420610] [<ffffffffa045e9f8>] ? iterate_session_caps+0xe8/0x250 [ceph] [13439.427584] [<ffffffffa045ea25>] iterate_session_caps+0x115/0x250 [ceph] [13439.434499] [<ffffffffa045de90>] ? set_request_path_attr+0x2d0/0x2d0 [ceph] [13439.441646] [<ffffffffa0462888>] send_mds_reconnect+0x238/0x450 [ceph] [13439.448363] [<ffffffffa0464542>] ? ceph_mdsmap_decode+0x5e2/0x770 [ceph] [13439.455250] [<ffffffffa0462e42>] check_new_map+0x352/0x500 [ceph] [13439.461534] [<ffffffffa04631ad>] ceph_mdsc_handle_map+0x1bd/0x260 [ceph] [13439.468432] [<ffffffff814ebc7e>] ? mutex_unlock+0xe/0x10 [13439.473934] [<ffffffffa043c612>] extra_mon_dispatch+0x22/0x30 [ceph] [13439.480464] [<ffffffffa03f6c2c>] dispatch+0xbc/0x110 [libceph] [13439.486492] [<ffffffffa03eec3d>] process_message+0x1ad/0x1d0 [libceph] [13439.493190] [<ffffffffa03f1498>] ? read_partial_message+0x3e8/0x520 [libceph] . . . [13439.587132] ceph: mds0 reconnect success [13490.720032] ceph: mds0 caps stale [13501.235257] ceph: mds0 recovery completed [13501.300419] ceph: mds0 caps renewed Fix it up by encoding locks into a buffer first, and when the number of encoded locks is stable, copy that into a ceph_pagelist. [ abbreviated the stack info a bit.] Signed-off-by: Jim Schutt <> Reviewed-by: Alex Elder <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-20ceph: add cpu_to_le32() calls when encoding a reconnect capabilityJim Schutt2-3/+6
commit c420276a532a10ef59849adc2681f45306166b89 upstream. In his review, Alex Elder mentioned that he hadn't checked that num_fcntl_locks and num_flock_locks were properly decoded on the server side, from a le32 over-the-wire type to a cpu type. I checked, and AFAICS it is done; those interested can consult Locker::_do_cap_update() in src/mds/ and src/include/encoding.h in the Ceph server code (git:// I also checked the server side for flock_len decoding, and I believe that also happens correctly, by virtue of having been declared __le32 in struct ceph_mds_cap_reconnect, in src/include/ceph_fs.h. Signed-off-by: Jim Schutt <> Reviewed-by: Alex Elder <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-20libceph: must hold mutex for reset_changed_osds()Alex Elder1-1/+1
commit 14d2f38df67fadee34625fcbd282ee22514c4846 upstream. An osd client has a red-black tree describing its osds, and occasionally we would get crashes due to one of these trees tree becoming corrupt somehow. The problem turned out to be that reset_changed_osds() was being called without protection of the osd client request mutex. That function would call __reset_osd() for any osd that had changed, and __reset_osd() would call __remove_osd() for any osd with no outstanding requests, and finally __remove_osd() would remove the corresponding entry from the red-black tree. Thus, the tree was getting modified without having any lock protection, and was vulnerable to problems due to concurrent updates. This appears to be the only osd tree updating path that has this problem. It can be fairly easily fixed by moving the call up a few lines, to just before the request mutex gets dropped in kick_requests(). This resolves: Signed-off-by: Alex Elder <> Reviewed-by: Sage Weil <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-20b43: stop format string leaking into error msgsKees Cook1-1/+1
commit e0e29b683d6784ef59bbc914eac85a04b650e63c upstream. The module parameter "fwpostfix" is userspace controllable, unfiltered, and is used to define the firmware filename. b43_do_request_fw() populates ctx->errors[] on error, containing the firmware filename. b43err() parses its arguments as a format string. For systems with b43 hardware, this could lead to a uid-0 to ring-0 escalation. CVE-2013-2852 Signed-off-by: Kees Cook <> Signed-off-by: John W. Linville <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-13Linux 3.4.49v3.4.49Greg Kroah-Hartman1-1/+1
2013-06-13ftrace: Move ftrace_filter_lseek out of CONFIG_DYNAMIC_FTRACE sectionSteven Rostedt2-15/+16
commit 7f49ef69db6bbf756c0abca7e9b65b32e999eec8 upstream. As ftrace_filter_lseek is now used with ftrace_pid_fops, it needs to be moved out of the #ifdef CONFIG_DYNAMIC_FTRACE section as the ftrace_pid_fops is defined when DYNAMIC_FTRACE is not. Signed-off-by: Steven Rostedt <> Cc: Namhyung Kim <> [ lizf: adjust context ] Signed-off-by: Li Zefan <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-13tracing: Fix possible NULL pointer dereferencesNamhyung Kim3-7/+7
commit 6a76f8c0ab19f215af2a3442870eeb5f0e81998d upstream. Currently set_ftrace_pid and set_graph_function files use seq_lseek for their fops. However seq_open() is called only for FMODE_READ in the fops->open() so that if an user tries to seek one of those file when she open it for writing, it sees NULL seq_file and then panic. It can be easily reproduced with following command: $ cd /sys/kernel/debug/tracing $ echo 1234 | sudo tee -a set_ftrace_pid In this example, GNU coreutils' tee opens the file with fopen(, "a") and then the fopen() internally calls lseek(). Link: Signed-off-by: Namhyung Kim <> Cc: Frederic Weisbecker <> Cc: Ingo Molnar <> Cc: Namhyung Kim <> Signed-off-by: Steven Rostedt <> [ lizf: adjust context ] Signed-off-by: Li Zefan <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-13drm/gma500: Increase max resolution for mode settingPatrik Jakobsson1-2/+2
commit cbbd379aa43890f36da934f5af619d2fb8ec3d87 upstream. By having a higher max resolution we can now set up a virtual framebuffer that spans several monitors. 4096 should be ok since we're gen 3 or higher and should be enough for most dual head setups. Bugzilla: Signed-off-by: Patrik Jakobsson <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-13USB: ftdi_sio: Quiet sparse noise about using plain integer was NULL pointerYing Xue1-1/+1
commit a816e3113b63753c330ca4751ea1d208e93e3015 upstream. Pointers should not be compared to plain integers. Quiets the sparse warning: warning: Using plain integer as NULL pointer Signed-off-by: Ying Xue <> Cc: Lotfi Manseur <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-13xen-pciback: rate limit error messages from xen_pcibk_enable_msi{,x}()Jan Beulich1-7/+9
commit 51ac8893a7a51b196501164e645583bf78138699 upstream. ... as being guest triggerable (e.g. by invoking XEN_PCI_OP_enable_msi{,x} on a device not being MSI/MSI-X capable). This is CVE-2013-0231 / XSA-43. Also make the two messages uniform in both their wording and severity. Signed-off-by: Jan Beulich <> Acked-by: Ian Campbell <> Reviewed-by: Konrad Rzeszutek Wilk <> [stable tree: Added two extra #include files] Signed-off-by: Konrad Rzeszutek Wilk <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-13drm/i915: no lvds quirk for hp t5740Ben Mesman1-2/+2
commit 45a211d75137b1ac869a8a758a6667f15827a115 upstream. Last year, a patch was made for the "HP t5740e Thin Client" (see This device reports an lvds panel, but does not really have one. The predecessor of this device is the "hp t5740", which also does not have an lvds panel. This patch will add the same quirk for this device. Signed-off-by: Ben Mesman <> Signed-off-by: Daniel Vetter <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-13drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC.Egbert Eich1-1/+1
commit 53d3b4d7778daf15900867336c85d3f8dd70600c upstream. In intel_sdvo_get_lvds_modes() the wrong i2c adapter record is used for DDC. Thus the code will always have to rely on a LVDS panel mode supplied by VBT. In most cases this succeeds, so this didn't get detected for quite a while. This regression seems to have been introduced in commit f899fc64cda8569d0529452aafc0da31c042df2e Author: Chris Wilson <> Date: Tue Jul 20 15:44:45 2010 -0700 drm/i915: use GMBUS to manage i2c links Signed-off-by: Egbert Eich <> Reviewed-by: Chris Wilson <> [danvet: Add note about which commit likely introduced this issue.] Signed-off-by: Daniel Vetter <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-13drm: fix a use-after-free when GPU acceleration disabledHuacai Chen1-1/+5
commit b7ea85a4fed37835eec78a7be3039c8dc22b8178 upstream. When GPU acceleration is disabled, drm_vblank_cleanup() will free the vblank-related data, such as vblank_refcount, vblank_inmodeset, etc. But we found that drm_vblank_post_modeset() may be called after the cleanup, which use vblank_refcount and vblank_inmodeset. And this will cause a kernel panic. Fix this by return immediately if dev->num_crtcs is zero. This is the same thing that drm_vblank_pre_modeset() does. Call trace of a drm_vblank_post_modeset() after drm_vblank_cleanup(): [ 62.628906] [<ffffffff804868d0>] drm_vblank_post_modeset+0x34/0xb4 [ 62.628906] [<ffffffff804c7008>] atombios_crtc_dpms+0xb4/0x174 [ 62.628906] [<ffffffff804c70e0>] atombios_crtc_commit+0x18/0x38 [ 62.628906] [<ffffffff8047f038>] drm_crtc_helper_set_mode+0x304/0x3cc [ 62.628906] [<ffffffff8047f92c>] drm_crtc_helper_set_config+0x6d8/0x988 [ 62.628906] [<ffffffff8047dd40>] drm_fb_helper_set_par+0x94/0x104 [ 62.628906] [<ffffffff80439d14>] fbcon_init+0x424/0x57c [ 62.628906] [<ffffffff8046a638>] visual_init+0xb8/0x118 [ 62.628906] [<ffffffff8046b9f8>] take_over_console+0x238/0x384 [ 62.628906] [<ffffffff80436df8>] fbcon_takeover+0x7c/0xdc [ 62.628906] [<ffffffff8024fa20>] notifier_call_chain+0x44/0x94 [ 62.628906] [<ffffffff8024fcbc>] __blocking_notifier_call_chain+0x48/0x68 [ 62.628906] [<ffffffff8042d990>] register_framebuffer+0x228/0x260 [ 62.628906] [<ffffffff8047e010>] drm_fb_helper_single_fb_probe+0x260/0x314 [ 62.628906] [<ffffffff8047e2c4>] drm_fb_helper_initial_config+0x200/0x234 [ 62.628906] [<ffffffff804e5560>] radeon_fbdev_init+0xd4/0xf4 [ 62.628906] [<ffffffff804e0e08>] radeon_modeset_init+0x9bc/0xa18 [ 62.628906] [<ffffffff804bfc14>] radeon_driver_load_kms+0xdc/0x12c [ 62.628906] [<ffffffff8048b548>] drm_get_pci_dev+0x148/0x238 [ 62.628906] [<ffffffff80423564>] local_pci_probe+0x5c/0xd0 [ 62.628906] [<ffffffff80241ac4>] work_for_cpu_fn+0x1c/0x30 [ 62.628906] [<ffffffff802427c8>] process_one_work+0x274/0x3bc [ 62.628906] [<ffffffff80242934>] process_scheduled_works+0x24/0x44 [ 62.628906] [<ffffffff8024515c>] worker_thread+0x31c/0x3f4 [ 62.628906] [<ffffffff802497a8>] kthread+0x88/0x90 [ 62.628906] [<ffffffff80206794>] kernel_thread_helper+0x10/0x18 Signed-off-by: Huacai Chen <> Signed-off-by: Binbin Zhou <> Reviewed-by: Michel Dänzer <> Acked-by: Paul Menzel <> Signed-off-by: Dave Airlie <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-13hwmon: (adm1021) Strengthen chip detection for ADM1021, LM84 and MAX1617Guenter Roeck1-8/+50
commit 591bfcfc334a003ba31c0deff03b22e73349939b upstream. On a system with both MAX1617 and JC42 sensors, JC42 sensors can be misdetected as LM84. Strengthen detection sufficiently enough to avoid this misdetection. Also improve detection for ADM1021. Modeled after chip detection code in sensors-detect command. Signed-off-by: Guenter Roeck <> Tested-by: Jean Delvare <> Acked-by: Jean Delvare <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-13drm/radeon: don't allow audio on DCE6Alex Deucher1-3/+8
commit 1cbcca302a318499f20a512847c5d6a510c08c35 upstream. It's not supported yet. Fixes display issues when users force it on. Signed-off-by: Alex Deucher <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-13radeon: Fix system hang issue when using KMS with older cardsAdis Hamzić13-45/+78
commit e49f3959a96dc279860af7e86e6dbcfda50580a5 upstream. The current radeon driver initialization routines, when using KMS, are written so that the IRQ installation routine is called before initializing the WB buffer and the CP rings. With some ASICs, though, the IRQ routine tries to access the GFX_INDEX ring causing a call to RREG32 with the value of -1 in radeon_fence_read. This, in turn causes the system to completely hang with some cards, requiring a hard reset. A call stack that can cause such a hang looks like this (using rv515 ASIC for the example here): * rv515_init (rv515.c) * radeon_irq_kms_init (radeon_irq_kms.c) * drm_irq_install (drm_irq.c) * radeon_driver_irq_preinstall_kms (radeon_irq_kms.c) * rs600_irq_process (rs600.c) * radeon_fence_process - due to SW interrupt (radeon_fence.c) * radeon_fence_read (radeon_fence.c) * hang due to RREG32(-1) The patch moves the IRQ installation to the card startup routine, after the ring has been initialized, but before the IRQ has been set. This fixes the issue, but requires a check to see if the IRQ is already installed, as is the case in the system resume codepath. I have tested the patch on three machines using the rv515, the rv770 and the evergreen ASIC. They worked without issues. This seems to be a known issue and has been reported on several bug tracking sites by various distributions (see links below). Most of reports recommend booting the system with KMS disabled and then enabling KMS by reloading the radeon module. For some reason, this was indeed a usable workaround, however, UMS is now deprecated and disabled by default. Bug reports: Signed-off-by: Adis Hamzić <> Signed-off-by: Alex Deucher <>
2013-06-13powerpc/eeh: Don't check RTAS token to get PE addrGavin Shan1-7/+5
commit b8b3de224f194005ad87ede6fd022fcc2bef3b1a upstream. RTAS token "ibm,get-config-addr-info" or ibm,get-config-addr-info2" are used to retrieve the PE address according to PCI address, which made up of domain/bus/slot/function. If we don't have those 2 tokens, the domain/bus/slot/function would be used as the address for EEH RTAS operations. Some older f/w might not have those 2 tokens and that blocks the EEH functionality to be initialized. It was introduced by commit e2af155c ("powerpc/eeh: pseries platform EEH initialization"). The patch skips the check on those 2 tokens so we can bring up EEH functionality successfully. And domain/bus/slot/function will be used as address for EEH RTAS operations. Reported-by: Robert Knight <> Signed-off-by: Gavin Shan <> Tested-by: Robert Knight <> Signed-off-by: Benjamin Herrenschmidt <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-13ACPI / video: ignore BIOS initial backlight value for HP Pavilion g6Ash Willis1-0/+8
commit 780a6ec640a3fed671fc2c40e4dd30c03eca3ac3 upstream. This patch addresses kernel bug 56661. BIOS reports an incorrect backlight value, causing the driver to switch off the backlight completely during startup. This patch ignores the incorrect value from BIOS. References: Signed-off-by: Ash Willis <> Signed-off-by: Rafael J. Wysocki <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-13ACPI / video: ignore BIOS initial backlight value for HP m4Alex Hung1-0/+8
commit fedbe9bc6fd3e14b1ffbb3dac407777ac4a3650c upstream. On HP m4 lapops, BIOS reports minimum backlight on boot and causes backlight to dim completely. This ignores the initial backlight values and set to max brightness. References: Signed-off-by: Alex Hung <> Signed-off-by: Rafael J. Wysocki <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-13USB: mos7720: fix hardware flow controlJohan Hovold1-1/+1
commit a26f009a070e840fadacb91013b2391ba7ab6cc2 upstream. The register access to enable hardware flow control depends on the device port number and not the port minor number. Signed-off-by: Johan Hovold <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-13USB: mos7720: fix message timeoutsJohan Hovold1-3/+3
commit 849513a7809175420d353625b6f651d961e99d49 upstream. The control and bulk-message timeouts are specified in milliseconds and should not depend on HZ. Signed-off-by: Johan Hovold <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-13USB: mos7720: fix DMA to stackJohan Hovold1-3/+14
commit 72ea18a558ed7a63a50bb121ba60d73b5b38ae30 upstream. The read_mos_reg function is called with stack-allocated buffers, which must not be used for control messages. Signed-off-by: Johan Hovold <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-13USB: revert periodic scheduling bugfixAlan Stern1-1/+1
commit fdc03438f53a00294ed9939eb3a1f6db6f3d8963 upstream. This patch reverts commit 3e619d04159be54b3daa0b7036b0ce9e067f4b5d (USB: EHCI: fix bug in scheduling periodic split transfers). The commit was valid -- it fixed a real bug -- but the periodic scheduler in ehci-hcd is in such bad shape (especially the part that handles split transactions) that fixing one bug is very likely to cause another to surface. That's what happened in this case; the result was choppy and noisy playback on certain 24-bit audio devices. The only real fix will be to rewrite this entire section of code. My next project... This fixes Thanks to Tim Richardson for extra testing and feedback, and to Joseph Salisbury and Tyson Tan for tracking down the original source of the problem. Signed-off-by: Alan Stern <> CC: Joseph Salisbury <> CC: Tim Richardson <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-13USB: serial: fix Treo/Kyocera interrrupt-in urb contextJohan Hovold1-0/+1
commit 5f8e2c07d75967ee49a5da1d21ddf5f50d48cda0 upstream. The first and second interrupt-in urbs are swapped for some Treo/Kyocera devices, but the urb context was never updated with the new port. Signed-off-by: Johan Hovold <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-13USB: whiteheat: fix broken port configurationJohan Hovold1-1/+1
commit 9eecf22d2b375b9064a20421c6c307b760b03d46 upstream. When configuring the port (e.g. set_termios) the port minor number rather than the port number was used in the request (and they only coincide for minor number 0). Signed-off-by: Johan Hovold <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-13USB: Serial: cypress_M8: Enable FRWD Dongle hidcom deviceRobert Butora2-1/+21
commit 6529591e3eef65f0f528a81ac169f6e294b947a7 upstream. The patch adds a new HIDCOM device and does not affect other devices driven by the cypress_M8 module. Changes are: - add VendorID ProductID to device tables - skip unstable speed check because FRWD uses 115200bps - skip reset at probe which is an issue workaround for this particular device. Signed-off-by: Robert Butora <> Signed-off-by: Greg Kroah-Hartman <>
2013-06-13USB: visor: fix initialisation of Treo/Kyocera devicesJohan Hovold1-0/+8
commit 420021a395ce38b7ab2cceb52dee4038be7d8fa3 upstream. Fix regression introduced by commit 214916f2e ("USB: visor: reimplement using generic framework") which broke initialisation of Treo/Kyocera devices that re-mapped bulk-in endpoints. Signed-off-by: Johan Hovold <> Signed-off-by: Greg Kroah-Hartman <>