commit 0b33b75960bcc85d984ea8d4d7fa103a1dc7b796 Author: Alexandre Frade Date: Sun Oct 17 20:57:23 2021 +0000 Linux 5.10.73-rt54-xanmod1 Signed-off-by: Alexandre Frade commit 1db06d427424031fba8526cb3f210864a0c99a51 Author: Alexandre Frade Date: Sat Jul 24 19:53:14 2021 +0000 char/lrng: add capability to store the return IP of the hard interrupt handler for RT Signed-off-by: Alexandre Frade commit 6ae8c6743d703f69ac3f166f59a8854c023d399b Author: Stephan Mueller Date: Mon Aug 2 22:01:09 2021 +0200 char/lrng: add power-on and runtime self-tests Parts of the LRNG are already covered by self-tests, including: * Self-test of SP800-90A DRBG provided by the Linux kernel crypto API. * Self-test of the PRNG provided by the Linux kernel crypto API. * Raw noise source data testing including SP800-90B compliant tests when enabling CONFIG_LRNG_HEALTH_TESTS This patch adds the self-tests for the remaining critical functions of the LRNG that are essential to maintain entropy and provide cryptographic strong random numbers. The following self-tests are implemented: * Self-test of the time array maintenance. This test verifies whether the time stamp array management to store multiple values in one integer implements a concatenation of the data. * Self-test of the software hash implementation ensures that this function operates compliant to the FIPS 180-4 specification. The self-test performs a hash operation of a zeroized per-CPU data array. * Self-test of the ChaCha20 DRNG is based on the self-tests that are already present and implemented with the stand-alone user space ChaCha20 DRNG implementation available at [1]. The self-tests cover different use cases of the DRNG seeded with known seed data. The status of the LRNG self-tests is provided with the selftest_status SysFS file. If the file contains a zero, the self-tests passed. The value 0xffffffff means that the self-tests were not executed. Any other value indicates a self-test failure. The self-test may be compiled to panic the system if the self-test fails. All self-tests operate on private state data structures. This implies that none of the self-tests have any impact on the regular LRNG operations. This allows the self-tests to be repeated at runtime by writing anything into the selftest_status SysFS file. [1] https://www.chronox.de/chacha20.html CC: Torsten Duwe CC: "Eric W. Biederman" CC: "Alexander E. Patrakov" CC: "Ahmed S. Darwish" CC: "Theodore Y. Ts'o" CC: Willy Tarreau CC: Matthew Garrett CC: Vito Caputo CC: Andreas Dilger CC: Jan Kara CC: Ray Strode CC: William Jon McCann CC: zhangjs CC: Andy Lutomirski CC: Florian Weimer CC: Lennart Poettering CC: Nicolai Stange CC: Marcelo Henrique Cerri CC: Neil Horman Reviewed-by: Alexander Lobakin Tested-by: Alexander Lobakin Signed-off-by: Stephan Mueller commit 9dc02cd0f84cb77b65a1fd4b3aa7f9217a2d825d Author: Stephan Mueller Date: Mon Aug 2 22:08:30 2021 +0200 char/lrng: add interface for gathering of raw entropy The test interface allows a privileged process to capture the raw unconditioned noise that is collected by the LRNG for statistical analysis. Such testing allows the analysis how much entropy the interrupt noise source provides on a given platform. Extracted noise data is not used to seed the LRNG. This is a test interface and not appropriate for production systems. Yet, the interface is considered to be sufficiently secured for production systems. Access to the data is given through the lrng_raw debugfs file. The data buffer should be multiples of sizeof(u32) to fill the entire buffer. Using the option lrng_testing.boot_test=1 the raw noise of the first 1000 entropy events since boot can be sampled. This test interface allows generating the data required for analysis whether the LRNG is in compliance with SP800-90B sections 3.1.3 and 3.1.4. In addition, the test interface allows gathering of the concatenated raw entropy data to verify that the concatenation works appropriately. This includes sampling of the following raw data: * high-resolution time stamp * Jiffies * IRQ number * IRQ flags * return instruction pointer * interrupt register state * array logic batching the high-resolution time stamp * enabling the runtime configuration of entropy source entropy rates Also, a testing interface to support ACVT of the hash implementation is provided. The reason why only hash testing is supported (as opposed to also provide testing for the DRNG) is the fact that the LRNG software hash implementation contains glue code that may warrant testing in addition to the testing of the software ciphers via the kernel crypto API. Also, for testing the CTR-DRBG, the underlying AES implementation would need to be tested. However, such AES test interface cannot be provided by the LRNG as it has no means to access the AES operation. Finally, the execution duration for processing a time stamp can be obtained with the LRNG raw entropy interface. If a test interface is not compiled, its code is a noop which has no impact on the performance. CC: Torsten Duwe CC: "Eric W. Biederman" CC: "Alexander E. Patrakov" CC: "Ahmed S. Darwish" CC: "Theodore Y. Ts'o" CC: Willy Tarreau CC: Matthew Garrett CC: Vito Caputo CC: Andreas Dilger CC: Jan Kara CC: Ray Strode CC: William Jon McCann CC: zhangjs CC: Andy Lutomirski CC: Florian Weimer CC: Lennart Poettering CC: Nicolai Stange Reviewed-by: Alexander Lobakin Tested-by: Alexander Lobakin Reviewed-by: Roman Drahtmueller Tested-by: Marcelo Henrique Cerri Tested-by: Neil Horman Signed-off-by: Stephan Mueller commit 539a2b3156db9da818c4eeefdceeff9da46d0488 Author: Stephan Mueller Date: Mon Aug 2 21:59:23 2021 +0200 char/lrng: add SP800-90B compliant health tests Implement health tests for LRNG's slow noise sources as mandated by SP-800-90B The file contains the following health tests: - stuck test: The stuck test calculates the first, second and third discrete derivative of the time stamp to be processed by the hash for the per-CPU entropy pool. Only if all three values are non-zero, the received time delta is considered to be non-stuck. - SP800-90B Repetition Count Test (RCT): The LRNG uses an enhanced version of the RCT specified in SP800-90B section 4.4.1. Instead of counting identical back-to-back values, the input to the RCT is the counting of the stuck values during the processing of received interrupt events. The RCT is applied with alpha=2^-30 compliant to the recommendation of FIPS 140-2 IG 9.8. During the counting operation, the LRNG always calculates the RCT cut-off value of C. If that value exceeds the allowed cut-off value, the LRNG will trigger the health test failure discussed below. An error is logged to the kernel log that such RCT failure occurred. This test is only applied and enforced in FIPS mode, i.e. when the kernel compiled with CONFIG_CONFIG_FIPS is started with fips=1. - SP800-90B Adaptive Proportion Test (APT): The LRNG implements the APT as defined in SP800-90B section 4.4.2. The applied significance level again is alpha=2^-30 compliant to the recommendation of FIPS 140-2 IG 9.8. The aforementioned health tests are applied to the first 1,024 time stamps obtained from interrupt events. In case one error is identified for either the RCT, or the APT, the collected entropy is invalidated and the SP800-90B startup health test is restarted. As long as the SP800-90B startup health test is not completed, all LRNG random number output interfaces that may block will block and not generate any data. This implies that only those potentially blocking interfaces are defined to provide random numbers that are seeded with the interrupt noise source being SP800-90B compliant. All other output interfaces will not be affected by the SP800-90B startup test and thus are not considered SP800-90B compliant. At runtime, the SP800-90B APT and RCT are applied to each time stamp generated for a received interrupt. When either the APT and RCT indicates a noise source failure, the LRNG is reset to a state it has immediately after boot: - all entropy counters are set to zero - the SP800-90B startup tests are re-performed which implies that getrandom(2) would block again until new entropy was collected To summarize, the following rules apply: • SP800-90B compliant output interfaces - /dev/random - getrandom(2) system call - get_random_bytes kernel-internal interface when being triggered by the callback registered with add_random_ready_callback • SP800-90B non-compliant output interfaces - /dev/urandom - get_random_bytes kernel-internal interface called directly - randomize_page kernel-internal interface - get_random_u32 and get_random_u64 kernel-internal interfaces - get_random_u32_wait, get_random_u64_wait, get_random_int_wait, and get_random_long_wait kernel-internal interfaces If either the RCT, or the APT health test fails irrespective whether during initialization or runtime, the following actions occur: 1. The entropy of the entire entropy pool is invalidated. 2. All DRNGs are reset which imply that they are treated as being not seeded and require a reseed during next invocation. 3. The SP800-90B startup health test are initiated with all implications of the startup tests. That implies that from that point on, new events must be observed and its entropy must be inserted into the entropy pool before random numbers are calculated from the entropy pool. Further details on the SP800-90B compliance and the availability of all test tools required to perform all tests mandated by SP800-90B are provided at [1]. The entire health testing code is compile-time configurable. The patch provides a CONFIG_BROKEN configuration of the APT / RCT cutoff values which have a high likelihood to trigger the health test failure. The BROKEN APT cutoff is set to the exact mean of the expected value if the time stamps are equally distributed (512 time stamps divided by 16 possible values due to using the 4 LSB of the time stamp). The BROKEN RCT cutoff value is set to 1 which is likely to be triggered during regular operation. CC: Torsten Duwe CC: "Eric W. Biederman" CC: "Alexander E. Patrakov" CC: "Ahmed S. Darwish" CC: "Theodore Y. Ts'o" CC: Willy Tarreau CC: Matthew Garrett CC: Vito Caputo CC: Andreas Dilger CC: Jan Kara CC: Ray Strode CC: William Jon McCann CC: zhangjs CC: Andy Lutomirski CC: Florian Weimer CC: Lennart Poettering CC: Nicolai Stange Reviewed-by: Alexander Lobakin Tested-by: Alexander Lobakin Reviewed-by: Roman Drahtmueller Tested-by: Marcelo Henrique Cerri Tested-by: Neil Horman Signed-off-by: Stephan Mueller commit a6623185d163eb2786f91a97b6885cf5605ac973 Author: Stephan Mueller Date: Mon Aug 30 12:32:04 2021 +0200 char/lrng: add Jitter RNG fast noise source The Jitter RNG fast noise source implemented as part of the kernel crypto API is queried for 256 bits of entropy at the time the seed buffer managed by the LRNG is about to be filled. CC: Torsten Duwe CC: "Eric W. Biederman" CC: "Alexander E. Patrakov" CC: "Ahmed S. Darwish" CC: "Theodore Y. Ts'o" CC: Willy Tarreau CC: Matthew Garrett CC: Vito Caputo CC: Andreas Dilger CC: Jan Kara CC: Ray Strode CC: William Jon McCann CC: zhangjs CC: Andy Lutomirski CC: Florian Weimer CC: Lennart Poettering CC: Nicolai Stange Reviewed-by: Alexander Lobakin Tested-by: Alexander Lobakin Reviewed-by: Marcelo Henrique Cerri Tested-by: Marcelo Henrique Cerri Tested-by: Neil Horman Signed-off-by: Stephan Mueller commit 55dbf9aae87b3ce739489c5a0b80cf4eaa83c2e6 Author: Stephan Mueller Date: Wed Sep 16 09:50:27 2020 +0200 crypto: move Jitter RNG header include dir To support the LRNG operation which uses the Jitter RNG separately from the kernel crypto API, the header file must be accessible to the LRNG code. CC: Torsten Duwe CC: "Eric W. Biederman" CC: "Alexander E. Patrakov" CC: "Ahmed S. Darwish" CC: "Theodore Y. Ts'o" CC: Willy Tarreau CC: Matthew Garrett CC: Vito Caputo CC: Andreas Dilger CC: Jan Kara CC: Ray Strode CC: William Jon McCann CC: zhangjs CC: Andy Lutomirski CC: Florian Weimer CC: Lennart Poettering CC: Nicolai Stange Reviewed-by: Alexander Lobakin Tested-by: Alexander Lobakin Reviewed-by: Roman Drahtmueller Tested-by: Roman Drahtmüller Tested-by: Marcelo Henrique Cerri Tested-by: Neil Horman Signed-off-by: Stephan Mueller commit 20fb326a14ff66aebde8ca156e583283c47dc59a Author: Stephan Mueller Date: Fri Jun 18 08:10:53 2021 +0200 char/lrng: add kernel crypto API PRNG extension Add runtime-pluggable support for all PRNGs that are accessible via the kernel crypto API, including hardware PRNGs. The PRNG is selected with the module parameter drng_name where the name must be one that the kernel crypto API can resolve into an RNG. This allows using of the kernel crypto API PRNG implementations that provide an interface to hardware PRNGs. Using this extension, the LRNG uses the hardware PRNGs to generate random numbers. An example is the S390 CPACF support providing such a PRNG. The hash is provided by a kernel crypto API SHASH whose digest size complies with the seedsize of the PRNG. CC: Torsten Duwe CC: "Eric W. Biederman" CC: "Alexander E. Patrakov" CC: "Ahmed S. Darwish" CC: "Theodore Y. Ts'o" CC: Willy Tarreau CC: Matthew Garrett CC: Vito Caputo CC: Andreas Dilger CC: Jan Kara CC: Ray Strode CC: William Jon McCann CC: zhangjs CC: Andy Lutomirski CC: Florian Weimer CC: Lennart Poettering CC: Nicolai Stange Reviewed-by: Alexander Lobakin Tested-by: Alexander Lobakin Reviewed-by: Marcelo Henrique Cerri Reviewed-by: Roman Drahtmueller Tested-by: Marcelo Henrique Cerri Tested-by: Neil Horman Signed-off-by: Stephan Mueller commit 4b95689b31e15184bb3e0d530e535b88e81ef584 Author: Stephan Mueller Date: Fri Jun 18 08:09:59 2021 +0200 char/lrng: add SP800-90A DRBG extension Using the LRNG switchable DRNG support, the SP800-90A DRBG extension is implemented. The DRBG uses the kernel crypto API DRBG implementation. In addition, it uses the kernel crypto API SHASH support to provide the hashing operation. The DRBG supports the choice of either a CTR DRBG using AES-256, HMAC DRBG with SHA-512 core or Hash DRBG with SHA-512 core. The used core can be selected with the module parameter lrng_drbg_type. The default is the CTR DRBG. When compiling the DRBG extension statically, the DRBG is loaded at late_initcall stage which implies that with the start of user space, the user space interfaces of getrandom(2), /dev/random and /dev/urandom provide random data produced by an SP800-90A DRBG. CC: Torsten Duwe CC: "Eric W. Biederman" CC: "Alexander E. Patrakov" CC: "Ahmed S. Darwish" CC: "Theodore Y. Ts'o" CC: Willy Tarreau CC: Matthew Garrett CC: Vito Caputo CC: Andreas Dilger CC: Jan Kara CC: Ray Strode CC: William Jon McCann CC: zhangjs CC: Andy Lutomirski CC: Florian Weimer CC: Lennart Poettering CC: Nicolai Stange Reviewed-by: Alexander Lobakin Tested-by: Alexander Lobakin Reviewed-by: Roman Drahtmueller Tested-by: Marcelo Henrique Cerri Tested-by: Neil Horman Signed-off-by: Stephan Mueller commit 09dacb6cc9f8ce468c4319ecda5a548b735384c2 Author: Stephan Mueller Date: Tue Sep 15 22:17:43 2020 +0200 crypto: DRBG - externalize DRBG functions for LRNG This patch allows several DRBG functions to be called by the LRNG kernel code paths outside the drbg.c file. CC: Torsten Duwe CC: "Eric W. Biederman" CC: "Alexander E. Patrakov" CC: "Ahmed S. Darwish" CC: "Theodore Y. Ts'o" CC: Willy Tarreau CC: Matthew Garrett CC: Vito Caputo CC: Andreas Dilger CC: Jan Kara CC: Ray Strode CC: William Jon McCann CC: zhangjs CC: Andy Lutomirski CC: Florian Weimer CC: Lennart Poettering CC: Nicolai Stange Reviewed-by: Alexander Lobakin Tested-by: Alexander Lobakin Reviewed-by: Roman Drahtmueller Tested-by: Roman Drahtmüller Tested-by: Marcelo Henrique Cerri Tested-by: Neil Horman Signed-off-by: Stephan Mueller commit d32046d6b9f79f62ab122fc192c9f2536b9ff247 Author: Stephan Mueller Date: Fri Jun 18 08:08:20 2021 +0200 char/lrng: add common generic hash support The LRNG switchable DRNG support also allows the replacement of the hash implementation used as conditioning component. The common generic hash support code provides the required callbacks using the synchronous hash implementations of the kernel crypto API. All synchronous hash implementations supported by the kernel crypto API can be used as part of the LRNG with this generic support. The generic support is intended to be configured by separate switchable DRNG backends. CC: Torsten Duwe CC: "Eric W. Biederman" CC: "Alexander E. Patrakov" CC: "Ahmed S. Darwish" CC: "Theodore Y. Ts'o" CC: Willy Tarreau CC: Matthew Garrett CC: Vito Caputo CC: Andreas Dilger CC: Jan Kara CC: Ray Strode CC: William Jon McCann CC: zhangjs CC: Andy Lutomirski CC: Florian Weimer CC: Lennart Poettering CC: Nicolai Stange CC: "Peter, Matthias" CC: Marcelo Henrique Cerri CC: Neil Horman Reviewed-by: Alexander Lobakin Tested-by: Alexander Lobakin Signed-off-by: Stephan Mueller commit 984b61242a55cb34985cb4ae00839129e5aa3c6a Author: Stephan Mueller Date: Mon Aug 2 21:54:12 2021 +0200 char/lrng: add switchable DRNG support The DRNG switch support allows replacing the DRNG mechanism of the LRNG. The switching support rests on the interface definition of include/linux/lrng.h. A new DRNG is implemented by filling in the interface defined in this header file. In addition to the DRNG, the extension also has to provide a hash implementation that is used to hash the entropy pool for random number extraction. Note: It is permissible to implement a DRNG whose operations may sleep. However, the hash function must not sleep. The switchable DRNG support allows replacing the DRNG at runtime. However, only one DRNG extension is allowed to be loaded at any given time. Before replacing it with another DRNG implementation, the possibly existing DRNG extension must be unloaded. The switchable DRNG extension activates the new DRNG during load time. It is expected, however, that such a DRNG switch would be done only once by an administrator to load the intended DRNG implementation. It is permissible to compile DRNG extensions either as kernel modules or statically. The initialization of the DRNG extension should be performed with a late_initcall to ensure the extension is available when user space starts but after all other initialization completed. The initialization is performed by registering the function call data structure with the lrng_set_drng_cb function. In order to unload the DRNG extension, lrng_set_drng_cb must be invoked with the NULL parameter. The DRNG extension should always provide a security strength that is at least as strong as LRNG_DRNG_SECURITY_STRENGTH_BITS. The hash extension must not sleep and must not maintain a separate state. CC: Torsten Duwe CC: "Eric W. Biederman" CC: "Alexander E. Patrakov" CC: "Ahmed S. Darwish" CC: "Theodore Y. Ts'o" CC: Willy Tarreau CC: Matthew Garrett CC: Vito Caputo CC: Andreas Dilger CC: Jan Kara CC: Ray Strode CC: William Jon McCann CC: zhangjs CC: Andy Lutomirski CC: Florian Weimer CC: Lennart Poettering CC: Nicolai Stange Reviewed-by: Alexander Lobakin Tested-by: Alexander Lobakin Reviewed-by: Marcelo Henrique Cerri Reviewed-by: Roman Drahtmueller Tested-by: Marcelo Henrique Cerri Tested-by: Neil Horman Signed-off-by: Stephan Mueller commit a69615011b1473dfdcfe2b8b803c15f13c3ba22d Author: Stephan Mueller Date: Mon Aug 2 21:52:37 2021 +0200 char/lrng: sysctls and /proc interface The LRNG sysctl interface provides the same controls as the existing /dev/random implementation. These sysctls behave identically and are implemented identically. The goal is to allow a possible merge of the existing /dev/random implementation with this implementation which implies that this patch tries have a very close similarity. Yet, all sysctls are documented at [1]. In addition, it provides the file lrng_type which provides details about the LRNG: - the name of the DRNG that produces the random numbers for /dev/random, /dev/urandom, getrandom(2) - the hash used to produce random numbers from the entropy pool - the number of secondary DRNG instances - indicator whether the LRNG operates SP800-90B compliant - indicator whether a high-resolution timer is identified - only with a high-resolution timer the interrupt noise source will deliver sufficient entropy - indicator whether the LRNG has been minimally seeded (i.e. is the secondary DRNG seeded with at least 128 bits of entropy) - indicator whether the LRNG has been fully seeded (i.e. is the secondary DRNG seeded with at least 256 bits of entropy) [1] https://www.chronox.de/lrng.html CC: Torsten Duwe CC: "Eric W. Biederman" CC: "Alexander E. Patrakov" CC: "Ahmed S. Darwish" CC: "Theodore Y. Ts'o" CC: Willy Tarreau CC: Matthew Garrett CC: Vito Caputo CC: Andreas Dilger CC: Jan Kara CC: Ray Strode CC: William Jon McCann CC: zhangjs CC: Andy Lutomirski CC: Florian Weimer CC: Lennart Poettering CC: Nicolai Stange Reviewed-by: Alexander Lobakin Tested-by: Alexander Lobakin Reviewed-by: Marcelo Henrique Cerri Reviewed-by: Roman Drahtmueller Tested-by: Marcelo Henrique Cerri Tested-by: Neil Horman Signed-off-by: Stephan Mueller commit 3ab12fbc2dd0ba8447c5c7ad92a829c9cf355c7f Author: Stephan Mueller Date: Mon Aug 2 21:49:21 2021 +0200 char/lrng: allocate one DRNG instance per NUMA node In order to improve NUMA-locality when serving getrandom(2) requests, allocate one DRNG instance per node. The DRNG instance that is present right from the start of the kernel is reused as the first per-NUMA-node DRNG. For all remaining online NUMA nodes a new DRNG instance is allocated. During boot time, the multiple DRNG instances are seeded sequentially. With this, the first DRNG instance (referenced as the initial DRNG in the code) is completely seeded with 256 bits of entropy before the next DRNG instance is completely seeded. When random numbers are requested, the NUMA-node-local DRNG is checked whether it has been already fully seeded. If this is not the case, the initial DRNG is used to serve the request. CC: Torsten Duwe CC: "Eric W. Biederman" CC: "Alexander E. Patrakov" CC: "Ahmed S. Darwish" CC: "Theodore Y. Ts'o" CC: Willy Tarreau CC: Matthew Garrett CC: Vito Caputo CC: Andreas Dilger CC: Jan Kara CC: Ray Strode CC: William Jon McCann CC: zhangjs CC: Andy Lutomirski CC: Florian Weimer CC: Lennart Poettering CC: Nicolai Stange CC: Eric Biggers Reviewed-by: Alexander Lobakin Tested-by: Alexander Lobakin Reviewed-by: Marcelo Henrique Cerri Reviewed-by: Roman Drahtmueller Tested-by: Marcelo Henrique Cerri Tested-by: Neil Horman Signed-off-by: Stephan Mueller commit dedef501b50af33c52e7fa67d85e992d3261c6b3 Author: Stephan Mueller Date: Wed Sep 22 17:39:33 2021 +0000 drivers: Introduce the Linux Random Number Generator In an effort to provide a flexible implementation for a random number generator that also delivers entropy during early boot time, allows replacement of the deterministic random number generation mechanism, implement the various components in separate code for easier maintenance, and provide compliance to SP800-90[A|B|C], introduce the Linux Random Number Generator (LRNG) framework. The general design is as follows. Additional implementation details are given in [1]. The LRNG consists of the following components: 1. The LRNG implements a DRNG. The DRNG always generates the requested amount of output. When using the SP800-90A terminology it operates without prediction resistance. The secondary DRNG maintains a counter of how many bytes were generated since last re-seed and a timer of the elapsed time since last re-seed. If either the counter or the timer reaches a threshold, the secondary DRNG is seeded from the entropy pool. In case the Linux kernel detects a NUMA system, one secondary DRNG instance per NUMA node is maintained. 2. The DRNG is seeded by concatenating the data from the following sources: (a) the output of the entropy pool, (b) the Jitter RNG if available and enabled, and (c) the CPU-based noise source such as Intel RDRAND if available and enabled. The entropy estimate of the data of all noise sources are added to form the entropy estimate of the data used to seed the DRNG with. The LRNG ensures, however, that the DRNG after seeding is at maximum the security strength of the DRNG. The LRNG is designed such that none of these noise sources can dominate the other noise sources to provide seed data to the DRNG during due to the following: (a) During boot time, the amount of received interrupts are the trigger points to (re)seed the DRNG. (b) At runtime, the available entropy from the slow noise source is concatenated with a pre-defined amount of data from the fast noise sources. In addition, each DRNG reseed operation triggers external noise source providers to deliver one block of data. 3. The entropy pool accumulates entropy obtained from certain events, which will henceforth be collectively called "slow noise sources". The entropy pool collects noise data from slow noise sources. Any data received by the LRNG from the slow noise sources is inserted into a per-CPU entropy pool using a hash operation that can be changed during runtime. Per default, SHA-256 is used. (a) When an interrupt occurs, the high-resolution time stamp is mixed into the per-CPU entropy pool. This time stamp is credited with heuristically implied entropy. (b) HID event data like the key stroke or the mouse coordinates are mixed into the per-CPU entropy pool. This data is not credited with entropy by the LRNG. (c) Device drivers may provide data that is mixed into an auxiliary pool using the same hash that is used to process the per-CPU entropy pool. This data is not credited with entropy by the LRNG. Any data provided from user space by either writing to /dev/random, /dev/urandom or the IOCTL of RNDADDENTROPY on both device files are always injected into the auxiliary pool. In addition, when a hardware random number generator covered by the Linux kernel HW generator framework wants to deliver random numbers, it is injected into the auxiliary pool as well. HW generator noise source is handled separately from the other noise source due to the fact that the HW generator framework may decide by itself when to deliver data whereas the other noise sources always requested for data driven by the LRNG operation. Similarly any user space provided data is inserted into the entropy pool. When seed data for the DRNG is to be generated, all per-CPU entropy pools and the auxiliary pool are hashed. The message digest forms the new auxiliary pool state. At the same time, this data is used for seeding the DRNG. To speed up the interrupt handling code of the LRNG, the time stamp collected for an interrupt event is truncated to the 8 least significant bits. 64 truncated time stamps are concatenated and then jointly inserted into the per-CPU entropy pool. During boot time, until the fully seeded stage is reached, each time stamp with its 32 least significant bits is are concatenated. When 16 such events are received, they are injected into the per-CPU entropy pool. The LRNG allows the DRNG mechanism to be changed at runtime. Per default, a ChaCha20-based DRNG is used. The ChaCha20-DRNG implemented for the LRNG is also provided as a stand-alone user space deterministic random number generator. The LRNG also offers an SP800-90A DRBG based on the Linux kernel crypto API DRBG implementation. The processing of entropic data from the noise source before injecting them into the DRNG is performed with the following mathematical operations: 1. Truncation: The received time stamps are truncated to 8 least significant bits (or 32 least significant bits during boot time) 2. Concatenation: The received and truncated time stamps as well as auxiliary 32 bit words are concatenated to fill the per-CPU data array that is capable of holding 64 8-bit words. 3. Hashing: A set of concatenated time stamp data received from the interrupts are hashed together with the current existing per-CPU entropy pool state. The resulting message digest is the new per-CPU entropy pool state. 4. Hashing: When new data is added to the auxiliary pool, the data is hashed together with the auxiliary pool to form a new auxiliary pool state. 5. Hashing: A message digest of all per-CPU entropy pools and the auxiliary pool is calculated which forms the new auxiliary pool state. At the same time, this message digest is used to fill the slow noise source output buffer discussed in the following. 6. Truncation: The most-significant bits (MSB) defined by the requested number of bits (commonly equal to the security strength of the DRBG) or the entropy available transported with the buffer (which is the minimum of the message digest size and the available entropy in all entropy pools and the auxiliary pool), whatever is smaller, are obtained from the slow noise source output buffer. 7. Concatenation: The temporary seed buffer used to seed the DRNG is a concatenation of the slow noise source buffer, the Jitter RNG output, the CPU noise source output, and the current time. The DRNG always tries to seed itself with 256 bits of entropy, except during boot. In any case, if the noise sources cannot deliver that amount, the available entropy is used and the DRNG keeps track on how much entropy it was seeded with. The entropy implied by the LRNG available in the entropy pool may be too conservative. To ensure that during boot time all available entropy from the entropy pool is transferred to the DRNG, the hash_df function always generates 256 data bits during boot to seed the DRNG. During boot, the DRNG is seeded as follows: 1. The DRNG is reseeded from the entropy pool and potentially the fast noise sources if the entropy pool has collected at least 32 bits of entropy from the interrupt noise source. The goal of this step is to ensure that the DRNG receives some initial entropy as early as possible. In addition it receives the entropy available from the fast noise sources. 2. The DRNG is reseeded from the entropy pool and potentially the fast noise sources if all noise sources collectively can provide at least 128 bits of entropy. 3. The DRNG is reseeded from the entropy pool and potentially the fast noise sources if all noise sources collectivel can provide at least 256 bits. At the time of the reseeding steps, the DRNG requests as much entropy as is available in order to skip certain steps and reach the seeding level of 256 bits. This may imply that one or more of the aforementioned steps are skipped. In all listed steps, the DRNG is (re)seeded with a number of random bytes from the entropy pool that is at most the amount of entropy present in the entropy pool. This means that when the entropy pool contains 128 or 256 bits of entropy, the DRNG is seeded with that amount of entropy as well. Before the DRNG is seeded with 256 bits of entropy in step 3, requests of random data from /dev/random and the getrandom system call are not processed. The hash operation providing random data from the entropy pools will always require that all entropy sources collectively can deliver at least 128 entropy bits. The DRNG operates as deterministic random number generator with the following properties: * The maximum number of random bytes that can be generated with one DRNG generate operation is limited to 4096 bytes. When longer random numbers are requested, multiple DRNG generate operations are performed. The ChaCha20 DRNG as well as the SP800-90A DRBGs implement an update of their state after completing a generate request for backtracking resistance. * The secondary DRNG is reseeded with whatever entropy is available – in the worst case where no additional entropy can be provided by the noise sources, the DRNG is not re-seeded and continues its operation to try to reseed again after again the expiry of one of these thresholds: - If the last reseeding of the secondary DRNG is more than 600 seconds ago, or - 2^20 DRNG generate operations are performed, whatever comes first, or - the secondary DRNG is forced to reseed before the next generation of random numbers if data has been injected into the LRNG by writing data into /dev/random or /dev/urandom. The chosen values prevent high-volume requests from user space to cause frequent reseeding operations which drag down the performance of the DRNG. With the automatic reseeding after 600 seconds, the LRNG is triggered to reseed itself before the first request after a suspend that put the hardware to sleep for longer than 600 seconds. To support smaller devices including IoT environments, this patch allows reducing the runtime memory footprint of the LRNG at compile time by selecting smaller collection data sizes. When selecting the compilation of a kernel for a small environment, prevent the allocation of a buffer up to 4096 bytes to serve user space requests. In this case, the stack variable of 64 bytes is used to serve all user space requests. The LRNG has the following properties: * internal noise source: interrupts timing with fast boot time seeding * high performance of interrupt handling code: The LRNG impact on the interrupt handling has been reduced to a minimum. On one example system, the LRNG interrupt handling code in its fastest configuration executes within an average 55 cycles whereas the existing /dev/random on the same device takes about 97 cycles when measuring the execution time of add_interrupt_randomness(). * use of almost never contended lock for hashing operation to collect raw entropy supporting concurrency-free use of massive parallel systems - worst case rate of contention is the number of DRNG reseeds, usually: number of NUMA nodes contentions per 5 minutes. * use of standalone ChaCha20 based RNG with the option to use a different DRNG selectable at compile time * instantiate one DRNG per NUMA node * support for runtime switchable output DRNGs * use of runtime-switchable hash for conditioning implementation following widely accepted approach * compile-time selectable collection size * support of small systems by allowing the reduction of the runtime memory needs Further details including the rationale for the design choices and properties of the LRNG together with testing is provided at [1]. In addition, the documentation explains the conducted regression tests to verify that the LRNG is API and ABI compatible with the existing /dev/random implementation. [1] https://www.chronox.de/lrng.html CC: Torsten Duwe CC: "Eric W. Biederman" CC: "Alexander E. Patrakov" CC: "Ahmed S. Darwish" CC: "Theodore Y. Ts'o" CC: Willy Tarreau CC: Matthew Garrett CC: Vito Caputo CC: Andreas Dilger CC: Jan Kara CC: Ray Strode CC: William Jon McCann CC: zhangjs CC: Andy Lutomirski CC: Florian Weimer CC: Lennart Poettering CC: Nicolai Stange Reviewed-by: Alexander Lobakin Tested-by: Alexander Lobakin Mathematical aspects Reviewed-by: "Peter, Matthias" Reviewed-by: Marcelo Henrique Cerri Reviewed-by: Roman Drahtmueller Tested-by: Marcelo Henrique Cerri Tested-by: Neil Horman Signed-off-by: Alexandre Frade commit deb5d71a6e0ac8a298866e100be3356d2031ac81 Author: Alexandre Frade Date: Wed Sep 22 17:28:41 2021 +0000 drivers/char: remove lrng v41 Signed-off-by: Alexandre Frade commit 0b854fb7a4b5b8912fbb4e42533429f971e0a210 Author: Alexandre Frade Date: Sun Oct 17 20:04:39 2021 +0000 Revert "char/lrng: add capability to store the return IP of the hard interrupt handler for RT" This reverts commit d26855e81e29ba3cd24fa2e25e8cd32f55dd3270. commit c9158a44df6527795c1cd951b247c6b1c33b3dac Author: Denis Pauk Date: Sun Oct 3 00:08:54 2021 +0300 hwmon: (nct6775) Add additional ASUS motherboards. Add support: * PRIME B360-PLUS * PRIME X570-PRO * ROG CROSSHAIR VIII FORMULA * ROG STRIX B550-I GAMING * ROG STRIX X570-F GAMING * ROG STRIX Z390-E GAMING * TUF GAMING B550-PRO * TUF GAMING Z490-PLUS * TUF GAMING Z490-PLUS (WI-FI) BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204807 Signed-off-by: Denis Pauk Tested-by: matt-testalltheway Tested-by: Kamil Dudka Tested-by: Robert Swiecki Tested-by: Kamil Pietrzak Tested-by: Igor Tested-by: Tor Vic Tested-by: Poezevara Cc: Andy Shevchenko Cc: Guenter Roeck Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20211002210857.709956-2-pauk.denis@gmail.com Signed-off-by: Guenter Roeck commit c474fde3df1532ffd0374c019b04e54936b3b30b Author: Denis Pauk Date: Sat Sep 18 01:02:40 2021 +0300 hwmon: (nct6775) Support access via Asus WMI Support accessing the NCT677x via Asus WMI functions. On mainboards that support this way of accessing the chip, the driver will usually not work without this option since in these mainboards, ACPI will mark the I/O port as used. Code uses ACPI firmware interface to communicate with sensors with ASUS motherboards: * PRIME B460-PLUS, * ROG CROSSHAIR VIII IMPACT, * ROG STRIX B550-E GAMING, * ROG STRIX B550-F GAMING, * ROG STRIX B550-F GAMING (WI-FI), * ROG STRIX Z490-I GAMING, * TUF GAMING B550M-PLUS, * TUF GAMING B550M-PLUS (WI-FI), * TUF GAMING B550-PLUS, * TUF GAMING X570-PLUS, * TUF GAMING X570-PRO (WI-FI). BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204807 Signed-off-by: Denis Pauk Co-developed-by: Bernhard Seibold Signed-off-by: Bernhard Seibold Tested-by: Pär Ekholm Tested-by: Tested-by: Artem S. Tashkinov Tested-by: Vittorio Roberto Alfieri Tested-by: Sahan Fernando Cc: Andy Shevchenko Cc: Guenter Roeck Link: https://lore.kernel.org/r/20210917220240.56553-4-pauk.denis@gmail.com Signed-off-by: Guenter Roeck commit 609a7880b17f31509ccc303c580845f8cfd7edc2 Author: Denis Pauk Date: Sat Sep 18 01:02:39 2021 +0300 hwmon: (nct6775) Use nct6775_*() function pointers in nct6775_data. Prepare for platform specific callbacks usage: * Use nct6775 function pointers in struct nct6775_data instead direct calls. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204807 Signed-off-by: Denis Pauk Co-developed-by: Bernhard Seibold Signed-off-by: Bernhard Seibold Cc: Andy Shevchenko Cc: Guenter Roeck Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20210917220240.56553-3-pauk.denis@gmail.com Signed-off-by: Guenter Roeck commit 7112facd7099bbe258d185bd1a1c03317d69d016 Author: Denis Pauk Date: Sat Sep 18 01:02:38 2021 +0300 hwmon: (nct6775) Use superio_*() function pointers in sio_data. Prepare for platform specific callbacks usage: * Rearrange code for directly use struct nct6775_sio_data in superio_*() functions. * Use superio function pointers in nct6775_sio_data struct instead direct calls. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204807 Signed-off-by: Denis Pauk Co-developed-by: Bernhard Seibold Signed-off-by: Bernhard Seibold Cc: Andy Shevchenko Cc: Guenter Roeck Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20210917220240.56553-2-pauk.denis@gmail.com Signed-off-by: Guenter Roeck commit 671f28bb368dccaea915ffc6747d5cd3e6b24a14 Author: Alexandre Frade Date: Thu Oct 7 14:09:55 2021 +0000 i2c: busses: Add SMBus capability to work with OpenRGB driver control Signed-off-by: Alexandre Frade commit f72e8d27bff07efb87897f22c1932a79b32c90e3 Merge: 99d0a98c8f10 89b60c844728 Author: Alexandre Frade Date: Sun Oct 17 19:54:29 2021 +0000 Merge tag 'v5.10.73-rt54' into 5.10-rt Linux 5.10.73-rt54 commit 89b60c844728be4533e56da779e32b6447230153 Author: Steven Rostedt (VMware) Date: Fri Oct 15 23:32:13 2021 -0400 Linux 5.10.73-rt54 commit 5417dc5a11ee7eb22638740b207bfcfd85cd3241 Merge: 3e2c5afd34a2 0268aa579b1f Author: Steven Rostedt (VMware) Date: Fri Oct 15 17:14:47 2021 -0400 Merge tag 'v5.10.73' into v5.10-rt This is the 5.10.73 stable release commit 0268aa579b1f741b12300bc7f084ffe990cfde5f Author: Greg Kroah-Hartman Date: Wed Oct 13 10:04:30 2021 +0200 Linux 5.10.73 Link: https://lore.kernel.org/r/20211011134508.362906295@linuxfoundation.org Tested-by: Florian Fainelli Link: https://lore.kernel.org/r/20211011153306.939942789@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Fox Chen Tested-by: Salvatore Bonaccorso Tested-by: Shuah Khan Tested-by: Guenter Roeck Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Link: https://lore.kernel.org/r/20211012093348.134236881@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Linux Kernel Functional Testing Tested-by: Guenter Roeck Tested-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit 825c00c2ee143eff1d869605c318270686f689e0 Author: Thomas Gleixner Date: Thu Sep 30 19:21:39 2021 +0200 x86/hpet: Use another crystalball to evaluate HPET usability commit 6e3cd95234dc1eda488f4f487c281bac8fef4d9b upstream. On recent Intel systems the HPET stops working when the system reaches PC10 idle state. The approach of adding PCI ids to the early quirks to disable HPET on these systems is a whack a mole game which makes no sense. Check for PC10 instead and force disable HPET if supported. The check is overbroad as it does not take ACPI, intel_idle enablement and command line parameters into account. That's fine as long as there is at least PMTIMER available to calibrate the TSC frequency. The decision can be overruled by adding "hpet=force" on the kernel command line. Remove the related early PCI quirks for affected Ice Cake and Coffin Lake systems as they are not longer required. That should also cover all other systems, i.e. Tiger Rag and newer generations, which are most likely affected by this as well. Fixes: Yet another hardware trainwreck Reported-by: Jakub Kicinski Signed-off-by: Thomas Gleixner Tested-by: Jakub Kicinski Reviewed-by: Rafael J. Wysocki Cc: stable@vger.kernel.org Cc: Kai-Heng Feng Cc: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit f2447f6587b8ffe42ba04d14ce67d429a1163e5e Author: Vegard Nossum Date: Mon Oct 4 00:34:23 2021 +0200 x86/entry: Clear X86_FEATURE_SMAP when CONFIG_X86_SMAP=n commit 3958b9c34c2729597e182cc606cc43942fd19f7c upstream. Commit 3c73b81a9164 ("x86/entry, selftests: Further improve user entry sanity checks") added a warning if AC is set when in the kernel. Commit 662a0221893a3d ("x86/entry: Fix AC assertion") changed the warning to only fire if the CPU supports SMAP. However, the warning can still trigger on a machine that supports SMAP but where it's disabled in the kernel config and when running the syscall_nt selftest, for example: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 49 at irqentry_enter_from_user_mode CPU: 0 PID: 49 Comm: init Tainted: G T 5.15.0-rc4+ #98 e6202628ee053b4f310759978284bd8bb0ce6905 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 RIP: 0010:irqentry_enter_from_user_mode ... Call Trace: ? irqentry_enter ? exc_general_protection ? asm_exc_general_protection ? asm_exc_general_protectio IS_ENABLED(CONFIG_X86_SMAP) could be added to the warning condition, but even this would not be enough in case SMAP is disabled at boot time with the "nosmap" parameter. To be consistent with "nosmap" behaviour, clear X86_FEATURE_SMAP when !CONFIG_X86_SMAP. Found using entry-fuzz + satrandconfig. [ bp: Massage commit message. ] Fixes: 3c73b81a9164 ("x86/entry, selftests: Further improve user entry sanity checks") Fixes: 662a0221893a ("x86/entry: Fix AC assertion") Signed-off-by: Vegard Nossum Signed-off-by: Borislav Petkov Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20211003223423.8666-1-vegard.nossum@oracle.com Signed-off-by: Greg Kroah-Hartman commit 6bfe1f6fc8769c728d4de87aa8e30ec36e706a9d Author: Lukas Bulwahn Date: Tue Aug 3 13:35:23 2021 +0200 x86/entry: Correct reference to intended CONFIG_64_BIT commit 2c861f2b859385e9eaa6e464a8a7435b5a6bf564 upstream. Commit in Fixes adds a condition with IS_ENABLED(CONFIG_64_BIT), but the intended config item is called CONFIG_64BIT, as defined in arch/x86/Kconfig. Fortunately, scripts/checkkconfigsymbols.py warns: 64_BIT Referencing files: arch/x86/include/asm/entry-common.h Correct the reference to the intended config symbol. Fixes: 662a0221893a ("x86/entry: Fix AC assertion") Suggested-by: Randy Dunlap Signed-off-by: Lukas Bulwahn Signed-off-by: Borislav Petkov Cc: Link: https://lkml.kernel.org/r/20210803113531.30720-2-lukas.bulwahn@gmail.com Signed-off-by: Greg Kroah-Hartman commit 5d637bc6f98ae7f980f4773608f997f222176ef5 Author: Tom Lendacky Date: Thu Sep 30 23:42:01 2021 -0500 x86/sev: Return an error on a returned non-zero SW_EXITINFO1[31:0] commit 06f2ac3d4219bbbfd93d79e01966a42053084f11 upstream. After returning from a VMGEXIT NAE event, SW_EXITINFO1[31:0] is checked for a value of 1, which indicates an error and that SW_EXITINFO2 contains exception information. However, future versions of the GHCB specification may define new values for SW_EXITINFO1[31:0], so really any non-zero value should be treated as an error. Fixes: 597cfe48212a ("x86/boot/compressed/64: Setup a GHCB-based VC Exception handler") Signed-off-by: Tom Lendacky Signed-off-by: Borislav Petkov Cc: # 5.10+ Link: https://lkml.kernel.org/r/efc772af831e9e7f517f0439b13b41f56bad8784.1633063321.git.thomas.lendacky@amd.com Signed-off-by: Greg Kroah-Hartman commit df121cf550032175454e325d816af27b89cf0447 Author: Lukas Bulwahn Date: Tue Aug 3 13:35:25 2021 +0200 x86/Kconfig: Correct reference to MWINCHIP3D commit 225bac2dc5d192e55f2c50123ee539b1edf8a411 upstream. Commit in Fixes intended to exclude the Winchip series and referred to CONFIG_WINCHIP3D, but the config symbol is called CONFIG_MWINCHIP3D. Hence, scripts/checkkconfigsymbols.py warns: WINCHIP3D Referencing files: arch/x86/Kconfig Correct the reference to the intended config symbol. Fixes: 69b8d3fcabdc ("x86/Kconfig: Exclude i586-class CPUs lacking PAE support from the HIGHMEM64G Kconfig group") Suggested-by: Randy Dunlap Signed-off-by: Lukas Bulwahn Signed-off-by: Borislav Petkov Cc: Link: https://lkml.kernel.org/r/20210803113531.30720-4-lukas.bulwahn@gmail.com Signed-off-by: Greg Kroah-Hartman commit d7c36115fb8177e58a8aa99e79e7e076f6f07395 Author: Lukas Bulwahn Date: Tue Aug 3 13:35:24 2021 +0200 x86/platform/olpc: Correct ifdef symbol to intended CONFIG_OLPC_XO15_SCI commit 4758fd801f919b8b9acad78d2e49a195ec2be46b upstream. The refactoring in the commit in Fixes introduced an ifdef CONFIG_OLPC_XO1_5_SCI, however the config symbol is actually called "CONFIG_OLPC_XO15_SCI". Fortunately, ./scripts/checkkconfigsymbols.py warns: OLPC_XO1_5_SCI Referencing files: arch/x86/platform/olpc/olpc.c Correct this ifdef condition to the intended config symbol. Fixes: ec9964b48033 ("Platform: OLPC: Move EC-specific functionality out from x86") Suggested-by: Randy Dunlap Signed-off-by: Lukas Bulwahn Signed-off-by: Borislav Petkov Cc: Link: https://lkml.kernel.org/r/20210803113531.30720-3-lukas.bulwahn@gmail.com Signed-off-by: Greg Kroah-Hartman commit f73ca4961d51304a8f1418a6b6b9d9c77ea95041 Author: Mahesh Salgaonkar Date: Mon Sep 20 22:03:26 2021 +0530 pseries/eeh: Fix the kdump kernel crash during eeh_pseries_init [ Upstream commit eb8257a12192f43ffd41bd90932c39dade958042 ] On pseries LPAR when an empty slot is assigned to partition OR in single LPAR mode, kdump kernel crashes during issuing PHB reset. In the kdump scenario, we traverse all PHBs and issue reset using the pe_config_addr of the first child device present under each PHB. However the code assumes that none of the PHB slots can be empty and uses list_first_entry() to get the first child device under the PHB. Since list_first_entry() expects the list to be non-empty, it returns an invalid pci_dn entry and ends up accessing NULL phb pointer under pci_dn->phb causing kdump kernel crash. This patch fixes the below kdump kernel crash by skipping empty slots: audit: initializing netlink subsys (disabled) thermal_sys: Registered thermal governor 'fair_share' thermal_sys: Registered thermal governor 'step_wise' cpuidle: using governor menu pstore: Registered nvram as persistent store backend Issue PHB reset ... audit: type=2000 audit(1631267818.000:1): state=initialized audit_enabled=0 res=1 BUG: Kernel NULL pointer dereference on read at 0x00000268 Faulting instruction address: 0xc000000008101fb0 Oops: Kernel access of bad area, sig: 7 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: CPU: 7 PID: 1 Comm: swapper/7 Not tainted 5.14.0 #1 NIP: c000000008101fb0 LR: c000000009284ccc CTR: c000000008029d70 REGS: c00000001161b840 TRAP: 0300 Not tainted (5.14.0) MSR: 8000000002009033 CR: 28000224 XER: 20040002 CFAR: c000000008101f0c DAR: 0000000000000268 DSISR: 00080000 IRQMASK: 0 ... NIP pseries_eeh_get_pe_config_addr+0x100/0x1b0 LR __machine_initcall_pseries_eeh_pseries_init+0x2cc/0x350 Call Trace: 0xc00000001161bb80 (unreliable) __machine_initcall_pseries_eeh_pseries_init+0x2cc/0x350 do_one_initcall+0x60/0x2d0 kernel_init_freeable+0x350/0x3f8 kernel_init+0x3c/0x17c ret_from_kernel_thread+0x5c/0x64 Fixes: 5a090f7c363fd ("powerpc/pseries: PCIE PHB reset") Signed-off-by: Mahesh Salgaonkar [mpe: Tweak wording and trim oops] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/163215558252.413351.8600189949820258982.stgit@jupiter Signed-off-by: Sasha Levin commit 411b38fe68ba20a8bbe724b0939762c3f16e16ca Author: Nicholas Piggin Date: Tue Oct 5 00:56:38 2021 +1000 powerpc/64s: fix program check interrupt emergency stack path [ Upstream commit 3e607dc4df180b72a38e75030cb0f94d12808712 ] Emergency stack path was jumping into a 3: label inside the __GEN_COMMON_BODY macro for the normal path after it had finished, rather than jumping over it. By a small miracle this is the correct place to build up a new interrupt frame with the existing stack pointer, so things basically worked okay with an added weird looking 700 trap frame on top (which had the wrong ->nip so it didn't decode bug messages either). Fix this by avoiding using numeric labels when jumping over non-trivial macros. Before: LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: CPU: 0 PID: 88 Comm: sh Not tainted 5.15.0-rc2-00034-ge057cdade6e5 #2637 NIP: 7265677368657265 LR: c00000000006c0c8 CTR: c0000000000097f0 REGS: c0000000fffb3a50 TRAP: 0700 Not tainted MSR: 9000000000021031 CR: 00000700 XER: 20040000 CFAR: c0000000000098b0 IRQMASK: 0 GPR00: c00000000006c964 c0000000fffb3cf0 c000000001513800 0000000000000000 GPR04: 0000000048ab0778 0000000042000000 0000000000000000 0000000000001299 GPR08: 000001e447c718ec 0000000022424282 0000000000002710 c00000000006bee8 GPR12: 9000000000009033 c0000000016b0000 00000000000000b0 0000000000000001 GPR16: 0000000000000000 0000000000000002 0000000000000000 0000000000000ff8 GPR20: 0000000000001fff 0000000000000007 0000000000000080 00007fff89d90158 GPR24: 0000000002000000 0000000002000000 0000000000000255 0000000000000300 GPR28: c000000001270000 0000000042000000 0000000048ab0778 c000000080647e80 NIP [7265677368657265] 0x7265677368657265 LR [c00000000006c0c8] ___do_page_fault+0x3f8/0xb10 Call Trace: [c0000000fffb3cf0] [c00000000000bdac] soft_nmi_common+0x13c/0x1d0 (unreliable) --- interrupt: 700 at decrementer_common_virt+0xb8/0x230 NIP: c0000000000098b8 LR: c00000000006c0c8 CTR: c0000000000097f0 REGS: c0000000fffb3d60 TRAP: 0700 Not tainted MSR: 9000000000021031 CR: 22424282 XER: 20040000 CFAR: c0000000000098b0 IRQMASK: 0 GPR00: c00000000006c964 0000000000002400 c000000001513800 0000000000000000 GPR04: 0000000048ab0778 0000000042000000 0000000000000000 0000000000001299 GPR08: 000001e447c718ec 0000000022424282 0000000000002710 c00000000006bee8 GPR12: 9000000000009033 c0000000016b0000 00000000000000b0 0000000000000001 GPR16: 0000000000000000 0000000000000002 0000000000000000 0000000000000ff8 GPR20: 0000000000001fff 0000000000000007 0000000000000080 00007fff89d90158 GPR24: 0000000002000000 0000000002000000 0000000000000255 0000000000000300 GPR28: c000000001270000 0000000042000000 0000000048ab0778 c000000080647e80 NIP [c0000000000098b8] decrementer_common_virt+0xb8/0x230 LR [c00000000006c0c8] ___do_page_fault+0x3f8/0xb10 --- interrupt: 700 Instruction dump: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX ---[ end trace 6d28218e0cc3c949 ]--- After: ------------[ cut here ]------------ kernel BUG at arch/powerpc/kernel/exceptions-64s.S:491! Oops: Exception in kernel mode, sig: 5 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: CPU: 0 PID: 88 Comm: login Not tainted 5.15.0-rc2-00034-ge057cdade6e5-dirty #2638 NIP: c0000000000098b8 LR: c00000000006bf04 CTR: c0000000000097f0 REGS: c0000000fffb3d60 TRAP: 0700 Not tainted MSR: 9000000000021031 CR: 24482227 XER: 00040000 CFAR: c0000000000098b0 IRQMASK: 0 GPR00: c00000000006bf04 0000000000002400 c000000001513800 c000000001271868 GPR04: 00000000100f0d29 0000000042000000 0000000000000007 0000000000000009 GPR08: 00000000100f0d29 0000000024482227 0000000000002710 c000000000181b3c GPR12: 9000000000009033 c0000000016b0000 00000000100f0d29 c000000005b22f00 GPR16: 00000000ffff0000 0000000000000001 0000000000000009 00000000100eed90 GPR20: 00000000100eed90 0000000010000000 000000001000a49c 00000000100f1430 GPR24: c000000001271868 0000000002000000 0000000000000215 0000000000000300 GPR28: c000000001271800 0000000042000000 00000000100f0d29 c000000080647860 NIP [c0000000000098b8] decrementer_common_virt+0xb8/0x230 LR [c00000000006bf04] ___do_page_fault+0x234/0xb10 Call Trace: Instruction dump: 4182000c 39400001 48000008 894d0932 714a0001 39400008 408225fc 718a4000 7c2a0b78 3821fcf0 41c20008 e82d0910 <0981fcf0> f92101a0 f9610170 f9810178 ---[ end trace a5dbd1f5ea4ccc51 ]--- Fixes: 0a882e28468f4 ("powerpc/64s/exception: remove bad stack branch") Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20211004145642.1331214-2-npiggin@gmail.com Signed-off-by: Sasha Levin commit 18a2a2cafcf93ece4bde3a4f0b76324a7bfc0872 Author: Naveen N. Rao Date: Wed Oct 6 01:55:23 2021 +0530 powerpc/bpf: Fix BPF_SUB when imm == 0x80000000 [ Upstream commit 5855c4c1f415ca3ba1046e77c0b3d3dfc96c9025 ] We aren't handling subtraction involving an immediate value of 0x80000000 properly. Fix the same. Fixes: 156d0e290e969c ("powerpc/ebpf/jit: Implement JIT compiler for extended BPF") Signed-off-by: Naveen N. Rao Reviewed-by: Christophe Leroy [mpe: Fold in fix from Naveen to use imm <= 32768] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/fc4b1276eb10761fd7ce0814c8dd089da2815251.1633464148.git.naveen.n.rao@linux.vnet.ibm.com Signed-off-by: Sasha Levin commit a4037dded56bb82eb4fbb37b5bdbf18a55e2bb96 Author: Palmer Dabbelt Date: Sat Oct 2 17:21:20 2021 -0700 RISC-V: Include clone3() on rv32 [ Upstream commit 59a4e0d5511ba61353ea9a4efdb1b86c23ecf134 ] As far as I can tell this should be enabled on rv32 as well, I'm not sure why it's rv64-only. checksyscalls is complaining about our lack of clone3() on rv32. Fixes: 56ac5e213933 ("riscv: enable sys_clone3 syscall for rv64") Signed-off-by: Palmer Dabbelt Reviewed-by: Arnd Bergmann Acked-by: Christian Brauner Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 29fdb11ca88d3c490a3d56f0dc77eb9444d086be Author: Tiezhu Yang Date: Mon Sep 27 15:06:14 2021 +0800 bpf, s390: Fix potential memory leak about jit_data [ Upstream commit 686cb8b9f6b46787f035afe8fbd132a74e6b1bdd ] Make sure to free jit_data through kfree() in the error path. Fixes: 1c8f9b91c456 ("bpf: s390: add JIT support for multi-function programs") Signed-off-by: Tiezhu Yang Acked-by: Ilya Leoshkevich Reviewed-by: Christian Borntraeger Signed-off-by: Christian Borntraeger Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 2c152d9da8fed3cade515eb5249fab805c87d831 Author: Tong Tiangen Date: Wed Sep 1 02:46:21 2021 +0000 riscv/vdso: make arch_setup_additional_pages wait for mmap_sem for write killable [ Upstream commit 8bb0ab3ae7a4dbe6cf32deb830cf2bdbf5736867 ] riscv architectures relying on mmap_sem for write in their arch_setup_additional_pages. If the waiting task gets killed by the oom killer it would block oom_reaper from asynchronous address space reclaim and reduce the chances of timely OOM resolving. Wait for the lock in the killable mode and return with EINTR if the task got killed while waiting. Signed-off-by: Tong Tiangen Reviewed-by: Kefeng Wang Fixes: 76d2a0493a17 ("RISC-V: Init and Halt Code") Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit de834e12b96d90d7edd1374c9b12a62baa8cdb9b Author: Kewei Xu Date: Fri Sep 17 18:14:14 2021 +0800 i2c: mediatek: Add OFFSET_EXT_CONF setting back [ Upstream commit 3bce7703c7ba648bd9e174dc1413f422b7998833 ] In the commit be5ce0e97cc7 ("i2c: mediatek: Add i2c ac-timing adjust support"), we miss setting OFFSET_EXT_CONF register if i2c->dev_comp->timing_adjust is false, now add it back. Fixes: be5ce0e97cc7 ("i2c: mediatek: Add i2c ac-timing adjust support") Signed-off-by: Kewei Xu Reviewed-by: Qii Wang Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit f86de018fd7a24ee07372d55ffa7824f0c674a95 Author: Jamie Iles Date: Wed Sep 22 17:57:18 2021 +0100 i2c: acpi: fix resource leak in reconfiguration device addition [ Upstream commit 6558b646ce1c2a872fe1c2c7cb116f05a2c1950f ] acpi_i2c_find_adapter_by_handle() calls bus_find_device() which takes a reference on the adapter which is never released which will result in a reference count leak and render the adapter unremovable. Make sure to put the adapter after creating the client in the same manner that we do for OF. Fixes: 525e6fabeae2 ("i2c / ACPI: add support for ACPI reconfigure notifications") Signed-off-by: Jamie Iles Acked-by: Mika Westerberg [wsa: fixed title] Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 87990a60b45ff820e6ffb10d2f779892f400f7b5 Author: Alexey Kardashevskiy Date: Thu Sep 30 13:44:54 2021 +1000 powerpc/iommu: Report the correct most efficient DMA mask for PCI devices [ Upstream commit 23c216b335d1fbd716076e8263b54a714ea3cf0e ] According to dma-api.rst, the dma_get_required_mask() helper should return "the mask that the platform requires to operate efficiently". Which in the case of PPC64 means the bypass mask and not a mask from an IOMMU table which is shorter and slower to use due to map/unmap operations (especially expensive on "pseries"). However the existing implementation ignores the possibility of bypassing and returns the IOMMU table mask on the pseries platform which makes some drivers (mpt3sas is one example) choose 32bit DMA even though bypass is supported. The powernv platform sort of handles it by having a bigger default window with a mask >=40 but it only works as drivers choose 63/64bit if the required mask is >32 which is rather pointless. This reintroduces the bypass capability check to let drivers make a better choice of the DMA mask. Fixes: f1565c24b596 ("powerpc: use the generic dma_ops_bypass mode") Signed-off-by: Alexey Kardashevskiy Reviewed-by: Christoph Hellwig Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210930034454.95794-1-aik@ozlabs.ru Signed-off-by: Sasha Levin commit 985cca1ad11ed9c84b3922c6f05aef2d11e13e76 Author: Mike Manning Date: Tue Oct 5 14:03:42 2021 +0100 net: prefer socket bound to interface when not in VRF [ Upstream commit 8d6c414cd2fb74aa6812e9bfec6178f8246c4f3a ] The commit 6da5b0f027a8 ("net: ensure unbound datagram socket to be chosen when not in a VRF") modified compute_score() so that a device match is always made, not just in the case of an l3mdev skb, then increments the score also for unbound sockets. This ensures that sockets bound to an l3mdev are never selected when not in a VRF. But as unbound and bound sockets are now scored equally, this results in the last opened socket being selected if there are matches in the default VRF for an unbound socket and a socket bound to a dev that is not an l3mdev. However, handling prior to this commit was to always select the bound socket in this case. Reinstate this handling by incrementing the score only for bound sockets. The required isolation due to choosing between an unbound socket and a socket bound to an l3mdev remains in place due to the device match always being made. The same approach is taken for compute_score() for stream sockets. Fixes: 6da5b0f027a8 ("net: ensure unbound datagram socket to be chosen when not in a VRF") Fixes: e78190581aff ("net: ensure unbound stream socket to be chosen when not in a VRF") Signed-off-by: Mike Manning Reviewed-by: David Ahern Link: https://lore.kernel.org/r/cf0a8523-b362-1edf-ee78-eef63cbbb428@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 97aeed72af4f83ae51534f0a2473ff52f8d66236 Author: Sylwester Dziedziuch Date: Fri Sep 24 11:40:41 2021 +0200 i40e: Fix freeing of uninitialized misc IRQ vector [ Upstream commit 2e5a20573a926302b233b0c2e1077f5debc7ab2e ] When VSI set up failed in i40e_probe() as part of PF switch set up driver was trying to free misc IRQ vectors in i40e_clear_interrupt_scheme and produced a kernel Oops: Trying to free already-free IRQ 266 WARNING: CPU: 0 PID: 5 at kernel/irq/manage.c:1731 __free_irq+0x9a/0x300 Workqueue: events work_for_cpu_fn RIP: 0010:__free_irq+0x9a/0x300 Call Trace: ? synchronize_irq+0x3a/0xa0 free_irq+0x2e/0x60 i40e_clear_interrupt_scheme+0x53/0x190 [i40e] i40e_probe.part.108+0x134b/0x1a40 [i40e] ? kmem_cache_alloc+0x158/0x1c0 ? acpi_ut_update_ref_count.part.1+0x8e/0x345 ? acpi_ut_update_object_reference+0x15e/0x1e2 ? strstr+0x21/0x70 ? irq_get_irq_data+0xa/0x20 ? mp_check_pin_attr+0x13/0xc0 ? irq_get_irq_data+0xa/0x20 ? mp_map_pin_to_irq+0xd3/0x2f0 ? acpi_register_gsi_ioapic+0x93/0x170 ? pci_conf1_read+0xa4/0x100 ? pci_bus_read_config_word+0x49/0x70 ? do_pci_enable_device+0xcc/0x100 local_pci_probe+0x41/0x90 work_for_cpu_fn+0x16/0x20 process_one_work+0x1a7/0x360 worker_thread+0x1cf/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130 ? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x1f/0x40 The problem is that at that point misc IRQ vectors were not allocated yet and we get a call trace that driver is trying to free already free IRQ vectors. Add a check in i40e_clear_interrupt_scheme for __I40E_MISC_IRQ_REQUESTED PF state before calling i40e_free_misc_vector. This state is set only if misc IRQ vectors were properly initialized. Fixes: c17401a1dd21 ("i40e: use separate state bit for miscellaneous IRQ setup") Reported-by: PJ Waskiewicz Signed-off-by: Sylwester Dziedziuch Signed-off-by: Mateusz Palczewski Tested-by: Dave Switzer Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 2dc768a98c9b83f33a2bc98a275bf4b352d946f1 Author: Jiri Benc Date: Tue Sep 14 10:54:42 2021 +0200 i40e: fix endless loop under rtnl [ Upstream commit 857b6c6f665cca9828396d9743faf37fd09e9ac3 ] The loop in i40e_get_capabilities can never end. The problem is that although i40e_aq_discover_capabilities returns with an error if there's a firmware problem, the returned error is not checked. There is a check for pf->hw.aq.asq_last_status but that value is set to I40E_AQ_RC_OK on most firmware problems. When i40e_aq_discover_capabilities encounters a firmware problem, it will encounter the same problem on its next invocation. As the result, the loop becomes endless. We hit this with I40E_ERR_ADMIN_QUEUE_TIMEOUT but looking at the code, it can happen with a range of other firmware errors. I don't know what the correct behavior should be: whether the firmware should be retried a few times, or whether pf->hw.aq.asq_last_status should be always set to the encountered firmware error (but then it would be pointless and can be just replaced by the i40e_aq_discover_capabilities return value). However, the current behavior with an endless loop under the rtnl mutex(!) is unacceptable and Intel has not submitted a fix, although we explained the bug to them 7 months ago. This may not be the best possible fix but it's better than hanging the whole system on a firmware bug. Fixes: 56a62fc86895 ("i40e: init code and hardware support") Tested-by: Stefan Assmann Signed-off-by: Jiri Benc Reviewed-by: Jesse Brandeburg Tested-by: Dave Switzer Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit d3a07ca78acecae90a7c8b1af7a26cbfc59ba2c8 Author: Eric Dumazet Date: Tue Oct 5 18:01:38 2021 -0700 gve: report 64bit tx_bytes counter from gve_handle_report_stats() [ Upstream commit 17c37d748f2b122a95b6d0524d410302ff89a2b1 ] Each tx queue maintains a 64bit counter for bytes, there is no reason to truncate this to 32bit (or this has not been documented) Fixes: 24aeb56f2d38 ("gve: Add Gvnic stats AQ command and ethtool show/set-priv-flags.") Signed-off-by: Eric Dumazet Cc: Yangchun Fu Cc: Kuo Zhao Cc: David Awogbemila Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 35f6ddd934e6a2c9eb52a8bdf8fae72529c9a282 Author: Eric Dumazet Date: Tue Oct 5 17:30:30 2021 -0700 gve: fix gve_get_stats() [ Upstream commit 2f57d4975fa027eabd35fdf23a49f8222ef3abf2 ] gve_get_stats() can report wrong numbers if/when u64_stats_fetch_retry() returns true. What is needed here is to sample values in temporary variables, and only use them after each loop is ended. Fixes: f5cedc84a30d ("gve: Add transmit and receive support") Signed-off-by: Eric Dumazet Cc: Catherine Sullivan Cc: Sagi Shahar Cc: Jon Olson Cc: Willem de Bruijn Cc: Luigi Rizzo Cc: Jeroen de Borst Cc: Tao Liu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9a043022522e7966f87c39fd6248cbf8fc617046 Author: Eric Dumazet Date: Tue Oct 5 14:04:17 2021 -0700 rtnetlink: fix if_nlmsg_stats_size() under estimation [ Upstream commit d34367991933d28bd7331f67a759be9a8c474014 ] rtnl_fill_statsinfo() is filling skb with one mandatory if_stats_msg structure. nlmsg_put(skb, pid, seq, type, sizeof(struct if_stats_msg), flags); But if_nlmsg_stats_size() never considered the needed storage. This bug did not show up because alloc_skb(X) allocates skb with extra tailroom, because of added alignments. This could very well be changed in the future to have deterministic behavior. Fixes: 10c9ead9f3c6 ("rtnetlink: add new RTM_GETSTATS message to dump link stats") Signed-off-by: Eric Dumazet Cc: Roopa Prabhu Acked-by: Roopa Prabhu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 72c2a68f1d833d2793ee63c626c376a054e2dfe4 Author: Tao Liu Date: Tue Oct 5 19:42:20 2021 -0700 gve: Avoid freeing NULL pointer [ Upstream commit 922aa9bcac92b3ab6a423526a8e785b35a60b441 ] Prevent possible crashes when cleaning up after unsuccessful initializations. Fixes: 893ce44df5658 ("gve: Add basic driver framework for Compute Engine Virtual NIC") Signed-off-by: Tao Liu Signed-off-by: Catherine Sully Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5d903a694b087f2aec9f18b0e0dedeeebd66f7af Author: Catherine Sullivan Date: Tue Oct 5 19:42:19 2021 -0700 gve: Correct available tx qpl check [ Upstream commit d03477ee10f4bc35d3573cf1823814378ef2dca2 ] The qpl_map_size is rounded up to a multiple of sizeof(long), but the number of qpls doesn't have to be. Fixes: f5cedc84a30d2 ("gve: Add transmit and receive support") Signed-off-by: Catherine Sullivan Signed-off-by: Jeroen de Borst Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f69556a42043b5444ca712ee889829ba89fdcba8 Author: Yang Yingliang Date: Sat Sep 11 15:50:23 2021 +0800 drm/nouveau/debugfs: fix file release memory leak [ Upstream commit f5a8703a9c418c6fc54eb772712dfe7641e3991c ] When using single_open() for opening, single_release() should be called, otherwise the 'op' allocated in single_open() will be leaked. Fixes: 6e9fc177399f ("drm/nouveau/debugfs: add copy of sysfs pstate interface ported to debugfs") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Reviewed-by: Karol Herbst Signed-off-by: Karol Herbst Link: https://patchwork.freedesktop.org/patch/msgid/20210911075023.3969054-2-yangyingliang@huawei.com Signed-off-by: Maarten Lankhorst Signed-off-by: Sasha Levin commit 65fff0a8efcdca8d84ffe3e23057c3b32403482d Author: Yang Yingliang Date: Sat Sep 11 15:50:22 2021 +0800 drm/nouveau/kms/nv50-: fix file release memory leak [ Upstream commit 0b3d4945cc7e7ea1acd52cb06dfa83bfe265b6d5 ] When using single_open() for opening, single_release() should be called, otherwise the 'op' allocated in single_open() will be leaked. Fixes: 12885ecbfe62 ("drm/nouveau/kms/nvd9-: Add CRC support") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Reviewed-by: Karol Herbst Signed-off-by: Karol Herbst Link: https://patchwork.freedesktop.org/patch/msgid/20210911075023.3969054-1-yangyingliang@huawei.com Signed-off-by: Maarten Lankhorst Signed-off-by: Sasha Levin commit f86e19d918a85492ad1a01fcdc0ad5ecbdac6f96 Author: Jeremy Cline Date: Wed Dec 2 19:02:20 2020 -0500 drm/nouveau: avoid a use-after-free when BO init fails [ Upstream commit bcf34aa5082ee2343574bc3f4d1c126030913e54 ] nouveau_bo_init() is backed by ttm_bo_init() and ferries its return code back to the caller. On failures, ttm_bo_init() invokes the provided destructor which should de-initialize and free the memory. Thus, when nouveau_bo_init() returns an error the gem object has already been released and the memory freed by nouveau_bo_del_ttm(). Fixes: 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM object") Cc: Thierry Reding Signed-off-by: Jeremy Cline Reviewed-by: Lyude Paul Reviewed-by: Karol Herbst Signed-off-by: Karol Herbst Link: https://patchwork.freedesktop.org/patch/msgid/20201203000220.18238-1-jcline@redhat.com Signed-off-by: Maarten Lankhorst Signed-off-by: Sasha Levin commit 008224cdc12628d21a3eb92259fa3aa3ea5b22a1 Author: Mark Brown Date: Tue Sep 21 22:21:02 2021 +0100 video: fbdev: gbefb: Only instantiate device when built for IP32 [ Upstream commit 11b8e2bb986d23157e82e267fb8cc6b281dfdee9 ] The gbefb driver not only registers a driver but also the device for that driver. This is all well and good when run on the IP32 machines that are supported by the driver but since the driver supports building with COMPILE_TEST we might also be building on other platforms which do not have this hardware and will crash instantiating the driver. Add an IS_ENABLED() check so we compile out the device registration if we don't have the Kconfig option for the machine enabled. Fixes: 552ccf6b259d290c0c ("video: fbdev: gbefb: add COMPILE_TEST support") Signed-off-by: Mark Brown Cc: Bartlomiej Zolnierkiewicz Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210921212102.30803-1-broonie@kernel.org Signed-off-by: Maarten Lankhorst Signed-off-by: Sasha Levin commit d2ccbaaa6615332e4c28c6f99f54876414de1d1f Author: Jernej Skrabec Date: Wed Sep 15 19:58:36 2021 +0200 drm/sun4i: dw-hdmi: Fix HDMI PHY clock setup [ Upstream commit c64c8e04a12ed3e2238761e26cda78e72550dc98 ] Recent rework, which made HDMI PHY driver a platform device, inadvertely reversed clock setup order. HW is very touchy about it. Proper way is to handle controllers resets and clocks first and HDMI PHYs second. Currently, without this fix, first mode set completely fails (nothing on HDMI monitor) on H3 era PHYs. On H6, it still somehow work. Move HDMI PHY reset & clocks handling to sun8i_hdmi_phy_init() which will assure that code is executed after controllers reset & clocks are handled. Additionally, add sun8i_hdmi_phy_deinit() which will deinit them at controllers driver unload. Tested on A64, H3, H6 and R40. Fixes: 9bf3797796f5 ("drm/sun4i: dw-hdmi: Make HDMI PHY into a platform device") Signed-off-by: Jernej Skrabec Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20210915175836.3158839-1-jernej.skrabec@gmail.com Signed-off-by: Maarten Lankhorst Signed-off-by: Sasha Levin commit 18d2568cc7ffb05537a503bd2852d414e51b4fe9 Author: Tony Lindgren Date: Wed Sep 8 08:49:36 2021 +0300 bus: ti-sysc: Use CLKDM_NOAUTO for dra7 dcan1 for errata i893 [ Upstream commit b13a270ace2e4c70653aa1d1d0394c553905802f ] Commit 94f6345712b3 ("bus: ti-sysc: Implement quirk handling for CLKDM_NOAUTO") should have also added the quirk for dra7 dcan1 in addition to dcan2 for errata i893 handling. Let's also pass the quirk flag for legacy mode booting for if "ti,hwmods" dts property is used with related dcan hwmod data. This should be only needed if anybody needs to git bisect earlier stable trees though. Fixes: 94f6345712b3 ("bus: ti-sysc: Implement quirk handling for CLKDM_NOAUTO") Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 40a84fcae2bf3003cc4f84ea8d6040838031f7ff Author: John Garry Date: Thu Oct 22 19:02:26 2020 +0800 perf jevents: Tidy error handling [ Upstream commit fa1b41a74d1136cbdd6960f36d7b9c7aa35c8139 ] There is much duplication in the error handling for directory transvering for prcessing JSONs. Factor out the common code to tidy a bit. Signed-off-by: John Garry Reviewed-By: Kajol Jain Link: https://lore.kernel.org/r/1603364547-197086-2-git-send-email-john.garry@huawei.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 628b31d96711ebacca39a961ee676861ec2d63d0 Author: Eric Dumazet Date: Mon Oct 4 14:24:15 2021 -0700 netlink: annotate data races around nlk->bound [ Upstream commit 7707a4d01a648e4c655101a469c956cb11273655 ] While existing code is correct, KCSAN is reporting a data-race in netlink_insert / netlink_sendmsg [1] It is correct to read nlk->bound without a lock, as netlink_autobind() will acquire all needed locks. [1] BUG: KCSAN: data-race in netlink_insert / netlink_sendmsg write to 0xffff8881031c8b30 of 1 bytes by task 18752 on cpu 0: netlink_insert+0x5cc/0x7f0 net/netlink/af_netlink.c:597 netlink_autobind+0xa9/0x150 net/netlink/af_netlink.c:842 netlink_sendmsg+0x479/0x7c0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:703 [inline] sock_sendmsg net/socket.c:723 [inline] ____sys_sendmsg+0x360/0x4d0 net/socket.c:2392 ___sys_sendmsg net/socket.c:2446 [inline] __sys_sendmsg+0x1ed/0x270 net/socket.c:2475 __do_sys_sendmsg net/socket.c:2484 [inline] __se_sys_sendmsg net/socket.c:2482 [inline] __x64_sys_sendmsg+0x42/0x50 net/socket.c:2482 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff8881031c8b30 of 1 bytes by task 18751 on cpu 1: netlink_sendmsg+0x270/0x7c0 net/netlink/af_netlink.c:1891 sock_sendmsg_nosec net/socket.c:703 [inline] sock_sendmsg net/socket.c:723 [inline] __sys_sendto+0x2a8/0x370 net/socket.c:2019 __do_sys_sendto net/socket.c:2031 [inline] __se_sys_sendto net/socket.c:2027 [inline] __x64_sys_sendto+0x74/0x90 net/socket.c:2027 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0x00 -> 0x01 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 18751 Comm: syz-executor.0 Not tainted 5.14.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Fixes: da314c9923fe ("netlink: Replace rhash_portid with bound") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 144715fbab1be6a2fbb0062ae2a33da6eeee7935 Author: Sean Anderson Date: Mon Oct 4 17:50:02 2021 -0400 net: sfp: Fix typo in state machine debug string [ Upstream commit 25a9da6641f1f66006e93ddbefee13a437efa8c0 ] The string should be "tx_disable" to match the state enum. Fixes: 4005a7cb4f55 ("net: phy: sftp: print debug message with text, not numbers") Signed-off-by: Sean Anderson Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3ec73ffeef54596c32aff0e73fe60971b9c8b866 Author: Eric Dumazet Date: Mon Oct 4 12:55:22 2021 -0700 net/sched: sch_taprio: properly cancel timer from taprio_destroy() [ Upstream commit a56d447f196fa9973c568f54c0d76d5391c3b0c0 ] There is a comment in qdisc_create() about us not calling ops->reset() in some cases. err_out4: /* * Any broken qdiscs that would require a ops->reset() here? * The qdisc was never in action so it shouldn't be necessary. */ As taprio sets a timer before actually receiving a packet, we need to cancel it from ops->destroy, just in case ops->reset has not been called. syzbot reported: ODEBUG: free active (active state 0) object type: hrtimer hint: advance_sched+0x0/0x9a0 arch/x86/include/asm/atomic64_64.h:22 WARNING: CPU: 0 PID: 8441 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505 Modules linked in: CPU: 0 PID: 8441 Comm: syz-executor813 Not tainted 5.14.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505 Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd e0 d3 e3 89 4c 89 ee 48 c7 c7 e0 c7 e3 89 e8 5b 86 11 05 <0f> 0b 83 05 85 03 92 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3 RSP: 0018:ffffc9000130f330 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000 RDX: ffff88802baeb880 RSI: ffffffff815d87b5 RDI: fffff52000261e58 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815d25ee R11: 0000000000000000 R12: ffffffff898dd020 R13: ffffffff89e3ce20 R14: ffffffff81653630 R15: dffffc0000000000 FS: 0000000000f0d300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffb64b3e000 CR3: 0000000036557000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __debug_check_no_obj_freed lib/debugobjects.c:987 [inline] debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1018 slab_free_hook mm/slub.c:1603 [inline] slab_free_freelist_hook+0x171/0x240 mm/slub.c:1653 slab_free mm/slub.c:3213 [inline] kfree+0xe4/0x540 mm/slub.c:4267 qdisc_create+0xbcf/0x1320 net/sched/sch_api.c:1299 tc_modify_qdisc+0x4c8/0x1a60 net/sched/sch_api.c:1663 rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5571 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504 netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340 netlink_sendmsg+0x86d/0xdb0 net/netlink/af_netlink.c:1929 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2403 ___sys_sendmsg+0xf3/0x170 net/socket.c:2457 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2486 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 Fixes: 44d4775ca518 ("net/sched: sch_taprio: reset child qdiscs before freeing them") Signed-off-by: Eric Dumazet Cc: Davide Caratti Reported-by: syzbot Acked-by: Vinicius Costa Gomes Acked-by: Davide Caratti Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 60955b65bd6a7dca624dd36c9a77b3326a6851a6 Author: Eric Dumazet Date: Mon Oct 4 18:05:08 2021 -0700 net: bridge: fix under estimation in br_get_linkxstats_size() [ Upstream commit 0854a0513321cf70bea5fa483ebcaa983cc7c62e ] Commit de1799667b00 ("net: bridge: add STP xstats") added an additional nla_reserve_64bit() in br_fill_linkxstats(), but forgot to update br_get_linkxstats_size() accordingly. This can trigger the following in rtnl_stats_get() WARN_ON(err == -EMSGSIZE); Fixes: de1799667b00 ("net: bridge: add STP xstats") Signed-off-by: Eric Dumazet Cc: Vivien Didelot Cc: Nikolay Aleksandrov Acked-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c480d15190eba5a552aa66570dceeaba4863048b Author: Eric Dumazet Date: Mon Oct 4 18:05:07 2021 -0700 net: bridge: use nla_total_size_64bit() in br_get_linkxstats_size() [ Upstream commit dbe0b88064494b7bb6a9b2aa7e085b14a3112d44 ] bridge_fill_linkxstats() is using nla_reserve_64bit(). We must use nla_total_size_64bit() instead of nla_total_size() for corresponding data structure. Fixes: 1080ab95e3c7 ("net: bridge: add support for IGMP/MLD stats and export them via netlink") Signed-off-by: Eric Dumazet Cc: Nikolay Aleksandrov Cc: Vivien Didelot Acked-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit cb8880680bdfde95aa4836807d81400f0a449117 Author: Oleksij Rempel Date: Tue Sep 28 15:49:40 2021 +0200 ARM: imx6: disable the GIC CPU interface before calling stby-poweroff sequence [ Upstream commit 783f3db030563f7bcdfe2d26428af98ea1699a8e ] Any pending interrupt can prevent entering standby based power off state. To avoid it, disable the GIC CPU interface. Fixes: 8148d2136002 ("ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set") Signed-off-by: Oleksij Rempel Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 2b0035d1058a8535f99e57f55f6045bda08f81c6 Author: Geert Uytterhoeven Date: Fri Sep 24 14:35:12 2021 +0200 dt-bindings: drm/bridge: ti-sn65dsi86: Fix reg value [ Upstream commit b2d70c0dbf2731a37d1c7bcc86ab2387954d5f56 ] make dtbs_check: arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dt.yaml: bridge@2c: reg:0:0: 45 was expected According to the datasheet, the I2C address can be either 0x2c or 0x2d, depending on the ADDR control input. Fixes: e3896e6dddf0b821 ("dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings") Signed-off-by: Geert Uytterhoeven Reviewed-by: Kieran Bingham Link: https://lore.kernel.org/r/08f73c2aa0d4e580303357dfae107d084d962835.1632486753.git.geert+renesas@glider.be Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit 10afd15972630267b01393ae1e133ee48ba814c7 Author: Michael Walle Date: Thu Oct 1 11:11:30 2020 +0200 arm64: dts: ls1028a: add missing CAN nodes [ Upstream commit 04fa4f03e3533f51b4db19cb487435f5862a0514 ] The LS1028A has two FlexCAN controller. These are compatible with the ones from the LX2160A. Add the nodes. The first controller was tested on the Kontron sl28 board. Signed-off-by: Michael Walle Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 95ba03fb4cb12fb72f6c3d28a1d0388ad4ad9290 Author: Andy Shevchenko Date: Fri Oct 1 19:20:33 2021 +0300 ptp_pch: Load module automatically if ID matches [ Upstream commit 7cd8b1542a7ba0720c5a0a85ed414a122015228b ] The driver can't be loaded automatically because it misses module alias to be provided. Add corresponding MODULE_DEVICE_TABLE() call to the driver. Fixes: 863d08ece9bf ("supports eg20t ptp clock") Signed-off-by: Andy Shevchenko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 442ea65d0ccb375588ee24027085ba121c9e0653 Author: Pali Rohár Date: Sat Oct 2 11:04:09 2021 +0200 powerpc/fsl/dts: Fix phy-connection-type for fm1mac3 [ Upstream commit eed183abc0d3b8adb64fd1363b7cea7986cd58d6 ] Property phy-connection-type contains invalid value "sgmii-2500" per scheme defined in file ethernet-controller.yaml. Correct phy-connection-type value should be "2500base-x". Signed-off-by: Pali Rohár Fixes: 84e0f1c13806 ("powerpc/mpc85xx: Add MDIO bus muxing support to the board device tree(s)") Acked-by: Scott Wood Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit acff2d182c0768a713cee77442caeb07668bd68f Author: Eric Dumazet Date: Thu Sep 30 14:22:39 2021 -0700 net_sched: fix NULL deref in fifo_set_limit() [ Upstream commit 560ee196fe9e5037e5015e2cdb14b3aecb1cd7dc ] syzbot reported another NULL deref in fifo_set_limit() [1] I could repro the issue with : unshare -n tc qd add dev lo root handle 1:0 tbf limit 200000 burst 70000 rate 100Mbit tc qd replace dev lo parent 1:0 pfifo_fast tc qd change dev lo root handle 1:0 tbf limit 300000 burst 70000 rate 100Mbit pfifo_fast does not have a change() operation. Make fifo_set_limit() more robust about this. [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 1cf99067 P4D 1cf99067 PUD 7ca49067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN CPU: 1 PID: 14443 Comm: syz-executor959 Not tainted 5.15.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. RSP: 0018:ffffc9000e2f7310 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffffffff8d6ecc00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff888024c27910 RDI: ffff888071e34000 RBP: ffff888071e34000 R08: 0000000000000001 R09: ffffffff8fcfb947 R10: 0000000000000001 R11: 0000000000000000 R12: ffff888024c27910 R13: ffff888071e34018 R14: 0000000000000000 R15: ffff88801ef74800 FS: 00007f321d897700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 00000000722c3000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: fifo_set_limit net/sched/sch_fifo.c:242 [inline] fifo_set_limit+0x198/0x210 net/sched/sch_fifo.c:227 tbf_change+0x6ec/0x16d0 net/sched/sch_tbf.c:418 qdisc_change net/sched/sch_api.c:1332 [inline] tc_modify_qdisc+0xd9a/0x1a60 net/sched/sch_api.c:1634 rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5572 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504 netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340 netlink_sendmsg+0x86d/0xdb0 net/netlink/af_netlink.c:1929 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: fb0305ce1b03 ("net-sched: consolidate default fifo qdisc setup") Signed-off-by: Eric Dumazet Reported-by: syzbot Link: https://lore.kernel.org/r/20210930212239.3430364-1-eric.dumazet@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0d2dd40a7be61b89a7c99dae8ee96389d27b413a Author: Pavel Skripkin Date: Thu Sep 30 20:50:28 2021 +0300 phy: mdio: fix memory leak [ Upstream commit ca6e11c337daf7925ff8a2aac8e84490a8691905 ] Syzbot reported memory leak in MDIO bus interface, the problem was in wrong state logic. MDIOBUS_ALLOCATED indicates 2 states: 1. Bus is only allocated 2. Bus allocated and __mdiobus_register() fails, but device_register() was called In case of device_register() has been called we should call put_device() to correctly free the memory allocated for this device, but mdiobus_free() calls just kfree(dev) in case of MDIOBUS_ALLOCATED state To avoid this behaviour we need to set bus->state to MDIOBUS_UNREGISTERED _before_ calling device_register(), because put_device() should be called even in case of device_register() failure. Link: https://lore.kernel.org/netdev/YVMRWNDZDUOvQjHL@shell.armlinux.org.uk/ Fixes: 46abc02175b3 ("phylib: give mdio buses a device tree presence") Reported-and-tested-by: syzbot+398e7dc692ddbbb4cfec@syzkaller.appspotmail.com Reviewed-by: Dan Carpenter Signed-off-by: Pavel Skripkin Link: https://lore.kernel.org/r/eceae1429fbf8fa5c73dd2a0d39d525aa905074d.1633024062.git.paskripkin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6e6f79e39830708f05179cc2d18f552e5cd8c43b Author: Moshe Shemesh Date: Thu Sep 23 17:57:47 2021 +0300 net/mlx5: E-Switch, Fix double allocation of acl flow counter [ Upstream commit a586775f83bd729ad60b56352dbe067f4bb0beee ] Flow counter is allocated in eswitch legacy acl setting functions without checking if already allocated by previous setting. Add a check to avoid such double allocation. Fixes: 07bab9502641 ("net/mlx5: E-Switch, Refactor eswitch ingress acl codes") Fixes: ea651a86d468 ("net/mlx5: E-Switch, Refactor eswitch egress acl codes") Signed-off-by: Moshe Shemesh Reviewed-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit d70cb6c77ad983f37a401fd29017da4546c57093 Author: Raed Salem Date: Thu Aug 26 17:07:17 2021 +0300 net/mlx5e: IPSEC RX, enable checksum complete [ Upstream commit f9a10440f0b1f33faa792af26f4e9823a9b8b6a4 ] Currently in Rx data path IPsec crypto offloaded packets uses csum_none flag, so checksum is handled by the stack, this naturally have some performance/cpu utilization impact on such flows. As Nvidia NIC starting from ConnectX6DX provides checksum complete value out of the box also for such flows there is no sense in taking csum_none path, furthermore the stack (xfrm) have the method to handle checksum complete corrections for such flows i.e. IPsec trailer removal and consequently checksum value adjustment. Because of the above and in addition the ConnectX6DX is the first HW which supports IPsec crypto offload then it is safe to report csum complete for IPsec offloaded traffic. Fixes: b2ac7541e377 ("net/mlx5e: IPsec: Add Connect-X IPsec Rx data path offload") Signed-off-by: Raed Salem Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 064faa8e8a9b50f5010c5aa5740e06d477677a89 Author: Tatsuhiko Yasumatsu Date: Thu Sep 30 22:55:45 2021 +0900 bpf: Fix integer overflow in prealloc_elems_and_freelist() [ Upstream commit 30e29a9a2bc6a4888335a6ede968b75cd329657a ] In prealloc_elems_and_freelist(), the multiplication to calculate the size passed to bpf_map_area_alloc() could lead to an integer overflow. As a result, out-of-bounds write could occur in pcpu_freelist_populate() as reported by KASAN: [...] [ 16.968613] BUG: KASAN: slab-out-of-bounds in pcpu_freelist_populate+0xd9/0x100 [ 16.969408] Write of size 8 at addr ffff888104fc6ea0 by task crash/78 [ 16.970038] [ 16.970195] CPU: 0 PID: 78 Comm: crash Not tainted 5.15.0-rc2+ #1 [ 16.970878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 [ 16.972026] Call Trace: [ 16.972306] dump_stack_lvl+0x34/0x44 [ 16.972687] print_address_description.constprop.0+0x21/0x140 [ 16.973297] ? pcpu_freelist_populate+0xd9/0x100 [ 16.973777] ? pcpu_freelist_populate+0xd9/0x100 [ 16.974257] kasan_report.cold+0x7f/0x11b [ 16.974681] ? pcpu_freelist_populate+0xd9/0x100 [ 16.975190] pcpu_freelist_populate+0xd9/0x100 [ 16.975669] stack_map_alloc+0x209/0x2a0 [ 16.976106] __sys_bpf+0xd83/0x2ce0 [...] The possibility of this overflow was originally discussed in [0], but was overlooked. Fix the integer overflow by changing elem_size to u64 from u32. [0] https://lore.kernel.org/bpf/728b238e-a481-eb50-98e9-b0f430ab01e7@gmail.com/ Fixes: 557c0c6e7df8 ("bpf: convert stackmap to pre-allocation") Signed-off-by: Tatsuhiko Yasumatsu Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20210930135545.173698-1-th.yasumatsu@gmail.com Signed-off-by: Sasha Levin commit d5f4b27c3cfcf8be787035d61cf254b747257ac7 Author: Tony Lindgren Date: Thu Sep 30 11:30:03 2021 +0300 soc: ti: omap-prm: Fix external abort for am335x pruss [ Upstream commit b232537074fcaf0c2837abbb217429c097bb7598 ] Starting with v5.15-rc1, we may now see some am335x beaglebone black device produce the following error on pruss probe: Unhandled fault: external abort on non-linefetch (0x1008) at 0xe0326000 This has started with the enabling of pruss for am335x in the dts files. Turns out the is caused by the PRM reset handling not waiting for the reset bit to clear. To fix the issue, let's always wait for the reset bit to clear, even if there is a separate reset status register. We attempted to fix a similar issue for dra7 iva with a udelay() in commit effe89e40037 ("soc: ti: omap-prm: Fix occasional abort on reset deassert for dra7 iva"). There is no longer a need for the udelay() for dra7 iva reset either with the check added for reset bit clearing. Cc: Drew Fustini Cc: Grygorii Strashko Cc: "H. Nikolaus Schaller" Cc: Robert Nelson Cc: Yongqin Liu Fixes: effe89e40037 ("soc: ti: omap-prm: Fix occasional abort on reset deassert for dra7 iva") Reported-by: Matti Vaittinen Tested-by: Matti Vaittinen Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 1d8f4447e8c442f8d2aeabfd3653957015043179 Author: Johan Almbladh Date: Tue Sep 28 11:13:10 2021 +0200 bpf, arm: Fix register clobbering in div/mod implementation [ Upstream commit 79e3445b38e0cab94264a3894c0c3d57c930b97e ] On ARM CPUs that lack div/mod instructions, ALU32 BPF_DIV and BPF_MOD are implemented using a call to a helper function. Before, the emitted code for those function calls failed to preserve caller-saved ARM registers. Since some of those registers happen to be mapped to BPF registers, it resulted in eBPF register values being overwritten. This patch emits code to push and pop the remaining caller-saved ARM registers r2-r3 into the stack during the div/mod function call. ARM registers r0-r1 are used as arguments and return value, and those were already saved and restored correctly. Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler") Signed-off-by: Johan Almbladh Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin commit 29a19eaeb29d57f4576cf57ccac5a2740f1384db Author: Vladimir Zapolskiy Date: Fri Sep 24 15:21:54 2021 +0300 iwlwifi: pcie: add configuration of a Wi-Fi adapter on Dell XPS 15 [ Upstream commit fe5c735d0d47b495be6753d6aea4f8f78c909a0a ] There is a Killer AX1650 2x2 Wi-Fi 6 and Bluetooth 5.1 wireless adapter found on Dell XPS 15 (9510) laptop, its configuration was present on Linux v5.7, however accidentally it has been removed from the list of supported devices, let's add it back. The problem is manifested on driver initialization: Intel(R) Wireless WiFi driver for Linux iwlwifi 0000:00:14.3: enabling device (0000 -> 0002) iwlwifi: No config found for PCI dev 43f0/1651, rev=0x354, rfid=0x10a100 iwlwifi: probe of 0000:00:14.3 failed with error -22 Bug: https://bugzilla.kernel.org/show_bug.cgi?id=213939 Fixes: 3f910a25839b ("iwlwifi: pcie: convert all AX101 devices to the device tables") Cc: Julien Wajsberg Signed-off-by: Vladimir Zapolskiy Acked-by: Luca Coelho Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210924122154.2376577-1-vladimir.zapolskiy@linaro.org Signed-off-by: Sasha Levin commit 6b0132f73094d1f8d77ab20e02d7d2bf59c3496c Author: Max Filippov Date: Mon Sep 27 09:46:33 2021 -0700 xtensa: call irqchip_init only when CONFIG_USE_OF is selected [ Upstream commit 6489f8d0e1d93a3603d8dad8125797559e4cf2a2 ] During boot time kernel configured with OF=y but USE_OF=n displays the following warnings and hangs shortly after starting userspace: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at kernel/irq/irqdomain.c:695 irq_create_mapping_affinity+0x29/0xc0 irq_create_mapping_affinity(, 6) called with NULL domain CPU: 0 PID: 0 Comm: swapper Not tainted 5.15.0-rc3-00001-gd67ed2510d28 #30 Call Trace: __warn+0x69/0xc4 warn_slowpath_fmt+0x6c/0x94 irq_create_mapping_affinity+0x29/0xc0 local_timer_setup+0x40/0x88 time_init+0xb1/0xe8 start_kernel+0x31d/0x3f4 _startup+0x13b/0x13b ---[ end trace 1e6630e1c5eda35b ]--- ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at arch/xtensa/kernel/time.c:141 local_timer_setup+0x58/0x88 error: can't map timer irq CPU: 0 PID: 0 Comm: swapper Tainted: G W 5.15.0-rc3-00001-gd67ed2510d28 #30 Call Trace: __warn+0x69/0xc4 warn_slowpath_fmt+0x6c/0x94 local_timer_setup+0x58/0x88 time_init+0xb1/0xe8 start_kernel+0x31d/0x3f4 _startup+0x13b/0x13b ---[ end trace 1e6630e1c5eda35c ]--- Failed to request irq 0 (timer) Fix that by calling irqchip_init only when CONFIG_USE_OF is selected and calling legacy interrupt controller init otherwise. Fixes: da844a81779e ("xtensa: add device trees support") Signed-off-by: Max Filippov Signed-off-by: Sasha Levin commit 3d288ed98314f31607832ba759f5fb1b90cd9e98 Author: Randy Dunlap Date: Fri Sep 24 20:29:51 2021 -0700 xtensa: use CONFIG_USE_OF instead of CONFIG_OF [ Upstream commit d67ed2510d28a1eb33171010d35cf52178cfcbdd ] CONFIG_OF can be set by a randconfig or by a user -- without setting the early flattree option (OF_EARLY_FLATTREE). This causes build errors. However, if randconfig or a user sets USE_OF in the Xtensa config, the right kconfig symbols are set to fix the build. Fixes these build errors: ../arch/xtensa/kernel/setup.c:67:19: error: ‘__dtb_start’ undeclared here (not in a function); did you mean ‘dtb_start’? 67 | void *dtb_start = __dtb_start; | ^~~~~~~~~~~ ../arch/xtensa/kernel/setup.c: In function 'xtensa_dt_io_area': ../arch/xtensa/kernel/setup.c:201:14: error: implicit declaration of function 'of_flat_dt_is_compatible'; did you mean 'of_machine_is_compatible'? [-Werror=implicit-function-declaration] 201 | if (!of_flat_dt_is_compatible(node, "simple-bus")) ../arch/xtensa/kernel/setup.c:204:18: error: implicit declaration of function 'of_get_flat_dt_prop' [-Werror=implicit-function-declaration] 204 | ranges = of_get_flat_dt_prop(node, "ranges", &len); ../arch/xtensa/kernel/setup.c:204:16: error: assignment to 'const __be32 *' {aka 'const unsigned int *'} from 'int' makes pointer from integer without a cast [-Werror=int-conversion] 204 | ranges = of_get_flat_dt_prop(node, "ranges", &len); | ^ ../arch/xtensa/kernel/setup.c: In function 'early_init_devtree': ../arch/xtensa/kernel/setup.c:228:9: error: implicit declaration of function 'early_init_dt_scan'; did you mean 'early_init_devtree'? [-Werror=implicit-function-declaration] 228 | early_init_dt_scan(params); ../arch/xtensa/kernel/setup.c:229:9: error: implicit declaration of function 'of_scan_flat_dt' [-Werror=implicit-function-declaration] 229 | of_scan_flat_dt(xtensa_dt_io_area, NULL); xtensa-elf-ld: arch/xtensa/mm/mmu.o:(.text+0x0): undefined reference to `xtensa_kio_paddr' Fixes: da844a81779e ("xtensa: add device trees support") Fixes: 6cb971114f63 ("xtensa: remap io area defined in device tree") Signed-off-by: Randy Dunlap Signed-off-by: Max Filippov Signed-off-by: Sasha Levin commit 997bec509a83aeb7f02a795c26ed0280f9a9ceab Author: Dmitry Baryshkov Date: Thu Sep 16 18:13:39 2021 +0300 arm64: dts: qcom: pm8150: use qcom,pm8998-pon binding [ Upstream commit a153d317168aa3d61a204fadc85bac3995381d33 ] Change pm8150 to use the qcom,pm8998-pon compatible string for the pon in order to pass reboot mode properly. Fixes: 5101f22a5c37 ("arm64: dts: qcom: pm8150: Add base dts file") Signed-off-by: Dmitry Baryshkov Tested-by: Amit Pundir Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210916151341.1797512-1-dmitry.baryshkov@linaro.org Signed-off-by: Sasha Levin commit fbca14abc11154683c9ebf534e6f23846a5318f4 Author: Arnd Bergmann Date: Mon Sep 20 14:23:44 2021 +0200 ath5k: fix building with LEDS=m [ Upstream commit fb8c3a3c52400512fc8b3b61150057b888c30b0d ] Randconfig builds still show a failure for the ath5k driver, similar to the one that was fixed for ath9k earlier: WARNING: unmet direct dependencies detected for MAC80211_LEDS Depends on [n]: NET [=y] && WIRELESS [=y] && MAC80211 [=y] && (LEDS_CLASS [=m]=y || LEDS_CLASS [=m]=MAC80211 [=y]) Selected by [m]: - ATH5K [=m] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_ATH [=y] && (PCI [=y] || ATH25) && MAC80211 [=y] net/mac80211/led.c: In function 'ieee80211_alloc_led_names': net/mac80211/led.c:34:22: error: 'struct led_trigger' has no member named 'name' 34 | local->rx_led.name = kasprintf(GFP_KERNEL, "%srx", | ^ Copying the same logic from my ath9k patch makes this one work as well, stubbing out the calls to the LED subsystem. Fixes: b64acb28da83 ("ath9k: fix build error with LEDS_CLASS=m") Fixes: 72cdab808714 ("ath9k: Do not select MAC80211_LEDS by default") Fixes: 3a078876caee ("ath5k: convert LED code to use mac80211 triggers") Link: https://lore.kernel.org/all/20210722105501.1000781-1-arnd@kernel.org/ Signed-off-by: Arnd Bergmann Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210920122359.353810-1-arnd@kernel.org Signed-off-by: Sasha Levin commit 8aef3824e9469445e748d00b89a9f18bb77cab03 Author: Long Li Date: Mon Aug 30 16:13:27 2021 -0700 PCI: hv: Fix sleep while in non-sleep context when removing child devices from the bus [ Upstream commit 41608b64b10b80fe00dd253cd8326ec8ad85930f ] In hv_pci_bus_exit, the code is holding a spinlock while calling pci_destroy_slot(), which takes a mutex. This is not safe for spinlock. Fix this by moving the children to be deleted to a list on the stack, and removing them after spinlock is released. Fixes: 94d22763207a ("PCI: hv: Fix a race condition when removing the device") Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Stephen Hemminger Cc: Wei Liu Cc: Dexuan Cui Cc: Lorenzo Pieralisi Cc: Rob Herring Cc: "Krzysztof Wilczyński" Cc: Bjorn Helgaas Cc: Michael Kelley Reported-by: Dan Carpenter Link: https://lore.kernel.org/linux-hyperv/20210823152130.GA21501@kili/ Signed-off-by: Long Li Reviewed-by: Wei Liu Link: https://lore.kernel.org/r/1630365207-20616-1-git-send-email-longli@linuxonhyperv.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit d9b838ae390e6867c62fd7330ddcc540350825d3 Author: Fabio Estevam Date: Tue Sep 14 14:17:15 2021 -0300 ARM: dts: imx6qdl-pico: Fix Ethernet support [ Upstream commit 450e7fe9b1b3c90eeed74a2fe0eeb13a7b57f3da ] Currently, it is no longer possible to retrieve a DHCP address on the imx6qdl-pico board. This issue has been exposed by commit f5d9aa79dfdf ("ARM: imx6q: remove clk-out fixup for the Atheros AR8031 and AR8035 PHYs"). Fix it by describing the qca,clk-out-frequency property as suggested by the commit above. Fixes: 98670a0bb0ef14bbb3 ("ARM: dts: imx6qdl: Add imx6qdl-pico support") Signed-off-by: Fabio Estevam Reviewed-by: Andrew Lunn Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 9e99ad4194a503bba830a148a8447b39a46299c0 Author: Marek Vasut Date: Sun Sep 5 02:01:37 2021 +0200 ARM: dts: imx: Fix USB host power regulator polarity on M53Menlo [ Upstream commit 5c187e2eb3f92daa38cb3d4ab45e1107ea34108e ] The MIC2025 switch input signal nEN is active low, describe it as such in the DT. The previous change to this regulator polarity was incorrectly influenced by broken quirks in gpiolib-of.c, which is now long fixed. So fix this regulator polarity setting here once and for all. Fixes: 3c3601cd6a6d3 ("ARM: dts: imx53: Update USB configuration on M53Menlo") Signed-off-by: Marek Vasut Cc: Shawn Guo Cc: Fabio Estevam Cc: NXP Linux Team Reviewed-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 2ba34cf0c16cbe381c9625b8133648036600012f Author: Marek Vasut Date: Sun Sep 5 02:00:48 2021 +0200 ARM: dts: imx: Add missing pinctrl-names for panel on M53Menlo [ Upstream commit c8c1efe14a4aadcfe93a158b1272e48298d2de15 ] The panel already contains pinctrl-0 phandle, but it is missing the default pinctrl-names property, so the pin configuration is ignored. Fill in the missing pinctrl-names property, so the pin configuration is applied. Fixes: d81765d693db6 ("ARM: dts: imx53: Update LCD panel node on M53Menlo") Signed-off-by: Marek Vasut Cc: Shawn Guo Cc: Fabio Estevam Cc: NXP Linux Team Reviewed-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 8f977e97b2b9284b76af46ccf64ce6ceecf60144 Author: Shawn Guo Date: Sat Aug 28 15:02:02 2021 +0800 soc: qcom: mdt_loader: Drop PT_LOAD check on hash segment [ Upstream commit 833d51d7c66d6708abbc02398892b96b950167b9 ] PT_LOAD type denotes that the segment should be loaded into the final firmware memory region. Hash segment is not one such, because it's only needed for PAS init and shouldn't be in the final firmware memory region. That's why mdt_phdr_valid() explicitly reject non PT_LOAD segment and hash segment. This actually makes the hash segment type check in qcom_mdt_read_metadata() unnecessary and redundant. For a hash segment, it won't be loaded into firmware memory region anyway, due to the QCOM_MDT_TYPE_HASH check in mdt_phdr_valid(), even if it has a PT_LOAD type for some reason (misusing or abusing?). Some firmware files on Sony phones are such examples, e.g WCNSS firmware of Sony Xperia M4 Aqua phone. The type of hash segment is just PT_LOAD. Drop the unnecessary hash segment type check in qcom_mdt_read_metadata() to fix firmware loading failure on these phones, while hash segment is still kept away from the final firmware memory region. Fixes: 498b98e93900 ("soc: qcom: mdt_loader: Support loading non-split images") Signed-off-by: Shawn Guo Reviewed-by: Marijn Suijten Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210828070202.7033-1-shawn.guo@linaro.org Signed-off-by: Sasha Levin commit 14f52004bda51ce7695abada3470752a73fa6b60 Author: Claudiu Beznea Date: Mon Aug 23 16:19:12 2021 +0300 ARM: at91: pm: do not panic if ram controllers are not enabled [ Upstream commit 1605de1b3ca66e3eddbca4b3c353c13c26476fe2 ] In case PM is enabled but there is no RAM controller information in DT the code will panic. Avoid such scenarios by not initializing platform specific PM code in case RAM controller is not provided via DT. Reported-by: Eugen Hristev Fixes: 827de1f123ba0 ("ARM: at91: remove at91_dt_initialize and machine init_early()") Fixes: 892e1f4a3ae58 ("ARM: at91: pm: add sama7g5 ddr phy controller") Signed-off-by: Claudiu Beznea Signed-off-by: Nicolas Ferre Link: https://lore.kernel.org/r/20210823131915.23857-2-claudiu.beznea@microchip.com Signed-off-by: Sasha Levin commit d89a313a573953074e57fc42170dd32a315659c1 Author: Marijn Suijten Date: Sun Aug 29 22:30:25 2021 +0200 ARM: dts: qcom: apq8064: Use 27MHz PXO clock as DSI PLL reference [ Upstream commit f1db21c315f4b4f8c3fbea56aac500673132d317 ] The 28NM DSI PLL driver for msm8960 calculates with a 27MHz reference clock and should hence use PXO, not CXO which runs at 19.2MHz. Note that none of the DSI PHY/PLL drivers currently use this "ref" clock; they all rely on (sometimes inexistant) global clock names and usually function normally without a parent clock. This discrepancy will be corrected in a future patch, for which this change needs to be in place first. Fixes: 6969d1d9c615 ("ARM: dts: qcom-apq8064: Set 'cxo_board' as ref clock of the DSI PHY") Reviewed-by: Dmitry Baryshkov Signed-off-by: Marijn Suijten Link: https://lore.kernel.org/r/20210829203027.276143-2-marijn.suijten@somainline.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 25ac88e601ebc7c44a5aa0a5fa094e59e53eaaae Author: Antonio Martorana Date: Mon Aug 16 17:24:39 2021 -0700 soc: qcom: socinfo: Fixed argument passed to platform_set_data() [ Upstream commit 9c5a4ec69bbf5951f84ada9e0db9c6c50de61808 ] Set qcom_socinfo pointer as data being stored instead of pointer to soc_device structure. Aligns with future calls to platform_get_data() which expects qcom_socinfo pointer. Fixes: efb448d0a3fc ("soc: qcom: Add socinfo driver") Signed-off-by: Antonio Martorana Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/1629159879-95777-1-git-send-email-amartora@codeaurora.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit ab8073794be3316ae6928225dd795c657eb8b05a Author: Nathan Chancellor Date: Sun Aug 15 12:18:52 2021 -0700 bus: ti-sysc: Add break in switch statement in sysc_init_soc() [ Upstream commit e879f855e590b40fe3c79f2fbd8f65ca3c724120 ] After commit a6d90e9f2232 ("bus: ti-sysc: AM3: RNG is GP only"), clang with -Wimplicit-fallthrough enabled warns: drivers/bus/ti-sysc.c:2958:3: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough] default: ^ drivers/bus/ti-sysc.c:2958:3: note: insert 'break;' to avoid fall-through default: ^ break; 1 warning generated. Clang's version of this warning is a little bit more pedantic than GCC's. Add the missing break to satisfy it to match what has been done all over the kernel tree. Fixes: a6d90e9f2232 ("bus: ti-sysc: AM3: RNG is GP only") Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 427faa29e06f0709476ea1bd59758f997ec8b64e Author: Alexandre Ghiti Date: Sat Sep 18 18:02:21 2021 +0200 riscv: Flush current cpu icache before other cpus commit bb8958d5dc79acbd071397abb57b8756375fe1ce upstream. On SiFive Unmatched, I recently fell onto the following BUG when booting: [ 0.000000] ftrace: allocating 36610 entries in 144 pages [ 0.000000] Oops - illegal instruction [#1] [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.13.1+ #5 [ 0.000000] Hardware name: SiFive HiFive Unmatched A00 (DT) [ 0.000000] epc : riscv_cpuid_to_hartid_mask+0x6/0xae [ 0.000000] ra : __sbi_rfence_v02+0xc8/0x10a [ 0.000000] epc : ffffffff80007240 ra : ffffffff80009964 sp : ffffffff81803e10 [ 0.000000] gp : ffffffff81a1ea70 tp : ffffffff8180f500 t0 : ffffffe07fe30000 [ 0.000000] t1 : 0000000000000004 t2 : 0000000000000000 s0 : ffffffff81803e60 [ 0.000000] s1 : 0000000000000000 a0 : ffffffff81a22238 a1 : ffffffff81803e10 [ 0.000000] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000 [ 0.000000] a5 : 0000000000000000 a6 : ffffffff8000989c a7 : 0000000052464e43 [ 0.000000] s2 : ffffffff81a220c8 s3 : 0000000000000000 s4 : 0000000000000000 [ 0.000000] s5 : 0000000000000000 s6 : 0000000200000100 s7 : 0000000000000001 [ 0.000000] s8 : ffffffe07fe04040 s9 : ffffffff81a22c80 s10: 0000000000001000 [ 0.000000] s11: 0000000000000004 t3 : 0000000000000001 t4 : 0000000000000008 [ 0.000000] t5 : ffffffcf04000808 t6 : ffffffe3ffddf188 [ 0.000000] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000002 [ 0.000000] [] riscv_cpuid_to_hartid_mask+0x6/0xae [ 0.000000] [] sbi_remote_fence_i+0x1e/0x26 [ 0.000000] [] flush_icache_all+0x12/0x1a [ 0.000000] [] patch_text_nosync+0x26/0x32 [ 0.000000] [] ftrace_init_nop+0x52/0x8c [ 0.000000] [] ftrace_process_locs.isra.0+0x29c/0x360 [ 0.000000] [] ftrace_init+0x80/0x130 [ 0.000000] [] start_kernel+0x5c4/0x8f6 [ 0.000000] ---[ end trace f67eb9af4d8d492b ]--- [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- While ftrace is looping over a list of addresses to patch, it always failed when patching the same function: riscv_cpuid_to_hartid_mask. Looking at the backtrace, the illegal instruction is encountered in this same function. However, patch_text_nosync, after patching the instructions, calls flush_icache_range. But looking at what happens in this function: flush_icache_range -> flush_icache_all -> sbi_remote_fence_i -> __sbi_rfence_v02 -> riscv_cpuid_to_hartid_mask The icache and dcache of the current cpu are never synchronized between the patching of riscv_cpuid_to_hartid_mask and calling this same function. So fix this by flushing the current cpu's icache before asking for the other cpus to do the same. Signed-off-by: Alexandre Ghiti Fixes: fab957c11efe ("RISC-V: Atomic and Locking Code") Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit 05287407dedf5275ce2e98eb5cd0dd03922eb3cd Author: David Heidelberg Date: Wed Aug 18 08:53:17 2021 +0200 ARM: dts: qcom: apq8064: use compatible which contains chipid commit f5c03f131dae3f06d08464e6157dd461200f78d9 upstream. Also resolves these kernel warnings for APQ8064: adreno 4300000.adreno-3xx: Using legacy qcom,chipid binding! adreno 4300000.adreno-3xx: Use compatible qcom,adreno-320.2 instead. Tested on Nexus 7 2013, no functional changes. Cc: Signed-off-by: David Heidelberg Link: https://lore.kernel.org/r/20210818065317.19822-1-david@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit ac06fe40e8896c96786b47857ddc50738a103f6e Author: Michal Vokáč Date: Wed Aug 18 09:02:08 2021 +0200 ARM: dts: imx6dl-yapp4: Fix lp5562 LED driver probe commit 9b663b34c94a78f39fa2c7a8271b1f828b546e16 upstream. Since the LED multicolor framework support was added in commit 92a81562e695 ("leds: lp55xx: Add multicolor framework support to lp55xx") LEDs on this platform stopped working. Author of the framework attempted to accommodate this DT to the framework in commit b86d3d21cd4c ("ARM: dts: imx6dl-yapp4: Add reg property to the lp5562 channel node") but that is not sufficient. A color property is now required even if the multicolor framework is not used, otherwise the driver probe fails: lp5562: probe of 1-0030 failed with error -22 Add the color property to fix this. Fixes: 92a81562e695 ("leds: lp55xx: Add multicolor framework support to lp55xx") Cc: Cc: linux-leds@vger.kernel.org Signed-off-by: Michal Vokáč Acked-by: Pavel Machek Reviewed-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 71d3ce62ac88190c63eb470e86fe76fc7e19bb0f Author: Roger Quadros Date: Thu Sep 2 12:58:28 2021 +0300 ARM: dts: omap3430-sdp: Fix NAND device node commit 80d680fdccba214e8106dc1aa33de5207ad75394 upstream. Nand is on CS1 so reg properties first field should be 1 not 0. Fixes: 44e4716499b8 ("ARM: dts: omap3: Fix NAND device nodes") Cc: stable@vger.kernel.org # v4.6+ Signed-off-by: Roger Quadros Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman commit f9a855d1bcb2630db6163de363945c9c84feaa46 Author: Juergen Gross Date: Tue Oct 5 15:34:33 2021 +0200 xen/balloon: fix cancelled balloon action commit 319933a80fd4f07122466a77f93e5019d71be74c upstream. In case a ballooning action is cancelled the new kernel thread handling the ballooning might end up in a busy loop. Fix that by handling the cancelled action gracefully. While at it introduce a short wait for the BP_WAIT case. Cc: stable@vger.kernel.org Fixes: 8480ed9c2bbd56 ("xen/balloon: use a kernel thread instead a workqueue") Reported-by: Marek Marczykowski-Górecki Signed-off-by: Juergen Gross Tested-by: Jason Andryuk Reviewed-by: Boris Ostrovsky Link: https://lore.kernel.org/r/20211005133433.32008-1-jgross@suse.com Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 9aac782ab0ab0fd0a8e507a6294359c2f5cf182d Author: J. Bruce Fields Date: Fri Oct 1 09:59:21 2021 -0400 SUNRPC: fix sign error causing rpcsec_gss drops commit 2ba5acfb34957e8a7fe47cd78c77ca88e9cc2b03 upstream. If sd_max is unsigned, then sd_max - GSS_SEQ_WIN is a very large number whenever sd_max is less than GSS_SEQ_WIN, and the comparison: seq_num <= sd->sd_max - GSS_SEQ_WIN in gss_check_seq_num is pretty much always true, even when that's clearly not what was intended. This was causing pynfs to hang when using krb5, because pynfs uses zero as the initial gss sequence number. That's perfectly legal, but this logic error causes knfsd to drop the rpc in that case. Out-of-order sequence IDs in the first GSS_SEQ_WIN (128) calls will also cause this. Fixes: 10b9d99a3dbb ("SUNRPC: Augment server-side rpcgss tracepoints") Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 8f174a208c4c7dae73b36db2ca84d06ee901ecb1 Author: Trond Myklebust Date: Thu Sep 30 15:44:41 2021 -0400 nfsd4: Handle the NFSv4 READDIR 'dircount' hint being zero commit f2e717d655040d632c9015f19aa4275f8b16e7f2 upstream. RFC3530 notes that the 'dircount' field may be zero, in which case the recommendation is to ignore it, and only enforce the 'maxcount' field. In RFC5661, this recommendation to ignore a zero valued field becomes a requirement. Fixes: aee377644146 ("nfsd4: fix rd_dircount enforcement") Cc: Signed-off-by: Trond Myklebust Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 12d4b179022ac7d07aa263b46159779536b3c6a6 Author: Patrick Ho Date: Sat Aug 21 02:56:26 2021 -0400 nfsd: fix error handling of register_pernet_subsys() in init_nfsd() commit 1d625050c7c2dd877e108e382b8aaf1ae3cfe1f4 upstream. init_nfsd() should not unregister pernet subsys if the register fails but should instead unwind from the last successful operation which is register_filesystem(). Unregistering a failed register_pernet_subsys() call can result in a kernel GPF as revealed by programmatically injecting an error in register_pernet_subsys(). Verified the fix handled failure gracefully with no lingering nfsd entry in /proc/filesystems. This change was introduced by the commit bd5ae9288d64 ("nfsd: register pernet ops last, unregister first"), the original error handling logic was correct. Fixes: bd5ae9288d64 ("nfsd: register pernet ops last, unregister first") Cc: stable@vger.kernel.org Signed-off-by: Patrick Ho Acked-by: J. Bruce Fields Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 1bc2f315a215585f8bc07257542e67373c86e801 Author: Miklos Szeredi Date: Mon Sep 27 11:23:57 2021 +0200 ovl: fix IOCB_DIRECT if underlying fs doesn't support direct IO commit 1dc1eed46f9fa4cb8a07baa24fb44c96d6dd35c9 upstream. Normally the check at open time suffices, but e.g loop device does set IOCB_DIRECT after doing its own checks (which are not sufficent for overlayfs). Make sure we don't call the underlying filesystem read/write method with the IOCB_DIRECT if it's not supported. Reported-by: Huang Jianan Fixes: 16914e6fc7e1 ("ovl: add ovl_read_iter()") Cc: # v4.19 Tested-by: Huang Jianan Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 9763ffd4da217adfcbdcd519e9f434dfa3952fc3 Author: Zheng Liang Date: Fri Sep 24 09:16:27 2021 +0800 ovl: fix missing negative dentry check in ovl_rename() commit a295aef603e109a47af355477326bd41151765b6 upstream. The following reproducer mkdir lower upper work merge touch lower/old touch lower/new mount -t overlay overlay -olowerdir=lower,upperdir=upper,workdir=work merge rm merge/new mv merge/old merge/new & unlink upper/new may result in this race: PROCESS A: rename("merge/old", "merge/new"); overwrite=true,ovl_lower_positive(old)=true, ovl_dentry_is_whiteout(new)=true -> flags |= RENAME_EXCHANGE PROCESS B: unlink("upper/new"); PROCESS A: lookup newdentry in new_upperdir call vfs_rename() with negative newdentry and RENAME_EXCHANGE Fix by adding the missing check for negative newdentry. Signed-off-by: Zheng Liang Fixes: e9be9d5e76e3 ("overlay filesystem") Cc: # v3.18 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 1500f0c83670294b786e0cbf62c15da23fae1a26 Author: Claudiu Beznea Date: Fri Sep 24 11:28:51 2021 +0300 mmc: sdhci-of-at91: replace while loop with read_poll_timeout commit 30d4b990ec644e8bd49ef0a2f074fabc0d189e53 upstream. Replace while loop with read_poll_timeout(). Signed-off-by: Claudiu Beznea Acked-by: Adrian Hunter Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210924082851.2132068-3-claudiu.beznea@microchip.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 3a0feae5f642258f6a217560a2d8f8a773e79cf0 Author: Claudiu Beznea Date: Fri Sep 24 11:28:50 2021 +0300 mmc: sdhci-of-at91: wait for calibration done before proceed commit af467fad78f03a42de8b72190f6a595366b870db upstream. Datasheet specifies that at the end of calibration the SDMMC_CALCR_EN bit will be cleared. No commands should be send before calibration is done. Fixes: dbdea70f71d67 ("mmc: sdhci-of-at91: fix CALCR register being rewritten") Fixes: 727d836a375ad ("mmc: sdhci-of-at91: add DT property to enable calibration on full reset") Signed-off-by: Claudiu Beznea Acked-by: Adrian Hunter Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210924082851.2132068-2-claudiu.beznea@microchip.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit e5cb3680b958ed3eb66504c0865f767d760cc9cd Author: Neil Armstrong Date: Tue Sep 28 09:36:52 2021 +0200 mmc: meson-gx: do not use memcpy_to/fromio for dram-access-quirk commit 8a38a4d51c5055d0201542e5ea3c0cb287f6e223 upstream. The memory at the end of the controller only accepts 32bit read/write accesses, but the arm64 memcpy_to/fromio implementation only uses 64bit (which will be split into two 32bit access) and 8bit leading to incomplete copies to/from this memory when the buffer is not multiple of 8bytes. Add a local copy using writel/readl accesses to make sure we use the right memory access width. The switch to memcpy_to/fromio was done because of 285133040e6c ("arm64: Import latest memcpy()/memmove() implementation"), but using memcpy worked before since it mainly used 32bit memory acceses. Fixes: 103a5348c22c ("mmc: meson-gx: use memcpy_to/fromio for dram-access-quirk") Reported-by: Christian Hewitt Suggested-by: Martin Blumenstingl Signed-off-by: Neil Armstrong Tested-by: Martin Blumenstingl Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210928073652.434690-1-narmstrong@baylibre.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 13d17cc717d58034a472353ab0e3a84fb675c678 Author: Jan Beulich Date: Wed Sep 22 12:17:48 2021 +0200 xen/privcmd: fix error handling in mmap-resource processing commit e11423d6721dd63b23fb41ade5e8d0b448b17780 upstream. xen_pfn_t is the same size as int only on 32-bit builds (and not even on Arm32). Hence pfns[] can't be used directly to read individual error values returned from xen_remap_domain_mfn_array(); every other error indicator would be skipped/ignored on 64-bit. Fixes: 3ad0876554ca ("xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE") Cc: stable@vger.kernel.org Signed-off-by: Jan Beulich Reviewed-by: Boris Ostrovsky Signed-off-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/aa6d6a67-6889-338a-a910-51e889f792d5@suse.com Signed-off-by: Juergen Gross commit de1e8bd36ab4ba9a34911802f9c8f029621dcb67 Author: Ben Skeggs Date: Mon Sep 6 10:56:28 2021 +1000 drm/nouveau/kms/tu102-: delay enabling cursor until after assign_windows commit f732e2e34aa08493fdd762f3daa4e5f16bbf1e45 upstream. Prevent NVD core channel error code 67 occuring and hanging display, managed to reproduce on GA102 while testing suspend/resume scenarios. Required extension of earlier commit to fix interactions with EFI. Fixes: e78b1b545c6c ("drm/nouveau/kms/nv50: workaround EFI GOP window channel format differences") Signed-off-by: Ben Skeggs Cc: Lyude Paul Cc: Karol Herbst Cc: # v5.12+ Reviewed-by: Karol Herbst Signed-off-by: Karol Herbst Link: https://patchwork.freedesktop.org/patch/msgid/20210906005628.11499-2-skeggsb@gmail.com Signed-off-by: Maarten Lankhorst Signed-off-by: Greg Kroah-Hartman commit 1d4e9f27d20d73dd3f5b65b2febb4ef887b94b9b Author: Xu Yang Date: Tue Sep 28 19:16:39 2021 +0800 usb: typec: tcpm: handle SRC_STARTUP state if cc changes commit 6d91017a295e9790eec02c4e43f020cdb55f5d98 upstream. TCPM for DRP should do the same action as SRC_ATTACHED when cc changes in SRC_STARTUP state. Otherwise, TCPM will transition to SRC_UNATTACHED state which is not satisfied with the Type-C spec. Per Type-C spec: DRP port should move to Unattached.SNK instead of Unattached.SRC if sink removed. Fixes: 4b4e02c83167 ("typec: tcpm: Move out of staging") cc: Reviewed-by: Guenter Roeck Acked-by: Heikki Krogerus Signed-off-by: Xu Yang Link: https://lore.kernel.org/r/20210928111639.3854174-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman commit feb3fe702a589ccf95ad5c5312db35462ab80733 Author: Johan Hovold Date: Wed Sep 29 11:09:37 2021 +0200 USB: cdc-acm: fix break reporting commit 58fc1daa4d2e9789b9ffc880907c961ea7c062cc upstream. A recent change that started reporting break events forgot to push the event to the line discipline, which meant that a detected break would not be reported until further characters had been receive (the port could even have been closed and reopened in between). Fixes: 08dff274edda ("cdc-acm: fix BREAK rx code path adding necessary calls") Cc: stable@vger.kernel.org Acked-by: Oliver Neukum Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210929090937.7410-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit fc8b3e838bdf343e3341df176fa7d8170ea5c691 Author: Johan Hovold Date: Wed Sep 29 11:09:36 2021 +0200 USB: cdc-acm: fix racy tty buffer accesses commit 65a205e6113506e69a503b61d97efec43fc10fd7 upstream. A recent change that started reporting break events to the line discipline caused the tty-buffer insertions to no longer be serialised by inserting events also from the completion handler for the interrupt endpoint. Completion calls for distinct endpoints are not guaranteed to be serialised. For example, in case a host-controller driver uses bottom-half completion, the interrupt and bulk-in completion handlers can end up running in parallel on two CPUs (high-and low-prio tasklets, respectively) thereby breaking the tty layer's single producer assumption. Fix this by holding the read lock also when inserting characters from the bulk endpoint. Fixes: 08dff274edda ("cdc-acm: fix BREAK rx code path adding necessary calls") Cc: stable@vger.kernel.org Acked-by: Oliver Neukum Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210929090937.7410-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit b3265b88e83b16c7be762fa5fb7e0632bce0002c Author: Fabio Estevam Date: Tue Sep 21 08:37:54 2021 -0300 usb: chipidea: ci_hdrc_imx: Also search for 'phys' phandle commit 8253a34bfae3278baca52fc1209b7c29270486ca upstream. When passing 'phys' in the devicetree to describe the USB PHY phandle (which is the recommended way according to Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt) the following NULL pointer dereference is observed on i.MX7 and i.MX8MM: [ 1.489344] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098 [ 1.498170] Mem abort info: [ 1.500966] ESR = 0x96000044 [ 1.504030] EC = 0x25: DABT (current EL), IL = 32 bits [ 1.509356] SET = 0, FnV = 0 [ 1.512416] EA = 0, S1PTW = 0 [ 1.515569] FSC = 0x04: level 0 translation fault [ 1.520458] Data abort info: [ 1.523349] ISV = 0, ISS = 0x00000044 [ 1.527196] CM = 0, WnR = 1 [ 1.530176] [0000000000000098] user address but active_mm is swapper [ 1.536544] Internal error: Oops: 96000044 [#1] PREEMPT SMP [ 1.542125] Modules linked in: [ 1.545190] CPU: 3 PID: 7 Comm: kworker/u8:0 Not tainted 5.14.0-dirty #3 [ 1.551901] Hardware name: Kontron i.MX8MM N801X S (DT) [ 1.557133] Workqueue: events_unbound deferred_probe_work_func [ 1.562984] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) [ 1.568998] pc : imx7d_charger_detection+0x3f0/0x510 [ 1.573973] lr : imx7d_charger_detection+0x22c/0x510 This happens because the charger functions check for the phy presence inside the imx_usbmisc_data structure (data->usb_phy), but the chipidea core populates the usb_phy passed via 'phys' inside 'struct ci_hdrc' (ci->usb_phy) instead. This causes the NULL pointer dereference inside imx7d_charger_detection(). Fix it by also searching for 'phys' in case 'fsl,usbphy' is not found. Tested on a imx7s-warp board. Fixes: 746f316b753a ("usb: chipidea: introduce imx7d USB charger detection") Cc: stable@vger.kernel.org Reported-by: Heiko Thiery Tested-by: Frieder Schrempf Reviewed-by: Frieder Schrempf Acked-by: Peter Chen Signed-off-by: Fabio Estevam Link: https://lore.kernel.org/r/20210921113754.767631-1-festevam@gmail.com Signed-off-by: Greg Kroah-Hartman commit 16d728110bd76d1ebb4aad8bcf36596f7ce11be0 Author: Ben Hutchings Date: Tue Sep 21 16:34:42 2021 +0200 Partially revert "usb: Kconfig: using select for USB_COMMON dependency" commit 4d1aa9112c8e6995ef2c8a76972c9671332ccfea upstream. This reverts commit cb9c1cfc86926d0e86d19c8e34f6c23458cd3478 for USB_LED_TRIG. This config symbol has bool type and enables extra code in usb_common itself, not a separate driver. Enabling it should not force usb_common to be built-in! Fixes: cb9c1cfc8692 ("usb: Kconfig: using select for USB_COMMON dependency") Cc: stable Signed-off-by: Ben Hutchings Signed-off-by: Salvatore Bonaccorso Link: https://lore.kernel.org/r/20210921143442.340087-1-carnil@debian.org Signed-off-by: Greg Kroah-Hartman commit 5aa003b38148d584f20455ecac85c51187d0b71e Author: Greg Kroah-Hartman Date: Sat Oct 9 14:40:58 2021 +0200 Linux 5.10.72 Link: https://lore.kernel.org/r/20211008112716.914501436@linuxfoundation.org Tested-by: Fox Chen Tested-by: Jon Hunter Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Pavel Machek (CIP) Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Signed-off-by: Greg Kroah-Hartman commit 387aecdab7facf7af40ff1ce8ba2d819b1f11829 Author: Kate Hsuan Date: Fri Sep 3 17:44:11 2021 +0800 libata: Add ATA_HORKAGE_NO_NCQ_ON_ATI for Samsung 860 and 870 SSD. commit 7a8526a5cd51cf5f070310c6c37dd7293334ac49 upstream. Many users are reporting that the Samsung 860 and 870 SSD are having various issues when combined with AMD/ATI (vendor ID 0x1002) SATA controllers and only completely disabling NCQ helps to avoid these issues. Always disabling NCQ for Samsung 860/870 SSDs regardless of the host SATA adapter vendor will cause I/O performance degradation with well behaved adapters. To limit the performance impact to ATI adapters, introduce the ATA_HORKAGE_NO_NCQ_ON_ATI flag to force disable NCQ only for these adapters. Also, two libata.force parameters (noncqati and ncqati) are introduced to disable and enable the NCQ for the system which equipped with ATI SATA adapter and Samsung 860 and 870 SSDs. The user can determine NCQ function to be enabled or disabled according to the demand. After verifying the chipset from the user reports, the issue appears on AMD/ATI SB7x0/SB8x0/SB9x0 SATA Controllers and does not appear on recent AMD SATA adapters. The vendor ID of ATI should be 0x1002. Therefore, ATA_HORKAGE_NO_NCQ_ON_AMD was modified to ATA_HORKAGE_NO_NCQ_ON_ATI. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201693 Signed-off-by: Kate Hsuan Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20210903094411.58749-1-hpa@redhat.com Reviewed-by: Martin K. Petersen Signed-off-by: Jens Axboe Cc: Krzysztof Olędzki Signed-off-by: Greg Kroah-Hartman commit 02bf504bc32b2b29e0c30d1d55fb0a504962282b Author: Anand K Mistry Date: Wed Sep 29 17:04:21 2021 +1000 perf/x86: Reset destroy callback on event init failure commit 02d029a41dc986e2d5a77ecca45803857b346829 upstream. perf_init_event tries multiple init callbacks and does not reset the event state between tries. When x86_pmu_event_init runs, it unconditionally sets the destroy callback to hw_perf_event_destroy. On the next init attempt after x86_pmu_event_init, in perf_try_init_event, if the pmu's capabilities includes PERF_PMU_CAP_NO_EXCLUDE, the destroy callback will be run. However, if the next init didn't set the destroy callback, hw_perf_event_destroy will be run (since the callback wasn't reset). Looking at other pmu init functions, the common pattern is to only set the destroy callback on a successful init. Resetting the callback on failure tries to replicate that pattern. This was discovered after commit f11dd0d80555 ("perf/x86/amd/ibs: Extend PERF_PMU_CAP_NO_EXCLUDE to IBS Op") when the second (and only second) run of the perf tool after a reboot results in 0 samples being generated. The extra run of hw_perf_event_destroy results in active_events having an extra decrement on each perf run. The second run has active_events == 0 and every subsequent run has active_events < 0. When active_events == 0, the NMI handler will early-out and not record any samples. Signed-off-by: Anand K Mistry Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210929170405.1.I078b98ee7727f9ae9d6df8262bad7e325e40faf0@changeid Signed-off-by: Greg Kroah-Hartman commit b56475c29bd82589c5cab0c349476206ae7a2e40 Author: Maxim Levitsky Date: Tue Sep 14 18:48:12 2021 +0300 KVM: x86: nSVM: restore int_vector in svm_clear_vintr [ Upstream commit aee77e1169c1900fe4248dc186962e745b479d9e ] In svm_clear_vintr we try to restore the virtual interrupt injection that might be pending, but we fail to restore the interrupt vector. Signed-off-by: Maxim Levitsky Message-Id: <20210914154825.104886-2-mlevitsk@redhat.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit ae34f26d4a8487e37ab9cfdca72f447c1ef49aa5 Author: Fares Mehanna Date: Wed Sep 15 13:39:50 2021 +0000 kvm: x86: Add AMD PMU MSRs to msrs_to_save_all[] [ Upstream commit e1fc1553cd78292ab3521c94c9dd6e3e70e606a1 ] Intel PMU MSRs is in msrs_to_save_all[], so add AMD PMU MSRs to have a consistent behavior between Intel and AMD when using KVM_GET_MSRS, KVM_SET_MSRS or KVM_GET_MSR_INDEX_LIST. We have to add legacy and new MSRs to handle guests running without X86_FEATURE_PERFCTR_CORE. Signed-off-by: Fares Mehanna Message-Id: <20210915133951.22389-1-faresx@amazon.de> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 6d0ff920599960a22ea520afda99eed3096c0e12 Author: Sergey Senozhatsky Date: Thu Sep 2 12:11:00 2021 +0900 KVM: do not shrink halt_poll_ns below grow_start [ Upstream commit ae232ea460888dc5a8b37e840c553b02521fbf18 ] grow_halt_poll_ns() ignores values between 0 and halt_poll_ns_grow_start (10000 by default). However, when we shrink halt_poll_ns we may fall way below halt_poll_ns_grow_start and endup with halt_poll_ns values that don't make a lot of sense: like 1 or 9, or 19. VCPU1 trace (halt_poll_ns_shrink equals 2): VCPU1 grow 10000 VCPU1 shrink 5000 VCPU1 shrink 2500 VCPU1 shrink 1250 VCPU1 shrink 625 VCPU1 shrink 312 VCPU1 shrink 156 VCPU1 shrink 78 VCPU1 shrink 39 VCPU1 shrink 19 VCPU1 shrink 9 VCPU1 shrink 4 Mirror what grow_halt_poll_ns() does and set halt_poll_ns to 0 as soon as new shrink-ed halt_poll_ns value falls below halt_poll_ns_grow_start. Signed-off-by: Sergey Senozhatsky Signed-off-by: Paolo Bonzini Message-Id: <20210902031100.252080-1-senozhatsky@chromium.org> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit b8add3f47ae7fee564a941aa9ade3eb51ea997f0 Author: Oliver Upton Date: Tue Sep 21 17:11:21 2021 +0000 selftests: KVM: Align SMCCC call with the spec in steal_time [ Upstream commit 01f91acb55be7aac3950b89c458bcea9ef6e4f49 ] The SMC64 calling convention passes a function identifier in w0 and its parameters in x1-x17. Given this, there are two deviations in the SMC64 call performed by the steal_time test: the function identifier is assigned to a 64 bit register and the parameter is only 32 bits wide. Align the call with the SMCCC by using a 32 bit register to handle the function identifier and increasing the parameter width to 64 bits. Suggested-by: Andrew Jones Signed-off-by: Oliver Upton Reviewed-by: Andrew Jones Message-Id: <20210921171121.2148982-3-oupton@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 352b02562a3e01a640bf7d242ebf61003cf93c59 Author: Changbin Du Date: Fri Sep 24 15:43:41 2021 -0700 tools/vm/page-types: remove dependency on opt_file for idle page tracking [ Upstream commit ebaeab2fe87987cef28eb5ab174c42cd28594387 ] Idle page tracking can also be used for process address space, not only file mappings. Without this change, using with '-i' option for process address space encounters below errors reported. $ sudo ./page-types -p $(pidof bash) -i mark page idle: Bad file descriptor mark page idle: Bad file descriptor mark page idle: Bad file descriptor mark page idle: Bad file descriptor ... Link: https://lkml.kernel.org/r/20210917032826.10669-1-changbin.du@gmail.com Signed-off-by: Changbin Du Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 84778fd66d3d48638d34512a4b496955ff6b0b86 Author: Steve French Date: Thu Sep 23 16:00:31 2021 -0500 smb3: correct smb3 ACL security descriptor [ Upstream commit b06d893ef2492245d0319b4136edb4c346b687a3 ] Address warning: fs/smbfs_client/smb2pdu.c:2425 create_sd_buf() warn: struct type mismatch 'smb3_acl vs cifs_acl' Pointed out by Dan Carpenter via smatch code analysis tool Reported-by: Dan Carpenter Acked-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Sasha Levin commit a7be240d1703784be96d23715a0b716a0d2fcc34 Author: Marc Zyngier Date: Fri Sep 10 18:29:25 2021 +0100 irqchip/gic: Work around broken Renesas integration [ Upstream commit b78f26926b17cc289e4f16b63363abe0aa2e8efc ] Geert reported that the GIC driver locks up on a Renesas system since 005c34ae4b44f085 ("irqchip/gic: Atomically update affinity") fixed the driver to use writeb_relaxed() instead of writel_relaxed(). As it turns out, the interconnect used on this system mandates 32bit wide accesses for all MMIO transactions, even if the GIC architecture specifically mandates for some registers to be byte accessible. Gahhh... Work around the issue by crudly detecting the offending system, and falling back to an inefficient RMW+lock implementation. Reported-by: Geert Uytterhoeven Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/CAMuHMdV+Ev47K5NO8XHsanSq5YRMCHn2gWAQyV-q2LpJVy9HiQ@mail.gmail.com Signed-off-by: Sasha Levin commit 8724a2a0e6d95242fd9e5c5dcffbd55ab4194b66 Author: Wen Xiong Date: Thu Sep 16 22:24:21 2021 -0500 scsi: ses: Retry failed Send/Receive Diagnostic commands [ Upstream commit fbdac19e642899455b4e64c63aafe2325df7aafa ] Setting SCSI logging level with error=3, we saw some errors from enclosues: [108017.360833] ses 0:0:9:0: tag#641 Done: NEEDS_RETRY Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK cmd_age=0s [108017.360838] ses 0:0:9:0: tag#641 CDB: Receive Diagnostic 1c 01 01 00 20 00 [108017.427778] ses 0:0:9:0: Power-on or device reset occurred [108017.427784] ses 0:0:9:0: tag#641 Done: SUCCESS Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s [108017.427788] ses 0:0:9:0: tag#641 CDB: Receive Diagnostic 1c 01 01 00 20 00 [108017.427791] ses 0:0:9:0: tag#641 Sense Key : Unit Attention [current] [108017.427793] ses 0:0:9:0: tag#641 Add. Sense: Bus device reset function occurred [108017.427801] ses 0:0:9:0: Failed to get diagnostic page 0x1 [108017.427804] ses 0:0:9:0: Failed to bind enclosure -19 [108017.427895] ses 0:0:10:0: Attached Enclosure device [108017.427942] ses 0:0:10:0: Attached scsi generic sg18 type 13 Retry if the Send/Receive Diagnostic commands complete with a transient error status (NOT_READY or UNIT_ATTENTION with ASC 0x29). Link: https://lore.kernel.org/r/1631849061-10210-2-git-send-email-wenxiong@linux.ibm.com Reviewed-by: Brian King Reviewed-by: James Bottomley Signed-off-by: Wen Xiong Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 2e28f7dd3743bf8f386fa72b96e5da2898039df5 Author: Ansuel Smith Date: Tue Sep 7 23:25:42 2021 +0200 thermal/drivers/tsens: Fix wrong check for tzd in irq handlers [ Upstream commit cf96921876dcee4d6ac07b9de470368a075ba9ad ] Some devices can have some thermal sensors disabled from the factory. The current two irq handler functions check all the sensor by default and the check if the sensor was actually registered is wrong. The tzd is actually never set if the registration fails hence the IS_ERR check is wrong. Signed-off-by: Ansuel Smith Reviewed-by: Matthias Kaehlcke Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210907212543.20220-1-ansuelsmth@gmail.com Signed-off-by: Sasha Levin commit 7a670cfb0f4cba692a2cc0caa60810986ceeab3d Author: James Smart Date: Tue Sep 14 11:20:07 2021 +0200 nvme-fc: avoid race between time out and tear down [ Upstream commit e5445dae29d25d7b03e0a10d3d4277a1d0c8119b ] To avoid race between time out and tear down, in tear down process, first we quiesce the queue, and then delete the timer and cancel the time out work for the queue. This patch merges the admin and io sync ops into the queue teardown logic as shown in the RDMA patch 3017013dcc "nvme-rdma: avoid race between time out and tear down". There is no teardown_lock in nvme-fc. Signed-off-by: James Smart Tested-by: Daniel Wagner Reviewed-by: Himanshu Madhani Reviewed-by: Hannes Reinecke Reviewed-by: Daniel Wagner Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit c251d023ed22732fa9b0c367240afe1187b4fa6f Author: Daniel Wagner Date: Tue Sep 14 11:20:06 2021 +0200 nvme-fc: update hardware queues before using them [ Upstream commit 555f66d0f8a38537456acc77043d0e4469fcbe8e ] In case the number of hardware queues changes, we need to update the tagset and the mapping of ctx to hctx first. If we try to create and connect the I/O queues first, this operation will fail (target will reject the connect call due to the wrong number of queues) and hence we bail out of the recreate function. Then we will to try the very same operation again, thus we don't make any progress. Signed-off-by: Daniel Wagner Reviewed-by: Ming Lei Reviewed-by: Himanshu Madhani Reviewed-by: Hannes Reinecke Reviewed-by: James Smart Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit c4506403e1f32fc41a83a693a0a8f9f0bc13e171 Author: Shuah Khan Date: Wed Sep 15 15:28:06 2021 -0600 selftests:kvm: fix get_warnings_count() ignoring fscanf() return warn [ Upstream commit 39a71f712d8a13728febd8f3cb3f6db7e1fa7221 ] Fix get_warnings_count() to check fscanf() return value to get rid of the following warning: x86_64/mmio_warning_test.c: In function ‘get_warnings_count’: x86_64/mmio_warning_test.c:85:2: warning: ignoring return value of ‘fscanf’ declared with attribute ‘warn_unused_result’ [-Wunused-result] 85 | fscanf(f, "%d", &warnings); | ^~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Shuah Khan Acked-by: Paolo Bonzini Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit bcc4b4de63a44130608d9cb68aa8707c130163d2 Author: Li Zhijian Date: Wed Sep 15 21:45:54 2021 +0800 selftests: be sure to make khdr before other targets [ Upstream commit 8914a7a247e065438a0ec86a58c1c359223d2c9e ] LKP/0Day reported some building errors about kvm, and errors message are not always same: - lib/x86_64/processor.c:1083:31: error: ‘KVM_CAP_NESTED_STATE’ undeclared (first use in this function); did you mean ‘KVM_CAP_PIT_STATE2’? - lib/test_util.c:189:30: error: ‘MAP_HUGE_16KB’ undeclared (first use in this function); did you mean ‘MAP_HUGE_16GB’? Although kvm relies on the khdr, they still be built in parallel when -j is specified. In this case, it will cause compiling errors. Here we mark target khdr as NOTPARALLEL to make it be always built first. CC: Philip Li Reported-by: kernel test robot Signed-off-by: Li Zhijian Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 6a4aaf1d84f75fc86961d5982f2b43d1897de1d3 Author: Oded Gabbay Date: Sun Sep 12 10:25:49 2021 +0300 habanalabs/gaudi: fix LBW RR configuration [ Upstream commit 0a5ff77bf0a94468d541735f919a633f167787e9 ] Couple of fixes to the LBW RR configuration: 1. Add missing configuration of the SM RR registers in the DMA_IF. 2. Remove HBW range that doesn't belong. 3. Add entire gap + DBG area, from end of TPC7 to end of entire DBG space. Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit 2754fa3b73df7d0ae042f3ed6cfd9df9042f6262 Author: Yang Yingliang Date: Tue Aug 31 16:42:36 2021 +0800 usb: dwc2: check return value after calling platform_get_resource() [ Upstream commit 856e6e8e0f9300befa87dde09edb578555c99a82 ] It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20210831084236.1359677-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ed6574d4846936a063940c2c7a552d0bce52dc49 Author: Faizel K B Date: Thu Sep 2 17:14:44 2021 +0530 usb: testusb: Fix for showing the connection speed [ Upstream commit f81c08f897adafd2ed43f86f00207ff929f0b2eb ] testusb' application which uses 'usbtest' driver reports 'unknown speed' from the function 'find_testdev'. The variable 'entry->speed' was not updated from the application. The IOCTL mentioned in the FIXME comment can only report whether the connection is low speed or not. Speed is read using the IOCTL USBDEVFS_GET_SPEED which reports the proper speed grade. The call is implemented in the function 'handle_testdev' where the file descriptor was availble locally. Sample output is given below where 'high speed' is printed as the connected speed. sudo ./testusb -a high speed /dev/bus/usb/001/011 0 /dev/bus/usb/001/011 test 0, 0.000015 secs /dev/bus/usb/001/011 test 1, 0.194208 secs /dev/bus/usb/001/011 test 2, 0.077289 secs /dev/bus/usb/001/011 test 3, 0.170604 secs /dev/bus/usb/001/011 test 4, 0.108335 secs /dev/bus/usb/001/011 test 5, 2.788076 secs /dev/bus/usb/001/011 test 6, 2.594610 secs /dev/bus/usb/001/011 test 7, 2.905459 secs /dev/bus/usb/001/011 test 8, 2.795193 secs /dev/bus/usb/001/011 test 9, 8.372651 secs /dev/bus/usb/001/011 test 10, 6.919731 secs /dev/bus/usb/001/011 test 11, 16.372687 secs /dev/bus/usb/001/011 test 12, 16.375233 secs /dev/bus/usb/001/011 test 13, 2.977457 secs /dev/bus/usb/001/011 test 14 --> 22 (Invalid argument) /dev/bus/usb/001/011 test 17, 0.148826 secs /dev/bus/usb/001/011 test 18, 0.068718 secs /dev/bus/usb/001/011 test 19, 0.125992 secs /dev/bus/usb/001/011 test 20, 0.127477 secs /dev/bus/usb/001/011 test 21 --> 22 (Invalid argument) /dev/bus/usb/001/011 test 24, 4.133763 secs /dev/bus/usb/001/011 test 27, 2.140066 secs /dev/bus/usb/001/011 test 28, 2.120713 secs /dev/bus/usb/001/011 test 29, 0.507762 secs Signed-off-by: Faizel K B Link: https://lore.kernel.org/r/20210902114444.15106-1-faizel.kb@dicortech.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 60df9f55562a57173a11b6c7011eee40dfa48157 Author: Ming Lei Date: Mon Sep 6 17:01:12 2021 +0800 scsi: sd: Free scsi_disk device via put_device() [ Upstream commit 265dfe8ebbabae7959060bd1c3f75c2473b697ed ] After a device is initialized via device_initialize() it should be freed via put_device(). sd_probe() currently gets this wrong, fix it up. Link: https://lore.kernel.org/r/20210906090112.531442-1-ming.lei@redhat.com Reviewed-by: Bart Van Assche Reviewed-by: Christoph Hellwig Signed-off-by: Ming Lei Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 76c7063c7405f30758876af25cfc5e9e39b7bc6e Author: Dan Carpenter Date: Tue Sep 21 23:32:33 2021 +0300 ext2: fix sleeping in atomic bugs on error [ Upstream commit 372d1f3e1bfede719864d0d1fbf3146b1e638c88 ] The ext2_error() function syncs the filesystem so it sleeps. The caller is holding a spinlock so it's not allowed to sleep. ext2_statfs() <- disables preempt -> ext2_count_free_blocks() -> ext2_get_group_desc() Fix this by using WARN() to print an error message and a stack trace instead of using ext2_error(). Link: https://lore.kernel.org/r/20210921203233.GA16529@kili Signed-off-by: Dan Carpenter Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit b114f2d18e0f97e2776ccfd877f88b3f30ba54a9 Author: Linus Torvalds Date: Mon Sep 20 10:56:32 2021 -0700 sparc64: fix pci_iounmap() when CONFIG_PCI is not set [ Upstream commit d8b1e10a2b8efaf71d151aa756052fbf2f3b6d57 ] Guenter reported [1] that the pci_iounmap() changes remain problematic, with sparc64 allnoconfig and tinyconfig still not building due to the header file changes and confusion with the arch-specific pci_iounmap() implementation. I'm pretty convinced that sparc should just use GENERIC_IOMAP instead of doing its own thing, since it turns out that the sparc64 version of pci_iounmap() is somewhat buggy (see [2]). But in the meantime, this just fixes the build by avoiding the trivial re-definition of the empty case. Link: https://lore.kernel.org/lkml/20210920134424.GA346531@roeck-us.net/ [1] Link: https://lore.kernel.org/lkml/CAHk-=wgheheFx9myQyy5osh79BAazvmvYURAtub2gQtMvLrhqQ@mail.gmail.com/ [2] Reported-by: Guenter Roeck Cc: David Miller Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit fdfb3bc87381e46b43bb521dfa8b02628b38a955 Author: Jan Beulich Date: Fri Sep 17 08:27:10 2021 +0200 xen-netback: correct success/error reporting for the SKB-with-fraglist case [ Upstream commit 3ede7f84c7c21f93c5eac611d60eba3f2c765e0f ] When re-entering the main loop of xenvif_tx_check_gop() a 2nd time, the special considerations for the head of the SKB no longer apply. Don't mistakenly report ERROR to the frontend for the first entry in the list, even if - from all I can tell - this shouldn't matter much as the overall transmit will need to be considered failed anyway. Signed-off-by: Jan Beulich Reviewed-by: Paul Durrant Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a41938d07201d0e7793f5aade5574a49f32ae82f Author: Vladimir Oltean Date: Fri Sep 17 16:34:32 2021 +0300 net: mdio: introduce a shutdown method to mdio device drivers [ Upstream commit cf9579976f724ad517cc15b7caadea728c7e245c ] MDIO-attached devices might have interrupts and other things that might need quiesced when we kexec into a new kernel. Things are even more creepy when those interrupt lines are shared, and in that case it is absolutely mandatory to disable all interrupt sources. Moreover, MDIO devices might be DSA switches, and DSA needs its own shutdown method to unlink from the DSA master, which is a new requirement that appeared after commit 2f1e8ea726e9 ("net: dsa: link interfaces with the DSA master to get rid of lockdep warnings"). So introduce a ->shutdown method in the MDIO device driver structure. Signed-off-by: Vladimir Oltean Reviewed-by: Andrew Lunn Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 63c89930d4b5f6205b4f4f13498a37cee86d80fa Author: Filipe Manana Date: Wed Sep 8 19:05:44 2021 +0100 btrfs: fix mount failure due to past and transient device flush error [ Upstream commit 6b225baababf1e3d41a4250e802cbd193e1343fb ] When we get an error flushing one device, during a super block commit, we record the error in the device structure, in the field 'last_flush_error'. This is used to later check if we should error out the super block commit, depending on whether the number of flush errors is greater than or equals to the maximum tolerated device failures for a raid profile. However if we get a transient device flush error, unmount the filesystem and later try to mount it, we can fail the mount because we treat that past error as critical and consider the device is missing. Even if it's very likely that the error will happen again, as it's probably due to a hardware related problem, there may be cases where the error might not happen again. One example is during testing, and a test case like the new generic/648 from fstests always triggers this. The test cases generic/019 and generic/475 also trigger this scenario, but very sporadically. When this happens we get an error like this: $ mount /dev/sdc /mnt mount: /mnt wrong fs type, bad option, bad superblock on /dev/sdc, missing codepage or helper program, or other error. $ dmesg (...) [12918.886926] BTRFS warning (device sdc): chunk 13631488 missing 1 devices, max tolerance is 0 for writable mount [12918.888293] BTRFS warning (device sdc): writable mount is not allowed due to too many missing devices [12918.890853] BTRFS error (device sdc): open_ctree failed The failure happens because when btrfs_check_rw_degradable() is called at mount time, or at remount from RO to RW time, is sees a non zero value in a device's ->last_flush_error attribute, and therefore considers that the device is 'missing'. Fix this by setting a device's ->last_flush_error to zero when we close a device, making sure the error is not seen on the next mount attempt. We only need to track flush errors during the current mount, so that we never commit a super block if such errors happened. Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 50628b06e604401138c767b7b57600cbaae1597b Author: Qu Wenruo Date: Tue Aug 17 07:55:40 2021 +0800 btrfs: replace BUG_ON() in btrfs_csum_one_bio() with proper error handling [ Upstream commit bbc9a6eb5eec03dcafee266b19f56295e3b2aa8f ] There is a BUG_ON() in btrfs_csum_one_bio() to catch code logic error. It has indeed caught several bugs during subpage development. But the BUG_ON() itself will bring down the whole system which is an overkill. Replace it with a WARN() and exit gracefully, so that it won't crash the whole system while we can still catch the code logic error. Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 83050cc23909ae7fe788af2ff67cfe314fb714cd Author: Dai Ngo Date: Thu Sep 16 14:22:12 2021 -0400 nfsd: back channel stuck in SEQ4_STATUS_CB_PATH_DOWN [ Upstream commit 02579b2ff8b0becfb51d85a975908ac4ab15fba8 ] When the back channel enters SEQ4_STATUS_CB_PATH_DOWN state, the client recovers by sending BIND_CONN_TO_SESSION but the server fails to recover the back channel and leaves it as NFSD4_CB_DOWN. Fix by enhancing nfsd4_bind_conn_to_session to probe the back channel by calling nfsd4_probe_callback. Signed-off-by: Dai Ngo Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit f986cf270284e0dff977d95b33deebb590708583 Author: Hans de Goede Date: Sun Sep 5 15:02:10 2021 +0200 platform/x86: touchscreen_dmi: Update info for the Chuwi Hi10 Plus (CWI527) tablet [ Upstream commit 196159d278ae3b49e7bbb7c76822e6008fd89b97 ] Add info for getting the firmware directly from the UEFI for the Chuwi Hi10 Plus (CWI527), so that the user does not need to manually install the firmware in /lib/firmware/silead. This change will make the touchscreen on these devices work OOTB, without requiring any manual setup. Also tweak the min and width/height values a bit for more accurate position reporting. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210905130210.32810-2-hdegoede@redhat.com Signed-off-by: Sasha Levin commit e5611503249fd0cfa0c8262ee18cca39865ed972 Author: Hans de Goede Date: Sun Sep 5 15:02:09 2021 +0200 platform/x86: touchscreen_dmi: Add info for the Chuwi HiBook (CWI514) tablet [ Upstream commit 3bf1669b0e033c885ebcb1ddc2334088dd125f2d ] Add touchscreen info for the Chuwi HiBook (CWI514) tablet. This includes info for getting the firmware directly from the UEFI, so that the user does not need to manually install the firmware in /lib/firmware/silead. This change will make the touchscreen on these devices work OOTB, without requiring any manual setup. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210905130210.32810-1-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 2ababcd8c2ababe7f11032b928b9e8ab35af5e8c Author: Tobias Schramm Date: Fri Aug 27 07:03:57 2021 +0200 spi: rockchip: handle zero length transfers without timing out [ Upstream commit 5457773ef99f25fcc4b238ac76b68e28273250f4 ] Previously zero length transfers submitted to the Rokchip SPI driver would time out in the SPI layer. This happens because the SPI peripheral does not trigger a transfer completion interrupt for zero length transfers. Fix that by completing zero length transfers immediately at start of transfer. Signed-off-by: Tobias Schramm Link: https://lore.kernel.org/r/20210827050357.165409-1-t.schramm@manjaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5cd40b137cba45a5a3d0b9a8554f779a3e0e93b4 Author: Greg Kroah-Hartman Date: Wed Oct 6 15:56:04 2021 +0200 Linux 5.10.71 Link: https://lore.kernel.org/r/20211004125034.579439135@linuxfoundation.org Tested-by: Fox Chen Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Florian Fainelli Tested-by: Guenter Roeck Link: https://lore.kernel.org/r/20211005083301.812942169@linuxfoundation.org Tested-by: Fox Chen Tested-by: Jon Hunter Tested-by: Florian Fainelli Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: SSalvatore Bonaccorso Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman commit 96f439a7eda6e80b1f45a97da7d3020b259b04a4 Author: Pablo Neira Ayuso Date: Mon Sep 13 20:38:52 2021 +0200 netfilter: nf_tables: Fix oversized kvmalloc() calls commit 45928afe94a094bcda9af858b96673d59bc4a0e9 upstream. The commit 7661809d493b ("mm: don't allow oversized kvmalloc() calls") limits the max allocatable memory via kvmalloc() to MAX_INT. Reported-by: syzbot+cd43695a64bcd21b8596@syzkaller.appspotmail.com Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit e2d192301a0df8160d1555b66ae8611e8050e424 Author: Eric Dumazet Date: Fri Sep 17 15:15:56 2021 -0700 netfilter: conntrack: serialize hash resizes and cleanups commit e9edc188fc76499b0b9bd60364084037f6d03773 upstream. Syzbot was able to trigger the following warning [1] No repro found by syzbot yet but I was able to trigger similar issue by having 2 scripts running in parallel, changing conntrack hash sizes, and: for j in `seq 1 1000` ; do unshare -n /bin/true >/dev/null ; done It would take more than 5 minutes for net_namespace structures to be cleaned up. This is because nf_ct_iterate_cleanup() has to restart everytime a resize happened. By adding a mutex, we can serialize hash resizes and cleanups and also make get_next_corpse() faster by skipping over empty buckets. Even without resizes in the picture, this patch considerably speeds up network namespace dismantles. [1] INFO: task syz-executor.0:8312 can't die for more than 144 seconds. task:syz-executor.0 state:R running task stack:25672 pid: 8312 ppid: 6573 flags:0x00004006 Call Trace: context_switch kernel/sched/core.c:4955 [inline] __schedule+0x940/0x26f0 kernel/sched/core.c:6236 preempt_schedule_common+0x45/0xc0 kernel/sched/core.c:6408 preempt_schedule_thunk+0x16/0x18 arch/x86/entry/thunk_64.S:35 __local_bh_enable_ip+0x109/0x120 kernel/softirq.c:390 local_bh_enable include/linux/bottom_half.h:32 [inline] get_next_corpse net/netfilter/nf_conntrack_core.c:2252 [inline] nf_ct_iterate_cleanup+0x15a/0x450 net/netfilter/nf_conntrack_core.c:2275 nf_conntrack_cleanup_net_list+0x14c/0x4f0 net/netfilter/nf_conntrack_core.c:2469 ops_exit_list+0x10d/0x160 net/core/net_namespace.c:171 setup_net+0x639/0xa30 net/core/net_namespace.c:349 copy_net_ns+0x319/0x760 net/core/net_namespace.c:470 create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc1/0x1f0 kernel/nsproxy.c:226 ksys_unshare+0x445/0x920 kernel/fork.c:3128 __do_sys_unshare kernel/fork.c:3202 [inline] __se_sys_unshare kernel/fork.c:3200 [inline] __x64_sys_unshare+0x2d/0x40 kernel/fork.c:3200 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f63da68e739 RSP: 002b:00007f63d7c05188 EFLAGS: 00000246 ORIG_RAX: 0000000000000110 RAX: ffffffffffffffda RBX: 00007f63da792f80 RCX: 00007f63da68e739 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000040000000 RBP: 00007f63da6e8cc4 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f63da792f80 R13: 00007fff50b75d3f R14: 00007f63d7c05300 R15: 0000000000022000 Showing all locks held in the system: 1 lock held by khungtaskd/27: #0: ffffffff8b980020 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:6446 2 locks held by kworker/u4:2/153: #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline] #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic_long_set include/linux/atomic/atomic-long.h:41 [inline] #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: atomic_long_set include/linux/atomic/atomic-instrumented.h:1198 [inline] #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_data kernel/workqueue.c:634 [inline] #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_pool_and_clear_pending kernel/workqueue.c:661 [inline] #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x896/0x1690 kernel/workqueue.c:2268 #1: ffffc9000140fdb0 ((kfence_timer).work){+.+.}-{0:0}, at: process_one_work+0x8ca/0x1690 kernel/workqueue.c:2272 1 lock held by systemd-udevd/2970: 1 lock held by in:imklog/6258: #0: ffff88807f970ff0 (&f->f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100 fs/file.c:990 3 locks held by kworker/1:6/8158: 1 lock held by syz-executor.0/8312: 2 locks held by kworker/u4:13/9320: 1 lock held by syz-executor.5/10178: 1 lock held by syz-executor.4/10217: Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit deb2949417677649e2413266d7ce8c2ff73952b4 Author: Haimin Zhang Date: Fri Sep 3 10:37:06 2021 +0800 KVM: x86: Handle SRCU initialization failure during page track init commit eb7511bf9182292ef1df1082d23039e856d1ddfb upstream. Check the return of init_srcu_struct(), which can fail due to OOM, when initializing the page track mechanism. Lack of checking leads to a NULL pointer deref found by a modified syzkaller. Reported-by: TCS Robot Signed-off-by: Haimin Zhang Message-Id: <1630636626-12262-1-git-send-email-tcs_kernel@tencent.com> [Move the call towards the beginning of kvm_arch_init_vm. - Paolo] Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit f7ac4d24e1610b92689946fa88177673f1e88a3f Author: Anirudh Rayabharam Date: Thu Jun 24 00:10:29 2021 +0530 HID: usbhid: free raw_report buffers in usbhid_stop commit f7744fa16b96da57187dc8e5634152d3b63d72de upstream. Free the unsent raw_report buffers when the device is removed. Fixes a memory leak reported by syzbot at: https://syzkaller.appspot.com/bug?id=7b4fa7cb1a7c2d3342a2a8a6c53371c8c418ab47 Reported-by: syzbot+47b26cd837ececfc666d@syzkaller.appspotmail.com Tested-by: syzbot+47b26cd837ececfc666d@syzkaller.appspotmail.com Signed-off-by: Anirudh Rayabharam Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 57a269a1b12a3a6fe51f62e1be5e74494bad1d92 Author: Linus Torvalds Date: Wed Jul 14 09:45:49 2021 -0700 mm: don't allow oversized kvmalloc() calls commit 7661809d493b426e979f39ab512e3adf41fbcc69 upstream. 'kvmalloc()' is a convenience function for people who want to do a kmalloc() but fall back on vmalloc() if there aren't enough physically contiguous pages, or if the allocation is larger than what kmalloc() supports. However, let's make sure it doesn't get _too_ easy to do crazy things with it. In particular, don't allow big allocations that could be due to integer overflow or underflow. So make sure the allocation size fits in an 'int', to protect against trivial integer conversion issues. Acked-by: Willy Tarreau Cc: Kees Cook Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit da5b8b9319f044c2ca24f6602c54033931e0c1cc Author: Jozsef Kadlecsik Date: Mon Sep 6 18:26:34 2021 +0200 netfilter: ipset: Fix oversized kvmalloc() calls commit 7bbc3d385bd813077acaf0e6fdb2a86a901f5382 upstream. The commit commit 7661809d493b426e979f39ab512e3adf41fbcc69 Author: Linus Torvalds Date: Wed Jul 14 09:45:49 2021 -0700 mm: don't allow oversized kvmalloc() calls limits the max allocatable memory via kvmalloc() to MAX_INT. Apply the same limit in ipset. Reported-by: syzbot+3493b1873fb3ea827986@syzkaller.appspotmail.com Reported-by: syzbot+2b8443c35458a617c904@syzkaller.appspotmail.com Reported-by: syzbot+ee5cb15f4a0e85e0d54e@syzkaller.appspotmail.com Signed-off-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit dedfc35a2de2bae9fa3da8210a05bfd515f83fee Author: F.A.Sulaiman Date: Tue Aug 24 20:37:30 2021 +0530 HID: betop: fix slab-out-of-bounds Write in betop_probe commit 1e4ce418b1cb1a810256b5fb3fd33d22d1325993 upstream. Syzbot reported slab-out-of-bounds Write bug in hid-betopff driver. The problem is the driver assumes the device must have an input report but some malicious devices violate this assumption. So this patch checks hid_device's input is non empty before it's been used. Reported-by: syzbot+07efed3bc5a1407bd742@syzkaller.appspotmail.com Signed-off-by: F.A. SULAIMAN Reviewed-by: Pavel Skripkin Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 17ccc64e4fa5d3673528474bfeda814d95dc600a Author: Dan Carpenter Date: Thu Aug 26 16:04:27 2021 +0300 crypto: ccp - fix resource leaks in ccp_run_aes_gcm_cmd() commit 505d9dcb0f7ddf9d075e729523a33d38642ae680 upstream. There are three bugs in this code: 1) If we ccp_init_data() fails for &src then we need to free aad. Use goto e_aad instead of goto e_ctx. 2) The label to free the &final_wa was named incorrectly as "e_tag" but it should have been "e_final_wa". One error path leaked &final_wa. 3) The &tag was leaked on one error path. In that case, I added a free before the goto because the resource was local to that block. Fixes: 36cf515b9bbe ("crypto: ccp - Enable support for AES GCM on v5 CCPs") Reported-by: "minihanshen(沈明航)" Signed-off-by: Dan Carpenter Reviewed-by: John Allen Tested-by: John Allen Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 28f0fdbac0f52c411763a6bbc475b0643a5d8d28 Author: Dongliang Mu Date: Wed Jul 21 16:14:57 2021 +0800 usb: hso: remove the bailout parameter commit dcb713d53e2eadf42b878c12a471e74dc6ed3145 upstream. There are two invocation sites of hso_free_net_device. After refactoring hso_create_net_device, this parameter is useless. Remove the bailout in the hso_free_net_device and change the invocation sites of this function. Signed-off-by: Dongliang Mu Signed-off-by: David S. Miller [Backport this cleanup patch to 5.10 and 5.14 in order to keep the codebase consistent with the 4.14/4.19/5.4 patchseries] Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman commit 4ad4852b9adf1345561c202569fe88b0af21eabf Author: Shuming Fan Date: Mon Feb 8 17:40:42 2021 -0600 ASoC: dapm: use component prefix when checking widget names commit ae4fc532244b3bb4d86c397418d980b0c6be1dfd upstream. On a TigerLake SoundWire platform, we see these warnings: [ 27.360086] rt5682 sdw:0:25d:5682:0: ASoC: DAPM unknown pin MICBIAS [ 27.360092] rt5682 sdw:0:25d:5682:0: ASoC: DAPM unknown pin Vref2 This is root-caused to the addition of a component prefix in the machine driver. The tests in soc-dapm should account for a prefix instead of reporting an invalid issue. Reported-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Signed-off-by: Shuming Fan Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210208234043.59750-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Robert Lee Signed-off-by: Greg Kroah-Hartman commit 5c3a90b6ff75c18d9c8e1701b3b9b56580acfc61 Author: Eric Dumazet Date: Mon Sep 27 17:29:24 2021 -0700 net: udp: annotate data race around udp_sk(sk)->corkflag commit a9f5970767d11eadc805d5283f202612c7ba1f59 upstream. up->corkflag field can be read or written without any lock. Annotate accesses to avoid possible syzbot/KCSAN reports. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a7f4c633ae120562e91a0891101ed44eaa6c6d1e Author: Andrej Shadura Date: Thu Sep 16 17:33:11 2021 +0100 HID: u2fzero: ignore incomplete packets without data commit 22d65765f211cc83186fd8b87521159f354c0da9 upstream. Since the actual_length calculation is performed unsigned, packets shorter than 7 bytes (e.g. packets without data or otherwise truncated) or non-received packets ("zero" bytes) can cause buffer overflow. Link: https://bugzilla.kernel.org/show_bug.cgi?id=214437 Fixes: 42337b9d4d958("HID: add driver for U2F Zero built-in LED and RNG") Signed-off-by: Andrej Shadura Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 3770e21f60fc29326a7f3febfa8adc9a3c2dde62 Author: yangerkun Date: Tue Sep 14 19:14:15 2021 +0800 ext4: fix potential infinite loop in ext4_dx_readdir() commit 42cb447410d024e9d54139ae9c21ea132a8c384c upstream. When ext4_htree_fill_tree() fails, ext4_dx_readdir() can run into an infinite loop since if info->last_pos != ctx->pos this will reset the directory scan and reread the failing entry. For example: 1. a dx_dir which has 3 block, block 0 as dx_root block, block 1/2 as leaf block which own the ext4_dir_entry_2 2. block 1 read ok and call_filldir which will fill the dirent and update the ctx->pos 3. block 2 read fail, but we has already fill some dirent, so we will return back to userspace will a positive return val(see ksys_getdents64) 4. the second ext4_dx_readdir will reset the world since info->last_pos != ctx->pos, and will also init the curr_hash which pos to block 1 5. So we will read block1 too, and once block2 still read fail, we can only fill one dirent because the hash of the entry in block1(besides the last one) won't greater than curr_hash 6. this time, we forget update last_pos too since the read for block2 will fail, and since we has got the one entry, ksys_getdents64 can return success 7. Latter we will trapped in a loop with step 4~6 Cc: stable@kernel.org Signed-off-by: yangerkun Reviewed-by: Jan Kara Signed-off-by: Theodore Ts'o Link: https://lore.kernel.org/r/20210914111415.3921954-1-yangerkun@huawei.com Signed-off-by: Greg Kroah-Hartman commit a63474dbf692dd09b50fed592bc41f6de5f102fc Author: Theodore Ts'o Date: Thu Sep 2 11:36:01 2021 -0400 ext4: add error checking to ext4_ext_replay_set_iblocks() commit 1fd95c05d8f742abfe906620780aee4dbe1a2db0 upstream. If the call to ext4_map_blocks() fails due to an corrupted file system, ext4_ext_replay_set_iblocks() can get stuck in an infinite loop. This could be reproduced by running generic/526 with a file system that has inline_data and fast_commit enabled. The system will repeatedly log to the console: EXT4-fs warning (device dm-3): ext4_block_to_path:105: block 1074800922 > max in inode 131076 and the stack that it gets stuck in is: ext4_block_to_path+0xe3/0x130 ext4_ind_map_blocks+0x93/0x690 ext4_map_blocks+0x100/0x660 skip_hole+0x47/0x70 ext4_ext_replay_set_iblocks+0x223/0x440 ext4_fc_replay_inode+0x29e/0x3b0 ext4_fc_replay+0x278/0x550 do_one_pass+0x646/0xc10 jbd2_journal_recover+0x14a/0x270 jbd2_journal_load+0xc4/0x150 ext4_load_journal+0x1f3/0x490 ext4_fill_super+0x22d4/0x2c00 With this patch, generic/526 still fails, but system is no longer locking up in a tight loop. It's likely the root casue is that fast_commit replay is corrupting file systems with inline_data, and we probably need to add better error handling in the fast commit replay code path beyond what is done here, which essentially just breaks the infinite loop without reporting the to the higher levels of the code. Fixes: 8016E29F4362 ("ext4: fast commit recovery path") Cc: stable@kernel.org Cc: Harshad Shirwadkar Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 9ccf35492b084ecbc916761a5c6f42599450f013 Author: Jeffle Xu Date: Mon Aug 23 14:13:58 2021 +0800 ext4: fix reserved space counter leakage commit 6fed83957f21eff11c8496e9f24253b03d2bc1dc upstream. When ext4_insert_delayed block receives and recovers from an error from ext4_es_insert_delayed_block(), e.g., ENOMEM, it does not release the space it has reserved for that block insertion as it should. One effect of this bug is that s_dirtyclusters_counter is not decremented and remains incorrectly elevated until the file system has been unmounted. This can result in premature ENOSPC returns and apparent loss of free space. Another effect of this bug is that /sys/fs/ext4//delayed_allocation_blocks can remain non-zero even after syncfs has been executed on the filesystem. Besides, add check for s_dirtyclusters_counter when inode is going to be evicted and freed. s_dirtyclusters_counter can still keep non-zero until inode is written back in .evict_inode(), and thus the check is delayed to .destroy_inode(). Fixes: 51865fda28e5 ("ext4: let ext4 maintain extent status tree") Cc: stable@kernel.org Suggested-by: Gao Xiang Signed-off-by: Jeffle Xu Reviewed-by: Eric Whitney Signed-off-by: Theodore Ts'o Link: https://lore.kernel.org/r/20210823061358.84473-1-jefflexu@linux.alibaba.com Signed-off-by: Greg Kroah-Hartman commit dc0942168ab3e38e3a6e6368fae3ebc4b5f4ce2d Author: Hou Tao Date: Fri Aug 20 12:45:05 2021 +0800 ext4: limit the number of blocks in one ADD_RANGE TLV commit a2c2f0826e2b75560b31daf1cd9a755ab93cf4c6 upstream. Now EXT4_FC_TAG_ADD_RANGE uses ext4_extent to track the newly-added blocks, but the limit on the max value of ee_len field is ignored, and it can lead to BUG_ON as shown below when running command "fallocate -l 128M file" on a fast_commit-enabled fs: kernel BUG at fs/ext4/ext4_extents.h:199! invalid opcode: 0000 [#1] SMP PTI CPU: 3 PID: 624 Comm: fallocate Not tainted 5.14.0-rc6+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:ext4_fc_write_inode_data+0x1f3/0x200 Call Trace: ? ext4_fc_write_inode+0xf2/0x150 ext4_fc_commit+0x93b/0xa00 ? ext4_fallocate+0x1ad/0x10d0 ext4_sync_file+0x157/0x340 ? ext4_sync_file+0x157/0x340 vfs_fsync_range+0x49/0x80 do_fsync+0x3d/0x70 __x64_sys_fsync+0x14/0x20 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae Simply fixing it by limiting the number of blocks in one EXT4_FC_TAG_ADD_RANGE TLV. Fixes: aa75f4d3daae ("ext4: main fast-commit commit path") Cc: stable@kernel.org Signed-off-by: Hou Tao Signed-off-by: Theodore Ts'o Link: https://lore.kernel.org/r/20210820044505.474318-1-houtao1@huawei.com Signed-off-by: Greg Kroah-Hartman commit d11502fa26913f84883438c55fab0a8cb0d11474 Author: Ritesh Harjani Date: Sat Jun 5 10:39:32 2021 +0530 ext4: fix loff_t overflow in ext4_max_bitmap_size() commit 75ca6ad408f459f00b09a64f04c774559848c097 upstream. We should use unsigned long long rather than loff_t to avoid overflow in ext4_max_bitmap_size() for comparison before returning. w/o this patch sbi->s_bitmap_maxbytes was becoming a negative value due to overflow of upper_limit (with has_huge_files as true) Below is a quick test to trigger it on a 64KB pagesize system. sudo mkfs.ext4 -b 65536 -O ^has_extents,^64bit /dev/loop2 sudo mount /dev/loop2 /mnt sudo echo "hello" > /mnt/hello -> This will error out with "echo: write error: File too large" Signed-off-by: Ritesh Harjani Reviewed-by: Jan Kara Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Link: https://lore.kernel.org/r/594f409e2c543e90fd836b78188dfa5c575065ba.1622867594.git.riteshh@linux.ibm.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 7cea848678470daadbfdaa6a112b823c290f900c Author: Johan Hovold Date: Fri Sep 17 13:46:21 2021 +0200 ipack: ipoctal: fix module reference leak commit bb8a4fcb2136508224c596a7e665bdba1d7c3c27 upstream. A reference to the carrier module was taken on every open but was only released once when the final reference to the tty struct was dropped. Fix this by taking the module reference and initialising the tty driver data when installing the tty. Fixes: 82a82340bab6 ("ipoctal: get carrier driver to avoid rmmod") Cc: stable@vger.kernel.org # 3.18 Cc: Federico Vaga Acked-by: Samuel Iglesias Gonsalvez Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210917114622.5412-6-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 843efca98e6a24a917585247883d7cc34e9fe077 Author: Johan Hovold Date: Fri Sep 17 13:46:20 2021 +0200 ipack: ipoctal: fix missing allocation-failure check commit 445c8132727728dc297492a7d9fc074af3e94ba3 upstream. Add the missing error handling when allocating the transmit buffer to avoid dereferencing a NULL pointer in write() should the allocation ever fail. Fixes: ba4dc61fe8c5 ("Staging: ipack: add support for IP-OCTAL mezzanine board") Cc: stable@vger.kernel.org # 3.5 Acked-by: Samuel Iglesias Gonsalvez Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210917114622.5412-5-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 67d1df661088b70382cd2499945ad80333c16ba1 Author: Johan Hovold Date: Fri Sep 17 13:46:19 2021 +0200 ipack: ipoctal: fix tty-registration error handling commit cd20d59291d1790dc74248476e928f57fc455189 upstream. Registration of the ipoctal tty devices is unlikely to fail, but if it ever does, make sure not to deregister a never registered tty device (and dereference a NULL pointer) when the driver is later unbound. Fixes: 2afb41d9d30d ("Staging: ipack/devices/ipoctal: Check tty_register_device return value.") Cc: stable@vger.kernel.org # 3.7 Acked-by: Samuel Iglesias Gonsalvez Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210917114622.5412-4-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit f46e5db92fa2c28724724a39f1f51e8ca6a78de9 Author: Johan Hovold Date: Fri Sep 17 13:46:18 2021 +0200 ipack: ipoctal: fix tty registration race commit 65c001df517a7bf9be8621b53d43c89f426ce8d6 upstream. Make sure to set the tty class-device driver data before registering the tty to avoid having a racing open() dereference a NULL pointer. Fixes: 9c1d784afc6f ("Staging: ipack/devices/ipoctal: Get rid of ipoctal_list.") Cc: stable@vger.kernel.org # 3.7 Acked-by: Samuel Iglesias Gonsalvez Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210917114622.5412-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 5f6a309a699675680df15d9b6d389114515b4426 Author: Johan Hovold Date: Fri Sep 17 13:46:17 2021 +0200 ipack: ipoctal: fix stack information leak commit a89936cce87d60766a75732a9e7e25c51164f47c upstream. The tty driver name is used also after registering the driver and must specifically not be allocated on the stack to avoid leaking information to user space (or triggering an oops). Drivers should not try to encode topology information in the tty device name but this one snuck in through staging without anyone noticing and another driver has since copied this malpractice. Fixing the ABI is a separate issue, but this at least plugs the security hole. Fixes: ba4dc61fe8c5 ("Staging: ipack: add support for IP-OCTAL mezzanine board") Cc: stable@vger.kernel.org # 3.5 Acked-by: Samuel Iglesias Gonsalvez Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210917114622.5412-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 3bef1b7242e0a344177ba95ddafb3d2c67693ab2 Author: Nirmoy Das Date: Thu Sep 2 12:29:17 2021 +0200 debugfs: debugfs_create_file_size(): use IS_ERR to check for error commit af505cad9567f7a500d34bf183696d570d7f6810 upstream. debugfs_create_file() returns encoded error so use IS_ERR for checking return value. Reviewed-by: Christian König Signed-off-by: Nirmoy Das Fixes: ff9fb72bc077 ("debugfs: return error values, not NULL") Cc: stable References: https://gitlab.freedesktop.org/drm/amd/-/issues/1686 Link: https://lore.kernel.org/r/20210902102917.2233-1-nirmoy.das@amd.com Signed-off-by: Greg Kroah-Hartman commit 15fd3954bca729467675b976e85f54f1d03a2aad Author: Chen Jingwen Date: Tue Sep 28 20:56:57 2021 +0800 elf: don't use MAP_FIXED_NOREPLACE for elf interpreter mappings commit 9b2f72cc0aa4bb444541bb87581c35b7508b37d3 upstream. In commit b212921b13bd ("elf: don't use MAP_FIXED_NOREPLACE for elf executable mappings") we still leave MAP_FIXED_NOREPLACE in place for load_elf_interp. Unfortunately, this will cause kernel to fail to start with: 1 (init): Uhuuh, elf segment at 00003ffff7ffd000 requested but the memory is mapped already Failed to execute /init (error -17) The reason is that the elf interpreter (ld.so) has overlapping segments. readelf -l ld-2.31.so Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x000000000002c94c 0x000000000002c94c R E 0x10000 LOAD 0x000000000002dae0 0x000000000003dae0 0x000000000003dae0 0x00000000000021e8 0x0000000000002320 RW 0x10000 LOAD 0x000000000002fe00 0x000000000003fe00 0x000000000003fe00 0x00000000000011ac 0x0000000000001328 RW 0x10000 The reason for this problem is the same as described in commit ad55eac74f20 ("elf: enforce MAP_FIXED on overlaying elf segments"). Not only executable binaries, elf interpreters (e.g. ld.so) can have overlapping elf segments, so we better drop MAP_FIXED_NOREPLACE and go back to MAP_FIXED in load_elf_interp. Fixes: 4ed28639519c ("fs, elf: drop MAP_FIXED usage from elf_map") Cc: # v4.19 Cc: Andrew Morton Cc: Michal Hocko Signed-off-by: Chen Jingwen Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 011b4de950d80d9438e67b44622e2a587e097d56 Author: Keith Busch Date: Mon Sep 27 08:43:06 2021 -0700 nvme: add command id quirk for apple controllers commit a2941f6aa71a72be2c82c0a168523a492d093530 upstream. Some apple controllers use the command id as an index to implementation specific data structures and will fail if the value is out of bounds. The nvme driver's recently introduced command sequence number breaks this controller. Provide a quirk so these spec incompliant controllers can function as before. The driver will not have the ability to detect bad completions when this quirk is used, but we weren't previously checking this anyway. The quirk bit was selected so that it can readily apply to stable. Link: https://bugzilla.kernel.org/show_bug.cgi?id=214509 Cc: Sven Peter Reported-by: Orlando Chamberlain Reported-by: Aditya Garg Signed-off-by: Keith Busch Reviewed-by: Christoph Hellwig Tested-by: Sven Peter Link: https://lore.kernel.org/r/20210927154306.387437-1-kbusch@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 44c600a57d57547a0bb4865f2589cfb26728b524 Author: Vadim Pasternak Date: Mon Sep 27 10:07:40 2021 +0300 hwmon: (pmbus/mp2975) Add missed POUT attribute for page 1 mp2975 controller [ Upstream commit 2292e2f685cd5c65e3f47bbcf9f469513acc3195 ] Add missed attribute for reading POUT from page 1. It is supported by device, but has been missed in initial commit. Fixes: 2c6fcbb21149 ("hwmon: (pmbus) Add support for MPS Multi-phase mp2975 controller") Signed-off-by: Vadim Pasternak Link: https://lore.kernel.org/r/20210927070740.2149290-1-vadimp@nvidia.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 7fc5f60a01bbcce366d2180722f2bf71c9e3c3df Author: Kan Liang Date: Tue Sep 28 08:19:03 2021 -0700 perf/x86/intel: Update event constraints for ICX [ Upstream commit ecc2123e09f9e71ddc6c53d71e283b8ada685fe2 ] According to the latest event list, the event encoding 0xEF is only available on the first 4 counters. Add it into the event constraints table. Fixes: 6017608936c1 ("perf/x86/intel: Add Icelake support") Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/1632842343-25862-1-git-send-email-kan.liang@linux.intel.com Signed-off-by: Sasha Levin commit 3db53827a0e9130d9e2cbe3c3b5bca601caa4c74 Author: Eric Dumazet Date: Wed Sep 29 15:57:50 2021 -0700 af_unix: fix races in sk_peer_pid and sk_peer_cred accesses [ Upstream commit 35306eb23814444bd4021f8a1c3047d3cb0c8b2b ] Jann Horn reported that SO_PEERCRED and SO_PEERGROUPS implementations are racy, as af_unix can concurrently change sk_peer_pid and sk_peer_cred. In order to fix this issue, this patch adds a new spinlock that needs to be used whenever these fields are read or written. Jann also pointed out that l2cap_sock_get_peer_pid_cb() is currently reading sk->sk_peer_pid which makes no sense, as this field is only possibly set by AF_UNIX sockets. We will have to clean this in a separate patch. This could be done by reverting b48596d1dc25 "Bluetooth: L2CAP: Add get_peer_pid callback" or implementing what was truly expected. Fixes: 109f6e39fa07 ("af_unix: Allow SO_PEERCRED to work across namespaces.") Signed-off-by: Eric Dumazet Reported-by: Jann Horn Cc: Eric W. Biederman Cc: Luiz Augusto von Dentz Cc: Marcel Holtmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d0d520c19e7ea19ed38dc5797b12397b6ccf9f88 Author: Vlad Buslov Date: Wed Sep 29 18:08:49 2021 +0300 net: sched: flower: protect fl_walk() with rcu [ Upstream commit d5ef190693a7d76c5c192d108e8dec48307b46ee ] Patch that refactored fl_walk() to use idr_for_each_entry_continue_ul() also removed rcu protection of individual filters which causes following use-after-free when filter is deleted concurrently. Fix fl_walk() to obtain rcu read lock while iterating and taking the filter reference and temporary release the lock while calling arg->fn() callback that can sleep. KASAN trace: [ 352.773640] ================================================================== [ 352.775041] BUG: KASAN: use-after-free in fl_walk+0x159/0x240 [cls_flower] [ 352.776304] Read of size 4 at addr ffff8881c8251480 by task tc/2987 [ 352.777862] CPU: 3 PID: 2987 Comm: tc Not tainted 5.15.0-rc2+ #2 [ 352.778980] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 352.781022] Call Trace: [ 352.781573] dump_stack_lvl+0x46/0x5a [ 352.782332] print_address_description.constprop.0+0x1f/0x140 [ 352.783400] ? fl_walk+0x159/0x240 [cls_flower] [ 352.784292] ? fl_walk+0x159/0x240 [cls_flower] [ 352.785138] kasan_report.cold+0x83/0xdf [ 352.785851] ? fl_walk+0x159/0x240 [cls_flower] [ 352.786587] kasan_check_range+0x145/0x1a0 [ 352.787337] fl_walk+0x159/0x240 [cls_flower] [ 352.788163] ? fl_put+0x10/0x10 [cls_flower] [ 352.789007] ? __mutex_unlock_slowpath.constprop.0+0x220/0x220 [ 352.790102] tcf_chain_dump+0x231/0x450 [ 352.790878] ? tcf_chain_tp_delete_empty+0x170/0x170 [ 352.791833] ? __might_sleep+0x2e/0xc0 [ 352.792594] ? tfilter_notify+0x170/0x170 [ 352.793400] ? __mutex_unlock_slowpath.constprop.0+0x220/0x220 [ 352.794477] tc_dump_tfilter+0x385/0x4b0 [ 352.795262] ? tc_new_tfilter+0x1180/0x1180 [ 352.796103] ? __mod_node_page_state+0x1f/0xc0 [ 352.796974] ? __build_skb_around+0x10e/0x130 [ 352.797826] netlink_dump+0x2c0/0x560 [ 352.798563] ? netlink_getsockopt+0x430/0x430 [ 352.799433] ? __mutex_unlock_slowpath.constprop.0+0x220/0x220 [ 352.800542] __netlink_dump_start+0x356/0x440 [ 352.801397] rtnetlink_rcv_msg+0x3ff/0x550 [ 352.802190] ? tc_new_tfilter+0x1180/0x1180 [ 352.802872] ? rtnl_calcit.isra.0+0x1f0/0x1f0 [ 352.803668] ? tc_new_tfilter+0x1180/0x1180 [ 352.804344] ? _copy_from_iter_nocache+0x800/0x800 [ 352.805202] ? kasan_set_track+0x1c/0x30 [ 352.805900] netlink_rcv_skb+0xc6/0x1f0 [ 352.806587] ? rht_deferred_worker+0x6b0/0x6b0 [ 352.807455] ? rtnl_calcit.isra.0+0x1f0/0x1f0 [ 352.808324] ? netlink_ack+0x4d0/0x4d0 [ 352.809086] ? netlink_deliver_tap+0x62/0x3d0 [ 352.809951] netlink_unicast+0x353/0x480 [ 352.810744] ? netlink_attachskb+0x430/0x430 [ 352.811586] ? __alloc_skb+0xd7/0x200 [ 352.812349] netlink_sendmsg+0x396/0x680 [ 352.813132] ? netlink_unicast+0x480/0x480 [ 352.813952] ? __import_iovec+0x192/0x210 [ 352.814759] ? netlink_unicast+0x480/0x480 [ 352.815580] sock_sendmsg+0x6c/0x80 [ 352.816299] ____sys_sendmsg+0x3a5/0x3c0 [ 352.817096] ? kernel_sendmsg+0x30/0x30 [ 352.817873] ? __ia32_sys_recvmmsg+0x150/0x150 [ 352.818753] ___sys_sendmsg+0xd8/0x140 [ 352.819518] ? sendmsg_copy_msghdr+0x110/0x110 [ 352.820402] ? ___sys_recvmsg+0xf4/0x1a0 [ 352.821110] ? __copy_msghdr_from_user+0x260/0x260 [ 352.821934] ? _raw_spin_lock+0x81/0xd0 [ 352.822680] ? __handle_mm_fault+0xef3/0x1b20 [ 352.823549] ? rb_insert_color+0x2a/0x270 [ 352.824373] ? copy_page_range+0x16b0/0x16b0 [ 352.825209] ? perf_event_update_userpage+0x2d0/0x2d0 [ 352.826190] ? __fget_light+0xd9/0xf0 [ 352.826941] __sys_sendmsg+0xb3/0x130 [ 352.827613] ? __sys_sendmsg_sock+0x20/0x20 [ 352.828377] ? do_user_addr_fault+0x2c5/0x8a0 [ 352.829184] ? fpregs_assert_state_consistent+0x52/0x60 [ 352.830001] ? exit_to_user_mode_prepare+0x32/0x160 [ 352.830845] do_syscall_64+0x35/0x80 [ 352.831445] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 352.832331] RIP: 0033:0x7f7bee973c17 [ 352.833078] Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10 [ 352.836202] RSP: 002b:00007ffcbb368e28 EFLAGS: 00000246 ORIG_RAX: 000000000000002e [ 352.837524] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f7bee973c17 [ 352.838715] RDX: 0000000000000000 RSI: 00007ffcbb368e50 RDI: 0000000000000003 [ 352.839838] RBP: 00007ffcbb36d090 R08: 00000000cea96d79 R09: 00007f7beea34a40 [ 352.841021] R10: 00000000004059bb R11: 0000000000000246 R12: 000000000046563f [ 352.842208] R13: 0000000000000000 R14: 0000000000000000 R15: 00007ffcbb36d088 [ 352.843784] Allocated by task 2960: [ 352.844451] kasan_save_stack+0x1b/0x40 [ 352.845173] __kasan_kmalloc+0x7c/0x90 [ 352.845873] fl_change+0x282/0x22db [cls_flower] [ 352.846696] tc_new_tfilter+0x6cf/0x1180 [ 352.847493] rtnetlink_rcv_msg+0x471/0x550 [ 352.848323] netlink_rcv_skb+0xc6/0x1f0 [ 352.849097] netlink_unicast+0x353/0x480 [ 352.849886] netlink_sendmsg+0x396/0x680 [ 352.850678] sock_sendmsg+0x6c/0x80 [ 352.851398] ____sys_sendmsg+0x3a5/0x3c0 [ 352.852202] ___sys_sendmsg+0xd8/0x140 [ 352.852967] __sys_sendmsg+0xb3/0x130 [ 352.853718] do_syscall_64+0x35/0x80 [ 352.854457] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 352.855830] Freed by task 7: [ 352.856421] kasan_save_stack+0x1b/0x40 [ 352.857139] kasan_set_track+0x1c/0x30 [ 352.857854] kasan_set_free_info+0x20/0x30 [ 352.858609] __kasan_slab_free+0xed/0x130 [ 352.859348] kfree+0xa7/0x3c0 [ 352.859951] process_one_work+0x44d/0x780 [ 352.860685] worker_thread+0x2e2/0x7e0 [ 352.861390] kthread+0x1f4/0x220 [ 352.862022] ret_from_fork+0x1f/0x30 [ 352.862955] Last potentially related work creation: [ 352.863758] kasan_save_stack+0x1b/0x40 [ 352.864378] kasan_record_aux_stack+0xab/0xc0 [ 352.865028] insert_work+0x30/0x160 [ 352.865617] __queue_work+0x351/0x670 [ 352.866261] rcu_work_rcufn+0x30/0x40 [ 352.866917] rcu_core+0x3b2/0xdb0 [ 352.867561] __do_softirq+0xf6/0x386 [ 352.868708] Second to last potentially related work creation: [ 352.869779] kasan_save_stack+0x1b/0x40 [ 352.870560] kasan_record_aux_stack+0xab/0xc0 [ 352.871426] call_rcu+0x5f/0x5c0 [ 352.872108] queue_rcu_work+0x44/0x50 [ 352.872855] __fl_put+0x17c/0x240 [cls_flower] [ 352.873733] fl_delete+0xc7/0x100 [cls_flower] [ 352.874607] tc_del_tfilter+0x510/0xb30 [ 352.886085] rtnetlink_rcv_msg+0x471/0x550 [ 352.886875] netlink_rcv_skb+0xc6/0x1f0 [ 352.887636] netlink_unicast+0x353/0x480 [ 352.888285] netlink_sendmsg+0x396/0x680 [ 352.888942] sock_sendmsg+0x6c/0x80 [ 352.889583] ____sys_sendmsg+0x3a5/0x3c0 [ 352.890311] ___sys_sendmsg+0xd8/0x140 [ 352.891019] __sys_sendmsg+0xb3/0x130 [ 352.891716] do_syscall_64+0x35/0x80 [ 352.892395] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 352.893666] The buggy address belongs to the object at ffff8881c8251000 which belongs to the cache kmalloc-2k of size 2048 [ 352.895696] The buggy address is located 1152 bytes inside of 2048-byte region [ffff8881c8251000, ffff8881c8251800) [ 352.897640] The buggy address belongs to the page: [ 352.898492] page:00000000213bac35 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1c8250 [ 352.900110] head:00000000213bac35 order:3 compound_mapcount:0 compound_pincount:0 [ 352.901541] flags: 0x2ffff800010200(slab|head|node=0|zone=2|lastcpupid=0x1ffff) [ 352.902908] raw: 002ffff800010200 0000000000000000 dead000000000122 ffff888100042f00 [ 352.904391] raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000 [ 352.905861] page dumped because: kasan: bad access detected [ 352.907323] Memory state around the buggy address: [ 352.908218] ffff8881c8251380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 352.909471] ffff8881c8251400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 352.910735] >ffff8881c8251480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 352.912012] ^ [ 352.912642] ffff8881c8251500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 352.913919] ffff8881c8251580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 352.915185] ================================================================== Fixes: d39d714969cd ("idr: introduce idr_for_each_entry_continue_ul()") Signed-off-by: Vlad Buslov Acked-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e63f6d8fe74a5e65a77189cc13930630e8e88971 Author: Florian Fainelli Date: Tue Sep 28 13:32:33 2021 -0700 net: phy: bcm7xxx: Fixed indirect MMD operations [ Upstream commit d88fd1b546ff19c8040cfaea76bf16aed1c5a0bb ] When EEE support was added to the 28nm EPHY it was assumed that it would be able to support the standard clause 45 over clause 22 register access method. It turns out that the PHY does not support that, which is the very reason for using the indirect shadow mode 2 bank 3 access method. Implement {read,write}_mmd to allow the standard PHY library routines pertaining to EEE querying and configuration to work correctly on these PHYs. This forces us to implement a __phy_set_clr_bits() function that does not grab the MDIO bus lock since the PHY driver's {read,write}_mmd functions are always called with that lock held. Fixes: 83ee102a6998 ("net: phy: bcm7xxx: add support for 28nm EPHY") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 071febc37e066c9bd6f417179b4f763d0b13437b Author: Guangbin Huang Date: Wed Sep 29 17:35:55 2021 +0800 net: hns3: fix always enable rx vlan filter problem after selftest [ Upstream commit 27bf4af69fcb9845fb2f0076db5d562ec072e70f ] Currently, the rx vlan filter will always be disabled before selftest and be enabled after selftest as the rx vlan filter feature is fixed on in old device earlier than V3. However, this feature is not fixed in some new devices and it can be disabled by user. In this case, it is wrong if rx vlan filter is enabled after selftest. So fix it. Fixes: bcc26e8dc432 ("net: hns3: remove unused code in hns3_self_test()") Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 85e4f5d28d25c40965004c225133457f3bcb0ac9 Author: Peng Li Date: Mon Aug 30 14:06:37 2021 +0800 net: hns3: reconstruct function hns3_self_test [ Upstream commit 4c8dab1c709c5a715bce14efdb8f4e889d86aa04 ] This patch reconstructs function hns3_self_test to reduce the code cycle complexity and make code more concise. Signed-off-by: Peng Li Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8e89876c84b23d79a7ea58c3f5c300695a227570 Author: Huazhong Tan Date: Fri Mar 26 09:36:25 2021 +0800 net: hns3: fix prototype warning [ Upstream commit a1e144d7dc3c55aa4d451e3a23cd8f34cd65ee01 ] Correct a report warning in hns3_ethtool.c Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d4a14faf7919b331d95d87d7d84e36774f9408c4 Author: Jian Shen Date: Wed Sep 29 17:35:53 2021 +0800 net: hns3: fix show wrong state when add existing uc mac address [ Upstream commit 108b3c7810e14892c4a1819b1d268a2c785c087c ] Currently, if function adds an existing unicast mac address, eventhough driver will not add this address into hardware, but it will return 0 in function hclge_add_uc_addr_common(). It will cause the state of this unicast mac address is ACTIVE in driver, but it should be in TO-ADD state. To fix this problem, function hclge_add_uc_addr_common() returns -EEXIST if mac address is existing, and delete two error log to avoid printing them all the time after this modification. Fixes: 72110b567479 ("net: hns3: return 0 and print warning when hit duplicate MAC") Signed-off-by: Jian Shen Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 64dae9551f8af31033836a043f2273fee2a74c55 Author: Jian Shen Date: Wed Sep 29 17:35:52 2021 +0800 net: hns3: fix mixed flag HCLGE_FLAG_MQPRIO_ENABLE and HCLGE_FLAG_DCB_ENABLE [ Upstream commit 0472e95ffeac8e61259eec17ab61608c6b35599d ] HCLGE_FLAG_MQPRIO_ENABLE is supposed to set when enable multiple TCs with tc mqprio, and HCLGE_FLAG_DCB_ENABLE is supposed to set when enable multiple TCs with ets. But the driver mixed the flags when updating the tm configuration. Furtherly, PFC should be available when HCLGE_FLAG_MQPRIO_ENABLE too, so remove the unnecessary limitation. Fixes: 5a5c90917467 ("net: hns3: add support for tc mqprio offload") Signed-off-by: Jian Shen Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8d3d27664ef42775c14118c0127d015c687c744f Author: Yonglong Liu Date: Sat Nov 28 11:51:50 2020 +0800 net: hns3: keep MAC pause mode when multiple TCs are enabled [ Upstream commit d78e5b6a6764cb6e83668806b63d74566db36399 ] Bellow HNAE3_DEVICE_VERSION_V3, MAC pause mode just support one TC, when enabled multiple TCs, force enable PFC mode. HNAE3_DEVICE_VERSION_V3 can support MAC pause mode on multiple TCs, so when enable multiple TCs, just keep MAC pause mode, and enable PFC mode just according to the user settings. Signed-off-by: Yonglong Liu Signed-off-by: Huazhong Tan Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f8ba689cb69523144d10606096ef686002dd7285 Author: Jian Shen Date: Wed Sep 29 17:35:49 2021 +0800 net: hns3: do not allow call hns3_nic_net_open repeatedly [ Upstream commit 5b09e88e1bf7fe86540fab4b5f3eece8abead39e ] hns3_nic_net_open() is not allowed to called repeatly, but there is no checking for this. When doing device reset and setup tc concurrently, there is a small oppotunity to call hns3_nic_net_open repeatedly, and cause kernel bug by calling napi_enable twice. The calltrace information is like below: [ 3078.222780] ------------[ cut here ]------------ [ 3078.230255] kernel BUG at net/core/dev.c:6991! [ 3078.236224] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 3078.243431] Modules linked in: hns3 hclgevf hclge hnae3 vfio_iommu_type1 vfio_pci vfio_virqfd vfio pv680_mii(O) [ 3078.258880] CPU: 0 PID: 295 Comm: kworker/u8:5 Tainted: G O 5.14.0-rc4+ #1 [ 3078.269102] Hardware name: , BIOS KpxxxFPGA 1P B600 V181 08/12/2021 [ 3078.276801] Workqueue: hclge hclge_service_task [hclge] [ 3078.288774] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--) [ 3078.296168] pc : napi_enable+0x80/0x84 tc qdisc sho[w 3d0e7v8 .e3t0h218 79] lr : hns3_nic_net_open+0x138/0x510 [hns3] [ 3078.314771] sp : ffff8000108abb20 [ 3078.319099] x29: ffff8000108abb20 x28: 0000000000000000 x27: ffff0820a8490300 [ 3078.329121] x26: 0000000000000001 x25: ffff08209cfc6200 x24: 0000000000000000 [ 3078.339044] x23: ffff0820a8490300 x22: ffff08209cd76000 x21: ffff0820abfe3880 [ 3078.349018] x20: 0000000000000000 x19: ffff08209cd76900 x18: 0000000000000000 [ 3078.358620] x17: 0000000000000000 x16: ffffc816e1727a50 x15: 0000ffff8f4ff930 [ 3078.368895] x14: 0000000000000000 x13: 0000000000000000 x12: 0000259e9dbeb6b4 [ 3078.377987] x11: 0096a8f7e764eb40 x10: 634615ad28d3eab5 x9 : ffffc816ad8885b8 [ 3078.387091] x8 : ffff08209cfc6fb8 x7 : ffff0820ac0da058 x6 : ffff0820a8490344 [ 3078.396356] x5 : 0000000000000140 x4 : 0000000000000003 x3 : ffff08209cd76938 [ 3078.405365] x2 : 0000000000000000 x1 : 0000000000000010 x0 : ffff0820abfe38a0 [ 3078.414657] Call trace: [ 3078.418517] napi_enable+0x80/0x84 [ 3078.424626] hns3_reset_notify_up_enet+0x78/0xd0 [hns3] [ 3078.433469] hns3_reset_notify+0x64/0x80 [hns3] [ 3078.441430] hclge_notify_client+0x68/0xb0 [hclge] [ 3078.450511] hclge_reset_rebuild+0x524/0x884 [hclge] [ 3078.458879] hclge_reset_service_task+0x3c4/0x680 [hclge] [ 3078.467470] hclge_service_task+0xb0/0xb54 [hclge] [ 3078.475675] process_one_work+0x1dc/0x48c [ 3078.481888] worker_thread+0x15c/0x464 [ 3078.487104] kthread+0x160/0x170 [ 3078.492479] ret_from_fork+0x10/0x18 [ 3078.498785] Code: c8027c81 35ffffa2 d50323bf d65f03c0 (d4210000) [ 3078.506889] ---[ end trace 8ebe0340a1b0fb44 ]--- Once hns3_nic_net_open() is excute success, the flag HNS3_NIC_STATE_DOWN will be cleared. So add checking for this flag, directly return when HNS3_NIC_STATE_DOWN is no set. Fixes: e888402789b9 ("net: hns3: call hns3_nic_net_open() while doing HNAE3_UP_CLIENT") Signed-off-by: Jian Shen Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 20f6c4a31a525edd9ea6243712b868ba0e4e331e Author: Feng Zhou Date: Tue Sep 28 15:23:59 2021 -0700 ixgbe: Fix NULL pointer dereference in ixgbe_xdp_setup [ Upstream commit 513e605d7a9ce136886cb42ebb2c40e9a6eb6333 ] The ixgbe driver currently generates a NULL pointer dereference with some machine (online cpus < 63). This is due to the fact that the maximum value of num_xdp_queues is nr_cpu_ids. Code is in "ixgbe_set_rss_queues"". Here's how the problem repeats itself: Some machine (online cpus < 63), And user set num_queues to 63 through ethtool. Code is in the "ixgbe_set_channels", adapter->ring_feature[RING_F_FDIR].limit = count; It becomes 63. When user use xdp, "ixgbe_set_rss_queues" will set queues num. adapter->num_rx_queues = rss_i; adapter->num_tx_queues = rss_i; adapter->num_xdp_queues = ixgbe_xdp_queues(adapter); And rss_i's value is from f = &adapter->ring_feature[RING_F_FDIR]; rss_i = f->indices = f->limit; So "num_rx_queues" > "num_xdp_queues", when run to "ixgbe_xdp_setup", for (i = 0; i < adapter->num_rx_queues; i++) if (adapter->xdp_ring[i]->xsk_umem) It leads to panic. Call trace: [exception RIP: ixgbe_xdp+368] RIP: ffffffffc02a76a0 RSP: ffff9fe16202f8d0 RFLAGS: 00010297 RAX: 0000000000000000 RBX: 0000000000000020 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 000000000000001c RDI: ffffffffa94ead90 RBP: ffff92f8f24c0c18 R8: 0000000000000000 R9: 0000000000000000 R10: ffff9fe16202f830 R11: 0000000000000000 R12: ffff92f8f24c0000 R13: ffff9fe16202fc01 R14: 000000000000000a R15: ffffffffc02a7530 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 7 [ffff9fe16202f8f0] dev_xdp_install at ffffffffa89fbbcc 8 [ffff9fe16202f920] dev_change_xdp_fd at ffffffffa8a08808 9 [ffff9fe16202f960] do_setlink at ffffffffa8a20235 10 [ffff9fe16202fa88] rtnl_setlink at ffffffffa8a20384 11 [ffff9fe16202fc78] rtnetlink_rcv_msg at ffffffffa8a1a8dd 12 [ffff9fe16202fcf0] netlink_rcv_skb at ffffffffa8a717eb 13 [ffff9fe16202fd40] netlink_unicast at ffffffffa8a70f88 14 [ffff9fe16202fd80] netlink_sendmsg at ffffffffa8a71319 15 [ffff9fe16202fdf0] sock_sendmsg at ffffffffa89df290 16 [ffff9fe16202fe08] __sys_sendto at ffffffffa89e19c8 17 [ffff9fe16202ff30] __x64_sys_sendto at ffffffffa89e1a64 18 [ffff9fe16202ff38] do_syscall_64 at ffffffffa84042b9 19 [ffff9fe16202ff50] entry_SYSCALL_64_after_hwframe at ffffffffa8c0008c So I fix ixgbe_max_channels so that it will not allow a setting of queues to be higher than the num_online_cpus(). And when run to ixgbe_xdp_setup, take the smaller value of num_rx_queues and num_xdp_queues. Fixes: 4a9b32f30f80 ("ixgbe: fix potential RX buffer starvation for AF_XDP") Signed-off-by: Feng Zhou Tested-by: Sandeep Penigalapati Signed-off-by: Tony Nguyen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 16138cf938dc1194ba1dddcd7028080f35322ddc Author: Rahul Lakkireddy Date: Mon Sep 27 21:44:08 2021 +0530 scsi: csiostor: Add module softdep on cxgb4 [ Upstream commit 79a7482249a7353bc86aff8127954d5febf02472 ] Both cxgb4 and csiostor drivers run on their own independent Physical Function. But when cxgb4 and csiostor are both being loaded in parallel via modprobe, there is a race when firmware upgrade is attempted by both the drivers. When the cxgb4 driver initiates the firmware upgrade, it halts the firmware and the chip until upgrade is complete. When the csiostor driver is coming up in parallel, the firmware mailbox communication fails with timeouts and the csiostor driver probe fails. Add a module soft dependency on cxgb4 driver to ensure loading csiostor triggers cxgb4 to load first when available to avoid the firmware upgrade race. Link: https://lore.kernel.org/r/1632759248-15382-1-git-send-email-rahul.lakkireddy@chelsio.com Fixes: a3667aaed569 ("[SCSI] csiostor: Chelsio FCoE offload driver") Signed-off-by: Rahul Lakkireddy Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 0306a2c7df7ebe7c740ecb6c845668401ed3cc8e Author: Jens Axboe Date: Tue Sep 28 06:33:15 2021 -0600 Revert "block, bfq: honor already-setup queue merges" [ Upstream commit ebc69e897e17373fbe1daaff1debaa77583a5284 ] This reverts commit 2d52c58b9c9bdae0ca3df6a1eab5745ab3f7d80b. We have had several folks complain that this causes hangs for them, which is especially problematic as the commit has also hit stable already. As no resolution seems to be forthcoming right now, revert the patch. Link: https://bugzilla.kernel.org/show_bug.cgi?id=214503 Fixes: 2d52c58b9c9b ("block, bfq: honor already-setup queue merges") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 1f2ca30fbde6387c2c68e7b8fc3bdda3158d2789 Author: Arnd Bergmann Date: Mon Sep 27 16:13:02 2021 +0200 net: ks8851: fix link error [ Upstream commit 51bb08dd04a05035a64504faa47651d36b0f3125 ] An object file cannot be built for both loadable module and built-in use at the same time: arm-linux-gnueabi-ld: drivers/net/ethernet/micrel/ks8851_common.o: in function `ks8851_probe_common': ks8851_common.c:(.text+0xf80): undefined reference to `__this_module' Change the ks8851_common code to be a standalone module instead, and use Makefile logic to ensure this is built-in if at least one of its two users is. Fixes: 797047f875b5 ("net: ks8851: Implement Parallel bus operations") Link: https://lore.kernel.org/netdev/20210125121937.3900988-1-arnd@kernel.org/ Reviewed-by: Andrew Lunn Acked-by: Marek Vasut Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f1dd6e10f077cef7f8a073fae759db8e41705ac8 Author: Jiri Benc Date: Thu Sep 23 10:40:22 2021 +0200 selftests, bpf: test_lwt_ip_encap: Really disable rp_filter [ Upstream commit 79e2c306667542b8ee2d9a9d947eadc7039f0a3c ] It's not enough to set net.ipv4.conf.all.rp_filter=0, that does not override a greater rp_filter value on the individual interfaces. We also need to set net.ipv4.conf.default.rp_filter=0 before creating the interfaces. That way, they'll also get their own rp_filter value of zero. Fixes: 0fde56e4385b0 ("selftests: bpf: add test_lwt_ip_encap selftest") Signed-off-by: Jiri Benc Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/b1cdd9d469f09ea6e01e9c89a6071c79b7380f89.1632386362.git.jbenc@redhat.com Signed-off-by: Sasha Levin commit 4967ae9ab44b8a92b51859dfdf6b81794a61b9a6 Author: Jiri Benc Date: Mon Sep 27 18:01:36 2021 +0200 selftests, bpf: Fix makefile dependencies on libbpf [ Upstream commit d888eaac4fb1df30320bb1305a8f78efe86524c6 ] When building bpf selftest with make -j, I'm randomly getting build failures such as this one: In file included from progs/bpf_flow.c:19: [...]/tools/testing/selftests/bpf/tools/include/bpf/bpf_helpers.h:11:10: fatal error: 'bpf_helper_defs.h' file not found #include "bpf_helper_defs.h" ^~~~~~~~~~~~~~~~~~~ The file that fails the build varies between runs but it's always in the progs/ subdir. The reason is a missing make dependency on libbpf for the .o files in progs/. There was a dependency before commit 3ac2e20fba07e but that commit removed it to prevent unneeded rebuilds. However, that only works if libbpf has been built already; the 'wildcard' prerequisite does not trigger when there's no bpf_helper_defs.h generated yet. Keep the libbpf as an order-only prerequisite to satisfy both goals. It is always built before the progs/ objects but it does not trigger unnecessary rebuilds by itself. Fixes: 3ac2e20fba07e ("selftests/bpf: BPF object files should depend only on libbpf headers") Signed-off-by: Jiri Benc Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/ee84ab66436fba05a197f952af23c98d90eb6243.1632758415.git.jbenc@redhat.com Signed-off-by: Sasha Levin commit 59efda5073abb4fff2ce8c90ca9c2d25882e84a4 Author: Lorenz Bauer Date: Wed Sep 22 12:11:52 2021 +0100 bpf: Exempt CAP_BPF from checks against bpf_jit_limit [ Upstream commit 8a98ae12fbefdb583a7696de719a1d57e5e940a2 ] When introducing CAP_BPF, bpf_jit_charge_modmem() was not changed to treat programs with CAP_BPF as privileged for the purpose of JIT memory allocation. This means that a program without CAP_BPF can block a program with CAP_BPF from loading a program. Fix this by checking bpf_capable() in bpf_jit_charge_modmem(). Fixes: 2c78ee898d8f ("bpf: Implement CAP_BPF") Signed-off-by: Lorenz Bauer Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20210922111153.19843-1-lmb@cloudflare.com Signed-off-by: Sasha Levin commit f908072391a653776d7ce9e23d63d3789a6c4b7d Author: Yixing Liu Date: Fri Dec 11 09:37:36 2020 +0800 RDMA/hns: Fix inaccurate prints [ Upstream commit 61918e9b008492f48577692428aca3cebf56111a ] Some %d in print format string should be %u, and some prints miss the useful errno or are in nonstandard format. Just fix above issues. Link: https://lore.kernel.org/r/1607650657-35992-11-git-send-email-liweihang@huawei.com Signed-off-by: Yixing Liu Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 7e3eda32b88140252f11c81b100bda4a43f4a727 Author: Jacob Keller Date: Wed Sep 8 10:52:37 2021 -0700 e100: fix buffer overrun in e100_get_regs [ Upstream commit 51032e6f17ce990d06123ad7307f258c50d25aa7 ] The e100_get_regs function is used to implement a simple register dump for the e100 device. The data is broken into a couple of MAC control registers, and then a series of PHY registers, followed by a memory dump buffer. The total length of the register dump is defined as (1 + E100_PHY_REGS) * sizeof(u32) + sizeof(nic->mem->dump_buf). The logic for filling in the PHY registers uses a convoluted inverted count for loop which counts from E100_PHY_REGS (0x1C) down to 0, and assigns the slots 1 + E100_PHY_REGS - i. The first loop iteration will fill in [1] and the final loop iteration will fill in [1 + 0x1C]. This is actually one more than the supposed number of PHY registers. The memory dump buffer is then filled into the space at [2 + E100_PHY_REGS] which will cause that memcpy to assign 4 bytes past the total size. The end result is that we overrun the total buffer size allocated by the kernel, which could lead to a panic or other issues due to memory corruption. It is difficult to determine the actual total number of registers here. The only 8255x datasheet I could find indicates there are 28 total MDI registers. However, we're reading 29 here, and reading them in reverse! In addition, the ethtool e100 register dump interface appears to read the first PHY register to determine if the device is in MDI or MDIx mode. This doesn't appear to be documented anywhere within the 8255x datasheet. I can only assume it must be in register 28 (the extra register we're reading here). Lets not change any of the intended meaning of what we copy here. Just extend the space by 4 bytes to account for the extra register and continue copying the data out in the same order. Change the E100_PHY_REGS value to be the correct total (29) so that the total register dump size is calculated properly. Fix the offset for where we copy the dump buffer so that it doesn't overrun the total size. Re-write the for loop to use counting up instead of the convoluted down-counting. Correct the mdio_read offset to use the 0-based register offsets, but maintain the bizarre reverse ordering so that we have the ABI expected by applications like ethtool. This requires and additional subtraction of 1. It seems a bit odd but it makes the flow of assignment into the register buffer easier to follow. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Felicitas Hetzelt Signed-off-by: Jacob Keller Tested-by: Jacob Keller Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit f2edf80cdd0316e9e3452437e9797e948b8271bf Author: Jacob Keller Date: Wed Sep 8 10:52:36 2021 -0700 e100: fix length calculation in e100_get_regs_len [ Upstream commit 4329c8dc110b25d5f04ed20c6821bb60deff279f ] commit abf9b902059f ("e100: cleanup unneeded math") tried to simplify e100_get_regs_len and remove a double 'divide and then multiply' calculation that the e100_reg_regs_len function did. This change broke the size calculation entirely as it failed to account for the fact that the numbered registers are actually 4 bytes wide and not 1 byte. This resulted in a significant under allocation of the register buffer used by e100_get_regs. Fix this by properly multiplying the register count by u32 first before adding the size of the dump buffer. Fixes: abf9b902059f ("e100: cleanup unneeded math") Reported-by: Felicitas Hetzelt Signed-off-by: Jacob Keller Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit c20a0ad7b6a054d77c3f20660befe77eaae3f24d Author: Andrew Lunn Date: Sun Sep 26 19:41:26 2021 +0200 dsa: mv88e6xxx: Include tagger overhead when setting MTU for DSA and CPU ports [ Upstream commit b9c587fed61cf88bd45822c3159644445f6d5aa6 ] Same members of the Marvell Ethernet switches impose MTU restrictions on ports used for connecting to the CPU or another switch for DSA. If the MTU is set too low, tagged frames will be discarded. Ensure the worst case tagger overhead is included in setting the MTU for DSA and CPU ports. Fixes: 1baf0fac10fb ("net: dsa: mv88e6xxx: Use chip-wide max frame size for MTU") Reported by: 曹煜 Signed-off-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7b771b12229e82dac66cf0090d0774475a3c662c Author: Andrew Lunn Date: Sun Sep 26 19:41:25 2021 +0200 dsa: mv88e6xxx: Fix MTU definition [ Upstream commit b92ce2f54c0f0ff781e914ec189c25f7bf1b1ec2 ] The MTU passed to the DSA driver is the payload size, typically 1500. However, the switch uses the frame size when applying restrictions. Adjust the MTU with the size of the Ethernet header and the frame checksum. The VLAN header also needs to be included when the frame size it per port, but not when it is global. Fixes: 1baf0fac10fb ("net: dsa: mv88e6xxx: Use chip-wide max frame size for MTU") Reported by: 曹煜 Signed-off-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ee4d0495a65e366538063907c8b4459245620e0c Author: Andrew Lunn Date: Sun Sep 26 19:41:24 2021 +0200 dsa: mv88e6xxx: 6161: Use chip wide MAX MTU [ Upstream commit fe23036192c95b66e60d019d2ec1814d0d561ffd ] The datasheets suggests the 6161 uses a per port setting for jumbo frames. Testing has however shown this is not correct, it uses the old style chip wide MTU control. Change the ops in the 6161 structure to reflect this. Fixes: 1baf0fac10fb ("net: dsa: mv88e6xxx: Use chip-wide max frame size for MTU") Reported by: 曹煜 Signed-off-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d35d95e8b9da638d27bce9552262e0c486138343 Author: Matthew Auld Date: Tue Sep 21 14:42:02 2021 +0100 drm/i915/request: fix early tracepoints [ Upstream commit c83ff0186401169eb27ce5057d820b7a863455c3 ] Currently we blow up in trace_dma_fence_init, when calling into get_driver_name or get_timeline_name, since both the engine and context might be NULL(or contain some garbage address) in the case of newly allocated slab objects via the request ctor. Note that we also use SLAB_TYPESAFE_BY_RCU here, which allows requests to be immediately freed, but delay freeing the underlying page by an RCU grace period. With this scheme requests can be re-allocated, at the same time as they are also being read by some lockless RCU lookup mechanism. In the ctor case, which is only called for new slab objects(i.e allocate new page and call the ctor for each object) it's safe to reset the context/engine prior to calling into dma_fence_init, since we can be certain that no one is doing an RCU lookup which might depend on peeking at the engine/context, like in active_engine(), since the object can't yet be externally visible. In the recycled case(which might also be externally visible) the request refcount always transitions from 0->1 after we set the context/engine etc, which should ensure it's valid to dereference the engine for example, when doing an RCU list-walk, so long as we can also increment the refcount first. If the refcount is already zero, then the request is considered complete/released. If it's non-zero, then the request might be in the process of being re-allocated, or potentially still in flight, however after successfully incrementing the refcount, it's possible to carefully inspect the request state, to determine if the request is still what we were looking for. Note that all externally visible requests returned to the cache must have zero refcount. One possible fix then is to move dma_fence_init out from the request ctor. Originally this was how it was done, but it was moved in: commit 855e39e65cfc33a73724f1cc644ffc5754864a20 Author: Chris Wilson Date: Mon Feb 3 09:41:48 2020 +0000 drm/i915: Initialise basic fence before acquiring seqno where it looks like intel_timeline_get_seqno() relied on some of the rq->fence state, but that is no longer the case since: commit 12ca695d2c1ed26b2dcbb528b42813bd0f216cfc Author: Maarten Lankhorst Date: Tue Mar 23 16:49:50 2021 +0100 drm/i915: Do not share hwsp across contexts any more, v8. intel_timeline_get_seqno() could also be cleaned up slightly by dropping the request argument. Moving dma_fence_init back out of the ctor, should ensure we have enough of the request initialised in case of trace_dma_fence_init. Functionally this should be the same, and is effectively what we were already open coding before, except now we also assign the fence->lock and fence->ops, but since these are invariant for recycled requests(which might be externally visible), and will therefore already hold the same value, it shouldn't matter. An alternative fix, since we don't yet have a fully initialised request when in the ctor, is just setting the context/engine as NULL, but this does require adding some extra handling in get_driver_name etc. v2(Daniel): - Try to make the commit message less confusing Fixes: 855e39e65cfc ("drm/i915: Initialise basic fence before acquiring seqno") Signed-off-by: Matthew Auld Cc: Michael Mason Cc: Daniel Vetter Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210921134202.3803151-1-matthew.auld@intel.com (cherry picked from commit be988eaee1cb208c4445db46bc3ceaf75f586f0b) Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 8321738c6e5ab8c85983c3ac5d7d36e0ccc451ae Author: Aaro Koskinen Date: Fri Sep 24 01:00:16 2021 +0300 smsc95xx: fix stalled rx after link change [ Upstream commit 5ab8a447bcfee1ded709e7ff5dc7608ca9f66ae2 ] After commit 05b35e7eb9a1 ("smsc95xx: add phylib support"), link changes are no longer propagated to usbnet. As a result, rx URB allocation won't happen until there is a packet sent out first (this might never happen, e.g. running just ssh server with a static IP). Fix by triggering usbnet EVENT_LINK_CHANGE. Fixes: 05b35e7eb9a1 ("smsc95xx: add phylib support") Signed-off-by: Aaro Koskinen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8de12ad9162ca2648c82d631c47c2f7de565aa73 Author: Xiao Liang Date: Thu Sep 23 23:03:19 2021 +0800 net: ipv4: Fix rtnexthop len when RTA_FLOW is present [ Upstream commit 597aa16c782496bf74c5dc3b45ff472ade6cee64 ] Multipath RTA_FLOW is embedded in nexthop. Dump it in fib_add_nexthop() to get the length of rtnexthop correct. Fixes: b0f60193632e ("ipv4: Refactor nexthop attributes in fib_dump_info") Signed-off-by: Xiao Liang Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b22c5e2c8e0380430a1c6d9ccbac8cb19d4ce986 Author: Vladimir Oltean Date: Thu Sep 23 16:23:33 2021 +0300 net: enetc: fix the incorrect clearing of IF_MODE bits [ Upstream commit 325fd36ae76a6d089983b2d2eccb41237d35b221 ] The enetc phylink .mac_config handler intends to clear the IFMODE field (bits 1:0) of the PM0_IF_MODE register, but incorrectly clears all the other fields instead. For normal operation, the bug was inconsequential, due to the fact that we write the PM0_IF_MODE register in two stages, first in phylink .mac_config (which incorrectly cleared out a bunch of stuff), then we update the speed and duplex to the correct values in phylink .mac_link_up. Judging by the code (not tested), it looks like maybe loopback mode was broken, since this is one of the settings in PM0_IF_MODE which is incorrectly cleared. Fixes: c76a97218dcb ("net: enetc: force the RGMII speed and duplex instead of operating in inband mode") Reported-by: Pavel Machek (CIP) Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5ee40530b0a6eaae24f77c63411bb1216caab0e2 Author: Paul Fertser Date: Fri Sep 24 12:30:11 2021 +0300 hwmon: (tmp421) fix rounding for negative values [ Upstream commit 724e8af85854c4d3401313b6dd7d79cf792d8990 ] Old code produces -24999 for 0b1110011100000000 input in standard format due to always rounding up rather than "away from zero". Use the common macro for division, unify and simplify the conversion code along the way. Fixes: 9410700b881f ("hwmon: Add driver for Texas Instruments TMP421/422/423 sensor chips") Signed-off-by: Paul Fertser Link: https://lore.kernel.org/r/20210924093011.26083-3-fercerpav@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 89d96f147d82c74f8ec1e2812695fbf89ec3e7ee Author: Paul Fertser Date: Fri Sep 24 12:30:10 2021 +0300 hwmon: (tmp421) report /PVLD condition as fault [ Upstream commit 540effa7f283d25bcc13c0940d808002fee340b8 ] For both local and remote sensors all the supported ICs can report an "undervoltage lockout" condition which means the conversion wasn't properly performed due to insufficient power supply voltage and so the measurement results can't be trusted. Fixes: 9410700b881f ("hwmon: Add driver for Texas Instruments TMP421/422/423 sensor chips") Signed-off-by: Paul Fertser Link: https://lore.kernel.org/r/20210924093011.26083-2-fercerpav@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 560271d09f780726f52f65cb6f19f0e95084abdc Author: Florian Westphal Date: Thu Sep 23 17:04:11 2021 -0700 mptcp: don't return sockets in foreign netns [ Upstream commit ea1300b9df7c8e8b65695a08b8f6aaf4b25fec9c ] mptcp_token_get_sock() may return a mptcp socket that is in a different net namespace than the socket that received the token value. The mptcp syncookie code path had an explicit check for this, this moves the test into mptcp_token_get_sock() function. Eventually token.c should be converted to pernet storage, but such change is not suitable for net tree. Fixes: 2c5ebd001d4f0 ("mptcp: refactor token container") Signed-off-by: Florian Westphal Signed-off-by: Mat Martineau Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9c6591ae8e63f93c895ad5e2703c36c548aac997 Author: Xin Long Date: Thu Sep 23 00:05:04 2021 -0400 sctp: break out if skb_header_pointer returns NULL in sctp_rcv_ootb [ Upstream commit f7e745f8e94492a8ac0b0a26e25f2b19d342918f ] We should always check if skb_header_pointer's return is NULL before using it, otherwise it may cause null-ptr-deref, as syzbot reported: KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_rcv_ootb net/sctp/input.c:705 [inline] RIP: 0010:sctp_rcv+0x1d84/0x3220 net/sctp/input.c:196 Call Trace: sctp6_rcv+0x38/0x60 net/sctp/ipv6.c:1109 ip6_protocol_deliver_rcu+0x2e9/0x1ca0 net/ipv6/ip6_input.c:422 ip6_input_finish+0x62/0x170 net/ipv6/ip6_input.c:463 NF_HOOK include/linux/netfilter.h:307 [inline] NF_HOOK include/linux/netfilter.h:301 [inline] ip6_input+0x9c/0xd0 net/ipv6/ip6_input.c:472 dst_input include/net/dst.h:460 [inline] ip6_rcv_finish net/ipv6/ip6_input.c:76 [inline] NF_HOOK include/linux/netfilter.h:307 [inline] NF_HOOK include/linux/netfilter.h:301 [inline] ipv6_rcv+0x28c/0x3c0 net/ipv6/ip6_input.c:297 Fixes: 3acb50c18d8d ("sctp: delay as much as possible skb_linearize") Reported-by: syzbot+581aff2ae6b860625116@syzkaller.appspotmail.com Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2c204cf594df3b9468368dc9d0b24d482d93cda7 Author: Johannes Berg Date: Wed Sep 15 11:29:37 2021 +0200 mac80211-hwsim: fix late beacon hrtimer handling [ Upstream commit 313bbd1990b6ddfdaa7da098d0c56b098a833572 ] Thomas explained in https://lore.kernel.org/r/87mtoeb4hb.ffs@tglx that our handling of the hrtimer here is wrong: If the timer fires late (e.g. due to vCPU scheduling, as reported by Dmitry/syzbot) then it tries to actually rearm the timer at the next deadline, which might be in the past already: 1 2 3 N N+1 | | | ... | | ^ intended to fire here (1) ^ next deadline here (2) ^ actually fired here The next time it fires, it's later, but will still try to schedule for the next deadline (now 3), etc. until it catches up with N, but that might take a long time, causing stalls etc. Now, all of this is simulation, so we just have to fix it, but note that the behaviour is wrong even per spec, since there's no value then in sending all those beacons unaligned - they should be aligned to the TBTT (1, 2, 3, ... in the picture), and if we're a bit (or a lot) late, then just resume at that point. Therefore, change the code to use hrtimer_forward_now() which will ensure that the next firing of the timer would be at N+1 (in the picture), i.e. the next interval point after the current time. Suggested-by: Thomas Gleixner Reported-by: Dmitry Vyukov Reported-by: syzbot+0e964fad69a9c462bc1e@syzkaller.appspotmail.com Fixes: 01e59e467ecf ("mac80211_hwsim: hrtimer beacon") Reviewed-by: Thomas Gleixner Link: https://lore.kernel.org/r/20210915112936.544f383472eb.I3f9712009027aa09244b65399bf18bf482a8c4f1@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 8576e72ac5d651c3ef41afc54b657bed7e9a69d7 Author: Johannes Berg Date: Mon Sep 20 15:40:05 2021 +0200 mac80211: mesh: fix potentially unaligned access [ Upstream commit b9731062ce8afd35cf723bf3a8ad55d208f915a5 ] The pointer here points directly into the frame, so the access is potentially unaligned. Use get_unaligned_le16 to avoid that. Fixes: 3f52b7e328c5 ("mac80211: mesh power save basics") Link: https://lore.kernel.org/r/20210920154009.3110ff75be0c.Ib6a2ff9e9cc9bc6fca50fce631ec1ce725cc926b@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 1282bb00835ff79d2d9c023055d514df5b4de260 Author: Lorenzo Bianconi Date: Mon Sep 20 14:45:22 2021 +0200 mac80211: limit injected vht mcs/nss in ieee80211_parse_tx_radiotap [ Upstream commit 13cb6d826e0ac0d144b0d48191ff1a111d32f0c6 ] Limit max values for vht mcs and nss in ieee80211_parse_tx_radiotap routine in order to fix the following warning reported by syzbot: WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_rate_set_vht include/net/mac80211.h:989 [inline] WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244 Modules linked in: CPU: 0 PID: 10717 Comm: syz-executor.5 Not tainted 5.14.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:ieee80211_rate_set_vht include/net/mac80211.h:989 [inline] RIP: 0010:ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244 RSP: 0018:ffffc9000186f3e8 EFLAGS: 00010216 RAX: 0000000000000618 RBX: ffff88804ef76500 RCX: ffffc900143a5000 RDX: 0000000000040000 RSI: ffffffff888f478e RDI: 0000000000000003 RBP: 00000000ffffffff R08: 0000000000000000 R09: 0000000000000100 R10: ffffffff888f46f9 R11: 0000000000000000 R12: 00000000fffffff8 R13: ffff88804ef7653c R14: 0000000000000001 R15: 0000000000000004 FS: 00007fbf5718f700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2de23000 CR3: 000000006a671000 CR4: 00000000001506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 Call Trace: ieee80211_monitor_select_queue+0xa6/0x250 net/mac80211/iface.c:740 netdev_core_pick_tx+0x169/0x2e0 net/core/dev.c:4089 __dev_queue_xmit+0x6f9/0x3710 net/core/dev.c:4165 __bpf_tx_skb net/core/filter.c:2114 [inline] __bpf_redirect_no_mac net/core/filter.c:2139 [inline] __bpf_redirect+0x5ba/0xd20 net/core/filter.c:2162 ____bpf_clone_redirect net/core/filter.c:2429 [inline] bpf_clone_redirect+0x2ae/0x420 net/core/filter.c:2401 bpf_prog_eeb6f53a69e5c6a2+0x59/0x234 bpf_dispatcher_nop_func include/linux/bpf.h:717 [inline] __bpf_prog_run include/linux/filter.h:624 [inline] bpf_prog_run include/linux/filter.h:631 [inline] bpf_test_run+0x381/0xa30 net/bpf/test_run.c:119 bpf_prog_test_run_skb+0xb84/0x1ee0 net/bpf/test_run.c:663 bpf_prog_test_run kernel/bpf/syscall.c:3307 [inline] __sys_bpf+0x2137/0x5df0 kernel/bpf/syscall.c:4605 __do_sys_bpf kernel/bpf/syscall.c:4691 [inline] __se_sys_bpf kernel/bpf/syscall.c:4689 [inline] __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4689 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x4665f9 Reported-by: syzbot+0196ac871673f0c20f68@syzkaller.appspotmail.com Fixes: 646e76bb5daf4 ("mac80211: parse VHT info in injected frames") Signed-off-by: Lorenzo Bianconi Link: https://lore.kernel.org/r/c26c3f02dcb38ab63b2f2534cb463d95ee81bb13.1632141760.git.lorenzo@kernel.org Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 3748871e1215834a5671849162afbcc4328f7f96 Author: Chih-Kang Chang Date: Mon Aug 30 15:32:40 2021 +0800 mac80211: Fix ieee80211_amsdu_aggregate frag_tail bug [ Upstream commit fe94bac626d9c1c5bc98ab32707be8a9d7f8adba ] In ieee80211_amsdu_aggregate() set a pointer frag_tail point to the end of skb_shinfo(head)->frag_list, and use it to bind other skb in the end of this function. But when execute ieee80211_amsdu_aggregate() ->ieee80211_amsdu_realloc_pad()->pskb_expand_head(), the address of skb_shinfo(head)->frag_list will be changed. However, the ieee80211_amsdu_aggregate() not update frag_tail after call pskb_expand_head(). That will cause the second skb can't bind to the head skb appropriately.So we update the address of frag_tail to fix it. Fixes: 6e0456b54545 ("mac80211: add A-MSDU tx support") Signed-off-by: Chih-Kang Chang Signed-off-by: Zong-Zhe Yang Signed-off-by: Ping-Ke Shih Link: https://lore.kernel.org/r/20210830073240.12736-1-pkshih@realtek.com [reword comment] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 76bbb482d33bfcd7e9070ecf594c9ec73e01c930 Author: Vadim Pasternak Date: Thu Sep 16 21:31:51 2021 +0300 hwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs [ Upstream commit e6fab7af6ba1bc77c78713a83876f60ca7a4a064 ] Fan speed minimum can be enforced from sysfs. For example, setting current fan speed to 20 is used to enforce fan speed to be at 100% speed, 19 - to be not below 90% speed, etcetera. This feature provides ability to limit fan speed according to some system wise considerations, like absence of some replaceable units or high system ambient temperature. Request for changing fan minimum speed is configuration request and can be set only through 'sysfs' write procedure. In this situation value of argument 'state' is above nominal fan speed maximum. Return non-zero code in this case to avoid thermal_cooling_device_stats_update() call, because in this case statistics update violates thermal statistics table range. The issues is observed in case kernel is configured with option CONFIG_THERMAL_STATISTICS. Here is the trace from KASAN: [ 159.506659] BUG: KASAN: slab-out-of-bounds in thermal_cooling_device_stats_update+0x7d/0xb0 [ 159.516016] Read of size 4 at addr ffff888116163840 by task hw-management.s/7444 [ 159.545625] Call Trace: [ 159.548366] dump_stack+0x92/0xc1 [ 159.552084] ? thermal_cooling_device_stats_update+0x7d/0xb0 [ 159.635869] thermal_zone_device_update+0x345/0x780 [ 159.688711] thermal_zone_device_set_mode+0x7d/0xc0 [ 159.694174] mlxsw_thermal_modules_init+0x48f/0x590 [mlxsw_core] [ 159.700972] ? mlxsw_thermal_set_cur_state+0x5a0/0x5a0 [mlxsw_core] [ 159.731827] mlxsw_thermal_init+0x763/0x880 [mlxsw_core] [ 160.070233] RIP: 0033:0x7fd995909970 [ 160.074239] Code: 73 01 c3 48 8b 0d 28 d5 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 99 2d 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff .. [ 160.095242] RSP: 002b:00007fff54f5d938 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 160.103722] RAX: ffffffffffffffda RBX: 0000000000000013 RCX: 00007fd995909970 [ 160.111710] RDX: 0000000000000013 RSI: 0000000001906008 RDI: 0000000000000001 [ 160.119699] RBP: 0000000001906008 R08: 00007fd995bc9760 R09: 00007fd996210700 [ 160.127687] R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000013 [ 160.135673] R13: 0000000000000001 R14: 00007fd995bc8600 R15: 0000000000000013 [ 160.143671] [ 160.145338] Allocated by task 2924: [ 160.149242] kasan_save_stack+0x19/0x40 [ 160.153541] __kasan_kmalloc+0x7f/0xa0 [ 160.157743] __kmalloc+0x1a2/0x2b0 [ 160.161552] thermal_cooling_device_setup_sysfs+0xf9/0x1a0 [ 160.167687] __thermal_cooling_device_register+0x1b5/0x500 [ 160.173833] devm_thermal_of_cooling_device_register+0x60/0xa0 [ 160.180356] mlxreg_fan_probe+0x474/0x5e0 [mlxreg_fan] [ 160.248140] [ 160.249807] The buggy address belongs to the object at ffff888116163400 [ 160.249807] which belongs to the cache kmalloc-1k of size 1024 [ 160.263814] The buggy address is located 64 bytes to the right of [ 160.263814] 1024-byte region [ffff888116163400, ffff888116163800) [ 160.277536] The buggy address belongs to the page: [ 160.282898] page:0000000012275840 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888116167000 pfn:0x116160 [ 160.294872] head:0000000012275840 order:3 compound_mapcount:0 compound_pincount:0 [ 160.303251] flags: 0x200000000010200(slab|head|node=0|zone=2) [ 160.309694] raw: 0200000000010200 ffffea00046f7208 ffffea0004928208 ffff88810004dbc0 [ 160.318367] raw: ffff888116167000 00000000000a0006 00000001ffffffff 0000000000000000 [ 160.327033] page dumped because: kasan: bad access detected [ 160.333270] [ 160.334937] Memory state around the buggy address: [ 160.356469] >ffff888116163800: fc .. Fixes: 65afb4c8e7e4 ("hwmon: (mlxreg-fan) Add support for Mellanox FAN driver") Signed-off-by: Vadim Pasternak Link: https://lore.kernel.org/r/20210916183151.869427-1-vadimp@nvidia.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit c61736a994fe68b0e5498e4e84e1c9108dc41075 Author: Piotr Krysiuk Date: Wed Sep 15 17:04:37 2021 +0100 bpf, mips: Validate conditional branch offsets [ Upstream commit 37cb28ec7d3a36a5bace7063a3dba633ab110f8b ] The conditional branch instructions on MIPS use 18-bit signed offsets allowing for a branch range of 128 KBytes (backward and forward). However, this limit is not observed by the cBPF JIT compiler, and so the JIT compiler emits out-of-range branches when translating certain cBPF programs. A specific example of such a cBPF program is included in the "BPF_MAXINSNS: exec all MSH" test from lib/test_bpf.c that executes anomalous machine code containing incorrect branch offsets under JIT. Furthermore, this issue can be abused to craft undesirable machine code, where the control flow is hijacked to execute arbitrary Kernel code. The following steps can be used to reproduce the issue: # echo 1 > /proc/sys/net/core/bpf_jit_enable # modprobe test_bpf test_name="BPF_MAXINSNS: exec all MSH" This should produce multiple warnings from build_bimm() similar to: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 209 at arch/mips/mm/uasm-mips.c:210 build_insn+0x558/0x590 Micro-assembler field overflow Modules linked in: test_bpf(+) CPU: 0 PID: 209 Comm: modprobe Not tainted 5.14.3 #1 Stack : 00000000 807bb824 82b33c9c 801843c0 00000000 00000004 00000000 63c9b5ee 82b33af4 80999898 80910000 80900000 82fd6030 00000001 82b33a98 82087180 00000000 00000000 80873b28 00000000 000000fc 82b3394c 00000000 2e34312e 6d6d6f43 809a180f 809a1836 6f6d203a 80900000 00000001 82b33bac 80900000 00027f80 00000000 00000000 807bb824 00000000 804ed790 001cc317 00000001 [...] Call Trace: [<80108f44>] show_stack+0x38/0x118 [<807a7aac>] dump_stack_lvl+0x5c/0x7c [<807a4b3c>] __warn+0xcc/0x140 [<807a4c3c>] warn_slowpath_fmt+0x8c/0xb8 [<8011e198>] build_insn+0x558/0x590 [<8011e358>] uasm_i_bne+0x20/0x2c [<80127b48>] build_body+0xa58/0x2a94 [<80129c98>] bpf_jit_compile+0x114/0x1e4 [<80613fc4>] bpf_prepare_filter+0x2ec/0x4e4 [<8061423c>] bpf_prog_create+0x80/0xc4 [] test_bpf_init+0x300/0xba8 [test_bpf] [<8010051c>] do_one_initcall+0x50/0x1d4 [<801c5e54>] do_init_module+0x60/0x220 [<801c8b20>] sys_finit_module+0xc4/0xfc [<801144d0>] syscall_common+0x34/0x58 [...] ---[ end trace a287d9742503c645 ]--- Then the anomalous machine code executes: => 0xc0a18000: addiu sp,sp,-16 0xc0a18004: sw s3,0(sp) 0xc0a18008: sw s4,4(sp) 0xc0a1800c: sw s5,8(sp) 0xc0a18010: sw ra,12(sp) 0xc0a18014: move s5,a0 0xc0a18018: move s4,zero 0xc0a1801c: move s3,zero # __BPF_STMT(BPF_LDX | BPF_B | BPF_MSH, 0) 0xc0a18020: lui t6,0x8012 0xc0a18024: ori t4,t6,0x9e14 0xc0a18028: li a1,0 0xc0a1802c: jalr t4 0xc0a18030: move a0,s5 0xc0a18034: bnez v0,0xc0a1ffb8 # incorrect branch offset 0xc0a18038: move v0,zero 0xc0a1803c: andi s4,s3,0xf 0xc0a18040: b 0xc0a18048 0xc0a18044: sll s4,s4,0x2 [...] # __BPF_STMT(BPF_LDX | BPF_B | BPF_MSH, 0) 0xc0a1ffa0: lui t6,0x8012 0xc0a1ffa4: ori t4,t6,0x9e14 0xc0a1ffa8: li a1,0 0xc0a1ffac: jalr t4 0xc0a1ffb0: move a0,s5 0xc0a1ffb4: bnez v0,0xc0a1ffb8 # incorrect branch offset 0xc0a1ffb8: move v0,zero 0xc0a1ffbc: andi s4,s3,0xf 0xc0a1ffc0: b 0xc0a1ffc8 0xc0a1ffc4: sll s4,s4,0x2 # __BPF_STMT(BPF_LDX | BPF_B | BPF_MSH, 0) 0xc0a1ffc8: lui t6,0x8012 0xc0a1ffcc: ori t4,t6,0x9e14 0xc0a1ffd0: li a1,0 0xc0a1ffd4: jalr t4 0xc0a1ffd8: move a0,s5 0xc0a1ffdc: bnez v0,0xc0a3ffb8 # correct branch offset 0xc0a1ffe0: move v0,zero 0xc0a1ffe4: andi s4,s3,0xf 0xc0a1ffe8: b 0xc0a1fff0 0xc0a1ffec: sll s4,s4,0x2 [...] # epilogue 0xc0a3ffb8: lw s3,0(sp) 0xc0a3ffbc: lw s4,4(sp) 0xc0a3ffc0: lw s5,8(sp) 0xc0a3ffc4: lw ra,12(sp) 0xc0a3ffc8: addiu sp,sp,16 0xc0a3ffcc: jr ra 0xc0a3ffd0: nop To mitigate this issue, we assert the branch ranges for each emit call that could generate an out-of-range branch. Fixes: 36366e367ee9 ("MIPS: BPF: Restore MIPS32 cBPF JIT") Fixes: c6610de353da ("MIPS: net: Add BPF JIT") Signed-off-by: Piotr Krysiuk Signed-off-by: Daniel Borkmann Tested-by: Johan Almbladh Acked-by: Johan Almbladh Cc: Paul Burton Cc: Thomas Bogendoerfer Link: https://lore.kernel.org/bpf/20210915160437.4080-1-piotras@gmail.com Signed-off-by: Sasha Levin commit 3f4e68902d2e545033c80d7ad62fd9a439e573f4 Author: Tao Liu Date: Mon Sep 13 17:33:44 2021 +0800 RDMA/cma: Fix listener leak in rdma_cma_listen_on_all() failure [ Upstream commit ca465e1f1f9b38fe916a36f7d80c5d25f2337c81 ] If cma_listen_on_all() fails it leaves the per-device ID still on the listen_list but the state is not set to RDMA_CM_ADDR_BOUND. When the cmid is eventually destroyed cma_cancel_listens() is not called due to the wrong state, however the per-device IDs are still holding the refcount preventing the ID from being destroyed, thus deadlocking: task:rping state:D stack: 0 pid:19605 ppid: 47036 flags:0x00000084 Call Trace: __schedule+0x29a/0x780 ? free_unref_page_commit+0x9b/0x110 schedule+0x3c/0xa0 schedule_timeout+0x215/0x2b0 ? __flush_work+0x19e/0x1e0 wait_for_completion+0x8d/0xf0 _destroy_id+0x144/0x210 [rdma_cm] ucma_close_id+0x2b/0x40 [rdma_ucm] __destroy_id+0x93/0x2c0 [rdma_ucm] ? __xa_erase+0x4a/0xa0 ucma_destroy_id+0x9a/0x120 [rdma_ucm] ucma_write+0xb8/0x130 [rdma_ucm] vfs_write+0xb4/0x250 ksys_write+0xb5/0xd0 ? syscall_trace_enter.isra.19+0x123/0x190 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Ensure that cma_listen_on_all() atomically unwinds its action under the lock during error. Fixes: c80a0c52d85c ("RDMA/cma: Add missing error handling of listen_id") Link: https://lore.kernel.org/r/20210913093344.17230-1-thomas.liu@ucloud.cn Signed-off-by: Tao Liu Reviewed-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 62ba3c50104b405b522bf539eebf70cf0dce8fcd Author: Christoph Lameter Date: Wed Sep 8 13:43:28 2021 +0200 IB/cma: Do not send IGMP leaves for sendonly Multicast groups [ Upstream commit 2cc74e1ee31d00393b6698ec80b322fd26523da4 ] ROCE uses IGMP for Multicast instead of the native Infiniband system where joins are required in order to post messages on the Multicast group. On Ethernet one can send Multicast messages to arbitrary addresses without the need to subscribe to a group. So ROCE correctly does not send IGMP joins during rdma_join_multicast(). F.e. in cma_iboe_join_multicast() we see: if (addr->sa_family == AF_INET) { if (gid_type == IB_GID_TYPE_ROCE_UDP_ENCAP) { ib.rec.hop_limit = IPV6_DEFAULT_HOPLIMIT; if (!send_only) { err = cma_igmp_send(ndev, &ib.rec.mgid, true); } } } else { So the IGMP join is suppressed as it is unnecessary. However no such check is done in destroy_mc(). And therefore leaving a sendonly multicast group will send an IGMP leave. This means that the following scenario can lead to a multicast receiver unexpectedly being unsubscribed from a MC group: 1. Sender thread does a sendonly join on MC group X. No IGMP join is sent. 2. Receiver thread does a regular join on the same MC Group x. IGMP join is sent and the receiver begins to get messages. 3. Sender thread terminates and destroys MC group X. IGMP leave is sent and the receiver no longer receives data. This patch adds the same logic for sendonly joins to destroy_mc() that is also used in cma_iboe_join_multicast(). Fixes: ab15c95a17b3 ("IB/core: Support for CMA multicast join flags") Link: https://lore.kernel.org/r/alpine.DEB.2.22.394.2109081340540.668072@gentwo.de Signed-off-by: Christoph Lameter Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit d93f65586c59a555dc4ef2fe365d32457bef0fde Author: Hou Tao Date: Tue Sep 14 10:33:51 2021 +0800 bpf: Handle return value of BPF_PROG_TYPE_STRUCT_OPS prog [ Upstream commit 356ed64991c6847a0c4f2e8fa3b1133f7a14f1fc ] Currently if a function ptr in struct_ops has a return value, its caller will get a random return value from it, because the return value of related BPF_PROG_TYPE_STRUCT_OPS prog is just dropped. So adding a new flag BPF_TRAMP_F_RET_FENTRY_RET to tell bpf trampoline to save and return the return value of struct_ops prog if ret_size of the function ptr is greater than 0. Also restricting the flag to be used alone. Fixes: 85d33df357b6 ("bpf: Introduce BPF_MAP_TYPE_STRUCT_OPS") Signed-off-by: Hou Tao Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20210914023351.3664499-1-houtao1@huawei.com Signed-off-by: Sasha Levin commit 12cbdaeeb5d4dfde7a8c2f9eed93bcfa4f4653cd Author: Andrea Claudi Date: Fri Sep 10 18:08:39 2021 +0200 ipvs: check that ip_vs_conn_tab_bits is between 8 and 20 [ Upstream commit 69e73dbfda14fbfe748d3812da1244cce2928dcb ] ip_vs_conn_tab_bits may be provided by the user through the conn_tab_bits module parameter. If this value is greater than 31, or less than 0, the shift operator used to derive tab_size causes undefined behaviour. Fix this checking ip_vs_conn_tab_bits value to be in the range specified in ipvs Kconfig. If not, simply use default value. Fixes: 6f7edb4881bf ("IPVS: Allow boot time change of hash size") Reported-by: Yi Chen Signed-off-by: Andrea Claudi Acked-by: Julian Anastasov Acked-by: Simon Horman Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 9f382e1edf90ae03be43dbd4976c2a332cd7ce2d Author: Hawking Zhang Date: Sun Sep 26 22:19:35 2021 +0800 drm/amdgpu: correct initial cp_hqd_quantum for gfx9 commit 9f52c25f59b504a29dda42d83ac1e24d2af535d4 upstream. didn't read the value of mmCP_HQD_QUANTUM from correct register offset Signed-off-by: Hawking Zhang Reviewed-by: Le Ma Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit c331fad63b6d527193ae8b7c056b2f10fef53c81 Author: Charlene Liu Date: Mon Sep 20 14:30:02 2021 -0400 drm/amd/display: Pass PCI deviceid into DC commit d942856865c733ff60450de9691af796ad71d7bc upstream. [why] pci deviceid not passed to dal dc, without proper break, dcn2.x falls into dcn3.x code path [how] pass in pci deviceid, and break once dal_version initialized. Reviewed-by: Zhan Liu Acked-by: Anson Jacob Signed-off-by: Charlene Liu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 0a16c9751e0f1de96f08643216cf1f19e8a5a787 Author: Jason Gunthorpe Date: Wed Sep 15 17:21:43 2021 -0300 RDMA/cma: Do not change route.addr.src_addr.ss_family commit bc0bdc5afaa740d782fbf936aaeebd65e5c2921d upstream. If the state is not idle then rdma_bind_addr() will immediately fail and no change to global state should happen. For instance if the state is already RDMA_CM_LISTEN then this will corrupt the src_addr and would cause the test in cma_cancel_operation(): if (cma_any_addr(cma_src_addr(id_priv)) && !id_priv->cma_dev) To view a mangled src_addr, eg with a IPv6 loopback address but an IPv4 family, failing the test. This would manifest as this trace from syzkaller: BUG: KASAN: use-after-free in __list_add_valid+0x93/0xa0 lib/list_debug.c:26 Read of size 8 at addr ffff8881546491e0 by task syz-executor.1/32204 CPU: 1 PID: 32204 Comm: syz-executor.1 Not tainted 5.12.0-rc8-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:232 __kasan_report mm/kasan/report.c:399 [inline] kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:416 __list_add_valid+0x93/0xa0 lib/list_debug.c:26 __list_add include/linux/list.h:67 [inline] list_add_tail include/linux/list.h:100 [inline] cma_listen_on_all drivers/infiniband/core/cma.c:2557 [inline] rdma_listen+0x787/0xe00 drivers/infiniband/core/cma.c:3751 ucma_listen+0x16a/0x210 drivers/infiniband/core/ucma.c:1102 ucma_write+0x259/0x350 drivers/infiniband/core/ucma.c:1732 vfs_write+0x28e/0xa30 fs/read_write.c:603 ksys_write+0x1ee/0x250 fs/read_write.c:658 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae Which is indicating that an rdma_id_private was destroyed without doing cma_cancel_listens(). Instead of trying to re-use the src_addr memory to indirectly create an any address build one explicitly on the stack and bind to that as any other normal flow would do. Link: https://lore.kernel.org/r/0-v1-9fbb33f5e201+2a-cma_listen_jgg@nvidia.com Cc: stable@vger.kernel.org Fixes: 732d41c545bb ("RDMA/cma: Make the locking for automatic state transition more clear") Reported-by: syzbot+6bb0528b13611047209c@syzkaller.appspotmail.com Tested-by: Hao Sun Reviewed-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 31a13f039e15e6e16d30081cd07a8bbb1d9526e3 Author: Sean Young Date: Tue Sep 14 16:57:46 2021 +0200 media: ir_toy: prevent device from hanging during transmit commit f0c15b360fb65ee39849afe987c16eb3d0175d0d upstream. If the IR Toy is receiving IR while a transmit is done, it may end up hanging. We can prevent this from happening by re-entering sample mode just before issuing the transmit command. Link: https://github.com/bengtmartensson/HarcHardware/discussions/25 Cc: stable@vger.kernel.org Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 249e5e5a501ee69b26d55b68f863671396e62f7f Author: Sean Christopherson Date: Wed Sep 1 13:30:26 2021 -0700 KVM: rseq: Update rseq when processing NOTIFY_RESUME on xfer to KVM guest commit 8646e53633f314e4d746a988240d3b951a92f94a upstream. Invoke rseq's NOTIFY_RESUME handler when processing the flag prior to transferring to a KVM guest, which is roughly equivalent to an exit to userspace and processes many of the same pending actions. While the task cannot be in an rseq critical section as the KVM path is reachable only by via ioctl(KVM_RUN), the side effects that apply to rseq outside of a critical section still apply, e.g. the current CPU needs to be updated if the task is migrated. Clearing TIF_NOTIFY_RESUME without informing rseq can lead to segfaults and other badness in userspace VMMs that use rseq in combination with KVM, e.g. due to the CPU ID being stale after task migration. Fixes: 72c3c0fe54a3 ("x86/kvm: Use generic xfer to guest work function") Reported-by: Peter Foley Bisected-by: Doug Evans Acked-by: Mathieu Desnoyers Cc: Shakeel Butt Cc: Thomas Gleixner Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20210901203030.1292304-2-seanjc@google.com> Signed-off-by: Paolo Bonzini [sean: Resolve benign conflict due to unrelated access_ok() check in 5.10] Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 3778511dfc5941b0ee99d1040faab5c69e51dfac Author: Vitaly Kuznetsov Date: Tue Sep 7 18:35:30 2021 +0200 KVM: nVMX: Filter out all unsupported controls when eVMCS was activated commit 8d68bad6d869fae8f4d50ab6423538dec7da72d1 upstream. Windows Server 2022 with Hyper-V role enabled failed to boot on KVM when enlightened VMCS is advertised. Debugging revealed there are two exposed secondary controls it is not happy with: SECONDARY_EXEC_ENABLE_VMFUNC and SECONDARY_EXEC_SHADOW_VMCS. These controls are known to be unsupported, as there are no corresponding fields in eVMCSv1 (see the comment above EVMCS1_UNSUPPORTED_2NDEXEC definition). Previously, commit 31de3d2500e4 ("x86/kvm/hyper-v: move VMX controls sanitization out of nested_enable_evmcs()") introduced the required filtering mechanism for VMX MSRs but for some reason put only known to be problematic (and not full EVMCS1_UNSUPPORTED_* lists) controls there. Note, Windows Server 2022 seems to have gained some sanity check for VMX MSRs: it doesn't even try to launch a guest when there's something it doesn't like, nested_evmcs_check_controls() mechanism can't catch the problem. Let's be bold this time and instead of playing whack-a-mole just filter out all unsupported controls from VMX MSRs. Fixes: 31de3d2500e4 ("x86/kvm/hyper-v: move VMX controls sanitization out of nested_enable_evmcs()") Signed-off-by: Vitaly Kuznetsov Message-Id: <20210907163530.110066-1-vkuznets@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 4ed671e6bc62325729311dbc75c6db52d10233a7 Author: Maxim Levitsky Date: Tue Sep 14 18:48:16 2021 +0300 KVM: x86: nSVM: don't copy virt_ext from vmcb12 commit faf6b755629627f19feafa75b32e81cd7738f12d upstream. These field correspond to features that we don't expose yet to L2 While currently there are no CVE worthy features in this field, if AMD adds more features to this field, that could allow guest escapes similar to CVE-2021-3653 and CVE-2021-3656. Signed-off-by: Maxim Levitsky Message-Id: <20210914154825.104886-6-mlevitsk@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit bebabb76ad9acca8858e0371e102fb60d708e25b Author: Vitaly Kuznetsov Date: Fri Aug 27 11:25:14 2021 +0200 KVM: x86: Fix stack-out-of-bounds memory access from ioapic_write_indirect() commit 2f9b68f57c6278c322793a06063181deded0ad69 upstream. KASAN reports the following issue: BUG: KASAN: stack-out-of-bounds in kvm_make_vcpus_request_mask+0x174/0x440 [kvm] Read of size 8 at addr ffffc9001364f638 by task qemu-kvm/4798 CPU: 0 PID: 4798 Comm: qemu-kvm Tainted: G X --------- --- Hardware name: AMD Corporation DAYTONA_X/DAYTONA_X, BIOS RYM0081C 07/13/2020 Call Trace: dump_stack+0xa5/0xe6 print_address_description.constprop.0+0x18/0x130 ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm] __kasan_report.cold+0x7f/0x114 ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm] kasan_report+0x38/0x50 kasan_check_range+0xf5/0x1d0 kvm_make_vcpus_request_mask+0x174/0x440 [kvm] kvm_make_scan_ioapic_request_mask+0x84/0xc0 [kvm] ? kvm_arch_exit+0x110/0x110 [kvm] ? sched_clock+0x5/0x10 ioapic_write_indirect+0x59f/0x9e0 [kvm] ? static_obj+0xc0/0xc0 ? __lock_acquired+0x1d2/0x8c0 ? kvm_ioapic_eoi_inject_work+0x120/0x120 [kvm] The problem appears to be that 'vcpu_bitmap' is allocated as a single long on stack and it should really be KVM_MAX_VCPUS long. We also seem to clear the lower 16 bits of it with bitmap_zero() for no particular reason (my guess would be that 'bitmap' and 'vcpu_bitmap' variables in kvm_bitmap_or_dest_vcpus() caused the confusion: while the later is indeed 16-bit long, the later should accommodate all possible vCPUs). Fixes: 7ee30bc132c6 ("KVM: x86: deliver KVM IOAPIC scan request to target vCPUs") Fixes: 9a2ae9f6b6bb ("KVM: x86: Zero the IOAPIC scan request dest vCPUs bitmap") Reported-by: Dr. David Alan Gilbert Signed-off-by: Vitaly Kuznetsov Reviewed-by: Maxim Levitsky Reviewed-by: Sean Christopherson Message-Id: <20210827092516.1027264-7-vkuznets@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 782122ae7db0c4af199a0fdb4d03fcc1e2c7b734 Author: Zelin Deng Date: Wed Sep 29 13:13:48 2021 +0800 x86/kvmclock: Move this_cpu_pvti into kvmclock.h commit ad9af930680bb396c87582edc172b3a7cf2a3fbf upstream. There're other modules might use hv_clock_per_cpu variable like ptp_kvm, so move it into kvmclock.h and export the symbol to make it visiable to other modules. Signed-off-by: Zelin Deng Cc: Message-Id: <1632892429-101194-2-git-send-email-zelin.deng@linux.alibaba.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 57de2dcb18742dc2860861c9f496da7d42b67da0 Author: Johannes Berg Date: Mon Sep 27 11:58:39 2021 +0200 mac80211: fix use-after-free in CCMP/GCMP RX commit 94513069eb549737bcfc3d988d6ed4da948a2de8 upstream. When PN checking is done in mac80211, for fragmentation we need to copy the PN to the RX struct so we can later use it to do a comparison, since commit bf30ca922a0c ("mac80211: check defrag PN against current frame"). Unfortunately, in that commit I used the 'hdr' variable without it being necessarily valid, so use-after-free could occur if it was necessary to reallocate (parts of) the frame. Fix this by reloading the variable after the code that results in the reallocations, if any. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=214401. Cc: stable@vger.kernel.org Fixes: bf30ca922a0c ("mac80211: check defrag PN against current frame") Link: https://lore.kernel.org/r/20210927115838.12b9ac6bb233.I1d066acd5408a662c3b6e828122cd314fcb28cdb@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 201ba843fef53d7098ed30d359046938e3b50193 Author: Jonathan Hsu Date: Fri Sep 24 16:58:48 2021 +0800 scsi: ufs: Fix illegal offset in UPIU event trace commit e8c2da7e329ce004fee748b921e4c765dc2fa338 upstream. Fix incorrect index for UTMRD reference in ufshcd_add_tm_upiu_trace(). Link: https://lore.kernel.org/r/20210924085848.25500-1-jonathan.hsu@mediatek.com Fixes: 4b42d557a8ad ("scsi: ufs: core: Fix wrong Task Tag used in task management request UPIUs") Cc: stable@vger.kernel.org Reviewed-by: Stanley Chu Reviewed-by: Bart Van Assche Signed-off-by: Jonathan Hsu Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit bd4e446a6947528f6ea7e0e7f19031a4389a4017 Author: Andrey Gusakov Date: Thu Sep 23 20:22:16 2021 +0300 gpio: pca953x: do not ignore i2c errors commit 540cffbab8b8e6c52a4121666ca18d6e94586ed2 upstream. Per gpio_chip interface, error shall be proparated to the caller. Attempt to silent diagnostics by returning zero (as written in the comment) is plain wrong, because the zero return can be interpreted by the caller as the gpio value. Cc: stable@vger.kernel.org Signed-off-by: Andrey Gusakov Signed-off-by: Nikita Yushchenko Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 516d9055039017a20a698103be2b556b4c976bb8 Author: Nadezda Lutovinova Date: Tue Sep 21 18:51:51 2021 +0300 hwmon: (w83791d) Fix NULL pointer dereference by removing unnecessary structure field commit 943c15ac1b84d378da26bba41c83c67e16499ac4 upstream. If driver read val value sufficient for (val & 0x08) && (!(val & 0x80)) && ((val & 0x7) == ((val >> 4) & 0x7)) from device then Null pointer dereference occurs. (It is possible if tmp = 0b0xyz1xyz, where same literals mean same numbers) Also lm75[] does not serve a purpose anymore after switching to devm_i2c_new_dummy_device() in w83791d_detect_subclients(). The patch fixes possible NULL pointer dereference by removing lm75[]. Found by Linux Driver Verification project (linuxtesting.org). Cc: stable@vger.kernel.org Signed-off-by: Nadezda Lutovinova Link: https://lore.kernel.org/r/20210921155153.28098-1-lutovinova@ispras.ru [groeck: Dropped unnecessary continuation lines, fixed multi-line alignment] Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 1499bb2c3a87a2efea0065adab2bd66badee61c3 Author: Nadezda Lutovinova Date: Tue Sep 21 18:51:52 2021 +0300 hwmon: (w83792d) Fix NULL pointer dereference by removing unnecessary structure field commit 0f36b88173f028e372668ae040ab1a496834d278 upstream. If driver read val value sufficient for (val & 0x08) && (!(val & 0x80)) && ((val & 0x7) == ((val >> 4) & 0x7)) from device then Null pointer dereference occurs. (It is possible if tmp = 0b0xyz1xyz, where same literals mean same numbers) Also lm75[] does not serve a purpose anymore after switching to devm_i2c_new_dummy_device() in w83791d_detect_subclients(). The patch fixes possible NULL pointer dereference by removing lm75[]. Found by Linux Driver Verification project (linuxtesting.org). Cc: stable@vger.kernel.org Signed-off-by: Nadezda Lutovinova Link: https://lore.kernel.org/r/20210921155153.28098-2-lutovinova@ispras.ru [groeck: Dropped unnecessary continuation lines, fixed multipline alignment] Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 7c4fd5de39f273626a2b0f3a446d2cc85cd47616 Author: Nadezda Lutovinova Date: Tue Sep 21 18:51:53 2021 +0300 hwmon: (w83793) Fix NULL pointer dereference by removing unnecessary structure field commit dd4d747ef05addab887dc8ff0d6ab9860bbcd783 upstream. If driver read tmp value sufficient for (tmp & 0x08) && (!(tmp & 0x80)) && ((tmp & 0x7) == ((tmp >> 4) & 0x7)) from device then Null pointer dereference occurs. (It is possible if tmp = 0b0xyz1xyz, where same literals mean same numbers) Also lm75[] does not serve a purpose anymore after switching to devm_i2c_new_dummy_device() in w83791d_detect_subclients(). The patch fixes possible NULL pointer dereference by removing lm75[]. Found by Linux Driver Verification project (linuxtesting.org). Cc: stable@vger.kernel.org Signed-off-by: Nadezda Lutovinova Link: https://lore.kernel.org/r/20210921155153.28098-3-lutovinova@ispras.ru [groeck: Dropped unnecessary continuation lines, fixed multi-line alignments] Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 196dabd96bbfd8b816aeeb9b7a59bd489ed0ac89 Author: Paul Fertser Date: Fri Sep 24 12:30:09 2021 +0300 hwmon: (tmp421) handle I2C errors commit 2938b2978a70d4cc10777ee71c9e512ffe4e0f4b upstream. Function i2c_smbus_read_byte_data() can return a negative error number instead of the data read if I2C transaction failed for whatever reason. Lack of error checking can lead to serious issues on production hardware, e.g. errors treated as temperatures produce spurious critical temperature-crossed-threshold errors in BMC logs for OCP server hardware. The patch was tested with Mellanox OCP Mezzanine card emulating TMP421 protocol for temperature sensing which sometimes leads to I2C protocol error during early boot up stage. Fixes: 9410700b881f ("hwmon: Add driver for Texas Instruments TMP421/422/423 sensor chips") Cc: stable@vger.kernel.org Signed-off-by: Paul Fertser Link: https://lore.kernel.org/r/20210924093011.26083-1-fercerpav@gmail.com [groeck: dropped unnecessary line breaks] Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 23a6dfa10f0379509b334ee6db428488b7fbe0a0 Author: Eric Biggers Date: Thu Sep 16 13:34:24 2021 -0700 fs-verity: fix signed integer overflow with i_size near S64_MAX commit 80f6e3080bfcf865062a926817b3ca6c4a137a57 upstream. If the file size is almost S64_MAX, the calculated number of Merkle tree levels exceeds FS_VERITY_MAX_LEVELS, causing FS_IOC_ENABLE_VERITY to fail. This is unintentional, since as the comment above the definition of FS_VERITY_MAX_LEVELS states, it is enough for over U64_MAX bytes of data using SHA-256 and 4K blocks. (Specifically, 4096*128**8 >= 2**64.) The bug is actually that when the number of blocks in the first level is calculated from i_size, there is a signed integer overflow due to i_size being signed. Fix this by treating i_size as unsigned. This was found by the new test "generic: test fs-verity EFBIG scenarios" (https://lkml.kernel.org/r/b1d116cd4d0ea74b9cd86f349c672021e005a75c.1631558495.git.boris@bur.io). This didn't affect ext4 or f2fs since those have a smaller maximum file size, but it did affect btrfs which allows files up to S64_MAX bytes. Reported-by: Boris Burkov Fixes: 3fda4c617e84 ("fs-verity: implement FS_IOC_ENABLE_VERITY ioctl") Fixes: fd2d1acfcadf ("fs-verity: add the hook for file ->open()") Cc: # v5.4+ Reviewed-by: Boris Burkov Link: https://lore.kernel.org/r/20210916203424.113376-1-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit d1d0016e4a7d317c7680f63e61f717c066157b57 Author: Jia He Date: Wed Sep 22 23:29:19 2021 +0800 ACPI: NFIT: Use fallback node id when numa info in NFIT table is incorrect commit f060db99374e80e853ac4916b49f0a903f65e9dc upstream. When ACPI NFIT table is failing to populate correct numa information on arm64, dax_kmem will get NUMA_NO_NODE from the NFIT driver. Without this patch, pmem can't be probed as RAM devices on arm64 guest: $ndctl create-namespace -fe namespace0.0 --mode=devdax --map=dev -s 1g -a 128M kmem dax0.0: rejecting DAX region [mem 0x240400000-0x2bfffffff] with invalid node: -1 kmem: probe of dax0.0 failed with error -22 Suggested-by: Dan Williams Signed-off-by: Jia He Cc: Fixes: c221c0b0308f ("device-dax: "Hotplug" persistent memory for use like normal RAM") Link: https://lore.kernel.org/r/20210922152919.6940-1-justin.he@arm.com Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit e9edc7bc611a2c3b3079677abe97e7fa9db596ce Author: Cameron Berkenpas Date: Mon Sep 13 14:26:29 2021 -0700 ALSA: hda/realtek: Quirks to enable speaker output for Lenovo Legion 7i 15IMHG05, Yoga 7i 14ITL5/15ITL5, and 13s Gen2 laptops. commit ad7cc2d41b7a8d0c5c5ecff37c3de7a4e137b3a6 upstream. This patch initializes and enables speaker output on the Lenovo Legion 7i 15IMHG05, Yoga 7i 14ITL5/15ITL5, and 13s Gen2 series of laptops using the HDA verb sequence specific to each model. Speaker automute is suppressed for the Lenovo Legion 7i 15IMHG05 to avoid breaking speaker output on resume and when devices are unplugged from its headphone jack. Thanks to: Andreas Holzer, Vincent Morel, sycxyc, Max Christian Pohle and all others that helped. [ minor coding style fixes by tiwai ] BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208555 Signed-off-by: Cameron Berkenpas Cc: Link: https://lore.kernel.org/r/20210913212627.339362-1-cam@neo-zeon.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 23115ca7d22718662418a79962551ad42033cbd3 Author: Pawel Laszczak Date: Tue Sep 7 08:26:19 2021 +0200 usb: cdns3: fix race condition before setting doorbell [ Upstream commit b69ec50b3e55c4b2a85c8bc46763eaf330605847 ] For DEV_VER_V3 version there exist race condition between clearing ep_sts.EP_STS_TRBERR and setting ep_cmd.EP_CMD_DRDY bit. Setting EP_CMD_DRDY will be ignored by controller when EP_STS_TRBERR is set. So, between these two instructions we have a small time gap in which the EP_STSS_TRBERR can be set. In such case the transfer will not start after setting doorbell. Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") cc: # 5.12.x Tested-by: Aswath Govindraju Reviewed-by: Aswath Govindraju Signed-off-by: Pawel Laszczak Link: https://lore.kernel.org/r/20210907062619.34622-1-pawell@gli-login.cadence.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3945c481360caee7d496c95b5c73afe923a1c7cd Author: James Morse Date: Tue Sep 14 16:56:23 2021 +0000 cpufreq: schedutil: Destroy mutex before kobject_put() frees the memory [ Upstream commit cdef1196608892b9a46caa5f2b64095a7f0be60c ] Since commit e5c6b312ce3c ("cpufreq: schedutil: Use kobject release() method to free sugov_tunables") kobject_put() has kfree()d the attr_set before gov_attr_set_put() returns. kobject_put() isn't the last user of attr_set in gov_attr_set_put(), the subsequent mutex_destroy() triggers a use-after-free: | BUG: KASAN: use-after-free in mutex_is_locked+0x20/0x60 | Read of size 8 at addr ffff000800ca4250 by task cpuhp/2/20 | | CPU: 2 PID: 20 Comm: cpuhp/2 Not tainted 5.15.0-rc1 #12369 | Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development | Platform, BIOS EDK II Jul 30 2018 | Call trace: | dump_backtrace+0x0/0x380 | show_stack+0x1c/0x30 | dump_stack_lvl+0x8c/0xb8 | print_address_description.constprop.0+0x74/0x2b8 | kasan_report+0x1f4/0x210 | kasan_check_range+0xfc/0x1a4 | __kasan_check_read+0x38/0x60 | mutex_is_locked+0x20/0x60 | mutex_destroy+0x80/0x100 | gov_attr_set_put+0xfc/0x150 | sugov_exit+0x78/0x190 | cpufreq_offline.isra.0+0x2c0/0x660 | cpuhp_cpufreq_offline+0x14/0x24 | cpuhp_invoke_callback+0x430/0x6d0 | cpuhp_thread_fun+0x1b0/0x624 | smpboot_thread_fn+0x5e0/0xa6c | kthread+0x3a0/0x450 | ret_from_fork+0x10/0x20 Swap the order of the calls. Fixes: e5c6b312ce3c ("cpufreq: schedutil: Use kobject release() method to free sugov_tunables") Cc: 4.7+ # 4.7+ Signed-off-by: James Morse Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 2193cf76f43acdbd87b8609c7206f0b414b241d9 Author: Saurav Kashyap Date: Mon Aug 9 21:37:18 2021 -0700 scsi: qla2xxx: Changes to support kdump kernel for NVMe BFS [ Upstream commit 4a0a542fe5e4273baf9228459ef3f75c29490cba ] The MSI-X and MSI calls fails in kdump kernel. Because of this qla2xxx_create_qpair() fails leading to .create_queue callback failure. The fix is to return existing qpair instead of allocating new one and allocate a single hw queue. [ 19.975838] qla2xxx [0000:d8:00.1]-00c7:11: MSI-X: Failed to enable support, giving up -- 16/-28. [ 19.984885] qla2xxx [0000:d8:00.1]-0037:11: Falling back-to MSI mode -- ret=-28. [ 19.992278] qla2xxx [0000:d8:00.1]-0039:11: Falling back-to INTa mode -- ret=-28. .. .. .. [ 21.141518] qla2xxx [0000:d8:00.0]-2104:2: qla_nvme_alloc_queue: handle 00000000e7ee499d, idx =1, qsize 32 [ 21.151166] qla2xxx [0000:d8:00.0]-0181:2: FW/Driver is not multi-queue capable. [ 21.158558] qla2xxx [0000:d8:00.0]-2122:2: Failed to allocate qpair [ 21.164824] nvme nvme0: NVME-FC{0}: reset: Reconnect attempt failed (-22) [ 21.171612] nvme nvme0: NVME-FC{0}: Reconnect attempt in 2 seconds Link: https://lore.kernel.org/r/20210810043720.1137-13-njavali@marvell.com Cc: stable@vger.kernel.org Reviewed-by: Himanshu Madhani Signed-off-by: Saurav Kashyap Signed-off-by: Nilesh Javali Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a7d4fc84404d45d72f4490417e8cc3efa4af93f1 Author: Kevin Hao Date: Thu Aug 5 15:29:17 2021 +0800 cpufreq: schedutil: Use kobject release() method to free sugov_tunables [ Upstream commit e5c6b312ce3cc97e90ea159446e6bfa06645364d ] The struct sugov_tunables is protected by the kobject, so we can't free it directly. Otherwise we would get a call trace like this: ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x30 WARNING: CPU: 3 PID: 720 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100 Modules linked in: CPU: 3 PID: 720 Comm: a.sh Tainted: G W 5.14.0-rc1-next-20210715-yocto-standard+ #507 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 40400009 (nZcv daif +PAN -UAO -TCO BTYPE=--) pc : debug_print_object+0xb8/0x100 lr : debug_print_object+0xb8/0x100 sp : ffff80001ecaf910 x29: ffff80001ecaf910 x28: ffff00011b10b8d0 x27: ffff800011043d80 x26: ffff00011a8f0000 x25: ffff800013cb3ff0 x24: 0000000000000000 x23: ffff80001142aa68 x22: ffff800011043d80 x21: ffff00010de46f20 x20: ffff800013c0c520 x19: ffff800011d8f5b0 x18: 0000000000000010 x17: 6e6968207473696c x16: 5f72656d6974203a x15: 6570797420746365 x14: 6a626f2029302065 x13: 303378302f307830 x12: 2b6e665f72656d69 x11: ffff8000124b1560 x10: ffff800012331520 x9 : ffff8000100ca6b0 x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 0000000000000001 x5 : ffff800011d8c000 x4 : ffff800011d8c740 x3 : 0000000000000000 x2 : ffff0001108301c0 x1 : ab3c90eedf9c0f00 x0 : 0000000000000000 Call trace: debug_print_object+0xb8/0x100 __debug_check_no_obj_freed+0x1c0/0x230 debug_check_no_obj_freed+0x20/0x88 slab_free_freelist_hook+0x154/0x1c8 kfree+0x114/0x5d0 sugov_exit+0xbc/0xc0 cpufreq_exit_governor+0x44/0x90 cpufreq_set_policy+0x268/0x4a8 store_scaling_governor+0xe0/0x128 store+0xc0/0xf0 sysfs_kf_write+0x54/0x80 kernfs_fop_write_iter+0x128/0x1c0 new_sync_write+0xf0/0x190 vfs_write+0x2d4/0x478 ksys_write+0x74/0x100 __arm64_sys_write+0x24/0x30 invoke_syscall.constprop.0+0x54/0xe0 do_el0_svc+0x64/0x158 el0_svc+0x2c/0xb0 el0t_64_sync_handler+0xb0/0xb8 el0t_64_sync+0x198/0x19c irq event stamp: 5518 hardirqs last enabled at (5517): [] console_unlock+0x554/0x6c8 hardirqs last disabled at (5518): [] el1_dbg+0x28/0xa0 softirqs last enabled at (5504): [] __do_softirq+0x4d0/0x6c0 softirqs last disabled at (5483): [] irq_exit+0x1b0/0x1b8 So split the original sugov_tunables_free() into two functions, sugov_clear_global_tunables() is just used to clear the global_tunables and the new sugov_tunables_free() is used as kobj_type::release to release the sugov_tunables safely. Fixes: 9bdcb44e391d ("cpufreq: schedutil: New governor based on scheduler utilization data") Cc: 4.7+ # 4.7+ Signed-off-by: Kevin Hao Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit d570c48dd37dbe8fc6875d4461d01a9554ae2560 Author: Igor Matheus Andrade Torrente Date: Mon Jun 28 10:45:09 2021 -0300 tty: Fix out-of-bound vmalloc access in imageblit [ Upstream commit 3b0c406124719b625b1aba431659f5cdc24a982c ] This issue happens when a userspace program does an ioctl FBIOPUT_VSCREENINFO passing the fb_var_screeninfo struct containing only the fields xres, yres, and bits_per_pixel with values. If this struct is the same as the previous ioctl, the vc_resize() detects it and doesn't call the resize_screen(), leaving the fb_var_screeninfo incomplete. And this leads to the updatescrollmode() calculates a wrong value to fbcon_display->vrows, which makes the real_y() return a wrong value of y, and that value, eventually, causes the imageblit to access an out-of-bound address value. To solve this issue I made the resize_screen() be called even if the screen does not need any resizing, so it will "fix and fill" the fb_var_screeninfo independently. Cc: stable # after 5.15-rc2 is out, give it time to bake Reported-and-tested-by: syzbot+858dc7a2f7ef07c2c219@syzkaller.appspotmail.com Signed-off-by: Igor Matheus Andrade Torrente Link: https://lore.kernel.org/r/20210628134509.15895-1-igormtorrente@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f93026b28e2afe5060a493b0bbcee19d12961b7e Author: Greg Kroah-Hartman Date: Thu Sep 30 10:11:08 2021 +0200 Linux 5.10.70 Link: https://lore.kernel.org/r/20210927170225.702078779@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Pavel Machek (CIP) Tested-by: Fox Chen Tested-by: Shuah Khan Tested-by: Jon Hunter Tested-by: Hulk Robot Tested-by: Jon Hunter Link: https://lore.kernel.org/r/20210928071741.331837387@linuxfoundation.org Tested-by: Sudip Mukherjee Tested-by: Salvatore Bonaccorso Tested-by: Florian Fainelli Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Fox Chen Tested-by: Hulk Robot Signed-off-by: Greg Kroah-Hartman commit 59094296058d22864b7eebaed0fa1fc7adda3b74 Author: Linus Torvalds Date: Mon Sep 20 10:26:21 2021 -0700 qnx4: work around gcc false positive warning bug commit d5f6545934c47e97c0b48a645418e877b452a992 upstream. In commit b7213ffa0e58 ("qnx4: avoid stringop-overread errors") I tried to teach gcc about how the directory entry structure can be two different things depending on a status flag. It made the code clearer, and it seemed to make gcc happy. However, Arnd points to a gcc bug, where despite using two different members of a union, gcc then gets confused, and uses the size of one of the members to decide if a string overrun happens. And not necessarily the rigth one. End result: with some configurations, gcc-11 will still complain about the source buffer size being overread: fs/qnx4/dir.c: In function 'qnx4_readdir': fs/qnx4/dir.c:76:32: error: 'strnlen' specified bound [16, 48] exceeds source size 1 [-Werror=stringop-overread] 76 | size = strnlen(name, size); | ^~~~~~~~~~~~~~~~~~~ fs/qnx4/dir.c:26:22: note: source object declared here 26 | char de_name; | ^~~~~~~ because gcc will get confused about which union member entry is actually getting accessed, even when the source code is very clear about it. Gcc internally will have combined two "redundant" pointers (pointing to different union elements that are at the same offset), and takes the size checking from one or the other - not necessarily the right one. This is clearly a gcc bug, but we can work around it fairly easily. The biggest thing here is the big honking comment about why we do what we do. Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578#c6 Reported-and-tested-by: Arnd Bergmann Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 35c0dfbbd3448f6c6e71d513a85fd0acec6aa325 Author: Juergen Gross Date: Mon Sep 20 12:03:45 2021 +0200 xen/balloon: fix balloon kthread freezing commit 96f5bd03e1be606987644b71899ea56a8d05f825 upstream. Commit 8480ed9c2bbd56 ("xen/balloon: use a kernel thread instead a workqueue") switched the Xen balloon driver to use a kernel thread. Unfortunately the patch omitted to call try_to_freeze() or to use wait_event_freezable_timeout(), causing a system suspend to fail. Fixes: 8480ed9c2bbd56 ("xen/balloon: use a kernel thread instead a workqueue") Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Link: https://lore.kernel.org/r/20210920100345.21939-1-jgross@suse.com Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 8373d58c89be9406f64f8facb311ab10b97cd026 Author: Johan Hovold Date: Wed Sep 22 13:30:59 2021 +0200 USB: serial: cp210x: fix dropped characters with CP2102 commit c32dfec6c1c36bbbcd5d33e949d99aeb215877ec upstream. Some CP2102 do not support event-insertion mode but return no error when attempting to enable it. This means that any event escape characters in the input stream will not be escaped by the device and consequently regular data may be interpreted as escape sequences and be removed from the stream by the driver. The reporter's device has batch number DCL00X etched into it and as discovered by the SHA2017 Badge team, counterfeit devices with that marking can be detected by sending malformed vendor requests. [1][2] Tests confirm that the possibly counterfeit CP2102 returns a single byte in response to a malformed two-byte part-number request, while an original CP2102 returns two bytes. Assume that every CP2102 that behaves this way also does not support event-insertion mode (e.g. cannot report parity errors). [1] https://mobile.twitter.com/sha2017badge/status/1167902087289532418 [2] https://hackaday.com/2017/08/14/hands-on-with-the-shacamp-2017-badge/#comment-3903376 Reported-by: Malte Di Donato Tested-by: Malte Di Donato Fixes: a7207e9835a4 ("USB: serial: cp210x: add support for line-status events") Cc: stable@vger.kernel.org # 5.9 Link: https://lore.kernel.org/r/20210922113100.20888-1-johan@kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 67cdb51ab5e252bcd8061936a7f0c65def8f4360 Author: Antoine Tenart Date: Thu Sep 9 10:56:12 2021 +0200 thermal/drivers/int340x: Do not set a wrong tcc offset on resume commit 8b4bd256674720709a9d858a219fcac6f2f253b5 upstream. After upgrading to Linux 5.13.3 I noticed my laptop would shutdown due to overheat (when it should not). It turned out this was due to commit fe6a6de6692e ("thermal/drivers/int340x/processor_thermal: Fix tcc setting"). What happens is this drivers uses a global variable to keep track of the tcc offset (tcc_offset_save) and uses it on resume. The issue is this variable is initialized to 0, but is only set in tcc_offset_degree_celsius_store, i.e. when the tcc offset is explicitly set by userspace. If that does not happen, the resume path will set the offset to 0 (in my case the h/w default being 3, the offset would become too low after a suspend/resume cycle). The issue did not arise before commit fe6a6de6692e, as the function setting the offset would return if the offset was 0. This is no longer the case (rightfully). Fix this by not applying the offset if it wasn't saved before, reverting back to the old logic. A better approach will come later, but this will be easier to apply to stable kernels. The logic to restore the offset after a resume was there long before commit fe6a6de6692e, but as a value of 0 was considered invalid I'm referencing the commit that made the issue possible in the Fixes tag instead. Fixes: fe6a6de6692e ("thermal/drivers/int340x/processor_thermal: Fix tcc setting") Cc: stable@vger.kernel.org Cc: Srinivas Pandruvada Signed-off-by: Antoine Tenart Signed-off-by: Daniel Lezcano Reviewed-by: Srinivas Pandruvada Tested-by: Srinivas Pandruvada Link: https://lore.kernel.org/r/20210909085613.5577-2-atenart@kernel.org Signed-off-by: Greg Kroah-Hartman commit cc71740ee4d4c469efbc2f6faf329c01d20f91c9 Author: Borislav Petkov Date: Thu Sep 16 10:44:06 2021 +0200 EDAC/dmc520: Assign the proper type to dimm->edac_mode commit 54607282fae6148641a08d81a6e0953b541249c7 upstream. dimm->edac_mode contains values of type enum edac_type - not the corresponding capability flags. Fix that. Fixes: 1088750d7839 ("EDAC: Add EDAC driver for DMC520") Signed-off-by: Borislav Petkov Cc: Link: https://lkml.kernel.org/r/20210916085258.7544-1-bp@alien8.de Signed-off-by: Greg Kroah-Hartman commit 9afad85a43f5d77b9b7e9ebf5306d8e47dd87b5f Author: Sai Krishna Potthuri Date: Wed Aug 18 12:53:14 2021 +0530 EDAC/synopsys: Fix wrong value type assignment for edac_mode commit 5297cfa6bdf93e3889f78f9b482e2a595a376083 upstream. dimm->edac_mode contains values of type enum edac_type - not the corresponding capability flags. Fix that. Issue caught by Coverity check "enumerated type mixed with another type." [ bp: Rewrite commit message, add tags. ] Fixes: ae9b56e3996d ("EDAC, synps: Add EDAC support for zynq ddr ecc controller") Signed-off-by: Sai Krishna Potthuri Signed-off-by: Shubhrajyoti Datta Signed-off-by: Borislav Petkov Cc: Link: https://lkml.kernel.org/r/20210818072315.15149-1-shubhrajyoti.datta@xilinx.com Signed-off-by: Greg Kroah-Hartman commit db76cb05c0466362410d74c2559d521158030aff Author: Linus Torvalds Date: Sat Sep 18 10:05:06 2021 -0700 spi: Fix tegra20 build with CONFIG_PM=n [ Upstream commit efafec27c5658ed987e720130772f8933c685e87 ] Without CONFIG_PM enabled, the SET_RUNTIME_PM_OPS() macro ends up being empty, and the only use of tegra_slink_runtime_{resume,suspend} goes away, resulting in drivers/spi/spi-tegra20-slink.c:1200:12: error: ‘tegra_slink_runtime_resume’ defined but not used [-Werror=unused-function] 1200 | static int tegra_slink_runtime_resume(struct device *dev) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/spi/spi-tegra20-slink.c:1188:12: error: ‘tegra_slink_runtime_suspend’ defined but not used [-Werror=unused-function] 1188 | static int tegra_slink_runtime_suspend(struct device *dev) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ mark the functions __maybe_unused to make the build happy. This hits the alpha allmodconfig build (and others). Reported-by: Guenter Roeck Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 890e25c424eac432ed2d4c96376b51275bd031b1 Author: Guenter Roeck Date: Wed Sep 8 20:57:43 2021 -0700 net: 6pack: Fix tx timeout and slot time [ Upstream commit 3c0d2a46c0141913dc6fd126c57d0615677d946e ] tx timeout and slot time are currently specified in units of HZ. On Alpha, HZ is defined as 1024. When building alpha:allmodconfig, this results in the following error message. drivers/net/hamradio/6pack.c: In function 'sixpack_open': drivers/net/hamradio/6pack.c:71:41: error: unsigned conversion from 'int' to 'unsigned char' changes value from '256' to '0' In the 6PACK protocol, tx timeout is specified in units of 10 ms and transmitted over the wire: https://www.linux-ax25.org/wiki/6PACK Defining a value dependent on HZ doesn't really make sense, and presumably comes from the (very historical) situation where HZ was originally 100. Note that the SIXP_SLOTTIME use explicitly is about 10ms granularity: mod_timer(&sp->tx_t, jiffies + ((when + 1) * HZ) / 100); and the SIXP_TXDELAY walue is sent as a byte over the wire. Signed-off-by: Guenter Roeck Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 044513c1fadaa29008e3122d4548f52a6b24706c Author: Guenter Roeck Date: Wed Sep 8 22:00:33 2021 -0700 alpha: Declare virt_to_phys and virt_to_bus parameter as pointer to volatile [ Upstream commit 35a3f4ef0ab543daa1725b0c963eb8c05e3376f8 ] Some drivers pass a pointer to volatile data to virt_to_bus() and virt_to_phys(), and that works fine. One exception is alpha. This results in a number of compile errors such as drivers/net/wan/lmc/lmc_main.c: In function 'lmc_softreset': drivers/net/wan/lmc/lmc_main.c:1782:50: error: passing argument 1 of 'virt_to_bus' discards 'volatile' qualifier from pointer target type drivers/atm/ambassador.c: In function 'do_loader_command': drivers/atm/ambassador.c:1747:58: error: passing argument 1 of 'virt_to_bus' discards 'volatile' qualifier from pointer target type Declare the parameter of virt_to_phys and virt_to_bus as pointer to volatile to fix the problem. Signed-off-by: Guenter Roeck Acked-by: Arnd Bergmann Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 0a511ba6d2a7e3ac2d9ec8bf28fd18ae5a762ac9 Author: Dan Li Date: Tue Sep 14 17:44:02 2021 +0800 arm64: Mark __stack_chk_guard as __ro_after_init [ Upstream commit 9fcb2e93f41c07a400885325e7dbdfceba6efaec ] __stack_chk_guard is setup once while init stage and never changed after that. Although the modification of this variable at runtime will usually cause the kernel to crash (so does the attacker), it should be marked as __ro_after_init, and it should not affect performance if it is placed in the ro_after_init section. Signed-off-by: Dan Li Acked-by: Mark Rutland Link: https://lore.kernel.org/r/1631612642-102881-1-git-send-email-ashimida@linux.alibaba.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit fec3bd622db0f116ddf2d158d8349f88970748b9 Author: Helge Deller Date: Thu Sep 16 08:35:42 2021 +0200 parisc: Use absolute_pointer() to define PAGE0 [ Upstream commit 90cc7bed1ed19f869ae7221a6b41887fe762a6a3 ] Use absolute_pointer() wrapper for PAGE0 to avoid this compiler warning: arch/parisc/kernel/setup.c: In function 'start_parisc': error: '__builtin_memcmp_eq' specified bound 8 exceeds source size 0 Signed-off-by: Helge Deller Co-Developed-by: Guenter Roeck Suggested-by: Linus Torvalds Signed-off-by: Sasha Levin commit 61454e7fd624a24e5c6f73363e66b407dcbcaf1e Author: Linus Torvalds Date: Wed Sep 15 13:56:37 2021 -0700 qnx4: avoid stringop-overread errors [ Upstream commit b7213ffa0e585feb1aee3e7173e965e66ee0abaa ] The qnx4 directory entries are 64-byte blocks that have different contents depending on the a status byte that is in the last byte of the block. In particular, a directory entry can be either a "link info" entry with a 48-byte name and pointers to the real inode information, or an "inode entry" with a smaller 16-byte name and the full inode information. But the code was written to always just treat the directory name as if it was part of that "inode entry", and just extend the name to the longer case if the status byte said it was a link entry. That work just fine and gives the right results, but now that gcc is tracking data structure accesses much more, the code can trigger a compiler error about using up to 48 bytes (the long name) in a structure that only has that shorter name in it: fs/qnx4/dir.c: In function ‘qnx4_readdir’: fs/qnx4/dir.c:51:32: error: ‘strnlen’ specified bound 48 exceeds source size 16 [-Werror=stringop-overread] 51 | size = strnlen(de->di_fname, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from fs/qnx4/qnx4.h:3, from fs/qnx4/dir.c:16: include/uapi/linux/qnx4_fs.h:45:25: note: source object declared here 45 | char di_fname[QNX4_SHORT_NAME_MAX]; | ^~~~~~~~ which is because the source code doesn't really make this whole "one of two different types" explicit. Fix this by introducing a very explicit union of the two types, and basically explaining to the compiler what is really going on. Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 5520d27f02a15831e240e14c1f1a19ea6b3f467f Author: Linus Torvalds Date: Mon Sep 6 16:06:04 2021 -0700 sparc: avoid stringop-overread errors [ Upstream commit fc7c028dcdbfe981bca75d2a7b95f363eb691ef3 ] The sparc mdesc code does pointer games with 'struct mdesc_hdr', but didn't describe to the compiler how that header is then followed by the data that the header describes. As a result, gcc is now unhappy since it does stricter pointer range tracking, and doesn't understand about how these things work. This results in various errors like: arch/sparc/kernel/mdesc.c: In function ‘mdesc_node_by_name’: arch/sparc/kernel/mdesc.c:647:22: error: ‘strcmp’ reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread] 647 | if (!strcmp(names + ep[ret].name_offset, name)) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ which are easily avoided by just describing 'struct mdesc_hdr' better, and making the node_block() helper function look into that unsized data[] that follows the header. This makes the sparc64 build happy again at least for my cross-compiler version (gcc version 11.2.1). Link: https://lore.kernel.org/lkml/CAHk-=wi4NW3NC0xWykkw=6LnjQD6D_rtRtxY9g8gQAJXtQMi8A@mail.gmail.com/ Cc: Guenter Roeck Cc: David S. Miller Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 8d768beaf0efb0709fc23f9d826072c414a75938 Author: Guenter Roeck Date: Tue Sep 14 20:52:25 2021 -0700 net: i825xx: Use absolute_pointer for memcpy from fixed memory location [ Upstream commit dff2d13114f0beec448da9b3716204eb34b0cf41 ] gcc 11.x reports the following compiler warning/error. drivers/net/ethernet/i825xx/82596.c: In function 'i82596_probe': arch/m68k/include/asm/string.h:72:25: error: '__builtin_memcpy' reading 6 bytes from a region of size 0 [-Werror=stringop-overread] Use absolute_pointer() to work around the problem. Cc: Geert Uytterhoeven Signed-off-by: Guenter Roeck Reviewed-by: Geert Uytterhoeven Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit e99f9032715e5d109f3af2105e00a8a32baa3497 Author: Guenter Roeck Date: Tue Sep 14 20:52:24 2021 -0700 compiler.h: Introduce absolute_pointer macro [ Upstream commit f6b5f1a56987de837f8e25cd560847106b8632a8 ] absolute_pointer() disassociates a pointer from its originating symbol type and context. Use it to prevent compiler warnings/errors such as drivers/net/ethernet/i825xx/82596.c: In function 'i82596_probe': arch/m68k/include/asm/string.h:72:25: error: '__builtin_memcpy' reading 6 bytes from a region of size 0 [-Werror=stringop-overread] Such warnings may be reported by gcc 11.x for string and memory operations on fixed addresses. Suggested-by: Linus Torvalds Signed-off-by: Guenter Roeck Reviewed-by: Geert Uytterhoeven Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit f58d305887ad7b24986d58e881f6806bb81b2bdf Author: Li Jinlin Date: Tue Sep 14 12:26:05 2021 +0800 blk-cgroup: fix UAF by grabbing blkcg lock before destroying blkg pd [ Upstream commit 858560b27645e7e97aca37ee8f232cccd658fbd2 ] KASAN reports a use-after-free report when doing fuzz test: [693354.104835] ================================================================== [693354.105094] BUG: KASAN: use-after-free in bfq_io_set_weight_legacy+0xd3/0x160 [693354.105336] Read of size 4 at addr ffff888be0a35664 by task sh/1453338 [693354.105607] CPU: 41 PID: 1453338 Comm: sh Kdump: loaded Not tainted 4.18.0-147 [693354.105610] Hardware name: Huawei 2288H V5/BC11SPSCB0, BIOS 0.81 07/02/2018 [693354.105612] Call Trace: [693354.105621] dump_stack+0xf1/0x19b [693354.105626] ? show_regs_print_info+0x5/0x5 [693354.105634] ? printk+0x9c/0xc3 [693354.105638] ? cpumask_weight+0x1f/0x1f [693354.105648] print_address_description+0x70/0x360 [693354.105654] kasan_report+0x1b2/0x330 [693354.105659] ? bfq_io_set_weight_legacy+0xd3/0x160 [693354.105665] ? bfq_io_set_weight_legacy+0xd3/0x160 [693354.105670] bfq_io_set_weight_legacy+0xd3/0x160 [693354.105675] ? bfq_cpd_init+0x20/0x20 [693354.105683] cgroup_file_write+0x3aa/0x510 [693354.105693] ? ___slab_alloc+0x507/0x540 [693354.105698] ? cgroup_file_poll+0x60/0x60 [693354.105702] ? 0xffffffff89600000 [693354.105708] ? usercopy_abort+0x90/0x90 [693354.105716] ? mutex_lock+0xef/0x180 [693354.105726] kernfs_fop_write+0x1ab/0x280 [693354.105732] ? cgroup_file_poll+0x60/0x60 [693354.105738] vfs_write+0xe7/0x230 [693354.105744] ksys_write+0xb0/0x140 [693354.105749] ? __ia32_sys_read+0x50/0x50 [693354.105760] do_syscall_64+0x112/0x370 [693354.105766] ? syscall_return_slowpath+0x260/0x260 [693354.105772] ? do_page_fault+0x9b/0x270 [693354.105779] ? prepare_exit_to_usermode+0xf9/0x1a0 [693354.105784] ? enter_from_user_mode+0x30/0x30 [693354.105793] entry_SYSCALL_64_after_hwframe+0x65/0xca [693354.105875] Allocated by task 1453337: [693354.106001] kasan_kmalloc+0xa0/0xd0 [693354.106006] kmem_cache_alloc_node_trace+0x108/0x220 [693354.106010] bfq_pd_alloc+0x96/0x120 [693354.106015] blkcg_activate_policy+0x1b7/0x2b0 [693354.106020] bfq_create_group_hierarchy+0x1e/0x80 [693354.106026] bfq_init_queue+0x678/0x8c0 [693354.106031] blk_mq_init_sched+0x1f8/0x460 [693354.106037] elevator_switch_mq+0xe1/0x240 [693354.106041] elevator_switch+0x25/0x40 [693354.106045] elv_iosched_store+0x1a1/0x230 [693354.106049] queue_attr_store+0x78/0xb0 [693354.106053] kernfs_fop_write+0x1ab/0x280 [693354.106056] vfs_write+0xe7/0x230 [693354.106060] ksys_write+0xb0/0x140 [693354.106064] do_syscall_64+0x112/0x370 [693354.106069] entry_SYSCALL_64_after_hwframe+0x65/0xca [693354.106114] Freed by task 1453336: [693354.106225] __kasan_slab_free+0x130/0x180 [693354.106229] kfree+0x90/0x1b0 [693354.106233] blkcg_deactivate_policy+0x12c/0x220 [693354.106238] bfq_exit_queue+0xf5/0x110 [693354.106241] blk_mq_exit_sched+0x104/0x130 [693354.106245] __elevator_exit+0x45/0x60 [693354.106249] elevator_switch_mq+0xd6/0x240 [693354.106253] elevator_switch+0x25/0x40 [693354.106257] elv_iosched_store+0x1a1/0x230 [693354.106261] queue_attr_store+0x78/0xb0 [693354.106264] kernfs_fop_write+0x1ab/0x280 [693354.106268] vfs_write+0xe7/0x230 [693354.106271] ksys_write+0xb0/0x140 [693354.106275] do_syscall_64+0x112/0x370 [693354.106280] entry_SYSCALL_64_after_hwframe+0x65/0xca [693354.106329] The buggy address belongs to the object at ffff888be0a35580 which belongs to the cache kmalloc-1k of size 1024 [693354.106736] The buggy address is located 228 bytes inside of 1024-byte region [ffff888be0a35580, ffff888be0a35980) [693354.107114] The buggy address belongs to the page: [693354.107273] page:ffffea002f828c00 count:1 mapcount:0 mapping:ffff888107c17080 index:0x0 compound_mapcount: 0 [693354.107606] flags: 0x17ffffc0008100(slab|head) [693354.107760] raw: 0017ffffc0008100 ffffea002fcbc808 ffffea0030bd3a08 ffff888107c17080 [693354.108020] raw: 0000000000000000 00000000001c001c 00000001ffffffff 0000000000000000 [693354.108278] page dumped because: kasan: bad access detected [693354.108511] Memory state around the buggy address: [693354.108671] ffff888be0a35500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [693354.116396] ffff888be0a35580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [693354.124473] >ffff888be0a35600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [693354.132421] ^ [693354.140284] ffff888be0a35680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [693354.147912] ffff888be0a35700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [693354.155281] ================================================================== blkgs are protected by both queue and blkcg locks and holding either should stabilize them. However, the path of destroying blkg policy data is only protected by queue lock in blkcg_activate_policy()/blkcg_deactivate_policy(). Other tasks can get the blkg policy data before the blkg policy data is destroyed, and use it after destroyed, which will result in a use-after-free. CPU0 CPU1 blkcg_deactivate_policy spin_lock_irq(&q->queue_lock) bfq_io_set_weight_legacy spin_lock_irq(&blkcg->lock) blkg_to_bfqg(blkg) pd_to_bfqg(blkg->pd[pol->plid]) ^^^^^^blkg->pd[pol->plid] != NULL bfqg != NULL pol->pd_free_fn(blkg->pd[pol->plid]) pd_to_bfqg(blkg->pd[pol->plid]) bfqg_put(bfqg) kfree(bfqg) blkg->pd[pol->plid] = NULL spin_unlock_irq(q->queue_lock); bfq_group_set_weight(bfqg, val, 0) bfqg->entity.new_weight ^^^^^^trigger uaf here spin_unlock_irq(&blkcg->lock); Fix by grabbing the matching blkcg lock before trying to destroy blkg policy data. Suggested-by: Tejun Heo Signed-off-by: Li Jinlin Acked-by: Tejun Heo Link: https://lore.kernel.org/r/20210914042605.3260596-1-lijinlin3@huawei.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 1ef68b84bc11befba7e20bb847ea352b46d9c28f Author: Lihong Kou Date: Tue Sep 14 09:06:56 2021 +0200 block: flush the integrity workqueue in blk_integrity_unregister [ Upstream commit 3df49967f6f1d2121b0c27c381ca1c8386b1dab9 ] When the integrity profile is unregistered there can still be integrity reads queued up which could see a NULL verify_fn as shown by the race window below: CPU0 CPU1 process_one_work nvme_validate_ns bio_integrity_verify_fn nvme_update_ns_info nvme_update_disk_info blk_integrity_unregister ---set queue->integrity as 0 bio_integrity_process --access bi->profile->verify_fn(bi is a pointer of queue->integity) Before calling blk_integrity_unregister in nvme_update_disk_info, we must make sure that there is no work item in the kintegrityd_wq. Just call blk_flush_integrity to flush the work queue so the bug can be resolved. Signed-off-by: Lihong Kou [hch: split up and shortened the changelog] Signed-off-by: Christoph Hellwig Reviewed-by: Sagi Grimberg Link: https://lore.kernel.org/r/20210914070657.87677-3-hch@lst.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 1963bdb7489cee29472b84e9cdc41b4a09a8b0d6 Author: Christoph Hellwig Date: Tue Sep 14 09:06:55 2021 +0200 block: check if a profile is actually registered in blk_integrity_unregister [ Upstream commit 783a40a1b3ac7f3714d2776fa8ac8cce3535e4f6 ] While clearing the profile itself is harmless, we really should not clear the stable writes flag if it wasn't set due to a registered integrity profile. Reported-by: Lihong Kou Signed-off-by: Christoph Hellwig Reviewed-by: Sagi Grimberg Link: https://lore.kernel.org/r/20210914070657.87677-2-hch@lst.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 526261c1b706fec0ea80ce9f14c8fe8468bee34d Author: Simon Ser Date: Tue Sep 7 14:19:34 2021 +0000 amd/display: downgrade validation failure log level [ Upstream commit 7bbee36d71502ab9a341505da89a017c7ae2e6b2 ] In amdgpu_dm_atomic_check, dc_validate_global_state is called. On failure this logs a warning to the kernel journal. However warnings shouldn't be used for atomic test-only commit failures: user-space might be perfoming a lot of atomic test-only commits to find the best hardware configuration. Downgrade the log to a regular DRM atomic message. While at it, use the new device-aware logging infrastructure. This fixes error messages in the kernel when running gamescope [1]. [1]: https://github.com/Plagman/gamescope/issues/245 Reviewed-by: Nicholas Kazlauskas Signed-off-by: Simon Ser Cc: Alex Deucher Cc: Harry Wentland Cc: Nicholas Kazlauskas Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 54a4860c6257f4575968998939952bd1aa9dcbce Author: Andreas Larsson Date: Wed Sep 8 09:48:22 2021 +0200 sparc32: page align size in arch_dma_alloc [ Upstream commit 59583f747664046aaae5588d56d5954fab66cce8 ] Commit 53b7670e5735 ("sparc: factor the dma coherent mapping into helper") lost the page align for the calls to dma_make_coherent and srmmu_unmapiorange. The latter cannot handle a non page aligned len argument. Signed-off-by: Andreas Larsson Reviewed-by: Sam Ravnborg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit ecf0dc5a904830c926a64feffd8e01141f89822f Author: Ruozhu Li Date: Mon Sep 6 11:51:34 2021 +0800 nvme-rdma: destroy cm id before destroy qp to avoid use after free [ Upstream commit 9817d763dbe15327b9b3ff4404fa6f27f927e744 ] We should always destroy cm_id before destroy qp to avoid to get cma event after qp was destroyed, which may lead to use after free. In RDMA connection establishment error flow, don't destroy qp in cm event handler.Just report cm_error to upper level, qp will be destroy in nvme_rdma_alloc_queue() after destroy cm id. Signed-off-by: Ruozhu Li Reviewed-by: Max Gurtovoy Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 2a08960577af16d6ab339dafe2373aae3df7ee22 Author: Anton Eidelman Date: Sun Sep 12 12:54:57 2021 -0600 nvme-multipath: fix ANA state updates when a namespace is not present [ Upstream commit 79f528afa93918519574773ea49a444c104bc1bd ] nvme_update_ana_state() has a deficiency that results in a failure to properly update the ana state for a namespace in the following case: NSIDs in ctrl->namespaces: 1, 3, 4 NSIDs in desc->nsids: 1, 2, 3, 4 Loop iteration 0: ns index = 0, n = 0, ns->head->ns_id = 1, nsid = 1, MATCH. Loop iteration 1: ns index = 1, n = 1, ns->head->ns_id = 3, nsid = 2, NO MATCH. Loop iteration 2: ns index = 2, n = 2, ns->head->ns_id = 4, nsid = 4, MATCH. Where the update to the ANA state of NSID 3 is missed. To fix this increment n and retry the update with the same ns when ns->head->ns_id is higher than nsid, Signed-off-by: Anton Eidelman Signed-off-by: Christoph Hellwig Reviewed-by: Sagi Grimberg Signed-off-by: Sasha Levin commit 372d3e6ea1e115942fdfb4b25f7003d822d071be Author: Juergen Gross Date: Fri Aug 27 14:32:06 2021 +0200 xen/balloon: use a kernel thread instead a workqueue [ Upstream commit 8480ed9c2bbd56fc86524998e5f2e3e22f5038f6 ] Today the Xen ballooning is done via delayed work in a workqueue. This might result in workqueue hangups being reported in case of large amounts of memory are being ballooned in one go (here 16GB): BUG: workqueue lockup - pool cpus=6 node=0 flags=0x0 nice=0 stuck for 64s! Showing busy workqueues and worker pools: workqueue events: flags=0x0 pwq 12: cpus=6 node=0 flags=0x0 nice=0 active=2/256 refcnt=3 in-flight: 229:balloon_process pending: cache_reap workqueue events_freezable_power_: flags=0x84 pwq 12: cpus=6 node=0 flags=0x0 nice=0 active=1/256 refcnt=2 pending: disk_events_workfn workqueue mm_percpu_wq: flags=0x8 pwq 12: cpus=6 node=0 flags=0x0 nice=0 active=1/256 refcnt=2 pending: vmstat_update pool 12: cpus=6 node=0 flags=0x0 nice=0 hung=64s workers=3 idle: 2222 43 This can easily be avoided by using a dedicated kernel thread for doing the ballooning work. Reported-by: Jan Beulich Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Link: https://lore.kernel.org/r/20210827123206.15429-1-jgross@suse.com Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit 6345a0bee80139ea00a341c4202ebfd1534b5eb0 Author: Bixuan Cui Date: Sat Sep 11 08:55:57 2021 +0800 bpf: Add oversize check before call kvcalloc() [ Upstream commit 0e6491b559704da720f6da09dd0a52c4df44c514 ] Commit 7661809d493b ("mm: don't allow oversized kvmalloc() calls") add the oversize check. When the allocation is larger than what kmalloc() supports, the following warning triggered: WARNING: CPU: 0 PID: 8408 at mm/util.c:597 kvmalloc_node+0x108/0x110 mm/util.c:597 Modules linked in: CPU: 0 PID: 8408 Comm: syz-executor221 Not tainted 5.14.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:kvmalloc_node+0x108/0x110 mm/util.c:597 Call Trace: kvmalloc include/linux/mm.h:806 [inline] kvmalloc_array include/linux/mm.h:824 [inline] kvcalloc include/linux/mm.h:829 [inline] check_btf_line kernel/bpf/verifier.c:9925 [inline] check_btf_info kernel/bpf/verifier.c:10049 [inline] bpf_check+0xd634/0x150d0 kernel/bpf/verifier.c:13759 bpf_prog_load kernel/bpf/syscall.c:2301 [inline] __sys_bpf+0x11181/0x126e0 kernel/bpf/syscall.c:4587 __do_sys_bpf kernel/bpf/syscall.c:4691 [inline] __se_sys_bpf kernel/bpf/syscall.c:4689 [inline] __x64_sys_bpf+0x78/0x90 kernel/bpf/syscall.c:4689 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae Reported-by: syzbot+f3e749d4c662818ae439@syzkaller.appspotmail.com Signed-off-by: Bixuan Cui Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20210911005557.45518-1-cuibixuan@huawei.com Signed-off-by: Sasha Levin commit e567d33508a9cf36b4a15fb08d697f181b8e416a Author: Doug Smythies Date: Sun Sep 12 11:50:29 2021 -0700 cpufreq: intel_pstate: Override parameters if HWP forced by BIOS [ Upstream commit d9a7e9df731670acdc69e81748941ad338f47fab ] If HWP has been already been enabled by BIOS, it may be necessary to override some kernel command line parameters. Once it has been enabled it requires a reset to be disabled. Suggested-by: Rafael J. Wysocki Signed-off-by: Doug Smythies Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 9561bb98879e45c49c18b6b54ca9f6e36393edc8 Author: zhang kai Date: Thu Sep 9 16:39:18 2021 +0800 ipv6: delay fib6_sernum increase in fib6_add [ Upstream commit e87b5052271e39d62337ade531992b7e5d8c2cfa ] only increase fib6_sernum in net namespace after add fib6_info successfully. Signed-off-by: zhang kai Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 31df1d037cfd5b259d7901a0fbbbbc897ddb64c4 Author: Guenter Roeck Date: Mon Sep 6 23:07:29 2021 -0700 m68k: Double cast io functions to unsigned long [ Upstream commit b1a89856fbf63fffde6a4771d8f1ac21df549e50 ] m68k builds fail widely with errors such as arch/m68k/include/asm/raw_io.h:20:19: error: cast to pointer from integer of different size arch/m68k/include/asm/raw_io.h:30:32: error: cast to pointer from integer of different size [-Werror=int-to-p On m68k, io functions are defined as macros. The problem is seen if the macro parameter variable size differs from the size of a pointer. Cast the parameter of all io macros to unsigned long before casting it to a pointer to fix the problem. Signed-off-by: Guenter Roeck Link: https://lore.kernel.org/r/20210907060729.2391992-1-linux@roeck-us.net Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit cc3dd119d3cf3435878b24a4a0ed21be6950573c Author: Ming Lei Date: Mon Sep 6 14:50:03 2021 +0800 blk-mq: avoid to iterate over stale request [ Upstream commit 67f3b2f822b7e71cfc9b42dbd9f3144fa2933e0b ] blk-mq can't run allocating driver tag and updating ->rqs[tag] atomically, meantime blk-mq doesn't clear ->rqs[tag] after the driver tag is released. So there is chance to iterating over one stale request just after the tag is allocated and before updating ->rqs[tag]. scsi_host_busy_iter() calls scsi_host_check_in_flight() to count scsi in-flight requests after scsi host is blocked, so no new scsi command can be marked as SCMD_STATE_INFLIGHT. However, driver tag allocation still can be run by blk-mq core. One request is marked as SCMD_STATE_INFLIGHT, but this request may have been kept in another slot of ->rqs[], meantime the slot can be allocated out but ->rqs[] isn't updated yet. Then this in-flight request is counted twice as SCMD_STATE_INFLIGHT. This way causes trouble in handling scsi error. Fixes the issue by not iterating over stale request. Cc: linux-scsi@vger.kernel.org Cc: "Martin K. Petersen" Reported-by: luojiaxing Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20210906065003.439019-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit de7e03003367958623fe1394571f29226b06eee3 Author: Jesper Nilsson Date: Fri Sep 10 21:55:34 2021 +0200 net: stmmac: allow CSR clock of 300MHz [ Upstream commit 08dad2f4d541fcfe5e7bfda72cc6314bbfd2802f ] The Synopsys Ethernet IP uses the CSR clock as a base clock for MDC. The divisor used is set in the MAC_MDIO_Address register field CR (Clock Rate) The divisor is there to change the CSR clock into a clock that falls below the IEEE 802.3 specified max frequency of 2.5MHz. If the CSR clock is 300MHz, the code falls back to using the reset value in the MAC_MDIO_Address register, as described in the comment above this code. However, 300MHz is actually an allowed value and the proper divider can be estimated quite easily (it's just 1Hz difference!) A CSR frequency of 300MHz with the maximum clock rate value of 0x5 (STMMAC_CSR_250_300M, a divisor of 124) gives somewhere around ~2.42MHz which is below the IEEE 802.3 specified maximum. For the ARTPEC-8 SoC, the CSR clock is this problematic 300MHz, and unfortunately, the reset-value of the MAC_MDIO_Address CR field is 0x0. This leads to a clock rate of zero and a divisor of 42, and gives an MDC frequency of ~7.14MHz. Allow CSR clock of 300MHz by making the comparison inclusive. Signed-off-by: Jesper Nilsson Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7721221e87d25c9840d9ca6b986dbdc410d5ce2b Author: Tong Zhang Date: Wed Sep 8 12:02:32 2021 -0700 net: macb: fix use after free on rmmod [ Upstream commit d82d5303c4c539db86588ffb5dc5b26c3f1513e8 ] plat_dev->dev->platform_data is released by platform_device_unregister(), use of pclk and hclk is a use-after-free. Since device unregister won't need a clk device we adjust the function call sequence to fix this issue. [ 31.261225] BUG: KASAN: use-after-free in macb_remove+0x77/0xc6 [macb_pci] [ 31.275563] Freed by task 306: [ 30.276782] platform_device_release+0x25/0x80 Suggested-by: Nicolas Ferre Signed-off-by: Tong Zhang Acked-by: Nicolas Ferre Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a632288053b7a00e08f12ea69507bc07922331c8 Author: Nathan Rossi Date: Thu Sep 2 05:14:49 2021 +0000 net: phylink: Update SFP selected interface on advertising changes [ Upstream commit ea269a6f720782ed94171fb962b14ce07c372138 ] Currently changes to the advertising state via ethtool do not cause any reselection of the configured interface mode after the SFP is already inserted and initially configured. While it is not typical to change the advertised link modes for an interface using an SFP in certain use cases it is desirable. In the case of a SFP port that is capable of handling both SFP and SFP+ modules it will automatically select between 1G and 10G modes depending on the supported mode of the SFP. However if the SFP module is capable of working in multiple modes (e.g. a SFP+ DAC that can operate at 1G or 10G), one end of the cable may be attached to a SFP 1000base-x port thus the SFP+ end must be manually configured to the 1000base-x mode in order for the link to be established. This change causes the ethtool setting of advertised mode changes to reselect the interface mode so that the link can be established. Additionally when a module is inserted the advertising mode is reset to match the supported modes of the module. Signed-off-by: Nathan Rossi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3815fe7371d2411ce164281cef40d9fc7b323dee Author: Zhihao Cheng Date: Thu Sep 23 21:49:21 2021 +0800 blktrace: Fix uaf in blk_trace access after removing by sysfs [ Upstream commit 5afedf670caf30a2b5a52da96eb7eac7dee6a9c9 ] There is an use-after-free problem triggered by following process: P1(sda) P2(sdb) echo 0 > /sys/block/sdb/trace/enable blk_trace_remove_queue synchronize_rcu blk_trace_free relay_close rcu_read_lock __blk_add_trace trace_note_tsk (Iterate running_trace_list) relay_close_buf relay_destroy_buf kfree(buf) trace_note(sdb's bt) relay_reserve buf->offset <- nullptr deference (use-after-free) !!! rcu_read_unlock [ 502.714379] BUG: kernel NULL pointer dereference, address: 0000000000000010 [ 502.715260] #PF: supervisor read access in kernel mode [ 502.715903] #PF: error_code(0x0000) - not-present page [ 502.716546] PGD 103984067 P4D 103984067 PUD 17592b067 PMD 0 [ 502.717252] Oops: 0000 [#1] SMP [ 502.720308] RIP: 0010:trace_note.isra.0+0x86/0x360 [ 502.732872] Call Trace: [ 502.733193] __blk_add_trace.cold+0x137/0x1a3 [ 502.733734] blk_add_trace_rq+0x7b/0xd0 [ 502.734207] blk_add_trace_rq_issue+0x54/0xa0 [ 502.734755] blk_mq_start_request+0xde/0x1b0 [ 502.735287] scsi_queue_rq+0x528/0x1140 ... [ 502.742704] sg_new_write.isra.0+0x16e/0x3e0 [ 502.747501] sg_ioctl+0x466/0x1100 Reproduce method: ioctl(/dev/sda, BLKTRACESETUP, blk_user_trace_setup[buf_size=127]) ioctl(/dev/sda, BLKTRACESTART) ioctl(/dev/sdb, BLKTRACESETUP, blk_user_trace_setup[buf_size=127]) ioctl(/dev/sdb, BLKTRACESTART) echo 0 > /sys/block/sdb/trace/enable & // Add delay(mdelay/msleep) before kernel enters blk_trace_free() ioctl$SG_IO(/dev/sda, SG_IO, ...) // Enters trace_note_tsk() after blk_trace_free() returned // Use mdelay in rcu region rather than msleep(which may schedule out) Remove blk_trace from running_list before calling blk_trace_free() by sysfs if blk_trace is at Blktrace_running state. Fixes: c71a896154119f ("blktrace: add ftrace plugin") Signed-off-by: Zhihao Cheng Link: https://lore.kernel.org/r/20210923134921.109194-1-chengzhihao1@huawei.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ce092350b452f256bff4b39d74c80c221bf8b0cf Author: Jens Axboe Date: Fri Sep 24 07:39:08 2021 -0600 io_uring: put provided buffer meta data under memcg accounting [ Upstream commit 9990da93d2bf9892c2c14c958bef050d4e461a1a ] For each provided buffer, we allocate a struct io_buffer to hold the data associated with it. As a large number of buffers can be provided, account that data with memcg. Fixes: ddf0322db79c ("io_uring: add IORING_OP_PROVIDE_BUFFERS") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 7040b37a96302be1df77d1ab62bbb978dfacb0d7 Author: Kees Cook Date: Fri Sep 10 15:33:32 2021 -0700 x86/asm: Fix SETZ size enqcmds() build failure [ Upstream commit d81ff5fe14a950f53e2833cfa196e7bb3fd5d4e3 ] When building under GCC 4.9 and 5.5: arch/x86/include/asm/special_insns.h: Assembler messages: arch/x86/include/asm/special_insns.h:286: Error: operand size mismatch for `setz' Change the type to "bool" for condition code arguments, as documented. Fixes: 7f5933f81bd8 ("x86/asm: Add an enqcmds() wrapper for the ENQCMDS instruction") Co-developed-by: Arnd Bergmann Signed-off-by: Arnd Bergmann Signed-off-by: Kees Cook Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20210910223332.3224851-1-keescook@chromium.org Signed-off-by: Sasha Levin commit 54e85b6c287c1d4862c8b5a22646ad16eabcdb2e Author: Dave Jiang Date: Thu Jan 7 09:45:21 2021 -0700 x86/asm: Add a missing __iomem annotation in enqcmds() [ Upstream commit 5c99720b28381bb400d4f546734c34ddaf608761 ] Add a missing __iomem annotation to address a sparse warning. The caller is expected to pass an __iomem annotated pointer to this function. The current usages send a 64-bytes command descriptor to an MMIO location (portal) on a device for consumption. Also, from the comment in movdir64b(), which also applies to enqcmds(), @__dst must be supplied as an lvalue because this tells the compiler what the object is (its size) the instruction accesses. I.e., not the pointers but what they point to, thus the deref'ing '*'." The actual sparse warning is: drivers/dma/idxd/submit.c: note: in included file (through arch/x86/include/asm/processor.h, \ arch/x86/include/asm/timex.h, include/linux/timex.h, include/linux/time32.h, \ include/linux/time.h, include/linux/stat.h, ...): ./arch/x86/include/asm/special_insns.h:289:41: warning: incorrect type in initializer (different address spaces) ./arch/x86/include/asm/special_insns.h:289:41: expected struct *__dst ./arch/x86/include/asm/special_insns.h:289:41: got void [noderef] __iomem *dst [ bp: Massage commit message. ] Fixes: 7f5933f81bd8 ("x86/asm: Add an enqcmds() wrapper for the ENQCMDS instruction") Reported-by: kernel test robot Signed-off-by: Dave Jiang Signed-off-by: Borislav Petkov Reviewed-by: Ben Widawsky Reviewed-by: Dan Williams Link: https://lkml.kernel.org/r/161003789741.4062451.14362269365703761223.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Sasha Levin commit b18ba3f477a2fdd12d2ca2e01d2bd874968714e2 Author: Christoph Hellwig Date: Wed Sep 1 13:38:29 2021 +0200 md: fix a lock order reversal in md_alloc [ Upstream commit 7df835a32a8bedf7ce88efcfa7c9b245b52ff139 ] Commit b0140891a8cea3 ("md: Fix race when creating a new md device.") not only moved assigning mddev->gendisk before calling add_disk, which fixes the races described in the commit log, but also added a mddev->open_mutex critical section over add_disk and creation of the md kobj. Adding a kobject after add_disk is racy vs deleting the gendisk right after adding it, but md already prevents against that by holding a mddev->active reference. On the other hand taking this lock added a lock order reversal with what is not disk->open_mutex (used to be bdev->bd_mutex when the commit was added) for partition devices, which need that lock for the internal open for the partition scan, and a recent commit also takes it for non-partitioned devices, leading to further lockdep splatter. Fixes: b0140891a8ce ("md: Fix race when creating a new md device.") Fixes: d62633873590 ("block: support delayed holder registration") Reported-by: syzbot+fadc0aaf497e6a493b9f@syzkaller.appspotmail.com Signed-off-by: Christoph Hellwig Tested-by: syzbot+fadc0aaf497e6a493b9f@syzkaller.appspotmail.com Reviewed-by: NeilBrown Signed-off-by: Song Liu Signed-off-by: Sasha Levin commit 568662e37f927e3dc3e475f3ff7cf4ab7719c5e7 Author: Kaige Fu Date: Wed Sep 15 10:20:55 2021 +0800 irqchip/gic-v3-its: Fix potential VPE leak on error [ Upstream commit 280bef512933b2dda01d681d8cbe499b98fc5bdd ] In its_vpe_irq_domain_alloc, when its_vpe_init() returns an error, there is an off-by-one in the number of VPEs to be freed. Fix it by simply passing the number of VPEs allocated, which is the index of the loop iterating over the VPEs. Fixes: 7d75bbb4bc1a ("irqchip/gic-v3-its: Add VPE irq domain allocation/teardown") Signed-off-by: Kaige Fu [maz: fixed commit message] Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/d9e36dee512e63670287ed9eff884a5d8d6d27f2.1631672311.git.kaige.fu@linux.alibaba.com Signed-off-by: Sasha Levin commit af7c9ffe2beefa1e1674836be38fd83585114d73 Author: Randy Dunlap Date: Sun Sep 5 09:25:19 2021 -0700 irqchip/goldfish-pic: Select GENERIC_IRQ_CHIP to fix build [ Upstream commit 969ac78db78c723a24e9410666b457cc1b0cb3c3 ] irq-goldfish-pic uses GENERIC_IRQ_CHIP interfaces so select that symbol to fix build errors. Fixes these build errors: mips-linux-ld: drivers/irqchip/irq-goldfish-pic.o: in function `goldfish_pic_of_init': irq-goldfish-pic.c:(.init.text+0xc0): undefined reference to `irq_alloc_generic_chip' mips-linux-ld: irq-goldfish-pic.c:(.init.text+0xf4): undefined reference to `irq_gc_unmask_enable_reg' mips-linux-ld: irq-goldfish-pic.c:(.init.text+0xf8): undefined reference to `irq_gc_unmask_enable_reg' mips-linux-ld: irq-goldfish-pic.c:(.init.text+0x100): undefined reference to `irq_gc_mask_disable_reg' mips-linux-ld: irq-goldfish-pic.c:(.init.text+0x104): undefined reference to `irq_gc_mask_disable_reg' mips-linux-ld: irq-goldfish-pic.c:(.init.text+0x11c): undefined reference to `irq_setup_generic_chip' mips-linux-ld: irq-goldfish-pic.c:(.init.text+0x168): undefined reference to `irq_remove_generic_chip' Fixes: 4235ff50cf98 ("irqchip/irq-goldfish-pic: Add Goldfish PIC driver") Signed-off-by: Randy Dunlap Reported-by: kernel test robot Cc: Miodrag Dinic Cc: Geert Uytterhoeven Cc: Bartosz Golaszewski Cc: Thomas Gleixner Cc: Marc Zyngier Cc: Goran Ferenc Cc: Aleksandar Markovic Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210905162519.21507-1-rdunlap@infradead.org Signed-off-by: Sasha Levin commit 0595fc4794c3b0ac9c88d7c609d66c71ba9811b5 Author: Dan Carpenter Date: Thu Sep 16 16:23:31 2021 +0300 scsi: lpfc: Use correct scnprintf() limit [ Upstream commit 6dacc371b77f473770ec646e220303a84fe96c11 ] The limit should be "PAGE_SIZE - len" instead of "PAGE_SIZE". We're not going to hit the limit so this fix will not affect runtime. Link: https://lore.kernel.org/r/20210916132331.GE25094@kili Fixes: 5b9e70b22cc5 ("scsi: lpfc: raise sg count for nvme to use available sg resources") Reviewed-by: James Smart Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit cb948b158a868a5c46b40e95ffafecf1eb82b589 Author: Dmitry Bogdanov Date: Wed Sep 15 18:32:39 2021 +0300 scsi: qla2xxx: Restore initiator in dual mode [ Upstream commit 5f8579038842d77e6ce05e1df6bf9dd493b0e3ef ] In dual mode in case of disabling the target, the whole port goes offline and initiator is turned off too. Fix restoring initiator mode after disabling target in dual mode. Link: https://lore.kernel.org/r/20210915153239.8035-1-d.bogdanov@yadro.com Fixes: 0645cb8350cd ("scsi: qla2xxx: Add mode control for each physical port") Reviewed-by: Himanshu Madhani Signed-off-by: Dmitry Bogdanov Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 3d42ed6b790555c02483545865696d7443eca9b7 Author: Dan Carpenter Date: Tue Sep 21 23:33:35 2021 +0300 cifs: fix a sign extension bug [ Upstream commit e946d3c887a9dc33aa82a349c6284f4a084163f4 ] The problem is the mismatched types between "ctx->total_len" which is an unsigned int, "rc" which is an int, and "ctx->rc" which is a ssize_t. The code does: ctx->rc = (rc == 0) ? ctx->total_len : rc; We want "ctx->rc" to store the negative "rc" error code. But what happens is that "rc" is type promoted to a high unsigned int and 'ctx->rc" will store the high positive value instead of a negative value. The fix is to change "rc" from an int to a ssize_t. Fixes: c610c4b619e5 ("CIFS: Add asynchronous write support through kernel AIO") Signed-off-by: Dan Carpenter Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 8cba4c2698e282aa03948b74ebc259925c873402 Author: Dan Carpenter Date: Thu Sep 16 16:13:42 2021 +0300 thermal/core: Potential buffer overflow in thermal_build_list_of_policies() [ Upstream commit 1bb30b20b49773369c299d4d6c65227201328663 ] After printing the list of thermal governors, then this function prints a newline character. The problem is that "size" has not been updated after printing the last governor. This means that it can write one character (the NUL terminator) beyond the end of the buffer. Get rid of the "size" variable and just use "PAGE_SIZE - count" directly. Fixes: 1b4f48494eb2 ("thermal: core: group functions related to governor handling") Signed-off-by: Dan Carpenter Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210916131342.GB25094@kili Signed-off-by: Sasha Levin commit 215df4349916a62a03b1899ded08e7a9d2d40480 Author: Christoph Hellwig Date: Tue Sep 14 08:38:20 2021 +0200 nvme: keep ctrl->namespaces ordered [ Upstream commit 298ba0e3d4af539cc37f982d4c011a0f07fca48c ] Various places in the nvme code that rely on ctrl->namespace to be ordered. Ensure that the namespae is inserted into the list at the right position from the start instead of sorting it after the fact. Fixes: 540c801c65eb ("NVMe: Implement namespace list scanning") Reported-by: Anton Eidelman Signed-off-by: Christoph Hellwig Reviewed-by: Keith Busch Reviewed-by: Sagi Grimberg Reviewed-by: Chaitanya Kulkarni Reviewed-by: Damien Le Moal Signed-off-by: Sasha Levin commit 55e6f8b3c0f5cc600df12ddd0371d2703b910fd7 Author: Sami Tolvanen Date: Thu Apr 8 11:28:34 2021 -0700 treewide: Change list_sort to use const pointers [ Upstream commit 4f0f586bf0c898233d8f316f471a21db2abd522d ] list_sort() internally casts the comparison function passed to it to a different type with constant struct list_head pointers, and uses this pointer to call the functions, which trips indirect call Control-Flow Integrity (CFI) checking. Instead of removing the consts, this change defines the list_cmp_func_t type and changes the comparison function types of all list_sort() callers to use const pointers, thus avoiding type mismatches. Suggested-by: Nick Desaulniers Signed-off-by: Sami Tolvanen Reviewed-by: Nick Desaulniers Reviewed-by: Christoph Hellwig Reviewed-by: Kees Cook Tested-by: Nick Desaulniers Tested-by: Nathan Chancellor Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20210408182843.1754385-10-samitolvanen@google.com Signed-off-by: Sasha Levin commit 419fab1cb0861c0220e31aa09ca6f9297704a492 Author: Sagi Grimberg Date: Tue Sep 14 18:38:55 2021 +0300 nvme-tcp: fix incorrect h2cdata pdu offset accounting [ Upstream commit e371af033c560b9dd1e861f8f0b503142bf0a06c ] When the controller sends us multiple r2t PDUs in a single request we need to account for it correctly as our send/recv context run concurrently (i.e. we get a new r2t with r2t_offset before we updated our iterator and req->data_sent marker). This can cause wrong offsets to be sent to the controller. To fix that, we will first know that this may happen only in the send sequence of the last page, hence we will take the r2t_offset to the h2c PDU data_offset, and in nvme_tcp_try_send_data loop, we make sure to increment the request markers also when we completed a PDU but we are expecting more r2t PDUs as we still did not send the entire data of the request. Fixes: 825619b09ad3 ("nvme-tcp: fix possible use-after-completion") Reported-by: Nowak, Lukasz Tested-by: Nowak, Lukasz Signed-off-by: Sagi Grimberg Reviewed-by: Keith Busch Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit c6ecdcba9da3416030cfc9376dce83ec0d21cef0 Author: Jiapeng Chong Date: Fri Aug 13 14:40:42 2021 +0800 fpga: machxo2-spi: Fix missing error code in machxo2_write_complete() [ Upstream commit a1e4470823d99e75b596748086e120dea169ed3c ] The error code is missing in this code scenario, add the error code '-EINVAL' to the return value 'ret'. Eliminate the follow smatch warning: drivers/fpga/machxo2-spi.c:341 machxo2_write_complete() warn: missing error code 'ret'. [mdf@kernel.org: Reworded commit message] Fixes: 88fb3a002330 ("fpga: lattice machxo2: Add Lattice MachXO2 support") Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong Signed-off-by: Moritz Fischer Signed-off-by: Sasha Levin commit 5c6bfde245d82a5ccd27d7f4a720d8222ba943ee Author: Tom Rix Date: Tue Aug 10 09:40:36 2021 -0700 fpga: machxo2-spi: Return an error on failure [ Upstream commit 34331739e19fd6a293d488add28832ad49c9fc54 ] Earlier successes leave 'ret' in a non error state, so these errors are not reported. Set ret to -EINVAL before going to the error handler. This addresses two issues reported by smatch: drivers/fpga/machxo2-spi.c:229 machxo2_write_init() warn: missing error code 'ret' drivers/fpga/machxo2-spi.c:316 machxo2_write_complete() warn: missing error code 'ret' [mdf@kernel.org: Reworded commit message] Fixes: 88fb3a002330 ("fpga: lattice machxo2: Add Lattice MachXO2 support") Reported-by: Dan Carpenter Signed-off-by: Tom Rix Signed-off-by: Moritz Fischer Signed-off-by: Sasha Levin commit 4ea4925c70fd55511e39cda5f3e9b47628435dfc Author: Randy Dunlap Date: Wed Sep 1 17:38:06 2021 -0700 tty: synclink_gt: rename a conflicting function name [ Upstream commit 06e49073dfba24df4b1073a068631b13a0039c34 ] 'set_signals()' in synclink_gt.c conflicts with an exported symbol in arch/um/, so change set_signals() to set_gtsignals(). Keep the function names similar by also changing get_signals() to get_gtsignals(). ../drivers/tty/synclink_gt.c:442:13: error: conflicting types for ‘set_signals’ static void set_signals(struct slgt_info *info); ^~~~~~~~~~~ In file included from ../include/linux/irqflags.h:16:0, from ../include/linux/spinlock.h:58, from ../include/linux/mm_types.h:9, from ../include/linux/buildid.h:5, from ../include/linux/module.h:14, from ../drivers/tty/synclink_gt.c:46: ../arch/um/include/asm/irqflags.h:6:5: note: previous declaration of ‘set_signals’ was here int set_signals(int enable); ^~~~~~~~~~~ Fixes: 705b6c7b34f2 ("[PATCH] new driver synclink_gt") Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: Paul Fulghum Signed-off-by: Randy Dunlap Link: https://lore.kernel.org/r/20210902003806.17054-1-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 56a8f0b18f46fe505f5175f71135192f67561f05 Author: Jiri Slaby Date: Tue Mar 2 07:22:09 2021 +0100 tty: synclink_gt, drop unneeded forward declarations [ Upstream commit b9b90fe655c0bd816847ac1bcbf179cfa2981ecb ] Forward declarations make the code larger and rewrites harder. Harder as they are often omitted from global changes. Remove forward declarations which are not really needed, i.e. the definition of the function is before its first use. Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20210302062214.29627-39-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c64e6c307a7666b852cedf2848f9506926eb791d Author: Maurizio Lombardi Date: Mon Sep 6 17:18:09 2021 +0200 scsi: target: Fix the pgr/alua_support_store functions [ Upstream commit ef7ae7f746e95c6fa4ec2bcfacb949c36263da78 ] Commit 356ba2a8bc8d ("scsi: target: tcmu: Make pgr_support and alua_support attributes writable") introduced support for changeable alua_support and pgr_support target attributes. These can only be changed if the backstore is user-backed, otherwise the kernel returns -EINVAL. This triggers a warning in the targetcli/rtslib code when performing a target restore that includes non-userbacked backstores: # targetctl restore Storage Object block/storage1: Cannot set attribute alua_support: [Errno 22] Invalid argument, skipped Storage Object block/storage1: Cannot set attribute pgr_support: [Errno 22] Invalid argument, skipped Fix this warning by returning an error code only if we are really going to flip the PGR/ALUA bit in the transport_flags field, otherwise we will do nothing and return success. Return ENOSYS instead of EINVAL if the pgr/alua attributes can not be changed, this way it will be possible for userspace to understand if the operation failed because an invalid value has been passed to strtobool() or because the attributes are fixed. Fixes: 356ba2a8bc8d ("scsi: target: tcmu: Make pgr_support and alua_support attributes writable") Link: https://lore.kernel.org/r/20210906151809.52811-1-mlombard@redhat.com Reviewed-by: Bodo Stroesser Signed-off-by: Maurizio Lombardi Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 2d03054251791d238afccb65def48bab61e7f035 Author: Baokun Li Date: Wed Sep 1 16:53:36 2021 +0800 scsi: iscsi: Adjust iface sysfs attr detection [ Upstream commit 4e28550829258f7dab97383acaa477bd724c0ff4 ] ISCSI_NET_PARAM_IFACE_ENABLE belongs to enum iscsi_net_param instead of iscsi_iface_param so move it to ISCSI_NET_PARAM. Otherwise, when we call into the driver, we might not match and return that we don't want attr visible in sysfs. Found in code review. Link: https://lore.kernel.org/r/20210901085336.2264295-1-libaokun1@huawei.com Fixes: e746f3451ec7 ("scsi: iscsi: Fix iface sysfs attr detection") Reviewed-by: Lee Duncan Signed-off-by: Baokun Li Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 0032f8b3cf2a740ded49efbd649c8c2b956beed7 Author: Sudarsana Reddy Kalluru Date: Thu Sep 23 03:16:05 2021 -0700 atlantic: Fix issue in the pm resume flow. [ Upstream commit 4d88c339c423eefe2fd48215016cb0c75fcb4c4d ] After fixing hibernation resume flow, another usecase was found which should be explicitly handled - resume when device is in "down" state. Invoke aq_nic_init jointly with aq_nic_start only if ndev was already up during suspend/hibernate. We still need to perform nic_deinit() if caller requests for it, to handle the freeze/resume scenarios. Fixes: 57f780f1c433 ("atlantic: Fix driver resume flow.") Signed-off-by: Sudarsana Reddy Kalluru Signed-off-by: Igor Russkikh Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c2598bce4152516c329934e1bfc192ce0df01a75 Author: Aya Levin Date: Thu Sep 23 09:51:45 2021 +0300 net/mlx4_en: Don't allow aRFS for encapsulated packets [ Upstream commit fdbccea419dc782079ce5881d2705cc9e3881480 ] Driver doesn't support aRFS for encapsulated packets, return early error in such a case. Fixes: 1eb8c695bda9 ("net/mlx4_en: Add accelerated RFS support") Signed-off-by: Aya Levin Signed-off-by: Tariq Toukan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b4e54f5f4288e444fb90df36659f1280c77af7ac Author: Shai Malin Date: Wed Sep 22 13:53:26 2021 +0300 qed: rdma - don't wait for resources under hw error recovery flow [ Upstream commit 1ea7812326004afd2803cc968a4776ae5120a597 ] If the HW device is during recovery, the HW resources will never return, hence we shouldn't wait for the CID (HW context ID) bitmaps to clear. This fix speeds up the error recovery flow. Fixes: 64515dc899df ("qed: Add infrastructure for error detection and recovery") Signed-off-by: Michal Kalderon Signed-off-by: Ariel Elior Signed-off-by: Shai Malin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1bba406c07b3cb008ba0456ec589b6aa46d8a830 Author: Kunihiko Hayashi Date: Thu Sep 16 20:19:35 2021 +0900 gpio: uniphier: Fix void functions to remove return value [ Upstream commit 2dd824cca3407bc9a2bd11b00f6e117b66fcfcf1 ] The return type of irq_chip.irq_mask() and irq_chip.irq_unmask() should be void. Fixes: dbe776c2ca54 ("gpio: uniphier: add UniPhier GPIO controller driver") Signed-off-by: Kunihiko Hayashi Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit db94f89e1dadf693c15c2d60de0c34777cea5779 Author: Julian Wiedmann Date: Tue Sep 21 16:52:15 2021 +0200 s390/qeth: fix NULL deref in qeth_clear_working_pool_list() [ Upstream commit 248f064af222a1f97ee02c84a98013dfbccad386 ] When qeth_set_online() calls qeth_clear_working_pool_list() to roll back after an error exit from qeth_hardsetup_card(), we are at risk of accessing card->qdio.in_q before it was allocated by qeth_alloc_qdio_queues() via qeth_mpc_initialize(). qeth_clear_working_pool_list() then dereferences NULL, and by writing to queue->bufs[i].pool_entry scribbles all over the CPU's lowcore. Resulting in a crash when those lowcore areas are used next (eg. on the next machine-check interrupt). Such a scenario would typically happen when the device is first set online and its queues aren't allocated yet. An early IO error or certain misconfigs (eg. mismatched transport mode, bad portno) then cause us to error out from qeth_hardsetup_card() with card->qdio.in_q still being NULL. Fix it by checking the pointer for NULL before accessing it. Note that we also have (rare) paths inside qeth_mpc_initialize() where a configuration change can cause us to free the existing queues, expecting that subsequent code will allocate them again. If we then error out before that re-allocation happens, the same bug occurs. Fixes: eff73e16ee11 ("s390/qeth: tolerate pre-filled RX buffer") Reported-by: Stefan Raspl Root-caused-by: Heiko Carstens Signed-off-by: Julian Wiedmann Reviewed-by: Alexandra Winter Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3aa50241e1eda27013e92d0db4f1b179e5cc33a6 Author: Cristian Marussi Date: Mon Sep 20 13:12:28 2021 +0100 kselftest/arm64: signal: Skip tests if required features are missing [ Upstream commit 0e3dbf765fe22060acbcb8eb8c4d256e655a1247 ] During initialization of a signal testcase, features declared as required are properly checked against the running system but no action is then taken to effectively skip such a testcase. Fix core signals test logic to abort initialization and report such a testcase as skipped to the KSelfTest framework. Fixes: f96bf4340316 ("kselftest: arm64: mangle_pstate_invalid_compat_toggle and common utils") Signed-off-by: Cristian Marussi Reviewed-by: Mark Brown Link: https://lore.kernel.org/r/20210920121228.35368-1-cristian.marussi@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 91d4da33c3675b23aa47bbc421af07f18058dc5a Author: Mark Brown Date: Thu Aug 19 14:42:40 2021 +0100 kselftest/arm64: signal: Add SVE to the set of features we can check for [ Upstream commit d4e4dc4fab686c5f3f185272a19b83930664bef5 ] Allow testcases for SVE signal handling to flag the dependency and be skipped on systems without SVE support. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20210819134245.13935-2-broonie@kernel.org Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 2eaa39d83e30fdaaa8f5046c32f15ca0ba480176 Author: Vladimir Oltean Date: Tue Sep 21 00:42:09 2021 +0300 net: dsa: realtek: register the MDIO bus under devres [ Upstream commit 74b6d7d13307b016f4b5bba8198297824c0ee6df ] The Linux device model permits both the ->shutdown and ->remove driver methods to get called during a shutdown procedure. Example: a DSA switch which sits on an SPI bus, and the SPI bus driver calls this on its ->shutdown method: spi_unregister_controller -> device_for_each_child(&ctlr->dev, NULL, __unregister); -> spi_unregister_device(to_spi_device(dev)); -> device_del(&spi->dev); So this is a simple pattern which can theoretically appear on any bus, although the only other buses on which I've been able to find it are I2C: i2c_del_adapter -> device_for_each_child(&adap->dev, NULL, __unregister_client); -> i2c_unregister_device(client); -> device_unregister(&client->dev); The implication of this pattern is that devices on these buses can be unregistered after having been shut down. The drivers for these devices might choose to return early either from ->remove or ->shutdown if the other callback has already run once, and they might choose that the ->shutdown method should only perform a subset of the teardown done by ->remove (to avoid unnecessary delays when rebooting). So in other words, the device driver may choose on ->remove to not do anything (therefore to not unregister an MDIO bus it has registered on ->probe), because this ->remove is actually triggered by the device_shutdown path, and its ->shutdown method has already run and done the minimally required cleanup. This used to be fine until the blamed commit, but now, the following BUG_ON triggers: void mdiobus_free(struct mii_bus *bus) { /* For compatibility with error handling in drivers. */ if (bus->state == MDIOBUS_ALLOCATED) { kfree(bus); return; } BUG_ON(bus->state != MDIOBUS_UNREGISTERED); bus->state = MDIOBUS_RELEASED; put_device(&bus->dev); } In other words, there is an attempt to free an MDIO bus which was not unregistered. The attempt to free it comes from the devres release callbacks of the SPI device, which are executed after the device is unregistered. I'm not saying that the fact that MDIO buses allocated using devres would automatically get unregistered wasn't strange. I'm just saying that the commit didn't care about auditing existing call paths in the kernel, and now, the following code sequences are potentially buggy: (a) devm_mdiobus_alloc followed by plain mdiobus_register, for a device located on a bus that unregisters its children on shutdown. After the blamed patch, either both the alloc and the register should use devres, or none should. (b) devm_mdiobus_alloc followed by plain mdiobus_register, and then no mdiobus_unregister at all in the remove path. After the blamed patch, nobody unregisters the MDIO bus anymore, so this is even more buggy than the previous case which needs a specific bus configuration to be seen, this one is an unconditional bug. In this case, the Realtek drivers fall under category (b). To solve it, we can register the MDIO bus under devres too, which restores the previous behavior. Fixes: ac3a68d56651 ("net: phy: don't abuse devres in devm_mdiobus_register()") Reported-by: Lino Sanfilippo Reported-by: Alvin Šipraga Signed-off-by: Vladimir Oltean Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 43c880b860c7a7dbc8361e2e4a124cd5337d4c5f Author: Vladimir Oltean Date: Tue Sep 21 00:42:08 2021 +0300 net: dsa: don't allocate the slave_mii_bus using devres [ Upstream commit 5135e96a3dd2f4555ae6981c3155a62bcf3227f6 ] The Linux device model permits both the ->shutdown and ->remove driver methods to get called during a shutdown procedure. Example: a DSA switch which sits on an SPI bus, and the SPI bus driver calls this on its ->shutdown method: spi_unregister_controller -> device_for_each_child(&ctlr->dev, NULL, __unregister); -> spi_unregister_device(to_spi_device(dev)); -> device_del(&spi->dev); So this is a simple pattern which can theoretically appear on any bus, although the only other buses on which I've been able to find it are I2C: i2c_del_adapter -> device_for_each_child(&adap->dev, NULL, __unregister_client); -> i2c_unregister_device(client); -> device_unregister(&client->dev); The implication of this pattern is that devices on these buses can be unregistered after having been shut down. The drivers for these devices might choose to return early either from ->remove or ->shutdown if the other callback has already run once, and they might choose that the ->shutdown method should only perform a subset of the teardown done by ->remove (to avoid unnecessary delays when rebooting). So in other words, the device driver may choose on ->remove to not do anything (therefore to not unregister an MDIO bus it has registered on ->probe), because this ->remove is actually triggered by the device_shutdown path, and its ->shutdown method has already run and done the minimally required cleanup. This used to be fine until the blamed commit, but now, the following BUG_ON triggers: void mdiobus_free(struct mii_bus *bus) { /* For compatibility with error handling in drivers. */ if (bus->state == MDIOBUS_ALLOCATED) { kfree(bus); return; } BUG_ON(bus->state != MDIOBUS_UNREGISTERED); bus->state = MDIOBUS_RELEASED; put_device(&bus->dev); } In other words, there is an attempt to free an MDIO bus which was not unregistered. The attempt to free it comes from the devres release callbacks of the SPI device, which are executed after the device is unregistered. I'm not saying that the fact that MDIO buses allocated using devres would automatically get unregistered wasn't strange. I'm just saying that the commit didn't care about auditing existing call paths in the kernel, and now, the following code sequences are potentially buggy: (a) devm_mdiobus_alloc followed by plain mdiobus_register, for a device located on a bus that unregisters its children on shutdown. After the blamed patch, either both the alloc and the register should use devres, or none should. (b) devm_mdiobus_alloc followed by plain mdiobus_register, and then no mdiobus_unregister at all in the remove path. After the blamed patch, nobody unregisters the MDIO bus anymore, so this is even more buggy than the previous case which needs a specific bus configuration to be seen, this one is an unconditional bug. In this case, DSA falls into category (a), it tries to be helpful and registers an MDIO bus on behalf of the switch, which might be on such a bus. I've no idea why it does it under devres. It does this on probe: if (!ds->slave_mii_bus && ds->ops->phy_read) alloc and register mdio bus and this on remove: if (ds->slave_mii_bus && ds->ops->phy_read) unregister mdio bus I _could_ imagine using devres because the condition used on remove is different than the condition used on probe. So strictly speaking, DSA cannot determine whether the ds->slave_mii_bus it sees on remove is the ds->slave_mii_bus that _it_ has allocated on probe. Using devres would have solved that problem. But nonetheless, the existing code already proceeds to unregister the MDIO bus, even though it might be unregistering an MDIO bus it has never registered. So I can only guess that no driver that implements ds->ops->phy_read also allocates and registers ds->slave_mii_bus itself. So in that case, if unregistering is fine, freeing must be fine too. Stop using devres and free the MDIO bus manually. This will make devres stop attempting to free a still registered MDIO bus on ->shutdown. Fixes: ac3a68d56651 ("net: phy: don't abuse devres in devm_mdiobus_register()") Reported-by: Lino Sanfilippo Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Tested-by: Lino Sanfilippo Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b4561bd29e62b24b245a53391e64b6880f0792cc Author: Karsten Graul Date: Mon Sep 20 21:18:15 2021 +0200 net/smc: fix 'workqueue leaked lock' in smc_conn_abort_work [ Upstream commit a18cee4791b1123d0a6579a7c89f4b87e48abe03 ] The abort_work is scheduled when a connection was detected to be out-of-sync after a link failure. The work calls smc_conn_kill(), which calls smc_close_active_abort() and that might end up calling smc_close_cancel_work(). smc_close_cancel_work() cancels any pending close_work and tx_work but needs to release the sock_lock before and acquires the sock_lock again afterwards. So when the sock_lock was NOT acquired before then it may be held after the abort_work completes. Thats why the sock_lock is acquired before the call to smc_conn_kill() in __smc_lgr_terminate(), but this is missing in smc_conn_abort_work(). Fix that by acquiring the sock_lock first and release it after the call to smc_conn_kill(). Fixes: b286a0651e44 ("net/smc: handle incoming CDC validation message") Signed-off-by: Karsten Graul Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8a00c832ef88651a876546be1da7bf3a6334e860 Author: Karsten Graul Date: Mon Sep 20 21:18:14 2021 +0200 net/smc: add missing error check in smc_clc_prfx_set() [ Upstream commit 6c90731980655280ea07ce4b21eb97457bf86286 ] Coverity stumbled over a missing error check in smc_clc_prfx_set(): *** CID 1475954: Error handling issues (CHECKED_RETURN) /net/smc/smc_clc.c: 233 in smc_clc_prfx_set() >>> CID 1475954: Error handling issues (CHECKED_RETURN) >>> Calling "kernel_getsockname" without checking return value (as is done elsewhere 8 out of 10 times). 233 kernel_getsockname(clcsock, (struct sockaddr *)&addrs); Add the return code check in smc_clc_prfx_set(). Fixes: c246d942eabc ("net/smc: restructure netinfo for CLC proposal msgs") Reported-by: Julian Wiedmann Signed-off-by: Karsten Graul Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4e0fd1d79534f830e247f85db0f0531fcd9d3f82 Author: Yufeng Mo Date: Wed Sep 15 21:52:09 2021 +0800 net: hns3: check queue id range before using [ Upstream commit 63b1279d9905100a14da9e043de7b28e99dba3f8 ] The input parameters may not be reliable. Before using the queue id, we should check this parameter. Otherwise, memory overwriting may occur. Fixes: d34100184685 ("net: hns3: refactor the mailbox message between PF and VF") Signed-off-by: Yufeng Mo Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ca435999bcaf572a85b369a13982928c7ca2e335 Author: Jian Shen Date: Wed Sep 15 21:52:06 2021 +0800 net: hns3: fix change RSS 'hfunc' ineffective issue [ Upstream commit e184cec5e29d8eb3c3435b12a9074b75e2d69e4a ] When user change rss 'hfunc' without set rss 'hkey' by ethtool -X command, the driver will ignore the 'hfunc' for the hkey is NULL. It's unreasonable. So fix it. Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Fixes: 374ad291762a ("net: hns3: Add RSS general configuration support for VF") Signed-off-by: Jian Shen Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1365a0dc55962f87855dfee2c18abfd6f33bb927 Author: Michael Chan Date: Mon Sep 20 02:51:52 2021 -0400 bnxt_en: Fix TX timeout when TX ring size is set to the smallest [ Upstream commit 5bed8b0704c9ecccc8f4a2c377d7c8e21090a82e ] The smallest TX ring size we support must fit a TX SKB with MAX_SKB_FRAGS + 1. Because the first TX BD for a packet is always a long TX BD, we need an extra TX BD to fit this packet. Define BNXT_MIN_TX_DESC_CNT with this value to make this more clear. The current code uses a minimum that is off by 1. Fix it using this constant. The tx_wake_thresh to determine when to wake up the TX queue is half the ring size but we must have at least BNXT_MIN_TX_DESC_CNT for the next packet which may have maximum fragments. So the comparison of the available TX BDs with tx_wake_thresh should be >= instead of > in the current code. Otherwise, at the smallest ring size, we will never wake up the TX queue and will cause TX timeout. Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.") Reviewed-by: Pavan Chebbi Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d5afe3cf52e5e18cee85e316e30f9c6621f5fbd5 Author: Claudiu Manoil Date: Fri Sep 17 13:22:06 2021 +0300 enetc: Fix uninitialized struct dim_sample field usage [ Upstream commit 9f7afa05c9522b086327929ae622facab0f0f72b ] The only struct dim_sample member that does not get initialized by dim_update_sample() is comp_ctr. (There is special API to initialize comp_ctr: dim_update_sample_with_comps(), and it is currently used only for RDMA.) comp_ctr is used to compute curr_stats->cmps and curr_stats->cpe_ratio (see dim_calc_stats()) which in turn are consumed by the rdma_dim_*() API. Therefore, functionally, the net_dim*() API consumers are not affected. Nevertheless, fix the computation of statistics based on an uninitialized variable, even if the mentioned statistics are not used at the moment. Fixes: ae0e6a5d1627 ("enetc: Add adaptive interrupt coalescing") Signed-off-by: Claudiu Manoil Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6c3f1b741c6c2914ea120e3a5790d3e900152f7b Author: Claudiu Manoil Date: Fri Sep 17 13:22:05 2021 +0300 enetc: Fix illegal access when reading affinity_hint [ Upstream commit 7237a494decfa17d0b9d0076e6cee3235719de90 ] irq_set_affinity_hit() stores a reference to the cpumask_t parameter in the irq descriptor, and that reference can be accessed later from irq_affinity_hint_proc_show(). Since the cpu_mask parameter passed to irq_set_affinity_hit() has only temporary storage (it's on the stack memory), later accesses to it are illegal. Thus reads from the corresponding procfs affinity_hint file can result in paging request oops. The issue is fixed by the get_cpu_mask() helper, which provides a permanent storage for the cpumask_t parameter. Fixes: d4fd0404c1c9 ("enetc: Introduce basic PF and VF ENETC ethernet drivers") Signed-off-by: Claudiu Manoil Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 117661cb9d3aea3cbd6a36b77e3427fcf484e215 Author: Andy Shevchenko Date: Fri Aug 27 17:53:10 2021 +0300 platform/x86/intel: punit_ipc: Drop wrong use of ACPI_PTR() [ Upstream commit 349bff48ae0f5f8aa2075d0bdc2091a30bd634f6 ] ACPI_PTR() is more harmful than helpful. For example, in this case if CONFIG_ACPI=n, the ID table left unused which is not what we want. Instead of adding ifdeffery here and there, drop ACPI_PTR() and unused acpi.h. Fixes: fdca4f16f57d ("platform:x86: add Intel P-Unit mailbox IPC driver") Reported-by: kernel test robot Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210827145310.76239-1-andriy.shevchenko@linux.intel.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 22538c1bde2793ffeac21c8bc5c22832ed838d29 Author: David Howells Date: Wed Sep 8 21:55:19 2021 +0100 afs: Fix updating of i_blocks on file/dir extension [ Upstream commit 9d37e1cab2a9d2cee2737973fa455e6f89eee46a ] When an afs file or directory is modified locally such that the total file size is extended, i_blocks needs to be recalculated too. Fix this by making afs_write_end() and afs_edit_dir_add() call afs_set_i_size() rather than setting inode->i_size directly as that also recalculates inode->i_blocks. This can be tested by creating and writing into directories and files and then examining them with du. Without this change, directories show a 4 blocks (they start out at 2048 bytes) and files show 0 blocks; with this change, they should show a number of blocks proportional to the file size rounded up to 1024. Fixes: 31143d5d515e ("AFS: implement basic file write support") Fixes: 63a4681ff39c ("afs: Locally edit directory data for mkdir/create/unlink/...") Reported-by: Markus Suvanto Signed-off-by: David Howells Reviewed-by: Marc Dionne Tested-by: Markus Suvanto cc: linux-afs@lists.infradead.org Link: https://lore.kernel.org/r/163113612442.352844.11162345591911691150.stgit@warthog.procyon.org.uk/ Signed-off-by: Sasha Levin commit 55352944b497ba567e4e5ed5c9bd0927c3f3542d Author: David Howells Date: Wed Sep 1 18:11:33 2021 +0100 afs: Fix incorrect triggering of sillyrename on 3rd-party invalidation [ Upstream commit 63d49d843ef5fffeea069e0ffdfbd2bf40ba01c6 ] The AFS filesystem is currently triggering the silly-rename cleanup from afs_d_revalidate() when it sees that a dentry has been changed by a third party[1]. It should not be doing this as the cleanup includes deleting the silly-rename target file on iput. Fix this by removing the places in the d_revalidate handling that validate anything other than the directory and the dirent. It probably should not be looking to validate the target inode of the dentry also. This includes removing the point in afs_d_revalidate() where the inode that a dentry used to point to was marked as being deleted (AFS_VNODE_DELETED). We don't know it got deleted. It could have been renamed or it could have hard links remaining. This was reproduced by cloning a git repo onto an afs volume on one machine, switching to another machine and doing "git status", then switching back to the first and doing "git status". The second status would show weird output due to ".git/index" getting deleted by the above mentioned mechanism. A simpler way to do it is to do: machine 1: touch a machine 2: touch b; mv -f b a machine 1: stat a on an afs volume. The bug shows up as the stat failing with ENOENT and the file server log showing that machine 1 deleted "a". Fixes: 79ddbfa500b3 ("afs: Implement sillyrename for unlink and rename") Reported-by: Markus Suvanto Signed-off-by: David Howells Tested-by: Markus Suvanto cc: linux-afs@lists.infradead.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=214217#c4 [1] Link: https://lore.kernel.org/r/163111668100.283156.3851669884664475428.stgit@warthog.procyon.org.uk/ Signed-off-by: Sasha Levin commit 8d6a21e4cd6a319b0662cbe4ad6199e276ac776a Author: Ian Abbott Date: Thu Sep 16 15:50:23 2021 +0100 comedi: Fix memory leak in compat_insnlist() commit bb509a6ffed2c8b0950f637ab5779aa818ed1596 upstream. `compat_insnlist()` handles the 32-bit version of the `COMEDI_INSNLIST` ioctl (whenwhen `CONFIG_COMPAT` is enabled). It allocates memory to temporarily hold an array of `struct comedi_insn` converted from the 32-bit version in user space. This memory is only being freed if there is a fault while filling the array, otherwise it is leaked. Add a call to `kfree()` to fix the leak. Fixes: b8d47d881305 ("comedi: get rid of compat_alloc_user_space() mess in COMEDI_INSNLIST compat") Cc: Al Viro Cc: Greg Kroah-Hartman Cc: linux-staging@lists.linux.dev Cc: # 5.13+ Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20210916145023.157479-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit 43241a6c6e6c7426fdb92454f9bbc66390d292d7 Author: Johan Hovold Date: Fri Sep 17 12:12:04 2021 +0200 net: hso: fix muxed tty registration commit e8f69b16ee776da88589b5271e3f46020efc8f6c upstream. If resource allocation and registration fail for a muxed tty device (e.g. if there are no more minor numbers) the driver should not try to deregister the never-registered (or already-deregistered) tty. Fix up the error handling to avoid dereferencing a NULL pointer when attempting to remove the character device. Fixes: 72dc1c096c70 ("HSO: add option hso driver") Cc: stable@vger.kernel.org # 2.6.27 Signed-off-by: Johan Hovold Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 68d4fbe6220cd1f3d07cab0a4901e62f8c12cc68 Author: Lijo Lazar Date: Thu Sep 23 11:58:43 2021 +0800 drm/amd/pm: Update intermediate power state for SI commit ab39d3cef526ba09c4c6923b4cd7e6ec1c5d4faa upstream. Update the current state as boot state during dpm initialization. During the subsequent initialization, set_power_state gets called to transition to the final power state. set_power_state refers to values from the current state and without current state populated, it could result in NULL pointer dereference. For ex: on platforms where PCI speed change is supported through ACPI ATCS method, the link speed of current state needs to be queried before deciding on changing to final power state's link speed. The logic to query ATCS-support was broken on certain platforms. The issue became visible when broken ATCS-support logic got fixed with commit f9b7f3703ff9 ("drm/amdgpu/acpi: make ATPX/ATCS structures global (v2)"). Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1698 Signed-off-by: Lijo Lazar Reviewed-by: Hawking Zhang Acked-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 7dc9225fcde003a4289ecd4314e3907e877e8c67 Author: Naohiro Aota Date: Mon Sep 6 23:06:42 2021 +0900 scsi: sd_zbc: Ensure buffer size is aligned to SECTOR_SIZE commit 7215e909814fed7cda33c954943a4050d8348204 upstream. Reporting zones on a SCSI device sometimes fail with the following error: [76248.516390] ata16.00: invalid transfer count 131328 [76248.523618] sd 15:0:0:0: [sda] REPORT ZONES start lba 536870912 failed The error (from drivers/ata/libata-scsi.c:ata_scsi_zbc_in_xlat()) indicates that buffer size is not aligned to SECTOR_SIZE. This happens when the __vmalloc() failed. Consider we are reporting 4096 zones, then we will have "bufsize = roundup((4096 + 1) * 64, SECTOR_SIZE)" = (513 * 512) = 262656. Then, __vmalloc() failure halves the bufsize to 131328, which is no longer aligned to SECTOR_SIZE. Use rounddown() to ensure the size is always aligned to SECTOR_SIZE and fix the comment as well. Link: https://lore.kernel.org/r/20210906140642.2267569-1-naohiro.aota@wdc.com Fixes: 23a50861adda ("scsi: sd_zbc: Cleanup sd_zbc_alloc_report_buffer()") Cc: stable@vger.kernel.org # 5.5+ Reviewed-by: Johannes Thumshirn Reviewed-by: Damien Le Moal Reviewed-by: Himanshu Madhani Signed-off-by: Naohiro Aota Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 3dfffcd2602937e569a90539347219fe7a7b3d45 Author: Pali Rohár Date: Sat Sep 11 15:20:17 2021 +0200 serial: mvebu-uart: fix driver's tx_empty callback commit 74e1eb3b4a1ef2e564b4bdeb6e92afe844e900de upstream. Driver's tx_empty callback should signal when the transmit shift register is empty. So when the last character has been sent. STAT_TX_FIFO_EMP bit signals only that HW transmit FIFO is empty, which happens when the last byte is loaded into transmit shift register. STAT_TX_EMP bit signals when the both HW transmit FIFO and transmit shift register are empty. So replace STAT_TX_FIFO_EMP check by STAT_TX_EMP in mvebu_uart_tx_empty() callback function. Fixes: 30530791a7a0 ("serial: mvebu-uart: initial support for Armada-3700 serial port") Cc: stable Signed-off-by: Pali Rohár Link: https://lore.kernel.org/r/20210911132017.25505-1-pali@kernel.org Signed-off-by: Greg Kroah-Hartman commit 640946fc56b85c6095295fc8686f8ba18e805dc8 Author: Nishanth Menon Date: Fri Sep 3 00:05:50 2021 -0500 serial: 8250: 8250_omap: Fix RX_LVL register offset commit 79e9e30a9292a62d25ab75488d3886108db1eaad upstream. Commit b67e830d38fa ("serial: 8250: 8250_omap: Fix possible interrupt storm on K3 SoCs") introduced fixup including a register read to RX_LVL, however, we should be using word offset than byte offset since our registers are on 4 byte boundary (port.regshift = 2) for 8250_omap. Fixes: b67e830d38fa ("serial: 8250: 8250_omap: Fix possible interrupt storm on K3 SoCs") Cc: stable Cc: Jan Kiszka Cc: Vignesh Raghavendra Signed-off-by: Nishanth Menon Link: https://lore.kernel.org/r/20210903050550.29050-1-nm@ti.com Signed-off-by: Greg Kroah-Hartman commit 0ea9ac731a315cd10bd6d6b33817b68ca9111ecf Author: Kishon Vijay Abraham I Date: Thu Sep 9 12:11:59 2021 +0530 xhci: Set HCD flag to defer primary roothub registration commit b7a0a792f864583207c593b50fd1b752ed89f4c1 upstream. Set "HCD_FLAG_DEFER_RH_REGISTER" to hcd->flags in xhci_run() to defer registering primary roothub in usb_add_hcd(). This will make sure both primary roothub and secondary roothub will be registered along with the second HCD. This is required for cold plugged USB devices to be detected in certain PCIe USB cards (like Inateck USB card connected to AM64 EVM or J7200 EVM). CC: stable@vger.kernel.org # 5.4+ Suggested-by: Mathias Nyman Tested-by: Chris Chiu Signed-off-by: Kishon Vijay Abraham I Link: https://lore.kernel.org/r/20210909064200.16216-3-kishon@ti.com Signed-off-by: Greg Kroah-Hartman commit 80af86c12290e8c567b352f01320b29161b0beaf Author: Qu Wenruo Date: Thu Sep 16 20:43:29 2021 +0800 btrfs: prevent __btrfs_dump_space_info() to underflow its free space commit 0619b7901473c380abc05d45cf9c70bee0707db3 upstream. It's not uncommon where __btrfs_dump_space_info() gets called under over-commit situations. In that case free space would underflow as total allocated space is not enough to handle all the over-committed space. Such underflow values can sometimes cause confusion for users enabled enospc_debug mount option, and takes some seconds for developers to convert the underflow value to signed result. Just output the free space as s64 to avoid such problem. Reported-by: Eli V Link: https://lore.kernel.org/linux-btrfs/CAJtFHUSy4zgyhf-4d9T+KdJp9w=UgzC2A0V=VtmaeEpcGgm1-Q@mail.gmail.com/ CC: stable@vger.kernel.org # 5.4+ Reviewed-by: Anand Jain Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 8326be9e51218d23ebe52c8d4c2d7c23302f6e44 Author: Gao Xiang Date: Tue Sep 21 22:35:30 2021 +0800 erofs: fix up erofs_lookup tracepoint commit 93368aab0efc87288cac65e99c9ed2e0ffc9e7d0 upstream. Fix up a misuse that the filename pointer isn't always valid in the ring buffer, and we should copy the content instead. Link: https://lore.kernel.org/r/20210921143531.81356-1-hsiangkao@linux.alibaba.com Fixes: 13f06f48f7bf ("staging: erofs: support tracepoint") Cc: stable@vger.kernel.org # 4.19+ Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Greg Kroah-Hartman commit 91e4ad05bf18322b5921d1a6c9b603f6eb1694f0 Author: Dan Carpenter Date: Mon Sep 6 21:35:48 2021 +0900 mcb: fix error handling in mcb_alloc_bus() commit 25a1433216489de4abc889910f744e952cb6dbae upstream. There are two bugs: 1) If ida_simple_get() fails then this code calls put_device(carrier) but we haven't yet called get_device(carrier) and probably that leads to a use after free. 2) After device_initialize() then we need to use put_device() to release the bus. This will free the internal resources tied to the device and call mcb_free_bus() which will free the rest. Fixes: 5d9e2ab9fea4 ("mcb: Implement bus->dev.release callback") Fixes: 18d288198099 ("mcb: Correctly initialize the bus's device") Cc: stable@vger.kernel.org Signed-off-by: Dan Carpenter Signed-off-by: Johannes Thumshirn Link: https://lore.kernel.org/r/32e160cf6864ce77f9d62948338e24db9fd8ead9.1630931319.git.johannes.thumshirn@wdc.com Signed-off-by: Greg Kroah-Hartman commit 2c28bb016bed842de16a8730bf96a7fe92e2a18f Author: Slark Xiao Date: Fri Sep 17 19:01:06 2021 +0800 USB: serial: option: add device id for Foxconn T99W265 commit 9e3eed534f8235a4a596a9dae5b8a6425d81ea1a upstream. Adding support for Foxconn device T99W265 for enumeration with PID 0xe0db. usb-devices output for 0xe0db T: Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 19 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 P: Vendor=0489 ProdID=e0db Rev=05.04 S: Manufacturer=Microsoft S: Product=Generic Mobile Broadband Adapter S: SerialNumber=6c50f452 C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=896mA I: If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim I: If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option I: If#=0x3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#=0x4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option if0/1: MBIM, if2:Diag, if3:GNSS, if4: Modem Signed-off-by: Slark Xiao Link: https://lore.kernel.org/r/20210917110106.9852-1-slark_xiao@163.com [ johan: use USB_DEVICE_INTERFACE_CLASS(), amend comment ] Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 600b19610ad4b68de457e4c55ca709cc7b6afc8a Author: Krzysztof Kozlowski Date: Fri Sep 17 11:18:48 2021 +0200 USB: serial: option: remove duplicate USB device ID commit 1ca200a8c6f079950a04ea3c3380fe8cf78e95a2 upstream. The device ZTE 0x0094 is already on the list. Signed-off-by: Krzysztof Kozlowski Fixes: b9e44fe5ecda ("USB: option: cleanup zte 3g-dongle's pid in option.c") Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 0daf57973ff0a1232197bca0487997774a376216 Author: Carlo Lobrano Date: Fri Sep 3 14:39:13 2021 +0200 USB: serial: option: add Telit LN920 compositions commit 7bb057134d609b9c038a00b6876cf0d37d0118ce upstream. This patch adds the following Telit LN920 compositions: 0x1060: tty, adb, rmnet, tty, tty, tty, tty 0x1061: tty, adb, mbim, tty, tty, tty, tty 0x1062: rndis, tty, adb, tty, tty, tty, tty 0x1063: tty, adb, ecm, tty, tty, tty, tty Signed-off-by: Carlo Lobrano Link: https://lore.kernel.org/r/20210903123913.1086513-1-c.lobrano@gmail.com Reviewed-by: Daniele Palmas Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit dc131d3f133510e56b8b73f7038fb9b091b71d25 Author: Krzysztof Kozlowski Date: Fri Sep 17 11:18:47 2021 +0200 USB: serial: mos7840: remove duplicated 0xac24 device ID commit 211f323768a25b30c106fd38f15a0f62c7c2b5f4 upstream. 0xac24 device ID is already defined and used via BANDB_DEVICE_ID_USO9ML2_4. Remove the duplicate from the list. Fixes: 27f1281d5f72 ("USB: serial: Extra device/vendor ID for mos7840 driver") Signed-off-by: Krzysztof Kozlowski Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit d58fc9e9c15825e3a8fc1ef3b52495c93c41e71c Author: Kishon Vijay Abraham I Date: Thu Sep 9 12:11:58 2021 +0530 usb: core: hcd: Add support for deferring roothub registration commit 58877b0824da15698bd85a0a9dbfa8c354e6ecb7 upstream. It has been observed with certain PCIe USB cards (like Inateck connected to AM64 EVM or J7200 EVM) that as soon as the primary roothub is registered, port status change is handled even before xHC is running leading to cold plug USB devices not detected. For such cases, registering both the root hubs along with the second HCD is required. Add support for deferring roothub registration in usb_add_hcd(), so that both primary and secondary roothubs are registered along with the second HCD. CC: stable@vger.kernel.org # 5.4+ Suggested-by: Mathias Nyman Tested-by: Chris Chiu Acked-by: Alan Stern Signed-off-by: Kishon Vijay Abraham I Link: https://lore.kernel.org/r/20210909064200.16216-2-kishon@ti.com Signed-off-by: Greg Kroah-Hartman commit 996f7c4a1fcf512af3502507f69e4c4760d5f9c8 Author: Li Jun Date: Wed Sep 8 10:28:19 2021 +0800 usb: dwc3: core: balance phy init and exit commit 8cfac9a6744fcb143cb3e94ce002f09fd17fadbb upstream. After we start to do core soft reset while usb role switch, the phy init is invoked at every switch to device mode, but its counter part de-init is missing, this causes the actual phy init can not be done when we really want to re-init phy like system resume, because the counter maintained by phy core is not 0. considering phy init is actually redundant for role switch, so move out the phy init from core soft reset to dwc3 core init where is the only place required. Fixes: f88359e1588b ("usb: dwc3: core: Do core softreset when switch mode") Cc: Tested-by: faqiang.zhu Tested-by: John Stultz #HiKey960 Acked-by: Felipe Balbi Signed-off-by: Li Jun Link: https://lore.kernel.org/r/1631068099-13559-1-git-send-email-jun.li@nxp.com Signed-off-by: Greg Kroah-Hartman commit a05ff800013eed8f8bb12ccc7231875821b36197 Author: Julian Sikorski Date: Mon Sep 13 20:14:55 2021 +0200 Re-enable UAS for LaCie Rugged USB3-FW with fk quirk commit ce1c42b4dacfe7d71c852d8bf3371067ccba865c upstream. Further testing has revealed that LaCie Rugged USB3-FW does work with uas as long as US_FL_NO_REPORT_OPCODES and US_FL_NO_SAME are enabled. Link: https://lore.kernel.org/linux-usb/2167ea48-e273-a336-a4e0-10a4e883e75e@redhat.com/ Cc: stable Suggested-by: Hans de Goede Reviewed-by: Hans de Goede Acked-by: Oliver Neukum Signed-off-by: Julian Sikorski Link: https://lore.kernel.org/r/20210913181454.7365-1-belegdol+github@gmail.com Signed-off-by: Greg Kroah-Hartman commit b9e697e60ce9890e9258a73eb061288e7d68e5e6 Author: Johan Hovold Date: Mon Sep 6 14:45:38 2021 +0200 staging: greybus: uart: fix tty use after free commit 92dc0b1f46e12cfabd28d709bb34f7a39431b44f upstream. User space can hold a tty open indefinitely and tty drivers must not release the underlying structures until the last user is gone. Switch to using the tty-port reference counter to manage the life time of the greybus tty state to avoid use after free after a disconnect. Fixes: a18e15175708 ("greybus: more uart work") Cc: stable@vger.kernel.org # 4.9 Reviewed-by: Alex Elder Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210906124538.22358-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit d5b0473707fa53b03a5db0256ce62b2874bddbc7 Author: Todd Kjos Date: Mon Aug 30 12:51:46 2021 -0700 binder: make sure fd closes complete commit 5fdb55c1ac9585eb23bb2541d5819224429e103d upstream. During BC_FREE_BUFFER processing, the BINDER_TYPE_FDA object cleanup may close 1 or more fds. The close operations are completed using the task work mechanism -- which means the thread needs to return to userspace or the file object may never be dereferenced -- which can lead to hung processes. Force the binder thread back to userspace if an fd is closed during BC_FREE_BUFFER handling. Fixes: 80cd795630d6 ("binder: fix use-after-free due to ksys_close() during fdget()") Cc: stable Reviewed-by: Martijn Coenen Acked-by: Christian Brauner Signed-off-by: Todd Kjos Link: https://lore.kernel.org/r/20210830195146.587206-1-tkjos@google.com Signed-off-by: Greg Kroah-Hartman commit 302e60e26ad5b1998f71bfaf622e80d9e407eea3 Author: Rafał Miłecki Date: Tue Aug 31 08:54:19 2021 +0200 Revert "USB: bcma: Add a check for devm_gpiod_get" commit d91adc5322ab53df4b6d1989242bfb6c63163eb2 upstream. This reverts commit f3de5d857bb2362b00e2a8d4bc886cd49dcb66db. That commit broke USB on all routers that have USB always powered on and don't require toggling any GPIO. It's a majority of devices actually. The original code worked and seemed safe: vcc GPIO is optional and bcma_hci_platform_power_gpio() takes care of checking the pointer before using it. This revert fixes: [ 10.801127] bcma_hcd: probe of bcma0:11 failed with error -2 Fixes: f3de5d857bb2 ("USB: bcma: Add a check for devm_gpiod_get") Cc: stable Cc: Chuhong Yuan Signed-off-by: Rafał Miłecki Link: https://lore.kernel.org/r/20210831065419.18371-1-zajec5@gmail.com Signed-off-by: Greg Kroah-Hartman commit b33b3db476e69a6e09e8e6d9197013337a282352 Author: Johan Hovold Date: Tue Sep 7 10:23:18 2021 +0200 USB: cdc-acm: fix minor-number release commit 91fac0741d4817945c6ee0a17591421e7f5ecb86 upstream. If the driver runs out of minor numbers it would release minor 0 and allow another device to claim the minor while still in use. Fortunately, registering the tty class device of the second device would fail (with a stack dump) due to the sysfs name collision so no memory is leaked. Fixes: cae2bc768d17 ("usb: cdc-acm: Decrement tty port's refcount if probe() fail") Cc: stable@vger.kernel.org # 4.19 Cc: Jaejoong Kim Acked-by: Oliver Neukum Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210907082318.7757-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 0809b8576fa860b0f168305f46aa08382eab8ec9 Author: Uwe Brandt Date: Tue Sep 21 19:54:46 2021 +0200 USB: serial: cp210x: add ID for GW Instek GDM-834x Digital Multimeter commit 3bd18ba7d859eb1fbef3beb1e80c24f6f7d7596c upstream. Add the USB serial device ID for the GW Instek GDM-834x Digital Multimeter. Signed-off-by: Uwe Brandt Link: https://lore.kernel.org/r/YUxFl3YUCPGJZd8Y@hovoldconsulting.com Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit a34d6ef0c71a15fed610fd34493a46cf54dac4e3 Author: Ondrej Zary Date: Mon Sep 13 23:01:06 2021 +0200 usb-storage: Add quirk for ScanLogic SL11R-IDE older than 2.6c commit b55d37ef6b7db3eda9b4495a8d9b0a944ee8c67d upstream. ScanLogic SL11R-IDE with firmware older than 2.6c (the latest one) has broken tag handling, preventing the device from working at all: usb 1-1: new full-speed USB device number 2 using uhci_hcd usb 1-1: New USB device found, idVendor=04ce, idProduct=0002, bcdDevice= 2.60 usb 1-1: New USB device strings: Mfr=1, Product=1, SerialNumber=0 usb 1-1: Product: USB Device usb 1-1: Manufacturer: USB Device usb-storage 1-1:1.0: USB Mass Storage device detected scsi host2: usb-storage 1-1:1.0 usbcore: registered new interface driver usb-storage usb 1-1: reset full-speed USB device number 2 using uhci_hcd usb 1-1: reset full-speed USB device number 2 using uhci_hcd usb 1-1: reset full-speed USB device number 2 using uhci_hcd usb 1-1: reset full-speed USB device number 2 using uhci_hcd Add US_FL_BULK_IGNORE_TAG to fix it. Also update my e-mail address. 2.6c is the only firmware that claims Linux compatibility. The firmware can be upgraded using ezotgdbg utility: https://github.com/asciilifeform/ezotgdbg Acked-by: Alan Stern Signed-off-by: Ondrej Zary Cc: stable Link: https://lore.kernel.org/r/20210913210106.12717-1-linux@zary.sk Signed-off-by: Greg Kroah-Hartman commit f79282849187604697b6c5944121c817a0d640e5 Author: Jan Beulich Date: Mon Sep 20 18:15:11 2021 +0200 xen/x86: fix PV trap handling on secondary processors commit 0594c58161b6e0f3da8efa9c6e3d4ba52b652717 upstream. The initial observation was that in PV mode under Xen 32-bit user space didn't work anymore. Attempts of system calls ended in #GP(0x402). All of the sudden the vector 0x80 handler was not in place anymore. As it turns out up to 5.13 redundant initialization did occur: Once from cpu_initialize_context() (through its VCPUOP_initialise hypercall) and a 2nd time while each CPU was brought fully up. This 2nd initialization is now gone, uncovering that the 1st one was flawed: Unlike for the set_trap_table hypercall, a full virtual IDT needs to be specified here; the "vector" fields of the individual entries are of no interest. With many (kernel) IDT entries still(?) (i.e. at that point at least) empty, the syscall vector 0x80 ended up in slot 0x20 of the virtual IDT, thus becoming the domain's handler for vector 0x20. Make xen_convert_trap_info() fit for either purpose, leveraging the fact that on the xen_copy_trap_info() path the table starts out zero-filled. This includes moving out the writing of the sentinel, which would also have lead to a buffer overrun in the xen_copy_trap_info() case if all (kernel) IDT entries were populated. Convert the writing of the sentinel to clearing of the entire table entry rather than just the address field. (I didn't bother trying to identify the commit which uncovered the issue in 5.14; the commit named below is the one which actually introduced the bad code.) Fixes: f87e4cac4f4e ("xen: SMP guest support") Cc: stable@vger.kernel.org Signed-off-by: Jan Beulich Reviewed-by: Boris Ostrovsky Link: https://lore.kernel.org/r/7a266932-092e-b68f-f2bb-1473b61adc6e@suse.com Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 93028da5e92dd3d80b8cbb539b23137865cbcc81 Author: Steve French Date: Thu Sep 23 19:18:37 2021 -0500 cifs: fix incorrect check for null pointer in header_assemble commit 9ed38fd4a15417cac83967360cf20b853bfab9b6 upstream. Although very unlikely that the tlink pointer would be null in this case, get_next_mid function can in theory return null (but not an error) so need to check for null (not for IS_ERR, which can not be returned here). Address warning: fs/smbfs_client/connect.c:2392 cifs_match_super() warn: 'tlink' isn't an ERR_PTR Pointed out by Dan Carpenter via smatch code analysis tool CC: stable@vger.kernel.org Reported-by: Dan Carpenter Acked-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 5940e22528df689d4b835f4daceafca4b58beaa7 Author: Dan Carpenter Date: Thu Sep 16 16:57:37 2021 +0300 usb: musb: tusb6010: uninitialized data in tusb_fifo_write_unaligned() commit 517c7bf99bad3d6b9360558414aae634b7472d80 upstream. This is writing to the first 1 - 3 bytes of "val" and then writing all four bytes to musb_writel(). The last byte is always going to be garbage. Zero out the last bytes instead. Fixes: 550a7375fe72 ("USB: Add MUSB and TUSB support") Signed-off-by: Dan Carpenter Cc: stable Link: https://lore.kernel.org/r/20210916135737.GI25094@kili Signed-off-by: Greg Kroah-Hartman commit d071c7fd45dcde9fc051e5f4de2f2fb24792279e Author: Minas Harutyunyan Date: Sat Sep 11 22:58:30 2021 +0400 usb: dwc2: gadget: Fix ISOC transfer complete handling for DDMA commit dbe2518b2d8eabffa74dbf7d9fdd7dacddab7fc0 upstream. When last descriptor in a descriptor list completed with XferComplete interrupt, core switching to handle next descriptor and assert BNA interrupt. Both these interrupts are set while dwc2_hsotg_epint() handler called. Each interrupt should be handled separately: first XferComplete interrupt then BNA interrupt, otherwise last completed transfer will not be giveback to function driver as completed request. Fixes: 729cac693eec ("usb: dwc2: Change ISOC DDMA flow") Cc: stable Signed-off-by: Minas Harutyunyan Link: https://lore.kernel.org/r/a36981accc26cd674c5d8f8da6164344b94ec1fe.1631386531.git.Minas.Harutyunyan@synopsys.com Signed-off-by: Greg Kroah-Hartman commit 5f4bfac26173e06b49d95042f766ab429ebdb0aa Author: Minas Harutyunyan Date: Thu Sep 9 14:45:15 2021 +0400 usb: dwc2: gadget: Fix ISOC flow for BDMA and Slave commit 91bb163e1e4f88092f50dfaa5a816b658753e4b2 upstream. According USB spec each ISOC transaction should be performed in a designated for that transaction interval. On bus errors or delays in operating system scheduling of client software can result in no packet being transferred for a (micro)frame. An error indication should be returned as status to the client software in such a case. Current implementation in case of missed/dropped interval send same data in next possible interval instead of reporting missed isoc. This fix complete requests with -ENODATA if interval elapsed. HSOTG core in BDMA and Slave modes haven't HW support for (micro)frames tracking, this is why SW should care about tracking of (micro)frames. Because of that method and consider operating system scheduling delays, added few additional checking's of elapsed target (micro)frame: 1. Immediately before enabling EP to start transfer. 2. With any transfer completion interrupt. 3. With incomplete isoc in/out interrupt. 4. With EP disabled interrupt because of incomplete transfer. 5. With OUT token received while EP disabled interrupt (for OUT transfers). 6. With NAK replied to IN token interrupt (for IN transfers). As part of ISOC flow, additionally fixed 'current' and 'target' frame calculation functions. In HS mode SOF limits provided by DSTS register is 0x3fff, but in non HS mode this limit is 0x7ff. Tested by internal tool which also using for dwc3 testing. Signed-off-by: Minas Harutyunyan Cc: stable Link: https://lore.kernel.org/r/95d1423adf4b0f68187c9894820c4b7e964a3f7f.1631175721.git.Minas.Harutyunyan@synopsys.com Signed-off-by: Greg Kroah-Hartman commit 1fbd7eb385c3ecdacb292e32f355e116341e23a8 Author: Dan Carpenter Date: Mon Sep 6 12:42:21 2021 +0300 usb: gadget: r8a66597: fix a loop in set_feature() commit 17956b53ebff6a490baf580a836cbd3eae94892b upstream. This loop is supposed to loop until if reads something other than CS_IDST or until it times out after 30,000 attempts. But because of the || vs && bug, it will never time out and instead it will loop a minimum of 30,000 times. This bug is quite old but the code is only used in USB_DEVICE_TEST_MODE so it probably doesn't affect regular usage. Fixes: 96fe53ef5498 ("usb: gadget: r8a66597-udc: add support for TEST_MODE") Cc: stable Reviewed-by: Yoshihiro Shimoda Acked-by: Felipe Balbi Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20210906094221.GA10957@kili Signed-off-by: Greg Kroah-Hartman commit 838297222b2b76833d144f6e5229136835856bd1 Author: Chen Jun Date: Fri Sep 24 15:44:06 2021 -0700 mm: fix uninitialized use in overcommit_policy_handler commit bcbda81020c3ee77e2c098cadf3e84f99ca3de17 upstream. We get an unexpected value of /proc/sys/vm/overcommit_memory after running the following program: int main() { int fd = open("/proc/sys/vm/overcommit_memory", O_RDWR); write(fd, "1", 1); write(fd, "2", 1); close(fd); } write(fd, "2", 1) will pass *ppos = 1 to proc_dointvec_minmax. proc_dointvec_minmax will return 0 without setting new_policy. t.data = &new_policy; ret = proc_dointvec_minmax(&t, write, buffer, lenp, ppos) -->do_proc_dointvec -->__do_proc_dointvec if (write) { if (proc_first_pos_non_zero_ignore(ppos, table)) goto out; sysctl_overcommit_memory = new_policy; so sysctl_overcommit_memory will be set to an uninitialized value. Check whether new_policy has been changed by proc_dointvec_minmax. Link: https://lkml.kernel.org/r/20210923020524.13289-1-chenjun102@huawei.com Fixes: 56f3547bfa4d ("mm: adjust vm_committed_as_batch according to vm overcommit policy") Signed-off-by: Chen Jun Acked-by: Michal Hocko Reviewed-by: Feng Tang Reviewed-by: Kefeng Wang Cc: Rui Xiang Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 437be4d6faed97a45fd67519c551a78d30b1c6d1 Author: Wengang Wang Date: Fri Sep 24 15:43:35 2021 -0700 ocfs2: drop acl cache for directories too commit 9c0f0a03e386f4e1df33db676401547e1b7800c6 upstream. ocfs2_data_convert_worker() is currently dropping any cached acl info for FILE before down-converting meta lock. It should also drop for DIRECTORY. Otherwise the second acl lookup returns the cached one (from VFS layer) which could be already stale. The problem we are seeing is that the acl changes on one node doesn't get refreshed on other nodes in the following case: Node 1 Node 2 -------------- ---------------- getfacl dir1 getfacl dir1 <-- this is OK setfacl -m u:user1:rwX dir1 getfacl dir1 <-- see the change for user1 getfacl dir1 <-- can't see change for user1 Link: https://lkml.kernel.org/r/20210903012631.6099-1-wen.gang.wang@oracle.com Signed-off-by: Wengang Wang Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Gang He Cc: Jun Piao Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 31bd6cd06a18315c9a1b4c6035d027f086c59942 Author: Pali Rohár Date: Thu Jul 22 16:40:39 2021 +0200 PCI: aardvark: Increase polling delay to 1.5s while waiting for PIO response commit 2b58db229eb617d97d5746113b77045f1f884bcb upstream. Measurements in different conditions showed that aardvark hardware PIO response can take up to 1.44s. Increase wait timeout from 1ms to 1.5s to ensure that we do not miss responses from hardware. After 1.44s hardware returns errors (e.g. Completer abort). The previous two patches fixed checking for PIO status, so now we can use it to also catch errors which are reported by hardware after 1.44s. After applying this patch, kernel can detect and print PIO errors to dmesg: [ 6.879999] advk-pcie d0070000.pcie: Non-posted PIO Response Status: CA, 0xe00 @ 0x100004 [ 6.896436] advk-pcie d0070000.pcie: Posted PIO Response Status: COMP_ERR, 0x804 @ 0x100004 [ 6.913049] advk-pcie d0070000.pcie: Posted PIO Response Status: COMP_ERR, 0x804 @ 0x100010 [ 6.929663] advk-pcie d0070000.pcie: Non-posted PIO Response Status: CA, 0xe00 @ 0x100010 [ 6.953558] advk-pcie d0070000.pcie: Posted PIO Response Status: COMP_ERR, 0x804 @ 0x100014 [ 6.970170] advk-pcie d0070000.pcie: Non-posted PIO Response Status: CA, 0xe00 @ 0x100014 [ 6.994328] advk-pcie d0070000.pcie: Posted PIO Response Status: COMP_ERR, 0x804 @ 0x100004 Without this patch kernel prints only a generic error to dmesg: [ 5.246847] advk-pcie d0070000.pcie: config read/write timed out Link: https://lore.kernel.org/r/20210722144041.12661-3-pali@kernel.org Signed-off-by: Pali Rohár Signed-off-by: Lorenzo Pieralisi Reviewed-by: Marek Behún Cc: stable@vger.kernel.org # 7fbcb5da811b ("PCI: aardvark: Don't rely on jiffies while holding spinlock") Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 5f4196eaa90c139ac470111b8e2deabf5f283baa Author: Greg Kroah-Hartman Date: Sun Sep 26 14:09:02 2021 +0200 Linux 5.10.69 Link: https://lore.kernel.org/r/20210924124334.228235870@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Fox Chen Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Salvatore Bonaccorso Link: https://lore.kernel.org/r/20210925120750.056868347@linuxfoundation.org Tested-by: Fox Chen Tested-by: Pavel Machek (CIP) Tested-by: Guenter Roeck Tested-by: Hulk Robot Signed-off-by: Greg Kroah-Hartman commit 7c09505e9e6b1461cddf7c85fdb4f4ff1cc3fd23 Author: Guenter Roeck Date: Wed Sep 8 12:08:17 2021 -0700 drm/nouveau/nvkm: Replace -ENOSYS with -ENODEV commit e8f71f89236ef82d449991bfbc237e3cb6ea584f upstream. nvkm test builds fail with the following error. drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c: In function 'nvkm_control_mthd_pstate_info': drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c:60:35: error: overflow in conversion from 'int' to '__s8' {aka 'signed char'} changes value from '-251' to '5' The code builds on most architectures, but fails on parisc where ENOSYS is defined as 251. Replace the error code with -ENODEV (-19). The actual error code does not really matter and is not passed to userspace - it just has to be negative. Fixes: 7238eca4cf18 ("drm/nouveau: expose pstate selection per-power source in sysfs") Signed-off-by: Guenter Roeck Cc: Ben Skeggs Cc: David Airlie Cc: Daniel Vetter Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 83a3cb200effb8f61d51516bd64fd94dea4c7805 Author: Sebastian Andrzej Siewior Date: Mon Sep 6 13:30:34 2021 +0200 sched/idle: Make the idle timer expire in hard interrupt context [ Upstream commit 9848417926353daa59d2b05eb26e185063dbac6e ] The intel powerclamp driver will setup a per-CPU worker with RT priority. The worker will then invoke play_idle() in which it remains in the idle poll loop until it is stopped by the timer it started earlier. That timer needs to expire in hard interrupt context on PREEMPT_RT. Otherwise the timer will expire in ksoftirqd as a SOFT timer but that task won't be scheduled on the CPU because its priority is lower than the priority of the worker which is in the idle loop. Always expire the idle timer in hard interrupt context. Reported-by: Thomas Gleixner Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20210906113034.jgfxrjdvxnjqgtmc@linutronix.de Signed-off-by: Sasha Levin commit 647c19bc61023b305389f5b027b2f7edab0feca2 Author: Yu-Tung Chang Date: Mon Aug 30 13:25:32 2021 +0800 rtc: rx8010: select REGMAP_I2C [ Upstream commit 0c45d3e24ef3d3d87c5e0077b8f38d1372af7176 ] The rtc-rx8010 uses the I2C regmap but doesn't select it in Kconfig so depending on the configuration the build may fail. Fix it. Signed-off-by: Yu-Tung Chang Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210830052532.40356-1-mtwget@gmail.com Signed-off-by: Sasha Levin commit 9a14014df72d00d87a199e1f77896f7ea62cc126 Author: Song Liu Date: Tue Sep 7 16:03:38 2021 -0700 blk-mq: allow 4x BLK_MAX_REQUEST_COUNT at blk_plug for multiple_queues [ Upstream commit 7f2a6a69f7ced6db8220298e0497cf60482a9d4b ] Limiting number of request to BLK_MAX_REQUEST_COUNT at blk_plug hurts performance for large md arrays. [1] shows resync speed of md array drops for md array with more than 16 HDDs. Fix this by allowing more request at plug queue. The multiple_queue flag is used to only apply higher limit to multiple queue cases. [1] https://lore.kernel.org/linux-raid/CAFDAVznS71BXW8Jxv6k9dXc2iR3ysX3iZRBww_rzA8WifBFxGg@mail.gmail.com/ Tested-by: Marcin Wanat Signed-off-by: Song Liu Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 23dfb959c6cbb8346a5143f44a970373fcb4ce8f Author: Li Jinlin Date: Tue Sep 7 20:12:42 2021 +0800 blk-throttle: fix UAF by deleteing timer in blk_throtl_exit() [ Upstream commit 884f0e84f1e3195b801319c8ec3d5774e9bf2710 ] The pending timer has been set up in blk_throtl_init(). However, the timer is not deleted in blk_throtl_exit(). This means that the timer handler may still be running after freeing the timer, which would result in a use-after-free. Fix by calling del_timer_sync() to delete the timer in blk_throtl_exit(). Signed-off-by: Li Jinlin Link: https://lore.kernel.org/r/20210907121242.2885564-1-lijinlin3@huawei.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a2551d0a29e937515a9711b604d88cd1a31c386f Author: Uwe Kleine-König Date: Wed Jul 7 18:27:53 2021 +0200 pwm: stm32-lp: Don't modify HW state in .remove() callback [ Upstream commit d44084c93427bb0a9261432db1a8ca76a42d805e ] A consumer is expected to disable a PWM before calling pwm_put(). And if they didn't there is hopefully a good reason (or the consumer needs fixing). Also if disabling an enabled PWM was the right thing to do, this should better be done in the framework instead of in each low level driver. Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit a6a2b36a8cc45bf9063cdc4bde7434e8eac66ecd Author: Uwe Kleine-König Date: Wed Jul 7 18:27:52 2021 +0200 pwm: rockchip: Don't modify HW state in .remove() callback [ Upstream commit 9d768cd7fd42bb0be16f36aec48548fca5260759 ] A consumer is expected to disable a PWM before calling pwm_put(). And if they didn't there is hopefully a good reason (or the consumer needs fixing). Also if disabling an enabled PWM was the right thing to do, this should better be done in the framework instead of in each low level driver. Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 0a2ea5c0e5d1076fc189f695f18f6341f58f469d Author: Uwe Kleine-König Date: Wed Jul 7 18:27:51 2021 +0200 pwm: img: Don't modify HW state in .remove() callback [ Upstream commit c68eb29c8e9067c08175dd0414f6984f236f719d ] A consumer is expected to disable a PWM before calling pwm_put(). And if they didn't there is hopefully a good reason (or the consumer needs fixing). Also if disabling an enabled PWM was the right thing to do, this should better be done in the framework instead of in each low level driver. Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit db8838e48a0a7f30bc6d4d6f0f9cd4e2f06c289f Author: Ofir Bitton Date: Tue Jul 20 09:16:05 2021 +0300 habanalabs: add validity check for event ID received from F/W [ Upstream commit a6c849012b0f51c674f52384bd9a4f3dc0a33c31 ] Currently there is no validity check for event ID received from F/W, Thus exposing driver to memory overrun. Signed-off-by: Ofir Bitton Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit d7736e2faa13b0c0b677b901044d1e21879bd314 Author: Nanyong Sun Date: Tue Sep 7 20:00:23 2021 -0700 nilfs2: fix memory leak in nilfs_sysfs_delete_snapshot_group [ Upstream commit 17243e1c3072b8417a5ebfc53065d0a87af7ca77 ] kobject_put() should be used to cleanup the memory associated with the kobject instead of kobject_del(). See the section "Kobject removal" of "Documentation/core-api/kobject.rst". Link: https://lkml.kernel.org/r/20210629022556.3985106-7-sunnanyong@huawei.com Link: https://lkml.kernel.org/r/1625651306-10829-7-git-send-email-konishi.ryusuke@gmail.com Signed-off-by: Nanyong Sun Signed-off-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 0f36028d01339976c0d3dd67f11dd99f374f2e49 Author: Nanyong Sun Date: Tue Sep 7 20:00:21 2021 -0700 nilfs2: fix memory leak in nilfs_sysfs_create_snapshot_group [ Upstream commit b2fe39c248f3fa4bbb2a20759b4fdd83504190f7 ] If kobject_init_and_add returns with error, kobject_put() is needed here to avoid memory leak, because kobject_init_and_add may return error without freeing the memory associated with the kobject it allocated. Link: https://lkml.kernel.org/r/20210629022556.3985106-6-sunnanyong@huawei.com Link: https://lkml.kernel.org/r/1625651306-10829-6-git-send-email-konishi.ryusuke@gmail.com Signed-off-by: Nanyong Sun Signed-off-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 5770b54b112e3ea252fc0547dd1fbc5af5c7e7c3 Author: Nanyong Sun Date: Tue Sep 7 20:00:18 2021 -0700 nilfs2: fix memory leak in nilfs_sysfs_delete_##name##_group [ Upstream commit a3e181259ddd61fd378390977a1e4e2316853afa ] The kobject_put() should be used to cleanup the memory associated with the kobject instead of kobject_del. See the section "Kobject removal" of "Documentation/core-api/kobject.rst". Link: https://lkml.kernel.org/r/20210629022556.3985106-5-sunnanyong@huawei.com Link: https://lkml.kernel.org/r/1625651306-10829-5-git-send-email-konishi.ryusuke@gmail.com Signed-off-by: Nanyong Sun Signed-off-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 5acb21e30d85f90b658bae7fb3f53b5e42952292 Author: Nanyong Sun Date: Tue Sep 7 20:00:15 2021 -0700 nilfs2: fix memory leak in nilfs_sysfs_create_##name##_group [ Upstream commit 24f8cb1ed057c840728167dab33b32e44147c86f ] If kobject_init_and_add return with error, kobject_put() is needed here to avoid memory leak, because kobject_init_and_add may return error without freeing the memory associated with the kobject it allocated. Link: https://lkml.kernel.org/r/20210629022556.3985106-4-sunnanyong@huawei.com Link: https://lkml.kernel.org/r/1625651306-10829-4-git-send-email-konishi.ryusuke@gmail.com Signed-off-by: Nanyong Sun Signed-off-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 0480f7a480bccdd5e747e64365b703105ccae350 Author: Nanyong Sun Date: Tue Sep 7 20:00:12 2021 -0700 nilfs2: fix NULL pointer in nilfs_##name##_attr_release [ Upstream commit dbc6e7d44a514f231a64d9d5676e001b660b6448 ] In nilfs_##name##_attr_release, kobj->parent should not be referenced because it is a NULL pointer. The release() method of kobject is always called in kobject_put(kobj), in the implementation of kobject_put(), the kobj->parent will be assigned as NULL before call the release() method. So just use kobj to get the subgroups, which is more efficient and can fix a NULL pointer reference problem. Link: https://lkml.kernel.org/r/20210629022556.3985106-3-sunnanyong@huawei.com Link: https://lkml.kernel.org/r/1625651306-10829-3-git-send-email-konishi.ryusuke@gmail.com Signed-off-by: Nanyong Sun Signed-off-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit d95b50ff07b831495a87eb47dd3a7f23eaec2a40 Author: Nanyong Sun Date: Tue Sep 7 20:00:09 2021 -0700 nilfs2: fix memory leak in nilfs_sysfs_create_device_group [ Upstream commit 5f5dec07aca7067216ed4c1342e464e7307a9197 ] Patch series "nilfs2: fix incorrect usage of kobject". This patchset from Nanyong Sun fixes memory leak issues and a NULL pointer dereference issue caused by incorrect usage of kboject in nilfs2 sysfs implementation. This patch (of 6): Reported by syzkaller: BUG: memory leak unreferenced object 0xffff888100ca8988 (size 8): comm "syz-executor.1", pid 1930, jiffies 4294745569 (age 18.052s) hex dump (first 8 bytes): 6c 6f 6f 70 31 00 ff ff loop1... backtrace: kstrdup+0x36/0x70 mm/util.c:60 kstrdup_const+0x35/0x60 mm/util.c:83 kvasprintf_const+0xf1/0x180 lib/kasprintf.c:48 kobject_set_name_vargs+0x56/0x150 lib/kobject.c:289 kobject_add_varg lib/kobject.c:384 [inline] kobject_init_and_add+0xc9/0x150 lib/kobject.c:473 nilfs_sysfs_create_device_group+0x150/0x7d0 fs/nilfs2/sysfs.c:986 init_nilfs+0xa21/0xea0 fs/nilfs2/the_nilfs.c:637 nilfs_fill_super fs/nilfs2/super.c:1046 [inline] nilfs_mount+0x7b4/0xe80 fs/nilfs2/super.c:1316 legacy_get_tree+0x105/0x210 fs/fs_context.c:592 vfs_get_tree+0x8e/0x2d0 fs/super.c:1498 do_new_mount fs/namespace.c:2905 [inline] path_mount+0xf9b/0x1990 fs/namespace.c:3235 do_mount+0xea/0x100 fs/namespace.c:3248 __do_sys_mount fs/namespace.c:3456 [inline] __se_sys_mount fs/namespace.c:3433 [inline] __x64_sys_mount+0x14b/0x1f0 fs/namespace.c:3433 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae If kobject_init_and_add return with error, then the cleanup of kobject is needed because memory may be allocated in kobject_init_and_add without freeing. And the place of cleanup_dev_kobject should use kobject_put to free the memory associated with the kobject. As the section "Kobject removal" of "Documentation/core-api/kobject.rst" says, kobject_del() just makes the kobject "invisible", but it is not cleaned up. And no more cleanup will do after cleanup_dev_kobject, so kobject_put is needed here. Link: https://lkml.kernel.org/r/1625651306-10829-1-git-send-email-konishi.ryusuke@gmail.com Link: https://lkml.kernel.org/r/1625651306-10829-2-git-send-email-konishi.ryusuke@gmail.com Reported-by: Hulk Robot Link: https://lkml.kernel.org/r/20210629022556.3985106-2-sunnanyong@huawei.com Signed-off-by: Nanyong Sun Signed-off-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit aa1af89a6697ed8f1f0d3d62029036158a4486d9 Author: Anand Jain Date: Tue Aug 31 09:21:28 2021 +0800 btrfs: fix lockdep warning while mounting sprout fs [ Upstream commit c124706900c20dee70f921bb3a90492431561a0a ] Following test case reproduces lockdep warning. Test case: $ mkfs.btrfs -f $ btrfstune -S 1 $ mount $ btrfs device add -f $ umount $ mount $ umount The warning claims a possible ABBA deadlock between the threads initiated by [#1] btrfs device add and [#0] the mount. [ 540.743122] WARNING: possible circular locking dependency detected [ 540.743129] 5.11.0-rc7+ #5 Not tainted [ 540.743135] ------------------------------------------------------ [ 540.743142] mount/2515 is trying to acquire lock: [ 540.743149] ffffa0c5544c2ce0 (&fs_devs->device_list_mutex){+.+.}-{4:4}, at: clone_fs_devices+0x6d/0x210 [btrfs] [ 540.743458] but task is already holding lock: [ 540.743461] ffffa0c54a7932b8 (btrfs-chunk-00){++++}-{4:4}, at: __btrfs_tree_read_lock+0x32/0x200 [btrfs] [ 540.743541] which lock already depends on the new lock. [ 540.743543] the existing dependency chain (in reverse order) is: [ 540.743546] -> #1 (btrfs-chunk-00){++++}-{4:4}: [ 540.743566] down_read_nested+0x48/0x2b0 [ 540.743585] __btrfs_tree_read_lock+0x32/0x200 [btrfs] [ 540.743650] btrfs_read_lock_root_node+0x70/0x200 [btrfs] [ 540.743733] btrfs_search_slot+0x6c6/0xe00 [btrfs] [ 540.743785] btrfs_update_device+0x83/0x260 [btrfs] [ 540.743849] btrfs_finish_chunk_alloc+0x13f/0x660 [btrfs] <--- device_list_mutex [ 540.743911] btrfs_create_pending_block_groups+0x18d/0x3f0 [btrfs] [ 540.743982] btrfs_commit_transaction+0x86/0x1260 [btrfs] [ 540.744037] btrfs_init_new_device+0x1600/0x1dd0 [btrfs] [ 540.744101] btrfs_ioctl+0x1c77/0x24c0 [btrfs] [ 540.744166] __x64_sys_ioctl+0xe4/0x140 [ 540.744170] do_syscall_64+0x4b/0x80 [ 540.744174] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 540.744180] -> #0 (&fs_devs->device_list_mutex){+.+.}-{4:4}: [ 540.744184] __lock_acquire+0x155f/0x2360 [ 540.744188] lock_acquire+0x10b/0x5c0 [ 540.744190] __mutex_lock+0xb1/0xf80 [ 540.744193] mutex_lock_nested+0x27/0x30 [ 540.744196] clone_fs_devices+0x6d/0x210 [btrfs] [ 540.744270] btrfs_read_chunk_tree+0x3c7/0xbb0 [btrfs] [ 540.744336] open_ctree+0xf6e/0x2074 [btrfs] [ 540.744406] btrfs_mount_root.cold.72+0x16/0x127 [btrfs] [ 540.744472] legacy_get_tree+0x38/0x90 [ 540.744475] vfs_get_tree+0x30/0x140 [ 540.744478] fc_mount+0x16/0x60 [ 540.744482] vfs_kern_mount+0x91/0x100 [ 540.744484] btrfs_mount+0x1e6/0x670 [btrfs] [ 540.744536] legacy_get_tree+0x38/0x90 [ 540.744537] vfs_get_tree+0x30/0x140 [ 540.744539] path_mount+0x8d8/0x1070 [ 540.744541] do_mount+0x8d/0xc0 [ 540.744543] __x64_sys_mount+0x125/0x160 [ 540.744545] do_syscall_64+0x4b/0x80 [ 540.744547] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 540.744551] other info that might help us debug this: [ 540.744552] Possible unsafe locking scenario: [ 540.744553] CPU0 CPU1 [ 540.744554] ---- ---- [ 540.744555] lock(btrfs-chunk-00); [ 540.744557] lock(&fs_devs->device_list_mutex); [ 540.744560] lock(btrfs-chunk-00); [ 540.744562] lock(&fs_devs->device_list_mutex); [ 540.744564] *** DEADLOCK *** [ 540.744565] 3 locks held by mount/2515: [ 540.744567] #0: ffffa0c56bf7a0e0 (&type->s_umount_key#42/1){+.+.}-{4:4}, at: alloc_super.isra.16+0xdf/0x450 [ 540.744574] #1: ffffffffc05a9628 (uuid_mutex){+.+.}-{4:4}, at: btrfs_read_chunk_tree+0x63/0xbb0 [btrfs] [ 540.744640] #2: ffffa0c54a7932b8 (btrfs-chunk-00){++++}-{4:4}, at: __btrfs_tree_read_lock+0x32/0x200 [btrfs] [ 540.744708] stack backtrace: [ 540.744712] CPU: 2 PID: 2515 Comm: mount Not tainted 5.11.0-rc7+ #5 But the device_list_mutex in clone_fs_devices() is redundant, as explained below. Two threads [1] and [2] (below) could lead to clone_fs_device(). [1] open_ctree <== mount sprout fs btrfs_read_chunk_tree() mutex_lock(&uuid_mutex) <== global lock read_one_dev() open_seed_devices() clone_fs_devices() <== seed fs_devices mutex_lock(&orig->device_list_mutex) <== seed fs_devices [2] btrfs_init_new_device() <== sprouting mutex_lock(&uuid_mutex); <== global lock btrfs_prepare_sprout() lockdep_assert_held(&uuid_mutex) clone_fs_devices(seed_fs_device) <== seed fs_devices Both of these threads hold uuid_mutex which is sufficient to protect getting the seed device(s) freed while we are trying to clone it for sprouting [2] or mounting a sprout [1] (as above). A mounted seed device can not free/write/replace because it is read-only. An unmounted seed device can be freed by btrfs_free_stale_devices(), but it needs uuid_mutex. So this patch removes the unnecessary device_list_mutex in clone_fs_devices(). And adds a lockdep_assert_held(&uuid_mutex) in clone_fs_devices(). Reported-by: Su Yue Tested-by: Su Yue Signed-off-by: Anand Jain Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit c43803c1aa76f2cc15ee641564412741a18028ff Author: Josef Bacik Date: Tue Jul 27 17:01:16 2021 -0400 btrfs: update the bdev time directly when closing [ Upstream commit 8f96a5bfa1503e0a5f3c78d51e993a1794d4aff1 ] We update the ctime/mtime of a block device when we remove it so that blkid knows the device changed. However we do this by re-opening the block device and calling filp_update_time. This is more correct because it'll call the inode->i_op->update_time if it exists, but the block dev inodes do not do this. Instead call generic_update_time() on the bd_inode in order to avoid the blkdev_open path and get rid of the following lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 5.14.0-rc2+ #406 Not tainted ------------------------------------------------------ losetup/11596 is trying to acquire lock: ffff939640d2f538 ((wq_completion)loop0){+.+.}-{0:0}, at: flush_workqueue+0x67/0x5e0 but task is already holding lock: ffff939655510c68 (&lo->lo_mutex){+.+.}-{3:3}, at: __loop_clr_fd+0x41/0x660 [loop] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 (&lo->lo_mutex){+.+.}-{3:3}: __mutex_lock+0x7d/0x750 lo_open+0x28/0x60 [loop] blkdev_get_whole+0x25/0xf0 blkdev_get_by_dev.part.0+0x168/0x3c0 blkdev_open+0xd2/0xe0 do_dentry_open+0x161/0x390 path_openat+0x3cc/0xa20 do_filp_open+0x96/0x120 do_sys_openat2+0x7b/0x130 __x64_sys_openat+0x46/0x70 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #3 (&disk->open_mutex){+.+.}-{3:3}: __mutex_lock+0x7d/0x750 blkdev_get_by_dev.part.0+0x56/0x3c0 blkdev_open+0xd2/0xe0 do_dentry_open+0x161/0x390 path_openat+0x3cc/0xa20 do_filp_open+0x96/0x120 file_open_name+0xc7/0x170 filp_open+0x2c/0x50 btrfs_scratch_superblocks.part.0+0x10f/0x170 btrfs_rm_device.cold+0xe8/0xed btrfs_ioctl+0x2a31/0x2e70 __x64_sys_ioctl+0x80/0xb0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #2 (sb_writers#12){.+.+}-{0:0}: lo_write_bvec+0xc2/0x240 [loop] loop_process_work+0x238/0xd00 [loop] process_one_work+0x26b/0x560 worker_thread+0x55/0x3c0 kthread+0x140/0x160 ret_from_fork+0x1f/0x30 -> #1 ((work_completion)(&lo->rootcg_work)){+.+.}-{0:0}: process_one_work+0x245/0x560 worker_thread+0x55/0x3c0 kthread+0x140/0x160 ret_from_fork+0x1f/0x30 -> #0 ((wq_completion)loop0){+.+.}-{0:0}: __lock_acquire+0x10ea/0x1d90 lock_acquire+0xb5/0x2b0 flush_workqueue+0x91/0x5e0 drain_workqueue+0xa0/0x110 destroy_workqueue+0x36/0x250 __loop_clr_fd+0x9a/0x660 [loop] block_ioctl+0x3f/0x50 __x64_sys_ioctl+0x80/0xb0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae other info that might help us debug this: Chain exists of: (wq_completion)loop0 --> &disk->open_mutex --> &lo->lo_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&lo->lo_mutex); lock(&disk->open_mutex); lock(&lo->lo_mutex); lock((wq_completion)loop0); *** DEADLOCK *** 1 lock held by losetup/11596: #0: ffff939655510c68 (&lo->lo_mutex){+.+.}-{3:3}, at: __loop_clr_fd+0x41/0x660 [loop] stack backtrace: CPU: 1 PID: 11596 Comm: losetup Not tainted 5.14.0-rc2+ #406 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 Call Trace: dump_stack_lvl+0x57/0x72 check_noncircular+0xcf/0xf0 ? stack_trace_save+0x3b/0x50 __lock_acquire+0x10ea/0x1d90 lock_acquire+0xb5/0x2b0 ? flush_workqueue+0x67/0x5e0 ? lockdep_init_map_type+0x47/0x220 flush_workqueue+0x91/0x5e0 ? flush_workqueue+0x67/0x5e0 ? verify_cpu+0xf0/0x100 drain_workqueue+0xa0/0x110 destroy_workqueue+0x36/0x250 __loop_clr_fd+0x9a/0x660 [loop] ? blkdev_ioctl+0x8d/0x2a0 block_ioctl+0x3f/0x50 __x64_sys_ioctl+0x80/0xb0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Reviewed-by: Anand Jain Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 921ef7cfef15a7e25511089c9941ee37c3dc9fec Author: Jeff Layton Date: Thu Sep 2 08:31:03 2021 -0400 ceph: lockdep annotations for try_nonblocking_invalidate [ Upstream commit 3eaf5aa1cfa8c97c72f5824e2e9263d6cc977b03 ] Signed-off-by: Jeff Layton Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 487ead34a208c1da9da7fc9f776b517680255ca1 Author: Xiubo Li Date: Wed Aug 25 21:45:43 2021 +0800 ceph: remove the capsnaps when removing caps [ Upstream commit a6d37ccdd240e80f26aaea0e62cda310e0e184d7 ] capsnaps will take inode references via ihold when queueing to flush. When force unmounting, the client will just close the sessions and may never get a flush reply, causing a leak and inode ref leak. Fix this by removing the capsnaps for an inode when removing the caps. URL: https://tracker.ceph.com/issues/52295 Signed-off-by: Xiubo Li Reviewed-by: Jeff Layton Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 386fd6fd01bd1ee92640f97c0d0e06e204641c9f Author: Jeff Layton Date: Wed Aug 11 06:40:42 2021 -0400 ceph: request Fw caps before updating the mtime in ceph_write_iter [ Upstream commit b11ed50346683a749632ea664959b28d524d7395 ] The current code will update the mtime and then try to get caps to handle the write. If we end up having to request caps from the MDS, then the mtime in the cap grant will clobber the updated mtime and it'll be lost. This is most noticable when two clients are alternately writing to the same file. Fw caps are continually being granted and revoked, and the mtime ends up stuck because the updated mtimes are always being overwritten with the old one. Fix this by changing the order of operations in ceph_write_iter to get the caps before updating the times. Also, make sure we check the pool full conditions before even getting any caps or uninlining. URL: https://tracker.ceph.com/issues/46574 Reported-by: Jozef Kováč Signed-off-by: Jeff Layton Reviewed-by: Xiubo Li Reviewed-by: Luis Henriques Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit b26ced26251cc26cc6c8327535687b77af0c55db Author: Radhey Shyam Pandey Date: Thu Aug 19 14:28:48 2021 +0530 dmaengine: xilinx_dma: Set DMA mask for coherent APIs [ Upstream commit aac6c0f90799d66b8989be1e056408f33fd99fe6 ] The xilinx dma driver uses the consistent allocations, so for correct operation also set the DMA mask for coherent APIs. It fixes the below kernel crash with dmatest client when DMA IP is configured with 64-bit address width and linux is booted from high (>4GB) memory. Call trace: [ 489.531257] dma_alloc_from_pool+0x8c/0x1c0 [ 489.535431] dma_direct_alloc+0x284/0x330 [ 489.539432] dma_alloc_attrs+0x80/0xf0 [ 489.543174] dma_pool_alloc+0x160/0x2c0 [ 489.547003] xilinx_cdma_prep_memcpy+0xa4/0x180 [ 489.551524] dmatest_func+0x3cc/0x114c [ 489.555266] kthread+0x124/0x130 [ 489.558486] ret_from_fork+0x10/0x3c [ 489.562051] ---[ end trace 248625b2d596a90a ]--- Signed-off-by: Radhey Shyam Pandey Reviewed-by: Harini Katakam Link: https://lore.kernel.org/r/1629363528-30347-1-git-send-email-radhey.shyam.pandey@xilinx.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 9c1ea8537730790ee183fa32379932f777c95d17 Author: Johannes Berg Date: Mon Aug 9 11:24:09 2021 +0200 dmaengine: ioat: depends on !UML [ Upstream commit bbac7a92a46f0876e588722ebe552ddfe6fd790f ] Now that UML has PCI support, this driver must depend also on !UML since it pokes at X86_64 architecture internals that don't exist on ARCH=um. Reported-by: Geert Uytterhoeven Signed-off-by: Johannes Berg Acked-by: Dave Jiang Link: https://lore.kernel.org/r/20210809112409.a3a0974874d2.I2ffe3d11ed37f735da2f39884a74c953b258b995@changeid Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 35492619e010b312d0d3fe94bbe182bce0bae5ee Author: Zou Wei Date: Tue May 4 10:22:57 2021 +0800 dmaengine: sprd: Add missing MODULE_DEVICE_TABLE [ Upstream commit 4faee8b65ec32346f8096e64c5fa1d5a73121742 ] This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by: Hulk Robot Signed-off-by: Zou Wei Reviewed-by: Baolin Wang Link: https://lore.kernel.org/r/1620094977-70146-1-git-send-email-zou_wei@huawei.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit c12cf7f9afe23eef40cb5cff5fd28a0f39745232 Author: Johannes Berg Date: Fri Jun 25 10:38:10 2021 +0200 dmaengine: idxd: depends on !UML [ Upstream commit b2296eeac91555bd13f774efa7ab7d4b12fb71ef ] Now that UML has PCI support, this driver must depend also on !UML since it pokes at X86_64 architecture internals that don't exist on ARCH=um. Reported-by: kernel test robot Signed-off-by: Johannes Berg Acked-by: Dave Jiang Acked-By: Anton Ivanov Link: https://lore.kernel.org/r/20210625103810.fe877ae0aef4.If240438e3f50ae226f3f755fc46ea498c6858393@changeid Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit b4bb0b171b6ef63474bbbcfcb0b90660c27f8fcc Author: Wei Huang Date: Fri Aug 20 15:29:55 2021 -0500 iommu/amd: Relocate GAMSup check to early_enable_iommus [ Upstream commit c3811a50addd23b9bb5a36278609ee1638debcf6 ] Currently, iommu_init_ga() checks and disables IOMMU VAPIC support (i.e. AMD AVIC support in IOMMU) when GAMSup feature bit is not set. However it forgets to clear IRQ_POSTING_CAP from the previously set amd_iommu_irq_ops.capability. This triggers an invalid page fault bug during guest VM warm reboot if AVIC is enabled since the irq_remapping_cap(IRQ_POSTING_CAP) is incorrectly set, and crash the system with the following kernel trace. BUG: unable to handle page fault for address: 0000000000400dd8 RIP: 0010:amd_iommu_deactivate_guest_mode+0x19/0xbc Call Trace: svm_set_pi_irte_mode+0x8a/0xc0 [kvm_amd] ? kvm_make_all_cpus_request_except+0x50/0x70 [kvm] kvm_request_apicv_update+0x10c/0x150 [kvm] svm_toggle_avic_for_irq_window+0x52/0x90 [kvm_amd] svm_enable_irq_window+0x26/0xa0 [kvm_amd] vcpu_enter_guest+0xbbe/0x1560 [kvm] ? avic_vcpu_load+0xd5/0x120 [kvm_amd] ? kvm_arch_vcpu_load+0x76/0x240 [kvm] ? svm_get_segment_base+0xa/0x10 [kvm_amd] kvm_arch_vcpu_ioctl_run+0x103/0x590 [kvm] kvm_vcpu_ioctl+0x22a/0x5d0 [kvm] __x64_sys_ioctl+0x84/0xc0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes by moving the initializing of AMD IOMMU interrupt remapping mode (amd_iommu_guest_ir) earlier before setting up the amd_iommu_irq_ops.capability with appropriate IRQ_POSTING_CAP flag. [joro: Squashed the two patches and limited check_features_on_all_iommus() to CONFIG_IRQ_REMAP to fix a compile warning.] Signed-off-by: Wei Huang Co-developed-by: Suravee Suthikulpanit Signed-off-by: Suravee Suthikulpanit Link: https://lore.kernel.org/r/20210820202957.187572-2-suravee.suthikulpanit@amd.com Link: https://lore.kernel.org/r/20210820202957.187572-3-suravee.suthikulpanit@amd.com Fixes: 8bda0cfbdc1a ("iommu/amd: Detect and initialize guest vAPIC log") Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 2a07348e9821d7014b27ba3cd7a27318cbc5f4c9 Author: Guenter Roeck Date: Wed Sep 8 08:30:41 2021 -0700 parisc: Move pci_dev_is_behind_card_dino to where it is used [ Upstream commit 907872baa9f1538eed02ec737b8e89eba6c6e4b9 ] parisc build test images fail to compile with the following error. drivers/parisc/dino.c:160:12: error: 'pci_dev_is_behind_card_dino' defined but not used Move the function just ahead of its only caller to avoid the error. Fixes: 5fa1659105fa ("parisc: Disable HP HSC-PCI Cards to prevent kernel crash") Cc: Helge Deller Signed-off-by: Guenter Roeck Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit ca907291e11619843ea8b555ca30cf322a8d2514 Author: Geert Uytterhoeven Date: Thu Sep 2 14:49:11 2021 +0200 dma-buf: DMABUF_MOVE_NOTIFY should depend on DMA_SHARED_BUFFER [ Upstream commit c4f3a3460a5daebc772d9263500e4099b11e7300 ] Move notify between drivers is an option of DMA-BUF. Enabling DMABUF_MOVE_NOTIFY without DMA_SHARED_BUFFER does not have any impact, as drivers/dma-buf/ is not entered during the build when DMA_SHARED_BUFFER is disabled. Fixes: bb42df4662a44765 ("dma-buf: add dynamic DMA-buf handling v15") Signed-off-by: Geert Uytterhoeven Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210902124913.2698760-2-geert@linux-m68k.org Signed-off-by: Sasha Levin commit b9a1526d51744075a6245d3f3a5544b10a5405c9 Author: Thomas Gleixner Date: Tue Aug 31 13:48:34 2021 +0200 drivers: base: cacheinfo: Get rid of DEFINE_SMP_CALL_CACHE_FUNCTION() [ Upstream commit 4b92d4add5f6dcf21275185c997d6ecb800054cd ] DEFINE_SMP_CALL_CACHE_FUNCTION() was usefel before the CPU hotplug rework to ensure that the cache related functions are called on the upcoming CPU because the notifier itself could run on any online CPU. The hotplug state machine guarantees that the callbacks are invoked on the upcoming CPU. So there is no need to have this SMP function call obfuscation. That indirection was missed when the hotplug notifiers were converted. This also solves the problem of ARM64 init_cache_level() invoking ACPI functions which take a semaphore in that context. That's invalid as SMP function calls run with interrupts disabled. Running it just from the callback in context of the CPU hotplug thread solves this. Fixes: 8571890e1513 ("arm64: Add support for ACPI based firmware tables") Reported-by: Guenter Roeck Signed-off-by: Thomas Gleixner Tested-by: Guenter Roeck Acked-by: Will Deacon Acked-by: Peter Zijlstra Link: https://lore.kernel.org/r/871r69ersb.ffs@tglx Signed-off-by: Sasha Levin commit 45bd9dd1bee8aedc4cbd409b1ba7f9b4f941eea6 Author: Koba Ko Date: Mon Aug 30 10:02:00 2021 +0800 drm/amdgpu: Disable PCIE_DPM on Intel RKL Platform [ Upstream commit b3dc549986eb7b38eba4a144e979dc93f386751f ] Due to high latency in PCIE clock switching on RKL platforms, switching the PCIE clock dynamically at runtime can lead to HDMI/DP audio problems. On newer asics this is handled in the SMU firmware. For SMU7-based asics, disable PCIE clock switching to avoid the issue. AMD provide a parameter to disable PICE_DPM. modprobe amdgpu ppfeaturemask=0xfff7bffb It's better to contorl PCIE_DPM in amd gpu driver, switch PCI_DPM by determining intel RKL platform for SMU7-based asics. Fixes: 1a31474cdb48 ("drm/amd/pm: workaround for audio noise issue") Ref: https://lists.freedesktop.org/archives/amd-gfx/2021-August/067413.html Signed-off-by: Koba Ko Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c9538018cb2d61c269c4c622131545763f24a9ee Author: Arnd Bergmann Date: Thu Jul 22 11:06:44 2021 +0200 thermal/core: Fix thermal_cooling_device_register() prototype [ Upstream commit fb83610762dd5927212aa62a468dd3b756b57a88 ] There are two pairs of declarations for thermal_cooling_device_register() and thermal_of_cooling_device_register(), and only one set was changed in a recent patch, so the other one now causes a compile-time warning: drivers/net/wireless/mediatek/mt76/mt7915/init.c: In function 'mt7915_thermal_init': drivers/net/wireless/mediatek/mt76/mt7915/init.c:134:48: error: passing argument 1 of 'thermal_cooling_device_register' discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers] 134 | cdev = thermal_cooling_device_register(wiphy_name(wiphy), phy, | ^~~~~~~~~~~~~~~~~ In file included from drivers/net/wireless/mediatek/mt76/mt7915/init.c:7: include/linux/thermal.h:407:39: note: expected 'char *' but argument is of type 'const char *' 407 | thermal_cooling_device_register(char *type, void *devdata, | ~~~~~~^~~~ Change the dummy helper functions to have the same arguments as the normal version. Fixes: f991de53a8ab ("thermal: make device_register's type argument const") Signed-off-by: Arnd Bergmann Reviewed-by: Jean-Francois Dagenais Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210722090717.1116748-1-arnd@kernel.org Signed-off-by: Sasha Levin commit d1f9ecc00da1bb6af558251d3eb88ea33aa0c307 Author: Masami Hiramatsu Date: Sun Sep 5 00:54:31 2021 +0900 tools/bootconfig: Fix tracing_on option checking in ftrace2bconf.sh [ Upstream commit 32ba9f0fb027cc43074e3ea26fcf831adeee8e03 ] Since tracing_on indicates only "1" (default) or "0", ftrace2bconf.sh only need to check the value is "0". Link: https://lkml.kernel.org/r/163077087144.222577.6888011847727968737.stgit@devnote2 Fixes: 55ed4560774d ("tools/bootconfig: Add tracing_on support to helper scripts") Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 912afe602eacf4c9cf75a74d3cdb5c9f9c7c4698 Author: Lukas Bulwahn Date: Tue Sep 7 20:00:47 2021 -0700 Kconfig.debug: drop selecting non-existing HARDLOCKUP_DETECTOR_ARCH [ Upstream commit 6fe26259b4884b657cbc233fb9cdade9d704976e ] Commit 05a4a9527931 ("kernel/watchdog: split up config options") adds a new config HARDLOCKUP_DETECTOR, which selects the non-existing config HARDLOCKUP_DETECTOR_ARCH. Hence, ./scripts/checkkconfigsymbols.py warns: HARDLOCKUP_DETECTOR_ARCH Referencing files: lib/Kconfig.debug Simply drop selecting the non-existing HARDLOCKUP_DETECTOR_ARCH. Link: https://lkml.kernel.org/r/20210806115618.22088-1-lukas.bulwahn@gmail.com Fixes: 05a4a9527931 ("kernel/watchdog: split up config options") Signed-off-by: Lukas Bulwahn Cc: Nicholas Piggin Cc: Masahiro Yamada Cc: Babu Moger Cc: Don Zickus Cc: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit e418ce8b8dfd47c3555b6e53757382d1fb609b54 Author: Jeff Layton Date: Tue Jul 27 15:47:12 2021 -0400 ceph: cancel delayed work instead of flushing on mdsc teardown [ Upstream commit b4002173b7989588b6feaefc42edaf011b596782 ] The first thing metric_delayed_work does is check mdsc->stopping, and then return immediately if it's set. That's good since we would have already torn down the metric structures at this point, otherwise, but there is no locking around mdsc->stopping. It's possible that the ceph_metric_destroy call could race with the delayed_work, in which case we could end up with the delayed_work accessing destroyed percpu variables. At this point in the mdsc teardown, the "stopping" flag has already been set, so there's no benefit to flushing the work. Move the work cancellation in ceph_metric_destroy ahead of the percpu variable destruction, and eliminate the flush_delayed_work call in ceph_mdsc_destroy. Fixes: 18f473b384a6 ("ceph: periodically send perf metrics to MDSes") Signed-off-by: Jeff Layton Reviewed-by: Xiubo Li Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 8193ad306ea0005bbe1f2f8fc600ab270d27c8dd Author: Jeff Layton Date: Wed Jun 9 14:09:52 2021 -0400 ceph: allow ceph_put_mds_session to take NULL or ERR_PTR [ Upstream commit 7e65624d32b6e0429b1d3559e5585657f34f74a1 ] ...to simplify some error paths. Signed-off-by: Jeff Layton Reviewed-by: Luis Henriques Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 41aa215734868ba7cb195e2cc5f00cdba5bd1578 Author: Gwendal Grignou Date: Mon Aug 30 11:00:50 2021 -0700 platform/chrome: cros_ec_trace: Fix format warnings [ Upstream commit 4665584888ad2175831c972c004115741ec799e9 ] Fix printf format issues in new tracing events. Fixes: 814318242687 ("platform/chrome: cros_ec_trace: Add fields to command traces") Signed-off-by: Gwendal Grignou Link: https://lore.kernel.org/r/20210830180050.2077261-1-gwendal@chromium.org Signed-off-by: Benson Leung Signed-off-by: Sasha Levin commit 113a69460de5e82ae3be12b01ec1daee81fd9929 Author: Gwendal Grignou Date: Thu May 13 17:57:33 2021 -0700 platform/chrome: sensorhub: Add trace events for sample [ Upstream commit d453ceb6549af8798913de6a20444cb7200fdb69 ] Add trace event to report samples and their timestamp coming from the EC. It allows to check if the timestamps are correct and the filter is working correctly without introducing too much latency. To enable these events: cd /sys/kernel/debug/tracing/ echo 1 > events/cros_ec/enable echo 0 > events/cros_ec/cros_ec_request_start/enable echo 0 > events/cros_ec/cros_ec_request_done/enable echo 1 > tracing_on cat trace_pipe Observe event flowing: irq/105-chromeo-95 [000] .... 613.659758: cros_ec_sensorhub_timestamp: ... irq/105-chromeo-95 [000] .... 613.665219: cros_ec_sensorhub_filter: dx: ... Signed-off-by: Gwendal Grignou Signed-off-by: Enric Balletbo i Serra Signed-off-by: Sasha Levin commit 48271d10bf4cbdd4693ad4f94fb14c2aa7fcc4c5 Author: Dave Jiang Date: Thu Jul 22 10:54:10 2021 -0700 dmaengine: idxd: fix wq slot allocation index check [ Upstream commit 673d812d30be67942762bb9e8548abb26a3ba4a7 ] The sbitmap wait and allocate routine checks the index that is returned from sbitmap_queue_get(). It should be idxd >= 0 as 0 is also a valid index. This fixes issue where submission path hangs when WQ size is 1. Fixes: 0705107fcc80 ("dmaengine: idxd: move submission to sbitmap_queue") Signed-off-by: Dave Jiang Link: https://lore.kernel.org/r/162697645067.3478714.506720687816951762.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 777344da345a374eb74f2a743b5399e6e60d566b Author: Uwe Kleine-König Date: Wed Jul 7 18:27:50 2021 +0200 pwm: mxs: Don't modify HW state in .probe() after the PWM chip was registered commit 020162d6f49f2963062229814a56a89c86cbeaa8 upstream. This fixes a race condition: After pwmchip_add() is called there might already be a consumer and then modifying the hardware behind the consumer's back is bad. So reset before calling pwmchip_add(). Note that reseting the hardware isn't the right thing to do if the PWM is already running as it might e.g. disable (or even enable) a backlight that is supposed to be on (or off). Fixes: 4dce82c1e840 ("pwm: add pwm-mxs support") Cc: Sascha Hauer Cc: Shawn Guo Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit 322b70b522abe03cd59712bb47a72eddd835d19d Author: Uwe Kleine-König Date: Wed Jul 7 18:27:49 2021 +0200 pwm: lpc32xx: Don't modify HW state in .probe() after the PWM chip was registered commit 3d2813fb17e5fd0d73c1d1442ca0192bde4af10e upstream. This fixes a race condition: After pwmchip_add() is called there might already be a consumer and then modifying the hardware behind the consumer's back is bad. So set the default before. (Side-note: I don't know what this register setting actually does, if this modifies the polarity there is an inconsistency because the inversed polarity isn't considered if the PWM is already running during .probe().) Fixes: acfd92fdfb93 ("pwm: lpc32xx: Set PWM_PIN_LEVEL bit to default value") Cc: Sylvain Lemieux Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit c63df77c40ca40979ed8bb02b4a07500eef6cd28 Author: Prasad Sodagudi Date: Tue Sep 7 04:24:23 2021 -0700 PM: sleep: core: Avoid setting power.must_resume to false commit 4a9344cd0aa4499beb3772bbecb40bb78888c0e1 upstream. There are variables(power.may_skip_resume and dev->power.must_resume) and DPM_FLAG_MAY_SKIP_RESUME flags to control the resume of devices after a system wide suspend transition. Setting the DPM_FLAG_MAY_SKIP_RESUME flag means that the driver allows its "noirq" and "early" resume callbacks to be skipped if the device can be left in suspend after a system-wide transition into the working state. PM core determines that the driver's "noirq" and "early" resume callbacks should be skipped or not with dev_pm_skip_resume() function by checking power.may_skip_resume variable. power.must_resume variable is getting set to false in __device_suspend() function without checking device's DPM_FLAG_MAY_SKIP_RESUME settings. In problematic scenario, where all the devices in the suspend_late stage are successful and some device can fail to suspend in suspend_noirq phase. So some devices successfully suspended in suspend_late stage are not getting chance to execute __device_suspend_noirq() to set dev->power.must_resume variable to true and not getting resumed in early_resume phase. Add a check for device's DPM_FLAG_MAY_SKIP_RESUME flag before setting power.must_resume variable in __device_suspend function. Fixes: 6e176bf8d461 ("PM: sleep: core: Do not skip callbacks in the resume phase") Signed-off-by: Prasad Sodagudi Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 74190973ab01fb88e8b685f417651e30112ed4a1 Author: Pavel Skripkin Date: Tue Sep 7 19:58:21 2021 -0700 profiling: fix shift-out-of-bounds bugs commit 2d186afd04d669fe9c48b994c41a7405a3c9f16d upstream. Syzbot reported shift-out-of-bounds bug in profile_init(). The problem was in incorrect prof_shift. Since prof_shift value comes from userspace we need to clamp this value into [0, BITS_PER_LONG -1] boundaries. Second possible shiht-out-of-bounds was found by Tetsuo: sample_step local variable in read_profile() had "unsigned int" type, but prof_shift allows to make a BITS_PER_LONG shift. So, to prevent possible shiht-out-of-bounds sample_step type was changed to "unsigned long". Also, "unsigned short int" will be sufficient for storing [0, BITS_PER_LONG] value, that's why there is no need for "unsigned long" prof_shift. Link: https://lkml.kernel.org/r/20210813140022.5011-1-paskripkin@gmail.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-and-tested-by: syzbot+e68c89a9510c159d9684@syzkaller.appspotmail.com Suggested-by: Tetsuo Handa Signed-off-by: Pavel Skripkin Cc: Thomas Gleixner Cc: Steven Rostedt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0796d99c1b16f03fd34024a26da2e81ec1c728c1 Author: Zhen Lei Date: Tue Sep 7 20:00:26 2021 -0700 nilfs2: use refcount_dec_and_lock() to fix potential UAF commit 98e2e409e76ef7781d8511f997359e9c504a95c1 upstream. When the refcount is decreased to 0, the resource reclamation branch is entered. Before CPU0 reaches the race point (1), CPU1 may obtain the spinlock and traverse the rbtree to find 'root', see nilfs_lookup_root(). Although CPU1 will call refcount_inc() to increase the refcount, it is obviously too late. CPU0 will release 'root' directly, CPU1 then accesses 'root' and triggers UAF. Use refcount_dec_and_lock() to ensure that both the operations of decrease refcount to 0 and link deletion are lock protected eliminates this risk. CPU0 CPU1 nilfs_put_root(): <-------- (1) spin_lock(&nilfs->ns_cptree_lock); rb_erase(&root->rb_node, &nilfs->ns_cptree); spin_unlock(&nilfs->ns_cptree_lock); kfree(root); <-------- use-after-free refcount_t: underflow; use-after-free. WARNING: CPU: 2 PID: 9476 at lib/refcount.c:28 \ refcount_warn_saturate+0x1cf/0x210 lib/refcount.c:28 Modules linked in: CPU: 2 PID: 9476 Comm: syz-executor.0 Not tainted 5.10.45-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ... RIP: 0010:refcount_warn_saturate+0x1cf/0x210 lib/refcount.c:28 ... ... Call Trace: __refcount_sub_and_test include/linux/refcount.h:283 [inline] __refcount_dec_and_test include/linux/refcount.h:315 [inline] refcount_dec_and_test include/linux/refcount.h:333 [inline] nilfs_put_root+0xc1/0xd0 fs/nilfs2/the_nilfs.c:795 nilfs_segctor_destroy fs/nilfs2/segment.c:2749 [inline] nilfs_detach_log_writer+0x3fa/0x570 fs/nilfs2/segment.c:2812 nilfs_put_super+0x2f/0xf0 fs/nilfs2/super.c:467 generic_shutdown_super+0xcd/0x1f0 fs/super.c:464 kill_block_super+0x4a/0x90 fs/super.c:1446 deactivate_locked_super+0x6a/0xb0 fs/super.c:335 deactivate_super+0x85/0x90 fs/super.c:366 cleanup_mnt+0x277/0x2e0 fs/namespace.c:1118 __cleanup_mnt+0x15/0x20 fs/namespace.c:1125 task_work_run+0x8e/0x110 kernel/task_work.c:151 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_user_mode_loop kernel/entry/common.c:164 [inline] exit_to_user_mode_prepare+0x13c/0x170 kernel/entry/common.c:191 syscall_exit_to_user_mode+0x16/0x30 kernel/entry/common.c:266 do_syscall_64+0x45/0x80 arch/x86/entry/common.c:56 entry_SYSCALL_64_after_hwframe+0x44/0xa9 There is no reproduction program, and the above is only theoretical analysis. Link: https://lkml.kernel.org/r/1629859428-5906-1-git-send-email-konishi.ryusuke@gmail.com Fixes: ba65ae4729bf ("nilfs2: add checkpoint tree to nilfs object") Link: https://lkml.kernel.org/r/20210723012317.4146-1-thunder.leizhen@huawei.com Signed-off-by: Zhen Lei Signed-off-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 30417cbeccffeaaf5d7fa5a9e9feffe246a1430f Author: Cyrill Gorcunov Date: Tue Sep 7 20:00:41 2021 -0700 prctl: allow to setup brk for et_dyn executables commit e1fbbd073137a9d63279f6bf363151a938347640 upstream. Keno Fischer reported that when a binray loaded via ld-linux-x the prctl(PR_SET_MM_MAP) doesn't allow to setup brk value because it lays before mm:end_data. For example a test program shows | # ~/t | | start_code 401000 | end_code 401a15 | start_stack 7ffce4577dd0 | start_data 403e10 | end_data 40408c | start_brk b5b000 | sbrk(0) b5b000 and when executed via ld-linux | # /lib64/ld-linux-x86-64.so.2 ~/t | | start_code 7fc25b0a4000 | end_code 7fc25b0c4524 | start_stack 7fffcc6b2400 | start_data 7fc25b0ce4c0 | end_data 7fc25b0cff98 | start_brk 55555710c000 | sbrk(0) 55555710c000 This of course prevent criu from restoring such programs. Looking into how kernel operates with brk/start_brk inside brk() syscall I don't see any problem if we allow to setup brk/start_brk without checking for end_data. Even if someone pass some weird address here on a purpose then the worst possible result will be an unexpected unmapping of existing vma (own vma, since prctl works with the callers memory) but test for RLIMIT_DATA is still valid and a user won't be able to gain more memory in case of expanding VMAs via new values shipped with prctl call. Link: https://lkml.kernel.org/r/20210121221207.GB2174@grain Fixes: bbdc6076d2e5 ("binfmt_elf: move brk out of mmap when doing direct loader exec") Signed-off-by: Cyrill Gorcunov Reported-by: Keno Fischer Acked-by: Andrey Vagin Tested-by: Andrey Vagin Cc: Dmitry Safonov <0x7f454c46@gmail.com> Cc: Kirill Tkhai Cc: Eric W. Biederman Cc: Pavel Tikhomirov Cc: Alexander Mikhalitsyn Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e464b3876b022c0c4e0eb21518c491c6eb38130c Author: Xie Yongji Date: Mon May 17 16:35:57 2021 +0800 9p/trans_virtio: Remove sysfs file on probe failure commit f997ea3b7afc108eb9761f321b57de2d089c7c48 upstream. This ensures we don't leak the sysfs file if we failed to allocate chan->vc_wq during probe. Link: http://lkml.kernel.org/r/20210517083557.172-1-xieyongji@bytedance.com Fixes: 86c8437383ac ("net/9p: Add sysfs mount_tag file for virtio 9P device") Signed-off-by: Xie Yongji Signed-off-by: Dominique Martinet Signed-off-by: Greg Kroah-Hartman commit 375e779ec32a87edeb6bb26582c1c9a1f59876f9 Author: Dan Carpenter Date: Tue Aug 10 11:44:13 2021 +0300 thermal/drivers/exynos: Fix an error code in exynos_tmu_probe() commit 02d438f62c05f0d055ceeedf12a2f8796b258c08 upstream. This error path return success but it should propagate the negative error code from devm_clk_get(). Fixes: 6c247393cfdd ("thermal: exynos: Add TMU support for Exynos7 SoC") Signed-off-by: Dan Carpenter Reviewed-by: Krzysztof Kozlowski Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210810084413.GA23810@kili Signed-off-by: Greg Kroah-Hartman commit 38ab04186fb3f3b50f33e5cfde38066c5227e89d Author: Namhyung Kim Date: Fri Sep 10 15:46:30 2021 -0700 perf tools: Allow build-id with trailing zeros commit 4a86d41404005a3c7e7b6065e8169ac6202887a9 upstream. Currently perf saves a build-id with size but old versions assumes the size of 20. In case the build-id is less than 20 (like for MD5), it'd fill the rest with 0s. I saw a problem when old version of perf record saved a binary in the build-id cache and new version of perf reads the data. The symbols should be read from the build-id cache (as the path no longer has the same binary) but it failed due to mismatch in the build-id. symsrc__init: build id mismatch for /home/namhyung/.debug/.build-id/53/e4c2f42a4c61a2d632d92a72afa08f00000000/elf. The build-id event in the data has 20 byte build-ids, but it saw a different size (16) when it reads the build-id of the elf file in the build-id cache. $ readelf -n ~/.debug/.build-id/53/e4c2f42a4c61a2d632d92a72afa08f00000000/elf Displaying notes found in: .note.gnu.build-id Owner Data size Description GNU 0x00000010 NT_GNU_BUILD_ID (unique build ID bitstring) Build ID: 53e4c2f42a4c61a2d632d92a72afa08f Let's fix this by allowing trailing zeros if the size is different. Fixes: 39be8d0115b321ed ("perf tools: Pass build_id object to dso__build_id_equal()") Signed-off-by: Namhyung Kim Acked-by: Jiri Olsa Cc: Andi Kleen Cc: Ian Rogers Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20210910224630.1084877-1-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 87c4144450e6f09afeb2adc336f35b5f5274205c Author: Jiri Olsa Date: Thu Nov 26 18:00:06 2020 +0100 tools lib: Adopt memchr_inv() from kernel commit b3e453272d436aab8adbe810c6d7043670281487 upstream. We'll use it to check for undefined/zero data. Signed-off-by: Jiri Olsa Suggested-by: Arnaldo Carvalho de Melo Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Alexey Budankov Cc: Andi Kleen Cc: Ian Rogers Cc: Mark Rutland Cc: Michael Petlan Cc: Peter Zijlstra Cc: Song Liu Cc: Stephane Eranian Link: http://lore.kernel.org/lkml/20201126170026.2619053-6-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit ebcd3fd9207c98f0c01c317ef3aca7f2df41b72d Author: Michael Petlan Date: Thu Aug 5 18:06:11 2021 +0200 perf test: Fix bpf test sample mismatch reporting commit 3e11300cdfd5f1bc13a05dfc6dccf69aca5dd1dc upstream. When the expected sample count in the condition changed, the message needs to be changed too, otherwise we'll get: 0x1001f2091d8: mmap mask[0]: BPF filter result incorrect, expected 56, got 56 samples Fixes: 4b04e0decd2518e5 ("perf test: Fix basic bpf filtering test") Signed-off-by: Michael Petlan Cc: Jiri Olsa Cc: Sumanth Korikkar Link: https //lore.kernel.org/r/20210805160611.5542-1-mpetlan@redhat.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit fa64b08931ee27bec3513aed8f7936e99b8d1212 Author: Andy Shevchenko Date: Fri Jul 30 23:27:15 2021 +0300 dmaengine: acpi: Avoid comparison GSI with Linux vIRQ commit 67db87dc8284070adb15b3c02c1c31d5cf51c5d6 upstream. Currently the CRST parsing relies on the fact that on most of x86 devices the IRQ mapping is 1:1 with Linux vIRQ. However, it may be not true for some. Fix this by converting GSI to Linux vIRQ before checking it. Fixes: ee8209fd026b ("dma: acpi-dma: parse CSRT to extract additional resources") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210730202715.24375-1-andriy.shevchenko@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 9d49973b08488f59dd0ada269d9dca210d1fd365 Author: Johannes Berg Date: Fri Jun 25 10:34:37 2021 +0200 um: virtio_uml: fix memory leak on init failures commit 7ad28e0df7ee9dbcb793bb88dd81d4d22bb9a10e upstream. If initialization fails, e.g. because the connection failed, we leak the 'vu_dev'. Fix that. Reported by smatch. Fixes: 5d38f324993f ("um: drivers: Add virtio vhost-user driver") Signed-off-by: Johannes Berg Acked-By: Anton Ivanov Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 5d0e6a5e44416cdfd8b391fa46c69f7d08f9dd0d Author: QiuXi Date: Tue Sep 7 20:00:32 2021 -0700 coredump: fix memleak in dump_vma_snapshot() commit 6fcac87e1f9e5b27805a2a404f4849194bb51de8 upstream. dump_vma_snapshot() allocs memory for *vma_meta, when dump_vma_snapshot() returns -EFAULT, the memory will be leaked, so we free it correctly. Link: https://lkml.kernel.org/r/20210810020441.62806-1-qiuxi1@huawei.com Fixes: a07279c9a8cd7 ("binfmt_elf, binfmt_elf_fdpic: use a VMA list snapshot") Signed-off-by: QiuXi Cc: Al Viro Cc: Jann Horn Cc: Greg Kroah-Hartman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6b24588708fe7cb680d433a0492abb651bb1d5b0 Author: Nathan Chancellor Date: Sat Aug 14 16:56:26 2021 -0700 staging: rtl8192u: Fix bitwise vs logical operator in TranslateRxSignalStuff819xUsb() commit 099ec97ac92911abfb102bb5c68ed270fc12e0dd upstream. clang warns: drivers/staging/rtl8192u/r8192U_core.c:4268:20: warning: bitwise and of boolean expressions; did you mean logical and? [-Wbool-operation-and] bpacket_toself = bpacket_match_bssid & ^~~~~~~~~~~~~~~~~~~~~ && 1 warning generated. Replace the bitwise AND with a logical one to clear up the warning, as that is clearly what was intended. Fixes: 8fc8598e61f6 ("Staging: Added Realtek rtl8192u driver to staging") Signed-off-by: Nathan Chancellor Link: https://lore.kernel.org/r/20210814235625.1780033-1-nathan@kernel.org Signed-off-by: Greg Kroah-Hartman commit ccb79116c37242c07c34c991868acded87509e4c Author: Marcelo Ricardo Leitner Date: Mon Jun 28 16:13:44 2021 -0300 sctp: add param size validation for SCTP_PARAM_SET_PRIMARY commit ef6c8d6ccf0c1dccdda092ebe8782777cd7803c9 upstream. When SCTP handles an INIT chunk, it calls for example: sctp_sf_do_5_1B_init sctp_verify_init sctp_verify_param sctp_process_init sctp_process_param handling of SCTP_PARAM_SET_PRIMARY sctp_verify_init() wasn't doing proper size validation and neither the later handling, allowing it to work over the chunk itself, possibly being uninitialized memory. Signed-off-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ffca46766850d4b96a26ad511a7997f74da2df8c Author: Marcelo Ricardo Leitner Date: Mon Jun 28 16:13:43 2021 -0300 sctp: validate chunk size in __rcv_asconf_lookup commit b6ffe7671b24689c09faa5675dd58f93758a97ae upstream. In one of the fallbacks that SCTP has for identifying an association for an incoming packet, it looks for AddIp chunk (from ASCONF) and take a peek. Thing is, at this stage nothing was validating that the chunk actually had enough content for that, allowing the peek to happen over uninitialized memory. Similar check already exists in actual asconf handling in sctp_verify_asconf(). Signed-off-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 473cea4983b582fedb10f84b43e8924716ebc4fc Author: Greg Kroah-Hartman Date: Thu Sep 23 13:01:44 2021 +0200 Revert "net/mlx5: Register to devlink ingress VLAN filter trap" This reverts commit fe6322774ca28669868a7e231e173e09f7422118 which was commit 82e6c96f04e13c72d91777455836ffd012853caa upstream. It has been reported to cause regressions so should be dropped. Reported-by: Link: https://lore.kernel.org/r/BY5PR13MB3604D3031E984CA34A57B7C9EEA09@BY5PR13MB3604.namprd13.prod.outlook.com Cc: Aya Levin Cc: Tariq Toukan Cc: Tariq Toukan Cc: Saeed Mahameed Cc: Jakub Kicinski Cc: Sasha Levin Cc: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman commit 5ce134e65f3b8034220c416ab8cecd8652fdeb2d Author: Alex Sverdlin Date: Wed Sep 22 09:59:58 2021 -0700 ARM: 9098/1: ftrace: MODULE_PLT: Fix build problem without DYNAMIC_FTRACE commit 6fa630bf473827aee48cbf0efbbdf6f03134e890 upstream FTRACE_ADDR is only defined when CONFIG_DYNAMIC_FTRACE is defined, the latter is even stronger requirement than CONFIG_FUNCTION_TRACER (which is enough for MCOUNT_ADDR). Link: https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org/thread/ZUVCQBHDMFVR7CCB7JPESLJEWERZDJ3T/ Fixes: 1f12fb25c5c5d22f ("ARM: 9079/1: ftrace: Add MODULE_PLTS support") Reported-by: kernel test robot Signed-off-by: Alexander Sverdlin Signed-off-by: Russell King Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit f91d25a7c89e2f246a541603430ce2420bab58c5 Author: Alex Sverdlin Date: Wed Sep 22 09:59:57 2021 -0700 ARM: 9079/1: ftrace: Add MODULE_PLTS support commit 79f32b221b18c15a98507b101ef4beb52444cc6f upstream Teach ftrace_make_call() and ftrace_make_nop() about PLTs. Teach PLT code about FTRACE and all its callbacks. Otherwise the following might happen: ------------[ cut here ]------------ WARNING: CPU: 14 PID: 2265 at .../arch/arm/kernel/insn.c:14 __arm_gen_branch+0x83/0x8c() ... Hardware name: LSI Axxia AXM55XX [] (unwind_backtrace) from [] (show_stack+0x11/0x14) [] (show_stack) from [] (dump_stack+0x81/0xa8) [] (dump_stack) from [] (warn_slowpath_common+0x69/0x90) [] (warn_slowpath_common) from [] (warn_slowpath_null+0x17/0x1c) [] (warn_slowpath_null) from [] (__arm_gen_branch+0x83/0x8c) [] (__arm_gen_branch) from [] (ftrace_make_nop+0xf/0x24) [] (ftrace_make_nop) from [] (ftrace_process_locs+0x27b/0x3e8) [] (ftrace_process_locs) from [] (load_module+0x11e9/0x1a44) [] (load_module) from [] (SyS_finit_module+0x59/0x84) [] (SyS_finit_module) from [] (ret_fast_syscall+0x1/0x18) ---[ end trace e1b64ced7a89adcc ]--- ------------[ cut here ]------------ WARNING: CPU: 14 PID: 2265 at .../kernel/trace/ftrace.c:1979 ftrace_bug+0x1b1/0x234() ... Hardware name: LSI Axxia AXM55XX [] (unwind_backtrace) from [] (show_stack+0x11/0x14) [] (show_stack) from [] (dump_stack+0x81/0xa8) [] (dump_stack) from [] (warn_slowpath_common+0x69/0x90) [] (warn_slowpath_common) from [] (warn_slowpath_null+0x17/0x1c) [] (warn_slowpath_null) from [] (ftrace_bug+0x1b1/0x234) [] (ftrace_bug) from [] (ftrace_process_locs+0x285/0x3e8) [] (ftrace_process_locs) from [] (load_module+0x11e9/0x1a44) [] (load_module) from [] (SyS_finit_module+0x59/0x84) [] (SyS_finit_module) from [] (ret_fast_syscall+0x1/0x18) ---[ end trace e1b64ced7a89adcd ]--- ftrace failed to modify [] 0xe9ef7006 actual: 02:f0:3b:fa ftrace record flags: 0 (0) expected tramp: c0314265 Signed-off-by: Alexander Sverdlin Signed-off-by: Russell King Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit ad00533858f7b1436f7dc9c555ccac85c0e28c9a Author: Alex Sverdlin Date: Wed Sep 22 09:59:56 2021 -0700 ARM: 9078/1: Add warn suppress parameter to arm_gen_branch_link() commit 890cb057a46d323fd8c77ebecb6485476614cd21 upstream Will be used in the following patch. No functional change. Signed-off-by: Alexander Sverdlin Signed-off-by: Russell King Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit ce90c6706d5a95ddda8d3cea01768bd0b4445851 Author: Alex Sverdlin Date: Wed Sep 22 09:59:55 2021 -0700 ARM: 9077/1: PLT: Move struct plt_entries definition to header commit 4e271701c17dee70c6e1351c4d7d42e70405c6a9 upstream upstream No functional change, later it will be re-used in several files. Signed-off-by: Alexander Sverdlin Signed-off-by: Russell King Signed-off-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit eb46d7c8ae838b37ad4acee44fa3828af3062ce7 Author: Florian Fainelli Date: Thu Mar 18 21:03:33 2021 -0700 ARM: Qualify enabling of swiotlb_init() commit fcf044891c84e38fc90eb736b818781bccf94e38 upstream. We do not need a SWIOTLB unless we have DRAM that is addressable beyond the arm_dma_limit. Compare max_pfn with arm_dma_pfn_limit to determine whether we do need a SWIOTLB to be initialized. Fixes: ad3c7b18c5b3 ("arm: use swiotlb for bounce buffering on LPAE configs") Signed-off-by: Florian Fainelli Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 79286ea830b3922b38bcefbd150b2010f91a55ce Author: David Hildenbrand Date: Thu Sep 9 16:59:42 2021 +0200 s390/pci_mmio: fully validate the VMA before calling follow_pte() commit a8b92b8c1eac8d655a97b1e90f4d83c25d9b9a18 upstream. We should not walk/touch page tables outside of VMA boundaries when holding only the mmap sem in read mode. Evil user space can modify the VMA layout just before this function runs and e.g., trigger races with page table removal code since commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap"). find_vma() does not check if the address is >= the VMA start address; use vma_lookup() instead. Reviewed-by: Niklas Schnelle Reviewed-by: Liam R. Howlett Fixes: dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap") Signed-off-by: David Hildenbrand Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 74d54e5ceba3f50b9b695e4740172d876327815a Author: nick black Date: Mon Aug 30 04:56:15 2021 -0400 console: consume APC, DM, DCS commit 3a2b2eb55681158d3e3ef464fbf47574cf0c517c upstream. The Linux console's VT102 implementation already consumes OSC ("Operating System Command") sequences, probably because that's how palette changes are transmitted. In addition to OSC, there are three other major clases of ANSI control strings: APC ("Application Program Command"), PM ("Privacy Message"), and DCS ("Device Control String"). They are handled similarly to OSC in terms of termination. Source: vt100.net Add three new enumerated states, one for each of these types. All three are handled the same way right now--they simply consume input until terminated. I hope to expand upon this firmament in the future. Add new predicate ansi_control_string(), returning true for any of these states. Replace explicit checks against ESosc with calls to this function. Transition to these states appropriately from the escape initiation (ESesc) state. This was motivated by the following Notcurses bugs: https://github.com/dankamongmen/notcurses/issues/2050 https://github.com/dankamongmen/notcurses/issues/1828 https://github.com/dankamongmen/notcurses/issues/2069 where standard VT sequences are not consumed by the Linux console. It's not necessary that the Linux console *support* these sequences, but it ought *consume* these well-specified classes of sequences. Tested by sending a variety of escape sequences to the console, and verifying that they still worked, or were now properly consumed. Verified that the escapes were properly terminated at a generic level. Verified that the Notcurses tools continued to show expected output on the Linux console, except now without escape bleedthrough. Link: https://lore.kernel.org/lkml/YSydL0q8iaUfkphg@schwarzgerat.orthanc/ Signed-off-by: nick black Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: Tetsuo Handa Cc: Daniel Vetter Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9493e92a395330787def2b1980e930f5082de2f4 Author: Pali Rohár Date: Thu Jul 22 16:40:41 2021 +0200 PCI: aardvark: Fix reporting CRS value commit 43f5c77bcbd27cce70bf33c2b86d6726ce95dd66 upstream. Set CRSVIS flag in emulated root PCI bridge to indicate support for Completion Retry Status. Add check for CRSSVE flag from root PCI brige when issuing Configuration Read Request via PIO to correctly returns fabricated CRS value as it is required by PCIe spec. Link: https://lore.kernel.org/r/20210722144041.12661-5-pali@kernel.org Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space") Signed-off-by: Pali Rohár Signed-off-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org # e0d9d30b7354 ("PCI: pci-bridge-emul: Fix big-endian support") Signed-off-by: Greg Kroah-Hartman commit 9e766b86a9ef653a8ca48a9f70d3dbb580284594 Author: Pali Rohár Date: Thu Jul 22 16:40:40 2021 +0200 PCI: pci-bridge-emul: Add PCIe Root Capabilities Register commit e902bb7c24a7099d0eb0eb4cba06f2d91e9299f3 upstream. The 16-bit Root Capabilities register is at offset 0x1e in the PCIe Capability. Rename current 'rsvd' struct member to 'rootcap'. Link: https://lore.kernel.org/r/20210722144041.12661-4-pali@kernel.org Signed-off-by: Pali Rohár Signed-off-by: Lorenzo Pieralisi Reviewed-by: Marek Behún Signed-off-by: Greg Kroah-Hartman commit 4d8524048a35c03ff04c25ca1bcdf569f9aeb14a Author: Greg Kroah-Hartman Date: Wed Sep 22 12:28:07 2021 +0200 Linux 5.10.68 Link: https://lore.kernel.org/r/20210920163915.757887582@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Fox Chen Tested-by: Salvatore Bonaccorso Tested-by: Jon Hunter Tested-by: Shuah Khan Tested-by: Florian Fainelli Tested-by: Sudip Mukherjee Tested-by: Guenter Roeck Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Signed-off-by: Greg Kroah-Hartman commit a23d3576215f7447c547976817b33cb975ecec84 Author: Florian Fainelli Date: Thu Sep 16 14:33:35 2021 -0700 net: dsa: bcm_sf2: Fix array overrun in bcm_sf2_num_active_ports() commit 02319bf15acf54004216e40ac9c171437f24be24 upstream. After d12e1c464988 ("net: dsa: b53: Set correct number of ports in the DSA struct") we stopped setting dsa_switch::num_ports to DSA_MAX_PORTS, which created an off by one error between the statically allocated bcm_sf2_priv::port_sts array (of size DSA_MAX_PORTS). When dsa_is_cpu_port() is used, we end-up accessing an out of bounds member and causing a NPD. Fix this by iterating with the appropriate port count using ds->num_ports. Fixes: d12e1c464988 ("net: dsa: b53: Set correct number of ports in the DSA struct") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9f2972e151dd16d3286c1407bec4e66395f30135 Author: Michael Chan Date: Sun Sep 12 12:34:47 2021 -0400 bnxt_en: Fix error recovery regression commit eca4cf12acda306f851f6d2a05b1c9ef62cf0e81 upstream. The recent patch has introduced a regression by not reading the reset count in the ERROR_RECOVERY async event handler. We may have just gone through a reset and the reset count has just incremented. If we don't update the reset count in the ERROR_RECOVERY event handler, the health check timer will see that the reset count has changed and will initiate an unintended reset. Restore the unconditional update of the reset count in bnxt_async_event_process() if error recovery watchdog is enabled. Also, update the reset count at the end of the reset sequence to make it even more robust. Fixes: 1b2b91831983 ("bnxt_en: Fix possible unintended driver initiated error recovery") Reviewed-by: Edwin Peer Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 619d747c1850bab61625ca9d8b4730f470a5947b Author: Tony Luck Date: Mon Sep 13 14:52:39 2021 -0700 x86/mce: Avoid infinite loop for copy from user recovery commit 81065b35e2486c024c7aa86caed452e1f01a59d4 upstream. There are two cases for machine check recovery: 1) The machine check was triggered by ring3 (application) code. This is the simpler case. The machine check handler simply queues work to be executed on return to user. That code unmaps the page from all users and arranges to send a SIGBUS to the task that triggered the poison. 2) The machine check was triggered in kernel code that is covered by an exception table entry. In this case the machine check handler still queues a work entry to unmap the page, etc. but this will not be called right away because the #MC handler returns to the fix up code address in the exception table entry. Problems occur if the kernel triggers another machine check before the return to user processes the first queued work item. Specifically, the work is queued using the ->mce_kill_me callback structure in the task struct for the current thread. Attempting to queue a second work item using this same callback results in a loop in the linked list of work functions to call. So when the kernel does return to user, it enters an infinite loop processing the same entry for ever. There are some legitimate scenarios where the kernel may take a second machine check before returning to the user. 1) Some code (e.g. futex) first tries a get_user() with page faults disabled. If this fails, the code retries with page faults enabled expecting that this will resolve the page fault. 2) Copy from user code retries a copy in byte-at-time mode to check whether any additional bytes can be copied. On the other side of the fence are some bad drivers that do not check the return value from individual get_user() calls and may access multiple user addresses without noticing that some/all calls have failed. Fix by adding a counter (current->mce_count) to keep track of repeated machine checks before task_work() is called. First machine check saves the address information and calls task_work_add(). Subsequent machine checks before that task_work call back is executed check that the address is in the same page as the first machine check (since the callback will offline exactly one page). Expected worst case is four machine checks before moving on (e.g. one user access with page faults disabled, then a repeat to the same address with page faults enabled ... repeat in copy tail bytes). Just in case there is some code that loops forever enforce a limit of 10. [ bp: Massage commit message, drop noinstr, fix typo, extend panic messages. ] Fixes: 5567d11c21a1 ("x86/mce: Send #MC singal from task work") Signed-off-by: Tony Luck Signed-off-by: Borislav Petkov Cc: Link: https://lkml.kernel.org/r/YT/IJ9ziLqmtqEPu@agluck-desk2.amr.corp.intel.com Signed-off-by: Greg Kroah-Hartman commit 47bc9c3929eb0bafe805bf87474615c8596d16bc Author: Yoshihiro Shimoda Date: Tue Sep 7 20:29:40 2021 +0900 net: renesas: sh_eth: Fix freeing wrong tx descriptor [ Upstream commit 0341d5e3d1ee2a36dd5a49b5bef2ce4ad1cfa6b4 ] The cur_tx counter must be incremented after TACT bit of txdesc->status was set. However, a CPU is possible to reorder instructions and/or memory accesses between cur_tx and txdesc->status. And then, if TX interrupt happened at such a timing, the sh_eth_tx_free() may free the descriptor wrongly. So, add wmb() before cur_tx++. Otherwise NETDEV WATCHDOG timeout is possible to happen. Fixes: 86a74ff21a7a ("net: sh_eth: add support for Renesas SuperH Ethernet") Signed-off-by: Yoshihiro Shimoda Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b2f9b7455baf8ba12113520cdf0398b6141ae42f Author: Randy Dunlap Date: Mon Sep 6 17:19:49 2021 -0700 mfd: lpc_sch: Rename GPIOBASE to prevent build error [ Upstream commit cdff1eda69326fb46de10c5454212b3efcf4bb41 ] One MIPS platform (mach-rc32434) defines GPIOBASE. This macro conflicts with one of the same name in lpc_sch.c. Rename the latter one to prevent the build error. ../drivers/mfd/lpc_sch.c:25: error: "GPIOBASE" redefined [-Werror] 25 | #define GPIOBASE 0x44 ../arch/mips/include/asm/mach-rc32434/rb.h:32: note: this is the location of the previous definition 32 | #define GPIOBASE 0x050000 Cc: Denis Turischev Fixes: e82c60ae7d3a ("mfd: Introduce lpc_sch for Intel SCH LPC bridge") Signed-off-by: Randy Dunlap Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 027c44b8c8e4140d8dc1633fb32586ab07f1ed3a Author: Andy Shevchenko Date: Wed Mar 3 18:49:44 2021 +0200 mfd: lpc_sch: Partially revert "Add support for Intel Quark X1000" [ Upstream commit 922e8ce883e59b52786b2c11656d84dc58ef084a ] The IRQ support for SCH GPIO is not specific to the Intel Quark SoC. Moreover the IRQ routing is quite interesting there, so while it's needs a special support, the driver haven't it anyway yet. Due to above remove basically redundant code of IRQ support. This reverts commit ec689a8a8155ce8b966bd5d7737a3916f5e48be3. Signed-off-by: Andy Shevchenko Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 52a7e6667133553a51f93076f96c9294314ae44f Author: Michael Chan Date: Sun Sep 5 14:10:59 2021 -0400 bnxt_en: Fix possible unintended driver initiated error recovery [ Upstream commit 1b2b91831983aeac3adcbb469aa8b0dc71453f89 ] If error recovery is already enabled, bnxt_timer() will periodically check the heartbeat register and the reset counter. If we get an error recovery async. notification from the firmware (e.g. change in primary/secondary role), we will immediately read and update the heartbeat register and the reset counter. If the timer for the next health check expires soon after this, we may read the heartbeat register again in quick succession and find that it hasn't changed. This will trigger error recovery unintentionally. The likelihood is small because we also reset fw_health->tmr_counter which will reset the interval for the next health check. But the update is not protected and bnxt_timer() can miss the update and perform the health check without waiting for the full interval. Fix it by only reading the heartbeat register and reset counter in bnxt_async_event_process() if error recovery is trasitioning to the enabled state. Also add proper memory barriers so that when enabling for the first time, bnxt_timer() will see the tmr_counter interval and perform the health check after the full interval has elapsed. Fixes: 7e914027f757 ("bnxt_en: Enable health monitoring.") Reviewed-by: Edwin Peer Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9a3f52f73c04dd8dddf9209fbf555f530b315ec3 Author: Michael Chan Date: Sun Feb 14 18:05:01 2021 -0500 bnxt_en: Improve logging of error recovery settings information. [ Upstream commit f4d95c3c194de04ae7b44f850131321c7ceb9312 ] We currently only log the error recovery settings if it is enabled. In some cases, firmware disables error recovery after it was initially enabled. Without logging anything, the user will not be aware of this change in setting. Log it when error recovery is disabled. Also, change the reset count value from hexadecimal to decimal. Reviewed-by: Edwin Peer Reviewed-by: Pavan Chebbi Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 639a2eddb7310bf6e76377a2e5610184712204a3 Author: Michael Chan Date: Tue Jan 26 01:20:24 2021 -0500 bnxt_en: Convert to use netif_level() helpers. [ Upstream commit 871127e6ab0d6abb904cec81fc022baf6953be1f ] Use the various netif_level() helpers to simplify the C code. This was suggested by Joe Perches. Cc: Joe Perches Signed-off-by: Michael Chan Link: https://lore.kernel.org/r/1611642024-3166-1-git-send-email-michael.chan@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 01cad477a96834c16f76019698aac57c779893b4 Author: Michael Chan Date: Mon Jan 25 02:08:20 2021 -0500 bnxt_en: Consolidate firmware reset event logging. [ Upstream commit 5863b10aa86a5f5f69a25b55a5c15806c834471a ] Combine the three netdev_warn() calls into a single call, printed at the NETIF_MSG_HW log level. Reviewed-by: Vasundhara Volam Signed-off-by: Michael Chan Acked-by: Willem de Bruijn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fad75e046363ebf37c42c04dc8e3f68e0ed4c130 Author: Edwin Peer Date: Mon Jan 25 02:08:13 2021 -0500 bnxt_en: log firmware debug notifications [ Upstream commit a44daa8fcbcf572545c4c1a7908b3fbb38388048 ] Firmware is capable of generating asynchronous debug notifications. The event data is opaque to the driver and is simply logged. Debug notifications can be enabled by turning on hardware status messages using the ethtool msglvl interface. Reviewed-by: Pavan Chebbi Signed-off-by: Edwin Peer Signed-off-by: Michael Chan Acked-by: Willem de Bruijn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f90a34fabaa5f6c62fb0dcf4990c10ad84678eff Author: Michael Chan Date: Sun Sep 5 14:10:57 2021 -0400 bnxt_en: Fix asic.rev in devlink dev info command [ Upstream commit 6fdab8a3ade2adc123bbf5c4fdec3394560b1fb1 ] The current asic.rev is incomplete and does not include the metal revision. Add the metal revision and decode the complete asic revision into the more common and readable form (A0, B0, etc). Fixes: 7154917a12b2 ("bnxt_en: Refactor bnxt_dl_info_get().") Reviewed-by: Edwin Peer Reviewed-by: Somnath Kotur Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 72450231845518503833b8cc1892f44e59dd10e3 Author: Edwin Peer Date: Sun Sep 5 14:10:55 2021 -0400 bnxt_en: fix stored FW_PSID version masks [ Upstream commit 1656db67233e4259281d2ac35b25f712edbbc20b ] The FW_PSID version components are 8 bits wide, not 4. Fixes: db28b6c77f40 ("bnxt_en: Fix devlink info's stored fw.psid version format.") Signed-off-by: Edwin Peer Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit eb635e008cb1d9845e19ac5910c82ff77e660306 Author: Rafał Miłecki Date: Sun Sep 5 19:23:28 2021 +0200 net: dsa: b53: Fix IMP port setup on BCM5301x [ Upstream commit 63f8428b4077de3664eb0b252393c839b0b293ec ] Broadcom's b53 switches have one IMP (Inband Management Port) that needs to be programmed using its own designed register. IMP port may be different than CPU port - especially on devices with multiple CPU ports. For that reason it's required to explicitly note IMP port index and check for it when choosing a register to use. This commit fixes BCM5301x support. Those switches use CPU port 5 while their IMP port is 8. Before this patch b53 was trying to program port 5 with B53_PORT_OVERRIDE_CTRL instead of B53_GMII_PORT_OVERRIDE_CTRL(5). It may be possible to also replace "cpu_port" usages with dsa_is_cpu_port() but that is out of the scope of thix BCM5301x fix. Fixes: 967dd82ffc52 ("net: dsa: b53: Add support for Broadcom RoboSwitch") Signed-off-by: Rafał Miłecki Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 87b34cd6485192777f632f92d592f2a71d8801a6 Author: Willem de Bruijn Date: Sun Sep 5 11:21:09 2021 -0400 ip_gre: validate csum_start only on pull [ Upstream commit 8a0ed250f911da31a2aef52101bc707846a800ff ] The GRE tunnel device can pull existing outer headers in ipge_xmit. This is a rare path, apparently unique to this device. The below commit ensured that pulling does not move skb->data beyond csum_start. But it has a false positive if ip_summed is not CHECKSUM_PARTIAL and thus csum_start is irrelevant. Refine to exclude this. At the same time simplify and strengthen the test. Simplify, by moving the check next to the offending pull, making it more self documenting and removing an unnecessary branch from other code paths. Strengthen, by also ensuring that the transport header is correct and therefore the inner headers will be after skb_reset_inner_headers. The transport header is set to csum_start in skb_partial_csum_set. Link: https://lore.kernel.org/netdev/YS+h%2FtqCJJiQei+W@shredder/ Fixes: 1d011c4803c7 ("ip_gre: add validation for csum_start") Reported-by: Ido Schimmel Suggested-by: Alexander Duyck Signed-off-by: Willem de Bruijn Reviewed-by: Alexander Duyck Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9c98d2bd143420a26d3ba1b096326f28247a058d Author: Dinghao Liu Date: Fri Sep 3 15:35:43 2021 +0800 qlcnic: Remove redundant unlock in qlcnic_pinit_from_rom [ Upstream commit 9ddbc2a00d7f63fa9748f4278643193dac985f2d ] Previous commit 68233c583ab4 removes the qlcnic_rom_lock() in qlcnic_pinit_from_rom(), but remains its corresponding unlock function, which is odd. I'm not very sure whether the lock is missing, or the unlock is redundant. This bug is suggested by a static analysis tool, please advise. Fixes: 68233c583ab4 ("qlcnic: updated reset sequence") Signed-off-by: Dinghao Liu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8c01c620ae61142760d8924ee96a3ff8eec00aa6 Author: Eric Dumazet Date: Fri Sep 3 15:03:43 2021 -0700 fq_codel: reject silly quantum parameters [ Upstream commit c7c5e6ff533fe1f9afef7d2fa46678987a1335a7 ] syzbot found that forcing a big quantum attribute would crash hosts fast, essentially using this: tc qd replace dev eth0 root fq_codel quantum 4294967295 This is because fq_codel_dequeue() would have to loop ~2^31 times in : if (flow->deficit <= 0) { flow->deficit += q->quantum; list_move_tail(&flow->flowchain, &q->old_flows); goto begin; } SFQ max quantum is 2^19 (half a megabyte) Lets adopt a max quantum of one megabyte for FQ_CODEL. Fixes: 4b549a2ef4be ("fq_codel: Fair Queue Codel AQM") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6e2d36f2b1d19bee1096a53e6cbc9e0c0f0b05b4 Author: Benjamin Hesmans Date: Fri Sep 3 15:23:35 2021 +0200 netfilter: socket: icmp6: fix use-after-scope [ Upstream commit 730affed24bffcd1eebd5903171960f5ff9f1f22 ] Bug reported by KASAN: BUG: KASAN: use-after-scope in inet6_ehashfn (net/ipv6/inet6_hashtables.c:40) Call Trace: (...) inet6_ehashfn (net/ipv6/inet6_hashtables.c:40) (...) nf_sk_lookup_slow_v6 (net/ipv6/netfilter/nf_socket_ipv6.c:91 net/ipv6/netfilter/nf_socket_ipv6.c:146) It seems that this bug has already been fixed by Eric Dumazet in the past in: commit 78296c97ca1f ("netfilter: xt_socket: fix a stack corruption bug") But a variant of the same issue has been introduced in commit d64d80a2cde9 ("netfilter: x_tables: don't extract flow keys on early demuxed sks in socket match") `daddr` and `saddr` potentially hold a reference to ipv6_var that is no longer in scope when the call to `nf_socket_get_sock_v6` is made. Fixes: d64d80a2cde9 ("netfilter: x_tables: don't extract flow keys on early demuxed sks in socket match") Acked-by: Matthieu Baerts Signed-off-by: Benjamin Hesmans Reviewed-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit c361c955609a48d993f07caa93fdcc516de20849 Author: Rafał Miłecki Date: Thu Sep 2 10:30:51 2021 +0200 net: dsa: b53: Set correct number of ports in the DSA struct [ Upstream commit d12e1c4649883e8ca5e8ff341e1948b3b6313259 ] Setting DSA_MAX_PORTS caused DSA to call b53 callbacks (e.g. b53_disable_port() during dsa_register_switch()) for invalid (non-existent) ports. That made b53 modify unrelated registers and is one of reasons for a broken BCM5301x support. This problem exists for years but DSA_MAX_PORTS usage has changed few times. It seems the most accurate to reference commit dropping dsa_switch_alloc() in the Fixes tag. Fixes: 7e99e3470172 ("net: dsa: remove dsa_switch_alloc helper") Signed-off-by: Rafał Miłecki Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0db7e0d9f67da8789d2aea12e0464e40359f9bd4 Author: Rafał Miłecki Date: Thu Sep 2 10:30:50 2021 +0200 net: dsa: b53: Fix calculating number of switch ports [ Upstream commit cdb067d31c0fe4cce98b9d15f1f2ef525acaa094 ] It isn't true that CPU port is always the last one. Switches BCM5301x have 9 ports (port 6 being inactive) and they use port 5 as CPU by default (depending on design some other may be CPU ports too). A more reliable way of determining number of ports is to check for the last set bit in the "enabled_ports" bitfield. This fixes b53 internal state, it will allow providing accurate info to the DSA and is required to fix BCM5301x support. Fixes: 967dd82ffc52 ("net: dsa: b53: Add support for Broadcom RoboSwitch") Signed-off-by: Rafał Miłecki Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f89b0d032f86df6174f4c542ccb0bcdc2630718d Author: Ziyang Xuan Date: Thu Sep 2 16:36:09 2021 +0800 net: hso: add failure handler for add_net_device [ Upstream commit ecdc28defc46af476566fffd9e5cb4495a2f176e ] If the network devices connected to the system beyond HSO_MAX_NET_DEVICES. add_net_device() in hso_create_net_device() will be failed for the network_table is full. It will lead to business failure which rely on network_table, for example, hso_suspend() and hso_resume(). It will also lead to memory leak because resource release process can not search the hso_device object from network_table in hso_free_interface(). Add failure handler for add_net_device() in hso_create_net_device() to solve the above problems. Fixes: 72dc1c096c70 ("HSO: add option hso driver") Signed-off-by: Ziyang Xuan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f450958f7ff8e99a3e511ae4732dbe67f54c5223 Author: Matthieu Baerts Date: Wed Sep 1 10:15:37 2021 -0700 selftests: mptcp: clean tmp files in simult_flows [ Upstream commit bfd862a7e9318dd906844807a713d27cdd1a72b1 ] '$cin' and '$sin' variables are local to a function: they are then not available from the cleanup trap. Instead, we need to use '$large' and '$small' that are not local and defined just before setting the trap. Without this patch, running this script in a loop might cause a: write: No space left on device issue. Fixes: 1a418cb8e888 ("mptcp: simult flow self-tests") Acked-by: Paolo Abeni Signed-off-by: Matthieu Baerts Signed-off-by: Mat Martineau Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5711ced58eb4ad37b3b71409294505abe572e26b Author: Linus Walleij Date: Tue Aug 31 20:50:50 2021 +0200 net: dsa: tag_rtl4_a: Fix egress tags [ Upstream commit 0e90dfa7a8d817db755c7b5d89d77b9c485e4180 ] I noticed that only port 0 worked on the RTL8366RB since we started to use custom tags. It turns out that the format of egress custom tags is actually different from ingress custom tags. While the lower bits just contain the port number in ingress tags, egress tags need to indicate destination port by setting the bit for the corresponding port. It was working on port 0 because port 0 added 0x00 as port number in the lower bits, and if you do this the packet appears at all ports, including the intended port. Ooops. Fix this and all ports work again. Use the define for shifting the "type A" into place while we're at it. Tested on the D-Link DIR-685 by sending traffic to each of the ports in turn. It works. Fixes: 86dd9868b878 ("net: dsa: tag_rtl4_a: Support also egress tags") Cc: DENG Qingfang Cc: Mauri Sandberg Signed-off-by: Linus Walleij Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b167a0cec18772a52c04445b1c46f62f737d10e3 Author: Christophe JAILLET Date: Fri Aug 20 17:38:13 2021 +0200 gpio: mpc8xxx: Use 'devm_gpiochip_add_data()' to simplify the code and avoid a leak [ Upstream commit 889a1b3f35db6ba5ba6a0c23a3a55594570b6a17 ] If an error occurs after a 'gpiochip_add_data()' call it must be undone by a corresponding 'gpiochip_remove()' as already done in the remove function. To simplify the code a fix a leak in the error handling path of the probe, use the managed version instead (i.e. 'devm_gpiochip_add_data()') Fixes: 698b8eeaed72 ("gpio/mpc8xxx: change irq handler from chained to normal") Signed-off-by: Christophe JAILLET Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit f86956143da9a32f5f7c5cef248563c65dbee47c Author: Christophe JAILLET Date: Fri Aug 20 17:37:55 2021 +0200 gpio: mpc8xxx: Fix a resources leak in the error handling path of 'mpc8xxx_probe()' [ Upstream commit 555bda42b0c1a5ffb72d3227c043e8afde778f1f ] Commit 698b8eeaed72 ("gpio/mpc8xxx: change irq handler from chained to normal") has introduced a new 'goto err;' at the very end of the function, but has not updated the error handling path accordingly. Add the now missing 'irq_domain_remove()' call which balances a previous 'irq_domain_create_linear() call. Fixes: 698b8eeaed72 ("gpio/mpc8xxx: change irq handler from chained to normal") Signed-off-by: Christophe JAILLET Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit c2b52963fd0c2ceda4c75df66ff4a3129f148436 Author: Arnaldo Carvalho de Melo Date: Wed Aug 25 11:50:37 2021 -0300 perf bench inject-buildid: Handle writen() errors [ Upstream commit edf7b4a2d85e37a1ee77156bddaed4aa6af9c5e1 ] The build on fedora:35 and fedora:rawhide with clang is failing with: 49 41.00 fedora:35 : FAIL clang version 13.0.0 (Fedora 13.0.0~rc1-1.fc35) bench/inject-buildid.c:351:6: error: variable 'len' set but not used [-Werror,-Wunused-but-set-variable] u64 len = 0; ^ 1 error generated. make[3]: *** [/git/perf-5.14.0-rc7/tools/build/Makefile.build:139: bench] Error 2 50 41.11 fedora:rawhide : FAIL clang version 13.0.0 (Fedora 13.0.0~rc1-1.fc35) bench/inject-buildid.c:351:6: error: variable 'len' set but not used [-Werror,-Wunused-but-set-variable] u64 len = 0; ^ 1 error generated. make[3]: *** [/git/perf-5.14.0-rc7/tools/build/Makefile.build:139: bench] Error 2 That 'len' variable is not used at all, so just make sure all the synthesize_RECORD() routines return ssize_t to propagate the writen() return, as it may fail, ditch the 'ret' var and bail out if those routines fail. Fixes: 0bf02a0d80427f26 ("perf bench: Add build-id injection benchmark") Acked-by: Namhyung Kim Link: http://lore.kernel.org/lkml/CAM9d7cgEZNSor+B+7Y2C+QYGme_v5aH0Zn0RLfxoQ+Fy83EHrg@mail.gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 5a20adc388114bdfe5f8c1fee39703f840a1ddbb Author: Li Huafei Date: Mon Aug 23 21:43:40 2021 +0800 perf unwind: Do not overwrite FEATURE_CHECK_LDFLAGS-libunwind-{x86,aarch64} [ Upstream commit cdf32b44678c382a31dc183d9a767306915cda7b ] When setting LIBUNWIND_DIR, we first set FEATURE_CHECK_LDFLAGS-libunwind-{aarch64,x86} = -L$(LIBUNWIND_DIR)/lib. This happens a bit before, the overwritting, in: libunwind_arch_set_flags = $(eval $(libunwind_arch_set_flags_code)) define libunwind_arch_set_flags_code FEATURE_CHECK_CFLAGS-libunwind-$(1) = -I$(LIBUNWIND_DIR)/include FEATURE_CHECK_LDFLAGS-libunwind-$(1) = -L$(LIBUNWIND_DIR)/lib endef ifdef LIBUNWIND_DIR LIBUNWIND_CFLAGS = -I$(LIBUNWIND_DIR)/include LIBUNWIND_LDFLAGS = -L$(LIBUNWIND_DIR)/lib LIBUNWIND_ARCHS = x86 x86_64 arm aarch64 debug-frame-arm debug-frame-aarch64 $(foreach libunwind_arch,$(LIBUNWIND_ARCHS),$(call libunwind_arch_set_flags,$(libunwind_arch))) endif Look at that 'foreach' on all the LIBUNWIND_ARCHS. After commit 5c4d7c82c0dc ("perf unwind: Do not put libunwind-{x86,aarch64} in FEATURE_TESTS_BASIC"), FEATURE_CHECK_LDFLAGS-libunwind-{x86,aarch64} is overwritten. As a result, the remote libunwind libraries cannot be searched from $(LIBUNWIND_DIR)/lib directory during feature check tests. Fix it with variable appending. Before this patch: perf$ make VF=1 LIBUNWIND_DIR=/opt/libunwind_aarch64 BUILD: Doing 'make -j16' parallel build ... ... libopencsd: [ OFF ] ... libunwind-x86: [ OFF ] ... libunwind-x86_64: [ OFF ] ... libunwind-arm: [ OFF ] ... libunwind-aarch64: [ OFF ] ... libunwind-debug-frame: [ OFF ] ... libunwind-debug-frame-arm: [ OFF ] ... libunwind-debug-frame-aarch64: [ OFF ] ... cxx: [ OFF ] perf$ cat ../build/feature/test-libunwind-aarch64.make.output /usr/bin/ld: cannot find -lunwind-aarch64 /usr/bin/ld: cannot find -lunwind-aarch64 collect2: error: ld returned 1 exit status After this patch: perf$ make VF=1 LIBUNWIND_DIR=/opt/libunwind_aarch64 BUILD: Doing 'make -j16' parallel build ... libopencsd: [ OFF ] ... libunwind-x86: [ OFF ] ... libunwind-x86_64: [ OFF ] ... libunwind-arm: [ OFF ] ... libunwind-aarch64: [ on ] ... libunwind-debug-frame: [ OFF ] ... libunwind-debug-frame-arm: [ OFF ] ... libunwind-debug-frame-aarch64: [ OFF ] ... cxx: [ OFF ] perf$ cat ../build/feature/test-libunwind-aarch64.make.output perf$ ldd ./perf linux-vdso.so.1 (0x00007ffdf07da000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f30953dc000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f30951d4000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3094e36000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3094c32000) libelf.so.1 => /usr/lib/x86_64-linux-gnu/libelf.so.1 (0x00007f3094a18000) libdw.so.1 => /usr/lib/x86_64-linux-gnu/libdw.so.1 (0x00007f30947cc000) libunwind-x86_64.so.8 => /usr/lib/x86_64-linux-gnu/libunwind-x86_64.so.8 (0x00007f30945ad000) libunwind.so.8 => /usr/lib/x86_64-linux-gnu/libunwind.so.8 (0x00007f3094392000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f309416c000) libunwind-aarch64.so.8 => not found libslang.so.2 => /lib/x86_64-linux-gnu/libslang.so.2 (0x00007f3093c8a000) libpython2.7.so.1.0 => /usr/local/lib/libpython2.7.so.1.0 (0x00007f309386b000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f309364e000) libnuma.so.1 => /usr/lib/x86_64-linux-gnu/libnuma.so.1 (0x00007f3093443000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3093052000) /lib64/ld-linux-x86-64.so.2 (0x00007f3096097000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f3092e42000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f3092c3f000) Fixes: 5c4d7c82c0dceccf ("perf unwind: Do not put libunwind-{x86,aarch64} in FEATURE_TESTS_BASIC") Signed-off-by: Li Huafei Cc: Alexander Shishkin Cc: He Kuang Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Zhang Jinhao Link: http://lore.kernel.org/lkml/20210823134340.60955-1-lihuafei1@huawei.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit f5176a0798bd286a1fb2061a28f136fe1fdb0cc2 Author: Randy Dunlap Date: Mon Aug 16 14:05:33 2021 -0700 ARC: export clear_user_page() for modules [ Upstream commit 6b5ff0405e4190f23780362ea324b250bc495683 ] 0day bot reports a build error: ERROR: modpost: "clear_user_page" [drivers/media/v4l2-core/videobuf-dma-sg.ko] undefined! so export it in arch/arc/ to fix the build error. In most ARCHes, clear_user_page() is a macro. OTOH, in a few ARCHes it is a function and needs to be exported. PowerPC exported it in 2004. It looks like nds32 and nios2 still need to have it exported. Fixes: 4102b53392d63 ("ARC: [mm] Aliasing VIPT dcache support 2/4") Signed-off-by: Randy Dunlap Reported-by: kernel test robot Cc: Guenter Roeck Cc: linux-snps-arc@lists.infradead.org Signed-off-by: Vineet Gupta Signed-off-by: Sasha Levin commit 9da1fb128c5492fb7204eabf32d2f80575beed23 Author: Christophe JAILLET Date: Sat Aug 21 09:58:45 2021 +0200 mtd: rawnand: cafe: Fix a resource leak in the error handling path of 'cafe_nand_probe()' [ Upstream commit 6b430c7595e4eb95fae8fb54adc3c3ce002e75ae ] A successful 'init_rs_non_canonical()' call should be balanced by a corresponding 'free_rs()' call in the error handling path of the probe, as already done in the remove function. Update the error handling path accordingly. Fixes: 8c61b7a7f4d4 ("[MTD] [NAND] Use rslib for CAFÉ ECC") Signed-off-by: Christophe JAILLET Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/fd313d3fb787458bcc73189e349f481133a2cdc9.1629532640.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit 5402b31c0c46fde28bbbc7993ce0d2823847d80c Author: Andy Shevchenko Date: Fri Aug 13 18:36:19 2021 +0300 PCI: Sync __pci_register_driver() stub for CONFIG_PCI=n [ Upstream commit 817f9916a6e96ae43acdd4e75459ef4f92d96eb1 ] The CONFIG_PCI=y case got a new parameter long time ago. Sync the stub as well. [bhelgaas: add parameter names] Fixes: 725522b5453d ("PCI: add the sysfs driver name to all modules") Link: https://lore.kernel.org/r/20210813153619.89574-1-andriy.shevchenko@linux.intel.com Reported-by: kernel test robot Signed-off-by: Andy Shevchenko Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit a957d82b23161f175b124ef30b005a56e84e7ef2 Author: Oliver Upton Date: Wed Aug 18 20:21:31 2021 +0000 KVM: arm64: Handle PSCI resets before userspace touches vCPU state [ Upstream commit 6826c6849b46aaa91300201213701eb861af4ba0 ] The CPU_ON PSCI call takes a payload that KVM uses to configure a destination vCPU to run. This payload is non-architectural state and not exposed through any existing UAPI. Effectively, we have a race between CPU_ON and userspace saving/restoring a guest: if the target vCPU isn't ran again before the VMM saves its state, the requested PC and context ID are lost. When restored, the target vCPU will be runnable and start executing at its old PC. We can avoid this race by making sure the reset payload is serviced before userspace can access a vCPU's state. Fixes: 358b28f09f0a ("arm/arm64: KVM: Allow a VCPU to fully reset itself") Signed-off-by: Oliver Upton Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210818202133.1106786-3-oupton@google.com Signed-off-by: Sasha Levin commit 53921242cf995a6c9867154696ba9f07b6bd7957 Author: Oliver Upton Date: Wed Aug 18 20:21:30 2021 +0000 KVM: arm64: Fix read-side race on updates to vcpu reset state [ Upstream commit 6654f9dfcb88fea3b9affc180dc3c04333d0f306 ] KVM correctly serializes writes to a vCPU's reset state, however since we do not take the KVM lock on the read side it is entirely possible to read state from two different reset requests. Cure the race for now by taking the KVM lock when reading the reset_state structure. Fixes: 358b28f09f0a ("arm/arm64: KVM: Allow a VCPU to fully reset itself") Signed-off-by: Oliver Upton Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210818202133.1106786-2-oupton@google.com Signed-off-by: Sasha Levin commit b9b89da56af761fbb12da26ca5eb0c068446ec16 Author: Zhihao Cheng Date: Tue Aug 17 19:48:57 2021 +0800 mtd: mtdconcat: Check _read, _write callbacks existence before assignment [ Upstream commit a89d69a44e282be95ae76125dddc79515541efeb ] Since 2431c4f5b46c3 ("mtd: Implement mtd_{read,write}() as wrappers around mtd_{read,write}_oob()") don't allow _write|_read and _write_oob|_read_oob existing at the same time, we should check the existence of callbacks "_read and _write" from subdev's master device (We can trust master device since it has been registered) before assigning, otherwise following warning occurs while making concatenated device: WARNING: CPU: 2 PID: 6728 at drivers/mtd/mtdcore.c:595 add_mtd_device+0x7f/0x7b0 Fixes: 2431c4f5b46c3 ("mtd: Implement mtd_{read,write}() around ...") Signed-off-by: Zhihao Cheng Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210817114857.2784825-3-chengzhihao1@huawei.com Signed-off-by: Sasha Levin commit 812cbb143c12596ad2f2cc289e73a5afe462675f Author: Zhihao Cheng Date: Tue Aug 17 19:48:56 2021 +0800 mtd: mtdconcat: Judge callback existence based on the master [ Upstream commit f9e109a209a8e01e16f37e1252304f1eb3908be4 ] Since commit 46b5889cc2c5("mtd: implement proper partition handling") applied, mtd partition device won't hold some callback functions, such as _block_isbad, _block_markbad, etc. Besides, function mtd_block_isbad() will get mtd device's master mtd device, then invokes master mtd device's callback function. So, following process may result mtd_block_isbad() always return 0, even though mtd device has bad blocks: 1. Split a mtd device into 3 partitions: PA, PB, PC [ Each mtd partition device won't has callback function _block_isbad(). ] 2. Concatenate PA and PB as a new mtd device PN [ mtd_concat_create() finds out each subdev has no callback function _block_isbad(), so PN won't be assigned callback function concat_block_isbad(). ] Then, mtd_block_isbad() checks "!master->_block_isbad" is true, will always return 0. Reproducer: // reproduce.c static int __init init_diy_module(void) { struct mtd_info *mtd[2]; struct mtd_info *mtd_combine = NULL; mtd[0] = get_mtd_device_nm("NAND simulator partition 0"); if (!mtd[0]) { pr_err("cannot find mtd1\n"); return -EINVAL; } mtd[1] = get_mtd_device_nm("NAND simulator partition 1"); if (!mtd[1]) { pr_err("cannot find mtd2\n"); return -EINVAL; } put_mtd_device(mtd[0]); put_mtd_device(mtd[1]); mtd_combine = mtd_concat_create(mtd, 2, "Combine mtd"); if (mtd_combine == NULL) { pr_err("combine failed\n"); return -EINVAL; } mtd_device_register(mtd_combine, NULL, 0); pr_info("Combine success\n"); return 0; } 1. ID="0x20,0xac,0x00,0x15" 2. modprobe nandsim id_bytes=$ID parts=50,100 badblocks=100 3. insmod reproduce.ko 4. flash_erase /dev/mtd3 0 0 libmtd: error!: MEMERASE64 ioctl failed for eraseblock 100 (mtd3) error 5 (Input/output error) // Should be "flash_erase: Skipping bad block at 00c80000" Fixes: 46b5889cc2c54bac ("mtd: implement proper partition handling") Signed-off-by: Zhihao Cheng Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210817114857.2784825-2-chengzhihao1@huawei.com Signed-off-by: Sasha Levin commit e8dfc446a16a81b5a12c87de7367d79ba3ff8b54 Author: Masami Hiramatsu Date: Tue Aug 10 11:07:14 2021 +0900 tracing/boot: Fix a hist trigger dependency for boot time tracing [ Upstream commit 6fe7c745f2acb73e4cc961d7f91125eef5a8861f ] Fixes a build error when CONFIG_HIST_TRIGGERS=n with boot-time tracing. Since the trigger_process_regex() is defined only when CONFIG_HIST_TRIGGERS=y, if it is disabled, the 'actions' event option also must be disabled. Link: https://lkml.kernel.org/r/162856123376.203126.582144262622247352.stgit@devnote2 Fixes: 81a59555ff15 ("tracing/boot: Add per-event settings") Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 87479b10eb72f82aa45e8dc6a3dd9bfaec38f9d7 Author: Matthias Schiffer Date: Fri Jul 16 12:00:48 2021 +0200 mfd: tqmx86: Clear GPIO IRQ resource when no IRQ is set [ Upstream commit a946506c48f3bd09363c9d2b0a178e55733bcbb6 ] The driver was registering IRQ 0 when no IRQ was set. This leads to warnings with newer kernels. Clear the resource flags, so no resource is registered at all in this case. Fixes: 2f17dd34ffed ("mfd: tqmx86: IO controller with I2C, Wachdog and GPIO") Signed-off-by: Matthias Schiffer Reviewed-by: Andrew Lunn Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit f10f727cf9f452909be535a4e2db51baca7dff41 Author: Dan Carpenter Date: Thu Aug 12 10:00:04 2021 +0300 PCI: Fix pci_dev_str_match_path() alloc while atomic bug [ Upstream commit 7eb6ea4148579b85540a41d57bcec315b8af8ff8 ] pci_dev_str_match_path() is often called with a spinlock held so the allocation has to be atomic. The call tree is: pci_specified_resource_alignment() <-- takes spin_lock(); pci_dev_str_match() pci_dev_str_match_path() Fixes: 45db33709ccc ("PCI: Allow specifying devices using a base bus and path of devfns") Link: https://lore.kernel.org/r/20210812070004.GC31863@kili Signed-off-by: Dan Carpenter Signed-off-by: Bjorn Helgaas Reviewed-by: Logan Gunthorpe Signed-off-by: Sasha Levin commit ed44be1cbe5e1b3a032c5e20e4c4e6a6378c8bcd Author: Anshuman Khandual Date: Wed Aug 11 16:41:15 2021 +0530 KVM: arm64: Restrict IPA size to maximum 48 bits on 4K and 16K page size [ Upstream commit 5e5df9571c319fb107d7a523cc96fcc99961ee70 ] Even though ID_AA64MMFR0.PARANGE reports 52 bit PA size support, it cannot be enabled as guest IPA size on 4K or 16K page size configurations. Hence kvm_ipa_limit must be restricted to 48 bits. This change achieves required IPA capping. Before the commit c9b69a0cf0b4 ("KVM: arm64: Don't constrain maximum IPA size based on host configuration"), the problem here would have been just latent via PHYS_MASK_SHIFT (which earlier in turn capped kvm_ipa_limit), which remains capped at 48 bits on 4K and 16K configs. Cc: Marc Zyngier Cc: James Morse Cc: Alexandru Elisei Cc: Suzuki K Poulose Cc: Catalin Marinas Cc: Will Deacon Cc: linux-arm-kernel@lists.infradead.org Cc: kvmarm@lists.cs.columbia.edu Cc: linux-kernel@vger.kernel.org Fixes: c9b69a0cf0b4 ("KVM: arm64: Don't constrain maximum IPA size based on host configuration") Signed-off-by: Anshuman Khandual Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/1628680275-16578-1-git-send-email-anshuman.khandual@arm.com Signed-off-by: Sasha Levin commit 62f813769f50bb0010ab9a63c021d2af39d156e4 Author: Pavel Skripkin Date: Tue Aug 10 15:59:20 2021 +0300 netfilter: nft_ct: protect nft_ct_pcpu_template_refcnt with mutex [ Upstream commit e3245a7b7b34bd2e97f744fd79463add6e9d41f4 ] Syzbot hit use-after-free in nf_tables_dump_sets. The problem was in missing lock protection for nft_ct_pcpu_template_refcnt. Before commit f102d66b335a ("netfilter: nf_tables: use dedicated mutex to guard transactions") all transactions were serialized by global mutex, but then global mutex was changed to local per netnamespace commit_mutex. This change causes use-after-free bug, when 2 netnamespaces concurently changing nft_ct_pcpu_template_refcnt without proper locking. Fix it by adding nft_ct_pcpu_mutex and protect all nft_ct_pcpu_template_refcnt changes with it. Fixes: f102d66b335a ("netfilter: nf_tables: use dedicated mutex to guard transactions") Reported-and-tested-by: syzbot+649e339fa6658ee623d3@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin Acked-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 1cf43a1e5782167cff8afcc35074994517436269 Author: Gustavo A. R. Silva Date: Fri Mar 5 02:42:09 2021 -0600 netfilter: Fix fall-through warnings for Clang [ Upstream commit c2168e6bd7ec50cedb69b3be1ba6146e28893c69 ] In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple warnings by explicitly adding multiple break statements instead of just letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Acked-by: Florian Westphal Signed-off-by: Gustavo A. R. Silva Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 9e89c22d1c949d7123a2edd8abc8e18f24895e80 Author: Rob Herring Date: Tue Aug 3 15:56:56 2021 -0600 PCI: iproc: Fix BCMA probe resource handling [ Upstream commit aeaea8969b402e0081210cc9144404d13996efed ] In commit 7ef1c871da16 ("PCI: iproc: Use pci_parse_request_of_pci_ranges()"), calling devm_request_pci_bus_resources() was dropped from the common iProc probe code, but is still needed for BCMA bus probing. Without it, there will be lots of warnings like this: pci 0000:00:00.0: BAR 8: no space for [mem size 0x00c00000] pci 0000:00:00.0: BAR 8: failed to assign [mem size 0x00c00000] Add back calling devm_request_pci_bus_resources() and adding the resources to pci_host_bridge.windows for BCMA bus probe. Link: https://lore.kernel.org/r/20210803215656.3803204-2-robh@kernel.org Fixes: 7ef1c871da16 ("PCI: iproc: Use pci_parse_request_of_pci_ranges()") Reported-by: Rafał Miłecki Tested-by: Rafał Miłecki Signed-off-by: Rob Herring Signed-off-by: Lorenzo Pieralisi Cc: Srinath Mannam Cc: Roman Bacik Cc: Bharat Gooty Cc: Abhishek Shah Cc: Jitendra Bhivare Cc: Ray Jui Cc: Florian Fainelli Cc: BCM Kernel Feedback Cc: Scott Branden Cc: Lorenzo Pieralisi Cc: "Krzysztof Wilczyński" Cc: Bjorn Helgaas Signed-off-by: Sasha Levin commit b1f3be0c302a75ce2c712b9b5da930888426d686 Author: Rob Herring Date: Tue Aug 3 15:56:55 2021 -0600 PCI: of: Don't fail devm_pci_alloc_host_bridge() on missing 'ranges' [ Upstream commit d277f6e88c88729b1d57d40bbfb00d0bfc961972 ] Commit 669cbc708122 ("PCI: Move DT resource setup into devm_pci_alloc_host_bridge()") made devm_pci_alloc_host_bridge() fail on any DT resource parsing errors, but Broadcom iProc uses devm_pci_alloc_host_bridge() on BCMA bus devices that don't have DT resources. In particular, there is no 'ranges' property. Fix iProc by making 'ranges' optional. If 'ranges' is required by a platform, there's going to be more errors latter on if it is missing. Link: https://lore.kernel.org/r/20210803215656.3803204-1-robh@kernel.org Fixes: 669cbc708122 ("PCI: Move DT resource setup into devm_pci_alloc_host_bridge()") Reported-by: Rafał Miłecki Tested-by: Rafał Miłecki Signed-off-by: Rob Herring Signed-off-by: Lorenzo Pieralisi Acked-by: Bjorn Helgaas Cc: Srinath Mannam Cc: Roman Bacik Cc: Bharat Gooty Cc: Abhishek Shah Cc: Jitendra Bhivare Cc: Ray Jui Cc: Florian Fainelli Cc: BCM Kernel Feedback Cc: Scott Branden Cc: Bjorn Helgaas Cc: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit 063c3d980d78484996cfcfe299b5111b9dd6f03d Author: Linus Walleij Date: Thu Jul 15 13:36:36 2021 +0200 backlight: ktd253: Stabilize backlight [ Upstream commit daa37361518bf2d1f591bbdaa7c68b2a43d7af48 ] Remove interrupt disablement during backlight setting. It is way to dangerous and makes platforms instable by having it miss vblank IRQs leading to the graphics derailing. The code is using ndelay() which is not available on platforms such as ARM and will result in 32 * udelay(1) which is substantial. Add some code to detect if an interrupt occurs during the tight loop and in that case just redo it from the top. Fixes: 5317f37e48b9 ("backlight: Add Kinetic KTD253 backlight driver") Cc: Stephan Gerhold Reported-by: newbyte@disroot.org Reviewed-by: Daniel Thompson Signed-off-by: Linus Walleij Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 00303e459251c31d1206f261d598ab94ebd8cbaa Author: Hans de Goede Date: Tue Jun 29 19:12:39 2021 +0200 mfd: axp20x: Update AXP288 volatile ranges [ Upstream commit f949a9ebce7a18005266b859a17f10c891bb13d7 ] On Cherry Trail devices with an AXP288 PMIC the external SD-card slot used the AXP's DLDO2 as card-voltage and either DLDO3 or GPIO1LDO (GPIO1 pin in low noise LDO mode) as signal-voltage. These regulators are turned on/off and in case of the signal-voltage also have their output-voltage changed by the _PS0 and _PS3 power- management ACPI methods on the MMC-controllers ACPI fwnode as well as by the _DSM ACPI method for changing the signal voltage. The AML code implementing these methods is directly accessing the PMIC through ACPI I2C OpRegion accesses, instead of using the special PMIC OpRegion handled by drivers/acpi/pmic/intel_pmic_xpower.c . This means that the contents of the involved PMIC registers can change without the change being made through the regmap interface, so regmap should not cache the contents of these registers. Mark the regulator power on/off, the regulator voltage control and the GPIO1 control registers as volatile, to avoid regmap caching them. Specifically this fixes an issue on some models where the i915 driver toggles another LDO using the same on/off register on/off through MIPI sequences (through intel_soc_pmic_exec_mipi_pmic_seq_element()) which then writes back a cached on/off register-value where the card-voltage is off causing the external sdcard slot to stop working when the screen goes blank, or comes back on again. The regulator register-range now marked volatile also includes the buck regulator control registers. This is done on purpose these are normally not touched by the AML code, but they are updated directly by the SoC's PUNIT which means that they may also change without going through regmap. Note the AXP288 PMIC is only used on Bay- and Cherry-Trail platforms, so even though this is an ACPI specific problem there is no need to make the new volatile ranges conditional since these platforms always use ACPI. Fixes: dc91c3b6fe66 ("mfd: axp20x: Mark AXP20X_VBUS_IPSOUT_MGMT as volatile") Fixes: cd53216625a0 ("mfd: axp20x: Fix axp288 volatile ranges") Reported-and-tested-by: Clamshell Signed-off-by: Hans de Goede Reviewed-by: Chen-Yu Tsai Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit ab7cf225016159bc2c3590be6fa12965565d903b Author: Ilya Leoshkevich Date: Tue Sep 7 11:58:59 2021 +0200 s390/bpf: Fix branch shortening during codegen pass commit 1511df6f5e9ef32826f20db2ee81f8527154dc14 upstream. EMIT6_PCREL() macro assumes that the previous pass generated 6 bytes of code, which is not the case if branch shortening took place. Fix by using jit->prg, like all the other EMIT6_PCREL_*() macros. Reported-by: Johan Almbladh Fixes: 4e9b4a6883dd ("s390/bpf: Use relative long branches") Signed-off-by: Ilya Leoshkevich Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 4320c222c2ffe778a8aff5b8bc4ac33af6d54eba Author: Ilya Leoshkevich Date: Tue Sep 7 13:41:16 2021 +0200 s390/bpf: Fix 64-bit subtraction of the -0x80000000 constant commit 6e61dc9da0b7a0d91d57c2e20b5ea4fd2d4e7e53 upstream. The JIT uses agfi for subtracting constants, but -(-0x80000000) cannot be represented as a 32-bit signed binary integer. Fix by using algfi in this particular case. Reported-by: Johan Almbladh Fixes: 054623105728 ("s390/bpf: Add s390x eBPF JIT compiler backend") Reviewed-by: Heiko Carstens Signed-off-by: Ilya Leoshkevich Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit d92d3a9c2b6541f29f800fc2bd44620578b8f8a6 Author: Ilya Leoshkevich Date: Mon Sep 6 15:04:14 2021 +0200 s390/bpf: Fix optimizing out zero-extensions commit db7bee653859ef7179be933e7d1384644f795f26 upstream. Currently the JIT completely removes things like `reg32 += 0`, however, the BPF_ALU semantics requires the target register to be zero-extended in such cases. Fix by optimizing out only the arithmetic operation, but not the subsequent zero-extension. Reported-by: Johan Almbladh Fixes: 054623105728 ("s390/bpf: Add s390x eBPF JIT compiler backend") Reviewed-by: Heiko Carstens Signed-off-by: Ilya Leoshkevich Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 4a933932033854fc7be495ed966e47a42132a8c4 Author: Yang Li Date: Mon Jun 7 16:40:36 2021 +0800 NTB: perf: Fix an error code in perf_setup_inbuf() [ Upstream commit 0097ae5f7af5684f961a5f803ff7ad3e6f933668 ] When the function IS_ALIGNED() returns false, the value of ret is 0. So, we set ret to -EINVAL to indicate this error. Clean up smatch warning: drivers/ntb/test/ntb_perf.c:602 perf_setup_inbuf() warn: missing error code 'ret'. Reported-by: Abaci Robot Signed-off-by: Yang Li Reviewed-by: Serge Semin Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit ce660d6dfcdd2836883673154835636438928929 Author: Yang Li Date: Mon Jun 7 13:56:20 2021 +0800 NTB: Fix an error code in ntb_msit_probe() [ Upstream commit 319f83ac98d7afaabab84ce5281a819a358b9895 ] When the value of nm->isr_ctx is false, the value of ret is 0. So, we set ret to -ENOMEM to indicate this error. Clean up smatch warning: drivers/ntb/test/ntb_msi_test.c:373 ntb_msit_probe() warn: missing error code 'ret'. Reported-by: Abaci Robot Signed-off-by: Yang Li Reviewed-by: Logan Gunthorpe Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit e76ccbdedbddaf14c65b50bbf2ffe8118958d15e Author: Yang Li Date: Fri Sep 3 14:42:33 2021 +0800 ethtool: Fix an error code in cxgb2.c [ Upstream commit 7db8263a12155c7ae4ad97e850f1e499c73765fc ] When adapter->registered_device_map is NULL, the value of err is uncertain, we set err to -EINVAL to avoid ambiguity. Clean up smatch warning: drivers/net/ethernet/chelsio/cxgb/cxgb2.c:1114 init_one() warn: missing error code 'err' Reported-by: Abaci Robot Signed-off-by: Yang Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 70ac967a7b886329f7308b966a690f9d4a94f958 Author: Vishal Aslot Date: Wed Aug 18 11:57:51 2021 -0500 PCI: ibmphp: Fix double unmap of io_mem [ Upstream commit faa2e05ad0dccf37f995bcfbb8d1980d66c02c11 ] ebda_rsrc_controller() calls iounmap(io_mem) on the error path. Its caller, ibmphp_access_ebda(), also calls iounmap(io_mem) on good and error paths. Remove the iounmap(io_mem) invocation from ebda_rsrc_controller(). [bhelgaas: remove item from TODO] Link: https://lore.kernel.org/r/20210818165751.591185-1-os.vaslot@gmail.com Signed-off-by: Vishal Aslot Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 9ae759a36b6145df9c3cca198f8fcb198044ab34 Author: Paolo Valente Date: Mon Aug 2 16:13:52 2021 +0200 block, bfq: honor already-setup queue merges [ Upstream commit 2d52c58b9c9bdae0ca3df6a1eab5745ab3f7d80b ] The function bfq_setup_merge prepares the merging between two bfq_queues, say bfqq and new_bfqq. To this goal, it assigns bfqq->new_bfqq = new_bfqq. Then, each time some I/O for bfqq arrives, the process that generated that I/O is disassociated from bfqq and associated with new_bfqq (merging is actually a redirection). In this respect, bfq_setup_merge increases new_bfqq->ref in advance, adding the number of processes that are expected to be associated with new_bfqq. Unfortunately, the stable-merging mechanism interferes with this setup. After bfqq->new_bfqq has been set by bfq_setup_merge, and before all the expected processes have been associated with bfqq->new_bfqq, bfqq may happen to be stably merged with a different queue than the current bfqq->new_bfqq. In this case, bfqq->new_bfqq gets changed. So, some of the processes that have been already accounted for in the ref counter of the previous new_bfqq will not be associated with that queue. This creates an unbalance, because those references will never be decremented. This commit fixes this issue by reestablishing the previous, natural behaviour: once bfqq->new_bfqq has been set, it will not be changed until all expected redirections have occurred. Signed-off-by: Davide Zini Signed-off-by: Paolo Valente Link: https://lore.kernel.org/r/20210802141352.74353-2-paolo.valente@linaro.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 7f2b3242f0d4c276dc4caf966c0870159d6ef37c Author: Daniele Palmas Date: Thu Sep 2 12:51:22 2021 +0200 net: usb: cdc_mbim: avoid altsetting toggling for Telit LN920 [ Upstream commit aabbdc67f3485b5db27ab4eba01e5fbf1ffea62c ] Add quirk CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE for Telit LN920 0x1061 composition in order to avoid bind error. Signed-off-by: Daniele Palmas Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ca8ecd7444a9f4295bc7bed1be908564bcc206f0 Author: Ryoga Saito Date: Thu Sep 2 05:20:14 2021 +0000 Set fc_nlinfo in nh_create_ipv4, nh_create_ipv6 [ Upstream commit 9aca491e0dccf8a9d84a5b478e5eee3c6ea7803b ] This patch fixes kernel NULL pointer dereference when creating nexthop which is bound with SRv6 decapsulation. In the creation of nexthop, __seg6_end_dt_vrf_build is called. __seg6_end_dt_vrf_build expects fc_lninfo in fib6_config is set correctly, but it isn't set in nh_create_ipv6, which causes kernel crash. Here is steps to reproduce kernel crash: 1. modprobe vrf 2. ip -6 nexthop add encap seg6local action End.DT4 vrftable 1 dev eth0 We got the following message: [ 901.370336] BUG: kernel NULL pointer dereference, address: 0000000000000ba0 [ 901.371658] #PF: supervisor read access in kernel mode [ 901.372672] #PF: error_code(0x0000) - not-present page [ 901.373672] PGD 0 P4D 0 [ 901.374248] Oops: 0000 [#1] SMP PTI [ 901.374944] CPU: 0 PID: 8593 Comm: ip Not tainted 5.14-051400-generic #202108310811-Ubuntu [ 901.376404] Hardware name: Red Hat KVM, BIOS 1.11.1-4.module_el8.2.0+320+13f867d7 04/01/2014 [ 901.377907] RIP: 0010:vrf_ifindex_lookup_by_table_id+0x19/0x90 [vrf] [ 901.379182] Code: c1 e9 72 ff ff ff e8 96 49 01 c2 66 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 56 41 55 41 89 f5 41 54 53 8b 05 47 4c 00 00 <48> 8b 97 a0 0b 00 00 48 8b 1c c2 e8 57 27 53 c1 4c 8d a3 88 00 00 [ 901.382652] RSP: 0018:ffffbf2d02043590 EFLAGS: 00010282 [ 901.383746] RAX: 000000000000000b RBX: ffff990808255e70 RCX: ffffbf2d02043aa8 [ 901.385436] RDX: 0000000000000001 RSI: 0000000000000001 RDI: 0000000000000000 [ 901.386924] RBP: ffffbf2d020435b0 R08: 00000000000000c0 R09: ffff990808255e40 [ 901.388537] R10: ffffffff83b08c90 R11: 0000000000000009 R12: 0000000000000000 [ 901.389937] R13: 0000000000000001 R14: 0000000000000000 R15: 000000000000000b [ 901.391226] FS: 00007fe49381f740(0000) GS:ffff99087dc00000(0000) knlGS:0000000000000000 [ 901.392737] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 901.393803] CR2: 0000000000000ba0 CR3: 000000000e3e8003 CR4: 0000000000770ef0 [ 901.395122] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 901.396496] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 901.397833] PKRU: 55555554 [ 901.398578] Call Trace: [ 901.399144] l3mdev_ifindex_lookup_by_table_id+0x3b/0x70 [ 901.400179] __seg6_end_dt_vrf_build+0x34/0xd0 [ 901.401067] seg6_end_dt4_build+0x16/0x20 [ 901.401904] seg6_local_build_state+0x271/0x430 [ 901.402797] lwtunnel_build_state+0x81/0x130 [ 901.403645] fib_nh_common_init+0x82/0x100 [ 901.404465] ? sock_def_readable+0x4b/0x80 [ 901.405285] fib6_nh_init+0x115/0x7c0 [ 901.406033] nh_create_ipv6.isra.0+0xe1/0x140 [ 901.406932] rtm_new_nexthop+0x3b7/0xeb0 [ 901.407828] rtnetlink_rcv_msg+0x152/0x3a0 [ 901.408663] ? rtnl_calcit.isra.0+0x130/0x130 [ 901.409535] netlink_rcv_skb+0x55/0x100 [ 901.410319] rtnetlink_rcv+0x15/0x20 [ 901.411026] netlink_unicast+0x1a8/0x250 [ 901.411813] netlink_sendmsg+0x238/0x470 [ 901.412602] ? _copy_from_user+0x2b/0x60 [ 901.413394] sock_sendmsg+0x65/0x70 [ 901.414112] ____sys_sendmsg+0x218/0x290 [ 901.414929] ? copy_msghdr_from_user+0x5c/0x90 [ 901.415814] ___sys_sendmsg+0x81/0xc0 [ 901.416559] ? fsnotify_destroy_marks+0x27/0xf0 [ 901.417447] ? call_rcu+0xa4/0x230 [ 901.418153] ? kmem_cache_free+0x23f/0x410 [ 901.418972] ? dentry_free+0x37/0x70 [ 901.419705] ? mntput_no_expire+0x4c/0x260 [ 901.420574] __sys_sendmsg+0x62/0xb0 [ 901.421297] __x64_sys_sendmsg+0x1f/0x30 [ 901.422057] do_syscall_64+0x5c/0xc0 [ 901.422756] ? syscall_exit_to_user_mode+0x27/0x50 [ 901.423675] ? __x64_sys_close+0x12/0x40 [ 901.424462] ? do_syscall_64+0x69/0xc0 [ 901.425219] ? irqentry_exit_to_user_mode+0x9/0x20 [ 901.426149] ? irqentry_exit+0x19/0x30 [ 901.426901] ? exc_page_fault+0x89/0x160 [ 901.427709] ? asm_exc_page_fault+0x8/0x30 [ 901.428536] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 901.429514] RIP: 0033:0x7fe493945747 [ 901.430248] Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10 [ 901.433549] RSP: 002b:00007ffe9932cf68 EFLAGS: 00000246 ORIG_RAX: 000000000000002e [ 901.434981] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe493945747 [ 901.436303] RDX: 0000000000000000 RSI: 00007ffe9932cfe0 RDI: 0000000000000003 [ 901.437607] RBP: 00000000613053f7 R08: 0000000000000001 R09: 00007ffe9932d07c [ 901.438990] R10: 000055f4a903a010 R11: 0000000000000246 R12: 0000000000000001 [ 901.440340] R13: 0000000000000001 R14: 000055f4a802b163 R15: 000055f4a8042020 [ 901.441630] Modules linked in: vrf nls_utf8 isofs nls_iso8859_1 dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua intel_rapl_msr intel_rapl_common isst_if_mbox_msr isst_if_common nfit rapl input_leds joydev serio_raw qemu_fw_cfg mac_hid sch_fq_codel drm virtio_rng ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel crypto_simd virtio_net net_failover cryptd psmouse virtio_blk failover i2c_piix4 pata_acpi floppy [ 901.450808] CR2: 0000000000000ba0 [ 901.451514] ---[ end trace c27b934b99ade304 ]--- [ 901.452403] RIP: 0010:vrf_ifindex_lookup_by_table_id+0x19/0x90 [vrf] [ 901.453626] Code: c1 e9 72 ff ff ff e8 96 49 01 c2 66 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 56 41 55 41 89 f5 41 54 53 8b 05 47 4c 00 00 <48> 8b 97 a0 0b 00 00 48 8b 1c c2 e8 57 27 53 c1 4c 8d a3 88 00 00 [ 901.456910] RSP: 0018:ffffbf2d02043590 EFLAGS: 00010282 [ 901.457912] RAX: 000000000000000b RBX: ffff990808255e70 RCX: ffffbf2d02043aa8 [ 901.459238] RDX: 0000000000000001 RSI: 0000000000000001 RDI: 0000000000000000 [ 901.460552] RBP: ffffbf2d020435b0 R08: 00000000000000c0 R09: ffff990808255e40 [ 901.461882] R10: ffffffff83b08c90 R11: 0000000000000009 R12: 0000000000000000 [ 901.463208] R13: 0000000000000001 R14: 0000000000000000 R15: 000000000000000b [ 901.464529] FS: 00007fe49381f740(0000) GS:ffff99087dc00000(0000) knlGS:0000000000000000 [ 901.466058] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 901.467189] CR2: 0000000000000ba0 CR3: 000000000e3e8003 CR4: 0000000000770ef0 [ 901.468515] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 901.469858] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 901.471139] PKRU: 55555554 Signed-off-by: Ryoga Saito Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c422c555053e5adc192b0f08d16d26cb59e4f249 Author: Smadar Fuks Date: Wed Sep 1 11:08:59 2021 +0530 octeontx2-af: Add additional register check to rvu_poll_reg() [ Upstream commit 21274aa1781941884599a97ab59be7f8f36af98c ] Check one more time before exiting the API with an error. Fix API to poll at least twice, in case there are other high priority tasks and this API doesn't get CPU cycles for multiple jiffies update. In addition, increase timeout from usecs_to_jiffies(10000) to usecs_to_jiffies(20000), to prevent the case that for CONFIG_100HZ timeout will be a single jiffies. A single jiffies results actual timeout that can be any time between 1usec and 10msec. To solve this, a value of usecs_to_jiffies(20000) ensures that timeout is 2 jiffies. Signed-off-by: Smadar Fuks Signed-off-by: Sunil Goutham Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1cac475eeb9f5c46c1b5ddb4ca79f531ad15e1c8 Author: Jan Kiszka Date: Sun Aug 1 09:56:25 2021 +0200 watchdog: Start watchdog in watchdog_set_last_hw_keepalive only if appropriate [ Upstream commit dbe80cf471f940db3063197b7adb1169f89be9ed ] We must not pet a running watchdog when handle_boot_enabled is off because this will kick off automatic triggering before userland is running, defeating the purpose of the handle_boot_enabled control. Furthermore, don't ping in case watchdog_set_last_hw_keepalive was called incorrectly when the hardware watchdog is actually not running. Fixed: cef9572e9af3 ("watchdog: add support for adjusting last known HW keepalive time") Signed-off-by: Jan Kiszka Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/93d56386-6e37-060b-55ce-84de8cde535f@web.de Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit e5609d3fd57d4ab53db3bbe291fff2b525abbce1 Author: George Cherian Date: Tue Aug 10 17:54:25 2021 +0530 PCI: Add ACS quirks for Cavium multi-function devices [ Upstream commit 32837d8a8f63eb95dcb9cd005524a27f06478832 ] Some Cavium endpoints are implemented as multi-function devices without ACS capability, but they actually don't support peer-to-peer transactions. Add ACS quirks to declare DMA isolation for the following devices: - BGX device found on Octeon-TX (8xxx) - CGX device found on Octeon-TX2 (9xxx) - RPM device found on Octeon-TX3 (10xxx) Link: https://lore.kernel.org/r/20210810122425.1115156-1-george.cherian@marvell.com Signed-off-by: George Cherian Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 365cdfcc6eba04124f22dc74e4355d307bd4fe05 Author: Kishon Vijay Abraham I Date: Wed Aug 11 18:03:35 2021 +0530 PCI: j721e: Add PCIe support for AM64 [ Upstream commit c8a375a8e15ac31293d7fda08008d6da8f5df3db ] AM64 has the same PCIe IP as in J7200 with certain erratas not applicable (quirk_detect_quiet_flag). Add support for "ti,am64-pcie-host" compatible and "ti,am64-pcie-ep" compatible that is specific to AM64. Link: https://lore.kernel.org/r/20210811123336.31357-5-kishon@ti.com Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit 81381b72f40ca6632402f5cc6dda789b1b6f6310 Author: Kishon Vijay Abraham I Date: Wed Aug 11 18:03:34 2021 +0530 PCI: j721e: Add PCIe support for J7200 [ Upstream commit f1de58802f0fff364cf49f5e47d1be744baa434f ] J7200 has the same PCIe IP as in J721E with minor changes in the wrapper. J7200 allows byte access of bridge configuration space registers and the register field for LINK_DOWN interrupt is different. J7200 also requires "quirk_detect_quiet_flag" to be set. Configure these changes as part of driver data applicable only to J7200. Link: https://lore.kernel.org/r/20210811123336.31357-4-kishon@ti.com Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit 4892b1515b402b9279ad747f28b087bbdafc1412 Author: Nadeem Athani Date: Wed Aug 11 18:03:33 2021 +0530 PCI: cadence: Add quirk flag to set minimum delay in LTSSM Detect.Quiet state [ Upstream commit 09c24094b2e3a15ef3fc44f54a191b3db522fb11 ] PCIe fails to link up if SERDES lanes not used by PCIe are assigned to another protocol. For example, link training fails if lanes 2 and 3 are assigned to another protocol while lanes 0 and 1 are used for PCIe to form a two lane link. This failure is due to an incorrect tie-off on an internal status signal indicating electrical idle. Status signals going from SERDES to PCIe Controller are tied-off when a lane is not assigned to PCIe. Signal indicating electrical idle is incorrectly tied-off to a state that indicates non-idle. As a result, PCIe sees unused lanes to be out of electrical idle and this causes LTSSM to exit Detect.Quiet state without waiting for 12ms timeout to occur. If a receiver is not detected on the first receiver detection attempt in Detect.Active state, LTSSM goes back to Detect.Quiet and again moves forward to Detect.Active state without waiting for 12ms as required by PCIe base specification. Since wait time in Detect.Quiet is skipped, multiple receiver detect operations are performed back-to-back without allowing time for capacitance on the transmit lines to discharge. This causes subsequent receiver detection to always fail even if a receiver gets connected eventually. Add a quirk flag "quirk_detect_quiet_flag" to program the minimum time the LTSSM should wait on entering Detect.Quiet state here. This has to be set for J7200 as it has an incorrect tie-off on unused lanes. Link: https://lore.kernel.org/r/20210811123336.31357-3-kishon@ti.com Signed-off-by: Nadeem Athani Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit a83e032cc48981a77c9fead708fc0f49ad842085 Author: Kishon Vijay Abraham I Date: Wed Aug 11 18:03:32 2021 +0530 PCI: cadence: Use bitfield for *quirk_retrain_flag* instead of bool [ Upstream commit f4455748b2126a9ba2bcc9cfb2fbcaa08de29bb2 ] No functional change. As we are intending to add additional 1-bit members in struct j721e_pcie_data/struct cdns_pcie_rc, use bitfields instead of bool since it takes less space. As discussed in [1], the preference is to use bitfileds instead of bool inside structures. [1] -> https://lore.kernel.org/linux-fsdevel/CA+55aFzKQ6Pj18TB8p4Yr0M4t+S+BsiHH=BJNmn=76-NcjTj-g@mail.gmail.com/ Suggested-by: Bjorn Helgaas Link: https://lore.kernel.org/r/20210811123336.31357-2-kishon@ti.com Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit 3aedfe4b080026157a36bf2be6495e158c7d0c62 Author: Masami Hiramatsu Date: Thu Aug 19 19:26:02 2021 +0900 tracing/probes: Reject events which have the same name of existing one [ Upstream commit 8e242060c6a4947e8ae7d29794af6a581db08841 ] Since kprobe_events and uprobe_events only check whether the other same-type probe event has the same name or not, if the user gives the same name of the existing tracepoint event (or the other type of probe events), it silently fails to create the tracefs entry (but registered.) as below. /sys/kernel/tracing # ls events/task/task_rename enable filter format hist id trigger /sys/kernel/tracing # echo p:task/task_rename vfs_read >> kprobe_events [ 113.048508] Could not create tracefs 'task_rename' directory /sys/kernel/tracing # cat kprobe_events p:task/task_rename vfs_read To fix this issue, check whether the existing events have the same name or not in trace_probe_register_event_call(). If exists, it rejects to register the new event. Link: https://lkml.kernel.org/r/162936876189.187130.17558311387542061930.stgit@devnote2 Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 75420f9400a6792dc4b43e5a43ee0f105dd3f9ee Author: Dinghao Liu Date: Thu Apr 8 15:24:02 2021 +0800 PCI: rcar: Fix runtime PM imbalance in rcar_pcie_ep_probe() [ Upstream commit 1e29cd9983eba1b596bc07f94d81d728007f8a25 ] pm_runtime_get_sync() will increase the runtime PM counter even it returns an error. Thus a pairing decrement is needed to prevent refcount leak. Fix this by replacing this API with pm_runtime_resume_and_get(), which will not change the runtime PM counter on error. Link: https://lore.kernel.org/r/20210408072402.15069-1-dinghao.liu@zju.edu.cn Signed-off-by: Dinghao Liu Signed-off-by: Lorenzo Pieralisi Reviewed-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit b6352e2e276469ce756e5d698ea95855535e62a4 Author: Marc Zyngier Date: Sun Jul 25 19:07:54 2021 +0100 mfd: Don't use irq_create_mapping() to resolve a mapping [ Upstream commit 9ff80e2de36d0554e3a6da18a171719fe8663c17 ] Although irq_create_mapping() is able to deal with duplicate mappings, it really isn't supposed to be a substitute for irq_find_mapping(), and can result in allocations that take place in atomic context if the mapping didn't exist. Fix the handful of MFD drivers that use irq_create_mapping() in interrupt context by using irq_find_mapping() instead. Cc: Linus Walleij Cc: Lee Jones Cc: Maxime Coquelin Cc: Alexandre Torgue Signed-off-by: Marc Zyngier Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit aa638669c8a47f856eb4a096ca4f18d612f6cd95 Author: Christophe JAILLET Date: Tue May 4 19:17:42 2021 +0200 PCI: tegra: Fix OF node reference leak [ Upstream commit eff21f5da308265678e7e59821795e606f3e560f ] Commit 9e38e690ace3 ("PCI: tegra: Fix OF node reference leak") has fixed some node reference leaks in this function but missed some of them. In fact, having 'port' referenced in the 'rp' structure is not enough to prevent the leak, until 'rp' is actually added in the 'pcie->ports' list. Add the missing 'goto err_node_put' accordingly. Link: https://lore.kernel.org/r/55b11e9a7fa2987fbc0869d68ae59888954d65e2.1620148539.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET Signed-off-by: Lorenzo Pieralisi Reviewed-by: Vidya Sagar Signed-off-by: Sasha Levin commit d5c5d1b141faee0be01c93f48f2b714838004ef1 Author: Om Prakash Singh Date: Wed Jun 23 15:35:22 2021 +0530 PCI: tegra194: Fix MSI-X programming [ Upstream commit 43537cf7e351264a1f05ed42ad402942bfc9140e ] Lower order MSI-X address is programmed in MSIX_ADDR_MATCH_HIGH_OFF DBI register instead of higher order address. This patch fixes this programming mistake. Link: https://lore.kernel.org/r/20210623100525.19944-3-omp@nvidia.com Signed-off-by: Om Prakash Singh Signed-off-by: Lorenzo Pieralisi Reviewed-by: Bjorn Helgaas Acked-by: Vidya Sagar Signed-off-by: Sasha Levin commit 13f366bab07724d12c8ed73977870c0a9e964ad7 Author: Om Prakash Singh Date: Wed Jun 23 15:35:21 2021 +0530 PCI: tegra194: Fix handling BME_CHGED event [ Upstream commit ceb1412c1c8ca5b28c4252bdb15f2f1f17b4a1b0 ] In tegra_pcie_ep_hard_irq(), APPL_INTR_STATUS_L0 is stored in val and again APPL_INTR_STATUS_L1_0_0 is also stored in val. So when execution reaches "if (val & APPL_INTR_STATUS_L0_PCI_CMD_EN_INT)", val is not correct. Link: https://lore.kernel.org/r/20210623100525.19944-2-omp@nvidia.com Signed-off-by: Om Prakash Singh Signed-off-by: Lorenzo Pieralisi Reviewed-by: Bjorn Helgaas Acked-by: Vidya Sagar Signed-off-by: Sasha Levin commit b7d4f310bb8f605cff7c4c70014a9e2b866625c4 Author: Miklos Szeredi Date: Wed Aug 4 13:22:58 2021 +0200 fuse: fix use after free in fuse_read_interrupt() [ Upstream commit e1e71c168813564be0f6ea3d6740a059ca42d177 ] There is a potential race between fuse_read_interrupt() and fuse_request_end(). TASK1 in fuse_read_interrupt(): delete req->intr_entry (while holding fiq->lock) TASK2 in fuse_request_end(): req->intr_entry is empty -> skip fiq->lock wake up TASK3 TASK3 request is freed TASK1 in fuse_read_interrupt(): dereference req->in.h.unique ***BAM*** Fix by always grabbing fiq->lock if the request was ever interrupted (FR_INTERRUPTED set) thereby serializing with concurrent fuse_read_interrupt() calls. FR_INTERRUPTED is set before the request is queued on fiq->interrupts. Dequeing the request is done with list_del_init() but FR_INTERRUPTED is not cleared in this case. Reported-by: lijiazi Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 03cc3a2923d62f847d148f545c711f73f79617f0 Author: Wasim Khan Date: Thu Jul 29 14:17:47 2021 +0200 PCI: Add ACS quirks for NXP LX2xx0 and LX2xx2 platforms [ Upstream commit d08c8b855140e9f5240b3ffd1b8b9d435675e281 ] Root Ports in NXP LX2xx0 and LX2xx2, where each Root Port is a Root Complex with unique segment numbers, do provide isolation features to disable peer transactions and validate bus numbers in requests, but do not provide an actual PCIe ACS capability. Add ACS quirks for NXP LX2xx0 A/C/E/N and LX2xx2 A/C/E/N platforms. LX2xx0A : without security features + CAN-FD LX2160A (0x8d81) - 16 cores LX2120A (0x8da1) - 12 cores LX2080A (0x8d83) - 8 cores LX2xx0C : security features + CAN-FD LX2160C (0x8d80) - 16 cores LX2120C (0x8da0) - 12 cores LX2080C (0x8d82) - 8 cores LX2xx0E : security features + CAN LX2160E (0x8d90) - 16 cores LX2120E (0x8db0) - 12 cores LX2080E (0x8d92) - 8 cores LX2xx0N : without security features + CAN LX2160N (0x8d91) - 16 cores LX2120N (0x8db1) - 12 cores LX2080N (0x8d93) - 8 cores LX2xx2A : without security features + CAN-FD LX2162A (0x8d89) - 16 cores LX2122A (0x8da9) - 12 cores LX2082A (0x8d8b) - 8 cores LX2xx2C : security features + CAN-FD LX2162C (0x8d88) - 16 cores LX2122C (0x8da8) - 12 cores LX2082C (0x8d8a) - 8 cores LX2xx2E : security features + CAN LX2162E (0x8d98) - 16 cores LX2122E (0x8db8) - 12 cores LX2082E (0x8d9a) - 8 cores LX2xx2N : without security features + CAN LX2162N (0x8d99) - 16 cores LX2122N (0x8db9) - 12 cores LX2082N (0x8d9b) - 8 cores [bhelgaas: put PCI_VENDOR_ID_NXP definition next to PCI_VENDOR_ID_FREESCALE as a clue that they share the same Device ID namespace] Link: https://lore.kernel.org/r/20210729121747.1823086-1-wasim.khan@oss.nxp.com Link: https://lore.kernel.org/r/20210803180021.3252886-1-wasim.khan@oss.nxp.com Signed-off-by: Wasim Khan Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 7a44361a1f6ac2085e1fb64170a4342898b37f6b Author: Linus Walleij Date: Mon Aug 2 01:33:13 2021 +0200 mfd: db8500-prcmu: Adjust map to reality [ Upstream commit ec343111c056ec3847800302f6dbc57281f833fa ] These are the actual frequencies reported by the PLL, so let's report these. The roundoffs are inappropriate, we should round to the frequency that the clock will later report. Drop some whitespace at the same time. Cc: phone-devel@vger.kernel.org Signed-off-by: Linus Walleij Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 619f137ffd691708fec72c785db497fb85b16cd5 Author: Miquel Raynal Date: Thu Jun 10 16:39:45 2021 +0200 dt-bindings: mtd: gpmc: Fix the ECC bytes vs. OOB bytes equation [ Upstream commit 778cb8e39f6ec252be50fc3850d66f3dcbd5dd5a ] "PAGESIZE / 512" is the number of ECC chunks. "ECC_BYTES" is the number of bytes needed to store a single ECC code. "2" is the space reserved by the bad block marker. "2 + (PAGESIZE / 512) * ECC_BYTES" should of course be lower or equal than the total number of OOB bytes, otherwise it won't fit. Fix the equation by substituting s/>=/<=/. Suggested-by: Ryan J. Barnett Signed-off-by: Miquel Raynal Acked-by: Rob Herring Link: https://lore.kernel.org/linux-mtd/20210610143945.3504781-1-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin commit 49cf30ebb35c50234144dd2a34fe7a6d50b966e2 Author: David Hildenbrand Date: Tue Sep 7 19:54:59 2021 -0700 mm/memory_hotplug: use "unsigned long" for PFN in zone_for_pfn_range() commit 7cf209ba8a86410939a24cb1aeb279479a7e0ca6 upstream. Patch series "mm/memory_hotplug: preparatory patches for new online policy and memory" These are all cleanups and one fix previously sent as part of [1]: [PATCH v1 00/12] mm/memory_hotplug: "auto-movable" online policy and memory groups. These patches make sense even without the other series, therefore I pulled them out to make the other series easier to digest. [1] https://lkml.kernel.org/r/20210607195430.48228-1-david@redhat.com This patch (of 4): Checkpatch complained on a follow-up patch that we are using "unsigned" here, which defaults to "unsigned int" and checkpatch is correct. As we will search for a fitting zone using the wrong pfn, we might end up onlining memory to one of the special kernel zones, such as ZONE_DMA, which can end badly as the onlined memory does not satisfy properties of these zones. Use "unsigned long" instead, just as we do in other places when handling PFNs. This can bite us once we have physical addresses in the range of multiple TB. Link: https://lkml.kernel.org/r/20210712124052.26491-2-david@redhat.com Fixes: e5e689302633 ("mm, memory_hotplug: display allowed zones in the preferred ordering") Signed-off-by: David Hildenbrand Reviewed-by: Pankaj Gupta Reviewed-by: Muchun Song Reviewed-by: Oscar Salvador Cc: David Hildenbrand Cc: Vitaly Kuznetsov Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Pankaj Gupta Cc: Wei Yang Cc: Michal Hocko Cc: Dan Williams Cc: Anshuman Khandual Cc: Dave Hansen Cc: Vlastimil Babka Cc: Mike Rapoport Cc: "Rafael J. Wysocki" Cc: Len Brown Cc: Pavel Tatashin Cc: Heiko Carstens Cc: Michael Ellerman Cc: Catalin Marinas Cc: virtualization@lists.linux-foundation.org Cc: Andy Lutomirski Cc: "Aneesh Kumar K.V" Cc: Anton Blanchard Cc: Ard Biesheuvel Cc: Baoquan He Cc: Benjamin Herrenschmidt Cc: Borislav Petkov Cc: Christian Borntraeger Cc: Christophe Leroy Cc: Dave Jiang Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jia He Cc: Joe Perches Cc: Kefeng Wang Cc: Laurent Dufour Cc: Michel Lespinasse Cc: Nathan Lynch Cc: Nicholas Piggin Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Pierre Morel Cc: "Rafael J. Wysocki" Cc: Rich Felker Cc: Scott Cheloha Cc: Sergei Trofimovich Cc: Thiago Jung Bauermann Cc: Thomas Gleixner Cc: Vasily Gorbik Cc: Vishal Verma Cc: Will Deacon Cc: Yoshinori Sato Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: David Hildenbrand Signed-off-by: Greg Kroah-Hartman commit aa39eb744a82e35ca6dde7c2279a1b1c315cb357 Author: Jiaran Zhang Date: Mon Sep 13 21:08:25 2021 +0800 net: hns3: fix the timing issue of VF clearing interrupt sources commit 427900d27d86b820c559037a984bd403f910860f upstream. Currently, the VF does not clear the interrupt source immediately after receiving the interrupt. As a result, if the second interrupt task is triggered when processing the first interrupt task, clearing the interrupt source before exiting will clear the interrupt sources of the two tasks at the same time. As a result, no interrupt is triggered for the second task. The VF detects the missed message only when the next interrupt is generated. Clearing it immediately after executing check_evt_cause ensures that: 1. Even if two interrupt tasks are triggered at the same time, they can be processed. 2. If the second task is triggered during the processing of the first task and the interrupt source is not cleared, the interrupt is reported after vector0 is enabled. Fixes: b90fcc5bd904 ("net: hns3: add reset handling for VF when doing Core/Global/IMP reset") Signed-off-by: Jiaran Zhang Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ad47e092210882ae1b5a2239ea59c4e8339cc980 Author: Yufeng Mo Date: Mon Sep 13 21:08:23 2021 +0800 net: hns3: disable mac in flr process commit b81d8948746520f989e86d66292ff72b5056114a upstream. The firmware will not disable mac in flr process. Therefore, the driver needs to proactively disable mac during flr, which is the same as the function reset. Fixes: 35d93a30040c ("net: hns3: adjust the process of PF reset") Signed-off-by: Yufeng Mo Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b76522c7c349ef35333c8d11e0bba720a5e03244 Author: Yufeng Mo Date: Mon Sep 13 21:08:22 2021 +0800 net: hns3: change affinity_mask to numa node range commit 1dc839ec09d3ab2a4156dc98328b8bc3586f2b70 upstream. Currently, affinity_mask is set to a single cpu. As a result, irqbalance becomes invalid in SUBSET or EXACT mode. To solve this problem, change affinity_mask to numa node range. In this way, irqbalance can be performed on the cpu of the numa node. Fixes: 0812545487ec ("net: hns3: add interrupt affinity support for misc interrupt") Signed-off-by: Yufeng Mo Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 34fc06d0477e83088243702be08fa503b31e41c0 Author: Yufeng Mo Date: Mon Sep 13 21:08:21 2021 +0800 net: hns3: pad the short tunnel frame before sending to hardware commit d18e81183b1cb9c309266cbbce9acd3e0c528d04 upstream. The hardware cannot handle short tunnel frames below 65 bytes, and will cause vlan tag missing problem. So pads packet size to 65 bytes for tunnel frames to fix this bug. Fixes: 3db084d28dc0("net: hns3: Fix for vxlan tx checksum bug") Signed-off-by: Yufeng Mo Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0511d099db6f92680dc4f780d27492211454a02a Author: Edwin Peer Date: Sun Sep 12 12:34:48 2021 -0400 bnxt_en: make bnxt_free_skbs() safe to call after bnxt_free_mem() commit 1affc01fdc6035189a5ab2a24948c9419ee0ecf2 upstream. The call to bnxt_free_mem(..., false) in the bnxt_half_open_nic() error path will deallocate ring descriptor memory via bnxt_free_?x_rings(), but because irq_re_init is false, the ring info itself is not freed. To simplify error paths, deallocation functions have generally been written to be safe when called on unallocated memory. It should always be safe to call dev_close(), which calls bnxt_free_skbs() a second time, even in this semi- allocated ring state. Calling bnxt_free_skbs() a second time with the rings already freed will cause NULL pointer dereference. Fix it by checking the rings are valid before proceeding in bnxt_free_tx_skbs() and bnxt_free_one_rx_ring_skbs(). Fixes: 975bc99a4a39 ("bnxt_en: Refactor bnxt_free_rx_skbs().") Signed-off-by: Edwin Peer Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 49eff4ab7d43d625a5906b63c3bfcca9cfac56eb Author: Nicholas Piggin Date: Wed Sep 8 20:17:18 2021 +1000 KVM: PPC: Book3S HV: Tolerate treclaim. in fake-suspend mode changing registers commit 267cdfa21385d78c794768233678756e32b39ead upstream. POWER9 DD2.2 and 2.3 hardware implements a "fake-suspend" mode where certain TM instructions executed in HV=0 mode cause softpatch interrupts so the hypervisor can emulate them and prevent problematic processor conditions. In this fake-suspend mode, the treclaim. instruction does not modify registers. Unfortunately the rfscv instruction executed by the guest do not generate softpatch interrupts, which can cause the hypervisor to lose track of the fake-suspend mode, and it can execute this treclaim. while not in fake-suspend mode. This modifies GPRs and crashes the hypervisor. It's not trivial to disable scv in the guest with HFSCR now, because they assume a POWER9 has scv available. So this fix saves and restores checkpointed registers across the treclaim. Fixes: 7854f7545bff ("KVM: PPC: Book3S: Rework TM save/restore code and make it C-callable") Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210908101718.118522-2-npiggin@gmail.com Signed-off-by: Greg Kroah-Hartman commit e68795c1101ed6a1eb2954d40945708a459d14c3 Author: Sukadev Bhattiprolu Date: Wed Sep 8 09:58:20 2021 -0700 ibmvnic: check failover_pending in login response commit 273c29e944bda9a20a30c26cfc34c9a3f363280b upstream. If a failover occurs before a login response is received, the login response buffer maybe undefined. Check that there was no failover before accessing the login response buffer. Fixes: 032c5e82847a ("Driver for IBM System i/p VNIC protocol") Signed-off-by: Sukadev Bhattiprolu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit aeb67214ce94f23e76502d69231e334c17e422d7 Author: David Heidelberg Date: Sun Sep 12 18:51:20 2021 +0200 dt-bindings: arm: Fix Toradex compatible typo commit 55c21d57eafb7b379bb7b3e93baf9ca2695895b0 upstream. Fix board compatible typo reported by dtbs_check. Fixes: f4d1577e9bc6 ("dt-bindings: arm: Convert Tegra board/soc bindings to json-schema") Signed-off-by: David Heidelberg Link: https://lore.kernel.org/r/20210912165120.188490-1-david@ixit.cz Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman commit 0ab9981fa0c5f1ded9a70b44d9c003e549068e7a Author: Aya Levin Date: Mon Sep 13 10:53:49 2021 +0300 udp_tunnel: Fix udp_tunnel_nic work-queue type commit e50e711351bdc656a8e6ca1022b4293cae8dcd59 upstream. Turn udp_tunnel_nic work-queue to an ordered work-queue. This queue holds the UDP-tunnel configuration commands of the different netdevs. When the netdevs are functions of the same NIC the order of execution may be crucial. Problem example: NIC with 2 PFs, both PFs declare offload quota of up to 3 UDP-ports. $ifconfig eth2 1.1.1.1/16 up $ip link add eth2_19503 type vxlan id 5049 remote 1.1.1.2 dev eth2 dstport 19053 $ip link set dev eth2_19503 up $ip link add eth2_19504 type vxlan id 5049 remote 1.1.1.3 dev eth2 dstport 19054 $ip link set dev eth2_19504 up $ip link add eth2_19505 type vxlan id 5049 remote 1.1.1.4 dev eth2 dstport 19055 $ip link set dev eth2_19505 up $ip link add eth2_19506 type vxlan id 5049 remote 1.1.1.5 dev eth2 dstport 19056 $ip link set dev eth2_19506 up NIC RX port offload infrastructure offloads the first 3 UDP-ports (on all devices which sets NETIF_F_RX_UDP_TUNNEL_PORT feature) and not UDP-port 19056. So both PFs gets this offload configuration. $ip link set dev eth2_19504 down This triggers udp-tunnel-core to remove the UDP-port 19504 from offload-ports-list and offload UDP-port 19056 instead. In this scenario it is important that the UDP-port of 19504 will be removed from both PFs before trying to add UDP-port 19056. The NIC can stop offloading a UDP-port only when all references are removed. Otherwise the NIC may report exceeding of the offload quota. Fixes: cc4e3835eff4 ("udp_tunnel: add central NIC RX port offload infrastructure") Signed-off-by: Aya Levin Reviewed-by: Tariq Toukan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5221e66329910239df788f2cf49f4acc072f86d0 Author: Shai Malin Date: Fri Sep 10 11:33:56 2021 +0300 qed: Handle management FW error commit 20e100f52730cd0db609e559799c1712b5f27582 upstream. Handle MFW (management FW) error response in order to avoid a crash during recovery flows. Changes from v1: - Add "Fixes tag". Fixes: tag 5e7ba042fd05 ("qed: Fix reading stale configuration information") Signed-off-by: Ariel Elior Signed-off-by: Shai Malin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e00eae1d6b1fb8eecb1250fdcadcc97ea391cbe5 Author: Andrea Claudi Date: Sat Sep 11 16:14:18 2021 +0200 selftest: net: fix typo in altname test commit 1b704b27beb11ce147d64b21c914e57afbfb5656 upstream. If altname deletion of the short alternative name fails, the error message printed is: "Failed to add short alternative name". This is obviously a typo, as we are testing altname deletion. Fix this using a proper error message. Fixes: f95e6c9c4617 ("selftest: net: add alternative names test") Signed-off-by: Andrea Claudi Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 53947b68c56bbdd2d8c8399b0d1a6ab154203577 Author: zhenggy Date: Tue Sep 14 09:51:15 2021 +0800 tcp: fix tp->undo_retrans accounting in tcp_sacktag_one() commit 4f884f3962767877d7aabbc1ec124d2c307a4257 upstream. Commit 10d3be569243 ("tcp-tso: do not split TSO packets at retransmit time") may directly retrans a multiple segments TSO/GSO packet without split, Since this commit, we can no longer assume that a retransmitted packet is a single segment. This patch fixes the tp->undo_retrans accounting in tcp_sacktag_one() that use the actual segments(pcount) of the retransmitted packet. Before that commit (10d3be569243), the assumption underlying the tp->undo_retrans-- seems correct. Fixes: 10d3be569243 ("tcp-tso: do not split TSO packets at retransmit time") Signed-off-by: zhenggy Reviewed-by: Eric Dumazet Acked-by: Yuchung Cheng Acked-by: Neal Cardwell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 35d3ab2ea2ed594406db5cb063dd1f9daf940a83 Author: Will Deacon Date: Mon Sep 13 17:35:47 2021 +0100 x86/uaccess: Fix 32-bit __get_user_asm_u64() when CC_HAS_ASM_GOTO_OUTPUT=y commit a69ae291e1cc2d08ae77c2029579c59c9bde5061 upstream. Commit 865c50e1d279 ("x86/uaccess: utilize CONFIG_CC_HAS_ASM_GOTO_OUTPUT") added an optimised version of __get_user_asm() for x86 using 'asm goto'. Like the non-optimised code, the 32-bit implementation of 64-bit get_user() expands to a pair of 32-bit accesses. Unlike the non-optimised code, the _original_ pointer is incremented to copy the high word instead of loading through a new pointer explicitly constructed to point at a 32-bit type. Consequently, if the pointer points at a 64-bit type then we end up loading the wrong data for the upper 32-bits. This was observed as a mount() failure in Android targeting i686 after b0cfcdd9b967 ("d_path: make 'prepend()' fill up the buffer exactly on overflow") because the call to copy_from_kernel_nofault() from prepend_copy() ends up in __get_kernel_nofault() and casts the source pointer to a 'u64 __user *'. An attempt to mount at "/debug_ramdisk" therefore ends up failing trying to mount "/debumdismdisk". Use the existing '__gu_ptr' source pointer to unsigned int for 32-bit __get_user_asm_u64() instead of the original pointer. Cc: Bill Wendling Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Peter Zijlstra Reported-by: Greg Kroah-Hartman Fixes: 865c50e1d279 ("x86/uaccess: utilize CONFIG_CC_HAS_ASM_GOTO_OUTPUT") Signed-off-by: Will Deacon Reviewed-by: Nick Desaulniers Tested-by: Greg Kroah-Hartman Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit cf6f29bb2c18be0aaa54d85b5d58f6a9759bcbf1 Author: Vladimir Oltean Date: Tue Sep 14 16:43:31 2021 +0300 net: dsa: destroy the phylink instance on any error in dsa_slave_phy_setup commit 6a52e73368038f47f6618623d75061dc263b26ae upstream. DSA supports connecting to a phy-handle, and has a fallback to a non-OF based method of connecting to an internal PHY on the switch's own MDIO bus, if no phy-handle and no fixed-link nodes were present. The -ENODEV error code from the first attempt (phylink_of_phy_connect) is what triggers the second attempt (phylink_connect_phy). However, when the first attempt returns a different error code than -ENODEV, this results in an unbalance of calls to phylink_create and phylink_destroy by the time we exit the function. The phylink instance has leaked. There are many other error codes that can be returned by phylink_of_phy_connect. For example, phylink_validate returns -EINVAL. So this is a practical issue too. Fixes: aab9c4067d23 ("net: dsa: Plug in PHYLINK support") Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Reviewed-by: Russell King (Oracle) Link: https://lore.kernel.org/r/20210914134331.2303380-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit df38f941a7e4c966919741b86df5e877a1f69e9a Author: Eric Dumazet Date: Wed Sep 8 17:00:29 2021 -0700 net/af_unix: fix a data-race in unix_dgram_poll commit 04f08eb44b5011493d77b602fdec29ff0f5c6cd5 upstream. syzbot reported another data-race in af_unix [1] Lets change __skb_insert() to use WRITE_ONCE() when changing skb head qlen. Also, change unix_dgram_poll() to use lockless version of unix_recvq_full() It is verry possible we can switch all/most unix_recvq_full() to the lockless version, this will be done in a future kernel version. [1] HEAD commit: 8596e589b787732c8346f0482919e83cc9362db1 BUG: KCSAN: data-race in skb_queue_tail / unix_dgram_poll write to 0xffff88814eeb24e0 of 4 bytes by task 25815 on cpu 0: __skb_insert include/linux/skbuff.h:1938 [inline] __skb_queue_before include/linux/skbuff.h:2043 [inline] __skb_queue_tail include/linux/skbuff.h:2076 [inline] skb_queue_tail+0x80/0xa0 net/core/skbuff.c:3264 unix_dgram_sendmsg+0xff2/0x1600 net/unix/af_unix.c:1850 sock_sendmsg_nosec net/socket.c:703 [inline] sock_sendmsg net/socket.c:723 [inline] ____sys_sendmsg+0x360/0x4d0 net/socket.c:2392 ___sys_sendmsg net/socket.c:2446 [inline] __sys_sendmmsg+0x315/0x4b0 net/socket.c:2532 __do_sys_sendmmsg net/socket.c:2561 [inline] __se_sys_sendmmsg net/socket.c:2558 [inline] __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2558 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff88814eeb24e0 of 4 bytes by task 25834 on cpu 1: skb_queue_len include/linux/skbuff.h:1869 [inline] unix_recvq_full net/unix/af_unix.c:194 [inline] unix_dgram_poll+0x2bc/0x3e0 net/unix/af_unix.c:2777 sock_poll+0x23e/0x260 net/socket.c:1288 vfs_poll include/linux/poll.h:90 [inline] ep_item_poll fs/eventpoll.c:846 [inline] ep_send_events fs/eventpoll.c:1683 [inline] ep_poll fs/eventpoll.c:1798 [inline] do_epoll_wait+0x6ad/0xf00 fs/eventpoll.c:2226 __do_sys_epoll_wait fs/eventpoll.c:2238 [inline] __se_sys_epoll_wait fs/eventpoll.c:2233 [inline] __x64_sys_epoll_wait+0xf6/0x120 fs/eventpoll.c:2233 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0x0000001b -> 0x00000001 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 25834 Comm: syz-executor.1 Tainted: G W 5.14.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Fixes: 86b18aaa2b5b ("skbuff: fix a data race in skb_queue_len()") Cc: Qian Cai Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit cad96d0e50e4149758d43bcc3bd13f6381312362 Author: Paolo Abeni Date: Wed Sep 8 13:42:09 2021 +0200 vhost_net: fix OoB on sendmsg() failure. commit 3c4cea8fa7f71f00c5279547043a84bc2a4d8b8c upstream. If the sendmsg() call in vhost_tx_batch() fails, both the 'batched_xdp' and 'done_idx' indexes are left unchanged. If such failure happens when batched_xdp == VHOST_NET_BATCH, the next call to vhost_net_build_xdp() will access and write memory outside the xdp buffers area. Since sendmsg() can only error with EBADFD, this change addresses the issue explicitly freeing the XDP buffers batch on error. Fixes: 0a0be13b8fe2 ("vhost_net: batch submitting XDP buffers to underlayer sockets") Suggested-by: Jason Wang Signed-off-by: Paolo Abeni Acked-by: Jason Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7843861e214026bd867d19e832de10d16a52e757 Author: Kortan Date: Wed Sep 8 11:28:48 2021 +0800 gen_compile_commands: fix missing 'sys' package commit ec783c7cb2495c5a3b8ca10db8056d43c528f940 upstream. We need to import the 'sys' package since the script has called sys.exit() method. Fixes: 6ad7cbc01527 ("Makefile: Add clang-tidy and static analyzer support to makefile") Signed-off-by: Kortan Reviewed-by: Nathan Chancellor Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman commit 983ef866291cc7e51f151cdea5a7c2fe36f632a3 Author: Alex Elder Date: Tue Sep 7 12:05:54 2021 -0500 net: ipa: initialize all filter table slots commit b5c102238cea985d8126b173d06b9e1de88037ee upstream. There is an off-by-one problem in ipa_table_init_add(), when initializing filter tables. In that function, the number of filter table entries is determined based on the number of set bits in the filter map. However that count does *not* include the extra "slot" in the filter table that holds the filter map itself. Meanwhile, ipa_table_addr() *does* include the filter map in the memory it returns, but because the count it's provided doesn't include it, it includes one too few table entries. Fix this by including the extra slot for the filter map in the count computed in ipa_table_init_add(). Note: ipa_filter_reset_table() does not have this problem; it resets filter table entries one by one, but does not overwrite the filter bitmap. Fixes: 2b9feef2b6c2 ("soc: qcom: ipa: filter and routing tables") Signed-off-by: Alex Elder Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c5102ced8ac0a106182332de15ea2b2920581811 Author: Baptiste Lepers Date: Mon Sep 6 11:53:10 2021 +1000 events: Reuse value read using READ_ONCE instead of re-reading it commit b89a05b21f46150ac10a962aa50109250b56b03b upstream. In perf_event_addr_filters_apply, the task associated with the event (event->ctx->task) is read using READ_ONCE at the beginning of the function, checked, and then re-read from event->ctx->task, voiding all guarantees of the checks. Reuse the value that was read by READ_ONCE to ensure the consistency of the task struct throughout the function. Fixes: 375637bc52495 ("perf/core: Introduce address range filtering") Signed-off-by: Baptiste Lepers Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210906015310.12802-1-baptiste.lepers@gmail.com Signed-off-by: Greg Kroah-Hartman commit 8f8ad122ffe01efb7c14b34f9c33b8b16e02fec5 Author: Keith Busch Date: Thu Sep 9 08:54:52 2021 -0700 nvme-tcp: fix io_work priority inversion commit 70f437fb4395ad4d1d16fab9a1ad9fbc9fc0579b upstream. Dispatching requests inline with the .queue_rq() call may block while holding the send_mutex. If the tcp io_work also happens to schedule, it may see the req_list is non-empty, leaving "pending" true and remaining in TASK_RUNNING. Since io_work is of higher scheduling priority, the .queue_rq task may not get a chance to run, blocking forward progress and leading to io timeouts. Instead of checking for pending requests within io_work, let the queueing restart io_work outside the send_mutex lock if there is more work to be done. Fixes: a0fdd1418007f ("nvme-tcp: rerun io_work if req_list is not empty") Reported-by: Samuel Jones Signed-off-by: Keith Busch Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit c586bc31d5b9ae7ed202fc0dcaffbaaed77bde06 Author: Maor Gottlieb Date: Wed Sep 1 11:48:13 2021 +0300 net/mlx5: Fix potential sleeping in atomic context commit ee27e330a953595903979ffdb84926843595a9fe upstream. Fixes the below flow of sleeping in atomic context by releasing the RCU lock before calling to free_match_list. build_match_list() <- disables preempt -> free_match_list() -> tree_put_node() -> down_write_ref_node() <- take write lock Fixes: 693c6883bbc4 ("net/mlx5: Add hash table for flow groups in flow table") Reported-by: Dan Carpenter Signed-off-by: Maor Gottlieb Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 29a5af9112a279398c0716bd8d932c94c6a03b16 Author: Saeed Mahameed Date: Wed Aug 18 13:09:26 2021 -0700 net/mlx5: FWTrace, cancel work on alloc pd error flow commit dfe6fd72b5f1878b16aa2c8603e031bbcd66b96d upstream. Handle error flow on mlx5_core_alloc_pd() failure, read_fw_strings_work must be canceled. Fixes: c71ad41ccb0c ("net/mlx5: FW tracer, events handling") Reported-by: Pavel Machek (CIP) Suggested-by: Pavel Machek (CIP) Signed-off-by: Saeed Mahameed Reviewed-by: Aya Levin Signed-off-by: Greg Kroah-Hartman commit 229e9293b2bada323485dd2168c03b7d69328014 Author: Michael Petlan Date: Mon Jul 19 16:53:32 2021 +0200 perf machine: Initialize srcline string member in add_location struct commit 57f0ff059e3daa4e70a811cb1d31a49968262d20 upstream. It's later supposed to be either a correct address or NULL. Without the initialization, it may contain an undefined value which results in the following segmentation fault: # perf top --sort comm -g --ignore-callees=do_idle terminates with: #0 0x00007ffff56b7685 in __strlen_avx2 () from /lib64/libc.so.6 #1 0x00007ffff55e3802 in strdup () from /lib64/libc.so.6 #2 0x00005555558cb139 in hist_entry__init (callchain_size=, sample_self=true, template=0x7fffde7fb110, he=0x7fffd801c250) at util/hist.c:489 #3 hist_entry__new (template=template@entry=0x7fffde7fb110, sample_self=sample_self@entry=true) at util/hist.c:564 #4 0x00005555558cb4ba in hists__findnew_entry (hists=hists@entry=0x5555561d9e38, entry=entry@entry=0x7fffde7fb110, al=al@entry=0x7fffde7fb420, sample_self=sample_self@entry=true) at util/hist.c:657 #5 0x00005555558cba1b in __hists__add_entry (hists=hists@entry=0x5555561d9e38, al=0x7fffde7fb420, sym_parent=, bi=bi@entry=0x0, mi=mi@entry=0x0, sample=sample@entry=0x7fffde7fb4b0, sample_self=true, ops=0x0, block_info=0x0) at util/hist.c:288 #6 0x00005555558cbb70 in hists__add_entry (sample_self=true, sample=0x7fffde7fb4b0, mi=0x0, bi=0x0, sym_parent=, al=, hists=0x5555561d9e38) at util/hist.c:1056 #7 iter_add_single_cumulative_entry (iter=0x7fffde7fb460, al=) at util/hist.c:1056 #8 0x00005555558cc8a4 in hist_entry_iter__add (iter=iter@entry=0x7fffde7fb460, al=al@entry=0x7fffde7fb420, max_stack_depth=, arg=arg@entry=0x7fffffff7db0) at util/hist.c:1231 #9 0x00005555557cdc9a in perf_event__process_sample (machine=, sample=0x7fffde7fb4b0, evsel=, event=, tool=0x7fffffff7db0) at builtin-top.c:842 #10 deliver_event (qe=, qevent=) at builtin-top.c:1202 #11 0x00005555558a9318 in do_flush (show_progress=false, oe=0x7fffffff80e0) at util/ordered-events.c:244 #12 __ordered_events__flush (oe=oe@entry=0x7fffffff80e0, how=how@entry=OE_FLUSH__TOP, timestamp=timestamp@entry=0) at util/ordered-events.c:323 #13 0x00005555558a9789 in __ordered_events__flush (timestamp=, how=, oe=) at util/ordered-events.c:339 #14 ordered_events__flush (how=OE_FLUSH__TOP, oe=0x7fffffff80e0) at util/ordered-events.c:341 #15 ordered_events__flush (oe=oe@entry=0x7fffffff80e0, how=how@entry=OE_FLUSH__TOP) at util/ordered-events.c:339 #16 0x00005555557cd631 in process_thread (arg=0x7fffffff7db0) at builtin-top.c:1114 #17 0x00007ffff7bb817a in start_thread () from /lib64/libpthread.so.0 #18 0x00007ffff5656dc3 in clone () from /lib64/libc.so.6 If you look at the frame #2, the code is: 488 if (he->srcline) { 489 he->srcline = strdup(he->srcline); 490 if (he->srcline == NULL) 491 goto err_rawdata; 492 } If he->srcline is not NULL (it is not NULL if it is uninitialized rubbish), it gets strdupped and strdupping a rubbish random string causes the problem. Also, if you look at the commit 1fb7d06a509e, it adds the srcline property into the struct, but not initializing it everywhere needed. Committer notes: Now I see, when using --ignore-callees=do_idle we end up here at line 2189 in add_callchain_ip(): 2181 if (al.sym != NULL) { 2182 if (perf_hpp_list.parent && !*parent && 2183 symbol__match_regex(al.sym, &parent_regex)) 2184 *parent = al.sym; 2185 else if (have_ignore_callees && root_al && 2186 symbol__match_regex(al.sym, &ignore_callees_regex)) { 2187 /* Treat this symbol as the root, 2188 forgetting its callees. */ 2189 *root_al = al; 2190 callchain_cursor_reset(cursor); 2191 } 2192 } And the al that doesn't have the ->srcline field initialized will be copied to the root_al, so then, back to: 1211 int hist_entry_iter__add(struct hist_entry_iter *iter, struct addr_location *al, 1212 int max_stack_depth, void *arg) 1213 { 1214 int err, err2; 1215 struct map *alm = NULL; 1216 1217 if (al) 1218 alm = map__get(al->map); 1219 1220 err = sample__resolve_callchain(iter->sample, &callchain_cursor, &iter->parent, 1221 iter->evsel, al, max_stack_depth); 1222 if (err) { 1223 map__put(alm); 1224 return err; 1225 } 1226 1227 err = iter->ops->prepare_entry(iter, al); 1228 if (err) 1229 goto out; 1230 1231 err = iter->ops->add_single_entry(iter, al); 1232 if (err) 1233 goto out; 1234 That al at line 1221 is what hist_entry_iter__add() (called from sample__resolve_callchain()) saw as 'root_al', and then: iter->ops->add_single_entry(iter, al); will go on with al->srcline with a bogus value, I'll add the above sequence to the cset and apply, thanks! Signed-off-by: Michael Petlan CC: Milian Wolff Cc: Jiri Olsa Fixes: 1fb7d06a509e ("perf report Use srcline from callchain for hist entries") Link: https //lore.kernel.org/r/20210719145332.29747-1-mpetlan@redhat.com Reported-by: Juri Lelli Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 33c983f7a1821a839fde706ded2fafa18cafeff1 Author: Arnd Bergmann Date: Tue Apr 28 23:31:24 2020 +0200 drm/rockchip: cdn-dp-core: Make cdn_dp_core_resume __maybe_unused commit 040b8907ccf1c78d020aca29800036565d761d73 upstream. With the new static annotation, the compiler warns when the functions are actually unused: drivers/gpu/drm/rockchip/cdn-dp-core.c:1123:12: error: 'cdn_dp_resume' defined but not used [-Werror=unused-function] 1123 | static int cdn_dp_resume(struct device *dev) | ^~~~~~~~~~~~~ Mark them __maybe_unused to suppress that warning as well. [ Not so 'new' static annotations any more, and I removed the part of the patch that added __maybe_unused to cdn_dp_suspend(), because it's used by the shutdown/remove code. So only the resume function ends up possibly unused if CONFIG_PM isn't set - Linus ] Fixes: 7c49abb4c2f8 ("drm/rockchip: cdn-dp-core: Make cdn_dp_core_suspend/resume static") Signed-off-by: Arnd Bergmann Reviewed-by: Enric Balletbo i Serra Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit fd9ed47fe6be437bccab7afb396a270b6c79e499 Author: Hoang Le Date: Mon Sep 13 16:28:52 2021 +0700 tipc: increase timeout in tipc_sk_enqueue() commit f4bb62e64c88c93060c051195d3bbba804e56945 upstream. In tipc_sk_enqueue() we use hardcoded 2 jiffies to extract socket buffer from generic queue to particular socket. The 2 jiffies is too short in case there are other high priority tasks get CPU cycles for multiple jiffies update. As result, no buffer could be enqueued to particular socket. To solve this, we switch to use constant timeout 20msecs. Then, the function will be expired between 2 jiffies (CONFIG_100HZ) and 20 jiffies (CONFIG_1000HZ). Fixes: c637c1035534 ("tipc: resolve race problem at unicast message reception") Acked-by: Jon Maloy Signed-off-by: Hoang Le Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit abe460eb6fbb7720010e82cf1e386ace87cec422 Author: Florian Fainelli Date: Thu Sep 9 10:33:28 2021 -0700 r6040: Restore MDIO clock frequency after MAC reset commit e3f0cc1a945fcefec0c7c9d9dfd028a51daa1846 upstream. A number of users have reported that they were not able to get the PHY to successfully link up, especially after commit c36757eb9dee ("net: phy: consider AN_RESTART status when reading link status") where we stopped reading just BMSR, but we also read BMCR to determine the link status. Andrius at NetBSD did a wonderful job at debugging the problem and found out that the MDIO bus clock frequency would be incorrectly set back to its default value which would prevent the MDIO bus controller from reading PHY registers properly. Back when we only read BMSR, if we read all 1s, we could falsely indicate a link status, though in general there is a cable plugged in, so this went unnoticed. After a second read of BMCR was added, a wrong read will lead to the inability to determine a link UP condition which is when it started to be visibly broken, even if it was long before that. The fix consists in restoring the value of the MD_CSR register that was set prior to the MAC reset. Link: http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=53494 Fixes: 90f750a81a29 ("r6040: consolidate MAC reset to its own function") Reported-by: Andrius V Reported-by: Darek Strugacz Tested-by: Darek Strugacz Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit edfab735d5182fbfe5b5773869304291aaa12be8 Author: Xiyu Yang Date: Thu Sep 9 12:32:00 2021 +0800 net/l2tp: Fix reference count leak in l2tp_udp_recv_core commit 9b6ff7eb666415e1558f1ba8a742f5db6a9954de upstream. The reference count leak issue may take place in an error handling path. If both conditions of tunnel->version == L2TP_HDR_VER_3 and the return value of l2tp_v3_ensure_opt_in_linear is nonzero, the function would directly jump to label invalid, without decrementing the reference count of the l2tp_session object session increased earlier by l2tp_tunnel_get_session(). This may result in refcount leaks. Fix this issue by decrease the reference count before jumping to the label invalid. Fixes: 4522a70db7aa ("l2tp: fix reading optional fields of L2TPv3") Signed-off-by: Xiyu Yang Signed-off-by: Xin Xiong Signed-off-by: Xin Tan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6c3cb65d561e76fd0398026c023e587fec70e188 Author: Lin, Zhenpeng Date: Wed Sep 8 03:40:59 2021 +0000 dccp: don't duplicate ccid when cloning dccp sock commit d9ea761fdd197351890418acd462c51f241014a7 upstream. Commit 2677d2067731 ("dccp: don't free ccid2_hc_tx_sock ...") fixed a UAF but reintroduced CVE-2017-6074. When the sock is cloned, two dccps_hc_tx_ccid will reference to the same ccid. So one can free the ccid object twice from two socks after cloning. This issue was found by "Hadar Manor" as well and assigned with CVE-2020-16119, which was fixed in Ubuntu's kernel. So here I port the patch from Ubuntu to fix it. The patch prevents cloned socks from referencing the same ccid. Fixes: 2677d2067731410 ("dccp: don't free ccid2_hc_tx_sock ...") Signed-off-by: Zhenpeng Lin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f6f80766558b72d59bd7a25519abc55c71c126c7 Author: Randy Dunlap Date: Mon Sep 13 15:06:05 2021 -0700 ptp: dp83640: don't define PAGE0 commit 7366c23ff492ad260776a3ee1aaabba9fc773a8b upstream. Building dp83640.c on arch/parisc/ produces a build warning for PAGE0 being redefined. Since the macro is not used in the dp83640 driver, just make it a comment for documentation purposes. In file included from ../drivers/net/phy/dp83640.c:23: ../drivers/net/phy/dp83640_reg.h:8: warning: "PAGE0" redefined 8 | #define PAGE0 0x0000 from ../drivers/net/phy/dp83640.c:11: ../arch/parisc/include/asm/page.h:187: note: this is the location of the previous definition 187 | #define PAGE0 ((struct zeropage *)__PAGE_OFFSET) Fixes: cb646e2b02b2 ("ptp: Added a clock driver for the National Semiconductor PHYTER.") Signed-off-by: Randy Dunlap Reported-by: Geert Uytterhoeven Cc: Richard Cochran Cc: John Stultz Cc: Heiner Kallweit Cc: Russell King Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20210913220605.19682-1-rdunlap@infradead.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit bd6d9a0dd4111691542ef84db5847fcbdda35686 Author: Eric Dumazet Date: Mon Sep 13 11:08:36 2021 -0700 net-caif: avoid user-triggerable WARN_ON(1) commit 550ac9c1aaaaf51fd42e20d461f0b1cdbd55b3d2 upstream. syszbot triggers this warning, which looks something we can easily prevent. If we initialize priv->list_field in chnl_net_init(), then always use list_del_init(), we can remove robust_list_del() completely. WARNING: CPU: 0 PID: 3233 at net/caif/chnl_net.c:67 robust_list_del net/caif/chnl_net.c:67 [inline] WARNING: CPU: 0 PID: 3233 at net/caif/chnl_net.c:67 chnl_net_uninit+0xc9/0x2e0 net/caif/chnl_net.c:375 Modules linked in: CPU: 0 PID: 3233 Comm: syz-executor.3 Not tainted 5.14.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:robust_list_del net/caif/chnl_net.c:67 [inline] RIP: 0010:chnl_net_uninit+0xc9/0x2e0 net/caif/chnl_net.c:375 Code: 89 eb e8 3a a3 ba f8 48 89 d8 48 c1 e8 03 42 80 3c 28 00 0f 85 bf 01 00 00 48 81 fb 00 14 4e 8d 48 8b 2b 75 d0 e8 17 a3 ba f8 <0f> 0b 5b 5d 41 5c 41 5d e9 0a a3 ba f8 4c 89 e3 e8 02 a3 ba f8 4c RSP: 0018:ffffc90009067248 EFLAGS: 00010202 RAX: 0000000000008780 RBX: ffffffff8d4e1400 RCX: ffffc9000fd34000 RDX: 0000000000040000 RSI: ffffffff88bb6e49 RDI: 0000000000000003 RBP: ffff88802cd9ee08 R08: 0000000000000000 R09: ffffffff8d0e6647 R10: ffffffff88bb6dc2 R11: 0000000000000000 R12: ffff88803791ae08 R13: dffffc0000000000 R14: 00000000e600ffce R15: ffff888073ed3480 FS: 00007fed10fa0700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2c322000 CR3: 00000000164a6000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: register_netdevice+0xadf/0x1500 net/core/dev.c:10347 ipcaif_newlink+0x4c/0x260 net/caif/chnl_net.c:468 __rtnl_newlink+0x106d/0x1750 net/core/rtnetlink.c:3458 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3506 rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5572 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504 netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340 netlink_sendmsg+0x86d/0xdb0 net/netlink/af_netlink.c:1929 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:724 __sys_sendto+0x21c/0x320 net/socket.c:2036 __do_sys_sendto net/socket.c:2048 [inline] __se_sys_sendto net/socket.c:2044 [inline] __x64_sys_sendto+0xdd/0x1b0 net/socket.c:2044 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: cc36a070b590 ("net-caif: add CAIF netdevice") Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 855c17ffa65fe61b1e3cc9164833496191dc61e1 Author: Eli Cohen Date: Wed Sep 15 07:47:27 2021 +0300 net/{mlx5|nfp|bnxt}: Remove unnecessary RTNL lock assert commit 7c3a0a018e672a9723a79b128227272562300055 upstream. Remove the assert from the callback priv lookup function since it does not require RTNL lock and is already protected by flow_indr_block_lock. This will avoid warnings from being emitted to dmesg if the driver registers its callback after an ingress qdisc was created for a netdevice. The warnings started after the following patch was merged: commit 74fc4f828769 ("net: Fix offloading indirect devices dependency on qdisc order creation") Signed-off-by: Eli Cohen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c5c9ee2d367bf4e9939e2888e20999b932c545e9 Author: Saeed Mahameed Date: Mon Jul 26 15:15:39 2021 -0700 ethtool: Fix rxnfc copy to user buffer overflow commit 9b29a161ef38040f000dcf9ccf78e34495edfd55 upstream. In the cited commit, copy_to_user() got called with the wrong pointer, instead of passing the actual buffer ptr to copy from, a pointer to the pointer got passed, which causes a buffer overflow calltrace to pop up when executing "ethtool -x ethX". Fix ethtool_rxnfc_copy_to_user() to use the rxnfc pointer as passed to the function, instead of a pointer to it. This fixes below call trace: [ 15.533533] ------------[ cut here ]------------ [ 15.539007] Buffer overflow detected (8 < 192)! [ 15.544110] WARNING: CPU: 3 PID: 1801 at include/linux/thread_info.h:200 copy_overflow+0x15/0x20 [ 15.549308] Modules linked in: [ 15.551449] CPU: 3 PID: 1801 Comm: ethtool Not tainted 5.14.0-rc2+ #1058 [ 15.553919] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 15.558378] RIP: 0010:copy_overflow+0x15/0x20 [ 15.560648] Code: e9 7c ff ff ff b8 a1 ff ff ff eb c4 66 0f 1f 84 00 00 00 00 00 55 48 89 f2 89 fe 48 c7 c7 88 55 78 8a 48 89 e5 e8 06 5c 1e 00 <0f> 0b 5d c3 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 55 [ 15.565114] RSP: 0018:ffffad49c0523bd0 EFLAGS: 00010286 [ 15.566231] RAX: 0000000000000000 RBX: 00000000000000c0 RCX: 0000000000000000 [ 15.567616] RDX: 0000000000000001 RSI: ffffffff8a7912e7 RDI: 00000000ffffffff [ 15.569050] RBP: ffffad49c0523bd0 R08: ffffffff8ab2ae28 R09: 00000000ffffdfff [ 15.570534] R10: ffffffff8aa4ae40 R11: ffffffff8aa4ae40 R12: 0000000000000000 [ 15.571899] R13: 00007ffd4cc2a230 R14: ffffad49c0523c00 R15: 0000000000000000 [ 15.573584] FS: 00007f538112f740(0000) GS:ffff96d5bdd80000(0000) knlGS:0000000000000000 [ 15.575639] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 15.577092] CR2: 00007f5381226d40 CR3: 0000000013542000 CR4: 00000000001506e0 [ 15.578929] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 15.580695] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 15.582441] Call Trace: [ 15.582970] ethtool_rxnfc_copy_to_user+0x30/0x46 [ 15.583815] ethtool_get_rxnfc.cold+0x23/0x2b [ 15.584584] dev_ethtool+0x29c/0x25f0 [ 15.585286] ? security_netlbl_sid_to_secattr+0x77/0xd0 [ 15.586728] ? do_set_pte+0xc4/0x110 [ 15.587349] ? _raw_spin_unlock+0x18/0x30 [ 15.588118] ? __might_sleep+0x49/0x80 [ 15.588956] dev_ioctl+0x2c1/0x490 [ 15.589616] sock_ioctl+0x18e/0x330 [ 15.591143] __x64_sys_ioctl+0x41c/0x990 [ 15.591823] ? irqentry_exit_to_user_mode+0x9/0x20 [ 15.592657] ? irqentry_exit+0x33/0x40 [ 15.593308] ? exc_page_fault+0x32f/0x770 [ 15.593877] ? exit_to_user_mode_prepare+0x3c/0x130 [ 15.594775] do_syscall_64+0x35/0x80 [ 15.595397] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 15.596037] RIP: 0033:0x7f5381226d4b [ 15.596492] Code: 0f 1e fa 48 8b 05 3d b1 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 0d b1 0c 00 f7 d8 64 89 01 48 [ 15.598743] RSP: 002b:00007ffd4cc2a1f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 15.599804] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5381226d4b [ 15.600795] RDX: 00007ffd4cc2a350 RSI: 0000000000008946 RDI: 0000000000000003 [ 15.601712] RBP: 00007ffd4cc2a340 R08: 00007ffd4cc2a350 R09: 0000000000000001 [ 15.602751] R10: 00007f538128a990 R11: 0000000000000246 R12: 0000000000000000 [ 15.603882] R13: 00007ffd4cc2a350 R14: 00007ffd4cc2a4b0 R15: 0000000000000000 [ 15.605042] ---[ end trace 325cf185e2795048 ]--- Fixes: dd98d2895de6 ("ethtool: improve compat ioctl handling") Reported-by: Shannon Nelson CC: Arnd Bergmann CC: Christoph Hellwig Signed-off-by: Saeed Mahameed Tested-by: Shannon Nelson Acked-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ee3ffd56b40ea6e5128502d03b49ffb53a09c7f6 Author: Xin Long Date: Fri Jul 23 13:25:36 2021 -0400 tipc: fix an use-after-free issue in tipc_recvmsg commit cc19862ffe454a5b632ca202e5a51bfec9f89fd2 upstream. syzbot reported an use-after-free crash: BUG: KASAN: use-after-free in tipc_recvmsg+0xf77/0xf90 net/tipc/socket.c:1979 Call Trace: tipc_recvmsg+0xf77/0xf90 net/tipc/socket.c:1979 sock_recvmsg_nosec net/socket.c:943 [inline] sock_recvmsg net/socket.c:961 [inline] sock_recvmsg+0xca/0x110 net/socket.c:957 tipc_conn_rcv_from_sock+0x162/0x2f0 net/tipc/topsrv.c:398 tipc_conn_recv_work+0xeb/0x190 net/tipc/topsrv.c:421 process_one_work+0x98d/0x1630 kernel/workqueue.c:2276 worker_thread+0x658/0x11f0 kernel/workqueue.c:2422 As Hoang pointed out, it was caused by skb_cb->bytes_read still accessed after calling tsk_advance_rx_queue() to free the skb in tipc_recvmsg(). This patch is to fix it by accessing skb_cb->bytes_read earlier than calling tsk_advance_rx_queue(). Fixes: f4919ff59c28 ("tipc: keep the skb in rcv queue until the whole data is read") Reported-by: syzbot+e6741b97d5552f97c24d@syzkaller.appspotmail.com Signed-off-by: Xin Long Acked-by: Jon Maloy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 12551b75b00b8d1de3a944ab44c997bee7c9bce0 Author: Mike Rapoport Date: Thu Aug 19 16:27:17 2021 +0300 x86/mm: Fix kern_addr_valid() to cope with existing but not present entries commit 34b1999da935a33be6239226bfa6cd4f704c5c88 upstream. Jiri Olsa reported a fault when running: # cat /proc/kallsyms | grep ksys_read ffffffff8136d580 T ksys_read # objdump -d --start-address=0xffffffff8136d580 --stop-address=0xffffffff8136d590 /proc/kcore /proc/kcore: file format elf64-x86-64 Segmentation fault general protection fault, probably for non-canonical address 0xf887ffcbff000: 0000 [#1] SMP PTI CPU: 12 PID: 1079 Comm: objdump Not tainted 5.14.0-rc5qemu+ #508 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-4.fc34 04/01/2014 RIP: 0010:kern_addr_valid Call Trace: read_kcore ? rcu_read_lock_sched_held ? rcu_read_lock_sched_held ? rcu_read_lock_sched_held ? trace_hardirqs_on ? rcu_read_lock_sched_held ? lock_acquire ? lock_acquire ? rcu_read_lock_sched_held ? lock_acquire ? rcu_read_lock_sched_held ? rcu_read_lock_sched_held ? rcu_read_lock_sched_held ? lock_release ? _raw_spin_unlock ? __handle_mm_fault ? rcu_read_lock_sched_held ? lock_acquire ? rcu_read_lock_sched_held ? lock_release proc_reg_read ? vfs_read vfs_read ksys_read do_syscall_64 entry_SYSCALL_64_after_hwframe The fault happens because kern_addr_valid() dereferences existent but not present PMD in the high kernel mappings. Such PMDs are created when free_kernel_image_pages() frees regions larger than 2Mb. In this case, a part of the freed memory is mapped with PMDs and the set_memory_np_noalias() -> ... -> __change_page_attr() sequence will mark the PMD as not present rather than wipe it completely. Have kern_addr_valid() check whether higher level page table entries are present before trying to dereference them to fix this issue and to avoid similar issues in the future. Stable backporting note: ------------------------ Note that the stable marking is for all active stable branches because there could be cases where pagetable entries exist but are not valid - see 9a14aefc1d28 ("x86: cpa, fix lookup_address"), for example. So make sure to be on the safe side here and use pXY_present() accessors rather than pXY_none() which could #GP when accessing pages in the direct map. Also see: c40a56a7818c ("x86/mm/init: Remove freed kernel image areas from alias mapping") for more info. Reported-by: Jiri Olsa Signed-off-by: Mike Rapoport Signed-off-by: Borislav Petkov Reviewed-by: David Hildenbrand Acked-by: Dave Hansen Tested-by: Jiri Olsa Cc: # 4.4+ Link: https://lkml.kernel.org/r/20210819132717.19358-1-rppt@kernel.org Signed-off-by: Greg Kroah-Hartman commit 6672dc68e28eca6ba8ffc2809db4cdd8f0cc5d12 Author: Jeff Moyer Date: Wed Aug 11 17:07:37 2021 -0400 x86/pat: Pass valid address to sanitize_phys() commit aeef8b5089b76852bd84889f2809e69a7cfb414e upstream. The end address passed to memtype_reserve() is handed directly to sanitize_phys(). However, end is exclusive and sanitize_phys() expects an inclusive address. If end falls at the end of the physical address space, sanitize_phys() will return 0. This can result in drivers failing to load, and the following warning: WARNING: CPU: 26 PID: 749 at arch/x86/mm/pat.c:354 reserve_memtype+0x262/0x450 reserve_memtype failed: [mem 0x3ffffff00000-0xffffffffffffffff], req uncached-minus Call Trace: [] reserve_memtype+0x262/0x450 [] ioremap_nocache+0x1a/0x20 [] mpt3sas_base_map_resources+0x151/0xa60 [mpt3sas] [] mpt3sas_base_attach+0xf5/0xa50 [mpt3sas] ---[ end trace 6d6eea4438db89ef ]--- ioremap reserve_memtype failed -22 mpt3sas_cm0: unable to map adapter memory! or resource not found mpt3sas_cm0: failure at drivers/scsi/mpt3sas/mpt3sas_scsih.c:10597/_scsih_probe()! Fix this by passing the inclusive end address to sanitize_phys(). Fixes: 510ee090abc3 ("x86/mm/pat: Prepare {reserve, free}_memtype() for "decoy" addresses") Signed-off-by: Jeff Moyer Signed-off-by: Thomas Gleixner Reviewed-by: David Hildenbrand Reviewed-by: Dan Williams Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/x49o8a3pu5i.fsf@segfault.boston.devel.redhat.com Signed-off-by: Greg Kroah-Hartman commit 0346f8a2c5ecef2fea9932ebeb447c0d957f749a Author: Alexander Egorenkov Date: Thu Sep 9 12:20:56 2021 +0200 s390/sclp: fix Secure-IPL facility detection commit d76b14f3971a0638b6cd0da289f8b48acee287d0 upstream. Prevent out-of-range access if the returned SCLP SCCB response is smaller in size than the address of the Secure-IPL flag. Fixes: c9896acc7851 ("s390/ipl: Provide has_secure sysfs attribute") Cc: stable@vger.kernel.org # 5.2+ Signed-off-by: Alexander Egorenkov Reviewed-by: Christian Borntraeger Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit cc9d96c9f9e009b8a33385fab9b78ccf92e51d6e Author: Lucas Stach Date: Fri Aug 20 22:18:30 2021 +0200 drm/etnaviv: add missing MMU context put when reaping MMU mapping commit f2faea8b64125852fa9acc6771c07fc0311a039b upstream. When we forcefully evict a mapping from the the address space and thus the MMU context, the MMU context is leaked, as the mapping no longer points to it, so it doesn't get freed when the GEM object is destroyed. Add the mssing context put to fix the leak. Cc: stable@vger.kernel.org # 5.4 Signed-off-by: Lucas Stach Tested-by: Michael Walle Tested-by: Marek Vasut Reviewed-by: Christian Gmeiner Signed-off-by: Greg Kroah-Hartman commit ea995e8a629446c4a27e7f8042fc08e05659298b Author: Lucas Stach Date: Fri Aug 20 22:18:29 2021 +0200 drm/etnaviv: reference MMU context when setting up hardware state commit d6408538f091fb22d47f792d4efa58143d56c3fb upstream. Move the refcount manipulation of the MMU context to the point where the hardware state is programmed. At that point it is also known if a previous MMU state is still there, or the state needs to be reprogrammed with a potentially different context. Cc: stable@vger.kernel.org # 5.4 Signed-off-by: Lucas Stach Tested-by: Michael Walle Tested-by: Marek Vasut Reviewed-by: Christian Gmeiner Signed-off-by: Greg Kroah-Hartman commit 660dfbf208a4bf3eaab8560e8671be831b52e1c1 Author: Lucas Stach Date: Fri Aug 20 22:18:28 2021 +0200 drm/etnaviv: fix MMU context leak on GPU reset commit f978a5302f5566480c58ffae64a16d34456801bd upstream. After a reset the GPU is no longer using the MMU context and may be restarted with a different context. While the mmu_state proeprly was cleared, the context wasn't unreferenced, leading to a memory leak. Cc: stable@vger.kernel.org # 5.4 Reported-by: Michael Walle Signed-off-by: Lucas Stach Tested-by: Michael Walle Tested-by: Marek Vasut Reviewed-by: Christian Gmeiner Signed-off-by: Greg Kroah-Hartman commit 22163efedcf303e7d1b73bb3bd3aee26bd41b888 Author: Lucas Stach Date: Fri Aug 20 22:18:27 2021 +0200 drm/etnaviv: exec and MMU state is lost when resetting the GPU commit 725cbc7884c37f3b4f1777bc1aea6432cded8ca5 upstream. When the GPU is reset both the current exec state, as well as all MMU state is lost. Move the driver side state tracking into the reset function to keep hardware and software state from diverging. Cc: stable@vger.kernel.org # 5.4 Signed-off-by: Lucas Stach Tested-by: Michael Walle Tested-by: Marek Vasut Reviewed-by: Christian Gmeiner Signed-off-by: Greg Kroah-Hartman commit 6b1c223d8a53a9b08f06c65d932eeb3278022ee8 Author: Lucas Stach Date: Fri Aug 20 22:18:26 2021 +0200 drm/etnaviv: keep MMU context across runtime suspend/resume commit 8f3eea9d01d7b0f95b0fe04187c0059019ada85b upstream. The MMU state may be kept across a runtime suspend/resume cycle, as we avoid a full hardware reset to keep the latency of the runtime PM small. Don't pretend that the MMU state is lost in driver state. The MMU context is pushed out when new HW jobs with a different context are coming in. The only exception to this is when the GPU is unbound, in which case we need to make sure to also free the last active context. Cc: stable@vger.kernel.org # 5.4 Reported-by: Michael Walle Signed-off-by: Lucas Stach Tested-by: Michael Walle Tested-by: Marek Vasut Reviewed-by: Christian Gmeiner Signed-off-by: Greg Kroah-Hartman commit c63e6e0951ff4ab021947b834db37f591781ee28 Author: Lucas Stach Date: Fri Aug 20 22:18:25 2021 +0200 drm/etnaviv: stop abusing mmu_context as FE running marker commit 23e0f5a57d0ecec86e1fc82194acd94aede21a46 upstream. While the DMA frontend can only be active when the MMU context is set, the reverse isn't necessarily true, as the frontend can be stopped while the MMU state is kept. Stop treating mmu_context being set as a indication that the frontend is running and instead add a explicit property. Cc: stable@vger.kernel.org # 5.4 Signed-off-by: Lucas Stach Tested-by: Michael Walle Tested-by: Marek Vasut Reviewed-by: Christian Gmeiner Signed-off-by: Greg Kroah-Hartman commit cf24bd826e4b4c99b2f183a2cc605b0ae641420a Author: Lucas Stach Date: Fri Aug 20 22:18:24 2021 +0200 drm/etnaviv: put submit prev MMU context when it exists commit cda7532916f7bc860b36a1806cb8352e6f63dacb upstream. The prev context is the MMU context at the time of the job queueing in hardware. As a job might be queued multiple times due to recovery after a GPU hang, we need to make sure to put the stale prev MMU context from a prior queuing, to avoid the reference and thus the MMU context leaking. Cc: stable@vger.kernel.org # 5.4 Signed-off-by: Lucas Stach Tested-by: Michael Walle Tested-by: Marek Vasut Reviewed-by: Christian Gmeiner Signed-off-by: Greg Kroah-Hartman commit 0759f648470b5713b0ed89353607a8e0cd3f395e Author: Lucas Stach Date: Fri Aug 20 22:18:23 2021 +0200 drm/etnaviv: return context from etnaviv_iommu_context_get commit 78edefc05e41352099ffb8f06f8d9b2d091e29cd upstream. Being able to have the refcount manipulation in an assignment makes it much easier to parse the code. Cc: stable@vger.kernel.org # 5.4 Signed-off-by: Lucas Stach Tested-by: Michael Walle Tested-by: Marek Vasut Reviewed-by: Christian Gmeiner Signed-off-by: Greg Kroah-Hartman commit 8f95553f0016c3994d9c022b5af4a1a433d6714e Author: Ernst Sjöstrand Date: Thu Sep 2 09:50:27 2021 +0200 drm/amd/amdgpu: Increase HWIP_MAX_INSTANCE to 10 commit 67a44e659888569a133a8f858c8230e9d7aad1d5 upstream. Seems like newer cards can have even more instances now. Found by UBSAN: array-index-out-of-bounds in drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:318:29 index 8 is out of range for type 'uint32_t *[8]' Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1697 Cc: stable@vger.kernel.org Signed-off-by: Ernst Sjöstrand Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 87f7032dc2276cec3317c01d626c86093353f39e Author: Evan Quan Date: Fri Sep 3 14:33:11 2021 +0800 PCI: Add AMD GPU multi-function power dependencies commit 60b78ed088ebe1a872ee1320b6c5ad6ee2c4bd9a upstream. Some AMD GPUs have built-in USB xHCI and USB Type-C UCSI controllers with power dependencies between the GPU and the other functions as in 6d2e369f0d4c ("PCI: Add NVIDIA GPU multi-function power dependencies"). Add device link support for the AMD integrated USB xHCI and USB Type-C UCSI controllers. Without this, runtime power management, including GPU resume and temp and fan sensors don't work correctly. Reported-at: https://gitlab.freedesktop.org/drm/amd/-/issues/1704 Link: https://lore.kernel.org/r/20210903063311.3606226-1-evan.quan@amd.com Signed-off-by: Evan Quan Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit cd64b416aed2f152d89c25db2ebf4f05e16fc08d Author: Juergen Gross Date: Fri Sep 3 10:49:36 2021 +0200 PM: base: power: don't try to use non-existing RTC for storing data commit 0560204b360a332c321124dbc5cdfd3364533a74 upstream. If there is no legacy RTC device, don't try to use it for storing trace data across suspend/resume. Cc: Signed-off-by: Juergen Gross Reviewed-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/20210903084937.19392-2-jgross@suse.com Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit a67e7cdbc633076e5e54ae40d68581c55daea5b5 Author: Mark Brown Date: Thu Sep 9 17:53:56 2021 +0100 arm64/sve: Use correct size when reinitialising SVE state commit e35ac9d0b56e9efefaeeb84b635ea26c2839ea86 upstream. When we need a buffer for SVE register state we call sve_alloc() to make sure that one is there. In order to avoid repeated allocations and frees we keep the buffer around unless we change vector length and just memset() it to ensure a clean register state. The function that deals with this takes the task to operate on as an argument, however in the case where we do a memset() we initialise using the SVE state size for the current task rather than the task passed as an argument. This is only an issue in the case where we are setting the register state for a task via ptrace and the task being configured has a different vector length to the task tracing it. In the case where the buffer is larger in the traced process we will leak old state from the traced process to itself, in the case where the buffer is smaller in the traced process we will overflow the buffer and corrupt memory. Fixes: bc0ee4760364 ("arm64/sve: Core task context handling") Cc: # 4.15.x Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20210909165356.10675-1-broonie@kernel.org Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 84da60070c36ddcd8bf4a576e637be8e86535ede Author: Adrian Bunk Date: Sun Sep 12 22:05:23 2021 +0300 bnx2x: Fix enabling network interfaces without VFs commit 52ce14c134a003fee03d8fc57442c05a55b53715 upstream. This function is called to enable SR-IOV when available, not enabling interfaces without VFs was a regression. Fixes: 65161c35554f ("bnx2x: Fix missing error code in bnx2x_iov_init_one()") Signed-off-by: Adrian Bunk Reported-by: YunQiang Su Tested-by: YunQiang Su Cc: stable@vger.kernel.org Acked-by: Shai Malin Link: https://lore.kernel.org/r/20210912190523.27991-1-bunk@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1a5a3ba21aeebc6908c06c31125bcdc7584194a2 Author: Juergen Gross Date: Fri Sep 3 10:49:37 2021 +0200 xen: reset legacy rtc flag for PV domU commit f68aa100d815b5b4467fd1c3abbe3b99d65fd028 upstream. A Xen PV guest doesn't have a legacy RTC device, so reset the legacy RTC flag. Otherwise the following WARN splat will occur at boot: [ 1.333404] WARNING: CPU: 1 PID: 1 at /home/gross/linux/head/drivers/rtc/rtc-mc146818-lib.c:25 mc146818_get_time+0x1be/0x210 [ 1.333404] Modules linked in: [ 1.333404] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 5.14.0-rc7-default+ #282 [ 1.333404] RIP: e030:mc146818_get_time+0x1be/0x210 [ 1.333404] Code: c0 64 01 c5 83 fd 45 89 6b 14 7f 06 83 c5 64 89 6b 14 41 83 ec 01 b8 02 00 00 00 44 89 63 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 <0f> 0b 48 c7 c7 30 0e ef 82 4c 89 e6 e8 71 2a 24 00 48 c7 c0 ff ff [ 1.333404] RSP: e02b:ffffc90040093df8 EFLAGS: 00010002 [ 1.333404] RAX: 00000000000000ff RBX: ffffc90040093e34 RCX: 0000000000000000 [ 1.333404] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 000000000000000d [ 1.333404] RBP: ffffffff82ef0e30 R08: ffff888005013e60 R09: 0000000000000000 [ 1.333404] R10: ffffffff82373e9b R11: 0000000000033080 R12: 0000000000000200 [ 1.333404] R13: 0000000000000000 R14: 0000000000000002 R15: ffffffff82cdc6d4 [ 1.333404] FS: 0000000000000000(0000) GS:ffff88807d440000(0000) knlGS:0000000000000000 [ 1.333404] CS: 10000e030 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.333404] CR2: 0000000000000000 CR3: 000000000260a000 CR4: 0000000000050660 [ 1.333404] Call Trace: [ 1.333404] ? wakeup_sources_sysfs_init+0x30/0x30 [ 1.333404] ? rdinit_setup+0x2b/0x2b [ 1.333404] early_resume_init+0x23/0xa4 [ 1.333404] ? cn_proc_init+0x36/0x36 [ 1.333404] do_one_initcall+0x3e/0x200 [ 1.333404] kernel_init_freeable+0x232/0x28e [ 1.333404] ? rest_init+0xd0/0xd0 [ 1.333404] kernel_init+0x16/0x120 [ 1.333404] ret_from_fork+0x1f/0x30 Cc: Fixes: 8d152e7a5c7537 ("x86/rtc: Replace paravirt rtc check with platform legacy quirk") Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Link: https://lore.kernel.org/r/20210903084937.19392-3-jgross@suse.com Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit ce8f81b76d3bef7b9fe6c8f84d029ab898b19469 Author: Jens Axboe Date: Sun Sep 12 06:45:07 2021 -0600 io_uring: ensure symmetry in handling iter types in loop_rw_iter() commit 16c8d2df7ec0eed31b7d3b61cb13206a7fb930cc upstream. When setting up the next segment, we check what type the iter is and handle it accordingly. However, when incrementing and processed amount we do not, and both iter advance and addr/len are adjusted, regardless of type. Split the increment side just like we do on the setup side. Fixes: 4017eb91a9e7 ("io_uring: make loop_rw_iter() use original user supplied pointers") Cc: stable@vger.kernel.org Reported-by: Valentina Palmiotti Reviewed-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 88f3d951e2dbdc7927da799792d885c20b8b94d5 Author: Anand Jain Date: Tue Aug 10 23:23:44 2021 +0800 btrfs: fix upper limit for max_inline for page size 64K commit 6f93e834fa7c5faa0372e46828b4b2a966ac61d7 upstream. The mount option max_inline ranges from 0 to the sectorsize (which is now equal to page size). But we parse the mount options too early and before the actual sectorsize is read from the superblock. So the upper limit of max_inline is unaware of the actual sectorsize and is limited by the temporary sectorsize 4096, even on a system where the default sectorsize is 64K. Fix this by reading the superblock sectorsize before the mount option parse. Reported-by: Alexander Tsvetkov CC: stable@vger.kernel.org # 5.4+ Signed-off-by: Anand Jain Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Anand Jain Signed-off-by: Greg Kroah-Hartman commit 575279059e26b27aababbb7edae2f0f19205779d Author: Robert Foss Date: Thu Dec 17 15:09:33 2020 +0100 drm/bridge: lt9611: Fix handling of 4k panels commit d1a97648ae028a44536927c87837c45ada7141c9 upstream. 4k requires two dsi pipes, so don't report MODE_OK when only a single pipe is configured. But rather report MODE_PANEL to signal that requirements of the panel are not being met. Reported-by: Peter Collingbourne Suggested-by: Peter Collingbourne Signed-off-by: Robert Foss Tested-by: John Stultz Tested-by: Anibal Limon Tested-by: Peter Collingbourne Reviewed-by: Bjorn Andersson Acked-by: Vinod Koul Link: https://patchwork.freedesktop.org/patch/msgid/20201217140933.1133969-1-robert.foss@linaro.org Cc: Peter Collingbourne Signed-off-by: Greg Kroah-Hartman commit faf816b0f8d0fa8ea24f579fb6a51e5ed3efd750 Author: Greg Kroah-Hartman Date: Sat Sep 18 13:40:38 2021 +0200 Linux 5.10.67 Link: https://lore.kernel.org/r/20210916155753.903069397@linuxfoundation.org Tested-by: Fox Chen Tested-by: Shuah Khan Tested-by: Florian Fainelli Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Guenter Roeck Tested-by: Sudip Mukherjee Tested-by: Salvatore Bonaccorso Tested-by: Hulk Robot Signed-off-by: Greg Kroah-Hartman commit ad3ea16746cc68307165d52e22a3f75015ccd16e Author: Amir Goldstein Date: Thu Mar 4 12:48:26 2021 +0200 fanotify: limit number of event merge attempts commit b8cd0ee8cda68a888a317991c1e918a8cba1a568 upstream. Event merges are expensive when event queue size is large, so limit the linear search to 128 merge tests. [Stable backport notes] The following statement from upstream commit is irrelevant for backport: - -In combination with 128 size hash table, there is a potential to merge -with up to 16K events in the hashed queue. - [Stable backport notes] The problem is as old as fanotify and described in the linked cover letter "Performance improvement for fanotify merge". This backported patch fixes the performance issue at the cost of merging fewer potential events. Fixing the performance issue is more important than preserving the "event merge" behavior, which was not predictable in any way that applications could rely on. Link: https://lore.kernel.org/r/20210304104826.3993892-6-amir73il@gmail.com Signed-off-by: Amir Goldstein Signed-off-by: Jan Kara Cc: Link: https://lore.kernel.org/linux-fsdevel/20210202162010.305971-1-amir73il@gmail.com/ Link: https://lore.kernel.org/linux-fsdevel/20210915163334.GD6166@quack2.suse.cz/ Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit 412974e75fdd0ce230dbfa2412dbf4a3e54a0b4e Author: Alyssa Rosenzweig Date: Tue Aug 24 13:30:27 2021 -0400 drm/panfrost: Clamp lock region to Bifrost minimum commit bd7ffbc3ca12629aeb66fb9e28cf42b7f37e3e3b upstream. When locking a region, we currently clamp to a PAGE_SIZE as the minimum lock region. While this is valid for Midgard, it is invalid for Bifrost, where the minimum locking size is 8x larger than the 4k page size. Add a hardware definition for the minimum lock region size (corresponding to KBASE_LOCK_REGION_MIN_SIZE_LOG2 in kbase) and respect it. Signed-off-by: Alyssa Rosenzweig Tested-by: Chris Morgan Reviewed-by: Steven Price Reviewed-by: Rob Herring Cc: Signed-off-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20210824173028.7528-4-alyssa.rosenzweig@collabora.com Signed-off-by: Greg Kroah-Hartman commit 8976e09443cbba49f1818c7fb217d016b247ee87 Author: Alyssa Rosenzweig Date: Tue Aug 24 13:30:26 2021 -0400 drm/panfrost: Use u64 for size in lock_region commit a77b58825d7221d4a45c47881c35a47ba003aa73 upstream. Mali virtual addresses are 48-bit. Use a u64 instead of size_t to ensure we can express the "lock everything" condition as ~0ULL without overflow. This code was silently broken on any platform where a size_t is less than 48-bits; in particular, it was broken on 32-bit armv7 platforms which remain in use with panfrost. (Mainly RK3288) Signed-off-by: Alyssa Rosenzweig Suggested-by: Rob Herring Tested-by: Chris Morgan Reviewed-by: Steven Price Reviewed-by: Rob Herring Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") Cc: Signed-off-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20210824173028.7528-3-alyssa.rosenzweig@collabora.com Signed-off-by: Greg Kroah-Hartman commit 95251e6833fa38199b3189d5621bc19b0c027e4b Author: Alyssa Rosenzweig Date: Tue Aug 24 13:30:25 2021 -0400 drm/panfrost: Simplify lock_region calculation commit b5fab345654c603c07525100d744498f28786929 upstream. In lock_region, simplify the calculation of the region_width parameter. This field is the size, but encoded as ceil(log2(size)) - 1. ceil(log2(size)) may be computed directly as fls(size - 1). However, we want to use the 64-bit versions as the amount to lock can exceed 32-bits. This avoids undefined (and completely wrong) behaviour when locking all memory (size ~0). In this case, the old code would "round up" ~0 to the nearest page, overflowing to 0. Since fls(0) == 0, this would calculate a region width of 10 + 0 = 10. But then the code would shift by (region_width - 11) = -1. As shifting by a negative number is undefined, UBSAN flags the bug. Of course, even if it were defined the behaviour is wrong, instead of locking all memory almost none would get locked. The new form of the calculation corrects this special case and avoids the undefined behaviour. Signed-off-by: Alyssa Rosenzweig Reported-and-tested-by: Chris Morgan Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") Cc: Reviewed-by: Steven Price Reviewed-by: Rob Herring Signed-off-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20210824173028.7528-2-alyssa.rosenzweig@collabora.com Signed-off-by: Greg Kroah-Hartman commit b80a99e048275d566d63f2463a2f640065ccbf75 Author: Jerry (Fangzhi) Zuo Date: Wed Jun 17 20:34:33 2020 -0400 drm/amd/display: Update bounding box states (v2) commit a7a9d11e12fcc32160d55e8612e72e5ab51b15dc upstream. [Why] Drop hardcoded dispclk, dppclk, phyclk [How] Read the corresponding values from clock table entries already populated. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1403 Cc: stable@vger.kernel.org Signed-off-by: Jerry (Fangzhi) Zuo Signed-off-by: Aurabindo Pillai Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 583c4f3d09c3e980a683b59febbb0c775bdff1db Author: Aurabindo Pillai Date: Tue Aug 24 15:10:50 2021 -0400 drm/amd/display: Update number of DCN3 clock states commit 0bbf06d888734041e813b916d7821acd4f72005a upstream. [Why & How] The DCN3 SoC parameter num_states was calculated but not saved into the object. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1403 Cc: stable@vger.kernel.org Signed-off-by: Aurabindo Pillai Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 7b1abace16a9dff6804d4eb94750beb60d9502b4 Author: Andrey Grodzovsky Date: Tue Jun 22 12:23:38 2021 -0400 drm/amdgpu: Fix BUG_ON assert commit ea7acd7c5967542353430947f3faf699e70602e5 upstream. With added CPU domain to placement you can have now 3 placemnts at once. CC: stable@kernel.org Signed-off-by: Andrey Grodzovsky Reviewed-by: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/20210622162339.761651-5-andrey.grodzovsky@amd.com Signed-off-by: Greg Kroah-Hartman commit c29485e34e63198dca6289639aa711f99d88e76e Author: Boris Brezillon Date: Mon Jun 21 15:38:56 2021 +0200 drm/panfrost: Make sure MMU context lifetime is not bound to panfrost_priv commit 7fdc48cc63a30fa3480d18bdd8c5fff2b9b15212 upstream. Jobs can be in-flight when the file descriptor is closed (either because the process did not terminate properly, or because it didn't wait for all GPU jobs to be finished), and apparently panfrost_job_close() does not cancel already running jobs. Let's refcount the MMU context object so it's lifetime is no longer bound to the FD lifetime and running jobs can finish properly without generating spurious page faults. Reported-by: Icecream95 Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces") Cc: Signed-off-by: Boris Brezillon Reviewed-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20210621133907.1683899-2-boris.brezillon@collabora.com Signed-off-by: Greg Kroah-Hartman commit bb693c114e8b53e3e0b8228be218d907d35959a5 Author: Rajkumar Subbiah Date: Tue Jul 6 08:30:34 2021 -0700 drm/dp_mst: Fix return code on sideband message failure commit 92bd92c44d0d9be5dcbcda315b4be4b909ed9740 upstream. Commit 2f015ec6eab6 ("drm/dp_mst: Add sideband down request tracing + selftests") added some debug code for sideband message tracing. But it seems to have unintentionally changed the behavior on sideband message failure. It catches and returns failure only if DRM_UT_DP is enabled. Otherwise it ignores the error code and returns success. So on an MST unplug, the caller is unaware that the clear payload message failed and ends up waiting for 4 seconds for the response. Fixes the issue by returning the proper error code. Changes in V2: -- Revise commit text as review comment -- add Fixes text Changes in V3: -- remove "unlikely" optimization Fixes: 2f015ec6eab6 ("drm/dp_mst: Add sideband down request tracing + selftests") Cc: # v5.5+ Signed-off-by: Rajkumar Subbiah Signed-off-by: Kuogee Hsieh Reviewed-by: Stephen Boyd Reviewed-by: Jani Nikula Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/1625585434-9562-1-git-send-email-khsieh@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit 84cac4f80605e023d3b6febb9adc520b236a3d17 Author: David Heidelberg Date: Wed Aug 11 19:06:31 2021 +0200 drm/msi/mdp4: populate priv->kms in mdp4_kms_init commit cb0927ab80d224c9074f53d1a55b087d12ec5a85 upstream. Without this fix boot throws NULL ptr exception at msm_dsi_manager_setup_encoder on devices like Nexus 7 2013 (MDP4 v4.4). Fixes: 03436e3ec69c ("drm/msm/dsi: Move setup_encoder to modeset_init") Cc: Signed-off-by: David Heidelberg Link: https://lore.kernel.org/r/20210811170631.39296-1-david@ixit.cz Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit be1fcecfc1457a6c51d242f817af162b9cee774a Author: Thomas Zimmermann Date: Wed Jul 14 16:22:28 2021 +0200 drm/mgag200: Select clock in PLL update functions commit 147696720eca12ae48d020726208b9a61cdd80bc upstream. Put the clock-selection code into each of the PLL-update functions to make them select the correct pixel clock. Instead of copying the code, introduce a new helper WREG_MISC_MASKED, which does masked writes into . Use it from each individual PLL update function. The pixel clock for video output was not actually set before programming the clock's values. It worked because the device had the correct clock pre-set. v2: * don't duplicate update code (Sam) Signed-off-by: Thomas Zimmermann Fixes: db05f8d3dc87 ("drm/mgag200: Split MISC register update into PLL selection, SYNC and I/O") Acked-by: Sam Ravnborg Cc: Sam Ravnborg Cc: Emil Velikov Cc: Dave Airlie Cc: dri-devel@lists.freedesktop.org Cc: # v5.9+ Link: https://patchwork.freedesktop.org/patch/msgid/20210714142240.21979-2-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit d0aaea1f117d21cbbf77bd201914ff06bc02fb1d Author: Jan Hoffmann Date: Wed Sep 1 20:49:33 2021 +0200 net: dsa: lantiq_gswip: fix maximum frame length commit 552799f8b3b0074d2617f53a63a088f9514a66e3 upstream. Currently, outgoing packets larger than 1496 bytes are dropped when tagged VLAN is used on a switch port. Add the frame check sequence length to the value of the register GSWIP_MAC_FLEN to fix this. This matches the lantiq_ppa vendor driver, which uses a value consisting of 1518 bytes for the MAC frame, plus the lengths of special tag and VLAN tags. Fixes: 14fceff4771e ("net: dsa: Add Lantiq / Intel DSA driver for vrx200") Cc: stable@vger.kernel.org Signed-off-by: Jan Hoffmann Acked-by: Hauke Mehrtens Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5944d0e2b0ab7f85cc32f216dd534aa91630ba04 Author: Kees Cook Date: Fri Jul 23 15:19:31 2021 -0700 lib/test_stackinit: Fix static initializer test commit f9398f15605a50110bf570aaa361163a85113dd1 upstream. The static initializer test got accidentally converted to a dynamic initializer. Fix this and retain the giant padding hole without using an aligned struct member. Fixes: 50ceaa95ea09 ("lib: Introduce test_stackinit module") Cc: Ard Biesheuvel Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20210723221933.3431999-2-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman commit 00cdb2fb4df1d3e8e69751c8da22772ef1f7de07 Author: Patryk Duda Date: Tue May 18 16:07:58 2021 +0200 platform/chrome: cros_ec_proto: Send command again when timeout occurs commit 3abc16af57c9939724df92fcbda296b25cc95168 upstream. Sometimes kernel is trying to probe Fingerprint MCU (FPMCU) when it hasn't initialized SPI yet. This can happen because FPMCU is restarted during system boot and kernel can send message in short window eg. between sysjump to RW and SPI initialization. Cc: # 4.4+ Signed-off-by: Patryk Duda Link: https://lore.kernel.org/r/20210518140758.29318-1-pdk@semihalf.com Signed-off-by: Benson Leung Signed-off-by: Greg Kroah-Hartman commit b2e72e53cd26c1bccf42b94b0faea47ef9e55461 Author: sumiyawang Date: Sun Aug 22 19:49:09 2021 +0800 libnvdimm/pmem: Fix crash triggered when I/O in-flight during unbind commit 32b2397c1e56f33b0b1881def965bb89bd12f448 upstream. There is a use after free crash when the pmem driver tears down its mapping while I/O is still inbound. This is triggered by driver unbind, "ndctl destroy-namespace", while I/O is in flight. Fix the sequence of blk_cleanup_queue() vs memunmap(). The crash signature is of the form: BUG: unable to handle page fault for address: ffffc90080200000 CPU: 36 PID: 9606 Comm: systemd-udevd Call Trace: ? pmem_do_bvec+0xf9/0x3a0 ? xas_alloc+0x55/0xd0 pmem_rw_page+0x4b/0x80 bdev_read_page+0x86/0xb0 do_mpage_readpage+0x5d4/0x7a0 ? lru_cache_add+0xe/0x10 mpage_readpages+0xf9/0x1c0 ? bd_link_disk_holder+0x1a0/0x1a0 blkdev_readpages+0x1d/0x20 read_pages+0x67/0x1a0 ndctl Call Trace in vmcore: PID: 23473 TASK: ffff88c4fbbe8000 CPU: 1 COMMAND: "ndctl" __schedule schedule blk_mq_freeze_queue_wait blk_freeze_queue blk_cleanup_queue pmem_release_queue devm_action_release release_nodes devres_release_all device_release_driver_internal device_driver_detach unbind_store Cc: Signed-off-by: sumiyawang Reviewed-by: yongduan Link: https://lore.kernel.org/r/1629632949-14749-1-git-send-email-sumiyawang@tencent.com Fixes: 50f44ee7248a ("mm/devm_memremap_pages: fix final page put race") Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 6d86634d7bd12223f5e743adea2f595995cb9d9b Author: Vasily Averin Date: Thu Sep 2 14:54:57 2021 -0700 memcg: enable accounting for pids in nested pid namespaces commit fab827dbee8c2e06ca4ba000fa6c48bcf9054aba upstream. Commit 5d097056c9a0 ("kmemcg: account certain kmem allocations to memcg") enabled memcg accounting for pids allocated from init_pid_ns.pid_cachep, but forgot to adjust the setting for nested pid namespaces. As a result, pid memory is not accounted exactly where it is really needed, inside memcg-limited containers with their own pid namespaces. Pid was one the first kernel objects enabled for memcg accounting. init_pid_ns.pid_cachep marked by SLAB_ACCOUNT and we can expect that any new pids in the system are memcg-accounted. Though recently I've noticed that it is wrong. nested pid namespaces creates own slab caches for pid objects, nested pids have increased size because contain id both for all parent and for own pid namespaces. The problem is that these slab caches are _NOT_ marked by SLAB_ACCOUNT, as a result any pids allocated in nested pid namespaces are not memcg-accounted. Pid struct in nested pid namespace consumes up to 500 bytes memory, 100000 such objects gives us up to ~50Mb unaccounted memory, this allow container to exceed assigned memcg limits. Link: https://lkml.kernel.org/r/8b6de616-fd1a-02c6-cbdb-976ecdcfa604@virtuozzo.com Fixes: 5d097056c9a0 ("kmemcg: account certain kmem allocations to memcg") Cc: stable@vger.kernel.org Signed-off-by: Vasily Averin Reviewed-by: Michal Koutný Reviewed-by: Shakeel Butt Acked-by: Christian Brauner Acked-by: Roman Gushchin Cc: Michal Hocko Cc: Johannes Weiner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 388f12dabbe0ca7a55d70ae29eea3338cf2e0376 Author: Rik van Riel Date: Wed Sep 8 18:10:08 2021 -0700 mm,vmscan: fix divide by zero in get_scan_count commit 32d4f4b782bb8f0ceb78c6b5dc46eb577ae25bf7 upstream. Commit f56ce412a59d ("mm: memcontrol: fix occasional OOMs due to proportional memory.low reclaim") introduced a divide by zero corner case when oomd is being used in combination with cgroup memory.low protection. When oomd decides to kill a cgroup, it will force the cgroup memory to be reclaimed after killing the tasks, by writing to the memory.max file for that cgroup, forcing the remaining page cache and reclaimable slab to be reclaimed down to zero. Previously, on cgroups with some memory.low protection that would result in the memory being reclaimed down to the memory.low limit, or likely not at all, having the page cache reclaimed asynchronously later. With f56ce412a59d the oomd write to memory.max tries to reclaim all the way down to zero, which may race with another reclaimer, to the point of ending up with the divide by zero below. This patch implements the obvious fix. Link: https://lkml.kernel.org/r/20210826220149.058089c6@imladris.surriel.com Fixes: f56ce412a59d ("mm: memcontrol: fix occasional OOMs due to proportional memory.low reclaim") Signed-off-by: Rik van Riel Acked-by: Roman Gushchin Acked-by: Michal Hocko Acked-by: Johannes Weiner Acked-by: Chris Down Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2d2d8b0eca6473eac0a142edea4c2b038da08cbd Author: Liu Zixian Date: Wed Sep 8 18:10:05 2021 -0700 mm/hugetlb: initialize hugetlb_usage in mm_init commit 13db8c50477d83ad3e3b9b0ae247e5cd833a7ae4 upstream. After fork, the child process will get incorrect (2x) hugetlb_usage. If a process uses 5 2MB hugetlb pages in an anonymous mapping, HugetlbPages: 10240 kB and then forks, the child will show, HugetlbPages: 20480 kB The reason for double the amount is because hugetlb_usage will be copied from the parent and then increased when we copy page tables from parent to child. Child will have 2x actual usage. Fix this by adding hugetlb_count_init in mm_init. Link: https://lkml.kernel.org/r/20210826071742.877-1-liuzixian4@huawei.com Fixes: 5d317b2b6536 ("mm: hugetlb: proc: add HugetlbPages field to /proc/PID/status") Signed-off-by: Liu Zixian Reviewed-by: Naoya Horiguchi Reviewed-by: Mike Kravetz Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ce75a6b399e07ff8a7ccca668047663362befd46 Author: Li Zhijian Date: Wed Sep 8 18:10:02 2021 -0700 mm/hmm: bypass devmap pte when all pfn requested flags are fulfilled commit 4b42fb213678d2b6a9eeea92a9be200f23e49583 upstream. Previously, we noticed the one rpma example was failed[1] since commit 36f30e486dce ("IB/core: Improve ODP to use hmm_range_fault()"), where it will use ODP feature to do RDMA WRITE between fsdax files. After digging into the code, we found hmm_vma_handle_pte() will still return EFAULT even though all the its requesting flags has been fulfilled. That's because a DAX page will be marked as (_PAGE_SPECIAL | PAGE_DEVMAP) by pte_mkdevmap(). Link: https://github.com/pmem/rpma/issues/1142 [1] Link: https://lkml.kernel.org/r/20210830094232.203029-1-lizhijian@cn.fujitsu.com Fixes: 405506274922 ("mm/hmm: add missing call to hmm_pte_need_fault in HMM_PFN_SPECIAL handling") Signed-off-by: Li Zhijian Reviewed-by: Christoph Hellwig Reviewed-by: Jason Gunthorpe Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e1fa3b2b60abb9f43b937741e27c6531ef4cbef9 Author: Mike Kravetz Date: Thu Sep 2 14:58:53 2021 -0700 hugetlb: fix hugetlb cgroup refcounting during vma split commit 09a26e832705fdb7a9484495b71a05e0bbc65207 upstream. Guillaume Morin reported hitting the following WARNING followed by GPF or NULL pointer deference either in cgroups_destroy or in the kill_css path.: percpu ref (css_release) <= 0 (-1) after switching to atomic WARNING: CPU: 23 PID: 130 at lib/percpu-refcount.c:196 percpu_ref_switch_to_atomic_rcu+0x127/0x130 CPU: 23 PID: 130 Comm: ksoftirqd/23 Kdump: loaded Tainted: G O 5.10.60 #1 RIP: 0010:percpu_ref_switch_to_atomic_rcu+0x127/0x130 Call Trace: rcu_core+0x30f/0x530 rcu_core_si+0xe/0x10 __do_softirq+0x103/0x2a2 run_ksoftirqd+0x2b/0x40 smpboot_thread_fn+0x11a/0x170 kthread+0x10a/0x140 ret_from_fork+0x22/0x30 Upon further examination, it was discovered that the css structure was associated with hugetlb reservations. For private hugetlb mappings the vma points to a reserve map that contains a pointer to the css. At mmap time, reservations are set up and a reference to the css is taken. This reference is dropped in the vma close operation; hugetlb_vm_op_close. However, if a vma is split no additional reference to the css is taken yet hugetlb_vm_op_close will be called twice for the split vma resulting in an underflow. Fix by taking another reference in hugetlb_vm_op_open. Note that the reference is only taken for the owner of the reserve map. In the more common fork case, the pointer to the reserve map is cleared for non-owning vmas. Link: https://lkml.kernel.org/r/20210830215015.155224-1-mike.kravetz@oracle.com Fixes: e9fe92ae0cd2 ("hugetlb_cgroup: add reservation accounting for private mappings") Signed-off-by: Mike Kravetz Reported-by: Guillaume Morin Suggested-by: Guillaume Morin Tested-by: Guillaume Morin Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 27dd91221b3f714f315c6e6b8f59924fbdd4c331 Author: Halil Pasic Date: Sat Jul 24 01:17:46 2021 +0200 s390/pv: fix the forcing of the swiotlb commit 93ebb6828723b8aef114415c4dc3518342f7dcad upstream. Since commit 903cd0f315fe ("swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing") if code sets swiotlb_force it needs to do so before the swiotlb is initialised. Otherwise io_tlb_default_mem->force_bounce will not get set to true, and devices that use (the default) swiotlb will not bounce despite switolb_force having the value of SWIOTLB_FORCE. Let us restore swiotlb functionality for PV by fulfilling this new requirement. This change addresses what turned out to be a fragility in commit 64e1f0c531d1 ("s390/mm: force swiotlb for protected virtualization"), which ain't exactly broken in its original context, but could give us some more headache if people backport the broken change and forget this fix. Signed-off-by: Halil Pasic Tested-by: Christian Borntraeger Reviewed-by: Christian Borntraeger Fixes: 903cd0f315fe ("swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing") Fixes: 64e1f0c531d1 ("s390/mm: force swiotlb for protected virtualization") Cc: stable@vger.kernel.org #5.3+ Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 086faa4a2e86e4480f76fcf687b380061a0083f8 Author: Pratik R. Sampat Date: Wed Jul 28 17:35:00 2021 +0530 cpufreq: powernv: Fix init_chip_info initialization in numa=off commit f34ee9cb2c5ac5af426fee6fa4591a34d187e696 upstream. In the numa=off kernel command-line configuration init_chip_info() loops around the number of chips and attempts to copy the cpumask of that node which is NULL for all iterations after the first chip. Hence, store the cpu mask for each chip instead of derving cpumask from node while populating the "chips" struct array and copy that to the chips[i].mask Fixes: 053819e0bf84 ("cpufreq: powernv: Handle throttling due to Pmax capping at chip level") Cc: stable@vger.kernel.org # v4.3+ Reported-by: Shirisha Ganta Signed-off-by: Pratik R. Sampat Reviewed-by: Gautham R. Shenoy [mpe: Rename goto label to out_free_chip_cpu_mask] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210728120500.87549-2-psampat@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 55be9eb1936af0ec23af2dab68de059e9c0575b2 Author: Saurav Kashyap Date: Mon Aug 9 21:37:19 2021 -0700 scsi: qla2xxx: Sync queue idx with queue_pair_map idx commit c8fadf019964d0eb1da410ba8b629494d3339db9 upstream. The first invocation of function find_first_zero_bit will return 0 and queue_id gets set to 0. An index of queue_pair_map also gets set to 0. qpair_id = find_first_zero_bit(ha->qpair_qid_map, ha->max_qpairs); set_bit(qpair_id, ha->qpair_qid_map); ha->queue_pair_map[qpair_id] = qpair; In the alloc_queue callback driver checks the map, if queue is already allocated: ha->queue_pair_map[qidx] This works fine as long as max_qpairs is greater than nvme_max_hw_queues(8) since the size of the queue_pair_map is equal to max_qpair. In case nr_cpus is less than 8, max_qpairs is less than 8. This creates wrong value returned as qpair. [ 1572.353669] qla2xxx [0000:24:00.3]-2121:6: Returning existing qpair of 4e00000000000000 for idx=2 [ 1572.354458] general protection fault: 0000 [#1] SMP PTI [ 1572.354461] CPU: 1 PID: 44 Comm: kworker/1:1H Kdump: loaded Tainted: G IOE --------- - - 4.18.0-304.el8.x86_64 #1 [ 1572.354462] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 03/01/2013 [ 1572.354467] Workqueue: kblockd blk_mq_run_work_fn [ 1572.354485] RIP: 0010:qla_nvme_post_cmd+0x92/0x760 [qla2xxx] [ 1572.354486] Code: 84 24 5c 01 00 00 00 00 b8 0a 74 1e 66 83 79 48 00 0f 85 a8 03 00 00 48 8b 44 24 08 48 89 ee 4c 89 e7 8b 50 24 e8 5e 8e 00 00 41 ff 47 04 0f ae f0 41 f6 47 24 04 74 19 f0 41 ff 4f 04 b8 f0 [ 1572.354487] RSP: 0018:ffff9c81c645fc90 EFLAGS: 00010246 [ 1572.354489] RAX: 0000000000000001 RBX: ffff8ea3e5070138 RCX: 0000000000000001 [ 1572.354490] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff8ea4c866b800 [ 1572.354491] RBP: ffff8ea4c866b800 R08: 0000000000005010 R09: ffff8ea4c866b800 [ 1572.354492] R10: 0000000000000001 R11: 000000069d1ca3ff R12: ffff8ea4bc460000 [ 1572.354493] R13: ffff8ea3e50702b0 R14: ffff8ea4c4c16a58 R15: 4e00000000000000 [ 1572.354494] FS: 0000000000000000(0000) GS:ffff8ea4dfd00000(0000) knlGS:0000000000000000 [ 1572.354495] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1572.354496] CR2: 000055884504fa58 CR3: 00000005a1410001 CR4: 00000000000606e0 [ 1572.354497] Call Trace: [ 1572.354503] ? check_preempt_curr+0x62/0x90 [ 1572.354506] ? dma_direct_map_sg+0x72/0x1f0 [ 1572.354509] ? nvme_fc_start_fcp_op.part.32+0x175/0x460 [nvme_fc] [ 1572.354511] ? blk_mq_dispatch_rq_list+0x11c/0x730 [ 1572.354515] ? __switch_to_asm+0x35/0x70 [ 1572.354516] ? __switch_to_asm+0x41/0x70 [ 1572.354518] ? __switch_to_asm+0x35/0x70 [ 1572.354519] ? __switch_to_asm+0x41/0x70 [ 1572.354521] ? __switch_to_asm+0x35/0x70 [ 1572.354522] ? __switch_to_asm+0x41/0x70 [ 1572.354523] ? __switch_to_asm+0x35/0x70 [ 1572.354525] ? entry_SYSCALL_64_after_hwframe+0xb9/0xca [ 1572.354527] ? __switch_to_asm+0x41/0x70 [ 1572.354529] ? __blk_mq_sched_dispatch_requests+0xc6/0x170 [ 1572.354531] ? blk_mq_sched_dispatch_requests+0x30/0x60 [ 1572.354532] ? __blk_mq_run_hw_queue+0x51/0xd0 [ 1572.354535] ? process_one_work+0x1a7/0x360 [ 1572.354537] ? create_worker+0x1a0/0x1a0 [ 1572.354538] ? worker_thread+0x30/0x390 [ 1572.354540] ? create_worker+0x1a0/0x1a0 [ 1572.354541] ? kthread+0x116/0x130 [ 1572.354543] ? kthread_flush_work_fn+0x10/0x10 [ 1572.354545] ? ret_from_fork+0x35/0x40 Fix is to use index 0 for admin and first IO queue. Link: https://lore.kernel.org/r/20210810043720.1137-14-njavali@marvell.com Fixes: e84067d74301 ("scsi: qla2xxx: Add FC-NVMe F/W initialization and transport registration") Cc: stable@vger.kernel.org Reviewed-by: Himanshu Madhani Signed-off-by: Saurav Kashyap Signed-off-by: Nilesh Javali Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 9c8414325eee8f821e6e265bf94b93fe2f225922 Author: Saurav Kashyap Date: Mon Aug 9 21:37:17 2021 -0700 scsi: qla2xxx: Changes to support kdump kernel commit 62e0dec59c1e139dab55aff5aa442adc97804271 upstream. Avoid allocating firmware dump and only allocate a single queue for a kexec kernel. Link: https://lore.kernel.org/r/20210810043720.1137-12-njavali@marvell.com Cc: stable@vger.kernel.org Reviewed-by: Himanshu Madhani Signed-off-by: Saurav Kashyap Signed-off-by: Nilesh Javali Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 137dafa722303d5eed1340ded248bcbaea514d58 Author: Maciej W. Rozycki Date: Tue Apr 20 20:01:47 2021 +0200 scsi: BusLogic: Fix missing pr_cont() use commit 44d01fc86d952f5a8b8b32bdb4841504d5833d95 upstream. Update BusLogic driver's messaging system to use pr_cont() for continuation lines, bringing messy output: pci 0000:00:13.0: PCI->APIC IRQ transform: INT A -> IRQ 17 scsi: ***** BusLogic SCSI Driver Version 2.1.17 of 12 September 2013 ***** scsi: Copyright 1995-1998 by Leonard N. Zubkoff scsi0: Configuring BusLogic Model BT-958 PCI Wide Ultra SCSI Host Adapter scsi0: Firmware Version: 5.07B, I/O Address: 0x7000, IRQ Channel: 17/Level scsi0: PCI Bus: 0, Device: 19, Address: 0xE0012000, Host Adapter SCSI ID: 7 scsi0: Parity Checking: Enabled, Extended Translation: Enabled scsi0: Synchronous Negotiation: Ultra, Wide Negotiation: Enabled scsi0: Disconnect/Reconnect: Enabled, Tagged Queuing: Enabled scsi0: Scatter/Gather Limit: 128 of 8192 segments, Mailboxes: 211 scsi0: Driver Queue Depth: 211, Host Adapter Queue Depth: 192 scsi0: Tagged Queue Depth: Automatic , Untagged Queue Depth: 3 scsi0: SCSI Bus Termination: Both Enabled , SCAM: Disabled scsi0: *** BusLogic BT-958 Initialized Successfully *** scsi host0: BusLogic BT-958 back to order: pci 0000:00:13.0: PCI->APIC IRQ transform: INT A -> IRQ 17 scsi: ***** BusLogic SCSI Driver Version 2.1.17 of 12 September 2013 ***** scsi: Copyright 1995-1998 by Leonard N. Zubkoff scsi0: Configuring BusLogic Model BT-958 PCI Wide Ultra SCSI Host Adapter scsi0: Firmware Version: 5.07B, I/O Address: 0x7000, IRQ Channel: 17/Level scsi0: PCI Bus: 0, Device: 19, Address: 0xE0012000, Host Adapter SCSI ID: 7 scsi0: Parity Checking: Enabled, Extended Translation: Enabled scsi0: Synchronous Negotiation: Ultra, Wide Negotiation: Enabled scsi0: Disconnect/Reconnect: Enabled, Tagged Queuing: Enabled scsi0: Scatter/Gather Limit: 128 of 8192 segments, Mailboxes: 211 scsi0: Driver Queue Depth: 211, Host Adapter Queue Depth: 192 scsi0: Tagged Queue Depth: Automatic, Untagged Queue Depth: 3 scsi0: SCSI Bus Termination: Both Enabled, SCAM: Disabled scsi0: *** BusLogic BT-958 Initialized Successfully *** scsi host0: BusLogic BT-958 Also diagnostic output such as with the BusLogic=TraceConfiguration parameter is affected and becomes vertical and therefore hard to read. This has now been corrected, e.g.: pci 0000:00:13.0: PCI->APIC IRQ transform: INT A -> IRQ 17 blogic_cmd(86) Status = 30: 4 ==> 4: FF 05 93 00 blogic_cmd(95) Status = 28: (Modify I/O Address) blogic_cmd(91) Status = 30: 1 ==> 1: 01 blogic_cmd(04) Status = 30: 4 ==> 4: 41 41 35 30 blogic_cmd(8D) Status = 30: 14 ==> 14: 45 DC 00 20 00 00 00 00 00 40 30 37 42 1D scsi: ***** BusLogic SCSI Driver Version 2.1.17 of 12 September 2013 ***** scsi: Copyright 1995-1998 by Leonard N. Zubkoff blogic_cmd(04) Status = 30: 4 ==> 4: 41 41 35 30 blogic_cmd(0B) Status = 30: 3 ==> 3: 00 08 07 blogic_cmd(0D) Status = 30: 34 ==> 34: 03 01 07 04 00 00 00 00 00 00 00 00 00 00 00 00 FF 42 44 46 FF 00 00 00 00 00 00 00 00 00 FF 00 FF 00 blogic_cmd(8D) Status = 30: 14 ==> 14: 45 DC 00 20 00 00 00 00 00 40 30 37 42 1D blogic_cmd(84) Status = 30: 1 ==> 1: 37 blogic_cmd(8B) Status = 30: 5 ==> 5: 39 35 38 20 20 blogic_cmd(85) Status = 30: 1 ==> 1: 42 blogic_cmd(86) Status = 30: 4 ==> 4: FF 05 93 00 blogic_cmd(91) Status = 30: 64 ==> 64: 41 46 3E 20 39 35 38 20 20 00 C4 00 04 01 07 2F 07 04 35 FF FF FF FF FF FF FF FF FF FF 01 00 FE FF 08 FF FF 00 00 00 00 00 00 00 01 00 01 00 00 FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 FC scsi0: Configuring BusLogic Model BT-958 PCI Wide Ultra SCSI Host Adapter etc. Link: https://lore.kernel.org/r/alpine.DEB.2.21.2104201940430.44318@angie.orcam.me.uk Fixes: 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing continuation lines") Cc: stable@vger.kernel.org # v4.9+ Acked-by: Khalid Aziz Signed-off-by: Maciej W. Rozycki Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 69775e4e17f2380f67c972899b02828d7a71d627 Author: chenying Date: Mon Aug 16 18:02:56 2021 +0800 ovl: fix BUG_ON() in may_delete() when called from ovl_cleanup() commit 52d5a0c6bd8a89f460243ed937856354f8f253a3 upstream. If function ovl_instantiate() returns an error, ovl_cleanup will be called and try to remove newdentry from wdir, but the newdentry has been moved to udir at this time. This will causes BUG_ON(victim->d_parent->d_inode != dir) in fs/namei.c:may_delete. Signed-off-by: chenying Fixes: 01b39dcc9568 ("ovl: use inode_insert5() to hash a newly created inode") Link: https://lore.kernel.org/linux-unionfs/e6496a94-a161-dc04-c38a-d2544633acb4@bytedance.com/ Cc: # v4.18 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 7a5756e90563e5a31739d313fb6b379449ded9d9 Author: Mikulas Patocka Date: Mon Aug 30 05:42:27 2021 -0400 parisc: fix crash with signals and alloca commit 030f653078316a9cc9ca6bd1b0234dcf858be35d upstream. I was debugging some crashes on parisc and I found out that there is a crash possibility if a function using alloca is interrupted by a signal. The reason for the crash is that the gcc alloca implementation leaves garbage in the upper 32 bits of the sp register. This normally doesn't matter (the upper bits are ignored because the PSW W-bit is clear), however the signal delivery routine in the kernel uses full 64 bits of sp and it fails with -EFAULT if the upper 32 bits are not zero. I created this program that demonstrates the problem: #include #include #include #include static __attribute__((noinline,noclone)) void aa(int *size) { void * volatile p = alloca(-*size); while (1) ; } static void handler(int sig) { write(1, "signal delivered\n", 17); _exit(0); } int main(void) { int size = -0x100; signal(SIGALRM, handler); alarm(1); aa(&size); } If you compile it with optimizations, it will crash. The "aa" function has this disassembly: 000106a0 : 106a0: 08 03 02 41 copy r3,r1 106a4: 08 1e 02 43 copy sp,r3 106a8: 6f c1 00 80 stw,ma r1,40(sp) 106ac: 37 dc 3f c1 ldo -20(sp),ret0 106b0: 0c 7c 12 90 stw ret0,8(r3) 106b4: 0f 40 10 9c ldw 0(r26),ret0 ; ret0 = 0x00000000FFFFFF00 106b8: 97 9c 00 7e subi 3f,ret0,ret0 ; ret0 = 0xFFFFFFFF0000013F 106bc: d7 80 1c 1a depwi 0,31,6,ret0 ; ret0 = 0xFFFFFFFF00000100 106c0: 0b 9e 0a 1e add,l sp,ret0,sp ; sp = 0xFFFFFFFFxxxxxxxx 106c4: e8 1f 1f f7 b,l,n 106c4 ,r0 This patch fixes the bug by truncating the "usp" variable to 32 bits. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 9a4e7f9038660b7fd41280f9d97e6c722804bd1d Author: Pavel Begunkov Date: Sat Nov 7 13:16:26 2020 +0000 io_uring: remove duplicated io_size from rw [ Upstream commit 632546c4b5a4dad8e3ac456406c65c0db9a0b570 ] io_size and iov_count in io_read() and io_write() hold the same value, kill the last one. Signed-off-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 6930a2a5be5cbb0c202fcfa2773c95bd10a19197 Author: David Laight Date: Sat Nov 7 13:16:25 2020 +0000 fs/io_uring Don't use the return value from import_iovec(). [ Upstream commit 10fc72e43352753a08f9cf83aa5c40baec00d212 ] This is the only code that relies on import_iovec() returning iter.count on success. This allows a better interface to import_iovec(). Signed-off-by: David Laight Signed-off-by: Pavel Begunkov Reviewed-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 2c304c65defd4aaf2e4e0c8226c6e03cc09a7355 Author: Guojia Liao Date: Mon Aug 30 21:51:07 2021 +0800 net: hns3: clean up a type mismatch warning [ Upstream commit e79c0e324b011b0288cd411a5b53870a7730f163 ] abs() returns signed long, which could not convert the type as unsigned, and it may cause a mismatch type warning from static tools. To fix it, this patch uses an variable to save the abs()'s result and does a explicit conversion. Signed-off-by: Guojia Liao Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit fb1ee027878b30f7545c77b1cdf1f61136d21092 Author: Yang Yingliang Date: Tue Aug 31 16:40:18 2021 +0800 net: w5100: check return value after calling platform_get_resource() [ Upstream commit a39ff4a47f3e1da3b036817ef436b1a9be10783a ] It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. Signed-off-by: Yang Yingliang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c49a52046da7580c1eaa251396b18aa3da091d13 Author: Haimin Zhang Date: Mon Aug 30 11:47:01 2021 +0800 fix array-index-out-of-bounds in taprio_change [ Upstream commit efe487fce3061d94222c6501d7be3aa549b3dc78 ] syzbot report an array-index-out-of-bounds in taprio_change index 16 is out of range for type '__u16 [16]' that's because mqprio->num_tc is lager than TC_MAX_QUEUE,so we check the return value of netdev_set_num_tc. Reported-by: syzbot+2b3e5fb6c7ef285a94f6@syzkaller.appspotmail.com Signed-off-by: Haimin Zhang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a4301d06a0b88166565a21ce34cdb50d51976e49 Author: 王贇 Date: Mon Aug 30 18:28:01 2021 +0800 net: fix NULL pointer reference in cipso_v4_doi_free [ Upstream commit 733c99ee8be9a1410287cdbb943887365e83b2d6 ] In netlbl_cipsov4_add_std() when 'doi_def->map.std' alloc failed, we sometime observe panic: BUG: kernel NULL pointer dereference, address: ... RIP: 0010:cipso_v4_doi_free+0x3a/0x80 ... Call Trace: netlbl_cipsov4_add_std+0xf4/0x8c0 netlbl_cipsov4_add+0x13f/0x1b0 genl_family_rcv_msg_doit.isra.15+0x132/0x170 genl_rcv_msg+0x125/0x240 This is because in cipso_v4_doi_free() there is no check on 'doi_def->map.std' when 'doi_def->type' equal 1, which is possibe, since netlbl_cipsov4_add_std() haven't initialize it before alloc 'doi_def->map.std'. This patch just add the check to prevent panic happen for similar cases. Reported-by: Abaci Signed-off-by: Michael Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5ed5d594d9a7adc9b81c29d3714a642d2422c1fc Author: Miaoqing Pan Date: Mon Aug 9 12:05:16 2021 +0800 ath9k: fix sleeping in atomic context [ Upstream commit 7c48662b9d56666219f526a71ace8c15e6e12f1f ] The problem is that gpio_free() can sleep and the cfg_soc() can be called with spinlocks held. One problematic call tree is: --> ath_reset_internal() takes &sc->sc_pcu_lock spin lock --> ath9k_hw_reset() --> ath9k_hw_gpio_request_in() --> ath9k_hw_gpio_request() --> ath9k_hw_gpio_cfg_soc() Remove gpio_free(), use error message instead, so we should make sure there is no GPIO conflict. Also remove ath9k_hw_gpio_free() from ath9k_hw_apply_gpio_override(), as gpio_mask will never be set for SOC chips. Signed-off-by: Miaoqing Pan Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1628481916-15030-1-git-send-email-miaoqing@codeaurora.org Signed-off-by: Sasha Levin commit aa3708236ea011adee77af428f21ba30becd0ba3 Author: Zekun Shen Date: Sat Jun 19 09:29:14 2021 -0400 ath9k: fix OOB read ar9300_eeprom_restore_internal [ Upstream commit 23151b9ae79e3bc4f6a0c4cd3a7f355f68dad128 ] Bad header can have large length field which can cause OOB. cptr is the last bytes for read, and the eeprom is parsed from high to low address. The OOB, triggered by the condition length > cptr could cause memory error with a read on negative index. There are some sanity check around length, but it is not compared with cptr (the remaining bytes). Here, the corrupted/bad EEPROM can cause panic. I was able to reproduce the crash, but I cannot find the log and the reproducer now. After I applied the patch, the bug is no longer reproducible. Signed-off-by: Zekun Shen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/YM3xKsQJ0Hw2hjrc@Zekuns-MBP-16.fios-router.home Signed-off-by: Sasha Levin commit be457b27dd0a0428bcf9dd10156049c20031fb34 Author: Loic Poulain Date: Thu Aug 26 17:46:08 2021 +0200 wcn36xx: Fix missing frame timestamp for beacon/probe-resp [ Upstream commit 8678fd31f2d3eb14f2b8b39c9bc266f16fa24b22 ] When receiving a beacon or probe response, we should update the boottime_ns field which is the timestamp the frame was received at. (cf mac80211.h) This fixes a scanning issue with Android since it relies on this timestamp to determine when the AP has been seen for the last time (via the nl80211 BSS_LAST_SEEN_BOOTTIME parameter). Signed-off-by: Loic Poulain Reviewed-by: Bryan O'Donoghue Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1629992768-23785-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Sasha Levin commit b1d547f2f51ace1caa2573e357d571cf1321ccb9 Author: Chengfeng Ye Date: Fri Aug 27 00:41:40 2021 -0700 selftests/bpf: Fix potential unreleased lock [ Upstream commit 47bb27a20d6ea22cd092c1fc2bb4fcecac374838 ] This lock is not released if the program return at the patched branch. Signed-off-by: Chengfeng Ye Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20210827074140.118671-1-cyeaa@connect.ust.hk Signed-off-by: Sasha Levin commit 3ad66d67822d0f72bc2c4ff5a0879db1b2dd90bb Author: Colin Ian King Date: Fri Jul 30 11:07:10 2021 +0100 parport: remove non-zero check on count [ Upstream commit 0be883a0d795d9146f5325de582584147dd0dcdc ] The check for count appears to be incorrect since a non-zero count check occurs a couple of statements earlier. Currently the check is always false and the dev->port->irq != PARPORT_IRQ_NONE part of the check is never tested and the if statement is dead-code. Fix this by removing the check on count. Note that this code is pre-git history, so I can't find a sha for it. Acked-by: Sudip Mukherjee Signed-off-by: Colin Ian King Addresses-Coverity: ("Logically dead code") Link: https://lore.kernel.org/r/20210730100710.27405-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1e9302537804a6a3ccf681718b753e39e165a891 Author: Yevgeny Kliteynik Date: Thu Sep 24 20:58:50 2020 +0300 net/mlx5: DR, Enable QP retransmission [ Upstream commit ec449ed8230cd30769de3cb70ee0fce293047372 ] Under high stress, SW steering might get stuck on polling for completion that never comes. For such cases QP needs to have protocol retransmission mechanism enabled. Currently the retransmission timeout is defined as 0 (unlimited). Fix this by defining a real timeout. Signed-off-by: Yevgeny Kliteynik Reviewed-by: Alex Vesker Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 9c5c65ecbd87c3d7ab5bb44187038c4865cb7dd0 Author: Wentao_Liang Date: Thu Aug 19 22:30:05 2021 +0800 net/mlx5: DR, fix a potential use-after-free bug [ Upstream commit 6cc64770fb386b10a64a1fe09328396de7bb5262 ] In line 849 (#1), "mlx5dr_htbl_put(cur_htbl);" drops the reference to cur_htbl and may cause cur_htbl to be freed. However, cur_htbl is subsequently used in the next line, which may result in an use-after-free bug. Fix this by calling mlx5dr_err() before the cur_htbl is put. Signed-off-by: Wentao_Liang Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 4bbf0a9d90e8e56b5dfa46f3e5feb96091f16300 Author: Ilan Peer Date: Thu Aug 26 22:47:42 2021 +0300 iwlwifi: mvm: Fix scan channel flags settings [ Upstream commit 090f1be3abf3069ef856b29761f181808bf55917 ] The iwl_mvm_scan_ch_n_aps_flag() is called with a variable before the value of the variable is set. Fix it. Signed-off-by: Ilan Peer Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210826224715.f6f188980a5e.Ie7331a8b94004d308f6cbde44e519155a5be91dd@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit a693aff5e8d7fa70bfaf222cbe0443c742af27c9 Author: Johannes Berg Date: Thu Aug 5 14:21:54 2021 +0300 iwlwifi: fw: correctly limit to monitor dump [ Upstream commit e6344c060209ef4e970cac18adeac1676a2a73cd ] In commit 79f033f6f229 ("iwlwifi: dbg: don't limit dump decisions to all or monitor") we changed the code to pass around a bitmap, but in the monitor_only case, one place accidentally used the bit number, not the bit mask, resulting in CSR and FW_INFO getting dumped instead of monitor data. Fix that. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210805141826.774fd8729a33.Ic985a787071d1c0b127ef0ba8367da896ee11f57@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 4ed6510e0559510ac967b42eb019c0753e435c43 Author: Johannes Berg Date: Thu Aug 5 13:19:31 2021 +0300 iwlwifi: mvm: fix access to BSS elements [ Upstream commit 6c608cd6962ebdf84fd3de6d42f88ed64d2f4e1b ] BSS elements are protected using RCU, so we need to use RCU properly to access them, fix that. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210805130823.fd8b5791ab44.Iba26800a6301078d3782fb249c476dd8ac2bf3c6@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 9e80a3d88f4dfccd3371a91cdd778f79f738a029 Author: Johannes Berg Date: Mon Aug 2 17:28:27 2021 +0300 iwlwifi: mvm: avoid static queue number aliasing [ Upstream commit c6ce1c74ef2923b8ffd85f7f8b486f804f343b39 ] When TVQM is enabled (iwl_mvm_has_new_tx_api() is true), then queue numbers are just sequentially assigned 0, 1, 2, ... Prior to TVQM, in DQA, there were some statically allocated queue numbers: * IWL_MVM_DQA_AUX_QUEUE == 1, * both IWL_MVM_DQA_INJECT_MONITOR_QUEUE and IWL_MVM_DQA_P2P_DEVICE_QUEUE == 2, and * IWL_MVM_DQA_AP_PROBE_RESP_QUEUE == 9. Now, these values are assigned to the members mvm->aux_queue, mvm->snif_queue, mvm->probe_queue and mvm->p2p_dev_queue by default. Normally, this doesn't really matter, and if TVQM is in fact available we override them to the real values after allocating a queue for use there. However, this allocation doesn't always happen. For example, for mvm->p2p_dev_queue (== 2) it only happens when the P2P Device interface is started, if any. If it's not started, the value in mvm->p2p_dev_queue remains 2. This wouldn't really matter all that much if it weren't for iwl_mvm_is_static_queue() which checks a queue number against one of those four static numbers. Now, if no P2P Device or monitor interface is added then queue 2 may be dynamically allocated, yet alias mvm->p2p_dev_queue or mvm->snif_queue, and thus iwl_mvm_is_static_queue() erroneously returns true for it. If it then gets full, all interface queues are stopped, instead of just backpressuring against the one TXQ that's really the only affected one. This clearly can lead to issues, as everything is stopped even if just a single TXQ filled its corresponding HW queue, if it happens to have an appropriate number (2 or 9, AUX is always reassigned.) Due to a mac80211 bug, this also led to a situation in which the queues remained stopped across a deauthentication and then attempts to connect to a new AP started failing, but that's fixed separately. Fix all of this by simply initializing the queue numbers to the invalid value until they're used, if TVQM is enabled, and also setting them back to that value when the queues are later freed again. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210802172232.2e47e623f9e2.I9b0830dafbb68ef35b7b8f0f46160abec02ac7d0@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 3ed8982df50ed30165e1f2148958def2bb6dc2e1 Author: Zhang Qilong Date: Mon Aug 2 17:28:24 2021 +0300 iwlwifi: mvm: fix a memory leak in iwl_mvm_mac_ctxt_beacon_changed [ Upstream commit 0f5d44ac6e55551798dd3da0ff847c8df5990822 ] If beacon_inject_active is true, we will return without freeing beacon. Fid that by freeing it before returning. Signed-off-by: Zhang Qilong [reworded the commit message] Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210802172232.d16206ca60fc.I9984a9b442c84814c307cee3213044e24d26f38a@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 608c8359c567b4a04dedbe121d711b51797e390e Author: Johannes Berg Date: Mon Aug 2 17:09:38 2021 +0300 iwlwifi: pcie: free RBs during configure [ Upstream commit 6ac5720086c8b176794eb74c5cc09f8b79017f38 ] When switching op-modes, or more generally when reconfiguring, we might switch the RB size. In _iwl_pcie_rx_init() we have a comment saying we must free all RBs since we might switch the size, but this is actually too late: the switch has been done and we'll free the buffers with the wrong size. Fix this by always freeing the buffers, if any, at the start of configure, instead of only after the size may have changed. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210802170640.42d7c93279c4.I07f74e65aab0e3d965a81206fcb289dc92d74878@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit eb04c51a439e38dbbab363cf5f0599cbe0507b13 Author: J. Bruce Fields Date: Tue Aug 24 22:36:03 2021 -0400 nfsd: fix crash on LOCKT on reexported NFSv3 [ Upstream commit 0bcc7ca40bd823193224e9f38bafbd8325aaf566 ] Unlike other filesystems, NFSv3 tries to use fl_file in the GETLK case. Signed-off-by: J. Bruce Fields Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 0e9f4492219f8f991163691aad43897da8478c4e Author: Sean Keely Date: Thu Aug 19 21:26:14 2021 -0500 drm/amdkfd: Account for SH/SE count when setting up cu masks. [ Upstream commit 1ec06c2dee679e9f089e78ed20cb74ee90155f61 ] On systems with multiple SH per SE compute_static_thread_mgmt_se# is split into independent masks, one for each SH, in the upper and lower 16 bits. We need to detect this and apply cu masking to each SH. The cu mask bits are assigned first to each SE, then to alternate SHs, then finally to higher CU id. This ensures that the maximum number of SPIs are engaged as early as possible while balancing CU assignment to each SH. v2: Use max SH/SE rather than max SH in cu_per_sh. v3: Fix comment blocks, ensure se_mask is initially zero filled, and correctly assign se.sh.cu positions to unset bits in cu_mask. Signed-off-by: Sean Keely Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 27d4a96addefb9bffb78b3556ebb2c5ece64912f Author: Xiaotan Luo Date: Thu Aug 26 12:02:36 2021 +0800 ASoC: rockchip: i2s: Fixup config for DAIFMT_DSP_A/B [ Upstream commit 1bf56843e664eef2525bdbfae6a561e98910f676 ] - DSP_A: PCM delay 1 bit mode, L data MSB after FRM LRC - DSP_B: PCM no delay mode, L data MSB during FRM LRC Signed-off-by: Xiaotan Luo Signed-off-by: Sugar Zhang Link: https://lore.kernel.org/r/1629950562-14281-3-git-send-email-sugar.zhang@rock-chips.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 969eddc3b4dcd0610fb370a5084fd06cec5ad5ab Author: Sugar Zhang Date: Thu Aug 26 12:01:50 2021 +0800 ASoC: rockchip: i2s: Fix regmap_ops hang [ Upstream commit 53ca9b9777b95cdd689181d7c547e38dc79adad0 ] API 'set_fmt' maybe called when PD is off, in the situation, any register access will hang the system. so, enable PD before r/w register. Signed-off-by: Sugar Zhang Link: https://lore.kernel.org/r/1629950520-14190-4-git-send-email-sugar.zhang@rock-chips.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7344a8a80190f7215752f6a90d1903b1f31cc9b9 Author: Shuah Khan Date: Thu Aug 19 16:59:37 2021 -0600 usbip:vhci_hcd USB port can get stuck in the disabled state [ Upstream commit 66cce9e73ec61967ed1f97f30cee79bd9a2bb7ee ] When a remote usb device is attached to the local Virtual USB Host Controller Root Hub port, the bound device driver may send a port reset command. vhci_hcd accepts port resets only when the device doesn't have port address assigned to it. When reset happens device is in assigned/used state and vhci_hcd rejects it leaving the port in a stuck state. This problem was found when a blue-tooth or xbox wireless dongle was passed through using usbip. A few drivers reset the port during probe including mt76 driver specific to this bug report. Fix the problem with a change to honor reset requests when device is in used state (VDEV_ST_USED). Reported-and-tested-by: Michael Suggested-by: Michael Signed-off-by: Shuah Khan Link: https://lore.kernel.org/r/20210819225937.41037-1-skhan@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 29c8f13a345d9399648fc5cffad244db0c8e3fa6 Author: Anirudh Rayabharam Date: Sat Aug 21 00:31:21 2021 +0530 usbip: give back URBs for unsent unlink requests during cleanup [ Upstream commit 258c81b341c8025d79073ce2d6ce19dcdc7d10d2 ] In vhci_device_unlink_cleanup(), the URBs for unsent unlink requests are not given back. This sometimes causes usb_kill_urb to wait indefinitely for that urb to be given back. syzbot has reported a hung task issue [1] for this. To fix this, give back the urbs corresponding to unsent unlink requests (unlink_tx list) similar to how urbs corresponding to unanswered unlink requests (unlink_rx list) are given back. [1]: https://syzkaller.appspot.com/bug?id=08f12df95ae7da69814e64eb5515d5a85ed06b76 Reported-by: syzbot+74d6ef051d3d2eacf428@syzkaller.appspotmail.com Tested-by: syzbot+74d6ef051d3d2eacf428@syzkaller.appspotmail.com Reviewed-by: Shuah Khan Signed-off-by: Anirudh Rayabharam Link: https://lore.kernel.org/r/20210820190122.16379-2-mail@anirudhrb.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8de01a896c1bc14b6b65b8d26013626597a45eda Author: Nadezda Lutovinova Date: Thu Aug 19 19:33:23 2021 +0300 usb: musb: musb_dsps: request_irq() after initializing musb [ Upstream commit 7c75bde329d7e2a93cf86a5c15c61f96f1446cdc ] If IRQ occurs between calling dsps_setup_optional_vbus_irq() and dsps_create_musb_pdev(), then null pointer dereference occurs since glue->musb wasn't initialized yet. The patch puts initializing of neccesery data before registration of the interrupt handler. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Nadezda Lutovinova Link: https://lore.kernel.org/r/20210819163323.17714-1-lutovinova@ispras.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c0751eeb938c079d9c7c8e50e16fe6f5ae52fe1b Author: Mathias Nyman Date: Fri Aug 20 15:35:01 2021 +0300 Revert "USB: xhci: fix U1/U2 handling for hardware with XHCI_INTEL_HOST quirk set" [ Upstream commit 2847c46c61486fd8bca9136a6e27177212e78c69 ] This reverts commit 5d5323a6f3625f101dbfa94ba3ef7706cce38760. That commit effectively disabled Intel host initiated U1/U2 lpm for devices with periodic endpoints. Before that commit we disabled host initiated U1/U2 lpm if the exit latency was larger than any periodic endpoint service interval, this is according to xhci spec xhci 1.1 specification section 4.23.5.2 After that commit we incorrectly checked that service interval was smaller than U1/U2 inactivity timeout. This is not relevant, and can't happen for Intel hosts as previously set U1/U2 timeout = 105% * service interval. Patch claimed it solved cases where devices can't be enumerated because of bandwidth issues. This might be true but it's a side effect of accidentally turning off lpm. exit latency calculations have been revised since then Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210820123503.2605901-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ba2faddf1f14c2a7ecb0adecaebcc332c919cf05 Author: Ding Hui Date: Tue Aug 17 22:55:10 2021 +0800 cifs: fix wrong release in sess_alloc_buffer() failed path [ Upstream commit d72c74197b70bc3c95152f351a568007bffa3e11 ] smb_buf is allocated by small_smb_init_no_tc(), and buf type is CIFS_SMALL_BUFFER, so we should use cifs_small_buf_release() to release it in failed path. Signed-off-by: Ding Hui Reviewed-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 7c7d6c9cd879a4bb19b101735858a175e698219b Author: Nishad Kamdar Date: Wed Aug 25 00:47:26 2021 +0530 mmc: core: Return correct emmc response in case of ioctl error [ Upstream commit e72a55f2e5ddcfb3dce0701caf925ce435b87682 ] When a read/write command is sent via ioctl to the kernel, and the command fails, the actual error response of the emmc is not sent to the user. IOCTL read/write tests are carried out using commands 17 (Single BLock Read), 24 (Single Block Write), 18 (Multi Block Read), 25 (Multi Block Write) The tests are carried out on a 64Gb emmc device. All of these tests try to access an "out of range" sector address (0x09B2FFFF). It is seen that without the patch the response received by the user is not OUT_OF_RANGE error (R1 response 31st bit is not set) as per JEDEC specification. After applying the patch proper response is seen. This is because the function returns without copying the response to the user in case of failure. This patch fixes the issue. Hence, this memcpy is required whether we get an error response or not. Therefor it is moved up from the current position up to immediately after we have called mmc_wait_for_req(). The test code and the output of only the CMD17 is included in the commit to limit the message length. CMD17 (Test Code Snippet): ========================== printf("Forming CMD%d\n", opt_idx); /* single block read */ cmd.blksz = 512; cmd.blocks = 1; cmd.write_flag = 0; cmd.opcode = 17; //cmd.arg = atoi(argv[3]); cmd.arg = 0x09B2FFFF; /* Expecting response R1B */ cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_R1 | MMC_CMD_ADTC; memset(data, 0, sizeof(__u8) * 512); mmc_ioc_cmd_set_data(cmd, data); printf("Sending CMD%d: ARG[0x%08x]\n", opt_idx, cmd.arg); if(ioctl(fd, MMC_IOC_CMD, &cmd)) perror("Error"); printf("\nResponse: %08x\n", cmd.response[0]); CMD17 (Output without patch): ============================= test@test-LIVA-Z:~$ sudo ./mmc cmd_test /dev/mmcblk0 17 Entering the do_mmc_commands:Device: /dev/mmcblk0 nargs:4 Entering the do_mmc_commands:Device: /dev/mmcblk0 options[17, 0x09B2FFF] Forming CMD17 Sending CMD17: ARG[0x09b2ffff] Error: Connection timed out Response: 00000000 (Incorrect response) CMD17 (Output with patch): ========================== test@test-LIVA-Z:~$ sudo ./mmc cmd_test /dev/mmcblk0 17 [sudo] password for test: Entering the do_mmc_commands:Device: /dev/mmcblk0 nargs:4 Entering the do_mmc_commands:Device: /dev/mmcblk0 options[17, 09B2FFFF] Forming CMD17 Sending CMD17: ARG[0x09b2ffff] Error: Connection timed out Response: 80000900 (Correct OUT_OF_ERROR response as per JEDEC specification) Signed-off-by: Nishad Kamdar Reviewed-by: Avri Altman Link: https://lore.kernel.org/r/20210824191726.8296-1-nishadkamdar@gmail.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit d1e382a04adafdf30cb0c738448327d13703422b Author: Li Zhijian Date: Fri Aug 20 09:55:53 2021 +0800 selftests/bpf: Enlarge select() timeout for test_maps [ Upstream commit 2d82d73da35b72b53fe0d96350a2b8d929d07e42 ] 0Day robot observed that it's easily timeout on a heavy load host. ------------------- # selftests: bpf: test_maps # Fork 1024 tasks to 'test_update_delete' # Fork 1024 tasks to 'test_update_delete' # Fork 100 tasks to 'test_hashmap' # Fork 100 tasks to 'test_hashmap_percpu' # Fork 100 tasks to 'test_hashmap_sizes' # Fork 100 tasks to 'test_hashmap_walk' # Fork 100 tasks to 'test_arraymap' # Fork 100 tasks to 'test_arraymap_percpu' # Failed sockmap unexpected timeout not ok 3 selftests: bpf: test_maps # exit=1 # selftests: bpf: test_lru_map # nr_cpus:8 ------------------- Since this test will be scheduled by 0Day to a random host that could have only a few cpus(2-8), enlarge the timeout to avoid a false NG report. In practice, i tried to pin it to only one cpu by 'taskset 0x01 ./test_maps', and knew 10S is likely enough, but i still perfer to a larger value 30. Reported-by: kernel test robot Signed-off-by: Li Zhijian Signed-off-by: Alexei Starovoitov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20210820015556.23276-2-lizhijian@cn.fujitsu.com Signed-off-by: Sasha Levin commit 3aab5bffdde0d30a8885d0140afc2d58e76da714 Author: Thomas Hebb Date: Sun Aug 1 04:46:14 2021 -0700 mmc: rtsx_pci: Fix long reads when clock is prescaled [ Upstream commit 3ac5e45291f3f0d699a721357380d4593bc2dcb3 ] For unexplained reasons, the prescaler register for this device needs to be cleared (set to 1) while performing a data read or else the command will hang. This does not appear to affect the real clock rate sent out on the bus, so I assume it's purely to work around a hardware bug. During normal operation, the prescaler is already set to 1, so nothing needs to be done. However, in "initial mode" (which is used for sub-MHz clock speeds, like the core sets while enumerating cards), it's set to 128 and so we need to reset it during data reads. We currently fail to do this for long reads. This has no functional affect on the driver's operation currently written, as the MMC core always sets a clock above 1MHz before attempting any long reads. However, the core could conceivably set any clock speed at any time and the driver should still work, so I think this fix is worthwhile. I personally encountered this issue while performing data recovery on an external chip. My connections had poor signal integrity, so I modified the core code to reduce the clock speed. Without this change, I saw the card enumerate but was unable to actually read any data. Writes don't seem to work in the situation described above even with this change (and even if the workaround is extended to encompass data write commands). I was not able to find a way to get them working. Signed-off-by: Thomas Hebb Link: https://lore.kernel.org/r/2fef280d8409ab0100c26c6ac7050227defd098d.1627818365.git.tommyhebb@gmail.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 7f43da79ebc5e60ba8c0f9677e58a3fce37c12d6 Author: Manish Narani Date: Tue Jun 15 16:13:54 2021 +0530 mmc: sdhci-of-arasan: Check return value of non-void funtions [ Upstream commit 66bad6ed2204fdb78a0a8fb89d824397106a5471 ] At a couple of places, the return values of the non-void functions were not getting checked. This was reported by the coverity tool. Modify the code to check the return values of the same. Addresses-Coverity: ("check_return") Signed-off-by: Manish Narani Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/1623753837-21035-5-git-send-email-manish.narani@xilinx.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 834ecf61cebd84922443d9688d1cff84e4a0e9c2 Author: Manish Narani Date: Tue Jun 15 16:13:51 2021 +0530 mmc: sdhci-of-arasan: Modified SD default speed to 19MHz for ZynqMP [ Upstream commit c0b4e411a9b09748466ee06d2ae6772effa64dfb ] SD standard speed timing was met only at 19MHz and not 25 MHz, that's why changing driver to 19MHz. The reason for this is when a level shifter is used on the board, timing was met for standard speed only at 19MHz. Since this level shifter is commonly required for high speed modes, the driver is modified to use standard speed of 19Mhz. Signed-off-by: Manish Narani Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/1623753837-21035-2-git-send-email-manish.narani@xilinx.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 1a40e60e2af49cf2b4ecc51e2925a771c757c16e Author: Marc Zyngier Date: Fri Aug 20 15:47:22 2021 +0100 of: Don't allow __of_attached_node_sysfs() without CONFIG_SYSFS [ Upstream commit 6211e9cb2f8faf7faae0b6caf844bfe9527cc607 ] Trying to boot without SYSFS, but with OF_DYNAMIC quickly results in a crash: [ 0.088460] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070 [...] [ 0.103927] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc3 #4179 [ 0.105810] Hardware name: linux,dummy-virt (DT) [ 0.107147] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) [ 0.108876] pc : kernfs_find_and_get_ns+0x3c/0x7c [ 0.110244] lr : kernfs_find_and_get_ns+0x3c/0x7c [...] [ 0.134087] Call trace: [ 0.134800] kernfs_find_and_get_ns+0x3c/0x7c [ 0.136054] safe_name+0x4c/0xd0 [ 0.136994] __of_attach_node_sysfs+0xf8/0x124 [ 0.138287] of_core_init+0x90/0xfc [ 0.139296] driver_init+0x30/0x4c [ 0.140283] kernel_init_freeable+0x160/0x1b8 [ 0.141543] kernel_init+0x30/0x140 [ 0.142561] ret_from_fork+0x10/0x18 While not having sysfs isn't a very common option these days, it is still expected that such configuration would work. Paper over it by bailing out from __of_attach_node_sysfs() if CONFIG_SYSFS isn't enabled. Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210820144722.169226-1-maz@kernel.org Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit be69ed7bb9d3c05074718af811868e47f3f512b8 Author: Gustaw Lewandowski Date: Wed Aug 18 09:57:37 2021 +0200 ASoC: Intel: Skylake: Fix passing loadable flag for module [ Upstream commit c5ed9c547cba1dc1238c6e8a0c290fd62ee6e127 ] skl_get_module_info() tries to set mconfig->module->loadable before mconfig->module has been assigned thus flag was always set to false and driver did not try to load module binaries. Signed-off-by: Gustaw Lewandowski Signed-off-by: Cezary Rojewski Tested-by: Lukasz Majczak Link: https://lore.kernel.org/r/20210818075742.1515155-7-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4a48ed479467a62a197d7c2353249d54d6119d47 Author: Cezary Rojewski Date: Wed Aug 18 09:57:36 2021 +0200 ASoC: Intel: Skylake: Fix module configuration for KPB and MIXER [ Upstream commit e4e0633bcadc950b4b4af06c7f1bb7f7e3e86321 ] KeyPhrasebuffer, Mixin and Mixout modules configuration is described by firmware's basic module configuration structure. There are no extended parameters required. Update functions taking part in building INIT_INSTANCE IPC payload to reflect that. Signed-off-by: Cezary Rojewski Tested-by: Lukasz Majczak Link: https://lore.kernel.org/r/20210818075742.1515155-6-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d72afec087f731492a17198619017f2acbaaa0d6 Author: Pierre-Louis Bossart Date: Wed Aug 18 10:49:52 2021 +0800 soundwire: intel: fix potential race condition during power down [ Upstream commit ea6942dad4b2a7e1735aa0f10f3d0b04b847750f ] The power down sequence sets the link_up flag as false outside of the mutex_lock. This is potentially unsafe. In additional the flow in that sequence can be improved by first testing if the link was powered, setting the link_up flag as false and proceeding with the power down. In case the CPA bits cannot be cleared, we only flag an error since we cannot deal with interrupts any longer. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20210818024954.16873-2-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit b225eeaf3a02f2d47a4a5ee8cc976fc822eddac7 Author: Marcos Paulo de Souza Date: Mon Aug 2 09:34:00 2021 -0300 btrfs: tree-log: check btrfs_lookup_data_extent return value [ Upstream commit 3736127a3aa805602b7a2ad60ec9cfce68065fbb ] Function btrfs_lookup_data_extent calls btrfs_search_slot to verify if the EXTENT_ITEM exists in the extent tree. btrfs_search_slot can return values bellow zero if an error happened. Function replay_one_extent currently checks if the search found something (0 returned) and increments the reference, and if not, it seems to evaluate as 'not found'. Fix the condition by checking if the value was bellow zero and return early. Reviewed-by: Filipe Manana Signed-off-by: Marcos Paulo de Souza Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 87ae522e467e17a13b796e2cb595f9c3943e4d5e Author: Arnd Bergmann Date: Mon Aug 9 18:01:31 2021 +1000 m68knommu: only set CONFIG_ISA_DMA_API for ColdFire sub-arch [ Upstream commit db87db65c1059f3be04506d122f8ec9b2fa3b05e ] > Hi Arnd, > > First bad commit (maybe != root cause): > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > head: 2f73937c9aa561e2082839bc1a8efaac75d6e244 > commit: 47fd22f2b84765a2f7e3f150282497b902624547 [4771/5318] cs89x0: rework driver configuration > config: m68k-randconfig-c003-20210804 (attached as .config) > compiler: m68k-linux-gcc (GCC) 10.3.0 > reproduce (this is a W=1 build): > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=47fd22f2b84765a2f7e3f150282497b902624547 > git remote add linux-next https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > git fetch --no-tags linux-next master > git checkout 47fd22f2b84765a2f7e3f150282497b902624547 > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-10.3.0 make.cross ARCH=m68k > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All errors (new ones prefixed by >>): > > In file included from include/linux/kernel.h:19, > from include/linux/list.h:9, > from include/linux/module.h:12, > from drivers/net/ethernet/cirrus/cs89x0.c:51: > drivers/net/ethernet/cirrus/cs89x0.c: In function 'net_open': > drivers/net/ethernet/cirrus/cs89x0.c:897:20: error: implicit declaration of function 'isa_virt_to_bus'; did you mean 'virt_to_bus'? [-Werror=implicit-function-declaration] > 897 | (unsigned long)isa_virt_to_bus(lp->dma_buff)); > | ^~~~~~~~~~~~~~~ > include/linux/printk.h:141:17: note: in definition of macro 'no_printk' > 141 | printk(fmt, ##__VA_ARGS__); \ > | ^~~~~~~~~~~ > drivers/net/ethernet/cirrus/cs89x0.c:86:3: note: in expansion of macro 'pr_debug' > 86 | pr_##level(fmt, ##__VA_ARGS__); \ > | ^~~ > drivers/net/ethernet/cirrus/cs89x0.c:894:3: note: in expansion of macro 'cs89_dbg' > 894 | cs89_dbg(1, debug, "%s: dma %lx %lx\n", > | ^~~~~~~~ > >> drivers/net/ethernet/cirrus/cs89x0.c:914:3: error: implicit declaration of function 'disable_dma'; did you mean 'disable_irq'? [-Werror=implicit-function-declaration] As far as I can tell, this is a bug with the m68kmmu architecture, not with my driver: The CONFIG_ISA_DMA_API option is provided for coldfire, which implements it, but dragonball also sets the option as a side-effect, without actually implementing the interfaces. The patch below should fix it. Signed-off-by: Arnd Bergmann Signed-off-by: Greg Ungerer Signed-off-by: Sasha Levin commit c10b1afc2f43f58a26207128edc0705b25367036 Author: Subbaraya Sundeep Date: Sun Aug 22 17:32:18 2021 +0530 octeontx2-pf: Fix NIX1_RX interface backpressure [ Upstream commit e8fb4df1f5d84bc08dd4f4827821a851d2eab241 ] 'bp_ena' in Aura context is NIX block index, setting it zero will always backpressure NIX0 block, even if NIXLF belongs to NIX1. Hence fix this by setting it appropriately based on NIX block address. Signed-off-by: Subbaraya Sundeep Signed-off-by: Hariprasad Kelam Signed-off-by: Sunil Goutham Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6d657f1fa121f98ecf807c11eba2d9f7c8795185 Author: Chin-Yen Lee Date: Wed Jul 28 09:43:35 2021 +0800 rtw88: wow: fix size access error of probe request [ Upstream commit 69c7044526d984df672b8d9b6d6998c34617cde4 ] Current flow will lead to null ptr access because of trying to get the size of freed probe-request packets. We store the information of packet size into rsvd page instead and also fix the size error issue, which will cause unstable behavoir of sending probe request by wow firmware. Signed-off-by: Chin-Yen Lee Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210728014335.8785-6-pkshih@realtek.com Signed-off-by: Sasha Levin commit aa82a11176bd6af7cec315edd237fa23d3686762 Author: Ping-Ke Shih Date: Wed Jul 28 09:43:33 2021 +0800 rtw88: wow: build wow function only if CONFIG_PM is on [ Upstream commit 05e45887382c4c0f9522515759b34991aa17e69d ] The kernel test robot reports undefined reference after we report wakeup reason to mac80211. This is because CONFIG_PM is not defined in the testing configuration file. In fact, functions within wow.c are used if CONFIG_PM is defined, so use CONFIG_PM to decide whether we build this file or not. The reported messages are: hppa-linux-ld: drivers/net/wireless/realtek/rtw88/wow.o: in function `rtw_wow_show_wakeup_reason': >> (.text+0x6c4): undefined reference to `ieee80211_report_wowlan_wakeup' >> hppa-linux-ld: (.text+0x6e0): undefined reference to `ieee80211_report_wowlan_wakeup' Reported-by: kernel test robot Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210728014335.8785-4-pkshih@realtek.com Signed-off-by: Sasha Levin commit 2fd1964f7501b76963690ab54eb59352a8bc2de3 Author: Chin-Yen Lee Date: Wed Jul 28 09:43:31 2021 +0800 rtw88: use read_poll_timeout instead of fixed sleep [ Upstream commit 02a55c0009a55b204e1e5c17295431f0a9e7d3b6 ] In current wow flow, driver calls rtw_wow_fw_start and sleep for 100ms, to wait firmware finish preliminary work and then update the value of WOWLAN_WAKE_REASON register to zero. But later firmware will start wow function with power-saving mode, in which mode the value of WOWLAN_WAKE_REASON register is 0xea. So driver may get 0xea value and return fail. We use read_poll_timeout instead to check the value to avoid this issue. Signed-off-by: Chin-Yen Lee Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210728014335.8785-2-pkshih@realtek.com Signed-off-by: Sasha Levin commit 9baf6f8ca285f0d491dd58bc4f558d4fe98ee812 Author: Chris Chiu Date: Wed Aug 4 23:13:25 2021 +0800 rtl8xxxu: Fix the handling of TX A-MPDU aggregation [ Upstream commit 95a581ab3592082c60a08090aabe09ac7d0bd650 ] The TX A-MPDU aggregation is not handled in the driver since the ieee80211_start_tx_ba_session has never been started properly. Start and stop the TX BA session by tracking the TX aggregation status of each TID. Fix the ampdu_action and the tx descriptor accordingly with the given TID. Signed-off-by: Chris Chiu Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210804151325.86600-1-chris.chiu@canonical.com Signed-off-by: Sasha Levin commit 756924bc1804f0696fda8aeedd48a42152c0c7bf Author: Nathan Chancellor Date: Tue Jul 27 16:36:56 2021 -0700 drm/exynos: Always initialize mapping in exynos_drm_register_dma() [ Upstream commit c626f3864bbbb28bbe06476b0b497c1330aa4463 ] In certain randconfigs, clang warns: drivers/gpu/drm/exynos/exynos_drm_dma.c:121:19: warning: variable 'mapping' is uninitialized when used here [-Wuninitialized] priv->mapping = mapping; ^~~~~~~ drivers/gpu/drm/exynos/exynos_drm_dma.c:111:16: note: initialize the variable 'mapping' to silence this warning void *mapping; ^ = NULL 1 warning generated. This occurs when CONFIG_EXYNOS_IOMMU is enabled and both CONFIG_ARM_DMA_USE_IOMMU and CONFIG_IOMMU_DMA are disabled, which makes the code look like void *mapping; if (0) mapping = arm_iommu_create_mapping() else if (0) mapping = iommu_get_domain_for_dev() ... priv->mapping = mapping; Add an else branch that initializes mapping to the -ENODEV error pointer so that there is no more warning and the driver does not change during runtime. Reported-by: kernel test robot Signed-off-by: Nathan Chancellor Signed-off-by: Inki Dae Signed-off-by: Sasha Levin commit 9ce6e29375bab3c081bc61162d82e47e8d7a439a Author: J. Bruce Fields Date: Fri Aug 20 17:01:59 2021 -0400 lockd: lockd server-side shouldn't set fl_ops [ Upstream commit 7de875b231edb807387a81cde288aa9e1015ef9e ] Locks have two sets of op arrays, fl_lmops for the lock manager (lockd or nfsd), fl_ops for the filesystem. The server-side lockd code has been setting its own fl_ops, which leads to confusion (and crashes) in the reexport case, where the filesystem expects to be the only one setting fl_ops. And there's no reason for it that I can see-the lm_get/put_owner ops do the same job. Reported-by: Daire Byrne Tested-by: Daire Byrne Signed-off-by: J. Bruce Fields Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 2d3fab9ceafad925d30d0ea78f3a2b1bc8ce550b Author: Li Jun Date: Fri Jun 18 16:28:58 2021 +0800 usb: chipidea: host: fix port index underflow and UBSAN complains [ Upstream commit e5d6a7c6cfae9e714a0e8ff64facd1ac68a784c6 ] If wIndex is 0 (and it often is), these calculations underflow and UBSAN complains, here resolve this by not decrementing the index when it is equal to 0, this copies the solution from commit 85e3990bea49 ("USB: EHCI: avoid undefined pointer arithmetic and placate UBSAN") Reported-by: Zhipeng Wang Signed-off-by: Li Jun Link: https://lore.kernel.org/r/1624004938-2399-1-git-send-email-jun.li@nxp.com Signed-off-by: Peter Chen Signed-off-by: Sasha Levin commit 2225a5cd2fbc2ef0e0f78e585db3844f60416a39 Author: Bob Peterson Date: Fri Jul 30 12:41:49 2021 -0500 gfs2: Don't call dlm after protocol is unmounted [ Upstream commit d1340f80f0b8066321b499a376780da00560e857 ] In the gfs2 withdraw sequence, the dlm protocol is unmounted with a call to lm_unmount. After a withdraw, users are allowed to unmount the withdrawn file system. But at that point we may still have glocks left over that we need to free via unmount's call to gfs2_gl_hash_clear. These glocks may have never been completed because of whatever problem caused the withdraw (IO errors or whatever). Before this patch, function gdlm_put_lock would still try to call into dlm to unlock these leftover glocks, which resulted in dlm returning -EINVAL because the lock space was abandoned. These glocks were never freed because there was no mechanism after that to free them. This patch adds a check to gdlm_put_lock to see if the locking protocol was inactive (DFL_UNMOUNT flag) and if so, free the glock and not make the invalid call into dlm. I could have combined this "if" with the one that follows, related to leftover glock LVBs, but I felt the code was more readable with its own if clause. Signed-off-by: Bob Peterson Signed-off-by: Sasha Levin commit 0df5eba67bf05663bfc044865c8daddaf3a2cb4a Author: Mark Brown Date: Thu Aug 19 17:57:23 2021 +0100 kselftest/arm64: pac: Fix skipping of tests on systems without PAC [ Upstream commit 0c69bd2ca6ee20064dde7853cd749284e053a874 ] The PAC tests check to see if the system supports the relevant PAC features but instead of skipping the tests if they can't be executed they fail the tests which makes things look like they're not working when they are. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20210819165723.43903-1-broonie@kernel.org Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 9486d7ac9f30fb412ece53cbf59e13e1a6636ab0 Author: Mark Brown Date: Thu Aug 19 18:29:02 2021 +0100 kselftest/arm64: mte: Fix misleading output when skipping tests [ Upstream commit 83e5dcbece4ea67ec3ad94b897e2844184802fd7 ] When skipping the tests due to a lack of system support for MTE we currently print a message saying FAIL which makes it look like the test failed even though the test did actually report KSFT_SKIP, creating some confusion. Change the error message to say SKIP instead so things are clearer. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20210819172902.56211-1-broonie@kernel.org Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 1f5db5b8a3d6b351673f9592b8577a7e29eb7432 Author: Eli Cohen Date: Tue Aug 17 20:05:18 2021 +0300 net: Fix offloading indirect devices dependency on qdisc order creation [ Upstream commit 74fc4f828769cca1c3be89ea92cb88feaa27ef52 ] Currently, when creating an ingress qdisc on an indirect device before the driver registered for callbacks, the driver will not have a chance to register its filter configuration callbacks. To fix that, modify the code such that it keeps track of all the ingress qdiscs that call flow_indr_dev_setup_offload(). When a driver calls flow_indr_dev_register(), go through the list of tracked ingress qdiscs and call the driver callback entry point so as to give it a chance to register its callback. Reviewed-by: Jiri Pirko Signed-off-by: Eli Cohen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2a69325ee51003201043df3b3eec8bbec7b66c12 Author: Kees Cook Date: Tue Aug 17 21:42:52 2021 -0700 staging: rts5208: Fix get_ms_information() heap buffer size [ Upstream commit cbe34165cc1b7d1110b268ba8b9f30843c941639 ] Fix buf allocation size (it needs to be 2 bytes larger). Found when __alloc_size() annotations were added to kmalloc() interfaces. In file included from ./include/linux/string.h:253, from ./include/linux/bitmap.h:10, from ./include/linux/cpumask.h:12, from ./arch/x86/include/asm/paravirt.h:17, from ./arch/x86/include/asm/irqflags.h:63, from ./include/linux/irqflags.h:16, from ./include/linux/rcupdate.h:26, from ./include/linux/rculist.h:11, from ./include/linux/pid.h:5, from ./include/linux/sched.h:14, from ./include/linux/blkdev.h:5, from drivers/staging/rts5208/rtsx_scsi.c:12: In function 'get_ms_information', inlined from 'ms_sp_cmnd' at drivers/staging/rts5208/rtsx_scsi.c:2877:12, inlined from 'rtsx_scsi_handler' at drivers/staging/rts5208/rtsx_scsi.c:3247:12: ./include/linux/fortify-string.h:54:29: warning: '__builtin_memcpy' forming offset [106, 107] is out of the bounds [0, 106] [-Warray-bounds] 54 | #define __underlying_memcpy __builtin_memcpy | ^ ./include/linux/fortify-string.h:417:2: note: in expansion of macro '__underlying_memcpy' 417 | __underlying_##op(p, q, __fortify_size); \ | ^~~~~~~~~~~~~ ./include/linux/fortify-string.h:463:26: note: in expansion of macro '__fortify_memcpy_chk' 463 | #define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \ | ^~~~~~~~~~~~~~~~~~~~ drivers/staging/rts5208/rtsx_scsi.c:2851:3: note: in expansion of macro 'memcpy' 2851 | memcpy(buf + i, ms_card->raw_sys_info, 96); | ^~~~~~ Cc: Greg Kroah-Hartman Cc: linux-staging@lists.linux.dev Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20210818044252.1533634-1-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 868831492dd63b9759b63ad12da5df65d99a4940 Author: Brandon Wyman Date: Fri Aug 6 22:51:31 2021 +0000 hwmon: (pmbus/ibm-cffps) Fix write bits for LED control [ Upstream commit 76b72736f574ec38b3e94603ea5f74b1853f26b0 ] When doing a PMBus write for the LED control on the IBM Common Form Factor Power Supplies (ibm-cffps), the DAh command requires that bit 7 be low and bit 6 be high in order to indicate that you are truly attempting to do a write. Signed-off-by: Brandon Wyman Link: https://lore.kernel.org/r/20210806225131.1808759-1-bjwyman@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 39738ebfad3969768d62d7432a38b910d960c7f8 Author: Yonghong Song Date: Tue Aug 17 12:09:23 2021 -0700 selftests/bpf: Fix flaky send_signal test [ Upstream commit b16ac5bf732a5e23d164cf908ec7742d6a6120d3 ] libbpf CI has reported send_signal test is flaky although I am not able to reproduce it in my local environment. But I am able to reproduce with on-demand libbpf CI ([1]). Through code analysis, the following is possible reason. The failed subtest runs bpf program in softirq environment. Since bpf_send_signal() only sends to a fork of "test_progs" process. If the underlying current task is not "test_progs", bpf_send_signal() will not be triggered and the subtest will fail. To reduce the chances where the underlying process is not the intended one, this patch boosted scheduling priority to -20 (highest allowed by setpriority() call). And I did 10 runs with on-demand libbpf CI with this patch and I didn't observe any failures. [1] https://github.com/libbpf/libbpf/actions/workflows/ondemand.yml Signed-off-by: Yonghong Song Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210817190923.3186725-1-yhs@fb.com Signed-off-by: Sasha Levin commit c53c68c9bf2a8543046360a1e75589f00c032d1a Author: J. Bruce Fields Date: Thu Aug 12 16:41:42 2021 -0400 rpc: fix gss_svc_init cleanup on failure [ Upstream commit 5a4753446253a427c0ff1e433b9c4933e5af207c ] The failure case here should be rare, but it's obviously wrong. Signed-off-by: J. Bruce Fields Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 4b1b4d3f45dffaaee29456f696aa38889ce5f001 Author: Luke Hsiao Date: Mon Aug 16 20:51:06 2021 +0000 tcp: enable data-less, empty-cookie SYN with TFO_SERVER_COOKIE_NOT_REQD [ Upstream commit e3faa49bcecdfcc80e94dd75709d6acb1a5d89f6 ] Since the original TFO server code was implemented in commit 168a8f58059a22feb9e9a2dcc1b8053dbbbc12ef ("tcp: TCP Fast Open Server - main code path") the TFO server code has supported the sysctl bit flag TFO_SERVER_COOKIE_NOT_REQD. Currently, when the TFO_SERVER_ENABLE and TFO_SERVER_COOKIE_NOT_REQD sysctl bit flags are set, a server connection will accept a SYN with N bytes of data (N > 0) that has no TFO cookie, create a new fast open connection, process the incoming data in the SYN, and make the connection ready for accepting. After accepting, the connection is ready for read()/recvmsg() to read the N bytes of data in the SYN, ready for write()/sendmsg() calls and data transmissions to transmit data. This commit changes an edge case in this feature by changing this behavior to apply to (N >= 0) bytes of data in the SYN rather than only (N > 0) bytes of data in the SYN. Now, a server will accept a data-less SYN without a TFO cookie if TFO_SERVER_COOKIE_NOT_REQD is set. Caveat! While this enables a new kind of TFO (data-less empty-cookie SYN), some firewall rules setup may not work if they assume such packets are not legit TFOs and will filter them. Signed-off-by: Luke Hsiao Acked-by: Neal Cardwell Acked-by: Yuchung Cheng Signed-off-by: Eric Dumazet Link: https://lore.kernel.org/r/20210816205105.2533289-1-luke.w.hsiao@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fca514f25c4d714d80aac858986b33dd092fefaf Author: Darrick J. Wong Date: Tue Aug 10 18:32:55 2021 -0700 iomap: pass writeback errors to the mapping [ Upstream commit b69eea82d37d9ee7cfb3bf05103549dd4ed5ffc3 ] Modern-day mapping_set_error has the ability to squash the usual negative error code into something appropriate for long-term storage in a struct address_space -- ENOSPC becomes AS_ENOSPC, and everything else becomes EIO. iomap squashes /everything/ to EIO, just as XFS did before that, but this doesn't make sense. Fix this by making it so that we can pass ENOSPC to userspace when writeback fails due to space problems. Signed-off-by: Darrick J. Wong Reviewed-by: Matthew Wilcox (Oracle) Signed-off-by: Sasha Levin commit 49e2bcb7cf580f83fec96b29bf2b3774bdf1b930 Author: Ulrich Hecht Date: Mon Aug 16 18:22:01 2021 +0200 serial: sh-sci: fix break handling for sysrq [ Upstream commit 87b8061bad9bd4b549b2daf36ffbaa57be2789a2 ] This fixes two issues that cause the sysrq sequence to be inadvertently aborted on SCIF serial consoles: - a NUL character remains in the RX queue after a break has been detected, which is then passed on to uart_handle_sysrq_char() - the break interrupt is handled twice on controllers with multiplexed ERI and BRI interrupts Signed-off-by: Ulrich Hecht Link: https://lore.kernel.org/r/20210816162201.28801-1-uli+renesas@fpond.eu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a99eec36ed39f7717827d15aeb329fe0e17396e5 Author: Rajendra Nayak Date: Thu Aug 12 16:57:20 2021 +0530 opp: Don't print an error if required-opps is missing [ Upstream commit 020d86fc0df8b865f6dc168d88a7c2dccabd0a9e ] The 'required-opps' property is considered optional, hence remove the pr_err() in of_parse_required_opp() when we find the property is missing. While at it, also fix the return value of of_get_required_opp_performance_state() when of_parse_required_opp() fails, return a -ENODEV instead of the -EINVAL. Signed-off-by: Rajendra Nayak Reviewed-by: Ulf Hansson Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 6698029de35b780f382495315798f3f504d2c4a5 Author: Luiz Augusto von Dentz Date: Wed Aug 11 16:20:15 2021 -0700 Bluetooth: Fix handling of LE Enhanced Connection Complete [ Upstream commit cafae4cd625502f65d1798659c1aa9b62d38cc56 ] LE Enhanced Connection Complete contains the Local RPA used in the connection which must be used when set otherwise there could problems when pairing since the address used by the remote stack could be the Local RPA: BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 4, Part E page 2396 'Resolvable Private Address being used by the local device for this connection. This is only valid when the Own_Address_Type (from the HCI_LE_Create_Connection, HCI_LE_Set_Advertising_Parameters, HCI_LE_Set_Extended_Advertising_Parameters, or HCI_LE_Extended_Create_Connection commands) is set to 0x02 or 0x03, and the Controller generated a resolvable private address for the local device using a non-zero local IRK. For other Own_Address_Type values, the Controller shall return all zeros.' Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 240a7025a6f89f9596c36134bd07f3855c56c712 Author: Sagi Grimberg Date: Wed Jun 16 14:19:36 2021 -0700 nvme: code command_id with a genctr for use-after-free validation [ Upstream commit e7006de6c23803799be000a5dcce4d916a36541a ] We cannot detect a (perhaps buggy) controller that is sending us a completion for a request that was already completed (for example sending a completion twice), this phenomenon was seen in the wild a few times. So to protect against this, we use the upper 4 msbits of the nvme sqe command_id to use as a 4-bit generation counter and verify it matches the existing request generation that is incrementing on every execution. The 16-bit command_id structure now is constructed by: | xxxx | xxxxxxxxxxxx | gen request tag This means that we are giving up some possible queue depth as 12 bits allow for a maximum queue depth of 4095 instead of 65536, however we never create such long queues anyways so no real harm done. Suggested-by: Keith Busch Signed-off-by: Sagi Grimberg Acked-by: Keith Busch Reviewed-by: Hannes Reinecke Reviewed-by: Daniel Wagner Tested-by: Daniel Wagner Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 24618e92d50f647774cec82a630bf25053d23fee Author: Sagi Grimberg Date: Wed Jun 16 14:19:35 2021 -0700 nvme-tcp: don't check blk_mq_tag_to_rq when receiving pdu data [ Upstream commit 3b01a9d0caa8276d9ce314e09610f7fb70f49a00 ] We already validate it when receiving the c2hdata pdu header and this is not changing so this is a redundant check. Reviewed-by: Hannes Reinecke Signed-off-by: Sagi Grimberg Reviewed-by: Daniel Wagner Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 27e8bc1f5b32509ff40e9a9ed64ca071f42e7c5c Author: Raag Jadav Date: Thu Aug 5 00:54:45 2021 +0530 arm64: dts: ls1046a: fix eeprom entries [ Upstream commit c1a6018d1839c9cb8f807dc863a50102a1a5c412 ] ls1046afrwy and ls1046ardb boards have CAT24C04[1] and CAT24C05[2] eeproms respectively. Both are 4Kb (512 bytes) in size, and compatible with AT24C04[3]. Remove multi-address entries, as both the boards have a single chip each. [1] https://www.onsemi.com/pdf/datasheet/cat24c01-d.pdf [2] https://www.onsemi.com/pdf/datasheet/cat24c03-d.pdf [3] https://ww1.microchip.com/downloads/en/DeviceDoc/doc0180.pdf Signed-off-by: Raag Jadav Acked-by: Li Yang Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit aa06cfc5291ca824632fbebe35a2ae8161ce7790 Author: Thierry Reding Date: Tue Jun 22 15:44:22 2021 +0200 arm64: tegra: Fix compatible string for Tegra132 CPUs [ Upstream commit f865d0292ff3c0ca09414436510eb4c815815509 ] The documented compatible string for the CPUs found on Tegra132 is "nvidia,tegra132-denver", rather than the previously used compatible string "nvidia,denver". Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 9c2b89f64f2e803c2ac9473e4889742c53440890 Author: Andreas Obergschwandtner Date: Thu Jul 29 16:42:26 2021 +0200 ARM: tegra: tamonten: Fix UART pad setting [ Upstream commit 2270ad2f4e123336af685ecedd1618701cb4ca1e ] This patch fixes the tristate and pullup configuration for UART 1 to 3 on the Tamonten SOM. Signed-off-by: Andreas Obergschwandtner Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 035e8d5a6dd8a7b4632925fb24647ae7385c9057 Author: Dmitry Osipenko Date: Tue Aug 3 00:19:43 2021 +0300 ARM: tegra: acer-a500: Remove bogus USB VBUS regulators [ Upstream commit 70e740ad55e5f93a19493720f4105555fade4a73 ] The configuration of USB VBUS regulators was borrowed from downstream kernel, which is incorrect because the corresponding GPIOs are connected to PROX_EN (A501 3G model) and LED_EN pins in accordance to the board schematics. USB works fine with both GPIOs being disabled, so remove the bogus USB VBUS regulators. The USB VBUS of USB3 is supplied from the fixed 5v system regulator and device-mode USB1 doesn't have VBUS switches. Signed-off-by: Dmitry Osipenko Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 9713dfa5185ac06efa5998c61d4287d8306f60f4 Author: Johan Almbladh Date: Mon Jun 28 14:32:46 2021 +0200 mac80211: Fix monitor MTU limit so that A-MSDUs get through [ Upstream commit 79f5962baea74ce1cd4e5949598944bff854b166 ] The maximum MTU was set to 2304, which is the maximum MSDU size. While this is valid for normal WLAN interfaces, it is too low for monitor interfaces. A monitor interface may receive and inject MPDU frames, and the maximum MPDU frame size is larger than 2304. The MPDU may also contain an A-MSDU frame, in which case the size may be much larger than the MTU limit. Since the maximum size of an A-MSDU depends on the PHY mode of the transmitting STA, it is not possible to set an exact MTU limit for a monitor interface. Now the maximum MTU for a monitor interface is unrestricted. Signed-off-by: Johan Almbladh Link: https://lore.kernel.org/r/20210628123246.2070558-1-johan.almbladh@anyfinetworks.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 83449db3aac0895147eac723bf23d0739720b968 Author: Tuo Li Date: Tue Aug 10 21:07:03 2021 -0700 drm/display: fix possible null-pointer dereference in dcn10_set_clock() [ Upstream commit 554594567b1fa3da74f88ec7b2dc83d000c58e98 ] The variable dc->clk_mgr is checked in: if (dc->clk_mgr && dc->clk_mgr->funcs->get_clock) This indicates dc->clk_mgr can be NULL. However, it is dereferenced in: if (!dc->clk_mgr->funcs->get_clock) To fix this null-pointer dereference, check dc->clk_mgr and the function pointer dc->clk_mgr->funcs->get_clock earlier, and return if one of them is NULL. Reported-by: TOTE Robot Signed-off-by: Tuo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2254383788ff93a423e20068333b9f8376d56cb4 Author: Tuo Li Date: Wed Aug 11 04:34:58 2021 -0700 gpu: drm: amd: amdgpu: amdgpu_i2c: fix possible uninitialized-variable access in amdgpu_i2c_router_select_ddc_port() [ Upstream commit a211260c34cfadc6068fece8c9e99e0fe1e2a2b6 ] The variable val is declared without initialization, and its address is passed to amdgpu_i2c_get_byte(). In this function, the value of val is accessed in: DRM_DEBUG("i2c 0x%02x 0x%02x read failed\n", addr, *val); Also, when amdgpu_i2c_get_byte() returns, val may remain uninitialized, but it is accessed in: val &= ~amdgpu_connector->router.ddc_mux_control_pin; To fix this possible uninitialized-variable access, initialize val to 0 in amdgpu_i2c_router_select_ddc_port(). Reported-by: TOTE Robot Signed-off-by: Tuo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 155e7047909d871f2910bf24b66432c23a2a11e4 Author: Eran Ben Elisha Date: Tue Aug 10 21:15:05 2021 +0300 net/mlx5: Fix variable type to match 64bit [ Upstream commit 979aa51967add26b37f9d77e01729d44a2da8e5f ] Fix the following smatch warning: wait_func_handle_exec_timeout() warn: should '1 << ent->idx' be a 64 bit type? Use 1ULL, to have a 64 bit type variable. Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Eran Ben Elisha Reviewed-by: Moshe Shemesh Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit f86bc4a1a401d3691bad41e67f9db0c2ea94da32 Author: Kuogee Hsieh Date: Thu Aug 5 13:44:54 2021 -0700 drm/msm/dp: return correct edid checksum after corrupted edid checksum read [ Upstream commit 7948fe12d47a946fb8025a0534c900e3dd4b5839 ] Response with correct edid checksum saved at connector after corrupted edid checksum read. This fixes Link Layer CTS cases 4.2.2.3, 4.2.2.6. Signed-off-by: Kuogee Hsieh Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/1628196295-7382-6-git-send-email-khsieh@codeaurora.org Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 98d44b7be6f1bcfd4f824c5f8bc2b742f890879f Author: Desmond Cheong Zhi Xi Date: Tue Aug 10 12:14:06 2021 +0800 Bluetooth: avoid circular locks in sco_sock_connect [ Upstream commit 734bc5ff783115aa3164f4e9dd5967ae78e0a8ab ] In a future patch, calls to bh_lock_sock in sco.c should be replaced by lock_sock now that none of the functions are run in IRQ context. However, doing so results in a circular locking dependency: ====================================================== WARNING: possible circular locking dependency detected 5.14.0-rc4-syzkaller #0 Not tainted ------------------------------------------------------ syz-executor.2/14867 is trying to acquire lock: ffff88803e3c1120 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1613 [inline] ffff88803e3c1120 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: sco_conn_del+0x12a/0x2a0 net/bluetooth/sco.c:191 but task is already holding lock: ffffffff8d2dc7c8 (hci_cb_list_lock){+.+.}-{3:3}, at: hci_disconn_cfm include/net/bluetooth/hci_core.h:1497 [inline] ffffffff8d2dc7c8 (hci_cb_list_lock){+.+.}-{3:3}, at: hci_conn_hash_flush+0xda/0x260 net/bluetooth/hci_conn.c:1608 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (hci_cb_list_lock){+.+.}-{3:3}: __mutex_lock_common kernel/locking/mutex.c:959 [inline] __mutex_lock+0x12a/0x10a0 kernel/locking/mutex.c:1104 hci_connect_cfm include/net/bluetooth/hci_core.h:1482 [inline] hci_remote_features_evt net/bluetooth/hci_event.c:3263 [inline] hci_event_packet+0x2f4d/0x7c50 net/bluetooth/hci_event.c:6240 hci_rx_work+0x4f8/0xd30 net/bluetooth/hci_core.c:5122 process_one_work+0x98d/0x1630 kernel/workqueue.c:2276 worker_thread+0x658/0x11f0 kernel/workqueue.c:2422 kthread+0x3e5/0x4d0 kernel/kthread.c:319 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 -> #1 (&hdev->lock){+.+.}-{3:3}: __mutex_lock_common kernel/locking/mutex.c:959 [inline] __mutex_lock+0x12a/0x10a0 kernel/locking/mutex.c:1104 sco_connect net/bluetooth/sco.c:245 [inline] sco_sock_connect+0x227/0xa10 net/bluetooth/sco.c:601 __sys_connect_file+0x155/0x1a0 net/socket.c:1879 __sys_connect+0x161/0x190 net/socket.c:1896 __do_sys_connect net/socket.c:1906 [inline] __se_sys_connect net/socket.c:1903 [inline] __x64_sys_connect+0x6f/0xb0 net/socket.c:1903 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #0 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}: check_prev_add kernel/locking/lockdep.c:3051 [inline] check_prevs_add kernel/locking/lockdep.c:3174 [inline] validate_chain kernel/locking/lockdep.c:3789 [inline] __lock_acquire+0x2a07/0x54a0 kernel/locking/lockdep.c:5015 lock_acquire kernel/locking/lockdep.c:5625 [inline] lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5590 lock_sock_nested+0xca/0x120 net/core/sock.c:3170 lock_sock include/net/sock.h:1613 [inline] sco_conn_del+0x12a/0x2a0 net/bluetooth/sco.c:191 sco_disconn_cfm+0x71/0xb0 net/bluetooth/sco.c:1202 hci_disconn_cfm include/net/bluetooth/hci_core.h:1500 [inline] hci_conn_hash_flush+0x127/0x260 net/bluetooth/hci_conn.c:1608 hci_dev_do_close+0x528/0x1130 net/bluetooth/hci_core.c:1778 hci_unregister_dev+0x1c0/0x5a0 net/bluetooth/hci_core.c:4015 vhci_release+0x70/0xe0 drivers/bluetooth/hci_vhci.c:340 __fput+0x288/0x920 fs/file_table.c:280 task_work_run+0xdd/0x1a0 kernel/task_work.c:164 exit_task_work include/linux/task_work.h:32 [inline] do_exit+0xbd4/0x2a60 kernel/exit.c:825 do_group_exit+0x125/0x310 kernel/exit.c:922 get_signal+0x47f/0x2160 kernel/signal.c:2808 arch_do_signal_or_restart+0x2a9/0x1c40 arch/x86/kernel/signal.c:865 handle_signal_work kernel/entry/common.c:148 [inline] exit_to_user_mode_loop kernel/entry/common.c:172 [inline] exit_to_user_mode_prepare+0x17d/0x290 kernel/entry/common.c:209 __syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline] syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:302 ret_from_fork+0x15/0x30 arch/x86/entry/entry_64.S:288 other info that might help us debug this: Chain exists of: sk_lock-AF_BLUETOOTH-BTPROTO_SCO --> &hdev->lock --> hci_cb_list_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(hci_cb_list_lock); lock(&hdev->lock); lock(hci_cb_list_lock); lock(sk_lock-AF_BLUETOOTH-BTPROTO_SCO); *** DEADLOCK *** The issue is that the lock hierarchy should go from &hdev->lock --> hci_cb_list_lock --> sk_lock-AF_BLUETOOTH-BTPROTO_SCO. For example, one such call trace is: hci_dev_do_close(): hci_dev_lock(); hci_conn_hash_flush(): hci_disconn_cfm(): mutex_lock(&hci_cb_list_lock); sco_disconn_cfm(): sco_conn_del(): lock_sock(sk); However, in sco_sock_connect, we call lock_sock before calling hci_dev_lock inside sco_connect, thus inverting the lock hierarchy. We fix this by pulling the call to hci_dev_lock out from sco_connect. Signed-off-by: Desmond Cheong Zhi Xi Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit a1073aad497d0d071a71f61b721966a176d50c08 Author: Desmond Cheong Zhi Xi Date: Tue Aug 10 12:14:05 2021 +0800 Bluetooth: schedule SCO timeouts with delayed_work [ Upstream commit ba316be1b6a00db7126ed9a39f9bee434a508043 ] struct sock.sk_timer should be used as a sock cleanup timer. However, SCO uses it to implement sock timeouts. This causes issues because struct sock.sk_timer's callback is run in an IRQ context, and the timer callback function sco_sock_timeout takes a spin lock on the socket. However, other functions such as sco_conn_del and sco_conn_ready take the spin lock with interrupts enabled. This inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} lock usage could lead to deadlocks as reported by Syzbot [1]: CPU0 ---- lock(slock-AF_BLUETOOTH-BTPROTO_SCO); lock(slock-AF_BLUETOOTH-BTPROTO_SCO); To fix this, we use delayed work to implement SCO sock timouts instead. This allows us to avoid taking the spin lock on the socket in an IRQ context, and corrects the misuse of struct sock.sk_timer. As a note, cancel_delayed_work is used instead of cancel_delayed_work_sync in sco_sock_set_timer and sco_sock_clear_timer to avoid a deadlock. In the future, the call to bh_lock_sock inside sco_sock_timeout should be changed to lock_sock to synchronize with other functions using lock_sock. However, since sco_sock_set_timer and sco_sock_clear_timer are sometimes called under the locked socket (in sco_connect and __sco_sock_close), cancel_delayed_work_sync might cause them to sleep until an sco_sock_timeout that has started finishes running. But sco_sock_timeout would also sleep until it can grab the lock_sock. Using cancel_delayed_work is fine because sco_sock_timeout does not change from run to run, hence there is no functional difference between: 1. waiting for a timeout to finish running before scheduling another timeout 2. scheduling another timeout while a timeout is running. Link: https://syzkaller.appspot.com/bug?id=9089d89de0502e120f234ca0fc8a703f7368b31e [1] Reported-by: syzbot+2f6d7c28bb4bf7e82060@syzkaller.appspotmail.com Tested-by: syzbot+2f6d7c28bb4bf7e82060@syzkaller.appspotmail.com Signed-off-by: Desmond Cheong Zhi Xi Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit d6c91423993e8164ca4162ff046c6437bbd75b53 Author: Desmond Cheong Zhi Xi Date: Sat Jul 24 19:18:24 2021 +0800 drm/vmwgfx: fix potential UAF in vmwgfx_surface.c [ Upstream commit 2bc5da528dd570c5ecabc107e6fbdbc55974276f ] drm_file.master should be protected by either drm_device.master_mutex or drm_file.master_lookup_lock when being dereferenced. However, drm_master_get is called on unprotected file_priv->master pointers in vmw_surface_define_ioctl and vmw_gb_surface_define_internal. This is fixed by replacing drm_master_get with drm_file_get_master. Signed-off-by: Desmond Cheong Zhi Xi Reviewed-by: Daniel Vetter Reviewed-by: Zack Rusin Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20210724111824.59266-4-desmondcheongzx@gmail.com Signed-off-by: Sasha Levin commit 3841dfa7eb5c93044bb28a3bf5400eb8add3a85e Author: Jussi Maki Date: Sat Jul 31 05:57:37 2021 +0000 selftests/bpf: Fix xdp_tx.c prog section name [ Upstream commit 95413846cca37f20000dd095cf6d91f8777129d7 ] The program type cannot be deduced from 'tx' which causes an invalid argument error when trying to load xdp_tx.o using the skeleton. Rename the section name to "xdp" so that libbpf can deduce the type. Signed-off-by: Jussi Maki Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210731055738.16820-7-joamaki@gmail.com Signed-off-by: Sasha Levin commit 63ebc1f1df813ebb40d19449c356480555008166 Author: Roy Chan Date: Mon Jul 19 19:00:22 2021 -0400 drm/amd/display: fix incorrect CM/TF programming sequence in dwb [ Upstream commit 781e1e23131cce56fb557e6ec2260480a6bd08cc ] [How] the programming sequeune was for old asic. the correct programming sequeunce should be similar to the one used in mpc. the fix is copied from the mpc programming sequeunce. Reviewed-by: Anthony Koo Acked-by: Anson Jacob Signed-off-by: Roy Chan Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d763afc4ea2b251217ec87cf4c1e006c9f0aef99 Author: Roy Chan Date: Wed Jul 21 19:33:26 2021 -0400 drm/amd/display: fix missing writeback disablement if plane is removed [ Upstream commit 82367e7f22d085092728f45fd5fbb15e3fb997c0 ] [Why] If the plane has been removed, the writeback disablement logic doesn't run [How] fix the logic order Acked-by: Anson Jacob Signed-off-by: Roy Chan Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 491c8be21993bdb63f36dba3b7004d8bce6a83ff Author: Sanjay R Mehta Date: Tue Aug 3 07:34:56 2021 -0500 thunderbolt: Fix port linking by checking all adapters [ Upstream commit 42716425ad7e1b6529ec61c260c11176841f4b5f ] In tb_switch_default_link_ports(), while linking of ports, only odd-numbered ports (1,3,5..) are considered and even-numbered ports are not considered. AMD host router has lane adapters at 2 and 3 and link ports at adapter 2 is not considered due to which lane bonding gets disabled. Hence added a fix such that all ports are considered during linking of ports. Signed-off-by: Basavaraj Natikar Signed-off-by: Sanjay R Mehta Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit 0f0f1de02b9b1c793cff929b55c42b9fda7680b1 Author: Quanyang Wang Date: Tue Mar 23 10:55:01 2021 +0800 drm: xlnx: zynqmp: release reset to DP controller before accessing DP registers [ Upstream commit a338619bd76011035d462f0f9e8b2f24d7fe5a1e ] When insmod zynqmp-dpsub.ko after rmmod it, system will hang with the error log as below: root@xilinx-zynqmp:~# insmod zynqmp-dpsub.ko [ 88.391289] [drm] Initialized zynqmp-dpsub 1.0.0 20130509 for fd4a0000.display on minor 0 [ 88.529906] Console: switching to colour frame buffer device 128x48 [ 88.549402] zynqmp-dpsub fd4a0000.display: [drm] fb0: zynqmp-dpsubdrm frame buffer device [ 88.571624] zynqmp-dpsub fd4a0000.display: ZynqMP DisplayPort Subsystem driver probed root@xilinx-zynqmp:~# rmmod zynqmp_dpsub [ 94.023404] Console: switching to colour dummy device 80x25 root@xilinx-zynqmp:~# insmod zynqmp-dpsub.ko This is because that in zynqmp_dp_probe it tries to access some DP registers while the DP controller is still in the reset state. When running "rmmod zynqmp_dpsub", zynqmp_dp_reset(dp, true) in zynqmp_dp_phy_exit is called to force the DP controller into the reset state. Then insmod will call zynqmp_dp_probe to program the DP registers, but at this moment the DP controller hasn't been brought out of the reset state yet since the function zynqmp_dp_reset(dp, false) is called later and this will result the system hang. Releasing the reset to DP controller before any read/write operation to it will fix this issue. And for symmetry, move zynqmp_dp_reset() call from zynqmp_dp_phy_exit() to zynqmp_dp_remove(). Signed-off-by: Quanyang Wang Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Signed-off-by: Sasha Levin commit f76f78f9f479ebfdd94ec8c868b39aba7ca4fb0f Author: Quanyang Wang Date: Wed Mar 10 12:59:45 2021 +0800 drm: xlnx: zynqmp_dpsub: Call pm_runtime_get_sync before setting pixel clock [ Upstream commit a19effb6dbe5bd1be77a6d68eba04dba8993ffeb ] The Runtime PM subsystem will force the device "fd4a0000.zynqmp-display" to enter suspend state while booting if the following conditions are met: - the usage counter is zero (pm_runtime_get_sync hasn't been called yet) - no 'active' children (no zynqmp-dp-snd-xx node under dpsub node) - no other device in the same power domain (dpdma node has no "power-domains = <&zynqmp_firmware PD_DP>" property) So there is a scenario as below: 1) DP device enters suspend state <- call zynqmp_gpd_power_off 2) zynqmp_disp_crtc_setup_clock <- configurate register VPLL_FRAC_CFG 3) pm_runtime_get_sync <- call zynqmp_gpd_power_on and clear previous VPLL_FRAC_CFG configuration 4) clk_prepare_enable(disp->pclk) <- enable failed since VPLL_FRAC_CFG configuration is corrupted From above, we can see that pm_runtime_get_sync may clear register VPLL_FRAC_CFG configuration and result the failure of clk enabling. Putting pm_runtime_get_sync at the very beginning of the function zynqmp_disp_crtc_atomic_enable can resolve this issue. Signed-off-by: Quanyang Wang Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Signed-off-by: Sasha Levin commit 127f3610a0e399df5b1149c6dca826a400240a14 Author: Konrad Dybcio Date: Thu Jul 29 00:20:54 2021 +0200 drm/msm/dsi: Fix DSI and DSI PHY regulator config from SDM660 [ Upstream commit 462f7017a6918d152870bfb8852f3c70fd74b296 ] VDDA is not present and the specified load value is wrong. Fix it. Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20210728222057.52641-1-konrad.dybcio@somainline.org Reviewed-by: Dmitry Baryshkov Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 0bbbe3ec67f0360dac572fed91edb9f585d015de Author: David Heidelberg Date: Thu Jul 15 08:09:25 2021 +0200 drm/msm: mdp4: drop vblank get/put from prepare/complete_commit [ Upstream commit 56bd931ae506730c9ab1e4cc4bfefa43fc2d18fa ] msm_atomic is doing vblank get/put's already, currently there no need to duplicate the effort in MDP4 Fix warning: ... WARNING: CPU: 3 PID: 79 at drivers/gpu/drm/drm_vblank.c:1194 drm_vblank_put+0x1cc/0x1d4 ... and multiple vblank time-outs: ... msm 5100000.mdp: vblank time out, crtc=1 ... Tested on Nexus 7 2013 (deb), LTS 5.10.50. Introduced by: 119ecb7fd3b5 ("drm/msm/mdp4: request vblank during modeset") Signed-off-by: David Heidelberg Link: https://lore.kernel.org/r/20210715060925.7880-1-david@ixit.cz Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit ac21cd44c95457ee2904783fc13c78b3c2deca10 Author: Nathan Chancellor Date: Fri Aug 6 12:13:40 2021 -0700 net: ethernet: stmmac: Do not use unreachable() in ipq806x_gmac_probe() [ Upstream commit 4367355dd90942a71641c98c40c74589c9bddf90 ] When compiling with clang in certain configurations, an objtool warning appears: drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.o: warning: objtool: ipq806x_gmac_probe() falls through to next function phy_modes() This happens because the unreachable annotation in the third switch statement is not eliminated. The compiler should know that the first default case would prevent the second and third from being reached as the comment notes but sanitizer options can make it harder for the compiler to reason this out. Help the compiler out by eliminating the unreachable() annotation and unifying the default case error handling so that there is no objtool warning, the meaning of the code stays the same, and there is less duplication. Reported-by: Sami Tolvanen Tested-by: Sami Tolvanen Signed-off-by: Nathan Chancellor Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2b0fa8d5304102db03c7ba89742902219b3eec94 Author: Rajendra Nayak Date: Fri Aug 6 09:59:45 2021 +0100 nvmem: qfprom: Fix up qfprom_disable_fuse_blowing() ordering [ Upstream commit 11c4b3e264d68ba6dcd52d12dbcfd3f564f2f137 ] qfprom_disable_fuse_blowing() disables a bunch of resources, and then does a few register writes in the 'conf' address space. It works perhaps because the resources are needed only for the 'raw' register space writes, and that the 'conf' space allows read/writes regardless. However that makes the code look confusing, so just move the register writes before turning off the resources in the function. Reviewed-by: Douglas Anderson Signed-off-by: Rajendra Nayak Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20210806085947.22682-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 35e5c99b152de914b3f84fa41aa16bac3c699b48 Author: Georgi Djakov Date: Thu Feb 11 21:36:37 2021 +0200 arm64: dts: qcom: sm8250: Fix epss_l3 unit address [ Upstream commit 77b53d65dc1e54321ec841912f06bcb558a079c0 ] The unit address of the epss_l3 node is incorrect and does not match the address of its "reg" property. Let's fix it. Signed-off-by: Georgi Djakov Reviewed-by: Dmitry Baryshkov Reviewed-by: Sibi Sankar Link: https://lore.kernel.org/r/20210211193637.9737-1-georgi.djakov@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 43ccafc91f638e9cf1c50fb49856164f5787cef3 Author: Vinod Koul Date: Mon Mar 8 11:38:17 2021 +0530 arm64: dts: qcom: msm8996: don't use underscore in node name [ Upstream commit 84f3efbe5b4654077608bc2fc027177fe4592321 ] We have underscore (_) in node name leading to warning: arch/arm64/boot/dts/qcom/apq8096-db820c.dt.yaml: clocks: $nodename:0: 'clocks' does not match '^([a-z][a-z0-9\\-]+-bus|bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$' arch/arm64/boot/dts/qcom/apq8096-db820c.dt.yaml: clocks: xo_board: {'type': 'object'} is not allowed for {'compatible': ['fixed-clock'], '#clock-cells': [[0]], 'clock-frequency': [[19200000]], 'clock-output-names': ['xo_board'], 'phandle': [[115]]} Fix this by changing node name to use dash (-) Signed-off-by: Vinod Koul Link: https://lore.kernel.org/r/20210308060826.3074234-10-vkoul@kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f868c2d62a27de5fd7971f635b9cea34261c0c1b Author: Vinod Koul Date: Mon Mar 8 11:38:16 2021 +0530 arm64: dts: qcom: msm8994: don't use underscore in node name [ Upstream commit 8c678beca7ed3fa8a2c6d86f6603bc23400f9ad8 ] We have underscore (_) in node name leading to warning: arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon-cityman.dt.yaml: clocks: xo_board: {'type': 'object'} is not allowed for {'compatible': ['fixed-clock'], '#clock-cells': [[0]], 'clock-frequency': [[19200000]], 'phandle': [[26]]} arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon-cityman.dt.yaml: clocks: sleep_clk: {'type': 'object'} is not allowed for {'compatible': ['fixed-clock'], '#clock-cells': [[0]], 'clock-frequency': [[32768]]} Fix this by changing node name to use dash (-) Signed-off-by: Vinod Koul Link: https://lore.kernel.org/r/20210308060826.3074234-9-vkoul@kernel.org [bjorn: Added clock-output-names to satisfy parent_names] Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit bda9c84edbb3eba9bebb8888bb7b2393235b003c Author: Vinod Koul Date: Mon Mar 8 11:38:18 2021 +0530 arm64: dts: qcom: sdm630: don't use underscore in node name [ Upstream commit 639dfdbecd88ec05bda87b1d5d419afad50af21c ] We have underscore (_) in node name so fix that up as well. Fix this by changing node name to use dash (-) Signed-off-by: Vinod Koul Link: https://lore.kernel.org/r/20210308060826.3074234-11-vkoul@kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit aa16e76c80afecb97dc509e3c48db0f89c0d6ba5 Author: Vinod Koul Date: Mon Mar 8 11:38:26 2021 +0530 arm64: dts: qcom: ipq6018: drop '0x' from unit address [ Upstream commit 1b91b8ef60e9a67141e66af3cca532c00f4605fe ] Nodes need not contain '0x' for the unit address. Drop it to fix the below warning: arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dt.yaml: reserved-memory: 'memory@0x60000' does not match any of the regexes Signed-off-by: Vinod Koul Link: https://lore.kernel.org/r/20210308060826.3074234-19-vkoul@kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit da714a198342c752839045d54d4240cf335cd67a Author: Vinod Koul Date: Mon Mar 8 11:38:25 2021 +0530 arm64: dts: qcom: sdm660: use reg value for memory node [ Upstream commit c81210e38966cfa1c784364e4035081c3227cf5b ] memory node like other node should be node@reg, which is missing in this case, so fix it up arch/arm64/boot/dts/qcom/ipq8074-hk01.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 1073741824, 0, 536870912]]} Signed-off-by: Vinod Koul Link: https://lore.kernel.org/r/20210308060826.3074234-18-vkoul@kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 34e9c56675a81f32d7fcec53087a232f77a39371 Author: Vinod Koul Date: Mon Mar 8 11:38:24 2021 +0530 arm64: dts: qcom: ipq8074: fix pci node reg property [ Upstream commit 52c9887fba71fc8f12d343833fc595c762aac8c7 ] reg property should be array of values, here it is a single array, leading to below warning: arch/arm64/boot/dts/qcom/ipq8074-hk01.dt.yaml: soc: pci@10000000:reg:0: [268435456, 3869, 268439328, 168, 557056, 8192, 269484032, 4096] is too long arch/arm64/boot/dts/qcom/ipq8074-hk01.dt.yaml: soc: pci@10000000:ranges: 'oneOf' conditional failed, one must be fixed: arch/arm64/boot/dts/qcom/ipq8074-hk01.dt.yaml: soc: pci@10000000:ranges: 'oneOf' conditional failed, one must be fixed: [[2164260864, 0, 270532608, 270532608, 0, 1048576, 2181038080, 0, 271581184, 271581184, 0, 13631488]] is not of type 'null' [2164260864, 0, 270532608, 270532608, 0, 1048576, 2181038080, 0, 271581184, 271581184, 0, 13631488] is too long arch/arm64/boot/dts/qcom/ipq8074-hk01.dt.yaml: soc: pci@20000000:reg:0: [536870912, 3869, 536874784, 168, 524288, 8192, 537919488, 4096] is too long arch/arm64/boot/dts/qcom/ipq8074-hk01.dt.yaml: soc: pci@20000000:ranges: 'oneOf' conditional failed, one must be fixed: arch/arm64/boot/dts/qcom/ipq8074-hk01.dt.yaml: soc: pci@20000000:ranges: 'oneOf' conditional failed, one must be fixed: [[2164260864, 0, 538968064, 538968064, 0, 1048576, 2181038080, 0, 540016640, 540016640, 0, 13631488]] is not of type 'null' [2164260864, 0, 538968064, 538968064, 0, 1048576, 2181038080, 0, 540016640, 540016640, 0, 13631488] is too long Signed-off-by: Vinod Koul Link: https://lore.kernel.org/r/20210308060826.3074234-17-vkoul@kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 74287874c91d878e133daecab676bcdb4c9e388f Author: Sebastian Reichel Date: Mon Aug 2 19:23:08 2021 +0200 ARM: dts: imx53-ppd: Fix ACHC entry [ Upstream commit cd7cd5b716d594e27a933c12f026d4f2426d7bf4 ] PPD has only one ACHC device, which effectively is a Kinetis microcontroller. It has one SPI interface used for normal communication. Additionally it's possible to flash the device firmware using NXP's EzPort protocol by correctly driving a second chip select pin and the device reset pin. Signed-off-by: Sebastian Reichel Link: https://lore.kernel.org/r/20210802172309.164365-3-sebastian.reichel@collabora.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6a00decce3a6edc59f659468a6d8f80c313b742c Author: Tony Lindgren Date: Tue Jul 27 13:35:33 2021 +0300 serial: 8250_omap: Handle optional overrun-throttle-ms property [ Upstream commit 1fe0e1fa3209ad8e9124147775bd27b1d9f04bd4 ] Handle optional overrun-throttle-ms property as done for 8250_fsl in commit 6d7f677a2afa ("serial: 8250: Rate limit serial port rx interrupts during input overruns"). This can be used to rate limit the UART interrupts on noisy lines that end up producing messages like the following: ttyS ttyS2: 4 input overrun(s) At least on droid4, the multiplexed USB and UART port is left to UART mode by the bootloader for a debug console, and if a USB charger is connected on boot, we get noise on the UART until the PMIC related drivers for PHY and charger are loaded. With this patch and overrun-throttle-ms = <500> we avoid the extra rx interrupts. Cc: Carl Philipp Klemm Cc: Merlijn Wajer Cc: Pavel Machek Cc: Sebastian Reichel Cc: Vignesh Raghavendra Signed-off-by: Tony Lindgren Link: https://lore.kernel.org/r/20210727103533.51547-2-tony@atomide.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 699c91475847e634ab88d96a199c518d0f38138b Author: AngeloGioacchino Del Regno Date: Thu Jul 29 00:25:11 2021 +0200 arm64: dts: qcom: sdm630: Fix TLMM node and pinctrl configuration [ Upstream commit 36a0d47aee6a8cfd3c6cf4274732d8ef994a25b4 ] Previous pinctrl configuration was wrong. Fix it and clean up how multi-pin states are described. Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20210728222542.54269-9-konrad.dybcio@somainline.org [bjorn: Polished the commit message] Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 310a127178b09af7a66edce236c85706d861d323 Author: AngeloGioacchino Del Regno Date: Thu Jul 29 00:25:04 2021 +0200 arm64: dts: qcom: sdm630: Rewrite memory map [ Upstream commit 26e02c98a9ad63eb21b9be4ac92002f555130d3b ] The memory map was wrong. Fix it. Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20210728222542.54269-2-konrad.dybcio@somainline.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 783be2a942999d3521c505b58157a87063de2c03 Author: Bob Peterson Date: Tue Jun 1 09:41:40 2021 -0500 gfs2: Fix glock recursion in freeze_go_xmote_bh [ Upstream commit 9d9b16054b7d357afde69a027514c695092b0d22 ] We must not call gfs2_consist (which does a file system withdraw) from the freeze glock's freeze_go_xmote_bh function because the withdraw will try to use the freeze glock, thus causing a glock recursion error. This patch changes freeze_go_xmote_bh to call function gfs2_assert_withdraw_delayed instead of gfs2_consist to avoid recursion. Signed-off-by: Bob Peterson Signed-off-by: Sasha Levin commit 4e014ff22e4bca97193bc36fd67c2233422690b6 Author: Evgeny Novikov Date: Wed Jul 28 16:44:32 2021 +0200 media: tegra-cec: Handle errors of clk_prepare_enable() [ Upstream commit 38367073c796a37a61549b1f66a71b3adb03802d ] tegra_cec_probe() and tegra_cec_resume() ignored possible errors of clk_prepare_enable(). The patch fixes this. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Evgeny Novikov Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit c159db240cf27af29f4e4e747c8bd60faa5e34fa Author: Krzysztof Hałasa Date: Mon Jul 26 12:46:28 2021 +0200 media: TDA1997x: fix tda1997x_query_dv_timings() return value [ Upstream commit 7dee1030871a48d4f3c5a74227a4b4188463479a ] Correctly propagate the tda1997x_detect_std error value. Signed-off-by: Krzysztof Hałasa Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit e3a2e20ed5037e668df4522575fd09a2b87263c3 Author: Hans Verkuil Date: Fri Jul 23 10:22:59 2021 +0200 media: v4l2-dv-timings.c: fix wrong condition in two for-loops [ Upstream commit 4108b3e6db31acc4c68133290bbcc87d4db905c9 ] These for-loops should test against v4l2_dv_timings_presets[i].bt.width, not if i < v4l2_dv_timings_presets[i].bt.width. Luckily nothing ever broke, since the smallest width is still a lot higher than the total number of presets, but it is wrong. The last item in the presets array is all 0, so the for-loop must stop when it reaches that sentinel. Signed-off-by: Hans Verkuil Reported-by: Krzysztof Hałasa Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit ac1bcf53e32fe503e0d311af4ae14789c6566210 Author: Umang Jain Date: Fri Jul 23 13:22:33 2021 +0200 media: imx258: Limit the max analogue gain to 480 [ Upstream commit f809665ee75fff3f4ea8907f406a66d380aeb184 ] The range for analog gain mentioned in the datasheet is [0, 480]. The real gain formula mentioned in the datasheet is: Gain = 512 / (512 – X) Hence, values larger than 511 clearly makes no sense. The gain register field is also documented to be of 9-bits in the datasheet. Certainly, it is enough to infer that, the kernel driver currently advertises an arbitrary analog gain max. Fix it by rectifying the value as per the data sheet i.e. 480. Signed-off-by: Umang Jain Reviewed-by: Laurent Pinchart Reviewed-by: Dave Stevenson Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 4cb4967472c878a57a1de6e1f3d582bb9d00acd5 Author: Laurent Pinchart Date: Fri Jul 23 13:22:32 2021 +0200 media: imx258: Rectify mismatch of VTS value [ Upstream commit 51f93add3669f1b1f540de1cf397815afbd4c756 ] The frame_length_lines (0x0340) registers are hard-coded as follows: - 4208x3118 frame_length_lines = 0x0c50 - 2104x1560 frame_length_lines = 0x0638 - 1048x780 frame_length_lines = 0x034c The driver exposes the V4L2_CID_VBLANK control in read-only mode and sets its value to vts_def - height, where vts_def is a mode-dependent value coming from the supported_modes array. It is set using one of the following macros defined in the driver: #define IMX258_VTS_30FPS 0x0c98 #define IMX258_VTS_30FPS_2K 0x0638 #define IMX258_VTS_30FPS_VGA 0x034c There's a clear mismatch in the value for the full resolution mode i.e. IMX258_VTS_30FPS. Fix it by rectifying the macro with the value set for the frame_length_lines register as stated above. Signed-off-by: Laurent Pinchart Signed-off-by: Umang Jain Reviewed-by: Bingbu Cao Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a64e3f1d8a27f6868e01f99f7f21519e46da61fb Author: Pierre-Louis Bossart Date: Mon Aug 2 10:21:50 2021 -0500 ASoC: Intel: update sof_pcm512x quirks [ Upstream commit 22414cade8dfec25ab94df52b3a4f7aa8edb6120 ] The default SOF topology enables SSP capture and DMICs, even though both of these hardware capabilities are not always available in hardware (specific versions of HiFiberry and DMIC kit needed). For the SSP capture, this leads to annoying "SP5-Codec: ASoC: no backend capture" and "streamSSP5-Codec: ASoC: no users capture at close - state 0" errors. Update the quirks to match what the topology needs, which also allows for the ability to remove SSP capture and DMIC support. BugLink: https://github.com/thesofproject/linux/issues/3061 Signed-off-by: Pierre-Louis Bossart Reviewed-by: Guennadi Liakhovetski Link: https://lore.kernel.org/r/20210802152151.15832-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9cf827242033f664d3b6536d8e264a6378ab3a8e Author: Hans de Goede Date: Mon Aug 2 16:24:56 2021 +0200 ASoC: Intel: bytcr_rt5640: Move "Platform Clock" routes to the maps for the matching in-/output [ Upstream commit dccd1dfd0770bfd494b68d1135b4547b2c602c42 ] Move the "Platform Clock" routes for the "Internal Mic" and "Speaker" routes to the intmic_*_map[] / *_spk_map[] arrays. This ensures that these "Platform Clock" routes do not get added when the BYT_RT5640_NO_INTERNAL_MIC_MAP / BYT_RT5640_NO_SPEAKERS quirks are used. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210802142501.991985-2-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f1fb1f6fa17253bf898ae73c39a36ff781f1a6ad Author: Vidya Sagar Date: Wed Jul 28 00:20:55 2021 +0530 arm64: tegra: Fix Tegra194 PCIe EP compatible string [ Upstream commit bf2942a8b7c38e8cc2d5157b4f0323d7f4e5ec71 ] The initialization sequence performed by the generic platform driver pcie-designware-plat.c for a DWC based implementation doesn't work for Tegra194. Tegra194 has a different initialization sequence requirement which can only be satisfied by the Tegra194 specific platform driver pcie-tegra194.c. So, remove the generic compatible string "snps,dw-pcie-ep" from Tegra194's endpoint controller nodes. Signed-off-by: Vidya Sagar Reviewed-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 8fb3d8c151a78c47aff1ab994c57ba785fe6a4f0 Author: Nicolas Ferre Date: Thu Jul 29 16:28:27 2021 +0200 ARM: dts: at91: use the right property for shutdown controller [ Upstream commit 818c4593434e81c9971b8fc278215121622c755e ] The wrong property "atmel,shdwc-debouncer" was used to specify the debounce delay for the shutdown controler. Replace it with the documented and implemented property "debounce-delay-us", as mentioned in v4 driver submission. See: https://lore.kernel.org/r/1458134390-23847-3-git-send-email-nicolas.ferre@atmel.com/ Signed-off-by: Nicolas Ferre Reported-by: Clément Léger Reviewed-by: Claudiu Beznea Link: https://lore.kernel.org/r/20210730172729.28093-1-nicolas.ferre@microchip.com/ Signed-off-by: Sasha Levin commit f710323dcd24ce6209ee767e910ac4a21ffc618c Author: Yufeng Mo Date: Fri Jul 30 10:19:11 2021 +0800 bonding: 3ad: fix the concurrency between __bond_release_one() and bond_3ad_state_machine_handler() [ Upstream commit 220ade77452c15ecb1ab94c3f8aaeb6d033c3582 ] Some time ago, I reported a calltrace issue "did not find a suitable aggregator", please see[1]. After a period of analysis and reproduction, I find that this problem is caused by concurrency. Before the problem occurs, the bond structure is like follows: bond0 - slaver0(eth0) - agg0.lag_ports -> port0 - port1 \ port0 \ slaver1(eth1) - agg1.lag_ports -> NULL \ port1 If we run 'ifenslave bond0 -d eth1', the process is like below: excuting __bond_release_one() | bond_upper_dev_unlink()[step1] | | | | | bond_3ad_lacpdu_recv() | | ->bond_3ad_rx_indication() | | spin_lock_bh() | | ->ad_rx_machine() | | ->__record_pdu()[step2] | | spin_unlock_bh() | | | | bond_3ad_state_machine_handler() | spin_lock_bh() | ->ad_port_selection_logic() | ->try to find free aggregator[step3] | ->try to find suitable aggregator[step4] | ->did not find a suitable aggregator[step5] | spin_unlock_bh() | | | | bond_3ad_unbind_slave() | spin_lock_bh() spin_unlock_bh() step1: already removed slaver1(eth1) from list, but port1 remains step2: receive a lacpdu and update port0 step3: port0 will be removed from agg0.lag_ports. The struct is "agg0.lag_ports -> port1" now, and agg0 is not free. At the same time, slaver1/agg1 has been removed from the list by step1. So we can't find a free aggregator now. step4: can't find suitable aggregator because of step2 step5: cause a calltrace since port->aggregator is NULL To solve this concurrency problem, put bond_upper_dev_unlink() after bond_3ad_unbind_slave(). In this way, we can invalid the port first and skip this port in bond_3ad_state_machine_handler(). This eliminates the situation that the slaver has been removed from the list but the port is still valid. [1]https://lore.kernel.org/netdev/10374.1611947473@famine/ Signed-off-by: Yufeng Mo Acked-by: Jay Vosburgh Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5d008cb7636de3a5962856e6a7eb39d1f7cb9619 Author: Marek Vasut Date: Sun Jun 20 23:24:31 2021 +0200 ARM: dts: stm32: Update AV96 adv7513 node per dtbs_check [ Upstream commit 1e6bc5987a5252948e3411e5a2dbb434fd1ea107 ] Swap reg and reg-names order and drop adi,input-justification and adi,input-style to fix the following dtbs_check warnings: arch/arm/boot/dts/stm32mp157a-dhcor-avenger96.dt.yaml: hdmi-transmitter@3d: adi,input-justification: False schema does not allow ['evenly'] arch/arm/boot/dts/stm32mp157a-dhcor-avenger96.dt.yaml: hdmi-transmitter@3d: adi,input-style: False schema does not allow [[1]] arch/arm/boot/dts/stm32mp157a-dhcor-avenger96.dt.yaml: hdmi-transmitter@3d: reg-names:1: 'edid' was expected arch/arm/boot/dts/stm32mp157a-dhcor-avenger96.dt.yaml: hdmi-transmitter@3d: reg-names:2: 'cec' was expected Signed-off-by: Marek Vasut Cc: Alexandre Torgue Cc: Patrice Chotard Cc: Patrick Delaunay Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit 3142476fa002e366c8a9dbd124618ab263fb7a89 Author: Marek Vasut Date: Thu Jun 10 17:03:06 2021 +0200 ARM: dts: stm32: Set {bitclock,frame}-master phandles on ST DKx [ Upstream commit 8aec45d7884f16cc21d668693c5b88bff8df0f02 ] Fix the following dtbs_check warning: cs42l51@4a: port:endpoint@0:frame-master: True is not of type 'array' cs42l51@4a: port:endpoint@0:bitclock-master: True is not of type 'array' Signed-off-by: Marek Vasut Cc: Alexandre Torgue Cc: Patrice Chotard Cc: Patrick Delaunay Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit 37437a60a93b8b5f2ce760d97d57704ded3bc047 Author: Marek Vasut Date: Thu Jun 10 17:02:41 2021 +0200 ARM: dts: stm32: Set {bitclock,frame}-master phandles on DHCOM SoM [ Upstream commit a79e78c391dc074742c855dc0108a88f781d56a3 ] Fix the following dtbs_check warning: arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dt.yaml: codec@a: port:endpoint@0:frame-master: True is not of type 'array' arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dt.yaml: codec@a: port:endpoint@0:bitclock-master: True is not of type 'array' Signed-off-by: Marek Vasut Cc: Alexandre Torgue Cc: Patrice Chotard Cc: Patrick Delaunay Cc: kernel@dh-electronics.com Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit f4c7c95e3ee5741439cd11bf67b84a7d07e7c1c1 Author: Zhen Lei Date: Thu Jul 22 11:03:52 2021 +0800 workqueue: Fix possible memory leaks in wq_numa_init() [ Upstream commit f728c4a9e8405caae69d4bc1232c54ff57b5d20f ] In error handling branch "if (WARN_ON(node == NUMA_NO_NODE))", the previously allocated memories are not released. Doing this before allocating memory eliminates memory leaks. tj: Note that the condition only occurs when the arch code is pretty broken and the WARN_ON might as well be BUG_ON(). Signed-off-by: Zhen Lei Reviewed-by: Lai Jiangshan Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 6528cc687c888d312bc5599bc9cdb603b3e7eb5a Author: Desmond Cheong Zhi Xi Date: Wed Jul 28 15:51:04 2021 +0800 Bluetooth: skip invalid hci_sync_conn_complete_evt [ Upstream commit 92fe24a7db751b80925214ede43f8d2be792ea7b ] Syzbot reported a corrupted list in kobject_add_internal [1]. This happens when multiple HCI_EV_SYNC_CONN_COMPLETE event packets with status 0 are sent for the same HCI connection. This causes us to register the device more than once which corrupts the kset list. As this is forbidden behavior, we add a check for whether we're trying to process the same HCI_EV_SYNC_CONN_COMPLETE event multiple times for one connection. If that's the case, the event is invalid, so we report an error that the device is misbehaving, and ignore the packet. Link: https://syzkaller.appspot.com/bug?extid=66264bf2fd0476be7e6c [1] Reported-by: syzbot+66264bf2fd0476be7e6c@syzkaller.appspotmail.com Tested-by: syzbot+66264bf2fd0476be7e6c@syzkaller.appspotmail.com Signed-off-by: Desmond Cheong Zhi Xi Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 3b82e4799f539103579e01c46e082fcfe6400567 Author: Andy Shevchenko Date: Tue Jul 27 15:51:30 2021 +0300 ata: sata_dwc_460ex: No need to call phy_exit() befre phy_init() [ Upstream commit 3ad4a31620355358316fa08fcfab37b9d6c33347 ] Last change to device managed APIs cleaned up error path to simple phy_exit() call, which in some cases has been executed with NULL parameter. This per se is not a problem, but rather logical misconception: no need to free resource when it's for sure has not been allocated yet. Fix the driver accordingly. Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210727125130.19977-1-andriy.shevchenko@linux.intel.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 4af60a543ba60239d8931215c7e239c91e42c129 Author: Martynas Pumputis Date: Mon Jul 26 17:20:01 2021 +0200 libbpf: Fix race when pinning maps in parallel [ Upstream commit 043c5bb3c4f43670ab4fea0b847373ab42d25f3e ] When loading in parallel multiple programs which use the same to-be pinned map, it is possible that two instances of the loader will call bpf_object__create_maps() at the same time. If the map doesn't exist when both instances call bpf_object__reuse_map(), then one of the instances will fail with EEXIST when calling bpf_map__pin(). Fix the race by retrying reusing a map if bpf_map__pin() returns EEXIST. The fix is similar to the one in iproute2: e4c4685fd6e4 ("bpf: Fix race condition with map pinning"). Before retrying the pinning, we don't do any special cleaning of an internal map state. The closer code inspection revealed that it's not required: - bpf_object__create_map(): map->inner_map is destroyed after a successful call, map->fd is closed if pinning fails. - bpf_object__populate_internal_map(): created map elements is destroyed upon close(map->fd). - init_map_slots(): slots are freed after their initialization. Signed-off-by: Martynas Pumputis Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210726152001.34845-1-m@lambda.lt Signed-off-by: Sasha Levin commit 874d5aa06ce2aac1085d3bf2868b0bc57afd5856 Author: Juhee Kang Date: Tue Jul 27 04:10:55 2021 +0000 samples: bpf: Fix tracex7 error raised on the missing argument [ Upstream commit 7d07006f05922b95518be403f08ef8437b67aa32 ] The current behavior of 'tracex7' doesn't consist with other bpf samples tracex{1..6}. Other samples do not require any argument to run with, but tracex7 should be run with btrfs device argument. (it should be executed with test_override_return.sh) Currently, tracex7 doesn't have any description about how to run this program and raises an unexpected error. And this result might be confusing since users might not have a hunch about how to run this program. // Current behavior # ./tracex7 sh: 1: Syntax error: word unexpected (expecting ")") // Fixed behavior # ./tracex7 ERROR: Run with the btrfs device argument! In order to fix this error, this commit adds logic to report a message and exit when running this program with a missing argument. Additionally in test_override_return.sh, there is a problem with multiple directory(tmpmnt) creation. So in this commit adds a line with removing the directory with every execution. Signed-off-by: Juhee Kang Signed-off-by: Andrii Nakryiko Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20210727041056.23455-1-claudiajkang@gmail.com Signed-off-by: Sasha Levin commit 035f83b5abd35169e853190ff5be7bf49cfa3720 Author: Christophe JAILLET Date: Wed Jul 21 10:45:11 2021 +0200 staging: ks7010: Fix the initialization of the 'sleep_status' structure [ Upstream commit 56315e55119c0ea57e142b6efb7c31208628ad86 ] 'sleep_status' has 3 atomic_t members. Initialize the 3 of them instead of initializing only 2 of them and setting 0 twice to the same variable. Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/d2e52a33a9beab41879551d0ae2fdfc99970adab.1626856991.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d0a8ef04c22043c88b2ac0628d0f3e2dcca4b8cf Author: Greg Kroah-Hartman Date: Mon Jul 26 15:07:17 2021 +0200 serial: 8250_pci: make setup_port() parameters explicitly unsigned [ Upstream commit 3a96e97ab4e835078e6f27b7e1c0947814df3841 ] The bar and offset parameters to setup_port() are used in pointer math, and while it would be very difficult to get them to wrap as a negative number, just be "safe" and make them unsigned so that static checkers do not trip over them unintentionally. Cc: Jiri Slaby Reported-by: Jordy Zomer Link: https://lore.kernel.org/r/20210726130717.2052096-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2603740df8b2f8d443a4257a37db12cb1264e24f Author: Jiri Slaby Date: Fri Jul 23 09:43:11 2021 +0200 hvsi: don't panic on tty_register_driver failure [ Upstream commit 7ccbdcc4d08a6d7041e4849219bbb12ffa45db4c ] The alloc_tty_driver failure is handled gracefully in hvsi_init. But tty_register_driver is not. panic is called if that one fails. So handle the failure of tty_register_driver gracefully too. This will keep at least the console functional as it was enabled earlier by console_initcall in hvsi_console_init. Instead of shooting down the whole system. This means, we disable interrupts and restore hvsi_wait back to poll_for_state(). Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20210723074317.32690-3-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit dd3307a8b3838f76632d5d5c083f164da4dbbd3d Author: Jiri Slaby Date: Fri Jul 23 09:43:10 2021 +0200 xtensa: ISS: don't panic in rs_init [ Upstream commit 23411c720052ad860b3e579ee4873511e367130a ] While alloc_tty_driver failure in rs_init would mean we have much bigger problem, there is no reason to panic when tty_register_driver fails there. It can fail for various reasons. So handle the failure gracefully. Actually handle them both while at it. This will make at least the console functional as it was enabled earlier by console_initcall in iss_console_init. Instead of shooting down the whole system. We move tty_port_init() after alloc_tty_driver(), so that we don't need to destroy the port in case the latter function fails. Cc: Chris Zankel Cc: Max Filippov Cc: linux-xtensa@linux-xtensa.org Acked-by: Max Filippov Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20210723074317.32690-2-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b763d2e7d45c1d067e560fca8353997fc2e3da88 Author: Maciej W. Rozycki Date: Sat Jun 26 06:11:51 2021 +0200 serial: 8250: Define RX trigger levels for OxSemi 950 devices [ Upstream commit d7aff291d069c4418285f3c8ee27b0ff67ce5998 ] Oxford Semiconductor 950 serial port devices have a 128-byte FIFO and in the enhanced (650) mode, which we select in `autoconfig_has_efr' with the ECB bit set in the EFR register, they support the receive interrupt trigger level selectable with FCR bits 7:6 from the set of 16, 32, 112, 120. This applies to the original OX16C950 discrete UART[1] as well as 950 cores embedded into more complex devices. For these devices we set the default to 112, which sets an excessively high level of 112 or 7/8 of the FIFO capacity, unlike with other port types where we choose at most 1/2 of their respective FIFO capacities. Additionally we don't make the trigger level configurable. Consequently frequent input overruns happen with high bit rates where hardware flow control cannot be used (e.g. terminal applications) even with otherwise highly-performant systems. Lower the default receive interrupt trigger level to 32 then, and make it configurable. Document the trigger levels along with other port types, including the set of 16, 32, 64, 112 for the transmit interrupt as well[2]. References: [1] "OX16C950 rev B High Performance UART with 128 byte FIFOs", Oxford Semiconductor, Inc., DS-0031, Sep 05, Table 10: "Receiver Trigger Levels", p. 22 [2] same, Table 9: "Transmit Interrupt Trigger Levels", p. 22 Signed-off-by: Maciej W. Rozycki Link: https://lore.kernel.org/r/alpine.DEB.2.21.2106260608480.37803@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 973c57c5e649481a7444ec79f29b213115cb8c2c Author: Niklas Schnelle Date: Thu Jul 8 14:55:42 2021 +0200 s390: make PCI mio support a machine flag [ Upstream commit 3322ba0d7bea1e24ae464418626f6a15b69533ab ] Kernel support for the newer PCI mio instructions can be toggled off with the pci=nomio command line option which needs to integrate with common code PCI option parsing. However this option then toggles static branches which can't be toggled yet in an early_param() call. Thus commit 9964f396f1d0 ("s390: fix setting of mio addressing control") moved toggling the static branches to the PCI init routine. With this setup however we can't check for mio support outside the PCI code during early boot, i.e. before switching the static branches, which we need to be able to export this as an ELF HWCAP. Improve on this by turning mio availability into a machine flag that gets initially set based on CONFIG_PCI and the facility bit and gets toggled off if pci=nomio is found during PCI option parsing allowing simple access to this machine flag after early init. Reviewed-by: Heiko Carstens Signed-off-by: Niklas Schnelle Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 77d62f2bcc7fadf2764c792d31a94cb80943d031 Author: Heiko Carstens Date: Mon Jul 12 19:26:01 2021 +0200 s390/jump_label: print real address in a case of a jump label bug [ Upstream commit 5492886c14744d239e87f1b0b774b5a341e755cc ] In case of a jump label print the real address of the piece of code where a mismatch was detected. This is right before the system panics, so there is nothing revealed. Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 863d2eb2f726add454283dfd935c9743be71aa51 Author: Gustavo A. R. Silva Date: Mon Jul 26 14:25:11 2021 -0500 flow_dissector: Fix out-of-bounds warnings [ Upstream commit 323e0cb473e2a8706ff162b6b4f4fa16023c9ba7 ] Fix the following out-of-bounds warnings: net/core/flow_dissector.c: In function '__skb_flow_dissect': >> net/core/flow_dissector.c:1104:4: warning: 'memcpy' offset [24, 39] from the object at '' is out of the bounds of referenced subobject 'saddr' with type 'struct in6_addr' at offset 8 [-Warray-bounds] 1104 | memcpy(&key_addrs->v6addrs, &iph->saddr, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1105 | sizeof(key_addrs->v6addrs)); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from include/linux/ipv6.h:5, from net/core/flow_dissector.c:6: include/uapi/linux/ipv6.h:133:18: note: subobject 'saddr' declared here 133 | struct in6_addr saddr; | ^~~~~ >> net/core/flow_dissector.c:1059:4: warning: 'memcpy' offset [16, 19] from the object at '' is out of the bounds of referenced subobject 'saddr' with type 'unsigned int' at offset 12 [-Warray-bounds] 1059 | memcpy(&key_addrs->v4addrs, &iph->saddr, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1060 | sizeof(key_addrs->v4addrs)); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from include/linux/ip.h:17, from net/core/flow_dissector.c:5: include/uapi/linux/ip.h:103:9: note: subobject 'saddr' declared here 103 | __be32 saddr; | ^~~~~ The problem is that the original code is trying to copy data into a couple of struct members adjacent to each other in a single call to memcpy(). So, the compiler legitimately complains about it. As these are just a couple of members, fix this by copying each one of them in separate calls to memcpy(). This helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). Link: https://github.com/KSPP/linux/issues/109 Reported-by: kernel test robot Link: https://lore.kernel.org/lkml/d5ae2e65-1f18-2577-246f-bada7eee6ccd@intel.com/ Signed-off-by: Gustavo A. R. Silva Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 64583448c231df5dd809de712322c42de3680cfb Author: Gustavo A. R. Silva Date: Mon Jul 26 14:52:51 2021 -0500 ipv4: ip_output.c: Fix out-of-bounds warning in ip_copy_addrs() [ Upstream commit 6321c7acb82872ef6576c520b0e178eaad3a25c0 ] Fix the following out-of-bounds warning: In function 'ip_copy_addrs', inlined from '__ip_queue_xmit' at net/ipv4/ip_output.c:517:2: net/ipv4/ip_output.c:449:2: warning: 'memcpy' offset [40, 43] from the object at 'fl' is out of the bounds of referenced subobject 'saddr' with type 'unsigned int' at offset 36 [-Warray-bounds] 449 | memcpy(&iph->saddr, &fl4->saddr, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 450 | sizeof(fl4->saddr) + sizeof(fl4->daddr)); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The problem is that the original code is trying to copy data into a couple of struct members adjacent to each other in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &iph->saddr and &fl4->saddr. As these are just a couple of struct members, fix this by using direct assignments, instead of memcpy(). This helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). Link: https://github.com/KSPP/linux/issues/109 Reported-by: kernel test robot Link: https://lore.kernel.org/lkml/d5ae2e65-1f18-2577-246f-bada7eee6ccd@intel.com/ Signed-off-by: Gustavo A. R. Silva Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit bcc61adefd7845fa89d6dd0514a0ee8b545f85ef Author: Zheyu Ma Date: Mon Jul 26 10:03:55 2021 +0000 video: fbdev: riva: Error out if 'pixclock' equals zero [ Upstream commit f92763cb0feba247e0939ed137b495601fd072a5 ] The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of 'pixclock', it may cause divide error. Fix this by checking whether 'pixclock' is zero first. The following log reveals it: [ 33.396850] divide error: 0000 [#1] PREEMPT SMP KASAN PTI [ 33.396864] CPU: 5 PID: 11754 Comm: i740 Not tainted 5.14.0-rc2-00513-gac532c9bbcfb-dirty #222 [ 33.396883] RIP: 0010:riva_load_video_mode+0x417/0xf70 [ 33.396969] Call Trace: [ 33.396973] ? debug_smp_processor_id+0x1c/0x20 [ 33.396984] ? tick_nohz_tick_stopped+0x1a/0x90 [ 33.396996] ? rivafb_copyarea+0x3c0/0x3c0 [ 33.397003] ? wake_up_klogd.part.0+0x99/0xd0 [ 33.397014] ? vprintk_emit+0x110/0x4b0 [ 33.397024] ? vprintk_default+0x26/0x30 [ 33.397033] ? vprintk+0x9c/0x1f0 [ 33.397041] ? printk+0xba/0xed [ 33.397054] ? record_print_text.cold+0x16/0x16 [ 33.397063] ? __kasan_check_read+0x11/0x20 [ 33.397074] ? profile_tick+0xc0/0x100 [ 33.397084] ? __sanitizer_cov_trace_const_cmp4+0x24/0x80 [ 33.397094] ? riva_set_rop_solid+0x2a0/0x2a0 [ 33.397102] rivafb_set_par+0xbe/0x610 [ 33.397111] ? riva_set_rop_solid+0x2a0/0x2a0 [ 33.397119] fb_set_var+0x5bf/0xeb0 [ 33.397127] ? fb_blank+0x1a0/0x1a0 [ 33.397134] ? lock_acquire+0x1ef/0x530 [ 33.397143] ? lock_release+0x810/0x810 [ 33.397151] ? lock_is_held_type+0x100/0x140 [ 33.397159] ? ___might_sleep+0x1ee/0x2d0 [ 33.397170] ? __mutex_lock+0x620/0x1190 [ 33.397180] ? trace_hardirqs_on+0x6a/0x1c0 [ 33.397190] do_fb_ioctl+0x31e/0x700 Signed-off-by: Zheyu Ma Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/1627293835-17441-4-git-send-email-zheyuma97@gmail.com Signed-off-by: Sasha Levin commit 63abc0eb8af54cf24df2bad768bab4dd561c2999 Author: Zheyu Ma Date: Mon Jul 26 10:03:54 2021 +0000 video: fbdev: kyro: Error out if 'pixclock' equals zero [ Upstream commit 1520b4b7ba964f8eec2e7dd14c571d50de3e5191 ] The userspace program could pass any values to the driver through ioctl() interface. if the driver doesn't check the value of 'pixclock', it may cause divide error because the value of 'lineclock' and 'frameclock' will be zero. Fix this by checking whether 'pixclock' is zero in kyrofb_check_var(). The following log reveals it: [ 103.073930] divide error: 0000 [#1] PREEMPT SMP KASAN PTI [ 103.073942] CPU: 4 PID: 12483 Comm: syz-executor Not tainted 5.14.0-rc2-00478-g2734d6c1b1a0-dirty #118 [ 103.073959] RIP: 0010:kyrofb_set_par+0x316/0xc80 [ 103.074045] Call Trace: [ 103.074048] ? ___might_sleep+0x1ee/0x2d0 [ 103.074060] ? kyrofb_ioctl+0x330/0x330 [ 103.074069] fb_set_var+0x5bf/0xeb0 [ 103.074078] ? fb_blank+0x1a0/0x1a0 [ 103.074085] ? lock_acquire+0x3bd/0x530 [ 103.074094] ? lock_release+0x810/0x810 [ 103.074103] ? ___might_sleep+0x1ee/0x2d0 [ 103.074114] ? __mutex_lock+0x620/0x1190 [ 103.074126] ? trace_hardirqs_on+0x6a/0x1c0 [ 103.074137] do_fb_ioctl+0x31e/0x700 [ 103.074144] ? fb_getput_cmap+0x280/0x280 [ 103.074152] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074162] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074171] ? __sanitizer_cov_trace_switch+0x67/0xf0 [ 103.074181] ? __sanitizer_cov_trace_const_cmp2+0x20/0x80 [ 103.074191] ? do_vfs_ioctl+0x14b/0x16c0 [ 103.074199] ? vfs_fileattr_set+0xb60/0xb60 [ 103.074207] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074216] ? lock_release+0x483/0x810 [ 103.074224] ? __fget_files+0x217/0x3d0 [ 103.074234] ? __fget_files+0x239/0x3d0 [ 103.074243] ? do_fb_ioctl+0x700/0x700 [ 103.074250] fb_ioctl+0xe6/0x130 Signed-off-by: Zheyu Ma Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/1627293835-17441-3-git-send-email-zheyuma97@gmail.com Signed-off-by: Sasha Levin commit 6a8dcd2ffb4126214107d77fdc0361fab4b2acfa Author: Zheyu Ma Date: Mon Jul 26 10:03:53 2021 +0000 video: fbdev: asiliantfb: Error out if 'pixclock' equals zero [ Upstream commit b36b242d4b8ea178f7fd038965e3cac7f30c3f09 ] The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of 'pixclock', it may cause divide error. Fix this by checking whether 'pixclock' is zero first. The following log reveals it: [ 43.861711] divide error: 0000 [#1] PREEMPT SMP KASAN PTI [ 43.861737] CPU: 2 PID: 11764 Comm: i740 Not tainted 5.14.0-rc2-00513-gac532c9bbcfb-dirty #224 [ 43.861756] RIP: 0010:asiliantfb_check_var+0x4e/0x730 [ 43.861843] Call Trace: [ 43.861848] ? asiliantfb_remove+0x190/0x190 [ 43.861858] fb_set_var+0x2e4/0xeb0 [ 43.861866] ? fb_blank+0x1a0/0x1a0 [ 43.861873] ? lock_acquire+0x1ef/0x530 [ 43.861884] ? lock_release+0x810/0x810 [ 43.861892] ? lock_is_held_type+0x100/0x140 [ 43.861903] ? ___might_sleep+0x1ee/0x2d0 [ 43.861914] ? __mutex_lock+0x620/0x1190 [ 43.861921] ? do_fb_ioctl+0x313/0x700 [ 43.861929] ? mutex_lock_io_nested+0xfa0/0xfa0 [ 43.861936] ? __this_cpu_preempt_check+0x1d/0x30 [ 43.861944] ? _raw_spin_unlock_irqrestore+0x46/0x60 [ 43.861952] ? lockdep_hardirqs_on+0x59/0x100 [ 43.861959] ? _raw_spin_unlock_irqrestore+0x46/0x60 [ 43.861967] ? trace_hardirqs_on+0x6a/0x1c0 [ 43.861978] do_fb_ioctl+0x31e/0x700 Signed-off-by: Zheyu Ma Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/1627293835-17441-2-git-send-email-zheyuma97@gmail.com Signed-off-by: Sasha Levin commit 3740418ccde89fe26057fad3f31ecb1730100461 Author: Jernej Skrabec Date: Thu Jul 22 18:12:18 2021 +0200 arm64: dts: allwinner: h6: tanix-tx6: Fix regulator node names [ Upstream commit 7ab1f6539762946de06ca14d7401ae123821bc40 ] Regulator node names don't reflect class of the device. Fix that by prefixing names with "regulator-". Signed-off-by: Jernej Skrabec Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20210722161220.51181-2-jernej.skrabec@gmail.com Signed-off-by: Sasha Levin commit be2e11b9f8fab49da85a3d79a34f4436c60510df Author: Geert Uytterhoeven Date: Wed Jul 14 11:48:06 2021 +0200 drm/bridge: nwl-dsi: Avoid potential multiplication overflow on 32-bit [ Upstream commit 47956bc86ee4e8530cac386a04f62a6095f7afbe ] As nwl_dsi.lanes is u32, and NSEC_PER_SEC is 1000000000L, the second multiplication in dsi->lanes * 8 * NSEC_PER_SEC will overflow on a 32-bit platform. Fix this by making the constant unsigned long long, forcing 64-bit arithmetic. As iMX8 is arm64, this driver is currently used on 64-bit platforms only, where long is 64-bit, so this cannot happen. But the issue will start to happen when the driver is reused for a 32-bit SoC (e.g. i.MX7ULP), or when code is copied for a new driver. Signed-off-by: Geert Uytterhoeven Reviewed-by: Fabio Estevam Reviewed-by: Laurent Pinchart Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/ebb82941a86b4e35c4fcfb1ef5a5cfad7c1fceab.1626255956.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 6a3564739b9f9f0c8df4c0eab3ce888a04e967a4 Author: Johan Almbladh Date: Wed Jul 21 12:38:22 2021 +0200 bpf/tests: Do not PASS tests without actually testing the result [ Upstream commit 2b7e9f25e590726cca76700ebdb10e92a7a72ca1 ] Each test case can have a set of sub-tests, where each sub-test can run the cBPF/eBPF test snippet with its own data_size and expected result. Before, the end of the sub-test array was indicated by both data_size and result being zero. However, most or all of the internal eBPF tests has a data_size of zero already. When such a test also had an expected value of zero, the test was never run but reported as PASS anyway. Now the test runner always runs the first sub-test, regardless of the data_size and result values. The sub-test array zero-termination only applies for any additional sub-tests. There are other ways fix it of course, but this solution at least removes the surprise of eBPF tests with a zero result always succeeding. Signed-off-by: Johan Almbladh Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210721103822.3755111-1-johan.almbladh@anyfinetworks.com Signed-off-by: Sasha Levin commit 99121dec14b0bbdc37709da95d8971f188ee9c0f Author: Johan Almbladh Date: Wed Jul 21 12:40:58 2021 +0200 bpf/tests: Fix copy-and-paste error in double word test [ Upstream commit ae7f47041d928b1a2f28717d095b4153c63cbf6a ] This test now operates on DW as stated instead of W, which was already covered by another test. Signed-off-by: Johan Almbladh Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210721104058.3755254-1-johan.almbladh@anyfinetworks.com Signed-off-by: Sasha Levin commit 6f51f4241253974a6a147daecd5c20beb7450330 Author: Anson Jacob Date: Tue Jul 20 11:00:44 2021 -0400 drm/amd/amdgpu: Update debugfs link_settings output link_rate field in hex [ Upstream commit 1a394b3c3de2577f200cb623c52a5c2b82805cec ] link_rate is updated via debugfs using hex values, set it to output in hex as well. eg: Resolution: 1920x1080@144Hz cat /sys/kernel/debug/dri/0/DP-1/link_settings Current: 4 0x14 0 Verified: 4 0x1e 0 Reported: 4 0x1e 16 Preferred: 0 0x0 0 echo "4 0x1e" > /sys/kernel/debug/dri/0/DP-1/link_settings cat /sys/kernel/debug/dri/0/DP-1/link_settings Current: 4 0x1e 0 Verified: 4 0x1e 0 Reported: 4 0x1e 16 Preferred: 4 0x1e 0 Signed-off-by: Anson Jacob Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a5999d18a8d8c4c767c60d67fe6a6fe51b9a203d Author: Oak Zeng Date: Wed Jul 14 09:50:37 2021 -0500 drm/amdgpu: Fix a printing message [ Upstream commit 95f71f12aa45d65b7f2ccab95569795edffd379a ] The printing message "PSP loading VCN firmware" is mis-leading because people might think driver is loading VCN firmware. Actually when this message is printed, driver is just preparing some VCN ucode, not loading VCN firmware yet. The actual VCN firmware loading will be in the PSP block hw_init. Fix the printing message Signed-off-by: Oak Zeng Reviewed-by: Christian Konig Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5b3a45eedd27a5e3fac887fa6ad486f44723a4d9 Author: Arnd Bergmann Date: Thu Jul 22 16:28:59 2021 +0200 ethtool: improve compat ioctl handling [ Upstream commit dd98d2895de6485c884a9cb42de69fed02826fa4 ] The ethtool compat ioctl handling is hidden away in net/socket.c, which introduces a couple of minor oddities: - The implementation may end up diverging, as seen in the RXNFC extension in commit 84a1d9c48200 ("net: ethtool: extend RXNFC API to support RSS spreading of filter matches") that does not work in compat mode. - Most architectures do not need the compat handling at all because u64 and compat_u64 have the same alignment. - On x86, the conversion is done for both x32 and i386 user space, but it's actually wrong to do it for x32 and cannot work there. - On 32-bit Arm, it never worked for compat oabi user space, since that needs to do the same conversion but does not. - It would be nice to get rid of both compat_alloc_user_space() and copy_in_user() throughout the kernel. None of these actually seems to be a serious problem that real users are likely to encounter, but fixing all of them actually leads to code that is both shorter and more readable. Signed-off-by: Arnd Bergmann Reviewed-by: Christoph Hellwig Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 52bb703f71d37d52c4c6dbb216c213c9ab79300e Author: Niklas Söderlund Date: Thu Jul 22 13:25:02 2021 +0200 nfp: fix return statement in nfp_net_parse_meta() [ Upstream commit 4431531c482a2c05126caaa9fcc5053a4a5c495b ] The return type of the function is bool and while NULL do evaluate to false it's not very nice, fix this by explicitly returning false. There is no functional change. Signed-off-by: Niklas Söderlund Signed-off-by: Louis Peens Signed-off-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 23e5fb6475897f3ad380781883ae6d5440daa8b6 Author: Yang Yingliang Date: Thu Jun 17 09:23:29 2021 +0200 media: atomisp: pci: fix error return code in atomisp_pci_probe() [ Upstream commit d14e272958bdfdc40dcafb827d24ba6fdafa9d52 ] If init_atomisp_wdts() fails, atomisp_pci_probe() need return error code. Link: https://lore.kernel.org/linux-media/20210617072329.1233662-1-yangyingliang@huawei.com Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit e5cecb9105d45ad7955e202e048441920595d78b Author: Dinghao Liu Date: Thu Apr 8 10:18:43 2021 +0200 media: atomisp: Fix runtime PM imbalance in atomisp_pci_probe [ Upstream commit 672fe1cf145ab9978c62eb827d6a16aa6b63994b ] When hmm_pool_register() fails, a pairing PM usage counter increment is needed to keep the counter balanced. It's the same for the following error paths. Link: https://lore.kernel.org/linux-media/20210408081850.24278-1-dinghao.liu@zju.edu.cn Signed-off-by: Dinghao Liu Acked-by: Andy Shevchenko Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 9a85b9e37601df890b4f668c413f731c4ba4a215 Author: Evgeny Novikov Date: Sat Jul 10 14:04:32 2021 +0200 media: platform: stm32: unprepare clocks at handling errors in probe [ Upstream commit 055d2db28ec2fa3ab5c527c5604f1b32b89fa13a ] stm32_cec_probe() did not unprepare clocks on error handling paths. The patch fixes that. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Evgeny Novikov Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit c6e5eebd95406f08298b80543323b7e32e45f58f Author: Ezequiel Garcia Date: Mon Jul 19 22:52:33 2021 +0200 media: hantro: vp8: Move noisy WARN_ON to vpu_debug [ Upstream commit 6ad61a7847da09b6261824accb539d05bcdfef65 ] When the VP8 decoders can't find a reference frame, the driver falls back to the current output frame. This will probably produce some undesirable results, leading to frame corruption, but shouldn't cause noisy warnings. Signed-off-by: Ezequiel Garcia Acked-by: Nicolas Dufresne Tested-by: Alex Bee Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit f462a39eb8334b52e332cc0cbffb705660b7d87b Author: Oliver Logush Date: Wed Jun 23 15:04:04 2021 -0400 drm/amd/display: Fix timer_per_pixel unit error [ Upstream commit 23e55639b87fb16a9f0f66032ecb57060df6c46c ] [why] The units of the time_per_pixel variable were incorrect, this had to be changed for the code to properly function. [how] The change was very straightforward, only required one line of code to be changed where the calculation was done. Acked-by: Rodrigo Siqueira Signed-off-by: Oliver Logush Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b4f5c9454dfcfee9393f547932eff81a2d9d50bc Author: Shuah Khan Date: Wed Jul 7 21:18:27 2021 -0600 selftests: firmware: Fix ignored return val of asprintf() warn [ Upstream commit fe968ca2cac91888310b143a483123c84906e3fc ] Fix the following ingonred return val of asprintf() warn during build: cc -Wall -O2 fw_namespace.c -o ../tools/testing/selftests/firmware/fw_namespace fw_namespace.c: In function ‘main’: fw_namespace.c:132:2: warning: ignoring return value of ‘asprintf’ declared with attribute ‘warn_unused_result’ [-Wunused-result] 132 | asprintf(&fw_path, "/lib/firmware/%s", fw_name); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Shuah Khan Link: https://lore.kernel.org/r/20210708031827.51293-1-skhan@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e944a221262e9e9f445ce88f79886476d8baec16 Author: Laurentiu Tudor Date: Thu Jul 15 17:07:18 2021 +0300 bus: fsl-mc: fix mmio base address for child DPRCs [ Upstream commit 8990f96a012f42543005b07d9e482694192e9309 ] Some versions of the MC firmware wrongly report 0 for register base address of the DPMCP associated with child DPRC objects thus rendering them unusable. This is particularly troublesome in ACPI boot scenarios where the legacy way of extracting this base address from the device tree does not apply. Given that DPMCPs share the same base address, workaround this by using the base address extracted from the root DPRC container. Signed-off-by: Laurentiu Tudor Link: https://lore.kernel.org/r/20210715140718.8513-8-laurentiu.tudor@nxp.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 165c55af5f5f748ffa05b20b6896cef349e16a37 Author: Zheyu Ma Date: Wed Jul 14 05:53:23 2021 +0000 tty: serial: jsm: hold port lock when reporting modem line changes [ Upstream commit 240e126c28df084222f0b661321e8e3ecb0d232e ] uart_handle_dcd_change() requires a port lock to be held and will emit a warning when lockdep is enabled. Held corresponding lock to fix the following warnings. [ 132.528648] WARNING: CPU: 5 PID: 11600 at drivers/tty/serial/serial_core.c:3046 uart_handle_dcd_change+0xf4/0x120 [ 132.530482] Modules linked in: [ 132.531050] CPU: 5 PID: 11600 Comm: jsm Not tainted 5.14.0-rc1-00003-g7fef2edf7cc7-dirty #31 [ 132.535268] RIP: 0010:uart_handle_dcd_change+0xf4/0x120 [ 132.557100] Call Trace: [ 132.557562] ? __free_pages+0x83/0xb0 [ 132.558213] neo_parse_modem+0x156/0x220 [ 132.558897] neo_param+0x399/0x840 [ 132.559495] jsm_tty_open+0x12f/0x2d0 [ 132.560131] uart_startup.part.18+0x153/0x340 [ 132.560888] ? lock_is_held_type+0xe9/0x140 [ 132.561660] uart_port_activate+0x7f/0xe0 [ 132.562351] ? uart_startup.part.18+0x340/0x340 [ 132.563003] tty_port_open+0x8d/0xf0 [ 132.563523] ? uart_set_options+0x1e0/0x1e0 [ 132.564125] uart_open+0x24/0x40 [ 132.564604] tty_open+0x15c/0x630 Signed-off-by: Zheyu Ma Link: https://lore.kernel.org/r/1626242003-3809-1-git-send-email-zheyuma97@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 642639bb8d42df1df445d65ccd5be0e08cf1866f Author: Geert Uytterhoeven Date: Wed Jul 14 12:13:46 2021 +0200 staging: board: Fix uninitialized spinlock when attaching genpd [ Upstream commit df00609821bf17f50a75a446266d19adb8339d84 ] On Armadillo-800-EVA with CONFIG_DEBUG_SPINLOCK=y: BUG: spinlock bad magic on CPU#0, swapper/1 lock: lcdc0_device+0x10c/0x308, .magic: 00000000, .owner: /-1, .owner_cpu: 0 CPU: 0 PID: 1 Comm: swapper Not tainted 5.11.0-rc5-armadillo-00036-gbbca04be7a80-dirty #287 Hardware name: Generic R8A7740 (Flattened Device Tree) [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (do_raw_spin_lock+0x20/0x94) [] (do_raw_spin_lock) from [] (dev_pm_get_subsys_data+0x8c/0x11c) [] (dev_pm_get_subsys_data) from [] (genpd_add_device+0x78/0x2b8) [] (genpd_add_device) from [] (of_genpd_add_device+0x34/0x4c) [] (of_genpd_add_device) from [] (board_staging_register_device+0x11c/0x148) [] (board_staging_register_device) from [] (board_staging_register_devices+0x24/0x28) of_genpd_add_device() is called before platform_device_register(), as it needs to attach the genpd before the device is probed. But the spinlock is only initialized when the device is registered. Fix this by open-coding the spinlock initialization, cfr. device_pm_init_common() in the internal drivers/base code, and in the SuperH early platform code. Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/57783ece7ddae55f2bda2f59f452180bff744ea0.1626257398.git.geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 03f4492dbff3d7d8b01d9245ddbb721d8181fca8 Author: Jack Pham Date: Tue Jul 20 01:09:07 2021 -0700 usb: gadget: composite: Allow bMaxPower=0 if self-powered [ Upstream commit bcacbf06c891374e7fdd7b72d11cda03b0269b43 ] Currently the composite driver encodes the MaxPower field of the configuration descriptor by reading the c->MaxPower of the usb_configuration only if it is non-zero, otherwise it falls back to using the value hard-coded in CONFIG_USB_GADGET_VBUS_DRAW. However, there are cases when a configuration must explicitly set bMaxPower to 0, particularly if its bmAttributes also has the Self-Powered bit set, which is a valid combination. This is specifically called out in the USB PD specification section 9.1, in which a PDUSB device "shall report zero in the bMaxPower field after negotiating a mutually agreeable Contract", and also verified by the USB Type-C Functional Test TD.4.10.2 Sink Power Precedence Test. The fix allows the c->MaxPower to be used for encoding the bMaxPower even if it is 0, if the self-powered bit is also set. An example usage of this would be for a ConfigFS gadget to be dynamically updated by userspace when the Type-C connection is determined to be operating in Power Delivery mode. Co-developed-by: Ronak Vijay Raheja Acked-by: Felipe Balbi Signed-off-by: Ronak Vijay Raheja Signed-off-by: Jack Pham Link: https://lore.kernel.org/r/20210720080907.30292-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5534de13b6dc23f890fad9194bacf5da05248a61 Author: Evgeny Novikov Date: Thu Jul 8 11:30:56 2021 +0300 USB: EHCI: ehci-mv: improve error handling in mv_ehci_enable() [ Upstream commit 61136a12cbed234374ec6f588af57c580b20b772 ] mv_ehci_enable() did not disable and unprepare clocks in case of failures of phy_init(). Besides, it did not take into account failures of ehci_clock_enable() (in effect, failures of clk_prepare_enable()). The patch fixes both issues and gets rid of redundant wrappers around clk_prepare_enable() and clk_disable_unprepare() to simplify this a bit. Found by Linux Driver Verification project (linuxtesting.org). Acked-by: Alan Stern Signed-off-by: Evgeny Novikov Link: https://lore.kernel.org/r/20210708083056.21543-1-novikov@ispras.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b2b8137ec9205900c4608f7c9e6667d8626ed472 Author: Maciej Żenczykowski Date: Thu Jul 1 04:48:34 2021 -0700 usb: gadget: u_ether: fix a potential null pointer dereference [ Upstream commit 8ae01239609b29ec2eff55967c8e0fe3650cfa09 ] f_ncm tx timeout can call us with null skb to flush a pending frame. In this case skb is NULL to begin with but ceases to be null after dev->wrap() completes. In such a case in->maxpacket will be read, even though we've failed to check that 'in' is not NULL. Though I've never observed this fail in practice, however the 'flush operation' simply does not make sense with a null usb IN endpoint - there's nowhere to flush to... (note that we're the gadget/device, and IN is from the point of view of the host, so here IN actually means outbound...) Cc: Brooke Basile Cc: "Bryan O'Donoghue" Cc: Felipe Balbi Cc: Greg Kroah-Hartman Cc: Lorenzo Colitti Signed-off-by: Maciej Żenczykowski Link: https://lore.kernel.org/r/20210701114834.884597-6-zenczykowski@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 566ddd2d94b099792a02ca44fffb657ea3fd59c6 Author: Kelly Devilliv Date: Sun Jun 27 20:57:47 2021 +0800 usb: host: fotg210: fix the actual_length of an iso packet [ Upstream commit 091cb2f782f32ab68c6f5f326d7868683d3d4875 ] We should acquire the actual_length of an iso packet from the iTD directly using FOTG210_ITD_LENGTH() macro. Signed-off-by: Kelly Devilliv Link: https://lore.kernel.org/r/20210627125747.127646-4-kelly.devilliv@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 224cf5e8c853691f92e984f3e6e399479793e2bf Author: Kelly Devilliv Date: Sun Jun 27 20:57:46 2021 +0800 usb: host: fotg210: fix the endpoint's transactional opportunities calculation [ Upstream commit c2e898764245c852bc8ee4857613ba4f3a6d761d ] Now that usb_endpoint_maxp() only returns the lowest 11 bits from wMaxPacketSize, we should make use of the usb_endpoint_* helpers instead and remove the unnecessary max_packet()/hb_mult() macro. Signed-off-by: Kelly Devilliv Link: https://lore.kernel.org/r/20210627125747.127646-3-kelly.devilliv@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 463b3edfba90f6771195626b4f252c8545002cb2 Author: Sasha Neftin Date: Mon Jun 14 15:19:39 2021 +0300 igc: Check if num of q_vectors is smaller than max before array access [ Upstream commit 373e2829e7c2e1e606503cdb5c97749f512a4be9 ] Ensure that the adapter->q_vector[MAX_Q_VECTORS] array isn't accessed beyond its size. It was fixed by using a local variable num_q_vectors as a limit for loop index, and ensure that num_q_vectors is not bigger than MAX_Q_VECTORS. Suggested-by: Aleksandr Loktionov Signed-off-by: Sasha Neftin Tested-by: Dvora Fuxbrumer Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit d3ca78775db42eedde8ce9fee5fbd5be4b36a0f1 Author: Zhouyi Zhou Date: Tue Jul 13 08:56:45 2021 +0800 rcu: Fix macro name CONFIG_TASKS_RCU_TRACE [ Upstream commit fed31a4dd3adb5455df7c704de2abb639a1dc1c0 ] This commit fixes several typos where CONFIG_TASKS_RCU_TRACE should instead be CONFIG_TASKS_TRACE_RCU. Among other things, these typos could cause CONFIG_TASKS_TRACE_RCU_READ_MB=y kernels to suffer from memory-ordering bugs that could result in false-positive quiescent states and too-short grace periods. Signed-off-by: Zhouyi Zhou Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit 34609faad0c9f9f08d4b59d25c94b78bf5710d93 Author: Desmond Cheong Zhi Xi Date: Mon Jul 12 12:35:08 2021 +0800 drm: protect drm_master pointers in drm_lease.c [ Upstream commit 56f0729a510f92151682ff6c89f69724d5595d6e ] drm_file->master pointers should be protected by drm_device.master_mutex or drm_file.master_lookup_lock when being dereferenced. However, in drm_lease.c, there are multiple instances where drm_file->master is accessed and dereferenced while neither lock is held. This makes drm_lease.c vulnerable to use-after-free bugs. We address this issue in 2 ways: 1. Add a new drm_file_get_master() function that calls drm_master_get on drm_file->master while holding on to drm_file.master_lookup_lock. Since drm_master_get increments the reference count of master, this prevents master from being freed until we unreference it with drm_master_put. 2. In each case where drm_file->master is directly accessed and eventually dereferenced in drm_lease.c, we wrap the access in a call to the new drm_file_get_master function, then unreference the master pointer once we are done using it. Reported-by: Daniel Vetter Signed-off-by: Desmond Cheong Zhi Xi Reviewed-by: Emil Velikov Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210712043508.11584-6-desmondcheongzx@gmail.com Signed-off-by: Sasha Levin commit 06a553a99bacb00d3bc25f79e75c8e0fbf7a5025 Author: Desmond Cheong Zhi Xi Date: Mon Jul 12 12:35:07 2021 +0800 drm: serialize drm_file.master with a new spinlock [ Upstream commit 0b0860a3cf5eccf183760b1177a1dcdb821b0b66 ] Currently, drm_file.master pointers should be protected by drm_device.master_mutex when being dereferenced. This is because drm_file.master is not invariant for the lifetime of drm_file. If drm_file is not the creator of master, then drm_file.is_master is false, and a call to drm_setmaster_ioctl will invoke drm_new_set_master, which then allocates a new master for drm_file and puts the old master. Thus, without holding drm_device.master_mutex, the old value of drm_file.master could be freed while it is being used by another concurrent process. However, it is not always possible to lock drm_device.master_mutex to dereference drm_file.master. Through the fbdev emulation code, this might occur in a deep nest of other locks. But drm_device.master_mutex is also the outermost lock in the nesting hierarchy, so this leads to potential deadlocks. To address this, we introduce a new spin lock at the bottom of the lock hierarchy that only serializes drm_file.master. With this change, the value of drm_file.master changes only when both drm_device.master_mutex and drm_file.master_lookup_lock are held. Hence, any process holding either of those locks can ensure that the value of drm_file.master will not change concurrently. Since no lock depends on the new drm_file.master_lookup_lock, when drm_file.master is dereferenced, but drm_device.master_mutex cannot be held, we can safely protect the master pointer with drm_file.master_lookup_lock. Reported-by: Daniel Vetter Signed-off-by: Desmond Cheong Zhi Xi Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210712043508.11584-5-desmondcheongzx@gmail.com Signed-off-by: Sasha Levin commit 54e51d288b38377e8cd645a83e1ad08cc9d20ccc Author: Desmond Cheong Zhi Xi Date: Mon Jul 12 12:35:05 2021 +0800 drm: avoid blocking in drm_clients_info's rcu section [ Upstream commit 5eff9585de220cdd131237f5665db5e6c6bdf590 ] Inside drm_clients_info, the rcu_read_lock is held to lock pid_task()->comm. However, within this protected section, a call to drm_is_current_master is made, which involves a mutex lock in a future patch. However, this is illegal because the mutex lock might block while in the RCU read-side critical section. Since drm_is_current_master isn't protected by rcu_read_lock, we avoid this by moving it out of the RCU critical section. The following report came from intel-gfx ci's igt@debugfs_test@read_all_entries testcase: ============================= [ BUG: Invalid wait context ] 5.13.0-CI-Patchwork_20515+ #1 Tainted: G W ----------------------------- debugfs_test/1101 is trying to lock: ffff888132d901a8 (&dev->master_mutex){+.+.}-{3:3}, at: drm_is_current_master+0x1e/0x50 other info that might help us debug this: context-{4:4} 3 locks held by debugfs_test/1101: #0: ffff88810fdffc90 (&p->lock){+.+.}-{3:3}, at: seq_read_iter+0x53/0x3b0 #1: ffff888132d90240 (&dev->filelist_mutex){+.+.}-{3:3}, at: drm_clients_info+0x63/0x2a0 #2: ffffffff82734220 (rcu_read_lock){....}-{1:2}, at: drm_clients_info+0x1b1/0x2a0 stack backtrace: CPU: 8 PID: 1101 Comm: debugfs_test Tainted: G W 5.13.0-CI-Patchwork_20515+ #1 Hardware name: Intel Corporation CometLake Client Platform/CometLake S UDIMM (ERB/CRB), BIOS CMLSFWR1.R00.1263.D00.1906260926 06/26/2019 Call Trace: dump_stack+0x7f/0xad __lock_acquire.cold.78+0x2af/0x2ca lock_acquire+0xd3/0x300 ? drm_is_current_master+0x1e/0x50 ? __mutex_lock+0x76/0x970 ? lockdep_hardirqs_on+0xbf/0x130 __mutex_lock+0xab/0x970 ? drm_is_current_master+0x1e/0x50 ? drm_is_current_master+0x1e/0x50 ? drm_is_current_master+0x1e/0x50 drm_is_current_master+0x1e/0x50 drm_clients_info+0x107/0x2a0 seq_read_iter+0x178/0x3b0 seq_read+0x104/0x150 full_proxy_read+0x4e/0x80 vfs_read+0xa5/0x1b0 ksys_read+0x5a/0xd0 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae Signed-off-by: Desmond Cheong Zhi Xi Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210712043508.11584-3-desmondcheongzx@gmail.com Signed-off-by: Sasha Levin commit df19d95141d18231952153e03f578f078f0be384 Author: Tianjia Zhang Date: Thu Jul 15 17:17:24 2021 +0800 Smack: Fix wrong semantics in smk_access_entry() [ Upstream commit 6d14f5c7028eea70760df284057fe198ce7778dd ] In the smk_access_entry() function, if no matching rule is found in the rust_list, a negative error code will be used to perform bit operations with the MAY_ enumeration value. This is semantically wrong. This patch fixes this issue. Signed-off-by: Tianjia Zhang Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit 3533aa65e6a93aedb8f5baf5bb52a3165f6a67c7 Author: Yajun Deng Date: Mon Jul 19 13:18:16 2021 +0800 netlink: Deal with ESRCH error in nlmsg_notify() [ Upstream commit fef773fc8110d8124c73a5e6610f89e52814637d ] Yonghong Song report: The bpf selftest tc_bpf failed with latest bpf-next. The following is the command to run and the result: $ ./test_progs -n 132 [ 40.947571] bpf_testmod: loading out-of-tree module taints kernel. test_tc_bpf:PASS:test_tc_bpf__open_and_load 0 nsec test_tc_bpf:PASS:bpf_tc_hook_create(BPF_TC_INGRESS) 0 nsec test_tc_bpf:PASS:bpf_tc_hook_create invalid hook.attach_point 0 nsec test_tc_bpf_basic:PASS:bpf_obj_get_info_by_fd 0 nsec test_tc_bpf_basic:PASS:bpf_tc_attach 0 nsec test_tc_bpf_basic:PASS:handle set 0 nsec test_tc_bpf_basic:PASS:priority set 0 nsec test_tc_bpf_basic:PASS:prog_id set 0 nsec test_tc_bpf_basic:PASS:bpf_tc_attach replace mode 0 nsec test_tc_bpf_basic:PASS:bpf_tc_query 0 nsec test_tc_bpf_basic:PASS:handle set 0 nsec test_tc_bpf_basic:PASS:priority set 0 nsec test_tc_bpf_basic:PASS:prog_id set 0 nsec libbpf: Kernel error message: Failed to send filter delete notification test_tc_bpf_basic:FAIL:bpf_tc_detach unexpected error: -3 (errno 3) test_tc_bpf:FAIL:test_tc_internal ingress unexpected error: -3 (errno 3) The failure seems due to the commit cfdf0d9ae75b ("rtnetlink: use nlmsg_notify() in rtnetlink_send()") Deal with ESRCH error in nlmsg_notify() even the report variable is zero. Reported-by: Yonghong Song Signed-off-by: Yajun Deng Link: https://lore.kernel.org/r/20210719051816.11762-1-yajun.deng@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9de06dcd4710a4fc4afc8eeba7f7f1276b9c6b29 Author: Zheyu Ma Date: Wed Jul 14 04:09:22 2021 +0000 video: fbdev: kyro: fix a DoS bug by restricting user input [ Upstream commit 98a65439172dc69cb16834e62e852afc2adb83ed ] The user can pass in any value to the driver through the 'ioctl' interface. The driver dost not check, which may cause DoS bugs. The following log reveals it: divide error: 0000 [#1] PREEMPT SMP KASAN PTI RIP: 0010:SetOverlayViewPort+0x133/0x5f0 drivers/video/fbdev/kyro/STG4000OverlayDevice.c:476 Call Trace: kyro_dev_overlay_viewport_set drivers/video/fbdev/kyro/fbdev.c:378 [inline] kyrofb_ioctl+0x2eb/0x330 drivers/video/fbdev/kyro/fbdev.c:603 do_fb_ioctl+0x1f3/0x700 drivers/video/fbdev/core/fbmem.c:1171 fb_ioctl+0xeb/0x130 drivers/video/fbdev/core/fbmem.c:1185 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19b/0x220 fs/ioctl.c:739 do_syscall_64+0x32/0x80 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae Signed-off-by: Zheyu Ma Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/1626235762-2590-1-git-send-email-zheyuma97@gmail.com Signed-off-by: Sasha Levin commit 29ab7f6d505f5e1219c76f2962c9de484418905d Author: David Heidelberg Date: Wed Jul 7 15:14:53 2021 +0200 ARM: dts: qcom: apq8064: correct clock names [ Upstream commit 0dc6c59892ead17a9febd11202c9f6794aac1895 ] Since new code doesn't take old clk names in account, it does fixes error: msm_dsi 4700000.mdss_dsi: dev_pm_opp_set_clkname: Couldn't find clock: -2 and following kernel oops introduced by b0530eb1191 ("drm/msm/dpu: Use OPP API to set clk/perf state"). Also removes warning about deprecated clock names. Tested against linux-5.10.y LTS on Nexus 7 2013. Reviewed-by: Brian Masney Signed-off-by: David Heidelberg Link: https://lore.kernel.org/r/20210707131453.24041-1-david@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e0c17c11b15df1fa57e000925f3b40021f8baf90 Author: Stefan Assmann Date: Tue Mar 16 11:01:41 2021 +0100 iavf: fix locking of critical sections [ Upstream commit 226d528512cfac890a1619aea4301f3dd314fe60 ] To avoid races between iavf_init_task(), iavf_reset_task(), iavf_watchdog_task(), iavf_adminq_task() as well as the shutdown and remove functions more locking is required. The current protection by __IAVF_IN_CRITICAL_TASK is needed in additional places. - The reset task performs state transitions, therefore needs locking. - The adminq task acts on replies from the PF in iavf_virtchnl_completion() which may alter the states. - The init task is not only run during probe but also if a VF gets stuck to reinitialize it. - The shutdown function performs a state transition. - The remove function performs a state transition and also free's resources. iavf_lock_timeout() is introduced to avoid waiting infinitely and cause a deadlock. Rather unlock and print a warning. Signed-off-by: Stefan Assmann Tested-by: Konrad Jankowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 67c9262e3f317c1004329344a17e2ae8ca81965f Author: Stefan Assmann Date: Fri Mar 5 13:38:56 2021 +0100 iavf: do not override the adapter state in the watchdog task [ Upstream commit 22c8fd71d3a5e6fe584ccc2c1e8760e5baefd5aa ] The iavf watchdog task overrides adapter->state to __IAVF_RESETTING when it detects a pending reset. Then schedules iavf_reset_task() which takes care of the reset. The reset task is capable of handling the reset without changing adapter->state. In fact we lose the state information when the watchdog task prematurely changes the adapter state. This may lead to a crash if instead of the reset task the iavf_remove() function gets called before the reset task. In that case (if we were in state __IAVF_RUNNING previously) the iavf_remove() function triggers iavf_close() which fails to close the device because of the incorrect state information. This may result in a crash due to pending interrupts. kernel BUG at drivers/pci/msi.c:357! [...] Call Trace: [] pci_disable_msix+0x3d/0x50 [] iavf_reset_interrupt_capability+0x23/0x40 [iavf] [] iavf_remove+0x10a/0x350 [iavf] [] pci_device_remove+0x39/0xc0 [] __device_release_driver+0x7f/0xf0 [] device_release_driver+0x23/0x30 [] pci_stop_bus_device+0x84/0xa0 [] pci_stop_and_remove_bus_device+0x12/0x20 [] pci_iov_remove_virtfn+0xaf/0x160 [] sriov_disable+0x3c/0xf0 [] pci_disable_sriov+0x23/0x30 [] i40e_free_vfs+0x265/0x2d0 [i40e] [] i40e_pci_sriov_configure+0x144/0x1f0 [i40e] [] sriov_numvfs_store+0x177/0x1d0 Code: 00 00 e8 3c 25 e3 ff 49 c7 86 88 08 00 00 00 00 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 48 8b 7b 28 e8 0d 44 RIP [] free_msi_irqs+0x188/0x190 The solution is to not touch the adapter->state in iavf_watchdog_task() and let the reset task handle the state transition. Signed-off-by: Stefan Assmann Tested-by: Konrad Jankowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 9f11de56012c413140390de736d8c44800602750 Author: Jonathan Cameron Date: Sun Jun 27 17:32:37 2021 +0100 iio: dac: ad5624r: Fix incorrect handling of an optional regulator. [ Upstream commit 97683c851f9cdbd3ea55697cbe2dcb6af4287bbd ] The naming of the regulator is problematic. VCC is usually a supply voltage whereas these devices have a separate VREF pin. Secondly, the regulator core might have provided a stub regulator if a real regulator wasn't provided. That would in turn have failed to provide a voltage when queried. So reality was that there was no way to use the internal reference. In order to avoid breaking any dts out in the wild, make sure to fallback to the original vcc naming if vref is not available. Signed-off-by: Jonathan Cameron Reported-by: kernel test robot Acked-by: Nuno Sá Link: https://lore.kernel.org/r/20210627163244.1090296-9-jic23@kernel.org Signed-off-by: Sasha Levin commit e78a0b4a339e8cc5343947680829f35a942b64fa Author: Marek Vasut Date: Sat Jul 17 14:32:49 2021 +0200 net: phy: Fix data type in DP83822 dp8382x_disable_wol() [ Upstream commit 0d6835ffe50c9c1f098b5704394331710b67af48 ] The last argument of phy_clear_bits_mmd(..., u16 val); is u16 and not int, just inline the value into the function call arguments. No functional change. Signed-off-by: Marek Vasut Cc: Andrew Lunn Cc: Florian Fainelli Cc: David S. Miller Reviewed-by: Florian Fainelli Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit cca61275874a8807ba357905206961a5decdc326 Author: Xin Long Date: Fri Jul 16 17:44:07 2021 -0400 tipc: keep the skb in rcv queue until the whole data is read [ Upstream commit f4919ff59c2828064b4156e3c3600a169909bcf4 ] Currently, when userspace reads a datagram with a buffer that is smaller than this datagram, the data will be truncated and only part of it can be received by users. It doesn't seem right that users don't know the datagram size and have to use a huge buffer to read it to avoid the truncation. This patch to fix it by keeping the skb in rcv queue until the whole data is read by users. Only the last msg of the datagram will be marked with MSG_EOR, just as TCP/SCTP does. Note that this will work as above only when MSG_EOR is set in the flags parameter of recvmsg(), so that it won't break any old user applications. Signed-off-by: Xin Long Acked-by: Jon Maloy Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit cc12ab5951aa3a9d0893614120560179db8659a2 Author: Rafael J. Wysocki Date: Thu Jul 8 15:25:06 2021 +0200 PCI: Use pci_update_current_state() in pci_enable_device_flags() [ Upstream commit 14858dcc3b3587f4bb5c48e130ee7d68fc2b0a29 ] Updating the current_state field of struct pci_dev the way it is done in pci_enable_device_flags() before calling do_pci_enable_device() may not work. For example, if the given PCI device depends on an ACPI power resource whose _STA method initially returns 0 ("off"), but the config space of the PCI device is accessible and the power state retrieved from the PCI_PM_CTRL register is D0, the current_state field in the struct pci_dev representing that device will get out of sync with the power.state of its ACPI companion object and that will lead to power management issues going forward. To avoid such issues, make pci_enable_device_flags() call pci_update_current_state() which takes ACPI device power management into account, if present, to retrieve the current power state of the device. Link: https://lore.kernel.org/lkml/20210314000439.3138941-1-luzmaximilian@gmail.com/ Reported-by: Maximilian Luz Signed-off-by: Rafael J. Wysocki Tested-by: Maximilian Luz Signed-off-by: Sasha Levin commit aad29a00a5983d3ed2d6ca06d2ab63a4f8a61adc Author: Sean Anderson Date: Thu Jul 1 14:56:38 2021 -0400 crypto: mxs-dcp - Use sg_mapping_iter to copy data [ Upstream commit 2e6d793e1bf07fe5e20cfbbdcec9e1af7e5097eb ] This uses the sg_pcopy_from_buffer to copy data, instead of doing it ourselves. In addition to reducing code size, this fixes the following oops resulting from failing to kmap the page: [ 68.896381] Unable to handle kernel NULL pointer dereference at virtual address 00000ab8 [ 68.904539] pgd = 3561adb3 [ 68.907475] [00000ab8] *pgd=00000000 [ 68.911153] Internal error: Oops: 805 [#1] ARM [ 68.915618] Modules linked in: cfg80211 rfkill des_generic libdes arc4 libarc4 cbc ecb algif_skcipher sha256_generic libsha256 sha1_generic hmac aes_generic libaes cmac sha512_generic md5 md4 algif_hash af_alg i2c_imx i2c_core ci_hdrc_imx ci_hdrc mxs_dcp ulpi roles udc_core imx_sdma usbmisc_imx usb_common firmware_class virt_dma phy_mxs_usb nf_tables nfnetlink ip_tables x_tables ipv6 autofs4 [ 68.950741] CPU: 0 PID: 139 Comm: mxs_dcp_chan/ae Not tainted 5.10.34 #296 [ 68.958501] Hardware name: Freescale i.MX6 Ultralite (Device Tree) [ 68.964710] PC is at memcpy+0xa8/0x330 [ 68.968479] LR is at 0xd7b2bc9d [ 68.971638] pc : [] lr : [] psr: 000f0013 [ 68.977920] sp : c2cbbee4 ip : 00000010 fp : 00000010 [ 68.983159] r10: 00000000 r9 : c3283a40 r8 : 1a5a6f08 [ 68.988402] r7 : 4bfe0ecc r6 : 76d8a220 r5 : c32f9050 r4 : 00000001 [ 68.994945] r3 : 00000ab8 r2 : fffffff0 r1 : c32f9050 r0 : 00000ab8 [ 69.001492] Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 69.008646] Control: 10c53c7d Table: 83664059 DAC: 00000051 [ 69.014414] Process mxs_dcp_chan/ae (pid: 139, stack limit = 0x667b57ab) [ 69.021133] Stack: (0xc2cbbee4 to 0xc2cbc000) [ 69.025519] bee0: c32f9050 c3235408 00000010 00000010 00000ab8 00000001 bf10406c [ 69.033720] bf00: 00000000 00000000 00000010 00000000 c32355d0 832fb080 00000000 c13de2fc [ 69.041921] bf20: c3628010 00000010 c33d5780 00000ab8 bf1067e8 00000002 c21e5010 c2cba000 [ 69.050125] bf40: c32f8040 00000000 bf106a40 c32f9040 c3283a80 00000001 bf105240 c3234040 [ 69.058327] bf60: ffffe000 c3204100 c2c69800 c2cba000 00000000 bf103b84 00000000 c2eddc54 [ 69.066530] bf80: c3204144 c0140d1c c2cba000 c2c69800 c0140be8 00000000 00000000 00000000 [ 69.074730] bfa0: 00000000 00000000 00000000 c0100114 00000000 00000000 00000000 00000000 [ 69.082932] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 69.091131] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [ 69.099364] [] (memcpy) from [] (dcp_chan_thread_aes+0x4e8/0x840 [mxs_dcp]) [ 69.108117] [] (dcp_chan_thread_aes [mxs_dcp]) from [] (kthread+0x134/0x160) [ 69.116941] [] (kthread) from [] (ret_from_fork+0x14/0x20) [ 69.124178] Exception stack(0xc2cbbfb0 to 0xc2cbbff8) [ 69.129250] bfa0: 00000000 00000000 00000000 00000000 [ 69.137450] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 69.145648] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 69.152289] Code: e320f000 e4803004 e4804004 e4805004 (e4806004) Signed-off-by: Sean Anderson Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 871abd1e6185fa0e066ced9ef8b7a517388f18e8 Author: Ani Sinha Date: Tue Jul 13 08:35:21 2021 +0530 x86/hyperv: fix for unwanted manipulation of sched_clock when TSC marked unstable [ Upstream commit c445535c3efbfb8cb42d098e624d46ab149664b7 ] Marking TSC as unstable has a side effect of marking sched_clock as unstable when TSC is still being used as the sched_clock. This is not desirable. Hyper-V ultimately uses a paravirtualized clock source that provides a stable scheduler clock even on systems without TscInvariant CPU capability. Hence, mark_tsc_unstable() call should be called _after_ scheduler clock has been changed to the paravirtualized clocksource. This will prevent any unwanted manipulation of the sched_clock. Only TSC will be correctly marked as unstable. Signed-off-by: Ani Sinha Reviewed-by: Michael Kelley Tested-by: Michael Kelley Link: https://lore.kernel.org/r/20210713030522.1714803-1-ani@anisinha.ca Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit c327b69e96b0d17b56ebf15ebdf3262148f7e7af Author: Martynas Pumputis Date: Mon Jul 12 14:55:51 2021 +0200 libbpf: Fix reuse of pinned map on older kernel [ Upstream commit 97eb31384af943d6b97eb5947262cee4ef25cb87 ] When loading a BPF program with a pinned map, the loader checks whether the pinned map can be reused, i.e. their properties match. To derive such of the pinned map, the loader invokes BPF_OBJ_GET_INFO_BY_FD and then does the comparison. Unfortunately, on < 4.12 kernels the BPF_OBJ_GET_INFO_BY_FD is not available, so loading the program fails with the following error: libbpf: failed to get map info for map FD 5: Invalid argument libbpf: couldn't reuse pinned map at '/sys/fs/bpf/tc/globals/cilium_call_policy': parameter mismatch" libbpf: map 'cilium_call_policy': error reusing pinned map libbpf: map 'cilium_call_policy': failed to create: Invalid argument(-22) libbpf: failed to load object 'bpf_overlay.o' To fix this, fallback to derivation of the map properties via /proc/$PID/fdinfo/$MAP_FD if BPF_OBJ_GET_INFO_BY_FD fails with EINVAL, which can be used as an indicator that the kernel doesn't support the latter. Signed-off-by: Martynas Pumputis Signed-off-by: Andrii Nakryiko Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20210712125552.58705-1-m@lambda.lt Signed-off-by: Sasha Levin commit 6a985c579499f9998d00992f3840383bd9c303e2 Author: Mauro Carvalho Chehab Date: Thu Jun 17 13:28:57 2021 +0200 media: dib8000: rewrite the init prbs logic [ Upstream commit 8db11aebdb8f93f46a8513c22c9bd52fa23263aa ] The logic at dib8000_get_init_prbs() has a few issues: 1. the tables used there has an extra unused value at the beginning; 2. the dprintk() message doesn't write the right value when transmission mode is not 8K; 3. the array overflow validation is done by the callers. Rewrite the code to fix such issues. This should also shut up those smatch warnings: drivers/media/dvb-frontends/dib8000.c:2125 dib8000_get_init_prbs() error: buffer overflow 'lut_prbs_8k' 14 <= 14 drivers/media/dvb-frontends/dib8000.c:2129 dib8000_get_init_prbs() error: buffer overflow 'lut_prbs_2k' 14 <= 14 drivers/media/dvb-frontends/dib8000.c:2131 dib8000_get_init_prbs() error: buffer overflow 'lut_prbs_4k' 14 <= 14 drivers/media/dvb-frontends/dib8000.c:2134 dib8000_get_init_prbs() error: buffer overflow 'lut_prbs_8k' 14 <= 14 Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 2048907d8cb7b295a9efd86b18f6f11e3d602b92 Author: Randy Dunlap Date: Wed Jul 7 14:47:52 2021 -0700 ASoC: atmel: ATMEL drivers don't need HAS_DMA [ Upstream commit 6c5c659dfe3f02e08054a6c20019e3886618b512 ] On a config (such as arch/sh/) which does not set HAS_DMA when MMU is not set, several ATMEL ASoC drivers select symbols that cause kconfig warnings. There is one "depends on HAS_DMA" which is no longer needed. Dropping it eliminates the kconfig warnings and still builds with no problems reported. Fix the following kconfig warnings: WARNING: unmet direct dependencies detected for SND_ATMEL_SOC_PDC Depends on [n]: SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] && HAS_DMA [=n] Selected by [m]: - SND_ATMEL_SOC_SSC [=m] && SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] - SND_ATMEL_SOC_SSC_PDC [=m] && SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] && ATMEL_SSC [=m] WARNING: unmet direct dependencies detected for SND_ATMEL_SOC_SSC_PDC Depends on [n]: SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] && ATMEL_SSC [=m] && HAS_DMA [=n] Selected by [m]: - SND_AT91_SOC_SAM9G20_WM8731 [=m] && SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] && (ARCH_AT91 || COMPILE_TEST [=y]) && ATMEL_SSC [=m] && SND_SOC_I2C_AND_SPI [=m] WARNING: unmet direct dependencies detected for SND_ATMEL_SOC_SSC Depends on [n]: SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] && HAS_DMA [=n] Selected by [m]: - SND_ATMEL_SOC_SSC_DMA [=m] && SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] && ATMEL_SSC [=m] WARNING: unmet direct dependencies detected for SND_ATMEL_SOC_SSC_DMA Depends on [n]: SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] && ATMEL_SSC [=m] && HAS_DMA [=n] Selected by [m]: - SND_ATMEL_SOC_WM8904 [=m] && SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] && (ARCH_AT91 || COMPILE_TEST [=y]) && ATMEL_SSC [=m] && I2C [=m] - SND_AT91_SOC_SAM9X5_WM8731 [=m] && SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] && (ARCH_AT91 || COMPILE_TEST [=y]) && ATMEL_SSC [=m] && SND_SOC_I2C_AND_SPI [=m] Signed-off-by: Randy Dunlap Reviewed-by: Codrin Ciubotariu Acked-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210707214752.3831-1-rdunlap@infradead.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 10a135969fd7419695c003ddb67ef8a7820a808b Author: Luben Tuikov Date: Fri Mar 26 16:40:22 2021 -0400 drm/amdgpu: Fix amdgpu_ras_eeprom_init() [ Upstream commit dce4400e6516d18313d23de45b5be8a18980b00e ] No need to account for the 2 bytes of EEPROM address--this is now well abstracted away by the fixes the the lower layers. Cc: Andrey Grodzovsky Cc: Alexander Deucher Signed-off-by: Luben Tuikov Acked-by: Alexander Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b32d3ded9dc2987edbc3427e66238bfdfcecf0ad Author: Dom Cobley Date: Tue May 25 15:23:48 2021 +0200 drm/vc4: hdmi: Set HD_CTL_WHOLSMP and HD_CTL_CHALIGN_SET [ Upstream commit 1698ecb218eb82587dbfc71a2e26ded66e5ecf59 ] Symptom is random switching of speakers when using multichannel. Repeatedly running speakertest -c8 occasionally starts with channels jumbled. This is fixed with HD_CTL_WHOLSMP. The other bit looks beneficial and apears harmless in testing so I'd suggest adding it too. Documentation says: HD_CTL_WHILSMP_SET Wait for whole sample. When this bit is set MAI transmit will start only when there is at least one whole sample available in the fifo. Documentation says: HD_CTL_CHALIGN_SET Channel Align When Overflow. This bit is used to realign the audio channels in case of an overflow. If this bit is set, after the detection of an overflow, equal amount of dummy words to the missing words will be written to fifo, filling up the broken sample and maintaining alignment. Signed-off-by: Dom Cobley Signed-off-by: Maxime Ripard Reviewed-by: Nicolas Saenz Julienne Link: https://patchwork.freedesktop.org/patch/msgid/20210525132354.297468-7-maxime@cerno.tech Signed-off-by: Sasha Levin commit 6afd1e053d9bd1f39cf03f2b0702ad0b06b647bd Author: Nadav Amit Date: Thu Sep 2 14:58:59 2021 -0700 userfaultfd: prevent concurrent API initialization [ Upstream commit 22e5fe2a2a279d9a6fcbdfb4dffe73821bef1c90 ] userfaultfd assumes that the enabled features are set once and never changed after UFFDIO_API ioctl succeeded. However, currently, UFFDIO_API can be called concurrently from two different threads, succeed on both threads and leave userfaultfd's features in non-deterministic state. Theoretically, other uffd operations (ioctl's and page-faults) can be dispatched while adversely affected by such changes of features. Moreover, the writes to ctx->state and ctx->features are not ordered, which can - theoretically, again - let userfaultfd_ioctl() think that userfaultfd API completed, while the features are still not initialized. To avoid races, it is arguably best to get rid of ctx->state. Since there are only 2 states, record the API initialization in ctx->features as the uppermost bit and remove ctx->state. Link: https://lkml.kernel.org/r/20210808020724.1022515-3-namit@vmware.com Fixes: 9cd75c3cd4c3d ("userfaultfd: non-cooperative: add ability to report non-PF events from uffd descriptor") Signed-off-by: Nadav Amit Cc: Alexander Viro Cc: Andrea Arcangeli Cc: Axel Rasmussen Cc: Jens Axboe Cc: Mike Rapoport Cc: Peter Xu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 1e4cfe954bd9c42242bb21292c3dd9fb7f384104 Author: Masahiro Yamada Date: Thu Aug 19 09:01:14 2021 +0900 kbuild: Fix 'no symbols' warning when CONFIG_TRIM_UNUSD_KSYMS=y [ Upstream commit 52d83df682c82055961531853c066f4f16e234ea ] When CONFIG_TRIM_UNUSED_KSYMS is enabled, I see some warnings like this: nm: arch/x86/entry/vdso/vdso32/note.o: no symbols $NM (both GNU nm and llvm-nm) warns when no symbol is found in the object. Suppress the stderr. Fangrui Song mentioned binutils>=2.37 `nm -q` can be used to suppress "no symbols" [1], and llvm-nm>=13.0.0 supports -q as well. We cannot use it for now, but note it as a TODO. [1]: https://sourceware.org/bugzilla/show_bug.cgi?id=27408 Fixes: bbda5ec671d3 ("kbuild: simplify dependency generation for CONFIG_TRIM_UNUSED_KSYMS") Signed-off-by: Masahiro Yamada Reviewed-by: Nathan Chancellor Signed-off-by: Sasha Levin commit 981bf9b0aa1bffe3d98607e4024aa42fb8024bf0 Author: Oleksij Rempel Date: Thu Sep 2 09:19:51 2021 +0200 MIPS: Malta: fix alignment of the devicetree buffer [ Upstream commit bea6a94a279bcbe6b2cde348782b28baf12255a5 ] Starting with following patch MIPS Malta is not able to boot: | commit 79edff12060fe7772af08607eff50c0e2486c5ba | Author: Rob Herring | scripts/dtc: Update to upstream version v1.6.0-51-g183df9e9c2b9 The reason is the alignment test added to the fdt_ro_probe_(). To fix this issue, we need to make sure that fdt_buf is aligned. Since the dtc patch was designed to uncover potential issue, I handle initial MIPS Malta patch as initial bug. Fixes: e81a8c7dabac ("MIPS: Malta: Setup RAM regions via DT") Signed-off-by: Oleksij Rempel Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit bb8108546da97d7c66a8abe93af5ce04b68b509e Author: Jaegeuk Kim Date: Mon Aug 30 13:30:45 2021 -0700 f2fs: should put a page beyond EOF when preparing a write [ Upstream commit 9605f75cf36e0bcc0f4ada07b5be712d30107607 ] The prepare_compress_overwrite() gets/locks a page to prepare a read, and calls f2fs_read_multi_pages() which checks EOF first. If there's any page beyond EOF, we unlock the page and set cc->rpages[i] = NULL, which we can't put the page anymore. This makes page leak, so let's fix by putting that page. Fixes: a949dc5f2c5c ("f2fs: compress: fix race condition of overwrite vs truncate") Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit d04925fb8d7081108fba1ea21ce7a6d14e64eabd Author: Jaegeuk Kim Date: Mon Aug 30 11:37:32 2021 -0700 f2fs: deallocate compressed pages when error happens [ Upstream commit 827f02842e40ea2e00f401e8f4cb1bccf3b8cd86 ] In f2fs_write_multi_pages(), f2fs_compress_pages() allocates pages for compression work in cc->cpages[]. Then, f2fs_write_compressed_pages() initiates bio submission. But, if there's any error before submitting the IOs like early f2fs_cp_error(), previously it didn't free cpages by f2fs_compress_free_page(). Let's fix memory leak by putting that just before deallocating cc->cpages. Fixes: 4c8ff7095bef ("f2fs: support data compression") Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 4b71928e5c547e774cb4767da0959f9970a4f0f0 Author: Chao Yu Date: Wed Aug 25 19:34:19 2021 +0800 f2fs: fix to unmap pages from userspace process in punch_hole() [ Upstream commit c8dc3047c48540183744f959412d44b08c5435e1 ] We need to unmap pages from userspace process before removing pagecache in punch_hole() like we did in f2fs_setattr(). Similar change: commit 5e44f8c374dc ("ext4: hole-punch use truncate_pagecache_range") Fixes: fbfa2cc58d53 ("f2fs: add file operations") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 1c934aba9fd531580f5fedefcd3364d68c560471 Author: Chao Yu Date: Thu Aug 26 10:03:15 2021 +0800 f2fs: fix unexpected ENOENT comes from f2fs_map_blocks() [ Upstream commit adf9ea89c719c1d23794e363f631e376b3ff8cbc ] In below path, it will return ENOENT if filesystem is shutdown: - f2fs_map_blocks - f2fs_get_dnode_of_data - f2fs_get_node_page - __get_node_page - read_node_page - is_sbi_flag_set(sbi, SBI_IS_SHUTDOWN) return -ENOENT - force return value from ENOENT to 0 It should be fine for read case, since it indicates a hole condition, and caller could use .m_next_pgofs to skip the hole and continue the lookup. However it may cause confusing for write case, since leaving a hole there, and said nothing was wrong doesn't help. There is at least one case from dax_iomap_actor() will complain that, so fix this in prior to supporting dax in f2fs. xfstest generic/388 reports below warning: ubuntu godown: xfstests-induced forced shutdown of /mnt/scratch_f2fs: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 485833 at fs/dax.c:1127 dax_iomap_actor+0x339/0x370 Call Trace: iomap_apply+0x1c4/0x7b0 ? dax_iomap_rw+0x1c0/0x1c0 dax_iomap_rw+0xad/0x1c0 ? dax_iomap_rw+0x1c0/0x1c0 f2fs_file_write_iter+0x5ab/0x970 [f2fs] do_iter_readv_writev+0x273/0x2e0 do_iter_write+0xab/0x1f0 vfs_iter_write+0x21/0x40 iter_file_splice_write+0x287/0x540 do_splice+0x37c/0xa60 __x64_sys_splice+0x15f/0x3a0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae ubuntu godown: xfstests-induced forced shutdown of /mnt/scratch_f2fs: ------------[ cut here ]------------ RIP: 0010:dax_iomap_pte_fault.isra.0+0x72e/0x14a0 Call Trace: dax_iomap_fault+0x44/0x70 f2fs_dax_huge_fault+0x155/0x400 [f2fs] f2fs_dax_fault+0x18/0x30 [f2fs] __do_fault+0x4e/0x120 do_fault+0x3cf/0x7a0 __handle_mm_fault+0xa8c/0xf20 ? find_held_lock+0x39/0xd0 handle_mm_fault+0x1b6/0x480 do_user_addr_fault+0x320/0xcd0 ? rcu_read_lock_sched_held+0x67/0xc0 exc_page_fault+0x77/0x3f0 ? asm_exc_page_fault+0x8/0x30 asm_exc_page_fault+0x1e/0x30 Fixes: 83a3bfdb5a8a ("f2fs: indicate shutdown f2fs to allow unmount successfully") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 45cb5f86c1c65da62806d0c9618e9351a4025efa Author: Chao Yu Date: Tue Aug 24 08:12:08 2021 +0800 f2fs: fix to account missing .skipped_gc_rwsem [ Upstream commit ad126ebddecbf696e0cf214ff56c7b170fa9f0f7 ] There is a missing place we forgot to account .skipped_gc_rwsem, fix it. Fixes: 6f8d4455060d ("f2fs: avoid fi->i_gc_rwsem[WRITE] lock in f2fs_gc") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit fd69f613af534eebd6fd79eb27b5b0a0d6b94686 Author: Yongqiang Niu Date: Mon Aug 2 15:52:26 2021 +0800 soc: mediatek: cmdq: add address shift in jump [ Upstream commit 8b60ed2b1674b78ebc433a11efa7d48821229037 ] Add address shift when compose jump instruction to compatible with 35bit format. Fixes: 0858fde496f8 ("mailbox: cmdq: variablize address shift in platform") Signed-off-by: Yongqiang Niu Reviewed-by: Nicolas Boichat Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit d320c1b2e7282de155d21b6f22cfc39e99ee3410 Author: Alexey Kardashevskiy Date: Fri Aug 27 14:07:06 2021 +1000 KVM: PPC: Fix clearing never mapped TCEs in realmode [ Upstream commit 1d78dfde33a02da1d816279c2e3452978b7abd39 ] Since commit e1a1ef84cd07 ("KVM: PPC: Book3S: Allocate guest TCEs on demand too"), pages for TCE tables for KVM guests are allocated only when needed. This allows skipping any update when clearing TCEs. This works mostly fine as TCE updates are handled when the MMU is enabled. The realmode handlers fail with H_TOO_HARD when pages are not yet allocated, except when clearing a TCE in which case KVM prints a warning and proceeds to dereference a NULL pointer, which crashes the host OS. This has not been caught so far as the change in commit e1a1ef84cd07 is reasonably new, and POWER9 runs mostly radix which does not use realmode handlers. With hash, the default TCE table is memset() by QEMU when the machine is reset which triggers page faults and the KVM TCE device's kvm_spapr_tce_fault() handles those with MMU on. And the huge DMA windows are not cleared by VMs which instead successfully create a DMA window big enough to map the VM memory 1:1 and then VMs just map everything without clearing. This started crashing now as commit 381ceda88c4c ("powerpc/pseries/iommu: Make use of DDW for indirect mapping") added a mode when a dymanic DMA window not big enough to map the VM memory 1:1 but it is used anyway, and the VM now is the first (i.e. not QEMU) to clear a just created table. Note that upstream QEMU needs to be modified to trigger the VM to trigger the host OS crash. This replaces WARN_ON_ONCE_RM() with a check and return, and adds another warning if TCE is not being cleared. Fixes: e1a1ef84cd07 ("KVM: PPC: Book3S: Allocate guest TCEs on demand too") Signed-off-by: Alexey Kardashevskiy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210827040706.517652-1-aik@ozlabs.ru Signed-off-by: Sasha Levin commit 6bf98b94ffeb4dea48b288d874e6be8ecba36191 Author: Codrin Ciubotariu Date: Wed Jul 7 16:12:13 2021 +0300 clk: at91: clk-generated: Limit the requested rate to our range [ Upstream commit af7651e67b9d5f7e63ea23b118e3672ac662244a ] On clk_generated_determine_rate(), the requested rate could be outside of clk's range. Limit the rate to the clock's range to not return an error. Fixes: df70aeef6083 ("clk: at91: add generated clock driver") Signed-off-by: Codrin Ciubotariu Link: https://lore.kernel.org/r/20210707131213.3283509-1-codrin.ciubotariu@microchip.com Acked-by: Nicolas Ferre Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 9bab2bc4c238ca5a2faeb26db03808d95784a204 Author: David Howells Date: Thu Jun 17 14:21:00 2021 +0100 fscache: Fix cookie key hashing [ Upstream commit 35b72573e977ed6b18b094136a4fa3e0ffb13603 ] The current hash algorithm used for hashing cookie keys is really bad, producing almost no dispersion (after a test kernel build, ~30000 files were split over just 18 out of the 32768 hash buckets). Borrow the full_name_hash() hash function into fscache to do the hashing for cookie keys and, in the future, volume keys. I don't want to use full_name_hash() as-is because I want the hash value to be consistent across arches and over time as the hash value produced may get used on disk. I can also optimise parts of it away as the key will always be a padded array of aligned 32-bit words. Fixes: ec0328e46d6e ("fscache: Maintain a catalogue of allocated cookies") Signed-off-by: David Howells Reviewed-by: Jeff Layton cc: linux-cachefs@redhat.com Link: https://lore.kernel.org/r/162431201844.2908479.8293647220901514696.stgit@warthog.procyon.org.uk/ Signed-off-by: Sasha Levin commit b4849e2ac706387fed6af98e88f619c49cecc4a8 Author: Wenpeng Liang Date: Thu Aug 26 21:37:31 2021 +0800 RDMA/hns: Fix QP's resp incomplete assignment [ Upstream commit d2e0ccffcdd7209fc9881c8970d2a7e28dcb43b9 ] The resp passed to the user space represents the enable flag of qp, incomplete assignment will cause some features of the user space to be disabled. Fixes: 90ae0b57e4a5 ("RDMA/hns: Combine enable flags of qp") Fixes: aba457ca890c ("RDMA/hns: Support owner mode doorbell") Link: https://lore.kernel.org/r/1629985056-57004-3-git-send-email-liangwenpeng@huawei.com Signed-off-by: Wenpeng Liang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit e91077cf1780108dc586cedf1d19f65b44fa3870 Author: Srikar Dronamraju Date: Thu Aug 26 15:34:00 2021 +0530 powerpc/smp: Update cpu_core_map on all PowerPc systems [ Upstream commit b8b928030332a0ca16d42433eb2c3085600d8704 ] lscpu() uses core_siblings to list the number of sockets in the system. core_siblings is set using topology_core_cpumask. While optimizing the powerpc bootup path, Commit 4ca234a9cbd7 ("powerpc/smp: Stop updating cpu_core_mask"). it was found that updating cpu_core_mask() ended up taking a lot of time. It was thought that on Powerpc, cpu_core_mask() would always be same as cpu_cpu_mask() i.e number of sockets will always be equal to number of nodes. As an optimization, cpu_core_mask() was made a snapshot of cpu_cpu_mask(). However that was found to be false with PowerPc KVM guests, where each node could have more than one socket. So with Commit c47f892d7aa6 ("powerpc/smp: Reintroduce cpu_core_mask"), cpu_core_mask was updated based on chip_id but in an optimized way using some mask manipulations and chip_id caching. However on non-PowerNV and non-pseries KVM guests (i.e not implementing cpu_to_chip_id(), continued to use a copy of cpu_cpu_mask(). There are two issues that were noticed on such systems 1. lscpu would report one extra socket. On a IBM,9009-42A (aka zz system) which has only 2 chips/ sockets/ nodes, lscpu would report Architecture: ppc64le Byte Order: Little Endian CPU(s): 160 On-line CPU(s) list: 0-159 Thread(s) per core: 8 Core(s) per socket: 6 Socket(s): 3 <-------------- NUMA node(s): 2 Model: 2.2 (pvr 004e 0202) Model name: POWER9 (architected), altivec supported Hypervisor vendor: pHyp Virtualization type: para L1d cache: 32K L1i cache: 32K L2 cache: 512K L3 cache: 10240K NUMA node0 CPU(s): 0-79 NUMA node1 CPU(s): 80-159 2. Currently cpu_cpu_mask is updated when a core is added/removed. However its not updated when smt mode switching or on CPUs are explicitly offlined. However all other percpu masks are updated to ensure only active/online CPUs are in the masks. This results in build_sched_domain traces since there will be CPUs in cpu_cpu_mask() but those CPUs are not present in SMT / CACHE / MC / NUMA domains. A loop of threads running smt mode switching and core add/remove will soon show this trace. Hence cpu_cpu_mask has to be update at smt mode switch. This will have impact on cpu_core_mask(). cpu_core_mask() is a snapshot of cpu_cpu_mask. Different CPUs within the same socket will end up having different cpu_core_masks since they are snapshots at different points of time. This means when lscpu will start reporting many more sockets than the actual number of sockets/ nodes / chips. Different ways to handle this problem: A. Update the snapshot aka cpu_core_mask for all CPUs whenever cpu_cpu_mask is updated. This would a non-optimal solution. B. Instead of a cpumask_var_t, make cpu_core_map a cpumask pointer pointing to cpu_cpu_mask. However percpu cpumask pointer is frowned upon and we need a clean way to handle PowerPc KVM guest which is not a snapshot. C. Update cpu_core_masks all PowerPc systems like in PowerPc KVM guests using mask manipulations. This approach is relatively simple and unifies with the existing code. D. On top of 3, we could also resurrect get_physical_package_id which could return a nid for the said CPU. However this is not needed at this time. Option C is the preferred approach for now. While this is somewhat a revert of Commit 4ca234a9cbd7 ("powerpc/smp: Stop updating cpu_core_mask"). 1. Plain revert has some conflicts 2. For chip_id == -1, the cpu_core_mask is made identical to cpu_cpu_mask, unlike previously where cpu_core_mask was set to a core if chip_id doesn't exist. This goes by the principle that if chip_id is not exposed, then sockets / chip / node share the same set of CPUs. With the fix, lscpu o/p would be Architecture: ppc64le Byte Order: Little Endian CPU(s): 160 On-line CPU(s) list: 0-159 Thread(s) per core: 8 Core(s) per socket: 6 Socket(s): 2 <-------------- NUMA node(s): 2 Model: 2.2 (pvr 004e 0202) Model name: POWER9 (architected), altivec supported Hypervisor vendor: pHyp Virtualization type: para L1d cache: 32K L1i cache: 32K L2 cache: 512K L3 cache: 10240K NUMA node0 CPU(s): 0-79 NUMA node1 CPU(s): 80-159 Fixes: 4ca234a9cbd7 ("powerpc/smp: Stop updating cpu_core_mask") Signed-off-by: Srikar Dronamraju Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210826100401.412519-3-srikar@linux.vnet.ibm.com Signed-off-by: Sasha Levin commit 903ca538f5882404f7764c3c93b5c82c4794a288 Author: Hans de Goede Date: Thu Aug 26 16:08:22 2021 +0200 platform/x86: dell-smbios-wmi: Add missing kfree in error-exit from run_smbios_call [ Upstream commit 0487d4fc42d7f31a56cfd9e2237f9ebd889e6112 ] As pointed out be Kees Cook if we return -EIO because the obj->type != ACPI_TYPE_BUFFER, then we must kfree the output buffer before the return. Fixes: 1a258e670434 ("platform/x86: dell-smbios-wmi: Add new WMI dispatcher driver") Reported-by: Kees Cook Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210826140822.71198-1-hdegoede@redhat.com Signed-off-by: Sasha Levin commit add8e8c3402f3bb54c66716b23544d2ef289a79d Author: Nicholas Piggin Date: Thu Aug 12 02:00:43 2021 +1000 KVM: PPC: Book3S HV Nested: Reflect guest PMU in-use to L0 when guest SPRs are live [ Upstream commit 1782663897945a5cf28e564ba5eed730098e9aa4 ] After the L1 saves its PMU SPRs but before loading the L2's PMU SPRs, switch the pmcregs_in_use field in the L1 lppaca to the value advertised by the L2 in its VPA. On the way out of the L2, set it back after saving the L2 PMU registers (if they were in-use). This transfers the PMU liveness indication between the L1 and L2 at the points where the registers are not live. This fixes the nested HV bug for which a workaround was added to the L0 HV by commit 63279eeb7f93a ("KVM: PPC: Book3S HV: Always save guest pmu for guest capable of nesting"), which explains the problem in detail. That workaround is no longer required for guests that include this bug fix. Fixes: 360cae313702 ("KVM: PPC: Book3S HV: Nested guest entry via hypercall") Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Reviewed-by: Fabiano Rosas Link: https://lore.kernel.org/r/20210811160134.904987-10-npiggin@gmail.com Signed-off-by: Sasha Levin commit 4c0c4f702196a735a3f7cabb4180d37c5a745979 Author: Alim Akhtar Date: Thu Aug 19 22:41:31 2021 +0530 scsi: ufs: ufs-exynos: Fix static checker warning [ Upstream commit 313bf281f2091552f509fd05a74172c70ce7572f ] clk_get_rate() returns unsigned long and currently this driver stores the return value in u32 type, resulting the below warning: Fixed smatch warnings: drivers/scsi/ufs/ufs-exynos.c:286 exynos_ufs_get_clk_info() warn: wrong type for 'ufs->mclk_rate' (should be 'ulong') drivers/scsi/ufs/ufs-exynos.c:287 exynos_ufs_get_clk_info() warn: wrong type for 'pclk_rate' (should be 'ulong') Link: https://lore.kernel.org/r/20210819171131.55912-1-alim.akhtar@samsung.com Fixes: 55f4b1f73631 ("scsi: ufs: ufs-exynos: Add UFS host support for Exynos SoCs") Reported-by: Dan Carpenter Signed-off-by: Alim Akhtar Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit bda5602c1c35fb22847951607776d49352322e47 Author: Fabiano Rosas Date: Thu Aug 5 18:26:14 2021 -0300 KVM: PPC: Book3S HV: Fix copy_tofrom_guest routines [ Upstream commit 5d7d6dac8fe99ed59eee2300e4a03370f94d5222 ] The __kvmhv_copy_tofrom_guest_radix function was introduced along with nested HV guest support. It uses the platform's Radix MMU quadrants to provide a nested hypervisor with fast access to its nested guests memory (H_COPY_TOFROM_GUEST hypercall). It has also since been added as a fast path for the kvmppc_ld/st routines which are used during instruction emulation. The commit def0bfdbd603 ("powerpc: use probe_user_read() and probe_user_write()") changed the low level copy function from raw_copy_from_user to probe_user_read, which adds a check to access_ok. In powerpc that is: static inline bool __access_ok(unsigned long addr, unsigned long size) { return addr < TASK_SIZE_MAX && size <= TASK_SIZE_MAX - addr; } and TASK_SIZE_MAX is 0x0010000000000000UL for 64-bit, which means that setting the two MSBs of the effective address (which correspond to the quadrant) now cause access_ok to reject the access. This was not caught earlier because the most common code path via kvmppc_ld/st contains a fallback (kvm_read_guest) that is likely to succeed for L1 guests. For nested guests there is no fallback. Another issue is that probe_user_read (now __copy_from_user_nofault) does not return the number of bytes not copied in case of failure, so the destination memory is not being cleared anymore in kvmhv_copy_from_guest_radix: ret = kvmhv_copy_tofrom_guest_radix(vcpu, eaddr, to, NULL, n); if (ret > 0) <-- always false! memset(to + (n - ret), 0, ret); This patch fixes both issues by skipping access_ok and open-coding the low level __copy_to/from_user_inatomic. Fixes: def0bfdbd603 ("powerpc: use probe_user_read() and probe_user_write()") Signed-off-by: Fabiano Rosas Reviewed-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210805212616.2641017-2-farosas@linux.ibm.com Signed-off-by: Sasha Levin commit 926bf91248dd12b5f93620a05f082c662b84db9d Author: Ahmad Fatoum Date: Tue Aug 10 17:14:33 2021 +0200 clk: imx8m: fix clock tree update of TF-A managed clocks [ Upstream commit d36207b848a6490e14664e2197a1c8ab51d8148e ] On the i.MX8M*, the TF-A exposes a SiP (Silicon Provider) service for DDR frequency scaling. The imx8m-ddrc-devfreq driver calls the SiP and then does clk_set_parent on the DDR muxes to synchronize the clock tree. Since 936c383673b9 ("clk: imx: fix composite peripheral flags"), these TF-A managed muxes have SET_PARENT_GATE set, which results in imx8m-ddrc-devfreq's clk_set_parent after SiP failing with -EBUSY: echo 25000000 > userspace/set_freq imx8m-ddrc-devfreq 3d400000.memory-controller: failed to set dram_apb parent: -16 Fix this by adding a new i.MX composite flag for firmware managed clocks, which clears SET_PARENT_GATE. This is safe to do, because updating the Linux clock tree to reflect reality will always be glitch-free. Fixes: 936c383673b9 ("clk: imx: fix composite peripheral flags") Signed-off-by: Ahmad Fatoum Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20210810151432.9228-1-a.fatoum@pengutronix.de Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin commit e84a72f6962180ff76343b49f9389b1f314e0123 Author: Jim Broadus Date: Sun Aug 8 23:55:05 2021 -0700 HID: i2c-hid: Fix Elan touchpad regression [ Upstream commit 786537063bbfb3a7ebc6fc21b2baf37fb91df401 ] A quirk was recently added for Elan devices that has same device match as an entry earlier in the list. The i2c_hid_lookup_quirk function will always return the last match in the list, so the new entry shadows the old entry. The quirk in the previous entry, I2C_HID_QUIRK_BOGUS_IRQ, silenced a flood of messages which have reappeared in the 5.13 kernel. This change moves the two quirk flags into the same entry. Fixes: ca66a6770bd9 (HID: i2c-hid: Skip ELAN power-on command after reset) Signed-off-by: Jim Broadus Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 253bac6c60ad317c805d3061aa813b74b8692b2a Author: Lu Baolu Date: Wed Aug 18 21:48:44 2021 +0800 iommu/vt-d: Update the virtual command related registers [ Upstream commit 4d99efb229e63928c6b03a756a2e38cd4777fbe8 ] The VT-d spec Revision 3.3 updated the virtual command registers, virtual command opcode B register, virtual command response register and virtual command capability register (Section 10.4.43, 10.4.44, 10.4.45, 10.4.46). This updates the virtual command interface implementation in the Intel IOMMU driver accordingly. Fixes: 24f27d32ab6b7 ("iommu/vt-d: Enlightened PASID allocation") Signed-off-by: Lu Baolu Cc: Ashok Raj Cc: Sanjay Kumar Cc: Kevin Tian Link: https://lore.kernel.org/r/20210713042649.3547403-1-baolu.lu@linux.intel.com Link: https://lore.kernel.org/r/20210818134852.1847070-2-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 947579a6967a651c3c33d983ecea9c2e6bfccbfb Author: Joel Stanley Date: Tue Aug 17 14:24:06 2021 +0930 powerpc/config: Renable MTD_PHYSMAP_OF [ Upstream commit d0e28a6145c3455b69991245e7f6147eb914b34a ] CONFIG_MTD_PHYSMAP_OF is not longer enabled as it depends on MTD_PHYSMAP which is not enabled. This is a regression from commit 642b1e8dbed7 ("mtd: maps: Merge physmap_of.c into physmap-core.c"), which added the extra dependency. Add CONFIG_MTD_PHYSMAP=y so this stays in the config, as Christophe said it is useful for build coverage. Fixes: 642b1e8dbed7 ("mtd: maps: Merge physmap_of.c into physmap-core.c") Signed-off-by: Joel Stanley Acked-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210817045407.2445664-3-joel@jms.id.au Signed-off-by: Sasha Levin commit 1bc19e4062e9a1bb23c019879bb18341721cd2b6 Author: Dan Carpenter Date: Tue Aug 10 11:51:49 2021 +0300 scsi: qedf: Fix error codes in qedf_alloc_global_queues() [ Upstream commit ccc89737aa6b9f248cf1623014038beb6c2b7f56 ] This driver has some left over "return 1" on failure style code mixed with "return negative error codes" style code. The caller doesn't care so we should just convert everything to return negative error codes. Then there was a problem that there were two variables used to store error codes which just resulted in confusion. If qedf_alloc_bdq() returned a negative error code, we accidentally returned success instead of propagating the error code. So get rid of the "rc" variable and use "status" every where. Also remove the "status = 0" initialization so that these sorts of bugs will be detected by the compiler in the future. Link: https://lore.kernel.org/r/20210810085023.GA23998@kili Fixes: 61d8658b4a43 ("scsi: qedf: Add QLogic FastLinQ offload FCoE driver framework.") Acked-by: Manish Rangankar Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit dc4577749987ef913b1b14b6a904c04ee5e1da26 Author: Dan Carpenter Date: Tue Aug 10 11:47:53 2021 +0300 scsi: qedi: Fix error codes in qedi_alloc_global_queues() [ Upstream commit 4dbe57d46d54a847875fa33e7d05877bb341585e ] This function had some left over code that returned 1 on error instead negative error codes. Convert everything to use negative error codes. The caller treats all non-zero returns the same so this does not affect run time. A couple places set "rc" instead of "status" so those error paths ended up returning success by mistake. Get rid of the "rc" variable and use "status" everywhere. Remove the bogus "status = 0" initialization, as a future proofing measure so the compiler will warn about uninitialized error codes. Link: https://lore.kernel.org/r/20210810084753.GD23810@kili Fixes: ace7f46ba5fd ("scsi: qedi: Add QLogic FastLinQ offload iSCSI driver framework.") Acked-by: Manish Rangankar Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 782c4017845d433862de03309582f4a7274c6a21 Author: Dan Carpenter Date: Tue Aug 10 11:46:13 2021 +0300 scsi: smartpqi: Fix an error code in pqi_get_raid_map() [ Upstream commit d1f6581a6796c4e9fd8a4a24e8b77463d18f0df1 ] Return -EINVAL on failure instead of success. Link: https://lore.kernel.org/r/20210810084613.GB23810@kili Fixes: a91aaae0243b ("scsi: smartpqi: allow for larger raid maps") Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 41066433be42e9c055a8fd3ff1c1315c20c13f93 Author: Laurent Dufour Date: Tue May 11 09:31:36 2021 +0200 powerpc/numa: Consider the max NUMA node for migratable LPAR [ Upstream commit 9c7248bb8de31f51c693bfa6a6ea53b1c07e0fa8 ] When a LPAR is migratable, we should consider the maximum possible NUMA node instead of the number of NUMA nodes from the actual system. The DT property 'ibm,current-associativity-domains' defines the maximum number of nodes the LPAR can see when running on that box. But if the LPAR is being migrated on another box, it may see up to the nodes defined by 'ibm,max-associativity-domains'. So if a LPAR is migratable, that value should be used. Unfortunately, there is no easy way to know if an LPAR is migratable or not. The hypervisor exports the property 'ibm,migratable-partition' in the case it set to migrate partition, but that would not mean that the current partition is migratable. Without this patch, when a LPAR is started on a 2 node box and then migrated to a 3 node box, the hypervisor may spread the LPAR's CPUs on the 3rd node. In that case if a CPU from that 3rd node is added to the LPAR, it will be wrongly assigned to the node because the kernel has been set to use up to 2 nodes (the configuration of the departure node). With this patch applies, the CPU is correctly added to the 3rd node. Fixes: f9f130ff2ec9 ("powerpc/numa: Detect support for coregroup") Signed-off-by: Laurent Dufour Reviewed-by: Srikar Dronamraju Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210511073136.17795-1-ldufour@linux.ibm.com Signed-off-by: Sasha Levin commit d3612083ecc1355fa85236e084b34b0d608279dd Author: Zhen Lei Date: Thu Jul 22 11:39:29 2021 +0800 pinctrl: single: Fix error return code in pcs_parse_bits_in_pinctrl_entry() [ Upstream commit d789a490d32fdf0465275e3607f8a3bc87d3f3ba ] Fix to return -ENOTSUPP instead of 0 when PCS_HAS_PINCONF is true, which is the same as that returned in pcs_parse_pinconf(). Fixes: 4e7e8017a80e ("pinctrl: pinctrl-single: enhance to configure multiple pins of different modules") Reported-by: Hulk Robot Signed-off-by: Zhen Lei Link: https://lore.kernel.org/r/20210722033930.4034-2-thunder.leizhen@huawei.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 6291fd0eeafc094d670232e3deade9bce8fe080a Author: Wei Li Date: Thu Jul 15 11:26:25 2021 +0800 scsi: fdomain: Fix error return code in fdomain_probe() [ Upstream commit 632c4ae6da1d629eddf9da1e692d7617c568c256 ] If request_region() fails the return value is not set. Return -EBUSY on error. Link: https://lore.kernel.org/r/20210715032625.1395495-1-liwei391@huawei.com Fixes: 8674a8aa2c39 ("scsi: fdomain: Add PCMCIA support") Reported-by: Hulk Robot Signed-off-by: Wei Li Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f02ab9d1d3a64f8d6bb4294295770fc897fa736f Author: Anna Schumaker Date: Tue Jul 20 16:04:42 2021 -0400 sunrpc: Fix return value of get_srcport() [ Upstream commit 5d46dd04cb68771f77ba66dbf6fd323a4a2ce00d ] Since bc1c56e9bbe9 transport->srcport may by unset, causing get_srcport() to return 0 when called. Fix this by querying the port from the underlying socket instead of the transport. Fixes: bc1c56e9bbe9 (SUNRPC: prevent port reuse on transports which don't request it) Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 21a2be1a5145d072deedc7cdc5b2d17380abea75 Author: Olga Kornievskaia Date: Wed Jun 23 23:28:48 2021 -0400 SUNRPC query transport's source port [ Upstream commit a8482488a7d6d320f63a9ee1912dbb5ae5b80a61 ] Provide ability to query transport's source port. Signed-off-by: Olga Kornievskaia Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit f19abe046354fb3c1578008c626b2e036a763f39 Author: Trond Myklebust Date: Mon Jul 26 08:03:12 2021 -0400 SUNRPC/xprtrdma: Fix reconnection locking [ Upstream commit f99fa50880f5300fbbb3c0754ddc7f8738d24fe7 ] The xprtrdma client code currently relies on the task that initiated the connect to hold the XPRT_LOCK for the duration of the connection attempt. If the task is woken early, due to some other event, then that lock could get released early. Avoid races by using the same mechanism that the socket code uses of transferring lock ownership to the RDMA connect worker itself. That frees us to call rpcrdma_xprt_disconnect() directly since we're now guaranteed exclusion w.r.t. other callers. Fixes: 4cf44be6f1e8 ("xprtrdma: Fix recursion into rpcrdma_xprt_disconnect()") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit f3d30161278776fb0a4a163c05f44a55acc47f1b Author: Trond Myklebust Date: Mon Jul 26 07:59:23 2021 -0400 SUNRPC: Fix potential memory corruption [ Upstream commit c2dc3e5fad13aca5d7bdf4bcb52b1a1d707c8555 ] We really should not call rpc_wake_up_queued_task_set_status() with xprt->snd_task as an argument unless we are certain that is actually an rpc_task. Fixes: 0445f92c5d53 ("SUNRPC: Fix disconnection races") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 9aa7a3ffb11c8b2e4004a9471cac59c19475b006 Author: Trond Myklebust Date: Fri Jul 23 08:57:21 2021 -0400 NFSv4/pnfs: The layout barrier indicate a minimal value for the seqid [ Upstream commit d6236a98b3bab07c0a1455fd1ab46f79c3978cdc ] The intention of the layout barrier is to ensure that we do not update the layout to match an older value than the current expectation. Fix the test in pnfs_layout_stateid_blocked() to reflect that it is legal for the seqid of the stateid to match that of the barrier. Fixes: aa95edf309ef ("NFSv4/pnfs: Fix the layout barrier update") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 2a542421eb7f489af1ff7672fa2d474870780182 Author: Trond Myklebust Date: Fri Jul 23 08:57:20 2021 -0400 NFSv4/pNFS: Always allow update of a zero valued layout barrier [ Upstream commit 45baadaad7bf9183651fb74f4ed1200da48505a5 ] A zero value for the layout barrier indicates that it has been cleared (since seqid '0' is an illegal value), so we should always allow it to be updated. Fixes: d29b468da4f9 ("pNFS/NFSv4: Improve rejection of out-of-order layouts") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 4b96edea5cd1b77bef855a51ecabfb3579f8b7bc Author: Trond Myklebust Date: Mon Jul 26 07:58:49 2021 -0400 NFSv4/pNFS: Fix a layoutget livelock loop [ Upstream commit e20772cbdf463c12088837e5a08bde1b876bfd25 ] If NFS_LAYOUT_RETURN_REQUESTED is set, but there is no value set for the layout plh_return_seq, we can end up in a livelock loop in which every layout segment retrieved by a new call to layoutget is immediately invalidated by pnfs_layout_need_return(). To get around this, we should just set plh_return_seq to the current value of the layout stateid's seqid. Fixes: d474f96104bd ("NFS: Don't return layout segments that are in use") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit fa55e76641d80b36994904c7dff7ec9b3d91b8a3 Author: Anthony Iliopoulos Date: Thu Jul 22 16:10:55 2021 +0200 dma-debug: fix debugfs initialization order [ Upstream commit 173735c346c412d9f084825ecb04f24ada0e2986 ] Due to link order, dma_debug_init is called before debugfs has a chance to initialize (via debugfs_init which also happens in the core initcall stage), so the directories for dma-debug are never created. Decouple dma_debug_fs_init from dma_debug_init and defer its init until core_initcall_sync (after debugfs has been initialized) while letting dma-debug initialization occur as soon as possible to catch any early mappings, as suggested in [1]. [1] https://lore.kernel.org/linux-iommu/YIgGa6yF%2Fadg8OSN@kroah.com/ Fixes: 15b28bbcd567 ("dma-debug: move initialization to common code") Signed-off-by: Anthony Iliopoulos Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit ca7f7e37bae4e3aa1d01536c5907131796b49136 Author: Randy Dunlap Date: Sun Jul 18 19:33:09 2021 -0700 openrisc: don't printk() unconditionally [ Upstream commit 946e1052cdcc7e585ee5d1e72528ca49fb295243 ] Don't call printk() when CONFIG_PRINTK is not set. Fixes the following build errors: or1k-linux-ld: arch/openrisc/kernel/entry.o: in function `_external_irq_handler': (.text+0x804): undefined reference to `printk' (.text+0x804): relocation truncated to fit: R_OR1K_INSN_REL_26 against undefined symbol `printk' Fixes: 9d02a4283e9c ("OpenRISC: Boot code") Signed-off-by: Randy Dunlap Reported-by: kernel test robot Cc: Jonas Bonn Cc: Stefan Kristiansson Cc: Stafford Horne Cc: openrisc@lists.librecores.org Signed-off-by: Stafford Horne Signed-off-by: Sasha Levin commit 31fd3211ef8b20855bab22a315f09c37512a22a1 Author: Yangtao Li Date: Wed Aug 4 11:29:46 2021 +0800 f2fs: reduce the scope of setting fsck tag when de->name_len is zero [ Upstream commit d4bf15a7ce172d186d400d606adf4f34a59130d6 ] I recently found a case where de->name_len is 0 in f2fs_fill_dentries() easily reproduced, and finally set the fsck flag. Thread A Thread B - f2fs_readdir - f2fs_read_inline_dir - ctx->pos = d.max - f2fs_add_dentry - f2fs_add_inline_entry - do_convert_inline_dir - f2fs_add_regular_entry - f2fs_readdir - f2fs_fill_dentries - set_sbi_flag(sbi, SBI_NEED_FSCK) Process A opens the folder, and has been reading without closing it. During this period, Process B created a file under the folder (occupying multiple f2fs_dir_entry, exceeding the d.max of the inline dir). After creation, process A uses the d.max of inline dir to read it again, and it will read that de->name_len is 0. And Chao pointed out that w/o inline conversion, the race condition still can happen as below: dir_entry1: A dir_entry2: B dir_entry3: C free slot: _ ctx->pos: ^ Thread A is traversing directory, ctx-pos moves to below position after readdir() by thread A: AAAABBBB___ ^ Then thread B delete dir_entry2, and create dir_entry3. Thread A calls readdir() to lookup dirents starting from middle of new dirent slots as below: AAAACCCCCC_ ^ In these scenarios, the file system is not damaged, and it's hard to avoid it. But we can bypass tagging FSCK flag if: a) bit_pos (:= ctx->pos % d->max) is non-zero and b) before bit_pos moves to first valid dir_entry. Fixes: ddf06b753a85 ("f2fs: fix to trigger fsck if dirent.name_len is zero") Signed-off-by: Yangtao Li [Chao: clean up description] Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 49e4c83db88537b23a1f662b234776c73b97e3aa Author: Nathan Chancellor Date: Tue Aug 3 14:15:47 2021 -0700 cpuidle: pseries: Mark pseries_idle_proble() as __init [ Upstream commit d04691d373e75c83424b85c0e68e4a3f9370c10d ] After commit 7cbd631d4dec ("cpuidle: pseries: Fixup CEDE0 latency only for POWER10 onwards"), pseries_idle_probe() is no longer inlined when compiling with clang, which causes a modpost warning: WARNING: modpost: vmlinux.o(.text+0xc86a54): Section mismatch in reference from the function pseries_idle_probe() to the function .init.text:fixup_cede0_latency() The function pseries_idle_probe() references the function __init fixup_cede0_latency(). This is often because pseries_idle_probe lacks a __init annotation or the annotation of fixup_cede0_latency is wrong. pseries_idle_probe() is a non-init function, which calls fixup_cede0_latency(), which is an init function, explaining the mismatch. pseries_idle_probe() is only called from pseries_processor_idle_init(), which is an init function, so mark pseries_idle_probe() as __init so there is no more warning. Fixes: 054e44ba99ae ("cpuidle: pseries: Add function to parse extended CEDE records") Signed-off-by: Nathan Chancellor Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210803211547.1093820-1-nathan@kernel.org Signed-off-by: Sasha Levin commit 876e45c95eb61b4af69bed05e78d2927979993f5 Author: Leon Romanovsky Date: Tue Aug 3 21:20:32 2021 +0300 RDMA/mlx5: Delete not-available udata check [ Upstream commit 5f6bb7e32283b8e3339b7adc00638234ac199cc4 ] XRC_TGT QPs are created through kernel verbs and don't have udata at all. Fixes: 6eefa839c4dd ("RDMA/mlx5: Protect from kernel crash if XRC_TGT doesn't have udata") Fixes: e383085c2425 ("RDMA/mlx5: Set ECE options during QP create") Link: https://lore.kernel.org/r/b68228597e730675020aa5162745390a2d39d3a2.1628014762.git.leonro@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit a77da9de0d7d2f5a2db590451b9d102868a552c6 Author: Leon Romanovsky Date: Fri Jul 23 14:39:45 2021 +0300 RDMA/efa: Remove double QP type assignment [ Upstream commit f9193d266347fe9bed5c173e7a1bf96268142a79 ] The QP type is set by the IB/core and shouldn't be set in the driver. Fixes: 40909f664d27 ("RDMA/efa: Add EFA verbs implementation") Link: https://lore.kernel.org/r/838c40134c1590167b888ca06ad51071139ff2ae.1627040189.git.leonro@nvidia.com Acked-by: Gal Pressman Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 1988836e30c503a820c2cc5211955e2efaf59bfb Author: Michal Suchanek Date: Thu Jul 29 20:01:03 2021 +0200 powerpc/stacktrace: Include linux/delay.h [ Upstream commit a6cae77f1bc89368a4e2822afcddc45c3062d499 ] commit 7c6986ade69e ("powerpc/stacktrace: Fix spurious "stale" traces in raise_backtrace_ipi()") introduces udelay() call without including the linux/delay.h header. This may happen to work on master but the header that declares the functionshould be included nonetheless. Fixes: 7c6986ade69e ("powerpc/stacktrace: Fix spurious "stale" traces in raise_backtrace_ipi()") Signed-off-by: Michal Suchanek Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210729180103.15578-1-msuchanek@suse.de Signed-off-by: Sasha Levin commit c5a5528da7228618979bc374f1bc03ad9b69b458 Author: Gautham R. Shenoy Date: Mon Jul 19 12:03:18 2021 +0530 cpuidle: pseries: Fixup CEDE0 latency only for POWER10 onwards [ Upstream commit 50741b70b0cbbafbd9199f5180e66c0c53783a4a ] Commit d947fb4c965c ("cpuidle: pseries: Fixup exit latency for CEDE(0)") sets the exit latency of CEDE(0) based on the latency values of the Extended CEDE states advertised by the platform On POWER9 LPARs, the firmwares advertise a very low value of 2us for CEDE1 exit latency on a Dedicated LPAR. The latency advertized by the PHYP hypervisor corresponds to the latency required to wakeup from the underlying hardware idle state. However the wakeup latency from the LPAR perspective should include 1. The time taken to transition the CPU from the Hypervisor into the LPAR post wakeup from platform idle state 2. Time taken to send the IPI from the source CPU (waker) to the idle target CPU (wakee). 1. can be measured via timer idle test, where we queue a timer, say for 1ms, and enter the CEDE state. When the timer fires, in the timer handler we compute how much extra timer over the expected 1ms have we consumed. On a a POWER9 LPAR the numbers are CEDE latency measured using a timer (numbers in ns) N Min Median Avg 90%ile 99%ile Max Stddev 400 2601 5677 5668.74 5917 6413 9299 455.01 1. and 2. combined can be determined by an IPI latency test where we send an IPI to an idle CPU and in the handler compute the time difference between when the IPI was sent and when the handler ran. We see the following numbers on POWER9 LPAR. CEDE latency measured using an IPI (numbers in ns) N Min Median Avg 90%ile 99%ile Max Stddev 400 711 7564 7369.43 8559 9514 9698 1200.01 Suppose, we consider the 99th percentile latency value measured using the IPI to be the wakeup latency, the value would be 9.5us This is in the ballpark of the default value of 10us. Hence, use the exit latency of CEDE(0) based on the latency values advertized by platform only from POWER10 onwards. The values advertized on POWER10 platforms is more realistic and informed by the latency measurements. For earlier platforms stick to the default value of 10us. The fix was suggested by Michael Ellerman. Fixes: d947fb4c965c ("cpuidle: pseries: Fixup exit latency for CEDE(0)") Reported-by: Enrico Joedecke Signed-off-by: Gautham R. Shenoy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/1626676399-15975-2-git-send-email-ego@linux.vnet.ibm.com Signed-off-by: Sasha Levin commit 3b2bbcccd6e9a19c552e720da3af83cd48b75f98 Author: Bart Van Assche Date: Wed Jul 21 20:34:22 2021 -0700 scsi: ufs: Fix memory corruption by ufshcd_read_desc_param() [ Upstream commit d3d9c4570285090b533b00946b72647361f0345b ] If param_offset > buff_len then the memcpy() statement in ufshcd_read_desc_param() corrupts memory since it copies 256 + buff_len - param_offset bytes into a buffer with size buff_len. Since param_offset < 256 this results in writing past the bound of the output buffer. Link: https://lore.kernel.org/r/20210722033439.26550-2-bvanassche@acm.org Fixes: cbe193f6f093 ("scsi: ufs: Fix potential NULL pointer access during memcpy") Reviewed-by: Avri Altman Reviewed-by: Daejun Park Signed-off-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit d353e093c0d5cb5c7d5e6c4c4327d2da7d8104f1 Author: Jason Gunthorpe Date: Fri Jul 16 15:39:12 2021 -0300 vfio: Use config not menuconfig for VFIO_NOIOMMU [ Upstream commit 26c22cfde5dd6e63f25c48458b0185dcb0fbb2fd ] VFIO_NOIOMMU is supposed to be an element in the VFIO menu, not start a new menu. Correct this copy-paste mistake. Fixes: 03a76b60f8ba ("vfio: Include No-IOMMU mode") Signed-off-by: Jason Gunthorpe Reviewed-by: Cornelia Huck Link: https://lore.kernel.org/r/0-v1-3f0b685c3679+478-vfio_menuconfig_jgg@nvidia.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 0f711378f0b1e80b9d2edd28a959ab4f71194e92 Author: Jaehyoung Choi Date: Fri Jul 30 22:29:05 2021 +0300 pinctrl: samsung: Fix pinctrl bank pin count [ Upstream commit 70115558ab02fe8d28a6634350b3491a542aaa02 ] Commit 1abd18d1a51a ("pinctrl: samsung: Register pinctrl before GPIO") changes the order of GPIO and pinctrl registration: now pinctrl is registered before GPIO. That means gpio_chip->ngpio is not set when samsung_pinctrl_register() called, and one cannot rely on that value anymore. Use `pin_bank->nr_pins' instead of `pin_bank->gpio_chip.ngpio' to fix mentioned inconsistency. Fixes: 1abd18d1a51a ("pinctrl: samsung: Register pinctrl before GPIO") Signed-off-by: Jaehyoung Choi Signed-off-by: Sam Protsenko Link: https://lore.kernel.org/r/20210730192905.7173-1-semen.protsenko@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 59137b7dfff1ac1fe84537d5dbe18a4e72b41917 Author: Colin Ian King Date: Fri Jul 30 10:50:31 2021 +0100 scsi: BusLogic: Use %X for u32 sized integer rather than %lX [ Upstream commit 2127cd21fb78c6e22d92944253afd967b0ff774d ] An earlier fix changed the print format specifier for adapter->bios_addr to use %lX. However, the integer is a u32 so the fix was wrong. Fix this by using the correct %X format specifier. Link: https://lore.kernel.org/r/20210730095031.26981-1-colin.king@canonical.com Fixes: 43622697117c ("scsi: BusLogic: use %lX for unsigned long rather than %X") Acked-by: Khalid Aziz Signed-off-by: Colin Ian King Signed-off-by: Martin K. Petersen Addresses-Coverity: ("Invalid type in argument") Signed-off-by: Sasha Levin commit 8ea3e622af56b6f5aa92e78d2b3d31603c6b5c6f Author: Leon Romanovsky Date: Wed Jul 28 16:04:12 2021 +0300 docs: Fix infiniband uverbs minor number [ Upstream commit 8d7e415d55610d503fdb8815344846b72d194a40 ] Starting from the beginning of infiniband subsystem, the uverbs char devices start from 192 as a minor number, see commit bc38a6abdd5a ("[PATCH] IB uverbs: core implementation"). This patch updates the admin guide documentation to reflect it. Fixes: 9d85025b0418 ("docs-rst: create an user's manual book") Link: https://lore.kernel.org/r/bad03e6bcde45550c01e12908a6fe7dfa4770703.1627477347.git.leonro@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit fe2a1cd62267c3afe233221b10df1f58e17da0f5 Author: Leon Romanovsky Date: Fri Jul 23 17:08:55 2021 +0300 RDMA/iwcm: Release resources if iw_cm module initialization fails [ Upstream commit e677b72a0647249370f2635862bf0241c86f66ad ] The failure during iw_cm module initialization partially left the system with unreleased memory and other resources. Rewrite the module init/exit routines in such way that netlink commands will be opened only after successful initialization. Fixes: b493d91d333e ("iwcm: common code for port mapper") Link: https://lore.kernel.org/r/b01239f99cb1a3e6d2b0694c242d89e6410bcd93.1627048781.git.leonro@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit b824bae96f7391ac8419e622c28141b8739c7fe9 Author: Mike Marciniszyn Date: Thu Jul 15 12:04:45 2021 -0400 IB/hfi1: Adjust pkey entry in index 0 [ Upstream commit 62004871e1fa7f9a60797595c03477af5b5ec36f ] It is possible for the primary IPoIB network device associated with any RDMA device to fail to join certain multicast groups preventing IPv6 neighbor discovery and possibly other network ULPs from working correctly. The IPv4 broadcast group is not affected as the IPoIB network device handles joining that multicast group directly. This is because the primary IPoIB network device uses the pkey at ndex 0 in the associated RDMA device's pkey table. Anytime the pkey value of index 0 changes, the primary IPoIB network device automatically modifies it's broadcast address (i.e. /sys/class/net/[ib0]/broadcast), since the broadcast address includes the pkey value, and then bounces carrier. This includes initial pkey assignment, such as when the pkey at index 0 transitions from the opa default of invalid (0x0000) to some value such as the OPA default pkey for Virtual Fabric 0: 0x8001 or when the fabric manager is restarted with a configuration change causing the pkey at index 0 to change. Many network ULPs are not sensitive to the carrier bounce and are not expecting the broadcast address to change including the linux IPv6 stack. This problem does not affect IPoIB child network devices as their pkey value is constant for all time. To mitigate this issue, change the default pkey in at index 0 to 0x8001 to cover the predominant case and avoid issues as ipoib comes up and the FM sweeps. At some point, ipoib multicast support should automatically fix non-broadcast addresses as it does with the primary broadcast address. Fixes: 7724105686e7 ("IB/hfi1: add driver files") Link: https://lore.kernel.org/r/20210715160445.142451.47651.stgit@awfm-01.cornelisnetworks.com Suggested-by: Josh Collier Signed-off-by: Mike Marciniszyn Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 273ed4f47e6f02303bd7998ceee1431349674f43 Author: Peter Geis Date: Wed Jul 28 14:00:28 2021 -0400 clk: rockchip: drop GRF dependency for rk3328/rk3036 pll types [ Upstream commit 6fffe52fb336ec2063270a7305652a93ea677ca1 ] The rk3036/rk3328 pll types were converted to checking the lock status via the internal register in january 2020, so don't need the grf reference since then. But it was forgotten to remove grf check when deciding between the pll rate ops (read-only vs. read-write), so a clock driver without the needed grf reference might've been put into the read-only mode just because the grf reference was missing. This affected the rk356x that needs to reclock certain plls at boot. Fix this by removing the check for the grf for selecting the utilized operations. Suggested-by: Heiko Stuebner Fixes: 7f6ffbb885d1 ("clk: rockchip: convert rk3036 pll type to use internal lock status") Signed-off-by: Peter Geis [adjusted the commit message, adjusted the fixes tag] Link: https://lore.kernel.org/r/20210728180034.717953-3-pgwipeout@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit f1eccc40816852e8a74a70cace71bdff336e14cb Author: Christoph Hellwig Date: Sat Jul 24 09:20:10 2021 +0200 scsi: bsg: Remove support for SCSI_IOCTL_SEND_COMMAND [ Upstream commit beec64d0c9749afedf51c3c10cf52de1d9a89cc0 ] SCSI_IOCTL_SEND_COMMAND has been deprecated longer than bsg exists and has been warning for just as long. More importantly it harcodes SCSI CDBs and thus will do the wrong thing on non-SCSI bsg nodes. Link: https://lore.kernel.org/r/20210724072033.1284840-2-hch@lst.de Fixes: aa387cc89567 ("block: add bsg helper library") Reviewed-by: Bart Van Assche Acked-by: Jens Axboe Signed-off-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ef5395fbadac89af2c4e20b3b6c449ad51c4e085 Author: Marek Behún Date: Mon Jul 19 13:29:38 2021 +0200 pinctrl: armada-37xx: Correct PWM pins definitions [ Upstream commit baf8d6899b1e8906dc076ef26cc633e96a8bb0c3 ] The PWM pins on North Bridge on Armada 37xx can be configured into PWM or GPIO functions. When in PWM function, each pin can also be configured to drive low on 0 and tri-state on 1 (LED mode). The current definitions handle this by declaring two pin groups for each pin: - group "pwmN" with functions "pwm" and "gpio" - group "ledN_od" ("od" for open drain) with functions "led" and "gpio" This is semantically incorrect. The correct definition for each pin should be one group with three functions: "pwm", "led" and "gpio". Change the "pwmN" groups to support "led" function. Remove "ledN_od" groups. This cannot break backwards compatibility with older device trees: no device tree uses it since there is no PWM driver for this SOC yet. Also "ledN_od" groups are not even documented. Fixes: b835d6953009 ("pinctrl: armada-37xx: swap polarity on LED group") Signed-off-by: Marek Behún Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210719112938.27594-1-kabel@kernel.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 782ceaba977c4ef5b8e124f939c6e44524c18560 Author: Zhaoyu Liu Date: Sun Dec 20 16:37:19 2020 +0800 pinctrl: remove empty lines in pinctrl subsystem [ Upstream commit 43878eb7c83d3335af7737dcce1fa79071065dfe ] Remove all empty lines at the end of functions in pinctrl subsystem, and make the code neat. Reviewed-by: Bjorn Andersson Reviewed-by: Geert Uytterhoeven Reviewed-by: Linus Walleij Reviewed-by: Andy Shevchenko Signed-off-by: Zhaoyu Liu Link: https://lore.kernel.org/r/X98NP6NFK1Afzrgd@manjaro Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 2d586a3f5b7ec2f5a939db4abc9aa053c237545c Author: Chao Yu Date: Mon Jul 19 16:46:47 2021 +0800 f2fs: quota: fix potential deadlock [ Upstream commit 9de71ede81e6d1a111fdd868b2d78d459fa77f80 ] xfstest generic/587 reports a deadlock issue as below: ====================================================== WARNING: possible circular locking dependency detected 5.14.0-rc1 #69 Not tainted ------------------------------------------------------ repquota/8606 is trying to acquire lock: ffff888022ac9320 (&sb->s_type->i_mutex_key#18){+.+.}-{3:3}, at: f2fs_quota_sync+0x207/0x300 [f2fs] but task is already holding lock: ffff8880084bcde8 (&sbi->quota_sem){.+.+}-{3:3}, at: f2fs_quota_sync+0x59/0x300 [f2fs] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&sbi->quota_sem){.+.+}-{3:3}: __lock_acquire+0x648/0x10b0 lock_acquire+0x128/0x470 down_read+0x3b/0x2a0 f2fs_quota_sync+0x59/0x300 [f2fs] f2fs_quota_on+0x48/0x100 [f2fs] do_quotactl+0x5e3/0xb30 __x64_sys_quotactl+0x23a/0x4e0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #1 (&sbi->cp_rwsem){++++}-{3:3}: __lock_acquire+0x648/0x10b0 lock_acquire+0x128/0x470 down_read+0x3b/0x2a0 f2fs_unlink+0x353/0x670 [f2fs] vfs_unlink+0x1c7/0x380 do_unlinkat+0x413/0x4b0 __x64_sys_unlinkat+0x50/0xb0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #0 (&sb->s_type->i_mutex_key#18){+.+.}-{3:3}: check_prev_add+0xdc/0xb30 validate_chain+0xa67/0xb20 __lock_acquire+0x648/0x10b0 lock_acquire+0x128/0x470 down_write+0x39/0xc0 f2fs_quota_sync+0x207/0x300 [f2fs] do_quotactl+0xaff/0xb30 __x64_sys_quotactl+0x23a/0x4e0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae other info that might help us debug this: Chain exists of: &sb->s_type->i_mutex_key#18 --> &sbi->cp_rwsem --> &sbi->quota_sem Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&sbi->quota_sem); lock(&sbi->cp_rwsem); lock(&sbi->quota_sem); lock(&sb->s_type->i_mutex_key#18); *** DEADLOCK *** 3 locks held by repquota/8606: #0: ffff88801efac0e0 (&type->s_umount_key#53){++++}-{3:3}, at: user_get_super+0xd9/0x190 #1: ffff8880084bc380 (&sbi->cp_rwsem){++++}-{3:3}, at: f2fs_quota_sync+0x3e/0x300 [f2fs] #2: ffff8880084bcde8 (&sbi->quota_sem){.+.+}-{3:3}, at: f2fs_quota_sync+0x59/0x300 [f2fs] stack backtrace: CPU: 6 PID: 8606 Comm: repquota Not tainted 5.14.0-rc1 #69 Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 Call Trace: dump_stack_lvl+0xce/0x134 dump_stack+0x17/0x20 print_circular_bug.isra.0.cold+0x239/0x253 check_noncircular+0x1be/0x1f0 check_prev_add+0xdc/0xb30 validate_chain+0xa67/0xb20 __lock_acquire+0x648/0x10b0 lock_acquire+0x128/0x470 down_write+0x39/0xc0 f2fs_quota_sync+0x207/0x300 [f2fs] do_quotactl+0xaff/0xb30 __x64_sys_quotactl+0x23a/0x4e0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f883b0b4efe The root cause is ABBA deadlock of inode lock and cp_rwsem, reorder locks in f2fs_quota_sync() as below to fix this issue: - lock inode - lock cp_rwsem - lock quota_sem Fixes: db6ec53b7e03 ("f2fs: add a rw_sem to cover quota flag changes") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 70fd9363673bcf3fafcb1e5075426602496a67a0 Author: Dmitry Torokhov Date: Tue Jun 29 11:25:50 2021 -0700 HID: input: do not report stylus battery state as "full" [ Upstream commit f4abaa9eebde334045ed6ac4e564d050f1df3013 ] The power supply states of discharging, charging, full, etc, represent state of charging, not the capacity level of the battery (for which we have a separate property). Current HID usage tables to not allow for expressing charging state of the batteries found in generic styli, so we should simply assume that the battery is discharging even if current capacity is at 100% when battery strength reporting is done via HID interface. In fact, we were doing just that before commit 581c4484769e. This change helps UIs to not mis-represent fully charged batteries in styli as being charging/topping-off. Fixes: 581c4484769e ("HID: input: map digitizer battery usage") Reported-by: Kenneth Albanowski Signed-off-by: Dmitry Torokhov Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 4e89aea738b5db125471c838f4544b64fd4b3776 Author: Pali Rohár Date: Fri Aug 20 17:50:20 2021 +0200 PCI: aardvark: Fix masking and unmasking legacy INTx interrupts commit d212dcee27c1f89517181047e5485fcbba4a25c2 upstream. irq_mask and irq_unmask callbacks need to be properly guarded by raw spin locks as masking/unmasking procedure needs atomic read-modify-write operation on hardware register. Link: https://lore.kernel.org/r/20210820155020.3000-1-pali@kernel.org Reported-by: Marc Zyngier Signed-off-by: Pali Rohár Signed-off-by: Lorenzo Pieralisi Acked-by: Marc Zyngier Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b50db4c