- Feb 02, 2022
-
-
Christophe Leroy authored
commit bba49665 upstream. Boot fails with GCC latent entropy plugin enabled. This is due to early boot functions trying to access 'latent_entropy' global data while the kernel is not relocated at its final destination yet. As there is no way to tell GCC to use PTRRELOC() to access it, disable latent entropy plugin in early_32.o and feature-fixups.o and code-patching.o Fixes: 38addce8 ("gcc-plugins: Add latent_entropy plugin") Cc: stable@vger.kernel.org # v4.9+ Reported-by:
Erhard Furtner <erhard_f@mailbox.org> Signed-off-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://bugzilla.kernel.org/show_bug.cgi?id=215217 Link: https://lore.kernel.org/r/2bac55483b8daf5b1caa163a45fa5f9cdbe18be4.1640178426.git.christophe.leroy@csgroup.eu Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Marek Behún authored
commit 2148927e upstream. Commit ce0aa27f ("sfp: add sfp-bus to bridge between network devices and sfp cages") added code which finds SFP bus DT node even if the node is disabled with status = "disabled". Because of this, when phylink is created, it ends with non-null .sfp_bus member, even though the SFP module is not probed (because the node is disabled). We need to ignore disabled SFP bus node. Fixes: ce0aa27f ("sfp: add sfp-bus to bridge between network devices and sfp cages") Signed-off-by:
Marek Behún <kabel@kernel.org> Cc: stable@vger.kernel.org # 2203cbf2 ("net: sfp: move fwnode parsing into sfp-bus layer") Signed-off-by:
David S. Miller <davem@davemloft.net> [ backport to 5.4 ] Signed-off-by:
Marek Behún <kabel@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sing-Han Chen authored
commit 82591149 upstream. CCGx clears Bit 0:Device Interrupt in the INTR_REG if CCGx is reset successfully. However, there might be a chance that other bits in INTR_REG are not cleared due to internal data queued in PPM. This case misleads the driver that CCGx reset failed. The commit checks bit 0 in INTR_REG and ignores other bits. The ucsi driver would reset PPM later. Fixes: 247c554a ("usb: typec: ucsi: add support for Cypress CCGx") Cc: stable@vger.kernel.org Reviewed-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
Sing-Han Chen <singhanc@nvidia.com> Signed-off-by:
Wayne Chang <waynec@nvidia.com> Link: https://lore.kernel.org/r/20220112094143.628610-1-waynec@nvidia.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Badhri Jagan Sridharan authored
commit 90b8aa9f upstream. With some chargers, vbus might momentarily raise above VSAFE5V and fall back to 0V before tcpm gets to read port->tcpc->get_vbus. This will will report a VBUS off event causing TCPM to transition to SNK_UNATTACHED where it should be waiting in either SNK_ATTACH_WAIT or SNK_DEBOUNCED state. This patch makes TCPM avoid vbus off events while in SNK_ATTACH_WAIT or SNK_DEBOUNCED state. Stub from the spec: "4.5.2.2.4.2 Exiting from AttachWait.SNK State A Sink shall transition to Unattached.SNK when the state of both the CC1 and CC2 pins is SNK.Open for at least tPDDebounce. A DRP shall transition to Unattached.SRC when the state of both the CC1 and CC2 pins is SNK.Open for at least tPDDebounce." [23.194131] CC1: 0 -> 0, CC2: 0 -> 5 [state SNK_UNATTACHED, polarity 0, connected] [23.201777] state change SNK_UNATTACHED -> SNK_ATTACH_WAIT [rev3 NONE_AMS] [23.209949] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 170 ms [rev3 NONE_AMS] [23.300579] VBUS off [23.300668] state change SNK_ATTACH_WAIT -> SNK_UNATTACHED [rev3 NONE_AMS] [23.301014] VBUS VSAFE0V [23.301111] Start toggling Fixes: f0690a25 ("staging: typec: USB Type-C Port Manager (tcpm)") Cc: stable@vger.kernel.org Acked-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
Badhri Jagan Sridharan <badhri@google.com> Link: https://lore.kernel.org/r/20220122015520.332507-1-badhri@google.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Alan Stern authored
commit 26fbe977 upstream. The syzbot fuzzer has identified a bug in which processes hang waiting for usb_kill_urb() to return. It turns out the issue is not unlinking the URB; that works just fine. Rather, the problem arises when the wakeup notification that the URB has completed is not received. The reason is memory-access ordering on SMP systems. In outline form, usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on different CPUs perform the following actions: CPU 0 CPU 1 ---------------------------- --------------------------------- usb_kill_urb(): __usb_hcd_giveback_urb(): ... ... atomic_inc(&urb->reject); atomic_dec(&urb->use_count); ... ... wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0); if (atomic_read(&urb->reject)) wake_up(&usb_kill_urb_queue); Confining your attention to urb->reject and urb->use_count, you can see that the overall pattern of accesses on CPU 0 is: write urb->reject, then read urb->use_count; whereas the overall pattern of accesses on CPU 1 is: write urb->use_count, then read urb->reject. This pattern is referred to in memory-model circles as SB (for "Store Buffering"), and it is well known that without suitable enforcement of the desired order of accesses -- in the form of memory barriers -- it is entirely possible for one or both CPUs to execute their reads ahead of their writes. The end result will be that sometimes CPU 0 sees the old un-decremented value of urb->use_count while CPU 1 sees the old un-incremented value of urb->reject. Consequently CPU 0 ends up on the wait queue and never gets woken up, leading to the observed hang in usb_kill_urb(). The same pattern of accesses occurs in usb_poison_urb() and the failure pathway of usb_hcd_submit_urb(). The problem is fixed by adding suitable memory barriers. To provide proper memory-access ordering in the SB pattern, a full barrier is required on both CPUs. The atomic_inc() and atomic_dec() accesses themselves don't provide any memory ordering, but since they are present, we can use the optimized smp_mb__after_atomic() memory barrier in the various routines to obtain the desired effect. This patch adds the necessary memory barriers. CC: <stable@vger.kernel.org> Reported-and-tested-by:
<syzbot+76629376e06e2c2ad626@syzkaller.appspotmail.com> Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/Ye8K0QYee0Q0Nna2@rowland.harvard.edu Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Pavankumar Kondeti authored
commit 904edf8a upstream. Currently when gadget enumerates in super speed plus, the isoc endpoint request buffer size is not calculated correctly. Fix this by checking the gadget speed against USB_SPEED_SUPER_PLUS and update the request buffer size. Fixes: 90c4d057 ("usb: fix various gadgets null ptr deref on 10gbps cabling.") Cc: stable <stable@vger.kernel.org> Signed-off-by:
Pavankumar Kondeti <quic_pkondeti@quicinc.com> Link: https://lore.kernel.org/r/1642820602-20619-1-git-send-email-quic_pkondeti@quicinc.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jon Hunter authored
commit 2e3dd4a6 upstream. Commit 7495af93 ("ARM: multi_v7_defconfig: Enable drivers for DragonBoard 410c") enables the CONFIG_PHY_QCOM_USB_HS for the ARM multi_v7_defconfig. Enabling this Kconfig is causing the kernel to crash on the Tegra20 Ventana platform in the ulpi_match() function. The Qualcomm USB HS PHY driver that is enabled by CONFIG_PHY_QCOM_USB_HS, registers a ulpi_driver but this driver does not provide an 'id_table', so when ulpi_match() is called on the Tegra20 Ventana platform, it crashes when attempting to deference the id_table pointer which is not valid. The Qualcomm USB HS PHY driver uses device-tree for matching the ULPI driver with the device and so fix this crash by using device-tree for matching if the id_table is not valid. Fixes: ef6a7bcf ("usb: ulpi: Support device discovery via DT") Cc: stable <stable@vger.kernel.org> Signed-off-by:
Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20220117150039.44058-1-jonathanh@nvidia.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Alan Stern authored
commit 5b67b315 upstream. Two people have reported (and mentioned numerous other reports on the web) that VIA's VL817 USB-SATA bridge does not work with the uas driver. Typical log messages are: [ 3606.232149] sd 14:0:0:0: [sdg] tag#2 uas_zap_pending 0 uas-tag 1 inflight: CMD [ 3606.232154] sd 14:0:0:0: [sdg] tag#2 CDB: Write(16) 8a 00 00 00 00 00 18 0c c9 80 00 00 00 80 00 00 [ 3606.306257] usb 4-4.4: reset SuperSpeed Plus Gen 2x1 USB device number 11 using xhci_hcd [ 3606.328584] scsi host14: uas_eh_device_reset_handler success Surprisingly, the devices do seem to work okay for some other people. The cause of the differing behaviors is not known. In the hope of getting the devices to work for the most users, even at the possible cost of degraded performance for some, this patch adds an unusual_devs entry for the VL817 to block it from binding to the uas driver by default. Users will be able to override this entry by means of a module parameter, if they want. CC: <stable@vger.kernel.org> Reported-by:
DocMAX <mail@vacharakis.de> Reported-and-tested-by:
Thomas Weißschuh <linux@weissschuh.net> Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/Ye8IsK2sjlEv1rqU@rowland.harvard.edu Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Cameron Williams authored
commit 152d1afa upstream. This commit adds support for the some of the Brainboxes PCI range of cards, including the UC-101, UC-235/246, UC-257, UC-268, UC-275/279, UC-302, UC-310, UC-313, UC-320/324, UC-346, UC-357, UC-368 and UC-420/431. Signed-off-by:
Cameron Williams <cang1@live.co.uk> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/AM5PR0202MB2564688493F7DD9B9C610827C45E9@AM5PR0202MB2564.eurprd02.prod.outlook.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
daniel.starke@siemens.com authored
commit 8838b2af upstream. n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010. See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516 The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to the newer 27.010 here. Chapter 5.2.7.3 states that DC1 (XON) and DC3 (XOFF) are the control characters defined in ISO/IEC 646. These shall be quoted if seen in the data stream to avoid interpretation as flow control characters. ISO/IEC 646 refers to the set of ISO standards described as the ISO 7-bit coded character set for information interchange. Its final version is also known as ITU T.50. See https://www.itu.int/rec/T-REC-T.50-199209-I/en To abide the standard it is needed to quote DC1 and DC3 correctly if these are seen as data bytes and not as control characters. The current implementation already tries to enforce this but fails to catch all defined cases. 3GPP 27.010 chapter 5.2.7.3 clearly states that the most significant bit shall be ignored for DC1 and DC3 handling. The current implementation handles only the case with the most significant bit set 0. Cases in which DC1 and DC3 have the most significant bit set 1 are left unhandled. This patch fixes this by masking the data bytes with ISO_IEC_646_MASK (only the 7 least significant bits set 1) before comparing them with XON (a.k.a. DC1) and XOFF (a.k.a. DC3) when testing which byte values need quotation via byte stuffing. Fixes: e1eaea46 ("tty: n_gsm line discipline") Cc: stable@vger.kernel.org Signed-off-by:
Daniel Starke <daniel.starke@siemens.com> Link: https://lore.kernel.org/r/20220120101857.2509-1-daniel.starke@siemens.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Valentin Caron authored
commit 037b91ec upstream. x_char is ignored by stm32_usart_start_tx() when xmit buffer is empty. Fix start_tx condition to allow x_char to be sent. Fixes: 48a6092f ("serial: stm32-usart: Add STM32 USART Driver") Cc: stable <stable@vger.kernel.org> Signed-off-by:
Erwan Le Ray <erwan.leray@foss.st.com> Signed-off-by:
Valentin Caron <valentin.caron@foss.st.com> Link: https://lore.kernel.org/r/20220111164441.6178-3-valentin.caron@foss.st.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Robert Hancock authored
commit d06b1cf2 upstream. 8250_of supports a reg-offset property which is intended to handle cases where the device registers start at an offset inside the region of memory allocated to the device. The Xilinx 16550 UART, for which this support was initially added, requires this. However, the code did not adjust the overall size of the mapped region accordingly, causing the driver to request an area of memory past the end of the device's allocation. For example, if the UART was allocated an address of 0xb0130000, size of 0x10000 and reg-offset of 0x1000 in the device tree, the region of memory reserved was b0131000-b0140fff, which caused the driver for the region starting at b0140000 to fail to probe. Fix this by subtracting reg-offset from the mapped region size. Fixes: b912b5e2 ([POWERPC] Xilinx: of_serial support for Xilinx uart 16550.) Cc: stable <stable@vger.kernel.org> Signed-off-by:
Robert Hancock <robert.hancock@calian.com> Link: https://lore.kernel.org/r/20220112194214.881844-1-robert.hancock@calian.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Pablo Neira Ayuso authored
commit 4e1860a3 upstream. IP fragments do not come with the transport header, hence skip bogus layer 4 checksum updates. Fixes: 18140969 ("netfilter: nft_payload: layer 4 checksum adjustment for pseudoheader fields") Reported-and-tested-by:
Steffen Weinreich <steve@weinreich.org> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
D Scott Phillips authored
commit 38e0257e upstream. The erratum 1418040 workaround enables CNTVCT_EL1 access trapping in EL0 when executing compat threads. The workaround is applied when switching between tasks, but the need for the workaround could also change at an exec(), when a non-compat task execs a compat binary or vice versa. Apply the workaround in arch_setup_new_exec(). This leaves a small window of time between SET_PERSONALITY and arch_setup_new_exec where preemption could occur and confuse the old workaround logic that compares TIF_32BIT between prev and next. Instead, we can just read cntkctl to make sure it's in the state that the next task needs. I measured cntkctl read time to be about the same as a mov from a general-purpose register on N1. Update the workaround logic to examine the current value of cntkctl instead of the previous task's compat state. Fixes: d49f7d73 ("arm64: Move handling of erratum 1418040 into C code") Cc: <stable@vger.kernel.org> # 5.9.x Signed-off-by:
D Scott Phillips <scott@os.amperecomputing.com> Reviewed-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211220234114.3926-1-scott@os.amperecomputing.com Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Lucas Stach authored
commit e3d26528 upstream. While all userspace tried to limit commandstreams to 64K in size, a bug in the Mesa driver lead to command streams of up to 128K being submitted. Allow those to avoid breaking existing userspace. Fixes: 6dfa2fab ("drm/etnaviv: limit submit sizes") Cc: stable@vger.kernel.org Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Reviewed-by:
Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Amir Goldstein authored
commit 29044dae upstream. Commit 49246466 ("fsnotify: move fsnotify_nameremove() hook out of d_delete()") moved the fsnotify delete hook before d_delete() so fsnotify will have access to a positive dentry. This allowed a race where opening the deleted file via cached dentry is now possible after receiving the IN_DELETE event. To fix the regression in pseudo filesystems, convert d_delete() calls to d_drop() (see commit 46c46f8d ("devpts_pty_kill(): don't bother with d_delete()") and move the fsnotify hook after d_drop(). Add a missing fsnotify_unlink() hook in nfsdfs that was found during the audit of fsnotify hooks in pseudo filesystems. Note that the fsnotify hooks in simple_recursive_removal() follow d_invalidate(), so they require no change. Link: https://lore.kernel.org/r/20220120215305.282577-2-amir73il@gmail.com Reported-by:
Ivan Delalande <colona@arista.com> Link: https://lore.kernel.org/linux-fsdevel/YeNyzoDM5hP5LtGW@visor/ Fixes: 49246466 ("fsnotify: move fsnotify_nameremove() hook out of d_delete()") Cc: stable@vger.kernel.org # v5.3+ Signed-off-by:
Amir Goldstein <amir73il@gmail.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tom Zanussi authored
commit 67ab5eb7 upstream. tr->n_err_log_entries should only be increased if entry allocation succeeds. Doing it when it fails won't cause any problems other than wasting an entry, but should be fixed anyway. Link: https://lkml.kernel.org/r/cad1ab28f75968db0f466925e7cba5970cec6c29.1643319703.git.zanussi@kernel.org Cc: stable@vger.kernel.org Fixes: 2f754e77 ("tracing: Don't inc err_log entry count if entry allocation fails") Signed-off-by:
Tom Zanussi <zanussi@kernel.org> Signed-off-by:
Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Xiaoke Wang authored
commit e629e7b5 upstream. kfree() is missing on an error path to free the memory allocated by kstrdup(): p = param = kstrdup(data->params[i], GFP_KERNEL); So it is better to free it via kfree(p). Link: https://lkml.kernel.org/r/tencent_C52895FD37802832A3E5B272D05008866F0A@qq.com Cc: stable@vger.kernel.org Fixes: d380dcde ("tracing: Fix now invalid var_ref_vals assumption in trace action") Signed-off-by:
Xiaoke Wang <xkernel.wang@foxmail.com> Signed-off-by:
Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
commit c9d967b2 upstream. The buffer handling in pm_show_wakelocks() is tricky, and hopefully correct. Ensure it really is correct by using sysfs_emit_at() which handles all of the tricky string handling logic in a PAGE_SIZE buffer for us automatically as this is a sysfs file being read from. Reviewed-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jan Kara authored
commit 7fc3b7c2 upstream. udf_expand_file_adinicb() calls directly ->writepage to write data expanded into a page. This however misses to setup inode for writeback properly and so we can crash on inode->i_wb dereference when submitting page for IO like: BUG: kernel NULL pointer dereference, address: 0000000000000158 #PF: supervisor read access in kernel mode ... <TASK> __folio_start_writeback+0x2ac/0x350 __block_write_full_page+0x37d/0x490 udf_expand_file_adinicb+0x255/0x400 [udf] udf_file_write_iter+0xbe/0x1b0 [udf] new_sync_write+0x125/0x1c0 vfs_write+0x28e/0x400 Fix the problem by marking the page dirty and going through the standard writeback path to write the page. Strictly speaking we would not even have to write the page but we want to catch e.g. ENOSPC errors early. Reported-by:
butt3rflyh4ck <butterflyhuangxx@gmail.com> CC: stable@vger.kernel.org Fixes: 52ebea74 ("writeback: make backing_dev_info host cgroup-specific bdi_writebacks") Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jan Kara authored
commit ea856919 upstream. When we fail to expand inode from inline format to a normal format, we restore inode to contain the original inline formatting but we forgot to set i_lenAlloc back. The mismatch between i_lenAlloc and i_size was then causing further problems such as warnings and lost data down the line. Reported-by:
butt3rflyh4ck <butterflyhuangxx@gmail.com> CC: stable@vger.kernel.org Fixes: 7e49b6f2 ("udf: Convert UDF to new truncate calling sequence") Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Steffen Maier authored
commit 8c9db667 upstream. Suppose we have an environment with a number of non-NPIV FCP devices (virtual HBAs / FCP devices / zfcp "adapter"s) sharing the same physical FCP channel (HBA port) and its I_T nexus. Plus a number of storage target ports zoned to such shared channel. Now one target port logs out of the fabric causing an RSCN. Zfcp reacts with an ADISC ELS and subsequent port recovery depending on the ADISC result. This happens on all such FCP devices (in different Linux images) concurrently as they all receive a copy of this RSCN. In the following we look at one of those FCP devices. Requests other than FSF_QTCB_FCP_CMND can be slow until they get a response. Depending on which requests are affected by slow responses, there are different recovery outcomes. Here we want to fix failed recoveries on port or adapter level by avoiding recovery requests that can be slow. We need the cached N_Port_ID for the remote port "link" test with ADISC. Just before sending the ADISC, we now intentionally forget the old cached N_Port_ID. The idea is that on receiving an RSCN for a port, we have to assume that any cached information about this port is stale. This forces a fresh new GID_PN [FC-GS] nameserver lookup on any subsequent recovery for the same port. Since we typically can still communicate with the nameserver efficiently, we now reach steady state quicker: Either the nameserver still does not know about the port so we stop recovery, or the nameserver already knows the port potentially with a new N_Port_ID and we can successfully and quickly perform open port recovery. For the one case, where ADISC returns successfully, we re-initialize port->d_id because that case does not involve any port recovery. This also solves a problem if the storage WWPN quickly logs into the fabric again but with a different N_Port_ID. Such as on virtual WWPN takeover during target NPIV failover. [https://www.redbooks.ibm.com/abstracts/redp5477.html] In that case the RSCN from the storage FDISC was ignored by zfcp and we could not successfully recover the failover. On some later failback on the storage, we could have been lucky if the virtual WWPN got the same old N_Port_ID from the SAN switch as we still had cached. Then the related RSCN triggered a successful port reopen recovery. However, there is no guarantee to get the same N_Port_ID on NPIV FDISC. Even though NPIV-enabled FCP devices are not affected by this problem, this code change optimizes recovery time for gone remote ports as a side effect. The timely drop of cached N_Port_IDs prevents unnecessary slow open port attempts. While the problem might have been in code before v2.6.32 commit 799b76d0 ("[SCSI] zfcp: Decouple gid_pn requests from erp") this fix depends on the gid_pn_work introduced with that commit, so we mark it as culprit to satisfy fix dependencies. Note: Point-to-point remote port is already handled separately and gets its N_Port_ID from the cached peer_d_id. So resetting port->d_id in general does not affect PtP. Link: https://lore.kernel.org/r/20220118165803.3667947-1-maier@linux.ibm.com Fixes: 799b76d0 ("[SCSI] zfcp: Decouple gid_pn requests from erp") Cc: <stable@vger.kernel.org> #2.6.32+ Suggested-by:
Benjamin Block <bblock@linux.ibm.com> Reviewed-by:
Benjamin Block <bblock@linux.ibm.com> Signed-off-by:
Steffen Maier <maier@linux.ibm.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Vasily Gorbik authored
commit 663d34c8 upstream. Currently if z/VM guest is allowed to retrieve hypervisor performance data globally for all guests (privilege class B) the query is formed in a way to include all guests but the group name is left empty. This leads to that z/VM guests which have access control group set not being included in the results (even local vm). Change the query group identifier from empty to "any" to retrieve information about all guests from any groups (or without a group set). Cc: stable@vger.kernel.org Fixes: 31cb4bd3 ("[S390] Hypervisor filesystem (s390_hypfs) for z/VM") Reviewed-by:
Gerald Schaefer <gerald.schaefer@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Brian Gix authored
commit 899663be upstream. Check for out-of-bound read was being performed at the end of while num_reports loop, and would fill journal with false positives. Added check to beginning of loop processing so that it doesn't get checked after ptr has been advanced. Signed-off-by:
Brian Gix <brian.gix@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Cc: syphyr <syphyr@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- Jan 29, 2022
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220127180258.362000607@linuxfoundation.org Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Tested-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mathias Krause authored
commit a0f90c88 upstream. A failing usercopy of the fence_rep object will lead to a stale entry in the file descriptor table as put_unused_fd() won't release it. This enables userland to refer to a dangling 'file' object through that still valid file descriptor, leading to all kinds of use-after-free exploitation scenarios. Fix this by deferring the call to fd_install() until after the usercopy has succeeded. Fixes: c906965d ("drm/vmwgfx: Add export fence to file descriptor support") Signed-off-by:
Mathias Krause <minipli@grsecurity.net> Signed-off-by:
Zack Rusin <zackr@vmware.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jan Kara authored
commit 68514dac upstream. A task can end up indefinitely sleeping in do_select() -> poll_schedule_timeout() when the following race happens: TASK1 (thread1) TASK2 TASK1 (thread2) do_select() setup poll_wqueues table with 'fd' write data to 'fd' pollwake() table->triggered = 1 closes 'fd' thread1 is waiting for poll_schedule_timeout() - sees table->triggered table->triggered = 0 return -EINTR loop back in do_select() But at this point when TASK1 loops back, the fdget() in the setup of poll_wqueues fails. So now so we never find 'fd' is ready for reading and sleep in poll_schedule_timeout() indefinitely. Treat an fd that got closed as a fd on which some event happened. This makes sure cannot block indefinitely in do_select(). Another option would be to return -EBADF in this case but that has a potential of subtly breaking applications that excercise this behavior and it happens to work for them. So returning fd as active seems like a safer choice. Suggested-by:
Linus Torvalds <torvalds@linux-foundation.org> CC: stable@vger.kernel.org Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tim Harvey authored
commit adab993c upstream. On IMX SoC's which support CMDQ the following can occur during high a high cpu load: mmc2: cqhci: ============ CQHCI REGISTER DUMP =========== mmc2: cqhci: Caps: 0x0000310a | Version: 0x00000510 mmc2: cqhci: Config: 0x00001001 | Control: 0x00000000 mmc2: cqhci: Int stat: 0x00000000 | Int enab: 0x00000006 mmc2: cqhci: Int sig: 0x00000006 | Int Coal: 0x00000000 mmc2: cqhci: TDL base: 0x8003f000 | TDL up32: 0x00000000 mmc2: cqhci: Doorbell: 0xbf01dfff | TCN: 0x00000000 mmc2: cqhci: Dev queue: 0x00000000 | Dev Pend: 0x08000000 mmc2: cqhci: Task clr: 0x00000000 | SSC1: 0x00011000 mmc2: cqhci: SSC2: 0x00000001 | DCMD rsp: 0x00000800 mmc2: cqhci: RED mask: 0xfdf9a080 | TERRI: 0x00000000 mmc2: cqhci: Resp idx: 0x0000000d | Resp arg: 0x00000000 mmc2: sdhci: ============ SDHCI REGISTER DUMP =========== mmc2: sdhci: Sys addr: 0x7c722000 | Version: 0x00000002 mmc2: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000020 mmc2: sdhci: Argument: 0x00018000 | Trn mode: 0x00000023 mmc2: sdhci: Present: 0x01f88008 | Host ctl: 0x00000030 mmc2: sdhci: Power: 0x00000002 | Blk gap: 0x00000080 mmc2: sdhci: Wake-up: 0x00000008 | Clock: 0x0000000f mmc2: sdhci: Timeout: 0x0000008f | Int stat: 0x00000000 mmc2: sdhci: Int enab: 0x107f4000 | Sig enab: 0x107f4000 mmc2: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000502 mmc2: sdhci: Caps: 0x07eb0000 | Caps_1: 0x8000b407 mmc2: sdhci: Cmd: 0x00000d1a | Max curr: 0x00ffffff mmc2: sdhci: Resp[0]: 0x00000000 | Resp[1]: 0xffc003ff mmc2: sdhci: Resp[2]: 0x328f5903 | Resp[3]: 0x00d07f01 mmc2: sdhci: Host ctl2: 0x00000088 mmc2: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0xfe179020 mmc2: sdhci-esdhc-imx: ========= ESDHC IMX DEBUG STATUS DUMP ==== mmc2: sdhci-esdhc-imx: cmd debug status: 0x2120 mmc2: sdhci-esdhc-imx: data debug status: 0x2200 mmc2: sdhci-esdhc-imx: trans debug status: 0x2300 mmc2: sdhci-esdhc-imx: dma debug status: 0x2400 mmc2: sdhci-esdhc-imx: adma debug status: 0x2510 mmc2: sdhci-esdhc-imx: fifo debug status: 0x2680 mmc2: sdhci-esdhc-imx: async fifo debug status: 0x2750 mmc2: sdhci: ============================================ For now, disable CMDQ support on the imx8qm/imx8qxp/imx8mm until the issue is found and resolved. Fixes: bb6e3581 ("mmc: sdhci-esdhc-imx: add CMDQ support") Fixes: cde5e8e9 ("mmc: sdhci-esdhc-imx: Add an new esdhc_soc_data for i.MX8MM") Cc: stable@vger.kernel.org Signed-off-by:
Tim Harvey <tharvey@gateworks.com> Reviewed-by:
Haibo Chen <haibo.chen@nxp.com> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20211103165415.2016-1-tharvey@gateworks.com Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Phil Elwell authored
commit c8013355 upstream Since [1], added in 5.7, the absence of a gpio-ranges property has prevented GPIOs from being restored to inputs when released. Add those properties for BCM283x and BCM2711 devices. [1] commit 2ab73c6d ("gpio: Support GPIO controllers without pin-ranges") Link: https://lore.kernel.org/r/20220104170247.956760-1-linus.walleij@linaro.org Fixes: 2ab73c6d ("gpio: Support GPIO controllers without pin-ranges") Fixes: 266423e6 ("pinctrl: bcm2835: Change init order for gpio hogs") Reported-by:
Stefan Wahren <stefan.wahren@i2se.com> Reported-by:
Florian Fainelli <f.fainelli@gmail.com> Reported-by:
Jan Kiszka <jan.kiszka@web.de> Signed-off-by:
Phil Elwell <phil@raspberrypi.com> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20211206092237.4105895-3-phil@raspberrypi.com Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Olof Johansson <olof@lixom.net> [florian: Remove bcm2711.dtsi hunk which does not exist in 5.4] Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Phil Elwell authored
commit 266423e6 upstream ...and gpio-ranges pinctrl-bcm2835 is a combined pinctrl/gpio driver. Currently the gpio side is registered first, but this breaks gpio hogs (which are configured during gpiochip_add_data). Part of the hog initialisation is a call to pinctrl_gpio_request, and since the pinctrl driver hasn't yet been registered this results in an -EPROBE_DEFER from which it can never recover. Change the initialisation sequence to register the pinctrl driver first. This also solves a similar problem with the gpio-ranges property, which is required in order for released pins to be returned to inputs. Fixes: 73345a18 ("pinctrl: bcm2835: Pass irqchip when adding gpiochip") Signed-off-by:
Phil Elwell <phil@raspberrypi.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20211206092237.4105895-2-phil@raspberrypi.com Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Florian Fainelli authored
commit 920fecc1 upstream Leverage the IRQCHIP_MASK_ON_SUSPEND flag in order to avoid having to specifically treat the GPIO interrupts during suspend and resume, and simply implement an irq_set_wake() callback that is responsible for enabling the parent wake-up interrupt as a wake-up interrupt. To avoid allocating unnecessary resources for other chips, the wake-up interrupts are only initialized if we have a brcm,bcm7211-gpio compatibility string. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20200531001101.24945-5-f.fainelli@gmail.com Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Florian Fainelli authored
commit 562c856f upstream The BCM7211 SoC uses the same pinconf_ops as the ones defined for the BCM2711 SoC, match the compatible string and use the correct set of options. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20200531001101.24945-4-f.fainelli@gmail.com Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Stefan Wahren authored
commit b1d84a3d upstream The BCM2711 supports 58 GPIOs. So extend pinctrl and GPIOs accordingly. Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Link: https://lore.kernel.org/r/1581166975-22949-4-git-send-email-stefan.wahren@i2se.com Reviewed-by:
Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Stefan Wahren authored
commit 90bfaf02 upstream This prepares the platform data to be easier to extend for more GPIOs. Except of this there is no functional change. Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Link: https://lore.kernel.org/r/1581166975-22949-3-git-send-email-stefan.wahren@i2se.com Reviewed-by:
Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Stefan Wahren authored
commit be30d5de upstream There is no usage for this define, so drop it. Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Link: https://lore.kernel.org/r/1580148908-4863-2-git-send-email-stefan.wahren@i2se.com Reviewed-by:
Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Paul E. McKenney authored
commit 614ddad1 upstream. Currently, rcu_advance_cbs_nowake() checks that a grace period is in progress, however, that grace period could end just after the check. This commit rechecks that a grace period is still in progress while holding the rcu_node structure's lock. The grace period cannot end while the current CPU's rcu_node structure's ->lock is held, thus avoiding false positives from the WARN_ON_ONCE(). As Daniel Vacek noted, it is not necessary for the rcu_node structure to have a CPU that has not yet passed through its quiescent state. Tested-by:
Guillaume Morin <guillaume@morinfr.org> Signed-off-by:
Paul E. McKenney <paulmck@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tvrtko Ursulin authored
commit 7938d615 upstream. We need to flush TLBs before releasing backing store otherwise userspace is able to encounter stale entries if a) it is not declaring access to certain buffers and b) it races with the backing store release from a such undeclared execution already executing on the GPU in parallel. The approach taken is to mark any buffer objects which were ever bound to the GPU and to trigger a serialized TLB flush when their backing store is released. Alternatively the flushing could be done on VMA unbind, at which point we would be able to ascertain whether there is potential a parallel GPU execution (which could race), but essentially it boils down to paying the cost of TLB flushes potentially needlessly at VMA unbind time (when the backing store is not known to be going away so not needed for safety), versus potentially needlessly at backing store relase time (since we at that point cannot tell whether there is anything executing on the GPU which uses that object). Thereforce simplicity of implementation has been chosen for now with scope to benchmark and refine later as required. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reported-by:
Sushma Venkatesh Reddy <sushma.venkatesh.reddy@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Dave Airlie <airlied@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- Jan 27, 2022
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220124183953.750177707@linuxfoundation.org Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Tested-by:
Hulk Robot <hulkrobot@huawei.com> Tested-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Link: https://lore.kernel.org/r/20220125155315.237374794@linuxfoundation.org Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Tested-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Hulk Robot <hulkrobot@huawei.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Masami Hiramatsu authored
This reverts commit 77fa5e15. Since the upstream commit e792ff80 depends on the generic kretprobe trampoline handler, which was introduced by commit 66ada2cc ("kprobes: Add generic kretprobe trampoline handler") but that is not ported to the stable kernel because it is not a bugfix series. So revert this commit to fix a build error. NOTE: I keep commit a7fe2378 ("ia64: kprobes: Fix to pass correct trampoline address to the handler") on the tree, that seems just a cleanup without the original reverted commit, but it would be better to use dereference_function_descriptor() macro instead of accessing descriptor's field directly. Fixes: 77fa5e15 ("ia64: kprobes: Use generic kretprobe trampoline handler") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Doyle, Patrick authored
commit fd0d8d85 upstream. In the unlikely event that both blocks 10 and 11 are marked as bad (on a 32 bit machine), then the process of marking block 10 as bad stomps on cached entry for block 11. There are (of course) other examples. Signed-off-by:
Patrick Doyle <pdoyle@irobot.com> Reviewed-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
Yoshio Furuyama <ytc-mb-yfuruyama7@kioxia.com> [<miquel.raynal@bootlin.com>: Fixed the title] Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Cc: Frieder Schrempf <frieder.schrempf@kontron.de> Link: https://lore.kernel.org/linux-mtd/774a92693f311e7de01e5935e720a179fb1b2468.1616635406.git.ytc-mb-yfuruyama7@kioxia.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-