- 22 Oct, 2015 40 commits
-
-
Eric W. Biederman authored
commit 397d425d upstream. In rare cases a directory can be renamed out from under a bind mount. In those cases without special handling it becomes possible to walk up the directory tree to the root dentry of the filesystem and down from the root dentry to every other file or directory on the filesystem. Like division by zero .. from an unconnected path can not be given a useful semantic as there is no predicting at which path component the code will realize it is unconnected. We certainly can not match the current behavior as the current behavior is a security hole. Therefore when encounting .. when following an unconnected path return -ENOENT. - Add a function path_connected to verify path->dentry is reachable from path->mnt.mnt_root. AKA to validate that rename did not do something nasty to the bind mount. To avoid races path_connected must be called after following a path component to it's next path component. Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Eric W. Biederman authored
commit cde93be4 upstream. A rename can result in a dentry that by walking up d_parent will never reach it's mnt_root. For lack of a better term I call this an escaped path. prepend_path is called by four different functions __d_path, d_absolute_path, d_path, and getcwd. __d_path only wants to see paths are connected to the root it passes in. So __d_path needs prepend_path to return an error. d_absolute_path similarly wants to see paths that are connected to some root. Escaped paths are not connected to any mnt_root so d_absolute_path needs prepend_path to return an error greater than 1. So escaped paths will be treated like paths on lazily unmounted mounts. getcwd needs to prepend "(unreachable)" so getcwd also needs prepend_path to return an error. d_path is the interesting hold out. d_path just wants to print something, and does not care about the weird cases. Which raises the question what should be printed? Given that <escaped_path>/<anything> should result in -ENOENT I believe it is desirable for escaped paths to be printed as empty paths. As there are not really any meaninful path components when considered from the perspective of a mount tree. So tweak prepend_path to return an empty path with an new error code of 3 when it encounters an escaped path. Signed-off-by:
-
Chaotian Jing authored
commit 031277d4 upstream. When get a CRC error, start the mmc_retune, it will issue CMD19/CMD21 to do tune, assume there were 10 clock phase need to try, phase 0 to phase 6 is ok, phase 7 to phase 9 is NG, we try it from 0 to 9, so the last CMD19/CMD21 will get CRC error, host->need_retune was set and cause mmc_retune was called, then dead loop of mmc_retune Signed-off-by:
Chaotian Jing <chaotian.jing@mediatek.com> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Fixes: bd11e8bd ("mmc: core: Flag re-tuning is needed on CRC errors") Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Ulf Hansson authored
commit 43934ece upstream. When CONFIG_GPIOLIB is unset, its stubs will return -ENOSYS. That means when the mmc core parses DT for CD/WP GPIOs via mmc_of_parse(), -ENOSYS becomes propagated to the caller. Typically this means that the mmc host driver fails to probe. As the CD/WP GPIOs are already treated as optional, let's extend that to cover the case when CONFIG_GPIOLIB is unset. Reported-by:
Michal Simek <michal.simek@xilinx.com> Fixes: 16b23787 ("mmc: sdhci-of-arasan: Call OF parsing for MMC") Signed-off-by:
Venu Byravarasu <vbyravarasu@nvidia.com> Signed-off-by:
-
Nicholas Bellinger authored
commit 673681ca upstream. This patch fixes a v4.2+ regression introduced by commit c04a6091 that removed support for obsolete sync-and-steering markers usage as originally defined in RFC-3720. The regression would involve attempting to send OFMarker=No + IFMarker=No keys during opertional negotiation login phase, including when initiators did not actually propose these keys. The result for MSFT iSCSI initiators would be random junk in TCP stream after the last successful login request was been sent signaling the move to full feature phase (FFP) operation. To address this bug, go ahead and avoid negotiating these keys by default unless the initiator explicitly proposes them, but still respond to them with 'No' if they are proposed. Reported-by:
Dragan Milivojević <galileo@pkm-inc.com> Bisected-by:
Christophe Vu-Brugier <cvubrugier@fastmail.fm> Tested-by:
Nicholas Bellinger <nab@linux-iscsi.org> Cc: Andy Grover <agrover@redhat.com> Signed-off-by:
-
Sudip Mukherjee authored
commit 21343ac2 upstream. The builds of allmodconfig of avr32 is failing with: drivers/net/ethernet/via/via-rhine.c:1098:2: error: implicit declaration of function 'pci_iomap' [-Werror=implicit-function-declaration] drivers/net/ethernet/via/via-rhine.c:1119:2: error: implicit declaration of function 'pci_iounmap' [-Werror=implicit-function-declaration] The generic empty pci_iomap and pci_iounmap is used only if CONFIG_PCI is not defined and CONFIG_GENERIC_PCI_IOMAP is defined. Add GENERIC_PCI_IOMAP in the dependency list for VIA_RHINE as we are getting build failure when CONFIG_PCI and CONFIG_GENERIC_PCI_IOMAP both are not defined. Signed-off-by:
Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
shengyong authored
commit 7c7feb2e upstream. UBI: attaching mtd1 to ubi0 UBI: scanning is finished UBI error: init_volumes: not enough PEBs, required 706, available 686 UBI error: ubi_wl_init: no enough physical eraseblocks (-20, need 1) UBI error: ubi_attach_mtd_dev: failed to attach mtd1, error -12 <= NOT ENOMEM UBI error: ubi_init: cannot attach mtd1 If available PEBs are not enough when initializing volumes, return -ENOSPC directly. If available PEBs are not enough when initializing WL, return -ENOSPC instead of -ENOMEM. Signed-off-by:
Sheng Yong <shengyong1@huawei.com> Signed-off-by:
Richard Weinberger <richard@nod.at> Reviewed-by:
David Gstir <david@sigma-star.at> Signed-off-by:
-
Richard Weinberger authored
commit 281fda27 upstream. Make sure that data_size is less than LEB size. Otherwise a handcrafted UBI image is able to trigger an out of bounds memory access in ubi_compare_lebs(). Signed-off-by:
-
Richard Weinberger authored
commit cf6f54e3 upstream. Fixes the following lockdep splat: [ 1.244527] ============================================= [ 1.245193] [ INFO: possible recursive locking detected ] [ 1.245193] 4.2.0-rc1+ #37 Not tainted [ 1.245193] --------------------------------------------- [ 1.245193] cp/742 is trying to acquire lock: [ 1.245193] (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [<ffffffff812b3f69>] ubifs_init_security+0x29/0xb0 [ 1.245193] [ 1.245193] but task is already holding lock: [ 1.245193] (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [<ffffffff81198e7f>] path_openat+0x3af/0x1280 [ 1.245193] [ 1.245193] other info that might help us debug this: [ 1.245193] Possible unsafe locking scenario: [ 1.245193] [ 1.245193] CPU0 [ 1.245193] ---- [ 1.245193] lock(&sb->s_type->i_mutex_key#9); [ 1.245193] lock(&sb->s_type->i_mutex_key#9); [ 1.245193] [ 1.245193] *** DEADLOCK *** [ 1.245193] [ 1.245193] May be due to missing lock nesting notation [ 1.245193] [ 1.245193] 2 locks held by cp/742: [ 1.245193] #0: (sb_writers#5){.+.+.+}, at: [<ffffffff811ad37f>] mnt_want_write+0x1f/0x50 [ 1.245193] #1: (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [<ffffffff81198e7f>] path_openat+0x3af/0x1280 [ 1.245193] [ 1.245193] stack backtrace: [ 1.245193] CPU: 2 PID: 742 Comm: cp Not tainted 4.2.0-rc1+ #37 [ 1.245193] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140816_022509-build35 04/01/2014 [ 1.245193] ffffffff8252d530 ffff88007b023a38 ffffffff814f6f49 ffffffff810b56c5 [ 1.245193] ffff88007c30cc80 ffff88007b023af8 ffffffff810a150d ffff88007b023a68 [ 1.245193] 000000008101302a ffff880000000000 00000008f447e23f ffffffff8252d500 [ 1.245193] Call Trace: [ 1.245193] [<ffffffff814f6f49>] dump_stack+0x4c/0x65 [ 1.245193] [<ffffffff810b56c5>] ? console_unlock+0x1c5/0x510 [ 1.245193] [<ffffffff810a150d>] __lock_acquire+0x1a6d/0x1ea0 [ 1.245193] [<ffffffff8109fa78>] ? __lock_is_held+0x58/0x80 [ 1.245193] [<ffffffff810a1a93>] lock_acquire+0xd3/0x270 [ 1.245193] [<ffffffff812b3f69>] ? ubifs_init_security+0x29/0xb0 [ 1.245193] [<ffffffff814fc83b>] mutex_lock_nested+0x6b/0x3a0 [ 1.245193] [<ffffffff812b3f69>] ? ubifs_init_security+0x29/0xb0 [ 1.245193] [<ffffffff812b3f69>] ? ubifs_init_security+0x29/0xb0 [ 1.245193] [<ffffffff812b3f69>] ubifs_init_security+0x29/0xb0 [ 1.245193] [<ffffffff8128e286>] ubifs_create+0xa6/0x1f0 [ 1.245193] [<ffffffff81198e7f>] ? path_openat+0x3af/0x1280 [ 1.245193] [<ffffffff81195d15>] vfs_create+0x95/0xc0 [ 1.245193] [<ffffffff8119929c>] path_openat+0x7cc/0x1280 [ 1.245193] [<ffffffff8109ffe3>] ? __lock_acquire+0x543/0x1ea0 [ 1.245193] [<ffffffff81088f20>] ? sched_clock_cpu+0x90/0xc0 [ 1.245193] [<ffffffff81088c00>] ? calc_global_load_tick+0x60/0x90 [ 1.245193] [<ffffffff81088f20>] ? sched_clock_cpu+0x90/0xc0 [ 1.245193] [<ffffffff811a9cef>] ? __alloc_fd+0xaf/0x180 [ 1.245193] [<ffffffff8119ac55>] do_filp_open+0x75/0xd0 [ 1.245193] [<ffffffff814ffd86>] ? _raw_spin_unlock+0x26/0x40 [ 1.245193] [<ffffffff811a9cef>] ? __alloc_fd+0xaf/0x180 [ 1.245193] [<ffffffff81189bd9>] do_sys_open+0x129/0x200 [ 1.245193] [<ffffffff81189cc9>] SyS_open+0x19/0x20 [ 1.245193] [<ffffffff81500717>] entry_SYSCALL_64_fastpath+0x12/0x6f While the lockdep splat is a false positive, becuase path_openat holds i_mutex of the parent directory and ubifs_init_security() tries to acquire i_mutex of a new inode, it reveals that taking i_mutex in ubifs_init_security() is in vain because it is only being called in the inode allocation path and therefore nobody else can see the inode yet. Reported-and-tested-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Reviewed-and-tested-by:
Dongsheng Yang <yangds.fnst@cn.fujitsu.com> Signed-off-by:
-
Christian Engelmayer authored
commit a8b97745 upstream. Commit 5d5cd85f ("rsi: Fix failure to load firmware after memory leak fix and fix the leak") also added a check on the allocation of DMA-accessible memory that may directly return. In that case the already allocated firmware data is leaked. Make sure the data is always freed correctly. Detected by Coverity CID 1316519. Fixes: 5d5cd85f ("rsi: Fix failure to load firmware after memory leak fix and fix the leak") Signed-off-by:
Christian Engelmayer <cengelma@gmx.at> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Paul Mackerras authored
commit e297c939 upstream. This fixes a race which can result in the same virtual IRQ number being assigned to two different MSI interrupts. The most visible consequence of that is usually a warning and stack trace from the sysfs code about an attempt to create a duplicate entry in sysfs. The race happens when one CPU (say CPU 0) is disposing of an MSI while another CPU (say CPU 1) is setting up an MSI. CPU 0 calls (for example) pnv_teardown_msi_irqs(), which calls msi_bitmap_free_hwirqs() to indicate that the MSI (i.e. its hardware IRQ number) is no longer in use. Then, before CPU 0 gets to calling irq_dispose_mapping() to free up the virtal IRQ number, CPU 1 comes in and calls msi_bitmap_alloc_hwirqs() to allocate an MSI, and gets the same hardware IRQ number that CPU 0 just freed. CPU 1 then calls irq_create_mapping() to get a virtual IRQ number, which sees that there is currently a mapping for that hardware IRQ number and returns the corresponding virtual IRQ number (which is the same virtual IRQ number that CPU 0 was using). CPU 0 then calls irq_dispose_mapping() and frees that virtual IRQ number. Now, if another CPU comes along and calls irq_create_mapping(), it is likely to get the virtual IRQ number that was just freed, resulting in the same virtual IRQ number apparently being used for two different hardware interrupts. To fix this race, we just move the call to msi_bitmap_free_hwirqs() to after the call to irq_dispose_mapping(). Since virq_to_hw() doesn't work for the virtual IRQ number after irq_dispose_mapping() has been called, we need to call it before irq_dispose_mapping() and remember the result for the msi_bitmap_free_hwirqs() call. The pattern of calling msi_bitmap_free_hwirqs() before irq_dispose_mapping() appears in 5 places under arch/powerpc, and appears to have originated in commit 05af7bd2 ("[POWERPC] MPIC U3/U4 MSI backend") from 2007. Fixes: 05af7bd2 ("[POWERPC] MPIC U3/U4 MSI backend") Reported-by:
Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Kapileshwar Singh authored
commit c2e4b24f upstream. When a trace recorded on a 32-bit device is processed with a 64-bit binary, the higher 32-bits of the address need to ignored. The lack of this results in the output of the 64-bit pointer value to the trace as the 32-bit address lookup fails in find_printk(). Before: burn-1778 [003] 548.600305: bputs: 0xc0046db2s: 2cec5c058d98c After: burn-1778 [003] 548.600305: bputs: 0xc0046db2s: RT throttling activated The problem occurs in PRINT_FIELD when the field is recognized as a pointer to a string (of the type const char *) Heterogeneous architectures cases below can arise and should be handled: * Traces recorded using 32-bit addresses processed on a 64-bit machine * Traces recorded using 64-bit addresses processed on a 32-bit machine Reported-by:
Juri Lelli <juri.lelli@arm.com> Signed-off-by:
Kapileshwar Singh <kapileshwar.singh@arm.com> Reviewed-by:
Steven Rostedt <rostedt@goodmis.org> Cc: David Ahern <dsahern@gmail.com> Cc: Javi Merino <javi.merino@arm.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Link: http://lkml.kernel.org/r/1442928123-13824-1-git-send-email-kapileshwar.singh@arm.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Linus Lüssing authored
commit 53cf037b upstream. The two commits noted below added calls to ip_hdr() and ipv6_hdr(). They need a correctly set skb network header. Unfortunately we cannot rely on the device drivers to set it for us. Therefore setting it in the beginning of the according ndo_start_xmit handler. Fixes: 1d8ab8d3 ("batman-adv: Modified forwarding behaviour for multicast packets") Fixes: ab49886e ("batman-adv: Add IPv4 link-local/IPv6-ll-all-nodes multicast support") Signed-off-by:
Linus Lüssing <linus.luessing@c0d3.blue> Signed-off-by:
Marek Lindner <mareklindner@neomailbox.ch> Signed-off-by:
Antonio Quartulli <antonio@meshcoding.com> Signed-off-by:
-
Linus Lüssing authored
commit 8a4023c5 upstream. So far the mcast tvlv handler did not anticipate the processing of multiple incoming OGMs from the same originator at the same time. This can lead to various issues: * Broken refcounting: For instance two mcast handlers might both assume that an originator just got multicast capabilities and will together wrongly decrease mcast.num_disabled by two, potentially leading to an integer underflow. * Potential kernel panic on hlist_del_rcu(): Two mcast handlers might one after another try to do an hlist_del_rcu(&orig->mcast_want_all_*_node). The second one will cause memory corruption / crashes. (Reported by: Sven Eckelmann <sven@narfation.org>) Right in the beginning the code path makes assumptions about the current multicast related state of an originator and bases all updates on that. The easiest and least error prune way to fix the issues in this case is to serialize multiple mcast handler invocations with a spinlock. Fixes: 60432d75 ("batman-adv: Announce new capability via multicast TVLV") Signed-off-by:
-
Linus Lüssing authored
commit 9c936e3f upstream. Bitwise OR/AND assignments in C aren't guaranteed to be atomic. One OGM handler might undo the set/clear of a specific bit from another handler run in between. Fix this by using the atomic set_bit()/clear_bit()/test_bit() functions. Fixes: 60432d75 ("batman-adv: Announce new capability via multicast TVLV") Signed-off-by:
-
Linus Lüssing authored
commit ac4eebd4 upstream. Bitwise OR/AND assignments in C aren't guaranteed to be atomic. One OGM handler might undo the set/clear of a specific bit from another handler run in between. Fix this by using the atomic set_bit()/clear_bit()/test_bit() functions. Fixes: e17931d1 ("batman-adv: introduce capability initialization bitfield") Signed-off-by:
-
Linus Lüssing authored
commit 4635469f upstream. Bitwise OR/AND assignments in C aren't guaranteed to be atomic. One OGM handler might undo the set/clear of a specific bit from another handler run in between. Fix this by using the atomic set_bit()/clear_bit()/test_bit() functions. Fixes: 3f4841ff ("batman-adv: tvlv - add network coding container") Signed-off-by:
-
Paul Burton authored
commit 7a63076d upstream. The CONFIG_MIPS_MT symbol can be selected by CONFIG_MIPS_VPE_LOADER in addition to CONFIG_MIPS_MT_SMP. We only want MT code in the CPS SMP boot vector if we're using MT for SMP. Thus switch the config symbol we ifdef against to CONFIG_MIPS_MT_SMP. Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/10867/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Paul Burton authored
commit a5b0f6db upstream. The MT-specific code in mips_cps_boot_vpes can safely be omitted from kernels which don't support MT, with the default VPE==0 case being used as it would be after the has_mt (Config3.MT) check failed at runtime. Discarding the code entirely will save us a few bytes & allow cleaner handling of MT ASE instructions by later patches. Signed-off-by:
-
Paul Burton authored
commit 1e5fb282 upstream. The has_mt macro ended with a branch, leaving its callers with a delay slot that would be executed if Config3.MT is not set. However it would not be executed if Config3 (or earlier Config registers) don't exist which makes it somewhat inconsistent at best. Fill the delay slot in the macro & fix the mips_cps_boot_vpes caller appropriately. Signed-off-by:
-
James Hogan authored
commit 53960059 upstream. If there is a DMA zone (usually 24bit = 16MB I believe), but no DMA32 zone, as is the case for some 32-bit kernels, then massage_gfp_flags() will cause DMA memory allocated for devices with a 32..63-bit coherent_dma_mask to fall back to using __GFP_DMA, even though there may only be 32-bits of physical address available anyway. Correct that case to compare against a mask the size of phys_addr_t instead of always using a 64-bit mask. Signed-off-by:
James Hogan <james.hogan@imgtec.com> Fixes: a2e715a8 ("MIPS: DMA: Fix computation of DMA flags from device's coherent_dma_mask.") Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9610/Signed-off-by:
-
Aurelien Jarno authored
commit b259e51f upstream. The rotr, seh and wsbh instructions have been introduced with the R2 ISA. Thus the current BPF code fails to build on pre-R2 little endian CPUs: CC arch/mips/net/bpf_jit.o AS arch/mips/net/bpf_jit_asm.o /home/aurel32/linux-4.2/arch/mips/net/bpf_jit_asm.S: Assembler messages: /home/aurel32/linux-4.2/arch/mips/net/bpf_jit_asm.S:67: Error: opcode not supported on this processor: mips32 (mips32) `wsbh $8,$19' /home/aurel32/linux-4.2/arch/mips/net/bpf_jit_asm.S:68: Error: opcode not supported on this processor: mips32 (mips32) `rotr $19,$8,16' /home/aurel32/linux-4.2/arch/mips/net/bpf_jit_asm.S:83: Error: opcode not supported on this processor: mips32 (mips32) `wsbh $8,$19' /home/aurel32/linux-4.2/arch/mips/net/bpf_jit_asm.S:84: Error: opcode not supported on this processor: mips32 (mips32) `seh $19,$8' /home/aurel32/linux-4.2/arch/mips/net/bpf_jit_asm.S:151: Error: opcode not supported on this processor: mips32 (mips32) `wsbh $8,$12' /home/aurel32/linux-4.2/arch/mips/net/bpf_jit_asm.S:153: Error: opcode not supported on this processor: mips32 (mips32) `rotr $19,$8,16' /home/aurel32/linux-4.2/arch/mips/net/bpf_jit_asm.S:164: Error: opcode not supported on this processor: mips32 (mips32) `wsbh $19,$12' /home/aurel32/linux-4.2/scripts/Makefile.build:294: recipe for target 'arch/mips/net/bpf_jit_asm.o' failed Fix that by providing equivalent code for these CPUs. Signed-off-by:
Aurelien Jarno <aurelien@aurel32.net> Reviewed-by:
Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/11098/Signed-off-by:
-
Aurelien Jarno authored
commit faa9724a upstream. On little endian, avoid generating the big endian version of the code by using #else in addition to #ifdef #endif. Also fix one alignment issue wrt delay slot. Signed-off-by:
-
Alexander Sverdlin authored
commit 88d34269 upstream. Commit a6335fa1 fixed the case with gap between initrd and next usable PFN zone, but broken the case when initrd is combined with usable memory into one region (in add_memory_region()). Restore the fixup initially brought in by f9a7febd. ---- error message ---- Unpacking initramfs... Initramfs unpacking failed: junk in compressed archive BUG: Bad page state in process swapper pfn:00261 page:81004c20 count:0 mapcount:-127 mapping: (null) index:0x2 flags: 0x0() page dumped because: nonzero mapcount CPU: 0 PID: 1 Comm: swapper Not tainted 4.2.0+ #1782 ----------------------- Signed-off-by:
Alexander Sverdlin <alexander.sverdlin@gmail.com> Reported-by:
Tony Wu <tung7970@gmail.com> Tested-by:
-
Guenter Roeck authored
commit fc2ca674 upstream. Commit 3adeb256 ("MIPS: Loongson: Improve LEFI firmware interface") made the number of UARTs dynamic if LEFI_FIRMWARE_INTERFACE is configured. Unfortunately, it did not initialize the number of UARTs if LEFI_FIRMWARE_INTERFACE is not configured. As a result, the Fulong2e system has no console. Fixes: 3adeb256 ("MIPS: Loongson: Improve LEFI firmware interface") Acked-by:
Huacai Chen <chenhc@lemote.com> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
-
Viresh Kumar authored
commit a2022001 upstream. Tolerance applies on both sides of the target voltage, i.e. both min and max sides. But while checking if a voltage is supported by the regulator or not, we haven't taken care of tolerance on the lower side. Fix that. Cc: Lucas Stach <l.stach@pengutronix.de> Fixes: 045ee45c ("cpufreq: cpufreq-dt: disable unsupported OPPs") Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Borislav Petkov authored
commit 2110d70c upstream. Philip Müller reported a hang when booting 32-bit 4.1 kernel on an AMD box. A fragment of the splat was enough to pinpoint the issue: task: f58e0000 ti: f58e8000 task.ti: f58e800 EIP: 0060:[<c135a903>] EFLAGS: 00010206 CPU: 0 EIP is at free_cache_attributes+0x83/0xd0 EAX: 00000001 EBX: f589d46c ECX: 00000090 EDX: 360c2000 ESI: 00000000 EDI: c1724a80 EBP: f58e9ec0 ESP: f58e9ea0 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 CR0: 8005003b CR2: 000000ac CR3: 01731000 CR4: 000006d0 cache_shared_cpu_map_setup() did check sibling CPUs cacheinfo descriptor while the respective teardown path cache_shared_cpu_map_remove() didn't. Fix that. >From tglx's version: to be on the safe side, move the cacheinfo descriptor check to free_cache_attributes(), thus cleaning up the hotplug path a little and making this even more robust. Reported-and-tested-by:
Philip Müller <philm@manjaro.org> Reviewed-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Sudeep Holla <sudeep.holla@arm.com> Cc: Andre Przywara <andre.przywara@arm.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: linux-kernel@vger.kernel.org Cc: manjaro-dev@manjaro.org Cc: Philip Müller <philm@manjaro.org> Link: https://lkml.kernel.org/r/55B47BB8.6080202@manjaro.orgSigned-off-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
-
Thomas Petazzoni authored
commit cfcd2271 upstream. The mv_cesa_queue_req() function calls crypto_enqueue_request() to enqueue a request. In the normal case (i.e the queue isn't full), this function returns -EINPROGRESS. The current Marvell CESA crypto driver takes this into account and cleans up the request only if an error occured, i.e if the return value is not -EINPROGRESS. Unfortunately this causes problems with CRYPTO_TFM_REQ_MAY_BACKLOG-flagged requests. When such a request is passed to crypto_enqueue_request() and the queue is full, crypto_enqueue_request() will return -EBUSY, but will keep the request enqueued nonetheless. This situation was not properly handled by the Marvell CESA driver, which was anyway cleaning up the request in such a situation. When later on the request was taken out of the backlog and actually processed, a kernel crash occured due to the internal driver data structures for this structure having been cleaned up. To avoid this situation, this commit adds a mv_cesa_req_needs_cleanup() helper function which indicates if the request needs to be cleaned up or not after a call to crypto_enqueue_request(). This helper allows to do the cleanup only in the appropriate cases, and all call sites of mv_cesa_queue_req() are fixed to use this new helper function. Reported-by:
Vincent Donnefort <vdonnefort@gmail.com> Fixes: db509a45 ("crypto: marvell/cesa - add TDMA support") Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Yao-Wen Mao authored
commit 8484bf29 upstream. These two headphones need a reset-resume quirk to properly resume to original volume level. Signed-off-by:
Yao-Wen Mao <yaowen@google.com> Signed-off-by:
-
Vincent Palatin authored
commit 72194739 upstream. Add a device quirk for the Logitech PTZ Pro Camera and its sibling the ConferenceCam CC3000e Camera. This fixes the failed camera enumeration on some boot, particularly on machines with fast CPU. Tested by connecting a Logitech PTZ Pro Camera to a machine with a Haswell Core i7-4600U CPU @ 2.10GHz, and doing thousands of reboot cycles while recording the kernel logs and taking camera picture after each boot. Before the patch, more than 7% of the boots show some enumeration transfer failures and in a few of them, the kernel is giving up before actually enumerating the webcam. After the patch, the enumeration has been correct on every reboot. Signed-off-by:
Vincent Palatin <vpalatin@chromium.org> Signed-off-by:
-
Alexander Inyukhin authored
commit 1d5c47f5 upstream. Rng reads in chaoskey driver could return the same data under the certain conditions. Signed-off-by:
Alexander Inyukhin <shurick@sectorb.msk.ru> Signed-off-by:
-
Felipe Balbi authored
commit b0a688dd upstream. since commit 33c300cb ("usb: musb: dsps: don't fake of_node to musb core") we have been preventing CPPI 4.1 from probing due to NULL of_node. We can't revert said commit otherwise a different regression would show up, so the fix is to look for the parent device's (glue layer's) of_node instead, since that's the thing which is actually described in DTS. Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Roger Quadros authored
commit 762982db upstream. The gpio-desc migration done in v4.0 caused a regression with legacy boots due to reversed reset logic. e.g. omap3-beagle USB host breaks on legacy boot. Request the reset GPIO with GPIOF_ACTIVE_LOW flag so that it matches the driver logic and pin behaviour. Fixes: e9f2cefb ("usb: phy: generic: migrate to gpio_desc") Tested-by:
Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
-
Mathias Nyman authored
commit ff30cbc8 upstream. Bits 1:0 of the bmAttributes are used for the burst multiplier. The rest of the bits used to be reserved (zero), but USB3.1 takes bit 7 into use. Use the existing USB_SS_MULT() macro instead to make sure the mult value and hence max packet calculations are correct for USB3.1 devices. Note that burst multiplier in bmAttributes is zero based and that the USB_SS_MULT() macro adds one. Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Peter Chen authored
commit 56ffa1d1 upstream. According to spec, there are functional and protocol stalls. For functional stall, it is for bulk and interrupt endpoints, below are cases for it: - Host sends SET_FEATURE request for Set-Halt, the udc driver needs to set stall, and return true unconditionally. - The gadget driver may call usb_ep_set_halt to stall certain endpoints, if there is a transfer in pending, the udc driver should not set stall, and return -EAGAIN accordingly. These two kinds of stall need to be cleared by host using CLEAR_FEATURE request (Clear-Halt). For protocol stall, it is for control endpoint, this stall will be set if the control request has failed. This stall will be cleared by next setup request (hardware will do it). It fixed usbtest (drivers/usb/misc/usbtest.c) Test 13 "set/clear halt" test failure, meanwhile, this change has been verified by USB2 CV Compliance Test and MSC Tests. Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Felipe Balbi <balbi@ti.com> Signed-off-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
-
Bin Liu authored
commit b8239dcc upstream. Fix the regression caused by commit ad78c918 ("usb: musb: dsps: just start polling already") which causes polling the ID pin status even in device-only mode. Fixes: ad78c918 ("usb: musb: dsps: just start polling already") Signed-off-by:
Bin Liu <b-liu@ti.com> Signed-off-by:
-
Jann Horn authored
commit b7f76ea2 upstream. Signed-off-by:
Jann Horn <jann@thejh.net> Reviewed-by:
Andy Lutomirski <luto@kernel.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Mark Brown authored
commit 176fc2d5 upstream. The in kernel snprintf() will conveniently return the actual length of the printed string even if not given an output beffer at all so just do that rather than relying on the user to pass in a suitable buffer, ensuring that we don't need to worry if the buffer was truncated due to the size of the buffer passed in. Reported-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Mark Brown authored
commit b763ec17 upstream. If a read is attempted which is smaller than the line length then we may underflow the subtraction we're doing with the unsigned size_t type so move some of the calculation to be additions on the right hand side instead in order to avoid this. Reported-by:
-
Gabriel Krisman Bertazi authored
commit e35d7f27 upstream. Remove unnecessary check that disabled SIS pipe commands for SIS-32 devices. This change was sufficient to enable raw mode and send SIS pipe commands for a 57B3 device. Fixes: f8ee25d7 ("ipr: AF DASD raw mode implementation in ipr driver") Signed-off-by:
Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com> Reviewed-by:
Wen Xiong <wenxiong@linux.vnet.ibm.com> Acked-by:
Brian King <brking@linux.vnet.ibm.com> Signed-off-by:
James Bottomley <JBottomley@Odin.com> Signed-off-by:
-
