- 01 Dec, 2014 22 commits
-
-
Murali Karicheri authored
commit c5edfff9 upstream. Keystone K2E EVM uses Marvel 0x9182 controller. This requires support for the ID in the ahci driver. Signed-off-by:
Murali Karicheri <m-karicheri2@ti.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> [lizf: Backported to 3.4: - adjust context - s/PCI_VENDOR_ID_MARVELL_EXT/0x1b4b/] Signed-off-by:
Zefan Li <lizefan@huawei.com>
-
Felipe Balbi authored
commit fed33afc upstream. Currently, we disable pm_runtime before all register accesses are done, this is dangerous and might lead to abort exceptions due to the driver trying to access a register which is clocked by a clock which was long gated. Fix that by moving pm_runtime_put_sync() and pm_runtime_disable() as the last thing we do before returning from our ->remove() method. Fixes: 72246da4 (usb: Introduce DesignWare USB3 DRD Driver) Signed-off-by:
Felipe Balbi <balbi@ti.com> [lizf: Backported to 3.4: adjust context] Signed-off-by:
-
Keith Busch authored
commit 2da78092 upstream. Releases the dev_t minor when all references are closed to prevent another device from acquiring the same major/minor. Since the partition's release may be invoked from call_rcu's soft-irq context, the ext_dev_idr's mutex had to be replaced with a spinlock so as not so sleep. Signed-off-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
Jens Axboe <axboe@fb.com> [lizf: Backported to 3.4: - adjust context - remove idr_preload() and idr_preload_end()] Signed-off-by:
-
Ross Lagerwall authored
commit 61a734d3 upstream. Always freeze processes when suspending and thaw processes when resuming to prevent a race noticeable with HVM guests. This prevents a deadlock where the khubd kthread (which is designed to be freezable) acquires a usb device lock and then tries to allocate memory which requires the disk which hasn't been resumed yet. Meanwhile, the xenwatch thread deadlocks waiting for the usb device lock. Freezing processes fixes this because the khubd thread is only thawed after the xenwatch thread finishes resuming all the devices. Signed-off-by:
Ross Lagerwall <ross.lagerwall@citrix.com> Signed-off-by:
David Vrabel <david.vrabel@citrix.com> [lizf: Backported to 3.4: adjust context] Signed-off-by:
-
Bjørn Mork authored
commit 5b3da692 upstream. This VID:PID is used for some Direct IP devices behaving identical to the already supported 0F3D:68AA devices. Reported-by:
Lars Melin <larsm17@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Bjørn Mork authored
commit 049255f5 upstream. Sierra Wireless Direct IP devices using the 68A3 product ID can be configured for modes including a CDC ECM class function. The known example uses interface numbers 12 and 13 for the ECM control and data interfaces respectively, consistent with CDC MBIM function interface numbering on other Sierra devices. It seems cleaner to restrict this driver to the ff/ff/ff vendor specific interfaces rather than increasing the already long interface number blacklist. This should be more future proof if Sierra adds more class functions using interface numbers not yet in the blacklist. Signed-off-by:
-
Johan Hovold authored
commit ee444609 upstream. Add device id for NOVITUS Bono E thermal printer. Reported-by:
Emanuel Koczwara <poczta@emanuelkoczwara.pl> Signed-off-by:
-
James Ralston authored
commit 6cad1376 upstream. This patch adds the IDE mode SATA Device IDs for the Intel 9 Series PCH. Signed-off-by:
James Ralston <james.d.ralston@intel.com> Signed-off-by:
-
James Ralston authored
commit 1b071a09 upstream. This patch adds the AHCI mode SATA Device IDs for the Intel 9 Series PCH. Signed-off-by:
-
Larry Finger authored
commit c6651716 upstream. The Sitecom WLA-2102 adapter uses this driver. Reported-by:
Nico Baggus <nico-linux@noci.xs4all.nl> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Nico Baggus <nico-linux@noci.xs4all.nl> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Alban Crequy authored
commit 71b1fb5c upstream. /proc/<pid>/cgroup contains one cgroup path on each line. If cgroup names are allowed to contain "\n", applications cannot parse /proc/<pid>/cgroup safely. Signed-off-by:
Alban Crequy <alban.crequy@collabora.co.uk> Signed-off-by:
-
Honggang Li authored
commit 3189eddb upstream. Currently, only SMP system free the percpu allocation info. Uniprocessor system should free it too. For example, one x86 UML virtual machine with 256MB memory, UML kernel wastes one page memory. Signed-off-by:
Honggang Li <enjoymindful@gmail.com> Signed-off-by:
-
Tejun Heo authored
commit 849f5169 upstream. If pcpu_map_pages() fails midway, it unmaps the already mapped pages. Currently, it doesn't flush tlb after the partial unmapping. This may be okay in most cases as the established mapping hasn't been used at that point but it can go wrong and when it goes wrong it'd be extremely difficult to track down. Flush tlb after the partial unmapping. Signed-off-by:
-
Tejun Heo authored
commit f0d27965 upstream. When pcpu_alloc_pages() fails midway, pcpu_free_pages() is invoked to free what has already been allocated. The invocation is across the whole requested range and pcpu_free_pages() will try to free all non-NULL pages; unfortunately, this is incorrect as pcpu_get_pages_and_bitmap(), unlike what its comment suggests, doesn't clear the pages array and thus the array may have entries from the previous invocations making the partial failure path free incorrect pages. Fix it by open-coding the partial freeing of the already allocated pages. Signed-off-by:
-
Eliad Peller authored
commit a5fe8e76 upstream. alpha2 is defined as 2-chars array, but is used in multiple places as string (e.g. with nla_put_string calls), which might leak kernel data. Solve it by simply adding an extra char for the NULL terminator, making such operations safe. Signed-off-by:
Eliad Peller <eliadx.peller@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> [lizf: Backported to 3.4: adjust context] Signed-off-by:
-
Jiri Kosina authored
commit 6726655d upstream. There is a following AB-BA dependency between cpu_hotplug.lock and cpuidle_lock: 1) cpu_hotplug.lock -> cpuidle_lock enable_nonboot_cpus() _cpu_up() cpu_hotplug_begin() LOCK(cpu_hotplug.lock) cpu_notify() ... acpi_processor_hotplug() cpuidle_pause_and_lock() LOCK(cpuidle_lock) 2) cpuidle_lock -> cpu_hotplug.lock acpi_os_execute_deferred() workqueue ... acpi_processor_cst_has_changed() cpuidle_pause_and_lock() LOCK(cpuidle_lock) get_online_cpus() LOCK(cpu_hotplug.lock) Fix this by reversing the order acpi_processor_cst_has_changed() does thigs -- let it first execute the protection against CPU hotplug by calling get_online_cpus() and obtain the cpuidle lock only after that (and perform the symmentric change when allowing CPUs hotplug again and dropping cpuidle lock). Spotted by lockdep. Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Takashi Iwai authored
commit acf08081 upstream. 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 <danagoyette@gmail.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Thomas Hellstrom authored
commit f01ea0c3 upstream. The code waiting for fifo idle was incorrect and could possibly spin forever under certain circumstances. Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reported-by:
Mark Sheldon <markshel@vmware.com> Reviewed-by:
Jakob Bornecrantz <jakob@vmware.com> Reivewed-by:
-
Al Viro authored
commit 88b368f2 upstream. The check in __propagate_umount() ("has somebody explicitly mounted something on that slave?") is done *before* taking the already doomed victims out of the child lists. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> [lizf: Backported to 3.4: - adjust context - s/hlist_for_each_entry/list_for_each_entry/] Signed-off-by:
-
Mathias Krause authored
commit bbe1c274 upstream. The __init annotations for the DMI callback functions are wrong as this code can be called even after the module has been initialized, e.g. like this: # echo 1 > /sys/bus/pci/devices/0000:00:02.0/remove # modprobe i915 # echo 1 > /sys/bus/pci/rescan The first command will remove the PCI device from the kernel's device list so the second command won't see it right away. But as it registers a PCI driver it'll see it on the third command. If the system happens to match one of the DMI table entries we'll try to call a function in long released memory and generate an Oops, at best. Fix this by removing the bogus annotation. Modpost should have caught that one but it ignores section reference mismatches from the .rodata section. :/ Fixes: 25e341cf ("drm/i915: quirk away broken OpRegion VBT") Fixes: 8ca4013d ("CHROMIUM: i915: Add DMI override to skip CRT...") Fixes: 425d244c ("drm/i915: ignore LVDS on intel graphics systems...") Signed-off-by:
Mathias Krause <minipli@googlemail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Duncan Laurie <dlaurie@chromium.org> Cc: Jarod Wilson <jarod@redhat.com> Cc: Rusty Russell <rusty@rustcorp.com.au> # Can modpost be fixed? Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Mark Brown authored
commit 5844a8b9 upstream. A previous over-zealous factorisation of code means that we only treat registers as volatile if they are readable. For most devices this is fine since normally most registers can be read and volatility implies readability but for format_write() devices where there is no readback from the hardware and we use volatility to mean simply uncacheability this means that we end up treating all registers as cacheble. A bigger refactoring of the code to clarify this is in order but as a fix make a minimal change and only check readability when checking volatility if there is no format_write() operation defined for the device. Signed-off-by:
Mark Brown <broonie@linaro.org> Tested-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
-
Christian Borntraeger authored
commit 614a80e4 upstream. In the early days, we had some special handling for the KVM_EXIT_S390_SIEIC exit, but this was gone in 2009 with commit d7b0b5eb (KVM: s390: Make psw available on all exits, not just a subset). Now this switch statement is just a sanity check for userspace not messing with the kvm_run structure. Unfortunately, this allows userspace to trigger a kernel BUG. Let's just remove this switch statement. Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by:
Cornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by:
David Hildenbrand <dahi@linux.vnet.ibm.com> [lizf: Backported to 3.4: - adjust context - no KVM_EXIT_S390_TSCH and KVM_EXIT_DEBUG in 3.4] Signed-off-by:
-
- 25 Sep, 2014 18 commits
-
-
Zefan Li authored
-
Michael Cree authored
commit 25534eb7 upstream. These functions are used in some PCI drivers with big-endian MMIO space. Admittedly it is almost certain that no one this side of the Moon would use such a card in an Alpha but it does get us closer to being able to build allyesconfig or allmodconfig, and it enables the Debian default generic config to build. Tested-by:
Raúl Porcel <armin76@gentoo.org> Signed-off-by:
Michael Cree <mcree@orcon.net.nz> Signed-off-by:
Matt Turner <mattst88@gmail.com> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Jan Kara authored
commit 7ba3ec57 upstream. Commit 8e3dffc6 "Ext2: mark inode dirty after the function dquot_free_block_nodirty is called" unveiled a bug in __ext2_get_block() called from ext2_get_xip_mem(). That function called ext2_get_block() mistakenly asking it to map 0 blocks while 1 was intended. Before the above mentioned commit things worked out fine by luck but after that commit we started returning that we allocated 0 blocks while we in fact allocated 1 block and thus allocation was looping until all blocks in the filesystem were exhausted. Fix the problem by properly asking for one block and also add assertion in ext2_get_blocks() to catch similar problems. Reported-and-tested-by:
Andiry Xu <andiry.xu@gmail.com> Signed-off-by:
Jan Kara <jack@suse.cz> Cc: Wang Nan <wangnan0@huawei.com> Signed-off-by:
-
Michael Cree authored
commit d1b5153f upstream. Commit ec221208 ("Disintegrate asm/system.h for Alpha") removed asm/system.h however arch/alpha/oprofile/common.c requires definitions that were shifted from asm/system.h to asm/special_insns.h. Include that. Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Guan Xuetao authored
commit 195d4577 upstream. When disintegrate system.h, I left an error in asm/cmpxchg.h, which will result in following error: arch/unicore32/include/asm/cmpxchg.h: In function '__xchg': arch/unicore32/include/asm/cmpxchg.h:38: error: void value not ignored as it ought to be Signed-off-by:
Guan Xuetao <gxt@mprc.pku.edu.cn> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Guan Xuetao authored
UniCore32-bugfix: Remove definitions in asm/bug.h to solve difference between native and cross compiler commit 10e1e99e upstream. For kernel/bound.c being compiled by native compiler, it will generate following errors in gcc 4.4.3: CC kernel/bounds.s In file included from include/linux/bug.h:4, from include/linux/page-flags.h:9, from kernel/bounds.c:9: arch/unicore32/include/asm/bug.h:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void' arch/unicore32/include/asm/bug.h:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'void' So, we moved definitions in asm/bug.h to arch/unicore32/kernel/setup.h to solve the problem. Signed-off-by:
-
Fengguang Wu authored
commit 82e54a6a upstream. It's required for the core fs/namespace.c and many other basic features. Signed-off-by:
Fengguang Wu <fengguang.wu@intel.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Paul Gortmaker authored
commit 7400ce7e (v3.4.92-76-g7400ce7e) was a backport of commit ebebd49a upstream ("8250/16?50: Add support for Broadcom TruManage redirected serial port") However, in the context of 3.4.x kernels, the pci setup code was expecting a struct uart_port and not a struct uart_8250_port, leading to the following concerning warnings: drivers/tty/serial/8250/8250_pci.c: In function ‘pci_brcm_trumanage_setup’: drivers/tty/serial/8250/8250_pci.c:1086:2: warning: passing argument 3 of ‘pci_default_setup’ from incompatible pointer type [enabled by default] int ret = pci_default_setup(priv, board, port, idx); ^ drivers/tty/serial/8250/8250_pci.c:1036:1: note: expected ‘struct uart_port *’ but argument is of type ‘struct uart_8250_port *’ pci_default_setup(struct serial_private *priv, ^ drivers/tty/serial/8250/8250_pci.c: At top level: drivers/tty/serial/8250/8250_pci.c:1746:3: warning: initialization from incompatible pointer type [enabled by default] .setup = pci_brcm_trumanage_setup, ^ drivers/tty/serial/8250/8250_pci.c:1746:3: warning: (near initialization for ‘pci_serial_quirks[56].setup’) [enabled by default] I'd also expect the initialization to not function correctly, and perhaps dereference random garbage due to this. Since the uart_port is a field within the uart_8250_port, the adaptation to fix these warnings is a straightforward removal of a layer of indirection. Cc: Stephen Hurd <shurd@broadcom.com> Cc: Michael Chan <mchan@broadcom.com> Cc: Ben Hutchings <ben@decadent.org.uk> Cc: Rui Xiang <rui.xiang@huawei.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
-
Andi Kleen authored
commit e7b691b0 upstream. slab_node() could access current->mempolicy from interrupt context. However there's a race condition during exit where the mempolicy is first freed and then the pointer zeroed. Using this from interrupts seems bogus anyways. The interrupt will interrupt a random process and therefore get a random mempolicy. Many times, this will be idle's, which noone can change. Just disable this here and always use local for slab from interrupts. I also cleaned up the callers of slab_node a bit which always passed the same argument. I believe the original mempolicy code did that in fact, so it's likely a regression. v2: send version with correct logic v3: simplify. fix typo. Reported-by:
Arun Sharma <asharma@fb.com> Cc: penberg@kernel.org Cc: cl@linux.com Signed-off-by:
Andi Kleen <ak@linux.intel.com> [tdmackey@twitter.com: Rework control flow based on feedback from cl@linux.com, fix logic, and cleanup current task_struct reference] Acked-by:
David Rientjes <rientjes@google.com> Acked-by:
Christoph Lameter <cl@linux.com> Acked-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Signed-off-by:
David Mackey <tdmackey@twitter.com> Signed-off-by:
Pekka Enberg <penberg@kernel.org> Signed-off-by:
-
Stefan Kristiansson authored
commit 160d8378 upstream. Prevents build issue with updated toolchain Reported-by:
Jack Thomasson <jkt@moonlitsw.com> Tested-by:
Christian Svensson <blue@cmd.nu> Signed-off-by:
Stefan Kristiansson <stefan.kristiansson@saunalahti.fi> Signed-off-by:
Jonas Bonn <jonas@southpole.se> Signed-off-by:
-
Ralf Baechle authored
commit ff522058 upstream. This fixes the following issue BUG: using smp_processor_id() in preemptible [00000000] code: kjournald/1761 caller is blast_dcache32+0x30/0x254 Call Trace: [<8047f02c>] dump_stack+0x8/0x34 [<802e7e40>] debug_smp_processor_id+0xe0/0xf0 [<80114d94>] blast_dcache32+0x30/0x254 [<80118484>] r4k_dma_cache_wback_inv+0x200/0x288 [<80110ff0>] mips_dma_map_sg+0x108/0x180 [<80355098>] ide_dma_prepare+0xf0/0x1b8 [<8034eaa4>] do_rw_taskfile+0x1e8/0x33c [<8035951c>] ide_do_rw_disk+0x298/0x3e4 [<8034a3c4>] do_ide_request+0x2e0/0x704 [<802bb0dc>] __blk_run_queue+0x44/0x64 [<802be000>] queue_unplugged.isra.36+0x1c/0x54 [<802beb94>] blk_flush_plug_list+0x18c/0x24c [<802bec6c>] blk_finish_plug+0x18/0x48 [<8026554c>] journal_commit_transaction+0x3b8/0x151c [<80269648>] kjournald+0xec/0x238 [<8014ac00>] kthread+0xb8/0xc0 [<8010268c>] ret_from_kernel_thread+0x14/0x1c Caches in most systems are identical - but not always, so we can't avoid the use of smp_call_function() by just looking at the boot CPU's data, have to fiddle with preemption instead. Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/5835Signed-off-by:
-
Florian Fainelli authored
commit 6c37c958 upstream. cc1: warnings being treated as errors arch/mips/kernel/perf_event_mipsxx.c:166: error: 'counters_per_cpu_to_total' defined but not used make[2]: *** [arch/mips/kernel/perf_event_mipsxx.o] Error 1 make[2]: *** Waiting for unfinished jobs.... It was first introduced by 82091564 [MIPS: perf: Add support for 64-bit perf counters.] in 3.2. Signed-off-by:
Florian Fainelli <florian@openwrt.org> Cc: linux-mips@linux-mips.org Cc: david.daney@cavium.com Patchwork: https://patchwork.linux-mips.org/patch/3357/Signed-off-by:
-
Johan Hovold authored
commit 5654699f upstream. Make sure to verify the number of ports requested by subdriver to avoid writing beyond the end of fixed-size array in interface data. The current usb-serial implementation is limited to eight ports per interface but failed to verify that the number of ports requested by a subdriver (which could have been determined from device descriptors) did not exceed this limit. Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> [lizf: Backported to 3.4: s/ddev/\&interface->dev/] Signed-off-by:
-
Johan Hovold authored
commit d979e9f9 upstream. Make sure to verify the maximum number of endpoints per type to avoid writing beyond the end of a stack-allocated array. The current usb-serial implementation is limited to eight ports per interface but failed to verify that the number of endpoints of a certain type reported by a device did not exceed this limit. Signed-off-by:
-
Mark Rutland authored
commit 2c32c65e upstream. On revisions of Cortex-A15 prior to r3p3, a CLREX instruction at PL1 may falsely trigger a watchpoint exception, leading to potential data aborts during exception return and/or livelock. This patch resolves the issue in the following ways: - Replacing our uses of CLREX with a dummy STREX sequence instead (as we did for v6 CPUs). - Removing the clrex code from v7_exit_coherency_flush and derivatives, since this only exists as a minor performance improvement when non-cached exclusives are in use (Linux doesn't use these). Benchmarking on a variety of ARM cores revealed no measurable performance difference with this change applied, so the change is performed unconditionally and no new Kconfig entry is added. Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> [lizf: Backported to 3.4: - Drop changes to arch/arm/include/asm/cacheflush.h and arch/arm/mach-exynos/mcpm-exynos.c] Signed-off-by:
-
Mark Rutland authored
commit 85868313 upstream. The ARMv6 and ARMv7 early abort handlers clear the exclusive monitors upon entry to the kernel, but this is redundant: - We clear the monitors on every exception return since commit 200b812d ("Clear the exclusive monitor when returning from an exception"), so this is not necessary to ensure the monitors are cleared before returning from a fault handler. - Any dummy STREX will target a temporary scratch area in memory, and may succeed or fail without corrupting useful data. Its status value will not be used. - Any other STREX in the kernel must be preceded by an LDREX, which will initialise the monitors consistently and will not depend on the earlier state of the monitors. Therefore we have no reason to care about the initial state of the exclusive monitors when a data abort is taken, and clearing the monitors prior to exception return (as we already do) is sufficient. This patch removes the redundant clearing of the exclusive monitors from the early abort handlers. Signed-off-by:
-
Jiri Kosina authored
commit 844817e4 upstream. The report passed to us from transport driver could potentially be arbitrarily large, therefore we better sanity-check it so that raw_data that we hold in picolcd_pending structure are always kept within proper bounds. Reported-by:
Steven Vittitoe <scvitti@google.com> Signed-off-by:
-
Jiri Kosina authored
commit c54def7b upstream. The report passed to us from transport driver could potentially be arbitrarily large, therefore we better sanity-check it so that magicmouse_emit_touch() gets only valid values of raw_id. Reported-by:
-
