- 09 Jan, 2017 40 commits
-
-
Nicholas Piggin authored
commit f87f253b upstream. From 80f23935 ("powerpc: Convert cmp to cmpd in idle enter sequence"): PowerPC's "cmp" instruction has four operands. Normally people write "cmpw" or "cmpd" for the second cmp operand 0 or 1. But, frequently people forget, and write "cmp" with just three operands. With older binutils this is silently accepted as if this was "cmpw", while often "cmpd" is wanted. With newer binutils GAS will complain about this for 64-bit code. For 32-bit code it still silently assumes "cmpw" is what is meant. In this case, cmpwi is called for, so this is just a build fix for new toolchains. Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
NeilBrown authored
commit 1cded9d2 upstream. There are two problems with refcounting of auth_gss messages. First, the reference on the pipe->pipe list (taken by a call to rpc_queue_upcall()) is not counted. It seems to be assumed that a message in pipe->pipe will always also be in pipe->in_downcall, where it is correctly reference counted. However there is no guaranty of this. I have a report of a NULL dereferences in rpc_pipe_read() which suggests a msg that has been freed is still on the pipe->pipe list. One way I imagine this might happen is: - message is queued for uid=U and auth->service=S1 - rpc.gssd reads this message and starts processing. This removes the message from pipe->pipe - message is queued for uid=U and auth->service=S2 - rpc.gssd replies to the first message. gss_pipe_downcall() calls __gss_find_upcall(pipe, U, NULL) and it finds the *second* message, as new messages are placed at the head of ->in_downcall, and the service type is not checked. - This second message is removed from ->in_downcall and freed by gss_release_msg() (even though it is still on pipe->pipe) - rpc.gssd tries to read another message, and dereferences a pointer to this message that has just been freed. I fix this by incrementing the reference count before calling rpc_queue_upcall(), and decrementing it if that fails, or normally in gss_pipe_destroy_msg(). It seems strange that the reply doesn't target the message more precisely, but I don't know all the details. In any case, I think the reference counting irregularity became a measureable bug when the extra arg was added to __gss_find_upcall(), hence the Fixes: line below. The second problem is that if rpc_queue_upcall() fails, the new message is not freed. gss_alloc_msg() set the ->count to 1, gss_add_msg() increments this to 2, gss_unhash_msg() decrements to 1, then the pointer is discarded so the memory never gets freed. Fixes: 9130b8db ("SUNRPC: allow for upcalls for same uid but different gss service") Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1011250Signed-off-by:
NeilBrown <neilb@suse.com> Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
Trond Myklebust authored
commit 54e4a0df upstream. We must not call nfs_pageio_init_read() on a new nfs_pageio_descriptor while holding a reference to a layout segment, as that can deadlock pnfs_update_layout(). Fixes: d67ae825 ("pnfs/flexfiles: Add the FlexFile Layout Driver") Signed-off-by:
-
Trond Myklebust authored
commit ae5a459d upstream. We must ensure that we don't schedule a layoutreturn if the layout stateid has been marked as invalid. Fixes: 2a59a041 ("pNFS: Fix pnfs_set_layout_stateid() to clear...") Signed-off-by:
-
Trond Myklebust authored
commit 7b650994 upstream. If we no longer hold any layout segments, we're normally expected to consider the layout stateid to be invalid. However we cannot assume this if we're about to, or in the process of sending a layoutreturn. Fixes: 334a8f37 ("pNFS: Don't forget the layout stateid if...") Signed-off-by:
-
Trond Myklebust authored
commit 6604b203 upstream. If there is an I/O error, we should not call LAYOUTGET until the LAYOUTRETURN that reports the error is complete. Signed-off-by:
-
Al Viro authored
commit c0cf3ef5 upstream. What matters when deciding if we should make a page uptodate is not how much we _wanted_ to copy, but how much we actually have copied. As it is, on architectures that do not zero tail on short copy we can leave uninitialized data in page marked uptodate. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Ilya Dryomov authored
commit 5c056fdc upstream. After sending an authorizer (ceph_x_authorize_a + ceph_x_authorize_b), the client gets back a ceph_x_authorize_reply, which it is supposed to verify to ensure the authenticity and protect against replay attacks. The code for doing this is there (ceph_x_verify_authorizer_reply(), ceph_auth_verify_authorizer_reply() + plumbing), but it is never invoked by the the messenger. AFAICT this goes back to 2009, when ceph authentication protocols support was added to the kernel client in 4e7a5dcd ("ceph: negotiate authentication protocol; implement AUTH_NONE protocol"). The second param of ceph_connection_operations::verify_authorizer_reply is unused all the way down. Pass 0 to facilitate backporting, and kill it in the next commit. Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Reviewed-by:
Sage Weil <sage@redhat.com> Signed-off-by:
-
Alan Stern authored
commit 6496ebd7 upstream. One some systems, the firmware does not allow certain PCI devices to be put in deep D-states. This can cause problems for wakeup signalling, if the device does not support PME# in the deepest allowed suspend state. For example, Pierre reports that on his system, ACPI does not permit his xHCI host controller to go into D3 during runtime suspend -- but D3 is the only state in which the controller can generate PME# signals. As a result, the controller goes into runtime suspend but never wakes up, so it doesn't work properly. USB devices plugged into the controller are never detected. If the device relies on PME# for wakeup signals but is not capable of generating PME# in the target state, the PCI core should accurately report that it cannot do wakeup from runtime suspend. This patch modifies the pci_dev_run_wake() routine to add this check. Reported-by:
Pierre de Villemereuil <flyos@mailoo.org> Tested-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> CC: Lukas Wunner <lukas@wunner.de> Signed-off-by:
-
Shiraz Saleem authored
commit 91c42b72 upstream. hw_stats is a pointer to i40_iw_dev_stats struct in i40iw_get_hw_stats(). Use hw_stats and not &hw_stats in the memcpy to copy the i40iw device stats data into rdma_hw_stats counters. Fixes: b40f4757 ("IB/core: Make device counter infrastructure dynamic") Signed-off-by:
Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by:
Faisal Latif <faisal.latif@intel.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Miklos Szeredi authored
commit 3f9ca755 upstream. New inode operations were forgotten to be added to bad_inode. Most of the time the op is checked for NULL before being called but marking the inode bad and the check can race (very unlikely). However in case of ->get_link() only DCACHE_SYMLINK_TYPE is checked before calling the op, so there's no race and will definitely oops when trying to follow links on such a beast. Also remove comments about extinct ops. Signed-off-by:
Miklos Szeredi <mszeredi@redhat.com> Signed-off-by:
-
Jingkui Wang authored
commit 5a8a6b89 upstream. We were assigning I2C bus controller instead of client as parent device. Besides being logically wrong, it messed up with devm handling of input device. As a result we were leaving input device and event node behind after rmmod-ing the driver, which lead to a kernel oops if one were to access the event node later. Let's remove the assignment and rely on devm_input_allocate_device() to set it up properly for us. Signed-off-by:
Jingkui Wang <jkwang@google.com> Fixes: 7132fe4f ("Input: drv260x - add TI drv260x haptics driver") Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Laurent Pinchart authored
commit d183e4ef upstream. A break is missing resulting in the hue control enabling or disabling the decode completely. Fix it. Fixes: c43875f6 ("[media] tvp5150: replace MEDIA_ENT_F_CONN_TEST by a control") Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
-
Andrey Utkin authored
commit 5fc4b067 upstream. This fixes a lockup at device probing which happens on some solo6010 hardware samples. This is a regression introduced by commit e1ceb25a ("[media] SOLO6x10: remove unneeded register locking and barriers") The observed lockup happens in solo_set_motion_threshold() called from solo_motion_config(). This extra "flushing" is not fundamentally needed for every write, but apparently the code in driver assumes such behaviour at last in some places. Actual fix was proposed by Hans Verkuil. Fixes: e1ceb25a ("[media] SOLO6x10: remove unneeded register locking and barriers") Signed-off-by:
Andrey Utkin <andrey.utkin@corp.bluecherry.net> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Marek Szyprowski authored
commit 3467c9a7 upstream. s5p_mfc_alloc_memdev() function lacks proper releasing of allocated device in case of reserved memory initialization failure. This results in NULL pointer dereference: [ 2.828457] Unable to handle kernel NULL pointer dereference at virtual address 00000001 [ 2.835089] pgd = c0004000 [ 2.837752] [00000001] *pgd=00000000 [ 2.844696] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 2.848680] Modules linked in: [ 2.851722] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.8.0-rc6-00002-gafa1b97 #878 [ 2.859357] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 2.865433] task: ef080000 task.stack: ef06c000 [ 2.869952] PC is at strcmp+0x0/0x30 [ 2.873508] LR is at platform_match+0x84/0xac [ 2.877847] pc : [<c032621c>] lr : [<c03f65e8>] psr: 20000013 [ 2.877847] sp : ef06dea0 ip : 00000000 fp : 00000000 [ 2.889303] r10: 00000000 r9 : c0b34848 r8 : c0b1e968 [ 2.894511] r7 : 00000000 r6 : 00000001 r5 : c086e7fc r4 : eeb8e010 [ 2.901021] r3 : 0000006d r2 : 00000000 r1 : c086e7fc r0 : 00000001 [ 2.907533] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 2.914649] Control: 10c5387d Table: 4000404a DAC: 00000051 [ 2.920378] Process swapper/0 (pid: 1, stack limit = 0xef06c210) [ 2.926367] Stack: (0xef06dea0 to 0xef06e000) [ 2.930711] dea0: eeb8e010 c0c2d91c c03f4a6c c03f4a8c 00000000 c0c2d91c c03f4a6c c03f2fc8 [ 2.938870] dec0: ef003274 ef10c4c0 c0c2d91c ef10cc80 c0c21270 c03f3fa4 c09c1be8 c0c2d91c [ 2.947028] dee0: 00000006 c0c2d91c 00000006 c0b3483c c0c47000 c03f5314 c0c2d908 c0b5fed8 [ 2.955188] df00: 00000006 c010178c 60000013 c0a4ef14 00000000 c06feaa0 ef080000 60000013 [ 2.963347] df20: 00000000 c0c095c8 efffca76 c0816b8c 000000d5 c0134098 c0b34848 c09d6cdc [ 2.971506] df40: c0a4de70 00000000 00000006 00000006 c0c09568 efffca40 c0b5fed8 00000006 [ 2.979665] df60: c0b3483c c0c47000 000000d5 c0b34848 c0b005a4 c0b00d84 00000006 00000006 [ 2.987824] df80: 00000000 c0b005a4 00000000 c06fb4d8 00000000 00000000 00000000 00000000 [ 2.995983] dfa0: 00000000 c06fb4e0 00000000 c01079b8 00000000 00000000 00000000 00000000 [ 3.004142] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 3.012302] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff [ 3.020469] [<c032621c>] (strcmp) from [<c03f65e8>] (platform_match+0x84/0xac) [ 3.027672] [<c03f65e8>] (platform_match) from [<c03f4a8c>] (__driver_attach+0x20/0xb0) [ 3.035654] [<c03f4a8c>] (__driver_attach) from [<c03f2fc8>] (bus_for_each_dev+0x54/0x88) [ 3.043812] [<c03f2fc8>] (bus_for_each_dev) from [<c03f3fa4>] (bus_add_driver+0xe8/0x1f4) [ 3.051971] [<c03f3fa4>] (bus_add_driver) from [<c03f5314>] (driver_register+0x78/0xf4) [ 3.059958] [<c03f5314>] (driver_register) from [<c010178c>] (do_one_initcall+0x3c/0x16c) [ 3.068123] [<c010178c>] (do_one_initcall) from [<c0b00d84>] (kernel_init_freeable+0x120/0x1ec) [ 3.076802] [<c0b00d84>] (kernel_init_freeable) from [<c06fb4e0>] (kernel_init+0x8/0x118) [ 3.084958] [<c06fb4e0>] (kernel_init) from [<c01079b8>] (ret_from_fork+0x14/0x3c) [ 3.092506] Code: 1afffffb e12fff1e e1a03000 eafffff7 (e4d03001) [ 3.098618] ---[ end trace 511bf9d750810709 ]--- [ 3.103207] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b This patch fixes this issue. Fixes: c79667dd ("media: s5p-mfc: replace custom reserved memory handling code with generic one") Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
-
Antti Palosaari authored
commit d930b5b5 upstream. A register used to identify chip during probe was overwritten during firmware download and due to that later probe's for warm chip were failing. Detect chip from the another register, which is located on different register bank 2. Fixes: 7908fad9 ("[media] mn88473: finalize driver") Signed-off-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
-
Antti Palosaari authored
commit 365fe4e0 upstream. A register used to identify chip during probe was overwritten during firmware download and due to that later probe's for warm chip were failing. Detect chip from the another register, which is located on different register bank 2. Fixes: 94d0eaa4 ("[media] mn88472: move out of staging to media") Signed-off-by:
-
Bart Van Assche authored
commit fba332b0 upstream. Code that dereferences the struct net_device ip_ptr member must be protected with an in_dev_get() / in_dev_put() pair. Hence insert calls to these functions. Fixes: commit 7b85627b ("IB/cma: IBoE (RoCE) IP-based GID addressing") Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Reviewed-by:
Moni Shoua <monis@mellanox.com> Cc: Or Gerlitz <ogerlitz@mellanox.com> Cc: Roland Dreier <roland@purestorage.com> Signed-off-by:
-
Bart Van Assche authored
commit e259934d upstream. A socket is associated with every QP by the rxe driver but sock_release() is never called. Add a call to sock_release() in rxe_qp_cleanup(). Fixes: commit 8700e3e7c48A5 ("Add Soft RoCE driver") Signed-off-by:
-
Bart Van Assche authored
commit d3a2418e upstream. This patch avoids that Coverity complains about not checking the ib_find_pkey() return value. Fixes: commit 547af765 ("IB/multicast: Report errors on multicast groups if P_key changes") Signed-off-by:
-
Bart Van Assche authored
commit 11b642b8 upstream. This patch avoids that Coverity reports the following: Using uninitialized value port_attr.state when calling printk Fixes: commit 94232d9c ("IPoIB: Start multicast join process only on active ports") Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
-
Bart Van Assche authored
commit 2fe2f378 upstream. The array ib_mad_mgmt_class_table.method_table has MAX_MGMT_CLASS (80) elements. Hence compare the array index with that value instead of with IB_MGMT_MAX_METHODS (128). This patch avoids that Coverity reports the following: Overrunning array class->method_table of 80 8-byte elements at element index 127 (byte offset 1016) using index convert_mgmt_class(mad_hdr->mgmt_class) (which evaluates to 127). Fixes: commit b7ab0b19 ("IB/mad: Verify mgmt class in received MADs") Signed-off-by:
Hal Rosenstock <hal@mellanox.com> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
commit 794de08a upstream. Both the wakeup and irqsoff tracers can use the function graph tracer when the display-graph option is set. The problem is that they ignore the notrace file, and record the entry of functions that would be ignored by the function_graph tracer. This causes the trace->depth to be recorded into the ring buffer. The set_graph_notrace uses a trick by adding a large negative number to the trace->depth when a graph function is to be ignored. On trace output, the graph function uses the depth to record a stack of functions. But since the depth is negative, it accesses the array with a negative number and causes an out of bounds access that can cause a kernel oops or corrupt data. Have the print functions handle cases where a tracer still records functions even when they are in set_graph_notrace. Also add warnings if the depth is below zero before accessing the array. Note, the function graph logic will still prevent the return of these functions from being recorded, which means that they will be left hanging without a return. For example: # echo '*spin*' > set_graph_notrace # echo 1 > options/display-graph # echo wakeup > current_tracer # cat trace [...] _raw_spin_lock() { preempt_count_add() { do_raw_spin_lock() { update_rq_clock(); Where it should look like: _raw_spin_lock() { preempt_count_add(); do_raw_spin_lock(); } update_rq_clock(); Cc: Namhyung Kim <namhyung.kim@lge.com> Fixes: 29ad23b0 ("ftrace: Add set_graph_notrace filter") Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Thomas Gleixner authored
commit 9d85eb91 upstream. The logical package management has several issues: - The APIC ids provided by ACPI are not required to be the same as the initial APIC id which can be retrieved by CPUID. The APIC ids provided by ACPI are those which are written by the BIOS into the APIC. The initial id is set by hardware and can not be changed. The hardware provided ids contain the real hardware package information. Especially AMD sets the effective APIC id different from the hardware id as they need to reserve space for the IOAPIC ids starting at id 0. As a consequence those machines trigger the currently active firmware bug printouts in dmesg, These are obviously wrong. - Virtual machines have their own interesting of enumerating APICs and packages which are not reliably covered by the current implementation. The sizing of the mapping array has been tweaked to be generously large to handle systems which provide a wrong core count when HT is disabled so the whole magic which checks for space in the physical hotplug case is not needed anymore. Simplify the whole machinery and do the mapping when the CPU starts and the CPUID derived physical package information is available. This solves the observed problems on AMD machines and works for the virtualization issues as well. Remove the extra call from XEN cpu bringup code as it is not longer required. Fixes: d49597fd ("x86/cpu: Deal with broken firmware (VMWare/XEN)") Reported-and-tested-by:
Borislav Petkov <bp@suse.de> Tested-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Juergen Gross <jgross@suse.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: M. Vefa Bicakci <m.v.b@runbox.com> Cc: xen-devel <xen-devel@lists.xen.org> Cc: Charles (Chas) Williams <ciwillia@brocade.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Alok Kataria <akataria@vmware.com> Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1612121102260.3429@nanosSigned-off-by:
-
Marcos Paulo de Souza authored
commit e74e2599 upstream. Without this patch, the Asus X45U wireless card can't be turned on (hard-blocked), but after a suspend/resume it just starts working. Following this bug report[1], there are other cases like this one, but this Asus is the only model that I can test. [1] https://ubuntuforums.org/showthread.php?t=2181558Signed-off-by:
Marcos Paulo de Souza <marcos.souza.org@gmail.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
commit 847fa1a6 upstream. With new binutils, gcc may get smart with its optimization and change a jmp from a 5 byte jump to a 2 byte one even though it was jumping to a global function. But that global function existed within a 2 byte radius, and gcc was able to optimize it. Unfortunately, that jump was also being modified when function graph tracing begins. Since ftrace expected that jump to be 5 bytes, but it was only two, it overwrote code after the jump, causing a crash. This was fixed for x86_64 with commit 8329e818, with the same subject as this commit, but nothing was done for x86_32. Fixes: d61f82d0 ("ftrace: use dynamic patching for updating mcount calls") Reported-by:
Colin Ian King <colin.king@canonical.com> Tested-by:
-
Michael S. Tsirkin authored
commit f83f12d6 upstream. These fields are 64 bit, using le32_to_cpu and friends on these will not do the right thing. Fix this up. Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Jan Kara authored
commit 5716863e upstream. fsnotify_unmount_inodes() plays complex tricks to pin next inode in the sb->s_inodes list when iterating over all inodes. Furthermore the code has a bug that if the current inode is the last on i_sb_list that does not have e.g. I_FREEING set, then we leave next_i pointing to inode which may get removed from the i_sb_list once we drop s_inode_list_lock thus resulting in use-after-free issues (usually manifesting as infinite looping in fsnotify_unmount_inodes()). Fix the problem by keeping current inode pinned somewhat longer. Then we can make the code much simpler and standard. Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Jim Mattson authored
commit ef85b673 upstream. When L2 exits to L0 due to "exception or NMI", software exceptions (#BP and #OF) for which L1 has requested an intercept should be handled by L1 rather than L0. Previously, only hardware exceptions were forwarded to L1. Signed-off-by:
Jim Mattson <jmattson@google.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Paul Mackerras authored
commit f064a0de upstream. The hashed page table MMU in POWER processors can update the R (reference) and C (change) bits in a HPTE at any time until the HPTE has been invalidated and the TLB invalidation sequence has completed. In kvmppc_h_protect, which implements the H_PROTECT hypercall, we read the HPTE, modify the second doubleword, invalidate the HPTE in memory, do the TLB invalidation sequence, and then write the modified value of the second doubleword back to memory. In doing so we could overwrite an R/C bit update done by hardware between when we read the HPTE and when the TLB invalidation completed. To fix this we re-read the second doubleword after the TLB invalidation and OR in the (possibly) new values of R and C. We can use an OR since hardware only ever sets R and C, never clears them. This race was found by code inspection. In principle this bug could cause occasional guest memory corruption under host memory pressure. Fixes: a8606e20 ("KVM: PPC: Handle some PAPR hcalls in the kernel", 2011-06-29) Signed-off-by:
Paul Mackerras <paulus@ozlabs.org> Signed-off-by:
-
Paul Mackerras authored
commit 0d808df0 upstream. When switching from/to a guest that has a transaction in progress, we need to save/restore the checkpointed register state. Although XER is part of the CPU state that gets checkpointed, the code that does this saving and restoring doesn't save/restore XER. This fixes it by saving and restoring the XER. To allow userspace to read/write the checkpointed XER value, we also add a new ONE_REG specifier. The visible effect of this bug is that the guest may see its XER value being corrupted when it uses transactions. Fixes: e4e38121 ("KVM: PPC: Book3S HV: Add transactional memory support") Fixes: 0a8eccef ("KVM: PPC: Book3S HV: Add missing code for transaction reclaim on guest exit") Signed-off-by:
Thomas Huth <thuth@redhat.com> Signed-off-by:
-
Kevin Barnett authored
commit ae2aae24 upstream. Controllers with this PCI ID never shipped outside of PMCS/Microsemi. Remove the ID from the aacraid driver. smartpqi is the correct driver for these controllers. [mkp: patch description] Reviewed-by:
Scott Teel <scott.teel@microsemi.com> Signed-off-by:
Kevin Barnett <kevin.barnett@microsemi.com> Signed-off-by:
Don Brace <don.brace@microsemi.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Konstantin Khlebnikov authored
commit e8d7c332 upstream. Current implementation employ 16bit counter of active stripes in lower bits of bio->bi_phys_segments. If request is big enough to overflow this counter bio will be completed and freed too early. Fortunately this not happens in default configuration because several other limits prevent that: stripe_cache_size * nr_disks effectively limits count of active stripes. And small max_sectors_kb at lower disks prevent that during normal read/write operations. Overflow easily happens in discard if it's enabled by module parameter "devices_handle_discard_safely" and stripe_cache_size is set big enough. This patch limits requests size with 256Mb - 8Kb to prevent overflows. Signed-off-by:
Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Cc: Shaohua Li <shli@kernel.org> Cc: Neil Brown <neilb@suse.com> Signed-off-by:
Shaohua Li <shli@fb.com> Signed-off-by:
-
Josh Cartwright authored
commit 04da7380 upstream. The use of IRQF_ONESHOT when registering an interrupt handler with request_irq() is non-sensical. Not only that, it also prevents the handler from being threaded when it otherwise should be w/ IRQ_FORCED_THREADING is enabled. This causes the following deadlock observed by Sean Nyekjaer on -rt: Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM [..] rt_spin_lock_slowlock from queue_kthread_work queue_kthread_work from sc16is7xx_irq sc16is7xx_irq [sc16is7xx] from handle_irq_event_percpu handle_irq_event_percpu from handle_irq_event handle_irq_event from handle_level_irq handle_level_irq from generic_handle_irq generic_handle_irq from mxc_gpio_irq_handler mxc_gpio_irq_handler from mx3_gpio_irq_handler mx3_gpio_irq_handler from generic_handle_irq generic_handle_irq from __handle_domain_irq __handle_domain_irq from gic_handle_irq gic_handle_irq from __irq_svc __irq_svc from rt_spin_unlock rt_spin_unlock from kthread_worker_fn kthread_worker_fn from kthread kthread from ret_from_fork Fixes: 9e6f4ca3 ("sc16is7xx: use kthread_worker for tx_work and irq") Reported-by:
Sean Nyekjaer <sean.nyekjaer@prevas.dk> Signed-off-by:
Josh Cartwright <joshc@ni.com> Cc: linux-rt-users@vger.kernel.org Cc: Jakub Kicinski <moorray3@wp.pl> Cc: linux-serial@vger.kernel.org Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
Julia Cartwright <julia@ni.com> Acked-by:
Jakub Kicinski <kubakici@wp.pl> Signed-off-by:
-
Kees Cook authored
commit 9988f4d5 upstream. This fixes build errors seen on gcc-4.9.3 or gcc-5.3.1 for an ARM: arm-soc/init/initramfs.c: In function 'error': arm-soc/init/initramfs.c:50:1: error: unrecognizable insn: } ^ (insn 26 25 27 5 (set (reg:SI 111 [ local_entropy.243 ]) (rotatert:SI (reg:SI 116 [ local_entropy.243 ]) (const_int -30 [0xffffffffffffffe2]))) -1 (nil)) Patch from PaX Team <pageexec@freemail.hu> Reported-by:
Arnd Bergmann <arnd@arndb.de> Reported-by:
Brad Spengler <spender@grsecurity.net> Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Marc Zyngier authored
commit 21cbe3cc upstream. The ARMv8 architecture allows the cycle counter to be configured by setting PMSELR_EL0.SEL==0x1f and then accessing PMXEVTYPER_EL0, hence accessing PMCCFILTR_EL0. But it disallows the use of PMSELR_EL0.SEL==0x1f to access the cycle counter itself through PMXEVCNTR_EL0. Linux itself doesn't violate this rule, but we may end up with PMSELR_EL0.SEL being set to 0x1f when we enter a guest. If that guest accesses PMXEVCNTR_EL0, the access may UNDEF at EL1, despite the guest not having done anything wrong. In order to avoid this unfortunate course of events (haha!), let's sanitize PMSELR_EL0 on guest entry. This ensures that the guest won't explode unexpectedly. Acked-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
-
Heiko Carstens authored
commit 9f88eb4d upstream. When re-adding crash kernel memory within setup_resources() the function memblock_add() is used. That function will add memory by default to node "MAX_NUMNODES" instead of node 0, like the memory detection code does. In case of !NUMA this will trigger this warning when the kernel generates the vmemmap: Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead WARNING: CPU: 0 PID: 0 at mm/memblock.c:1261 memblock_virt_alloc_internal+0x76/0x220 CPU: 0 PID: 0 Comm: swapper Not tainted 4.9.0-rc6 #16 Call Trace: [<0000000000d0b2e8>] memblock_virt_alloc_try_nid+0x88/0xc8 [<000000000083c8ea>] __earlyonly_bootmem_alloc.constprop.1+0x42/0x50 [<000000000083e7f4>] vmemmap_populate+0x1ac/0x1e0 [<0000000000840136>] sparse_mem_map_populate+0x46/0x68 [<0000000000d0c59c>] sparse_init+0x184/0x238 [<0000000000cf45f6>] paging_init+0xbe/0xf8 [<0000000000cf1d4a>] setup_arch+0xa02/0xae0 [<0000000000ced75a>] start_kernel+0x72/0x450 [<0000000000100020>] _stext+0x20/0x80 If NUMA is selected numa_setup_memory() will fix the node assignments before the vmemmap will be populated; so this warning will only appear if NUMA is not selected. To fix this simply use memblock_add_node() and re-add crash kernel memory explicitly to node 0. Reported-and-tested-by:
Christian Borntraeger <borntraeger@de.ibm.com> Fixes: 4e042af4 ("s390/kexec: fix crash on resize of reserved memory") Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Gerald Schaefer authored
commit 5457e03d upstream. The buffer for iucv_message_receive() needs to be below 2 GB. In __iucv_message_receive(), the buffer address is casted to an u32, which would result in either memory corruption or an addressing exception when using addresses >= 2 GB. Fix this by using GFP_DMA for the buffer allocation. Signed-off-by:
Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by:
-
Yves-Alexis Perez authored
commit 2e700f8d upstream. When you use the firmware usermode helper fallback with a timeout value set to a value greater than INT_MAX (2147483647) a cast overflow issue causes the timeout value to go negative and breaks all usermode helper loading. This regression was introduced through commit 68ff2a00 ("firmware_loader: handle timeout via wait_for_completion_interruptible_timeout()") on kernel v4.0. The firmware_class drivers relies on the firmware usermode helper fallback as a mechanism to look for firmware if the direct filesystem search failed only if: a) You've enabled CONFIG_FW_LOADER_USER_HELPER_FALLBACK (not many distros): Then all of these callers will rely on the fallback mechanism in case the firmware is not found through an initial direct filesystem lookup: o request_firmware() o request_firmware_into_buf() o request_firmware_nowait() b) If you've only enabled CONFIG_FW_LOADER_USER_HELPER (most distros): Then only callers using request_firmware_nowait() with the second argument set to false, this explicitly is requesting the UMH firmware fallback to be relied on in case the first filesystem lookup fails. Using Coccinelle SmPL grammar we have identified only two drivers explicitly requesting the UMH firmware fallback mechanism: - drivers/firmware/dell_rbu.c - drivers/leds/leds-lp55xx-common.c Since most distributions only enable CONFIG_FW_LOADER_USER_HELPER the biggest impact of this regression are users of the dell_rbu and leds-lp55xx-common device driver which required the UMH to find their respective needed firmwares. The default timeout for the UMH is set to 60 seconds always, as of commit 68ff2a00 ("firmware_loader: handle timeout via wait_for_completion_interruptible_timeout()") the timeout was bumped to MAX_JIFFY_OFFSET ((LONG_MAX >> 1)-1). Additionally the MAX_JIFFY_OFFSET value was also used if the timeout was configured by a user to 0. The following works: echo 2147483647 > /sys/class/firmware/timeout But both of the following set the timeout to MAX_JIFFY_OFFSET even if we display 0 back to userspace: echo 2147483648 > /sys/class/firmware/timeout cat /sys/class/firmware/timeout 0 echo 0> /sys/class/firmware/timeout cat /sys/class/firmware/timeout 0 A max value of INT_MAX (2147483647) seconds is therefore implicit due to the another cast with simple_strtol(). This fixes the secondary cast (the first one is simple_strtol() but its an issue only by forcing an implicit limit) by re-using the timeout variable and only setting retval in appropriate cases. Lastly worth noting systemd had ripped out the UMH firmware fallback mechanism from udev since udev 2014 via commit be2ea723b1d023b3d ("udev: remove userspace firmware loading support"), so as of systemd v217. Signed-off-by:
Yves-Alexis Perez <corsac@corsac.net> Fixes: 68ff2a00 "firmware_loader: handle timeout via wait_for_completion_interruptible_timeout()" Cc: Luis R. Rodriguez <mcgrof@kernel.org> Cc: Ming Lei <ming.lei@canonical.com> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by:
Luis R. Rodriguez <mcgrof@kernel.org> Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> [mcgrof@kernel.org: gave commit log a whole lot of love] Signed-off-by:
-
Vineet Gupta authored
commit 08fe0079 upstream. An ARC700 customer reported linux boot crashes when upgrading to bigger L1 dcache (64K from 32K). Turns out they had an aliasing VIPT config and current code only assumed 2 colours, while theirs had 4. So default to 4 colours and complain if there are fewer. Ideally this needs to be a Kconfig option, but heck that's too much of hassle for a single user. Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
