commit d6fc894baac777c38a95a31f65343bea8b1a2678 Author: Greg Kroah-Hartman Date: Wed Jul 14 17:07:52 2021 +0200 Linux 5.13.2 Link: https://lore.kernel.org/r/20210712060912.995381202@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Fox Chen Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Shuah Khan Tested-by: Linux Kernel Functional Testing Tested-by: Justin M. Forbes Signed-off-by: Greg Kroah-Hartman commit 20a015e948b825afb47855de2efce7cae7c2608f Author: Valentin Schneider Date: Wed Jul 7 19:38:31 2021 +0100 powerpc/preempt: Don't touch the idle task's preempt_count during hotplug commit 2c669ef6979c370f98d4b876e54f19613c81e075 upstream. Powerpc currently resets a CPU's idle task preempt_count to 0 before said task starts executing the secondary startup routine (and becomes an idle task proper). This conflicts with commit f1a0a376ca0c ("sched/core: Initialize the idle task with preemption disabled"). which initializes all of the idle tasks' preempt_count to PREEMPT_DISABLED during smp_init(). Note that this was superfluous before said commit, as back then the hotplug machinery would invoke init_idle() via idle_thread_get(), which would have already reset the CPU's idle task's preempt_count to PREEMPT_ENABLED. Get rid of this preempt_count write. Fixes: f1a0a376ca0c ("sched/core: Initialize the idle task with preemption disabled") Reported-by: Bharata B Rao Signed-off-by: Valentin Schneider Tested-by: Guenter Roeck Tested-by: Bharata B Rao Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210707183831.2106509-1-valentin.schneider@arm.com Signed-off-by: Greg Kroah-Hartman commit 51189a3c6e5417491382e7c5b58d9ff126c2e193 Author: Joerg Roedel Date: Mon Jun 7 14:49:05 2021 +0200 iommu/dma: Fix compile warning in 32-bit builds commit 7154cbd31c2069726cf730b0ed94e2e79a221602 upstream. Compiling the recent dma-iommu changes under 32-bit x86 triggers this compile warning: drivers/iommu/dma-iommu.c:249:5: warning: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘phys_addr_t’ {aka ‘unsigned int’} [-Wformat=] The reason is that %llx is used to print a variable of type phys_addr_t. Fix it by using the correct %pa format specifier for phys_addr_t. Cc: Srinath Mannam Cc: Robin Murphy Cc: Oza Pawandeep Fixes: 571f316074a20 ("iommu/dma: Fix IOVA reserve dma ranges") Signed-off-by: Joerg Roedel Link: https://lore.kernel.org/r/20210607124905.27525-1-joro@8bytes.org Signed-off-by: Greg Kroah-Hartman commit 572b2a62a94fb292b3516bccc4e122108f3192f2 Author: Yang Yingliang Date: Wed May 26 22:38:05 2021 +0800 cred: add missing return error code when set_cred_ucounts() failed commit 5e6b8a50a7cec5686ee2c4bda1d49899c79a7eae upstream. If set_cred_ucounts() failed, we need return the error code. Fixes: 905ae01c4ae2 ("Add a reference to ucounts for each cred") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Link: https://lkml.kernel.org/r/20210526143805.2549649-1-yangyingliang@huawei.com Reviewed-by: Alexey Gladkov Signed-off-by: Eric W. Biederman Signed-off-by: Greg Kroah-Hartman commit c3f65e8e26eefda0044b230eb3ae57d44c02e5db Author: Frederic Weisbecker Date: Wed May 26 01:58:49 2021 +0200 sched: Stop PF_NO_SETAFFINITY from being inherited by various init system threads commit a8ea6fc9b089156d9230bfeef964dd9be101a4a9 upstream. Commit: 00b89fe0197f ("sched: Make the idle task quack like a per-CPU kthread") ... added PF_KTHREAD | PF_NO_SETAFFINITY to the idle kernel threads. Unfortunately these properties are inherited to the init/0 children through kernel_thread() calls: init/1 and kthreadd. There are several side effects to that: 1) kthreadd affinity can not be reset anymore from userspace. Also PF_NO_SETAFFINITY propagates to all kthreadd children, including the unbound kthreads Therefore it's not possible anymore to overwrite the affinity of any of them. Here is an example of warning reported by rcutorture: WARNING: CPU: 0 PID: 116 at kernel/rcu/tree_nocb.h:1306 rcu_bind_current_to_nocb+0x31/0x40 Call Trace: rcu_torture_fwd_prog+0x62/0x730 kthread+0x122/0x140 ret_from_fork+0x22/0x30 2) init/1 does an exec() in the end which clears both PF_KTHREAD and PF_NO_SETAFFINITY so we are fine once kernel_init() escapes to userspace. But until then, no initcall or init code can successfully call sched_setaffinity() to init/1. Also PF_KTHREAD looks legit on init/1 before it calls exec() but we better be careful with unknown introduced side effects. One way to solve the PF_NO_SETAFFINITY issue is to not inherit this flag on copy_process() at all. The cases where it matters are: * fork_idle(): explicitly set the flag already. * fork() syscalls: userspace tasks that shouldn't be concerned by that. * create_io_thread(): the callers explicitly attribute the flag to the newly created tasks. * kernel_thread(): - Fix the issues on init/1 and kthreadd - Fix the issues on kthreadd children. - Usermode helper created by an unbound workqueue. This shouldn't matter. In the worst case it gives more control to userspace on setting affinity to these short living tasks although this can be tuned with inherited unbound workqueues affinity already. Fixes: 00b89fe0197f ("sched: Make the idle task quack like a per-CPU kthread") Reported-by: Paul E. McKenney Signed-off-by: Frederic Weisbecker Signed-off-by: Ingo Molnar Tested-by: Paul E. McKenney Link: https://lore.kernel.org/r/20210525235849.441842-1-frederic@kernel.org Signed-off-by: Greg Kroah-Hartman commit f13f01567321aa01db631da780d86eca5b13ea59 Author: Valentin Schneider Date: Wed Jul 7 17:33:38 2021 +0100 s390: preempt: Fix preempt_count initialization commit 6a942f5780545ebd11aca8b3ac4b163397962322 upstream. S390's init_idle_preempt_count(p, cpu) doesn't actually let us initialize the preempt_count of the requested CPU's idle task: it unconditionally writes to the current CPU's. This clearly conflicts with idle_threads_init(), which intends to initialize *all* the idle tasks, including their preempt_count (or their CPU's, if the arch uses a per-CPU preempt_count). Unfortunately, it seems the way s390 does things doesn't let us initialize every possible CPU's preempt_count early on, as the pages where this resides are only allocated when a CPU is brought up and are freed when it is brought down. Let the arch-specific code set a CPU's preempt_count when its lowcore is allocated, and turn init_idle_preempt_count() into an empty stub. Fixes: f1a0a376ca0c ("sched/core: Initialize the idle task with preemption disabled") Reported-by: Guenter Roeck Signed-off-by: Valentin Schneider Tested-by: Guenter Roeck Reviewed-by: Heiko Carstens Link: https://lore.kernel.org/r/20210707163338.1623014-1-valentin.schneider@arm.com Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit fbbd050e05d10035293a080dc70c303caa9263d7 Author: Wei Yongjun Date: Wed Jun 2 11:36:45 2021 +0000 crypto: qce - fix error return code in qce_skcipher_async_req_handle() commit a8bc4f5e7a72e4067f5afd7e98b61624231713ca upstream. Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 1339a7c3ba05 ("crypto: qce: skcipher: Fix incorrect sg count for dma transfers") Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Reviewed-by: Thara Gopinath Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit bd619678f6745c714ff490989037ccf2554ca7b1 Author: Quat Le Date: Tue Jun 29 08:58:26 2021 -0700 scsi: core: Retry I/O for Notify (Enable Spinup) Required error commit 104739aca4488909175e9e31d5cd7d75b82a2046 upstream. If the device is power-cycled, it takes time for the initiator to transmit the periodic NOTIFY (ENABLE SPINUP) SAS primitive, and for the device to respond to the primitive to become ACTIVE. Retry the I/O request to allow the device time to become ACTIVE. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210629155826.48441-1-quat.le@oracle.com Reviewed-by: Bart Van Assche Signed-off-by: Quat Le Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit d7c62923708bca62d5a4a5dfc6b2c330b985f75e Author: Mauro Carvalho Chehab Date: Tue May 11 17:03:21 2021 +0200 media: exynos4-is: remove a now unused integer commit 29dd19e3ac7b2a8671ebeac02859232ce0e34f58 upstream. The usage of pm_runtime_resume_and_get() removed the need of a temporary integer. So, drop it. Fixes: 59f96244af94 ("media: exynos4-is: fix pm_runtime_get_sync() usage count") Reported-by: Stephen Rothwell Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 8d3433ec89ccd6f7bc3e994ebd5181351a575b5c Author: Johan Hovold Date: Fri May 21 15:30:26 2021 +0200 mmc: vub3000: fix control-request direction commit 3c0bb3107703d2c58f7a0a7a2060bb57bc120326 upstream. The direction of the pipe argument must match the request-type direction bit or control requests may fail depending on the host-controller-driver implementation. Fix the SET_ROM_WAIT_STATES request which erroneously used usb_rcvctrlpipe(). Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver") Cc: stable@vger.kernel.org # 3.0 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210521133026.17296-1-johan@kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 165d6c32f8d070addb3057be8b3491e11db7307a Author: Bean Huo Date: Tue May 4 22:32:09 2021 +0200 mmc: block: Disable CMDQ on the ioctl path commit 70b52f09080565030a530a784f1c9948a7f48ca3 upstream. According to the eMMC Spec: "When command queuing is enabled (CMDQ Mode En bit in CMDQ_MODE_EN field is set to ‘1’) class 11 commands are the only method through which data transfer tasks can be issued. Existing data transfer commands, namely CMD18/CMD17 and CMD25/CMD24, are not supported when command queuing is enabled." which means if CMDQ is enabled, the FFU commands will not be supported. To fix this issue, just simply disable CMDQ on the ioctl path, and re-enable CMDQ once ioctl request is completed. Tested-by: Michael Brunner Signed-off-by: Bean Huo Acked-by: Adrian Hunter Fixes: 1e8e55b67030 (mmc: block: Add CQE support) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210504203209.361597-1-huobean@gmail.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 03105a24cd2b205f989d878e3a33255b56af0772 Author: Jens Axboe Date: Wed Jun 23 09:07:45 2021 -0600 io_uring: add IOPOLL and reserved field checks to IORING_OP_UNLINKAT commit 22634bc5620d29765e5199c7b230a372c7ddcda2 upstream. We can't support IOPOLL with non-pollable request types, and we should check for unused/reserved fields like we do for other request types. Fixes: 14a1143b68ee ("io_uring: add support for IORING_OP_UNLINKAT") Cc: stable@vger.kernel.org Reported-by: Dmitry Kadashev Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 4f5be8b54bd4fb73ad68354c4fa90356137cb0cc Author: Jens Axboe Date: Wed Jun 23 09:04:13 2021 -0600 io_uring: add IOPOLL and reserved field checks to IORING_OP_RENAMEAT commit ed7eb2592286ead7d3bfdf8adf65e65392167cc4 upstream. We can't support IOPOLL with non-pollable request types, and we should check for unused/reserved fields like we do for other request types. Fixes: 80a261fd0032 ("io_uring: add support for IORING_OP_RENAMEAT") Cc: stable@vger.kernel.org Reported-by: Dmitry Kadashev Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 378a830c2608f167616205cea872779563ade6d9 Author: Pavel Begunkov Date: Wed Jun 9 12:07:25 2021 +0100 io_uring: fix blocking inline submission commit 976517f162a05f4315b2373fd11585c395506259 upstream. There is a complaint against sys_io_uring_enter() blocking if it submits stdin reads. The problem is in __io_file_supports_async(), which sees that it's a cdev and allows it to be processed inline. Punt char devices using generic rules of io_file_supports_async(), including checking for presence of *_iter() versions of rw callbacks. Apparently, it will affect most of cdevs with some exceptions like null and zero devices. Cc: stable@vger.kernel.org Reported-by: Birk Hirdman Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/d60270856b8a4560a639ef5f76e55eb563633599.1623236455.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 89d2a15d0526d40f60fc7412d31d219fae5c2c8c Author: Long Li Date: Mon Jun 7 12:34:05 2021 -0700 block: return the correct bvec when checking for gaps commit c9c9762d4d44dcb1b2ba90cfb4122dc11ceebf31 upstream. After commit 07173c3ec276 ("block: enable multipage bvecs"), a bvec can have multiple pages. But bio_will_gap() still assumes one page bvec while checking for merging. If the pages in the bvec go across the seg_boundary_mask, this check for merging can potentially succeed if only the 1st page is tested, and can fail if all the pages are tested. Later, when SCSI builds the SG list the same check for merging is done in __blk_segment_map_sg_merge() with all the pages in the bvec tested. This time the check may fail if the pages in bvec go across the seg_boundary_mask (but tested okay in bio_will_gap() earlier, so those BIOs were merged). If this check fails, we end up with a broken SG list for drivers assuming the SG list not having offsets in intermediate pages. This results in incorrect pages written to the disk. Fix this by returning the multi-page bvec when testing gaps for merging. Cc: Jens Axboe Cc: Johannes Thumshirn Cc: Pavel Begunkov Cc: Ming Lei Cc: Tejun Heo Cc: "Matthew Wilcox (Oracle)" Cc: Jeffle Xu Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Fixes: 07173c3ec276 ("block: enable multipage bvecs") Signed-off-by: Long Li Reviewed-by: Ming Lei Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/1623094445-22332-1-git-send-email-longli@linuxonhyperv.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 3f7e6cae20645c0f61f56a0ddc360b5e9f9cb6dd Author: Wei Yongjun Date: Wed May 19 14:16:57 2021 +0000 erofs: fix error return code in erofs_read_superblock() commit 0508c1ad0f264a24c4643701823a45f6c9bd8146 upstream. 'ret' will be overwritten to 0 if erofs_sb_has_sb_chksum() return true, thus 0 will return in some error handling cases. Fix to return negative error code -EINVAL instead of 0. Link: https://lore.kernel.org/r/20210519141657.3062715-1-weiyongjun1@huawei.com Fixes: b858a4844cfb ("erofs: support superblock checksum") Cc: stable # 5.5+ Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Reviewed-by: Gao Xiang Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Greg Kroah-Hartman commit 9d2da0b8863a207c2f3d8a97b2b038ea8c6592b1 Author: Jarkko Sakkinen Date: Wed Jun 9 16:26:19 2021 +0300 tpm: Replace WARN_ONCE() with dev_err_once() in tpm_tis_status() commit 0178f9d0f60ba07e09bab57381a3ef18e2c1fd7f upstream. Do not tear down the system when getting invalid status from a TPM chip. This can happen when panic-on-warn is used. Instead, introduce TPM_TIS_INVALID_STATUS bitflag and use it to trigger once the error reporting per chip. In addition, print out the value of TPM_STS for improved forensics. Link: https://lore.kernel.org/keyrings/YKzlTR1AzUigShtZ@kroah.com/ Fixes: 55707d531af6 ("tpm_tis: Add a check for invalid status") Cc: stable@vger.kernel.org Signed-off-by: Jarkko Sakkinen Reviewed-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 5859c67160c32337a43813b5c0b93efa55929fd5 Author: Eric Biggers Date: Sat Jun 5 00:50:33 2021 -0700 fscrypt: fix derivation of SipHash keys on big endian CPUs commit 2fc2b430f559fdf32d5d1dd5ceaa40e12fb77bdf upstream. Typically, the cryptographic APIs that fscrypt uses take keys as byte arrays, which avoids endianness issues. However, siphash_key_t is an exception. It is defined as 'u64 key[2];', i.e. the 128-bit key is expected to be given directly as two 64-bit words in CPU endianness. fscrypt_derive_dirhash_key() and fscrypt_setup_iv_ino_lblk_32_key() forgot to take this into account. Therefore, the SipHash keys used to index encrypted+casefolded directories differ on big endian vs. little endian platforms, as do the SipHash keys used to hash inode numbers for IV_INO_LBLK_32-encrypted directories. This makes such directories non-portable between these platforms. Fix this by always using the little endian order. This is a breaking change for big endian platforms, but this should be fine in practice since these features (encrypt+casefold support, and the IV_INO_LBLK_32 flag) aren't known to actually be used on any big endian platforms yet. Fixes: aa408f835d02 ("fscrypt: derive dirhash key for casefolded directories") Fixes: e3b1078bedd3 ("fscrypt: add support for IV_INO_LBLK_32 policies") Cc: # v5.6+ Link: https://lore.kernel.org/r/20210605075033.54424-1-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 119782bf159e43fe1ca08a8bbe52d8492b6506c4 Author: Eric Biggers Date: Thu May 27 16:52:36 2021 -0700 fscrypt: don't ignore minor_hash when hash is 0 commit 77f30bfcfcf484da7208affd6a9e63406420bf91 upstream. When initializing a no-key name, fscrypt_fname_disk_to_usr() sets the minor_hash to 0 if the (major) hash is 0. This doesn't make sense because 0 is a valid hash code, so we shouldn't ignore the filesystem-provided minor_hash in that case. Fix this by removing the special case for 'hash == 0'. This is an old bug that appears to have originated when the encryption code in ext4 and f2fs was moved into fs/crypto/. The original ext4 and f2fs code passed the hash by pointer instead of by value. So 'if (hash)' actually made sense then, as it was checking whether a pointer was NULL. But now the hashes are passed by value, and filesystems just pass 0 for any hashes they don't have. There is no need to handle this any differently from the hashes actually being 0. It is difficult to reproduce this bug, as it only made a difference in the case where a filename's 32-bit major hash happened to be 0. However, it probably had the largest chance of causing problems on ubifs, since ubifs uses minor_hash to do lookups of no-key names, in addition to using it as a readdir cookie. ext4 only uses minor_hash as a readdir cookie, and f2fs doesn't use minor_hash at all. Fixes: 0b81d0779072 ("fs crypto: move per-file encryption from f2fs tree to fs/crypto") Cc: # v4.6+ Link: https://lore.kernel.org/r/20210527235236.2376556-1-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 2f2d7dc088c37ffa857fd83d13ac27eda74b5fc5 Author: Sibi Sankar Date: Wed Jun 16 23:12:58 2021 +0530 mailbox: qcom-ipcc: Fix IPCC mbox channel exhaustion commit d6fbfdbc12745ce24bcd348dbf7e652353b3e59c upstream. Fix IPCC (Inter-Processor Communication Controller) channel exhaustion by setting the channel private data to NULL on mbox shutdown. Err Logs: remoteproc: MBA booted without debug policy, loading mpss remoteproc: glink-edge: failed to acquire IPC channel remoteproc: failed to probe subdevices for remoteproc: -16 Fixes: fa74a0257f45 ("mailbox: Add support for Qualcomm IPCC") Signed-off-by: Sibi Sankar Cc: stable@vger.kernel.org Reviewed-by: Bjorn Andersson Reviewed-by: Manivannan Sadhasivam Signed-off-by: Jassi Brar Signed-off-by: Greg Kroah-Hartman commit 610de611adaeea765857985f72278e58f7fe061b Author: Javed Hasan Date: Thu Jun 3 03:14:04 2021 -0700 scsi: libfc: Correct the condition check and invalid argument passed commit 8f70328c068f9f5c5db82848724cb276f657b9cd upstream. Incorrect condition check was leading to data corruption. Link: https://lore.kernel.org/r/20210603101404.7841-3-jhasan@marvell.com Fixes: 8fd9efca86d0 ("scsi: libfc: Work around -Warray-bounds warning") CC: stable@vger.kernel.org Reviewed-by: Himanshu Madhani Signed-off-by: Javed Hasan Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 17902d3eb4ddba18ff807c0c5bff38bb2a824d8e Author: James Smart Date: Fri May 14 12:55:53 2021 -0700 scsi: lpfc: Fix Node recovery when driver is handling simultaneous PLOGIs commit 4012baeab6ca22b7f7beb121b6d0da0a62942fdd upstream. When lpfc is handling a solicited and unsolicited PLOGI with another initiator, the remote initiator is never recovered. The node for the initiator is erroneouosly removed and all resources released. In lpfc_cmpl_els_plogi(), when lpfc_els_retry() returns a failure code, the driver is calling the state machine with a device remove event because the remote port is not currently registered with the SCSI or NVMe transports. The issue is that on a PLOGI "collision" the driver correctly aborts the solicited PLOGI and allows the unsolicited PLOGI to complete the process, but this process is interrupted with a device_rm event. Introduce logic in the PLOGI completion to capture the PLOGI collision event and jump out of the routine. This will avoid removal of the node. If there is no collision, the normal node removal will occur. Fixes: 52edb2caf675 ("scsi: lpfc: Remove ndlp when a PLOGI/ADISC/PRLI/REG_RPI ultimately fails") Cc: # v5.11+ Link: https://lore.kernel.org/r/20210514195559.119853-6-jsmart2021@gmail.com Co-developed-by: Justin Tee Signed-off-by: Justin Tee Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit fc9f2f00424df7f7439845ad73924ba675405654 Author: James Smart Date: Fri May 14 12:55:49 2021 -0700 scsi: lpfc: Fix unreleased RPIs when NPIV ports are created commit 01131e7aae5d30e23e3cdd1eebe51bbc5489ae8f upstream. While testing NPIV and watching logins and used RPI levels, it was seen the used RPI count was much higher than the number of remote ports discovered. Code inspection showed that remote port removals on any NPIV instance are releasing the RPI, but not performing an UNREG_RPI with the adapter thus the reference counting never fully drops and the RPI is never fully released. This was happening on NPIV nodes due to a log of fabric ELS's to fabric addresses. This lack of UNREG_RPI was introduced by a prior node rework patch that performed the UNREG_RPI as part of node cleanup. To resolve the issue, do the following: - Restore the RPI release code, but move the location to so that it is in line with the new node cleanup design. - NPIV ports now release the RPI and drop the node when the caller sets the NLP_RELEASE_RPI flag. - Set the NLP_RELEASE_RPI flag in node cleanup which will trigger a release of RPI to free pool. - Ensure there's an UNREG_RPI at LOGO completion so that RPI release is completed. - Stop offline_prep from skipping nodes that are UNUSED. The RPI may not have been released. - Stop the default RPI handling in lpfc_cmpl_els_rsp() for SLI4. - Fixed up debugfs RPI displays for better debugging. Fixes: a70e63eee1c1 ("scsi: lpfc: Fix NPIV Fabric Node reference counting") Link: https://lore.kernel.org/r/20210514195559.119853-2-jsmart2021@gmail.com Cc: # v5.11+ Co-developed-by: Justin Tee Signed-off-by: Justin Tee Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 1d51f50c5af9f7d8a312fc6bddb3b5dfedfdb01c Author: Varun Prakash Date: Wed Apr 14 18:09:09 2021 +0530 scsi: target: cxgbit: Unmap DMA buffer before calling target_execute_cmd() commit 6ecdafaec79d4b3388a5b017245f23a0ff9d852d upstream. Instead of calling dma_unmap_sg() after completing WRITE I/O, call dma_unmap_sg() before calling target_execute_cmd() to sync the DMA buffer. Link: https://lore.kernel.org/r/1618403949-3443-1-git-send-email-varun@chelsio.com Cc: # 5.4+ Signed-off-by: Varun Prakash Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit c593bc3cb8726f1d6250ac44ce764f676eeff773 Author: Javed Hasan Date: Thu Jun 3 03:14:03 2021 -0700 scsi: fc: Correct RHBA attributes length commit 40445fd2c9fa427297acdfcc2c573ff10493f209 upstream. As per the FC-GS-5 specification, attribute lengths of node_name and manufacturer should in range of "4 to 64 Bytes" only. Link: https://lore.kernel.org/r/20210603101404.7841-2-jhasan@marvell.com Fixes: e721eb0616f6 ("scsi: scsi_transport_fc: Match HBA Attribute Length with HBAAPI V2.0 definitions") CC: stable@vger.kernel.org Reviewed-by: Himanshu Madhani Signed-off-by: Javed Hasan Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 63b60a83ce27367f9521a950540fe9edf3f811c4 Author: Chandrakanth Patil Date: Fri May 28 18:43:03 2021 +0530 scsi: megaraid_sas: Send all non-RW I/Os for TYPE_ENCLOSURE device through firmware commit 79db830162b733f5f3ee80f0673eeeb0245fe38b upstream. The driver issues all non-ReadWrite I/Os for TYPE_ENCLOSURE devices through the fast path with invalid dev handle. Fast path in turn directs all the I/Os to the firmware. As firmware stopped handling those I/Os from SAS3.5 generation of controllers (Ventura generation and onwards) this will lead to I/O failures. Switch the driver to issue all the non-ReadWrite I/Os for TYPE_ENCLOSURE devices directly to firmware for SAS3.5 generation of controllers and later. Link: https://lore.kernel.org/r/20210528131307.25683-2-chandrakanth.patil@broadcom.com Cc: # v5.11+ Signed-off-by: Chandrakanth Patil Signed-off-by: Sumit Saxena Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 646efb94462b253112a1afaa25ff1be7680f9414 Author: Namjae Jeon Date: Fri Jun 11 09:40:24 2021 +0900 exfat: handle wrong stream entry size in exfat_readdir() commit 1e5654de0f51890f88abd409ebf4867782431e81 upstream. The compatibility issue between linux exfat and exfat of some camera company was reported from Florian. In their exfat, if the number of files exceeds any limit, the DataLength in stream entry of the directory is no longer updated. So some files created from camera does not show in linux exfat. because linux exfat doesn't allow that cpos becomes larger than DataLength of stream entry. This patch check DataLength in stream entry only if the type is ALLOC_NO_FAT_CHAIN and add the check ensure that dentry offset does not exceed max dentries size(256 MB) to avoid the circular FAT chain issue. Fixes: ca06197382bd ("exfat: add directory operations") Cc: stable@vger.kernel.org # v5.9 Reported-by: Florian Cramer Reviewed-by: Sungjong Seo Tested-by: Chris Down Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 43661346eb2629fa46811bd894d9d7973cd8d43f Author: Guo Ren Date: Tue May 4 14:08:44 2021 +0800 csky: syscache: Fixup duplicate cache flush [ Upstream commit 6ea42c84f33368eb3fe1ec1bff8d7cb1a5c7b07a ] The current csky logic of sys_cacheflush is wrong, it'll cause icache flush call dcache flush again. Now fixup it with a conditional "break & fallthrough". Fixes: 997153b9a75c ("csky: Add flush_icache_mm to defer flush icache all") Fixes: 0679d29d3e23 ("csky: fix syscache.c fallthrough warning") Acked-by: Randy Dunlap Co-Developed-by: Randy Dunlap Signed-off-by: Guo Ren Cc: Arnd Bergmann Signed-off-by: Sasha Levin commit 268e8c75ecdf759c1a56740e5666b8fb39c34564 Author: Chris Packham Date: Fri Jul 2 15:27:24 2021 +1200 i2c: mpc: Restore reread of I2C status register [ Upstream commit 763778cd79267dadf0ec7e044caf7563df0ab597 ] Prior to commit 1538d82f4647 ("i2c: mpc: Interrupt driven transfer") the old interrupt handler would reread MPC_I2C_SR after checking the CSR_MIF bit. When the driver was re-written this was removed as it seemed unnecessary. However as it turns out this is necessary for i2c devices which do clock stretching otherwise we end up thinking the bus is still busy when processing the interrupt. Fixes: 1538d82f4647 ("i2c: mpc: Interrupt driven transfer") Signed-off-by: Chris Packham Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit ffa7e0d5920ed986cbc3e019811d035f5b20e96b Author: Arnaldo Carvalho de Melo Date: Thu Jul 1 14:20:58 2021 -0300 perf llvm: Return -ENOMEM when asprintf() fails [ Upstream commit c435c166dcf526ac827bc964d82cc0d5e7a1fd0b ] Zhihao sent a patch but it made llvm__compile_bpf() return what asprintf() returns on error, which is just -1, but since this function returns -errno, fix it by returning -ENOMEM for this case instead. Fixes: cb76371441d098 ("perf llvm: Allow passing options to llc ...") Fixes: 5eab5a7ee032ac ("perf llvm: Display eBPF compiling command ...") Reported-by: Hulk Robot Reported-by: Zhihao Cheng Cc: Alexei Starovoitov Cc: Andrii Nakryiko Cc: Daniel Borkmann Cc: Ingo Molnar Cc: Jiri Olsa Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: Peter Zijlstra Cc: Yu Kuai Cc: clang-built-linux@googlegroups.com Link: http://lore.kernel.org/lkml/20210609115945.2193194-1-chengzhihao1@huawei.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 5d12814f02d4ecc1bc5dba1c2f713877e81b5ee4 Author: Dave Hansen Date: Wed Jun 30 18:56:59 2021 -0700 selftests/vm/pkeys: refill shadow register after implicit kernel write [ Upstream commit 6039ca254979694c5362dfebadd105e286c397bb ] The pkey test code keeps a "shadow" of the pkey register around. This ensures that any bugs which might write to the register can be caught more quickly. Generally, userspace has a good idea when the kernel is going to write to the register. For instance, alloc_pkey() is passed a permission mask. The caller of alloc_pkey() can update the shadow based on the return value and the mask. But, the kernel can also modify the pkey register in a more sneaky way. For mprotect(PROT_EXEC) mappings, the kernel will allocate a pkey and write the pkey register to create an execute-only mapping. The kernel never tells userspace what key it uses for this. This can cause the test to fail with messages like: protection_keys_64.2: pkey-helpers.h:132: _read_pkey_reg: Assertion `pkey_reg == shadow_pkey_reg' failed. because the shadow was not updated with the new kernel-set value. Forcibly update the shadow value immediately after an mprotect(). Link: https://lkml.kernel.org/r/20210611164200.EF76AB73@viggo.jf.intel.com Fixes: 6af17cf89e99 ("x86/pkeys/selftests: Add PROT_EXEC test") Signed-off-by: Dave Hansen Signed-off-by: Thomas Gleixner Tested-by: Aneesh Kumar K.V Cc: Ram Pai Cc: Sandipan Das Cc: Florian Weimer Cc: "Desnes A. Nunes do Rosario" Cc: Ingo Molnar Cc: Thiago Jung Bauermann Cc: Michael Ellerman Cc: Michal Hocko Cc: Michal Suchanek Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 328f60fa16d7192b072ad8593f6fd8bbad911491 Author: Dave Hansen Date: Wed Jun 30 18:56:56 2021 -0700 selftests/vm/pkeys: handle negative sys_pkey_alloc() return code [ Upstream commit bf68294a2ec39ed7fec6a5b45d52034e6983157a ] The alloc_pkey() sefltest function wraps the sys_pkey_alloc() system call. On success, it updates its "shadow" register value because sys_pkey_alloc() updates the real register. But, the success check is wrong. pkey_alloc() considers any non-zero return code to indicate success where the pkey register will be modified. This fails to take negative return codes into account. Consider only a positive return value as a successful call. Link: https://lkml.kernel.org/r/20210611164157.87AB4246@viggo.jf.intel.com Fixes: 5f23f6d082a9 ("x86/pkeys: Add self-tests") Reported-by: Thomas Gleixner Signed-off-by: Dave Hansen Tested-by: Aneesh Kumar K.V Cc: Ram Pai Cc: Sandipan Das Cc: Florian Weimer Cc: "Desnes A. Nunes do Rosario" Cc: Ingo Molnar Cc: Thiago Jung Bauermann Cc: Michael Ellerman Cc: Michal Hocko Cc: Michal Suchanek Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit b8e5d3ad5f5e47da775fbb3c132e57e34cda3880 Author: Dave Hansen Date: Wed Jun 30 18:56:53 2021 -0700 selftests/vm/pkeys: fix alloc_random_pkey() to make it really, really random [ Upstream commit f36ef407628835a7d7fb3d235b1f1aac7022d9a3 ] Patch series "selftests/vm/pkeys: Bug fixes and a new test". There has been a lot of activity on the x86 front around the XSAVE architecture which is used to context-switch processor state (among other things). In addition, AMD has recently joined the protection keys club by adding processor support for PKU. The AMD implementation helped uncover a kernel bug around the PKRU "init state", which actually applied to Intel's implementation but was just harder to hit. This series adds a test which is expected to help find this class of bug both on AMD and Intel. All the work around pkeys on x86 also uncovered a few bugs in the selftest. This patch (of 4): The "random" pkey allocation code currently does the good old: srand((unsigned int)time(NULL)); *But*, it unfortunately does this on every random pkey allocation. There may be thousands of these a second. time() has a one second resolution. So, each time alloc_random_pkey() is called, the PRNG is *RESET* to time(). This is nasty. Normally, if you do: srand(); foo = rand(); bar = rand(); You'll be quite guaranteed that 'foo' and 'bar' are different. But, if you do: srand(1); foo = rand(); srand(1); bar = rand(); You are quite guaranteed that 'foo' and 'bar' are the *SAME*. The recent "fix" effectively forced the test case to use the same "random" pkey for the whole test, unless the test run crossed a second boundary. Only run srand() once at program startup. This explains some very odd and persistent test failures I've been seeing. Link: https://lkml.kernel.org/r/20210611164153.91B76FB8@viggo.jf.intel.com Link: https://lkml.kernel.org/r/20210611164155.192D00FF@viggo.jf.intel.com Fixes: 6e373263ce07 ("selftests/vm/pkeys: fix alloc_random_pkey() to make it really random") Signed-off-by: Dave Hansen Signed-off-by: Thomas Gleixner Tested-by: Aneesh Kumar K.V Cc: Ram Pai Cc: Sandipan Das Cc: Florian Weimer Cc: "Desnes A. Nunes do Rosario" Cc: Ingo Molnar Cc: Thiago Jung Bauermann Cc: Michael Ellerman Cc: Michal Hocko Cc: Michal Suchanek Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 0ef6f9783957506dd364b98d0de0d8f5f67fa902 Author: Trent Piepho Date: Wed Jun 30 18:55:49 2021 -0700 lib/math/rational.c: fix divide by zero [ Upstream commit 65a0d3c14685663ba111038a35db70f559e39336 ] If the input is out of the range of the allowed values, either larger than the largest value or closer to zero than the smallest non-zero allowed value, then a division by zero would occur. In the case of input too large, the division by zero will occur on the first iteration. The best result (largest allowed value) will be found by always choosing the semi-convergent and excluding the denominator based limit when finding it. In the case of the input too small, the division by zero will occur on the second iteration. The numerator based semi-convergent should not be calculated to avoid the division by zero. But the semi-convergent vs previous convergent test is still needed, which effectively chooses between 0 (the previous convergent) vs the smallest allowed fraction (best semi-convergent) as the result. Link: https://lkml.kernel.org/r/20210525144250.214670-1-tpiepho@gmail.com Fixes: 323dd2c3ed0 ("lib/math/rational.c: fix possible incorrect result from rational fractions helper") Signed-off-by: Trent Piepho Reported-by: Yiyuan Guo Reviewed-by: Andy Shevchenko Cc: Oskar Schirmer Cc: Daniel Latypov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 928003bd28c397a163c32934dade4d71c77fa782 Author: Marco Elver Date: Wed Jun 30 18:54:03 2021 -0700 kfence: unconditionally use unbound work queue [ Upstream commit ff06e45d3aace3f93d23956c1e655224f363ebe2 ] Unconditionally use unbound work queue, and not just if wq_power_efficient is true. Because if the system is idle, KFENCE may wait, and by being run on the unbound work queue, we permit the scheduler to make better scheduling decisions and not require pinning KFENCE to the same CPU upon waking up. Link: https://lkml.kernel.org/r/20210521111630.472579-1-elver@google.com Fixes: 36f0b35d0894 ("kfence: use power-efficient work queue to run delayed work") Signed-off-by: Marco Elver Reported-by: Hillf Danton Reviewed-by: Alexander Potapenko Cc: Dmitry Vyukov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 11ebc09e50dcc073f36ce73f9c198cd05194a13b Author: Miaohe Lin Date: Wed Jun 30 18:52:55 2021 -0700 mm/zswap.c: fix two bugs in zswap_writeback_entry() [ Upstream commit 46b76f2e09dc35f70aca2f4349eb0d158f53fe93 ] In the ZSWAP_SWAPCACHE_FAIL and ZSWAP_SWAPCACHE_EXIST case, we forgot to call zpool_unmap_handle() when zpool can't sleep. And we might sleep in zswap_get_swap_cache_page() while zpool can't sleep. To fix all of these, zpool_unmap_handle() should be done before zswap_get_swap_cache_page() when zpool can't sleep. Link: https://lkml.kernel.org/r/20210522092242.3233191-4-linmiaohe@huawei.com Fixes: fc6697a89f56 ("mm/zswap: add the flag can_sleep_mapped") Signed-off-by: Miaohe Lin Cc: Colin Ian King Cc: Dan Streetman Cc: Nathan Chancellor Cc: Sebastian Andrzej Siewior Cc: Seth Jennings Cc: Tian Tao Cc: Vitaly Wool Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 72b032f10071db0dd0e99b105c37eb5772126416 Author: Muchun Song Date: Wed Jun 30 18:51:29 2021 -0700 mm: migrate: fix missing update page_private to hugetlb_page_subpool [ Upstream commit 6acfb5ba150cf75005ce85e0e25d79ef2fec287c ] Since commit d6995da31122 ("hugetlb: use page.private for hugetlb specific page flags") converts page.private for hugetlb specific page flags. We should use hugetlb_page_subpool() to get the subpool pointer instead of page_private(). This 'could' prevent the migration of hugetlb pages. page_private(hpage) is now used for hugetlb page specific flags. At migration time, the only flag which could be set is HPageVmemmapOptimized. This flag will only be set if the new vmemmap reduction feature is enabled. In addition, !page_mapping() implies an anonymous mapping. So, this will prevent migration of hugetb pages in anonymous mappings if the vmemmap reduction feature is enabled. In addition, that if statement checked for the rare race condition of a page being migrated while in the process of being freed. Since that check is now wrong, we could leak hugetlb subpool usage counts. The commit forgot to update it in the page migration routine. So fix it. [songmuchun@bytedance.com: fix compiler error when !CONFIG_HUGETLB_PAGE reported by Randy] Link: https://lkml.kernel.org/r/20210521022747.35736-1-songmuchun@bytedance.com Link: https://lkml.kernel.org/r/20210520025949.1866-1-songmuchun@bytedance.com Fixes: d6995da31122 ("hugetlb: use page.private for hugetlb specific page flags") Signed-off-by: Muchun Song Reported-by: Anshuman Khandual Reviewed-by: Mike Kravetz Acked-by: Michal Hocko Tested-by: Anshuman Khandual [arm64] Cc: Oscar Salvador Cc: David Hildenbrand Cc: Matthew Wilcox Cc: Xiongchun Duan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 95d192da198d45f1ff0b3c73276d1355c9caa584 Author: Miaohe Lin Date: Wed Jun 30 18:50:39 2021 -0700 mm/z3fold: use release_z3fold_page_locked() to release locked z3fold page [ Upstream commit 28473d91ff7f686d58047ff55f2fa98ab59114a4 ] We should use release_z3fold_page_locked() to release z3fold page when it's locked, although it looks harmless to use release_z3fold_page() now. Link: https://lkml.kernel.org/r/20210619093151.1492174-7-linmiaohe@huawei.com Fixes: dcf5aedb24f8 ("z3fold: stricter locking and more careful reclaim") Signed-off-by: Miaohe Lin Reviewed-by: Vitaly Wool Cc: Hillf Danton Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ccb7848e23445afdc3432d6aa890d41f84f7538a Author: Miaohe Lin Date: Wed Jun 30 18:50:36 2021 -0700 mm/z3fold: fix potential memory leak in z3fold_destroy_pool() [ Upstream commit dac0d1cfda56472378d330b1b76b9973557a7b1d ] There is a memory leak in z3fold_destroy_pool() as it forgets to free_percpu pool->unbuddied. Call free_percpu for pool->unbuddied to fix this issue. Link: https://lkml.kernel.org/r/20210619093151.1492174-6-linmiaohe@huawei.com Fixes: d30561c56f41 ("z3fold: use per-cpu unbuddied lists") Signed-off-by: Miaohe Lin Reviewed-by: Vitaly Wool Cc: Hillf Danton Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 093d3fc8cb238fa0b7377ccd5c02df378cc449ad Author: Mike Kravetz Date: Wed Jun 30 18:48:31 2021 -0700 hugetlb: remove prep_compound_huge_page cleanup [ Upstream commit 48b8d744ea841b8adf8d07bfe7a2d55f22e4d179 ] Patch series "Fix prep_compound_gigantic_page ref count adjustment". These patches address the possible race between prep_compound_gigantic_page and __page_cache_add_speculative as described by Jann Horn in [1]. The first patch simply removes the unnecessary/obsolete helper routine prep_compound_huge_page to make the actual fix a little simpler. The second patch is the actual fix and has a detailed explanation in the commit message. This potential issue has existed for almost 10 years and I am unaware of anyone actually hitting the race. I did not cc stable, but would be happy to squash the patches and send to stable if anyone thinks that is a good idea. [1] https://lore.kernel.org/linux-mm/CAG48ez23q0Jy9cuVnwAe7t_fdhMk2S7N5Hdi-GLcCeq5bsfLxw@mail.gmail.com/ This patch (of 2): I could not think of a reliable way to recreate the issue for testing. Rather, I 'simulated errors' to exercise all the error paths. The routine prep_compound_huge_page is a simple wrapper to call either prep_compound_gigantic_page or prep_compound_page. However, it is only called from gather_bootmem_prealloc which only processes gigantic pages. Eliminate the routine and call prep_compound_gigantic_page directly. Link: https://lkml.kernel.org/r/20210622021423.154662-1-mike.kravetz@oracle.com Link: https://lkml.kernel.org/r/20210622021423.154662-2-mike.kravetz@oracle.com Signed-off-by: Mike Kravetz Cc: Andrea Arcangeli Cc: Jan Kara Cc: Jann Horn Cc: John Hubbard Cc: "Kirill A . Shutemov" Cc: Matthew Wilcox Cc: Michal Hocko Cc: Youquan Song Cc: Muchun Song Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 9f7229c901c12e1653a01dbd7ec8d8e2c5331dac Author: Miaohe Lin Date: Wed Jun 30 18:47:57 2021 -0700 mm/huge_memory.c: don't discard hugepage if other processes are mapping it [ Upstream commit babbbdd08af98a59089334eb3effbed5a7a0cf7f ] If other processes are mapping any other subpages of the hugepage, i.e. in pte-mapped thp case, page_mapcount() will return 1 incorrectly. Then we would discard the page while other processes are still mapping it. Fix it by using total_mapcount() which can tell whether other processes are still mapping it. Link: https://lkml.kernel.org/r/20210511134857.1581273-6-linmiaohe@huawei.com Fixes: b8d3c4c3009d ("mm/huge_memory.c: don't split THP page when MADV_FREE syscall is called") Reviewed-by: Yang Shi Signed-off-by: Miaohe Lin Cc: Alexey Dobriyan Cc: "Aneesh Kumar K . V" Cc: Anshuman Khandual Cc: David Hildenbrand Cc: Hugh Dickins Cc: Johannes Weiner Cc: Kirill A. Shutemov Cc: Matthew Wilcox Cc: Minchan Kim Cc: Ralph Campbell Cc: Rik van Riel Cc: Song Liu Cc: William Kucharski Cc: Zi Yan Cc: Mike Kravetz Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit f13259175e4fb6d26c833ef76ddfd081a2e7e4b5 Author: Miaohe Lin Date: Wed Jun 30 18:47:50 2021 -0700 mm/huge_memory.c: add missing read-only THP checking in transparent_hugepage_enabled() [ Upstream commit e6be37b2e7bddfe0c76585ee7c7eee5acc8efeab ] Since commit 99cb0dbd47a1 ("mm,thp: add read-only THP support for (non-shmem) FS"), read-only THP file mapping is supported. But it forgot to add checking for it in transparent_hugepage_enabled(). To fix it, we add checking for read-only THP file mapping and also introduce helper transhuge_vma_enabled() to check whether thp is enabled for specified vma to reduce duplicated code. We rename transparent_hugepage_enabled to transparent_hugepage_active to make the code easier to follow as suggested by David Hildenbrand. [linmiaohe@huawei.com: define transhuge_vma_enabled next to transhuge_vma_suitable] Link: https://lkml.kernel.org/r/20210514093007.4117906-1-linmiaohe@huawei.com Link: https://lkml.kernel.org/r/20210511134857.1581273-4-linmiaohe@huawei.com Fixes: 99cb0dbd47a1 ("mm,thp: add read-only THP support for (non-shmem) FS") Signed-off-by: Miaohe Lin Reviewed-by: Yang Shi Cc: Alexey Dobriyan Cc: "Aneesh Kumar K . V" Cc: Anshuman Khandual Cc: David Hildenbrand Cc: Hugh Dickins Cc: Johannes Weiner Cc: Kirill A. Shutemov Cc: Matthew Wilcox Cc: Minchan Kim Cc: Ralph Campbell Cc: Rik van Riel Cc: Song Liu Cc: William Kucharski Cc: Zi Yan Cc: Mike Kravetz Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit afafd371e7de389daec2421eb362b651e49d4a67 Author: Miaohe Lin Date: Wed Jun 30 18:47:43 2021 -0700 mm/huge_memory.c: remove dedicated macro HPAGE_CACHE_INDEX_MASK [ Upstream commit b2bd53f18bb7f7cfc91b3bb527d7809376700a8e ] Patch series "Cleanup and fixup for huge_memory:, v3. This series contains cleanups to remove dedicated macro and remove unnecessary tlb_remove_page_size() for huge zero pmd. Also this adds missing read-only THP checking for transparent_hugepage_enabled() and avoids discarding hugepage if other processes are mapping it. More details can be found in the respective changelogs. Thi patch (of 5): Rewrite the pgoff checking logic to remove macro HPAGE_CACHE_INDEX_MASK which is only used here to simplify the code. Link: https://lkml.kernel.org/r/20210511134857.1581273-1-linmiaohe@huawei.com Link: https://lkml.kernel.org/r/20210511134857.1581273-2-linmiaohe@huawei.com Signed-off-by: Miaohe Lin Reviewed-by: Yang Shi Reviewed-by: Anshuman Khandual Reviewed-by: David Hildenbrand Cc: Zi Yan Cc: William Kucharski Cc: Matthew Wilcox Cc: "Aneesh Kumar K . V" Cc: Ralph Campbell Cc: Song Liu Cc: Kirill A. Shutemov Cc: Rik van Riel Cc: Johannes Weiner Cc: Minchan Kim Cc: Hugh Dickins Cc: Alexey Dobriyan Cc: Mike Kravetz Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ada04453947006ab6b0eb20e512a47558a2e72a8 Author: Alex Williamson Date: Mon Jun 28 14:08:12 2021 -0600 vfio/pci: Handle concurrent vma faults [ Upstream commit 6a45ece4c9af473555f01f0f8b97eba56e3c7d0d ] io_remap_pfn_range() will trigger a BUG_ON if it encounters a populated pte within the mapping range. This can occur because we map the entire vma on fault and multiple faults can be blocked behind the vma_lock. This leads to traces like the one reported below. We can use our vma_list to test whether a given vma is mapped to avoid this issue. [ 1591.733256] kernel BUG at mm/memory.c:2177! [ 1591.739515] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 1591.747381] Modules linked in: vfio_iommu_type1 vfio_pci vfio_virqfd vfio pv680_mii(O) [ 1591.760536] CPU: 2 PID: 227 Comm: lcore-worker-2 Tainted: G O 5.11.0-rc3+ #1 [ 1591.770735] Hardware name: , BIOS HixxxxFPGA 1P B600 V121-1 [ 1591.778872] pstate: 40400009 (nZcv daif +PAN -UAO -TCO BTYPE=--) [ 1591.786134] pc : remap_pfn_range+0x214/0x340 [ 1591.793564] lr : remap_pfn_range+0x1b8/0x340 [ 1591.799117] sp : ffff80001068bbd0 [ 1591.803476] x29: ffff80001068bbd0 x28: 0000042eff6f0000 [ 1591.810404] x27: 0000001100910000 x26: 0000001300910000 [ 1591.817457] x25: 0068000000000fd3 x24: ffffa92f1338e358 [ 1591.825144] x23: 0000001140000000 x22: 0000000000000041 [ 1591.832506] x21: 0000001300910000 x20: ffffa92f141a4000 [ 1591.839520] x19: 0000001100a00000 x18: 0000000000000000 [ 1591.846108] x17: 0000000000000000 x16: ffffa92f11844540 [ 1591.853570] x15: 0000000000000000 x14: 0000000000000000 [ 1591.860768] x13: fffffc0000000000 x12: 0000000000000880 [ 1591.868053] x11: ffff0821bf3d01d0 x10: ffff5ef2abd89000 [ 1591.875932] x9 : ffffa92f12ab0064 x8 : ffffa92f136471c0 [ 1591.883208] x7 : 0000001140910000 x6 : 0000000200000000 [ 1591.890177] x5 : 0000000000000001 x4 : 0000000000000001 [ 1591.896656] x3 : 0000000000000000 x2 : 0168044000000fd3 [ 1591.903215] x1 : ffff082126261880 x0 : fffffc2084989868 [ 1591.910234] Call trace: [ 1591.914837] remap_pfn_range+0x214/0x340 [ 1591.921765] vfio_pci_mmap_fault+0xac/0x130 [vfio_pci] [ 1591.931200] __do_fault+0x44/0x12c [ 1591.937031] handle_mm_fault+0xcc8/0x1230 [ 1591.942475] do_page_fault+0x16c/0x484 [ 1591.948635] do_translation_fault+0xbc/0xd8 [ 1591.954171] do_mem_abort+0x4c/0xc0 [ 1591.960316] el0_da+0x40/0x80 [ 1591.965585] el0_sync_handler+0x168/0x1b0 [ 1591.971608] el0_sync+0x174/0x180 [ 1591.978312] Code: eb1b027f 540000c0 f9400022 b4fffe02 (d4210000) Fixes: 11c4cd07ba11 ("vfio-pci: Fault mmaps to enable vma tracking") Reported-by: Zeng Tao Suggested-by: Zeng Tao Link: https://lore.kernel.org/r/162497742783.3883260.3282953006487785034.stgit@omen Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 13a4d6ea398e74cd858d90ec7ca5a08bc4b6c3cd Author: Nicholas Piggin Date: Wed Jun 30 17:46:17 2021 +1000 powerpc/64s/interrupt: preserve regs->softe for NMI interrupts [ Upstream commit 1b0482229c302a3c6afd00d6b3bf0169cf279b44 ] If an NMI interrupt hits in an implicit soft-masked region, regs->softe is modified to reflect that. This may not be necessary for correctness at the moment, but it is less surprising and it's unhelpful when debugging or adding checks. Make sure this is changed back to how it was found before returning. Fixes: 4ec5feec1ad0 ("powerpc/64s: Make NMI record implicitly soft-masked code as irqs disabled") Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210630074621.2109197-6-npiggin@gmail.com Signed-off-by: Sasha Levin commit 9924e27c19acb6c6a60c327b6e011bd30cdd80af Author: Nicholas Piggin Date: Wed Jun 30 17:46:13 2021 +1000 powerpc/64s: fix hash page fault interrupt handler [ Upstream commit 5567b1ee29b7a83e8c01d99d34b5bbd306ce0bcf ] The early bad fault or key fault test in do_hash_fault() ends up calling into ___do_page_fault without having gone through an interrupt handler wrapper (except the initial _RAW one). This can end up calling local irq functions while the interrupt has not been reconciled, which will likely cause crashes and it trips up on a later patch that adds more assertions. pkey_exec_prot from selftests causes this path to be executed. There is no real reason to run the in_nmi() test should be performed before the key fault check. In fact if a perf interrupt in the hash fault code did a stack walk that was made to take a key fault somehow then running ___do_page_fault could possibly cause another hash fault causing problems. Move the in_nmi() test first, and then do everything else inside the regular interrupt handler function. Fixes: 3a96570ffceb ("powerpc: convert interrupt handlers to use wrappers") Reported-by: Sachin Sant Signed-off-by: Nicholas Piggin Tested-by: Sachin Sant Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210630074621.2109197-2-npiggin@gmail.com Signed-off-by: Sasha Levin commit 4dcbce306d750103c9fcc3aecfc5cb0326a1be09 Author: Pali Rohár Date: Fri Jun 25 00:49:04 2021 +0200 arm64: dts: marvell: armada-37xx: Fix reg for standard variant of UART [ Upstream commit 2cbfdedef39fb5994b8f1e1df068eb8440165975 ] UART1 (standard variant with DT node name 'uart0') has register space 0x12000-0x12018 and not whole size 0x200. So fix also this in example. Signed-off-by: Pali Rohár Fixes: c737abc193d1 ("arm64: dts: marvell: Fix A37xx UART0 register size") Link: https://lore.kernel.org/r/20210624224909.6350-6-pali@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 25b601d9d877c597122c5e409346fb6fa61727df Author: Pali Rohár Date: Fri Jun 25 00:49:02 2021 +0200 serial: mvebu-uart: correctly calculate minimal possible baudrate [ Upstream commit deeaf963569a0d9d1b08babb771f61bb501a5704 ] For default (x16) scheme which is currently used by mvebu-uart.c driver, maximal divisor of UART base clock is 1023*16. Therefore there is limit for minimal supported baudrate. This change calculate it correctly and prevents setting invalid divisor 0 into hardware registers. Signed-off-by: Pali Rohár Fixes: 68a0db1d7da2 ("serial: mvebu-uart: add function to change baudrate") Link: https://lore.kernel.org/r/20210624224909.6350-4-pali@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 59146c5835a41fac570b4cac5fb3b28cf64ad703 Author: Pali Rohár Date: Fri Jun 25 00:49:01 2021 +0200 serial: mvebu-uart: do not allow changing baudrate when uartclk is not available [ Upstream commit ecd6b010d81f97b06b2f64d2d4f50ebf5acddaa9 ] Testing mvuart->clk for non-error is not enough as mvuart->clk may contain valid clk pointer but when clk_prepare_enable(mvuart->clk) failed then port->uartclk is zero. When mvuart->clk is not available then port->uartclk is zero too. Parent clock rate port->uartclk is needed to calculate UART clock divisor and without it is not possible to change baudrate. So fix test condition when it is possible to change baudrate. Signed-off-by: Pali Rohár Fixes: 68a0db1d7da2 ("serial: mvebu-uart: add function to change baudrate") Link: https://lore.kernel.org/r/20210624224909.6350-3-pali@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ce2d17c9801b48364169553cd7d64d93a1f118a8 Author: Christophe JAILLET Date: Thu Jun 24 20:49:36 2021 +0200 ALSA: firewire-lib: Fix 'amdtp_domain_start()' when no AMDTP_OUT_STREAM stream is found [ Upstream commit 0cbbeaf370221fc469c95945dd3c1198865c5fe4 ] The intent here is to return an error code if we don't find what we are looking for in the 'list_for_each_entry()' loop. 's' is not NULL if the list is empty or if we scan the complete list. Introduce a new 'found' variable to handle such cases. Fixes: 60dd49298ec5 ("ALSA: firewire-lib: handle several AMDTP streams in callback handler of IRQ target") Signed-off-by: Christophe JAILLET Acked-by: Takashi Sakamoto Link: https://lore.kernel.org/r/9c9a53a4905984a570ba5672cbab84f2027dedc1.1624560484.git.christophe.jaillet@wanadoo.fr Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 1a09a37887720ddb41303c8c408c1d8e65d5c9c5 Author: Michael Ellerman Date: Wed Jun 23 23:05:14 2021 +1000 powerpc: Fix is_kvm_guest() / kvm_para_available() [ Upstream commit 95839225639ba7c3d8d7231b542728dcf222bf2d ] Commit a21d1becaa3f ("powerpc: Reintroduce is_kvm_guest() as a fast-path check") added is_kvm_guest() and changed kvm_para_available() to use it. is_kvm_guest() checks a static key, kvm_guest, and that static key is set in check_kvm_guest(). The problem is check_kvm_guest() is only called on pseries, and even then only in some configurations. That means is_kvm_guest() always returns false on all non-pseries and some pseries depending on configuration. That's a bug. For PR KVM guests this is noticable because they no longer do live patching of themselves, which can be detected by the omission of a message in dmesg such as: KVM: Live patching for a fast VM worked To fix it make check_kvm_guest() an initcall, to ensure it's always called at boot. It needs to be core so that it runs before kvm_guest_init() which is postcore. To be an initcall it needs to return int, where 0 means success, so update that. We still call it manually in pSeries_smp_probe(), because that runs before init calls are run. Fixes: a21d1becaa3f ("powerpc: Reintroduce is_kvm_guest() as a fast-path check") Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210623130514.2543232-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit 0cbe9d9639d1ea16908cdd0d590a28913b887c1d Author: Vaibhav Jain Date: Thu May 13 14:53:49 2021 +0530 powerpc/papr_scm: Make 'perf_stats' invisible if perf-stats unavailable [ Upstream commit ed78f56e1271f108e8af61baeba383dcd77adbec ] In case performance stats for an nvdimm are not available, reading the 'perf_stats' sysfs file returns an -ENOENT error. A better approach is to make the 'perf_stats' file entirely invisible to indicate that performance stats for an nvdimm are unavailable. So this patch updates 'papr_nd_attribute_group' to add a 'is_visible' callback implemented as newly introduced 'papr_nd_attribute_visible()' that returns an appropriate mode in case performance stats aren't supported in a given nvdimm. Also the initialization of 'papr_scm_priv.stat_buffer_len' is moved from papr_scm_nvdimm_init() to papr_scm_probe() so that it value is available when 'papr_nd_attribute_visible()' is called during nvdimm initialization. Even though 'perf_stats' attribute is available since v5.9, there are no known user-space tools/scripts that are dependent on presence of its sysfs file. Hence I dont expect any user-space breakage with this patch. Fixes: 2d02bf835e57 ("powerpc/papr_scm: Fetch nvdimm performance stats from PHYP") Signed-off-by: Vaibhav Jain Reviewed-by: Dan Williams Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210513092349.285021-1-vaibhav@linux.ibm.com Signed-off-by: Sasha Levin commit 3ffbbc876404ac6a6f081737f468d3d56be35cc3 Author: Nicholas Piggin Date: Tue Jun 22 15:30:36 2021 +1000 powerpc/64s: Fix copy-paste data exposure into newly created tasks [ Upstream commit f35d2f249ef05b9671e7898f09ad89aa78f99122 ] copy-paste contains implicit "copy buffer" state that can contain arbitrary user data (if the user process executes a copy instruction). This could be snooped by another process if a context switch hits while the state is live. So cp_abort is executed on context switch to clear out possible sensitive data and prevent the leak. cp_abort is done after the low level _switch(), which means it is never reached by newly created tasks, so they could snoop on this buffer between their first and second context switch. Fix this by doing the cp_abort before calling _switch. Add some comments which should make the issue harder to miss. Fixes: 07d2a628bc000 ("powerpc/64s: Avoid cpabort in context switch when possible") Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210622053036.474678-1-npiggin@gmail.com Signed-off-by: Sasha Levin commit ba824a836d68724c31a49196eb5b6f13d1415db4 Author: Andy Shevchenko Date: Wed Jun 16 16:43:03 2021 +0300 powerpc/papr_scm: Properly handle UUID types and API [ Upstream commit 0e8554b5d7801b0aebc6c348a0a9f7706aa17b3b ] Parse to and export from UUID own type, before dereferencing. This also fixes wrong comment (Little Endian UUID is something else) and should eliminate the direct strict types assignments. Fixes: 43001c52b603 ("powerpc/papr_scm: Use ibm,unit-guid as the iset cookie") Fixes: 259a948c4ba1 ("powerpc/pseries/scm: Use a specific endian format for storing uuid from the device tree") Signed-off-by: Andy Shevchenko Reviewed-by: Aneesh Kumar K.V Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210616134303.58185-1-andriy.shevchenko@linux.intel.com Signed-off-by: Sasha Levin commit 410006801ea408ef3f46c8ed97110a6888fc56ea Author: Nicholas Piggin Date: Wed Jun 23 14:12:45 2021 +1000 powerpc: Offline CPU in stop_this_cpu() [ Upstream commit bab26238bbd44d5a4687c0a64fd2c7f2755ea937 ] printk_safe_flush_on_panic() has special lock breaking code for the case where we panic()ed with the console lock held. It relies on panic IPI causing other CPUs to mark themselves offline. Do as most other architectures do. This effectively reverts commit de6e5d38417e ("powerpc: smp_send_stop do not offline stopped CPUs"), unfortunately it may result in some false positive warnings, but the alternative is more situations where we can crash without getting messages out. Fixes: de6e5d38417e ("powerpc: smp_send_stop do not offline stopped CPUs") Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210623041245.865134-1-npiggin@gmail.com Signed-off-by: Sasha Levin commit ed87ec89b7f6071de06380a0216e6aa420eb9742 Author: Vignesh Raghavendra Date: Tue Jun 22 20:27:04 2021 +0530 serial: 8250: 8250_omap: Fix possible interrupt storm on K3 SoCs [ Upstream commit b67e830d38fa9335d927fe67e812e3ed81b4689c ] On K3 family of SoCs (which includes AM654 SoC), it is observed that RX TIMEOUT is signalled after RX FIFO has been drained, in which case a dummy read of RX FIFO is required to clear RX TIMEOUT condition. Otherwise, this would lead to an interrupt storm. Fix this by introducing UART_RX_TIMEOUT_QUIRK flag and doing a dummy read in IRQ handler when RX TIMEOUT is reported with no data in RX FIFO. Fixes: be70874498f3 ("serial: 8250_omap: Add support for AM654 UART controller") Reported-by: Jan Kiszka Tested-by: Jan Kiszka Signed-off-by: Vignesh Raghavendra Link: https://lore.kernel.org/r/20210622145704.11168-1-vigneshr@ti.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a8f4bf372aae651893faa5073ae821c392c0bfd6 Author: Christophe JAILLET Date: Sun Jun 20 10:21:31 2021 +0200 staging: rtl8723bs: Fix an error handling path [ Upstream commit eb64c6f60ed5406da496cf772fee4b29674bcbb1 ] 'ret' is known to be 0 at this point. It must be set to -ENOMEM if a memory allocation occurs. Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/a9533d1594900152e1e64e9f09e54240e3b7062a.1624177169.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 905bb4b7c2c1b872b4ab579170b88f008792bc8d Author: Dave Hansen Date: Mon Jun 21 12:05:56 2021 -0700 selftests/sgx: remove checks for file execute permissions [ Upstream commit 4896df9d53ae5521f3ce83751e828ad70bc65c80 ] The SGX selftests can fail for a bunch of non-obvious reasons like 'noexec' permissions on /dev (which is the default *EVERYWHERE* it seems). A new test mistakenly also looked for +x permission on the /dev/sgx_enclave. File execute permissions really only apply to the ability of execve() to work on a file, *NOT* on the ability for an application to map the file with PROT_EXEC. SGX needs to mmap(PROT_EXEC), but doesn't need to execve() the device file. Remove the check. Fixes: 4284f7acb78b ("selftests/sgx: Improve error detection and messages") Reported-by: Tim Gardner Cc: Jarkko Sakkinen Cc: Reinette Chatre Cc: Dave Hansen Cc: Shuah Khan Cc: linux-sgx@vger.kernel.org Cc: linux-kselftest@vger.kernel.org Cc: linux-kernel@vger.kernel.org Tested-by: Reinette Chatre Signed-off-by: Dave Hansen Reviewed-by: Jarkko Sakkinen Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 16bd2acbad854c1d6c7ff93805902aba5f898d7b Author: Krzysztof Kozlowski Date: Wed Jun 23 15:43:15 2021 +0200 selftests/ftrace: fix event-no-pid on 1-core machine [ Upstream commit 07b60713b57a8f952d029a2b6849d003d9c16108 ] When running event-no-pid test on small machines (e.g. cloud 1-core instance), other events might not happen: + cat trace + cnt=0 + [ 0 -eq 0 ] + fail No other events were recorded [15] event tracing - restricts events based on pid notrace filtering [FAIL] Schedule a simple sleep task to be sure that some other process events get recorded. Fixes: ebed9628f5c2 ("selftests/ftrace: Add test to test new set_event_notrace_pid file") Signed-off-by: Krzysztof Kozlowski Acked-by: Steven Rostedt (VMware) Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 5b2499ec3fb022045a422df3b75338bb51384a13 Author: Christophe JAILLET Date: Fri May 21 13:21:01 2021 +0200 leds: ktd2692: Fix an error handling path [ Upstream commit ee78b9360e14c276f5ceaa4a0d06f790f04ccdad ] In 'ktd2692_parse_dt()', if an error occurs after a successful 'regulator_enable()' call, we should call 'regulator_enable()'. This is the same in 'ktd2692_probe()', if an error occurs after a successful 'ktd2692_parse_dt()' call. Instead of adding 'regulator_enable()' in several places, implement a resource managed solution and simplify the remove function accordingly. Fixes: b7da8c5c725c ("leds: Add ktd2692 flash LED driver") Signed-off-by: Christophe JAILLET Signed-off-by: Pavel Machek Signed-off-by: Sasha Levin commit 2f0b82e12dbcbea6fd52db23958bc417fe2743bb Author: Zhen Lei Date: Sat May 15 11:06:46 2021 +0800 leds: as3645a: Fix error return code in as3645a_parse_node() [ Upstream commit 96a30960a2c5246c8ffebe8a3c9031f9df094d97 ] Return error code -ENODEV rather than '0' when the indicator node can not be found. Fixes: a56ba8fbcb55 ("media: leds: as3645a: Add LED flash class driver") Reported-by: Hulk Robot Acked-by: Sakari Ailus Signed-off-by: Zhen Lei Signed-off-by: Pavel Machek Signed-off-by: Sasha Levin commit 3a75092cac53e4e82390f8808eebcb4be73d23cb Author: Shengjiu Wang Date: Tue Jun 22 20:31:24 2021 +0800 ASoC: fsl_spdif: Fix unexpected interrupt after suspend [ Upstream commit a7a0a2feb957e446b2bcf732f245ba04fc8b6314 ] When system enter suspend, the machine driver suspend callback function will be called, then the cpu driver trigger callback (SNDRV_PCM_TRIGGER_SUSPEND) be called, it would disable the interrupt. But the machine driver suspend and cpu dai driver suspend order maybe changed, the cpu dai driver's suspend callback is called before machine driver's suppend callback, then the interrupt is not cleared successfully in trigger callback. So need to clear interrupts in cpu dai driver's suspend callback to avoid such issue. Fixes: 9cb2b3796e08 ("ASoC: fsl_spdif: Add pm runtime function") Signed-off-by: Shengjiu Wang Reviewed-by: Fabio Estevam Link: https://lore.kernel.org/r/1624365084-7934-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d759ee26be7c3896e340b930ead1ae186e6dd9dd Author: Libin Yang Date: Wed May 5 11:37:02 2021 -0500 ASoC: Intel: sof_sdw: add SOF_RT715_DAI_ID_FIX for AlderLake [ Upstream commit 81cd42e5174ba7918edd3d006406ce21ebaa8507 ] AlderLake needs the flag SOF_RT715_DAI_ID_FIX if it is using the rt715 DMIC. Reviewed-by: Bard Liao Signed-off-by: Libin Yang Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210505163705.305616-11-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 19a4d95bfaddbce372ae999fa9357317bc5776c3 Author: Chung-Chiang Cheng Date: Fri Jun 18 15:59:25 2021 +0800 configfs: fix memleak in configfs_release_bin_file [ Upstream commit 3c252b087de08d3cb32468b54a158bd7ad0ae2f7 ] When reading binary attributes in progress, buffer->bin_buffer is setup in configfs_read_bin_file() but never freed. Fixes: 03607ace807b4 ("configfs: implement binary attributes") Signed-off-by: Chung-Chiang Cheng [hch: move the vfree rather than duplicating it] Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 2c3bf6723aa594a9e15065220f750c516e1d4f45 Author: Shengjiu Wang Date: Fri Jun 18 20:38:33 2021 +0800 ASoC: fsl_xcvr: disable all interrupts when suspend happens [ Upstream commit ea837090b388245744988083313f6e9c7c9b9699 ] There is an unhandled interrupt after suspend, which cause endless interrupt when system resume, so system may hang. Disable all interrupts in runtime suspend callback to avoid above issue. Fixes: 28564486866f ("ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver") Signed-off-by: Shengjiu Wang Reviewed-by: Fabio Estevam Link: https://lore.kernel.org/r/1624019913-3380-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 86f6ad630bfa513edf648a882b87a35aa81e2129 Author: Codrin Ciubotariu Date: Fri Jun 18 18:07:41 2021 +0300 ASoC: atmel-i2s: Fix usage of capture and playback at the same time [ Upstream commit 3b7961a326f8a7e03f54a19f02fedae8d488b80f ] For both capture and playback streams to work at the same time, only the needed values from a register need to be updated. Also, clocks should be enabled only when the first stream is started and stopped when there is no running stream. Fixes: b543e467d1a9 ("ASoC: atmel-i2s: add driver for the new Atmel I2S controller") Signed-off-by: Codrin Ciubotariu Link: https://lore.kernel.org/r/20210618150741.401739-2-codrin.ciubotariu@microchip.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0f2f89c0642acce3e26adb01a0344b07441a2869 Author: Codrin Ciubotariu Date: Fri Jun 18 18:07:40 2021 +0300 ASoC: atmel-i2s: Set symmetric sample bits [ Upstream commit 489a830a25e1730aebf7ff53430c170db9a1771b ] The I2S needs to have the same sample bits for both capture and playback streams. Fixes: b543e467d1a9 ("ASoC: atmel-i2s: add driver for the new Atmel I2S controller") Signed-off-by: Codrin Ciubotariu Link: https://lore.kernel.org/r/20210618150741.401739-1-codrin.ciubotariu@microchip.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7ff5db55f657a808a6dc8fcc845cd63b46ae420a Author: Nicholas Piggin Date: Tue May 18 00:03:55 2021 +1000 powerpc/powernv: Fix machine check reporting of async store errors [ Upstream commit 3729e0ec59a20825bd4c8c70996b2df63915e1dd ] POWER9 and POWER10 asynchronous machine checks due to stores have their cause reported in SRR1 but SRR1[42] is set, which in other cases indicates DSISR cause. Check for these cases and clear SRR1[42], so the cause matching uses the i-side (SRR1) table. Fixes: 7b9f71f974a1 ("powerpc/64s: POWER9 machine check handler") Fixes: 201220bb0e8c ("powerpc/powernv: Machine check handler for POWER10") Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210517140355.2325406-1-npiggin@gmail.com Signed-off-by: Sasha Levin commit c6c8a250117ffb4e6e47b9050c49176974eec81b Author: Marek Szyprowski Date: Fri Apr 23 22:46:24 2021 +0200 extcon: max8997: Add missing modalias string [ Upstream commit dc11fc2991e9efbceef93912b83e333d2835fb19 ] The platform device driver name is "max8997-muic", so advertise it properly in the modalias string. This fixes automated module loading when this driver is compiled as a module. Fixes: b76668ba8a77 ("Extcon: add MAX8997 extcon driver") Signed-off-by: Marek Szyprowski Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin commit 3076d98e2c7ff3f3cfef1bf2a08c506cf99cf785 Author: Stephan Gerhold Date: Mon May 31 15:34:35 2021 +0200 extcon: sm5502: Drop invalid register write in sm5502_reg_data [ Upstream commit d25b224f8e5507879b36a769a6d1324cf163466c ] When sm5502_init_dev_type() iterates over sm5502_reg_data to initialize the registers it is limited by ARRAY_SIZE(sm5502_reg_data). There is no need to add another empty element to sm5502_reg_data. Having the additional empty element in sm5502_reg_data will just result in writing 0xff to register 0x00, which does not really make sense. Fixes: 914b881f9452 ("extcon: sm5502: Add support new SM5502 extcon device driver") Signed-off-by: Stephan Gerhold Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin commit b27d30b9a006d13b24aeaf1d9ae0e1fce9439ba0 Author: Christophe JAILLET Date: Sat Jun 5 15:17:43 2021 +0200 phy: ti: dm816x: Fix the error handling path in 'dm816x_usb_phy_probe() [ Upstream commit f7eedcb8539ddcbb6fe7791f1b4ccf43f905c72f ] Add an error handling path in the probe to release some resources, as already done in the remove function. Fixes: 609adde838f4 ("phy: Add a driver for dm816x USB PHY") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/ac5136881f6bdec50be19b3bf73b3bc1b15ef1f1.1622898974.git.christophe.jaillet@wanadoo.fr Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit a3b870c5f130258b52c7257fffb77e979db27d15 Author: Kunihiko Hayashi Date: Mon Jun 7 12:50:42 2021 +0900 phy: uniphier-pcie: Fix updating phy parameters [ Upstream commit 4a90bbb478dbf18ecdec9dcf8eb708e319d24264 ] The current driver uses a value from register TEST_O as the original value for register TEST_I, though, the value is overwritten by "param", so there is a bug that the original value isn't no longer used. The value of TEST_O[7:0] should be masked with "mask", replaced with "param", and placed in the bitfield TESTI_DAT_MASK as new TEST_I value. Fixes: c6d9b1324159 ("phy: socionext: add PCIe PHY driver support") Signed-off-by: Kunihiko Hayashi Link: https://lore.kernel.org/r/1623037842-19363-1-git-send-email-hayashi.kunihiko@socionext.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 96e9297738d60ce77f5597d65135c36dfb85bb59 Author: Richard Fitzgerald Date: Fri Jun 18 15:47:45 2021 +0100 soundwire: stream: Fix test for DP prepare complete [ Upstream commit 3d3e88e336338834086278236d42039f3cde50e1 ] In sdw_prep_deprep_slave_ports(), after the wait_for_completion() the DP prepare status register is read. If this indicates that the port is now prepared, the code should continue with the port setup. It is irrelevant whether the wait_for_completion() timed out if the port is now ready. The previous implementation would always fail if the wait_for_completion() timed out, even if the port was reporting successful prepare. This patch also fixes a minor bug where the return from sdw_read() was not checked for error - any error code with LSBits clear could be misinterpreted as a successful port prepare. Fixes: 79df15b7d37c ("soundwire: Add helpers for ports operations") Signed-off-by: Richard Fitzgerald Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210618144745.30629-1-rf@opensource.cirrus.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit f7150fc410e76dddbbe75a137b2ce98590e2b730 Author: Zhen Lei Date: Fri May 14 16:13:00 2021 +0800 scsi: mpt3sas: Fix error return value in _scsih_expander_add() [ Upstream commit d6c2ce435ffe23ef7f395ae76ec747414589db46 ] When an expander does not contain any 'phys', an appropriate error code -1 should be returned, as done elsewhere in this function. However, we currently do not explicitly assign this error code to 'rc'. As a result, 0 was incorrectly returned. Link: https://lore.kernel.org/r/20210514081300.6650-1-thunder.leizhen@huawei.com Fixes: f92363d12359 ("[SCSI] mpt3sas: add new driver supporting 12GB SAS") Reported-by: Hulk Robot Signed-off-by: Zhen Lei Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 6e0b909ad7462a83bd66654f93183f72dff80743 Author: Christophe JAILLET Date: Sat Jun 12 07:39:51 2021 +0200 habanalabs: Fix an error handling path in 'hl_pci_probe()' [ Upstream commit 3002f467a0b0a70aec01d9f446da4ac8c6fda10b ] If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it must be undone by a corresponding 'pci_disable_pcie_error_reporting()' call, as already done in the remove function. Fixes: 2e5eda4681f9 ("habanalabs: PCIe Advanced Error Reporting support") Signed-off-by: Christophe JAILLET Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit e0eaeea9a9ff070af2d1fa0c293e6e3b5ba007d7 Author: Yang Yingliang Date: Tue Jun 1 20:58:14 2021 +0800 mtd: rawnand: marvell: add missing clk_disable_unprepare() on error in marvell_nfc_resume() [ Upstream commit ae94c49527aa9bd3b563349adc4b5617747ca6bd ] Add clk_disable_unprepare() on error path in marvell_nfc_resume(). Fixes: bd9c3f9b3c00 ("mtd: rawnand: marvell: add suspend and resume hooks") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210601125814.3260364-1-yangyingliang@huawei.com Signed-off-by: Sasha Levin commit 93968d6341424830eb56c6f28f3fbfaa1c504625 Author: Geert Uytterhoeven Date: Wed Jun 16 11:27:44 2021 +0200 of: Fix truncation of memory sizes on 32-bit platforms [ Upstream commit 2892d8a00d23d511a0591ac4b2ff3f050ae1f004 ] Variable "size" has type "phys_addr_t", which can be either 32-bit or 64-bit on 32-bit systems, while "unsigned long" is always 32-bit on 32-bit systems. Hence the cast in (unsigned long)size / SZ_1M may truncate a 64-bit size to 32-bit, as casts have a higher operator precedence than divisions. Fix this by inverting the order of the cast and division, which should be safe for memory blocks smaller than 4 PiB. Note that the division is actually a shift, as SZ_1M is a power-of-two constant, hence there is no need to use div_u64(). While at it, use "%lu" to format "unsigned long". Fixes: e8d9d1f5485b52ec ("drivers: of: add initialization code for static reserved memory") Fixes: 3f0c8206644836e4 ("drivers: of: add initialization code for dynamic reserved memory") Signed-off-by: Geert Uytterhoeven Acked-by: Marek Szyprowski Link: https://lore.kernel.org/r/4a1117e72d13d26126f57be034c20dac02f1e915.1623835273.git.geert+renesas@glider.be Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit fe1870f414cb337e06ad45b62e35cd2dc37c9148 Author: Richard Fitzgerald Date: Wed Jun 16 14:56:04 2021 +0100 ASoC: cs42l42: Correct definition of CS42L42_ADC_PDN_MASK [ Upstream commit fac165f22ac947b55407cd3a60a2a9824f905235 ] The definition of CS42L42_ADC_PDN_MASK was incorrectly defined as the HP_PDN bit. Fixes: 2c394ca79604 ("ASoC: Add support for CS42L42 codec") Signed-off-by: Richard Fitzgerald Link: https://lore.kernel.org/r/20210616135604.19363-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit db91960d40bcfb5fa6d1d3a5c33c9b361da4ea9c Author: Jonathan Cameron Date: Sun Jun 13 16:23:01 2021 +0100 iio: prox: isl29501: Fix buffer alignment in iio_push_to_buffers_with_timestamp() [ Upstream commit 92babc9938ebbf4050f2fba774836f7edc16a570 ] Add __aligned(8) to ensure the buffer passed to iio_push_to_buffers_with_timestamp() is suitable for the naturally aligned timestamp that will be inserted. Here an explicit structure is not used, because the holes would necessitate the addition of an explict memset(), to avoid a kernel data leak, making for a less minimal fix. Fixes: 1c28799257bc ("iio: light: isl29501: Add support for the ISL29501 ToF sensor.") Signed-off-by: Jonathan Cameron Cc: Mathieu Othacehe Reviewed-by: Nuno Sá Link: https://lore.kernel.org/r/20210613152301.571002-9-jic23@kernel.org Signed-off-by: Sasha Levin commit 4637815d7922c4bce3bacb13dd1fb5e9a7d167d8 Author: Jonathan Cameron Date: Sun Jun 13 16:23:00 2021 +0100 iio: light: vcnl4035: Fix buffer alignment in iio_push_to_buffers_with_timestamp() [ Upstream commit ec90b52c07c0403a6db60d752484ec08d605ead0 ] Add __aligned(8) to ensure the buffer passed to iio_push_to_buffers_with_timestamp() is suitable for the naturally aligned timestamp that will be inserted. Here an explicit structure is not used, because the holes would necessitate the addition of an explict memset(), to avoid a potential kernel data leak, making for a less minimal fix. Fixes: 55707294c4eb ("iio: light: Add support for vishay vcnl4035") Signed-off-by: Jonathan Cameron Cc: Parthiban Nallathambi Reviewed-by: Nuno Sá Link: https://lore.kernel.org/r/20210613152301.571002-8-jic23@kernel.org Signed-off-by: Sasha Levin commit 1e8c052902861cadcc3ac39e4800f0ca8f335622 Author: Maciej W. Rozycki Date: Thu Jun 10 20:38:34 2021 +0200 serial: 8250: Actually allow UPF_MAGIC_MULTIPLIER baud rates [ Upstream commit 78bcae8616ac277d6cb7f38e211493948ed73e30 ] Support for magic baud rate divisors of 32770 and 32769 used with SMSC Super I/O chips for extra baud rates of 230400 and 460800 respectively where base rate is 115200[1] has been added around Linux 2.5.64, which predates our repo history, but the origin could be identified as commit 2a717aad772f ("Merge with Linux 2.5.64.") with the old MIPS/Linux repo also at: . Code that is now in `serial8250_do_get_divisor' was added back then to `serial8250_get_divisor', but that code would only ever trigger if one of the higher baud rates was actually requested, and that cannot ever happen, because the earlier call to `serial8250_get_baud_rate' never returns them. This is because it calls `uart_get_baud_rate' with the maximum requested being the base rate, that is clk/16 or 115200 for SMSC chips at their nominal clock rate. Fix it then and allow UPF_MAGIC_MULTIPLIER baud rates to be selected, by requesting the maximum baud rate of clk/4 rather than clk/16 if the flag has been set. Also correct the minimum baud rate, observing that these ports only support actual (non-magic) divisors of up to 32767 only. References: [1] "FDC37M81x, PC98/99 Compliant Enhanced Super I/O Controller with Keyboard/Mouse Wake-Up", Standard Microsystems Corporation, Rev. 03/27/2000, Table 31 - "Baud Rates", p. 77 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Maciej W. Rozycki Link: https://lore.kernel.org/r/alpine.DEB.2.21.2105190412280.29169@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 63432a8b2af244ea9a82652ce5a4a2d3e95883e9 Author: Dmitry Osipenko Date: Sun Jun 13 17:59:36 2021 +0300 usb: phy: tegra: Correct definition of B_SESS_VLD_WAKEUP_EN bit [ Upstream commit 7917e90667bc8dce02daa3c2e6df47f6fc9481f7 ] The B_SESS_VLD_WAKEUP_EN bit 6 was added by a mistake in a previous commit. This bit corresponds to B_SESS_END_WAKEUP_EN, which we don't use. The B_VBUS_VLD_WAKEUP_EN doesn't exist at all and B_SESS_VLD_WAKEUP_EN needs to be in place of it. We don't utilize B-sensors in the driver, so it never was a problem, nevertheless let's correct the definition of the bits. Fixes: 35192007d28d ("usb: phy: tegra: Support waking up from a low power mode") Signed-off-by: Dmitry Osipenko Link: https://lore.kernel.org/r/20210613145936.9902-2-digetx@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 13c6cb27fe1734e25ba0344a3c8b52298d7eecc7 Author: Dmitry Osipenko Date: Sun Jun 13 17:59:35 2021 +0300 usb: phy: tegra: Wait for VBUS wakeup status deassertion on suspend [ Upstream commit 6f8d39a8ef55efde414b6e574384acbce70c3119 ] Some devices need an extra delay after losing VBUS, otherwise VBUS may be detected as active at suspend time, preventing the PHY's suspension by the VBUS detection sensor. This problem was found on Asus Transformer TF700T (Tegra30) tablet device, where the USB PHY wakes up immediately from suspend because VBUS sensor continues to detect VBUS as active after disconnection. We need to poll the PHY's VBUS wakeup status until it's deasserted before suspending PHY in order to fix this minor trouble. Fixes: 35192007d28d ("usb: phy: tegra: Support waking up from a low power mode") Reported-by: Maxim Schwalm # Asus TF700T Tested-by: Maxim Schwalm # Asus TF700T Reviewed-by: Peter Chen Signed-off-by: Dmitry Osipenko Link: https://lore.kernel.org/r/20210613145936.9902-1-digetx@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 94dd90587784565e8bbc177f13d375df63e89152 Author: Sergio Paracuellos Date: Mon Jun 14 12:06:17 2021 +0200 staging: mt7621-dts: fix pci address for PCI memory range [ Upstream commit 5b4f167ef3555ec4c334a8dc89c1b44bb2c6bff5 ] Driver code call 'devm_of_pci_get_host_bridge_resources' to get resources and properly fill 'bridge->windows' and 'bridge->dma_ranges'. After parsing the ranges and store as resources, at the end it makes a call to pci function 'pci_add_resource_offset' to set the offset for the memory resource. To calculate offset, resource start address subtracts pci address of the range. MT7621 does not need any offset for the memory resource. Moreover, setting an offset got into 'WARN_ON' calls from pci devices driver code. Until now memory range pci_addr was being '0x00000000' and res->start is '0x60000000' but becase pci controller driver was manually setting resources and adding them using pci function 'pci_add_resource' where a zero is passed as offset, things was properly working. Since PCI_IOBASE is defined now for ralink we don't set nothing manually anymore so we have to properly fix PCI address for this range to make things work and the new pci address must be set to '0x60000000'. Doing in this way the subtract result obtain zero as offset and pci device driver code properly works. Fixes: d59578da2bb8 ("staging: mt7621-dts: add dts files") Signed-off-by: Sergio Paracuellos Link: https://lore.kernel.org/r/20210614100617.28753-4-sergio.paracuellos@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ab28a20dda470a59e54817c51abdb4782abef01a Author: Junhao He Date: Mon Jun 14 11:58:57 2021 -0600 coresight: core: Fix use of uninitialized pointer [ Upstream commit d777a8991847729ec4e2a13fcad58c2b00bb19dc ] Currently the pointer "sink" might be checked before initialized. Fix this by initializing this pointer. Link: https://lore.kernel.org/r/1620912469-52222-2-git-send-email-liuqi115@huawei.com Fixes: 6d578258b955 ("coresight: Make sysfs functional on topologies with per core sink") Signed-off-by: Junhao He Signed-off-by: Qi Liu Signed-off-by: Suzuki K Poulose Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20210614175901.532683-3-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5f7ce5c416f4d3ab2358645f37023ed35a91009e Author: Pavel Skripkin Date: Mon Jun 14 01:00:19 2021 +0300 staging: rtl8712: fix memory leak in rtl871x_load_fw_cb [ Upstream commit e02a3b945816a77702a2769a70ef5f9b06e49d54 ] There is a leak in rtl8712 driver. The problem was in non-freed adapter data if firmware load failed. This leak can be reproduced with this code: https://syzkaller.appspot.com/text?tag=ReproC&x=16612f02d00000, Autoload must fail (to not hit memory leak reported by syzkaller) There are 2 possible ways how rtl871x_load_fw_cb() and r871xu_dev_remove() can be called (in case of fw load error). 1st case: r871xu_dev_remove() then rtl871x_load_fw_cb() In this case r871xu_dev_remove() will wait for completion and then will jump to the end, because rtl871x_load_fw_cb() set intfdata to NULL: if (pnetdev) { struct _adapter *padapter = netdev_priv(pnetdev); /* never exit with a firmware callback pending */ wait_for_completion(&padapter->rtl8712_fw_ready); pnetdev = usb_get_intfdata(pusb_intf); usb_set_intfdata(pusb_intf, NULL); if (!pnetdev) goto firmware_load_fail; ... clean up code here ... } 2nd case: rtl871x_load_fw_cb() then r871xu_dev_remove() In this case pnetdev (from code snippet above) will be zero (because rtl871x_load_fw_cb() set it to NULL) And clean up code won't be executed again. So, in all cases we need to free adapted data in rtl871x_load_fw_cb(), because disconnect function cannot take care of it. And there won't be any race conditions, because complete() call happens after setting intfdata to NULL. In previous patch I moved out free_netdev() from r8712_free_drv_sw() and that's why now it's possible to free adapter data and then call complete. Fixes: 8c213fa59199 ("staging: r8712u: Use asynchronous firmware loading") Signed-off-by: Pavel Skripkin Link: https://lore.kernel.org/r/81e68fe0194499cc2e7692d35bc4dcf167827d8f.1623620630.git.paskripkin@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7709bce7514ddc51b08a7274fb35305ac2777479 Author: Pavel Skripkin Date: Mon Jun 14 01:00:13 2021 +0300 staging: rtl8712: fix error handling in r871xu_drv_init [ Upstream commit d1d3e3cdfda8eb91f0e24be7ec8be1e6e01b3a1c ] Previous error handling path was unique for all possible errors and there was unnecessary branching. Also, one step for freeing drv_sw was missing. All these problems was fixed by restructuring error handling path. Also, moved out free_netdev() from r8712_free_drv_sw() for correct error handling. Fixes: 2865d42c78a9 ("staging: r8712u: Add the new driver to the mainline kernel") Signed-off-by: Pavel Skripkin Link: https://lore.kernel.org/r/febb00f72354449bb4d305f373d6d2f47e539ab4.1623620630.git.paskripkin@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cf011614add0f71cd7ba3b1dcc0e753ac8f1ecb7 Author: Dan Carpenter Date: Mon Jun 14 12:58:36 2021 +0300 staging: gdm724x: check for overflow in gdm_lte_netif_rx() [ Upstream commit 7002b526f4ff1f6da34356e67085caafa6be383a ] This code assumes that "len" is at least 62 bytes, but we need a check to prevent a read overflow. Fixes: 61e121047645 ("staging: gdm7240: adding LTE USB driver") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/YMcoTPsCYlhh2TQo@mwanda Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b48eb064f4efbf457f8e3e0ee990fd83cc06b40e Author: Dan Carpenter Date: Mon Jun 14 12:55:35 2021 +0300 staging: gdm724x: check for buffer overflow in gdm_lte_multi_sdu_pkt() [ Upstream commit 4a36e160856db8a8ddd6a3d2e5db5a850ab87f82 ] There needs to be a check to verify that we don't read beyond the end of "buf". This function is called from do_rx(). The "buf" is the USB transfer_buffer and "len" is "urb->actual_length". Fixes: 61e121047645 ("staging: gdm7240: adding LTE USB driver") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/YMcnl4zCwGWGDVMG@mwanda Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit bf0c039cd5d81e18e3d0b901c1de891f564b47c4 Author: Shengjiu Wang Date: Fri Jun 11 14:18:38 2021 +0800 ASoC: fsl_spdif: Fix error handler with pm_runtime_enable [ Upstream commit 28108d71ee11a7232e1102effab3361049dcd3b8 ] There is error message when defer probe happens: fsl-spdif-dai 2dab0000.spdif: Unbalanced pm_runtime_enable! Fix the error handler with pm_runtime_enable and add fsl_spdif_remove() for pm_runtime_disable. Fixes: 9cb2b3796e08 ("ASoC: fsl_spdif: Add pm runtime function") Signed-off-by: Shengjiu Wang Link: https://lore.kernel.org/r/1623392318-26304-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a122de4862713afc8b26ef2ebb6af407c5ace959 Author: Jonathan Cameron Date: Sun Jun 13 16:22:59 2021 +0100 iio: light: vcnl4000: Fix buffer alignment in iio_push_to_buffers_with_timestamp() [ Upstream commit dce793c0ab00c35039028fdcd5ce123805a01361 ] Add __aligned(8) to ensure the buffer passed to iio_push_to_buffers_with_timestamp() is suitable for the naturally aligned timestamp that will be inserted. Here an explicit structure is not used, because the holes would necessitate the addition of an explict memset(), to avoid a kernel data leak, making for a less minimal fix. Found during an audit of all callers of iio_push_to_buffers_with_timestamp() Fixes: 8fe78d5261e7 ("iio: vcnl4000: Add buffer support for VCNL4010/20.") Signed-off-by: Jonathan Cameron Cc: Mathieu Othacehe Reviewed-by: Nuno Sá Link: https://lore.kernel.org/r/20210613152301.571002-7-jic23@kernel.org Signed-off-by: Sasha Levin commit 181d881980c021c9086907be01e26be7ecbda598 Author: Jonathan Cameron Date: Sun Jun 13 16:22:58 2021 +0100 iio: magn: rm3100: Fix alignment of buffer in iio_push_to_buffers_with_timestamp() [ Upstream commit b8f939fd20690623cb24845a563e7bc1e4a21482 ] Add __aligned(8) to ensure the buffer passed to iio_push_to_buffers_with_timestamp() is suitable for the naturally aligned timestamp that will be inserted. Here an explicit structure is not used, because this buffer is used in a non-trivial way for data repacking. Fixes: 121354b2eceb ("iio: magnetometer: Add driver support for PNI RM3100") Signed-off-by: Jonathan Cameron Cc: Song Qiang Reviewed-by: Nuno Sá Link: https://lore.kernel.org/r/20210613152301.571002-6-jic23@kernel.org Signed-off-by: Sasha Levin commit 3563bb70d6baa0a5e8082397e13f62f26053c04d Author: Jonathan Cameron Date: Sun Jun 13 16:22:57 2021 +0100 iio: adc: ti-ads8688: Fix alignment of buffer in iio_push_to_buffers_with_timestamp() [ Upstream commit 61fa5dfa5f52806f5ce37a0ba5712c271eb22f98 ] Add __aligned(8) to ensure the buffer passed to iio_push_to_buffers_with_timestamp() is suitable for the naturally aligned timestamp that will be inserted. Fixes: f214ff521fb1 ("iio: ti-ads8688: Update buffer allocation for timestamps") Signed-off-by: Jonathan Cameron Reviewed-by: Nuno Sá Link: https://lore.kernel.org/r/20210613152301.571002-5-jic23@kernel.org Signed-off-by: Sasha Levin commit 129cef3b2a6c0cb5cc262667b3580cfd9cfaee91 Author: Jonathan Cameron Date: Sun Jun 13 16:22:56 2021 +0100 iio: adc: mxs-lradc: Fix buffer alignment in iio_push_to_buffers_with_timestamp() [ Upstream commit 6a6be221b8bd561b053f0701ec752a5ed9007f69 ] To make code more readable, use a structure to express the channel layout and ensure the timestamp is 8 byte aligned. Add a comment on why the buffer is the size it is as not immediately obvious. Found during an audit of all calls of this function. Fixes: 6dd112b9f85e ("iio: adc: mxs-lradc: Add support for ADC driver") Signed-off-by: Jonathan Cameron Cc: Andreas Klinger Reviewed-by: Nuno Sá Link: https://lore.kernel.org/r/20210613152301.571002-4-jic23@kernel.org Signed-off-by: Sasha Levin commit 4a67fd76a418eb89135b3ec209c37355dcf26eca Author: Jonathan Cameron Date: Sun Jun 13 16:22:55 2021 +0100 iio: adc: hx711: Fix buffer alignment in iio_push_to_buffers_with_timestamp() [ Upstream commit afe2a789fbf7acd1a05407fc7839cc08d23825e3 ] To make code more readable, use a structure to express the channel layout and ensure the timestamp is 8 byte aligned. Found during an audit of all calls of this function. Fixes: d3bf60450d47 ("iio: hx711: add triggered buffer support") Signed-off-by: Jonathan Cameron Cc: Andreas Klinger Reviewed-by: Nuno Sá Link: https://lore.kernel.org/r/20210613152301.571002-3-jic23@kernel.org Signed-off-by: Sasha Levin commit 60882b0995a368d3b544e3202a9975d9f3245a9a Author: Jonathan Cameron Date: Sun Jun 13 16:22:54 2021 +0100 iio: adc: at91-sama5d2: Fix buffer alignment in iio_push_to_buffers_with_timestamp() [ Upstream commit 8f884758966259fa8c50c137ac6d4ce9bb7859db ] To make code more readable, use a structure to express the channel layout and ensure the timestamp is 8 byte aligned. Found during an audit of all calls of this function. Fixes: 5e1a1da0f8c9 ("iio: adc: at91-sama5d2_adc: add hw trigger and buffer support") Signed-off-by: Jonathan Cameron Cc: Eugen Hristev Reviewed-by: Nuno Sá Link: https://lore.kernel.org/r/20210613152301.571002-2-jic23@kernel.org Signed-off-by: Sasha Levin commit 5e8a3efb3e9ca18d1a9988588edc29e27b69198c Author: Wei Yongjun Date: Mon May 24 14:05:36 2021 +0000 iio: dummy: Fix build error when CONFIG_IIO_TRIGGERED_BUFFER is not set [ Upstream commit 94588c1bf1c8701392e1dc105c670d0d2fc7676a ] Gcc reports build error when CONFIG_IIO_TRIGGERED_BUFFER is not set: riscv64-linux-gnu-ld: drivers/iio/dummy/iio_simple_dummy_buffer.o: in function `iio_simple_dummy_configure_buffer': iio_simple_dummy_buffer.c:(.text+0x2b0): undefined reference to `iio_triggered_buffer_setup_ext' riscv64-linux-gnu-ld: drivers/iio/dummy/iio_simple_dummy_buffer.o: in function `.L0 ': iio_simple_dummy_buffer.c:(.text+0x2fc): undefined reference to `iio_triggered_buffer_cleanup' Fix it by select IIO_TRIGGERED_BUFFER for config IIO_SIMPLE_DUMMY_BUFFER. Fixes: 738f6ba11800 ("iio: dummy: iio_simple_dummy_buffer: use triggered buffer core calls") Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit d4ff9e9ed5af7b8f82567e142f3f1b1b37e7cc24 Author: David Gow Date: Thu Jun 10 20:57:25 2021 -0700 kunit: Fix result propagation for parameterised tests [ Upstream commit 384426bd101cb3cd580b18de19d4891ec5ca5bf9 ] When one parameter of a parameterised test failed, its failure would be propagated to the overall test, but not to the suite result (unless it was the last parameter). This is because test_case->success was being reset to the test->success result after each parameter was used, so a failing test's result would be overwritten by a non-failing result. The overall test result was handled in a third variable, test_result, but this was discarded after the status line was printed. Instead, just propagate the result after each parameter run. Signed-off-by: David Gow Fixes: fadb08e7c750 ("kunit: Support for Parameterized Testing") Reviewed-by: Marco Elver Reviewed-by: Brendan Higgins Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 61dc159ec20ec756fd0fabcca94009968ab84485 Author: Miquel Raynal Date: Thu May 27 10:43:45 2021 +0200 mtd: spinand: Fix double counting of ECC stats [ Upstream commit c93081b265735db2417f0964718516044d06b1a2 ] In the raw NAND world, ECC engines increment ecc_stats and the final caller is responsible for returning -EBADMSG if the verification failed. In the SPI-NAND world it was a bit different until now because there was only one possible ECC engine: the on-die one. Indeed, the spinand_mtd_read() call was incrementing the ecc_stats counters depending on the outcome of spinand_check_ecc_status() directly. So now let's split the logic like this: - spinand_check_ecc_status() is specific to the SPI-NAND on-die engine and is kept very simple: it just returns the ECC status (bonus point: the content of this helper can be overloaded). - spinand_ondie_ecc_finish_io_req() is the caller of spinand_check_ecc_status() and will increment the counters and eventually return -EBADMSG. - spinand_mtd_read() is not tied to the on-die ECC implementation and should be able to handle results coming from other ECC engines: it has the responsibility of returning the maximum number of bitflips which happened during the entire operation as this is the only helper that is aware that several pages may be read in a row. Fixes: 945845b54c9c ("mtd: spinand: Instantiate a SPI-NAND on-die ECC engine") Reported-by: YouChing Lin Signed-off-by: Miquel Raynal Tested-by: YouChing Lin Link: https://lore.kernel.org/linux-mtd/20210527084345.208215-1-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin commit 505056e4bdc2674268c75985f52ed399c3b4c270 Author: Mika Westerberg Date: Mon Jun 7 13:37:46 2021 +0300 thunderbolt: Bond lanes only when dual_link_port != NULL in alloc_dev_default() [ Upstream commit a0d36fa1065901f939b04587a09c65303a64ac88 ] We should not dereference ->dual_link_port if it is NULL and lane bonding is requested. For this reason move lane bonding configuration happen inside the block where ->dual_link_port != NULL. Fixes: 54509f5005ca ("thunderbolt: Add KUnit tests for path walking") Reported-by: kernel test robot Reported-by: Dan Carpenter Reviewed-by: Yehezkel Bernat Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit ab9e7649319692428b9dad4319c309b1d550c14b Author: Michael Walle Date: Mon Jun 7 13:27:43 2021 +0200 mtd: spi-nor: otp: return -EROFS if region is read-only [ Upstream commit 388161ca45c911f566b71716bce5ff0119fb5522 ] SPI NOR flashes will just ignore program commands if the OTP region is locked. Thus, a user might not notice that the intended write didn't end up in the flash. Return -EROFS to the user in this case. From what I can tell, chips/cfi_cmdset_0001.c also return this error code. One could optimize spi_nor_mtd_otp_range_is_locked() to read the status register only once and not for every OTP region, but for that we would need some more invasive changes. Given that this is one-time-programmable memory and the normal access mode is reading, we just live with the small overhead. By moving the code around a bit, we can just check the length before calling spi_nor_mtd_otp_range_is_locked() and avoid an underflow there if a len is 0. This way we don't need to take the lock either. We also skip the "*retlen = 0" assignment, mtdcore already takes care of that for us. Fixes: 069089acf88b ("mtd: spi-nor: add OTP support") Signed-off-by: Michael Walle Signed-off-by: Vignesh Raghavendra Reviewed-by: Pratyush Yadav Reviewed-by: Tudor Ambarus Signed-off-by: Sasha Levin commit 534ba50f4de9c2a34a546097bfcde613e8183dcd Author: Michael Walle Date: Mon Jun 7 13:27:41 2021 +0200 mtd: spi-nor: otp: fix access to security registers in 4 byte mode [ Upstream commit b97b1a769849beb6b40b740817b06f1a50e1c589 ] The security registers either take a 3 byte or a 4 byte address offset, depending on the address mode of the flash. Thus just leave the nor->addr_width as is. Fixes: cad3193fe9d1 ("mtd: spi-nor: implement OTP support for Winbond and similar flashes") Signed-off-by: Michael Walle Signed-off-by: Vignesh Raghavendra Reviewed-by: Tudor Ambarus Acked-by: Pratyush Yadav Signed-off-by: Sasha Levin commit 3802b97849b6e60718aade25ee3fe92f4a2651bb Author: Andy Shevchenko Date: Tue Jun 8 01:17:56 2021 +0300 eeprom: idt_89hpesx: Restore printing the unsupported fwnode name [ Upstream commit e0db3deea73ba418bf5dc21f5a4e32ca87d16dde ] When iterating over child firmware nodes restore printing the name of ones that are not supported. While at it, refactor loop body to clearly show that we stop at the first match. Fixes: db15d73e5f0e ("eeprom: idt_89hpesx: Support both ACPI and OF probing") Cc: Huy Duong Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210607221757.81465-2-andy.shevchenko@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 21652cc1d36833fcd1a7d0de61688ef6d82ba291 Author: Andy Shevchenko Date: Tue Jun 8 01:17:55 2021 +0300 eeprom: idt_89hpesx: Put fwnode in matching case during ->probe() [ Upstream commit 3f6ee1c095156a74ab2df605af13020f1ce3e600 ] device_get_next_child_node() bumps a reference counting of a returned variable. We have to balance it whenever we return to the caller. Fixes: db15d73e5f0e ("eeprom: idt_89hpesx: Support both ACPI and OF probing") Cc: Huy Duong Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210607221757.81465-1-andy.shevchenko@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9d5d1903cde3c7e9dbe4297ac51c1faef1dcbeaa Author: Clément Lassieur Date: Thu Jun 3 17:59:21 2021 +0200 usb: dwc2: Don't reset the core after setting turnaround time [ Upstream commit aafe93516b8567ab5864e1f4cd3eeabc54fb0e5a ] Every time the hub signals a reset while we (device) are hsotg->connected, dwc2_hsotg_core_init_disconnected() is called, which in turn calls dwc2_hs_phy_init(). GUSBCFG.USBTrdTim is cleared upon Core Soft Reset, so if hsotg->params.phy_utmi_width is 8-bit, the value of GUSBCFG.USBTrdTim (the default one: 0x5, corresponding to 16-bit) is always different from hsotg->params.phy_utmi_width, thus dwc2_core_reset() is called every time (usbcfg != usbcfg_old), which causes 2 issues: 1) The call to dwc2_core_reset() does another reset 300us after the initial Chirp K of the first reset (which should last at least Tuch = 1ms), and messes up the High-speed Detection Handshake: both hub and device drive current into the D+ and D- lines at the same time. 2) GUSBCFG.USBTrdTim is cleared by the second reset, so its value is always the default one (0x5). Setting GUSBCFG.USBTrdTim after the potential call to dwc2_core_reset() fixes both issues. It is now set even when select_phy is false because the cost of the Core Soft Reset is removed. Fixes: 1e868545f2bb ("usb: dwc2: gadget: Move gadget phy init into core phy init") Signed-off-by: Clément Lassieur Link: https://lore.kernel.org/r/20210603155921.940651-1-clement@lassieur.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3328f627c90b6fe44d29516883af2dc006f268cf Author: Andrew Gabbasov Date: Thu Jun 3 12:15:07 2021 -0500 usb: gadget: f_fs: Fix setting of device and driver data cross-references [ Upstream commit ecfbd7b9054bddb12cea07fda41bb3a79a7b0149 ] FunctionFS device structure 'struct ffs_dev' and driver data structure 'struct ffs_data' are bound to each other with cross-reference pointers 'ffs_data->private_data' and 'ffs_dev->ffs_data'. While the first one is supposed to be valid through the whole life of 'struct ffs_data' (and while 'struct ffs_dev' exists non-freed), the second one is cleared in 'ffs_closed()' (called from 'ffs_data_reset()' or the last 'ffs_data_put()'). This can be called several times, alternating in different order with 'ffs_free_inst()', that, if possible, clears the other cross-reference. As a result, different cases of these calls order may leave stale cross-reference pointers, used when the pointed structure is already freed. Even if it occasionally doesn't cause kernel crash, this error is reported by KASAN-enabled kernel configuration. For example, the case [last 'ffs_data_put()' - 'ffs_free_inst()'] was fixed by commit cdafb6d8b8da ("usb: gadget: f_fs: Fix use-after-free in ffs_free_inst"). The other case ['ffs_data_reset()' - 'ffs_free_inst()' - 'ffs_data_put()'] now causes KASAN reported error [1], when 'ffs_data_reset()' clears 'ffs_dev->ffs_data', then 'ffs_free_inst()' frees the 'struct ffs_dev', but can't clear 'ffs_data->private_data', which is then accessed in 'ffs_closed()' called from 'ffs_data_put()'. This happens since 'ffs_dev->ffs_data' reference is cleared too early. Moreover, one more use case, when 'ffs_free_inst()' is called immediately after mounting FunctionFS device (that is before the descriptors are written and 'ffs_ready()' is called), and then 'ffs_data_reset()' or 'ffs_data_put()' is called from accessing "ep0" file or unmounting the device. This causes KASAN error report like [2], since 'ffs_dev->ffs_data' is not yet set when 'ffs_free_inst()' can't properly clear 'ffs_data->private_data', that is later accessed to freed structure. Fix these (and may be other) cases of stale pointers access by moving setting and clearing of the mentioned cross-references to the single places, setting both of them when 'struct ffs_data' is created and bound to 'struct ffs_dev', and clearing both of them when one of the structures is destroyed. It seems convenient to make this pointer initialization and structures binding in 'ffs_acquire_dev()' and make pointers clearing in 'ffs_release_dev()'. This required some changes in these functions parameters and return types. Also, 'ffs_release_dev()' calling requires some cleanup, fixing minor issues, like (1) 'ffs_release_dev()' is not called if 'ffs_free_inst()' is called without unmounting the device, and "release_dev" callback is not called at all, or (2) "release_dev" callback is called before "ffs_closed" callback on unmounting, which seems to be not correctly nested with "acquire_dev" and "ffs_ready" callbacks. Make this cleanup togther with other mentioned 'ffs_release_dev()' changes. [1] ================================================================== root@rcar-gen3:~# mkdir /dev/cfs root@rcar-gen3:~# mkdir /dev/ffs root@rcar-gen3:~# modprobe libcomposite root@rcar-gen3:~# mount -t configfs none /dev/cfs root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1 root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs [ 64.340664] file system registered root@rcar-gen3:~# mount -t functionfs ffs /dev/ffs root@rcar-gen3:~# cd /dev/ffs root@rcar-gen3:/dev/ffs# /home/root/ffs-test ffs-test: info: ep0: writing descriptors (in v2 format) [ 83.181442] read descriptors [ 83.186085] read strings ffs-test: info: ep0: writing strings ffs-test: dbg: ep1: starting ffs-test: dbg: ep2: starting ffs-test: info: ep1: starts ffs-test: info: ep2: starts ffs-test: info: ep0: starts ^C root@rcar-gen3:/dev/ffs# cd /home/root/ root@rcar-gen3:~# rmdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs [ 98.935061] unloading root@rcar-gen3:~# umount /dev/ffs [ 102.734301] ================================================================== [ 102.742059] BUG: KASAN: use-after-free in ffs_release_dev+0x64/0xa8 [usb_f_fs] [ 102.749683] Write of size 1 at addr ffff0004d46ff549 by task umount/2997 [ 102.756709] [ 102.758311] CPU: 0 PID: 2997 Comm: umount Not tainted 5.13.0-rc4+ #8 [ 102.764971] Hardware name: Renesas Salvator-X board based on r8a77951 (DT) [ 102.772179] Call trace: [ 102.774779] dump_backtrace+0x0/0x330 [ 102.778653] show_stack+0x20/0x2c [ 102.782152] dump_stack+0x11c/0x1ac [ 102.785833] print_address_description.constprop.0+0x30/0x274 [ 102.791862] kasan_report+0x14c/0x1c8 [ 102.795719] __asan_report_store1_noabort+0x34/0x58 [ 102.800840] ffs_release_dev+0x64/0xa8 [usb_f_fs] [ 102.805801] ffs_fs_kill_sb+0x50/0x84 [usb_f_fs] [ 102.810663] deactivate_locked_super+0xa0/0xf0 [ 102.815339] deactivate_super+0x98/0xac [ 102.819378] cleanup_mnt+0xd0/0x1b0 [ 102.823057] __cleanup_mnt+0x1c/0x28 [ 102.826823] task_work_run+0x104/0x180 [ 102.830774] do_notify_resume+0x458/0x14e0 [ 102.835083] work_pending+0xc/0x5f8 [ 102.838762] [ 102.840357] Allocated by task 2988: [ 102.844032] kasan_save_stack+0x28/0x58 [ 102.848071] kasan_set_track+0x28/0x3c [ 102.852016] ____kasan_kmalloc+0x84/0x9c [ 102.856142] __kasan_kmalloc+0x10/0x1c [ 102.860088] __kmalloc+0x214/0x2f8 [ 102.863678] kzalloc.constprop.0+0x14/0x20 [usb_f_fs] [ 102.868990] ffs_alloc_inst+0x8c/0x208 [usb_f_fs] [ 102.873942] try_get_usb_function_instance+0xf0/0x164 [libcomposite] [ 102.880629] usb_get_function_instance+0x64/0x68 [libcomposite] [ 102.886858] function_make+0x128/0x1ec [libcomposite] [ 102.892185] configfs_mkdir+0x330/0x590 [configfs] [ 102.897245] vfs_mkdir+0x12c/0x1bc [ 102.900835] do_mkdirat+0x180/0x1d0 [ 102.904513] __arm64_sys_mkdirat+0x80/0x94 [ 102.908822] invoke_syscall+0xf8/0x25c [ 102.912772] el0_svc_common.constprop.0+0x150/0x1a0 [ 102.917891] do_el0_svc+0xa0/0xd4 [ 102.921386] el0_svc+0x24/0x34 [ 102.924613] el0_sync_handler+0xcc/0x154 [ 102.928743] el0_sync+0x198/0x1c0 [ 102.932238] [ 102.933832] Freed by task 2996: [ 102.937144] kasan_save_stack+0x28/0x58 [ 102.941181] kasan_set_track+0x28/0x3c [ 102.945128] kasan_set_free_info+0x28/0x4c [ 102.949435] ____kasan_slab_free+0x104/0x118 [ 102.953921] __kasan_slab_free+0x18/0x24 [ 102.958047] slab_free_freelist_hook+0x148/0x1f0 [ 102.962897] kfree+0x318/0x440 [ 102.966123] ffs_free_inst+0x164/0x2d8 [usb_f_fs] [ 102.971075] usb_put_function_instance+0x84/0xa4 [libcomposite] [ 102.977302] ffs_attr_release+0x18/0x24 [usb_f_fs] [ 102.982344] config_item_put+0x140/0x1a4 [configfs] [ 102.987486] configfs_rmdir+0x3fc/0x518 [configfs] [ 102.992535] vfs_rmdir+0x114/0x234 [ 102.996122] do_rmdir+0x274/0x2b0 [ 102.999617] __arm64_sys_unlinkat+0x94/0xc8 [ 103.004015] invoke_syscall+0xf8/0x25c [ 103.007961] el0_svc_common.constprop.0+0x150/0x1a0 [ 103.013080] do_el0_svc+0xa0/0xd4 [ 103.016575] el0_svc+0x24/0x34 [ 103.019801] el0_sync_handler+0xcc/0x154 [ 103.023930] el0_sync+0x198/0x1c0 [ 103.027426] [ 103.029020] The buggy address belongs to the object at ffff0004d46ff500 [ 103.029020] which belongs to the cache kmalloc-128 of size 128 [ 103.042079] The buggy address is located 73 bytes inside of [ 103.042079] 128-byte region [ffff0004d46ff500, ffff0004d46ff580) [ 103.054236] The buggy address belongs to the page: [ 103.059262] page:0000000021aa849b refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff0004d46fee00 pfn:0x5146fe [ 103.070437] head:0000000021aa849b order:1 compound_mapcount:0 [ 103.076456] flags: 0x8000000000010200(slab|head|zone=2) [ 103.081948] raw: 8000000000010200 fffffc0013521a80 0000000d0000000d ffff0004c0002300 [ 103.090052] raw: ffff0004d46fee00 000000008020001e 00000001ffffffff 0000000000000000 [ 103.098150] page dumped because: kasan: bad access detected [ 103.103985] [ 103.105578] Memory state around the buggy address: [ 103.110602] ffff0004d46ff400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 103.118161] ffff0004d46ff480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 103.125726] >ffff0004d46ff500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 103.133284] ^ [ 103.139120] ffff0004d46ff580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 103.146679] ffff0004d46ff600: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 103.154238] ================================================================== [ 103.161792] Disabling lock debugging due to kernel taint [ 103.167319] Unable to handle kernel paging request at virtual address 0037801d6000018e [ 103.175406] Mem abort info: [ 103.178457] ESR = 0x96000004 [ 103.181609] EC = 0x25: DABT (current EL), IL = 32 bits [ 103.187020] SET = 0, FnV = 0 [ 103.190185] EA = 0, S1PTW = 0 [ 103.193417] Data abort info: [ 103.196385] ISV = 0, ISS = 0x00000004 [ 103.200315] CM = 0, WnR = 0 [ 103.203366] [0037801d6000018e] address between user and kernel address ranges [ 103.210611] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 103.216231] Modules linked in: usb_f_fs libcomposite configfs ath9k_htc led_class mac80211 libarc4 ath9k_common ath9k_hw ath cfg80211 aes_ce_blk sata_rc4 [ 103.259233] CPU: 0 PID: 2997 Comm: umount Tainted: G B 5.13.0-rc4+ #8 [ 103.267031] Hardware name: Renesas Salvator-X board based on r8a77951 (DT) [ 103.273951] pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--) [ 103.280001] pc : ffs_data_clear+0x138/0x370 [usb_f_fs] [ 103.285197] lr : ffs_data_clear+0x124/0x370 [usb_f_fs] [ 103.290385] sp : ffff800014777a80 [ 103.293725] x29: ffff800014777a80 x28: ffff0004d7649c80 x27: 0000000000000000 [ 103.300931] x26: ffff800014777fb0 x25: ffff60009aec9394 x24: ffff0004d7649ca4 [ 103.308136] x23: 1fffe0009a3d063a x22: dfff800000000000 x21: ffff0004d1e831d0 [ 103.315340] x20: e1c000eb00000bb4 x19: ffff0004d1e83000 x18: 0000000000000000 [ 103.322545] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 103.329748] x14: 0720072007200720 x13: 0720072007200720 x12: 1ffff000012ef658 [ 103.336952] x11: ffff7000012ef658 x10: 0720072007200720 x9 : ffff800011322648 [ 103.344157] x8 : ffff800014777818 x7 : ffff80000977b2c7 x6 : 0000000000000000 [ 103.351359] x5 : 0000000000000001 x4 : ffff7000012ef659 x3 : 0000000000000001 [ 103.358562] x2 : 0000000000000000 x1 : 1c38001d6000018e x0 : e1c000eb00000c70 [ 103.365766] Call trace: [ 103.368235] ffs_data_clear+0x138/0x370 [usb_f_fs] [ 103.373076] ffs_data_reset+0x20/0x304 [usb_f_fs] [ 103.377829] ffs_data_closed+0x1ec/0x244 [usb_f_fs] [ 103.382755] ffs_fs_kill_sb+0x70/0x84 [usb_f_fs] [ 103.387420] deactivate_locked_super+0xa0/0xf0 [ 103.391905] deactivate_super+0x98/0xac [ 103.395776] cleanup_mnt+0xd0/0x1b0 [ 103.399299] __cleanup_mnt+0x1c/0x28 [ 103.402906] task_work_run+0x104/0x180 [ 103.406691] do_notify_resume+0x458/0x14e0 [ 103.410823] work_pending+0xc/0x5f8 [ 103.414351] Code: b4000a54 9102f280 12000802 d343fc01 (38f66821) [ 103.420490] ---[ end trace 57b43a50e8244f57 ]--- Segmentation fault root@rcar-gen3:~# ================================================================== [2] ================================================================== root@rcar-gen3:~# mkdir /dev/ffs root@rcar-gen3:~# modprobe libcomposite root@rcar-gen3:~# root@rcar-gen3:~# mount -t configfs none /dev/cfs root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1 root@rcar-gen3:~# mkdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs [ 54.766480] file system registered root@rcar-gen3:~# mount -t functionfs ffs /dev/ffs root@rcar-gen3:~# rmdir /dev/cfs/usb_gadget/g1/functions/ffs.ffs [ 63.197597] unloading root@rcar-gen3:~# cat /dev/ffs/ep0 cat: read error:[ 67.213506] ================================================================== [ 67.222095] BUG: KASAN: use-after-free in ffs_data_clear+0x70/0x370 [usb_f_fs] [ 67.229699] Write of size 1 at addr ffff0004c26e974a by task cat/2994 [ 67.236446] [ 67.238045] CPU: 0 PID: 2994 Comm: cat Not tainted 5.13.0-rc4+ #8 [ 67.244431] Hardware name: Renesas Salvator-X board based on r8a77951 (DT) [ 67.251624] Call trace: [ 67.254212] dump_backtrace+0x0/0x330 [ 67.258081] show_stack+0x20/0x2c [ 67.261579] dump_stack+0x11c/0x1ac [ 67.265260] print_address_description.constprop.0+0x30/0x274 [ 67.271286] kasan_report+0x14c/0x1c8 [ 67.275143] __asan_report_store1_noabort+0x34/0x58 [ 67.280265] ffs_data_clear+0x70/0x370 [usb_f_fs] [ 67.285220] ffs_data_reset+0x20/0x304 [usb_f_fs] [ 67.290172] ffs_data_closed+0x240/0x244 [usb_f_fs] [ 67.295305] ffs_ep0_release+0x40/0x54 [usb_f_fs] [ 67.300256] __fput+0x304/0x580 [ 67.303576] ____fput+0x18/0x24 [ 67.306893] task_work_run+0x104/0x180 [ 67.310846] do_notify_resume+0x458/0x14e0 [ 67.315154] work_pending+0xc/0x5f8 [ 67.318834] [ 67.320429] Allocated by task 2988: [ 67.324105] kasan_save_stack+0x28/0x58 [ 67.328144] kasan_set_track+0x28/0x3c [ 67.332090] ____kasan_kmalloc+0x84/0x9c [ 67.336217] __kasan_kmalloc+0x10/0x1c [ 67.340163] __kmalloc+0x214/0x2f8 [ 67.343754] kzalloc.constprop.0+0x14/0x20 [usb_f_fs] [ 67.349066] ffs_alloc_inst+0x8c/0x208 [usb_f_fs] [ 67.354017] try_get_usb_function_instance+0xf0/0x164 [libcomposite] [ 67.360705] usb_get_function_instance+0x64/0x68 [libcomposite] [ 67.366934] function_make+0x128/0x1ec [libcomposite] [ 67.372260] configfs_mkdir+0x330/0x590 [configfs] [ 67.377320] vfs_mkdir+0x12c/0x1bc [ 67.380911] do_mkdirat+0x180/0x1d0 [ 67.384589] __arm64_sys_mkdirat+0x80/0x94 [ 67.388899] invoke_syscall+0xf8/0x25c [ 67.392850] el0_svc_common.constprop.0+0x150/0x1a0 [ 67.397969] do_el0_svc+0xa0/0xd4 [ 67.401464] el0_svc+0x24/0x34 [ 67.404691] el0_sync_handler+0xcc/0x154 [ 67.408819] el0_sync+0x198/0x1c0 [ 67.412315] [ 67.413909] Freed by task 2993: [ 67.417220] kasan_save_stack+0x28/0x58 [ 67.421257] kasan_set_track+0x28/0x3c [ 67.425204] kasan_set_free_info+0x28/0x4c [ 67.429513] ____kasan_slab_free+0x104/0x118 [ 67.434001] __kasan_slab_free+0x18/0x24 [ 67.438128] slab_free_freelist_hook+0x148/0x1f0 [ 67.442978] kfree+0x318/0x440 [ 67.446205] ffs_free_inst+0x164/0x2d8 [usb_f_fs] [ 67.451156] usb_put_function_instance+0x84/0xa4 [libcomposite] [ 67.457385] ffs_attr_release+0x18/0x24 [usb_f_fs] [ 67.462428] config_item_put+0x140/0x1a4 [configfs] [ 67.467570] configfs_rmdir+0x3fc/0x518 [configfs] [ 67.472626] vfs_rmdir+0x114/0x234 [ 67.476215] do_rmdir+0x274/0x2b0 [ 67.479710] __arm64_sys_unlinkat+0x94/0xc8 [ 67.484108] invoke_syscall+0xf8/0x25c [ 67.488055] el0_svc_common.constprop.0+0x150/0x1a0 [ 67.493175] do_el0_svc+0xa0/0xd4 [ 67.496671] el0_svc+0x24/0x34 [ 67.499896] el0_sync_handler+0xcc/0x154 [ 67.504024] el0_sync+0x198/0x1c0 [ 67.507520] [ 67.509114] The buggy address belongs to the object at ffff0004c26e9700 [ 67.509114] which belongs to the cache kmalloc-128 of size 128 [ 67.522171] The buggy address is located 74 bytes inside of [ 67.522171] 128-byte region [ffff0004c26e9700, ffff0004c26e9780) [ 67.534328] The buggy address belongs to the page: [ 67.539355] page:000000003177a217 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5026e8 [ 67.549175] head:000000003177a217 order:1 compound_mapcount:0 [ 67.555195] flags: 0x8000000000010200(slab|head|zone=2) [ 67.560687] raw: 8000000000010200 fffffc0013037100 0000000c00000002 ffff0004c0002300 [ 67.568791] raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000 [ 67.576890] page dumped because: kasan: bad access detected [ 67.582725] [ 67.584318] Memory state around the buggy address: [ 67.589343] ffff0004c26e9600: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 67.596903] ffff0004c26e9680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 67.604463] >ffff0004c26e9700: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 67.612022] ^ [ 67.617860] ffff0004c26e9780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 67.625421] ffff0004c26e9800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.632981] ================================================================== [ 67.640535] Disabling lock debugging due to kernel taint File descriptor[ 67.646100] Unable to handle kernel paging request at virtual address fabb801d4000018d in bad state [ 67.655456] Mem abort info: [ 67.659619] ESR = 0x96000004 [ 67.662801] EC = 0x25: DABT (current EL), IL = 32 bits [ 67.668225] SET = 0, FnV = 0 [ 67.671375] EA = 0, S1PTW = 0 [ 67.674613] Data abort info: [ 67.677587] ISV = 0, ISS = 0x00000004 [ 67.681522] CM = 0, WnR = 0 [ 67.684588] [fabb801d4000018d] address between user and kernel address ranges [ 67.691849] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 67.697470] Modules linked in: usb_f_fs libcomposite configfs ath9k_htc led_class mac80211 libarc4 ath9k_common ath9k_hw ath cfg80211 aes_ce_blk crypto_simd cryptd aes_ce_cipher ghash_ce gf128mul sha2_ce sha1_ce evdev sata_rcar libata xhci_plat_hcd scsi_mod xhci_hcd rene4 [ 67.740467] CPU: 0 PID: 2994 Comm: cat Tainted: G B 5.13.0-rc4+ #8 [ 67.748005] Hardware name: Renesas Salvator-X board based on r8a77951 (DT) [ 67.754924] pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--) [ 67.760974] pc : ffs_data_clear+0x138/0x370 [usb_f_fs] [ 67.766178] lr : ffs_data_clear+0x124/0x370 [usb_f_fs] [ 67.771365] sp : ffff800014767ad0 [ 67.774706] x29: ffff800014767ad0 x28: ffff800009cf91c0 x27: ffff0004c54861a0 [ 67.781913] x26: ffff0004dc90b288 x25: 1fffe00099ec10f5 x24: 00000000000a801d [ 67.789118] x23: 1fffe00099f6953a x22: dfff800000000000 x21: ffff0004cfb4a9d0 [ 67.796322] x20: d5e000ea00000bb1 x19: ffff0004cfb4a800 x18: 0000000000000000 [ 67.803526] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 67.810730] x14: 0720072007200720 x13: 0720072007200720 x12: 1ffff000028ecefa [ 67.817934] x11: ffff7000028ecefa x10: 0720072007200720 x9 : ffff80001132c014 [ 67.825137] x8 : ffff8000147677d8 x7 : ffff8000147677d7 x6 : 0000000000000000 [ 67.832341] x5 : 0000000000000001 x4 : ffff7000028ecefb x3 : 0000000000000001 [ 67.839544] x2 : 0000000000000005 x1 : 1abc001d4000018d x0 : d5e000ea00000c6d [ 67.846748] Call trace: [ 67.849218] ffs_data_clear+0x138/0x370 [usb_f_fs] [ 67.854058] ffs_data_reset+0x20/0x304 [usb_f_fs] [ 67.858810] ffs_data_closed+0x240/0x244 [usb_f_fs] [ 67.863736] ffs_ep0_release+0x40/0x54 [usb_f_fs] [ 67.868488] __fput+0x304/0x580 [ 67.871665] ____fput+0x18/0x24 [ 67.874837] task_work_run+0x104/0x180 [ 67.878622] do_notify_resume+0x458/0x14e0 [ 67.882754] work_pending+0xc/0x5f8 [ 67.886282] Code: b4000a54 9102f280 12000802 d343fc01 (38f66821) [ 67.892422] ---[ end trace 6d7cedf53d7abbea ]--- Segmentation fault root@rcar-gen3:~# ================================================================== Fixes: 4b187fceec3c ("usb: gadget: FunctionFS: add devices management code") Fixes: 3262ad824307 ("usb: gadget: f_fs: Stop ffs_closed NULL pointer dereference") Fixes: cdafb6d8b8da ("usb: gadget: f_fs: Fix use-after-free in ffs_free_inst") Reported-by: Bhuvanesh Surachari Tested-by: Eugeniu Rosca Reviewed-by: Eugeniu Rosca Signed-off-by: Andrew Gabbasov Link: https://lore.kernel.org/r/20210603171507.22514-1-andrew_gabbasov@mentor.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e78e2c04941a5c2e9c8c1e0009f3d42d21bec7f9 Author: Christophe JAILLET Date: Sun Jun 6 16:31:09 2021 +0200 ASoC: mediatek: mtk-btcvsd: Fix an error handling path in 'mtk_btcvsd_snd_probe()' [ Upstream commit b6052c3c7a78f5e2b9756c92ef77c0b56435f107 ] If an error occurs after a successful 'of_iomap()' call, it must be undone by a corresponding 'iounmap()' call, as already done in the remove function. While at it, remove the useless initialization of 'ret' at the beginning of the function. Fixes: 4bd8597dc36c ("ASoC: mediatek: add btcvsd driver") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/0c2ba562c3364e61bfbd5b3013a99dfa0d9045d7.1622989685.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8a7cbece6b691cf554b25ae7e9318f3477291816 Author: Bard Liao Date: Mon Jun 7 17:22:39 2021 -0500 ASoC: rt711-sdca: handle mbq_regmap in rt711_sdca_io_init [ Upstream commit bcc0f0c078771e983a7e602eb14efa02f811445f ] We currently only hangle rt711->regmap in rt711_sdca_io_init(), and rt711->mbq_regmap is missing. Fixes: 7ad4d237e7c4a ('ASoC: rt711-sdca: Add RT711 SDCA vendor-specific driver') Signed-off-by: Bard Liao Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210607222239.582139-16-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 060735a28a1fb48dabc37f795e2bfefbe7b31c7c Author: Bard Liao Date: Mon Jun 7 17:22:38 2021 -0500 ASoC: rt711-sdca-sdw: add readable for SDW_SDCA_CTL() registers [ Upstream commit 5ad1ba99e4784929588c79e9810f5610825f0411 ] SDW_SDCA_CTL() registers are used but are not set to readable. Fixes: 7ad4d237e7c4a ('ASoC: rt711-sdca: Add RT711 SDCA vendor-specific driver') Signed-off-by: Bard Liao Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210607222239.582139-15-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c7c275d9930c22c6b8f2767e34bbac7e7c614fe2 Author: Bard Liao Date: Mon Jun 7 17:22:37 2021 -0500 ASoC: rt5682-sdw: set regcache_cache_only false before reading RT5682_DEVICE_ID [ Upstream commit c0372bc873dd29f325ee908351e0bd5b08d4d608 ] RT5682_DEVICE_ID is a volatile register, we can not read it in cache only mode. Fixes: 03f6fc6de919 ("ASoC: rt5682: Add the soundwire support") Signed-off-by: Bard Liao Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210607222239.582139-14-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1863731292586d0929175dc3fc6d5c2c74bdcd29 Author: Oder Chiou Date: Mon Jun 7 17:22:36 2021 -0500 ASoC: rt5682: Fix a problem with error handling in the io init function of the soundwire [ Upstream commit 9266d95405ae0c078f188ec8bca3a004631be429 ] The device checking error should be a jump to pm_runtime_put_autosuspend() as done before returning value. Fixes: 867f8d18df4f ('ASoC: rt5682: fix getting the wrong device id when the suspend_stress_test') Reviewed-by: Bard Liao Signed-off-by: Oder Chiou Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210607222239.582139-13-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5544d5522a1938a5741059cd95a5e19556776c1b Author: Jack Yu Date: Mon Jun 7 17:22:35 2021 -0500 ASoC: rt715-sdca: fix clock stop prepare timeout issue [ Upstream commit e343d34a9c912fc5c321e2a9fbc02e9dc9534ade ] Fix clock stop prepare timeout issue (#2853). The trigger of internal circuit which belong to “SDCA preset stuffs” was not set correctly in previous driver, which could block clock_stop_preparation state. Add the correct register setting to fix it. Fixes: 20d17057f0a8c ('ASoC: rt715-sdca: Add RT715 sdca vendor-specific driver') Signed-off-by: Jack Yu Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210607222239.582139-12-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 15e920874b4d78748181d2713bb19ba7af1612bd Author: Pierre-Louis Bossart Date: Mon Jun 7 17:22:34 2021 -0500 ASoC: rt715-sdw: use first_hw_init flag on resume [ Upstream commit dbc07517ab173688ef11234d1099bc1e24e4f14b ] The intent of the status check on resume was to verify if a SoundWire peripheral reported ATTACHED before waiting for the initialization to complete. This is required to avoid timeouts that will happen with 'ghost' devices that are exposed in the platform firmware but are not populated in hardware. Unfortunately we used 'hw_init' instead of 'first_hw_init'. Due to another error, the resume operation never timed out, but the volume settings were not properly restored. BugLink: https://github.com/thesofproject/linux/issues/2908 BugLink: https://github.com/thesofproject/linux/issues/2637 Fixes: d1ede0641b05e ('ASoC: rt715: add RT715 codec driver') Signed-off-by: Pierre-Louis Bossart Reviewed-by: Guennadi Liakhovetski Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20210607222239.582139-11-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ea62150dd7333ab4c63d290475d46019165b59fa Author: Pierre-Louis Bossart Date: Mon Jun 7 17:22:33 2021 -0500 ASoC: rt715-sdca-sdw: use first_hw_init flag on resume [ Upstream commit d34d0897a753f42c8a7a6af3866781dd57344a45 ] The intent of the status check on resume was to verify if a SoundWire peripheral reported ATTACHED before waiting for the initialization to complete. This is required to avoid timeouts that will happen with 'ghost' devices that are exposed in the platform firmware but are not populated in hardware. Unfortunately we used 'hw_init' instead of 'first_hw_init'. Due to another error, the resume operation never timed out, but the volume settings were not properly restored. This patch renames the status flag to 'first_hw_init' for consistency with other drivers (was 'first_init') BugLink: https://github.com/thesofproject/linux/issues/2908 BugLink: https://github.com/thesofproject/linux/issues/2637 Fixes: 20d17057f0a8c ('ASoC: rt715-sdca: Add RT715 sdca vendor-specific driver') Signed-off-by: Pierre-Louis Bossart Reviewed-by: Guennadi Liakhovetski Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20210607222239.582139-10-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7b87d4763fe21507d421da9a3b50b5acc30f73e4 Author: Pierre-Louis Bossart Date: Mon Jun 7 17:22:32 2021 -0500 ASoC: rt711-sdw: use first_hw_init flag on resume [ Upstream commit a0897ebca669f09a2e02206a9c48a738af655329 ] The intent of the status check on resume was to verify if a SoundWire peripheral reported ATTACHED before waiting for the initialization to complete. This is required to avoid timeouts that will happen with 'ghost' devices that are exposed in the platform firmware but are not populated in hardware. Unfortunately we used 'hw_init' instead of 'first_hw_init'. Due to another error, the resume operation never timed out, but the volume settings were not properly restored. BugLink: https://github.com/thesofproject/linux/issues/2908 BugLink: https://github.com/thesofproject/linux/issues/2637 Fixes: 320b8b0d13b81 ('ASoC: rt711: add rt711 codec driver') Signed-off-by: Pierre-Louis Bossart Reviewed-by: Guennadi Liakhovetski Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20210607222239.582139-9-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9c06ea07f82e03bdd83917de0658ddc325c7bc6b Author: Pierre-Louis Bossart Date: Mon Jun 7 17:22:31 2021 -0500 ASoC: rt711-sdca-sdw: use first_hw_init flag on resume [ Upstream commit b32cab09707bb7fd851128633157c92716df6781 ] The intent of the status check on resume was to verify if a SoundWire peripheral reported ATTACHED before waiting for the initialization to complete. This is required to avoid timeouts that will happen with 'ghost' devices that are exposed in the platform firmware but are not populated in hardware. Unfortunately we used 'hw_init' instead of 'first_hw_init'. Due to another error, the resume operation never timed out, but the volume settings were not properly restored. BugLink: https://github.com/thesofproject/linux/issues/2908 BugLink: https://github.com/thesofproject/linux/issues/2637 Fixes: 7ad4d237e7c4a ('ASoC: rt711-sdca: Add RT711 SDCA vendor-specific driver') Signed-off-by: Pierre-Louis Bossart Reviewed-by: Guennadi Liakhovetski Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20210607222239.582139-8-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7baba8a47772931bc9d01cdb8529a7b2e85329c5 Author: Pierre-Louis Bossart Date: Mon Jun 7 17:22:30 2021 -0500 ASoC: rt700-sdw: use first_hw_init flag on resume [ Upstream commit a9e54e5fbe396b546771cf77b43ce7c75e212278 ] The intent of the status check on resume was to verify if a SoundWire peripheral reported ATTACHED before waiting for the initialization to complete. This is required to avoid timeouts that will happen with 'ghost' devices that are exposed in the platform firmware but are not populated in hardware. Unfortunately we used 'hw_init' instead of 'first_hw_init'. Due to another error, the resume operation never timed out, but the volume settings were not properly restored. BugLink: https://github.com/thesofproject/linux/issues/2908 BugLink: https://github.com/thesofproject/linux/issues/2637 Fixes: 7d2a5f9ae41e3 ('ASoC: rt700: add rt700 codec driver') Signed-off-by: Pierre-Louis Bossart Reviewed-by: Guennadi Liakhovetski Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20210607222239.582139-7-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b4b4f4c0df1f1b64960e99cf878ae7c18a3304bb Author: Pierre-Louis Bossart Date: Mon Jun 7 17:22:29 2021 -0500 ASoC: rt5682-sdw: use first_hw_init flag on resume [ Upstream commit 5361a42114689f875a9748299cadb4b1adbee6f4 ] The intent of the status check on resume was to verify if a SoundWire peripheral reported ATTACHED before waiting for the initialization to complete. This is required to avoid timeouts that will happen with 'ghost' devices that are exposed in the platform firmware but are not populated in hardware. Unfortunately we used 'hw_init' instead of 'first_hw_init'. Due to another error, the resume operation never timed out, but the volume settings were not properly restored. BugLink: https://github.com/thesofproject/linux/issues/2908 BugLink: https://github.com/thesofproject/linux/issues/2637 Fixes: 03f6fc6de9192 ('ASoC: rt5682: Add the soundwire support') Signed-off-by: Pierre-Louis Bossart Reviewed-by: Guennadi Liakhovetski Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20210607222239.582139-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d2d2558c19201a3f46e7a9e65de2683027f6d0ad Author: Pierre-Louis Bossart Date: Mon Jun 7 17:22:28 2021 -0500 ASoC: rt1316-sdw: use first_hw_init flag on resume [ Upstream commit ebe2ef60ed76c1afd8ec84e1bfd1868e3456e96b ] The intent of the status check on resume was to verify if a SoundWire peripheral reported ATTACHED before waiting for the initialization to complete. This is required to avoid timeouts that will happen with 'ghost' devices that are exposed in the platform firmware but are not populated in hardware. Unfortunately we used 'hw_init' instead of 'first_hw_init'. Due to another error, the resume operation never timed out, but the volume settings were not properly restored. BugLink: https://github.com/thesofproject/linux/issues/2908 BugLink: https://github.com/thesofproject/linux/issues/2637 Fixes: 2b719fd20f327 ('ASoC: rt1316: Add RT1316 SDCA vendor-specific driver') Signed-off-by: Pierre-Louis Bossart Reviewed-by: Guennadi Liakhovetski Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20210607222239.582139-5-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b1cdc0cdf8948e741a59c084c34bc2426ce11f16 Author: Pierre-Louis Bossart Date: Mon Jun 7 17:22:27 2021 -0500 ASoC: rt1308-sdw: use first_hw_init flag on resume [ Upstream commit 30e102dab5fad1db71684f8ac5e1ac74e49da06d ] The intent of the status check on resume was to verify if a SoundWire peripheral reported ATTACHED before waiting for the initialization to complete. This is required to avoid timeouts that will happen with 'ghost' devices that are exposed in the platform firmware but are not populated in hardware. Unfortunately we used 'hw_init' instead of 'first_hw_init'. Due to another error, the resume operation never timed out, but the volume settings were not properly restored. BugLink: https://github.com/thesofproject/linux/issues/2908 BugLink: https://github.com/thesofproject/linux/issues/2637 Fixes: a87a6653a28c0 ('ASoC: rt1308-sdw: add rt1308 SdW amplifier driver') Signed-off-by: Pierre-Louis Bossart Reviewed-by: Guennadi Liakhovetski Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20210607222239.582139-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c96efdc4e7558ef0d668036aaad95f68dfc4e76f Author: Pierre-Louis Bossart Date: Mon Jun 7 17:22:26 2021 -0500 ASoC: max98373-sdw: use first_hw_init flag on resume [ Upstream commit bf881170311ea74ff30c3be0be8fb097132ce696 ] The intent of the status check on resume was to verify if a SoundWire peripheral reported ATTACHED before waiting for the initialization to complete. This is required to avoid timeouts that will happen with 'ghost' devices that are exposed in the platform firmware but are not populated in hardware. Unfortunately we used 'hw_init' instead of 'first_hw_init'. Due to another error, the resume operation never timed out, but the volume settings were not properly restored. This patch renames the status flag to 'first_hw_init' for consistency with other drivers. BugLink: https://github.com/thesofproject/linux/issues/2637 Fixes: 56a5b7910e96 ('ASoC: codecs: max98373: add SoundWire support') Signed-off-by: Pierre-Louis Bossart Reviewed-by: Guennadi Liakhovetski Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20210607222239.582139-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fd999972a61b152d416a4caf79a949860ad757b9 Author: Pierre-Louis Bossart Date: Mon Jun 7 17:22:25 2021 -0500 ASoC: max98373-sdw: add missing memory allocation check [ Upstream commit 468a272ca49cc4e2f58f3c360643c3f6d313c146 ] We forgot to test that devm_kcalloc doesn't return NULL. Fixes: 349dd23931d1 ('ASoC: max98373: don't access volatile registers in bias level off') Signed-off-by: Pierre-Louis Bossart Reviewed-by: Guennadi Liakhovetski Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20210607222239.582139-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0420caf49693840b3bed42f792a82d9e5bc8583f Author: Srinath Mannam Date: Mon Sep 14 12:53:19 2020 +0530 iommu/dma: Fix IOVA reserve dma ranges [ Upstream commit 571f316074a203e979ea90211d9acf423dfe5f46 ] Fix IOVA reserve failure in the case when address of first memory region listed in dma-ranges is equal to 0x0. Fixes: aadad097cd46f ("iommu/dma: Reserve IOVA for PCIe inaccessible DMA address") Signed-off-by: Srinath Mannam Reviewed-by: Robin Murphy Tested-by: Sven Peter Link: https://lore.kernel.org/r/20200914072319.6091-1-srinath.mannam@broadcom.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 2efa055728cdd5511eebd5a42fa2331aca46563c Author: Kees Cook Date: Wed May 26 20:25:37 2021 -0700 selftests: splice: Adjust for handler fallback removal [ Upstream commit 6daf076b717d189f4d02a303d45edd5732341ec1 ] Some pseudo-filesystems do not have an explicit splice fops since adding commit 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops"), and now will reject attempts to use splice() in those filesystem paths. Reported-by: kernel test robot Link: https://lore.kernel.org/lkml/202009181443.C2179FB@keescook/ Fixes: 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops") Cc: Christoph Hellwig Cc: Shuah Khan Cc: linux-kselftest@vger.kernel.org Signed-off-by: Kees Cook Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit c7f4ec0649dcb03bfef617e741baea8417a78748 Author: Randy Dunlap Date: Thu May 27 17:24:20 2021 -0700 s390: appldata depends on PROC_SYSCTL [ Upstream commit 5d3516b3647621d5a1180672ea9e0817fb718ada ] APPLDATA_BASE should depend on PROC_SYSCTL instead of PROC_FS. Building with PROC_FS but not PROC_SYSCTL causes a build error, since appldata_base.c uses data and APIs from fs/proc/proc_sysctl.c. arch/s390/appldata/appldata_base.o: in function `appldata_generic_handler': appldata_base.c:(.text+0x192): undefined reference to `sysctl_vals' Fixes: c185b783b099 ("[S390] Remove config options.") Signed-off-by: Randy Dunlap Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Christian Borntraeger Cc: linux-s390@vger.kernel.org Signed-off-by: Vasily Gorbik Link: https://lore.kernel.org/r/20210528002420.17634-1-rdunlap@infradead.org Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 11a86e01ae29f52aded266e685d7848825ff85f1 Author: Niklas Schnelle Date: Fri Feb 19 12:00:52 2021 +0100 s390: enable HAVE_IOREMAP_PROT [ Upstream commit d460bb6c6417588dd8b0907d34f69b237918812a ] In commit b02002cc4c0f ("s390/pci: Implement ioremap_wc/prot() with MIO") we implemented both ioremap_wc() and ioremap_prot() however until now we had not set HAVE_IOREMAP_PROT in Kconfig, do so now. This also requires implementing pte_pgprot() as this is used in the generic_access_phys() code enabled by CONFIG_HAVE_IOREMAP_PROT. As with ioremap_wc() we need to take the MMIO Write Back bit index into account. Moreover since the pgprot value returned from pte_pgprot() is to be used for mappings into kernel address space we must make sure that it uses appropriate kernel page table protection bits. In particular a pgprot value originally coming from userspace could have the _PAGE_PROTECT bit set to enable fault based dirty bit accounting which would then make the mapping inaccessible when used in kernel address space. Fixes: b02002cc4c0f ("s390/pci: Implement ioremap_wc/prot() with MIO") Reviewed-by: Gerald Schaefer Signed-off-by: Niklas Schnelle Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 5cef83686407d63372c7fe6f14d8b41b8ba9438e Author: Robin Murphy Date: Thu Jun 3 14:48:21 2021 +0100 iommu/amd: Tidy up DMA ops init [ Upstream commit be227f8e99a663d097536e9f9bc935fb26bdbc41 ] Now that DMA ops are part of the core API via iommu-dma, fold the vestigial remains of the IOMMU_DMA_OPS init state into the IOMMU API phase, and clean up a few other leftovers. This should also close the race window wherein bus_set_iommu() effectively makes the DMA ops state visible before its nominal initialisation - it seems this was previously fairly benign, but since commit a250c23f15c2 ("iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE") it can now lead to the strict flush queue policy inadvertently being picked for default domains allocated during that window, with a corresponding unexpected perfomance impact. Reported-by: Jussi Maki Tested-by: Jussi Maki Signed-off-by: Robin Murphy Fixes: a250c23f15c2 ("iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE") Link: https://lore.kernel.org/r/665db61e23ff8d54ac5eb391bef520b3a803fcb9.1622727974.git.robin.murphy@arm.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit a935344b6dac3484082da42b3c658c4e617c4294 Author: Alexander Monakov Date: Tue May 4 13:22:20 2021 +0300 iommu/amd: Fix extended features logging [ Upstream commit 4b21a503adf597773e4b37db05db0e9b16a81d53 ] print_iommu_info prints the EFR register and then the decoded list of features on a separate line: pci 0000:00:00.2: AMD-Vi: Extended features (0x206d73ef22254ade): PPR X2APIC NX GT IA GA PC GA_vAPIC The second line is emitted via 'pr_cont', which causes it to have a different ('warn') loglevel compared to the previous line ('info'). Commit 9a295ff0ffc9 attempted to rectify this by removing the newline from the pci_info format string, but this doesn't work, as pci_info calls implicitly append a newline anyway. Printing the decoded features on the same line would make it quite long. Instead, change pci_info() to pr_info() to omit PCI bus location info, which is also shown in the preceding message. This results in: pci 0000:00:00.2: AMD-Vi: Found IOMMU cap 0x40 AMD-Vi: Extended features (0x206d73ef22254ade): PPR X2APIC NX GT IA GA PC GA_vAPIC AMD-Vi: Interrupt remapping enabled Fixes: 9a295ff0ffc9 ("iommu/amd: Print extended features in one line to fix divergent log levels") Link: https://lore.kernel.org/lkml/alpine.LNX.2.20.13.2104112326460.11104@monopod.intra.ispras.ru Signed-off-by: Alexander Monakov Cc: Paul Menzel Cc: Joerg Roedel Cc: Suravee Suthikulpanit Cc: iommu@lists.linux-foundation.org Reviewed-by: Paul Menzel Link: https://lore.kernel.org/r/20210504102220.1793-1-amonakov@ispras.ru Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit a9c55cbadef5cdec4094a3d790684b73b6ec76ea Author: Zhen Lei Date: Fri May 28 16:26:14 2021 +0800 visorbus: fix error return code in visorchipset_init() [ Upstream commit ce52ec5beecc1079c251f60e3973b3758f60eb59 ] Commit 1366a3db3dcf ("staging: unisys: visorbus: visorchipset_init clean up gotos") assigns the initial value -ENODEV to the local variable 'err', and the first several error branches will return this value after "goto error". But commit f1f537c2e7f5 ("staging: unisys: visorbus: Consolidate controlvm channel creation.") overwrites 'err' in the middle of the way. As a result, some error branches do not successfully return the initial value -ENODEV of 'err', but return 0. In addition, when kzalloc() fails, -ENOMEM should be returned instead of -ENODEV. Fixes: f1f537c2e7f5 ("staging: unisys: visorbus: Consolidate controlvm channel creation.") Reported-by: Hulk Robot Signed-off-by: Zhen Lei Link: https://lore.kernel.org/r/20210528082614.9337-1-thunder.leizhen@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3886a5e6bbe36384bcfb2715ab6733fecf4de146 Author: Joachim Fenkes Date: Fri Jul 24 16:45:18 2020 +0930 fsi/sbefifo: Fix reset timeout [ Upstream commit 9ab1428dfe2c66b51e0b41337cd0164da0ab6080 ] On BMCs with lower timer resolution than 1ms, msleep(1) will take way longer than 1ms, so looping 10k times won't wait for 10s but significantly longer. Fix this by using jiffies like the rest of the code. Fixes: 9f4a8a2d7f9d ("fsi/sbefifo: Add driver for the SBE FIFO") Signed-off-by: Joachim Fenkes Link: https://lore.kernel.org/r/20200724071518.430515-3-joel@jms.id.au Signed-off-by: Joel Stanley Signed-off-by: Sasha Levin commit 657cd9acd6ef0f76eaf1880f57857f69cb006956 Author: Joachim Fenkes Date: Fri Jul 24 16:45:17 2020 +0930 fsi/sbefifo: Clean up correct FIFO when receiving reset request from SBE [ Upstream commit 95152433e46fdb36652ebdbea442356a16ae1fa6 ] When the SBE requests a reset via the down FIFO, that is also the FIFO we should go and reset ;) Fixes: 9f4a8a2d7f9d ("fsi/sbefifo: Add driver for the SBE FIFO") Signed-off-by: Joachim Fenkes Signed-off-by: Joel Stanley Link: https://lore.kernel.org/r/20200724071518.430515-2-joel@jms.id.au Signed-off-by: Joel Stanley Signed-off-by: Sasha Levin commit ebb29df21cec672c4ddfc89ae35b891bed52a41b Author: Eddie James Date: Tue Feb 9 11:12:32 2021 -0600 fsi: occ: Don't accept response from un-initialized OCC [ Upstream commit 8a4659be08576141f47d47d94130eb148cb5f0df ] If the OCC is not initialized and responds as such, the driver should continue waiting for a valid response until the timeout expires. Signed-off-by: Eddie James Reviewed-by: Joel Stanley Fixes: 7ed98dddb764 ("fsi: Add On-Chip Controller (OCC) driver") Link: https://lore.kernel.org/r/20210209171235.20624-2-eajames@linux.ibm.com Signed-off-by: Joel Stanley Signed-off-by: Sasha Levin commit 485d8c421dbc82e65006bd6e4d2b388cf0461914 Author: Eddie James Date: Mon Mar 29 10:13:44 2021 -0500 fsi: scom: Reset the FSI2PIB engine for any error [ Upstream commit a5c317dac5567206ca7b6bc9d008dd6890c8bced ] The error bits in the FSI2PIB status are only cleared by a reset. So the driver needs to perform a reset after seeing any of the FSI2PIB errors, otherwise subsequent operations will also look like failures. Fixes: 6b293258cded ("fsi: scom: Major overhaul") Signed-off-by: Eddie James Reviewed-by: Joel Stanley Link: https://lore.kernel.org/r/20210329151344.14246-1-eajames@linux.ibm.com Signed-off-by: Joel Stanley Signed-off-by: Sasha Levin commit 7d884f6f7faa925448046c79cf94615bde760409 Author: Colin Ian King Date: Thu Jun 3 13:28:12 2021 +0100 fsi: core: Fix return of error values on failures [ Upstream commit 910810945707fe9877ca86a0dca4e585fd05e37b ] Currently the cfam_read and cfam_write functions return the provided number of bytes given in the count parameter and not the error return code in variable rc, hence all failures of read/writes are being silently ignored. Fix this by returning the error code in rc. Addresses-Coverity: ("Unused value") Fixes: d1dcd6782576 ("fsi: Add cfam char devices") Signed-off-by: Colin Ian King Reviewed-by: Jeremy Kerr Link: https://lore.kernel.org/r/20210603122812.83587-1-colin.king@canonical.com Signed-off-by: Joel Stanley Signed-off-by: Sasha Levin commit 51ab817f8a0b2840578f96a9515c64f7d40e5c31 Author: Andreas Kemnade Date: Sat May 15 22:55:18 2021 +0200 mfd: rn5t618: Fix IRQ trigger by changing it to level mode [ Upstream commit a1649a5260631979c68e5b2012f60f90300e646f ] During more massive generation of interrupts, the IRQ got stuck, and the subdevices did not see any new interrupts. That happens especially at wonky USB supply in combination with ADC reads. To fix that trigger the IRQ at level low instead of falling edge. Fixes: 0c81604516af ("mfd: rn5t618: Add IRQ support") Signed-off-by: Andreas Kemnade Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit f0a5801a8df23b0e1cd8b2da1f40f45d93a57d2b Author: Andy Shevchenko Date: Mon May 10 17:15:52 2021 +0300 mfd: Remove software node conditionally and locate at right place [ Upstream commit 5a23e8b0fd6010e25ae58362292235cc9213ca57 ] Currently the software node is removed in error case and at ->remove() stage unconditionally, that ruins the symmetry. Besides, in some cases, when mfd_add_device() fails, the device_remove_software_node() call may lead to NULL pointer dereference: BUG: kernel NULL pointer dereference, address: 00000000 ... EIP: strlen+0x12/0x20 ... kernfs_name_hash+0x13/0x70 kernfs_find_ns+0x32/0xc0 kernfs_remove_by_name_ns+0x2a/0x90 sysfs_remove_link+0x16/0x30 software_node_notify.cold+0x34/0x6b device_remove_software_node+0x5a/0x90 mfd_add_device.cold+0x30a/0x427 Fix all these by guarding device_remove_software_node() with a conditional and locating it at the right place. Fixes: 42e59982917a ("mfd: core: Add support for software nodes") Signed-off-by: Andy Shevchenko Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit cffae75db764133c0d73c513037e489d48e3c7ef Author: Randy Dunlap Date: Mon May 3 19:32:18 2021 -0700 mfd: mp2629: Select MFD_CORE to fix build error [ Upstream commit a933272041d852a1ef1c85f0c18b93e9999a41fa ] MFD_MP2629 should select MFD_CORE to a prevent build error: ERROR: modpost: "devm_mfd_add_devices" [drivers/mfd/mp2629.ko] undefined! Fixes: 06081646450e ("mfd: mp2629: Add support for mps battery charger") Signed-off-by: Randy Dunlap Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 270c97c23e0d6569fa91cd99415f2ecb1c7e4fe8 Author: Mike Christie Date: Tue May 25 13:18:09 2021 -0500 scsi: iscsi: Flush block work before unblock [ Upstream commit 7ce9fc5ecde0d8bd64c29baee6c5e3ce7074ec9a ] We set the max_active iSCSI EH works to 1, so all work is going to execute in order by default. However, userspace can now override this in sysfs. If max_active > 1, we can end up with the block_work on CPU1 and iscsi_unblock_session running the unblock_work on CPU2 and the session and target/device state will end up out of sync with each other. This adds a flush of the block_work in iscsi_unblock_session. Link: https://lore.kernel.org/r/20210525181821.7617-17-michael.christie@oracle.com Fixes: 1d726aa6ef57 ("scsi: iscsi: Optimize work queue flush use") Reviewed-by: Lee Duncan Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit bee1e10216dc1b9b79f88b86e2124d0071bd6b31 Author: Mike Christie Date: Tue May 25 13:18:00 2021 -0500 scsi: iscsi: Fix in-kernel conn failure handling [ Upstream commit 23d6fefbb3f6b1cc29794427588b470ed06ff64e ] Commit 0ab710458da1 ("scsi: iscsi: Perform connection failure entirely in kernel space") has the following regressions/bugs that this patch fixes: 1. It can return cmds to upper layers like dm-multipath where that can retry them. After they are successful the fs/app can send new I/O to the same sectors, but we've left the cmds running in FW or in the net layer. We need to be calling ep_disconnect if userspace is not up. This patch only fixes the issue for offload drivers. iscsi_tcp will be fixed in separate commit because it doesn't have a ep_disconnect call. 2. The drivers that implement ep_disconnect expect that it's called before conn_stop. Besides crashes, if the cleanup_task callout is called before ep_disconnect it might free up driver/card resources for session1 then they could be allocated for session2. But because the driver's ep_disconnect is not called it has not cleaned up the firmware so the card is still using the resources for the original cmd. 3. The stop_conn_work_fn can run after userspace has done its recovery and we are happily using the session. We will then end up with various bugs depending on what is going on at the time. We may also run stop_conn_work_fn late after userspace has called stop_conn and ep_disconnect and is now going to call start/bind conn. If stop_conn_work_fn runs after bind but before start, we would leave the conn in a unbound but sort of started state where IO might be allowed even though the drivers have been set in a state where they no longer expect I/O. 4. Returning -EAGAIN in iscsi_if_destroy_conn if we haven't yet run the in kernel stop_conn function is breaking userspace. We should have been doing this for the caller. Link: https://lore.kernel.org/r/20210525181821.7617-8-michael.christie@oracle.com Fixes: 0ab710458da1 ("scsi: iscsi: Perform connection failure entirely in kernel space") Reviewed-by: Lee Duncan Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 3f1782fc50f9bd38fedbb879a26ce9655c14c0de Author: Mike Christie Date: Tue May 25 13:17:59 2021 -0500 scsi: iscsi: Rel ref after iscsi_lookup_endpoint() [ Upstream commit 9e5fe1700896c85040943fdc0d3fee0dd3e0d36f ] Subsequent commits allow the kernel to do ep_disconnect. In that case we will have to get a proper refcount on the ep so one thread does not delete it from under another. Link: https://lore.kernel.org/r/20210525181821.7617-7-michael.christie@oracle.com Reviewed-by: Lee Duncan Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 96a6275ea9009ddc1a63fd8e343fd122abd2dec6 Author: Mike Christie Date: Tue May 25 13:17:58 2021 -0500 scsi: iscsi: Use system_unbound_wq for destroy_work [ Upstream commit b25b957d2db1585602c2c70fdf4261a5641fe6b7 ] Use the system_unbound_wq for async session destruction. We don't need a dedicated workqueue for async session destruction because: 1. perf does not seem to be an issue since we only allow 1 active work. 2. it does not have deps with other system works and we can run them in parallel with each other. Link: https://lore.kernel.org/r/20210525181821.7617-6-michael.christie@oracle.com Reviewed-by: Lee Duncan Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 6622a20c1c70f73c0b5b2dc2e24bf4b779a46ae3 Author: Mike Christie Date: Tue May 25 13:17:57 2021 -0500 scsi: iscsi: Force immediate failure during shutdown [ Upstream commit 06c203a5566beecebb1f8838d026de8a61c8df71 ] If the system is not up, we can just fail immediately since iscsid is not going to ever answer our netlink events. We are already setting the recovery_tmo to 0, but by passing stop_conn STOP_CONN_TERM we never will block the session and start the recovery timer, because for that flag userspace will do the unbind and destroy events which would remove the devices and wake up and kill the eh. Since the conn is dead and the system is going dowm this just has us use STOP_CONN_RECOVER with recovery_tmo=0 so we fail immediately. However, if the user has set the recovery_tmo=-1 we let the system hang like they requested since they might have used that setting for specific reasons (one known reason is for buggy cluster software). Link: https://lore.kernel.org/r/20210525181821.7617-5-michael.christie@oracle.com Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 901d6de154af50f3bde32b7fe7735de19e5425be Author: Mike Christie Date: Tue May 25 13:17:55 2021 -0500 scsi: iscsi: Stop queueing during ep_disconnect [ Upstream commit 891e2639deae721dc43764a44fa255890dc34313 ] During ep_disconnect we have been doing iscsi_suspend_tx/queue to block new I/O but every driver except cxgbi and iscsi_tcp can still get I/O from __iscsi_conn_send_pdu() if we haven't called iscsi_conn_failure() before ep_disconnect. This could happen if we were terminating the session, and the logout timed out before it was even sent to libiscsi. Fix the issue by adding a helper which reverses the bind_conn call that allows new I/O to be queued. Drivers implementing ep_disconnect can use this to make sure new I/O is not queued to them when handling the disconnect. Link: https://lore.kernel.org/r/20210525181821.7617-3-michael.christie@oracle.com Reviewed-by: Lee Duncan Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c7db90f1ad98d4a421a2a65eb019496ad6325d61 Author: Randy Dunlap Date: Sat May 29 16:48:57 2021 -0700 scsi: FlashPoint: Rename si_flags field [ Upstream commit 4d431153e751caa93f3b7e6f6313446974e92253 ] The BusLogic driver has build errors on ia64 due to a name collision (in the #included FlashPoint.c file). Rename the struct field in struct sccb_mgr_info from si_flags to si_mflags (manager flags) to mend the build. This is the first problem. There are 50+ others after this one: In file included from ../include/uapi/linux/signal.h:6, from ../include/linux/signal_types.h:10, from ../include/linux/sched.h:29, from ../include/linux/hardirq.h:9, from ../include/linux/interrupt.h:11, from ../drivers/scsi/BusLogic.c:27: ../arch/ia64/include/uapi/asm/siginfo.h:15:27: error: expected ':', ',', ';', '}' or '__attribute__' before '.' token 15 | #define si_flags _sifields._sigfault._flags | ^ ../drivers/scsi/FlashPoint.c:43:6: note: in expansion of macro 'si_flags' 43 | u16 si_flags; | ^~~~~~~~ In file included from ../drivers/scsi/BusLogic.c:51: ../drivers/scsi/FlashPoint.c: In function 'FlashPoint_ProbeHostAdapter': ../drivers/scsi/FlashPoint.c:1076:11: error: 'struct sccb_mgr_info' has no member named '_sifields' 1076 | pCardInfo->si_flags = 0x0000; | ^~ ../drivers/scsi/FlashPoint.c:1079:12: error: 'struct sccb_mgr_info' has no member named '_sifields' Link: https://lore.kernel.org/r/20210529234857.6870-1-rdunlap@infradead.org Fixes: 391e2f25601e ("[SCSI] BusLogic: Port driver to 64-bit.") Cc: "James E.J. Bottomley" Cc: "Martin K. Petersen" Cc: Christoph Hellwig Cc: Jens Axboe Cc: Hannes Reinecke Cc: Khalid Aziz Cc: Khalid Aziz Reported-by: kernel test robot Reviewed-by: Hannes Reinecke Signed-off-by: Randy Dunlap Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 710c7ffff9ae152af5799d8a1fb160a51eb8de78 Author: Andy Shevchenko Date: Mon May 10 12:50:40 2021 +0300 leds: lp50xx: Put fwnode in error case during ->probe() [ Upstream commit f1e1d532da7e6ef355528a22fb97d9a8fbf76c4e ] fwnode_for_each_child_node() bumps a reference counting of a returned variable. We have to balance it whenever we return to the caller. OTOH, the successful iteration will drop reference count under the hood, no need to do it twice. Fixes: 242b81170fb8 ("leds: lp50xx: Add the LP50XX family of the RGB LED driver") Cc: Dan Murphy Signed-off-by: Andy Shevchenko Signed-off-by: Pavel Machek Signed-off-by: Sasha Levin commit 93d38eec2923ae9c185dd438a8d5ae78b9019fb8 Author: Andy Shevchenko Date: Mon May 10 12:50:39 2021 +0300 leds: lm3697: Don't spam logs when probe is deferred [ Upstream commit 807553f8bf4afa673750e52905e0f9488179112f ] When requesting GPIO line the probe can be deferred. In such case don't spam logs with an error message. This can be achieved by switching to dev_err_probe(). Fixes: 5c1d824cda9f ("leds: lm3697: Introduce the lm3697 driver") Cc: Dan Murphy Signed-off-by: Andy Shevchenko Signed-off-by: Pavel Machek Signed-off-by: Sasha Levin commit a20a178d2aaf86fb2f739190b24377b5d945ca90 Author: Andy Shevchenko Date: Mon May 10 12:50:35 2021 +0300 leds: lm3692x: Put fwnode in any case during ->probe() [ Upstream commit f55db1c7fadc2a29c9fa4ff3aec98dbb111f2206 ] device_get_next_child_node() bumps a reference counting of a returned variable. We have to balance it whenever we return to the caller. Fixes: 9a5c1c64ac0a ("leds: lm3692x: Change DT calls to fwnode calls") Cc: Dan Murphy Signed-off-by: Andy Shevchenko Signed-off-by: Pavel Machek Signed-off-by: Sasha Levin commit 4c8bfceb5c405119cf0ebe597857158c99c0b021 Author: Andy Shevchenko Date: Mon May 10 12:50:33 2021 +0300 leds: lm36274: Put fwnode in error case during ->probe() [ Upstream commit 3c5f655c44bb65cb7e3c219d08c130ce5fa45d7f ] device_get_next_child_node() bumps a reference counting of a returned variable. We have to balance it whenever we return to the caller. In the older code the same is implied with device_for_each_child_node(). Fixes: 11e1bbc116a7 ("leds: lm36274: Introduce the TI LM36274 LED driver") Fixes: a448fcf19c9c ("leds: lm36274: don't iterate through children since there is only one") Cc: Dan Murphy Cc: Marek Behún Signed-off-by: Andy Shevchenko Signed-off-by: Pavel Machek Signed-off-by: Sasha Levin commit 0045de2146523e045b523c1c5be448df14d6f1e9 Author: Andy Shevchenko Date: Mon May 10 12:50:31 2021 +0300 leds: lm3532: select regmap I2C API [ Upstream commit 99be74f61cb0292b518f5e6d7e5c6611555c2ec7 ] Regmap APIs should be selected, otherwise link can fail ERROR: modpost: "__devm_regmap_init_i2c" [drivers/leds/leds-lm3532.ko] undefined! Fixes: bc1b8492c764 ("leds: lm3532: Introduce the lm3532 LED driver") Cc: Dan Murphy Signed-off-by: Andy Shevchenko Signed-off-by: Pavel Machek Signed-off-by: Sasha Levin commit bd9b145ab8abe47b29b6766a43f5fa1fd762d115 Author: Andy Shevchenko Date: Mon May 10 12:50:24 2021 +0300 leds: lgm-sso: Fix clock handling [ Upstream commit fba8a6f2263bc54683cf3fd75df4dbd5d041c195 ] The clock handling has a few issues: - when getting second clock fails, the first one left prepared and enabled - on ->remove() clocks are unprepared and disabled twice Fix all these by converting to use bulk clock operations since both clocks are mandatory. Fixes: c3987cd2bca3 ("leds: lgm: Add LED controller driver for LGM SoC") Cc: Amireddy Mallikarjuna reddy Signed-off-by: Andy Shevchenko Signed-off-by: Pavel Machek Signed-off-by: Sasha Levin commit fee25ffa1454d91809ee94981b2c5ca08de5e62e Author: Andy Shevchenko Date: Mon May 10 12:50:18 2021 +0300 leds: class: The -ENOTSUPP should never be seen by user space [ Upstream commit 0ac40af86077982a5346dbc9655172d2775d6b08 ] Drop the bogus error code and let of_led_get() to take care about absent of_node. Fixes: e389240ad992 ("leds: Add managed API to get a LED from a device driver") Cc: Jean-Jacques Hiblot Signed-off-by: Andy Shevchenko Signed-off-by: Pavel Machek Signed-off-by: Sasha Levin commit e25b5dcc4c86066adea071ddb5f2e02670ae44d7 Author: Christophe JAILLET Date: Tue May 25 20:51:57 2021 +0200 tty: nozomi: Fix the error handling path of 'nozomi_card_init()' [ Upstream commit 6ae7d0f5a92b9619f6e3c307ce56b2cefff3f0e9 ] The error handling path is broken and we may un-register things that have never been registered. Update the loops index accordingly. Fixes: 9842c38e9176 ("kfifo: fix warn_unused_result") Suggested-by: Dan Carpenter Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/e28c2e92c7475da25b03d022ea2d6dcf1ba807a2.1621968629.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1d1edde89cb4c6dd63624b627f48cf86b210ea88 Author: Christophe JAILLET Date: Fri May 21 20:22:15 2021 +0200 firmware: stratix10-svc: Fix a resource leak in an error handling path [ Upstream commit d99247f9b542533ddbf87a3481a05473b8e48194 ] If an error occurs after a successful 'kfifo_alloc()' call, it must be undone by a corresponding 'kfifo_free()' call, as already done in the remove function. While at it, move the 'platform_device_put()' call to this new error handling path and explicitly return 0 in the success path. Fixes: b5dc75c915cd ("firmware: stratix10-svc: extend svc to support new RSU features") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/0ca3f3ab139c53e846804455a1e7599ee8ae896a.1621621271.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 51790ca96fd006edd03ac524fa6092a18b2236f3 Author: Christophe JAILLET Date: Sat May 22 08:55:03 2021 +0200 misc/pvpanic-mmio: Fix error handling in 'pvpanic_mmio_probe()' [ Upstream commit 9a3c72ee6ffcd461bae1bbdf4e71dca6d5bc160c ] There is no error handling path in the probe function. Switch to managed resource so that errors in the probe are handled easily and simplify the remove function accordingly. Fixes: b3c0f8774668 ("misc/pvpanic: probe multiple instances") Reviewed-by: Andy Shevchenko Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/2a5dab18f10db783b27e0579ba66cc38d610734a.1621665058.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a9ecb8bc82abd75d094ef07a96f587d2ea4a8956 Author: Christophe JAILLET Date: Sat May 22 08:54:33 2021 +0200 misc/pvpanic-pci: Fix error handling in 'pvpanic_pci_probe()' [ Upstream commit 372dae89972594393b57f29ec44e351fa7eedbbe ] There is no error handling path in the probe function. Switch to managed resource so that errors in the probe are handled easily and simplify the remove function accordingly. Fixes: db3a4f0abefd ("misc/pvpanic: add PCI driver") Reviewed-by: Andy Shevchenko Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/ab071b1f4ed6e1174f9199095fb16a58bb406090.1621665058.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b91a065a5ba4d3ac173326894a8d2a064ef802e6 Author: Yu Kuai Date: Fri May 21 20:06:17 2021 +0800 char: pcmcia: error out if 'num_bytes_read' is greater than 4 in set_protocol() [ Upstream commit 37188559c610f1b7eec83c8e448936c361c578de ] Theoretically, it will cause index out of bounds error if 'num_bytes_read' is greater than 4. As we expect it(and was tested) never to be greater than 4, error out if it happens. Fixes: c1986ee9bea3 ("[PATCH] New Omnikey Cardman 4000 driver") Signed-off-by: Yu Kuai Link: https://lore.kernel.org/r/20210521120617.138396-1-yukuai3@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f46e3fd7d9653dc2b0584f481c92fde493757377 Author: Dave Stevenson Date: Tue May 25 23:57:37 2021 +0200 staging: mmal-vchiq: Fix incorrect static vchiq_instance. [ Upstream commit afc023da53e46b88552822f2fe035c7129c505a2 ] For some reason lost in history function vchiq_mmal_init used a static variable for storing the vchiq_instance. This value is retrieved from vchiq per instance, so worked fine until you try to call vchiq_mmal_init multiple times concurrently when things then go wrong. This seemed to happen quite frequently if using the cutdown firmware (no MMAL or VCSM services running) as the vchiq_connect then failed, and one or other vchiq_shutdown was working on an invalid handle. Remove the static so that each caller gets a unique vchiq_instance. Fixes: 7b3ad5abf027 ("staging: Import the BCM2835 MMAL-based V4L2 camera driver.") Signed-off-by: Dave Stevenson Signed-off-by: Stefan Wahren Link: https://lore.kernel.org/r/1621979857-26754-1-git-send-email-stefan.wahren@i2se.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9e6812ac02cb1c627a685a9d0d29836bd2c71432 Author: Miquel Raynal Date: Wed May 26 11:32:41 2021 +0200 mtd: rawnand: arasan: Ensure proper configuration for the asserted target [ Upstream commit b5437c7b682c9a505065b4ab4716cdc951dc3c7c ] The controller being always asserting one CS or the other, there is no need to actually select the right target before doing a page read/write. However, the anfc_select_target() helper actually also changes the timing configuration and clock in the case were two different NAND chips with different timing requirements would be used. In this situation, we must ensure proper configuration of the controller by calling it. As a consequence of this change, the anfc_select_target() helper is being moved earlier in the driver. Fixes: 88ffef1b65cf ("mtd: rawnand: arasan: Support the hardware BCH ECC engine") Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210526093242.183847-4-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin commit 765beb5ef9da4fecb50210decd55dd24187a0698 Author: Ansuel Smith Date: Wed May 26 01:09:31 2021 +0200 mtd: parsers: qcom: Fix leaking of partition name [ Upstream commit 10f3b4d79958d6f9f71588c6fa862159c83fa80f ] Add cleanup function as the name variable for the partition name was allocaed but never freed after the use as the add mtd function duplicate the name and free the pparts struct as the partition name is assumed to be static. The leak was found using kmemleak. Fixes: 803eb124e1a6 ("mtd: parsers: Add Qcom SMEM parser") Signed-off-by: Ansuel Smith Reviewed-by: Bjorn Andersson Reviewed-by: Manivannan Sadhasivam Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210525230931.30013-1-ansuelsmth@gmail.com Signed-off-by: Sasha Levin commit d5023eb76f0dc651558b0c7ba04565891ff18435 Author: Corentin Labbe Date: Thu May 20 11:48:50 2021 +0000 mtd: partitions: redboot: seek fis-index-block in the right node [ Upstream commit 237960880960863fb41888763d635b384cffb104 ] fis-index-block is seeked in the master node and not in the partitions node. For following binding and current usage, the driver need to check the partitions subnode. Fixes: c0e118c8a1a3 ("mtd: partitions: Add OF support to RedBoot partitions") Signed-off-by: Corentin Labbe Reviewed-by: Linus Walleij Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210520114851.1274609-1-clabbe@baylibre.com Signed-off-by: Sasha Levin commit e6fd14af0e6bfd5acf38004e8430dc44873e77b3 Author: Adrian Hunter Date: Tue May 25 12:51:03 2021 +0300 perf scripting python: Fix tuple_set_u64() [ Upstream commit d04c1ff0b3ddd5c0fbbe640996c8eaad279ed1c5 ] tuple_set_u64() produces a signed value instead of an unsigned value. That works for database export but not other cases. Rename to tuple_set_d64() for database export and fix tuple_set_u64(). Fixes: df919b400ad3f ("perf scripting python: Extend interface to export data in a database-friendly way") Signed-off-by: Adrian Hunter Cc: Andi Kleen Cc: Jiri Olsa Signed-off-by: Arnaldo Carvalho de Melo Link: https://lore.kernel.org/r/20210525095112.1399-2-adrian.hunter@intel.com Signed-off-by: Sasha Levin commit 693c6dc2bdb34ebaea8d7327bcd7cc79e0425bcd Author: Zhen Lei Date: Mon May 24 11:52:42 2021 -0700 Input: hil_kbd - fix error return code in hil_dev_connect() [ Upstream commit d9b576917a1d0efa293801a264150a1b37691617 ] Return error code -EINVAL rather than '0' when the combo devices are not supported. Fixes: fa71c605c2bb ("Input: combine hil_kbd and hil_ptr drivers") Reported-by: Hulk Robot Signed-off-by: Zhen Lei Link: https://lore.kernel.org/r/20210515030053.6824-1-thunder.leizhen@huawei.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 0a663843c2d5450e6f5b923d956c7570305a4558 Author: Kuninori Morimoto Date: Mon May 24 15:12:09 2021 +0900 ASoC: rsnd: tidyup loop on rsnd_adg_clk_query() [ Upstream commit cf9d5c6619fadfc41cf8f5154cb990cc38e3da85 ] commit 06e8f5c842f2d ("ASoC: rsnd: don't call clk_get_rate() under atomic context") used saved clk_rate, thus for_each_rsnd_clk() is no longer needed. This patch fixes it. Fixes: 06e8f5c842f2d ("ASoC: rsnd: don't call clk_get_rate() under atomic context") Signed-off-by: Kuninori Morimoto Link: https://lore.kernel.org/r/87v978oe2u.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 524f379950320f37e29f9449ef75157bd89c0b78 Author: Badhri Jagan Sridharan Date: Mon May 17 12:21:09 2021 -0700 usb: typec: tcpm: Fix up PR_SWAP when vsafe0v is signalled [ Upstream commit d112efbe6dbf7d4c482e2a3f381fa315aabfe63b ] During PR_SWAP, When TCPM is in PR_SWAP_SNK_SRC_SINK_OFF, vbus is expected to reach VSAFE0V when source turns off vbus. Do not move to SNK_UNATTACHED state when this happens. Fixes: 28b43d3d746b ("usb: typec: tcpm: Introduce vsafe0v for vbus") Reviewed-by: Guenter Roeck Acked-by: Heikki Krogerus Signed-off-by: Badhri Jagan Sridharan Link: https://lore.kernel.org/r/20210517192112.40934-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 69660a9aee199588483c578bdfee11c3f6dbbd3e Author: Andy Shevchenko Date: Mon May 10 12:57:16 2021 +0300 backlight: lm3630a_bl: Put fwnode in error case during ->probe() [ Upstream commit 6d1c32dbedd7d7e7372aa38033ec8782c39f6379 ] device_for_each_child_node() bumps a reference counting of a returned variable. We have to balance it whenever we return to the caller. Cc: Brian Masney Cc: Dan Murphy Fixes: 8fbce8efe15cd ("backlight: lm3630a: Add firmware node support") Signed-off-by: Andy Shevchenko Reviewed-by: Brian Masney Reviewed-by: Daniel Thompson Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit bed4f1f93767aade738019b69a492699b8ec4e6a Author: Yang Yingliang Date: Tue May 18 12:45:14 2021 +0800 ASoC: hisilicon: fix missing clk_disable_unprepare() on error in hi6210_i2s_startup() [ Upstream commit 375904e3931955fcf0a847f029b2492a117efc43 ] After calling clk_prepare_enable(), clk_disable_unprepare() need be called when calling clk_set_rate() failed. Fixes: 0bf750f4cbe1 ("ASoC: hisilicon: Add hi6210 i2s audio driver") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20210518044514.607010-1-yangyingliang@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4f662271fc5b1cd441e81008084a9fd6a9279b5a Author: Yang Yingliang Date: Tue May 18 15:58:47 2021 +0800 ASoC: rk3328: fix missing clk_disable_unprepare() on error in rk3328_platform_probe() [ Upstream commit d14eece945a8068a017995f7512ea2beac21e34b ] Fix the missing clk_disable_unprepare() before return from rk3328_platform_probe() in the error handling case. Fixes: c32759035ad2 ("ASoC: rockchip: support ACODEC for rk3328") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20210518075847.1116983-1-yangyingliang@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit af74662aaa87ba623dcf2940cbf327a076e952c8 Author: Jonathan Cameron Date: Sat May 1 18:13:48 2021 +0100 iio: potentiostat: lmp91000: Fix alignment of buffer in iio_push_to_buffers_with_timestamp() [ Upstream commit 8979b67ec61abc232636400ee8c758a16a73c95f ] Add __aligned(8) to ensure the buffer passed to iio_push_to_buffers_with_timestamp() is suitable for the naturally aligned timestamp that will be inserted. Here structure is not used, because this buffer is also used elsewhere in the driver. Fixes: 67e17300dc1d ("iio: potentiostat: add LMP91000 support") Signed-off-by: Jonathan Cameron Cc: Matt Ranostay Acked-by: Matt Ranostay Link: https://lore.kernel.org/r/20210501171352.512953-8-jic23@kernel.org Signed-off-by: Sasha Levin commit 90c16bad0d130745e69369d2a7cae02f28fa5878 Author: Jonathan Cameron Date: Sat May 1 18:13:47 2021 +0100 iio: cros_ec_sensors: Fix alignment of buffer in iio_push_to_buffers_with_timestamp() [ Upstream commit 8dea228b174ac9637b567e5ef54f4c40db4b3c41 ] The samples buffer is passed to iio_push_to_buffers_with_timestamp() which requires a buffer aligned to 8 bytes as it is assumed that the timestamp will be naturally aligned if present. Fixes tag is inaccurate but prior to that likely manual backporting needed (for anything before 4.18) Earlier than that the include file to fix is drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.h: commit 974e6f02e27 ("iio: cros_ec_sensors_core: Add common functions for the ChromeOS EC Sensor Hub.") present since kernel stable 4.10. (Thanks to Gwendal for tracking this down) Fixes: 5a0b8cb46624c ("iio: cros_ec: Move cros_ec_sensors_core.h in /include") Signed-off-by: Jonathan Cameron Reviewed-by: Gwendal Grignou commit b1d6d4cecdaa52acd509a8cec84a3fea349a533a Author: Jonathan Cameron Date: Sat May 1 18:13:46 2021 +0100 iio: chemical: atlas: Fix buffer alignment in iio_push_to_buffers_with_timestamp() [ Upstream commit b0f5d8db7348a6ce5cdd79fba46ebc91eebc8fd9 ] Variable location for the timestamp, so just use __aligned(8) to ensure it is always possible to naturally align it. Found during an audit of all calls of uses of iio_push_to_buffers_with_timestamp() Fixes tag is not accurate, but it will need manual backporting beyond that point if anyone cares. Fixes: 0d15190f53b4 ("iio: chemical: atlas-ph-sensor: rename atlas-ph-sensor to atlas-sensor") Signed-off-by: Jonathan Cameron Cc: Matt Ranostay Acked-by: Matt Ranostay Link: https://lore.kernel.org/r/20210501171352.512953-6-jic23@kernel.org Signed-off-by: Sasha Levin commit 5499e75447368be117788e7a3917eeafab9170a7 Author: Jonathan Cameron Date: Sat May 1 18:01:21 2021 +0100 iio: light: tcs3472: Fix buffer alignment in iio_push_to_buffers_with_timestamp() [ Upstream commit df2f37cffd6ed486d613e7ee22aadc8e49ae2dd3 ] To make code more readable, use a structure to express the channel layout and ensure the timestamp is 8 byte aligned. Found during an audit of all calls of uses of iio_push_to_buffers_with_timestamp(). Fixes tag is not strictly accurate as prior to that patch there was potentially an unaligned write. However, any backport past there will need to be done manually. Fixes: 0624bf847dd0 ("iio:tcs3472: Use iio_push_to_buffers_with_timestamp()") Signed-off-by: Jonathan Cameron Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210501170121.512209-20-jic23@kernel.org Signed-off-by: Sasha Levin commit 57df003962c41ab5216dd962c10e58614823a6d7 Author: Jonathan Cameron Date: Sat May 1 18:01:20 2021 +0100 iio: light: tcs3414: Fix buffer alignment in iio_push_to_buffers_with_timestamp() [ Upstream commit ff08fbc22ab32ccc6690c21b0e5e1d402dcc076f ] To make code more readable, use a structure to express the channel layout and ensure the timestamp is 8 byte aligned. Found during an audit of all calls of uses of iio_push_to_buffers_with_timestamp() Fixes: a244e7b57f0f ("iio: Add driver for AMS/TAOS tcs3414 digital color sensor") Signed-off-by: Jonathan Cameron Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210501170121.512209-19-jic23@kernel.org Signed-off-by: Sasha Levin commit 61aa73978ae5d12ace4f24d4aab27f3013fcd0c6 Author: Jonathan Cameron Date: Sat May 1 18:01:19 2021 +0100 iio: light: isl29125: Fix buffer alignment in iio_push_to_buffers_with_timestamp() [ Upstream commit 3d4725194de6935dba2ad7c9cc075c885008f747 ] To make code more readable, use a structure to express the channel layout and ensure the timestamp is 8 byte aligned. Found during an audit of all calls of uses of iio_push_to_buffers_with_timestamp() Fixes: 6c25539cbc46 ("iio: Add Intersil isl29125 digital color light sensor driver") Signed-off-by: Jonathan Cameron Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210501170121.512209-18-jic23@kernel.org Signed-off-by: Sasha Levin commit b25f1318c124b8f0385caea8f8a64c6ab350dfd1 Author: Jonathan Cameron Date: Sat May 1 18:01:18 2021 +0100 iio: magn: bmc150: Fix buffer alignment in iio_push_to_buffers_with_timestamp() [ Upstream commit 7692088f72865c41b6b531fd09486ee99a5da930 ] To make code more readable, use a structure to express the channel layout and ensure the timestamp is 8 byte aligned. Found during an audit of all calls of uses of iio_push_to_buffers_with_timestamp() Fixes: c91746a2361d ("iio: magn: Add support for BMC150 magnetometer") Signed-off-by: Jonathan Cameron Cc: Stephan Gerhold Cc: Linus Walleij Reviewed-by: Linus Walleij Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210501170121.512209-17-jic23@kernel.org Signed-off-by: Sasha Levin commit d40bbe4ccfe66099a5179e5f29f0947febe87550 Author: Jonathan Cameron Date: Sat May 1 18:01:17 2021 +0100 iio: magn: hmc5843: Fix buffer alignment in iio_push_to_buffers_with_timestamp() [ Upstream commit 1ef2f51e9fe424ccecca5bb0373d71b900c2cd41 ] To make code more readable, use a structure to express the channel layout and ensure the timestamp is 8 byte aligned. Found during an audit of all calls of uses of iio_push_to_buffers_with_timestamp() Fixes: 7247645f6865 ("iio: hmc5843: Move hmc5843 out of staging") Signed-off-by: Jonathan Cameron Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210501170121.512209-16-jic23@kernel.org Signed-off-by: Sasha Levin commit c8d0c967c04232a5c08001014f24e46cd3177c51 Author: Jonathan Cameron Date: Sat May 1 18:01:16 2021 +0100 iio: prox: as3935: Fix buffer alignment in iio_push_to_buffers_with_timestamp() [ Upstream commit 37eb8d8c64f2ecb3a5521ba1cc1fad973adfae41 ] To make code more readable, use a structure to express the channel layout and ensure the timestamp is 8 byte aligned. Found during an audit of all calls of uses of iio_push_to_buffers_with_timestamp() Fixes: 37b1ba2c68cf ("iio: proximity: as3935: fix buffer stack trashing") Signed-off-by: Jonathan Cameron Cc: Matt Ranostay Acked-by: Matt Ranostay Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210501170121.512209-15-jic23@kernel.org Signed-off-by: Sasha Levin commit ca40b4e4d0fb537cf76aa5223ded26aaaf2f51a3 Author: Jonathan Cameron Date: Sat May 1 18:01:15 2021 +0100 iio: prox: pulsed-light: Fix buffer alignment in iio_push_to_buffers_with_timestamp() [ Upstream commit 679cc377a03ff1944491eafc7355c1eb1fad4109 ] To make code more readable, use a structure to express the channel layout and ensure the timestamp is 8 byte aligned. Found during an audit of all calls of uses of iio_push_to_buffers_with_timestamp() Fixes: cb119d535083 ("iio: proximity: add support for PulsedLight LIDAR") Signed-off-by: Jonathan Cameron Cc: Matt Ranostay Acked-by: Matt Ranostay Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210501170121.512209-14-jic23@kernel.org Signed-off-by: Sasha Levin commit f124951d8b2f66f2ba65759724c842d1fa2dc764 Author: Jonathan Cameron Date: Sat May 1 18:01:14 2021 +0100 iio: prox: srf08: Fix buffer alignment in iio_push_to_buffers_with_timestamp() [ Upstream commit 19f1a254fe4949fff1e67db386409f48cf438bd7 ] To make code more readable, use a structure to express the channel layout and ensure the timestamp is 8 byte aligned. Found during an audit of all calls of uses of iio_push_to_buffers_with_timestamp() Fixes: 78f839029e1d ("iio: distance: srf08: add IIO driver for us ranger") Signed-off-by: Jonathan Cameron Cc: Andreas Klinger Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210501170121.512209-13-jic23@kernel.org Signed-off-by: Sasha Levin commit 870214f4d6176428a6d3e9671575ea40d8ed174f Author: Jonathan Cameron Date: Sat May 1 18:01:13 2021 +0100 iio: humidity: am2315: Fix buffer alignment in iio_push_to_buffers_with_timestamp() [ Upstream commit f4ca2e2595d9fee65d5ce0d218b22ce00e5b2915 ] To make code more readable, use a structure to express the channel layout and ensure the timestamp is 8 byte aligned. Found during an audit of all calls of uses of iio_push_to_buffers_with_timestamp() Fixes: 0d96d5ead3f7 ("iio: humidity: Add triggered buffer support for AM2315") Signed-off-by: Jonathan Cameron Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210501170121.512209-12-jic23@kernel.org Signed-off-by: Sasha Levin commit e41a3882768d6684de2727ea4ebe3a67bdbac0be Author: Jonathan Cameron Date: Sat May 1 18:01:12 2021 +0100 iio: gyro: bmg160: Fix buffer alignment in iio_push_to_buffers_with_timestamp() [ Upstream commit 06778d881f3798ce93ffbbbf801234292250b598 ] To make code more readable, use a structure to express the channel layout and ensure the timestamp is 8 byte aligned. Found during an audit of all calls of uses of iio_push_to_buffers_with_timestamp() Fixes: 13426454b649 ("iio: bmg160: Separate i2c and core driver") Signed-off-by: Jonathan Cameron Cc: Stephan Gerhold Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210501170121.512209-11-jic23@kernel.org Signed-off-by: Sasha Levin commit 64dff722b0df0f0ba10227507a048a8c3455382e Author: Jonathan Cameron Date: Sat May 1 18:01:11 2021 +0100 iio: adc: vf610: Fix buffer alignment in iio_push_to_buffers_with_timestamp() [ Upstream commit 7765dfaa22ea08abf0c175e7553826ba2a939632 ] To make code more readable, use a structure to express the channel layout and ensure the timestamp is 8 byte aligned. Found during an audit of all calls of uses of iio_push_to_buffers_with_timestamp() Fixes: 0010d6b44406 ("iio: adc: vf610: Add IIO buffer support for Vybrid ADC") Signed-off-by: Jonathan Cameron Cc: Stefan-Gabriel Mirea Cc: Sanchayan Maity Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210501170121.512209-10-jic23@kernel.org Signed-off-by: Sasha Levin commit c4302d44f1f11922d48655f627829c908d59d912 Author: Jonathan Cameron Date: Sat May 1 18:01:10 2021 +0100 iio: adc: ti-ads1015: Fix buffer alignment in iio_push_to_buffers_with_timestamp() [ Upstream commit d85d71dd1ab67eaa7351f69fec512d8f09d164e1 ] To make code more readable, use a structure to express the channel layout and ensure the timestamp is 8 byte aligned. Found during an audit of all calls of this function. Fixes: ecc24e72f437 ("iio: adc: Add TI ADS1015 ADC driver support") Signed-off-by: Jonathan Cameron Cc: Daniel Baluta Cc: Andy Shevchenko Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210501170121.512209-9-jic23@kernel.org Signed-off-by: Sasha Levin commit 927a7d88f0851e6cbc8d56d366364b2d82a6fd25 Author: Jonathan Cameron Date: Sat May 1 18:01:09 2021 +0100 iio: accel: stk8ba50: Fix buffer alignment in iio_push_to_buffers_with_timestamp() [ Upstream commit 334883894bc1e145a1e0f5de1b0d1b6a1133f0e6 ] To make code more readable, use a structure to express the channel layout and ensure the timestamp is 8 byte aligned. Found during an audit of all calls of this function. Fixes: db6a19b8251f ("iio: accel: Add trigger support for STK8BA50") Signed-off-by: Jonathan Cameron Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210501170121.512209-8-jic23@kernel.org Signed-off-by: Sasha Levin commit cc3e33b0c9a46dcfa4ed51c6048ed91851857541 Author: Jonathan Cameron Date: Sat May 1 18:01:08 2021 +0100 iio: accel: stk8312: Fix buffer alignment in iio_push_to_buffers_with_timestamp() [ Upstream commit f40a71ffec808e7e51848f63f0c0d3c32d65081b ] To make code more readable, use a structure to express the channel layout and ensure the timestamp is 8 byte aligned. Found during an audit of all calls of this function. Fixes: 95c12bba51c3 ("iio: accel: Add buffer mode for Sensortek STK8312") Signed-off-by: Jonathan Cameron Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210501170121.512209-7-jic23@kernel.org Signed-off-by: Sasha Levin commit 3ef6d9ff5b737aebe2bbcbab2da04074855ab837 Author: Jonathan Cameron Date: Sat May 1 18:01:07 2021 +0100 iio: accel: mxc4005: Fix overread of data and alignment issue. [ Upstream commit f65802284a3a337510d7f8f916c97d66c74f2e71 ] The bulk read size is based on the size of an array that also has space for the timestamp alongside the channels. Fix that and also fix alignment of the buffer passed to iio_push_to_buffers_with_timestamp. Found during an audit of all calls to this function. Fixes: 1ce0eda0f757 ("iio: mxc4005: add triggered buffer mode for mxc4005") Signed-off-by: Jonathan Cameron Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210501170121.512209-6-jic23@kernel.org Signed-off-by: Sasha Levin commit f8bd7333394887a996c32ddd7489055dc8e0e6c4 Author: Jonathan Cameron Date: Sat May 1 18:01:06 2021 +0100 iio: accel: kxcjk-1013: Fix buffer alignment in iio_push_to_buffers_with_timestamp() [ Upstream commit 3ab3aa2e7bd57497f9a7c6275c00dce237d2c9ba ] To make code more readable, use a structure to express the channel layout and ensure the timestamp is 8 byte aligned. Found during an audit of all calls of this function. Fixes: 1a4fbf6a9286 ("iio: accel: kxcjk1013 3-axis accelerometer driver") Signed-off-by: Jonathan Cameron Cc: Srinivas Pandruvada Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210501170121.512209-5-jic23@kernel.org Signed-off-by: Sasha Levin commit 8d49028df646b5aeb072bce1dcf2cce7c2dd6a3d Author: Jonathan Cameron Date: Sat May 1 18:01:05 2021 +0100 iio: accel: hid: Fix buffer alignment in iio_push_to_buffers_with_timestamp() [ Upstream commit c6559bf796ccdb3a0c79db846af96c8f7046880b ] To make code more readable, use a structure to express the channel layout and ensure the timestamp is 8 byte aligned. Note this matches what was done in all the other hid sensor drivers. This one was missed previously due to an extra level of indirection. Found during an audit of all calls of this function. Fixes: a96cd0f901ee ("iio: accel: hid-sensor-accel-3d: Add timestamp") Signed-off-by: Jonathan Cameron Cc: Srinivas Pandruvada Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210501170121.512209-4-jic23@kernel.org Signed-off-by: Sasha Levin commit 72daeb5f020e9841d21bcc41ec9e41982449fdb9 Author: Jonathan Cameron Date: Sat May 1 18:01:04 2021 +0100 iio: accel: bma220: Fix buffer alignment in iio_push_to_buffers_with_timestamp() [ Upstream commit 151dbf0078da98206817ee0b87d499035479ef11 ] To make code more readable, use a structure to express the channel layout and ensure the timestamp is 8 byte aligned. Found during an audit of all calls of this function. Fixes: 194dc4c71413 ("iio: accel: Add triggered buffer support for BMA220") Signed-off-by: Jonathan Cameron Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210501170121.512209-3-jic23@kernel.org Signed-off-by: Sasha Levin commit b9e837d4a7a465507d551ed976d0a1c7af9a33b3 Author: Jonathan Cameron Date: Sat May 1 18:01:03 2021 +0100 iio: accel: bma180: Fix buffer alignment in iio_push_to_buffers_with_timestamp() [ Upstream commit fc36da3131a747a9367a05caf06de19be1bcc972 ] To make code more readable, use a structure to express the channel layout and ensure the timestamp is 8 byte aligned. Found during an audit of all calls of this function. Fixes: b9a6a237ffc9 ("iio:bma180: Drop _update_scan_mode()") Signed-off-by: Jonathan Cameron Cc: Peter Meerwald Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210501170121.512209-2-jic23@kernel.org Signed-off-by: Sasha Levin commit 0a918214b71abab80977662a0336d910c961bdff Author: Nuno Sa Date: Tue Apr 27 10:54:49 2021 +0200 iio: adis16475: do not return ints in irq handlers [ Upstream commit 00a72db718fa198da3946286dcad222399ccd4fb ] On an IRQ handler we should not return normal error codes as 'irqreturn_t' is expected. This is done by jumping to the 'check_burst32' label where we return 'IRQ_HANDLED'. Note that it is fine to do the burst32 check in this error path. If we have proper settings to apply burst32, we might just do the setup now so that the next sample already uses it. Fixes: fff7352bf7a3c ("iio: imu: Add support for adis16475") Reviewed-by: Alexandru Ardelean Signed-off-by: Nuno Sa Link: https://lore.kernel.org/r/20210427085454.30616-2-nuno.sa@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit cac49141208aab4958400260958653279bbe28ff Author: Nuno Sa Date: Thu Apr 22 12:19:04 2021 +0200 iio: adis16400: do not return ints in irq handlers [ Upstream commit ab3df79782e7d8a27a58576c9b4e8c6c4879ad79 ] On an IRQ handler we should not return normal error codes as 'irqreturn_t' is expected. Not necessary to apply to stable as the original check cannot fail and as such the bug cannot actually occur. Fixes: 5eda3550a3cc1 ("staging:iio:adis16400: Preallocate transfer message") Reviewed-by: Alexandru Ardelean Signed-off-by: Nuno Sa Link: https://lore.kernel.org/r/20210422101911.135630-3-nuno.sa@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 7ad60ebd7c04e0aa4f0f0e201dc8824a74d8f199 Author: Nuno Sa Date: Thu Apr 22 12:19:03 2021 +0200 iio: adis_buffer: do not return ints in irq handlers [ Upstream commit d877539ad8e8fdde9af69887055fec6402be1a13 ] On an IRQ handler we should not return normal error codes as 'irqreturn_t' is expected. Not necessarily stable material as the old check cannot fail, so it's a bug we can not hit. Fixes: ccd2b52f4ac69 ("staging:iio: Add common ADIS library") Reviewed-by: Alexandru Ardelean Signed-off-by: Nuno Sa Link: https://lore.kernel.org/r/20210422101911.135630-2-nuno.sa@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 52728a7966dabd7c4cfe7acbfc6b31b0bf5a5983 Author: Arnd Bergmann Date: Sat May 8 00:07:55 2021 +0200 mwifiex: re-fix for unaligned accesses [ Upstream commit 8f4e3d48bb50765ab27ae5bebed2595b20de80a1 ] A patch from 2017 changed some accesses to DMA memory to use get_unaligned_le32() and similar interfaces, to avoid problems with doing unaligned accesson uncached memory. However, the change in the mwifiex_pcie_alloc_sleep_cookie_buf() function ended up changing the size of the access instead, as it operates on a pointer to u8. Change this function back to actually access the entire 32 bits. Note that the pointer is aligned by definition because it came from dma_alloc_coherent(). Fixes: 92c70a958b0b ("mwifiex: fix for unaligned reads") Acked-by: Kalle Valo Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit b25bc3e21b800c11ab19c070569b8cbe389596da Author: Sergio Paracuellos Date: Sat May 8 09:09:30 2021 +0200 phy: ralink: phy-mt7621-pci: properly print pointer address [ Upstream commit 652a6a2e3824ce2ebf79a2d5326940d05c4db036 ] The way of printing the pointer address for the 'port_base' address got into compile warnings on some architectures [-Wpointer-to-int-cast]. Instead of use '%08x' and cast to an 'unsigned int' just make use of '%px' and avoid the cast. To avoid not really needed driver verbosity on normal behaviour change also from 'dev_info' to 'dev_dbg'. Fixes: d87da32372a0 ("phy: ralink: Add PHY driver for MT7621 PCIe PHY") Reported-by: kernel test robot Signed-off-by: Sergio Paracuellos Link: https://lore.kernel.org/r/20210508070930.5290-7-sergio.paracuellos@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit c99410c9223de3f210ee6044566f970deb8b9fc0 Author: Christophe JAILLET Date: Sun May 9 19:22:33 2021 +0200 tty: nozomi: Fix a resource leak in an error handling function [ Upstream commit 31a9a318255960d32ae183e95d0999daf2418608 ] A 'request_irq()' call is not balanced by a corresponding 'free_irq()' in the error handling path, as already done in the remove function. Add it. Fixes: 9842c38e9176 ("kfifo: fix warn_unused_result") Reviewed-by: Jiri Slaby Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/4f0d2b3038e82f081d370ccb0cade3ad88463fe7.1620580838.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 527cc7317abf80a0b7f90141bde5cd3cbfafbc52 Author: Dan Carpenter Date: Thu Apr 29 10:19:22 2021 +0300 serial: 8250_omap: fix a timeout loop condition [ Upstream commit d7e325aaa8c3593b5a572b583ecad79e95f32e7f ] This loop ends on -1 so the error message will never be printed. Fixes: 4bcf59a5dea0 ("serial: 8250: 8250_omap: Account for data in flight during DMA teardown") Reviewed-by: Alexander Sverdlin Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/YIpd+kOpXKMpEXPf@mwanda Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d12c159cdd241b7e18695199f47611a491857080 Author: Michael Walle Date: Wed May 12 16:12:52 2021 +0200 serial: fsl_lpuart: remove RTSCTS handling from get_mctrl() [ Upstream commit e60c2991f18bf221fa9908ff10cb24eaedaa9bae ] The wrong code in set_mctrl() was already removed in commit 2b30efe2e88a ("tty: serial: lpuart: Remove unnecessary code from set_mctrl"), but the code in get_mctrl() wasn't removed. It will not return the state of the RTS or CTS line but whether automatic flow control is enabled, which is wrong for the get_mctrl(). Thus remove it. Fixes: 2b30efe2e88a ("tty: serial: lpuart: Remove unnecessary code from set_mctrl") Signed-off-by: Michael Walle Link: https://lore.kernel.org/r/20210512141255.18277-7-michael@walle.cc Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 032c57aadf36a89b452ffadeda3bd73bfe711b4e Author: Michael Walle Date: Wed May 12 16:12:47 2021 +0200 serial: fsl_lpuart: don't modify arbitrary data on lpuart32 [ Upstream commit ccf08fd1204bcb5311cc10aea037c71c6e74720a ] lpuart_rx_dma_startup() is used for both the 8 bit and the 32 bit version of the LPUART. Modify the UARTCR only for the 8 bit version. Fixes: f4eef224a09f ("serial: fsl_lpuart: add sysrq support when using dma") Signed-off-by: Michael Walle Link: https://lore.kernel.org/r/20210512141255.18277-2-michael@walle.cc Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 75f27ce5b93bdfa05ccbb8faf4dbedca0f38ea84 Author: Paul E. McKenney Date: Wed Mar 31 10:59:05 2021 -0700 rcu: Invoke rcu_spawn_core_kthreads() from rcu_spawn_gp_kthread() [ Upstream commit 8e4b1d2bc198e34b48fc7cc3a3c5a2fcb269e271 ] Currently, rcu_spawn_core_kthreads() is invoked via an early_initcall(), which works, except that rcu_spawn_gp_kthread() is also invoked via an early_initcall() and rcu_spawn_core_kthreads() relies on adjustments to kthread_prio that are carried out by rcu_spawn_gp_kthread(). There is no guaranttee of ordering among early_initcall() handlers, and thus no guarantee that kthread_prio will be properly checked and range-limited at the time that rcu_spawn_core_kthreads() needs it. In most cases, this bug is harmless. After all, the only reason that rcu_spawn_gp_kthread() adjusts the value of kthread_prio is if the user specified a nonsensical value for this boot parameter, which experience indicates is rare. Nevertheless, a bug is a bug. This commit therefore causes the rcu_spawn_core_kthreads() function to be invoked directly from rcu_spawn_gp_kthread() after any needed adjustments to kthread_prio have been carried out. Fixes: 48d07c04b4cc ("rcu: Enable elimination of Tree-RCU softirq processing") Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit 0b5edb884bf7e23d336f3b9ddaa8ad240fec5c45 Author: Stephen Boyd Date: Sat May 8 00:51:50 2021 -0700 ASoC: rt5682: Disable irq on shutdown [ Upstream commit 47bcb1c7108363418cd578283333d72e310dfeaa ] We cancel the work queues, and reset the device on shutdown, but the irq isn't disabled so the work queues could be queued again. Let's disable the irq during shutdown so that we don't have to worry about this device trying to do anything anymore. This fixes a problem seen where the i2c bus is shutdown at reboot but this device irq still comes in and tries to make another i2c transaction when the bus doesn't work. Cc: Jairaj Arava Cc: Sathyanarayana Nujella Cc: Pierre-Louis Bossart Cc: Shuming Fan Cc: Ranjani Sridharan Fixes: 45a2702ce109 ("ASoC: rt5682: Fix panic in rt5682_jack_detect_handler happening during system shutdown") Signed-off-by: Stephen Boyd Link: https://lore.kernel.org/r/20210508075151.1626903-1-swboyd@chromium.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6dfbed1ac5735ffc18b1645f8189dd48cec12291 Author: Andy Shevchenko Date: Mon May 3 20:21:11 2021 +0300 staging: fbtft: Don't spam logs when probe is deferred [ Upstream commit 37667f6e57712cef5652fa67f1cbd1299e204d94 ] When requesting GPIO line the probe can be deferred. In such case don't spam logs with an error message. This can be achieved by switching to dev_err_probe(). Fixes: c440eee1a7a1 ("Staging: fbtft: Switch to the gpio descriptor interface") Cc: Nishad Kamdar Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210503172114.27891-3-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 37a3335c1b454d396bd295ecccf098b3f7ab1fa7 Author: Andy Shevchenko Date: Mon May 3 20:21:10 2021 +0300 staging: fbtft: Rectify GPIO handling [ Upstream commit ec03c2104365ead0a33627c05e685093eed3eaef ] The infamous commit c440eee1a7a1 ("Staging: staging: fbtft: Switch to the GPIO descriptor interface") broke GPIO handling completely. It has already four commits to rectify and it seems not enough. In order to fix the mess here we: 1) Set default to "inactive" for all requested pins 2) Fix CS#, RD#, and WR# pins polarity since it's active low and GPIO descriptor interface takes it into consideration from the Device Tree or ACPI 3) Consolidate chip activation (CS# assertion) under default ->reset() callback To summarize the expectations about polarity for GPIOs: RD# Low WR# Low CS# Low RESET# Low DC or RS High RW High Data 0 .. 15 High See also Adafruit learning course [1] for the example of the schematics. While at it, drop unneeded NULL checks, since GPIO API is tolerant to that. [1]: https://learn.adafruit.com/adafruit-2-8-and-3-2-color-tft-touchscreen-breakout-v2/downloads Fixes: 92e3e884887c ("Staging: fbtft: Fix GPIO handling") Fixes: b918d1c27066 ("Staging: fbtft: Fix reset assertion when using gpio descriptor") Fixes: dbc4f989c878 ("Staging: fbtft: Fix probing of gpio descriptor") Fixes: c440eee1a7a1 ("Staging: fbtft: Switch to the gpio descriptor interface") Cc: Jan Sebastian Götte Cc: Nishad Kamdar Reviewed-by: Phil Reid Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210503172114.27891-2-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3fc3179becfa72050408e3bb6a037ed34494103b Author: Christophe JAILLET Date: Sun May 2 09:21:08 2021 +0200 staging: rtl8712: Fix some tests against some 'data' subtype frames [ Upstream commit 116138c3bd34f92e550431d495db515f5ea19f13 ] Commit 6e2baa44c6d1 ("staging: rtl8712: remove enum WIFI_FRAME_SUBTYPE") was wrong because: WIFI_DATA_NULL != IEEE80211_STYPE_NULLFUNC WIFI_DATA_CFACK != IEEE80211_STYPE_DATA_CFACK WIFI_DATA_CFPOLL != IEEE80211_STYPE_DATA_CFPOLL WIFI_DATA_CFACKPOLL != IEEE80211_STYPE_DATA_CFACKPOLL the WIFI_DATA_xxx definitions include WIFI_DATA_TYPE, which is 'BIT(3)'. Restore the previous behavior by adding the missing 'IEEE80211_FTYPE_DATA |' (0x0008, that is to say BIT(3)) when these values are used. Hopefully, the wrong commit was small enough and hand review is possible. Fixes: 6e2baa44c6d1 ("staging: rtl8712: remove enum WIFI_FRAME_SUBTYPE") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/44aebfa3c5ce8f45ae05369c73e9ff77c6d271f9.1619939806.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 466654d21be1bb74ba41706895209a5dc0b11a31 Author: Wei Li Date: Tue Jun 29 22:14:20 2021 +0800 MIPS: Fix PKMAP with 32-bit MIPS huge page support [ Upstream commit cf02ce742f09188272bcc8b0e62d789eb671fc4c ] When 32-bit MIPS huge page support is enabled, we halve the number of pointers a PTE page holds, making its last half go to waste. Correspondingly, we should halve the number of kmap entries, as we just initialized only a single pte table for that in pagetable_init(). Fixes: 35476311e529 ("MIPS: Add partial 32-bit huge page support") Signed-off-by: Wei Li Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 7ab2438efaba387080219c63d16c8a9d242fc3ea Author: Leon Romanovsky Date: Tue Jun 29 09:49:33 2021 +0300 RDMA/core: Always release restrack object [ Upstream commit 3d8287544223a3d2f37981c1f9ffd94d0b5e9ffc ] Change location of rdma_restrack_del() to fix the bug where task_struct was acquired but not released, causing to resource leak. ucma_create_id() { ucma_alloc_ctx(); rdma_create_user_id() { rdma_restrack_new(); rdma_restrack_set_name() { rdma_restrack_attach_task.part.0(); <--- task_struct was gotten } } ucma_destroy_private_ctx() { ucma_put_ctx(); rdma_destroy_id() { _destroy_id() <--- id_priv was freed } } } Fixes: 889d916b6f8a ("RDMA/core: Don't access cm_id after its destruction") Link: https://lore.kernel.org/r/073ec27acb943ca8b6961663c47c5abe78a5c8cc.1624948948.git.leonro@nvidia.com Reported-by: Pavel Skripkin Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit d19a51aaafcf88cd1d640802f4607efe7c761794 Author: Leon Romanovsky Date: Tue Jun 29 11:51:38 2021 +0300 RDMA/mlx5: Don't access NULL-cleared mpi pointer [ Upstream commit 4a754d7637026b42b0c9ba5787ad5ee3bc2ff77f ] The "dev->port[i].mp.mpi" is set to NULL during mlx5_ib_unbind_slave_port() execution, however that field is needed to add device to unaffiliated list. Such flow causes to the following kernel panic while unloading mlx5_ib module in multi-port mode, hence the device should be added to the list prior to unbind call. RPC: Unregistered rdma transport module. RPC: Unregistered rdma backchannel transport module. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI CPU: 4 PID: 1904 Comm: modprobe Not tainted 5.13.0-rc7_for_upstream_min_debug_2021_06_24_12_08 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5_ib_cleanup_multiport_master+0x18b/0x2d0 [mlx5_ib] Code: 00 04 0f 85 c4 00 00 00 48 89 df e8 ef fa ff ff 48 8b 83 40 0d 00 00 48 8b 15 b9 e8 05 00 4a 8b 44 28 20 48 89 05 ad e8 05 00 <48> c7 00 d0 57 c5 a0 48 89 50 08 48 89 02 39 ab 88 0a 00 00 0f 86 RSP: 0018:ffff888116ee3df8 EFLAGS: 00010296 RAX: 0000000000000000 RBX: ffff8881154f6000 RCX: 0000000000000080 RDX: ffffffffa0c557d0 RSI: ffff88810b69d200 RDI: 000000000002d8a0 RBP: 0000000000000002 R08: ffff888110780408 R09: 0000000000000000 R10: ffff88812452e1c0 R11: fffffffffff7e028 R12: 0000000000000000 R13: 0000000000000080 R14: ffff888102c58000 R15: 0000000000000000 FS: 00007f884393a740(0000) GS:ffff8882f5a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001249f6004 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mlx5_ib_stage_init_cleanup+0x16/0xd0 [mlx5_ib] __mlx5_ib_remove+0x33/0x90 [mlx5_ib] mlx5r_remove+0x22/0x30 [mlx5_ib] auxiliary_bus_remove+0x18/0x30 __device_release_driver+0x177/0x220 driver_detach+0xc4/0x100 bus_remove_driver+0x58/0xd0 auxiliary_driver_unregister+0x12/0x20 mlx5_ib_cleanup+0x13/0x897 [mlx5_ib] __x64_sys_delete_module+0x154/0x230 ? exit_to_user_mode_prepare+0x104/0x140 do_syscall_64+0x3f/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f8842e095c7 Code: 73 01 c3 48 8b 0d d9 48 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a9 48 2c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffc68f6e758 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 RAX: ffffffffffffffda RBX: 00005638207929c0 RCX: 00007f8842e095c7 RDX: 0000000000000000 RSI: 0000000000000800 RDI: 0000563820792a28 RBP: 00005638207929c0 R08: 00007ffc68f6d701 R09: 0000000000000000 R10: 00007f8842e82880 R11: 0000000000000206 R12: 0000563820792a28 R13: 0000000000000001 R14: 0000563820792a28 R15: 00007ffc68f6fb40 Modules linked in: xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat xt_addrtype xt_conntrack nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter overlay rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_ipoib ib_cm ib_umad mlx5_ib(-) mlx4_ib ib_uverbs ib_core mlx4_en mlx4_core mlx5_core ptp pps_core [last unloaded: rpcrdma] CR2: 0000000000000000 ---[ end trace a0bb7e20804e9e9b ]--- Fixes: 7ce6095e3bff ("RDMA/mlx5: Don't add slave port to unaffiliated list") Link: https://lore.kernel.org/r/899ac1b33a995be5ec0e16a4765c4e43c2b1ba5b.1624956444.git.leonro@nvidia.com Reviewed-by: Itay Aveksis Reviewed-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 420451e090ee7667b10b5232c58a9e72607f732e Author: Menglong Dong Date: Sun Jun 27 23:37:44 2021 -0700 net: tipc: fix FB_MTU eat two pages [ Upstream commit 0c6de0c943dbb42831bf7502eb5c007f71e752d2 ] FB_MTU is used in 'tipc_msg_build()' to alloc smaller skb when memory allocation fails, which can avoid unnecessary sending failures. The value of FB_MTU now is 3744, and the data size will be: (3744 + SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) + \ SKB_DATA_ALIGN(BUF_HEADROOM + BUF_TAILROOM + 3)) which is larger than one page(4096), and two pages will be allocated. To avoid it, replace '3744' with a calculation: (PAGE_SIZE - SKB_DATA_ALIGN(BUF_OVERHEAD) - \ SKB_DATA_ALIGN(sizeof(struct skb_shared_info))) What's more, alloc_skb_fclone() will call SKB_DATA_ALIGN for data size, and it's not necessary to make alignment for buf_size in tipc_buf_acquire(). So, just remove it. Fixes: 4c94cc2d3d57 ("tipc: fall back to smaller MTU if allocation of local send skb fails") Signed-off-by: Menglong Dong Acked-by: Jon Maloy Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 281c4b33035b492c7d0f809ad1e927459ba95d31 Author: Pavel Skripkin Date: Fri Jun 25 23:23:48 2021 +0300 net: sched: fix warning in tcindex_alloc_perfect_hash [ Upstream commit 3f2db250099f46988088800052cdf2332c7aba61 ] Syzbot reported warning in tcindex_alloc_perfect_hash. The problem was in too big cp->hash, which triggers warning in kmalloc. Since cp->hash comes from userspace, there is no need to warn if value is not correct Fixes: b9a24bb76bf6 ("net_sched: properly handle failure case of tcf_exts_init()") Reported-and-tested-by: syzbot+1071ad60cd7df39fdadb@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin Acked-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 37287acdae7792acfc4995eb7f9d99a28c9323c1 Author: Vadim Fedorenko Date: Fri Jun 25 19:21:39 2021 +0300 net: lwtunnel: handle MTU calculation in forwading [ Upstream commit fade56410c22cacafb1be9f911a0afd3701d8366 ] Commit 14972cbd34ff ("net: lwtunnel: Handle fragmentation") moved fragmentation logic away from lwtunnel by carry encap headroom and use it in output MTU calculation. But the forwarding part was not covered and created difference in MTU for output and forwarding and further to silent drops on ipv4 forwarding path. Fix it by taking into account lwtunnel encap headroom. The same commit also introduced difference in how to treat RTAX_MTU in IPv4 and IPv6 where latter explicitly removes lwtunnel encap headroom from route MTU. Make IPv4 version do the same. Fixes: 14972cbd34ff ("net: lwtunnel: Handle fragmentation") Suggested-by: David Ahern Signed-off-by: Vadim Fedorenko Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit cae2f265c5a94019caf25019be946fd46a11aeff Author: Muchun Song Date: Fri Apr 2 17:11:45 2021 +0800 writeback: fix obtain a reference to a freeing memcg css [ Upstream commit 8b0ed8443ae6458786580d36b7d5f8125535c5d4 ] The caller of wb_get_create() should pin the memcg, because wb_get_create() relies on this guarantee. The rcu read lock only can guarantee that the memcg css returned by css_from_id() cannot be released, but the reference of the memcg can be zero. rcu_read_lock() memcg_css = css_from_id() wb_get_create(memcg_css) cgwb_create(memcg_css) // css_get can change the ref counter from 0 back to 1 css_get(memcg_css) rcu_read_unlock() Fix it by holding a reference to the css before calling wb_get_create(). This is not a problem I encountered in the real world. Just the result of a code review. Fixes: 682aa8e1a6a1 ("writeback: implement unlocked_inode_to_wb transaction and use it for stat updates") Link: https://lore.kernel.org/r/20210402091145.80635-1-songmuchun@bytedance.com Signed-off-by: Muchun Song Acked-by: Michal Hocko Acked-by: Tejun Heo Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 6eeb73fa1492a66a8c095bf69aa3355d2430e4b0 Author: Ravi Bangoria Date: Tue Jun 22 16:30:26 2021 +0530 bpf, x86: Fix extable offset calculation [ Upstream commit 328aac5ecd119ede3633f7d17969b1ff34ccc784 ] Commit 4c5de127598e1 ("bpf: Emit explicit NULL pointer checks for PROBE_LDX instructions.") is emitting a couple of instructions before the actual load. Consider those additional instructions while calculating extable offset. Fixes: 4c5de127598e1 ("bpf: Emit explicit NULL pointer checks for PROBE_LDX instructions.") Signed-off-by: Ravi Bangoria Signed-off-by: Alexei Starovoitov Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20210622110026.1157847-1-ravi.bangoria@linux.ibm.com Signed-off-by: Sasha Levin commit 514795d6fb842d21252145ef40b2c5755d361f15 Author: Robert Hancock Date: Thu Mar 25 13:26:39 2021 -0600 clk: si5341: Update initialization magic [ Upstream commit 3c9b49b0031aefb81adfdba5ab0ddf3ca3a2cdc9 ] Update the default register settings to include the VCO_RESET_CALCODE settings (set by the SiLabs ClockBuilder software but not described in the datasheet). Also update part of the initialization sequence to match ClockBuilder and the datasheet. Fixes: 3044a860fd ("clk: Add Si5341/Si5340 driver") Signed-off-by: Robert Hancock Link: https://lore.kernel.org/r/20210325192643.2190069-6-robert.hancock@calian.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 2f19f9ef84c213c9b52859ad2178d6cbfd22ae8b Author: Robert Hancock Date: Thu Mar 25 13:26:38 2021 -0600 clk: si5341: Check for input clock presence and PLL lock on startup [ Upstream commit 71dcc4d1f7d2ad97ff7ab831281bc6893ff713a2 ] After initializing the device, wait for it to report that the input clock is present and the PLL has locked before declaring success. Fixes: 3044a860fd ("clk: Add Si5341/Si5340 driver") Signed-off-by: Robert Hancock Link: https://lore.kernel.org/r/20210325192643.2190069-5-robert.hancock@calian.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit f09f20dc21b2cab86477991587e3114cce0351e6 Author: Robert Hancock Date: Thu Mar 25 13:26:37 2021 -0600 clk: si5341: Avoid divide errors due to bogus register contents [ Upstream commit 78f6f406026d688868223d5dbeb197a4f7e9a9fd ] If the Si5341 is being initially programmed and has no stored NVM configuration, some of the register contents may contain unexpected values, such as zeros, which could cause divide by zero errors during driver initialization. Trap errors caused by zero registers or zero clock rates which could result in divide errors later in the code. Fixes: 3044a860fd ("clk: Add Si5341/Si5340 driver") Signed-off-by: Robert Hancock Link: https://lore.kernel.org/r/20210325192643.2190069-4-robert.hancock@calian.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 91a1de176b941fcbcff9d4573411b2df8a22d228 Author: Robert Hancock Date: Thu Mar 25 13:26:36 2021 -0600 clk: si5341: Wait for DEVICE_READY on startup [ Upstream commit 6e7d2de1e000d36990923ed80d2e78dfcb545cee ] The Si5341 datasheet warns that before accessing any other registers, including the PAGE register, we need to wait for the DEVICE_READY register to indicate the device is ready, or the process of the device loading its state from NVM can be corrupted. Wait for DEVICE_READY on startup before continuing initialization. This is done using a raw I2C register read prior to setting up regmap to avoid any potential unwanted automatic PAGE register accesses from regmap at this stage. Fixes: 3044a860fd ("clk: Add Si5341/Si5340 driver") Signed-off-by: Robert Hancock Link: https://lore.kernel.org/r/20210325192643.2190069-3-robert.hancock@calian.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 884a3988922881037c581941f3f144a3fbdead15 Author: Jonathan Marek Date: Tue Jun 8 22:28:52 2021 -0400 clk: qcom: clk-alpha-pll: fix CAL_L write in alpha_pll_fabia_prepare [ Upstream commit 7f54bf2640e877c8a9b4cc7e2b29f82e3ca1a284 ] Caught this when looking at alpha-pll code. Untested but it is clear that this was intended to write to PLL_CAL_L_VAL and not PLL_ALPHA_VAL. Fixes: 691865bad627 ("clk: qcom: clk-alpha-pll: Add support for Fabia PLL calibration") Signed-off-by: Jonathan Marek Link: https://lore.kernel.org/r/20210609022852.4151-1-jonathan@marek.ca Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 39468899710a3aa7180295abe31862618f15c1dc Author: Cristian Ciocaltea Date: Thu Jun 10 23:05:24 2021 +0300 clk: actions: Fix AHPPREDIV-H-AHB clock chain on Owl S500 SoC [ Upstream commit fd90b5b9045274360b12cea0f2ce50f3bcfb25cc ] There are a few issues with the setup of the Actions Semi Owl S500 SoC's clock chain involving AHPPREDIV, H and AHB clocks: * AHBPREDIV clock is defined as a muxer only, although it also acts as a divider. * H clock is using a wrong divider register offset * AHB is defined as a multi-rate factor clock, but it is actually just a fixed pass clock. Let's provide the following fixes: * Change AHBPREDIV clock to an ungated OWL_COMP_DIV definition. * Use the correct register shift value in the OWL_DIVIDER definition for H clock * Drop the unneeded 'ahb_factor_table[]' and change AHB clock to an ungated OWL_COMP_FIXED_FACTOR definition. Fixes: ed6b4795ece4 ("clk: actions: Add clock driver for S500 SoC") Signed-off-by: Cristian Ciocaltea Link: https://lore.kernel.org/r/21c1abd19a7089b65a34852ac6513961be88cbe1.1623354574.git.cristian.ciocaltea@gmail.com Reviewed-by: Manivannan Sadhasivam Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit bb4367cc37221c137da3b60e94355396beb3df43 Author: Cristian Ciocaltea Date: Thu Jun 10 23:05:23 2021 +0300 clk: actions: Fix bisp_factor_table based clocks on Owl S500 SoC [ Upstream commit a8f1f03caa51aa7a69c671aa87c475034db7d368 ] The following clocks of the Actions Semi Owl S500 SoC have been defined to use a shared clock factor table 'bisp_factor_table[]': DE[1-2], VCE, VDE, BISP, SENSOR[0-1] There are several issues involved in this approach: * 'bisp_factor_table[]' describes the configuration of a regular 8-rates divider, so its usage is redundant. Additionally, judging by the BISP clock context, it is incomplete since it maps only 8 out of 12 possible entries. * The clocks mentioned above are not identical in terms of the available rates, therefore cannot rely on the same factor table. Specifically, BISP and SENSOR* are standard 12-rate dividers so their configuration should rely on a proper clock div table, while VCE and VDE require a factor table that is a actually a subset of the one needed for DE[1-2] clocks. Let's fix this by implementing the following: * Add new factor tables 'de_factor_table' and 'hde_factor_table' to properly handle DE[1-2], VCE and VDE clocks. * Add a common div table 'std12rate_div_table' for BISP and SENSOR[0-1] clocks converted to OWL_COMP_DIV. * Drop the now unused 'bisp_factor_table[]'. Additionally, drop the CLK_IGNORE_UNUSED flag for SENSOR[0-1] since there is no reason to always keep ON those clocks. Fixes: ed6b4795ece4 ("clk: actions: Add clock driver for S500 SoC") Signed-off-by: Cristian Ciocaltea Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/e675820a46cd9930d8d576c6cae61d41c1a8416f.1623354574.git.cristian.ciocaltea@gmail.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 7f8d9cca344fa0a098e7a74f424cb7fccf406eb1 Author: Cristian Ciocaltea Date: Thu Jun 10 23:05:22 2021 +0300 clk: actions: Fix SD clocks factor table on Owl S500 SoC [ Upstream commit fe1f71e338d77814da3ef44e9f64d32981a6ccdf ] Drop the unsupported entries in the factor table used for the SD[0-2] clocks definitions on the Actions Semi Owl S500 SoC. Fixes: ed6b4795ece4 ("clk: actions: Add clock driver for S500 SoC") Signed-off-by: Cristian Ciocaltea Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/196c948d708a22b8198c95f064a0f6b6820f9980.1623354574.git.cristian.ciocaltea@gmail.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 059f4c4ca01e6d8f7f0a82d532350ef7a8494594 Author: Cristian Ciocaltea Date: Thu Jun 10 23:05:21 2021 +0300 clk: actions: Fix UART clock dividers on Owl S500 SoC [ Upstream commit 2dca2a619a907579e3e65e7c1789230c2b912e88 ] Use correct divider registers for the Actions Semi Owl S500 SoC's UART clocks. Fixes: ed6b4795ece4 ("clk: actions: Add clock driver for S500 SoC") Signed-off-by: Cristian Ciocaltea Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/4714d05982b19ac5fec2ed74f54be42d8238e392.1623354574.git.cristian.ciocaltea@gmail.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 51c2a6cd472a70f0281ef7ce7178f2560b37dc7e Author: Taniya Das Date: Wed Jun 23 17:27:51 2021 +0530 clk: qcom: gcc: Add support for a new frequency for SC7280 [ Upstream commit ca1c667f4be935825fffb232a106c9d3f1c09b0b ] There is a requirement to support 52MHz for qup clocks for bluetooth usecase, thus update the frequency table to support the frequency. Fixes: a3cc092196ef ("clk: qcom: Add Global Clock controller (GCC) driver for SC7280") Signed-off-by: Taniya Das Link: https://lore.kernel.org/r/1624449471-9984-1-git-send-email-tdas@codeaurora.org Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 4c41eceb422ba8da29804cf8465506ae51fe7fc4 Author: Luiz Augusto von Dentz Date: Tue Jun 22 20:59:02 2021 -0700 Bluetooth: Fix handling of HCI_LE_Advertising_Set_Terminated event [ Upstream commit 23837a6d7a1a61818ed94a6b8af552d6cf7d32d5 ] Error status of this event means that it has ended due reasons other than a connection: 'If advertising has terminated as a result of the advertising duration elapsing, the Status parameter shall be set to the error code Advertising Timeout (0x3C).' 'If advertising has terminated because the Max_Extended_Advertising_Events was reached, the Status parameter shall be set to the error code Limit Reached (0x43).' Fixes: acf0aeae431a0 ("Bluetooth: Handle ADv set terminated event") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 606c3bdfa66ad41fa029dc81f5b5029ee599996b Author: Luiz Augusto von Dentz Date: Wed Jun 9 11:09:27 2021 -0700 Bluetooth: Fix Set Extended (Scan Response) Data [ Upstream commit c9ed0a7077306f9d41d74fb006ab5dbada8349c5 ] These command do have variable length and the length can go up to 251, so this changes the struct to not use a fixed size and then when creating the PDU only the actual length of the data send to the controller. Fixes: a0fb3726ba551 ("Bluetooth: Use Set ext adv/scan rsp data if controller supports") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 077f680b0e36e4968b3779dbb790c8d442b0c30b Author: Luiz Augusto von Dentz Date: Fri May 28 11:45:02 2021 -0700 Bluetooth: mgmt: Fix slab-out-of-bounds in tlv_data_is_valid [ Upstream commit 799acb9347915bfe4eac0ff2345b468f0a1ca207 ] This fixes parsing of LTV entries when the length is 0. Found with: tools/mgmt-tester -s "Add Advertising - Success (ScRsp only)" Add Advertising - Success (ScRsp only) - run Sending Add Advertising (0x003e) Test condition added, total 1 [ 11.004577] ================================================================== [ 11.005292] BUG: KASAN: slab-out-of-bounds in tlv_data_is_valid+0x87/0xe0 [ 11.005984] Read of size 1 at addr ffff888002c695b0 by task mgmt-tester/87 [ 11.006711] [ 11.007176] [ 11.007429] Allocated by task 87: [ 11.008151] [ 11.008438] The buggy address belongs to the object at ffff888002c69580 [ 11.008438] which belongs to the cache kmalloc-64 of size 64 [ 11.010526] The buggy address is located 48 bytes inside of [ 11.010526] 64-byte region [ffff888002c69580, ffff888002c695c0) [ 11.012423] The buggy address belongs to the page: [ 11.013291] [ 11.013544] Memory state around the buggy address: [ 11.014359] ffff888002c69480: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc [ 11.015453] ffff888002c69500: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc [ 11.016232] >ffff888002c69580: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc [ 11.017010] ^ [ 11.017547] ffff888002c69600: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc [ 11.018296] ffff888002c69680: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc [ 11.019116] ================================================================== Fixes: 2bb36870e8cb2 ("Bluetooth: Unify advertising instance flags check") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 3b760a0a24c780d7c9098846ebe33c5727888a04 Author: Colin Ian King Date: Fri Apr 9 17:53:14 2021 +0100 Bluetooth: virtio_bt: add missing null pointer check on alloc_skb call return [ Upstream commit 1cb027f2f803d0a7abe9c291f0625e6bccd25999 ] The call to alloc_skb with the GFP_KERNEL flag can return a null sk_buff pointer, so add a null check to avoid any null pointer deference issues. Addresses-Coverity: ("Dereference null return value") Fixes: afd2daa26c7a ("Bluetooth: Add support for virtio transport driver") Signed-off-by: Colin Ian King Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit bed9525b9322a441fa2069696b188dabb0fb68a6 Author: Michal Simek Date: Tue Jun 22 12:15:11 2021 +0200 clk: zynqmp: fix compile testing without ZYNQMP_FIRMWARE [ Upstream commit 6c9feabc2c6bd49abbd2130341e7cb91f42d3fa5 ] When the firmware code is disabled, the incomplete error handling in the clk driver causes compile-time warnings: drivers/clk/zynqmp/pll.c: In function 'zynqmp_pll_recalc_rate': drivers/clk/zynqmp/pll.c:147:29: error: 'fbdiv' is used uninitialized [-Werror=uninitialized] 147 | rate = parent_rate * fbdiv; | ~~~~~~~~~~~~^~~~~~~ In function 'zynqmp_pll_get_mode', inlined from 'zynqmp_pll_recalc_rate' at drivers/clk/zynqmp/pll.c:148:6: drivers/clk/zynqmp/pll.c:61:27: error: 'ret_payload' is used uninitialized [-Werror=uninitialized] 61 | return ret_payload[1]; | ~~~~~~~~~~~^~~ drivers/clk/zynqmp/pll.c: In function 'zynqmp_pll_recalc_rate': drivers/clk/zynqmp/pll.c:53:13: note: 'ret_payload' declared here 53 | u32 ret_payload[PAYLOAD_ARG_CNT]; | ^~~~~~~~~~~ drivers/clk/zynqmp/clk-mux-zynqmp.c: In function 'zynqmp_clk_mux_get_parent': drivers/clk/zynqmp/clk-mux-zynqmp.c:57:16: error: 'val' is used uninitialized [-Werror=uninitialized] 57 | return val; | ^~~ As it was apparently intentional to support this for compile testing purposes, change the code to have just enough error handling for the compiler to not notice the remaining bugs. Fixes: 21f237534661 ("clk: zynqmp: Drop dependency on ARCH_ZYNQMP") Co-developed-by: Arnd Bergmann Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/f1c4e8c903fe2d5df5413421920a56890a46387a.1624356908.git.michal.simek@xilinx.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 5fe0ca3d5d9219dfef16a31a52c15591c88b8653 Author: Petr Oros Date: Fri Jun 25 10:27:45 2021 +0200 Revert "be2net: disable bh with spin_lock in be_process_mcc" [ Upstream commit d6765985a42a660f078896d5c5b27f97c580a490 ] Patch was based on wrong presumption that be_poll can be called only from bh context. It reintroducing old regression (also reverted) and causing deadlock when we use netconsole with benet in bonding. Old revert: commit 072a9c486004 ("netpoll: revert 6bdb7fe3104 and fix be_poll() instead") [ 331.269715] bond0: (slave enp0s7f0): Releasing backup interface [ 331.270121] CPU: 4 PID: 1479 Comm: ifenslave Not tainted 5.13.0-rc7+ #2 [ 331.270122] Call Trace: [ 331.270122] [c00000001789f200] [c0000000008c505c] dump_stack+0x100/0x174 (unreliable) [ 331.270124] [c00000001789f240] [c008000001238b9c] be_poll+0x64/0xe90 [be2net] [ 331.270125] [c00000001789f330] [c000000000d1e6e4] netpoll_poll_dev+0x174/0x3d0 [ 331.270127] [c00000001789f400] [c008000001bc167c] bond_poll_controller+0xb4/0x130 [bonding] [ 331.270128] [c00000001789f450] [c000000000d1e624] netpoll_poll_dev+0xb4/0x3d0 [ 331.270129] [c00000001789f520] [c000000000d1ed88] netpoll_send_skb+0x448/0x470 [ 331.270130] [c00000001789f5d0] [c0080000011f14f8] write_msg+0x180/0x1b0 [netconsole] [ 331.270131] [c00000001789f640] [c000000000230c0c] console_unlock+0x54c/0x790 [ 331.270132] [c00000001789f7b0] [c000000000233098] vprintk_emit+0x2d8/0x450 [ 331.270133] [c00000001789f810] [c000000000234758] vprintk+0xc8/0x270 [ 331.270134] [c00000001789f850] [c000000000233c28] printk+0x40/0x54 [ 331.270135] [c00000001789f870] [c000000000ccf908] __netdev_printk+0x150/0x198 [ 331.270136] [c00000001789f910] [c000000000ccfdb4] netdev_info+0x68/0x94 [ 331.270137] [c00000001789f950] [c008000001bcbd70] __bond_release_one+0x188/0x6b0 [bonding] [ 331.270138] [c00000001789faa0] [c008000001bcc6f4] bond_do_ioctl+0x42c/0x490 [bonding] [ 331.270139] [c00000001789fb60] [c000000000d0d17c] dev_ifsioc+0x17c/0x400 [ 331.270140] [c00000001789fbc0] [c000000000d0db70] dev_ioctl+0x390/0x890 [ 331.270141] [c00000001789fc10] [c000000000c7c76c] sock_do_ioctl+0xac/0x1b0 [ 331.270142] [c00000001789fc90] [c000000000c7ffac] sock_ioctl+0x31c/0x6e0 [ 331.270143] [c00000001789fd60] [c0000000005b9728] sys_ioctl+0xf8/0x150 [ 331.270145] [c00000001789fdb0] [c0000000000336c0] system_call_exception+0x160/0x2f0 [ 331.270146] [c00000001789fe10] [c00000000000d35c] system_call_common+0xec/0x278 [ 331.270147] --- interrupt: c00 at 0x7fffa6c6ec00 [ 331.270147] NIP: 00007fffa6c6ec00 LR: 0000000105c4185c CTR: 0000000000000000 [ 331.270148] REGS: c00000001789fe80 TRAP: 0c00 Not tainted (5.13.0-rc7+) [ 331.270148] MSR: 800000000280f033 CR: 28000428 XER: 00000000 [ 331.270155] IRQMASK: 0 [ 331.270156] GPR00: 0000000000000036 00007fffd494d5b0 00007fffa6d57100 0000000000000003 [ 331.270158] GPR04: 0000000000008991 00007fffd494d6d0 0000000000000008 00007fffd494f28c [ 331.270161] GPR08: 0000000000000003 0000000000000000 0000000000000000 0000000000000000 [ 331.270164] GPR12: 0000000000000000 00007fffa6dfa220 0000000000000000 0000000000000000 [ 331.270167] GPR16: 0000000105c44880 0000000000000000 0000000105c60088 0000000105c60318 [ 331.270170] GPR20: 0000000105c602c0 0000000105c44560 0000000000000000 0000000000000000 [ 331.270172] GPR24: 00007fffd494dc50 00007fffd494d6a8 0000000105c60008 00007fffd494d6d0 [ 331.270175] GPR28: 00007fffd494f27e 0000000105c6026c 00007fffd494f284 0000000000000000 [ 331.270178] NIP [00007fffa6c6ec00] 0x7fffa6c6ec00 [ 331.270178] LR [0000000105c4185c] 0x105c4185c [ 331.270179] --- interrupt: c00 This reverts commit d0d006a43e9a7a796f6f178839c92fcc222c564d. Fixes: d0d006a43e9a7a ("be2net: disable bh with spin_lock in be_process_mcc") Signed-off-by: Petr Oros Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 51a36dde7aa5d8743979701436e3f7382a93f996 Author: Bailey Forrest Date: Thu Jun 24 19:55:41 2021 -0700 gve: Fix swapped vars when fetching max queues [ Upstream commit 1db1a862a08f85edc36aad091236ac9b818e949e ] Fixes: 893ce44df565 ("gve: Add basic driver framework for Compute Engine Virtual NIC") Signed-off-by: Bailey Forrest Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 58faaa992dee2a4153e4d15ea98ae5e5ca97a98f Author: Håkon Bugge Date: Tue Jun 22 16:13:27 2021 +0200 RDMA/cma: Fix incorrect Packet Lifetime calculation [ Upstream commit e84045eab69c625bc0b0bf24d8e05bc65da1eed1 ] An approximation for the PacketLifeTime is half the local ACK timeout. The encoding for both timers are logarithmic. If the local ACK timeout is set, but zero, it means the timer is disabled. In this case, we choose the CMA_IBOE_PACKET_LIFETIME value, since 50% of infinite makes no sense. Before this commit, the PacketLifeTime became 255 if local ACK timeout was zero (not running). Fixed by explicitly testing for timeout being zero. Fixes: e1ee1e62bec4 ("RDMA/cma: Use ACK timeout for RoCE packetLifeTime") Link: https://lore.kernel.org/r/1624371207-26710-1-git-send-email-haakon.bugge@oracle.com Signed-off-by: Håkon Bugge Reviewed-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 2eddafd7ec46f267a36c0c32f9ab6738097847d2 Author: Gary Lin Date: Wed Jun 23 12:09:18 2021 +0800 bpfilter: Specify the log level for the kmsg message [ Upstream commit a196fa78a26571359740f701cf30d774eb8a72cb ] Per the kmsg document [0], if we don't specify the log level with a prefix "" in the message string, the default log level will be applied to the message. Since the default level could be warning(4), this would make the log utility such as journalctl treat the message, "Started bpfilter", as a warning. To avoid confusion, this commit adds the prefix "<5>" to make the message always a notice. [0] https://www.kernel.org/doc/Documentation/ABI/testing/dev-kmsg Fixes: 36c4357c63f3 ("net: bpfilter: print umh messages to /dev/kmsg") Reported-by: Martin Loviska Signed-off-by: Gary Lin Signed-off-by: Daniel Borkmann Acked-by: Dmitrii Banshchikov Link: https://lore.kernel.org/bpf/20210623040918.8683-1-glin@suse.com Signed-off-by: Sasha Levin commit 9c34dfa6f036258bd3cc6bbaa4798dc80db59c96 Author: Vladimir Oltean Date: Thu Jun 24 18:52:07 2021 +0300 net: dsa: sja1105: fix NULL pointer dereference in sja1105_reload_cbs() [ Upstream commit be7f62eebaff2f86c1467a2d33930a0a7a87675b ] priv->cbs is an array of priv->info->num_cbs_shapers elements of type struct sja1105_cbs_entry which only get allocated if CONFIG_NET_SCH_CBS is enabled. However, sja1105_reload_cbs() is called from sja1105_static_config_reload() which in turn is called for any of the items in sja1105_reset_reasons, therefore during the normal runtime of the driver and not just from a code path which can be triggered by the tc-cbs offload. The sja1105_reload_cbs() function does not contain a check whether the priv->cbs array is NULL or not, it just assumes it isn't and proceeds to iterate through the credit-based shaper elements. This leads to a NULL pointer dereference. The solution is to return success if the priv->cbs array has not been allocated, since sja1105_reload_cbs() has nothing to do. Fixes: 4d7525085a9b ("net: dsa: sja1105: offload the Credit-Based Shaper qdisc") Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f6bb341b08ae35a119748c195768c4bad9b50969 Author: Sasha Neftin Date: Thu Jun 24 12:02:48 2021 -0700 e1000e: Check the PCIm state [ Upstream commit 2e7256f12cdb16eaa2515b6231d665044a07c51a ] Complete to commit def4ec6dce393e ("e1000e: PCIm function state support") Check the PCIm state only on CSME systems. There is no point to do this check on non CSME systems. This patch fixes a generation a false-positive warning: "Error in exiting dmoff" Fixes: def4ec6dce39 ("e1000e: PCIm function state support") Signed-off-by: Sasha Neftin Tested-by: Dvora Fuxbrumer Signed-off-by: Tony Nguyen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f5311a0c02aa4a53017324735dd6ff7195a8f322 Author: Eric Dumazet Date: Thu Jun 24 03:07:20 2021 -0700 ipv6: fix out-of-bound access in ip6_parse_tlv() [ Upstream commit 624085a31c1ad6a80b1e53f686bf6ee92abbf6e8 ] First problem is that optlen is fetched without checking there is more than one byte to parse. Fix this by taking care of IPV6_TLV_PAD1 before fetching optlen (under appropriate sanity checks against len) Second problem is that IPV6_TLV_PADN checks of zero padding are performed before the check of remaining length. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: c1412fce7ecc ("net/ipv6/exthdrs.c: Strict PadN option checking") Signed-off-by: Eric Dumazet Cc: Paolo Abeni Cc: Tom Herbert Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 710f87cb04f9929b7ffb9c0551c1554a7645c9c5 Author: Antoine Tenart Date: Thu Jun 24 11:38:30 2021 +0200 net: atlantic: fix the macsec key length [ Upstream commit d67fb4772d9a6cfd10f1109f0e7b1e6eb58c8e16 ] The key length used to store the macsec key was set to MACSEC_KEYID_LEN (16), which is an issue as: - This was never meant to be the key length. - The key length can be > 16. Fix this by using MACSEC_MAX_KEY_LEN instead (the max length accepted in uAPI). Fixes: 27736563ce32 ("net: atlantic: MACSec egress offload implementation") Fixes: 9ff40a751a6f ("net: atlantic: MACSec ingress offload implementation") Reported-by: Lior Nahmanson Signed-off-by: Antoine Tenart Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d22eadd94ca5a50e8f1acbc54bc72af456b00ec4 Author: Antoine Tenart Date: Thu Jun 24 11:38:29 2021 +0200 net: phy: mscc: fix macsec key length [ Upstream commit c309217f91f2d2097c2a0a832d9bff50b88c81dc ] The key length used to store the macsec key was set to MACSEC_KEYID_LEN (16), which is an issue as: - This was never meant to be the key length. - The key length can be > 16. Fix this by using MACSEC_MAX_KEY_LEN instead (the max length accepted in uAPI). Fixes: 28c5107aa904 ("net: phy: mscc: macsec support") Reported-by: Lior Nahmanson Signed-off-by: Antoine Tenart Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 70521208f6ce38ed82c8f27b35389d41582e831c Author: Antoine Tenart Date: Thu Jun 24 11:38:28 2021 +0200 net: macsec: fix the length used to copy the key for offloading [ Upstream commit 1f7fe5121127e037b86592ba42ce36515ea0e3f7 ] The key length used when offloading macsec to Ethernet or PHY drivers was set to MACSEC_KEYID_LEN (16), which is an issue as: - This was never meant to be the key length. - The key length can be > 16. Fix this by using MACSEC_MAX_KEY_LEN to store the key (the max length accepted in uAPI) and secy->key_len to copy it. Fixes: 3cf3227a21d1 ("net: macsec: hardware offloading infrastructure") Reported-by: Lior Nahmanson Signed-off-by: Antoine Tenart Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1e3b94af52bf0217cbcb29046509d83666043d81 Author: Håkon Bugge Date: Tue Jun 22 15:39:57 2021 +0200 RDMA/cma: Protect RMW with qp_mutex [ Upstream commit ca0c448d2b9f43e3175835d536853854ef544e22 ] The struct rdma_id_private contains three bit-fields, tos_set, timeout_set, and min_rnr_timer_set. These are set by accessor functions without any synchronization. If two or all accessor functions are invoked in close proximity in time, there will be Read-Modify-Write from several contexts to the same variable, and the result will be intermittent. Fixed by protecting the bit-fields by the qp_mutex in the accessor functions. The consumer of timeout_set and min_rnr_timer_set is in rdma_init_qp_attr(), which is called with qp_mutex held for connected QPs. Explicit locking is added for the consumers of tos and tos_set. This commit depends on ("RDMA/cma: Remove unnecessary INIT->INIT transition"), since the call to rdma_init_qp_attr() from cma_init_conn_qp() does not hold the qp_mutex. Fixes: 2c1619edef61 ("IB/cma: Define option to set ack timeout and pack tos_set") Fixes: 3aeffc46afde ("IB/cma: Introduce rdma_set_min_rnr_timer()") Link: https://lore.kernel.org/r/1624369197-24578-3-git-send-email-haakon.bugge@oracle.com Signed-off-by: Håkon Bugge Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 3e174152dfb9459729f27290ddde592a3aa72a1e Author: Sukadev Bhattiprolu Date: Wed Jun 23 21:13:15 2021 -0700 ibmvnic: free tx_pool if tso_pool alloc fails [ Upstream commit f6ebca8efa52e4ae770f0325d618e7bcf08ada0c ] Free tx_pool and clear it, if allocation of tso_pool fails. release_tx_pools() assumes we have both tx and tso_pools if ->tx_pool is non-NULL. If allocation of tso_pool fails in init_tx_pools(), the assumption will not be true and we would end up dereferencing ->tx_buff, ->free_map fields from a NULL pointer. Fixes: 3205306c6b8d ("ibmvnic: Update TX pool initialization routine") Signed-off-by: Sukadev Bhattiprolu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ca854faf0b85397180f74baa3409727338f46e05 Author: Sukadev Bhattiprolu Date: Wed Jun 23 21:13:14 2021 -0700 ibmvnic: set ltb->buff to NULL after freeing [ Upstream commit 552a33729f1a7cc5115d0752064fe9abd6e3e336 ] free_long_term_buff() checks ltb->buff to decide whether we have a long term buffer to free. So set ltb->buff to NULL afer freeing. While here, also clear ->map_id, fix up some coding style and log an error. Fixes: 9c4eaabd1bb39 ("Check CRQ command return codes") Signed-off-by: Sukadev Bhattiprolu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 781b69c0d216ba98e395252c88c628cfafef07b5 Author: Sukadev Bhattiprolu Date: Wed Jun 23 21:13:13 2021 -0700 ibmvnic: account for bufs already saved in indir_buf [ Upstream commit 72368f8b2b9e4106072a2728bed3367d54641c22 ] This fixes a crash in replenish_rx_pool() when called from ibmvnic_poll() after a previous call to replenish_rx_pool() encountered an error when allocating a socket buffer. Thanks to Rick Lindsley and Dany Madden for helping debug the crash. Fixes: 4f0b6812e9b9 ("ibmvnic: Introduce batched RX buffer descriptor transmission") Signed-off-by: Sukadev Bhattiprolu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5142c39253385702a4de8f897027e1d76fc333de Author: Sukadev Bhattiprolu Date: Wed Jun 23 21:13:12 2021 -0700 ibmvnic: clean pending indirect buffs during reset [ Upstream commit 65d6470d139a6c1655fccb5cbacbeaba8e8ad2f8 ] We batch subordinate command response queue (scrq) descriptors that we need to send to the VIOS using an "indirect" buffer. If after we queue one or more scrqs in the indirect buffer encounter an error (say fail to allocate an skb), we leave the queued scrq descriptors in the indirect buffer until the next call to ibmvnic_xmit(). On the next call to ibmvnic_xmit(), it is possible that the adapter is going through a reset and it is possible that the long term buffers have been unmapped on the VIOS side. If we proceed to flush (send) the packets that are in the indirect buffer, we will end up using the old map ids and this can cause the VIOS to trigger an unnecessary FATAL error reset. Instead of flushing packets remaining on the indirect_buff, discard (clean) them instead. Fixes: 0d973388185d4 ("ibmvnic: Introduce xmit_more support using batched subCRQ hcalls") Signed-off-by: Sukadev Bhattiprolu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit eacd61111d91157bfab8b3fd1ecb4e3e6de9cceb Author: Dany Madden Date: Wed Jun 23 21:13:11 2021 -0700 Revert "ibmvnic: remove duplicate napi_schedule call in open function" [ Upstream commit 2ca220f92878470c6ba03f9946e412323093cc94 ] This reverts commit 7c451f3ef676c805a4b77a743a01a5c21a250a73. When a vnic interface is taken down and then up, connectivity is not restored. We bisected it to this commit. Reverting this commit until we can fully investigate the issue/benefit of the change. Fixes: 7c451f3ef676 ("ibmvnic: remove duplicate napi_schedule call in open function") Reported-by: Cristobal Forno Reported-by: Abdul Haleem Signed-off-by: Dany Madden Signed-off-by: Sukadev Bhattiprolu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e7f3c4348fb17df6faa66fac5e4feaed3b6dc614 Author: Sukadev Bhattiprolu Date: Wed Jun 23 21:13:10 2021 -0700 Revert "ibmvnic: simplify reset_long_term_buff function" [ Upstream commit 0ec13aff058a82426c8d44b688c804cc4a5a0a3d ] This reverts commit 1c7d45e7b2c29080bf6c8cd0e213cc3cbb62a054. We tried to optimize the number of hcalls we send and skipped sending the REQUEST_MAP calls for some maps. However during resets, we need to resend all the maps to the VIOS since the VIOS does not remember the old values. In fact we may have failed over to a new VIOS which will not have any of the mappings. When we send packets with map ids the VIOS does not know about, it triggers a FATAL reset. While the client does recover from the FATAL error reset, we are seeing a large number of such resets. Handling FATAL resets is lot more unnecessary work than issuing a few more hcalls so revert the commit and resend the maps to the VIOS. Fixes: 1c7d45e7b2c ("ibmvnic: simplify reset_long_term_buff function") Signed-off-by: Sukadev Bhattiprolu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8b09cfd020cf9d3d1ed5f53b2118f0d03ebc0d65 Author: Yixing Liu Date: Tue Jun 22 20:16:03 2021 +0800 RDMA/hns: Add window selection field of congestion control [ Upstream commit 7ae61c5f16671ecaf23526feb6892c8249d0c2d7 ] The window selection field is necessary for congestion control of HIP09, it is got from firmware and then filled into QPC. Some algorithms need it to decide whether to limit the number of windows. Fixes: f91696f2f053 ("RDMA/hns: Support congestion control type selection according to the FW") Link: https://lore.kernel.org/r/1624364163-44185-1-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 f067cd951611306aa572063a601926e1cd50acc3 Author: Weihang Li Date: Mon Jun 21 16:00:36 2021 +0800 RDMA/hns: Add a check to ensure integer mtu is positive [ Upstream commit fe331da0f210c60342b042a03fe53f1b564b412b ] GCC may reports an running time assert error when a value calculated from ib_mtu_enum_to_int() is using as 'val' in FIELD_PREDP: include/linux/compiler_types.h:328:38: error: call to '__compiletime_assert_1524' declared with attribute error: FIELD_PREP: value too large for the field So a check is added about whether integer mtu from ib_mtu_enum_to_int() is negative to avoid this warning. Link: https://lore.kernel.org/r/1624262443-24528-3-git-send-email-liweihang@huawei.com Reported-by: kernel test robot Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 8853324cd846f77cef01ed75aa709955ff5a18b9 Author: Jan Sokolowski Date: Fri Jun 11 12:01:41 2021 +0200 i40e: Fix missing rtnl locking when setting up pf switch [ Upstream commit 956e759d5f8e0859e86b951a8779c60af633aafd ] A recent change that made i40e use new udp_tunnel infrastructure uses a method that expects to be called under rtnl lock. However, not all codepaths do the lock prior to calling i40e_setup_pf_switch. Fix that by adding additional rtnl locking and unlocking. Fixes: 40a98cb6f01f ("i40e: convert to new udp_tunnel infrastructure") Signed-off-by: Jan Sokolowski Signed-off-by: Mateusz Palczewski Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 431557e806dc163d898224a3d99884b4ffc7d06a Author: Mateusz Palczewski Date: Wed Mar 10 11:12:54 2021 +0000 i40e: Fix autoneg disabling for non-10GBaseT links [ Upstream commit 9262793e59f0423437166a879a73d056b1fe6f9a ] Disabling autonegotiation was allowed only for 10GBaseT PHY. The condition was changed to check if link media type is BaseT. Fixes: 3ce12ee9d8f9 ("i40e: Fix order of checks when enabling/disabling autoneg in ethtool") Reviewed-by: Aleksandr Loktionov Reviewed-by: Karen Sornek Signed-off-by: Dawid Lukwinski Signed-off-by: Mateusz Palczewski Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 7cd87f624d5ebf5112d2bbd41458cb30aab84906 Author: Dinghao Liu Date: Sun Feb 28 19:50:58 2021 +0800 i40e: Fix error handling in i40e_vsi_open [ Upstream commit 9c04cfcd4aad232e36306cdc5c74cd9fc9148a7e ] When vsi->type == I40E_VSI_FDIR, we have caught the return value of i40e_vsi_request_irq() but without further handling. Check and execute memory clean on failure just like the other i40e_vsi_request_irq(). Fixes: 8a9eb7d3cbcab ("i40e: rework fdir setup and teardown") Signed-off-by: Dinghao Liu Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 138fa2ab24aef2ca8e55ea25194b5b3d062aeeae Author: Maciej Żenczykowski Date: Wed Jun 16 17:09:51 2021 -0700 bpf: Do not change gso_size during bpf_skb_change_proto() [ Upstream commit 364745fbe981a4370f50274475da4675661104df ] This is technically a backwards incompatible change in behaviour, but I'm going to argue that it is very unlikely to break things, and likely to fix *far* more then it breaks. In no particular order, various reasons follow: (a) I've long had a bug assigned to myself to debug a super rare kernel crash on Android Pixel phones which can (per stacktrace) be traced back to BPF clat IPv6 to IPv4 protocol conversion causing some sort of ugly failure much later on during transmit deep in the GSO engine, AFAICT precisely because of this change to gso_size, though I've never been able to manually reproduce it. I believe it may be related to the particular network offload support of attached USB ethernet dongle being used for tethering off of an IPv6-only cellular connection. The reason might be we end up with more segments than max permitted, or with a GSO packet with only one segment... (either way we break some assumption and hit a BUG_ON) (b) There is no check that the gso_size is > 20 when reducing it by 20, so we might end up with a negative (or underflowing) gso_size or a gso_size of 0. This can't possibly be good. Indeed this is probably somehow exploitable (or at least can result in a kernel crash) by delivering crafted packets and perhaps triggering an infinite loop or a divide by zero... As a reminder: gso_size (MSS) is related to MTU, but not directly derived from it: gso_size/MSS may be significantly smaller then one would get by deriving from local MTU. And on some NICs (which do loose MTU checking on receive, it may even potentially be larger, for example my work pc with 1500 MTU can receive 1520 byte frames [and sometimes does due to bugs in a vendor plat46 implementation]). Indeed even just going from 21 to 1 is potentially problematic because it increases the number of segments by a factor of 21 (think DoS, or some other crash due to too many segments). (c) It's always safe to not increase the gso_size, because it doesn't result in the max packet size increasing. So the skb_increase_gso_size() call was always unnecessary for correctness (and outright undesirable, see later). As such the only part which is potentially dangerous (ie. could cause backwards compatibility issues) is the removal of the skb_decrease_gso_size() call. (d) If the packets are ultimately destined to the local device, then there is absolutely no benefit to playing around with gso_size. It only matters if the packets will egress the device. ie. we're either forwarding, or transmitting from the device. (e) This logic only triggers for packets which are GSO. It does not trigger for skbs which are not GSO. It will not convert a non-GSO MTU sized packet into a GSO packet (and you don't even know what the MTU is, so you can't even fix it). As such your transmit path must *already* be able to handle an MTU 20 bytes larger then your receive path (for IPv4 to IPv6 translation) - and indeed 28 bytes larger due to IPv4 fragments. Thus removing the skb_decrease_gso_size() call doesn't actually increase the size of the packets your transmit side must be able to handle. ie. to handle non-GSO max-MTU packets, the IPv4/IPv6 device/ route MTUs must already be set correctly. Since for example with an IPv4 egress MTU of 1500, IPv4 to IPv6 translation will already build 1520 byte IPv6 frames, so you need a 1520 byte device MTU. This means if your IPv6 device's egress MTU is 1280, your IPv4 route must be 1260 (and actually 1252, because of the need to handle fragments). This is to handle normal non-GSO packets. Thus the reduction is simply not needed for GSO packets, because when they're correctly built, they will already be the right size. (f) TSO/GSO should be able to exactly undo GRO: the number of packets (TCP segments) should not be modified, so that TCP's MSS counting works correctly (this matters for congestion control). If protocol conversion changes the gso_size, then the number of TCP segments may increase or decrease. Packet loss after protocol conversion can result in partial loss of MSS segments that the sender sent. How's the sending TCP stack going to react to receiving ACKs/SACKs in the middle of the segments it sent? (g) skb_{decrease,increase}_gso_size() are already no-ops for GSO_BY_FRAGS case (besides triggering WARN_ON_ONCE). This means you already cannot guarantee that gso_size (and thus resulting packet MTU) is changed. ie. you must assume it won't be changed. (h) changing gso_size is outright buggy for UDP GSO packets, where framing matters (I believe that's also the case for SCTP, but it's already excluded by [g]). So the only remaining case is TCP, which also doesn't want it (see [f]). (i) see also the reasoning on the previous attempt at fixing this (commit fa7b83bf3b156c767f3e4a25bbf3817b08f3ff8e) which shows that the current behaviour causes TCP packet loss: In the forwarding path GRO -> BPF 6 to 4 -> GSO for TCP traffic, the coalesced packet payload can be > MSS, but < MSS + 20. bpf_skb_proto_6_to_4() will upgrade the MSS and it can be > the payload length. After then tcp_gso_segment checks for the payload length if it is <= MSS. The condition is causing the packet to be dropped. tcp_gso_segment(): [...] mss = skb_shinfo(skb)->gso_size; if (unlikely(skb->len <= mss)) goto out; [...] Thus changing the gso_size is simply a very bad idea. Increasing is unnecessary and buggy, and decreasing can go negative. Fixes: 6578171a7ff0 ("bpf: add bpf_skb_change_proto helper") Signed-off-by: Maciej Żenczykowski Signed-off-by: Daniel Borkmann Cc: Dongseok Yi Cc: Willem de Bruijn Link: https://lore.kernel.org/bpf/CANP3RGfjLikQ6dg=YpBU0OeHvyv7JOki7CyOUS9modaXAi-9vQ@mail.gmail.com Link: https://lore.kernel.org/bpf/20210617000953.2787453-2-zenczykowski@gmail.com Signed-off-by: Sasha Levin commit c7e78a1b0af734ed083df9a2f7c710fcd2586d72 Author: Norbert Slusarek Date: Sun Jun 20 14:38:42 2021 +0200 can: j1939: j1939_sk_setsockopt(): prevent allocation of j1939 filter for optlen == 0 [ Upstream commit aaf473d0100f64abc88560e2bea905805bcf2a8e ] If optval != NULL and optlen == 0 are specified for SO_J1939_FILTER in j1939_sk_setsockopt(), memdup_sockptr() will return ZERO_PTR for 0 size allocation. The new filter will be mistakenly assigned ZERO_PTR. This patch checks for optlen != 0 and filter will be assigned NULL in case of optlen == 0. Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Link: https://lore.kernel.org/r/20210620123842.117975-1-nslusarek@gmx.net Signed-off-by: Norbert Slusarek Acked-by: Oleksij Rempel Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 59e8f3f131a1d3fd4b22457057d34dfc7dfe395e Author: Eric Dumazet Date: Wed Jun 23 08:27:00 2021 -0700 ipv6: exthdrs: do not blindly use init_net [ Upstream commit bcc3f2a829b9edbe3da5fb117ee5a63686d31834 ] I see no reason why max_dst_opts_cnt and max_hbh_opts_cnt are fetched from the initial net namespace. The other sysctls (max_dst_opts_len & max_hbh_opts_len) are in fact already using the current ns. Note: it is not clear why ipv6_destopt_rcv() use two ways to get to the netns : 1) dev_net(dst->dev) Originally used to increment IPSTATS_MIB_INHDRERRORS 2) dev_net(skb->dev) Tom used this variant in his patch. Maybe this calls to use ipv6_skb_net() instead ? Fixes: 47d3d7ac656a ("ipv6: Implement limits on Hop-by-Hop and Destination options") Signed-off-by: Eric Dumazet Cc: Tom Herbert Cc: Coco Li Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 80dbfebba92fa5b0f116bc92e0306eb172afdbfd Author: Jian-Hong Pan Date: Wed Jun 23 11:28:03 2021 +0800 net: bcmgenet: Fix attaching to PYH failed on RPi 4B [ Upstream commit b2ac9800cfe0f8da16abc4e74e003440361c112e ] The Broadcom UniMAC MDIO bus from mdio-bcm-unimac module comes too late. So, GENET cannot find the ethernet PHY on UniMAC MDIO bus. This leads GENET fail to attach the PHY as following log: bcmgenet fd580000.ethernet: GENET 5.0 EPHY: 0x0000 ... could not attach to PHY bcmgenet fd580000.ethernet eth0: failed to connect to PHY uart-pl011 fe201000.serial: no DMA platform data libphy: bcmgenet MII bus: probed ... unimac-mdio unimac-mdio.-19: Broadcom UniMAC MDIO bus This patch adds the soft dependency to load mdio-bcm-unimac module before genet module to avoid the issue. Fixes: 9a4e79697009 ("net: bcmgenet: utilize generic Broadcom UniMAC MDIO controller driver") Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=213485 Signed-off-by: Jian-Hong Pan Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit abca3782c5d62676755bd1651156bcc13bbf6176 Author: Ping-Ke Shih Date: Wed Jun 23 21:48:25 2021 +0800 mac80211: remove iwlwifi specific workaround NDPs of null_response [ Upstream commit 744757e46bf13ec3a7b3507d17ab3faab9516d43 ] Remove the remaining workaround that is not removed by the commit e41eb3e408de ("mac80211: remove iwlwifi specific workaround that broke sta NDP tx") Fixes: 41cbb0f5a295 ("mac80211: add support for HE") Signed-off-by: Ping-Ke Shih Link: https://lore.kernel.org/r/20210623134826.10318-1-pkshih@realtek.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit be7be4caa6d0b10646d1bd8018988fdb70060e47 Author: Zhen Lei Date: Mon May 10 14:38:05 2021 +0800 drm/msm/dpu: Fix error return code in dpu_mdss_init() [ Upstream commit e020ac961ce5d038de66dc7f6ffca98899e9a3f3 ] The error code returned by platform_get_irq() is stored in 'irq', it's forgotten to be copied to 'ret' before being returned. As a result, the value 0 of 'ret' is returned incorrectly. After the above fix is completed, initializing the local variable 'ret' to 0 is no longer needed, remove it. In addition, when dpu_mdss_init() is successfully returned, the value of 'ret' is always 0. Therefore, replace "return ret" with "return 0" to make the code clearer. Fixes: 070e64dc1bbc ("drm/msm/dpu: Convert to a chained irq chip") Reported-by: Hulk Robot Signed-off-by: Zhen Lei Link: https://lore.kernel.org/r/20210510063805.3262-2-thunder.leizhen@huawei.com Reviewed-by: Stephen Boyd Reviewed-by: Dmitry Baryshkov Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 48a14a2d67e9eeb9d419fd9f29ac195adf65915d Author: Zhen Lei Date: Sat May 8 10:28:36 2021 +0800 drm/msm: Fix error return code in msm_drm_init() [ Upstream commit a1c9b1e3bdd6d8dc43c18699772fb6cf4497d45a ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 7f9743abaa79 ("drm/msm: validate display and event threads") Reported-by: Hulk Robot Signed-off-by: Zhen Lei Link: https://lore.kernel.org/r/20210508022836.1777-1-thunder.leizhen@huawei.com Reviewed-by: Dmitry Baryshkov Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit e75247cd452258339fa557ba41ec5dfa68c89b29 Author: Krishna Manikandan Date: Thu May 27 10:37:56 2021 +0530 drm/msm/disp/dpu1: avoid perf update in frame done event [ Upstream commit a1f2ba60eace242fd034173db3762f342a824a2e ] Crtc perf update from frame event work can result in wrong bandwidth and clock update from dpu if the work is scheduled after the swap state has happened. Avoid such issues by moving perf update to complete commit once the frame is accepted by the hardware. Fixes: a29c8c024165 ("drm/msm/disp/dpu1: fix display underruns during modeset") Signed-off-by: Krishna Manikandan Tested-by: Douglas Anderson Link: https://lore.kernel.org/r/1622092076-5100-1-git-send-email-mkrishn@codeaurora.org Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 17992ed2fb98e4c036c5af08564587d6459b84ff Author: Kuogee Hsieh Date: Fri May 21 15:25:30 2021 -0700 drm/msm/dp: handle irq_hpd with sink_count = 0 correctly [ Upstream commit f21c8a276c2daddddf58d483b49b01d0603f0316 ] irq_hpd interrupt should be handled after dongle plugged in and before dongle unplugged. Hence irq_hpd interrupt is enabled at the end of the plugin handle and disabled at the beginning of unplugged handle. Current irq_hpd with sink_count = 0 is wrongly handled same as the dongle unplugged which tears down the mainlink and disables the phy. This patch fixes this problem by only tearing down the mainlink but keeping phy enabled at irq_hpd with sink_count = 0 handle so that next irq_hpd with sink_count =1 can be handled by setup mainlink only. This patch also set dongle into D3 (power off) state at end of handling irq_hpd with sink_count = 0. Changes in v2: -- add ctrl->phy_Power_count Changes in v3: -- del ctrl->phy_Power_count -- add phy_power_off to dp_ctrl_off_link_stream() Changes in v4: -- return immediately if clock disable failed at dp_ctrl_off_link_stream() Changes in v5: -- set dongle to D3 (power off) state at dp_ctrl_off_link_stream() Changes in v6: -- add Fixes tag Fixes: ea9f337ce81e ("drm/msm/dp: reset dp controller only at boot up and pm_resume") Signed-off-by: Kuogee Hsieh Tested-by: Stephen Boyd Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/1621635930-30161-1-git-send-email-khsieh@codeaurora.org Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit b8a6022adad615af2f8e2a68bb3df918cbb195c8 Author: John Fastabend Date: Wed Jun 16 15:55:00 2021 -0700 bpf: Fix null ptr deref with mixed tail calls and subprogs [ Upstream commit 7506d211b932870155bcb39e3dd9e39fab45a7c7 ] The sub-programs prog->aux->poke_tab[] is populated in jit_subprogs() and then used when emitting 'BPF_JMP|BPF_TAIL_CALL' insn->code from the individual JITs. The poke_tab[] to use is stored in the insn->imm by the code adding it to that array slot. The JIT then uses imm to find the right entry for an individual instruction. In the x86 bpf_jit_comp.c this is done by calling emit_bpf_tail_call_direct with the poke_tab[] of the imm value. However, we observed the below null-ptr-deref when mixing tail call programs with subprog programs. For this to happen we just need to mix bpf-2-bpf calls and tailcalls with some extra calls or instructions that would be patched later by one of the fixup routines. So whats happening? Before the fixup_call_args() -- where the jit op is done -- various code patching is done by do_misc_fixups(). This may increase the insn count, for example when we patch map_lookup_up using map_gen_lookup hook. This does two things. First, it means the instruction index, insn_idx field, of a tail call instruction will move by a 'delta'. In verifier code, struct bpf_jit_poke_descriptor desc = { .reason = BPF_POKE_REASON_TAIL_CALL, .tail_call.map = BPF_MAP_PTR(aux->map_ptr_state), .tail_call.key = bpf_map_key_immediate(aux), .insn_idx = i + delta, }; Then subprog start values subprog_info[i].start will be updated with the delta and any poke descriptor index will also be updated with the delta in adjust_poke_desc(). If we look at the adjust subprog starts though we see its only adjusted when the delta occurs before the new instructions, /* NOTE: fake 'exit' subprog should be updated as well. */ for (i = 0; i <= env->subprog_cnt; i++) { if (env->subprog_info[i].start <= off) continue; Earlier subprograms are not changed because their start values are not moved. But, adjust_poke_desc() does the offset + delta indiscriminately. The result is poke descriptors are potentially corrupted. Then in jit_subprogs() we only populate the poke_tab[] when the above insn_idx is less than the next subprogram start. From above we corrupted our insn_idx so we might incorrectly assume a poke descriptor is not used in a subprogram omitting it from the subprogram. And finally when the jit runs it does the deref of poke_tab when emitting the instruction and crashes with below. Because earlier step omitted the poke descriptor. The fix is straight forward with above context. Simply move same logic from adjust_subprog_starts() into adjust_poke_descs() and only adjust insn_idx when needed. [ 82.396354] bpf_testmod: version magic '5.12.0-rc2alu+ SMP preempt mod_unload ' should be '5.12.0+ SMP preempt mod_unload ' [ 82.623001] loop10: detected capacity change from 0 to 8 [ 88.487424] ================================================================== [ 88.487438] BUG: KASAN: null-ptr-deref in do_jit+0x184a/0x3290 [ 88.487455] Write of size 8 at addr 0000000000000008 by task test_progs/5295 [ 88.487471] CPU: 7 PID: 5295 Comm: test_progs Tainted: G I 5.12.0+ #386 [ 88.487483] Hardware name: Dell Inc. Precision 5820 Tower/002KVM, BIOS 1.9.2 01/24/2019 [ 88.487490] Call Trace: [ 88.487498] dump_stack+0x93/0xc2 [ 88.487515] kasan_report.cold+0x5f/0xd8 [ 88.487530] ? do_jit+0x184a/0x3290 [ 88.487542] do_jit+0x184a/0x3290 ... [ 88.487709] bpf_int_jit_compile+0x248/0x810 ... [ 88.487765] bpf_check+0x3718/0x5140 ... [ 88.487920] bpf_prog_load+0xa22/0xf10 Fixes: a748c6975dea3 ("bpf: propagate poke descriptors to subprograms") Reported-by: Jussi Maki Signed-off-by: John Fastabend Signed-off-by: Alexei Starovoitov Reviewed-by: Daniel Borkmann Signed-off-by: Sasha Levin commit 7fc2cbe4c840b0307fbc9aeb098191e804ed3c73 Author: Eric Dumazet Date: Mon Jun 21 11:02:44 2021 -0700 ieee802154: hwsim: avoid possible crash in hwsim_del_edge_nl() [ Upstream commit 0303b30375dff5351a79cc2c3c87dfa4fda29bed ] Both MAC802154_HWSIM_ATTR_RADIO_ID and MAC802154_HWSIM_ATTR_RADIO_EDGE must be present to avoid a crash. Fixes: f25da51fdc38 ("ieee802154: hwsim: add replacement for fakelb") Signed-off-by: Eric Dumazet Cc: Alexander Aring Cc: Stefan Schmidt Reported-by: syzbot Acked-by: Alexander Aring Link: https://lore.kernel.org/r/20210621180244.882076-1-eric.dumazet@gmail.com Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin commit 812801e0b924ef6fb6d64d401d8f31288ab2a696 Author: Dongliang Mu Date: Wed Jun 16 10:09:01 2021 +0800 ieee802154: hwsim: Fix memory leak in hwsim_add_one [ Upstream commit 28a5501c3383f0e6643012c187b7c2027ef42aea ] No matter from hwsim_remove or hwsim_del_radio_nl, hwsim_del fails to remove the entry in the edges list. Take the example below, phy0, phy1 and e0 will be deleted, resulting in e1 not freed and accessed in the future. hwsim_phys | ------------------------------ | | phy0 (edges) phy1 (edges) ----> e1 (idx = 1) ----> e0 (idx = 0) Fix this by deleting and freeing all the entries in the edges list between hwsim_edge_unsubscribe_me and list_del(&phy->list). Reported-by: syzbot+b80c9959009a9325cdff@syzkaller.appspotmail.com Fixes: 1c9f4a3fce77 ("ieee802154: hwsim: fix rcu handling") Signed-off-by: Dongliang Mu Acked-by: Alexander Aring Link: https://lore.kernel.org/r/20210616020901.2759466-1-mudongliangabcd@gmail.com Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin commit 4416dc914ccaaa45ca9aee92fb0fa6d0ec41f746 Author: Yixing Liu Date: Fri Jun 18 18:10:12 2021 +0800 RDMA/hns: Fix uninitialized variable [ Upstream commit 2a38c0f10e6d7d28e06ff1eb1f350804c4850275 ] A random value will be returned if the condition below is not met, so it needs to be initialized. Fixes: 9ea9a53ea93b ("RDMA/hns: Add mapped page count checking for MTR") Link: https://lore.kernel.org/r/1624011020-16992-3-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 5fc0d1725e73cb6a53482e983b1d6f8d52607207 Author: Lang Cheng Date: Fri Jun 18 18:10:11 2021 +0800 RDMA/hns: Force rewrite inline flag of WQE [ Upstream commit e13026578b727becf2614f34a4f35e7f0ed21be1 ] When a non-inline WR reuses a WQE that was used for inline last time, the remaining inline flag should be cleared. Fixes: 62490fd5a865 ("RDMA/hns: Avoid unnecessary memset on WQEs in post_send") Link: https://lore.kernel.org/r/1624011020-16992-2-git-send-email-liweihang@huawei.com Signed-off-by: Lang Cheng Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 3c4a4c05b01f55855069581a94bf9dfc3a687567 Author: Marcelo Ricardo Leitner Date: Tue Jun 22 12:05:00 2021 -0300 tc-testing: fix list handling [ Upstream commit b4fd096cbb871340be837491fa1795864a48b2d9 ] python lists don't have an 'add' method, but 'append'. Fixes: 14e5175e9e04 ("tc-testing: introduce scapyPlugin for basic traffic") Signed-off-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d44313d1240c4bddfd4a29a34930ab3f215a8eb3 Author: Vignesh Raghavendra Date: Tue Jun 22 20:08:57 2021 +0530 net: ti: am65-cpsw-nuss: Fix crash when changing number of TX queues [ Upstream commit ce8eb4c728ef40b554b4f3d8963f11ed44502e00 ] When changing number of TX queues using ethtool: # ethtool -L eth0 tx 1 [ 135.301047] Unable to handle kernel paging request at virtual address 00000000af5d0000 [...] [ 135.525128] Call trace: [ 135.525142] dma_release_from_dev_coherent+0x2c/0xb0 [ 135.525148] dma_free_attrs+0x54/0xe0 [ 135.525156] k3_cppi_desc_pool_destroy+0x50/0xa0 [ 135.525164] am65_cpsw_nuss_remove_tx_chns+0x88/0xdc [ 135.525171] am65_cpsw_set_channels+0x3c/0x70 [...] This is because k3_cppi_desc_pool_destroy() which is called after k3_udma_glue_release_tx_chn() in am65_cpsw_nuss_remove_tx_chns() references struct device that is unregistered at the end of k3_udma_glue_release_tx_chn() Therefore the right order is to call k3_cppi_desc_pool_destroy() and destroy desc pool before calling k3_udma_glue_release_tx_chn(). Fix this throughout the driver. Fixes: 93a76530316a ("net: ethernet: ti: introduce am65x/j721e gigabit eth subsystem driver") Signed-off-by: Vignesh Raghavendra Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9d47eeb96ddc6f23ff897fe2a491c485782f9f91 Author: Rafał Miłecki Date: Tue Jun 22 07:24:15 2021 +0200 net: broadcom: bcm4908_enet: reset DMA rings sw indexes properly [ Upstream commit ddeacc4f6494e07cbb6f033627926623f3e7a9d0 ] Resetting software indexes in bcm4908_dma_alloc_buf_descs() is not enough as it's called during device probe only. Driver resets DMA on every .ndo_open callback and it's required to reset indexes then. This fixes inconsistent rings state and stalled traffic after interface down & up sequence. Fixes: 4feffeadbcb2 ("net: broadcom: bcm4908enet: add BCM4908 controller driver") Signed-off-by: Rafał Miłecki Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a7d381c90c4be80433efd6082802ec9118cfca54 Author: Miao Wang Date: Tue Jun 22 12:24:50 2021 +0800 net/ipv4: swap flow ports when validating source [ Upstream commit c69f114d09891adfa3e301a35d9e872b8b7b5a50 ] When doing source address validation, the flowi4 struct used for fib_lookup should be in the reverse direction to the given skb. fl4_dport and fl4_sport returned by fib4_rules_early_flow_dissect should thus be swapped. Fixes: 5a847a6e1477 ("net/ipv4: Initialize proto and ports in flow struct") Signed-off-by: Miao Wang Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6380a373f9d134b6a122c7002ed996b5f2bb9128 Author: Jakub Kicinski Date: Mon Jun 21 18:52:54 2021 -0700 ip6_tunnel: fix GRE6 segmentation [ Upstream commit a6e3f2985a80ef6a45a17d2d9d9151f17ea3ce07 ] Commit 6c11fbf97e69 ("ip6_tunnel: add MPLS transmit support") moved assiging inner_ipproto down from ipxip6_tnl_xmit() to its callee ip6_tnl_xmit(). The latter is also used by GRE. Since commit 38720352412a ("gre: Use inner_proto to obtain inner header protocol") GRE had been depending on skb->inner_protocol during segmentation. It sets it in gre_build_header() and reads it in gre_gso_segment(). Changes to ip6_tnl_xmit() overwrite the protocol, resulting in GSO skbs getting dropped. Note that inner_protocol is a union with inner_ipproto, GRE uses the former while the change switched it to the latter (always setting it to just IPPROTO_GRE). Restore the original location of skb_set_inner_ipproto(), it is unclear why it was moved in the first place. Fixes: 6c11fbf97e69 ("ip6_tunnel: add MPLS transmit support") Signed-off-by: Jakub Kicinski Tested-by: Vadim Fedorenko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a1a10328ddab3500512b930c17250757ec995a1f Author: Paolo Abeni Date: Mon Jun 21 17:33:08 2021 -0700 mptcp: avoid race on msk state changes [ Upstream commit 490274b47468793e3e157c2df6b2da0e646cc4a9 ] The msk socket state is currently updated in a few spots without owning the msk socket lock itself. Some of such operations are safe, as they happens before exposing the msk socket to user-space and can't race with other changes. A couple of them, at connect time, can actually race with close() or shutdown(), leaving breaking the socket state machine. This change addresses the issue moving such update under the msk socket lock with the usual: scheme. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/56 Fixes: 8fd738049ac3 ("mptcp: fallback in case of simultaneous connect") Fixes: c3c123d16c0e ("net: mptcp: don't hang in mptcp_sendmsg() after TCP fallback") Signed-off-by: Paolo Abeni Signed-off-by: Mat Martineau Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 027c5a4c89ec83de6b56a8e9cc0b877a0e09d244 Author: Bui Quang Minh Date: Sun Jun 13 21:34:39 2021 +0700 bpf: Fix integer overflow in argument calculation for bpf_map_area_alloc [ Upstream commit 7dd5d437c258bbf4cc15b35229e5208b87b8b4e0 ] In 32-bit architecture, the result of sizeof() is a 32-bit integer so the expression becomes the multiplication between 2 32-bit integer which can potentially leads to integer overflow. As a result, bpf_map_area_alloc() allocates less memory than needed. Fix this by casting 1 operand to u64. Fixes: 0d2c4f964050 ("bpf: Eliminate rlimit-based memory accounting for sockmap and sockhash maps") Fixes: 99c51064fb06 ("devmap: Use bpf_map_area_alloc() for allocating hash buckets") Fixes: 546ac1ffb70d ("bpf: add devmap, a map for storing net device references") Signed-off-by: Bui Quang Minh Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20210613143440.71975-1-minhquangbui99@gmail.com Signed-off-by: Sasha Levin commit f4ecb17d3ad4a84bfe339285eff62f613f402dea Author: Eric Dumazet Date: Mon Jun 21 07:44:17 2021 -0700 vxlan: add missing rcu_read_lock() in neigh_reduce() [ Upstream commit 85e8b032d6ebb0f698a34dd22c2f13443d905888 ] syzbot complained in neigh_reduce(), because rcu_read_lock_bh() is treated differently than rcu_read_lock() WARNING: suspicious RCU usage 5.13.0-rc6-syzkaller #0 Not tainted ----------------------------- include/net/addrconf.h:313 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 3 locks held by kworker/0:0/5: #0: ffff888011064d38 ((wq_completion)events){+.+.}-{0:0}, at: arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline] #0: ffff888011064d38 ((wq_completion)events){+.+.}-{0:0}, at: atomic64_set include/asm-generic/atomic-instrumented.h:856 [inline] #0: ffff888011064d38 ((wq_completion)events){+.+.}-{0:0}, at: atomic_long_set include/asm-generic/atomic-long.h:41 [inline] #0: ffff888011064d38 ((wq_completion)events){+.+.}-{0:0}, at: set_work_data kernel/workqueue.c:617 [inline] #0: ffff888011064d38 ((wq_completion)events){+.+.}-{0:0}, at: set_work_pool_and_clear_pending kernel/workqueue.c:644 [inline] #0: ffff888011064d38 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x871/0x1600 kernel/workqueue.c:2247 #1: ffffc90000ca7da8 ((work_completion)(&port->wq)){+.+.}-{0:0}, at: process_one_work+0x8a5/0x1600 kernel/workqueue.c:2251 #2: ffffffff8bf795c0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0x1da/0x3130 net/core/dev.c:4180 stack backtrace: CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.13.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events ipvlan_process_multicast Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 __in6_dev_get include/net/addrconf.h:313 [inline] __in6_dev_get include/net/addrconf.h:311 [inline] neigh_reduce drivers/net/vxlan.c:2167 [inline] vxlan_xmit+0x34d5/0x4c30 drivers/net/vxlan.c:2919 __netdev_start_xmit include/linux/netdevice.h:4944 [inline] netdev_start_xmit include/linux/netdevice.h:4958 [inline] xmit_one net/core/dev.c:3654 [inline] dev_hard_start_xmit+0x1eb/0x920 net/core/dev.c:3670 __dev_queue_xmit+0x2133/0x3130 net/core/dev.c:4246 ipvlan_process_multicast+0xa99/0xd70 drivers/net/ipvlan/ipvlan_core.c:287 process_one_work+0x98d/0x1600 kernel/workqueue.c:2276 worker_thread+0x64c/0x1120 kernel/workqueue.c:2422 kthread+0x3b1/0x4a0 kernel/kthread.c:313 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 Fixes: f564f45c4518 ("vxlan: add ipv6 proxy support") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f433230c54334de470c622f82d4d50b8f3ebe4f7 Author: Po-Hao Huang Date: Mon Apr 26 09:32:52 2021 +0800 rtw88: 8822c: fix lc calibration timing [ Upstream commit 05684fd583e1acc34dddea283838fbfbed4904a0 ] Before this patch, we use value from 2 seconds ago to decide whether we should do lc calibration. Although this don't happen frequently, fix flow to the way it should be. Fixes: 7ae7784ec2a8 ("rtw88: 8822c: add LC calibration for RTL8822C") Signed-off-by: Po-Hao Huang Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210426013252.5665-3-pkshih@realtek.com Signed-off-by: Sasha Levin commit 1f7495df501fddf0b683484248b1ef67eeb6feef Author: Maciej Żenczykowski Date: Fri Jun 18 03:55:26 2021 -0700 bpf: Fix regression on BPF_OBJ_GET with non-O_RDWR flags [ Upstream commit 5dec6d96d12d33900ec315972c8e47a73bcc378d ] This reverts commit d37300ed1821 ("bpf: program: Refuse non-O_RDWR flags in BPF_OBJ_GET"). It breaks Android userspace which expects to be able to fetch programs with just read permissions. See: https://cs.android.com/android/platform/superproject/+/master:frameworks/libs/net/common/native/bpf_syscall_wrappers/include/BpfSyscallWrappers.h;drc=7005c764be23d31fa1d69e826b4a2f6689a8c81e;l=124 Side-note: another option to fix it would be to extend bpf_prog_new_fd() and to pass in used file mode flags in the same way as we do for maps via bpf_map_new_fd(). Meaning, they'd end up in anon_inode_getfd() and thus would be retained for prog fd operations with bpf() syscall. Right now these flags are not checked with progs since they are immutable for their lifetime (as opposed to maps which can be updated from user space). In future this could potentially change with new features, but at that point it's still fine to do the bpf_prog_new_fd() extension when needed. For a simple stable fix, a revert is less churn. Fixes: d37300ed1821 ("bpf: program: Refuse non-O_RDWR flags in BPF_OBJ_GET") Signed-off-by: Maciej Żenczykowski [ Daniel: added side-note to commit message ] Signed-off-by: Daniel Borkmann Acked-by: Lorenz Bauer Acked-by: Greg Kroah-Hartman Link: https://lore.kernel.org/bpf/20210618105526.265003-1-zenczykowski@gmail.com Signed-off-by: Sasha Levin commit ef8f0bdbb724ed5dce24ec142719c37ec5ca1bb9 Author: Luca Coelho Date: Sat Jun 12 14:32:40 2021 +0300 iwlwifi: increase PNVM load timeout [ Upstream commit 5cc816ef9db1fe03f73e56e9d8f118add9c6efe4 ] The FW has a watchdog of 200ms in the PNVM load flow, so the driver should have a slightly higher timeout. Change the timeout from 100ms to 250ms. Signed-off-by: Luca Coelho Fixes: 70d3ca86b025 ("iwlwifi: mvm: ring the doorbell and wait for PNVM load completion") Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210612142637.ba22aec1e2be.I36bfadc28c480f4fc57266c075a79e8ea4a6934f@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit e47311366a799d2aa96829f13183c6bd582e6b38 Author: Pablo Neira Ayuso Date: Tue Jun 22 12:10:49 2021 +0200 netfilter: nf_tables: do not allow to delete table with owner by handle [ Upstream commit e31f072ffab0397a328b31a9589dcf9733dc9c72 ] nft_table_lookup_byhandle() also needs to validate the netlink PortID owner when deleting a table by handle. Fixes: 6001a930ce03 ("netfilter: nftables: introduce table ownership") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 1433324d08abed9f3f3c35af39b2f3389c579245 Author: Pablo Neira Ayuso Date: Tue Jun 22 11:45:11 2021 +0200 netfilter: nf_tables: skip netlink portID validation if zero [ Upstream commit 534799097a777e82910f77a4f9d289c815a9a64e ] nft_table_lookup() allows us to obtain the table object by the name and the family. The netlink portID validation needs to be skipped for the dump path, since the ownership only applies to commands to update the given table. Skip validation if the specified netlink PortID is zero when calling nft_table_lookup(). Fixes: 6001a930ce03 ("netfilter: nftables: introduce table ownership") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 445e7e3cfe7459ec84fd247df951dde74a132f64 Author: Ayush Sawal Date: Tue Jun 22 09:25:31 2021 +0530 xfrm: Fix xfrm offload fallback fail case [ Upstream commit dd72fadf2186fc8a6018f97fe72f4d5ca05df440 ] In case of xfrm offload, if xdo_dev_state_add() of driver returns -EOPNOTSUPP, xfrm offload fallback is failed. In xfrm state_add() both xso->dev and xso->real_dev are initialized to dev and when err(-EOPNOTSUPP) is returned only xso->dev is set to null. So in this scenario the condition in func validate_xmit_xfrm(), if ((x->xso.dev != dev) && (x->xso.real_dev == dev)) return skb; returns true, due to which skb is returned without calling esp_xmit() below which has fallback code. Hence the CRYPTO_FALLBACK is failing. So fixing this with by keeping x->xso.real_dev as NULL when err is returned in func xfrm_dev_state_add(). Fixes: bdfd2d1fa79a ("bonding/xfrm: use real_dev instead of slave_dev") Signed-off-by: Ayush Sawal Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 8e3823a5d97b95746d7c83c32deb11e923a447d3 Author: Eric Dumazet Date: Mon Jun 21 10:54:49 2021 -0700 pkt_sched: sch_qfq: fix qfq_change_class() error path [ Upstream commit 0cd58e5c53babb9237b741dbef711f0a9eb6d3fd ] If qfq_change_class() is unable to allocate memory for qfq_aggregate, it frees the class that has been inserted in the class hash table, but does not unhash it. Defer the insertion after the problematic allocation. BUG: KASAN: use-after-free in hlist_add_head include/linux/list.h:884 [inline] BUG: KASAN: use-after-free in qdisc_class_hash_insert+0x200/0x210 net/sched/sch_api.c:731 Write of size 8 at addr ffff88814a534f10 by task syz-executor.4/31478 CPU: 0 PID: 31478 Comm: syz-executor.4 Not tainted 5.13.0-rc6-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:233 __kasan_report mm/kasan/report.c:419 [inline] kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:436 hlist_add_head include/linux/list.h:884 [inline] qdisc_class_hash_insert+0x200/0x210 net/sched/sch_api.c:731 qfq_change_class+0x96c/0x1990 net/sched/sch_qfq.c:489 tc_ctl_tclass+0x514/0xe50 net/sched/sch_api.c:2113 rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5564 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+0x856/0xd90 net/netlink/af_netlink.c:1929 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x4665d9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fdc7b5f0188 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000056bf80 RCX: 00000000004665d9 RDX: 0000000000000000 RSI: 00000000200001c0 RDI: 0000000000000003 RBP: 00007fdc7b5f01d0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 00007ffcf7310b3f R14: 00007fdc7b5f0300 R15: 0000000000022000 Allocated by task 31445: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:46 [inline] set_alloc_info mm/kasan/common.c:428 [inline] ____kasan_kmalloc mm/kasan/common.c:507 [inline] ____kasan_kmalloc mm/kasan/common.c:466 [inline] __kasan_kmalloc+0x9b/0xd0 mm/kasan/common.c:516 kmalloc include/linux/slab.h:556 [inline] kzalloc include/linux/slab.h:686 [inline] qfq_change_class+0x705/0x1990 net/sched/sch_qfq.c:464 tc_ctl_tclass+0x514/0xe50 net/sched/sch_api.c:2113 rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5564 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+0x856/0xd90 net/netlink/af_netlink.c:1929 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae Freed by task 31445: kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38 kasan_set_track+0x1c/0x30 mm/kasan/common.c:46 kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:357 ____kasan_slab_free mm/kasan/common.c:360 [inline] ____kasan_slab_free mm/kasan/common.c:325 [inline] __kasan_slab_free+0xfb/0x130 mm/kasan/common.c:368 kasan_slab_free include/linux/kasan.h:212 [inline] slab_free_hook mm/slub.c:1583 [inline] slab_free_freelist_hook+0xdf/0x240 mm/slub.c:1608 slab_free mm/slub.c:3168 [inline] kfree+0xe5/0x7f0 mm/slub.c:4212 qfq_change_class+0x10fb/0x1990 net/sched/sch_qfq.c:518 tc_ctl_tclass+0x514/0xe50 net/sched/sch_api.c:2113 rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5564 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+0x856/0xd90 net/netlink/af_netlink.c:1929 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae The buggy address belongs to the object at ffff88814a534f00 which belongs to the cache kmalloc-128 of size 128 The buggy address is located 16 bytes inside of 128-byte region [ffff88814a534f00, ffff88814a534f80) The buggy address belongs to the page: page:ffffea0005294d00 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14a534 flags: 0x57ff00000000200(slab|node=1|zone=2|lastcpupid=0x7ff) raw: 057ff00000000200 ffffea00004fee00 0000000600000006 ffff8880110418c0 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x12cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY), pid 29797, ts 604817765317, free_ts 604810151744 prep_new_page mm/page_alloc.c:2358 [inline] get_page_from_freelist+0x1033/0x2b60 mm/page_alloc.c:3994 __alloc_pages+0x1b2/0x500 mm/page_alloc.c:5200 alloc_pages+0x18c/0x2a0 mm/mempolicy.c:2272 alloc_slab_page mm/slub.c:1646 [inline] allocate_slab+0x2c5/0x4c0 mm/slub.c:1786 new_slab mm/slub.c:1849 [inline] new_slab_objects mm/slub.c:2595 [inline] ___slab_alloc+0x4a1/0x810 mm/slub.c:2758 __slab_alloc.constprop.0+0xa7/0xf0 mm/slub.c:2798 slab_alloc_node mm/slub.c:2880 [inline] slab_alloc mm/slub.c:2922 [inline] __kmalloc+0x315/0x330 mm/slub.c:4050 kmalloc include/linux/slab.h:561 [inline] kzalloc include/linux/slab.h:686 [inline] __register_sysctl_table+0x112/0x1090 fs/proc/proc_sysctl.c:1318 mpls_dev_sysctl_register+0x1b7/0x2d0 net/mpls/af_mpls.c:1421 mpls_add_dev net/mpls/af_mpls.c:1472 [inline] mpls_dev_notify+0x214/0x8b0 net/mpls/af_mpls.c:1588 notifier_call_chain+0xb5/0x200 kernel/notifier.c:83 call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:2121 call_netdevice_notifiers_extack net/core/dev.c:2133 [inline] call_netdevice_notifiers net/core/dev.c:2147 [inline] register_netdevice+0x106b/0x1500 net/core/dev.c:10312 veth_newlink+0x585/0xac0 drivers/net/veth.c:1547 __rtnl_newlink+0x1062/0x1710 net/core/rtnetlink.c:3452 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3500 page last free stack trace: reset_page_owner include/linux/page_owner.h:24 [inline] free_pages_prepare mm/page_alloc.c:1298 [inline] free_pcp_prepare+0x223/0x300 mm/page_alloc.c:1342 free_unref_page_prepare mm/page_alloc.c:3250 [inline] free_unref_page+0x12/0x1d0 mm/page_alloc.c:3298 __vunmap+0x783/0xb60 mm/vmalloc.c:2566 free_work+0x58/0x70 mm/vmalloc.c:80 process_one_work+0x98d/0x1600 kernel/workqueue.c:2276 worker_thread+0x64c/0x1120 kernel/workqueue.c:2422 kthread+0x3b1/0x4a0 kernel/kthread.c:313 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 Memory state around the buggy address: ffff88814a534e00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88814a534e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88814a534f00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88814a534f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88814a535000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Fixes: 462dbc9101acd ("pkt_sched: QFQ Plus: fair-queueing service at DRR cost") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7c8e4bc68e58befffa5bce9cf08dd949d9823a24 Author: Eldar Gasanov Date: Mon Jun 21 11:54:38 2021 +0300 net: dsa: mv88e6xxx: Fix adding vlan 0 [ Upstream commit b8b79c414eca4e9bcab645e02cb92c48db974ce9 ] 8021q module adds vlan 0 to all interfaces when it starts. When 8021q module is loaded it isn't possible to create bond with mv88e6xxx interfaces, bonding module dipslay error "Couldn't add bond vlan ids", because it tries to add vlan 0 to slave interfaces. There is unexpected behavior in the switch. When a PVID is assigned to a port the switch changes VID to PVID in ingress frames with VID 0 on the port. Expected that the switch doesn't assign PVID to tagged frames with VID 0. But there isn't a way to change this behavior in the switch. Fixes: 57e661aae6a8 ("net: dsa: mv88e6xxx: Link aggregation support") Signed-off-by: Eldar Gasanov Reviewed-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c648c4bd3233c9a99215b211652d6f5a1511941f Author: Christophe JAILLET Date: Sun Jun 20 15:43:28 2021 +0200 net: mana: Fix a memory leak in an error handling path in 'mana_create_txq()' [ Upstream commit b90788459cd6d140171b046f0b37fad341ade0a3 ] If this test fails we must free some resources as in all the other error handling paths of this function. Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Signed-off-by: Christophe JAILLET Reviewed-by: Dexuan Cui Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7dc2320844fefe73cff6beab5e806b70abd4c60c Author: Paolo Abeni Date: Fri Jun 18 15:02:21 2021 -0700 mptcp: fix 32 bit DSN expansion [ Upstream commit 5957a8901db44c03540505ccedd95031c21ef2f2 ] The current implementation of 32 bit DSN expansion is buggy. After the previous patch, we can simply reuse the newly introduced helper to do the expansion safely. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/120 Fixes: 648ef4b88673 ("mptcp: Implement MPTCP receive path") Reviewed-by: Mat Martineau Signed-off-by: Paolo Abeni Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9405815dad41515661ca2bbbc1c552e886c4b022 Author: Paolo Abeni Date: Fri Jun 18 15:02:20 2021 -0700 mptcp: fix bad handling of 32 bit ack wrap-around [ Upstream commit 1502328f17ab0684ca5ed6764433aa0a83bdaf95 ] When receiving 32 bits DSS ack from the peer, the MPTCP need to expand them to 64 bits value. The current code is buggy WRT detecting 32 bits ack wrap-around: when the wrap-around happens the current unsigned 32 bit ack value is lower than the previous one. Additionally check for possible reverse wrap and make the helper visible, so that we could re-use it for the next patch. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/204 Fixes: cc9d25669866 ("mptcp: update per unacked sequence on pkt reception") Reviewed-by: Mat Martineau Signed-off-by: Paolo Abeni Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4a4d230b177876566cc4bbe4252e0d0a3d7d54e4 Author: Pablo Neira Ayuso Date: Sat Jun 19 01:25:14 2021 +0200 netfilter: nf_tables_offload: check FLOW_DISSECTOR_KEY_BASIC in VLAN transfer logic [ Upstream commit ea45fdf82cc90430bb7c280e5e53821e833782c5 ] The VLAN transfer logic should actually check for FLOW_DISSECTOR_KEY_BASIC, not FLOW_DISSECTOR_KEY_CONTROL. Moreover, do not fallback to case 2) .n_proto is set to 802.1q or 802.1ad, if FLOW_DISSECTOR_KEY_BASIC is unset. Fixes: 783003f3bb8a ("netfilter: nftables_offload: special ethertype handling for VLAN") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 09b1f676e2e0bbff67c568672c565c6f31470157 Author: Pablo Neira Ayuso Date: Sat Jun 19 00:55:20 2021 +0200 netfilter: nf_tables: memleak in hw offload abort path [ Upstream commit 3c5e44622011b9ea21bd425875dcccfc9a158f5f ] Release flow from the abort path, this is easy to reproduce since b72920f6e4a9 ("netfilter: nftables: counter hardware offload support"). If the preparation phase fails, then the abort path is exercised without releasing the flow rule object. unreferenced object 0xffff8881f0fa7700 (size 128): comm "nft", pid 1335, jiffies 4294931120 (age 4163.740s) hex dump (first 32 bytes): 08 e4 de 13 82 88 ff ff 98 e4 de 13 82 88 ff ff ................ 48 e4 de 13 82 88 ff ff 01 00 00 00 00 00 00 00 H............... backtrace: [<00000000634547e7>] flow_rule_alloc+0x26/0x80 [<00000000c8426156>] nft_flow_rule_create+0xc9/0x3f0 [nf_tables] [<0000000075ff8e46>] nf_tables_newrule+0xc79/0x10a0 [nf_tables] [<00000000ba65e40e>] nfnetlink_rcv_batch+0xaac/0xf90 [nfnetlink] [<00000000505c614a>] nfnetlink_rcv+0x1bb/0x1f0 [nfnetlink] [<00000000eb78e1fe>] netlink_unicast+0x34b/0x480 [<00000000a8f72c94>] netlink_sendmsg+0x3af/0x690 [<000000009cb1ddf4>] sock_sendmsg+0x96/0xa0 [<0000000039d06e44>] ____sys_sendmsg+0x3fe/0x440 [<00000000137e82ca>] ___sys_sendmsg+0xd8/0x140 [<000000000c6bf6a6>] __sys_sendmsg+0xb3/0x130 [<0000000043bd6268>] do_syscall_64+0x40/0xb0 [<00000000afdebc2d>] entry_SYSCALL_64_after_hwframe+0x44/0xae Remove flow rule release from the offload commit path, otherwise error from the offload commit phase might trigger a double-free due to the execution of the abort_offload -> abort. After this patch, the abort path takes care of releasing the flow rule. This fix also needs to move the nft_flow_rule_create() call before the transaction object is added otherwise the abort path might find a NULL pointer to the flow rule object for the NFT_CHAIN_HW_OFFLOAD case. While at it, rename BASIC-like goto tags to slightly more meaningful names rather than adding a new "err3" tag. Fixes: 63b48c73ff56 ("netfilter: nf_tables_offload: undo updates if transaction fails") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 0fe29dd7019445b777087c620fa196da2ffb3852 Author: Jakub Kicinski Date: Fri Jun 18 13:34:06 2021 -0700 tls: prevent oversized sendfile() hangs by ignoring MSG_MORE [ Upstream commit d452d48b9f8b1a7f8152d33ef52cfd7fe1735b0a ] We got multiple reports that multi_chunk_sendfile test case from tls selftest fails. This was sort of expected, as the original fix was never applied (see it in the first Link:). The test in question uses sendfile() with count larger than the size of the underlying file. This will make splice set MSG_MORE on all sendpage calls, meaning TLS will never close and flush the last partial record. Eric seem to have addressed a similar problem in commit 35f9c09fe9c7 ("tcp: tcp_sendpages() should call tcp_push() once") by introducing MSG_SENDPAGE_NOTLAST. Unlike MSG_MORE MSG_SENDPAGE_NOTLAST is not set on the last call of a "pipefull" of data (PIPE_DEF_BUFFERS == 16, so every 16 pages or whenever we run out of data). Having a break every 16 pages should be fine, TLS can pack exactly 4 pages into a record, so for aligned reads there should be no difference, unaligned may see one extra record per sendpage(). Sticking to TCP semantics seems preferable to modifying splice, but we can revisit it if real life scenarios show a regression. Reported-by: Vadim Fedorenko Reported-by: Seth Forshee Link: https://lore.kernel.org/netdev/1591392508-14592-1-git-send-email-pooja.trivedi@stackpath.com/ Fixes: 3c4d7559159b ("tls: kernel TLS support") Signed-off-by: Jakub Kicinski Tested-by: Seth Forshee Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6f26c4e638cd20e5c46f37e86be0f03351471ec8 Author: Jakub Kicinski Date: Fri Jun 18 13:25:04 2021 -0700 selftests: tls: fix chacha+bidir tests [ Upstream commit 291c53e4dacd3a2cc3152d8af37f07f8496c594a ] ChaCha support did not adjust the bidirectional test. We need to set up KTLS in reverse direction correctly, otherwise these two cases will fail: tls.12_chacha.bidir tls.13_chacha.bidir Fixes: 4f336e88a870 ("selftests/tls: add CHACHA20-POLY1305 to tls selftests") Signed-off-by: Jakub Kicinski Acked-by: Vadim Fedorenko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f4b35106f13c1ebefb74a6496f794d1045973b64 Author: Jakub Kicinski Date: Fri Jun 18 13:25:03 2021 -0700 selftests: tls: clean up uninitialized warnings [ Upstream commit baa00119d69e3318da8d99867fc1170ebddf09ce ] A bunch of tests uses uninitialized stack memory as random data to send. This is harmless but generates compiler warnings. Explicitly init the buffers with random data. Signed-off-by: Jakub Kicinski Acked-by: Vadim Fedorenko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 99b0c836b3d88e43b8aad90db3d4d761a33c0348 Author: Yunsheng Lin Date: Thu Jun 17 09:04:14 2021 +0800 net: sched: add barrier to ensure correct ordering for lockless qdisc [ Upstream commit 89837eb4b2463c556a123437f242d6c2bc62ce81 ] The spin_trylock() was assumed to contain the implicit barrier needed to ensure the correct ordering between STATE_MISSED setting/clearing and STATE_MISSED checking in commit a90c57f2cedd ("net: sched: fix packet stuck problem for lockless qdisc"). But it turns out that spin_trylock() only has load-acquire semantic, for strongly-ordered system(like x86), the compiler barrier implicitly contained in spin_trylock() seems enough to ensure the correct ordering. But for weakly-orderly system (like arm64), the store-release semantic is needed to ensure the correct ordering as clear_bit() and test_bit() is store operation, see queued_spin_lock(). So add the explicit barrier to ensure the correct ordering for the above case. Fixes: a90c57f2cedd ("net: sched: fix packet stuck problem for lockless qdisc") Signed-off-by: Yunsheng Lin Acked-by: Jakub Kicinski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 754da271ff3e30eda55dee305c11f4c0f8fc37cd Author: Antoine Tenart Date: Fri Jun 18 17:15:53 2021 +0200 vrf: do not push non-ND strict packets with a source LLA through packet taps again [ Upstream commit 603113c514e95c3350598bc3cccbd03af7ea4ab2 ] Non-ND strict packets with a source LLA go through the packet taps again, while non-ND strict packets with other source addresses do not, and we can see a clone of those packets on the vrf interface (we should not). This is due to a series of changes: Commit 6f12fa775530[1] made non-ND strict packets not being pushed again in the packet taps. This changed with commit 205704c618af[2] for those packets having a source LLA, as they need a lookup with the orig_iif. The issue now is those packets do not skip the 'vrf_ip6_rcv' function to the end (as the ones without a source LLA) and go through the check to call packet taps again. This check was changed by commit 6f12fa775530[1] and do not exclude non-strict packets anymore. Packets matching 'need_strict && !is_ndisc && is_ll_src' are now being sent through the packet taps again. This can be seen by dumping packets on the vrf interface. Fix this by having the same code path for all non-ND strict packets and selectively lookup with the orig_iif for those with a source LLA. This has the effect to revert to the pre-205704c618af[2] condition, which should also be easier to maintain. [1] 6f12fa775530 ("vrf: mark skb for multicast or link-local as enslaved to VRF") [2] 205704c618af ("vrf: packets with lladdr src needs dst at input with orig_iif when needs strict") Fixes: 205704c618af ("vrf: packets with lladdr src needs dst at input with orig_iif when needs strict") Cc: Stephen Suryaputra Reported-by: Paolo Abeni Signed-off-by: Antoine Tenart Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 74a084743db0ad1d2987f59f64e2bd5fd3b5d898 Author: Cong Wang Date: Mon Jun 14 19:13:40 2021 -0700 skmsg: Teach sk_psock_verdict_apply() to return errors [ Upstream commit 1581a6c1c3291a8320b080f4411345f60229976d ] Currently sk_psock_verdict_apply() is void, but it handles some error conditions too. Its caller is impossible to learn whether it succeeds or fails, especially sk_psock_verdict_recv(). Make it return int to indicate error cases and propagate errors to callers properly. Fixes: ef5659280eb1 ("bpf, sockmap: Allow skipping sk_skb parser program") Signed-off-by: Cong Wang Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Acked-by: Jakub Sitnicki Link: https://lore.kernel.org/bpf/20210615021342.7416-7-xiyou.wangcong@gmail.com Signed-off-by: Sasha Levin commit a72fd1ef2ddf4cbf779778c69f747749662be85f Author: Cong Wang Date: Mon Jun 14 19:13:39 2021 -0700 skmsg: Fix a memory leak in sk_psock_verdict_apply() [ Upstream commit 0cf6672b23c8aa9d9274798dd63cbf6ede77ef90 ] If the dest psock does not set SK_PSOCK_TX_ENABLED, the skb can't be queued anywhere so must be dropped. This one is found during code review. Fixes: 799aa7f98d53 ("skmsg: Avoid lock_sock() in sk_psock_backlog()") Signed-off-by: Cong Wang Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Acked-by: Jakub Sitnicki Link: https://lore.kernel.org/bpf/20210615021342.7416-6-xiyou.wangcong@gmail.com Signed-off-by: Sasha Levin commit 60eef5b7eecb849a1e4c6babff7f6c5e6e52d479 Author: Cong Wang Date: Mon Jun 14 19:13:38 2021 -0700 skmsg: Clear skb redirect pointer before dropping it [ Upstream commit 30b9c54a707db4155735cf71f4600241c1b7b6ff ] When we drop skb inside sk_psock_skb_redirect(), we have to clear its skb->_sk_redir pointer too, otherwise kfree_skb() would misinterpret it as a valid skb->_skb_refdst and dst_release() would eventually complain. Fixes: e3526bb92a20 ("skmsg: Move sk_redir from TCP_SKB_CB to skb") Reported-by: Jiang Wang Signed-off-by: Cong Wang Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Acked-by: Jakub Sitnicki Link: https://lore.kernel.org/bpf/20210615021342.7416-5-xiyou.wangcong@gmail.com Signed-off-by: Sasha Levin commit b2265f3e7fbe222d0c801391621f54fd3288f3a8 Author: Cong Wang Date: Mon Jun 14 19:13:37 2021 -0700 udp: Fix a memory leak in udp_read_sock() [ Upstream commit e00a5c331bf57f41fcfdc5da4f5caeafe5e54c1d ] sk_psock_verdict_recv() clones the skb and uses the clone afterward, so udp_read_sock() should free the skb after using it, regardless of error or not. This fixes a real kmemleak. Fixes: d7f571188ecf ("udp: Implement ->read_sock() for sockmap") Signed-off-by: Cong Wang Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Acked-by: Jakub Sitnicki Link: https://lore.kernel.org/bpf/20210615021342.7416-4-xiyou.wangcong@gmail.com Signed-off-by: Sasha Levin commit 600a68d582b7372cd77f862a30fecfbd3583db09 Author: Cong Wang Date: Mon Jun 14 19:13:36 2021 -0700 selftests/bpf: Retry for EAGAIN in udp_redir_to_connected() [ Upstream commit a7e65fe7d8201527129206754db1a2db6a6b2fde ] We use non-blocking sockets for testing sockmap redirections, and got some random EAGAIN errors from UDP tests. There is no guarantee the packet would be immediately available to receive as soon as it is sent out, even on the local host. For UDP, this is especially true because it does not lock the sock during BH (unlike the TCP path). This is probably why we only saw this error in UDP cases. No matter how hard we try to make the queue empty check accurate, it is always possible for recvmsg() to beat ->sk_data_ready(). Therefore, we should just retry in case of EAGAIN. Fixes: d6378af615275 ("selftests/bpf: Add a test case for udp sockmap") Reported-by: Jiang Wang Signed-off-by: Cong Wang Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Acked-by: Jakub Sitnicki Link: https://lore.kernel.org/bpf/20210615021342.7416-3-xiyou.wangcong@gmail.com Signed-off-by: Sasha Levin commit 48c858a38ad25b06f4a7f86e81f8a50201901bc5 Author: Pavel Skripkin Date: Fri Jun 18 19:14:47 2021 +0300 net: ethernet: ezchip: fix error handling [ Upstream commit 0de449d599594f5472e00267d651615c7f2c6c1d ] As documented at drivers/base/platform.c for platform_get_irq: * Gets an IRQ for a platform device and prints an error message if finding the * IRQ fails. Device drivers should check the return value for errors so as to * not pass a negative integer value to the request_irq() APIs. So, the driver should check that platform_get_irq() return value is _negative_, not that it's equal to zero, because -ENXIO (return value from request_irq() if irq was not found) will pass this check and it leads to passing negative irq to request_irq() Fixes: 0dd077093636 ("NET: Add ezchip ethernet driver") Signed-off-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 062e01fdb28139ea71dc85d81f8fe687b3ade575 Author: Pavel Skripkin Date: Fri Jun 18 19:14:31 2021 +0300 net: ethernet: ezchip: fix UAF in nps_enet_remove [ Upstream commit e4b8700e07a86e8eab6916aa5c5ba99042c34089 ] priv is netdev private data, but it is used after free_netdev(). It can cause use-after-free when accessing priv pointer. So, fix it by moving free_netdev() after netif_napi_del() call. Fixes: 0dd077093636 ("NET: Add ezchip ethernet driver") Signed-off-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7e6f10fb798f18812341f400d9119b5a91cc7348 Author: Pavel Skripkin Date: Fri Jun 18 17:57:31 2021 +0300 net: ethernet: aeroflex: fix UAF in greth_of_remove [ Upstream commit e3a5de6d81d8b2199935c7eb3f7d17a50a7075b7 ] static int greth_of_remove(struct platform_device *of_dev) { ... struct greth_private *greth = netdev_priv(ndev); ... unregister_netdev(ndev); free_netdev(ndev); of_iounmap(&of_dev->resource[0], greth->regs, resource_size(&of_dev->resource[0])); ... } greth is netdev private data, but it is used after free_netdev(). It can cause use-after-free when accessing greth pointer. So, fix it by moving free_netdev() after of_iounmap() call. Fixes: d4c41139df6e ("net: Add Aeroflex Gaisler 10/100/1G Ethernet MAC driver") Signed-off-by: Pavel Skripkin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d07ebb093e084db7b54ea90b1c8c1e2209df58ba Author: Sean Wang Date: Thu Jun 17 09:39:19 2021 +0800 mt76: mt7921: fix the coredump is being truncated [ Upstream commit 723885a6750102e5d807429b3d06aa6b0d29cc66 ] Fix the maximum size of the coredump generated with current mt7921 firmware. Otherwise, a truncated coredump would be reported to userland via dev_coredumpv. Also, there is an additional error handling enhanced in the patch to avoid the possible invalid buffer access when the system failed to create the buffer to hold the coredump. Fixes: 0da3c795d07b ("mt76: mt7921: add coredump support") Co-developed-by: YN Chen Signed-off-by: YN Chen Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 29ba2ad0ff18355c85bc876c24a9490c55d3d89a Author: Sean Wang Date: Wed Jun 16 05:31:10 2021 +0800 mt76: mt7921: fix kernel warning when reset on vif is not sta [ Upstream commit 78b0328ff8c46fce64eb969d2572c3f631735dc1 ] ieee80211_disconnect is only called for the staton mode. [ 714.050429] WARNING: CPU: 1 PID: 382 at net/mac80211/mlme.c:2787 ieee80211_disconnect+0x108/0x118 [mac80211] [ 714.116704] Hardware name: MediaTek Asurada rev1 board (DT) [ 714.122303] Workqueue: mt76 mt7921_mac_reset_work [mt7921e] [ 714.127877] pstate: 20c00009 (nzCv daif +PAN +UAO) [ 714.132761] pc : ieee80211_disconnect+0x108/0x118 [mac80211] [ 714.138430] lr : mt7921_vif_connect_iter+0x28/0x54 [mt7921e] [ 714.144083] sp : ffffffc0107cbbd0 [ 714.147394] x29: ffffffc0107cbbd0 x28: ffffffb26c9cb928 [ 714.152706] x27: ffffffb26c9cbd98 x26: 0000000000000000 [ 714.158017] x25: 0000000000000003 x24: ffffffb26c9c9c38 [ 714.163328] x23: ffffffb26c9c9c38 x22: ffffffb26c9c8860 [ 714.168639] x21: ffffffb23b940000 x20: ffffffb26c9c8860 [ 714.173950] x19: 0000000000000001 x18: 000000000000b67e [ 714.179261] x17: 00000000064dd409 x16: ffffffd739cb28f0 [ 714.184571] x15: 0000000000000000 x14: 0000000000000227 [ 714.189881] x13: 0000000000000400 x12: ffffffd73a4eb060 [ 714.195191] x11: 0000000000000000 x10: 0000000000000000 [ 714.200502] x9 : ffffffd703a0a000 x8 : 0000000000000006 [ 714.205812] x7 : 2828282828282828 x6 : ffffffb200440396 [ 714.211122] x5 : 0000000000000000 x4 : 0000000000000004 [ 714.216432] x3 : 0000000000000000 x2 : ffffffb23b940c90 [ 714.221743] x1 : 0000000000000001 x0 : ffffffb23b940c90 [ 714.227054] Call trace: [ 714.229594] ieee80211_disconnect+0x108/0x118 [mac80211] [ 714.234913] mt7921_vif_connect_iter+0x28/0x54 [mt7921e] [ 714.240313] __iterate_interfaces+0xc4/0xdc [mac80211] [ 714.245541] ieee80211_iterate_interfaces+0x4c/0x68 [mac80211] [ 714.251381] mt7921_mac_reset_work+0x410/0x468 [mt7921e] [ 714.256696] process_one_work+0x208/0x3c8 [ 714.260706] worker_thread+0x23c/0x3e8 [ 714.264456] kthread+0x140/0x17c [ 714.267685] ret_from_fork+0x10/0x18 Fixes: 0c1ce9884607 ("mt76: mt7921: add wifi reset support") Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 611beba9b300a6438c949a1fec73f08470cf0fcb Author: Shayne Chen Date: Tue Jun 8 14:55:58 2021 +0800 mt76: mt7915: fix rx fcs error count in testmode [ Upstream commit 89043529c8b833d87391f1844e9d1cc1643393eb ] FCS error packets are filtered by default and won't be reported to driver, so that RX fcs error and PER in testmode always show zero. Fix this issue by reading fcs error count from hw counter. We did't fix this issue by disabling fcs error rx filter since it may let HW suffer some SER errors. Fixes: 5d8a83f09941 ("mt76: mt7915: implement testmode rx support") Signed-off-by: Shayne Chen Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 0a446c73492b77cc5bcd51aef1230b1a3672f67f Author: Lorenzo Bianconi Date: Sat Jun 5 13:46:03 2021 +0200 mt76: mt7921: wake the device before dumping power table [ Upstream commit 271fa685365842962f56651c9d1a33a0d0d3b30b ] Always wake the device up before dumping the single_sku power table otherwise the device can hang. Fixes: ea29acc97c555 ("mt76: mt7921: add dumping Tx power table") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 3acae0c71d2b7f4cb31f0cde4e490752457af56e Author: Ryder Lee Date: Mon May 17 12:45:58 2021 +0800 mt76: mt7915: fix MT_EE_CAL_GROUP_SIZE [ Upstream commit ee8ba94f9cc9afab570fd71ad421292f6360983c ] Fix wrong offset for pre-calibration data. Fixes: 495184ac91bb ("mt76: mt7915: add support for applying pre-calibration data") Signed-off-by: Ryder Lee Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 734f5fe1b8604ff03d92deb23cf4d6f816b745b8 Author: Ryder Lee Date: Thu Apr 22 06:20:03 2021 +0800 mt76: mt7615: fix potential overflow on large shift [ Upstream commit 3253f8fddd954aba9ac88ce3c34551dcca505b21 ] Fix the following static checker warning: error: undefined (user controlled) shift '(((1))) << (c->omac_idx)' Fixes: 402a695b1ae6 ("mt76: mt7615: fix CSA notification for DBDC") Reported-by: Dan Carpenter Signed-off-by: Ryder Lee Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 31635a9389f9ea9c2def9696abc65a749e8b6e25 Author: Lorenzo Bianconi Date: Thu May 27 13:35:30 2021 +0200 mt76: testmode: remove undefined behaviour in mt76_testmode_alloc_skb [ Upstream commit 223cea6d3c974acd393bfac2d168b2945a6cf1e5 ] Get rid of an undefined behaviour in mt76_testmode_alloc_skb routine allocating skb frames Fixes: 2601dda8faa76 ("mt76: testmode: add support to send larger packet") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 5b2deebec2b9599c64fed1a5102751ab3d8fee09 Author: Lorenzo Bianconi Date: Thu May 27 13:35:28 2021 +0200 mt76: testmode: fix memory leak in mt76_testmode_alloc_skb [ Upstream commit fe2c3b1fc64ea0c7a5b2ca2f671b4572ff99baf8 ] Free all pending frames in case of failure in mt76_testmode_alloc_skb routine Fixes: 2601dda8faa76 ("mt76: testmode: add support to send larger packet") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 2e25e8e35ab65bccc681a5b094b4e01d2144b978 Author: Lorenzo Bianconi Date: Sun May 23 23:08:05 2021 +0200 mt76: mt7921: do not schedule hw reset if the device is not running [ Upstream commit d74c4b5667425c35d74906795a08e02e29df5b46 ] Do not schedule hw full reset if the device is not fully initialized (e.g if the channel has not been configured yet). This patch fixes the kernel crash reported below [ 44.440266] mt7921e 0000:01:00.0: chip reset failed [ 44.527575] Unable to handle kernel paging request at virtual address ffffffc02f3e0000 [ 44.535771] Mem abort info: [ 44.538646] ESR = 0x96000006 [ 44.541792] EC = 0x25: DABT (current EL), IL = 32 bits [ 44.547268] SET = 0, FnV = 0 [ 44.550413] EA = 0, S1PTW = 0 [ 44.553648] Data abort info: [ 44.556613] ISV = 0, ISS = 0x00000006 [ 44.560563] CM = 0, WnR = 0 [ 44.563619] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000000955000 [ 44.570530] [ffffffc02f3e0000] pgd=100000003ffff003, p4d=100000003ffff003, pud=100000003ffff003, pmd=0000000000000000 [ 44.581489] Internal error: Oops: 96000006 [#1] SMP [ 44.606406] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 5.13.0-rc1-espressobin-12875-g6dc7f82ebc26 #33 [ 44.617264] Hardware name: Globalscale Marvell ESPRESSOBin Board (DT) [ 44.623905] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO BTYPE=--) [ 44.630100] pc : __queue_work+0x1f0/0x500 [ 44.634249] lr : __queue_work+0x1e8/0x500 [ 44.638384] sp : ffffffc010003d70 [ 44.641798] x29: ffffffc010003d70 x28: 0000000000000000 x27: ffffff8003989200 [ 44.649166] x26: ffffffc010c08510 x25: 0000000000000002 x24: ffffffc010ad90b0 [ 44.656533] x23: ffffffc010c08508 x22: 0000000000000012 x21: 0000000000000000 [ 44.663899] x20: ffffff8006385238 x19: ffffffc02f3e0000 x18: 00000000000003c9 [ 44.671266] x17: 0000000000000000 x16: 0000000000000000 x15: 000009b1a8a3bf90 [ 44.678632] x14: 0098968000000000 x13: 0000000000000000 x12: 0000000000000325 [ 44.685998] x11: ffffff803fda1928 x10: 0000000000000001 x9 : ffffffc010003e98 [ 44.693365] x8 : 0000000000000032 x7 : fff8000000000000 x6 : 0000000000000035 [ 44.700732] x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffffffc010adf700 [ 44.708098] x2 : ffffff8006385238 x1 : 000000007fffffff x0 : 0000000000000000 [ 44.715465] Call trace: [ 44.717982] __queue_work+0x1f0/0x500 [ 44.721760] delayed_work_timer_fn+0x18/0x20 [ 44.726167] call_timer_fn+0x2c/0x178 [ 44.729947] run_timer_softirq+0x488/0x5c8 [ 44.734172] _stext+0x11c/0x378 [ 44.737411] irq_exit+0x100/0x108 [ 44.740830] __handle_domain_irq+0x60/0xb0 [ 44.745059] gic_handle_irq+0x70/0x2b4 [ 44.748929] el1_irq+0xb8/0x13c [ 44.752167] arch_cpu_idle+0x14/0x30 [ 44.755858] default_idle_call+0x38/0x168 [ 44.759994] do_idle+0x1fc/0x210 [ 44.763325] cpu_startup_entry+0x20/0x58 [ 44.767372] rest_init+0xb8/0xc8 [ 44.770703] arch_call_rest_init+0xc/0x14 [ 44.774841] start_kernel+0x408/0x424 [ 44.778623] Code: aa1403e0 97fff54f aa0003f5 b5fff500 (f9400275) [ 44.784907] ---[ end trace be73c3142d8c36a9 ]--- [ 44.789668] Kernel panic - not syncing: Oops: Fatal exception in interrupt Fixes: 0c1ce9884607 ("mt76: mt7921: add wifi reset support") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit d26261090df50839cbc3f3d8648891d5cfd902bf Author: Sean Wang Date: Thu May 20 11:46:38 2021 +0800 mt76: mt7921: avoid unnecessary consecutive WiFi resets [ Upstream commit f07ac384b4579f294bb1e0380ed501156219ed71 ] Avoid unnecessary consecutive WiFi resets by dropping reset request when reset work is working. Co-developed-by: Lorenzo Bianconi Signed-off-by: Lorenzo Bianconi Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 7c041b2b416abfdc2c6f77e1221d8f1f60f7b821 Author: Sean Wang Date: Thu May 20 11:46:40 2021 +0800 mt76: mt7921: fix OMAC idx usage [ Upstream commit 213f87289ea01514acdbfeed9f65bcb5f12aef70 ] OMAC idx have to be same with BSS idx according to firmware usage. Fixes: e0f9fdda81bd ("mt76: mt7921: add ieee80211_ops") Reviewed-by: Lorenzo Bianconi Signed-off-by: Deren Wu Signed-off-by: YN Chen Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 7fd445618a314f4a5c229398e829f9b860a47ab1 Author: Sean Wang Date: Thu May 20 11:46:39 2021 +0800 mt76: mt7921: fix invalid register access in wake_work [ Upstream commit f86625ae0e35924ed495cdf0ff2d3133cb6e3010 ] Make sure mt7921_pm_wake_work wouldn't be scheduled after the driver is in suspend mode to fix the following the kernel crash. [ 3515.390012] mt7921e 0000:01:00.0: calling pci_pm_suspend+0x0/0x22c @ 2869, parent: 0000:00:00.0 [ 3515.390015] mt7921e 0000:01:00.0: mt7921_pci_suspend + [ 3515.396395] anx7625 3-0058: anx7625_suspend+0x0/0x6c returned 0 after 0 usecs [ 3515.405965] mt7921e 0000:01:00.0: mt7921_pci_suspend - [ 3515.411336] usb 1-1.4: usb_dev_suspend+0x0/0x2c returned 0 after 1 usecs [ 3515.411513] SError Interrupt on CPU7, code 0xbe000011 -- SError [ 3515.411515] CPU: 7 PID: 2849 Comm: kworker/u16:27 Not tainted 5.4.114 #44 [ 3515.411516] Hardware name: MediaTek Asurada rev1 board (DT) [ 3515.411517] Workqueue: mt76 mt7921_pm_wake_work [mt7921e] [ 3515.411518] pstate: 80c00009 (Nzcv daif +PAN +UAO) [ 3515.411519] pc : mt76_mmio_rr+0x30/0xf0 [mt76] [ 3515.411520] lr : mt7921_rr+0x38/0x44 [mt7921e] [ 3515.411520] sp : ffffffc015813c50 [ 3515.411521] x29: ffffffc015813c50 x28: 0000000000000402 [ 3515.411522] x27: ffffffe5a2012138 x26: ffffffe5a1eea018 [ 3515.411524] x25: 00000000328be505 x24: 00000000000a0002 [ 3515.411525] x23: 0000000000000006 x22: ffffffbd29b7a300 [ 3515.411527] x21: ffffffbd29b7a300 x20: 00000000000e0010 [ 3515.411528] x19: 00000000eac08f43 x18: 0000000000000000 [ 3515.411529] x17: 0000000000000000 x16: ffffffe5a16b2914 [ 3515.411531] x15: 0000000000000010 x14: 0000000000000010 [ 3515.411532] x13: 00000000003dd3a2 x12: 0000000000010000 [ 3515.411533] x11: ffffffe597abec14 x10: 0000000000000010 [ 3515.411535] x9 : ffffffe597abeba8 x8 : ffffffc013ce0010 [ 3515.411536] x7 : 000000b2b5593519 x6 : 0000000000300000 [ 3515.411537] x5 : 0000000000000000 x4 : 0000000000000032 [ 3515.411539] x3 : 0000000000000000 x2 : 0000000000000004 [ 3515.411540] x1 : 00000000000e0010 x0 : ffffffbd29b7a300 [ 3515.411542] Kernel panic - not syncing: Asynchronous SError Interrupt [ 3515.411543] CPU: 7 PID: 2849 Comm: kworker/u16:27 Not tainted 5.4.114 #44 [ 3515.411544] Hardware name: MediaTek Asurada rev1 board (DT) [ 3515.411544] Workqueue: mt76 mt7921_pm_wake_work [mt7921e] [ 3515.411545] Call trace: [ 3515.411546] dump_backtrace+0x0/0x14c [ 3515.411546] show_stack+0x20/0x2c [ 3515.411547] dump_stack+0xa0/0xfc [ 3515.411548] panic+0x154/0x350 [ 3515.411548] panic+0x0/0x350 [ 3515.411549] arm64_serror_panic+0x78/0x84 [ 3515.411550] do_serror+0x0/0x118 [ 3515.411550] do_serror+0xa4/0x118 [ 3515.411551] el1_error+0x84/0xf8 [ 3515.411552] mt76_mmio_rr+0x30/0xf0 [mt76] [ 3515.411552] mt7921_rr+0x38/0x44 [mt7921e] [ 3515.411553] __mt76_poll_msec+0x5c/0x9c [mt76] [ 3515.411554] __mt7921_mcu_drv_pmctrl+0x50/0x94 [mt7921e] [ 3515.411555] mt7921_mcu_drv_pmctrl+0x38/0xb0 [mt7921e] [ 3515.411555] mt7921_pm_wake_work+0x34/0xd4 [mt7921e] [ 3515.411556] process_one_work+0x208/0x3c8 [ 3515.411557] worker_thread+0x23c/0x3e8 [ 3515.411557] kthread+0x144/0x178 [ 3515.411558] ret_from_fork+0x10/0x18 [ 3515.418831] SMP: stopping secondary CPUs [ 3515.418832] Kernel Offset: 0x2590c00000 from 0xffffffc010000000 [ 3515.418832] PHYS_OFFSET: 0xffffffc400000000 [ 3515.418833] CPU features: 0x080026,2a80aa18 [ 3515.418834] Memory Limit: none [DL] 00000000 00000000 010701 Fixes: 1d8efc741df80 ("mt76: mt7921: introduce Runtime PM support") Co-developed-by: Lorenzo Bianconi Signed-off-by: Lorenzo Bianconi Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 9d9fb322b13d96e19448156e9cd26e1c7619daa5 Author: Sean Wang Date: Mon May 10 23:14:57 2021 +0800 mt76: mt7921: add back connection monitor support [ Upstream commit 10de032a31683585292cd10b598d896d7bcf276f ] Hw beacon cmd to the mt7921 firmware doesn't only filter out the beacon, but also performs its own connection monitoring, including periodic keep-alives to the AP and probing the AP on beacon loss. Will indicate the host with the event when the firmware detects the connection is lost. Fixes: 1d8efc741df8 ("mt76: mt7921: introduce Runtime PM support") Reviewed-by: Lorenzo Bianconi Signed-off-by: Deren Wu Signed-off-by: YN Chen Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit fcab20e23e3cbb13e114030eb411bcd94fc868f7 Author: Sean Wang Date: Mon May 10 23:14:55 2021 +0800 mt76: mt7921: consider the invalid value for to_rssi [ Upstream commit edb5aebc1c3db312e74e1dcf75b8626ee5300596 ] It is possible the RCPI from the certain antenna is an invalid value, especially packets are receiving while the system is frequently entering deep sleep mode, so consider calculating RSSI with the reasonable upper bound to avoid report the wrong value to the mac80211 layer. Fixes: 163f4d22c118 ("mt76: mt7921: add MAC support") Reviewed-by: Lorenzo Bianconi Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit a889b3e5efbb527d60909dc04db87eb12846e83f Author: YN Chen Date: Mon May 10 23:14:54 2021 +0800 mt76: connac: fix WoW with disconnetion and bitmap pattern [ Upstream commit 193e5f22eeb2a9661bff8bc0d8519e6ded48c807 ] Update MCU command usage to fix WoW configuration with disconnection and bitmap pattern and to avoid magic number. Fixes: ffa1bf97425b ("mt76: mt7921: introduce PM support") Reviewed-by: Lorenzo Bianconi Signed-off-by: YN Chen Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 3c72c4f4013b1d1ee544898192b961e4b6570f06 Author: Sean Wang Date: Mon May 10 23:14:51 2021 +0800 mt76: connac: fw_own rely on all packet memory all being free [ Upstream commit 4bfa291251623486711693a69d9eaa539478d340 ] If the device is MMIO-based, we must ensure all TxD/TxP on the host memory all being consumed by the device prior to safely switching to fw_own state. Fixes: ec7bd7b4a9c0 ("mt76: connac: check wake refcount in mcu_fw_pmctrl") Reviewed-by: Lorenzo Bianconi Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 7966772888c31f898812279c20dbd81e8a3d6791 Author: Sean Wang Date: Mon May 10 23:14:50 2021 +0800 mt76: mt7921: Don't alter Rx path classifier [ Upstream commit 2c80c02a682aefc073df2cfbb48c77c74579cb4a ] Keep Rx path classifier the mt7921 firmware prefers to allow frames pass through MCU. Fixes: 5c14a5f944b9 ("mt76: mt7921: introduce mt7921e support") Reviewed-by: Lorenzo Bianconi Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit ca72aaa9bdebf64ed493fa4893393e9f429fe107 Author: Sean Wang Date: Mon May 10 23:14:49 2021 +0800 mt76: mt7921: fix mt7921_wfsys_reset sequence [ Upstream commit 20eb83c749609199443972cf80fb6004fc36afc6 ] WiFi subsytem reset should control MT_WFSYS_SW_RST_B and then poll the same register until the bit WFSYS_SW_INIT_DONE bit is set. Fixes: 0c1ce9884607 ("mt76: mt7921: add wifi reset support") Reviewed-by: Lorenzo Bianconi Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 6d4004306f3a64165870d8c1206a417247afe9c0 Author: Lorenzo Bianconi Date: Tue Apr 27 12:07:14 2021 +0200 mt76: mt7615: fix NULL pointer dereference in tx_prepare_skb() [ Upstream commit 8d3cdc1bbb1d355f0ebef973175ae5fd74286feb ] Fix theoretical NULL pointer dereference in mt7615_tx_prepare_skb and mt7663_usb_sdio_tx_prepare_skb routines. This issue has been identified by code analysis. Fixes: 6aa4ed7927f11 ("mt76: mt7615: implement DMA support for MT7622") Fixes: 4bb586bc33b98 ("mt76: mt7663u: sync probe sampling with rate configuration") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit fb63ea6702f4330e0267db4ab13f92376c4c954e Author: Lorenzo Bianconi Date: Tue Apr 27 12:05:00 2021 +0200 mt76: fix possible NULL pointer dereference in mt76_tx [ Upstream commit d7400a2f3e295b8cee692c7a66e10f60015a3c37 ] Even if this is not a real issue since mt76_tx is never run with wcid set to NULL, fix a theoretical NULL pointer dereference in mt76_tx routine Fixes: db9f11d3433f7 ("mt76: store wcid tx rate info in one u32 reduce locking") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 57fa5990a28dd1c16620a7ea0f1915e9a969bda9 Author: Dan Carpenter Date: Mon May 3 17:53:59 2021 +0300 mt76: mt7915: fix a signedness bug in mt7915_mcu_apply_tx_dpd() [ Upstream commit 861fad474ec7638aeca46a508da4ea81612374b9 ] "idx" needs to be signed for the error handling to work. Fixes: 495184ac91bb ("mt76: mt7915: add support for applying pre-calibration data") Signed-off-by: Dan Carpenter Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit ba9232736dd4408dabe40fa626cad034b1b183c0 Author: Pavel Machek Date: Fri Jun 18 11:35:26 2021 +0200 net: pxa168_eth: Fix a potential data race in pxa168_eth_remove [ Upstream commit bd70957438f0cc4879cbdff8bbc8614bc1cddf49 ] Commit 0571a753cb07 cancelled delayed work too late, keeping small race. Cancel work sooner to close it completely. Signed-off-by: Pavel Machek (CIP) Fixes: 0571a753cb07 ("net: pxa168_eth: Fix a potential data race in pxa168_eth_remove") Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a00c9faf7efa106a69a67408dd83dbc962887351 Author: Wang Hai Date: Wed Jun 16 12:25:34 2021 +0800 samples/bpf: Fix the error return code of xdp_redirect's main() [ Upstream commit 7c6090ee2a7b3315410cfc83a94c3eb057407b25 ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. If bpf_map_update_elem() failed, main() should return a negative error. Fixes: 832622e6bd18 ("xdp: sample program for new bpf_redirect helper") Signed-off-by: Wang Hai Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210616042534.315097-1-wanghai38@huawei.com Signed-off-by: Sasha Levin commit 9abfeb4e2c5fd54497d9f97d1c87ef78db51d1e7 Author: Wang Hai Date: Wed Jun 16 12:23:24 2021 +0800 samples/bpf: Fix Segmentation fault for xdp_redirect command [ Upstream commit 85102ba58b4125ebad941d7555c3c248b23efd16 ] A Segmentation fault error is caused when the following command is executed. $ sudo ./samples/bpf/xdp_redirect lo Segmentation fault This command is missing a device as an argument, resulting in out-of-bounds access from argv. If the number of devices for the xdp_redirect parameter is not 2, we should report an error and exit. Fixes: 24251c264798 ("samples/bpf: add option for native and skb mode for redirect apps") Signed-off-by: Wang Hai Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210616042324.314832-1-wanghai38@huawei.com Signed-off-by: Sasha Levin commit a6f6a2fe3f2c0c84b93afd2ac9890e2e488ff51e Author: Xi Wang Date: Fri Jun 11 14:14:49 2021 +0800 RDMA/hns: Clear extended doorbell info before using [ Upstream commit 7e78dd816e458fbc2928a068d70009178d5d070d ] Both of HIP08 and HIP09 require the extended doorbell information to be cleared before being used. Fixes: 6b63597d3540 ("RDMA/hns: Add TSQ link table support") Link: https://lore.kernel.org/r/1623392089-35639-1-git-send-email-liweihang@huawei.com Signed-off-by: Xi Wang Signed-off-by: Weihang Li Reviewed-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit fffdf02df829a491c5d57c65b3fa73d3d3719cd6 Author: Jack Wang Date: Mon Jun 14 11:03:33 2021 +0200 RDMA/rtrs-srv: Set minimal max_send_wr and max_recv_wr [ Upstream commit 5e91eabf66c854f16ca2e954e5c68939bc81601e ] Currently rtrs when create_qp use a coarse numbers (bigger in general), which leads to hardware create more resources which only waste memory with no benefits. For max_send_wr, we don't really need alway max_qp_wr size when creating qp, reduce it to cq_size. For max_recv_wr, cq_size is enough. With the patch when sess_queue_depth=128, per session (2 paths) memory consumption reduced from 188 MB to 65MB When always_invalidate is enabled, we need send more wr, so treat it special. Fixes: 9cb837480424e ("RDMA/rtrs: server: main functionality") Link: https://lore.kernel.org/r/20210614090337.29557-2-jinpu.wang@ionos.com Signed-off-by: Jack Wang Reviewed-by: Md Haris Iqbal Signed-off-by: Gioh Kim Reviewed-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 3cb841954361cb296f22e1f00d2532c4feb870d6 Author: Tony Ambardar Date: Thu Jun 17 23:14:04 2021 -0700 bpf: Fix libelf endian handling in resolv_btfids [ Upstream commit 61e8aeda9398925f8c6fc290585bdd9727d154c4 ] The vmlinux ".BTF_ids" ELF section is declared in btf_ids.h to hold a list of zero-filled BTF IDs, which is then patched at link-time with correct values by resolv_btfids. The section is flagged as "allocable" to preclude compression, but notably the section contents (BTF IDs) are untyped. When patching the BTF IDs, resolve_btfids writes in host-native endianness and relies on libelf for any required translation on reading and updating vmlinux. However, since the type of the .BTF_ids section content defaults to ELF_T_BYTE (i.e. unsigned char), no translation occurs. This results in incorrect patched values when cross-compiling to non-native endianness, and can manifest as kernel Oops and test failures which are difficult to troubleshoot [1]. Explicitly set the type of patched data to ELF_T_WORD, the architecture- neutral ELF type corresponding to the u32 BTF IDs. This enables libelf to transparently perform any needed endian conversions. Fixes: fbbb68de80a4 ("bpf: Add resolve_btfids tool to resolve BTF IDs in ELF object") Signed-off-by: Tony Ambardar Signed-off-by: Daniel Borkmann Acked-by: Jiri Olsa Cc: Frank Eigler Cc: Mark Wielaard Cc: Jiri Olsa Cc: Yonghong Song Link: https://lore.kernel.org/bpf/CAPGftE_eY-Zdi3wBcgDfkz_iOr1KF10n=9mJHm1_a_PykcsoeA@mail.gmail.com [1] Link: https://lore.kernel.org/bpf/20210618061404.818569-1-Tony.Ambardar@gmail.com Signed-off-by: Sasha Levin commit 01faf195e6383a307e6ebdee6d72454afc7bea7b Author: Magnus Karlsson Date: Fri Jun 18 09:58:05 2021 +0200 xsk: Fix broken Tx ring validation [ Upstream commit f654fae47e83e56b454fbbfd0af0a4f232e356d6 ] Fix broken Tx ring validation for AF_XDP. The commit under the Fixes tag, fixed an off-by-one error in the validation but introduced another error. Descriptors are now let through even if they straddle a chunk boundary which they are not allowed to do in aligned mode. Worse is that they are let through even if they straddle the end of the umem itself, tricking the kernel to read data outside the allowed umem region which might or might not be mapped at all. Fix this by reintroducing the old code, but subtract the length by one to fix the off-by-one error that the original patch was addressing. The test chunk != chunk_end makes sure packets do not straddle chunk boundraries. Note that packets of zero length are allowed in the interface, therefore the test if the length is non-zero. Fixes: ac31565c2193 ("xsk: Fix for xp_aligned_validate_desc() when len == chunk_size") Signed-off-by: Magnus Karlsson Signed-off-by: Daniel Borkmann Reviewed-by: Xuan Zhuo Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20210618075805.14412-1-magnus.karlsson@gmail.com Signed-off-by: Sasha Levin commit 85912942f7fb43b092e1af157ec7e1a318e2a290 Author: Magnus Karlsson Date: Thu Jun 17 11:22:55 2021 +0200 xsk: Fix missing validation for skb and unaligned mode [ Upstream commit 2f99619820c2269534eb2c0cde44870313c6d353 ] Fix a missing validation of a Tx descriptor when executing in skb mode and the umem is in unaligned mode. A descriptor could point to a buffer straddling the end of the umem, thus effectively tricking the kernel to read outside the allowed umem region. This could lead to a kernel crash if that part of memory is not mapped. In zero-copy mode, the descriptor validation code rejects such descriptors by checking a bit in the DMA address that tells us if the next page is physically contiguous or not. For the last page in the umem, this bit is not set, therefore any descriptor pointing to a packet straddling this last page boundary will be rejected. However, the skb path does not use this bit since it copies out data and can do so to two different pages. (It also does not have the array of DMA address, so it cannot even store this bit.) The code just returned that the packet is always physically contiguous. But this is unfortunately also returned for the last page in the umem, which means that packets that cross the end of the umem are being allowed, which they should not be. Fix this by introducing a check for this in the SKB path only, not penalizing the zero-copy path. Fixes: 2b43470add8c ("xsk: Introduce AF_XDP buffer allocation API") Signed-off-by: Magnus Karlsson Signed-off-by: Daniel Borkmann Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20210617092255.3487-1-magnus.karlsson@gmail.com Signed-off-by: Sasha Levin commit 95599ef3256c59c25223a57fdd45f382a34f08f1 Author: Andrii Nakryiko Date: Thu Jun 17 17:28:24 2021 -0700 selftests/bpf: Fix ringbuf test fetching map FD [ Upstream commit 0c38740c08962ab109267cb23f4a40df2ccf2bbf ] Seems like 4d1b62986125 ("selftests/bpf: Convert few tests to light skeleton.") and 704e2beba23c ("selftests/bpf: Test ringbuf mmap read-only and read-write restrictions") were done independently on bpf and bpf-next trees and are in conflict with each other, despite a clean merge. Fix fetching of ringbuf's map_fd to use light skeleton properly. Fixes: 704e2beba23c ("selftests/bpf: Test ringbuf mmap read-only and read-write restrictions") Fixes: 4d1b62986125 ("selftests/bpf: Convert few tests to light skeleton.") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20210618002824.2081922-1-andrii@kernel.org Signed-off-by: Sasha Levin commit bb563904596107404e698b8d09fa95ca023b25c0 Author: Daniel Xu Date: Wed Jun 16 14:52:11 2021 -0700 selftests/bpf: Whitelist test_progs.h from .gitignore [ Upstream commit 809ed84de8b3f2fd7b1d06efb94bf98fd318a7d7 ] Somehow test_progs.h was being included by the existing rule: /test_progs* This is bad because: 1) test_progs.h is a checked in file 2) grep-like tools like ripgrep[0] respect gitignore and test_progs.h was being hidden from searches [0]: https://github.com/BurntSushi/ripgrep Fixes: 74b5a5968fe8 ("selftests/bpf: Replace test_progs and test_maps w/ general rule") Signed-off-by: Daniel Xu Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/a46f64944bf678bc652410ca6028d3450f4f7f4b.1623880296.git.dxu@dxuuu.xyz Signed-off-by: Sasha Levin commit f35dd32ac5026e276cc8730262a91b98f23342fc Author: Bob Pearson Date: Fri Jun 4 18:05:59 2021 -0500 RDMA/rxe: Fix qp reference counting for atomic ops [ Upstream commit 15ae1375ea91ae2dee6f12d71a79d8c0a10a30bf ] Currently the rdma_rxe driver attempts to protect atomic responder resources by taking a reference to the qp which is only freed when the resource is recycled for a new read or atomic operation. This means that in normal circumstances there is almost always an extra qp reference once an atomic operation has been executed which prevents cleaning up the qp and associated pd and cqs when the qp is destroyed. This patch removes the call to rxe_add_ref() in send_atomic_ack() and the call to rxe_drop_ref() in free_rd_atomic_resource(). If the qp is destroyed while a peer is retrying an atomic op it will cause the operation to fail which is acceptable. Link: https://lore.kernel.org/r/20210604230558.4812-1-rpearsonhpe@gmail.com Reported-by: Zhu Yanjun Fixes: 86af61764151 ("IB/rxe: remove unnecessary skb_clone") Signed-off-by: Bob Pearson Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit d8a190f35b3b1c6d5a29ee3f0ae069c89f3608b8 Author: Pablo Neira Ayuso Date: Fri Jun 11 19:26:56 2021 +0200 netfilter: nft_tproxy: restrict support to TCP and UDP transport protocols [ Upstream commit 52f0f4e178c757b3d356087376aad8bd77271828 ] Add unfront check for TCP and UDP packets before performing further processing. Fixes: 4ed8eb6570a4 ("netfilter: nf_tables: Add native tproxy support") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit da0fa9a91fbde67ae819614621a031b7755ed003 Author: Pablo Neira Ayuso Date: Thu Jun 10 20:20:31 2021 +0200 netfilter: nft_osf: check for TCP packet before further processing [ Upstream commit 8f518d43f89ae00b9cf5460e10b91694944ca1a8 ] The osf expression only supports for TCP packets, add a upfront sanity check to skip packet parsing if this is not a TCP packet. Fixes: b96af92d6eaf ("netfilter: nf_tables: implement Passive OS fingerprint module in nft_osf") Signed-off-by: Pablo Neira Ayuso Reported-by: kernel test robot Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 34a76bb820d6f077272709dfdd634767cc1d7852 Author: Pablo Neira Ayuso Date: Thu Jun 10 20:20:30 2021 +0200 netfilter: nft_exthdr: check for IPv6 packet before further processing [ Upstream commit cdd73cc545c0fb9b1a1f7b209f4f536e7990cff4 ] ipv6_find_hdr() does not validate that this is an IPv6 packet. Add a sanity check for calling ipv6_find_hdr() to make sure an IPv6 packet is passed for parsing. Fixes: 96518518cc41 ("netfilter: add nftables") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 803ffe5f1fa58e507dd879aebd89d814a064ccf5 Author: Leon Romanovsky Date: Mon May 31 19:04:44 2021 +0300 RDMA/mlx5: Don't add slave port to unaffiliated list [ Upstream commit 7ce6095e3bff8e20ce018b050960b527e298f7df ] The mlx5_ib_bind_slave_port() doesn't remove multiport device from the unaffiliated list, but mlx5_ib_unbind_slave_port() did it. This unbalanced flow caused to the situation where mlx5_ib_unaffiliated_port_list was changed during iteration. Fixes: 32f69e4be269 ("{net, IB}/mlx5: Manage port association for multiport RoCE") Link: https://lore.kernel.org/r/2726e6603b1e6ecfe76aa5a12a063af72173bcf7.1622477058.git.leonro@nvidia.com Reported-by: Dan Carpenter Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit e3fdf2f3cbbf274e2e1b5e43dacdf404664ffa38 Author: Liu Shixin Date: Tue Jun 15 10:14:44 2021 +0800 netlabel: Fix memory leak in netlbl_mgmt_add_common [ Upstream commit b8f6b0522c298ae9267bd6584e19b942a0636910 ] Hulk Robot reported memory leak in netlbl_mgmt_add_common. The problem is non-freed map in case of netlbl_domhsh_add() failed. BUG: memory leak unreferenced object 0xffff888100ab7080 (size 96): comm "syz-executor537", pid 360, jiffies 4294862456 (age 22.678s) hex dump (first 32 bytes): 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 ................ backtrace: [<0000000008b40026>] netlbl_mgmt_add_common.isra.0+0xb2a/0x1b40 [<000000003be10950>] netlbl_mgmt_add+0x271/0x3c0 [<00000000c70487ed>] genl_family_rcv_msg_doit.isra.0+0x20e/0x320 [<000000001f2ff614>] genl_rcv_msg+0x2bf/0x4f0 [<0000000089045792>] netlink_rcv_skb+0x134/0x3d0 [<0000000020e96fdd>] genl_rcv+0x24/0x40 [<0000000042810c66>] netlink_unicast+0x4a0/0x6a0 [<000000002e1659f0>] netlink_sendmsg+0x789/0xc70 [<000000006e43415f>] sock_sendmsg+0x139/0x170 [<00000000680a73d7>] ____sys_sendmsg+0x658/0x7d0 [<0000000065cbb8af>] ___sys_sendmsg+0xf8/0x170 [<0000000019932b6c>] __sys_sendmsg+0xd3/0x190 [<00000000643ac172>] do_syscall_64+0x37/0x90 [<000000009b79d6dc>] entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: 63c416887437 ("netlabel: Add network address selectors to the NetLabel/LSM domain mapping") Reported-by: Hulk Robot Signed-off-by: Liu Shixin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4074391995a6b589a6261a0cd6147e978632bd21 Author: Johannes Berg Date: Mon Apr 26 21:29:30 2021 +0200 wil6210: remove erroneous wiphy locking [ Upstream commit 8f78caa2264ece71c2e207cba023f28ab6665138 ] We already hold the wiphy lock in all cases when we get here, so this would deadlock, remove the erroneous locking. Fixes: a05829a7222e ("cfg80211: avoid holding the RTNL when calling the driver") Signed-off-by: Johannes Berg Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210426212929.83f1de07c2cd.I630a2a00eff185ba0452324b3d3f645e01128a95@changeid Signed-off-by: Sasha Levin commit c497a0c9c4571e4836a697eb48aafcccb160946a Author: Seevalamuthu Mariappan Date: Tue May 25 15:30:28 2021 +0200 ath11k: send beacon template after vdev_start/restart during csa [ Upstream commit 979ebc54cf13bd1e3eb6e21766d208d5de984fb8 ] Firmware has added assert if beacon template is received after vdev_down. Firmware expects beacon template after vdev_start and before vdev_up. This change is needed to support MBSSID EMA cases in firmware. Hence, Change the sequence in ath11k as expected from firmware. This new change is not causing any issues with older firmware. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1.r3-00011-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1.r4-00008-QCAHKSWPL_SILICONZ-1 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Seevalamuthu Mariappan [sven@narfation.org: added tested-on/fixes information] Signed-off-by: Sven Eckelmann Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210525133028.2805615-1-sven@narfation.org Signed-off-by: Sasha Levin commit 7f72b0b6c15a284c5851f6c8ece5528d46e68419 Author: Yang Li Date: Tue May 25 18:46:17 2021 +0800 ath10k: Fix an error code in ath10k_add_interface() [ Upstream commit e9ca70c735ce66fc6a0e02c8b6958434f74ef8de ] When the code execute this if statement, the value of ret is 0. However, we can see from the ath10k_warn() log that the value of ret should be -EINVAL. Clean up smatch warning: drivers/net/wireless/ath/ath10k/mac.c:5596 ath10k_add_interface() warn: missing error code 'ret' Reported-by: Abaci Robot Fixes: ccec9038c721 ("ath10k: enable raw encap mode and software crypto engine") Signed-off-by: Yang Li Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1621939577-62218-1-git-send-email-yang.lee@linux.alibaba.com Signed-off-by: Sasha Levin commit ab8fee33b6ecc63ba8b322c0c03c66a3552b3b32 Author: Christophe JAILLET Date: Sat May 22 11:50:54 2021 +0200 ath11k: Fix an error handling path in ath11k_core_fetch_board_data_api_n() [ Upstream commit 515bda1d1e51c64edf2a384a58801f85a80a3f2d ] All error paths but this one 'goto err' in order to release some resources. Fix this. Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Christophe JAILLET Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/e959eb544f3cb04258507d8e25a6f12eab126bde.1621676864.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit fdb3f590eb4aca12c18eecc57ff4333e105ea0f8 Author: Hang Zhang Date: Fri May 21 15:32:38 2021 -0700 cw1200: Revert unnecessary patches that fix unreal use-after-free bugs [ Upstream commit 3f60f4685699aa6006e58e424637e8e413e0a94d ] A previous commit 4f68ef64cd7f ("cw1200: Fix concurrency use-after-free bugs in cw1200_hw_scan()") tried to fix a seemingly use-after-free bug between cw1200_bss_info_changed() and cw1200_hw_scan(), where the former frees a sk_buff pointed to by frame.skb, and the latter accesses the sk_buff pointed to by frame.skb. However, this issue should be a false alarm because: (1) "frame.skb" is not a shared variable between the above two functions, because "frame" is a local function variable, each of the two functions has its own local "frame" - they just happen to have the same variable name. (2) the sk_buff(s) pointed to by these two "frame.skb" are also two different object instances, they are individually allocated by different dev_alloc_skb() within the two above functions. To free one object instance will not invalidate the access of another different one. Based on these facts, the previous commit should be unnecessary. Moreover, it also introduced a missing unlock which was addressed in a subsequent commit 51c8d24101c7 ("cw1200: fix missing unlock on error in cw1200_hw_scan()"). Now that the original use-after-free is unreal, these two commits should be reverted. This patch performs the reversion. Fixes: 4f68ef64cd7f ("cw1200: Fix concurrency use-after-free bugs in cw1200_hw_scan()") Fixes: 51c8d24101c7 ("cw1200: fix missing unlock on error in cw1200_hw_scan()") Signed-off-by: Hang Zhang Acked-by: Jia-Ju Bai Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210521223238.25020-1-zh.nvgt@gmail.com Signed-off-by: Sasha Levin commit eb6219ebf416494c3bbd65031a23021fbaf3efd8 Author: Christophe JAILLET Date: Wed May 12 22:58:30 2021 +0200 brcmsmac: mac80211_if: Fix a resource leak in an error handling path [ Upstream commit 9a25344d5177c2b9285532236dc3d10a091f39a8 ] If 'brcms_attach()' fails, we must undo the previous 'ieee80211_alloc_hw()' as already done in the remove function. Fixes: 5b435de0d786 ("net: wireless: add brcm80211 drivers") Signed-off-by: Christophe JAILLET Acked-by: Arend van Spriel Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/8fbc171a1a493b38db5a6f0873c6021fca026a6c.1620852921.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit f257ee3efae5a647eaf48886fb993997cf3ab62e Author: Matthias Brugger Date: Wed Jun 2 16:43:05 2021 +0200 brcmfmac: Delete second brcm folder hierarchy [ Upstream commit 4a26aafe4886a4ec9965171c280ce16df30dc362 ] BRCMF_FW_DEFAULT_PATH already defines the brcm folder, delete the second folder to match with Linux firmware repository layout. Fixes: 75729e110e68 ("brcmfmac: expose firmware config files through modinfo") Signed-off-by: Matthias Brugger Reviewed-by: Hans de Goede Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210602144305.4481-1-matthias.bgg@kernel.org Signed-off-by: Sasha Levin commit 837f0c940b49af2e1cd0088c1108dd0c22594577 Author: Tong Tiangen Date: Tue Jun 1 18:01:28 2021 +0800 brcmfmac: Fix a double-free in brcmf_sdio_bus_reset [ Upstream commit 7ea7a1e05c7ff5ffc9f9ec1f0849f6ceb7fcd57c ] brcmf_sdiod_remove has been called inside brcmf_sdiod_probe when fails, so there's no need to call another one. Otherwise, sdiodev->freezer would be double freed. Fixes: 7836102a750a ("brcmfmac: reset SDIO bus on a firmware crash") Signed-off-by: Tong Tiangen Reviewed-by: Arend van Spriel Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210601100128.69561-1-tongtiangen@huawei.com Signed-off-by: Sasha Levin commit 35bb54ed3124695e3638470976f0b6334258479c Author: Alvin Šipraga Date: Thu May 6 13:20:12 2021 +0000 brcmfmac: correctly report average RSSI in station info [ Upstream commit 9a1590934d9a02e570636432b93052c0c035f31f ] The rx_lastpkt_rssi field provided by the firmware is suitable for NL80211_STA_INFO_{SIGNAL,CHAIN_SIGNAL}, while the rssi field is an average. Fix up the assignments and set the correct STA_INFO bits. This lets userspace know that the average RSSI is part of the station info. Fixes: cae355dc90db ("brcmfmac: Add RSSI information to get_station.") Signed-off-by: Alvin Šipraga Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210506132010.3964484-2-alsi@bang-olufsen.dk Signed-off-by: Sasha Levin commit da997cc14d9b7daba19dc84eecaee4c5bd6b8d45 Author: Alvin Šipraga Date: Thu May 6 13:20:12 2021 +0000 brcmfmac: fix setting of station info chains bitmask [ Upstream commit feb45643762172110cb3a44f99dd54304f33b711 ] The sinfo->chains field is a bitmask for filled values in chain_signal and chain_signal_avg, not a count. Treat it as such so that the driver can properly report per-chain RSSI information. Before (MIMO mode): $ iw dev wlan0 station dump ... signal: -51 [-51] dBm After (MIMO mode): $ iw dev wlan0 station dump ... signal: -53 [-53, -54] dBm Fixes: cae355dc90db ("brcmfmac: Add RSSI information to get_station.") Signed-off-by: Alvin Šipraga Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210506132010.3964484-1-alsi@bang-olufsen.dk Signed-off-by: Sasha Levin commit aa68a411acd049b06284e15d39b1b6ec5f42fd57 Author: Zhen Lei Date: Sat May 15 15:29:49 2021 +0800 ssb: Fix error return code in ssb_bus_scan() [ Upstream commit 77a0989baa427dbd242c5784d05a53ca3d197d43 ] Fix to return -EINVAL from the error handling case instead of 0, as done elsewhere in this function. Fixes: 61e115a56d1a ("[SSB]: add Sonics Silicon Backplane bus support") Reported-by: Hulk Robot Signed-off-by: Zhen Lei Acked-by: Michael Büsch Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210515072949.7151-1-thunder.leizhen@huawei.com Signed-off-by: Sasha Levin commit 88d70c35d1bfb7de38612dbec0853a16848ad35a Author: Chris Wilson Date: Fri Jun 11 08:08:38 2021 +0200 drm/i915/selftests: Reorder tasklet_disable vs local_bh_disable [ Upstream commit 2328e1b35ac2bb003236c3268aabe456ffab8b56 ] Due to a change in requirements that disallows tasklet_disable() being called from atomic context, rearrange the selftest to avoid doing so. <3> [324.942939] BUG: sleeping function called from invalid context at kernel/softirq.c:888 <3> [324.942952] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 5601, name: i915_selftest <4> [324.942960] 1 lock held by i915_selftest/5601: <4> [324.942963] #0: ffff888101d19240 (&dev->mutex){....}-{3:3}, at: device_driver_attach+0x18/0x50 <3> [324.942987] Preemption disabled at: <3> [324.942990] [] live_hold_reset.part.65+0xc2/0x2f0 [i915] <4> [324.943255] CPU: 0 PID: 5601 Comm: i915_selftest Tainted: G U 5.13.0-rc5-CI-CI_DRM_10197+ #1 <4> [324.943259] Hardware name: Intel Corp. Geminilake/GLK RVP2 LP4SD (07), BIOS GELKRVPA.X64.0062.B30.1708222146 08/22/2017 <4> [324.943263] Call Trace: <4> [324.943267] dump_stack+0x7f/0xad <4> [324.943276] ___might_sleep.cold.123+0xf2/0x106 <4> [324.943286] tasklet_unlock_wait+0x2e/0xb0 <4> [324.943291] ? ktime_get_raw+0x81/0x120 <4> [324.943305] live_hold_reset.part.65+0x1ab/0x2f0 [i915] <4> [324.943500] __i915_subtests.cold.7+0x42/0x92 [i915] <4> [324.943723] ? __i915_live_teardown+0x50/0x50 [i915] <4> [324.943922] ? __intel_gt_live_setup+0x30/0x30 [i915] Fixes: da044747401fc ("tasklets: Replace spin wait in tasklet_unlock_wait()") Signed-off-by: Chris Wilson Reviewed-by: Thomas Hellström Signed-off-by: Matthew Auld Link: https://patchwork.freedesktop.org/patch/msgid/20210611060838.647973-1-thomas.hellstrom@linux.intel.com (cherry picked from commit 35c6367f516090a3086d37e7023b08608d555aba) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit c1df1d2271da5fd14d8b648683b67dd10063a82b Author: Sasha Levin Date: Sun Jul 4 10:33:21 2021 -0400 net: wwan: Fix WWAN config symbols [ Upstream commit 89212e160b81e778f829b89743570665810e3b13 ] There is not strong reason to have both WWAN and WWAN_CORE symbols, Let's build the WWAN core framework when WWAN is selected, in the same way as for other subsystems. This fixes issue with mhi_net selecting WWAN_CORE without WWAN and reported by kernel test robot: Kconfig warnings: (for reference only) WARNING: unmet direct dependencies detected for WWAN_CORE Depends on NETDEVICES && WWAN Selected by - MHI_NET && NETDEVICES && NET_CORE && MHI_BUS Fixes: 9a44c1cc6388 ("net: Add a WWAN subsystem") Reported-by: kernel test robot Signed-off-by: Loic Poulain Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit af6eaa8f703178746308ef4cb2962297717a8282 Author: Bryan O'Donoghue Date: Sat Jun 5 18:33:47 2021 +0100 wcn36xx: Move hal_buf allocation to devm_kmalloc in probe [ Upstream commit ef48667557c53d4b51a1ee3090eab7699324c9de ] Right now wcn->hal_buf is allocated in wcn36xx_start(). This is a problem since we should have setup all of the buffers we required by the time ieee80211_register_hw() is called. struct ieee80211_ops callbacks may run prior to mac_start() and therefore wcn->hal_buf must be initialized. This is easily remediated by moving the allocation to probe() taking the opportunity to tidy up freeing memory by using devm_kmalloc(). Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Bryan O'Donoghue Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210605173347.2266003-1-bryan.odonoghue@linaro.org Signed-off-by: Sasha Levin commit 4ec8141fe718dd4a8d055744d90bf63e17589ba9 Author: Lucas Stach Date: Fri May 28 20:01:35 2021 +0200 clk: imx8mq: remove SYS PLL 1/2 clock gates [ Upstream commit c586f53ae159c6c1390f093a1ec94baef2df9f3a ] Remove the PLL clock gates as the allowing to gate the sys1_pll_266m breaks the uSDHC module which is sporadically unable to enumerate devices after this change. Also it makes AMP clock management harder with no obvious benefit to Linux, so just revert the change. Link: https://lore.kernel.org/r/20210528180135.1640876-1-l.stach@pengutronix.de Fixes: b04383b6a558 ("clk: imx8mq: Define gates for pll1/2 fixed dividers") Signed-off-by: Lucas Stach Reviewed-by: Abel Vesa Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin commit 0757175bd62facc4ba0a30c578c2539bca9dafd9 Author: Dongliang Mu Date: Fri Jun 11 09:58:12 2021 +0800 ieee802154: hwsim: Fix possible memory leak in hwsim_subscribe_all_others [ Upstream commit ab372c2293f5d0b279f31c8d768566ea37602dc9 ] In hwsim_subscribe_all_others, the error handling code performs incorrectly if the second hwsim_alloc_edge fails. When this issue occurs, it goes to sub_fail, without cleaning the edges allocated before. Fixes: f25da51fdc38 ("ieee802154: hwsim: add replacement for fakelb") Signed-off-by: Dongliang Mu Acked-by: Alexander Aring Link: https://lore.kernel.org/r/20210611015812.1626999-1-mudongliangabcd@gmail.com Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin commit e41dc10d83b7a80173c817b799e319cf595e96ef Author: Randy Dunlap Date: Mon May 31 17:41:28 2021 +0300 wireless: carl9170: fix LEDS build errors & warnings [ Upstream commit 272fdc0c4542fad173b44965be02a16d6db95499 ] kernel test robot reports over 200 build errors and warnings that are due to this Kconfig problem when CARL9170=m, MAC80211=y, and LEDS_CLASS=m. 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]: - CARL9170_LEDS [=y] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_ATH [=y] && CARL9170 [=m] CARL9170_LEDS selects MAC80211_LEDS even though its kconfig dependencies are not met. This happens because 'select' does not follow any Kconfig dependency chains. Fix this by making CARL9170_LEDS depend on MAC80211_LEDS, where the latter supplies any needed dependencies on LEDS_CLASS. Fixes: 1d7e1e6b1b8ed ("carl9170: Makefile, Kconfig files and MAINTAINERS") Signed-off-by: Randy Dunlap Reported-by: kernel test robot Cc: Kalle Valo Cc: Christian Lamparter Cc: linux-wireless@vger.kernel.org Cc: Arnd Bergmann Suggested-by: Christian Lamparter Acked-by: Arnd Bergmann Acked-by: Christian Lamparter Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210530031134.23274-1-rdunlap@infradead.org Signed-off-by: Sasha Levin commit 4407f2b03b329da8bb5809460323b22a54c18edb Author: Yang Yingliang Date: Mon May 31 17:41:28 2021 +0300 ath10k: add missing error return code in ath10k_pci_probe() [ Upstream commit e2783e2f39ba99178dedfc1646d5cc0979d1bab3 ] When chip_id is not supported, the resources will be freed on path err_unsupported, these resources will also be freed when calling ath10k_pci_remove(), it will cause double free, so return -ENODEV when it doesn't support the device with wrong chip_id. Fixes: c0c378f9907c ("ath10k: remove target soc ps code") Fixes: 7505f7c3ec1d ("ath10k: create a chip revision whitelist") Fixes: f8914a14623a ("ath10k: restore QCA9880-AR1A (v1) detection") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210522105822.1091848-3-yangyingliang@huawei.com Signed-off-by: Sasha Levin commit bce39420d111aac4ee3450e638345fd6e3898fd8 Author: Yang Yingliang Date: Mon May 31 17:41:28 2021 +0300 ath10k: go to path err_unsupported when chip id is not supported [ Upstream commit 9e88dd431d2345acdb7a549f3e88aaf4c2a307a1 ] When chip id is not supported, it go to path err_unsupported to print the error message. Fixes: f8914a14623a ("ath10k: restore QCA9880-AR1A (v1) detection") Signed-off-by: Yang Yingliang Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210522105822.1091848-2-yangyingliang@huawei.com Signed-off-by: Sasha Levin commit f3fe80f74081cba3ef9b798fa56309be1333c5b1 Author: Zhihao Cheng Date: Wed Jun 9 19:59:16 2021 +0800 tools/bpftool: Fix error return code in do_batch() [ Upstream commit ca16b429f39b4ce013bfa7e197f25681e65a2a42 ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 668da745af3c2 ("tools: bpftool: add support for quotations ...") Reported-by: Hulk Robot Signed-off-by: Zhihao Cheng Signed-off-by: Andrii Nakryiko Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20210609115916.2186872-1-chengzhihao1@huawei.com Signed-off-by: Sasha Levin commit 944be014f9c15a46dbad8d3f0716fd5e7c1c0a16 Author: Wong Vee Khee Date: Fri Jun 11 17:02:38 2021 +0800 net: stmmac: Fix potential integer overflow [ Upstream commit 52e597d3e2e6e5bfce47559eb22b955ac17b3826 ] The commit d96febedfde2 ("net: stmmac: arrange Tx tail pointer update to stmmac_flush_tx_descriptors") introduced the following coverity warning:- 1. Unintentional integer overflow (OVERFLOW_BEFORE_WIDEN) overflow_before_widen: Potentially overflowing expression 'tx_q->cur_tx * desc_size' with type 'unsigned int' (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type dma_addr_t (64 bits, unsigned). Fixed this by assigning tx_tail_addr to dma_addr_t type, as dma_addr_t datatype is decided by CONFIG_ARCH_DMA_ADDR_T_64_BIT. Fixes: d96febedfde2 ("net: stmmac: arrange Tx tail pointer update to stmmac_flush_tx_descriptors") Signed-off-by: Wong Vee Khee Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c7cfbf45325a804da00e619b129882dc3064608c Author: Matteo Croce Date: Wed Jun 9 19:23:03 2021 +0200 stmmac: prefetch right address [ Upstream commit 4744bf072b4640c5e2ea65c2361ad6c832f28fa8 ] To support XDP, a headroom is prepended to the packet data. Consider this offset when doing a prefetch. Fixes: da5ec7f22a0f ("net: stmmac: refactor stmmac_init_rx_buffers for stmmac_reinit_rx_buffers") Signed-off-by: Matteo Croce Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6be3f2d04fbe4eed404181a07f387da1a3062f43 Author: Colin Ian King Date: Tue Jun 8 17:13:13 2021 +0100 drm: qxl: ensure surf.data is ininitialized [ Upstream commit fbbf23ddb2a1cc0c12c9f78237d1561c24006f50 ] The object surf is not fully initialized and the uninitialized field surf.data is being copied by the call to qxl_bo_create via the call to qxl_gem_object_create. Set surf.data to zero to ensure garbage data from the stack is not being copied. Addresses-Coverity: ("Uninitialized scalar variable") Fixes: f64122c1f6ad ("drm: add new QXL driver. (v1.4)") Signed-off-by: Colin Ian King Link: http://patchwork.freedesktop.org/patch/msgid/20210608161313.161922-1-colin.king@canonical.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin commit 296031d154af2b70e8c56e5b4f5811c4e6e47b7f Author: Luca Ceresoli Date: Thu May 27 23:16:47 2021 +0200 clk: vc5: fix output disabling when enabling a FOD [ Upstream commit fc336ae622df0ec114dbe5551a4d2760c535ecd0 ] On 5P49V6965, when an output is enabled we enable the corresponding FOD. When this happens for the first time, and specifically when writing register VC5_OUT_DIV_CONTROL in vc5_clk_out_prepare(), all other outputs are stopped for a short time and then restarted. According to Renesas support this is intended: "The reason for that is VC6E has synced up all output function". This behaviour can be disabled at least on VersaClock 6E devices, of which only the 5P49V6965 is currently implemented by this driver. This requires writing bit 7 (bypass_sync{1..4}) in register 0x20..0x50. Those registers are named "Unused Factory Reserved Register", and the bits are documented as "Skip VDDO verification", which does not clearly explain the relation to FOD sync. However according to Renesas support as well as my testing setting this bit does prevent disabling of all clock outputs when enabling a FOD. See "VersaClock ® 6E Family Register Descriptions and Programming Guide" (August 30, 2018), Table 116 "Power Up VDD check", page 58: https://www.renesas.com/us/en/document/mau/versaclock-6e-family-register-descriptions-and-programming-guide Signed-off-by: Luca Ceresoli Reviewed-by: Adam Ford Link: https://lore.kernel.org/r/20210527211647.1520720-1-luca@lucaceresoli.net Fixes: 2bda748e6ad8 ("clk: vc5: Add support for IDT VersaClock 5P49V6965") Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit ef06eab3b9a6d98b2a1ec20eaaf632d4faea0c55 Author: Maxime Ripard Date: Mon May 24 15:18:51 2021 +0200 drm/vc4: hdmi: Fix error path of hpd-gpios [ Upstream commit e075a7811977ff51c917a65ed1896e08231d2615 ] If the of_get_named_gpio_flags call fails in vc4_hdmi_bind, we jump to the err_unprepare_hsm label. That label will then call pm_runtime_disable and put_device on the DDC device. We just retrieved the DDC device, so the latter is definitely justified. However at that point we still haven't called pm_runtime_enable, so the call to pm_runtime_disable is not supposed to be there. Fixes: 10ee275cb12f ("drm/vc4: prepare for CEC support") Signed-off-by: Maxime Ripard Reviewed-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20210524131852.263883-1-maxime@cerno.tech Signed-off-by: Sasha Levin commit 8434d0dadad3446558290312023ee21e4e4aca66 Author: Kees Cook Date: Thu Jun 3 18:40:55 2021 -0700 drm/pl111: Actually fix CONFIG_VEXPRESS_CONFIG depends [ Upstream commit 4e566003571244f508408f59ce78f6ac2ccdba8e ] VEXPRESS_CONFIG needs to either be missing, built-in, or modular when pl111 is modular. Update the Kconfig to reflect the need. Fixes: 4dc7c97d04dc ("drm/pl111: depend on CONFIG_VEXPRESS_CONFIG") Signed-off-by: Kees Cook Reviewed-by: Linus Walleij Acked-by: Rob Herring Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20210604014055.4060521-1-keescook@chromium.org Signed-off-by: Sasha Levin commit 616a5ba2f822806ad9473b589fc8d2607d116934 Author: Kamal Heib Date: Thu Jun 3 12:01:12 2021 +0300 RDMA/rxe: Fix failure during driver load [ Upstream commit 32a25f2ea690dfaace19f7a3a916f5d7e1ddafe8 ] To avoid the following failure when trying to load the rdma_rxe module while IPv6 is disabled, add a check for EAFNOSUPPORT and ignore the failure, also delete the needless debug print from rxe_setup_udp_tunnel(). $ modprobe rdma_rxe modprobe: ERROR: could not insert 'rdma_rxe': Operation not permitted Fixes: dfdd6158ca2c ("IB/rxe: Fix kernel panic in udp_setup_tunnel") Link: https://lore.kernel.org/r/20210603090112.36341-1-kamalheib1@gmail.com Reported-by: Yi Zhang Signed-off-by: Kamal Heib Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 987e84710dc7ef94edab3ad3e4a4419523484a96 Author: Kees Cook Date: Wed Jun 2 14:52:52 2021 -0700 drm/pl111: depend on CONFIG_VEXPRESS_CONFIG [ Upstream commit 4dc7c97d04dcaa9f19482f70dcfdbeb52cc7193f ] Avoid randconfig build failures by requiring VEXPRESS_CONFIG: aarch64-linux-gnu-ld: drivers/gpu/drm/pl111/pl111_versatile.o: in function `pl111_vexpress_clcd_init': pl111_versatile.c:(.text+0x220): undefined reference to `devm_regmap_init_vexpress_config' Fixes: 826fc86b5903 ("drm: pl111: Move VExpress setup into versatile init") Signed-off-by: Kees Cook Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210602215252.695994-4-keescook@chromium.org Signed-off-by: Sasha Levin commit 16723287bd62b6e5ff97c92fb0d1f8562205794a Author: Mark Zhang Date: Wed Jun 2 13:27:07 2021 +0300 IB/cm: Improve the calling of cm_init_av_for_lap and cm_init_av_by_path [ Upstream commit 7345201c39633fc4c82dae7315da7154efaf2459 ] The cm_init_av_for_lap() and cm_init_av_by_path() function calls have the following issues: 1. Both of them might sleep and should not be called under spinlock. 2. The access of cm_id_priv->av should be under cm_id_priv->lock, which means it can't be initialized directly. This patch splits the calling of 2 functions into two parts: first one initializes an AV outside of the spinlock, the second one copies AV to cm_id_priv->av under spinlock. Fixes: e1444b5a163e ("IB/cm: Fix automatic path migration support") Link: https://lore.kernel.org/r/038fb8ad932869b4548b0c7708cab7f76af06f18.1622629024.git.leonro@nvidia.com Signed-off-by: Mark Zhang Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 325554115332879a40f82c73cb42ddc5e02cb43d Author: Mark Zhang Date: Wed Jun 2 13:27:05 2021 +0300 Revert "IB/cm: Mark stale CM id's whenever the mad agent was unregistered" [ Upstream commit 3595c398f6dbab79a38550ff26104c6ec1035cd3 ] This reverts commit 9db0ff53cb9b43ed75bacd42a89c1a0ab048b2b0, which wasn't a full fix and still causes to the following panic: panic @ time 1605623870.843, thread 0xfffffeb63b552000: vm_fault_lookup: fault on nofault entry, addr: 0xfffffe811a94e000 time = 1605623870 cpuid = 9, TSC = 0xb7937acc1b6 Panic occurred in module kernel loaded at 0xffffffff80200000:Stack: -------------------------------------------------- kernel:vm_fault+0x19da kernel:vm_fault_trap+0x6e kernel:trap_pfault+0x1f1 kernel:trap+0x31e kernel:cm_destroy_id+0x38c kernel:rdma_destroy_id+0x127 kernel:sdp_shutdown_task+0x3ae kernel:taskqueue_run_locked+0x10b kernel:taskqueue_thread_loop+0x87 kernel:fork_exit+0x83 Link: https://lore.kernel.org/r/4346449a7cdacc7a4eedc89cb1b42d8434ec9814.1622629024.git.leonro@nvidia.com Signed-off-by: Mark Zhang Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 020155e97970d79ace62548cc571ba69d534e3ef Author: Jason Gunthorpe Date: Wed Jun 2 13:27:02 2021 +0300 IB/cm: Split cm_alloc_msg() [ Upstream commit 4b4e586ebe37c8c7e2a4bf46dc4b742756fd788d ] This is being used with two quite different flows, one attaches the message to the priv and the other does not. Ensure the message attach is consistently done under the spinlock and ensure that the free on error always detaches the message from the cm_id_priv, also always under lock. This makes read/write to the cm_id_priv->msg consistently locked and consistently NULL'd when the message is freed, even in all error paths. Link: https://lore.kernel.org/r/f692b8c89eecb34fd82244f317e478bea6c97688.1622629024.git.leonro@nvidia.com Signed-off-by: Mark Zhang Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit ad6608cdd66df167feff54afa9161c91053f210d Author: Jason Gunthorpe Date: Wed Jun 2 13:27:01 2021 +0300 IB/cm: Pair cm_alloc_response_msg() with a cm_free_response_msg() [ Upstream commit 96376a40959e32502208210c62e68a6c60acfb48 ] This is not a functional change, but it helps make the purpose of all the cm_free_msg() calls clearer. In this case a response msg has a NULL context[0], and is never placed in cm_id_priv->msg. Link: https://lore.kernel.org/r/5cd53163be7df0a94f0d4ef7294546bc674fb74a.1622629024.git.leonro@nvidia.com Signed-off-by: Mark Zhang Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 66dfc041f8a974c0566c06c00f9a8318eee05594 Author: Leon Romanovsky Date: Wed May 19 11:37:31 2021 +0300 RDMA/core: Sanitize WQ state received from the userspace [ Upstream commit f97442887275d11c88c2899e720fe945c1f61488 ] The mlx4 and mlx5 implemented differently the WQ input checks. Instead of duplicating mlx4 logic in the mlx5, let's prepare the input in the central place. The mlx5 implementation didn't check for validity of state input. It is not real bug because our FW checked that, but still worth to fix. Fixes: f213c0527210 ("IB/uverbs: Add WQ support") Link: https://lore.kernel.org/r/ac41ad6a81b095b1a8ad453dcf62cf8d3c5da779.1621413310.git.leonro@nvidia.com Reported-by: Jiapeng Chong Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 9c13e23c16d6316a6cd92a82a0c95c139ee686c7 Author: Boris Sukholitko Date: Tue Jun 1 15:30:50 2021 +0300 net/sched: act_vlan: Fix modify to allow 0 [ Upstream commit 9c5eee0afca09cbde6bd00f77876754aaa552970 ] Currently vlan modification action checks existence of vlan priority by comparing it to 0. Therefore it is impossible to modify existing vlan tag to have priority 0. For example, the following tc command will change the vlan id but will not affect vlan priority: tc filter add dev eth1 ingress matchall action vlan modify id 300 \ priority 0 pipe mirred egress redirect dev eth2 The incoming packet on eth1: ethertype 802.1Q (0x8100), vlan 200, p 4, ethertype IPv4 will be changed to: ethertype 802.1Q (0x8100), vlan 300, p 4, ethertype IPv4 although the user has intended to have p == 0. The fix is to add tcfv_push_prio_exists flag to struct tcf_vlan_params and rely on it when deciding to set the priority. Fixes: 45a497f2d149a4a8061c (net/sched: act_vlan: Introduce TCA_VLAN_ACT_MODIFY vlan action) Signed-off-by: Boris Sukholitko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9177b18f8b54bd694b7dfa500261f1b50e0e5851 Author: Xin Long Date: Sat May 29 16:23:18 2021 -0400 xfrm: remove the fragment check for ipv6 beet mode [ Upstream commit eebd49a4ffb420a991c606e54aa3c9f02857a334 ] In commit 68dc022d04eb ("xfrm: BEET mode doesn't support fragments for inner packets"), it tried to fix the issue that in TX side the packet is fragmented before the ESP encapping while in the RX side the fragments always get reassembled before decapping with ESP. This is not true for IPv6. IPv6 is different, and it's using exthdr to save fragment info, as well as the ESP info. Exthdrs are added in TX and processed in RX both in order. So in the above case, the ESP decapping will be done earlier than the fragment reassembling in TX side. Here just remove the fragment check for the IPv6 inner packets to recover the fragments support for BEET mode. Fixes: 68dc022d04eb ("xfrm: BEET mode doesn't support fragments for inner packets") Reported-by: Xiumei Mu Signed-off-by: Xin Long Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit ee3582564a16a02ebc2116dc17d35ca56d2fd54a Author: Dmitry Osipenko Date: Sun May 16 19:30:33 2021 +0300 clk: tegra30: Use 300MHz for video decoder by default [ Upstream commit 56bb7c28ad00e7bcfc851c4e183c42d148d3ad4e ] The 600MHz is a too high clock rate for some SoC versions for the video decoder hardware and this may cause stability issues. Use 300MHz for the video decoder by default, which is supported by all hardware versions. Fixes: ed1a2459e20c ("clk: tegra: Add Tegra20/30 EMC clock implementation") Acked-by: Thierry Reding Signed-off-by: Dmitry Osipenko Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 96d211bddcf642a93232fada553fc40dc09e7793 Author: Zhen Lei Date: Fri May 28 16:55:55 2021 +0800 ehea: fix error return code in ehea_restart_qps() [ Upstream commit 015dbf5662fd689d581c0bc980711b073ca09a1a ] Fix to return -EFAULT from the error handling case instead of 0, as done elsewhere in this function. By the way, when get_zeroed_page() fails, directly return -ENOMEM to simplify code. Fixes: 2c69448bbced ("ehea: DLPAR memory add fix") Reported-by: Hulk Robot Signed-off-by: Zhen Lei Link: https://lore.kernel.org/r/20210528085555.9390-1-thunder.leizhen@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ca86c8cc2643a6609d0fccfa4a060437af0055b2 Author: Gioh Kim Date: Fri May 28 13:30:18 2021 +0200 RDMA/rtrs-clt: Fix memory leak of not-freed sess->stats and stats->pcpu_stats [ Upstream commit 7ecd7e290bee0ab9cf75b79a367a4cc113cf8292 ] sess->stats and sess->stats->pcpu_stats objects are freed when sysfs entry is removed. If something wrong happens and session is closed before sysfs entry is created, sess->stats and sess->stats->pcpu_stats objects are not freed. This patch adds freeing of them at three places: 1. When client uses wrong address and session creation fails. 2. When client fails to create a sysfs entry. 3. When client adds wrong address via sysfs add_path. Fixes: 215378b838df0 ("RDMA/rtrs: client: sysfs interface functions") Link: https://lore.kernel.org/r/20210528113018.52290-21-jinpu.wang@ionos.com Signed-off-by: Gioh Kim Signed-off-by: Jack Wang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 84d3b0760dfc0d0ecb95ca9bf54ab77b16eb6ed0 Author: Md Haris Iqbal Date: Fri May 28 13:30:17 2021 +0200 RDMA/rtrs-clt: Check if the queue_depth has changed during a reconnection [ Upstream commit 5b73b799c25c68a4703cd6c5ac4518006d9865b8 ] The queue_depth is a module parameter for rtrs_server. It is used on the client side to determing the queue_depth of the request queue for the RNBD virtual block device. During a reconnection event for an already mapped device, in case the rtrs_server module queue_depth has changed, fail the reconnect attempt. Also stop further auto reconnection attempts. A manual reconnect via sysfs has to be triggerred. Fixes: 6a98d71daea18 ("RDMA/rtrs: client: main functionality") Link: https://lore.kernel.org/r/20210528113018.52290-20-jinpu.wang@ionos.com Signed-off-by: Md Haris Iqbal Signed-off-by: Gioh Kim Signed-off-by: Jack Wang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit b69606171c143ac34a6791d5316fd5b4fbf16b1f Author: Jack Wang Date: Fri May 28 13:30:16 2021 +0200 RDMA/rtrs-srv: Fix memory leak when having multiple sessions [ Upstream commit 6bb97a2c1aa5278a30d49abb6186d50c34c207e2 ] Gioh notice memory leak below unreferenced object 0xffff8880acda2000 (size 2048): comm "kworker/4:1", pid 77, jiffies 4295062871 (age 1270.730s) hex dump (first 32 bytes): 00 20 da ac 80 88 ff ff 00 20 da ac 80 88 ff ff . ....... ...... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000e85d85b5>] rtrs_srv_rdma_cm_handler+0x8e5/0xa90 [rtrs_server] [<00000000e31a988a>] cma_ib_req_handler+0xdc5/0x2b50 [rdma_cm] [<000000000eb02c5b>] cm_process_work+0x2d/0x100 [ib_cm] [<00000000e1650ca9>] cm_req_handler+0x11bc/0x1c40 [ib_cm] [<000000009c28818b>] cm_work_handler+0xe65/0x3cf2 [ib_cm] [<000000002b53eaa1>] process_one_work+0x4bc/0x980 [<00000000da3499fb>] worker_thread+0x78/0x5c0 [<00000000167127a4>] kthread+0x191/0x1e0 [<0000000060802104>] ret_from_fork+0x3a/0x50 unreferenced object 0xffff88806d595d90 (size 8): comm "kworker/4:1H", pid 131, jiffies 4295062972 (age 1269.720s) hex dump (first 8 bytes): 62 6c 61 00 6b 6b 6b a5 bla.kkk. backtrace: [<000000004447d253>] kstrdup+0x2e/0x60 [<0000000047259793>] kobject_set_name_vargs+0x2f/0xb0 [<00000000c2ee3bc8>] dev_set_name+0xab/0xe0 [<000000002b6bdfb1>] rtrs_srv_create_sess_files+0x260/0x290 [rtrs_server] [<0000000075d87bd7>] rtrs_srv_info_req_done+0x71b/0x960 [rtrs_server] [<00000000ccdf1bb5>] __ib_process_cq+0x94/0x100 [ib_core] [<00000000cbcb60cb>] ib_cq_poll_work+0x32/0xc0 [ib_core] [<000000002b53eaa1>] process_one_work+0x4bc/0x980 [<00000000da3499fb>] worker_thread+0x78/0x5c0 [<00000000167127a4>] kthread+0x191/0x1e0 [<0000000060802104>] ret_from_fork+0x3a/0x50 unreferenced object 0xffff88806d6bb100 (size 256): comm "kworker/4:1H", pid 131, jiffies 4295062972 (age 1269.720s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 00 59 4d 86 ff ff ff ff .........YM..... backtrace: [<00000000a18a11e4>] device_add+0x74d/0xa00 [<00000000a915b95f>] rtrs_srv_create_sess_files.cold+0x49/0x1fe [rtrs_server] [<0000000075d87bd7>] rtrs_srv_info_req_done+0x71b/0x960 [rtrs_server] [<00000000ccdf1bb5>] __ib_process_cq+0x94/0x100 [ib_core] [<00000000cbcb60cb>] ib_cq_poll_work+0x32/0xc0 [ib_core] [<000000002b53eaa1>] process_one_work+0x4bc/0x980 [<00000000da3499fb>] worker_thread+0x78/0x5c0 [<00000000167127a4>] kthread+0x191/0x1e0 [<0000000060802104>] ret_from_fork+0x3a/0x50 The problem is we increase device refcount by get_device in process_info_req for each path, but only does put_deice for last path, which lead to memory leak. To fix it, it also calls put_device when dev_ref is not 0. Fixes: e2853c49477d1 ("RDMA/rtrs-srv-sysfs: fix missing put_device") Link: https://lore.kernel.org/r/20210528113018.52290-19-jinpu.wang@ionos.com Signed-off-by: Gioh Kim Signed-off-by: Jack Wang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 1ec059871932ec674264c2749e1f658dce7b0b20 Author: Gioh Kim Date: Fri May 28 13:30:15 2021 +0200 RDMA/rtrs-srv: Fix memory leak of unfreed rtrs_srv_stats object [ Upstream commit 2371c40354509746e4a4dad09a752e027a30f148 ] When closing a session, currently the rtrs_srv_stats object in the closing session is freed by kobject release. But if it failed to create a session by various reasons, it must free the rtrs_srv_stats object directly because kobject is not created yet. This problem is found by kmemleak as below: 1. One client machine maps /dev/nullb0 with session name 'bla': root@test1:~# echo "sessname=bla path=ip:192.168.122.190 \ device_path=/dev/nullb0" > /sys/devices/virtual/rnbd-client/ctl/map_device 2. Another machine failed to create a session with the same name 'bla': root@test2:~# echo "sessname=bla path=ip:192.168.122.190 \ device_path=/dev/nullb1" > /sys/devices/virtual/rnbd-client/ctl/map_device -bash: echo: write error: Connection reset by peer 3. The kmemleak on server machine reported an error: unreferenced object 0xffff888033cdc800 (size 128): comm "kworker/2:1", pid 83, jiffies 4295086585 (age 2508.680s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000a72903b2>] __alloc_sess+0x1d4/0x1250 [rtrs_server] [<00000000d1e5321e>] rtrs_srv_rdma_cm_handler+0xc31/0xde0 [rtrs_server] [<00000000bb2f6e7e>] cma_ib_req_handler+0xdc5/0x2b50 [rdma_cm] [<00000000e896235d>] cm_process_work+0x2d/0x100 [ib_cm] [<00000000b6866c5f>] cm_req_handler+0x11bc/0x1c40 [ib_cm] [<000000005f5dd9aa>] cm_work_handler+0xe65/0x3cf2 [ib_cm] [<00000000610151e7>] process_one_work+0x4bc/0x980 [<00000000541e0f77>] worker_thread+0x78/0x5c0 [<00000000423898ca>] kthread+0x191/0x1e0 [<000000005a24b239>] ret_from_fork+0x3a/0x50 Fixes: 39c2d639ca183 ("RDMA/rtrs-srv: Set .release function for rtrs srv device during device init") Link: https://lore.kernel.org/r/20210528113018.52290-18-jinpu.wang@ionos.com Signed-off-by: Gioh Kim Signed-off-by: Md Haris Iqbal Signed-off-by: Jack Wang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 7fa6e48794924a1399feb3c6556c4f7066fac2bd Author: Gioh Kim Date: Fri May 28 13:30:13 2021 +0200 RDMA/rtrs: Do not reset hb_missed_max after re-connection [ Upstream commit 64bce1ee978491a779eb31098b21c57d4e431d6a ] When re-connecting, it resets hb_missed_max to 0. Before the first re-connecting, client will trigger re-connection when it gets hb-ack more than 5 times. But after the first re-connecting, clients will do re-connection whenever it does not get hb-ack because hb_missed_max is 0. There is no need to reset hb_missed_max when re-connecting. hb_missed_max should be kept until closing the session. Fixes: c0894b3ea69d3 ("RDMA/rtrs: core: lib functions shared between client and server modules") Link: https://lore.kernel.org/r/20210528113018.52290-16-jinpu.wang@ionos.com Signed-off-by: Gioh Kim Signed-off-by: Jack Wang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 05c10aaaa06881eb28898c313ee7368c6061a3fa Author: Md Haris Iqbal Date: Fri May 28 13:30:10 2021 +0200 RDMA/rtrs-clt: Check state of the rtrs_clt_sess before reading its stats [ Upstream commit 41db63a7efe1c8c2dd282c1849a6ebfbbedbaf67 ] When get_next_path_min_inflight is called to select the next path, it iterates over the list of available rtrs_clt_sess (paths). It then reads the number of inflight IOs for that path to select one which has the least inflight IO. But it may so happen that rtrs_clt_sess (path) is no longer in the connected state because closing or error recovery paths can change the status of the rtrs_clt_Sess. For example, the client sent the heart-beat and did not get the response, it would change the session status and stop IO processing. The added checking of this patch can prevent accessing the broken path and generating duplicated error messages. It is ok if the status is changed after checking the status because the error recovery path does not free memory and only tries to reconnection. And also it is ok if the session is closed after checking the status because closing the session changes the session status and flush all IO beforing free memory. If the session is being accessed for IO processing, the closing session will wait. Fixes: 6a98d71daea18 ("RDMA/rtrs: client: main functionality") Link: https://lore.kernel.org/r/20210528113018.52290-13-jinpu.wang@ionos.com Signed-off-by: Md Haris Iqbal Reviewed-by: Gioh Kim Signed-off-by: Gioh Kim Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 695f54b87dc9109001c22981320ae736b81c14cf Author: Bart Van Assche Date: Sun May 23 21:12:10 2021 -0700 RDMA/srp: Fix a recently introduced memory leak [ Upstream commit 7ec2e27a3afff64c96bfe7a77685c33619db84be ] Only allocate a memory registration list if it will be used and if it will be freed. Link: https://lore.kernel.org/r/20210524041211.9480-5-bvanassche@acm.org Reviewed-by: Max Gurtovoy Fixes: f273ad4f8d90 ("RDMA/srp: Remove support for FMR memory registration") Signed-off-by: Bart Van Assche Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit c49229641646aade2a3007abf65aa8eb63cb2018 Author: Xi Wang Date: Fri May 21 17:29:53 2021 +0800 RDMA/hns: Fix wrong timer context buffer page size [ Upstream commit 5e6370d7cc75134b0eb5b15916aab40b628db9e1 ] The HEM page size for QPC timer and CQC timer is always 4K and there's no need to calculate a different size by the hns driver, otherwise the ROCEE may access an invalid address. Fixes: 719d13415f59 ("RDMA/hns: Remove duplicated hem page size config code") Link: https://lore.kernel.org/r/1621589395-2435-4-git-send-email-liweihang@huawei.com Signed-off-by: Xi Wang Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 63919d8eada18d8f97eeff5021ec1ad37ee5b414 Author: Jianguo Wu Date: Thu May 27 16:54:28 2021 -0700 mptcp: make sure flag signal is set when add addr with port [ Upstream commit eb5fb629f56da3f40f496c807da44a7ce7644779 ] When add address with port, it is mean to create a listening socket, and send an ADD_ADDR to remote, so it must have flag signal set, add this check in mptcp_pm_parse_addr(). Fixes: a77e9179c7651 ("mptcp: deal with MPTCP_PM_ADDR_ATTR_PORT in PM netlink") Acked-by: Geliang Tang Reviewed-by: Matthieu Baerts Signed-off-by: Jianguo Wu Signed-off-by: Mat Martineau Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e1c7a2f1f18549684e0749b7986e07468c7c862b Author: Jianguo Wu Date: Thu May 27 16:54:26 2021 -0700 mptcp: generate subflow hmac after mptcp_finish_join() [ Upstream commit 0a4d8e96e4fd687af92b961d5cdcea0fdbde05fe ] For outgoing subflow join, when recv SYNACK, in subflow_finish_connect(), the mptcp_finish_join() may return false in some cases, and send a RESET to remote, and no local hmac is required. So generate subflow hmac after mptcp_finish_join(). Fixes: ec3edaa7ca6c ("mptcp: Add handling of outgoing MP_JOIN requests") Signed-off-by: Jianguo Wu Signed-off-by: Mat Martineau Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4eafee9b9ef641b8bfe93fcafa0b22dd0396520f Author: Jianguo Wu Date: Thu May 27 16:54:24 2021 -0700 mptcp: fix pr_debug in mptcp_token_new_connect [ Upstream commit 2f1af441fd5dd5caf0807bb19ce9bbf9325ce534 ] After commit 2c5ebd001d4f ("mptcp: refactor token container"), pr_debug() is called before mptcp_crypto_key_gen_sha() in mptcp_token_new_connect(), so the output local_key, token and idsn are 0, like: MPTCP: ssk=00000000f6b3c4a2, local_key=0, token=0, idsn=0 Move pr_debug() after mptcp_crypto_key_gen_sha(). Fixes: 2c5ebd001d4f ("mptcp: refactor token container") Acked-by: Paolo Abeni Signed-off-by: Jianguo Wu Signed-off-by: Mat Martineau Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 005d5d547fdc07c62f57a2c9e3045c288c502e98 Author: Colin Ian King Date: Tue Sep 15 17:20:49 2020 +0100 drm/rockchip: cdn-dp: fix sign extension on an int multiply for a u64 result [ Upstream commit ce0cb93a5adb283f577cd4661f511047b5e39028 ] The variable bit_per_pix is a u8 and is promoted in the multiplication to an int type and then sign extended to a u64. If the result of the int multiplication is greater than 0x7fffffff then the upper 32 bits will be set to 1 as a result of the sign extension. Avoid this by casting tu_size_reg to u64 to avoid sign extension and also a potential overflow. Fixes: 1a0f7ed3abe2 ("drm/rockchip: cdn-dp: add cdn DP support for rk3399") Signed-off-by: Colin Ian King Reviewed-by: Guenter Roeck Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20200915162049.36434-1-colin.king@canonical.com Signed-off-by: Sasha Levin commit 64751457f5efb9fdb519de6f56ece9b6ea2a56bb Author: Christophe JAILLET Date: Sat May 1 17:13:16 2021 +0200 drm/rockchip: lvds: Fix an error handling path [ Upstream commit 3dfa159f6b0c054eb63673fbf643a5f2cc862e63 ] 'ret' is know to be 0 a this point. Checking the return value of 'phy_init()' and 'phy_set_mode()' was intended instead. So add the missing assignments. Fixes: cca1705c3d89 ("drm/rockchip: lvds: Add PX30 support") Signed-off-by: Christophe JAILLET Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/248220d4815dc8c8088cebfab7d6df5f70518438.1619881852.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit a087222cde4efb59a858543a80d2759735e198d3 Author: Thomas Hebb Date: Sun Apr 18 19:04:10 2021 -0700 drm/rockchip: dsi: move all lane config except LCDC mux to bind() [ Upstream commit 43c2de1002d2b70fb5941fa14e97a34e3dc214d4 ] When we first enable the DSI encoder, we currently program some per-chip configuration that we look up in rk3399_chip_data based on the device tree compatible we match. This data configures various parameters of the MIPI lanes, including on RK3399 whether DSI1 is slaved to DSI0 in a dual-mode configuration. It also selects which LCDC (i.e. VOP) to scan out from. This causes a problem in RK3399 dual-mode configurations, though: panel prepare() callbacks run before the encoder gets enabled and expect to be able to write commands to the DSI bus, but the bus isn't fully functional until the lane and master/slave configuration have been programmed. As a result, dual-mode panels (and possibly others too) fail to turn on when the rockchipdrm driver is initially loaded. Because the LCDC mux is the only thing we don't know until enable time (and is the only thing that can ever change), we can actually move most of the initialization to bind() and get it out of the way early. That's what this change does. (Rockchip's 4.4 BSP kernel does it in mode_set(), which also avoids the issue, but bind() seems like the more correct place to me.) Tested on a Google Scarlet board (Acer Chromebook Tab 10), which has a Kingdisplay KD097D04 dual-mode panel. Prior to this change, the panel's backlight would turn on but no image would appear when initially loading rockchipdrm. If I kept rockchipdrm loaded and reloaded the panel driver, it would come on. With this change, the panel successfully turns on during initial rockchipdrm load as expected. Fixes: 2d4f7bdafd70 ("drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge driver") Signed-off-by: Thomas Hebb Tested-by: Jonathan Liu Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/55fe7f3454d8c91dc3837ba5aa741d4a0e67378f.1618797813.git.tommyhebb@gmail.com Signed-off-by: Sasha Levin commit 0070511f03d1d30c8481bc01b0c7f458b934d2c3 Author: Yang Yingliang Date: Wed May 19 21:49:28 2021 +0800 drm/rockchip: cdn-dp-core: add missing clk_disable_unprepare() on error in cdn_dp_grf_write() [ Upstream commit ae41d925c75b53798f289c69ee8d9f7d36432f6d ] After calling clk_prepare_enable(), clk_disable_unprepare() need be called when calling regmap_write() failed. Fixes: 1a0f7ed3abe2 ("drm/rockchip: cdn-dp: add cdn DP support for rk3399") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20210519134928.2696617-1-yangyingliang@huawei.com Signed-off-by: Sasha Levin commit e9815b8319631c2cb7f79528d3bf959ca2652a1f Author: Alex Bee Date: Fri May 28 15:05:54 2021 +0200 drm: rockchip: set alpha_en to 0 if it is not used [ Upstream commit 046e0db975695540c9d9898cdbf0b60533d28afb ] alpha_en should be set to 0 if it is not used, i.e. to disable alpha blending if it was enabled before and should be disabled now. Fixes: 2aae8ed1f390 ("drm/rockchip: Add per-pixel alpha support for the PX30 VOP") Signed-off-by: Alex Bee Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20210528130554.72191-6-knaerzche@gmail.com Signed-off-by: Sasha Levin commit 8cb95b48901eca645d27956aff556b788e8d391f Author: Maxime Ripard Date: Fri May 7 17:05:08 2021 +0200 drm/vc4: crtc: Lookup the encoder from the register at boot [ Upstream commit b601c16b7ba8f3bb7a7e773b238da6b63657fa1d ] At boot, we can't rely on the vc4_get_crtc_encoder since we don't have a state yet and thus will not be able to figure out which connector is attached to our CRTC. However, we have a muxing bit in the CRTC register we can use to get the encoder currently connected to the pixelvalve. We can thus read that register, lookup the associated register through the vc4_pv_data structure, and then pass it to vc4_crtc_disable so that we can perform the proper operations. Fixes: 875a4d536842 ("drm/vc4: drv: Disable the CRTC at boot time") Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson Link: https://patchwork.freedesktop.org/patch/msgid/20210507150515.257424-6-maxime@cerno.tech Signed-off-by: Sasha Levin commit 81ae7270122f6aa4e4d574141e7ad7ecbc2607d3 Author: Maxime Ripard Date: Fri May 7 17:05:07 2021 +0200 drm/vc4: crtc: Fix vc4_get_crtc_encoder logic [ Upstream commit 5a184d959d5a5a66b377cb5cd4c95a80388e0c88 ] The vc4_get_crtc_encoder function currently only works when the connector->state->crtc pointer is set, which is only true when the connector is currently enabled. However, we use it as part of the disable path as well, and our lookup will fail in that case, resulting in it returning a null pointer we can't act on. We can access the connector that used to be connected to that crtc though using the old connector state in the disable path. Since we want to support both the enable and disable path, we can support it by passing the state accessor variant as a function pointer, together with the atomic state. Fixes: 792c3132bc1b ("drm/vc4: encoder: Add finer-grained encoder callbacks") Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson Link: https://patchwork.freedesktop.org/patch/msgid/20210507150515.257424-5-maxime@cerno.tech Signed-off-by: Sasha Levin commit bba1c86f1156663375541a8424bc8c088e2a0f20 Author: Maxime Ripard Date: Fri May 7 17:05:06 2021 +0200 drm/vc4: crtc: Pass the drm_atomic_state to config_pv [ Upstream commit c6883985d46319e0d4f159de8932b09ff93e877d ] The vc4_crtc_config_pv will need to access the drm_atomic_state structure and its only parent function, vc4_crtc_atomic_enable already has access to it. Let's pass it as a parameter. Fixes: 792c3132bc1b ("drm/vc4: encoder: Add finer-grained encoder callbacks") Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson Link: https://patchwork.freedesktop.org/patch/msgid/20210507150515.257424-4-maxime@cerno.tech Signed-off-by: Sasha Levin commit 0e9dce911326ae3f4011c405d457c22fbcb09995 Author: Tobias Schramm Date: Thu May 13 15:13:15 2021 +0200 clk: sunxi-ng: v3s: fix incorrect postdivider on pll-audio [ Upstream commit 47e4dc4e63e1dcb8eec01c4214bcefc248eb72ed ] Commit 46060be6d840 ("clk: sunxi-ng: v3s: use sigma-delta modulation for audio-pll") changed the audio pll on the Allwinner V3s and V3 SoCs to use sigma-delta modulation. In the process the declaration of fixed postdivider providing "pll-audio" was adjusted to provide the desired clock rates from the now sigma-delta modulated pll. However, while the divider used for calculations by the clock framework was adjusted the actual divider programmed into the hardware in sun8i_v3_v3s_ccu_init was left at "divide by four". This broke the "pll-audio" clock, now only providing quater the expected clock rate. It would in general be desirable to program the postdivider for "pll-audio" to four, such that a broader range of frequencies were available on the pll outputs. But the clock for the integrated codec "ac-dig" does not feature a mux that allows to select from all pll outputs as it is just a simple clock gate connected to "pll-audio". Thus we need to set the postdivider to one to be able to provide the 22.5792MHz and 24.576MHz rates required by the internal sun4i codec. This patches fixes the incorrect clock rate by forcing the postdivider to one in sun8i_v3_v3s_ccu_init. Fixes: 46060be6d840 ("clk: sunxi-ng: v3s: use sigma-delta modulation for audio-pll") Signed-off-by: Tobias Schramm Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20210513131315.2059451-1-t.schramm@manjaro.org Signed-off-by: Sasha Levin commit e1fd4e8e99e554020f082ff46e593d4f59f14e35 Author: Peter Geis Date: Wed May 19 13:41:49 2021 -0400 clk: rockchip: fix rk3568 cpll clk gate bits [ Upstream commit 2f3877d609e7951ef96d24979eb9d163f1f004f8 ] The cpll clk gate bits had an ordering issue. This led to the loss of the boot sdmmc controller when the gmac was shut down with: `ip link set eth0 down` as the cpll_100m was shut off instead of the cpll_62p5. cpll_62p5, cpll_50m, cpll_25m were all off by one with cpll_100m misplaced. Fixes: cf911d89c4c5 ("clk: rockchip: add clock controller for rk3568") Signed-off-by: Peter Geis Reviewed-by: Elaine Zhang Link: https://lore.kernel.org/r/20210519174149.3691335-1-pgwipeout@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 8989945c62c7a7990bd9dc30de1283151e2af57f Author: Yang Yingliang Date: Sat May 22 20:02:46 2021 +0800 net: ftgmac100: add missing error return code in ftgmac100_probe() [ Upstream commit 52af13a41489d7bbc1932d17583eff6e5fffc820 ] The variables will be free on path err_phy_connect, it should return error code, or it will cause double free when calling ftgmac100_remove(). Fixes: bd466c3fb5a4 ("net/faraday: Support NCSI mode") Fixes: 39bfab8844a0 ("net: ftgmac100: Add support for DT phy-handle property") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9834e82646233b3ed8ed7a69bdbe7f30a97115e8 Author: Aurabindo Pillai Date: Wed May 19 16:51:01 2021 -0400 drm/amd/display: take dc_lock in short pulse handler only [ Upstream commit d2aa1356834d845ffdac0d8c01b58aa60d1bdc65 ] [Why] Conditions that end up modifying the global dc state must be locked. However, during mst allocate payload sequence, lock is already taken. With StarTech 1.2 DP hub, we get an HPD RX interrupt for a reason other than to indicate down reply availability right after sending payload allocation. The handler again takes dc lock before calling the dc's HPD RX handler. Due to this contention, the DRM thread which waits for MST down reply never gets a chance to finish its waiting successfully and ends up timing out. Once the lock is released, the hpd rx handler fires and goes ahead to read from the MST HUB, but now its too late and the HUB doesnt lightup all displays since DRM lacks error handling when payload allocation fails. [How] Take lock only if there is a change in link status or if automated test pattern bit is set. The latter fixes the null pointer dereference when running certain DP Link Layer Compliance test. Fixes: c8ea79a8a276 ("drm/amd/display: NULL pointer error during compliance test") Signed-off-by: Aurabindo Pillai Reviewed-by: Nicholas Kazlauskas Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 700c74b34241c30cea0a0a77b9421294ddf10ba0 Author: Zhan Liu Date: Sun May 9 19:30:36 2021 -0400 drm/amd/display: Avoid HPD IRQ in GPU reset state [ Upstream commit 509b9a5b4865dee723296f143695a7774fc96c4a ] [Why] If GPU is in reset state, force enabling link will cause unexpected behaviour. [How] Avoid handling HPD IRQ when GPU is in reset state. Signed-off-by: Zhan Liu Reviewed-by: Nikola Cornij Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 490649a08850c679d2fc7fd8c19d69a5c629f1f7 Author: Roman Li Date: Mon Apr 19 11:47:00 2021 -0400 drm/amd/display: fix potential gpu reset deadlock [ Upstream commit cf8b92a75646735136053ce51107bfa8cfc23191 ] [Why] In gpu reset dc_lock acquired in dm_suspend(). Asynchronously handle_hpd_rx_irq can also be called through amdgpu_dm_irq_suspend->flush_work, which also tries to acquire dc_lock. That causes a deadlock. [How] Check if amdgpu executing reset before acquiring dc_lock. Signed-off-by: Lang Yu Signed-off-by: Roman Li Reviewed-by: Qingqing Zhuo Acked-by: Wayne Lin Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5dd6cdd732dfac6f3e5917610889fb562e388b15 Author: Jerome Brunet Date: Thu Apr 29 11:03:25 2021 +0200 clk: meson: g12a: fix gp0 and hifi ranges [ Upstream commit bc794f8c56abddf709f1f84fcb2a3c9e7d9cc9b4 ] While some SoC samples are able to lock with a PLL factor of 55, others samples can't. ATM, a minimum of 60 appears to work on all the samples I have tried. Even with 60, it sometimes takes a long time for the PLL to eventually lock. The documentation says that the minimum rate of these PLLs DCO should be 3GHz, a factor of 125. Let's use that to be on the safe side. With factor range changed, the PLL seems to lock quickly (enough) so far. It is still unclear if the range was the only reason for the delay. Fixes: 085a4ea93d54 ("clk: meson: g12a: add peripheral clock controller") Signed-off-by: Jerome Brunet Acked-by: Neil Armstrong Link: https://lore.kernel.org/r/20210429090325.60970-1-jbrunet@baylibre.com Signed-off-by: Sasha Levin commit e5c790fd50cfe47fd679d2369a54bcea6d06af79 Author: Wei Yongjun Date: Wed May 19 15:58:52 2021 +0000 net: qrtr: ns: Fix error return code in qrtr_ns_init() [ Upstream commit a49e72b3bda73d36664a084e47da9727a31b8095 ] Fix to return a negative error code -ENOMEM from the error handling case instead of 0, as done elsewhere in this function. Fixes: c6e08d6251f3 ("net: qrtr: Allocate workqueue before kernel_bind") Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Reviewed-by: Manivannan Sadhasivam Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 78c9dc7c59f81831b1765731fc6b92c3413ebcf7 Author: Stephen Rothwell Date: Wed Mar 17 14:05:42 2021 +1100 drm/i915: Merge fix for "drm: Switch to %p4cc format modifier" [ Upstream commit e3c2f1870af43fc95f6fe141537f5142c5fe4717 ] Signed-off-by: Stephen Rothwell Signed-off-by: Thomas Zimmermann Fixes: 92f1d09ca4ed ("drm: Switch to %p4cc format modifier") Cc: Sakari Ailus Cc: Petr Mladek Cc: Andy Shevchenko Cc: dri-devel@lists.freedesktop.org Link: https://lore.kernel.org/dri-devel/20210514115307.4364aff9@canb.auug.org.au/T/#macc61d4e0b17ca0da2b26aae8fbbcbf47324da13 Signed-off-by: Sasha Levin commit 26bbe384ea6531d5e7b173a0e1b69792e9978558 Author: Andrii Nakryiko Date: Thu May 6 22:41:17 2021 -0700 libbpf: Fix ELF symbol visibility update logic [ Upstream commit 247b8634e6446dbc8024685f803290501cba226f ] Fix silly bug in updating ELF symbol's visibility. Fixes: a46349227cd8 ("libbpf: Add linker extern resolution support for functions and global variables") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20210507054119.270888-6-andrii@kernel.org Signed-off-by: Sasha Levin commit 47bba472eba566a0717ed42230b0a5392d20b2f7 Author: Thomas Hellstrom Date: Tue May 4 23:57:37 2021 -0400 drm/vmwgfx: Fix cpu updates of coherent multisample surfaces [ Upstream commit 88509f698c4e38e287e016e86a0445547824135c ] In cases where the dirty linear memory range spans multiple sample sheets in a surface, the dirty surface region is incorrectly computed. To do this correctly and in an optimized fashion we would have to compute the dirty region of each sample sheet and compute the union of those regions. But assuming that cpu writing to a multisample surface is rather a corner case than a common case, just set the dirty region to the full surface. This fixes OpenGL piglit errors with SVGA_FORCE_COHERENT=1 and the piglit test: fbo-depthstencil blit default_fb -samples=2 -auto Fixes: 9ca7d19ff8ba ("drm/vmwgfx: Add surface dirty-tracking callbacks") Signed-off-by: Thomas Hellstrom Reviewed-by: Charmaine Lee Reviewed-by: Roland Scheidegger Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20210505035740.286923-4-zackr@vmware.com Signed-off-by: Sasha Levin commit 6fd6874917118330559462845804957fd7d0f99b Author: Thomas Hellstrom Date: Tue May 4 23:57:36 2021 -0400 drm/vmwgfx: Mark a surface gpu-dirty after the SVGA3dCmdDXGenMips command [ Upstream commit 75156a887b6cea6e09d83ec19f4ebfd7c86265f0 ] The SVGA3dCmdDXGenMips command uses a shader-resource view to access the underlying surface. Normally accesses using that view-type are not dirtying the underlying surface, but that particular command is an exception. Mark the surface gpu-dirty after a SVGA3dCmdDXGenMips command has been submitted. This fixes the piglit getteximage-formats test run with SVGA_FORCE_COHERENT=1 Fixes: a9f58c456e9d ("drm/vmwgfx: Be more restrictive when dirtying resources") Signed-off-by: Thomas Hellstrom Reviewed-by: Charmaine Lee Reviewed-by: Roland Scheidegger Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20210505035740.286923-3-zackr@vmware.com Signed-off-by: Sasha Levin commit b400d6618f0d1cabe1a88c535200d1cce10764d7 Author: Yixian Liu Date: Wed Apr 28 15:12:30 2021 +0800 RDMA/hns: Remove the condition of light load for posting DWQE [ Upstream commit 591f762b2750c628df9412d1c795b56e83a34b3e ] Even in the case of heavy load, direct WQE can still be posted. The hardware will decide whether to drop the DWQE or not. Thus, the limit needs to be removed. Fixes: 01584a5edcc4 ("RDMA/hns: Add support of direct wqe") Link: https://lore.kernel.org/r/1619593950-29414-1-git-send-email-liweihang@huawei.com Signed-off-by: Yixian Liu Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit bea7a8218abc93eb1beb3b010e1fc60068d628c7 Author: Geert Uytterhoeven Date: Fri Apr 30 14:31:01 2021 +0200 pinctrl: renesas: r8a77990: JTAG pins do not have pull-down capabilities [ Upstream commit 702a5fa2fe4d7e7f28fed92a170b540acfff9d34 ] Hence remove the SH_PFC_PIN_CFG_PULL_DOWN flags from their pin descriptions. Fixes: 83f6941a42a5e773 ("pinctrl: sh-pfc: r8a77990: Add bias pinconf support") Signed-off-by: Geert Uytterhoeven Reviewed-by: Niklas Söderlund Link: https://lore.kernel.org/r/da4b2d69955840a506412f1e8099607a0da97ecc.1619785375.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit c2331bec030a9773496865692bdcb89378b9d7e4 Author: Geert Uytterhoeven Date: Fri Apr 30 14:31:00 2021 +0200 pinctrl: renesas: r8a7796: Add missing bias for PRESET# pin [ Upstream commit 2cee31cd49733e89dfedf4f68a56839fc2e42040 ] R-Car Gen3 Hardware Manual Errata for Rev. 0.52 of Nov 30, 2016, added the configuration bit for bias pull-down control for the PRESET# pin on R-Car M3-W. Add driver support for controlling pull-down on this pin. Fixes: 2d40bd24274d2577 ("pinctrl: sh-pfc: r8a7796: Add bias pinconf support") Signed-off-by: Geert Uytterhoeven Reviewed-by: Niklas Söderlund Link: https://lore.kernel.org/r/c479de5b3f235c2f7d5faea9e7e08e6fccb135df.1619785375.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 35713cfa8c641cf4a41acf65432e15911459094b Author: Andy Shevchenko Date: Mon May 10 19:39:27 2021 +0300 net: pch_gbe: Propagate error from devm_gpio_request_one() [ Upstream commit 9e3617a7b84512bf96c04f9cf82d1a7257d33794 ] If GPIO controller is not available yet we need to defer the probe of GBE until provider will become available. While here, drop GPIOF_EXPORT because it's deprecated and may not be available. Fixes: f1a26fdf5944 ("pch_gbe: Add MinnowBoard support") Signed-off-by: Andy Shevchenko Tested-by: Flavio Suligoi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8487f76454dda3b4c4cac55e1633469d540724a0 Author: Andy Shevchenko Date: Mon May 10 12:58:05 2021 +0300 net: mvpp2: Put fwnode in error case during ->probe() [ Upstream commit 71f0891c84dfdc448736082ab0a00acd29853896 ] In each iteration fwnode_for_each_available_child_node() bumps a reference counting of a loop variable followed by dropping in on a next iteration, Since in error case the loop is broken, we have to drop a reference count by ourselves. Do it for port_fwnode in error case during ->probe(). Fixes: 248122212f68 ("net: mvpp2: use device_*/fwnode_* APIs instead of of_*") Cc: Marcin Wojtas Signed-off-by: Andy Shevchenko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4e953e501b9f0ce93480badfd96e01d1b288952a Author: Cong Wang Date: Sat May 8 11:00:33 2021 -0700 rtnetlink: avoid RCU read lock when holding RTNL [ Upstream commit a100243d95a60d74ae9bb9df1f5f2192e9aed6a7 ] When we call af_ops->set_link_af() we hold a RCU read lock as we retrieve af_ops from the RCU protected list, but this is unnecessary because we already hold RTNL lock, which is the writer lock for protecting rtnl_af_ops, so it is safer than RCU read lock. Similar for af_ops->validate_link_af(). This was not a problem until we begin to take mutex lock down the path of ->set_link_af() in __ipv6_dev_mc_dec() recently. We can just drop the RCU read lock there and assert RTNL lock. Reported-and-tested-by: syzbot+7d941e89dd48bcf42573@syzkaller.appspotmail.com Fixes: 63ed8de4be81 ("mld: add mc_lock for protecting per-interface mld data") Tested-by: Taehee Yoo Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2e023412a1502da37057b9f423a266cbaff18930 Author: Lucas Stach Date: Mon May 10 16:59:27 2021 +0200 drm/imx: ipuv3-plane: fix PRG modifiers after drm managed resource conversion [ Upstream commit 17b9a94656fe19aef3647c4f93d93be51697ceb1 ] The conversion to drm managed resources introduced two bugs: the plane is now always initialized with the linear-only list, while the list with the Vivante GPU modifiers should have been used when the PRG/PRE engines are present. This masked another issue, as ipu_plane_format_mod_supported() is now called before the private plane data is set up, so if a non-linear modifier is supplied in the plane modifier list, we run into a NULL pointer dereference checking for the PRG presence. To fix this just remove the check from this function, as we know that it will only be called with a non-linear modifier, if the plane init code has already determined that the PRG/PRE is present. Fixes: 699e7e543f1a ("drm/imx: ipuv3-plane: use drm managed resources") Signed-off-by: Lucas Stach Link: https://lore.kernel.org/r/20210510145927.988661-1-l.stach@pengutronix.de Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin commit 99631d4f4e9ad43562a2a0639c81a06be5e768d9 Author: Philipp Zabel Date: Tue Jan 19 14:51:08 2021 +0100 drm/imx: ipuv3-plane: do not advertise YUV formats on planes without CSC [ Upstream commit 06841148c570832d4d247b0f6befc1922a84120b ] Only planes that are displayed via the Display Processor (DP) path support color space conversion. Limit formats on planes that are shown via the direct Display Controller (DC) path to RGB. Reported-by: Fabio Estevam Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin commit 7c15cfa409d8ecf70970d422716fa58ac0018d5c Author: Christophe JAILLET Date: Thu May 6 20:57:05 2021 +0200 video: fbdev: imxfb: Fix an error message [ Upstream commit 767d724a160eb1cd00c86fb8c2e21fa1ab3c37ac ] 'ret' is known to be 0 here. No error code is available, so just remove it from the error message. Fixes: 72330b0eeefc ("i.MX Framebuffer: Use readl/writel instead of direct pointer deref") Reviewed-by: Uwe Kleine-König Signed-off-by: Christophe JAILLET Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/d7b25026f82659da3c6f7159eea480faa9d738be.1620327302.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit a5eebe5b325847f84d1522f5bb5d2a243ef28549 Author: Adrien Grassein Date: Wed May 5 00:02:07 2021 +0200 drm/bridge: fix LONTIUM_LT8912B dependencies [ Upstream commit 660729e494b6ee64feb97b41f3092c32a41c7dae ] LONTIUM_LT8912B uses "drm_display_mode_to_videomode" from DRM framework that needs VIDEOMODE_HELPERS to be enabled. Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Reported-by: Michal Suchánek Signed-off-by: Adrien Grassein Reviewed-by: Robert Foss Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20210504220207.4004511-1-adrien.grassein@gmail.com Signed-off-by: Sasha Levin commit 918fd0d654c802e7eff19e70e5ba625a65c3f94e Author: Hsin-Yi Wang Date: Wed Apr 28 19:51:16 2021 +0800 drm/bridge: anx7625: Fix power on delay [ Upstream commit 1fcf24fb07e254ca69001ab14adc8cf567127c44 ] >From anx7625 spec, the delay between powering on power supplies and gpio should be larger than 10ms. Fixes: 6c744983004e ("drm/bridge: anx7625: disable regulators when power off") Signed-off-by: Hsin-Yi Wang Reviewed-by: Neil Armstrong Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20210428115116.931328-1-hsinyi@chromium.org Signed-off-by: Sasha Levin commit 61eab97d07ef558f9915ac4a5f2c98fc932027db Author: Takashi Iwai Date: Wed Apr 21 19:04:58 2021 +0200 drm/ast: Fix missing conversions to managed API [ Upstream commit 9ea172a9a3f4a7c5e876469509fc18ddefc7d49d ] The commit 7cbb93d89838 ("drm/ast: Use managed pci functions") converted a few PCI accessors to the managed API and dropped the manual pci_iounmap() calls, but it seems to have forgotten converting pci_iomap() to the managed one. It resulted in the leftover resources after the driver unbind. Let's fix them. Fixes: 7cbb93d89838 ("drm/ast: Use managed pci functions") Signed-off-by: Takashi Iwai Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20210421170458.21178-1-tiwai@suse.de Signed-off-by: Sasha Levin commit 5164492766f4f3a3b09c8773612a0234e710fa51 Author: Yingjie Wang Date: Thu Apr 8 17:57:20 2021 -0700 drm/amd/dc: Fix a missing check bug in dm_dp_mst_detect() [ Upstream commit 655c0ed19772d92c9665ed08bdc5202acc096dda ] In dm_dp_mst_detect(), We should check whether or not @connector has been unregistered from userspace. If the connector is unregistered, we should return disconnected status. Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") Signed-off-by: Yingjie Wang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 89714541150ab63ce81ca8dd0ce60664bd452233 Author: Douglas Anderson Date: Fri Apr 16 15:39:24 2021 -0700 drm/bridge: Fix the stop condition of drm_bridge_chain_pre_enable() [ Upstream commit bab5cca7e609952b069a550e39fe4893149fb658 ] The drm_bridge_chain_pre_enable() is not the proper opposite of drm_bridge_chain_post_disable(). It continues along the chain to _before_ the starting bridge. Let's fix that. Fixes: 05193dc38197 ("drm/bridge: Make the bridge chain a double-linked list") Signed-off-by: Douglas Anderson Reviewed-by: Andrzej Hajda Reviewed-by: Laurent Pinchart Link: https://patchwork.freedesktop.org/patch/msgid/20210416153909.v4.1.If62a003f76a2bc4ccc6c53565becc05d2aad4430@changeid Signed-off-by: Sasha Levin commit 725d15c4427a6139aba32a7c9337f1262f2b8729 Author: Robert Foss Date: Mon Apr 19 11:01:24 2021 +0200 drm/bridge/sii8620: fix dependency on extcon [ Upstream commit 08319adbdde15ef7cee1970336f63461254baa2a ] The DRM_SIL_SII8620 kconfig has a weak `imply` dependency on EXTCON, which causes issues when sii8620 is built as a builtin and EXTCON is built as a module. The symptoms are 'undefined reference' errors caused by the symbols in EXTCON not being available to the sii8620 driver. Fixes: 688838442147 ("drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL") Reported-by: kernel test robot Signed-off-by: Robert Foss Reviewed-by: Randy Dunlap Link: https://patchwork.freedesktop.org/patch/msgid/20210419090124.153560-1-robert.foss@linaro.org Signed-off-by: Sasha Levin commit d3209bf8be210fa6fea0b881960162a2fb017115 Author: Sabrina Dubroca Date: Fri Apr 16 11:27:59 2021 +0200 xfrm: xfrm_state_mtu should return at least 1280 for ipv6 [ Upstream commit b515d2637276a3810d6595e10ab02c13bfd0b63a ] Jianwen reported that IPv6 Interoperability tests are failing in an IPsec case where one of the links between the IPsec peers has an MTU of 1280. The peer generates a packet larger than this MTU, the router replies with a "Packet too big" message indicating an MTU of 1280. When the peer tries to send another large packet, xfrm_state_mtu returns 1280 - ipsec_overhead, which causes ip6_setup_cork to fail with EINVAL. We can fix this by forcing xfrm_state_mtu to return IPV6_MIN_MTU when IPv6 is used. After going through IPsec, the packet will then be fragmented to obey the actual network's PMTU, just before leaving the host. Currently, TFC padding is capped to PMTU - overhead to avoid fragementation: after padding and encapsulation, we still fit within the PMTU. That behavior is preserved in this patch. Fixes: 91657eafb64b ("xfrm: take net hdr len into account for esp payload size calculation") Reported-by: Jianwen Ji Signed-off-by: Sabrina Dubroca Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 67a7436a51ae54a4e7b04330ef25ead6e913a37b Author: Liu Shixin Date: Mon Jun 28 19:42:33 2021 -0700 mm/page_alloc: fix counting of managed_pages [ Upstream commit f7ec104458e00d27a190348ac3a513f3df3699a4 ] commit f63661566fad ("mm/page_alloc.c: clear out zone->lowmem_reserve[] if the zone is empty") clears out zone->lowmem_reserve[] if zone is empty. But when zone is not empty and sysctl_lowmem_reserve_ratio[i] is set to zero, zone_managed_pages(zone) is not counted in the managed_pages either. This is inconsistent with the description of lowmem_reserve, so fix it. Link: https://lkml.kernel.org/r/20210527125707.3760259-1-liushixin2@huawei.com Fixes: f63661566fad ("mm/page_alloc.c: clear out zone->lowmem_reserve[] if the zone is empty") Signed-off-by: Liu Shixin Reported-by: yangerkun Reviewed-by: Baoquan He Acked-by: David Hildenbrand Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit b38b1d0b34dd990be8f04c5f60351b11062f8a78 Author: Waiman Long Date: Mon Jun 28 19:37:34 2021 -0700 mm: memcg/slab: properly set up gfp flags for objcg pointer array [ Upstream commit 41eb5df1cbc9b302fc263ad7c9f38cfc38b4df61 ] Patch series "mm: memcg/slab: Fix objcg pointer array handling problem", v4. Since the merging of the new slab memory controller in v5.9, the page structure stores a pointer to objcg pointer array for slab pages. When the slab has no used objects, it can be freed in free_slab() which will call kfree() to free the objcg pointer array in memcg_alloc_page_obj_cgroups(). If it happens that the objcg pointer array is the last used object in its slab, that slab may then be freed which may caused kfree() to be called again. With the right workload, the slab cache may be set up in a way that allows the recursive kfree() calling loop to nest deep enough to cause a kernel stack overflow and panic the system. In fact, we have a reproducer that can cause kernel stack overflow on a s390 system involving kmalloc-rcl-256 and kmalloc-rcl-128 slabs with the following kfree() loop recursively called 74 times: [ 285.520739] [<000000000ec432fc>] kfree+0x4bc/0x560 [ 285.520740] [<000000000ec43466>] __free_slab+0xc6/0x228 [ 285.520741] [<000000000ec41fc2>] __slab_free+0x3c2/0x3e0 [ 285.520742] [<000000000ec432fc>] kfree+0x4bc/0x560 : While investigating this issue, I also found an issue on the allocation side. If the objcg pointer array happen to come from the same slab or a circular dependency linkage is formed with multiple slabs, those affected slabs can never be freed again. This patch series addresses these two issues by introducing a new set of kmalloc-cg- caches split from kmalloc- caches. The new set will only contain non-reclaimable and non-dma objects that are accounted in memory cgroups whereas the old set are now for unaccounted objects only. By making this split, all the objcg pointer arrays will come from the kmalloc- caches, but those caches will never hold any objcg pointer array. As a result, deeply nested kfree() call and the unfreeable slab problems are now gone. This patch (of 4): Since the merging of the new slab memory controller in v5.9, the page structure may store a pointer to obj_cgroup pointer array for slab pages. Currently, only the __GFP_ACCOUNT bit is masked off. However, the array is not readily reclaimable and doesn't need to come from the DMA buffer. So those GFP bits should be masked off as well. Do the flag bit clearing at memcg_alloc_page_obj_cgroups() to make sure that it is consistently applied no matter where it is called. Link: https://lkml.kernel.org/r/20210505200610.13943-1-longman@redhat.com Link: https://lkml.kernel.org/r/20210505200610.13943-2-longman@redhat.com Fixes: 286e04b8ed7a ("mm: memcg/slab: allocate obj_cgroups for non-root slab pages") Signed-off-by: Waiman Long Reviewed-by: Shakeel Butt Acked-by: Roman Gushchin Reviewed-by: Vlastimil Babka Cc: Johannes Weiner Cc: Michal Hocko Cc: Vladimir Davydov Cc: Christoph Lameter Cc: Pekka Enberg Cc: David Rientjes Cc: Joonsoo Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit a533a21b692fc15a6aadfa827b29c7d9989109ca Author: Miaohe Lin Date: Mon Jun 28 19:36:57 2021 -0700 mm/shmem: fix shmem_swapin() race with swapoff [ Upstream commit 2efa33fc7f6ec94a3a538c1a264273c889be2b36 ] When I was investigating the swap code, I found the below possible race window: CPU 1 CPU 2 ----- ----- shmem_swapin swap_cluster_readahead if (likely(si->flags & (SWP_BLKDEV | SWP_FS_OPS))) { swapoff .. si->swap_file = NULL; .. struct inode *inode = si->swap_file->f_mapping->host;[oops!] Close this race window by using get/put_swap_device() to guard against concurrent swapoff. Link: https://lkml.kernel.org/r/20210426123316.806267-5-linmiaohe@huawei.com Fixes: 8fd2e0b505d1 ("mm: swap: check if swap backing device is congested or not") Signed-off-by: Miaohe Lin Reviewed-by: "Huang, Ying" Cc: Dennis Zhou Cc: Tim Chen Cc: Hugh Dickins Cc: Johannes Weiner Cc: Michal Hocko Cc: Joonsoo Kim Cc: Alex Shi Cc: Matthew Wilcox Cc: Minchan Kim Cc: Wei Yang Cc: Yang Shi Cc: David Hildenbrand Cc: Yu Zhao Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c3b39134bbd088b7dce5e5f342ccd6bb9142fd18 Author: Miaohe Lin Date: Mon Jun 28 19:36:50 2021 -0700 swap: fix do_swap_page() race with swapoff [ Upstream commit 2799e77529c2a25492a4395db93996e3dacd762d ] When I was investigating the swap code, I found the below possible race window: CPU 1 CPU 2 ----- ----- do_swap_page if (data_race(si->flags & SWP_SYNCHRONOUS_IO) swap_readpage if (data_race(sis->flags & SWP_FS_OPS)) { swapoff .. p->swap_file = NULL; .. struct file *swap_file = sis->swap_file; struct address_space *mapping = swap_file->f_mapping;[oops!] Note that for the pages that are swapped in through swap cache, this isn't an issue. Because the page is locked, and the swap entry will be marked with SWAP_HAS_CACHE, so swapoff() can not proceed until the page has been unlocked. Fix this race by using get/put_swap_device() to guard against concurrent swapoff. Link: https://lkml.kernel.org/r/20210426123316.806267-3-linmiaohe@huawei.com Fixes: 0bcac06f27d7 ("mm,swap: skip swapcache for swapin of synchronous device") Signed-off-by: Miaohe Lin Reviewed-by: "Huang, Ying" Cc: Alex Shi Cc: David Hildenbrand Cc: Dennis Zhou Cc: Hugh Dickins Cc: Johannes Weiner Cc: Joonsoo Kim Cc: Matthew Wilcox Cc: Michal Hocko Cc: Minchan Kim Cc: Tim Chen Cc: Wei Yang Cc: Yang Shi Cc: Yu Zhao Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit c24d5da468e42307be98844521fa6a3cf127b414 Author: Nicolas Saenz Julienne Date: Mon Jun 28 19:35:13 2021 -0700 mm: mmap_lock: use local locks instead of disabling preemption [ Upstream commit 832b50725373e8c46781b7d4db104ec9cf564a6b ] mmap_lock will explicitly disable/enable preemption upon manipulating its local CPU variables. This is to be expected, but in this case, it doesn't play well with PREEMPT_RT. The preemption disabled code section also takes a spin-lock. Spin-locks in RT systems will try to schedule, which is exactly what we're trying to avoid. To mitigate this, convert the explicit preemption handling to local_locks. Which are RT aware, and will disable migration instead of preemption when PREEMPT_RT=y. The faulty call trace looks like the following: __mmap_lock_do_trace_*() preempt_disable() get_mm_memcg_path() cgroup_path() kernfs_path_from_node() spin_lock_irqsave() /* Scheduling while atomic! */ Link: https://lkml.kernel.org/r/20210604163506.2103900-1-nsaenzju@redhat.com Fixes: 2b5067a8143e3 ("mm: mmap_lock: add tracepoints around lock acquisition ") Signed-off-by: Nicolas Saenz Julienne Tested-by: Axel Rasmussen Reviewed-by: Axel Rasmussen Cc: Vlastimil Babka Cc: Steven Rostedt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit f9416bf072fec33781d6ab9ae1f03cb5ff11cdde Author: Anshuman Khandual Date: Mon Jun 28 19:35:10 2021 -0700 mm/debug_vm_pgtable: ensure THP availability via has_transparent_hugepage() [ Upstream commit 65ac1a60a57e2c55f2ac37f27095f6b012295e81 ] On certain platforms, THP support could not just be validated via the build option CONFIG_TRANSPARENT_HUGEPAGE. Instead has_transparent_hugepage() also needs to be called upon to verify THP runtime support. Otherwise the debug test will just run into unusable THP helpers like in the case of a 4K hash config on powerpc platform [1]. This just moves all pfn_pmd() and pfn_pud() after THP runtime validation with has_transparent_hugepage() which prevents the mentioned problem. [1] https://bugzilla.kernel.org/show_bug.cgi?id=213069 Link: https://lkml.kernel.org/r/1621397588-19211-1-git-send-email-anshuman.khandual@arm.com Fixes: 787d563b8642 ("mm/debug_vm_pgtable: fix kernel crash by checking for THP support") Signed-off-by: Anshuman Khandual Cc: Aneesh Kumar K.V Cc: Christophe Leroy Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit a800caba38542a25f716c9e9edd8a5cf68e0200c Author: Jan Kara Date: Mon Jun 28 19:35:04 2021 -0700 dax: fix ENOMEM handling in grab_mapping_entry() [ Upstream commit 1a14e3779dd58c16b30e56558146e5cc850ba8b0 ] grab_mapping_entry() has a bug in handling of ENOMEM condition. Suppose we have a PMD entry at index i which we are downgrading to a PTE entry. grab_mapping_entry() will set pmd_downgrade to true, lock the entry, clear the entry in xarray, and decrement mapping->nrpages. The it will call: entry = dax_make_entry(pfn_to_pfn_t(0), flags); dax_lock_entry(xas, entry); which inserts new PTE entry into xarray. However this may fail allocating the new node. We handle this by: if (xas_nomem(xas, mapping_gfp_mask(mapping) & ~__GFP_HIGHMEM)) goto retry; however pmd_downgrade stays set to true even though 'entry' returned from get_unlocked_entry() will be NULL now. And we will go again through the downgrade branch. This is mostly harmless except that mapping->nrpages is decremented again and we temporarily have an invalid entry stored in xarray. Fix the problem by setting pmd_downgrade to false each time we lookup the entry we work with so that it matches the entry we found. Link: https://lkml.kernel.org/r/20210622160015.18004-1-jack@suse.cz Fixes: b15cd800682f ("dax: Convert page fault handlers to XArray") Signed-off-by: Jan Kara Reviewed-by: Dan Williams Cc: Matthew Wilcox Cc: "Aneesh Kumar K.V" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 1e515576f826d2c1ffc34672c206adb2094aecbf Author: Dan Carpenter Date: Mon Jun 28 19:34:01 2021 -0700 ocfs2: fix snprintf() checking [ Upstream commit 54e948c60cc843b6e84dc44496edc91f51d2a28e ] The snprintf() function returns the number of bytes which would have been printed if the buffer was large enough. In other words it can return ">= remain" but this code assumes it returns "== remain". The run time impact of this bug is not very severe. The next iteration through the loop would trigger a WARN() when we pass a negative limit to snprintf(). We would then return success instead of -E2BIG. The kernel implementation of snprintf() will never return negatives so there is no need to check and I have deleted that dead code. Link: https://lkml.kernel.org/r/20210511135350.GV1955@kadam Fixes: a860f6eb4c6a ("ocfs2: sysfile interfaces for online file check") Fixes: 74ae4e104dfc ("ocfs2: Create stack glue sysfs files.") Signed-off-by: Dan Carpenter Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Gang He Cc: Jun Piao Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 4e38237b3a528dcc25579045136479a4922894c3 Author: Ming Lei Date: Fri Jun 25 10:02:48 2021 +0800 blk-mq: update hctx->dispatch_busy in case of real scheduler [ Upstream commit cb9516be7708a2a18ec0a19fe3a225b5b3bc92c7 ] Commit 6e6fcbc27e77 ("blk-mq: support batching dispatch in case of io") starts to support io batching submission by using hctx->dispatch_busy. However, blk_mq_update_dispatch_busy() isn't changed to update hctx->dispatch_busy in that commit, so fix the issue by updating hctx->dispatch_busy in case of real scheduler. Reported-by: Jan Kara Reviewed-by: Jan Kara Fixes: 6e6fcbc27e77 ("blk-mq: support batching dispatch in case of io") Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20210625020248.1630497-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 1ae8fd0cfaec07222754d68f90e0a5ba76f0d200 Author: Edward Hsieh Date: Thu Jun 24 20:30:30 2021 +0800 block: fix trace completion for chained bio [ Upstream commit 60b6a7e6a0f4382cd689f9afdac816964fec2921 ] For chained bio, trace_block_bio_complete in bio_endio is currently called only by the parent bio once upon all chained bio completed. However, the sector and size for the parent bio are modified in bio_split. Therefore, the size and sector of the complete events might not match the queue events in blktrace. The original fix of bio completion trace ("block: trace completion of all bios.") wants multiple complete events to correspond to one queue event but missed this. The issue can be reproduced by md/raid5 read with bio cross chunks. To fix, move trace completion into the loop for every chained bio to call. Fixes: fbbaf700e7b1 ("block: trace completion of all bios.") Reviewed-by: Wade Liang Reviewed-by: BingJing Chang Signed-off-by: Edward Hsieh Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20210624123030.27014-1-edwardh@synology.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c4b228181982a71d1250a54d2b80bc94d86c9bc6 Author: Chanwoo Choi Date: Thu Jun 17 15:05:43 2021 +0900 PM / devfreq: passive: Fix get_target_freq when not using required-opp [ Upstream commit 8c37d01e1a86073d15ea7084390fba58d9a1665f ] The 86ad9a24f21e ("PM / devfreq: Add required OPPs support to passive governor") supported the required-opp property for using devfreq passive governor. But, 86ad9a24f21e has caused the problem on use-case when required-opp is not used such as exynos-bus.c devfreq driver. So that fix the get_target_freq of passive governor for supporting the case of when required-opp is not used. Fixes: 86ad9a24f21e ("PM / devfreq: Add required OPPs support to passive governor") Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin commit e3ff9b26bbb27fb342b0393a1a52a751729b8c91 Author: Rafael J. Wysocki Date: Tue Jun 22 21:11:39 2021 +0200 cpufreq: Make cpufreq_online() call driver->offline() on errors [ Upstream commit 3b7180573c250eb6e2a7eec54ae91f27472332ea ] In the CPU removal path the ->offline() callback provided by the driver is always invoked before ->exit(), but in the cpufreq_online() error path it is not, so ->exit() is expected to somehow know the context in which it has been called and act accordingly. That is less than straightforward, so make cpufreq_online() invoke the driver's ->offline() callback, if present, on errors before ->exit() too. This only potentially affects intel_pstate. Fixes: 91a12e91dc39 ("cpufreq: Allow light-weight tear down and bring up of CPUs") Signed-off-by: Rafael J. Wysocki Acked-by: Viresh Kumar Signed-off-by: Sasha Levin commit 3baa60e2801ebdb908002d034394077363000292 Author: Nathan Chancellor Date: Tue Jun 22 18:38:01 2021 -0700 ACPI: bgrt: Fix CFI violation [ Upstream commit f37ccf8fce155d08ae2a4fb3db677911ced0c21a ] clang's Control Flow Integrity requires that every indirect call has a valid target, which is based on the type of the function pointer. The *_show() functions in this file are written as if they will be called from dev_attr_show(); however, they will be called from sysfs_kf_seq_show() because the files were created by sysfs_create_group() and the sysfs ops are based on kobj_sysfs_ops because of kobject_add_and_create(). Because the *_show() functions do not match the type of the show() member in struct kobj_attribute, there is a CFI violation. $ cat /sys/firmware/acpi/bgrt/{status,type,version,{x,y}offset}} 1 0 1 522 307 $ dmesg | grep "CFI failure" [ 267.761825] CFI failure (target: type_show.d5e1ad21498a5fd14edbc5c320906598.cfi_jt+0x0/0x8): [ 267.762246] CFI failure (target: xoffset_show.d5e1ad21498a5fd14edbc5c320906598.cfi_jt+0x0/0x8): [ 267.762584] CFI failure (target: status_show.d5e1ad21498a5fd14edbc5c320906598.cfi_jt+0x0/0x8): [ 267.762973] CFI failure (target: yoffset_show.d5e1ad21498a5fd14edbc5c320906598.cfi_jt+0x0/0x8): [ 267.763330] CFI failure (target: version_show.d5e1ad21498a5fd14edbc5c320906598.cfi_jt+0x0/0x8): Convert these functions to the type of the show() member in struct kobj_attribute so that there is no more CFI violation. Because these functions are all so similar, combine them into a macro. Fixes: d1ff4b1cdbab ("ACPI: Add support for exposing BGRT data") Link: https://github.com/ClangBuiltLinux/linux/issues/1406 Signed-off-by: Nathan Chancellor Reviewed-by: Kees Cook Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit ad90f92825defd540d0fce71536842e7a4a06131 Author: Paolo Valente Date: Sat Jun 19 16:09:48 2021 +0200 block, bfq: reset waker pointer with shared queues [ Upstream commit 9a2ac41b13c573703d6689f51f3e27dd658324be ] Commit 85686d0dc194 ("block, bfq: keep shared queues out of the waker mechanism") leaves shared bfq_queues out of the waker-detection mechanism. It attains this goal by not updating the pointer last_completed_rq_bfqq, if the last request completed belongs to a shared bfq_queue (so that the pointer will not point to the shared bfq_queue). Yet this has a side effect: the pointer last_completed_rq_bfqq keeps pointing, deceptively, to a bfq_queue that actually is not the last one to have had a request completed. As a consequence, such a bfq_queue may deceptively be considered as a waker of some bfq_queue, even of some shared bfq_queue. To address this issue, reset last_completed_rq_bfqq if the last request completed belongs to a shared queue. Fixes: 85686d0dc194 ("block, bfq: keep shared queues out of the waker mechanism") Signed-off-by: Paolo Valente Link: https://lore.kernel.org/r/20210619140948.98712-8-paolo.valente@linaro.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 833cf2c80aa3142708f62a1cb7893d2bce57839e Author: Paolo Valente Date: Sat Jun 19 16:09:46 2021 +0200 block, bfq: avoid delayed merge of async queues [ Upstream commit bd3664b362381c4c1473753ebedf0ab242a60d1d ] Since commit 430a67f9d616 ("block, bfq: merge bursts of newly-created queues"), BFQ may schedule a merge between a newly created sync bfq_queue, say Q2, and the last sync bfq_queue created, say Q1. To this goal, BFQ stores the address of Q1 in the field bic->stable_merge_bfqq of the bic associated with Q2. So, when the time for the possible merge arrives, BFQ knows which bfq_queue to merge Q2 with. In particular, BFQ checks for possible merges on request arrivals. Yet the same bic may also be associated with an async bfq_queue, say Q3. So, if a request for Q3 arrives, then the above check may happen to be executed while the bfq_queue at hand is Q3, instead of Q2. In this case, Q1 happens to be merged with an async bfq_queue. This is not only a conceptual mistake, because async queues are to be kept out of queue merging, but also a bug that leads to inconsistent states. This commits simply filters async queues out of delayed merges. Fixes: 430a67f9d616 ("block, bfq: merge bursts of newly-created queues") Tested-by: Holger Hoffstätte Signed-off-by: Paolo Valente Link: https://lore.kernel.org/r/20210619140948.98712-6-paolo.valente@linaro.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 30d5c741d111d66391be6ec79a09d590fd18af88 Author: Zhang Yi Date: Sat Jun 19 17:37:00 2021 +0800 blk-wbt: make sure throttle is enabled properly [ Upstream commit 76a8040817b4b9c69b53f9b326987fa891b4082a ] After commit a79050434b45 ("blk-rq-qos: refactor out common elements of blk-wbt"), if throttle was disabled by wbt_disable_default(), we could not enable again, fix this by set enable_state back to WBT_STATE_ON_DEFAULT. Fixes: a79050434b45 ("blk-rq-qos: refactor out common elements of blk-wbt") Signed-off-by: Zhang Yi Link: https://lore.kernel.org/r/20210619093700.920393-3-yi.zhang@huawei.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 1c0d0e179994ccc7741433b58f2a2a828d1c45d2 Author: Zhang Yi Date: Sat Jun 19 17:36:59 2021 +0800 blk-wbt: introduce a new disable state to prevent false positive by rwb_enabled() [ Upstream commit 1d0903d61e9645c6330b94247b96dd873dfc11c8 ] Now that we disable wbt by simply zero out rwb->wb_normal in wbt_disable_default() when switch elevator to bfq, but it's not safe because it will become false positive if we change queue depth. If it become false positive between wbt_wait() and wbt_track() when submit write request, it will lead to drop rqw->inflight to -1 in wbt_done(), which will end up trigger IO hung. Fix this issue by introduce a new state which mean the wbt was disabled. Fixes: a79050434b45 ("blk-rq-qos: refactor out common elements of blk-wbt") Signed-off-by: Zhang Yi Link: https://lore.kernel.org/r/20210619093700.920393-2-yi.zhang@huawei.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 9dc613454be9bfe1842f59bf49f8e5ab4007d2c8 Author: Randy Dunlap Date: Sat Jun 19 09:02:03 2021 -0700 EDAC/igen6: fix core dependency [ Upstream commit 0a9ece9ba154dd6205709108180952c55e630833 ] igen6_edac needs mce_register()/unregister() functions, so it should depend on X86_MCE (or X86_MCE_INTEL). That change prevents these build errors: ld: drivers/edac/igen6_edac.o: in function `igen6_remove': igen6_edac.c:(.text+0x494): undefined reference to `mce_unregister_decode_chain' ld: drivers/edac/igen6_edac.o: in function `igen6_probe': igen6_edac.c:(.text+0xf5b): undefined reference to `mce_register_decode_chain' Fixes: 10590a9d4f23e ("EDAC/igen6: Add EDAC driver for Intel client SoCs using IBECC") Reported-by: kernel test robot Signed-off-by: Randy Dunlap Signed-off-by: Tony Luck Link: https://lore.kernel.org/r/20210619160203.2026-1-rdunlap@infradead.org Signed-off-by: Sasha Levin commit b0f3df13bdc72eafe89143c91244ad7b6776cbd6 Author: Xiaofei Tan Date: Fri Jun 11 20:37:07 2021 +0800 ACPI: APEI: fix synchronous external aborts in user-mode [ Upstream commit ccb5ecdc2ddeaff744ee075b54cdff8a689e8fa7 ] Before commit 8fcc4ae6faf8 ("arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work"), do_sea() would unconditionally signal the affected task from the arch code. Since that change, the GHES driver sends the signals. This exposes a problem as errors the GHES driver doesn't understand or doesn't handle effectively are silently ignored. It will cause the errors get taken again, and circulate endlessly. User-space task get stuck in this loop. Existing firmware on Kunpeng9xx systems reports cache errors with the 'ARM Processor Error' CPER records. Do memory failure handling for ARM Processor Error Section just like for Memory Error Section. Fixes: 8fcc4ae6faf8 ("arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work") Signed-off-by: Xiaofei Tan Reviewed-by: James Morse [ rjw: Subject edit ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 98c349bb2782670e3f39b7752306e5566d5dc9e3 Author: Matti Vaittinen Date: Tue Jun 8 13:10:31 2021 +0300 extcon: extcon-max8997: Fix IRQ freeing at error path [ Upstream commit 610bdc04830a864115e6928fc944f1171dfff6f3 ] If reading MAX8997_MUIC_REG_STATUS1 fails at probe the driver exits without freeing the requested IRQs. Free the IRQs prior returning if reading the status fails. Fixes: 3e34c8198960 ("extcon: max8997: Avoid forcing UART path on drive probe") Signed-off-by: Matti Vaittinen Reviewed-by: Hans de Goede Acked-by: Chanwoo Choi Link: https://lore.kernel.org/r/27ee4a48ee775c3f8c9d90459c18b6f2b15edc76.1623146580.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit adfbc32044cdc54f5ae60749e6d1b7144e9a91eb Author: Dan Carpenter Date: Sat Jun 5 15:48:16 2021 +0300 nvme-tcp: fix error codes in nvme_tcp_setup_ctrl() [ Upstream commit 522af60cb2f8e3658bda1902fb7f200dcf888a5c ] These error paths currently return success but they should return -EOPNOTSUPP. Fixes: 73ffcefcfca0 ("nvme-tcp: check sgl supported by target") Fixes: 3f2304f8c6d6 ("nvme-tcp: add NVMe over TCP host driver") Signed-off-by: Dan Carpenter Reviewed-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit f1a3f6f8ef136fb6e7e8f204429249df6b77cfd5 Author: Tony Lindgren Date: Thu Apr 15 11:55:06 2021 +0300 clocksource/drivers/timer-ti-dm: Save and restore timer TIOCP_CFG [ Upstream commit 9517c577f9f722270584cfb1a7b4e1354e408658 ] As we are using cpu_pm to save and restore context, we must also save and restore the timer sysconfig register TIOCP_CFG. This is needed because we are not calling PM runtime functions at all with cpu_pm. Fixes: b34677b0999a ("clocksource/drivers/timer-ti-dm: Implement cpu_pm notifier for context save and restore") Cc: Aaro Koskinen Cc: Adam Ford Cc: Andreas Kemnade Cc: Lokesh Vutla Cc: Peter Ujfalusi Signed-off-by: Tony Lindgren Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20210415085506.56828-1-tony@atomide.com Signed-off-by: Sasha Levin commit 31d1545b81a722ccc1cddd0fddfa4e4f6b953e5f Author: Maximilian Luz Date: Tue Jun 8 15:29:51 2021 +0200 HID: surface-hid: Fix get-report request [ Upstream commit 2b2bcc76e2ffbaff7e6ec1c62cb9c10881dc70cd ] Getting a report (e.g. feature report) from a device requires us to send a request indicating which report we want to retrieve and then waiting for the corresponding response containing that report. We already provide the response structure to the request call, but the request isn't marked as a request that expects a response. Thus the request returns before we receive the response and the response buffer indicates a zero length response due to that. This essentially means that the get-report calls are broken and will always indicate that a report of length zero has been read. Fix this by appropriately marking the request. Fixes: b05ff1002a5c ("HID: Add support for Surface Aggregator Module HID transport") Signed-off-by: Maximilian Luz Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 3e556500bd497b6ead70098e4e9093e2462afeab Author: Guoqing Jiang Date: Tue May 25 17:46:16 2021 +0800 md: revert io stats accounting [ Upstream commit ad3fc798800fb7ca04c1dfc439dba946818048d8 ] The commit 41d2d848e5c0 ("md: improve io stats accounting") could cause double fault problem per the report [1], and also it is not correct to change ->bi_end_io if md don't own it, so let's revert it. And io stats accounting will be replemented in later commits. [1]. https://lore.kernel.org/linux-raid/3bf04253-3fad-434a-63a7-20214e38cf26@gmail.com/T/#t Fixes: 41d2d848e5c0 ("md: improve io stats accounting") Signed-off-by: Guoqing Jiang Signed-off-by: Song Liu Signed-off-by: Sasha Levin commit d67ff22c7fc8558b091ee08e946d3345de16e044 Author: Christoph Hellwig Date: Tue Jun 8 18:13:27 2021 +0200 mark pstore-blk as broken [ Upstream commit d07f3b081ee632268786601f55e1334d1f68b997 ] pstore-blk just pokes directly into the pagecache for the block device without going through the file operations for that by faking up it's own file operations that do not match the block device ones. As this breaks the control of the block layer of it's page cache, and even now just works by accident only the best thing is to just disable this driver. Fixes: 17639f67c1d6 ("pstore/blk: Introduce backend for block devices") Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20210608161327.1537919-1-hch@lst.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 780ce7b2994f45566d5e4a27469ea8c69d52c61e Author: Krzysztof Wilczyński Date: Thu Jun 3 17:12:01 2021 +0000 ACPI: sysfs: Fix a buffer overrun problem with description_show() [ Upstream commit 888be6067b97132c3992866bbcf647572253ab3f ] Currently, a device description can be obtained using ACPI, if the _STR method exists for a particular device, and then exposed to the userspace via a sysfs object as a string value. If the _STR method is available for a given device then the data (usually a Unicode string) is read and stored in a buffer (of the ACPI_TYPE_BUFFER type) with a pointer to said buffer cached in the struct acpi_device_pnp for later access. The description_show() function is responsible for exposing the device description to the userspace via a corresponding sysfs object and internally calls the utf16s_to_utf8s() function with a pointer to the buffer that contains the Unicode string so that it can be converted from UTF16 encoding to UTF8 and thus allowing for the value to be safely stored and later displayed. When invoking the utf16s_to_utf8s() function, the description_show() function also sets a limit of the data that can be saved into a provided buffer as a result of the character conversion to be a total of PAGE_SIZE, and upon completion, the utf16s_to_utf8s() function returns an integer value denoting the number of bytes that have been written into the provided buffer. Following the execution of the utf16s_to_utf8s() a newline character will be added at the end of the resulting buffer so that when the value is read in the userspace through the sysfs object then it would include newline making it more accessible when working with the sysfs file system in the shell, etc. Normally, this wouldn't be a problem, but if the function utf16s_to_utf8s() happens to return the number of bytes written to be precisely PAGE_SIZE, then we would overrun the buffer and write the newline character outside the allotted space which can have undefined consequences or result in a failure. To fix this buffer overrun, ensure that there always is enough space left for the newline character to be safely appended. Fixes: d1efe3c324ea ("ACPI: Add new sysfs interface to export device description") Signed-off-by: Krzysztof Wilczyński Reviewed-by: Bjorn Helgaas Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 942511da9f3e063c9ec5595033dbff15bd60aa4c Author: Jing Xiangfeng Date: Wed Jun 2 19:58:12 2021 +0800 ACPI: tables: FPDT: Add missing acpi_put_table() in acpi_init_fpdt() [ Upstream commit dd9eaa23e72572d4f1c03f2e5d2e14a5b5793e79 ] acpi_init_fpdt() forgets to call acpi_put_table() in an error path. Add the missing function call to fix it. Fixes: d1eb86e59be0 ("ACPI: tables: introduce support for FPDT table") Signed-off-by: Jing Xiangfeng Acked-by: Zhang Rui Reviewed-by: Hanjun Guo [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 620f58c6c0d88cbaf3ac307f16fb6ca95ef0ff45 Author: Mario Limonciello Date: Fri May 28 11:02:34 2021 -0500 nvme-pci: look for StorageD3Enable on companion ACPI device instead [ Upstream commit e21e0243e7b0f1c2a21d21f4d115f7b37175772a ] The documentation around the StorageD3Enable property hints that it should be made on the PCI device. This is where newer AMD systems set the property and it's required for S0i3 support. So rather than look for nodes of the root port only present on Intel systems, switch to the companion ACPI device for all systems. David Box from Intel indicated this should work on Intel as well. Link: https://lore.kernel.org/linux-nvme/YK6gmAWqaRmvpJXb@google.com/T/#m900552229fa455867ee29c33b854845fce80ba70 Link: https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/power-management-for-storage-hardware-devices-intro Fixes: df4f9bc4fb9c ("nvme-pci: add support for ACPI StorageD3Enable property") Suggested-by: Liang Prike Acked-by: Raul E Rangel Signed-off-by: Mario Limonciello Reviewed-by: David E. Box Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 52a535c630e50495f1c24bc6b2a847edaea155c6 Author: Praveen Kumar Date: Mon May 31 13:10:46 2021 +0530 x86/hyperv: fix logical processor creation [ Upstream commit 450605c28d571eddca39a65fdbc1338add44c6d9 ] Microsoft Hypervisor expects the logical processor index to be the same as CPU's index during logical processor creation. Using cpu_physical_id confuses hypervisor's scheduler. That causes the root partition not boot when core scheduler is used. This patch removes the call to cpu_physical_id and uses the CPU index directly for bringing up logical processor. This scheme works for both classic scheduler and core scheduler. Fixes: 333abaf5abb3 (x86/hyperv: implement and use hv_smp_prepare_cpus) Signed-off-by: Praveen Kumar Link: https://lore.kernel.org/r/20210531074046.113452-1-kumarpraveen@linux.microsoft.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 9ec73d75f8c6a3ff4ce7dccca2c201aad755934d Author: Ming Lei Date: Tue May 11 23:22:33 2021 +0800 block: avoid double io accounting for flush request [ Upstream commit 84da7acc3ba53af26f15c4b0ada446127b7a7836 ] For flush request, rq->end_io() may be called two times, one is from timeout handling(blk_mq_check_expired()), another is from normal completion(__blk_mq_end_request()). Move blk_account_io_flush() after flush_rq->ref drops to zero, so io accounting can be done just once for flush request. Fixes: b68663186577 ("block: add iostat counters for flush requests") Reviewed-by: Bart Van Assche Reviewed-by: Christoph Hellwig Tested-by: John Garry Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20210511152236.763464-2-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 25adea16787053aeb754293a6434b8a9a73a452b Author: Rafael J. Wysocki Date: Fri May 14 21:08:51 2021 +0200 ACPI: PM / fan: Put fan device IDs into separate header file [ Upstream commit b9370dceabb7841c5e65ce4ee4405b9db5231fc4 ] The ACPI fan device IDs are shared between the fan driver and the device power management code. The former is modular, so it needs to include the table of device IDs for module autoloading and the latter needs that list to avoid attaching the generic ACPI PM domain to fan devices (which doesn't make sense) possibly before the fan driver module is loaded. Unfortunately, that requires the list of fan device IDs to be updated in two places which is prone to mistakes, so put it into a symbol definition in a separate header file so there is only one copy of it in case it needs to be updated again in the future. Fixes: b9ea0bae260f ("ACPI: PM: Avoid attaching ACPI PM domain to certain devices") Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 7e95c52cb786b34ce32470809636a8c436b3c309 Author: YueHaibing Date: Fri May 14 14:48:43 2021 +0800 PM / devfreq: Add missing error code in devfreq_add_device() [ Upstream commit 18b380ed61f892ed06838d1f1a5124d966292ed3 ] Set err code in the error path before jumping to the end of the function. Fixes: 4dc3bab8687f ("PM / devfreq: Add support delayed timer for polling mode") Signed-off-by: YueHaibing Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin commit 73bbd350e9ebd28594ee05a48af8e2595d660230 Author: Arnd Bergmann Date: Wed Apr 21 15:54:53 2021 +0200 EDAC/aspeed: Use proper format string for printing resource [ Upstream commit 2e2f16d5cdb33e5f6fc53b7ad66c9f456d5f2950 ] On ARMv7, resource_size_t can be 64-bit, which breaks printing it as %x: drivers/edac/aspeed_edac.c: In function 'init_csrows': drivers/edac/aspeed_edac.c:257:28: error: format '%x' expects argument of \ type 'unsigned int', but argument 4 has type 'resource_size_t' {aka 'long \ long unsigned int'} [-Werror=format=] 257 | dev_dbg(mci->pdev, "dt: /memory node resources: first page \ r.start=0x%x, resource_size=0x%x, PAGE_SHIFT macro=0x%x\n", Use the special %pR format string to pretty-print the entire resource instead. Fixes: edfc2d73ca45 ("EDAC/aspeed: Add support for AST2400 and AST2600") Signed-off-by: Arnd Bergmann Signed-off-by: Borislav Petkov Reviewed-by: Andrew Jeffery Link: https://lkml.kernel.org/r/20210421135500.3518661-1-arnd@kernel.org Signed-off-by: Sasha Levin commit a976b32a125f891ff05fb03610892ebb2a39558c Author: Marek Szyprowski Date: Fri Apr 23 22:44:57 2021 +0200 media: s5p-mfc: Fix display delay control creation [ Upstream commit 61c6f04a988e420a1fc5e8e81cf9aebf142a7bd6 ] v4l2_ctrl_new_std() fails if the caller provides no 'step' parameter for integer control, so define it to fix following error: s5p_mfc_dec_ctrls_setup:1166: Adding control (1) failed Fixes: c3042bff918a ("media: s5p-mfc: Use display delay and display enable std controls") Signed-off-by: Marek Szyprowski Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit f77ecd22b784132ae5c5eb62cb1a563a4f0e8225 Author: Dafna Hirschfeld Date: Fri Apr 23 19:27:45 2021 +0200 media: mtk-vpu: on suspend, read/write regs only if vpu is running [ Upstream commit 11420749c6b4b237361750de3d5b5579175f8622 ] If the vpu is not running, we should not rely on VPU_IDLE_REG value. In this case, the suspend cb should only unprepare the clock. This fixes a system-wide suspend to ram failure: [ 273.073363] PM: suspend entry (deep) [ 273.410502] mtk-msdc 11230000.mmc: phase: [map:ffffffff] [maxlen:32] [final:10] [ 273.455926] Filesystems sync: 0.378 seconds [ 273.589707] Freezing user space processes ... (elapsed 0.003 seconds) done. [ 273.600104] OOM killer disabled. [ 273.603409] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 273.613361] mwifiex_sdio mmc2:0001:1: None of the WOWLAN triggers enabled [ 274.784952] mtk_vpu 10020000.vpu: vpu idle timeout [ 274.789764] PM: dpm_run_callback(): platform_pm_suspend+0x0/0x70 returns -5 [ 274.796740] mtk_vpu 10020000.vpu: PM: failed to suspend: error -5 [ 274.802842] PM: Some devices failed to suspend, or early wake event detected [ 275.426489] OOM killer enabled. [ 275.429718] Restarting tasks ... [ 275.435765] done. [ 275.447510] PM: suspend exit Fixes: 1f565e263c3e ("media: mtk-vpu: VPU should be in idle state before system is suspended") Signed-off-by: Dafna Hirschfeld Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit e92492c7cb1513b1d9fe3998bf04e33165e99ae7 Author: Philipp Zabel Date: Mon Mar 22 15:44:08 2021 +0100 media: video-mux: Skip dangling endpoints [ Upstream commit 95778c2d0979618e3349b1d2324ec282a5a6adbf ] i.MX6 device tree include files contain dangling endpoints for the board device tree writers' convenience. These are still included in many existing device trees. Treat dangling endpoints as non-existent to support them. Signed-off-by: Philipp Zabel Signed-off-by: Hans Verkuil Fixes: 612b385efb1e ("media: video-mux: Create media links in bound notifier") Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 27a1251783a58654f1ae428289611ca984eadf08 Author: Sean Christopherson Date: Tue Jun 22 13:05:11 2021 -0700 KVM: selftests: Remove errant asm/barrier.h include to fix arm64 build [ Upstream commit ecc3a92c6f4953c134a9590c762755e6593f507c ] Drop an unnecessary include of asm/barrier.h from dirty_log_test.c to allow the test to build on arm64. arm64, s390, and x86 all build cleanly without the include (PPC and MIPS aren't supported in KVM's selftests). arm64's barrier.h includes linux/kasan-checks.h, which is not copied into tools/. In file included from ../../../../tools/include/asm/barrier.h:8, from dirty_log_test.c:19: .../arm64/include/asm/barrier.h:12:10: fatal error: linux/kasan-checks.h: No such file or directory 12 | #include | ^~~~~~~~~~~~~~~~~~~~~~ compilation terminated. Fixes: 84292e565951 ("KVM: selftests: Add dirty ring buffer test") Cc: Peter Xu Signed-off-by: Sean Christopherson Message-Id: <20210622200529.3650424-2-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit aa138d4229043c11b3136e9e65d84f577fb38180 Author: Hou Wenlong Date: Tue Jun 22 21:55:32 2021 +0800 KVM: selftests: fix triple fault if ept=0 in dirty_log_test [ Upstream commit e5830fb13b8cad5e3bdf84f0f7a3dcb4f4d9bcbb ] Commit 22f232d134e1 ("KVM: selftests: x86: Set supported CPUIDs on default VM") moved vcpu_set_cpuid into vm_create_with_vcpus, but dirty_log_test doesn't use it to create vm. So vcpu's CPUIDs is not set, the guest's pa_bits in kvm would be smaller than the value queried by userspace. However, the dirty track memory slot is in the highest GPA, the reserved bits in gpte would be set with wrong pa_bits. For shadow paging, page fault would fail in permission_fault and be injected into guest. Since guest doesn't have idt, it finally leads to vm_exit for triple fault. Move vcpu_set_cpuid into vm_vcpu_add_default to set supported CPUIDs on default vcpu, since almost all tests need it. Fixes: 22f232d134e1 ("KVM: selftests: x86: Set supported CPUIDs on default VM") Signed-off-by: Hou Wenlong Message-Id: <411ea2173f89abce56fc1fca5af913ed9c5a89c9.1624351343.git.houwenlong93@linux.alibaba.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 979965c33f734a1666af67900408f997ac669c23 Author: Zhaoyang Huang Date: Fri Jun 11 08:29:34 2021 +0800 psi: Fix race between psi_trigger_create/destroy [ Upstream commit 8f91efd870ea5d8bc10b0fcc9740db51cd4c0c83 ] Race detected between psi_trigger_destroy/create as shown below, which cause panic by accessing invalid psi_system->poll_wait->wait_queue_entry and psi_system->poll_timer->entry->next. Under this modification, the race window is removed by initialising poll_wait and poll_timer in group_init which are executed only once at beginning. psi_trigger_destroy() psi_trigger_create() mutex_lock(trigger_lock); rcu_assign_pointer(poll_task, NULL); mutex_unlock(trigger_lock); mutex_lock(trigger_lock); if (!rcu_access_pointer(group->poll_task)) { timer_setup(poll_timer, poll_timer_fn, 0); rcu_assign_pointer(poll_task, task); } mutex_unlock(trigger_lock); synchronize_rcu(); del_timer_sync(poll_timer); <-- poll_timer has been reinitialized by psi_trigger_create() So, trigger_lock/RCU correctly protects destruction of group->poll_task but misses this race affecting poll_timer and poll_wait. Fixes: 461daba06bdc ("psi: eliminate kthread_worker from psi trigger scheduling mechanism") Co-developed-by: ziwei.dai Signed-off-by: ziwei.dai Co-developed-by: ke.wang Signed-off-by: ke.wang Signed-off-by: Zhaoyang Huang Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Suren Baghdasaryan Acked-by: Johannes Weiner Link: https://lkml.kernel.org/r/1623371374-15664-1-git-send-email-huangzhaoyang@gmail.com Signed-off-by: Sasha Levin commit a476aa9eea4b0b5ba62d9b8062bdfe0e6e48eaf6 Author: Josh Poimboeuf Date: Wed Jun 23 10:42:28 2021 -0500 objtool: Don't make .altinstructions writable [ Upstream commit e31694e0a7a709293319475d8001e05e31f2178c ] When objtool creates the .altinstructions section, it sets the SHF_WRITE flag to make the section writable -- unless the section had already been previously created by the kernel. The mismatch between kernel-created and objtool-created section flags can cause failures with external tooling (kpatch-build). And the section doesn't need to be writable anyway. Make the section flags consistent with the kernel's. Fixes: 9bc0bb50727c ("objtool/x86: Rewrite retpoline thunk calls") Reported-by: Joe Lawrence Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/6c284ae89717889ea136f9f0064d914cd8329d31.1624462939.git.jpoimboe@redhat.com Signed-off-by: Sasha Levin commit c7c6fb95d7c4df6e09629149aa35d0255e77adae Author: Herbert Xu Date: Thu Jun 17 15:57:12 2021 +0800 crypto: nx - Fix RCU warning in nx842_OF_upd_status [ Upstream commit 2a96726bd0ccde4f12b9b9a9f61f7b1ac5af7e10 ] The function nx842_OF_upd_status triggers a sparse RCU warning when it directly dereferences the RCU-protected devdata. This appears to be an accident as there was another variable of the same name that was passed in from the caller. After it was removed (because the main purpose of using it, to update the status member was itself removed) the global variable unintenionally stood in as its replacement. This patch restores the devdata parameter. Fixes: 90fd73f912f0 ("crypto: nx - remove pSeries NX 'status' field") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 10a5921d19c746aeaaf91755d4ad3d7b9720f43e Author: Peter Zijlstra Date: Tue Jun 22 16:21:01 2021 +0200 perf: Fix task context PMU for Hetero [ Upstream commit 012669c740e6e2afa8bdb95394d06676f933dd2d ] On HETEROGENEOUS hardware (ARM big.Little, Intel Alderlake etc.) each CPU might have a different hardware PMU. Since each such PMU is represented by a different struct pmu, but we only have a single HW task context. That means that the task context needs to switch PMU type when it switches CPUs. Not doing this means that ctx->pmu calls (pmu_{dis,en}able(), {start,commit,cancel}_txn() etc.) are called against the wrong PMU and things will go wobbly. Fixes: f83d2f91d259 ("perf/x86/intel: Add Alder Lake Hybrid support") Reported-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Tested-by: Kan Liang Link: https://lkml.kernel.org/r/YMsy7BuGT8nBTspT@hirez.programming.kicks-ass.net Signed-off-by: Sasha Levin commit 48a513f67b2791c5427ad0eebe386b5f9ca59b46 Author: Mirko Vogt Date: Mon Jun 14 16:45:07 2021 +0200 spi: spi-sun6i: Fix chipselect/clock bug [ Upstream commit 0d7993b234c9fad8cb6bec6adfaa74694ba85ecb ] The current sun6i SPI implementation initializes the transfer too early, resulting in SCK going high before the transfer. When using an additional (gpio) chipselect with sun6i, the chipselect is asserted at a time when clock is high, making the SPI transfer fail. This is due to SUN6I_GBL_CTL_BUS_ENABLE being written into SUN6I_GBL_CTL_REG at an early stage. Moving that to the transfer function, hence, right before the transfer starts, mitigates that problem. Fixes: 3558fe900e8af (spi: sunxi: Add Allwinner A31 SPI controller driver) Signed-off-by: Mirko Vogt Signed-off-by: Ralf Schlatterbeck Link: https://lore.kernel.org/r/20210614144507.y3udezjfbko7eavv@runtux.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0a32c742e877cb61b14aa9bc74ef5b8839c8dde9 Author: Joerg Roedel Date: Tue Jun 22 16:48:25 2021 +0200 x86/sev: Use "SEV: " prefix for messages from sev.c [ Upstream commit 8d9d46bbf3b6b7ff8edcac33603ab45c29e0e07f ] The source file has been renamed froms sev-es.c to sev.c, but the messages are still prefixed with "SEV-ES: ". Change that to "SEV: " to make it consistent. Fixes: e759959fe3b8 ("x86/sev-es: Rename sev-es.{ch} to sev.{ch}") Signed-off-by: Joerg Roedel Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20210622144825.27588-4-joro@8bytes.org Signed-off-by: Sasha Levin commit a2c53d934a91a08e83695574d2ce243917b2b0f4 Author: Peter Zijlstra Date: Thu Jun 17 20:57:19 2021 +0200 lockdep/selftests: Fix selftests vs PROVE_RAW_LOCK_NESTING [ Upstream commit c0c2c0dad6a06e0c05e9a52d65f932bd54364c97 ] When PROVE_RAW_LOCK_NESTING=y many of the selftests FAILED because HARDIRQ context is out-of-bounds for spinlocks. Instead make the default hardware context the threaded hardirq context, which preserves the old locking rules. The wait-type specific locking selftests will have a non-threaded HARDIRQ variant. Fixes: de8f5e4f2dc1 ("lockdep: Introduce wait-type checks") Signed-off-by: Peter Zijlstra (Intel) Tested-by: Joerg Roedel Link: https://lore.kernel.org/r/20210617190313.322096283@infradead.org Signed-off-by: Sasha Levin commit 5fd218de86a33de7f6bdb6df477b581a0cdd407c Author: Peter Zijlstra Date: Thu Jun 17 20:57:18 2021 +0200 lockdep: Fix wait-type for empty stack [ Upstream commit f8b298cc39f0619544c607eaef09fd0b2afd10f3 ] Even the very first lock can violate the wait-context check, consider the various IRQ contexts. Fixes: de8f5e4f2dc1 ("lockdep: Introduce wait-type checks") Signed-off-by: Peter Zijlstra (Intel) Tested-by: Joerg Roedel Link: https://lore.kernel.org/r/20210617190313.256987481@infradead.org Signed-off-by: Sasha Levin commit eed2284c449febcf72fe87c1f60012b311ee9514 Author: Qais Yousef Date: Thu Jun 17 17:51:55 2021 +0100 sched/uclamp: Fix uclamp_tg_restrict() [ Upstream commit 0213b7083e81f4acd69db32cb72eb4e5f220329a ] Now cpu.uclamp.min acts as a protection, we need to make sure that the uclamp request of the task is within the allowed range of the cgroup, that is it is clamp()'ed correctly by tg->uclamp[UCLAMP_MIN] and tg->uclamp[UCLAMP_MAX]. As reported by Xuewen [1] we can have some corner cases where there's inversion between uclamp requested by task (p) and the uclamp values of the taskgroup it's attached to (tg). Following table demonstrates 2 corner cases: | p | tg | effective -----------+-----+------+----------- CASE 1 -----------+-----+------+----------- uclamp_min | 60% | 0% | 60% -----------+-----+------+----------- uclamp_max | 80% | 50% | 50% -----------+-----+------+----------- CASE 2 -----------+-----+------+----------- uclamp_min | 0% | 30% | 30% -----------+-----+------+----------- uclamp_max | 20% | 50% | 20% -----------+-----+------+----------- With this fix we get: | p | tg | effective -----------+-----+------+----------- CASE 1 -----------+-----+------+----------- uclamp_min | 60% | 0% | 50% -----------+-----+------+----------- uclamp_max | 80% | 50% | 50% -----------+-----+------+----------- CASE 2 -----------+-----+------+----------- uclamp_min | 0% | 30% | 30% -----------+-----+------+----------- uclamp_max | 20% | 50% | 30% -----------+-----+------+----------- Additionally uclamp_update_active_tasks() must now unconditionally update both UCLAMP_MIN/MAX because changing the tg's UCLAMP_MAX for instance could have an impact on the effective UCLAMP_MIN of the tasks. | p | tg | effective -----------+-----+------+----------- old -----------+-----+------+----------- uclamp_min | 60% | 0% | 50% -----------+-----+------+----------- uclamp_max | 80% | 50% | 50% -----------+-----+------+----------- *new* -----------+-----+------+----------- uclamp_min | 60% | 0% | *60%* -----------+-----+------+----------- uclamp_max | 80% |*70%* | *70%* -----------+-----+------+----------- [1] https://lore.kernel.org/lkml/CAB8ipk_a6VFNjiEnHRHkUMBKbA+qzPQvhtNjJ_YNzQhqV_o8Zw@mail.gmail.com/ Fixes: 0c18f2ecfcc2 ("sched/uclamp: Fix wrong implementation of cpu.uclamp.min") Reported-by: Xuewen Yan Signed-off-by: Qais Yousef Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210617165155.3774110-1-qais.yousef@arm.com Signed-off-by: Sasha Levin commit 00e1a563f1ecf5c41b1a5a766df1b50cee7c07e3 Author: Vincent Donnefort Date: Mon Jun 21 11:37:52 2021 +0100 sched/rt: Fix Deadline utilization tracking during policy change [ Upstream commit d7d607096ae6d378b4e92d49946d22739c047d4c ] DL keeps track of the utilization on a per-rq basis with the structure avg_dl. This utilization is updated during task_tick_dl(), put_prev_task_dl() and set_next_task_dl(). However, when the current running task changes its policy, set_next_task_dl() which would usually take care of updating the utilization when the rq starts running DL tasks, will not see a such change, leaving the avg_dl structure outdated. When that very same task will be dequeued later, put_prev_task_dl() will then update the utilization, based on a wrong last_update_time, leading to a huge spike in the DL utilization signal. The signal would eventually recover from this issue after few ms. Even if no DL tasks are run, avg_dl is also updated in __update_blocked_others(). But as the CPU capacity depends partly on the avg_dl, this issue has nonetheless a significant impact on the scheduler. Fix this issue by ensuring a load update when a running task changes its policy to DL. Fixes: 3727e0e ("sched/dl: Add dl_rq utilization tracking") Signed-off-by: Vincent Donnefort Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Vincent Guittot Link: https://lore.kernel.org/r/1624271872-211872-3-git-send-email-vincent.donnefort@arm.com Signed-off-by: Sasha Levin commit b5ee2425eaf65cf40b2b201a1c374634c536ac21 Author: Vincent Donnefort Date: Mon Jun 21 11:37:51 2021 +0100 sched/rt: Fix RT utilization tracking during policy change [ Upstream commit fecfcbc288e9f4923f40fd23ca78a6acdc7fdf6c ] RT keeps track of the utilization on a per-rq basis with the structure avg_rt. This utilization is updated during task_tick_rt(), put_prev_task_rt() and set_next_task_rt(). However, when the current running task changes its policy, set_next_task_rt() which would usually take care of updating the utilization when the rq starts running RT tasks, will not see a such change, leaving the avg_rt structure outdated. When that very same task will be dequeued later, put_prev_task_rt() will then update the utilization, based on a wrong last_update_time, leading to a huge spike in the RT utilization signal. The signal would eventually recover from this issue after few ms. Even if no RT tasks are run, avg_rt is also updated in __update_blocked_others(). But as the CPU capacity depends partly on the avg_rt, this issue has nonetheless a significant impact on the scheduler. Fix this issue by ensuring a load update when a running task changes its policy to RT. Fixes: 371bf427 ("sched/rt: Add rt_rq utilization tracking") Signed-off-by: Vincent Donnefort Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Vincent Guittot Link: https://lore.kernel.org/r/1624271872-211872-2-git-send-email-vincent.donnefort@arm.com Signed-off-by: Sasha Levin commit c6362a74da0c6fbe2c0f0507ccef7c5194994edc Author: Joerg Roedel Date: Fri Jun 18 13:54:09 2021 +0200 x86/sev: Split up runtime #VC handler for correct state tracking [ Upstream commit be1a5408868af341f61f93c191b5e346ee88c82a ] Split up the #VC handler code into a from-user and a from-kernel part. This allows clean and correct state tracking, as the #VC handler needs to enter NMI-state when raised from kernel mode and plain IRQ state when raised from user-mode. Fixes: 62441a1fb532 ("x86/sev-es: Correctly track IRQ states in runtime #VC handler") Suggested-by: Peter Zijlstra Signed-off-by: Joerg Roedel Signed-off-by: Borislav Petkov Acked-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210618115409.22735-3-joro@8bytes.org Signed-off-by: Sasha Levin commit 99e67ee2a1f886f0ebea40c090a7149a1a975735 Author: Joerg Roedel Date: Fri Jun 18 13:54:08 2021 +0200 x86/sev: Make sure IRQs are disabled while GHCB is active [ Upstream commit d187f217335dba2b49fc9002aab2004e04acddee ] The #VC handler only cares about IRQs being disabled while the GHCB is active, as it must not be interrupted by something which could cause another #VC while it holds the GHCB (NMI is the exception for which the backup GHCB exits). Make sure nothing interrupts the code path while the GHCB is active by making sure that callers of __sev_{get,put}_ghcb() have disabled interrupts upfront. [ bp: Massage commit message. ] Signed-off-by: Joerg Roedel Signed-off-by: Borislav Petkov Acked-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210618115409.22735-2-joro@8bytes.org Signed-off-by: Sasha Levin commit c7b63ad221fb25376e9bf6f9363a6ea3482f00f8 Author: David Sterba Date: Tue Jul 7 18:38:05 2020 +0200 btrfs: clear log tree recovering status if starting transaction fails [ Upstream commit 1aeb6b563aea18cd55c73cf666d1d3245a00f08c ] When a log recovery is in progress, lots of operations have to take that into account, so we keep this status per tree during the operation. Long time ago error handling revamp patch 79787eaab461 ("btrfs: replace many BUG_ONs with proper error handling") removed clearing of the status in an error branch. Add it back as was intended in e02119d5a7b4 ("Btrfs: Add a write ahead tree log to optimize synchronous operations"). There are probably no visible effects, log replay is done only during mount and if it fails all structures are cleared so the stale status won't be kept. Fixes: 79787eaab461 ("btrfs: replace many BUG_ONs with proper error handling") Reviewed-by: Qu Wenruo Reviewed-by: Anand Jain Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit f65ff29ff3a5413f2ba5a7e5142f5294ef88e41c Author: Matti Vaittinen Date: Thu Jun 3 08:43:04 2021 +0300 regulator: bd9576: Fix the driver name in id table [ Upstream commit e71e7d3df7eb712fc29b609bd712a63d60b81b5f ] Driver name was changed in MFD cell: https://lore.kernel.org/lkml/560b9748094392493ebf7af11b6cc558776c4fd5.1613031055.git.matti.vaittinen@fi.rohmeurope.com/ Fix the ID table to match this. Fixes: b1b3ced38979 ("mfd: Support ROHM BD9576MUF and BD9573MUF") Signed-off-by: Matti Vaittinen Link: https://lore.kernel.org/r/e0483149333626b3bea298f305cf2809429d1822.1622628334.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3fefb73f890d242d424266b133895ab810d897f2 Author: Axel Lin Date: Sat Jun 19 20:34:23 2021 +0800 regulator: hi6421v600: Fix setting idle mode [ Upstream commit 57c045bc727001c43b6a65adb0418aa7b3e6dbd0 ] commit db27f8294cd7 changed eco_mode << (ffs(sreg->eco_mode_mask) - 1) to sreg->eco_mode_mask << (ffs(sreg->eco_mode_mask) - 1) which is wrong. Fix it by simply set val = sreg->eco_mode_mask. In additional, sreg->eco_mode_mask can be 0 (LDO3, LDO33, LDO34). Return -EINVAL if idle mode is not supported when sreg->eco_mode_mask is 0. While at it, also use unsigned int for reg_val/val which is the expected type for regmap_read and regmap_update_bits. Fixes: db27f8294cd7 ("staging: regulator: hi6421v600-regulator: use shorter names for OF properties") Signed-off-by: Axel Lin Link: https://lore.kernel.org/r/20210619123423.4091429-1-axel.lin@ingics.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cf6fd4b281a6d0a093ab7f98a27c20c1c8bd2976 Author: Bhupesh Sharma Date: Thu Jun 17 10:47:11 2021 +0530 regulator: qcom-rpmh: Add terminator at the end of pm7325x_vreg_data[] array [ Upstream commit f26cdadad729743888eb4ac2c17eac3cf845b493 ] Add missing terminator(s) at the end of pm7325x_vreg_data[] array instances. Fixes: c4e5aa3dbee5 ("regulator: qcom-rpmh: Add PM7325/PMR735A regulator support") Cc: Mark Brown Reviewed-by: Bjorn Andersson Signed-off-by: Bhupesh Sharma Link: https://lore.kernel.org/r/20210617051712.345372-5-bhupesh.sharma@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 35cf50efb7790a09b1c04df357a8bf9ec361e50b Author: Axel Lin Date: Sun Jun 20 21:27:15 2021 +0800 regulator: hi655x: Fix pass wrong pointer to config.driver_data [ Upstream commit 61eb1b24f9e4f4e0725aa5f8164a932c933f3339 ] Current code sets config.driver_data to a zero initialized regulator which is obviously wrong. Fix it. Fixes: 4618119b9be5 ("regulator: hi655x: enable regulator for hi655x PMIC") Signed-off-by: Axel Lin Link: https://lore.kernel.org/r/20210620132715.60215-1-axel.lin@ingics.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 33e8f03d5950eeec2415d4287407bb23a3d9ada8 Author: Alexandru Elisei Date: Fri Jun 18 11:51:39 2021 +0100 KVM: arm64: Don't zero the cycle count register when PMCR_EL0.P is set [ Upstream commit 2a71fabf6a1bc9162a84e18d6ab991230ca4d588 ] According to ARM DDI 0487G.a, page D13-3895, setting the PMCR_EL0.P bit to 1 has the following effect: "Reset all event counters accessible in the current Exception level, not including PMCCNTR_EL0, to zero." Similar behaviour is described for AArch32 on page G8-7022. Make it so. Fixes: c01d6a18023b ("KVM: arm64: pmu: Only handle supported event counters") Signed-off-by: Alexandru Elisei Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210618105139.83795-1-alexandru.elisei@arm.com Signed-off-by: Sasha Levin commit 50cd74c7f38aea83858db25d5d97926a8e6f8384 Author: Tuan Phan Date: Thu Jun 17 09:08:49 2021 -0700 perf/arm-cmn: Fix invalid pointer when access dtc object sharing the same IRQ number [ Upstream commit 4e16f283edc289820e9b2d6f617ed8e514ee8396 ] When multiple dtcs share the same IRQ number, the irq_friend which used to refer to dtc object gets calculated incorrect which leads to invalid pointer. Fixes: 0ba64770a2f2 ("perf: Add Arm CMN-600 PMU driver") Signed-off-by: Tuan Phan Reviewed-by: Robin Murphy Link: https://lore.kernel.org/r/1623946129-3290-1-git-send-email-tuanphan@os.amperecomputing.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit e96f6d4bb390236cd350d6f5680e1b525316709d Author: Kai Huang Date: Tue Jun 15 12:57:10 2021 +1200 KVM: x86/mmu: Fix pf_fixed count in tdp_mmu_map_handle_target_level() [ Upstream commit 857f84743e4b78500afae010d866675642e18e90 ] Currently pf_fixed is not increased when prefault is true. This is not correct, since prefault here really means "async page fault completed". In that case, the original page fault from the guest was morphed into as async page fault and pf_fixed was not increased. So when prefault indicates async page fault is completed, pf_fixed should be increased. Additionally, currently pf_fixed is also increased even when page fault is spurious, while legacy MMU increases pf_fixed when page fault returns RET_PF_EMULATE or RET_PF_FIXED. To fix above two issues, change to increase pf_fixed when return value is not RET_PF_SPURIOUS (RET_PF_RETRY has already been ruled out by reaching here). More information: https://lore.kernel.org/kvm/cover.1620200410.git.kai.huang@intel.com/T/#mbb5f8083e58a2cd262231512b9211cbe70fc3bd5 Fixes: bb18842e2111 ("kvm: x86/mmu: Add TDP MMU PF handler") Reviewed-by: Sean Christopherson Signed-off-by: Kai Huang Message-Id: <2ea8b7f5d4f03c99b32bc56fc982e1e4e3d3fc6b.1623717884.git.kai.huang@intel.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 5f7fe9c419e7e601503d5899ba5d3f590cb8cb00 Author: Kai Huang Date: Tue Jun 15 12:57:09 2021 +1200 KVM: x86/mmu: Fix return value in tdp_mmu_map_handle_target_level() [ Upstream commit 57a3e96d6d17ae5ac9861ef34af024a627f1c3bb ] Currently tdp_mmu_map_handle_target_level() returns 0, which is RET_PF_RETRY, when page fault is actually fixed. This makes kvm_tdp_mmu_map() also return RET_PF_RETRY in this case, instead of RET_PF_FIXED. Fix by initializing ret to RET_PF_FIXED. Note that kvm_mmu_page_fault() resumes guest on both RET_PF_RETRY and RET_PF_FIXED, which means in practice returning the two won't make difference, so this fix alone won't be necessary for stable tree. Fixes: bb18842e2111 ("kvm: x86/mmu: Add TDP MMU PF handler") Reviewed-by: Sean Christopherson Reviewed-by: Ben Gardon Signed-off-by: Kai Huang Message-Id: Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 31678100f32a717ad53d9a8dd4509296e8035ac0 Author: Sean Christopherson Date: Wed Jun 9 16:42:23 2021 -0700 KVM: nVMX: Don't clobber nested MMU's A/D status on EPTP switch [ Upstream commit 272b0a998d084e7667284bdd2d0c675c6a2d11de ] Drop bogus logic that incorrectly clobbers the accessed/dirty enabling status of the nested MMU on an EPTP switch. When nested EPT is enabled, walk_mmu points at L2's _legacy_ page tables, not L1's EPT for L2. This is likely a benign bug, as mmu->ept_ad is never consumed (since the MMU is not a nested EPT MMU), and stuffing mmu_role.base.ad_disabled will never propagate into future shadow pages since the nested MMU isn't used to map anything, just to walk L2's page tables. Note, KVM also does a full MMU reload, i.e. the guest_mmu will be recreated using the new EPTP, and thus any change in A/D enabling will be properly recognized in the relevant MMU. Fixes: 41ab93727467 ("KVM: nVMX: Emulate EPTP switching for the L1 hypervisor") Signed-off-by: Sean Christopherson Message-Id: <20210609234235.1244004-4-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit ffaaf321c09ca0b4c2daf2ae9a810efe958ff196 Author: Sean Christopherson Date: Wed Jun 9 16:42:22 2021 -0700 KVM: nVMX: Ensure 64-bit shift when checking VMFUNC bitmap [ Upstream commit 0e75225dfa4c5d5d51291f54a3d2d5895bad38da ] Use BIT_ULL() instead of an open-coded shift to check whether or not a function is enabled in L1's VMFUNC bitmap. This is a benign bug as KVM supports only bit 0, and will fail VM-Enter if any other bits are set, i.e. bits 63:32 are guaranteed to be zero. Note, "function" is bounded by hardware as VMFUNC will #UD before taking a VM-Exit if the function is greater than 63. Before: if ((vmcs12->vm_function_control & (1 << function)) == 0) 0x000000000001a916 <+118>: mov $0x1,%eax 0x000000000001a91b <+123>: shl %cl,%eax 0x000000000001a91d <+125>: cltq 0x000000000001a91f <+127>: and 0x128(%rbx),%rax After: if (!(vmcs12->vm_function_control & BIT_ULL(function & 63))) 0x000000000001a955 <+117>: mov 0x128(%rbx),%rdx 0x000000000001a95c <+124>: bt %rax,%rdx Fixes: 27c42a1bb867 ("KVM: nVMX: Enable VMFUNC for the L1 hypervisor") Signed-off-by: Sean Christopherson Message-Id: <20210609234235.1244004-3-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 2e5c0d69ec467cf17838be7af30f7fab585412c4 Author: Sean Christopherson Date: Wed Jun 9 16:42:21 2021 -0700 KVM: nVMX: Sync all PGDs on nested transition with shadow paging [ Upstream commit 07ffaf343e34b555c9e7ea39a9c81c439a706f13 ] Trigger a full TLB flush on behalf of the guest on nested VM-Enter and VM-Exit when VPID is disabled for L2. kvm_mmu_new_pgd() syncs only the current PGD, which can theoretically leave stale, unsync'd entries in a previous guest PGD, which could be consumed if L2 is allowed to load CR3 with PCID_NOFLUSH=1. Rename KVM_REQ_HV_TLB_FLUSH to KVM_REQ_TLB_FLUSH_GUEST so that it can be utilized for its obvious purpose of emulating a guest TLB flush. Note, there is no change the actual TLB flush executed by KVM, even though the fast PGD switch uses KVM_REQ_TLB_FLUSH_CURRENT. When VPID is disabled for L2, vpid02 is guaranteed to be '0', and thus nested_get_vpid02() will return the VPID that is shared by L1 and L2. Generate the request outside of kvm_mmu_new_pgd(), as getting the common helper to correctly identify which requested is needed is quite painful. E.g. using KVM_REQ_TLB_FLUSH_GUEST when nested EPT is in play is wrong as a TLB flush from the L1 kernel's perspective does not invalidate EPT mappings. And, by using KVM_REQ_TLB_FLUSH_GUEST, nVMX can do future simplification by moving the logic into nested_vmx_transition_tlb_flush(). Fixes: 41fab65e7c44 ("KVM: nVMX: Skip MMU sync on nested VMX transition when possible") Signed-off-by: Sean Christopherson Message-Id: <20210609234235.1244004-2-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 80c0f6a4f6360a173f9a570a45ae8838962f6369 Author: Jim Mattson Date: Fri Jun 4 10:26:02 2021 -0700 KVM: nVMX: Add a return code to vmx_complete_nested_posted_interrupt [ Upstream commit 650293c3de6b042c4a2e87b2bc678efcff3843e8 ] No functional change intended. Signed-off-by: Jim Mattson Reviewed-by: Oliver Upton Message-Id: <20210604172611.281819-4-jmattson@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 8077ff1eeccba7a09f3d6ba88b27a55338b6f42f Author: Guenter Roeck Date: Wed May 26 08:40:16 2021 -0700 hwmon: (max31790) Fix fan speed reporting for fan7..12 [ Upstream commit cbbf244f0515af3472084f22b6213121b4a63835 ] Fans 7..12 do not have their own set of configuration registers. So far the code ignored that and read beyond the end of the configuration register range to get the tachometer period. This resulted in more or less random fan speed values for those fans. The datasheet is quite vague when it comes to defining the tachometer period for fans 7..12. Experiments confirm that the period is the same for both fans associated with a given set of configuration registers. Fixes: 54187ff9d766 ("hwmon: (max31790) Convert to use new hwmon registration API") Fixes: 195a4b4298a7 ("hwmon: Driver for Maxim MAX31790") Cc: Jan Kundrát Reviewed-by: Jan Kundrát Cc: Václav Kubernát Reviewed-by: Jan Kundrát Signed-off-by: Guenter Roeck Link: https://lore.kernel.org/r/20210526154022.3223012-2-linux@roeck-us.net Signed-off-by: Sasha Levin commit 8ba1cbcacb8dd81444f098c4ca8a0a8d2aa752b3 Author: Guenter Roeck Date: Sat May 8 09:50:25 2021 -0700 hwmon: (max31722) Remove non-standard ACPI device IDs [ Upstream commit 97387c2f06bcfd79d04a848d35517b32ee6dca7c ] Valid Maxim Integrated ACPI device IDs would start with MXIM, not with MAX1. On top of that, ACPI device IDs reflecting chip names are almost always invalid. Remove the invalid ACPI IDs. Fixes: 04e1e70afec6 ("hwmon: (max31722) Add support for MAX31722/MAX31723 temperature sensors") Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 4d557422aa282af27e14bfd2f488de93fa9c33a9 Author: Guenter Roeck Date: Sat May 8 09:44:50 2021 -0700 hwmon: (lm70) Revert "hwmon: (lm70) Add support for ACPI" [ Upstream commit ac61c8aae446b9c0fe18981fe721d4a43e283ad6 ] This reverts commit b58bd4c6dfe709646ed9efcbba2a70643f9bc873. None of the ACPI IDs introduced with the reverted patch is a valid ACPI device ID. Any ACPI users of this driver are advised to use PRP0001 and a devicetree-compatible device identification. Fixes: b58bd4c6dfe7 ("hwmon: (lm70) Add support for ACPI") Cc: Andrej Picej Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 1288a814a1b0df77481fe7cd682237bbb6ad304b Author: Chris Packham Date: Wed Jun 16 15:42:18 2021 +1200 hwmon: (pmbus/bpa-rs600) Handle Vin readings >= 256V [ Upstream commit 6e9ef8ca687e69e9d4cc89033d98e06350b0f3e0 ] The BPA-RS600 doesn't follow the PMBus spec for linear data. Specifically it treats the mantissa as an unsigned 11-bit value instead of a two's complement 11-bit value. At this point it's unclear whether this only affects Vin or if Pin/Pout1 are affected as well. Erring on the side of caution only Vin is dealt with here. Fixes: 15b2703e5e02 ("hwmon: (pmbus) Add driver for BluTek BPA-RS600") Signed-off-by: Chris Packham Link: https://lore.kernel.org/r/20210616034218.25821-1-chris.packham@alliedtelesis.co.nz Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 41e7e8d9457680047c99ca584a3c3a2c5b738126 Author: Jacopo Mondi Date: Wed Jun 16 14:46:11 2021 +0200 media: i2c: rdacm21: Power up OV10640 before OV490 [ Upstream commit 2b821698dc73c00719e3dc367db712f727bbda85 ] The current RDACM21 initialization routine powers up the OV10640 image sensor after the OV490 ISP. The ISP is programmed with a firmware loaded from an embedded serial flash that (most probably) tries to interact and program also the image sensor connected to the ISP. As described in commit "media: i2c: rdacm21: Fix OV10640 powerup" the image sensor powerdown signal is kept high by an internal pull up resistor and occasionally fails to startup correctly if the powerdown line is not asserted explicitly. Failures in the OV10640 startup causes the OV490 firmware to fail to boot correctly resulting in the camera module initialization to fail consequentially. Fix this by powering up the OV10640 image sensor before testing the OV490 firmware boot completion, by splitting the ov10640_initialize() function in an ov10640_power_up() one and an ov10640_check_id() one. Also make sure the OV10640 identification procedure gives enough time to the image sensor to resume after the programming phase performed by the OV490 firmware by repeating the ID read procedure. This commit fixes a sporadic start-up error triggered by a failure to detect the OV490 firmware boot completion: rdacm21 8-0054: Timeout waiting for firmware boot [hverkuil: fixed two typos in commit log] Fixes: a59f853b3b4b ("media: i2c: Add driver for RDACM21 camera module") Signed-off-by: Jacopo Mondi Reviewed-by: Laurent Pinchart Reviewed-by: Kieran Bingham Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 10cd7a128225a358771d1e3b42ec1d2d7db9147f Author: Jacopo Mondi Date: Wed Jun 16 14:46:10 2021 +0200 media: i2c: rdacm21: Fix OV10640 powerup [ Upstream commit ff75332b260cd33cc19000fdb5d256d9db4470d1 ] The OV10640 image sensor powerdown signal is controlled by the first line of the OV490 GPIO pad #1, but the pad #0 identifier OV490_GPIO_OUTPUT_VALUE0 was erroneously used. As a result the image sensor powerdown signal was never asserted but was left floating and kept high by an internal pull-up resistor, causing sporadic failures during the image sensor startup phase. Fix this by using the correct GPIO pad identifier and wait the mandatory 1.5 millisecond delay after the powerup lane is asserted. The reset delay is not characterized in the chip manual if not as "255 XVCLK + initialization". Wait for at least 3 milliseconds to guarantee the SCCB bus is available. While at it also fix the reset sequence, as the reset line was released before the powerdown one, and the line was not cycled. This commit fixes a sporadic start-up error triggered by a failure to read the OV10640 chip ID: rdacm21 8-0054: OV10640 ID mismatch: (0x01) Fixes: a59f853b3b4b ("media: i2c: Add driver for RDACM21 camera module") Signed-off-by: Jacopo Mondi Reviewed-by: Kieran Bingham Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit bd03f1cf32a1787fadccf43882a28315ed59fe8d Author: Dillon Min Date: Wed May 26 17:18:32 2021 +0200 media: s5p-g2d: Fix a memory leak on ctx->fh.m2m_ctx [ Upstream commit 5d11e6aad1811ea293ee2996cec9124f7fccb661 ] The m2m_ctx resources was allocated by v4l2_m2m_ctx_init() in g2d_open() should be freed from g2d_release() when it's not used. Fix it Fixes: 918847341af0 ("[media] v4l: add G2D driver for s5p device family") Signed-off-by: Dillon Min Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit b3362260388a48879d3a577769b50a411582b249 Author: Arnd Bergmann Date: Mon Jun 14 12:34:05 2021 +0200 media: subdev: remove VIDIOC_DQEVENT_TIME32 handling [ Upstream commit 765ba251d2522e2a0daa2f0793fd0f0ce34816ec ] Converting the VIDIOC_DQEVENT_TIME32/VIDIOC_DQEVENT32/ VIDIOC_DQEVENT32_TIME32 arguments to the canonical form is done in common code, but for some reason I ended up adding another conversion helper to subdev_do_ioctl() as well. I must have concluded that this does not go through the common conversion, but it has done that since the ioctl handler was first added. I assume this one is harmless as there should be no way to arrive here from user space if CONFIG_COMPAT_32BIT_TIME is set, but since it is dead code, it should just get removed. On a 64-bit architecture, as well as a 32-bit architecture without CONFIG_COMPAT_32BIT_TIME, handling this command is a mistake, and the kernel should return an error. Fixes: 1a6c0b36dd19 ("media: v4l2-core: fix VIDIOC_DQEVENT for time64 ABI") Signed-off-by: Arnd Bergmann Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 52d7255c14320464f42e97a2797c63ef4dcce65a Author: Arnd Bergmann Date: Mon Jun 14 12:34:02 2021 +0200 media: v4l2-core: ignore native time32 ioctls on 64-bit [ Upstream commit c344f07aa1b4ba38ca8fabe407a2afe2f436323c ] Syzbot found that passing ioctl command 0xc0505609 into a 64-bit kernel from a 32-bit process causes uninitialized kernel memory to get passed to drivers instead of the user space data: BUG: KMSAN: uninit-value in check_array_args drivers/media/v4l2-core/v4l2-ioctl.c:3041 [inline] BUG: KMSAN: uninit-value in video_usercopy+0x1631/0x3d30 drivers/media/v4l2-core/v4l2-ioctl.c:3315 CPU: 0 PID: 19595 Comm: syz-executor.4 Not tainted 5.11.0-rc7-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+0x21c/0x280 lib/dump_stack.c:120 kmsan_report+0xfb/0x1e0 mm/kmsan/kmsan_report.c:118 __msan_warning+0x5f/0xa0 mm/kmsan/kmsan_instr.c:197 check_array_args drivers/media/v4l2-core/v4l2-ioctl.c:3041 [inline] video_usercopy+0x1631/0x3d30 drivers/media/v4l2-core/v4l2-ioctl.c:3315 video_ioctl2+0x9f/0xb0 drivers/media/v4l2-core/v4l2-ioctl.c:3391 v4l2_ioctl+0x255/0x290 drivers/media/v4l2-core/v4l2-dev.c:360 v4l2_compat_ioctl32+0x2c6/0x370 drivers/media/v4l2-core/v4l2-compat-ioctl32.c:1248 __do_compat_sys_ioctl fs/ioctl.c:842 [inline] __se_compat_sys_ioctl+0x53d/0x1100 fs/ioctl.c:793 __ia32_compat_sys_ioctl+0x4a/0x70 fs/ioctl.c:793 do_syscall_32_irqs_on arch/x86/entry/common.c:79 [inline] __do_fast_syscall_32+0x102/0x160 arch/x86/entry/common.c:141 do_fast_syscall_32+0x6a/0xc0 arch/x86/entry/common.c:166 do_SYSENTER_32+0x73/0x90 arch/x86/entry/common.c:209 entry_SYSENTER_compat_after_hwframe+0x4d/0x5c The time32 commands are defined but were never meant to be called on 64-bit machines, as those have always used time64 interfaces. I missed this in my patch that introduced the time64 handling on 32-bit platforms. The problem in this case is the mismatch of one function checking for the numeric value of the command and another function checking for the type of process (native vs compat) instead, with the result being that for this combination, nothing gets copied into the buffer at all. Avoid this by only trying to convert the time32 commands when running on a 32-bit kernel where these are defined in a meaningful way. [hverkuil: fix 3 warnings: switch with no cases] Fixes: 577c89b0ce72 ("media: v4l2-core: fix v4l2_buffer handling for time64 ABI") Reported-by: syzbot+142888ffec98ab194028@syzkaller.appspotmail.com Signed-off-by: Arnd Bergmann Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 99876d2f3316c2ad1c37bf5a020b127387702fa4 Author: Anshuman Khandual Date: Tue Jun 15 15:02:58 2021 +0530 arm64/mm: Fix ttbr0 values stored in struct thread_info for software-pan [ Upstream commit 9163f01130304fab1f74683d7d44632da7bda637 ] When using CONFIG_ARM64_SW_TTBR0_PAN, a task's thread_info::ttbr0 must be the TTBR0_EL1 value used to run userspace. With 52-bit PAs, the PA must be packed into the TTBR using phys_to_ttbr(), but we forget to do this in some of the SW PAN code. Thus, if the value is installed into TTBR0_EL1 (as may happen in the uaccess routines), this could result in UNPREDICTABLE behaviour. Since hardware with 52-bit PA support almost certainly has HW PAN, which will be used in preference, this shouldn't be a practical issue, but let's fix this for consistency. Cc: Catalin Marinas Cc: Will Deacon Cc: Mark Rutland Cc: James Morse Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Fixes: 529c4b05a3cb ("arm64: handle 52-bit addresses in TTBR") Signed-off-by: Anshuman Khandual Reviewed-by: Catalin Marinas Link: https://lore.kernel.org/r/1623749578-11231-1-git-send-email-anshuman.khandual@arm.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit c8255c905aa1c28398cb2b1ba2ee0968ab170c53 Author: Zhen Lei Date: Sat May 8 10:03:21 2021 +0800 mmc: usdhi6rol0: fix error return code in usdhi6_probe() [ Upstream commit 2f9ae69e5267f53e89e296fccee291975a85f0eb ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 75fa9ea6e3c0 ("mmc: add a driver for the Renesas usdhi6rol0 SD/SDIO host controller") Reported-by: Hulk Robot Signed-off-by: Zhen Lei Link: https://lore.kernel.org/r/20210508020321.1677-1-thunder.leizhen@huawei.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 1f8d5a578c87c6cbe2f91713f15e19c798af6d49 Author: Hongbo Li Date: Fri Jun 4 14:30:35 2021 +0800 crypto: sm2 - fix a memory leak in sm2 [ Upstream commit 5cd259ca5d466f65ffd21e2e2fa00fb648a8c555 ] SM2 module alloc ec->Q in sm2_set_pub_key(), when doing alg test in test_akcipher_one(), it will set public key for every test vector, and don't free ec->Q. This will cause a memory leak. This patch alloc ec->Q in sm2_ec_ctx_init(). Fixes: ea7ecb66440b ("crypto: sm2 - introduce OSCCA SM2 asymmetric cipher algorithm") Signed-off-by: Hongbo Li Reviewed-by: Tianjia Zhang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit dfc62a9fb18aaa8b33eba36eebd6583e0c39f330 Author: Hangbin Liu Date: Thu Jun 3 01:53:40 2021 -0400 crypto: x86/curve25519 - fix cpu feature checking logic in mod_exit [ Upstream commit 1b82435d17774f3eaab35dce239d354548aa9da2 ] In curve25519_mod_init() the curve25519_alg will be registered only when (X86_FEATURE_BMI2 && X86_FEATURE_ADX). But in curve25519_mod_exit() it still checks (X86_FEATURE_BMI2 || X86_FEATURE_ADX) when do crypto unregister. This will trigger a BUG_ON in crypto_unregister_alg() as alg->cra_refcnt is 0 if the cpu only supports one of X86_FEATURE_BMI2 and X86_FEATURE_ADX. Fixes: 07b586fe0662 ("crypto: x86/curve25519 - replace with formally verified implementation") Signed-off-by: Hangbin Liu Reviewed-by: Jason A. Donenfeld Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 334ea984ff363d5f376131827688c6246306e350 Author: Zhang Qilong Date: Tue Jun 1 22:51:18 2021 +0800 crypto: omap-sham - Fix PM reference leak in omap sham ops [ Upstream commit ca323b2c61ec321eb9f2179a405b9c34cdb4f553 ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. We fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Fixes: 604c31039dae4 ("crypto: omap-sham - Check for return value from pm_runtime_get_sync") Signed-off-by: Zhang Qilong Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 46b988b2ce9851f72eff9469917c72066431383e Author: Tong Tiangen Date: Tue Jun 1 18:01:55 2021 +0800 crypto: nitrox - fix unchecked variable in nitrox_register_interrupts [ Upstream commit 57c126661f50b884d3812e7db6e00f2e778eccfb ] Function nitrox_register_interrupts leaves variable 'nr_vecs' unchecked, which would be use as kcalloc parameter later. Fixes: 5155e118dda9 ("crypto: cavium/nitrox - use pci_alloc_irq_vectors() while enabling MSI-X.") Signed-off-by: Tong Tiangen Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit ba68a06cfcbc4cd8a8068c1236207177559ebf5f Author: Axel Lin Date: Mon Jun 7 22:29:07 2021 +0800 regulator: fan53880: Fix vsel_mask setting for FAN53880_BUCK [ Upstream commit 2e11737a772b95c6587df73f216eec1762431432 ] According to the datasheet: REGISTER DETAILS − 0x02 BUCK, BUCK_OUT is BIT0 ~ BIT7. So vsel_mask for FAN53880_BUCK should be 0xFF. Fixes: e6dea51e2d41 ("regulator: fan53880: Add initial support") Signed-off-by: Axel Lin Link: https://lore.kernel.org/r/20210607142907.1599905-1-axel.lin@ingics.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b0b3a515164992d99db494b4b6f6be0ff64a90ed Author: Gustavo A. R. Silva Date: Wed Mar 10 19:40:43 2021 -0600 media: siano: Fix out-of-bounds warnings in smscore_load_firmware_family2() [ Upstream commit 13dfead49db07225335d4f587a560a2210391a1a ] Rename struct sms_msg_data4 to sms_msg_data5 and increase the size of its msg_data array from 4 to 5 elements. Notice that at some point the 5th element of msg_data is being accessed in function smscore_load_firmware_family2(): 1006 trigger_msg->msg_data[4] = 4; /* Task ID */ Also, there is no need for the object _trigger_msg_ of type struct sms_msg_data *, when _msg_ can be used, directly. Notice that msg_data in struct sms_msg_data is a one-element array, which causes multiple out-of-bounds warnings when accessing beyond its first element in function smscore_load_firmware_family2(): 992 struct sms_msg_data *trigger_msg = 993 (struct sms_msg_data *) msg; 994 995 pr_debug("sending MSG_SMS_SWDOWNLOAD_TRIGGER_REQ\n"); 996 SMS_INIT_MSG(&msg->x_msg_header, 997 MSG_SMS_SWDOWNLOAD_TRIGGER_REQ, 998 sizeof(struct sms_msg_hdr) + 999 sizeof(u32) * 5); 1000 1001 trigger_msg->msg_data[0] = firmware->start_address; 1002 /* Entry point */ 1003 trigger_msg->msg_data[1] = 6; /* Priority */ 1004 trigger_msg->msg_data[2] = 0x200; /* Stack size */ 1005 trigger_msg->msg_data[3] = 0; /* Parameter */ 1006 trigger_msg->msg_data[4] = 4; /* Task ID */ even when enough dynamic memory is allocated for _msg_: 929 /* PAGE_SIZE buffer shall be enough and dma aligned */ 930 msg = kmalloc(PAGE_SIZE, GFP_KERNEL | coredev->gfp_buf_flags); but as _msg_ is casted to (struct sms_msg_data *): 992 struct sms_msg_data *trigger_msg = 993 (struct sms_msg_data *) msg; the out-of-bounds warnings are actually valid and should be addressed. Fix this by declaring object _msg_ of type struct sms_msg_data5 *, which contains a 5-elements array, instead of just 4. And use _msg_ directly, instead of creating object trigger_msg. This helps with the ongoing efforts to enable -Warray-bounds by fixing the following warnings: CC [M] drivers/media/common/siano/smscoreapi.o drivers/media/common/siano/smscoreapi.c: In function ‘smscore_load_firmware_family2’: drivers/media/common/siano/smscoreapi.c:1003:24: warning: array subscript 1 is above array bounds of ‘u32[1]’ {aka ‘unsigned int[1]’} [-Warray-bounds] 1003 | trigger_msg->msg_data[1] = 6; /* Priority */ | ~~~~~~~~~~~~~~~~~~~~~^~~ In file included from drivers/media/common/siano/smscoreapi.c:12: drivers/media/common/siano/smscoreapi.h:619:6: note: while referencing ‘msg_data’ 619 | u32 msg_data[1]; | ^~~~~~~~ drivers/media/common/siano/smscoreapi.c:1004:24: warning: array subscript 2 is above array bounds of ‘u32[1]’ {aka ‘unsigned int[1]’} [-Warray-bounds] 1004 | trigger_msg->msg_data[2] = 0x200; /* Stack size */ | ~~~~~~~~~~~~~~~~~~~~~^~~ In file included from drivers/media/common/siano/smscoreapi.c:12: drivers/media/common/siano/smscoreapi.h:619:6: note: while referencing ‘msg_data’ 619 | u32 msg_data[1]; | ^~~~~~~~ drivers/media/common/siano/smscoreapi.c:1005:24: warning: array subscript 3 is above array bounds of ‘u32[1]’ {aka ‘unsigned int[1]’} [-Warray-bounds] 1005 | trigger_msg->msg_data[3] = 0; /* Parameter */ | ~~~~~~~~~~~~~~~~~~~~~^~~ In file included from drivers/media/common/siano/smscoreapi.c:12: drivers/media/common/siano/smscoreapi.h:619:6: note: while referencing ‘msg_data’ 619 | u32 msg_data[1]; | ^~~~~~~~ drivers/media/common/siano/smscoreapi.c:1006:24: warning: array subscript 4 is above array bounds of ‘u32[1]’ {aka ‘unsigned int[1]’} [-Warray-bounds] 1006 | trigger_msg->msg_data[4] = 4; /* Task ID */ | ~~~~~~~~~~~~~~~~~~~~~^~~ In file included from drivers/media/common/siano/smscoreapi.c:12: drivers/media/common/siano/smscoreapi.h:619:6: note: while referencing ‘msg_data’ 619 | u32 msg_data[1]; | ^~~~~~~~ Fixes: 018b0c6f8acb ("[media] siano: make load firmware logic to work with newer firmwares") Co-developed-by: Kees Cook Signed-off-by: Kees Cook Signed-off-by: Gustavo A. R. Silva Signed-off-by: Sasha Levin commit 7f245ea447dd8f37b73795aa0cdc597cde3ffb0c Author: Randy Dunlap Date: Wed May 26 17:12:51 2021 -0700 m68k: atari: Fix ATARI_KBD_CORE kconfig unmet dependency warning [ Upstream commit c1367ee016e3550745315fb9a2dd1e4ce02cdcf6 ] Since the code for ATARI_KBD_CORE does not use drivers/input/keyboard/ code, just move ATARI_KBD_CORE to arch/m68k/Kconfig.machine to remove the dependency on INPUT_KEYBOARD. Removes this kconfig warning: WARNING: unmet direct dependencies detected for ATARI_KBD_CORE Depends on [n]: !UML && INPUT [=y] && INPUT_KEYBOARD [=n] Selected by [y]: - MOUSE_ATARI [=y] && !UML && INPUT [=y] && INPUT_MOUSE [=y] && ATARI [=y] Fixes: c04cb856e20a ("m68k: Atari keyboard and mouse support.") Signed-off-by: Randy Dunlap Suggested-by: Geert Uytterhoeven Suggested-by: Michael Schmitz Acked-by: Dmitry Torokhov Link: https://lore.kernel.org/r/20210527001251.8529-1-rdunlap@infradead.org Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 262c340bf7e84c1f0c2cb5b8899243aa0bf496cc Author: Shaokun Zhang Date: Thu Jun 3 16:34:51 2021 +0800 drivers/perf: hisi: Fix data source control [ Upstream commit 814be609baae62aaa6c02fa6f3ad66cff32a6d15 ] 'Data source' is a new function for HHA PMU and config / clear interface was wrong by mistake. 'HHA_DATSRC_CTRL' register is mainly used for data source configuration, if we enable bit0 as driver, it will go on count the event and we didn't check it carefully. So fix the issue and do as the initial purpose. Fixes: 932f6a99f9b0 ("drivers/perf: hisi: Add new functions for HHA PMU") Reported-by: kernel test robot Cc: Will Deacon Cc: Mark Rutland Signed-off-by: Shaokun Zhang Link: https://lore.kernel.org/r/1622709291-37996-1-git-send-email-zhangshaokun@hisilicon.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 9234c34f62c853287b4ebe3679a711564dab2322 Author: Axel Lin Date: Tue May 25 20:40:16 2021 +0800 regulator: fan53555: Fix missing slew_reg/mask/shift settings for FAN53526 [ Upstream commit 30b38b805b36c03db3703ef62397111c783b5f3b ] The di->slew_reg/di->slew_mask/di->slew_shift was not set in current code, fix it. Fixes: f2a9eb975ab2 ("regulator: fan53555: Add support for FAN53526") Signed-off-by: Axel Lin Link: https://lore.kernel.org/r/20210525124017.2550029-1-axel.lin@ingics.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d017709732cc52e61d437a50322f4b4da3fdc00e Author: Johan Hovold Date: Mon May 24 13:09:18 2021 +0200 media: gspca/gl860: fix zero-length control requests [ Upstream commit 8ed339f23d41e21660a389adf2e7b2966d457ff6 ] The direction of the pipe argument must match the request-type direction bit or control requests may fail depending on the host-controller-driver implementation. Control transfers without a data stage are treated as OUT requests by the USB stack and should be using usb_sndctrlpipe(). Failing to do so will now trigger a warning. Fix the gl860_RTx() helper so that zero-length control reads fail with an error message instead. Note that there are no current callers that would trigger this. Fixes: 4f7cb8837cec ("V4L/DVB (12954): gspca - gl860: Addition of GL860 based webcams") Signed-off-by: Johan Hovold Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 0a84a0cd4eb6be464e1bc22265c45248de02ccbf Author: Joe Richey Date: Fri May 21 10:58:46 2021 +0200 media: vicodec: Use _BITUL() macro in UAPI headers [ Upstream commit ce67eaca95f8ab5c6aae41a10adfe9a6e8efa58c ] Replace BIT() in v4l2's UPAI header with _BITUL(). BIT() is not defined in the UAPI headers and its usage may cause userspace build errors. Fixes: 206bc0f6fb94 ("media: vicodec: mark the stateless FWHT API as stable") Signed-off-by: Joe Richey Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit cf689b19af21c8a4df29b3808ea2b24906128b8a Author: Zhen Lei Date: Sat May 15 08:58:30 2021 +0200 media: tc358743: Fix error return code in tc358743_probe_of() [ Upstream commit a6b1e7093f0a099571fc8836ab4a589633f956a8 ] When the CSI bps per lane is not in the valid range, an appropriate error code -EINVAL should be returned. However, we currently do not explicitly assign this error code to 'ret'. As a result, 0 was incorrectly returned. Fixes: 256148246852 ("[media] tc358743: support probe from device tree") Reported-by: Hulk Robot Signed-off-by: Zhen Lei Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit b01b4817f2e60835fac6333e2c630cd132153551 Author: Dan Carpenter Date: Fri May 14 16:20:38 2021 +0200 media: au0828: fix a NULL vs IS_ERR() check [ Upstream commit 8f2e452730d2bcd59fe05246f0e19a4c52e0012d ] The media_device_usb_allocate() function returns error pointers when it's enabled and something goes wrong. It can return NULL as well, but only if CONFIG_MEDIA_CONTROLLER is disabled so that doesn't apply here. Fixes: 812658d88d26 ("media: change au0828 to use Media Device Allocator API") Signed-off-by: Dan Carpenter Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit ff7233a3d0852c6923bee81d089f065261a0c343 Author: Lv Yunlong Date: Sun May 9 10:12:31 2021 +0200 media: exynos4-is: Fix a use after free in isp_video_release [ Upstream commit 01fe904c9afd26e79c1f73aa0ca2e3d785e5e319 ] In isp_video_release, file->private_data is freed via _vb2_fop_release()->v4l2_fh_release(). But the freed file->private_data is still used in v4l2_fh_is_singular_file() ->v4l2_fh_is_singular(file->private_data), which is a use after free bug. My patch uses a variable 'is_singular_file' to avoid the uaf. v3: https://lore.kernel.org/patchwork/patch/1419058/ Fixes: 34947b8aebe3f ("[media] exynos4-is: Add the FIMC-IS ISP capture DMA driver") Signed-off-by: Lv Yunlong Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 4085aa9b61829146471e77574adef33630c3178f Author: Ezequiel Garcia Date: Wed May 5 14:23:45 2021 +0200 media: rkvdec: Fix .buf_prepare [ Upstream commit ba1ed4ae760a81caf39f54232e089d95157a0dba ] The driver should only set the payload on .buf_prepare if the buffer is CAPTURE type. If an OUTPUT buffer has a zero bytesused set by userspace then v4l2-core will set it to buffer length. If we overwrite bytesused for OUTPUT buffers, too, then vb2_get_plane_payload() will return incorrect value which might be then written to hw registers by the driver in rkvdec-h264.c. [Changed the comment and used V4L2_TYPE_IS_CAPTURE macro] Fixes: cd33c830448ba ("media: rkvdec: Add the rkvdec driver") Signed-off-by: Ezequiel Garcia Signed-off-by: Adrian Ratiu Signed-off-by: Andrzej Pietrasiewicz Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit ba2e3533e3216efd4cd146930dd499a05a533cd1 Author: Stanimir Varbanov Date: Wed Apr 28 23:50:20 2021 +0200 media: venus: hfi_cmds: Fix conceal color property [ Upstream commit 6e2202ca1ee034920b029124151754aec67b61ba ] The conceal color property used for Venus v4 and v6 has the same payload structure. But currently v4 follow down to payload structure for v1. Correct this by moving set_property to v4. Fixes: 4ef6039fad8f ("media: venus: vdec: Add support for conceal control") Signed-off-by: Stanimir Varbanov Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit ba10157cd0f8711df4b2eaa36b6eb87272e2edb4 Author: Andy Shevchenko Date: Sun Apr 4 20:14:09 2021 +0200 media: ipu3-cio2: Fix reference counting when looping over ACPI devices [ Upstream commit 2cb2705cf7ffe41dc5bd81290e4241bfb7f031cc ] When we continue, due to device is disabled, loop we have to drop reference count. When we have an array full of devices we have to also drop the reference count. Note, in this case the cio2_bridge_unregister_sensors() is called by the caller. Fixes: 803abec64ef9 ("media: ipu3-cio2: Add cio2-bridge to ipu3-cio2 driver") Signed-off-by: Andy Shevchenko Reviewed-by: Daniel Scally Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 1b76864f4da70c7626e7db1af9a14046969b1017 Author: Valentin Schneider Date: Wed May 26 21:57:50 2021 +0100 sched: Don't defer CPU pick to migration_cpu_stop() [ Upstream commit 475ea6c60279e9f2ddf7e4cf2648cd8ae0608361 ] Will reported that the 'XXX __migrate_task() can fail' in migration_cpu_stop() can happen, and it *is* sort of a big deal. Looking at it some more, one will note there is a glaring hole in the deferred CPU selection: (w/ CONFIG_CPUSET=n, so that the affinity mask passed via taskset doesn't get AND'd with cpu_online_mask) $ taskset -pc 0-2 $PID # offline CPUs 3-4 $ taskset -pc 3-5 $PID `\ $PID may stay on 0-2 due to the cpumask_any_distribute() picking an offline CPU and __migrate_task() refusing to do anything due to cpu_is_allowed(). set_cpus_allowed_ptr() goes to some length to pick a dest_cpu that matches the right constraints vs affinity and the online/active state of the CPUs. Reuse that instead of discarding it in the affine_move_task() case. Fixes: 6d337eab041d ("sched: Fix migrate_disable() vs set_cpus_allowed_ptr()") Reported-by: Will Deacon Signed-off-by: Valentin Schneider Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210526205751.842360-2-valentin.schneider@arm.com Signed-off-by: Sasha Levin commit e2263985ad578005daa70bd971def56c337996d5 Author: Randy Dunlap Date: Mon May 24 15:41:50 2021 -0700 locking/lockdep: Reduce LOCKDEP dependency list [ Upstream commit b8e00abe7d9fe21dd13609e2e3a707e38902b105 ] Some arches (um, sparc64, riscv, xtensa) cause a Kconfig warning for LOCKDEP. These arch-es select LOCKDEP_SUPPORT but they are not listed as one of the arch-es that LOCKDEP depends on. Since (16) arch-es define the Kconfig symbol LOCKDEP_SUPPORT if they intend to have LOCKDEP support, replace the awkward list of arch-es that LOCKDEP depends on with the LOCKDEP_SUPPORT symbol. But wait. LOCKDEP_SUPPORT is included in LOCK_DEBUGGING_SUPPORT, which is already a dependency here, so LOCKDEP_SUPPORT is redundant and not needed. That leaves the FRAME_POINTER dependency, but it is part of an expression like this: depends on (A && B) && (FRAME_POINTER || B') where B' is a dependency of B so if B is true then B' is true and the value of FRAME_POINTER does not matter. Thus we can also delete the FRAME_POINTER dependency. Fixes this kconfig warning: (for um, sparc64, riscv, xtensa) WARNING: unmet direct dependencies detected for LOCKDEP Depends on [n]: DEBUG_KERNEL [=y] && LOCK_DEBUGGING_SUPPORT [=y] && (FRAME_POINTER [=n] || MIPS || PPC || S390 || MICROBLAZE || ARM || ARC || X86) Selected by [y]: - PROVE_LOCKING [=y] && DEBUG_KERNEL [=y] && LOCK_DEBUGGING_SUPPORT [=y] - LOCK_STAT [=y] && DEBUG_KERNEL [=y] && LOCK_DEBUGGING_SUPPORT [=y] - DEBUG_LOCK_ALLOC [=y] && DEBUG_KERNEL [=y] && LOCK_DEBUGGING_SUPPORT [=y] Fixes: 7d37cb2c912d ("lib: fix kconfig dependency on ARCH_WANT_FRAME_POINTERS") Signed-off-by: Randy Dunlap Signed-off-by: Peter Zijlstra (Intel) Acked-by: Waiman Long Link: https://lkml.kernel.org/r/20210524224150.8009-1-rdunlap@infradead.org Signed-off-by: Sasha Levin commit ebc9f608afa0d473a066f5bc59c1f0bc78b946c6 Author: Sergey Shtylyov Date: Sat Mar 20 23:32:38 2021 +0300 pata_ep93xx: fix deferred probing [ Upstream commit 5c8121262484d99bffb598f39a0df445cecd8efb ] The driver overrides the error codes returned by platform_get_irq() to -ENXIO, so if it returns -EPROBE_DEFER, the driver would fail the probe permanently instead of the deferred probing. Propagate the error code upstream, as it should have been done from the start... Fixes: 2fff27512600 ("PATA host controller driver for ep93xx") Signed-off-by: Sergey Shtylyov Link: https://lore.kernel.org/r/509fda88-2e0d-2cc7-f411-695d7e94b136@omprussia.ru Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 614016e8cd5d2105a7d056b027d64d379d280b74 Author: Randy Dunlap Date: Sat May 22 17:14:27 2021 -0700 regulator: bd71815: add select to fix build [ Upstream commit 5ba3747dbc9ade2d22a8f5bff3c928cb41d35030 ] Mend the Kconfig for REGULATOR_BD71815 to prevent build errors: riscv32-linux-ld: drivers/regulator/bd71815-regulator.o: in function `.L0 ': regulator.c:289: undefined reference to `rohm_regulator_set_dvs_levels' riscv32-linux-ld: drivers/regulator/bd71815-regulator.c:370: undefined reference to `rohm_regulator_set_dvs_levels' Fixes: 1aad39001e85 ("regulator: Support ROHM BD71815 regulators") Signed-off-by: Randy Dunlap Cc: Matti Vaittinen Cc: Lee Jones Cc: Mark Brown Cc: Liam Girdwood Reviewed-by: Matti Vaittinen Link: https://lore.kernel.org/r/20210523001427.13500-1-rdunlap@infradead.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7ef5567a8af82a98d9ea416407ddaf29ee2dee26 Author: Christophe JAILLET Date: Thu May 6 07:38:56 2021 +0200 media: rc: i2c: Fix an error message [ Upstream commit 9c87ae1a0dbeb5794957421157fd266d38a869b4 ] 'ret' is known to be 1 here. In fact 'i' is expected instead. Store the return value of 'i2c_master_recv()' in 'ret' so that the error message print the correct error code. Fixes: acaa34bf06e9 ("media: rc: implement zilog transmitter") Signed-off-by: Christophe JAILLET Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 1640411aa297aae122af17ef8c7822fcdd07b660 Author: Christophe JAILLET Date: Sun May 16 08:58:04 2021 +0200 crypto: ccp - Fix a resource leak in an error handling path [ Upstream commit a6f8e68e238a15bb15f1726b35c695136c64eaba ] If an error occurs after calling 'sp_get_irqs()', 'sp_free_irqs()' must be called as already done in the error handling path. Fixes: f4d18d656f88 ("crypto: ccp - Abstract interrupt registeration") Signed-off-by: Christophe JAILLET Acked-by: John Allen Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit e6678d84512744f6b5d80feab48fb35af76103f4 Author: Suman Anna Date: Fri May 14 11:12:44 2021 -0500 crypto: sa2ul - Use of_device_get_match_data() helper [ Upstream commit d699c5d0bd811e48de72aeeb8e3872c63e957745 ] Simplify the probe function by using the of_device_get_match_data() helper instead of open coding. The logic is also moved up to fix the missing pm_runtime cleanup in case of a match failure. Fixes: 0bc42311cdff ("crypto: sa2ul - Add support for AM64") Signed-off-by: Suman Anna Reviewed-by: Tero Kristo Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit dc0dae25ae082cb76694470cee1d8f287f35a24b Author: Suman Anna Date: Fri May 14 11:12:43 2021 -0500 crypto: sa2ul - Fix pm_runtime enable in sa_ul_probe() [ Upstream commit 5c8552325e013cbdabc443cd1f1b4d03c4a2e64e ] The pm_runtime APIs added first in commit 7694b6ca649f ("crypto: sa2ul - Add crypto driver") are not unwound properly and was fixed up partially in commit 13343badae09 ("crypto: sa2ul - Fix PM reference leak in sa_ul_probe()"). This fixed up the pm_runtime usage count but not the state. Fix this properly. Fixes: 13343badae09 ("crypto: sa2ul - Fix PM reference leak in sa_ul_probe()") Signed-off-by: Suman Anna Reviewed-by: Tero Kristo Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit b595f995689e0d434ca0ed5395fdd1d444baec8c Author: Suman Anna Date: Fri May 14 11:12:42 2021 -0500 crypto: sa2ul - Fix leaks on failure paths with sa_dma_init() [ Upstream commit 4c0716ee1d973f6504d13f0e8d4d10350c85ad37 ] The sa_dma_init() function doesn't release the requested dma channels on all failure paths. Any failure in this function also ends up leaking the dma pool created in sa_init_mem() in the sa_ul_probe() function. Fix all of these issues. Fixes: 7694b6ca649f ("crypto: sa2ul - Add crypto driver") Signed-off-by: Suman Anna Reviewed-by: Tero Kristo Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 61b720aa441fbeca8ed308c065bab01501bdbf9f Author: Joe Richey Date: Fri May 21 01:58:42 2021 -0700 x86/elf: Use _BITUL() macro in UAPI headers [ Upstream commit d06aca989c243dd9e5d3e20aa4e5c2ecfdd07050 ] Replace BIT() in x86's UAPI header with _BITUL(). BIT() is not defined in the UAPI headers and its usage may cause userspace build errors. Fixes: 742c45c3ecc9 ("x86/elf: Enumerate kernel FSGSBASE capability in AT_HWCAP2") Signed-off-by: Joe Richey Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20210521085849.37676-2-joerichey94@gmail.com Signed-off-by: Sasha Levin commit 2df42a9a9b4847f0b57f81e509aa39e4b6ed8285 Author: Hui Tang Date: Mon May 10 17:02:55 2021 +0800 crypto: hisilicon/hpre - fix unmapping invalid dma address [ Upstream commit 0b0553b701f830d820ba9026e5799c24e400a4b5 ] Currently, an invalid dma address may be unmapped when calling 'xx_data_clr_all' in error path, so check dma address of sqe in/out if initialized before calling 'dma_free_coherent' or 'dma_unmap_single'. Fixes: a9214b0b6ed2 ("crypto: hisilicon - fix the check on dma address") Signed-off-by: Hui Tang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit b47dc857836cdbfa3494da0d8a4ff49a45883b04 Author: Hui Tang Date: Mon May 10 16:54:08 2021 +0800 crypto: testmgr - fix initialization of 'secret_size' [ Upstream commit 2d016672528a592ada5188e53ac746e1b8b7a978 ] Actual data length of the 'secret' is not equal to the 'secret_size'. Since the 'curve_id' has removed in the 'secret', the 'secret_size' should subtract the length of the 'curve_id'. Fixes: 6763f5ea2d9a ("crypto: ecdh - move curve_id of ECDH from ...") Signed-off-by: Hui Tang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit b62d59e57437213c9ed34bf58495288fa23ffccc Author: Mimi Zohar Date: Mon Apr 26 18:13:45 2021 -0400 evm: fix writing /evm overflow [ Upstream commit 49219d9b8785ba712575c40e48ce0f7461254626 ] EVM_SETUP_COMPLETE is defined as 0x80000000, which is larger than INT_MAX. The "-fno-strict-overflow" compiler option properly prevents signaling EVM that the EVM policy setup is complete. Define and read an unsigned int. Fixes: f00d79750712 ("EVM: Allow userspace to signal an RSA key has been loaded") Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 152c2b7fd1266e663d9ede0cb800f8859473f351 Author: Sergey Shtylyov Date: Tue May 18 23:38:54 2021 +0300 pata_octeon_cf: avoid WARN_ON() in ata_host_activate() [ Upstream commit bfc1f378c8953e68ccdbfe0a8c20748427488b80 ] Iff platform_get_irq() fails (or returns IRQ0) and thus the polling mode has to be used, ata_host_activate() hits the WARN_ON() due to 'irq_handler' parameter being non-NULL if the polling mode is selected. Let's only set the pointer to the driver's IRQ handler if platform_get_irq() returns a valid IRQ # -- this should avoid the unnecessary WARN_ON()... Fixes: 43f01da0f279 ("MIPS/OCTEON/ata: Convert pata_octeon_cf.c to use device tree.") Signed-off-by: Sergey Shtylyov Link: https://lore.kernel.org/r/3a241167-f84d-1d25-5b9b-be910afbe666@omp.ru Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e77e1ad45f228d57ca748c7f7cfb2a48fda69d83 Author: Josh Poimboeuf Date: Tue May 18 18:59:15 2021 -0500 kbuild: Fix objtool dependency for 'OBJECT_FILES_NON_STANDARD_ := n' [ Upstream commit 8852c552402979508fdc395ae07aa8761aa46045 ] "OBJECT_FILES_NON_STANDARD_vma.o := n" has a dependency bug. When objtool source is updated, the affected object doesn't get re-analyzed by objtool. Peter's new variable-sized jump label feature relies on objtool rewriting the object file. Otherwise the system can fail to boot. That effectively upgrades this minor dependency issue to a major bug. The problem is that variables in prerequisites are expanded early, during the read-in phase. The '$(objtool_dep)' variable indirectly uses '$@', which isn't yet available when the target prerequisites are evaluated. Use '.SECONDEXPANSION:' which causes '$(objtool_dep)' to be expanded in a later phase, after the target-specific '$@' variable has been defined. Fixes: b9ab5ebb14ec ("objtool: Add CONFIG_STACK_VALIDATION option") Fixes: ab3257042c26 ("jump_label, x86: Allow short NOPs") Reported-by: Matthew Wilcox Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit c5b50bd025dec6f70d2497e1b3f485d0c4465935 Author: Qais Yousef Date: Mon May 10 15:50:32 2021 +0100 sched/uclamp: Fix locking around cpu_util_update_eff() [ Upstream commit 93b73858701fd01de26a4a874eb95f9b7156fd4b ] cpu_cgroup_css_online() calls cpu_util_update_eff() without holding the uclamp_mutex or rcu_read_lock() like other call sites, which is a mistake. The uclamp_mutex is required to protect against concurrent reads and writes that could update the cgroup hierarchy. The rcu_read_lock() is required to traverse the cgroup data structures in cpu_util_update_eff(). Surround the caller with the required locks and add some asserts to better document the dependency in cpu_util_update_eff(). Fixes: 7226017ad37a ("sched/uclamp: Fix a bug in propagating uclamp value in new cgroups") Reported-by: Quentin Perret Signed-off-by: Qais Yousef Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210510145032.1934078-3-qais.yousef@arm.com Signed-off-by: Sasha Levin commit 894ac20220b6bffda1ed4c5364bd5795450d8429 Author: Qais Yousef Date: Mon May 10 15:50:31 2021 +0100 sched/uclamp: Fix wrong implementation of cpu.uclamp.min [ Upstream commit 0c18f2ecfcc274a4bcc1d122f79ebd4001c3b445 ] cpu.uclamp.min is a protection as described in cgroup-v2 Resource Distribution Model Documentation/admin-guide/cgroup-v2.rst which means we try our best to preserve the minimum performance point of tasks in this group. See full description of cpu.uclamp.min in the cgroup-v2.rst. But the current implementation makes it a limit, which is not what was intended. For example: tg->cpu.uclamp.min = 20% p0->uclamp[UCLAMP_MIN] = 0 p1->uclamp[UCLAMP_MIN] = 50% Previous Behavior (limit): p0->effective_uclamp = 0 p1->effective_uclamp = 20% New Behavior (Protection): p0->effective_uclamp = 20% p1->effective_uclamp = 50% Which is inline with how protections should work. With this change the cgroup and per-task behaviors are the same, as expected. Additionally, we remove the confusing relationship between cgroup and !user_defined flag. We don't want for example RT tasks that are boosted by default to max to change their boost value when they attach to a cgroup. If a cgroup wants to limit the max performance point of tasks attached to it, then cpu.uclamp.max must be set accordingly. Or if they want to set different boost value based on cgroup, then sysctl_sched_util_clamp_min_rt_default must be used to NOT boost to max and set the right cpu.uclamp.min for each group to let the RT tasks obtain the desired boost value when attached to that group. As it stands the dependency on !user_defined flag adds an extra layer of complexity that is not required now cpu.uclamp.min behaves properly as a protection. The propagation model of effective cpu.uclamp.min in child cgroups as implemented by cpu_util_update_eff() is still correct. The parent protection sets an upper limit of what the child cgroups will effectively get. Fixes: 3eac870a3247 (sched/uclamp: Use TG's clamps to restrict TASK's clamps) Signed-off-by: Qais Yousef Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210510145032.1934078-2-qais.yousef@arm.com Signed-off-by: Sasha Levin commit 9e7050230b15018fc3f9a6b5d69f1016150cc8b7 Author: Randy Dunlap Date: Fri Apr 30 22:19:55 2021 +0200 media: I2C: change 'RST' to "RSET" to fix multiple build errors [ Upstream commit 8edcb5049ac29aa3c8acc5ef15dd4036543d747e ] The use of an enum named 'RST' conflicts with a #define macro named 'RST' in arch/mips/include/asm/mach-rc32434/rb.h. The MIPS use of RST was there first (AFAICT), so change the media/i2c/ uses of RST to be named 'RSET'. 'git grep -w RSET' does not report any naming conflicts with the new name. This fixes multiple build errors: arch/mips/include/asm/mach-rc32434/rb.h:15:14: error: expected identifier before '(' token 15 | #define RST (1 << 15) | ^ drivers/media/i2c/s5c73m3/s5c73m3.h:356:2: note: in expansion of macro 'RST' 356 | RST, | ^~~ ../arch/mips/include/asm/mach-rc32434/rb.h:15:14: error: expected identifier before '(' token 15 | #define RST (1 << 15) | ^ ../drivers/media/i2c/s5k6aa.c:180:2: note: in expansion of macro 'RST' 180 | RST, | ^~~ ../arch/mips/include/asm/mach-rc32434/rb.h:15:14: error: expected identifier before '(' token 15 | #define RST (1 << 15) | ^ ../drivers/media/i2c/s5k5baf.c:238:2: note: in expansion of macro 'RST' 238 | RST, | ^~~ and some others that I have trimmed. Fixes: cac47f1822fc ("[media] V4L: Add S5C73M3 camera driver") Fixes: 8b99312b7214 ("[media] Add v4l2 subdev driver for S5K4ECGX sensor") Fixes: 7d459937dc09 ("[media] Add driver for Samsung S5K5BAF camera sensor") Fixes: bfa8dd3a0524 ("[media] v4l: Add v4l2 subdev driver for S5K6AAFX sensor") Signed-off-by: Randy Dunlap Reported-by: kernel test robot Cc: Shawn Guo Cc: Sascha Hauer Cc: Pengutronix Kernel Team Cc: Fabio Estevam Cc: NXP Linux Team Cc: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) Cc: Andrzej Hajda Cc: Sylwester Nawrocki Cc: Sangwook Lee Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 25a0bda95d96746929001409e362e886efd0bc14 Author: Sergey Shtylyov Date: Mon Mar 15 14:46:53 2021 +0300 pata_rb532_cf: fix deferred probing [ Upstream commit 2d3a62fbae8e5badc2342388f65ab2191c209cc0 ] The driver overrides the error codes returned by platform_get_irq() to -ENOENT, so if it returns -EPROBE_DEFER, the driver would fail the probe permanently instead of the deferred probing. Switch to propagating the error code upstream, still checking/overriding IRQ0 as libata regards it as "no IRQ" (thus polling) anyway... Fixes: 9ec36cafe43b ("of/irq: do irq resolution in platform_get_irq") Signed-off-by: Sergey Shtylyov Link: https://lore.kernel.org/r/771ced55-3efb-21f5-f21c-b99920aae611@omprussia.ru Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f704f09d3dfa0cc4d349aec23cf86ff9380429a3 Author: Sergey Shtylyov Date: Sun Mar 14 23:34:27 2021 +0300 sata_highbank: fix deferred probing [ Upstream commit 4a24efa16e7db02306fb5db84518bb0a7ada5a46 ] The driver overrides the error codes returned by platform_get_irq() to -EINVAL, so if it returns -EPROBE_DEFER, the driver would fail the probe permanently instead of the deferred probing. Switch to propagating the error code upstream, still checking/overriding IRQ0 as libata regards it as "no IRQ" (thus polling) anyway... Fixes: 9ec36cafe43b ("of/irq: do irq resolution in platform_get_irq") Signed-off-by: Sergey Shtylyov Link: https://lore.kernel.org/r/105b456d-1199-f6e9-ceb7-ffc5ba551d1a@omprussia.ru Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ddac7d88f7e2b4f44dd1a0e09b48eda3177fb3db Author: Zhen Lei Date: Sat May 8 15:00:49 2021 +0800 crypto: ux500 - Fix error return code in hash_hw_final() [ Upstream commit b01360384009ab066940b45f34880991ea7ccbfb ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 8a63b1994c50 ("crypto: ux500 - Add driver for HASH hardware") Reported-by: Hulk Robot Signed-off-by: Zhen Lei Reviewed-by: Linus Walleij Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 88004270271a0dcf397a83fe4aad8dbd47b28aea Author: Corentin Labbe Date: Wed May 5 20:26:09 2021 +0000 crypto: ixp4xx - update IV after requests [ Upstream commit e8acf011f2e7e21a7e2fae47cbaa06598e533d40 ] Crypto selftests fail on ixp4xx since it do not update IV after skcipher requests. Fixes: 81bef0150074 ("crypto: ixp4xx - Hardware crypto support for IXP4xx CPUs") Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 8d75dedf2098712190c1c9fb0d2b75479b25998e Author: Corentin Labbe Date: Wed May 5 20:26:08 2021 +0000 crypto: ixp4xx - dma_unmap the correct address [ Upstream commit 9395c58fdddd79cdd3882132cdd04e8ac7ad525f ] Testing ixp4xx_crypto with CONFIG_DMA_API_DEBUG lead to the following error: DMA-API: platform ixp4xx_crypto.0: device driver tries to free DMA memory it has not allocated [device address=0x0000000000000000] [size=24 bytes] This is due to dma_unmap using the wrong address. Fixes: 0d44dc59b2b4 ("crypto: ixp4xx - Fix handling of chained sg buffers") Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit f152f5e20cb224a5b20eded2bc27935c2eaa3ca0 Author: Mauro Carvalho Chehab Date: Wed Apr 28 08:27:55 2021 +0200 media: hantro: do a PM resume earlier [ Upstream commit 892bb6ecead9b834ba7ad1d07513e9eba1baa3a4 ] The device_run() first enables the clock and then tries to resume PM runtime, checking for errors. Well, if for some reason the pm_runtime can not resume, it would be better to detect it beforehand. So, change the order inside device_run(). Reviewed-by: Ezequiel Garcia Fixes: 775fec69008d ("media: add Rockchip VPU JPEG encoder driver") Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 7ed930e68a125da21c64dce77f51adff5cca4fae Author: Mauro Carvalho Chehab Date: Tue Apr 27 08:36:00 2021 +0200 media: i2c: ccs-core: return the right error code at suspend [ Upstream commit 6005a8e955e4e451e4bf6000affaab566d4cab5e ] If pm_runtime resume logic fails, return the error code provided by it, instead of -EAGAIN, as, depending on what caused it to fail, it may not be something that would be recovered. Fixes: cbba45d43631 ("[media] smiapp: Use runtime PM") Reviewed-by: Jonathan Cameron Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 130fb80cabdfcb208c21ef683113cd094fc14347 Author: Mauro Carvalho Chehab Date: Wed Apr 28 09:38:56 2021 +0200 media: s5p_cec: decrement usage count if disabled [ Upstream commit 747bad54a677d8633ec14b39dfbeb859c821d7f2 ] There's a bug at s5p_cec_adap_enable(): if called to disable the device, it should call pm_runtime_put() instead of pm_runtime_disable(), as the goal here is to decrement the usage_count and not to disable PM runtime. Reported-by: Sylwester Nawrocki Reviewed-by: Jonathan Cameron Fixes: 1bcbf6f4b6b0 ("[media] cec: s5p-cec: Add s5p-cec driver") Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 8dd33849ea9d48eda75442a70447fc510af510e3 Author: Mauro Carvalho Chehab Date: Tue Apr 27 10:39:47 2021 +0200 media: venus: Rework error fail recover logic [ Upstream commit 4cba5473c5ce0f1389d316c5dc6f83a0259df5eb ] The Venus code has a sort of watchdog that attempts to recover from IP errors, implemented as a delayed work job, which calls venus_sys_error_handler(). Right now, it has several issues: 1. It assumes that PM runtime resume never fails 2. It internally runs two while() loops that also assume that PM runtime will never fail to go idle: while (pm_runtime_active(core->dev_dec) || pm_runtime_active(core->dev_enc)) msleep(10); ... while (core->pmdomains[0] && pm_runtime_active(core->pmdomains[0])) usleep_range(1000, 1500); 3. It uses an OR to merge all return codes and then report to the user 4. If the hardware never recovers, it keeps running on every 10ms, flooding the syslog with 2 messages (so, up to 200 messages per second). Rework the code, in order to prevent that, by: 1. check the return code from PM runtime resume; 2. don't let the while() loops run forever; 3. store the failed event; 4. use warn ratelimited when it fails to recover. Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper functions") Reviewed-by: Jonathan Cameron Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 5698d3e1fbb17cc5c255c6fa890df4dfb802dfe2 Author: Andy Shevchenko Date: Tue Apr 20 19:44:25 2021 +0300 spi: Avoid undefined behaviour when counting unused native CSs [ Upstream commit f60d7270c8a3d2beb1c23ae0da42497afa3584c2 ] ffz(), that has been used to count unused native CSs, might cause undefined behaviour when called against ~0U. To fix that, open code it with ffs(~value) - 1. Fixes: 7d93aecdb58d ("spi: Add generic support for unused native cs with cs-gpios") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210420164425.40287-2-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit bbf7cde09e9bb7c91046ceee1f3aca3389adcd07 Author: Andy Shevchenko Date: Tue Apr 20 19:44:24 2021 +0300 spi: Allow to have all native CSs in use along with GPIOs [ Upstream commit dbaca8e56ea3f23fa215f48c2d46dd03ede06e02 ] The commit 7d93aecdb58d ("spi: Add generic support for unused native cs with cs-gpios") excludes the valid case for the controllers that doesn't need to switch native CS in order to perform the transfer, i.e. when 0 native ... ... - 1 native GPIO + 1 GPIO ... ... where defines maximum of native CSs supported by the controller. To allow this, bail out from spi_get_gpio_descs() conditionally for the controllers which explicitly marked with SPI_MASTER_GPIO_SS. Fixes: 7d93aecdb58d ("spi: Add generic support for unused native cs with cs-gpios") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210420164425.40287-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3d9d4aa8dad320f4e8a20a05032263bb56dd708f Author: Andrii Nakryiko Date: Mon Jun 28 19:41:34 2021 -0700 kbuild: skip per-CPU BTF generation for pahole v1.18-v1.21 [ Upstream commit a0b8200d06ad6450c179407baa5f0f52f8cfcc97 ] Commit "mm/page_alloc: convert per-cpu list protection to local_lock" will introduce a zero-sized per-CPU variable, which causes pahole to generate invalid BTF. Only pahole versions 1.18 through 1.21 are impacted, as before 1.18 pahole doesn't know anything about per-CPU variables, and 1.22 contains the proper fix for the issue. Luckily, pahole 1.18 got --skip_encoding_btf_vars option disabling BTF generation for per-CPU variables in anticipation of some unanticipated problems. So use this escape hatch to disable per-CPU var BTF info on those problematic pahole versions. Users relying on availability of per-CPU var BTFs would need to upgrade to pahole 1.22+, but everyone won't notice any regressions. Link: https://lkml.kernel.org/r/20210530002536.3193829-1-andrii@kernel.org Signed-off-by: Andrii Nakryiko Acked-by: Mel Gorman Cc: Arnaldo Carvalho de Melo Cc: Hao Luo Cc: Michal Suchanek Cc: Jiri Olsa Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit d5719131c5ca9ec55b9690a580165ef90474d0f2 Author: Daniel Axtens Date: Mon Jun 28 19:40:46 2021 -0700 mm: define default MAX_PTRS_PER_* in include/pgtable.h [ Upstream commit c0f8aa4fa815daacb6eca52cae04820d6aecb7c2 ] Commit c65e774fb3f6 ("x86/mm: Make PGDIR_SHIFT and PTRS_PER_P4D variable") made PTRS_PER_P4D variable on x86 and introduced MAX_PTRS_PER_P4D as a constant for cases which need a compile-time constant (e.g. fixed-size arrays). powerpc likewise has boot-time selectable MMU features which can cause other mm "constants" to vary. For KASAN, we have some static PTE/PMD/PUD/P4D arrays so we need compile-time maximums for all these constants. Extend the MAX_PTRS_PER_ idiom, and place default definitions in include/pgtable.h. These define MAX_PTRS_PER_x to be PTRS_PER_x unless an architecture has defined MAX_PTRS_PER_x in its arch headers. Clean up pgtable-nop4d.h and s390's MAX_PTRS_PER_P4D definitions while we're at it: both can just pick up the default now. Link: https://lkml.kernel.org/r/20210624034050.511391-4-dja@axtens.net Signed-off-by: Daniel Axtens Acked-by: Andrey Konovalov Reviewed-by: Christophe Leroy Reviewed-by: Marco Elver Cc: Aneesh Kumar K.V Cc: Balbir Singh Cc: Alexander Potapenko Cc: Andrey Ryabinin Cc: Dmitry Vyukov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 3921b835fbaecf6db7153b0c4125cfe34f5954b1 Author: Roman Gushchin Date: Mon Jun 28 19:35:47 2021 -0700 writeback, cgroup: increment isw_nr_in_flight before grabbing an inode [ Upstream commit 8826ee4fe75051f8cbfa5d4a9aa70565938e724c ] isw_nr_in_flight is used to determine whether the inode switch queue should be flushed from the umount path. Currently it's increased after grabbing an inode and even scheduling the switch work. It means the umount path can walk past cleanup_offline_cgwb() with active inode references, which can result in a "Busy inodes after unmount." message and use-after-free issues (with inode->i_sb which gets freed). Fix it by incrementing isw_nr_in_flight before doing anything with the inode and decrementing in the case when switching wasn't scheduled. The problem hasn't yet been seen in the real life and was discovered by Jan Kara by looking into the code. Link: https://lkml.kernel.org/r/20210608230225.2078447-4-guro@fb.com Signed-off-by: Roman Gushchin Suggested-by: Jan Kara Reviewed-by: Jan Kara Cc: Alexander Viro Cc: Dave Chinner Cc: Dennis Zhou Cc: Tejun Heo Cc: Jens Axboe Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 53602599e6f63ddd03eda3606bb8631223e0d0e3 Author: Arnd Bergmann Date: Mon Jun 28 19:33:41 2021 -0700 ia64: mca_drv: fix incorrect array size calculation [ Upstream commit c5f320ff8a79501bb59338278336ec43acb9d7e2 ] gcc points out a mistake in the mca driver that goes back to before the git history: arch/ia64/kernel/mca_drv.c: In function 'init_record_index_pools': arch/ia64/kernel/mca_drv.c:346:54: error: expression does not compute the number of elements in this array; element typ e is 'int', not 'size_t' {aka 'long unsigned int'} [-Werror=sizeof-array-div] 346 | for (i = 1; i < sizeof sal_log_sect_min_sizes/sizeof(size_t); i++) | ^ This is the same as sizeof(size_t), which is two shorter than the actual array. Use the ARRAY_SIZE() macro to get the correct calculation instead. Link: https://lkml.kernel.org/r/20210514214123.875971-1-arnd@kernel.org Signed-off-by: Arnd Bergmann Cc: Masahiro Yamada Cc: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 10855647c0cbbc58c7a86fa1961bec5396b11ed8 Author: Petr Mladek Date: Mon Jun 28 19:33:35 2021 -0700 kthread_worker: fix return value when kthread_mod_delayed_work() races with kthread_cancel_delayed_work_sync() [ Upstream commit d71ba1649fa3c464c51ec7163e4b817345bff2c7 ] kthread_mod_delayed_work() might race with kthread_cancel_delayed_work_sync() or another kthread_mod_delayed_work() call. The function lets the other operation win when it sees work->canceling counter set. And it returns @false. But it should return @true as it is done by the related workqueue API, see mod_delayed_work_on(). The reason is that the return value might be used for reference counting. It has to distinguish the case when the number of queued works has changed or stayed the same. The change is safe. kthread_mod_delayed_work() return value is not checked anywhere at the moment. Link: https://lore.kernel.org/r/20210521163526.GA17916@redhat.com Link: https://lkml.kernel.org/r/20210610133051.15337-4-pmladek@suse.com Signed-off-by: Petr Mladek Reported-by: Oleg Nesterov Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: Tejun Heo Cc: Minchan Kim Cc: Cc: Martin Liu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit cf46e6f4898fccbf5167ce3e7c84b0af7525d99d Author: Ming Lei Date: Mon Jun 28 10:33:12 2021 +0800 block: fix discard request merge [ Upstream commit 2705dfb2094777e405e065105e307074af8965c1 ] ll_new_hw_segment() is reached only in case of single range discard merge, and we don't have max discard segment size limit actually, so it is wrong to run the following check: if (req->nr_phys_segments + nr_phys_segs > blk_rq_get_max_segments(req)) it may be always false since req->nr_phys_segments is initialized as one, and bio's segment count is still 1, blk_rq_get_max_segments(reg) is 1 too. Fix the issue by not doing the check and bypassing the calculation of discard request's nr_phys_segments. Based on analysis from Wang Shanker. Cc: Christoph Hellwig Reported-by: Wang Shanker Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20210628023312.1903255-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c9e970ed58c0f82afbbe68e17043f71d56a3b0db Author: Shawn Guo Date: Tue Jun 22 08:39:18 2021 +0800 mailbox: qcom: Use PLATFORM_DEVID_AUTO to register platform device [ Upstream commit 96e39e95c01283ff5695dafe659df88ada802159 ] In adding APCS clock support for MSM8939, the second clock registration fails due to duplicate device name like below. [ 0.519657] sysfs: cannot create duplicate filename '/bus/platform/devices/qcom-apcs-msm8916-clk' ... [ 0.661158] qcom_apcs_ipc b111000.mailbox: failed to register APCS clk This is because MSM8939 has 3 APCS instances for Cluster0 (little cores), Cluster1 (big cores) and CCI (Cache Coherent Interconnect). Although only APCS of Cluster0 and Cluster1 have IPC bits, each of 3 APCS has A53PLL clock control bits. That said, 3 'qcom-apcs-msm8916-clk' devices need to be registered to instantiate all 3 clocks. Use PLATFORM_DEVID_AUTO rather than PLATFORM_DEVID_NONE for platform_device_register_data() call to fix the issue above. Signed-off-by: Shawn Guo Reviewed-by: Bjorn Andersson Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit bebfd66f067c4c11d12ea6146f402cad5a611465 Author: Steve French Date: Thu Jun 24 15:28:04 2021 -0500 cifs: fix missing spinlock around update to ses->status [ Upstream commit 0060a4f28a9ef45ae8163c0805e944a2b1546762 ] In the other places where we update ses->status we protect the updates via GlobalMid_Lock. So to be consistent add the same locking around it in cifs_put_smb_ses where it was missing. Addresses-Coverity: 1268904 ("Data race condition") Signed-off-by: Steve French Signed-off-by: Sasha Levin commit b25ec82321ad47f34301912acfbc59cedc188d56 Author: Jason Gerecke Date: Wed Jun 23 09:58:09 2021 -0700 HID: wacom: Correct base usage for capacitive ExpressKey status bits [ Upstream commit 424d8237945c6c448c8b3f23885d464fb5685c97 ] The capacitive status of ExpressKeys is reported with usages beginning at 0x940, not 0x950. Bring our driver into alignment with reality. Signed-off-by: Jason Gerecke Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit fee404cb46578430eb04bc795b971cbcbcca240c Author: Steve French Date: Tue Jun 22 17:54:50 2021 -0500 smb3: fix possible access to uninitialized pointer to DACL [ Upstream commit a5628263a9f8d47d9a1548fe9d5d75ba4423a735 ] dacl_ptr can be null so we must check for it everywhere it is used in build_sec_desc. Addresses-Coverity: 1475598 ("Explicit null dereference") Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 2e4c04443e586296ec5f40a752328778d7d66c1a Author: Richard Fitzgerald Date: Mon Jun 21 16:24:33 2021 +0100 ACPI: tables: Add custom DSDT file as makefile prerequisite [ Upstream commit d1059c1b1146870c52f3dac12cb7b6cbf39ed27f ] A custom DSDT file is mostly used during development or debugging, and in that case it is quite likely to want to rebuild the kernel after changing ONLY the content of the DSDT. This patch adds the custom DSDT as a prerequisite to tables.o to ensure a rebuild if the DSDT file is updated. Make will merge the prerequisites from multiple rules for the same target. Signed-off-by: Richard Fitzgerald Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit e34583fce2ea318225811a5accc3c1a8b59bb5ac Author: Javier Martinez Canillas Date: Thu May 27 17:23:52 2021 +0200 tpm_tis_spi: add missing SPI device ID entries [ Upstream commit c46ed2281bbe4b84e6f3d4bdfb0e4e9ab813fa9d ] The SPI core always reports a "MODALIAS=spi:", even if the device was registered via OF. This means that this module won't auto-load if a DT has for example has a node with a compatible "infineon,slb9670" string. In that case kmod will expect a "MODALIAS=of:N*T*Cinfineon,slb9670" uevent but instead will get a "MODALIAS=spi:slb9670", which is not present in the kernel module aliases: $ modinfo drivers/char/tpm/tpm_tis_spi.ko | grep alias alias: of:N*T*Cgoogle,cr50C* alias: of:N*T*Cgoogle,cr50 alias: of:N*T*Ctcg,tpm_tis-spiC* alias: of:N*T*Ctcg,tpm_tis-spi alias: of:N*T*Cinfineon,slb9670C* alias: of:N*T*Cinfineon,slb9670 alias: of:N*T*Cst,st33htpm-spiC* alias: of:N*T*Cst,st33htpm-spi alias: spi:cr50 alias: spi:tpm_tis_spi alias: acpi*:SMO0768:* To workaround this issue, add in the SPI device ID table all the entries that are present in the OF device ID table. Reported-by: Alexander Wellbrock Signed-off-by: Javier Martinez Canillas Tested-by: Peter Robinson Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 155d3c5d24ee13cafa6236b49fc02b240a511d59 Author: Paul E. McKenney Date: Thu May 27 12:01:20 2021 -0700 clocksource: Check per-CPU clock synchronization when marked unstable [ Upstream commit 7560c02bdffb7c52d1457fa551b9e745d4b9e754 ] Some sorts of per-CPU clock sources have a history of going out of synchronization with each other. However, this problem has purportedy been solved in the past ten years. Except that it is all too possible that the problem has instead simply been made less likely, which might mean that some of the occasional "Marking clocksource 'tsc' as unstable" messages might be due to desynchronization. How would anyone know? Therefore apply CPU-to-CPU synchronization checking to newly unstable clocksource that are marked with the new CLOCK_SOURCE_VERIFY_PERCPU flag. Lists of desynchronized CPUs are printed, with the caveat that if it is the reporting CPU that is itself desynchronized, it will appear that all the other clocks are wrong. Just like in real life. Reported-by: Chris Mason Signed-off-by: Paul E. McKenney Signed-off-by: Thomas Gleixner Acked-by: Feng Tang Link: https://lore.kernel.org/r/20210527190124.440372-2-paulmck@kernel.org Signed-off-by: Sasha Levin commit d13f6800334232d1181d108eb7225052a6733a3d Author: Paul E. McKenney Date: Thu May 27 12:01:19 2021 -0700 clocksource: Retry clock read if long delays detected [ Upstream commit db3a34e17433de2390eb80d436970edcebd0ca3e ] When the clocksource watchdog marks a clock as unstable, this might be due to that clock being unstable or it might be due to delays that happen to occur between the reads of the two clocks. Yes, interrupts are disabled across those two reads, but there are no shortage of things that can delay interrupts-disabled regions of code ranging from SMI handlers to vCPU preemption. It would be good to have some indication as to why the clock was marked unstable. Therefore, re-read the watchdog clock on either side of the read from the clock under test. If the watchdog clock shows an excessive time delta between its pair of reads, the reads are retried. The maximum number of retries is specified by a new kernel boot parameter clocksource.max_cswd_read_retries, which defaults to three, that is, up to four reads, one initial and up to three retries. If more than one retry was required, a message is printed on the console (the occasional single retry is expected behavior, especially in guest OSes). If the maximum number of retries is exceeded, the clock under test will be marked unstable. However, the probability of this happening due to various sorts of delays is quite small. In addition, the reason (clock-read delays) for the unstable marking will be apparent. Reported-by: Chris Mason Signed-off-by: Paul E. McKenney Signed-off-by: Thomas Gleixner Acked-by: Feng Tang Link: https://lore.kernel.org/r/20210527190124.440372-1-paulmck@kernel.org Signed-off-by: Sasha Levin commit c37238fae66db055ad9ced2cdefc3d2d2f60023f Author: Luca Mariotti Date: Sat Jun 19 16:09:43 2021 +0200 block, bfq: fix delayed stable merge check [ Upstream commit e03f2ab78a4a673e4af23c3b855591c48b9de4d7 ] When attempting to schedule a merge of a given bfq_queue with the currently in-service bfq_queue or with a cooperating bfq_queue among the scheduled bfq_queues, delayed stable merge is checked for rotational or non-queueing devs. For this stable merge to be performed, some conditions must be met. If the current bfq_queue underwent some split from some merged bfq_queue, one of these conditions is that two hundred milliseconds must elapse from split, otherwise this condition is always met. Unfortunately, by mistake, time_is_after_jiffies() was written instead of time_is_before_jiffies() for this check, verifying that less than two hundred milliseconds have elapsed instead of verifying that at least two hundred milliseconds have elapsed. Fix this issue by replacing time_is_after_jiffies() with time_is_before_jiffies(). Signed-off-by: Luca Mariotti Signed-off-by: Paolo Valente Signed-off-by: Pietro Pedroni Link: https://lore.kernel.org/r/20210619140948.98712-3-paolo.valente@linaro.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a1e7400147eb5706323a6c12c439991115f0b6e1 Author: Zhang Rui Date: Mon Jun 21 09:37:27 2021 +0800 ACPI: EC: trust DSDT GPE for certain HP laptop [ Upstream commit 4370cbf350dbaca984dbda9f9ce3fac45d6949d5 ] On HP Pavilion Gaming Laptop 15-cx0xxx, the ECDT EC and DSDT EC share the same port addresses but different GPEs. And the DSDT GPE is the right one to use. The current code duplicates DSDT EC with ECDT EC if the port addresses are the same, and uses ECDT GPE as a result, which breaks this machine. Introduce a new quirk for the HP laptop to trust the DSDT GPE, and avoid duplicating even if the port addresses are the same. Link: https://bugzilla.kernel.org/show_bug.cgi?id=209989 Reported-and-tested-by: Shao Fu, Chen Signed-off-by: Zhang Rui Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit fa004a75b5ff7475dba4f10db04811a1635319f3 Author: Steve French Date: Sat Jun 19 15:53:18 2021 -0500 cifs: fix SMB1 error path in cifs_get_file_info_unix [ Upstream commit e39df24169a2ceb0d359eb3a05ff982711f2eb32 ] We were trying to fill in uninitialized file attributes in the error case. Addresses-Coverity: 139689 ("Uninitialized variables") Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 9a0c82374f675c42ab6b3d568bd7d8849cb53702 Author: Steve French Date: Sat Jun 19 12:22:20 2021 -0500 smb3: fix uninitialized value for port in witness protocol move [ Upstream commit ff93b71a3eff25fe9d4364ef13b6e01d935600c6 ] Although in practice this can not occur (since IPv4 and IPv6 are the only two cases currently supported), it is cleaner to avoid uninitialized variable warnings. Addresses smatch warning: fs/cifs/cifs_swn.c:468 cifs_swn_store_swn_addr() error: uninitialized symbol 'port'. Reported-by: kernel test robot Reported-by: Dan Carpenter CC: Samuel Cabrero Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 027c9f092d151f7a3310d2da3f011bb4f1fe68c2 Author: Thiago Rafael Becker Date: Tue Jun 15 13:42:56 2021 -0300 cifs: retry lookup and readdir when EAGAIN is returned. [ Upstream commit 6efa994e35a402ae4ae2161b6439c94b64816cee ] According to the investigation performed by Jacob Shivers at Red Hat, cifs_lookup and cifs_readdir leak EAGAIN when the user session is deleted on the server. Fix this issue by implementing a retry with limits, as is implemented in cifs_revalidate_dentry_attr. Reproducer based on the work by Jacob Shivers: ~~~ $ cat readdir-cifs-test.sh #!/bin/bash # Install and configure powershell and sshd on the windows # server as descibed in # https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_overview # This script uses expect(1) USER=dude SERVER=192.168.0.2 RPATH=root PASS='password' function debug_funcs { for line in $@ ; do echo "func $line +p" > /sys/kernel/debug/dynamic_debug/control done } function setup { echo 1 > /proc/fs/cifs/cifsFYI debug_funcs wait_for_compound_request \ smb2_query_dir_first cifs_readdir \ compound_send_recv cifs_reconnect_tcon \ generic_ip_connect cifs_reconnect \ smb2_reconnect_server smb2_reconnect \ cifs_readv_from_socket cifs_readv_receive tcpdump -i eth0 -w cifs.pcap host 192.168.2.182 & sleep 5 dmesg -C } function test_call { if [[ $1 == 1 ]] ; then tracer="strace -tt -f -s 4096 -o trace-$(date -Iseconds).txt" fi # Change the command here to anything appropriate $tracer ls $2 > /dev/null res=$? if [[ $1 == 1 ]] ; then if [[ $res == 0 ]] ; then 1>&2 echo success else 1>&2 echo "failure ($res)" fi fi } mountpoint /mnt > /dev/null || mount -t cifs -o username=$USER,pass=$PASS //$SERVER/$RPATH /mnt test_call 0 /mnt/ /usr/bin/expect << EOF set timeout 60 spawn ssh $USER@$SERVER expect "yes/no" { send "yes\r" expect "*?assword" { send "$PASS\r" } } "*?assword" { send "$PASS\r" } expect ">" { send "powershell close-smbsession -force\r" } expect ">" { send "exit\r" } expect eof EOF sysctl -w vm.drop_caches=2 > /dev/null sysctl -w vm.drop_caches=2 > /dev/null setup test_call 1 /mnt/ ~~~ Signed-off-by: Thiago Rafael Becker Acked-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 1c25524992af55283b2ba5e03ece15bb4b6b60c0 Author: Paulo Alcantara Date: Mon Jun 14 12:58:20 2021 -0300 cifs: fix check of dfs interlinks [ Upstream commit 889c2a700799f3b6f82210925e1faf4a9b833c4a ] Interlink is a special type of DFS link that resolves to a different DFS domain-based namespace. To determine whether it is an interlink or not, check if ReferralServers and StorageServers bits are set to 1 and 0 respectively in ReferralHeaderFlags, as specified in MS-DFSC 3.1.5.4.5 Determining Whether a Referral Response is an Interlink. Signed-off-by: Paulo Alcantara (SUSE) Reviewed-by: Aurelien Aptel Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 5e397c943424de94879830e72c95f2679e297a76 Author: Ronnie Sahlberg Date: Thu Jun 3 15:31:01 2021 +1000 cifs: improve fallocate emulation [ Upstream commit 966a3cb7c7db786452a87afdc3b48858fc4d4d6b ] RHBZ: 1866684 We don't have a real fallocate in the SMB2 protocol so we used to emulate fallocate by simply switching the file to become non-sparse. But as that could potantially consume a lot more data than we intended to fallocate (large sparse file and fallocating a thin slice in the middle) we would only do this IFF the fallocate request was for virtually the entire file. This patch improves this and starts allowing us to fallocate smaller chunks of a file by overwriting the region with 0, for the parts that are unallocated. The method used is to first query the server for FSCTL_QUERY_ALLOCATED_RANGES to find what is unallocated in the fallocate range and then to only overwrite-with-zero the unallocated ranges to fill in the holes. As overwriting-with-zero is different from just allocating blocks, and potentially much more expensive, we limit this to only allow fallocate ranges up to 1Mb in size. Reported-by: kernel test robot Signed-off-by: Ronnie Sahlberg Acked-by: Aurelien Aptel Acked-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 5f28c21d77021907e23f952f8b9821b6867e83d4 Author: Haiyang Zhang Date: Tue May 25 16:17:33 2021 -0700 PCI: hv: Add check for hyperv_initialized in init_hv_pci_drv() [ Upstream commit 7d815f4afa87f2032b650ae1bba7534b550a6b8b ] Add check for hv_is_hyperv_initialized() at the top of init_hv_pci_drv(), so if the pci-hyperv driver is force-loaded on non Hyper-V platforms, the init_hv_pci_drv() will exit immediately, without any side effects, like assignments to hvpci_block_ops, etc. Signed-off-by: Haiyang Zhang Reported-and-tested-by: Mohammad Alqayeem Reviewed-by: Wei Liu Link: https://lore.kernel.org/r/1621984653-1210-1-git-send-email-haiyangz@microsoft.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 8104b56965e17bf9c8800274a0fcc9353f877ba5 Author: Srinivas Pandruvada Date: Wed May 12 03:17:32 2021 -0700 tools/power/x86/intel-speed-select: Fix uncore memory frequency display [ Upstream commit 159f130f60f402273b235801d1fde3fc115c6795 ] The uncore memory frequency value from the mailbox command CONFIG_TDP_GET_MEM_FREQ needs to be scaled based on the platform for display. There is no single constant multiplier. This change introduces CPU model specific memory frequency multiplier. Signed-off-by: Srinivas Pandruvada Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 35d976c3550232418dbf183755e7d05300f66a72 Author: Tony Luck Date: Tue Jun 15 10:44:19 2021 -0700 EDAC/Intel: Do not load EDAC driver when running as a guest [ Upstream commit f0a029fff4a50eb01648810a77ba1873e829fdd4 ] There's little to no point in loading an EDAC driver running in a guest: 1) The CPU model reported by CPUID may not represent actual h/w 2) The hypervisor likely does not pass in access to memory controller devices 3) Hypervisors generally do not pass corrected error details to guests Add a check in each of the Intel EDAC drivers for X86_FEATURE_HYPERVISOR and simply return -ENODEV in the init routine. Acked-by: Borislav Petkov Signed-off-by: Tony Luck Link: https://lore.kernel.org/r/20210615174419.GA1087688@agluck-desk2.amr.corp.intel.com Signed-off-by: Sasha Levin commit 2fe788c18b66a2f6ef0ed3c3bcd5e9f6506776d3 Author: Hannes Reinecke Date: Tue May 25 14:54:14 2021 +0200 nvmet-fc: do not check for invalid target port in nvmet_fc_handle_fcp_rqst() [ Upstream commit 2a4a910aa4f0acc428dc8d10227c42e14ed21d10 ] When parsing a request in nvmet_fc_handle_fcp_rqst() we should not check for invalid target ports; if we do the command is aborted from the fcp layer, causing the host to assume a transport error. Rather we should still forward this request to the nvmet layer, which will then correctly fail the command with an appropriate error status. Signed-off-by: Hannes Reinecke Reviewed-by: James Smart Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 1205de7c198f532b0da78762b658b375fc95c0aa Author: JK Kim Date: Thu Jun 17 15:02:17 2021 +0900 nvme-pci: fix var. type for increasing cq_head [ Upstream commit a0aac973a26d1ac814b9e131e209eb39472a67ce ] nvmeq->cq_head is compared with nvmeq->q_depth and changed the value and cq_phase for handling the next cq db. but, nvmeq->q_depth's type is u32 and max. value is 0x10000 when CQP.MSQE is 0xffff and io_queue_depth is 0x10000. current temp. variable for comparing with nvmeq->q_depth is overflowed when previous nvmeq->cq_head is 0xffff. in this case, nvmeq->cq_phase is not updated. so, fix data type for temp. variable to u32. Signed-off-by: JK Kim Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit c74f85583f6ddb84cf7429d93e94659cfee4764d Author: Jiapeng Chong Date: Wed Jun 2 18:05:48 2021 +0800 platform/x86: toshiba_acpi: Fix missing error code in toshiba_acpi_setup_keyboard() [ Upstream commit 28e367127718a9cb85d615a71e152f7acee41bfc ] The error code is missing in this code scenario, add the error code '-EINVAL' to the return value 'error'. Eliminate the follow smatch warning: drivers/platform/x86/toshiba_acpi.c:2834 toshiba_acpi_setup_keyboard() warn: missing error code 'error'. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong Link: https://lore.kernel.org/r/1622628348-87035-1-git-send-email-jiapeng.chong@linux.alibaba.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 6632da07ac6c14ce4f8d53296a429094ee9ccf4d Author: Luke D. Jones Date: Mon Apr 19 19:49:15 2021 +1200 platform/x86: asus-nb-wmi: Revert "add support for ASUS ROG Zephyrus G14 and G15" [ Upstream commit 28117f3a5c3c8375a3304af76357d5bf9cf30f0b ] The quirks added to asus-nb-wmi for the ASUS ROG Zephyrus G14 and G15 are wrong, they tell the asus-wmi code to use the vendor specific WMI backlight interface. But there is no such interface on these laptops. As a side effect, these quirks stop the acpi_video driver to register since they make acpi_video_get_backlight_type() return acpi_backlight_vendor, leaving only the native AMD backlight driver in place, which is the one we want. This happy coincidence is being replaced with a new quirk in drivers/acpi/video_detect.c which actually sets the backlight_type to acpi_backlight_native fixinf this properly. This reverts commit 13bceda68fb9 ("platform/x86: asus-nb-wmi: add support for ASUS ROG Zephyrus G14 and G15"). Signed-off-by: Luke D. Jones Link: https://lore.kernel.org/r/20210419074915.393433-3-luke@ljones.dev Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 91634181ba81e7d8386709852d49265712c79938 Author: Luke D. Jones Date: Mon Apr 19 19:49:14 2021 +1200 platform/x86: asus-nb-wmi: Revert "Drop duplicate DMI quirk structures" [ Upstream commit 98c0c85b1040db24f0d04d3e1d315c6c7b05cc07 ] This is a preparation revert for reverting the "add support for ASUS ROG Zephyrus G14 and G15" change. This reverts commit 67186653c903 ("platform/x86: asus-nb-wmi: Drop duplicate DMI quirk structures") Signed-off-by: Luke D. Jones Link: https://lore.kernel.org/r/20210419074915.393433-2-luke@ljones.dev Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 6c22172ca78142b0dff366cc70ac83b37c920981 Author: Ming Lei Date: Wed Jun 9 09:58:21 2021 +0800 block: fix race between adding/removing rq qos and normal IO [ Upstream commit 2cafe29a8d03f02a3d16193bdaae2f3e82a423f9 ] Yi reported several kernel panics on: [16687.001777] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 ... [16687.163549] pc : __rq_qos_track+0x38/0x60 or [ 997.690455] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... [ 997.850347] pc : __rq_qos_done+0x2c/0x50 Turns out it is caused by race between adding rq qos(wbt) and normal IO because rq_qos_add can be run when IO is being submitted, fix this issue by freezing queue before adding/deleting rq qos to queue. rq_qos_exit() needn't to freeze queue because it is called after queue has been frozen. iolatency calls rq_qos_add() during allocating queue, so freezing won't add delay because queue usage refcount works at atomic mode at that time. iocost calls rq_qos_add() when writing cgroup attribute file, that is fine to freeze queue at that time since we usually freeze queue when storing to queue sysfs attribute, meantime iocost only exists on the root cgroup. wbt_init calls it in blk_register_queue() and queue sysfs attribute store(queue_wb_lat_store() when write it 1st time in case of !BLK_WBT_MQ), the following patch will speedup the queue freezing in wbt_init. Reported-by: Yi Zhang Cc: Bart Van Assche Signed-off-by: Ming Lei Reviewed-by: Bart Van Assche Tested-by: Yi Zhang Link: https://lore.kernel.org/r/20210609015822.103433-2-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 02f04a3c5d74bd8842ce1ad44a2304e5b62a238f Author: Pascal Giard Date: Fri Jun 4 12:10:23 2021 -0400 HID: sony: fix freeze when inserting ghlive ps3/wii dongles [ Upstream commit fb1a79a6b6e1223ddb18f12aa35e36f832da2290 ] This commit fixes a freeze on insertion of a Guitar Hero Live PS3/WiiU USB dongle. Indeed, with the current implementation, inserting one of those USB dongles will lead to a hard freeze. I apologize for not catching this earlier, it didn't occur on my old laptop. While the issue was isolated to memory alloc/free, I could not figure out why it causes a freeze. So this patch fixes this issue by simplifying memory allocation and usage. We remind that for the dongle to work properly, a control URB needs to be sent periodically. We used to alloc/free the URB each time this URB needed to be sent. With this patch, the memory for the URB is allocated on the probe, reused for as long as the dongle is plugged in, and freed once the dongle is unplugged. Signed-off-by: Pascal Giard Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 3cc07545a3eaaa08b8097fa5fba817b67b542c89 Author: Zoltan Tamas Vajda Date: Thu Jun 3 20:58:14 2021 +0200 HID: hid-input: add Surface Go battery quirk [ Upstream commit b5539722eb832441f309642fe5102cc3536f92b8 ] The Elantech touchscreen/digitizer in the Surface Go mistakenly reports having a battery. This results in a low battery message every time you try to use the pen. This patch adds a quirk to ignore the non-existent battery and gets rid of the false low battery messages. Signed-off-by: Zoltan Tamas Vajda Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit bf155b2eaab40e7d9862ce89ffe2b8a80f86703b Author: Hui Wang Date: Wed Jun 9 10:14:42 2021 +0800 ACPI: resources: Add checks for ACPI IRQ override [ Upstream commit 0ec4e55e9f571f08970ed115ec0addc691eda613 ] The laptop keyboard doesn't work on many MEDION notebooks, but the keyboard works well under Windows and Unix. Through debugging, we found this log in the dmesg: ACPI: IRQ 1 override to edge, high pnp 00:03: Plug and Play ACPI device, IDs PNP0303 (active) And we checked the IRQ definition in the DSDT, it is: IRQ (Level, ActiveLow, Exclusive, ) {1} So the BIOS defines the keyboard IRQ to Level_Low, but the Linux kernel override it to Edge_High. If the Linux kernel is modified to skip the IRQ override, the keyboard will work normally. From the existing comment in acpi_dev_get_irqresource(), the override function only needs to be called when IRQ() or IRQNoFlags() is used to populate the resource descriptor, and according to Section 6.4.2.1 of ACPI 6.4 [1], if IRQ() is empty or IRQNoFlags() is used, the IRQ is High true, edge sensitive and non-shareable. ACPICA also assumes that to be the case (see acpi_rs_set_irq[] in rsirq.c). In accordance with the above, check 3 additional conditions (EdgeSensitive, ActiveHigh and Exclusive) when deciding whether or not to treat an ACPI_RESOURCE_TYPE_IRQ resource as "legacy", in which case the IRQ override is applicable to it. Link: https://uefi.org/specs/ACPI/6.4/06_Device_Configuration/Device_Configuration.html#irq-descriptor # [1] BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=213031 BugLink: http://bugs.launchpad.net/bugs/1909814 Suggested-by: Rafael J. Wysocki Reported-by: Manuel Krause Tested-by: Manuel Krause Signed-off-by: Hui Wang [ rjw: Subject rewrite, changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 69136f2492ddcfb4e1d0296792b74005342c8f4e Author: Hanjun Guo Date: Wed Jun 2 17:36:50 2021 +0800 ACPI: bus: Call kobject_put() in acpi_init() error path [ Upstream commit 4ac7a817f1992103d4e68e9837304f860b5e7300 ] Although the system will not be in a good condition or it will not boot if acpi_bus_init() fails, it is still necessary to put the kobject in the error path before returning to avoid leaking memory. Signed-off-by: Hanjun Guo [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 2bf1f848ca0af4e3d49624df49cbbd5511ec49a3 Author: Erik Kaneda Date: Fri Jun 4 14:25:57 2021 -0700 ACPICA: Fix memory leak caused by _CID repair function [ Upstream commit c27bac0314131b11bccd735f7e8415ac6444b667 ] ACPICA commit 180cb53963aa876c782a6f52cc155d951b26051a According to the ACPI spec, _CID returns a package containing hardware ID's. Each element of an ASL package contains a reference count from the parent package as well as the element itself. Name (TEST, Package() { "String object" // this package element has a reference count of 2 }) A memory leak was caused in the _CID repair function because it did not decrement the reference count created by the package. Fix the memory leak by calling acpi_ut_remove_reference on _CID package elements that represent a hardware ID (_HID). Link: https://github.com/acpica/acpica/commit/180cb539 Tested-by: Shawn Guo Signed-off-by: Erik Kaneda Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 60c534a4a79eae00150683475e5ecfe8ba9877e0 Author: Alexander Aring Date: Wed Jun 2 09:45:16 2021 -0400 fs: dlm: fix memory leak when fenced [ Upstream commit 700ab1c363c7b54c9ea3222379b33fc00ab02f7b ] I got some kmemleak report when a node was fenced. The user space tool dlm_controld will therefore run some rmdir() in dlm configfs which was triggering some memleaks. This patch stores the sps and cms attributes which stores some handling for subdirectories of the configfs cluster entry and free them if they get released as the parent directory gets freed. unreferenced object 0xffff88810d9e3e00 (size 192): comm "dlm_controld", pid 342, jiffies 4294698126 (age 55438.801s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 73 70 61 63 65 73 00 00 ........spaces.. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000db8b640b>] make_cluster+0x5d/0x360 [<000000006a571db4>] configfs_mkdir+0x274/0x730 [<00000000b094501c>] vfs_mkdir+0x27e/0x340 [<0000000058b0adaf>] do_mkdirat+0xff/0x1b0 [<00000000d1ffd156>] do_syscall_64+0x40/0x80 [<00000000ab1408c8>] entry_SYSCALL_64_after_hwframe+0x44/0xae unreferenced object 0xffff88810d9e3a00 (size 192): comm "dlm_controld", pid 342, jiffies 4294698126 (age 55438.801s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 63 6f 6d 6d 73 00 00 00 ........comms... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000a7ef6ad2>] make_cluster+0x82/0x360 [<000000006a571db4>] configfs_mkdir+0x274/0x730 [<00000000b094501c>] vfs_mkdir+0x27e/0x340 [<0000000058b0adaf>] do_mkdirat+0xff/0x1b0 [<00000000d1ffd156>] do_syscall_64+0x40/0x80 [<00000000ab1408c8>] entry_SYSCALL_64_after_hwframe+0x44/0xae Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit 087f6c68e2ba63d8fafec1249d55071a069eea69 Author: Alexander Aring Date: Wed Jun 2 09:45:15 2021 -0400 fs: dlm: fix lowcomms_start error case [ Upstream commit fcef0e6c27ce109d2c617aa12f0bfd9f7ff47d38 ] This patch fixes the error path handling in lowcomms_start(). We need to cleanup some static allocated data structure and cleanup possible workqueue if these have started. Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit 7f9887a1a9e92ab560b825125700d79de34b9180 Author: Jiapeng Chong Date: Tue May 25 18:58:41 2021 +0800 drivers: hv: Fix missing error code in vmbus_connect() [ Upstream commit 9de6655cc5a6a1febc514465c87c24a0e96d8dba ] Eliminate the follow smatch warning: drivers/hv/connection.c:236 vmbus_connect() warn: missing error code 'ret'. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong Reviewed-by: Michael Kelley Link: https://lore.kernel.org/r/1621940321-72353-1-git-send-email-jiapeng.chong@linux.alibaba.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 2b2a31cad66c129be093474969f860cc0e5553f1 Author: Christian Brauner Date: Fri May 28 11:24:16 2021 +0200 open: don't silently ignore unknown O-flags in openat2() [ Upstream commit cfe80306a0dd6d363934913e47c3f30d71b721e5 ] The new openat2() syscall verifies that no unknown O-flag values are set and returns an error to userspace if they are while the older open syscalls like open() and openat() simply ignore unknown flag values: #define O_FLAG_CURRENTLY_INVALID (1 << 31) struct open_how how = { .flags = O_RDONLY | O_FLAG_CURRENTLY_INVALID, .resolve = 0, }; /* fails */ fd = openat2(-EBADF, "/dev/null", &how, sizeof(how)); /* succeeds */ fd = openat(-EBADF, "/dev/null", O_RDONLY | O_FLAG_CURRENTLY_INVALID); However, openat2() silently truncates the upper 32 bits meaning: #define O_FLAG_CURRENTLY_INVALID_LOWER32 (1 << 31) #define O_FLAG_CURRENTLY_INVALID_UPPER32 (1 << 40) struct open_how how_lowe32 = { .flags = O_RDONLY | O_FLAG_CURRENTLY_INVALID_LOWER32, }; struct open_how how_upper32 = { .flags = O_RDONLY | O_FLAG_CURRENTLY_INVALID_UPPER32, }; /* fails */ fd = openat2(-EBADF, "/dev/null", &how_lower32, sizeof(how_lower32)); /* succeeds */ fd = openat2(-EBADF, "/dev/null", &how_upper32, sizeof(how_upper32)); Fix this by preventing the immediate truncation in build_open_flags(). There's a snafu here though stripping FMODE_* directly from flags would cause the upper 32 bits to be truncated as well due to integer promotion rules since FMODE_* is unsigned int, O_* are signed ints (yuck). In addition, struct open_flags currently defines flags to be 32 bit which is reasonable. If we simply were to bump it to 64 bit we would need to change a lot of code preemptively which doesn't seem worth it. So simply add a compile-time check verifying that all currently known O_* flags are within the 32 bit range and fail to build if they aren't anymore. This change shouldn't regress old open syscalls since they silently truncate any unknown values anyway. It is a tiny semantic change for openat2() but it is very unlikely people pass ing > 32 bit unknown flags and the syscall is relatively new too. Link: https://lore.kernel.org/r/20210528092417.3942079-3-brauner@kernel.org Cc: Christoph Hellwig Cc: Aleksa Sarai Cc: Al Viro Cc: linux-fsdevel@vger.kernel.org Reported-by: Richard Guy Briggs Reviewed-by: Christoph Hellwig Reviewed-by: Aleksa Sarai Reviewed-by: Richard Guy Briggs Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 02d6273ab9bedd8dbd1087080823b0fce9269399 Author: Richard Fitzgerald Date: Tue May 25 13:20:12 2021 +0100 random32: Fix implicit truncation warning in prandom_seed_state() [ Upstream commit d327ea15a305024ef0085252fa3657bbb1ce25f5 ] sparse generates the following warning: include/linux/prandom.h:114:45: sparse: sparse: cast truncates bits from constant value This is because the 64-bit seed value is manipulated and then placed in a u32, causing an implicit cast and truncation. A forced cast to u32 doesn't prevent this warning, which is reasonable because a typecast doesn't prove that truncation was expected. Logical-AND the value with 0xffffffff to make explicit that truncation to 32-bit is intended. Reported-by: kernel test robot Signed-off-by: Richard Fitzgerald Reviewed-by: Petr Mladek Signed-off-by: Petr Mladek Link: https://lore.kernel.org/r/20210525122012.6336-3-rf@opensource.cirrus.com Signed-off-by: Sasha Levin commit 871166f159b367c4ee5dc5e9b65493e7c448b738 Author: Alexander Aring Date: Fri May 21 15:08:39 2021 -0400 fs: dlm: fix connection tcp EOF handling [ Upstream commit 8aa31cbf20ad168c35dd83476629402aacbf5a44 ] This patch fixes the EOF handling for TCP that if and EOF is received we will close the socket next time the writequeue runs empty. This is a half-closed socket functionality which doesn't exists in SCTP. The midcomms layer will do a half closed socket functionality on DLM side to solve this problem for the SCTP case. However there is still the last ack flying around but other reset functionality will take care of it if it got lost. Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit 38ef63844ef4289e69b15a785cc062f7060271bd Author: Alexander Aring Date: Fri May 21 15:08:38 2021 -0400 fs: dlm: cancel work sync othercon [ Upstream commit c6aa00e3d20c2767ba3f57b64eb862572b9744b3 ] These rx tx flags arguments are for signaling close_connection() from which worker they are called. Obviously the receive worker cannot cancel itself and vice versa for swork. For the othercon the receive worker should only be used, however to avoid deadlocks we should pass the same flags as the original close_connection() was called. Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit 18e5651e39a5bd9db285a63f83b3f479a9094305 Author: Alexander Aring Date: Fri May 21 15:08:37 2021 -0400 fs: dlm: reconnect if socket error report occurs [ Upstream commit ba868d9deaab2bb1c09e50650127823925154802 ] This patch will change the reconnect handling that if an error occurs if a socket error callback is occurred. This will also handle reconnects in a non blocking connecting case which is currently missing. If error ECONNREFUSED is reported we delay the reconnect by one second. Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit 7ae861bbfa0f69bd36bdff47f9755ad67a2bd219 Author: Alexander Aring Date: Fri May 21 15:08:35 2021 -0400 fs: dlm: fix srcu read lock usage [ Upstream commit b38bc9c2b3171f4411d80015ecb876bc6f9bcd26 ] This patch holds the srcu connection read lock in cases where we lookup the connections and accessing it. We don't hold the srcu lock in workers function where the scheduled worker is part of the connection itself. The connection should not be freed if any worker is scheduled or pending. Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit b407bf68af325786b5f572a5e38d51206914f91b Author: Ming Lei Date: Tue May 11 23:22:35 2021 +0800 blk-mq: clear stale request in tags->rq[] before freeing one request pool [ Upstream commit bd63141d585bef14f4caf111f6d0e27fe2300ec6 ] refcount_inc_not_zero() in bt_tags_iter() still may read one freed request. Fix the issue by the following approach: 1) hold a per-tags spinlock when reading ->rqs[tag] and calling refcount_inc_not_zero in bt_tags_iter() 2) clearing stale request referred via ->rqs[tag] before freeing request pool, the per-tags spinlock is held for clearing stale ->rq[tag] So after we cleared stale requests, bt_tags_iter() won't observe freed request any more, also the clearing will wait for pending request reference. The idea of clearing ->rqs[] is borrowed from John Garry's previous patch and one recent David's patch. Tested-by: John Garry Reviewed-by: David Jeffery Reviewed-by: Bart Van Assche Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20210511152236.763464-4-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 0c0e6cd55d8762c8faaa7bd007905fffcc04c311 Author: Ming Lei Date: Tue May 11 23:22:34 2021 +0800 blk-mq: grab rq->refcount before calling ->fn in blk_mq_tagset_busy_iter [ Upstream commit 2e315dc07df009c3e29d6926871f62a30cfae394 ] Grab rq->refcount before calling ->fn in blk_mq_tagset_busy_iter(), and this way will prevent the request from being re-used when ->fn is running. The approach is same as what we do during handling timeout. Fix request use-after-free(UAF) related with completion race or queue releasing: - If one rq is referred before rq->q is frozen, then queue won't be frozen before the request is released during iteration. - If one rq is referred after rq->q is frozen, refcount_inc_not_zero() will return false, and we won't iterate over this request. However, still one request UAF not covered: refcount_inc_not_zero() may read one freed request, and it will be handled in next patch. Tested-by: John Garry Reviewed-by: Christoph Hellwig Reviewed-by: Bart Van Assche Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20210511152236.763464-3-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b3ed6b4e39f2023775c7e6db57c71b53245432fb Author: zhangyi (F) Date: Sat Mar 13 11:01:44 2021 +0800 block_dump: remove block_dump feature in mark_inode_dirty() [ Upstream commit 12e0613715e1cf305fffafaf0e89d810d9a85cc0 ] block_dump is an old debugging interface, one of it's functions is used to print the information about who write which file on disk. If we enable block_dump through /proc/sys/vm/block_dump and turn on debug log level, we can gather information about write process name, target file name and disk from kernel message. This feature is realized in block_dump___mark_inode_dirty(), it print above information into kernel message directly when marking inode dirty, so it is noisy and can easily trigger log storm. At the same time, get the dentry refcount is also not safe, we found it will lead to deadlock on ext4 file system with data=journal mode. After tracepoints has been introduced into the kernel, we got a tracepoint in __mark_inode_dirty(), which is a better replacement of block_dump___mark_inode_dirty(). The only downside is that it only trace the inode number and not a file name, but it probably doesn't matter because the original printed file name in block_dump is not accurate in some cases, and we can still find it through the inode number and device id. So this patch delete the dirting inode part of block_dump feature. Signed-off-by: zhangyi (F) Reviewed-by: Jan Kara Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20210313030146.2882027-2-yi.zhang@huawei.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 5c2e42a7ff69c42a24c57955a7b3ccd9bf4b069b Author: Chris Chiu Date: Thu May 20 11:09:50 2021 +0800 ACPI: EC: Make more Asus laptops use ECDT _GPE [ Upstream commit 6306f0431914beaf220634ad36c08234006571d5 ] More ASUS laptops have the _GPE define in the DSDT table with a different value than the _GPE number in the ECDT. This is causing media keys not working on ASUS X505BA/BP, X542BA/BP Add model info to the quirks list. Signed-off-by: Chris Chiu Signed-off-by: Jian-Hong Pan Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 6e288c3f4b6a12f4c65647d524cb4c25660ef31d Author: Hans de Goede Date: Tue May 4 20:57:45 2021 +0200 platform/x86: touchscreen_dmi: Add info for the Goodix GT912 panel of TM800A550L tablets [ Upstream commit fcd8cf0e3e48f4c66af82c8e799c37cb0cccffe0 ] The Bay Trail Glavey TM800A550L tablet, which ships with Android installed from the factory, uses a GT912 touchscreen controller which needs to have its firmware uploaded by the OS to work (this is a first for a x86 based device with a Goodix touchscreen controller). Add a touchscreen_dmi entry for this which specifies the filenames to use for the firmware and config files needed for this. Note this matches on a GDIX1001 ACPI HID, while the original DSDT uses a HID of GODX0911. For the touchscreen to work on these devices a DSDT override is necessary to fix a missing IRQ and broken GPIO settings in the ACPI-resources for the touchscreen. This override also changes the HID to the standard GDIX1001 id typically used for Goodix touchscreens. The DSDT override is available here: https://fedorapeople.org/~jwrdegoede/glavey-tm800a550l-dsdt-override/ Reviewed-by: Bastien Nocera Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210504185746.175461-5-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 978dd194fd4af8394e597fe6ac62b7f764ea70a6 Author: Hans de Goede Date: Tue May 4 20:57:44 2021 +0200 platform/x86: touchscreen_dmi: Add an extra entry for the upside down Goodix touchscreen on Teclast X89 tablets [ Upstream commit a22e3803f2a4d947ff0083a9448a169269ea0f62 ] Teclast X89 tablets come in 2 versions, with Windows pre-installed and with Android pre-installed. These 2 versions have different DMI strings. Add a match for the DMI strings used by the Android version BIOS. Note the Android version BIOS has a bug in the DSDT where no IRQ is provided, so for the touchscreen to work a DSDT override fixing this is necessary as well. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210504185746.175461-4-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 2f09dc35f8d6db2a3fe731740d7cca977b398fef Author: Hans de Goede Date: Tue May 4 20:57:42 2021 +0200 Input: goodix - platform/x86: touchscreen_dmi - Move upside down quirks to touchscreen_dmi.c [ Upstream commit 5a6f0dbe621a5c20dc912ac474debf9f11129e03 ] Move the DMI quirks for upside-down mounted Goodix touchscreens from drivers/input/touchscreen/goodix.c to drivers/platform/x86/touchscreen_dmi.c, where all the other x86 touchscreen quirks live. Note the touchscreen_dmi.c code attaches standard touchscreen device-properties to an i2c-client device based on a combination of a DMI match + a device-name match. I've verified that the: Teclast X98 Pro, WinBook TW100 and WinBook TW700 uses an ACPI devicename of "GDIX1001:00" based on acpidumps and/or dmesg output available on the web. This patch was tested on a Teclast X89 tablet. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210504185746.175461-2-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 69476379eb453a0423408bd25d62bbb29ba72a69 Author: Richard Fitzgerald Date: Fri May 14 17:12:04 2021 +0100 lib: vsprintf: Fix handling of number field widths in vsscanf [ Upstream commit 900fdc4573766dd43b847b4f54bd4a1ee2bc7360 ] The existing code attempted to handle numbers by doing a strto[u]l(), ignoring the field width, and then repeatedly dividing to extract the field out of the full converted value. If the string contains a run of valid digits longer than will fit in a long or long long, this would overflow and no amount of dividing can recover the correct value. This patch fixes vsscanf() to obey number field widths when parsing the number. A new _parse_integer_limit() is added that takes a limit for the number of characters to parse. The number field conversion in vsscanf is changed to use this new function. If a number starts with a radix prefix, the field width must be long enough for at last one digit after the prefix. If not, it will be handled like this: sscanf("0x4", "%1i", &i): i=0, scanning continues with the 'x' sscanf("0x4", "%2i", &i): i=0, scanning continues with the '4' This is consistent with the observed behaviour of userland sscanf. Note that this patch does NOT fix the problem of a single field value overflowing the target type. So for example: sscanf("123456789abcdef", "%x", &i); Will not produce the correct result because the value obviously overflows INT_MAX. But sscanf will report a successful conversion. Note that where a very large number is used to mean "unlimited", the value INT_MAX is used for consistency with the behaviour of vsnprintf(). Signed-off-by: Richard Fitzgerald Reviewed-by: Petr Mladek Signed-off-by: Petr Mladek Link: https://lore.kernel.org/r/20210514161206.30821-2-rf@opensource.cirrus.com Signed-off-by: Sasha Levin commit 782da090933cfa83d809f743377ad522e272ac97 Author: YueHaibing Date: Fri May 14 15:01:16 2021 +0800 hv_utils: Fix passing zero to 'PTR_ERR' warning [ Upstream commit c6a8625fa4c6b0a97860d053271660ccedc3d1b3 ] Sparse warn this: drivers/hv/hv_util.c:753 hv_timesync_init() warn: passing zero to 'PTR_ERR' Use PTR_ERR_OR_ZERO instead of PTR_ERR to fix this. Signed-off-by: YueHaibing Link: https://lore.kernel.org/r/20210514070116.16800-1-yuehaibing@huawei.com [ wei: change %ld to %d ] Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 9e86d9c12351117b30ebaa7685eccfeddbcc9c24 Author: Mario Limonciello Date: Wed May 12 17:15:14 2021 -0500 ACPI: processor idle: Fix up C-state latency if not ordered [ Upstream commit 65ea8f2c6e230bdf71fed0137cf9e9d1b307db32 ] Generally, the C-state latency is provided by the _CST method or FADT, but some OEM platforms using AMD Picasso, Renoir, Van Gogh, and Cezanne set the C2 latency greater than C3's which causes the C2 state to be skipped. That will block the core entering PC6, which prevents S0ix working properly on Linux systems. In other operating systems, the latency values are not validated and this does not cause problems by skipping states. To avoid this issue on Linux, detect when latencies are not an arithmetic progression and sort them. Link: https://gitlab.freedesktop.org/agd5f/linux/-/commit/026d186e4592c1ee9c1cb44295912d0294508725 Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1230#note_712174 Suggested-by: Prike Liang Suggested-by: Alex Deucher Signed-off-by: Mario Limonciello [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 93545e3b7fe98ca2611b437f131488b17fe4e243 Author: Rafael J. Wysocki Date: Mon May 10 19:53:18 2021 +0200 ACPI: scan: Rearrange dep_unmet initialization [ Upstream commit 6d27975851b134be8d2a170437210c9719e524aa ] The dep_unmet field in struct acpi_device is used to store the number of unresolved _DEP dependencies (that is, operation region dependencies for which there are no drivers present) for the ACPI device object represented by it. That field is initialized to 1 for all ACPI device objects in acpi_add_single_object(), via acpi_init_device_object(), so as to avoid evaluating _STA prematurely for battery device objects in acpi_scan_init_status(), and it is "fixed up" in acpi_bus_check_add() after the acpi_add_single_object() called by it has returned. This is not particularly straightforward and causes dep_unmet to remain 1 for device objects without dependencies created by invoking acpi_add_single_object() directly, outside acpi_bus_check_add(). For this reason, rearrange acpi_add_single_object() to initialize dep_unmet completely before calling acpi_scan_init_status(), which requires passing one extra bool argument to it, and update all of its callers accordingly. Signed-off-by: Rafael J. Wysocki Reviewed-by: Hans de Goede Signed-off-by: Sasha Levin commit f5512b405739dae869f06943d310c15ecd5833e9 Author: Alex Deucher Date: Wed May 5 09:20:32 2021 -0400 ACPI: PM: s2idle: Add missing LPS0 functions for AMD [ Upstream commit f59a905b962c34642e862b5edec35c0eda72d70d ] These are supposedly not required for AMD platforms, but at least some HP laptops seem to require it to properly turn off the keyboard backlight. Based on a patch from Marcin Bachry . Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1230 Reviewed-by: Hans de Goede Signed-off-by: Alex Deucher Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 4b0f6a85a59af73f2e1189f947d2697c8b132c67 Author: Bixuan Cui Date: Wed May 12 11:37:27 2021 +0800 EDAC/ti: Add missing MODULE_DEVICE_TABLE [ Upstream commit 0a37f32ba5272b2d4ec8c8d0f6b212b81b578f7e ] The module misses MODULE_DEVICE_TABLE() for of_device_id tables and thus never autoloads on ID matches. Add the missing declaration. Reported-by: Hulk Robot Signed-off-by: Bixuan Cui Signed-off-by: Borislav Petkov Cc: Tero Kristo Link: https://lkml.kernel.org/r/20210512033727.26701-1-cuibixuan@huawei.com Signed-off-by: Sasha Levin commit 892ca2b2ff3a10f87250617accd2f60f3dc58e04 Author: Dmitry Torokhov Date: Fri Mar 19 17:27:16 2021 -0700 HID: do not use down_interruptible() when unbinding devices [ Upstream commit f2145f8dc566c4f3b5a8deb58dcd12bed4e20194 ] Action of unbinding driver from a device is not cancellable and should not fail, and driver core does not pay attention to the result of "remove" method, therefore using down_interruptible() in hid_device_remove() does not make sense. Signed-off-by: Dmitry Torokhov Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 31a5fc473d74d943438a03f83f519aac8d65ebe3 Author: Rodrigo Campos Date: Mon May 17 12:39:07 2021 -0700 seccomp: Support atomic "addfd + send reply" [ Upstream commit 0ae71c7720e3ae3aabd2e8a072d27f7bd173d25c ] Alban Crequy reported a race condition userspace faces when we want to add some fds and make the syscall return them[1] using seccomp notify. The problem is that currently two different ioctl() calls are needed by the process handling the syscalls (agent) for another userspace process (target): SECCOMP_IOCTL_NOTIF_ADDFD to allocate the fd and SECCOMP_IOCTL_NOTIF_SEND to return that value. Therefore, it is possible for the agent to do the first ioctl to add a file descriptor but the target is interrupted (EINTR) before the agent does the second ioctl() call. This patch adds a flag to the ADDFD ioctl() so it adds the fd and returns that value atomically to the target program, as suggested by Kees Cook[2]. This is done by simply allowing seccomp_do_user_notification() to add the fd and return it in this case. Therefore, in this case the target wakes up from the wait in seccomp_do_user_notification() either to interrupt the syscall or to add the fd and return it. This "allocate an fd and return" functionality is useful for syscalls that return a file descriptor only, like connect(2). Other syscalls that return a file descriptor but not as return value (or return more than one fd), like socketpair(), pipe(), recvmsg with SCM_RIGHTs, will not work with this flag. This effectively combines SECCOMP_IOCTL_NOTIF_ADDFD and SECCOMP_IOCTL_NOTIF_SEND into an atomic opteration. The notification's return value, nor error can be set by the user. Upon successful invocation of the SECCOMP_IOCTL_NOTIF_ADDFD ioctl with the SECCOMP_ADDFD_FLAG_SEND flag, the notifying process's errno will be 0, and the return value will be the file descriptor number that was installed. [1]: https://lore.kernel.org/lkml/CADZs7q4sw71iNHmV8EOOXhUKJMORPzF7thraxZYddTZsxta-KQ@mail.gmail.com/ [2]: https://lore.kernel.org/lkml/202012011322.26DCBC64F2@keescook/ Signed-off-by: Rodrigo Campos Signed-off-by: Sargun Dhillon Acked-by: Tycho Andersen Acked-by: Christian Brauner Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20210517193908.3113-4-sargun@sargun.me Signed-off-by: Sasha Levin commit 95dafa3beb9420cd848f0a2e57ee71a4088e7702 Author: Shuah Khan Date: Wed Jun 16 17:19:06 2021 +0200 media: Fix Media Controller API config checks [ Upstream commit 50e7a31d30e8221632675abed3be306382324ca2 ] Smatch static checker warns that "mdev" can be null: sound/usb/media.c:287 snd_media_device_create() warn: 'mdev' can also be NULL If CONFIG_MEDIA_CONTROLLER is disabled, this file should not be included in the build. The below conditions in the sound/usb/Makefile are in place to ensure that media.c isn't included in the build. sound/usb/Makefile: snd-usb-audio-$(CONFIG_SND_USB_AUDIO_USE_MEDIA_CONTROLLER) += media.o select SND_USB_AUDIO_USE_MEDIA_CONTROLLER if MEDIA_CONTROLLER && (MEDIA_SUPPORT=y || MEDIA_SUPPORT=SND_USB_AUDIO) The following config check in include/media/media-dev-allocator.h is in place to enable the API only when CONFIG_MEDIA_CONTROLLER and CONFIG_USB are enabled. #if defined(CONFIG_MEDIA_CONTROLLER) && defined(CONFIG_USB) This check doesn't work as intended when CONFIG_USB=m. When CONFIG_USB=m, CONFIG_USB_MODULE is defined and CONFIG_USB is not. The above config check doesn't catch that CONFIG_USB is defined as a module and disables the API. This results in sound/usb enabling Media Controller specific ALSA driver code, while Media disables the Media Controller API. Fix the problem requires two changes: 1. Change the check to use IS_ENABLED to detect when CONFIG_USB is enabled as a module or static. Since CONFIG_MEDIA_CONTROLLER is a bool, leave the check unchanged to be consistent with drivers/media/Makefile. 2. Change the drivers/media/mc/Makefile to include mc-dev-allocator.o in mc-objs when CONFIG_USB is enabled. Link: https://lore.kernel.org/alsa-devel/YLeAvT+R22FQ%2FEyw@mwanda/ Reported-by: Dan Carpenter Signed-off-by: Shuah Khan Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 57013d106790cfee3a462a85057238929c6c0043 Author: Axel Lin Date: Fri Jun 18 22:14:11 2021 +0800 regulator: da9052: Ensure enough delay time for .set_voltage_time_sel [ Upstream commit a336dc8f683e5be794186b5643cd34cb28dd2c53 ] Use DIV_ROUND_UP to prevent truncation by integer division issue. This ensures we return enough delay time. Also fix returning negative value when new_sel < old_sel. Signed-off-by: Axel Lin Link: https://lore.kernel.org/r/20210618141412.4014912-1-axel.lin@ingics.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6130d2ec297e8b9d04e3e30565e3bfab619b2610 Author: Hsin-Hsiung Wang Date: Wed Jun 23 12:56:09 2021 +0800 regulator: mt6358: Fix vdram2 .vsel_mask [ Upstream commit 50c9462edcbf900f3d5097ca3ad60171346124de ] The valid vsel value are 0 and 12, so the .vsel_mask should be 0xf. Signed-off-by: Hsin-Hsiung Wang Reviewed-by: Axel Lin Link: https://lore.kernel.org/r/1624424169-510-1-git-send-email-hsin-hsiung.wang@mediatek.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 72c4df2e3c064f72e2d7e59826f2ce96178064d4 Author: Heiko Carstens Date: Mon Jun 21 16:03:56 2021 +0200 KVM: s390: get rid of register asm usage [ Upstream commit 4fa3b91bdee1b08348c82660668ca0ca34e271ad ] Using register asm statements has been proven to be very error prone, especially when using code instrumentation where gcc may add function calls, which clobbers register contents in an unexpected way. Therefore get rid of register asm statements in kvm code, even though there is currently nothing wrong with them. This way we know for sure that this bug class won't be introduced here. Signed-off-by: Heiko Carstens Reviewed-by: Christian Borntraeger Reviewed-by: Thomas Huth Reviewed-by: Cornelia Huck Reviewed-by: Claudio Imbrenda Link: https://lore.kernel.org/r/20210621140356.1210771-1-hca@linux.ibm.com [borntraeger@de.ibm.com: checkpatch strict fix] Signed-off-by: Christian Borntraeger Signed-off-by: Sasha Levin commit 51653ce7417479885f30f793fdfce98b77227e3b Author: Boqun Feng Date: Sat Jun 19 01:01:09 2021 +0800 lockding/lockdep: Avoid to find wrong lock dep path in check_irq_usage() [ Upstream commit 7b1f8c6179769af6ffa055e1169610b51d71edd5 ] In the step #3 of check_irq_usage(), we seach backwards to find a lock whose usage conflicts the usage of @target_entry1 on safe/unsafe. However, we should only keep the irq-unsafe usage of @target_entry1 into consideration, because it could be a case where a lock is hardirq-unsafe but soft-safe, and in check_irq_usage() we find it because its hardirq-unsafe could result into a hardirq-safe-unsafe deadlock, but currently since we don't filter out the other usage bits, so we may find a lock dependency path softirq-unsafe -> softirq-safe, which in fact doesn't cause a deadlock. And this may cause misleading lockdep splats. Fix this by only keeping LOCKF_ENABLED_IRQ_ALL bits when we try the backwards search. Reported-by: Johannes Berg Signed-off-by: Boqun Feng Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20210618170110.3699115-4-boqun.feng@gmail.com Signed-off-by: Sasha Levin commit 6f0a350c26675b16c5c9b5327101d942b63201c6 Author: Boqun Feng Date: Sat Jun 19 01:01:07 2021 +0800 locking/lockdep: Fix the dep path printing for backwards BFS [ Upstream commit 69c7a5fb2482636f525f016c8333fdb9111ecb9d ] We use the same code to print backwards lock dependency path as the forwards lock dependency path, and this could result into incorrect printing because for a backwards lock_list ->trace is not the call trace where the lock of ->class is acquired. Fix this by introducing a separate function on printing the backwards dependency path. Also add a few comments about the printing while we are at it. Reported-by: Johannes Berg Signed-off-by: Boqun Feng Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20210618170110.3699115-2-boqun.feng@gmail.com Signed-off-by: Sasha Levin commit da5a7fbfc5ca24f332ef2730da01614e295c8efb Author: Christophe Leroy Date: Thu Jun 10 05:23:02 2021 +0000 btrfs: disable build on platforms having page size 256K [ Upstream commit b05fbcc36be1f8597a1febef4892053a0b2f3f60 ] With a config having PAGE_SIZE set to 256K, BTRFS build fails with the following message include/linux/compiler_types.h:326:38: error: call to '__compiletime_assert_791' declared with attribute error: BUILD_BUG_ON failed: (BTRFS_MAX_COMPRESSED % PAGE_SIZE) != 0 BTRFS_MAX_COMPRESSED being 128K, BTRFS cannot support platforms with 256K pages at the time being. There are two platforms that can select 256K pages: - hexagon - powerpc Disable BTRFS when 256K page size is selected. Supporting this would require changes to the subpage mode that's currently being developed. Given that 256K is many times larger than page sizes commonly used and for what the algorithms and structures have been tuned, it's out of scope and disabling build is a reasonable option. Reported-by: kernel test robot Signed-off-by: Christophe Leroy [ update changelog ] Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 23f3aff83a250d6067fca549699c72ef134efef8 Author: Qu Wenruo Date: Mon May 31 16:50:55 2021 +0800 btrfs: don't clear page extent mapped if we're not invalidating the full page [ Upstream commit bcd77455d590eaa0422a5e84ae852007cfce574a ] [BUG] With current btrfs subpage rw support, the following script can lead to fs hang: $ mkfs.btrfs -f -s 4k $dev $ mount $dev -o nospace_cache $mnt $ fsstress -w -n 100 -p 1 -s 1608140256 -v -d $mnt The fs will hang at btrfs_start_ordered_extent(). [CAUSE] In above test case, btrfs_invalidate() will be called with the following parameters: offset = 0 length = 53248 page dirty = 1 subpage dirty bitmap = 0x2000 Since @offset is 0, btrfs_invalidate() will try to invalidate the full page, and finally call clear_page_extent_mapped() which will detach subpage structure from the page. And since the page no longer has subpage structure, the subpage dirty bitmap will be cleared, preventing the dirty range from being written back, thus no way to wake up the ordered extent. [FIX] Just follow other filesystems, only to invalidate the page if the range covers the full page. There are cases like truncate_setsize() which can call btrfs_invalidatepage() with offset == 0 and length != 0 for the last page of an inode. Although the old code will still try to invalidate the full page, we are still safe to just wait for ordered extent to finish. So it shouldn't cause extra problems. Tested-by: Ritesh Harjani # [ppc64] Tested-by: Anand Jain # [aarch64] Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 77848dc0cf94765a2ad25e064ac2ad5fdafc47ad Author: David Sterba Date: Fri May 7 20:00:14 2021 +0200 btrfs: sysfs: fix format string for some discard stats [ Upstream commit 8c5ec995616f1202ab92e195fd75d6f60d86f85c ] The type of discard_bitmap_bytes and discard_extent_bytes is u64 so the format should be %llu, though the actual values would hardly ever overflow to negative values. Reviewed-by: Qu Wenruo Reviewed-by: Anand Jain Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 5f10bddef823677c8d09c4ffd9db38bae8f39902 Author: Josef Bacik Date: Thu May 20 11:21:31 2021 -0400 btrfs: always abort the transaction if we abort a trans handle [ Upstream commit 5963ffcaf383134985a5a2d8a4baa582d3999e0a ] While stress testing our error handling I noticed that sometimes we would still commit the transaction even though we had aborted the transaction. Currently we track if a trans handle has dirtied any metadata, and if it hasn't we mark the filesystem as having an error (so no new transactions can be started), but we will allow the current transaction to complete as we do not mark the transaction itself as having been aborted. This sounds good in theory, but we were not properly tracking IO errors in btrfs_finish_ordered_io, and thus committing the transaction with bogus free space data. This isn't necessarily a problem per-se with the free space cache, as the other guards in place would have kept us from accepting the free space cache as valid, but highlights a real world case where we had a bug and could have corrupted the filesystem because of it. This "skip abort on empty trans handle" is nice in theory, but assumes we have perfect error handling everywhere, which we clearly do not. Also we do not allow further transactions to be started, so all this does is save the last transaction that was happening, which doesn't necessarily gain us anything other than the potential for real corruption. Remove this particular bit of code, if we decide we need to abort the transaction then abort the current one and keep us from doing real harm to the file system, regardless of whether this specific trans handle dirtied anything or not. Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 0f9a0de7baa153b8bae2196c34c19cfb5de0eff1 Author: Josef Bacik Date: Fri May 21 16:44:09 2021 -0400 btrfs: abort transaction if we fail to update the delayed inode [ Upstream commit 04587ad9bef6ce9d510325b4ba9852b6129eebdb ] If we fail to update the delayed inode we need to abort the transaction, because we could leave an inode with the improper counts or some other such corruption behind. Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 24c08d4b6f9027ebb0f3d565d8d160d7e28c3881 Author: Josef Bacik Date: Fri May 21 16:44:08 2021 -0400 btrfs: fix error handling in __btrfs_update_delayed_inode [ Upstream commit bb385bedded3ccbd794559600de4a09448810f4a ] If we get an error while looking up the inode item we'll simply bail without cleaning up the delayed node. This results in this style of warning happening on commit: WARNING: CPU: 0 PID: 76403 at fs/btrfs/delayed-inode.c:1365 btrfs_assert_delayed_root_empty+0x5b/0x90 CPU: 0 PID: 76403 Comm: fsstress Tainted: G W 5.13.0-rc1+ #373 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 RIP: 0010:btrfs_assert_delayed_root_empty+0x5b/0x90 RSP: 0018:ffffb8bb815a7e50 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff95d6d07e1888 RCX: ffff95d6c0fa3000 RDX: 0000000000000002 RSI: 000000000029e91c RDI: ffff95d6c0fc8060 RBP: ffff95d6c0fc8060 R08: 00008d6d701a2c1d R09: 0000000000000000 R10: ffff95d6d1760ea0 R11: 0000000000000001 R12: ffff95d6c15a4d00 R13: ffff95d6c0fa3000 R14: 0000000000000000 R15: ffffb8bb815a7e90 FS: 00007f490e8dbb80(0000) GS:ffff95d73bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6e75555cb0 CR3: 00000001101ce001 CR4: 0000000000370ef0 Call Trace: btrfs_commit_transaction+0x43c/0xb00 ? finish_wait+0x80/0x80 ? vfs_fsync_range+0x90/0x90 iterate_supers+0x8c/0x100 ksys_sync+0x50/0x90 __do_sys_sync+0xa/0x10 do_syscall_64+0x3d/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae Because the iref isn't dropped and this leaves an elevated node->count, so any release just re-queues it onto the delayed inodes list. Fix this by going to the out label to handle the proper cleanup of the delayed node. Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 3c9cb03aa19f51d4d0f9c59e3ced86080faeaa24 Author: Suraj Jitindar Singh Date: Wed Jun 2 14:04:41 2021 +1000 KVM: PPC: Book3S HV: Fix TLB management on SMT8 POWER9 and POWER10 processors [ Upstream commit 77bbbc0cf84834ed130838f7ac1988567f4d0288 ] The POWER9 vCPU TLB management code assumes all threads in a core share a TLB, and that TLBIEL execued by one thread will invalidate TLBs for all threads. This is not the case for SMT8 capable POWER9 and POWER10 (big core) processors, where the TLB is split between groups of threads. This results in TLB multi-hits, random data corruption, etc. Fix this by introducing cpu_first_tlb_thread_sibling etc., to determine which siblings share TLBs, and use that in the guest TLB flushing code. [npiggin@gmail.com: add changelog and comment] Signed-off-by: Paul Mackerras Signed-off-by: Nicholas Piggin Reviewed-by: Fabiano Rosas Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210602040441.3984352-1-npiggin@gmail.com Signed-off-by: Sasha Levin commit f5822ae7d660766ccdd3addd8efb5e56c9a7ae81 Author: Marc Zyngier Date: Thu Jun 3 16:50:02 2021 +0100 KVM: arm64: Restore PMU configuration on first run [ Upstream commit d0c94c49792cf780cbfefe29f81bb8c3b73bc76b ] Restoring a guest with an active virtual PMU results in no perf counters being instanciated on the host side. Not quite what you'd expect from a restore. In order to fix this, force a writeback of PMCR_EL0 on the first run of a vcpu (using a new request so that it happens once the vcpu has been loaded). This will in turn create all the host-side counters that were missing. Reported-by: Jinank Jain Tested-by: Jinank Jain Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/87wnrbylxv.wl-maz@kernel.org Link: https://lore.kernel.org/r/b53dfcf9bbc4db7f96154b1cd5188d72b9766358.camel@amazon.de Signed-off-by: Sasha Levin commit 60c54321c8221d706fa668feb538d6912cd03c20 Author: Jing Xiangfeng Date: Thu Jun 17 20:26:14 2021 +0800 drivers/perf: fix the missed ida_simple_remove() in ddr_perf_probe() [ Upstream commit d96b1b8c9f79b6bb234a31c80972a6f422079376 ] ddr_perf_probe() misses to call ida_simple_remove() in an error path. Jump to cpuhp_state_err to fix it. Signed-off-by: Jing Xiangfeng Reviewed-by: Dong Aisheng Link: https://lore.kernel.org/r/20210617122614.166823-1-jingxiangfeng@huawei.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 2c95ccb350be9ee8d8f84e05dd8d9b24b2681907 Author: Kan Liang Date: Mon Jun 14 10:59:42 2021 -0700 perf/x86: Reset the dirty counter to prevent the leak for an RDPMC task [ Upstream commit 5471eea5d3bf850316f1064a6f57b34c444bce67 ] The counter value of a perf task may leak to another RDPMC task. For example, a perf stat task as below is running on CPU 0. perf stat -e 'branches,cycles' -- taskset -c 0 ./workload In the meantime, an RDPMC task, which is also running on CPU 0, may read the GP counters periodically. (The RDPMC task creates a fixed event, but read four GP counters.) $./rdpmc_read_all_counters index 0x0 value 0x8001e5970f99 index 0x1 value 0x8005d750edb6 index 0x2 value 0x0 index 0x3 value 0x0 index 0x0 value 0x8002358e48a5 index 0x1 value 0x8006bd1e3bc9 index 0x2 value 0x0 index 0x3 value 0x0 It is a potential security issue. Once the attacker knows what the other thread is counting. The PerfMon counter can be used as a side-channel to attack cryptosystems. The counter value of the perf stat task leaks to the RDPMC task because perf never clears the counter when it's stopped. Three methods were considered to address the issue. - Unconditionally reset the counter in x86_pmu_del(). It can bring extra overhead even when there is no RDPMC task running. - Only reset the un-assigned dirty counters when the RDPMC task is scheduled in via sched_task(). It fails for the below case. Thread A Thread B clone(CLONE_THREAD) ---> set_affine(0) set_affine(1) while (!event-enabled) ; event = perf_event_open() mmap(event) ioctl(event, IOC_ENABLE); ---> RDPMC Counters are still leaked to the thread B. - Only reset the un-assigned dirty counters before updating the CR4.PCE bit. The method is implemented here. The dirty counter is a counter, on which the assigned event has been deleted, but the counter is not reset. To track the dirty counters, add a 'dirty' variable in the struct cpu_hw_events. The security issue can only be found with an RDPMC task. To enable the RDMPC, the CR4.PCE bit has to be updated. Add a perf_clear_dirty_counters() right before updating the CR4.PCE bit to clear the existing dirty counters. Only the current un-assigned dirty counters are reset, because the RDPMC assigned dirty counters will be updated soon. After applying the patch, $ ./rdpmc_read_all_counters index 0x0 value 0x0 index 0x1 value 0x0 index 0x2 value 0x0 index 0x3 value 0x0 index 0x0 value 0x0 index 0x1 value 0x0 index 0x2 value 0x0 index 0x3 value 0x0 Performance The performance of a context switch only be impacted when there are two or more perf users and one of the users must be an RDPMC user. In other cases, there is no performance impact. The worst-case occurs when there are two users: the RDPMC user only uses one counter; while the other user uses all available counters. When the RDPMC task is scheduled in, all the counters, other than the RDPMC assigned one, have to be reset. Test results for the worst-case, using a modified lat_ctx as measured on an Ice Lake platform, which has 8 GP and 3 FP counters (ignoring SLOTS). lat_ctx -s 128K -N 1000 processes 2 Without the patch: The context switch time is 4.97 us With the patch: The context switch time is 5.16 us There is ~4% performance drop for the context switching time in the worst-case. Suggested-by: Peter Zijlstra (Intel) Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/1623693582-187370-1-git-send-email-kan.liang@linux.intel.com Signed-off-by: Sasha Levin commit 4c305975c29a83839d2ed55717fdcaade3b1558c Author: Lukasz Luba Date: Mon Jun 14 20:11:28 2021 +0100 sched/fair: Take thermal pressure into account while estimating energy [ Upstream commit 489f16459e0008c7a5c4c5af34bd80898aa82c2d ] Energy Aware Scheduling (EAS) needs to be able to predict the frequency requests made by the SchedUtil governor to properly estimate energy used in the future. It has to take into account CPUs utilization and forecast Performance Domain (PD) frequency. There is a corner case when the max allowed frequency might be reduced due to thermal. SchedUtil is aware of that reduced frequency, so it should be taken into account also in EAS estimations. SchedUtil, as a CPUFreq governor, knows the maximum allowed frequency of a CPU, thanks to cpufreq_driver_resolve_freq() and internal clamping to 'policy::max'. SchedUtil is responsible to respect that upper limit while setting the frequency through CPUFreq drivers. This effective frequency is stored internally in 'sugov_policy::next_freq' and EAS has to predict that value. In the existing code the raw value of arch_scale_cpu_capacity() is used for clamping the returned CPU utilization from effective_cpu_util(). This patch fixes issue with too big single CPU utilization, by introducing clamping to the allowed CPU capacity. The allowed CPU capacity is a CPU capacity reduced by thermal pressure raw value. Thanks to knowledge about allowed CPU capacity, we don't get too big value for a single CPU utilization, which is then added to the util sum. The util sum is used as a source of information for estimating whole PD energy. To avoid wrong energy estimation in EAS (due to capped frequency), make sure that the calculation of util sum is aware of allowed CPU capacity. This thermal pressure might be visible in scenarios where the CPUs are not heavily loaded, but some other component (like GPU) drastically reduced available power budget and increased the SoC temperature. Thus, we still use EAS for task placement and CPUs are not over-utilized. Signed-off-by: Lukasz Luba Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Vincent Guittot Reviewed-by: Dietmar Eggemann Link: https://lore.kernel.org/r/20210614191128.22735-1-lukasz.luba@arm.com Signed-off-by: Sasha Levin commit d5d76329a97c06b3950849e5fbdcb13461066e29 Author: Guenter Roeck Date: Wed May 26 08:40:18 2021 -0700 hwmon: (max31790) Fix pwmX_enable attributes [ Upstream commit 148c847c9e5a54b99850617bf9c143af9a344f92 ] pwmX_enable supports three possible values: 0: Fan control disabled. Duty cycle is fixed to 0% 1: Fan control enabled, pwm mode. Duty cycle is determined by values written into Target Duty Cycle registers. 2: Fan control enabled, rpm mode Duty cycle is adjusted such that fan speed matches the values in Target Count registers The current code does not do this; instead, it mixes pwm control configuration with fan speed monitoring configuration. Worse, it reports that pwm control would be disabled (pwmX_enable==0) when it is in fact enabled in pwm mode. Part of the problem may be that the chip sets the "TACH input enable" bit on its own whenever the mode bit is set to RPM mode, but that doesn't mean that "TACH input enable" accurately reflects the pwm mode. Fix it up and only handle pwm control with the pwmX_enable attributes. In the documentation, clarify that disabling pwm control (pwmX_enable=0) sets the pwm duty cycle to 0%. In the code, explain why TACH_INPUT_EN is set together with RPM_MODE. While at it, only update the configuration register if the configuration has changed, and only update the cached configuration if updating the chip configuration was successful. Cc: Jan Kundrát Cc: Václav Kubernát Signed-off-by: Guenter Roeck Tested-by: Václav Kubernát Reviewed-by: Jan Kundrát Link: https://lore.kernel.org/r/20210526154022.3223012-4-linux@roeck-us.net Signed-off-by: Sasha Levin commit 508cd1209b7dcecc85e19e2d364aef32fa128b37 Author: Guenter Roeck Date: Wed May 26 08:40:17 2021 -0700 hwmon: (max31790) Report correct current pwm duty cycles [ Upstream commit 897f6339893b741a5d68ae8e2475df65946041c2 ] The MAX31790 has two sets of registers for pwm duty cycles, one to request a duty cycle and one to read the actual current duty cycle. Both do not have to be the same. When reporting the pwm duty cycle to the user, the actual pwm duty cycle from pwm duty cycle registers needs to be reported. When setting it, the pwm target duty cycle needs to be written. Since we don't know the actual pwm duty cycle after a target pwm duty cycle has been written, set the valid flag to false to indicate that actual pwm duty cycle should be read from the chip instead of using cached values. Cc: Jan Kundrát Cc: Václav Kubernát Signed-off-by: Guenter Roeck Tested-by: Václav Kubernát Reviewed-by: Jan Kundrát Link: https://lore.kernel.org/r/20210526154022.3223012-3-linux@roeck-us.net Signed-off-by: Sasha Levin commit ead128748cab14e101e5368334480102d0c0d350 Author: Steve Longerbeam Date: Mon May 17 16:29:23 2021 +0200 media: imx-csi: Skip first few frames from a BT.656 source [ Upstream commit e198be37e52551bb863d07d2edc535d0932a3c4f ] Some BT.656 sensors (e.g. ADV718x) transmit frames with unstable BT.656 sync codes after initial power on. This confuses the imx CSI,resulting in vertical and/or horizontal sync issues. Skip the first 20 frames to avoid the unstable sync codes. [fabio: fixed checkpatch warning and increased the frame skipping to 20] Signed-off-by: Steve Longerbeam Signed-off-by: Fabio Estevam Reviewed-by: Tim Harvey Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 271e441c9a0abfcc4cb8c58cb9e63e290028ac5e Author: Mauro Carvalho Chehab Date: Thu Jun 10 08:57:02 2021 +0200 media: siano: fix device register error path [ Upstream commit 5368b1ee2939961a16e74972b69088433fc52195 ] As reported by smatch: drivers/media/common/siano/smsdvb-main.c:1231 smsdvb_hotplug() warn: '&client->entry' not removed from list If an error occur at the end of the registration logic, it won't drop the device from the list. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit bd6288233a8d4dd06403481774af013749208bb3 Author: Mauro Carvalho Chehab Date: Wed Jun 9 14:32:29 2021 +0200 media: dvbdev: fix error logic at dvb_register_device() [ Upstream commit 1fec2ecc252301110e4149e6183fa70460d29674 ] As reported by smatch: drivers/media/dvb-core/dvbdev.c: drivers/media/dvb-core/dvbdev.c:510 dvb_register_device() warn: '&dvbdev->list_head' not removed from list drivers/media/dvb-core/dvbdev.c: drivers/media/dvb-core/dvbdev.c:530 dvb_register_device() warn: '&dvbdev->list_head' not removed from list drivers/media/dvb-core/dvbdev.c: drivers/media/dvb-core/dvbdev.c:545 dvb_register_device() warn: '&dvbdev->list_head' not removed from list The error logic inside dvb_register_device() doesn't remove devices from the dvb_adapter_list in case of errors. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a64ddb6976e69d5694adee37321d5e1309fb86be Author: Mauro Carvalho Chehab Date: Wed Jun 16 13:13:54 2021 +0200 media: dvb_net: avoid speculation from net slot [ Upstream commit abc0226df64dc137b48b911c1fe4319aec5891bb ] The risk of especulation is actually almost-non-existing here, as there are very few users of TCP/IP using the DVB stack, as, this is mainly used with DVB-S/S2 cards, and only by people that receives TCP/IP from satellite connections, which limits a lot the number of users of such feature(*). (*) In thesis, DVB-C cards could also benefit from it, but I'm yet to see a hardware that supports it. Yet, fixing it is trivial. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 47a03368229e3b457dc0bd0b78fec6dd1edfa67d Author: Ard Biesheuvel Date: Thu Jun 10 08:21:50 2021 +0200 crypto: shash - avoid comparing pointers to exported functions under CFI [ Upstream commit 22ca9f4aaf431a9413dcc115dd590123307f274f ] crypto_shash_alg_has_setkey() is implemented by testing whether the .setkey() member of a struct shash_alg points to the default version, called shash_no_setkey(). As crypto_shash_alg_has_setkey() is a static inline, this requires shash_no_setkey() to be exported to modules. Unfortunately, when building with CFI, function pointers are routed via CFI stubs which are private to each module (or to the kernel proper) and so this function pointer comparison may fail spuriously. Let's fix this by turning crypto_shash_alg_has_setkey() into an out of line function. Cc: Sami Tolvanen Cc: Eric Biggers Signed-off-by: Ard Biesheuvel Reviewed-by: Eric Biggers Reviewed-by: Sami Tolvanen Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 239a5e142d257ed36caf122f0256ecc2861f411c Author: Axel Lin Date: Tue Jun 15 21:29:34 2021 +0800 regulator: mt6315: Fix checking return value of devm_regmap_init_spmi_ext [ Upstream commit 70d654ea3de937d7754c107bb8eeb20e30262c89 ] devm_regmap_init_spmi_ext() returns ERR_PTR() on error. Signed-off-by: Axel Lin Link: https://lore.kernel.org/r/20210615132934.3453965-1-axel.lin@ingics.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 230a4bf84904827a065643893e6b8d7dd0d48496 Author: zpershuai Date: Sun Jun 13 13:29:16 2021 +0800 spi: meson-spicc: fix memory leak in meson_spicc_probe [ Upstream commit b2d501c13470409ee7613855b17e5e5ec4111e1c ] when meson_spicc_clk_init returns failed, it should goto the out_clk label. Signed-off-by: zpershuai Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/1623562156-21995-1-git-send-email-zpershuai@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c77cbc710389f4ee44abe72552d7f459c9715ab4 Author: zpershuai Date: Sun Jun 13 13:29:32 2021 +0800 spi: meson-spicc: fix a wrong goto jump for avoiding memory leak. [ Upstream commit 95730d5eb73170a6d225a9998c478be273598634 ] In meson_spifc_probe function, when enable the device pclk clock is error, it should use clk_disable_unprepare to release the core clock. Signed-off-by: zpershuai Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/1623562172-22056-1-git-send-email-zpershuai@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 99c514bea5fa6e39fd47f7f0b1cd164f79f063d7 Author: Andrew Jeffery Date: Mon Jun 7 11:00:20 2021 +0930 mmc: sdhci-of-aspeed: Turn down a phase correction warning [ Upstream commit a7ab186f60785850b5af1be183867000485ad491 ] The card timing and the bus frequency are not changed atomically with respect to calls to the set_clock() callback in the driver. The result is the driver sees a transient state where there's a mismatch between the two and thus the inputs to the phase correction calculation formula are garbage. Switch from dev_warn() to dev_dbg() to avoid noise in the normal case, though the change does make bad configurations less likely to be noticed. Reported-by: Joel Stanley Signed-off-by: Andrew Jeffery Reviewed-by: Joel Stanley Link: https://lore.kernel.org/r/20210607013020.85885-1-andrew@aj.id.au Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit a62b72916a2c1c6b0cd761b30ad889b20a7c197d Author: Zheyu Ma Date: Thu Jun 3 13:33:20 2021 +0000 mmc: via-sdmmc: add a check against NULL pointer dereference [ Upstream commit 45c8ddd06c4b729c56a6083ab311bfbd9643f4a6 ] Before referencing 'host->data', the driver needs to check whether it is null pointer, otherwise it will cause a null pointer reference. This log reveals it: [ 29.355199] BUG: kernel NULL pointer dereference, address: 0000000000000014 [ 29.357323] #PF: supervisor write access in kernel mode [ 29.357706] #PF: error_code(0x0002) - not-present page [ 29.358088] PGD 0 P4D 0 [ 29.358280] Oops: 0002 [#1] PREEMPT SMP PTI [ 29.358595] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 5.12.4- g70e7f0549188-dirty #102 [ 29.359164] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [ 29.359978] RIP: 0010:via_sdc_isr+0x21f/0x410 [ 29.360314] Code: ff ff e8 84 aa d0 fd 66 45 89 7e 28 66 41 f7 c4 00 10 75 56 e8 72 aa d0 fd 66 41 f7 c4 00 c0 74 10 e8 65 aa d0 fd 48 8b 43 18 40 14 ac ff ff ff e8 55 aa d0 fd 48 89 df e8 ad fb ff ff e9 77 [ 29.361661] RSP: 0018:ffffc90000118e98 EFLAGS: 00010046 [ 29.362042] RAX: 0000000000000000 RBX: ffff888107d77880 RCX: 0000000000000000 [ 29.362564] RDX: 0000000000000000 RSI: ffffffff835d20bb RDI: 00000000ffffffff [ 29.363085] RBP: ffffc90000118ed8 R08: 0000000000000001 R09: 0000000000000001 [ 29.363604] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000008600 [ 29.364128] R13: ffff888107d779c8 R14: ffffc90009c00200 R15: 0000000000008000 [ 29.364651] FS: 0000000000000000(0000) GS:ffff88817bc80000(0000) knlGS:0000000000000000 [ 29.365235] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 29.365655] CR2: 0000000000000014 CR3: 0000000005a2e000 CR4: 00000000000006e0 [ 29.366170] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 29.366683] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 29.367197] Call Trace: [ 29.367381] [ 29.367537] __handle_irq_event_percpu+0x53/0x3e0 [ 29.367916] handle_irq_event_percpu+0x35/0x90 [ 29.368247] handle_irq_event+0x39/0x60 [ 29.368632] handle_fasteoi_irq+0xc2/0x1d0 [ 29.368950] __common_interrupt+0x7f/0x150 [ 29.369254] common_interrupt+0xb4/0xd0 [ 29.369547] [ 29.369708] asm_common_interrupt+0x1e/0x40 [ 29.370016] RIP: 0010:native_safe_halt+0x17/0x20 [ 29.370360] Code: 07 0f 00 2d db 80 43 00 f4 5d c3 0f 1f 84 00 00 00 00 00 8b 05 c2 37 e5 01 55 48 89 e5 85 c0 7e 07 0f 00 2d bb 80 43 00 fb f4 <5d> c3 cc cc cc cc cc cc cc 55 48 89 e5 e8 67 53 ff ff 8b 0d f9 91 [ 29.371696] RSP: 0018:ffffc9000008fe90 EFLAGS: 00000246 [ 29.372079] RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000000 [ 29.372595] RDX: 0000000000000000 RSI: ffffffff854f67a4 RDI: ffffffff85403406 [ 29.373122] RBP: ffffc9000008fe90 R08: 0000000000000001 R09: 0000000000000001 [ 29.373646] R10: 0000000000000000 R11: 0000000000000001 R12: ffffffff86009188 [ 29.374160] R13: 0000000000000000 R14: 0000000000000000 R15: ffff888100258000 [ 29.374690] default_idle+0x9/0x10 [ 29.374944] arch_cpu_idle+0xa/0x10 [ 29.375198] default_idle_call+0x6e/0x250 [ 29.375491] do_idle+0x1f0/0x2d0 [ 29.375740] cpu_startup_entry+0x18/0x20 [ 29.376034] start_secondary+0x11f/0x160 [ 29.376328] secondary_startup_64_no_verify+0xb0/0xbb [ 29.376705] Modules linked in: [ 29.376939] Dumping ftrace buffer: [ 29.377187] (ftrace buffer empty) [ 29.377460] CR2: 0000000000000014 [ 29.377712] ---[ end trace 51a473dffb618c47 ]--- [ 29.378056] RIP: 0010:via_sdc_isr+0x21f/0x410 [ 29.378380] Code: ff ff e8 84 aa d0 fd 66 45 89 7e 28 66 41 f7 c4 00 10 75 56 e8 72 aa d0 fd 66 41 f7 c4 00 c0 74 10 e8 65 aa d0 fd 48 8b 43 18 40 14 ac ff ff ff e8 55 aa d0 fd 48 89 df e8 ad fb ff ff e9 77 [ 29.379714] RSP: 0018:ffffc90000118e98 EFLAGS: 00010046 [ 29.380098] RAX: 0000000000000000 RBX: ffff888107d77880 RCX: 0000000000000000 [ 29.380614] RDX: 0000000000000000 RSI: ffffffff835d20bb RDI: 00000000ffffffff [ 29.381134] RBP: ffffc90000118ed8 R08: 0000000000000001 R09: 0000000000000001 [ 29.381653] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000008600 [ 29.382176] R13: ffff888107d779c8 R14: ffffc90009c00200 R15: 0000000000008000 [ 29.382697] FS: 0000000000000000(0000) GS:ffff88817bc80000(0000) knlGS:0000000000000000 [ 29.383277] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 29.383697] CR2: 0000000000000014 CR3: 0000000005a2e000 CR4: 00000000000006e0 [ 29.384223] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 29.384736] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 29.385260] Kernel panic - not syncing: Fatal exception in interrupt [ 29.385882] Dumping ftrace buffer: [ 29.386135] (ftrace buffer empty) [ 29.386401] Kernel Offset: disabled [ 29.386656] Rebooting in 1 seconds.. Signed-off-by: Zheyu Ma Link: https://lore.kernel.org/r/1622727200-15808-1-git-send-email-zheyuma97@gmail.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit c543fd01940d7517afb6ec31f0c315c13c14a854 Author: Krzysztof Kozlowski Date: Tue Jun 1 11:54:03 2021 +0200 mmc: sdhci-sprd: use sdhci_sprd_writew [ Upstream commit 961470820021e6f9d74db4837bd6831a1a30341b ] The sdhci_sprd_writew() was defined by never used in sdhci_ops: drivers/mmc/host/sdhci-sprd.c:134:20: warning: unused function 'sdhci_sprd_writew' Reported-by: kernel test robot Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20210601095403.236007-2-krzysztof.kozlowski@canonical.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit e0a53f67fed6f8563de7077879a54994ec4b721b Author: Tong Zhang Date: Tue May 11 12:39:45 2021 -0400 memstick: rtsx_usb_ms: fix UAF [ Upstream commit 42933c8aa14be1caa9eda41f65cde8a3a95d3e39 ] This patch fixes the following issues: 1. memstick_free_host() will free the host, so the use of ms_dev(host) after it will be a problem. To fix this, move memstick_free_host() after when we are done with ms_dev(host). 2. In rtsx_usb_ms_drv_remove(), pm need to be disabled before we remove and free host otherwise memstick_check will be called and UAF will happen. [ 11.351173] BUG: KASAN: use-after-free in rtsx_usb_ms_drv_remove+0x94/0x140 [rtsx_usb_ms] [ 11.357077] rtsx_usb_ms_drv_remove+0x94/0x140 [rtsx_usb_ms] [ 11.357376] platform_remove+0x2a/0x50 [ 11.367531] Freed by task 298: [ 11.368537] kfree+0xa4/0x2a0 [ 11.368711] device_release+0x51/0xe0 [ 11.368905] kobject_put+0xa2/0x120 [ 11.369090] rtsx_usb_ms_drv_remove+0x8c/0x140 [rtsx_usb_ms] [ 11.369386] platform_remove+0x2a/0x50 [ 12.038408] BUG: KASAN: use-after-free in __mutex_lock.isra.0+0x3ec/0x7c0 [ 12.045432] mutex_lock+0xc9/0xd0 [ 12.046080] memstick_check+0x6a/0x578 [memstick] [ 12.046509] process_one_work+0x46d/0x750 [ 12.052107] Freed by task 297: [ 12.053115] kfree+0xa4/0x2a0 [ 12.053272] device_release+0x51/0xe0 [ 12.053463] kobject_put+0xa2/0x120 [ 12.053647] rtsx_usb_ms_drv_remove+0xc4/0x140 [rtsx_usb_ms] [ 12.053939] platform_remove+0x2a/0x50 Signed-off-by: Tong Zhang Co-developed-by: Ulf Hansson Link: https://lore.kernel.org/r/20210511163944.1233295-1-ztong0001@gmail.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 8d570a009647b2b324b89c0468b5ebc4ab9a34f4 Author: Dongliang Mu Date: Tue May 25 15:06:52 2021 +0200 media: dvd_usb: memory leak in cinergyt2_fe_attach [ Upstream commit 9ad1efee086e0e913914fa2b2173efb830bad68c ] When the driver fails to talk with the hardware with dvb_usb_generic_rw, it will return an error to dvb_usb_adapter_frontend_init. However, the driver forgets to free the resource (e.g., struct cinergyt2_fe_state), which leads to a memory leak. Fix this by freeing struct cinergyt2_fe_state when dvb_usb_generic_rw fails in cinergyt2_frontend_attach. backtrace: [<0000000056e17b1a>] kmalloc include/linux/slab.h:552 [inline] [<0000000056e17b1a>] kzalloc include/linux/slab.h:682 [inline] [<0000000056e17b1a>] cinergyt2_fe_attach+0x21/0x80 drivers/media/usb/dvb-usb/cinergyT2-fe.c:271 [<00000000ae0b1711>] cinergyt2_frontend_attach+0x21/0x70 drivers/media/usb/dvb-usb/cinergyT2-core.c:74 [<00000000d0254861>] dvb_usb_adapter_frontend_init+0x11b/0x1b0 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:290 [<0000000002e08ac6>] dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:84 [inline] [<0000000002e08ac6>] dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:173 [inline] [<0000000002e08ac6>] dvb_usb_device_init.cold+0x4d0/0x6ae drivers/media/usb/dvb-usb/dvb-usb-init.c:287 Reported-by: syzbot+e1de8986786b3722050e@syzkaller.appspotmail.com Signed-off-by: Dongliang Mu Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 8d2d4b753431b69a3aa979134c39e6b0131b0074 Author: Nick Desaulniers Date: Fri May 21 18:26:24 2021 -0700 Makefile: fix GDB warning with CONFIG_RELR [ Upstream commit 27f2a4db76e8d8a8b601fc1c6a7a17f88bd907ab ] GDB produces the following warning when debugging kernels built with CONFIG_RELR: BFD: /android0/linux-next/vmlinux: unknown type [0x13] section `.relr.dyn' when loading a kernel built with CONFIG_RELR into GDB. It can also prevent debugging symbols using such relocations. Peter sugguests: [That flag] means that lld will use dynamic tags and section type numbers in the OS-specific range rather than the generic range. The kernel itself doesn't care about these numbers; it determines the location of the RELR section using symbols defined by a linker script. Link: https://github.com/ClangBuiltLinux/linux/issues/1057 Suggested-by: Peter Collingbourne Reviewed-by: Nathan Chancellor Signed-off-by: Nick Desaulniers Link: https://lore.kernel.org/r/20210522012626.2811297-1-ndesaulniers@google.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit b8ce443813d553d6303b761312ebdf0d116053d6 Author: Mark Rutland Date: Mon Jun 7 10:46:23 2021 +0100 arm64: entry: don't instrument entry code with KCOV [ Upstream commit bf6fa2c0dda751863c3446aa64d733013bec4a19 ] The code in entry-common.c runs at exception entry and return boundaries, where portions of the kernel environment aren't available. For example, RCU may not be watching, and lockdep state may be out-of-sync with the hardware. Due to this, it is not sound to instrument this code. We generally avoid instrumentation by marking the entry functions as `noinstr`, but currently this doesn't inhibit KCOV instrumentation. Prevent this by disabling KCOV for the entire compilation unit. Signed-off-by: Mark Rutland Acked-by: Catalin Marinas Acked-by: Marc Zyngier Cc: James Morse Cc: Will Deacon Link: https://lore.kernel.org/r/20210607094624.34689-20-mark.rutland@arm.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 6a8665574f6b7b1d54d328c6a98fa49ea741c73e Author: Kai Ye Date: Fri May 28 19:42:06 2021 +0800 crypto: hisilicon/sec - fixup 3des minimum key size declaration [ Upstream commit 6161f40c630bd7ced5f236cd5fbabec06e47afae ] Fixup the 3des algorithm minimum key size declaration. Signed-off-by: Kai Ye Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit d686a29b3f3ea6b04f78d7b0f26774496f1aa846 Author: Evgeny Novikov Date: Wed May 19 14:04:49 2021 +0200 media: st-hva: Fix potential NULL pointer dereferences [ Upstream commit b7fdd208687ba59ebfb09b2199596471c63b69e3 ] When ctx_id >= HVA_MAX_INSTANCES in hva_hw_its_irq_thread() it tries to access fields of ctx that is NULL at that point. The patch gets rid of these accesses. 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 8b367af282d6f79de5d2aa128804f96aa2742a97 Author: Zheyu Ma Date: Wed May 12 17:18:36 2021 +0200 media: bt8xx: Fix a missing check bug in bt878_probe [ Upstream commit 1a4520090681853e6b850cbe54b27247a013e0e5 ] In 'bt878_irq', the driver calls 'tasklet_schedule', but this tasklet is set in 'dvb_bt8xx_load_card' of another driver 'dvb-bt8xx'. However, this two drivers are separate. The user may not load the 'dvb-bt8xx' driver when loading the 'bt8xx' driver, that is, the tasklet has not been initialized when 'tasklet_schedule' is called, so it is necessary to check whether the tasklet is initialized in 'bt878_probe'. Fix this by adding a check at the end of bt878_probe. The KASAN's report reveals it: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 PGD 800000006aab2067 P4D 800000006aab2067 PUD 6b2ea067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN PTI CPU: 2 PID: 8724 Comm: syz-executor.0 Not tainted 4.19.177- gdba4159c14ef-dirty #40 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59- gc9ba5276e321-prebuilt.qemu.org 04/01/2014 RIP: 0010: (null) Code: Bad RIP value. RSP: 0018:ffff88806c287ea0 EFLAGS: 00010246 RAX: fffffbfff1b01774 RBX: dffffc0000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 1ffffffff1b01775 RDI: 0000000000000000 RBP: ffff88806c287f00 R08: fffffbfff1b01774 R09: fffffbfff1b01774 R10: 0000000000000001 R11: fffffbfff1b01773 R12: 0000000000000000 R13: ffff88806c29f530 R14: ffffffff8d80bb88 R15: ffffffff8d80bb90 FS: 00007f6b550e6700(0000) GS:ffff88806c280000(0000) knlGS: 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 000000005ec98000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: tasklet_action_common.isra.17+0x141/0x420 kernel/softirq.c:522 tasklet_action+0x50/0x70 kernel/softirq.c:540 __do_softirq+0x224/0x92c kernel/softirq.c:292 invoke_softirq kernel/softirq.c:372 [inline] irq_exit+0x15a/0x180 kernel/softirq.c:412 exiting_irq arch/x86/include/asm/apic.h:535 [inline] do_IRQ+0x123/0x1e0 arch/x86/kernel/irq.c:260 common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:670 RIP: 0010:__do_sys_interrupt kernel/sys.c:2593 [inline] RIP: 0010:__se_sys_interrupt kernel/sys.c:2584 [inline] RIP: 0010:__x64_sys_interrupt+0x5b/0x80 kernel/sys.c:2584 Code: ba 00 04 00 00 48 c7 c7 c0 99 31 8c e8 ae 76 5e 01 48 85 c0 75 21 e8 14 ae 24 00 48 c7 c3 c0 99 31 8c b8 0c 00 00 00 0f 01 c1 <31> db e8 fe ad 24 00 48 89 d8 5b 5d c3 48 c7 c3 ea ff ff ff eb ec RSP: 0018:ffff888054167f10 EFLAGS: 00000212 ORIG_RAX: ffffffffffffffde RAX: 000000000000000c RBX: ffffffff8c3199c0 RCX: ffffc90001ca6000 RDX: 000000000000001a RSI: ffffffff813478fc RDI: ffffffff8c319dc0 RBP: ffff888054167f18 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000080 R11: fffffbfff18633b7 R12: ffff888054167f58 R13: ffff88805f638000 R14: 0000000000000000 R15: 0000000000000000 do_syscall_64+0xb0/0x4e0 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4692a9 Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6b550e5c48 EFLAGS: 00000246 ORIG_RAX: 000000000000014f RAX: ffffffffffffffda RBX: 000000000077bf60 RCX: 00000000004692a9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020000140 RBP: 00000000004cf7eb R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000077bf60 R13: 0000000000000000 R14: 000000000077bf60 R15: 00007fff55a1dca0 Modules linked in: Dumping ftrace buffer: (ftrace buffer empty) CR2: 0000000000000000 ---[ end trace 68e5849c3f77cbb6 ]--- RIP: 0010: (null) Code: Bad RIP value. RSP: 0018:ffff88806c287ea0 EFLAGS: 00010246 RAX: fffffbfff1b01774 RBX: dffffc0000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 1ffffffff1b01775 RDI: 0000000000000000 RBP: ffff88806c287f00 R08: fffffbfff1b01774 R09: fffffbfff1b01774 R10: 0000000000000001 R11: fffffbfff1b01773 R12: 0000000000000000 R13: ffff88806c29f530 R14: ffffffff8d80bb88 R15: ffffffff8d80bb90 FS: 00007f6b550e6700(0000) GS:ffff88806c280000(0000) knlGS: 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 000000005ec98000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Reported-by: Zheyu Ma Signed-off-by: Zheyu Ma Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 0227d4ffca0afff13f6da367441435d18105ae8a Author: Lv Yunlong Date: Sun May 9 10:24:02 2021 +0200 media: v4l2-core: Avoid the dangling pointer in v4l2_fh_release [ Upstream commit 7dd0c9e547b6924e18712b6b51aa3cba1896ee2c ] A use after free bug caused by the dangling pointer filp->privitate_data in v4l2_fh_release. See https://lore.kernel.org/patchwork/patch/1419058/. My patch sets the dangling pointer to NULL to provide robust. Signed-off-by: Lv Yunlong Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 94b73f521e522119b87cb77162b09f886d561e32 Author: Andrzej Pietrasiewicz Date: Wed May 5 14:23:47 2021 +0200 media: cedrus: Fix .buf_prepare [ Upstream commit d84b9202d712309840f8b5abee0ed272506563bd ] The driver should only set the payload on .buf_prepare if the buffer is CAPTURE type. If an OUTPUT buffer has a zero bytesused set by userspace then v4l2-core will set it to buffer length. If we overwrite bytesused for OUTPUT buffers, too, then vb2_get_plane_payload() will return incorrect value which might be then written to hw registers by the driver in cedrus_h264.c or cedrus_vp8.c. Signed-off-by: Andrzej Pietrasiewicz Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 5ecae6b93cf57b34e3d91816f959af6f04fb99b6 Author: Andrzej Pietrasiewicz Date: Wed May 5 14:23:46 2021 +0200 media: hantro: Fix .buf_prepare [ Upstream commit 082aaecff35fbe1937531057911b1dd1fc6b496e ] The driver should only set the payload on .buf_prepare if the buffer is CAPTURE type. If an OUTPUT buffer has a zero bytesused set by userspace then v4l2-core will set it to buffer length. If we overwrite bytesused for OUTPUT buffers, too, then vb2_get_plane_payload() will return incorrect value which might be then written to hw registers by the driver in hantro_g1_h264_dec.c. Signed-off-by: Andrzej Pietrasiewicz Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit e7a3ea26832c6c8f96532465410b16b1d5440f27 Author: Igor Matheus Andrade Torrente Date: Tue May 4 20:32:49 2021 +0200 media: em28xx: Fix possible memory leak of em28xx struct [ Upstream commit ac5688637144644f06ed1f3c6d4dd8bb7db96020 ] The em28xx struct kref isn't being decreased after an error in the em28xx_ir_init, leading to a possible memory leak. A kref_put and em28xx_shutdown_buttons is added to the error handler code. Signed-off-by: Igor Matheus Andrade Torrente Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 6dc17634c1163cc50063196101bde584d6c9540a Author: Tong Zhang Date: Thu Apr 29 00:12:26 2021 +0200 media: bt878: do not schedule tasklet when it is not setup [ Upstream commit a3a54bf4bddaecda8b5767209cfc703f0be2841d ] There is a problem with the tasklet in bt878. bt->tasklet is set by dvb-bt8xx.ko, and bt878.ko can be loaded independently. In this case if interrupt comes it may cause null-ptr-dereference. To solve this issue, we check if the tasklet is actually set before calling tasklet_schedule. [ 1.750438] bt878(0): irq FDSR FBUS risc_pc= [ 1.750728] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 1.752969] RIP: 0010:0x0 [ 1.757526] Call Trace: [ 1.757659] [ 1.757770] tasklet_action_common.isra.0+0x107/0x110 [ 1.758041] tasklet_action+0x22/0x30 [ 1.758237] __do_softirq+0xe0/0x29b [ 1.758430] irq_exit_rcu+0xa4/0xb0 [ 1.758618] common_interrupt+0x8d/0xa0 [ 1.758824] Signed-off-by: Tong Zhang Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 2375ab34f7f3b029b7afa85f659f00b911028322 Author: Dillon Min Date: Tue May 4 07:09:53 2021 +0200 media: i2c: ov2659: Use clk_{prepare_enable,disable_unprepare}() to set xvclk on/off [ Upstream commit 24786ccd9c80fdb05494aa4d90fcb8f34295c193 ] On some platform(imx6q), xvclk might not switch on in advance, also for power save purpose, xvclk should not be always on. so, add clk_prepare_enable(), clk_disable_unprepare() in driver side to set xvclk on/off at proper stage. Add following changes: - add 'struct clk *clk;' in 'struct ov2659 {}' - enable xvclk in ov2659_power_on() - disable xvclk in ov2659_power_off() Signed-off-by: Dillon Min Acked-by: Lad Prabhakar Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit ac302ca5829f52cb0dc3c0f541fa8e6d065483af Author: Roberto Sassu Date: Fri May 14 17:27:53 2021 +0200 ima: Don't remove security.ima if file must not be appraised [ Upstream commit ed1b472fc15aeaa20ddeeb93fd25190014e50d17 ] Files might come from a remote source and might have xattrs, including security.ima. It should not be IMA task to decide whether security.ima should be kept or not. This patch removes the removexattr() system call in ima_inode_post_setattr(). Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 0221e855eb01759b1e0e625f89f8d3b1a4b14876 Author: Odin Ugedal Date: Tue May 18 14:52:02 2021 +0200 sched/fair: Fix ascii art by relpacing tabs [ Upstream commit 08f7c2f4d0e9f4283f5796b8168044c034a1bfcb ] When using something other than 8 spaces per tab, this ascii art makes not sense, and the reader might end up wondering what this advanced equation "is". Signed-off-by: Odin Ugedal Signed-off-by: Peter Zijlstra (Intel) Acked-by: Vincent Guittot Link: https://lkml.kernel.org/r/20210518125202.78658-4-odin@uged.al Signed-off-by: Sasha Levin commit b2e7f2f9701c4c282d1390228af3ff97227e4a5b Author: Tian Tao Date: Thu May 20 15:59:45 2021 +0800 arm64: perf: Convert snprintf to sysfs_emit [ Upstream commit a5740e955540181f4ab8f076cc9795c6bbe4d730 ] Use sysfs_emit instead of snprintf to avoid buf overrun,because in sysfs_emit it strictly checks whether buf is null or buf whether pagesize aligned, otherwise it returns an error. Signed-off-by: Tian Tao Link: https://lore.kernel.org/r/1621497585-30887-1-git-send-email-tiantao6@hisilicon.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit cab7a8c8ac9c01a7fcb5c9155501b703b1847e90 Author: Hui Tang Date: Sat May 22 10:44:29 2021 +0800 crypto: ecdh - fix 'ecdh_init' [ Upstream commit 8fd28fa5046b377039d5bbc0ab2f625dec703980 ] NIST P192 is not unregistered if failed to register NIST P256, actually it need to unregister the algorithms already registered. Signed-off-by: Hui Tang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9a091b3fe9a3488442cd1d3d7989d8c080108ce5 Author: Hui Tang Date: Sat May 22 10:44:28 2021 +0800 crypto: ecdh - fix ecdh-nist-p192's entry in testmgr [ Upstream commit 6889fc2104e5d20899b91e61daf07a7524b2010d ] Add a comment that p192 will fail to register in FIPS mode. Fix ecdh-nist-p192's entry in testmgr by removing the ifdefs and not setting fips_allowed. Signed-off-by: Hui Tang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 3b29a41e8e163c37283f86b6efe5bb9f3bb76a75 Author: Thara Gopinath Date: Thu May 20 22:20:23 2021 -0400 crypto: qce: skcipher: Fix incorrect sg count for dma transfers [ Upstream commit 1339a7c3ba05137a2d2fe75f602311bbfc6fab33 ] Use the sg count returned by dma_map_sg to call into dmaengine_prep_slave_sg rather than using the original sg count. dma_map_sg can merge consecutive sglist entries, thus making the original sg count wrong. This is a fix for memory coruption issues observed while testing encryption/decryption of large messages using libkcapi framework. Patch has been tested further by running full suite of tcrypt.ko tests including fuzz tests. Signed-off-by: Thara Gopinath Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 4d9440ec7e31a99ab9767d5285315b8f778d2842 Author: Jack Xu Date: Mon May 17 05:13:16 2021 -0400 crypto: qat - remove unused macro in FW loader [ Upstream commit 9afe77cf25d9670e61b489fd52cc6f75fd7f6803 ] Remove the unused macro ICP_DH895XCC_PESRAM_BAR_SIZE in the firmware loader. This is to fix the following warning when compiling the driver using the clang compiler with CC=clang W=2: drivers/crypto/qat/qat_common/qat_uclo.c:345:9: warning: macro is not used [-Wunused-macros] Signed-off-by: Jack Xu Co-developed-by: Zhehui Xiang Signed-off-by: Zhehui Xiang Reviewed-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 39d92a5c89e3d32470ee7d6774a075c33dd81b55 Author: Jack Xu Date: Mon May 17 05:13:15 2021 -0400 crypto: qat - check return code of qat_hal_rd_rel_reg() [ Upstream commit 96b57229209490c8bca4335b01a426a96173dc56 ] Check the return code of the function qat_hal_rd_rel_reg() and return it to the caller. This is to fix the following warning when compiling the driver with clang scan-build: drivers/crypto/qat/qat_common/qat_hal.c:1436:2: warning: 6th function call argument is an uninitialized value Signed-off-by: Jack Xu Co-developed-by: Zhehui Xiang Signed-off-by: Zhehui Xiang Reviewed-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 12dc9abe342358e11131836c969206fd5b8b88ed Author: Laurent Pinchart Date: Tue Apr 13 04:29:52 2021 +0200 media: imx: imx7_mipi_csis: Fix logging of only error event counters [ Upstream commit d2fcc9c2de1191ea80366e3658711753738dd10a ] The mipi_csis_events array ends with 6 non-error events, not 4. Update mipi_csis_log_counters() accordingly. While at it, log event counters in forward order, as there's no reason to log them backward. Signed-off-by: Laurent Pinchart Acked-by: Rui Miguel Silva Reviewed-by: Frieder Schrempf Tested-by: Frieder Schrempf Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 8a1ef71e3fa36db8e7df418cfc8a9e400680edce Author: Anirudh Rayabharam Date: Tue May 4 19:08:58 2021 +0200 media: pvrusb2: fix warning in pvr2_i2c_core_done [ Upstream commit f8194e5e63fdcb349e8da9eef9e574d5b1d687cb ] syzbot has reported the following warning in pvr2_i2c_done: sysfs group 'power' not found for kobject '1-0043' When the device is disconnected (pvr_hdw_disconnect), the i2c adapter is not unregistered along with the USB and v4l2 teardown. As part of the USB device disconnect, the sysfs files of the subdevices are also deleted. So, by the time pvr_i2c_core_done is called by pvr_context_destroy, the sysfs files have been deleted. To fix this, unregister the i2c adapter too in pvr_hdw_disconnect. Make the device deregistration code shared by calling pvr_hdw_disconnect from pvr2_hdw_destroy. Reported-by: syzbot+e74a998ca8f1df9cc332@syzkaller.appspotmail.com Tested-by: syzbot+e74a998ca8f1df9cc332@syzkaller.appspotmail.com Reviewed-by: Greg Kroah-Hartman Signed-off-by: Anirudh Rayabharam Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 27be0f88baedcc7eb42ecbdb6bc5369d9461dde9 Author: Jernej Skrabec Date: Tue Apr 27 09:15:54 2021 +0200 media: hevc: Fix dependent slice segment flags [ Upstream commit 67a7e53d5b21f3a84efc03a4e62db7caf97841ef ] Dependent slice segment flag for PPS control is misnamed. It should have "enabled" at the end. It only tells if this flag is present in slice header or not and not the actual value. Fix this by renaming the PPS flag and introduce another flag for slice control which tells actual value. Signed-off-by: Jernej Skrabec Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit b42989b813f2918064db25e86fbe4ebc7aef3f7d Author: Hans Verkuil Date: Fri Apr 23 10:00:49 2021 +0200 media: cobalt: fix race condition in setting HPD [ Upstream commit 3d37ef41bed0854805ab9af22c422267510e1344 ] The cobalt_s_bit_sysctrl reads the old register value over PCI, then changes a bit and sets writes the new value to the register. This is used among other things for setting the HPD output pin. But if the HPD is changed for multiple inputs at the same time, then this causes a race condition where a stale value is read. Serialize this function with a mutex. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a24a3803d883ca0deb106925ae937cada4e43713 Author: Pavel Skripkin Date: Wed Apr 21 21:43:45 2021 +0200 media: cpia2: fix memory leak in cpia2_usb_probe [ Upstream commit be8656e62e9e791837b606a027802b504a945c97 ] syzbot reported leak in cpia2 usb driver. The problem was in invalid error handling. v4l2_device_register() is called in cpia2_init_camera_struct(), but all error cases after cpia2_init_camera_struct() did not call the v4l2_device_unregister() Reported-by: syzbot+d1e69c888f0d3866ead4@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit dc6a87f5450debcf2f92059156f279b0be72fb2a Author: Valentin Schneider Date: Mon May 10 16:10:23 2021 +0100 sched: Make the idle task quack like a per-CPU kthread [ Upstream commit 00b89fe0197f0c55a045775c11553c0cdb7082fe ] For all intents and purposes, the idle task is a per-CPU kthread. It isn't created via the same route as other pcpu kthreads however, and as a result it is missing a few bells and whistles: it fails kthread_is_per_cpu() and it doesn't have PF_NO_SETAFFINITY set. Fix the former by giving the idle task a kthread struct along with the KTHREAD_IS_PER_CPU flag. This requires some extra iffery as init_idle() call be called more than once on the same idle task. Signed-off-by: Valentin Schneider Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210510151024.2448573-2-valentin.schneider@arm.com Signed-off-by: Sasha Levin commit b03f44f12056a0e09f1804e220a5887c913f828c Author: Mauro Carvalho Chehab Date: Tue May 18 11:26:31 2021 +0200 media: sti: fix obj-$(config) targets [ Upstream commit 56c1f0876293888f686e31278d183d4af2cac3c3 ] The right thing to do is to add a new object to the building system when a certain config option is selected, and *not* override them. So, fix obj-$(config) logic at sti makefiles, using "+=", instead of ":=". Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 536898457d30b831872203a2dd159ad5e92abda6 Author: Bixuan Cui Date: Sat May 8 11:14:55 2021 +0800 crypto: nx - add missing MODULE_DEVICE_TABLE [ Upstream commit 06676aa1f455c74e3ad1624cea3acb9ed2ef71ae ] 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: Bixuan Cui Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 56e208fd789a09beeca8524ff389486fdee0320c Author: Łukasz Stelmach Date: Wed May 5 20:29:14 2021 +0200 hwrng: exynos - Fix runtime PM imbalance on error [ Upstream commit 0cdbabf8bb7a6147f5adf37dbc251e92a1bbc2c7 ] pm_runtime_resume_and_get() wraps around pm_runtime_get_sync() and decrements the runtime PM usage counter in case the latter function fails and keeps the counter balanced. Signed-off-by: Łukasz Stelmach Reviewed-by: Krzysztof Kozlowski Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 24c79a7e54ccfa29fb8cbf7ed8d1e48ff1ec6e3d Author: Valentin Schneider Date: Wed May 12 10:46:36 2021 +0100 sched/core: Initialize the idle task with preemption disabled [ Upstream commit f1a0a376ca0c4ef1fc3d24e3e502acbb5b795674 ] As pointed out by commit de9b8f5dcbd9 ("sched: Fix crash trying to dequeue/enqueue the idle thread") init_idle() can and will be invoked more than once on the same idle task. At boot time, it is invoked for the boot CPU thread by sched_init(). Then smp_init() creates the threads for all the secondary CPUs and invokes init_idle() on them. As the hotplug machinery brings the secondaries to life, it will issue calls to idle_thread_get(), which itself invokes init_idle() yet again. In this case it's invoked twice more per secondary: at _cpu_up(), and at bringup_cpu(). Given smp_init() already initializes the idle tasks for all *possible* CPUs, no further initialization should be required. Now, removing init_idle() from idle_thread_get() exposes some interesting expectations with regards to the idle task's preempt_count: the secondary startup always issues a preempt_disable(), requiring some reset of the preempt count to 0 between hot-unplug and hotplug, which is currently served by idle_thread_get() -> idle_init(). Given the idle task is supposed to have preemption disabled once and never see it re-enabled, it seems that what we actually want is to initialize its preempt_count to PREEMPT_DISABLED and leave it there. Do that, and remove init_idle() from idle_thread_get(). Secondary startups were patched via coccinelle: @begone@ @@ -preempt_disable(); ... cpu_startup_entry(CPUHP_AP_ONLINE_IDLE); Signed-off-by: Valentin Schneider Signed-off-by: Ingo Molnar Acked-by: Peter Zijlstra Link: https://lore.kernel.org/r/20210512094636.2958515-1-valentin.schneider@arm.com Signed-off-by: Sasha Levin commit 08d3c4504a7a3a254616f7342320c4e61fca3241 Author: Zou Wei Date: Tue May 11 11:53:18 2021 +0800 regulator: uniphier: Add missing MODULE_DEVICE_TABLE [ Upstream commit d019f38a1af3c6015cde6a47951a3ec43beeed80 ] 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 Link: https://lore.kernel.org/r/1620705198-104566-1-git-send-email-zou_wei@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2183eb0f23ca7692842f326735c77181f9478414 Author: Tian Tao Date: Thu Apr 29 19:20:48 2021 +0800 spi: omap-100k: Fix the length judgment problem [ Upstream commit e7a1a3abea373e41ba7dfe0fbc93cb79b6a3a529 ] word_len should be checked in the omap1_spi100k_setup_transfer function to see if it exceeds 32. Signed-off-by: Tian Tao Link: https://lore.kernel.org/r/1619695248-39045-1-git-send-email-tiantao6@hisilicon.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4e2c9415918f9322db003cb6070d317c1163046f Author: Jay Fang Date: Thu May 6 15:08:08 2021 +0800 spi: spi-topcliff-pch: Fix potential double free in pch_spi_process_messages() [ Upstream commit 026a1dc1af52742c5897e64a3431445371a71871 ] pch_spi_set_tx() frees data->pkt_tx_buff on failure of kzalloc() for data->pkt_rx_buff, but its caller, pch_spi_process_messages(), will free data->pkt_tx_buff again. Set data->pkt_tx_buff to NULL after kfree() to avoid double free. Signed-off-by: Jay Fang Link: https://lore.kernel.org/r/1620284888-65215-1-git-send-email-f.fangjian@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b198e32d5f56237ab6aa0e11811aec3d62c75acc Author: Jay Fang Date: Mon May 10 14:58:23 2021 +0800 spi: spi-loopback-test: Fix 'tx_buf' might be 'rx_buf' [ Upstream commit 9e37a3ab0627011fb63875e9a93094b6fc8ddf48 ] In function 'spi_test_run_iter': Value 'tx_buf' might be 'rx_buf'. Signed-off-by: Jay Fang Link: https://lore.kernel.org/r/1620629903-15493-5-git-send-email-f.fangjian@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 946e1956adc41554f9dcf940d43296d341a248b8 Author: Mauro Carvalho Chehab Date: Fri Apr 23 17:19:18 2021 +0200 media: exynos-gsc: fix pm_runtime_get_sync() usage count [ Upstream commit 59087b66ea6730c130c57d23bd9fd139b78c1ba5 ] The pm_runtime_get_sync() internally increments the dev->power.usage_count without decrementing it, even on errors. Replace it by the new pm_runtime_resume_and_get(), introduced by: commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter") in order to properly decrement the usage counter, avoiding a potential PM usage counter leak. As a bonus, as pm_runtime_get_sync() always return 0 on success, the logic can be simplified. Reviewed-by: Jonathan Cameron Reviewed-by: Sylwester Nawrocki Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit e320bd62f3434f13fcc2956133e68d7377b429a8 Author: Mauro Carvalho Chehab Date: Fri Apr 23 17:19:17 2021 +0200 media: exynos4-is: fix pm_runtime_get_sync() usage count [ Upstream commit 59f96244af9403ddf4810ec5c0fbe8920857634e ] The pm_runtime_get_sync() internally increments the dev->power.usage_count without decrementing it, even on errors. On some places, this is ok, but on others the usage count ended being unbalanced on failures. Replace it by the new pm_runtime_resume_and_get(), introduced by: commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter") in order to properly decrement the usage counter, avoiding a potential PM usage counter leak. As a bonus, such function always return zero on success. So, some code can be simplified. Reviewed-by: Sylwester Nawrocki Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 8de265ab0659ae1c06cd15416a69dcba8f54967f Author: Mauro Carvalho Chehab Date: Fri Apr 23 17:19:21 2021 +0200 media: sti/bdisp: fix pm_runtime_get_sync() usage count [ Upstream commit c44eac5b72e23c31eefc0e10a71d9650036b8341 ] The pm_runtime_get_sync() internally increments the dev->power.usage_count without decrementing it, even on errors. The bdisp_start_streaming() doesn't take it into account, which would unbalance PM usage counter at bdisp_stop_streaming(). The logic at bdisp_probe() is correct, but the best is to use the same call along the driver. So, replace it by the new pm_runtime_resume_and_get(), introduced by: commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter") in order to properly decrement the usage counter, avoiding a potential PM usage counter leak. Reviewed-by: Jonathan Cameron Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit c816ee302c4fd0adbb1252faccc917124de31148 Author: Mauro Carvalho Chehab Date: Fri Apr 23 17:19:10 2021 +0200 media: sunxi: fix pm_runtime_get_sync() usage count [ Upstream commit 9c298f82d8392f799a0595f50076afa1d91e9092 ] The pm_runtime_get_sync() internally increments the dev->power.usage_count without decrementing it, even on errors. Replace it by the new pm_runtime_resume_and_get(), introduced by: commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter") in order to properly decrement the usage counter, avoiding a potential PM usage counter leak. Reviewed-by: Jonathan Cameron Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 3ac22a1256fb8c65d171dfd935b33091de2d6cde Author: Mauro Carvalho Chehab Date: Fri Apr 23 17:19:10 2021 +0200 media: s5p-jpeg: fix pm_runtime_get_sync() usage count [ Upstream commit 10343de268d10cf07b092b8b525e12ad558ead77 ] The pm_runtime_get_sync() internally increments the dev->power.usage_count without decrementing it, even on errors. Replace it by the new pm_runtime_resume_and_get(), introduced by: commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter") in order to properly decrement the usage counter, avoiding a potential PM usage counter leak. As a plus, pm_runtime_resume_and_get() doesn't return positive numbers, so the return code validation can be removed. Reviewed-by: Jonathan Cameron Reviewed-by: Sylwester Nawrocki Acked-by: Andrzej Pietrasiewicz Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 74cdbfc4a6325950ef6d008f2d9785f70d500ec4 Author: Mauro Carvalho Chehab Date: Fri Apr 23 17:19:09 2021 +0200 media: mtk-vcodec: fix PM runtime get logic [ Upstream commit 908711f542c17fe61e5d653da1beb8e5ab5c7b50 ] Currently, the driver just assumes that PM runtime logic succeded resuming the device. That may not be the case, as pm_runtime_get_sync() can fail (but keeping the usage count incremented). Replace the code to use pm_runtime_resume_and_get(), and letting it return the error code. This way, if mtk_vcodec_dec_pw_on() fails, the logic under fops_vcodec_open() will do the right thing and return an error, instead of just assuming that the device is ready to be used. Reviewed-by: Jonathan Cameron Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 22d11e498877ccd8fac784061072291a5d6d6c09 Author: Mauro Carvalho Chehab Date: Fri Apr 23 17:07:41 2021 +0200 media: sh_vou: fix pm_runtime_get_sync() usage count [ Upstream commit 6e8b1526db164c9d4b9dacfb9bc48e365d7c4860 ] The pm_runtime_get_sync() internally increments the dev->power.usage_count without decrementing it, even on errors. Replace it by the new pm_runtime_resume_and_get(), introduced by: commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter") in order to properly decrement the usage counter, avoiding a potential PM usage counter leak. While here, check if the PM runtime error was caught at open time. Reviewed-by: Jonathan Cameron Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit eb29fa40a3a23ba688155331c9704cc3eb8173e3 Author: Mauro Carvalho Chehab Date: Fri Apr 23 17:05:27 2021 +0200 media: am437x: fix pm_runtime_get_sync() usage count [ Upstream commit c41e02493334985cca1a22efd5ca962ce3abb061 ] The pm_runtime_get_sync() internally increments the dev->power.usage_count without decrementing it, even on errors. Replace it by the new pm_runtime_resume_and_get(), introduced by: commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter") in order to properly decrement the usage counter, avoiding a potential PM usage counter leak. While here, ensure that the driver will check if PM runtime resumed at vpfe_initialize_device(). Reviewed-by: Jonathan Cameron Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 2982dfc00e6d226474ca93d2ac6a242663980c0b Author: Mauro Carvalho Chehab Date: Fri Apr 23 17:04:23 2021 +0200 media: s5p: fix pm_runtime_get_sync() usage count [ Upstream commit fdc34e82c0f968ac4c157bd3d8c299ebc24c9c63 ] The pm_runtime_get_sync() internally increments the dev->power.usage_count without decrementing it, even on errors. Replace it by the new pm_runtime_resume_and_get(), introduced by: commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter") in order to properly decrement the usage counter, avoiding a potential PM usage counter leak. While here, check if the PM runtime error was caught at s5p_cec_adap_enable(). Reviewed-by: Jonathan Cameron Reviewed-by: Sylwester Nawrocki Acked-by: Marek Szyprowski Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 55eed167f79dc9a72b9ecb29dcca169f853c2633 Author: Mauro Carvalho Chehab Date: Fri Apr 23 16:57:16 2021 +0200 media: mdk-mdp: fix pm_runtime_get_sync() usage count [ Upstream commit d07bb9702cf5f5ccf3fb661e6cab54bbc33cd23f ] The pm_runtime_get_sync() internally increments the dev->power.usage_count without decrementing it, even on errors. Replace it by the new pm_runtime_resume_and_get(), introduced by: commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter") in order to properly decrement the usage counter, avoiding a potential PM usage counter leak. While here, fix the return contition of mtk_mdp_m2m_start_streaming(), as it doesn't make any sense to return 0 if the PM runtime failed to resume. Reviewed-by: Jonathan Cameron Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit e0a7065748d09d390f28e69f388ae863bb9f3c2e Author: Mauro Carvalho Chehab Date: Fri Apr 23 16:54:25 2021 +0200 media: marvel-ccic: fix some issues when getting pm_runtime [ Upstream commit e7c617cab7a522fba5b20f9033ee98565b6f3546 ] Calling pm_runtime_get_sync() is bad, since even when it returns an error, pm_runtime_put*() should be called. So, use instead pm_runtime_resume_and_get(). While here, ensure that the error condition will be checked during clock enable an media open() calls. Reviewed-by: Jonathan Cameron Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 59378a815637898dfcd85e58da448e1846eea4c0 Author: Mauro Carvalho Chehab Date: Fri Apr 23 17:19:13 2021 +0200 media: i2c: imx334: fix the pm runtime get logic [ Upstream commit 62c90446868b439929cb04395f04a709a64ae04b ] The PM runtime get logic is currently broken, as it checks if ret is zero instead of checking if it is an error code, as reported by Dan Carpenter. While here, use the pm_runtime_resume_and_get() as added by: commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter") added pm_runtime_resume_and_get() in order to automatically handle dev->power.usage_count decrement on errors. As a bonus, such function always return zero on success. It should also be noticed that a fail of pm_runtime_get_sync() would potentially result in a spurious runtime_suspend(), instead of using pm_runtime_put_noidle(). Reported-by: Dan Carpenter Reviewed-by: Daniele Alessandrelli Reviewed-by: Jonathan Cameron Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 58bc5e46ba44ab35728a6838dd7addff99de7c32 Author: Mauro Carvalho Chehab Date: Fri Apr 23 17:19:11 2021 +0200 staging: media: rkvdec: fix pm_runtime_get_sync() usage count [ Upstream commit e90812c47b958407b54d05780dc483fdc1b57a93 ] The pm_runtime_get_sync() internally increments the dev->power.usage_count without decrementing it, even on errors. Replace it by the new pm_runtime_resume_and_get(), introduced by: commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter") in order to properly decrement the usage counter, avoiding a potential PM usage counter leak. Reviewed-by: Ezequiel Garcia Reviewed-by: Jonathan Cameron Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 1199573d26016f59a6c3e55833065a2b38a4abd5 Author: Alexey Gladkov Date: Thu Apr 22 14:27:09 2021 +0200 Add a reference to ucounts for each cred [ Upstream commit 905ae01c4ae2ae3df05bb141801b1db4b7d83c61 ] For RLIMIT_NPROC and some other rlimits the user_struct that holds the global limit is kept alive for the lifetime of a process by keeping it in struct cred. Adding a pointer to ucounts in the struct cred will allow to track RLIMIT_NPROC not only for user in the system, but for user in the user_namespace. Updating ucounts may require memory allocation which may fail. So, we cannot change cred.ucounts in the commit_creds() because this function cannot fail and it should always return 0. For this reason, we modify cred.ucounts before calling the commit_creds(). Changelog v6: * Fix null-ptr-deref in is_ucounts_overlimit() detected by trinity. This error was caused by the fact that cred_alloc_blank() left the ucounts pointer empty. Reported-by: kernel test robot Signed-off-by: Alexey Gladkov Link: https://lkml.kernel.org/r/b37aaef28d8b9b0d757e07ba6dd27281bbe39259.1619094428.git.legion@kernel.org Signed-off-by: Eric W. Biederman Signed-off-by: Sasha Levin commit 9057b6cca1511a77b8b47a6db9ae40304ce4d3a2 Author: Charles Keepax Date: Wed Apr 21 11:14:02 2021 +0100 spi: Make of_register_spi_device also set the fwnode [ Upstream commit 0e793ba77c18382f08e440260fe72bc6fce2a3cb ] Currently, the SPI core doesn't set the struct device fwnode pointer when it creates a new SPI device. This means when the device is registered the fwnode is NULL and the check in device_add which sets the fwnode->dev pointer is skipped. This wasn't previously an issue, however these two patches: commit 4731210c09f5 ("gpiolib: Bind gpio_device to a driver to enable fw_devlink=on by default") commit ced2af419528 ("gpiolib: Don't probe gpio_device if it's not the primary device") Added some code to the GPIO core which relies on using that fwnode->dev pointer to determine if a driver is bound to the fwnode and if not bind a stub GPIO driver. This means the GPIO providers behind SPI will get both the expected driver and this stub driver causing the stub driver to fail if it attempts to request any pin configuration. For example on my system: madera-pinctrl madera-pinctrl: pin gpio5 already requested by madera-pinctrl; cannot claim for gpiochip3 madera-pinctrl madera-pinctrl: pin-4 (gpiochip3) status -22 madera-pinctrl madera-pinctrl: could not request pin 4 (gpio5) from group aif1 on device madera-pinctrl gpio_stub_drv gpiochip3: Error applying setting, reverse things back gpio_stub_drv: probe of gpiochip3 failed with error -22 The firmware node on the device created by the GPIO framework is set through the of_node pointer hence things generally actually work, however that fwnode->dev is never set, as the check was skipped at device_add time. This fix appears to match how the I2C subsystem handles the same situation. Signed-off-by: Charles Keepax Link: https://lore.kernel.org/r/20210421101402.8468-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a004cf847764c4f17d2e1c28d0eaabf4aa0ee644 Author: Lukasz Luba Date: Mon Jun 14 20:10:30 2021 +0100 thermal/cpufreq_cooling: Update offline CPUs per-cpu thermal_pressure [ Upstream commit 2ad8ccc17d1e4270cf65a3f2a07a7534aa23e3fb ] The thermal pressure signal gives information to the scheduler about reduced CPU capacity due to thermal. It is based on a value stored in a per-cpu 'thermal_pressure' variable. The online CPUs will get the new value there, while the offline won't. Unfortunately, when the CPU is back online, the value read from per-cpu variable might be wrong (stale data). This might affect the scheduler decisions, since it sees the CPU capacity differently than what is actually available. Fix it by making sure that all online+offline CPUs would get the proper value in their per-cpu variable when thermal framework sets capping. Fixes: f12e4f66ab6a3 ("thermal/cpu-cooling: Update thermal pressure in case of a maximum frequency capping") Signed-off-by: Lukasz Luba Signed-off-by: Peter Zijlstra (Intel) Acked-by: Viresh Kumar Link: https://lore.kernel.org/r/20210614191030.22241-1-lukasz.luba@arm.com Signed-off-by: Sasha Levin commit 0c1678f223daf89364283d4fa1b362b404d7b056 Author: Miklos Szeredi Date: Tue Jun 22 09:15:35 2021 +0200 fuse: reject internal errno commit 49221cf86d18bb66fe95d3338cb33bd4b9880ca5 upstream. Don't allow userspace to report errors that could be kernel-internal. Reported-by: Anatoly Trosinenko Fixes: 334f485df85a ("[PATCH] FUSE - device functions") Cc: # v2.6.14 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 2644fd6588e5951012cd4fc7fe016ea8c7157eff Author: Miklos Szeredi Date: Tue Jun 22 09:15:35 2021 +0200 fuse: check connected before queueing on fpq->io commit 80ef08670d4c28a06a3de954bd350368780bcfef upstream. A request could end up on the fpq->io list after fuse_abort_conn() has reset fpq->connected and aborted requests on that list: Thread-1 Thread-2 ======== ======== ->fuse_simple_request() ->shutdown ->__fuse_request_send() ->queue_request() ->fuse_abort_conn() ->fuse_dev_do_read() ->acquire(fpq->lock) ->wait_for(fpq->lock) ->set err to all req's in fpq->io ->release(fpq->lock) ->acquire(fpq->lock) ->add req to fpq->io After the userspace copy is done the request will be ended, but req->out.h.error will remain uninitialized. Also the copy might block despite being already aborted. Fix both issues by not allowing the request to be queued on the fpq->io list after fuse_abort_conn() has processed this list. Reported-by: Pradeep P V K Fixes: fd22d62ed0c3 ("fuse: no fc->lock for iqueue parts") Cc: # v4.2 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 76d97f2f3b028974f681f32884780f45e09d0d56 Author: Miklos Szeredi Date: Fri Jun 18 21:16:42 2021 +0200 fuse: ignore PG_workingset after stealing commit b89ecd60d38ec042d63bdb376c722a16f92bcb88 upstream. Fix the "fuse: trying to steal weird page" warning. Description from Johannes Weiner: "Think of it as similar to PG_active. It's just another usage/heat indicator of file and anon pages on the reclaim LRU that, unlike PG_active, persists across deactivation and even reclaim (we store it in the page cache / swapper cache tree until the page refaults). So if fuse accepts pages that can legally have PG_active set, PG_workingset is fine too." Reported-by: Thomas Lindroth Fixes: 1899ad18c607 ("mm: workingset: tell cache transitions from workingset thrashing") Cc: # v4.20 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 108adb1a56680e47119d94ae3c1beeae1e5ea9a0 Author: Greg Kurz Date: Fri Jun 4 18:11:52 2021 +0200 fuse: Fix infinite loop in sget_fc() commit e4a9ccdd1c03b3dc58214874399d24331ea0a3ab upstream. We don't set the SB_BORN flag on submounts. This is wrong as these superblocks are then considered as partially constructed or dying in the rest of the code and can break some assumptions. One such case is when you have a virtiofs filesystem with submounts and you try to mount it again : virtio_fs_get_tree() tries to obtain a superblock with sget_fc(). The logic in sget_fc() is to loop until it has either found an existing matching superblock with SB_BORN set or to create a brand new one. It is assumed that a superblock without SB_BORN is transient and the loop is restarted. Forgetting to set SB_BORN on submounts hence causes sget_fc() to retry forever. Setting SB_BORN requires special care, i.e. a write barrier for super_cache_count() which can check SB_BORN without taking any lock. We should call vfs_get_tree() to deal with that but this requires to have a proper ->get_tree() implementation for submounts, which is a bigger piece of work. Go for a simple bug fix in the meatime. Fixes: bf109c64040f ("fuse: implement crossmounts") Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Greg Kurz Reviewed-by: Max Reitz Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 809b077db6b821c17b317da46ce10f7df036adfe Author: Greg Kurz Date: Fri Jun 4 18:11:51 2021 +0200 fuse: Fix crash if superblock of submount gets killed early commit e3a43f2a95393000778f8f302d48795add2fc4a8 upstream. As soon as fuse_dentry_automount() does up_write(&sb->s_umount), the superblock can theoretically be killed. If this happens before the submount was added to the &fc->mounts list, fuse_mount_remove() later crashes in list_del_init() because it assumes the submount to be already there. Add the submount before dropping sb->s_umount to fix the inconsistency. It is okay to nest fc->killsb under sb->s_umount, we already do this on the ->kill_sb() path. Signed-off-by: Greg Kurz Fixes: bf109c64040f ("fuse: implement crossmounts") Cc: stable@vger.kernel.org # v5.10+ Reviewed-by: Max Reitz Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 7ef44eacefc1180f451009cea60f2ad3a467c153 Author: Greg Kurz Date: Fri Jun 4 18:11:50 2021 +0200 fuse: Fix crash in fuse_dentry_automount() error path commit d92d88f0568e97c437eeb79d9c9609bd8277406f upstream. If fuse_fill_super_submount() returns an error, the error path triggers a crash: [ 26.206673] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] [ 26.226362] RIP: 0010:__list_del_entry_valid+0x25/0x90 [...] [ 26.247938] Call Trace: [ 26.248300] fuse_mount_remove+0x2c/0x70 [fuse] [ 26.248892] virtio_kill_sb+0x22/0x160 [virtiofs] [ 26.249487] deactivate_locked_super+0x36/0xa0 [ 26.250077] fuse_dentry_automount+0x178/0x1a0 [fuse] The crash happens because fuse_mount_remove() assumes that the FUSE mount was already added to list under the FUSE connection, but this only done after fuse_fill_super_submount() has returned success. This means that until fuse_fill_super_submount() has returned success, the FUSE mount isn't actually owned by the superblock. We should thus reclaim ownership by clearing sb->s_fs_info, which will skip the call to fuse_mount_remove(), and perform rollback, like virtio_fs_get_tree() already does for the root sb. Fixes: bf109c64040f ("fuse: implement crossmounts") Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Greg Kurz Reviewed-by: Max Reitz Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 1c7c1de40632735d679f8dae10948ed929d24350 Author: Roberto Sassu Date: Fri May 14 17:27:44 2021 +0200 evm: Refuse EVM_ALLOW_METADATA_WRITES only if an HMAC key is loaded commit 9acc89d31f0c94c8e573ed61f3e4340bbd526d0c upstream. EVM_ALLOW_METADATA_WRITES is an EVM initialization flag that can be set to temporarily disable metadata verification until all xattrs/attrs necessary to verify an EVM portable signature are copied to the file. This flag is cleared when EVM is initialized with an HMAC key, to avoid that the HMAC is calculated on unverified xattrs/attrs. Currently EVM unnecessarily denies setting this flag if EVM is initialized with a public key, which is not a concern as it cannot be used to trust xattrs/attrs updates. This patch removes this limitation. Fixes: ae1ba1676b88e ("EVM: Allow userland to permit modification of EVM-protected metadata") Signed-off-by: Roberto Sassu Cc: stable@vger.kernel.org # 4.16.x Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 22527af823fa03164338056393a21326f73f6cc4 Author: Roberto Sassu Date: Fri May 14 17:27:42 2021 +0200 evm: Execute evm_inode_init_security() only when an HMAC key is loaded commit 9eea2904292c2d8fa98df141d3bf7c41ec9dc1b5 upstream. evm_inode_init_security() requires an HMAC key to calculate the HMAC on initial xattrs provided by LSMs. However, it checks generically whether a key has been loaded, including also public keys, which is not correct as public keys are not suitable to calculate the HMAC. Originally, support for signature verification was introduced to verify a possibly immutable initial ram disk, when no new files are created, and to switch to HMAC for the root filesystem. By that time, an HMAC key should have been loaded and usable to calculate HMACs for new files. More recently support for requiring an HMAC key was removed from the kernel, so that signature verification can be used alone. Since this is a legitimate use case, evm_inode_init_security() should not return an error when no HMAC key has been loaded. This patch fixes this problem by replacing the evm_key_loaded() check with a check of the EVM_INIT_HMAC flag in evm_initialized. Fixes: 26ddabfe96b ("evm: enable EVM when X509 certificate is loaded") Signed-off-by: Roberto Sassu Cc: stable@vger.kernel.org # 4.5.x Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 335d92decfdc98ac1111060809b12419ac66b1f4 Author: Kristian Klausen Date: Fri Jun 18 13:51:57 2021 +0200 loop: Fix missing discard support when using LOOP_CONFIGURE commit 2b9ac22b12a266eb4fec246a07b504dd4983b16b upstream. Without calling loop_config_discard() the discard flag and parameters aren't set/updated for the loop device and worst-case they could indicate discard support when it isn't the case (ex: if the LOOP_SET_STATUS ioctl was used with a different file prior to LOOP_CONFIGURE). Cc: # 5.8.x- Fixes: 3448914e8cc5 ("loop: Add LOOP_CONFIGURE ioctl") Signed-off-by: Kristian Klausen Link: https://lore.kernel.org/r/20210618115157.31452-1-kristian@klausen.dk Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit dac1e7eb17cffad52f5949c9574d783dd1b725a8 Author: Kan Liang Date: Fri Jun 18 08:12:54 2021 -0700 perf/x86/intel: Fix instructions:ppp support in Sapphire Rapids commit 1d5c7880992a06679585e7e568cc679c0c5fd4f2 upstream. Perf errors out when sampling instructions:ppp. $ perf record -e instructions:ppp -- true Error: The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (instructions:ppp). The instruction PDIR is only available on the fixed counter 0. The event constraint has been updated to fixed0_constraint in icl_get_event_constraints(). The Sapphire Rapids codes unconditionally error out for the event which is not available on the GP counter 0. Make the instructions:ppp an exception. Fixes: 61b985e3e775 ("perf/x86/intel: Add perf core PMU support for Sapphire Rapids") Reported-by: Yasin, Ahmad Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1624029174-122219-4-git-send-email-kan.liang@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit f457b2b8edd88d6f15144353578434672ebe8c72 Author: Kan Liang Date: Fri Jun 18 08:12:53 2021 -0700 perf/x86/intel: Add more events requires FRONTEND MSR on Sapphire Rapids commit d18216fafecf2a3a7c2b97086892269d6ab3cd5e upstream. On Sapphire Rapids, there are two more events 0x40ad and 0x04c2 which rely on the FRONTEND MSR. If the FRONTEND MSR is not set correctly, the count value is not correct. Update intel_spr_extra_regs[] to support them. Fixes: 61b985e3e775 ("perf/x86/intel: Add perf core PMU support for Sapphire Rapids") Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1624029174-122219-3-git-send-email-kan.liang@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit ef52fc1cc475c5b9f7c12fa33825b57026cd59e2 Author: Kan Liang Date: Fri Jun 18 08:12:52 2021 -0700 perf/x86/intel: Fix fixed counter check warning for some Alder Lake commit ee72a94ea4a6d8fa304a506859cd07ecdc0cf5c4 upstream. For some Alder Lake machine, the below fixed counter check warning may be triggered. [ 2.010766] hw perf events fixed 5 > max(4), clipping! Current perf unconditionally increases the number of the GP counters and the fixed counters for a big core PMU on an Alder Lake system, because the number enumerated in the CPUID only reflects the common counters. The big core may has more counters. However, Alder Lake may have an alternative configuration. With that configuration, the X86_FEATURE_HYBRID_CPU is not set. The number of the GP counters and fixed counters enumerated in the CPUID is accurate. Perf mistakenly increases the number of counters. The warning is triggered. Directly use the enumerated value on the system with the alternative configuration. Fixes: f83d2f91d259 ("perf/x86/intel: Add Alder Lake Hybrid support") Reported-by: Jin Yao Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1624029174-122219-2-git-send-email-kan.liang@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 4a16324ff687f0698bb0ae7ae47c871526e7a6af Author: Tejas Upadhyay Date: Tue Jun 8 11:04:11 2021 +0530 x86/gpu: add JasperLake to gen11 early quirks commit 31b77c70d9bc04d3b024ea56c129523f9edc1328 upstream. Let's reserve JSL stolen memory for graphics. JasperLake is a gen11 platform which is compatible with ICL/EHL changes. This was missed in commit 24ea098b7c0d ("drm/i915/jsl: Split EHL/JSL platform info and PCI ids") V2: - Added maintainer list in cc - Added patch ref in commit message V1: - Added Cc: x86@kernel.org Fixes: 24ea098b7c0d ("drm/i915/jsl: Split EHL/JSL platform info and PCI ids") Cc: # v5.11+ Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: x86@kernel.org Cc: José Roberto de Souza Signed-off-by: Tejas Upadhyay Signed-off-by: Maarten Lankhorst Link: https://patchwork.freedesktop.org/patch/msgid/20210608053411.394166-1-tejaskumarx.surendrakumar.upadhyay@intel.com Signed-off-by: Greg Kroah-Hartman commit 371764e376d1cdb98268c6728ee6e9d56e10536f Author: Michael Ellerman Date: Fri Jun 25 16:28:41 2021 +1000 powerpc/stacktrace: Fix spurious "stale" traces in raise_backtrace_ipi() commit 7c6986ade69e3c81bac831645bc72109cd798a80 upstream. In raise_backtrace_ipi() we iterate through the cpumask of CPUs, sending each an IPI asking them to do a backtrace, but we don't wait for the backtrace to happen. We then iterate through the CPU mask again, and if any CPU hasn't done the backtrace and cleared itself from the mask, we print a trace on its behalf, noting that the trace may be "stale". This works well enough when a CPU is not responding, because in that case it doesn't receive the IPI and the sending CPU is left to print the trace. But when all CPUs are responding we are left with a race between the sending and receiving CPUs, if the sending CPU wins the race then it will erroneously print a trace. This leads to spurious "stale" traces from the sending CPU, which can then be interleaved messily with the receiving CPU, note the CPU numbers, eg: [ 1658.929157][ C7] rcu: Stack dump where RCU GP kthread last ran: [ 1658.929223][ C7] Sending NMI from CPU 7 to CPUs 1: [ 1658.929303][ C1] NMI backtrace for cpu 1 [ 1658.929303][ C7] CPU 1 didn't respond to backtrace IPI, inspecting paca. [ 1658.929362][ C1] CPU: 1 PID: 325 Comm: kworker/1:1H Tainted: G W E 5.13.0-rc2+ #46 [ 1658.929405][ C7] irq_soft_mask: 0x01 in_mce: 0 in_nmi: 0 current: 325 (kworker/1:1H) [ 1658.929465][ C1] Workqueue: events_highpri test_work_fn [test_lockup] [ 1658.929549][ C7] Back trace of paca->saved_r1 (0xc0000000057fb400) (possibly stale): [ 1658.929592][ C1] NIP: c00000000002cf50 LR: c008000000820178 CTR: c00000000002cfa0 To fix it, change the logic so that the sending CPU waits 5s for the receiving CPU to print its trace. If the receiving CPU prints its trace successfully then the sending CPU just continues, avoiding any spurious "stale" trace. This has the added benefit of allowing all CPUs to print their traces in order and avoids any interleaving of their output. Fixes: 5cc05910f26e ("powerpc/64s: Wire up arch_trigger_cpumask_backtrace()") Cc: stable@vger.kernel.org # v4.18+ Reported-by: Nathan Lynch Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210625140408.3351173-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman commit 468e5a5c9d0873867099c4fd99c2090ea965fd8c Author: Yun Zhou Date: Sat Jun 26 11:21:56 2021 +0800 seq_buf: Make trace_seq_putmem_hex() support data longer than 8 commit 6a2cbc58d6c9d90cd74288cc497c2b45815bc064 upstream. Since the raw memory 'data' does not go forward, it will dump repeated data if the data length is more than 8. If we want to dump longer data blocks, we need to repeatedly call macro SEQ_PUT_HEX_FIELD. I think it is a bit redundant, and multiple function calls also affect the performance. Link: https://lore.kernel.org/lkml/20210625122453.5e2fe304@oasis.local.home/ Link: https://lkml.kernel.org/r/20210626032156.47889-2-yun.zhou@windriver.com Cc: stable@vger.kernel.org Fixes: 6d2289f3faa7 ("tracing: Make trace_seq_putmem_hex() more robust") Signed-off-by: Yun Zhou Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 751d51f3e9b2bbdf940674fb826378f951aa0776 Author: Steven Rostedt (VMware) Date: Tue Jun 29 09:40:10 2021 -0400 tracepoint: Add tracepoint_probe_register_may_exist() for BPF tracing commit 9913d5745bd720c4266805c8d29952a3702e4eca upstream. All internal use cases for tracepoint_probe_register() is set to not ever be called with the same function and data. If it is, it is considered a bug, as that means the accounting of handling tracepoints is corrupted. If the function and data for a tracepoint is already registered when tracepoint_probe_register() is called, it will call WARN_ON_ONCE() and return with EEXISTS. The BPF system call can end up calling tracepoint_probe_register() with the same data, which now means that this can trigger the warning because of a user space process. As WARN_ON_ONCE() should not be called because user space called a system call with bad data, there needs to be a way to register a tracepoint without triggering a warning. Enter tracepoint_probe_register_may_exist(), which can be called, but will not cause a WARN_ON() if the probe already exists. It will still error out with EEXIST, which will then be sent to the user space that performed the BPF system call. This keeps the previous testing for issues with other users of the tracepoint code, while letting BPF call it with duplicated data and not warn about it. Link: https://lore.kernel.org/lkml/20210626135845.4080-1-penguin-kernel@I-love.SAKURA.ne.jp/ Link: https://syzkaller.appspot.com/bug?id=41f4318cf01762389f4d1c1c459da4f542fe5153 Cc: stable@vger.kernel.org Fixes: c4f6699dfcb85 ("bpf: introduce BPF_RAW_TRACEPOINT") Reported-by: syzbot Reported-by: Tetsuo Handa Tested-by: syzbot+721aa903751db87aa244@syzkaller.appspotmail.com Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 31d28f8a04b3ed3a55871c950a6940461089be3c Author: Steven Rostedt (VMware) Date: Wed Jul 7 11:08:21 2021 -0400 tracing/histograms: Fix parsing of "sym-offset" modifier commit 26c563731056c3ee66f91106c3078a8c36bb7a9e upstream. With the addition of simple mathematical operations (plus and minus), the parsing of the "sym-offset" modifier broke, as it took the '-' part of the "sym-offset" as a minus, and tried to break it up into a mathematical operation of "field.sym - offset", in which case it failed to parse (unless the event had a field called "offset"). Both .sym and .sym-offset modifiers should not be entered into mathematical calculations anyway. If ".sym-offset" is found in the modifier, then simply make it not an operation that can be calculated on. Link: https://lkml.kernel.org/r/20210707110821.188ae255@oasis.local.home Cc: Ingo Molnar Cc: Andrew Morton Cc: Masami Hiramatsu Cc: Namhyung Kim Cc: Daniel Bristot de Oliveira Cc: stable@vger.kernel.org Fixes: 100719dcef447 ("tracing: Add simple expression support to hist triggers") Reviewed-by: Tom Zanussi Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 3b0bfe43fecc4edee069b87713822bc60a510bcd Author: Xiaochen Shen Date: Thu May 27 17:31:53 2021 +0800 selftests/resctrl: Fix incorrect parsing of option "-t" commit 1421ec684a43379b2aa3cfda20b03d38282dc990 upstream. Resctrl test suite accepts command line argument "-t" to specify the unit tests to run in the test list (e.g., -t mbm,mba,cmt,cat) as documented in the help. When calling strtok() to parse the option, the incorrect delimiters argument ":\t" is used. As a result, passing "-t mbm,mba,cmt,cat" throws an invalid option error. Fix this by using delimiters argument "," instead of ":\t" for parsing of unit tests list. At the same time, remove the unnecessary "spaces" between the unit tests in help documentation to prevent confusion. Fixes: 790bf585b0ee ("selftests/resctrl: Add Cache Allocation Technology (CAT) selftest") Fixes: 78941183d1b1 ("selftests/resctrl: Add Cache QoS Monitoring (CQM) selftest") Fixes: ecdbb911f22d ("selftests/resctrl: Add MBM test") Fixes: 034c7678dd2c ("selftests/resctrl: Add README for resctrl tests") Cc: stable@vger.kernel.org Signed-off-by: Xiaochen Shen Reviewed-by: Tony Luck Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman commit b8ffd9d4b9492f517dff05c5db5176f5b8760581 Author: Martin Fuzzey Date: Tue Jun 1 18:19:53 2021 +0200 rsi: fix AP mode with WPA failure due to encrypted EAPOL commit 314538041b5632ffaf64798faaeabaf2793fe029 upstream. In AP mode WPA2-PSK connections were not established. The reason was that the AP was sending the first message of the 4 way handshake encrypted, even though no pairwise key had (correctly) yet been set. Encryption was enabled if the "security_enable" driver flag was set and encryption was not explicitly disabled by IEEE80211_TX_INTFL_DONT_ENCRYPT. However security_enable was set when *any* key, including the AP GTK key, had been set which was causing unwanted encryption even if no key was avaialble for the unicast packet to be sent. Fix this by adding a check that we have a key and drop the old security_enable driver flag which is insufficient and redundant. The Redpine downstream out of tree driver does it this way too. Regarding the Fixes tag the actual code being modified was introduced earlier, with the original driver submission, in dad0d04fa7ba ("rsi: Add RS9113 wireless driver"), however at that time AP mode was not yet supported so there was no bug at that point. So I have tagged the introduction of AP support instead which was part of the patch set "rsi: support for AP mode" [1] It is not clear whether AP WPA has ever worked, I can see nothing on the kernel side that broke it afterwards yet the AP support patch series says "Tests are performed to confirm aggregation, connections in WEP and WPA/WPA2 security." One possibility is that the initial tests were done with a modified userspace (hostapd). [1] https://www.spinics.net/lists/linux-wireless/msg165302.html Signed-off-by: Martin Fuzzey Fixes: 38ef62353acb ("rsi: security enhancements for AP mode") CC: stable@vger.kernel.org Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1622564459-24430-1-git-send-email-martin.fuzzey@flowbird.group Signed-off-by: Greg Kroah-Hartman commit c812eb280471963fb80ced209a5f4d9e705e8cfd Author: Marek Vasut Date: Fri May 7 23:31:05 2021 +0200 rsi: Assign beacon rate settings to the correct rate_info descriptor field commit b1c3a24897bd528f2f4fda9fea7da08a84ae25b6 upstream. The RSI_RATE_x bits must be assigned to struct rsi_data_desc rate_info field. The rest of the driver does it correctly, except this one place, so fix it. This is also aligned with the RSI downstream vendor driver. Without this patch, an AP operating at 5 GHz does not transmit any beacons at all, this patch fixes that. Fixes: d26a9559403c ("rsi: add beacon changes for AP mode") Signed-off-by: Marek Vasut Cc: Amitkumar Karwar Cc: Angus Ainslie Cc: David S. Miller Cc: Jakub Kicinski Cc: Kalle Valo Cc: Karun Eagalapati Cc: Martin Kepplinger Cc: Prameela Rani Garnepudi Cc: Sebastian Krzyszkowiak Cc: Siva Rebbagondla Cc: netdev@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210507213105.140138-1-marex@denx.de Signed-off-by: Greg Kroah-Hartman commit 1852c5f9916b4b82ff587b679ca4456e502fab16 Author: Michael Buesch Date: Sat May 15 21:02:52 2021 +0200 ssb: sdio: Don't overwrite const buffer if block_write fails commit 47ec636f7a25aa2549e198c48ecb6b1c25d05456 upstream. It doesn't make sense to clobber the const driver-side buffer, if a write-to-device attempt failed. All other SSB variants (PCI, PCMCIA and SoC) also don't corrupt the buffer on any failure in block_write. Therefore, remove this memset from the SDIO variant. Signed-off-by: Michael Büsch Cc: stable@vger.kernel.org Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210515210252.318be2ba@wiggum Signed-off-by: Greg Kroah-Hartman commit b3a3ff8b0e7aef808a1df6bb387375367ab045ee Author: Pali Rohár Date: Mon May 31 17:41:27 2021 +0300 ath9k: Fix kernel NULL pointer dereference during ath_reset_internal() commit fb312ac5ccb007e843f982b38d4d6886ba4b32f2 upstream. I got this crash more times during debugging of PCIe controller and crash happens somehow at the time when PCIe kernel code started link retraining (as part of ASPM code) when at the same time PCIe link went down and ath9k probably executed hw reset procedure. Currently I'm not able to reproduce this issue as it looks like to be some race condition between link training, ASPM, link down and reset path. And as always, race conditions which depends on more input parameters are hard to reproduce as it depends on precise timings. But it is clear that pointers are zero in this case and should be properly filled as same code pattern is used in ath9k_stop() function. Anyway I was able to reproduce this crash by manually triggering ath reset worker prior putting card up. I created simple patch to export reset functionality via debugfs and use it to "simulate" of triggering reset. s proved that NULL-pointer dereference issue is there. Function ath9k_hw_reset() is dereferencing chan structure pointer, so it needs to be non-NULL pointer. Function ath9k_stop() already contains code which sets ah->curchan to valid non-NULL pointer prior calling ath9k_hw_reset() function. Add same code pattern also into ath_reset_internal() function to prevent kernel NULL pointer dereference in ath9k_hw_reset() function. This change fixes kernel NULL pointer dereference in ath9k_hw_reset() which is caused by calling ath9k_hw_reset() from ath_reset_internal() with NULL chan structure. [ 45.334305] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 [ 45.344417] Mem abort info: [ 45.347301] ESR = 0x96000005 [ 45.350448] EC = 0x25: DABT (current EL), IL = 32 bits [ 45.356166] SET = 0, FnV = 0 [ 45.359350] EA = 0, S1PTW = 0 [ 45.362596] Data abort info: [ 45.365756] ISV = 0, ISS = 0x00000005 [ 45.369735] CM = 0, WnR = 0 [ 45.372814] user pgtable: 4k pages, 39-bit VAs, pgdp=000000000685d000 [ 45.379663] [0000000000000008] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 45.388856] Internal error: Oops: 96000005 [#1] SMP [ 45.393897] Modules linked in: ath9k ath9k_common ath9k_hw [ 45.399574] CPU: 1 PID: 309 Comm: kworker/u4:2 Not tainted 5.12.0-rc2-dirty #785 [ 45.414746] Workqueue: phy0 ath_reset_work [ath9k] [ 45.419713] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--) [ 45.425910] pc : ath9k_hw_reset+0xc4/0x1c48 [ath9k_hw] [ 45.431234] lr : ath9k_hw_reset+0xc0/0x1c48 [ath9k_hw] [ 45.436548] sp : ffffffc0118dbca0 [ 45.439961] x29: ffffffc0118dbca0 x28: 0000000000000000 [ 45.445442] x27: ffffff800dee4080 x26: 0000000000000000 [ 45.450923] x25: ffffff800df9b9d8 x24: 0000000000000000 [ 45.456404] x23: ffffffc0115f6000 x22: ffffffc008d0d408 [ 45.461885] x21: ffffff800dee5080 x20: ffffff800df9b9d8 [ 45.467366] x19: 0000000000000000 x18: 0000000000000000 [ 45.472846] x17: 0000000000000000 x16: 0000000000000000 [ 45.478326] x15: 0000000000000010 x14: ffffffffffffffff [ 45.483807] x13: ffffffc0918db94f x12: ffffffc011498720 [ 45.489289] x11: 0000000000000003 x10: ffffffc0114806e0 [ 45.494770] x9 : ffffffc01014b2ec x8 : 0000000000017fe8 [ 45.500251] x7 : c0000000ffffefff x6 : 0000000000000001 [ 45.505733] x5 : 0000000000000000 x4 : 0000000000000000 [ 45.511213] x3 : 0000000000000000 x2 : ffffff801fece870 [ 45.516693] x1 : ffffffc00eded000 x0 : 000000000000003f [ 45.522174] Call trace: [ 45.524695] ath9k_hw_reset+0xc4/0x1c48 [ath9k_hw] [ 45.529653] ath_reset_internal+0x1a8/0x2b8 [ath9k] [ 45.534696] ath_reset_work+0x2c/0x40 [ath9k] [ 45.539198] process_one_work+0x210/0x480 [ 45.543339] worker_thread+0x5c/0x510 [ 45.547115] kthread+0x12c/0x130 [ 45.550445] ret_from_fork+0x10/0x1c [ 45.554138] Code: 910922c2 9117e021 95ff0398 b4000294 (b9400a61) [ 45.560430] ---[ end trace 566410ba90b50e8b ]--- [ 45.565193] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 45.572282] SMP: stopping secondary CPUs [ 45.576331] Kernel Offset: disabled [ 45.579924] CPU features: 0x00040002,0000200c [ 45.584416] Memory Limit: none [ 45.587564] Rebooting in 3 seconds.. Signed-off-by: Pali Rohár Cc: stable@vger.kernel.org Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210402122653.24014-1-pali@kernel.org Signed-off-by: Greg Kroah-Hartman commit 019f2c9f98a46735f97e0b79b589cdca8c9c4381 Author: Ondrej Zary Date: Fri Jun 11 22:19:39 2021 +0200 serial_cs: remove wrong GLOBETROTTER.cis entry commit 11b1d881a90fc184cc7d06e9804eb288c24a2a0d upstream. The GLOBETROTTER.cis entry in serial_cs matches more devices than intended and breaks them. Remove it. Example: # pccardctl info PRODID_1="Option International " PRODID_2="GSM-Ready 56K/ISDN " PRODID_3="021 " PRODID_4="A " MANFID=0013,0000 FUNCID=0 result: pcmcia 0.0: Direct firmware load for cis/GLOBETROTTER.cis failed with error -2 The GLOBETROTTER.cis is nowhere to be found. There's GLOBETROTTER.cis.ihex at https://netdev.vger.kernel.narkive.com/h4inqdxM/patch-axnet-cs-fix-phy-id-detection-for-bogus-asix-chip#post41 It's from completely diffetent card: vers_1 4.1, "Option International", "GSM/GPRS GlobeTrotter", "001", "A" Signed-off-by: Ondrej Zary Cc: stable Link: https://lore.kernel.org/r/20210611201940.23898-1-linux@zary.sk Signed-off-by: Greg Kroah-Hartman commit 8c0484fd3f11dfbd01e0adece764d423dcc8d416 Author: Ondrej Zary Date: Fri Jun 11 22:19:40 2021 +0200 serial_cs: Add Option International GSM-Ready 56K/ISDN modem commit d495dd743d5ecd47288156e25c4d9163294a0992 upstream. Add support for Option International GSM-Ready 56K/ISDN PCMCIA modem card. Signed-off-by: Ondrej Zary Cc: stable Link: https://lore.kernel.org/r/20210611201940.23898-2-linux@zary.sk Signed-off-by: Greg Kroah-Hartman commit a9cd055e36e506daa9198ca8c2bf9995200ff575 Author: Yoshihiro Shimoda Date: Thu Jun 10 20:08:06 2021 +0900 serial: sh-sci: Stop dmaengine transfer in sci_stop_tx() commit 08a84410a04f05c7c1b8e833f552416d8eb9f6fe upstream. Stop dmaengine transfer in sci_stop_tx(). Otherwise, the following message is possible output when system enters suspend and while transferring data, because clearing TIE bit in SCSCR is not able to stop any dmaengine transfer. sh-sci e6550000.serial: ttySC1: Unable to drain transmitter Note that this driver has already used some #ifdef in the .c file so that this patch also uses #ifdef to fix the issue. Otherwise, build errors happens if the CONFIG_SERIAL_SH_SCI_DMA is disabled. Fixes: 73a19e4c0301 ("serial: sh-sci: Add DMA support.") Cc: # v4.9+ Signed-off-by: Yoshihiro Shimoda Link: https://lore.kernel.org/r/20210610110806.277932-1-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 10f409e7ffb5f9a4c083e14ed1368989ef76d41a Author: Pali Rohár Date: Fri Jun 25 00:49:00 2021 +0200 serial: mvebu-uart: fix calculation of clock divisor commit 9078204ca5c33ba20443a8623a41a68a9995a70d upstream. The clock divisor should be rounded to the closest value. Signed-off-by: Pali Rohár Fixes: 68a0db1d7da2 ("serial: mvebu-uart: add function to change baudrate") Cc: stable@vger.kernel.org # 0e4cf69ede87 ("serial: mvebu-uart: clarify the baud rate derivation") Link: https://lore.kernel.org/r/20210624224909.6350-2-pali@kernel.org Signed-off-by: Greg Kroah-Hartman commit de8eea1e763657df223fd9ced6a2bdda2d66e44c Author: Hans de Goede Date: Sun May 23 19:00:56 2021 +0200 iio: accel: bmc150: Don't make the remove function of the second accelerometer unregister itself commit f407e2dca0f559621114eeaf657880d83f237fbd upstream. On machines with dual accelerometers described in a single ACPI fwnode, the bmc150_accel_probe() instantiates a second i2c-client for the second accelerometer. A pointer to this manually instantiated second i2c-client is stored inside the iio_dev's private-data through bmc150_set_second_device(), so that the i2c-client can be unregistered from bmc150_accel_remove(). Before this commit bmc150_set_second_device() took only 1 argument so it would store the pointer in private-data of the iio_dev belonging to the manually instantiated i2c-client, leading to the bmc150_accel_remove() call for the second_dev trying to unregister *itself* while it was being removed, leading to a deadlock and rmmod hanging. Change bmc150_set_second_device() to take 2 arguments: 1. The i2c-client which is instantiating the second i2c-client for the 2nd accelerometer and 2. The second-device pointer itself (which also is an i2c-client). This will store the second_device pointer in the private data of the iio_dev belonging to the (ACPI instantiated) i2c-client for the first accelerometer and will make bmc150_accel_remove() unregister the second_device i2c-client when called for the first client, avoiding the deadlock. Fixes: 5bfb3a4bd8f6 ("iio: accel: bmc150: Check for a second ACPI device for BOSC0200") Cc: Jeremy Cline Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit aabcb52a2a1a9f19db082cf70be27f13631e3a74 Author: Hans de Goede Date: Sun May 23 19:00:55 2021 +0200 iio: accel: bmc150: Fix dereferencing the wrong pointer in bmc150_get/set_second_device commit f2bf22dc9ea8ead180fc0221874bd556bf1d2685 upstream. The drvdata for iio-parent devices points to the struct iio_dev for the iio-device. So by directly casting the return from i2c_get_clientdata() to struct bmc150_accel_data * the code was ending up storing the second_dev pointer in (and retrieving it from) some semi-random offset inside struct iio_dev, rather then storing it in the second_dev member of the bmc150_accel_data struct. Fix the code to get the struct bmc150_accel_data * pointer to call iio_priv() on the struct iio_dev * returned by i2c_get_clientdata(), so that the correct pointer gets dereferenced. This fixes the following oops on rmmod, caused by trying to dereference the wrong return of bmc150_get_second_device(): [ 238.980737] BUG: unable to handle page fault for address: 0000000000004710 [ 238.980755] #PF: supervisor read access in kernel mode [ 238.980760] #PF: error_code(0x0000) - not-present page ... [ 238.980841] i2c_unregister_device.part.0+0x19/0x60 [ 238.980856] 0xffffffffc0815016 [ 238.980863] i2c_device_remove+0x25/0xb0 [ 238.980869] __device_release_driver+0x180/0x240 [ 238.980876] driver_detach+0xd4/0x120 [ 238.980882] bus_remove_driver+0x5b/0xd0 [ 238.980888] i2c_del_driver+0x44/0x70 While at it also remove the now no longer sensible checks for data being NULL, iio_priv never returns NULL for an iio_dev with non 0 sized private-data. Fixes: 5bfb3a4bd8f6 ("iio: accel: bmc150: Check for a second ACPI device for BOSC0200") Cc: Jeremy Cline Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit bcb312ee98a3c2839be75adbda0c1bf5e1f04535 Author: Stephan Gerhold Date: Fri Jun 11 10:08:54 2021 +0200 iio: accel: bmc150: Fix bma222 scale unit commit 6e2a90af0b8d757e850cc023d761ee9a9492e2fe upstream. According to sysfs-bus-iio documentation the unit for accelerometer values after applying scale/offset should be m/s^2, not g, which explains why the scale values for the other variants in bmc150-accel do not match exactly the values given in the datasheet. To get the correct values, we need to multiply the BMA222 scale values by g = 9.80665 m/s^2. Fixes: a1a210bf29a1 ("iio: accel: bmc150-accel: Add support for BMA222") Reviewed-by: Linus Walleij Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20210611080903.14384-2-stephan@gerhold.net Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 0deff8dcd0fc374c878cb5b8cfbebc90632fc54c Author: Stephan Gerhold Date: Wed May 26 11:44:07 2021 +0200 iio: accel: bma180: Fix BMA25x bandwidth register values commit 8090d67421ddab0ae932abab5a60200598bf0bbb upstream. According to the BMA253 datasheet [1] and BMA250 datasheet [2] the bandwidth value for BMA25x should be set as 01xxx: "Settings 00xxx result in a bandwidth of 7.81 Hz; [...] It is recommended [...] to use the range from ´01000b´ to ´01111b´ only in order to be compatible with future products." However, at the moment the drivers sets bandwidth values from 0 to 6, which is not recommended and always results into 7.81 Hz bandwidth according to the datasheet. Fix this by introducing a bw_offset = 8 = 01000b for BMA25x, so the additional bit is always set for BMA25x. [1]: https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bma253-ds000.pdf [2]: https://datasheet.octopart.com/BMA250-Bosch-datasheet-15540103.pdf Cc: Peter Meerwald Fixes: 2017cff24cc0 ("iio:bma180: Add BMA250 chip support") Signed-off-by: Stephan Gerhold Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20210526094408.34298-2-stephan@gerhold.net Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit f78812513693eade5e2612b902dddd2e04a84e28 Author: Oliver Lang Date: Thu Jun 10 15:46:18 2021 +0200 iio: ltr501: ltr501_read_ps(): add missing endianness conversion commit 71b33f6f93ef9462c84560e2236ed22209d26a58 upstream. The PS ADC Channel data is spread over 2 registers in little-endian form. This patch adds the missing endianness conversion. Fixes: 2690be905123 ("iio: Add Lite-On ltr501 ambient light / proximity sensor driver") Signed-off-by: Oliver Lang Reviewed-by: Andy Shevchenko Signed-off-by: Marc Kleine-Budde Tested-by: Nikita Travkin # ltr559 Link: https://lore.kernel.org/r/20210610134619.2101372-4-mkl@pengutronix.de Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 77825e12cc2f7ac97e1fd9874b8caf875f3502a0 Author: Oliver Lang Date: Thu Jun 10 15:46:17 2021 +0200 iio: ltr501: ltr559: fix initialization of LTR501_ALS_CONTR commit 421a26f3d7a7c3ca43f3a9dc0f3cb0f562d5bd95 upstream. The ltr559 chip uses only the lowest bit of the ALS_CONTR register to configure between active and stand-by mode. In the original driver BIT(1) is used, which does a software reset instead. This patch fixes the problem by using BIT(0) as als_mode_active for the ltr559 chip. Fixes: 8592a7eefa54 ("iio: ltr501: Add support for ltr559 chip") Signed-off-by: Oliver Lang Reviewed-by: Andy Shevchenko Signed-off-by: Marc Kleine-Budde Tested-by: Nikita Travkin # ltr559 Link: https://lore.kernel.org/r/20210610134619.2101372-3-mkl@pengutronix.de Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit acead08f0fad5189fc5970bdba37ba4b1558106f Author: Marc Kleine-Budde Date: Thu Jun 10 15:46:16 2021 +0200 iio: ltr501: mark register holding upper 8 bits of ALS_DATA{0,1} and PS_DATA as volatile, too commit 2ac0b029a04b673ce83b5089368f467c5dca720c upstream. The regmap is configured for 8 bit registers, uses a RB-Tree cache and marks several registers as volatile (i.e. do not cache). The ALS and PS data registers in the chip are 16 bit wide and spans two regmap registers. In the current driver only the base register is marked as volatile, resulting in the upper register only read once. Further the data sheet notes: | When the I2C read operation starts, all four ALS data registers are | locked until the I2C read operation of register 0x8B is completed. Which results in the registers never update after the 2nd read. This patch fixes the problem by marking the upper 8 bits of the ALS and PS registers as volatile, too. Fixes: 2f2c96338afc ("iio: ltr501: Add regmap support.") Reported-by: Oliver Lang Reviewed-by: Andy Shevchenko Signed-off-by: Marc Kleine-Budde Tested-by: Nikita Travkin # ltr559 Link: https://lore.kernel.org/r/20210610134619.2101372-2-mkl@pengutronix.de Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 9495675ef266d3d16067a8288cfcc401feb76aed Author: frank zago Date: Mon Apr 26 21:20:17 2021 -0500 iio: light: tcs3472: do not free unallocated IRQ commit 7cd04c863f9e1655d607705455e7714f24451984 upstream. Allocating an IRQ is conditional to the IRQ existence, but freeing it was not. If no IRQ was allocate, the driver would still try to free IRQ 0. Add the missing checks. This fixes the following trace when the driver is removed: [ 100.667788] Trying to free already-free IRQ 0 [ 100.667793] WARNING: CPU: 0 PID: 2315 at kernel/irq/manage.c:1826 free_irq+0x1fd/0x370 ... [ 100.667914] Call Trace: [ 100.667920] tcs3472_remove+0x3a/0x90 [tcs3472] [ 100.667927] i2c_device_remove+0x2b/0xa0 Signed-off-by: frank zago Link: https://lore.kernel.org/r/20210427022017.19314-2-frank@zago.net Fixes: 9d2f715d592e ("iio: light: tcs3472: support out-of-threshold events") Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 9cc4994b50c17dceeed9d8cbea3adad36e422c6c Author: Yang Yingliang Date: Tue Jun 1 22:26:05 2021 +0800 iio: frequency: adf4350: disable reg and clk on error in adf4350_probe() commit c8cc4cf60b000fb9f4b29bed131fb6cf1fe42d67 upstream. Disable reg and clk when devm_gpiod_get_optional() fails in adf4350_probe(). Fixes:4a89d2f47ccd ("iio: adf4350: Convert to use GPIO descriptor") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20210601142605.3613605-1-yangyingliang@huawei.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 7f6494552897fb4204f7ada4286f42b25b857ec6 Author: Martin Fuzzey Date: Mon Jun 7 19:36:40 2021 +0200 rtc: stm32: Fix unbalanced clk_disable_unprepare() on probe error path commit 950ac33dbe6ff656a623d862022f0762ec061ba7 upstream. The STM32MP1 RTC may have 2 clocks, the pclk and the rtc_ck. If clk_prepare_enable() fails for the second clock (rtc_ck) we must only call clk_disable_unprepare() for the first clock (pclk) but currently we call it on both leading to a WARN: [ 15.629568] WARNING: CPU: 0 PID: 146 at drivers/clk/clk.c:958 clk_core_disable+0xb0/0xc8 [ 15.637620] ck_rtc already disabled [ 15.663322] CPU: 0 PID: 146 Comm: systemd-udevd Not tainted 5.4.77-pknbsp-svn5759-atag-v5.4.77-204-gea4235203137-dirty #2413 [ 15.674510] Hardware name: STM32 (Device Tree Support) [ 15.679658] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 15.687371] [] (show_stack) from [] (dump_stack+0xc0/0xe0) [ 15.694574] [] (dump_stack) from [] (__warn+0xc8/0xf0) [ 15.701428] [] (__warn) from [] (warn_slowpath_fmt+0x60/0x94) [ 15.708894] [] (warn_slowpath_fmt) from [] (clk_core_disable+0xb0/0xc8) [ 15.717230] [] (clk_core_disable) from [] (clk_core_disable_lock+0x18/0x24) [ 15.725924] [] (clk_core_disable_lock) from [] (stm32_rtc_probe+0x124/0x5e4 [rtc_stm32]) [ 15.735739] [] (stm32_rtc_probe [rtc_stm32]) from [] (platform_drv_probe+0x48/0x98) [ 15.745095] [] (platform_drv_probe) from [] (really_probe+0x1f0/0x458) [ 15.753338] [] (really_probe) from [] (driver_probe_device+0x70/0x1c4) [ 15.761584] [] (driver_probe_device) from [] (device_driver_attach+0x58/0x60) [ 15.770439] [] (device_driver_attach) from [] (__driver_attach+0xcc/0x170) [ 15.779032] [] (__driver_attach) from [] (bus_for_each_dev+0x58/0x7c) [ 15.787191] [] (bus_for_each_dev) from [] (bus_add_driver+0xdc/0x1f8) [ 15.795352] [] (bus_add_driver) from [] (driver_register+0x7c/0x110) [ 15.803425] [] (driver_register) from [] (do_one_initcall+0x70/0x1b8) [ 15.811588] [] (do_one_initcall) from [] (do_init_module+0x58/0x1f8) [ 15.819660] [] (do_init_module) from [] (load_module+0x1e58/0x23c8) [ 15.827646] [] (load_module) from [] (sys_finit_module+0xa0/0xd4) [ 15.835459] [] (sys_finit_module) from [] (__sys_trace_return+0x0/0x20) Signed-off-by: Martin Fuzzey Fixes: 4e64350f42e2 ("rtc: add STM32 RTC driver") Cc: stable@vger.kernel.org Reviewed-by: Nobuhiro Iwamatsu Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/1623087421-19722-1-git-send-email-martin.fuzzey@flowbird.group Signed-off-by: Greg Kroah-Hartman commit 468fd1960b4ff74785224418f7c0ce873560e8bc Author: Dinh Nguyen Date: Thu Jun 10 21:52:00 2021 -0500 clk: agilex/stratix10: add support for the 2nd bypass commit c2c9c5661a48bf2e67dcb4e989003144304acd6a upstream. The EMAC clocks on Stratix10/Agilex/N5X have an additional bypass that was not being accounted for. The bypass selects between emaca_clk/emacb_clk and boot_clk. Because the bypass register offset is different between Stratix10 and Agilex/N5X, it's best to create a new function to calculate the bypass. Fixes: 80c6b7a0894f ("clk: socfpga: agilex: add clock driver for the Agilex platform") Cc: stable@vger.kernel.org Signed-off-by: Dinh Nguyen Link: https://lore.kernel.org/r/20210611025201.118799-3-dinguyen@kernel.org Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit e6b46c20ccdae9041d2a38b50f8fb58a4cd50f96 Author: Dinh Nguyen Date: Thu Jun 10 21:51:59 2021 -0500 clk: agilex/stratix10: fix bypass representation commit 6855ee839699bdabb4b16cf942557fd763bcb1fa upstream. Each of these clocks(s2f_usr0/1, sdmmc_clk, gpio_db, emac_ptp, emac0/1/2) have a bypass setting that can use the boot_clk. The previous representation was not correct. Fix the representation. Fixes: 80c6b7a0894f ("clk: socfpga: agilex: add clock driver for the Agilex platform") Cc: stable@vger.kernel.org Signed-off-by: Dinh Nguyen Link: https://lore.kernel.org/r/20210611025201.118799-2-dinguyen@kernel.org Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit acfd0d44231ebf4fc81f3c75df6c7150c0397ccf Author: Dinh Nguyen Date: Thu Jun 10 21:51:58 2021 -0500 clk: agilex/stratix10: remove noc_clk commit efbe21df3e889c0f4bf682c2b7e2465d60b0127c upstream. Early documentation had a noc_clk, but in reality, it's just the noc_free_clk. Remove the noc_clk clock and just use the noc_free_clk. Fixes: 80c6b7a0894f ("clk: socfpga: agilex: add clock driver for the Agilex platform") Cc: stable@vger.kernel.org Signed-off-by: Dinh Nguyen Link: https://lore.kernel.org/r/20210611025201.118799-1-dinguyen@kernel.org Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 55f03f3bed1912567e6bfd7475661b19f016061c Author: Dinh Nguyen Date: Thu Jun 10 21:52:01 2021 -0500 clk: agilex/stratix10/n5x: fix how the bypass_reg is handled commit dfd1427c3769ba51297777dbb296f1802d72dbf6 upstream. If the bypass_reg is set, then we can return the bypass parent, however, if there is not a bypass_reg, we need to figure what the correct parent mux is. The previous code never handled the parent mux if there was a bypass_reg. Fixes: 80c6b7a0894f ("clk: socfpga: agilex: add clock driver for the Agilex platform") Cc: stable@vger.kernel.org Signed-off-by: Dinh Nguyen Link: https://lore.kernel.org/r/20210611025201.118799-4-dinguyen@kernel.org Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 6c1265d7d32dfa5752d53cfa955ae8176f30a791 Author: Damien Le Moal Date: Tue Jun 22 15:45:02 2021 +0900 clk: k210: Fix k210_clk_set_parent() commit faa0e307948594b4379a86fff7fb2409067aed6f upstream. In k210_clk_set_parent(), add missing writel() call to update the mux register of a clock to change its parent. This also fixes a compilation warning with clang when compiling with W=1. Fixes: c6ca7616f7d5 ("clk: Add RISC-V Canaan Kendryte K210 clock driver") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Link: https://lore.kernel.org/r/20210622064502.14841-1-damien.lemoal@wdc.com Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit a97c0590bde4a703307d331bea1a436bb745c0ba Author: Shin'ichiro Kawasaki Date: Mon May 10 20:24:44 2021 +0900 f2fs: Prevent swap file in LFS mode commit d927ccfccb009ede24448d69c08b12e7c8a6979b upstream. The kernel writes to swap files on f2fs directly without the assistance of the filesystem. This direct write by kernel can be non-sequential even when the f2fs is in LFS mode. Such non-sequential write conflicts with the LFS semantics. Especially when f2fs is set up on zoned block devices, the non-sequential write causes unaligned write command errors. To avoid the non-sequential writes to swap files, prevent swap file activation when the filesystem is in LFS mode. Fixes: 4969c06a0d83 ("f2fs: support swap file w/ DIO") Signed-off-by: Shin'ichiro Kawasaki Cc: stable@vger.kernel.org # v5.10+ Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 7b8881bcd7f32ac8ac7ddd238805decfa88d1324 Author: Daniel Rosenberg Date: Thu Jun 3 09:50:38 2021 +0000 f2fs: Advertise encrypted casefolding in sysfs commit 4c039d5452691fe80260e4c3dd7b629a095bd0a7 upstream. Older kernels don't support encryption with casefolding. This adds the sysfs entry encrypted_casefold to show support for those combined features. Support for this feature was originally added by commit 7ad08a58bf67 ("f2fs: Handle casefolding with Encryption") Fixes: 7ad08a58bf67 ("f2fs: Handle casefolding with Encryption") Cc: stable@vger.kernel.org # v5.11+ Signed-off-by: Daniel Rosenberg Reviewed-by: Eric Biggers Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 1254698f9d631fd67ecdf076a45cc09a226969af Author: Janosch Frank Date: Tue Jan 12 05:40:53 2021 -0500 s390: mm: Fix secure storage access exception handling commit 85b18d7b5e7ffefb2f076186511d39c4990aa005 upstream. Turns out that the bit 61 in the TEID is not always 1 and if that's the case the address space ID and the address are unpredictable. Without an address and its address space ID we can't export memory and hence we can only send a SIGSEGV to the process or panic the kernel depending on who caused the exception. Unfortunately bit 61 is only reliable if we have the "misc" UV feature bit. Signed-off-by: Janosch Frank Reviewed-by: Christian Borntraeger Fixes: 084ea4d611a3d ("s390/mm: add (non)secure page access exceptions handlers") Cc: stable@vger.kernel.org Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 81bb61abaceb98a7247ebd1a9c7cd227faf434fb Author: Vineeth Vijayan Date: Wed Jun 9 09:21:08 2021 +0200 s390/cio: dont call css_wait_for_slow_path() inside a lock commit c749d8c018daf5fba6dfac7b6c5c78b27efd7d65 upstream. Currently css_wait_for_slow_path() gets called inside the chp->lock. The path-verification-loop of slowpath inside this lock could lead to deadlock as reported by the lockdep validator. The ccw_device_get_chp_desc() during the instance of a device-set-online would try to acquire the same 'chp->lock' to read the chp->desc. The instance of this function can get called from multiple scenario, like probing or setting-device online manually. This could, in some corner-cases lead to the deadlock. lockdep validator reported this as, CPU0 CPU1 ---- ---- lock(&chp->lock); lock(kn->active#43); lock(&chp->lock); lock((wq_completion)cio); The chp->lock was introduced to serialize the access of struct channel_path. This lock is not needed for the css_wait_for_slow_path() function, so invoke the slow-path function outside this lock. Fixes: b730f3a93395 ("[S390] cio: add lock to struct channel_path") Cc: Reviewed-by: Peter Oberparleiter Signed-off-by: Vineeth Vijayan Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 6bb7392f63653d6c01b20363bca3ac35789d0a83 Author: Sean Christopherson Date: Tue Jun 22 10:56:51 2021 -0700 KVM: x86: Force all MMUs to reinitialize if guest CPUID is modified commit 49c6f8756cdffeb9af1fbcb86bacacced26465d7 upstream. Invalidate all MMUs' roles after a CPUID update to force reinitizliation of the MMU context/helpers. Despite the efforts of commit de3ccd26fafc ("KVM: MMU: record maximum physical address width in kvm_mmu_extended_role"), there are still a handful of CPUID-based properties that affect MMU behavior but are not incorporated into mmu_role. E.g. 1gb hugepage support, AMD vs. Intel handling of bit 8, and SEV's C-Bit location all factor into the guest's reserved PTE bits. The obvious alternative would be to add all such properties to mmu_role, but doing so provides no benefit over simply forcing a reinitialization on every CPUID update, as setting guest CPUID is a rare operation. Note, reinitializing all MMUs after a CPUID update does not fix all of KVM's woes. Specifically, kvm_mmu_page_role doesn't track the CPUID properties, which means that a vCPU can reuse shadow pages that should not exist for the new vCPU model, e.g. that map GPAs that are now illegal (due to MAXPHYADDR changes) or that set bits that are now reserved (PAGE_SIZE for 1gb pages), etc... Tracking the relevant CPUID properties in kvm_mmu_page_role would address the majority of problems, but fully tracking that much state in the shadow page role comes with an unpalatable cost as it would require a non-trivial increase in KVM's memory footprint. The GBPAGES case is even worse, as neither Intel nor AMD provides a way to disable 1gb hugepage support in the hardware page walker, i.e. it's a virtualization hole that can't be closed when using TDP. In other words, resetting the MMU after a CPUID update is largely a superficial fix. But, it will allow reverting the tracking of MAXPHYADDR in the mmu_role, and that case in particular needs to mostly work because KVM's shadow_root_level depends on guest MAXPHYADDR when 5-level paging is supported. For cases where KVM botches guest behavior, the damage is limited to that guest. But for the shadow_root_level, a misconfigured MMU can cause KVM to incorrectly access memory, e.g. due to walking off the end of its shadow page tables. Fixes: 7dcd57552008 ("x86/kvm/mmu: check if tdp/shadow MMU reconfiguration is needed") Cc: Yu Zhang Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20210622175739.3610207-7-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 40928ae22323a2a3b9233f430ed7cbbede435170 Author: Sean Christopherson Date: Tue Jun 22 10:56:48 2021 -0700 KVM: x86: Properly reset MMU context at vCPU RESET/INIT commit 0aa1837533e5f4be8cc21bbc06314c23ba2c5447 upstream. Reset the MMU context at vCPU INIT (and RESET for good measure) if CR0.PG was set prior to INIT. Simply re-initializing the current MMU is not sufficient as the current root HPA may not be usable in the new context. E.g. if TDP is disabled and INIT arrives while the vCPU is in long mode, KVM will fail to switch to the 32-bit pae_root and bomb on the next VM-Enter due to running with a 64-bit CR3 in 32-bit mode. This bug was papered over in both VMX and SVM, but still managed to rear its head in the MMU role on VMX. Because EFER.LMA=1 requires CR0.PG=1, kvm_calc_shadow_mmu_root_page_role() checks for EFER.LMA without first checking CR0.PG. VMX's RESET/INIT flow writes CR0 before EFER, and so an INIT with the vCPU in 64-bit mode will cause the hack-a-fix to generate the wrong MMU role. In VMX, the INIT issue is specific to running without unrestricted guest since unrestricted guest is available if and only if EPT is enabled. Commit 8668a3c468ed ("KVM: VMX: Reset mmu context when entering real mode") resolved the issue by forcing a reset when entering emulated real mode. In SVM, commit ebae871a509d ("kvm: svm: reset mmu on VCPU reset") forced a MMU reset on every INIT to workaround the flaw in common x86. Note, at the time the bug was fixed, the SVM problem was exacerbated by a complete lack of a CR4 update. The vendor resets will be reverted in future patches, primarily to aid bisection in case there are non-INIT flows that rely on the existing VMX logic. Because CR0.PG is unconditionally cleared on INIT, and because CR0.WP and all CR4/EFER paging bits are ignored if CR0.PG=0, simply checking that CR0.PG was '1' prior to INIT/RESET is sufficient to detect a required MMU context reset. Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20210622175739.3610207-4-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 88edf696be93ae33b35daef56fd4d0091d433cd8 Author: Sean Christopherson Date: Tue Jun 22 10:56:49 2021 -0700 KVM: x86/mmu: Use MMU's role to detect CR4.SMEP value in nested NPT walk commit ef318b9edf66a082f23d00d79b70c17b4c055a26 upstream. Use the MMU's role to get its effective SMEP value when injecting a fault into the guest. When walking L1's (nested) NPT while L2 is active, vCPU state will reflect L2, whereas NPT uses the host's (L1 in this case) CR0, CR4, EFER, etc... If L1 and L2 have different settings for SMEP and L1 does not have EFER.NX=1, this can result in an incorrect PFEC.FETCH when injecting #NPF. Fixes: e57d4a356ad3 ("KVM: Add instruction fetch checking when walking guest page table") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20210622175739.3610207-5-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 66b1a19cfbacdcb0260135643cd7f81ca43f409a Author: Sean Christopherson Date: Tue Jun 22 10:56:47 2021 -0700 KVM: x86/mmu: Treat NX as used (not reserved) for all !TDP shadow MMUs commit 112022bdb5bc372e00e6e43cb88ee38ea67b97bd upstream. Mark NX as being used for all non-nested shadow MMUs, as KVM will set the NX bit for huge SPTEs if the iTLB mutli-hit mitigation is enabled. Checking the mitigation itself is not sufficient as it can be toggled on at any time and KVM doesn't reset MMU contexts when that happens. KVM could reset the contexts, but that would require purging all SPTEs in all MMUs, for no real benefit. And, KVM already forces EFER.NX=1 when TDP is disabled (for WP=0, SMEP=1, NX=0), so technically NX is never reserved for shadow MMUs. Fixes: b8e8c8303ff2 ("kvm: mmu: ITLB_MULTIHIT mitigation") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20210622175739.3610207-3-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 60ef300a34de974ba843b342ad0effcb8f45edb1 Author: Sean Christopherson Date: Tue Jun 22 10:56:46 2021 -0700 KVM: x86/mmu: Remove broken WARN that fires on 32-bit KVM w/ nested EPT commit f0d4379087d8a83f478b371ff7786e8df0cc2314 upstream. Remove a misguided WARN that attempts to detect the scenario where using a special A/D tracking flag will set reserved bits on a non-MMIO spte. The WARN triggers false positives when using EPT with 32-bit KVM because of the !64-bit clause, which is just flat out wrong. The whole A/D tracking goo is specific to EPT, and one of the big selling points of EPT is that EPT is decoupled from the host's native paging mode. Drop the WARN instead of trying to salvage the check. Keeping a check specific to A/D tracking bits would essentially regurgitate the same code that led to KVM needed the tracking bits in the first place. A better approach would be to add a generic WARN on reserved bits being set, which would naturally cover the A/D tracking bits, work for all flavors of paging, and be self-documenting to some extent. Fixes: 8a406c89532c ("KVM: x86/mmu: Rename and document A/D scheme for TDP SPTEs") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20210622175739.3610207-2-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit c3439d333f2dc7aa9ade2e609e7bf94e448dc489 Author: Nathan Chancellor Date: Mon Jun 21 11:24:40 2021 -0700 KVM: PPC: Book3S HV: Workaround high stack usage with clang commit 51696f39cbee5bb684e7959c0c98b5f54548aa34 upstream. LLVM does not emit optimal byteswap assembly, which results in high stack usage in kvmhv_enter_nested_guest() due to the inlining of byteswap_pt_regs(). With LLVM 12.0.0: arch/powerpc/kvm/book3s_hv_nested.c:289:6: error: stack frame size of 2512 bytes in function 'kvmhv_enter_nested_guest' [-Werror,-Wframe-larger-than=] long kvmhv_enter_nested_guest(struct kvm_vcpu *vcpu) ^ 1 error generated. While this gets fixed in LLVM, mark byteswap_pt_regs() as noinline_for_stack so that it does not get inlined and break the build due to -Werror by default in arch/powerpc/. Not inlining saves approximately 800 bytes with LLVM 12.0.0: arch/powerpc/kvm/book3s_hv_nested.c:290:6: warning: stack frame size of 1728 bytes in function 'kvmhv_enter_nested_guest' [-Wframe-larger-than=] long kvmhv_enter_nested_guest(struct kvm_vcpu *vcpu) ^ 1 warning generated. Cc: stable@vger.kernel.org # v4.20+ Reported-by: kernel test robot Signed-off-by: Nathan Chancellor Signed-off-by: Michael Ellerman Link: https://github.com/ClangBuiltLinux/linux/issues/1292 Link: https://bugs.llvm.org/show_bug.cgi?id=49610 Link: https://lore.kernel.org/r/202104031853.vDT0Qjqj-lkp@intel.com/ Link: https://gist.github.com/ba710e3703bf45043a31e2806c843ffd Link: https://lore.kernel.org/r/20210621182440.990242-1-nathan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 79739fc3cfdd1e44e34ac23039dfb45da47f32e1 Author: Sean Christopherson Date: Tue Jun 22 10:22:44 2021 -0700 KVM: nVMX: Handle split-lock #AC exceptions that happen in L2 commit b33bb78a1fada6445c265c585ee0dd0fc6279102 upstream. Mark #ACs that won't be reinjected to the guest as wanted by L0 so that KVM handles split-lock #AC from L2 instead of forwarding the exception to L1. Split-lock #AC isn't yet virtualized, i.e. L1 will treat it like a regular #AC and do the wrong thing, e.g. reinject it into L2. Fixes: e6f8b6c12f03 ("KVM: VMX: Extend VMXs #AC interceptor to handle split lock #AC in guest") Cc: Xiaoyao Li Signed-off-by: Sean Christopherson Message-Id: <20210622172244.3561540-1-seanjc@google.com> Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 283d80b859f82fc3d755e703d786b7a23dc1a5cc Author: Robin Murphy Date: Tue Jun 8 12:55:12 2021 +0100 perf/smmuv3: Don't trample existing events with global filter commit 4c1daba15c209b99d192f147fea3dade30f72ed2 upstream. With global filtering, we only allow an event to be scheduled if its filter settings exactly match those of any existing events, therefore it is pointless to reapply the filter in that case. Much worse, though, is that in doing that we trample the event type of counter 0 if it's already active, and never touch the appropriate PMEVTYPERn so the new event is likely not counting the right thing either. Don't do that. CC: stable@vger.kernel.org Signed-off-by: Robin Murphy Link: https://lore.kernel.org/r/32c80c0e46237f49ad8da0c9f8864e13c4a803aa.1623153312.git.robin.murphy@arm.com Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 562521b6fb3772d3f6f166f47a827dcde0351b75 Author: Jann Horn Date: Mon Jun 28 19:33:23 2021 -0700 mm/gup: fix try_grab_compound_head() race with split_huge_page() commit c24d37322548a6ec3caec67100d28b9c1f89f60a upstream. try_grab_compound_head() is used to grab a reference to a page from get_user_pages_fast(), which is only protected against concurrent freeing of page tables (via local_irq_save()), but not against concurrent TLB flushes, freeing of data pages, or splitting of compound pages. Because no reference is held to the page when try_grab_compound_head() is called, the page may have been freed and reallocated by the time its refcount has been elevated; therefore, once we're holding a stable reference to the page, the caller re-checks whether the PTE still points to the same page (with the same access rights). The problem is that try_grab_compound_head() has to grab a reference on the head page; but between the time we look up what the head page is and the time we actually grab a reference on the head page, the compound page may have been split up (either explicitly through split_huge_page() or by freeing the compound page to the buddy allocator and then allocating its individual order-0 pages). If that happens, get_user_pages_fast() may end up returning the right page but lifting the refcount on a now-unrelated page, leading to use-after-free of pages. To fix it: Re-check whether the pages still belong together after lifting the refcount on the head page. Move anything else that checks compound_head(page) below the refcount increment. This can't actually happen on bare-metal x86 (because there, disabling IRQs locks out remote TLB flushes), but it can happen on virtualized x86 (e.g. under KVM) and probably also on arm64. The race window is pretty narrow, and constantly allocating and shattering hugepages isn't exactly fast; for now I've only managed to reproduce this in an x86 KVM guest with an artificially widened timing window (by adding a loop that repeatedly calls `inl(0x3f8 + 5)` in `try_get_compound_head()` to force VM exits, so that PV TLB flushes are used instead of IPIs). As requested on the list, also replace the existing VM_BUG_ON_PAGE() with a warning and bailout. Since the existing code only performed the BUG_ON check on DEBUG_VM kernels, ensure that the new code also only performs the check under that configuration - I don't want to mix two logically separate changes together too much. The macro VM_WARN_ON_ONCE_PAGE() doesn't return a value on !DEBUG_VM, so wrap the whole check in an #ifdef block. An alternative would be to change the VM_WARN_ON_ONCE_PAGE() definition for !DEBUG_VM such that it always returns false, but since that would differ from the behavior of the normal WARN macros, it might be too confusing for readers. Link: https://lkml.kernel.org/r/20210615012014.1100672-1-jannh@google.com Fixes: 7aef4172c795 ("mm: handle PTE-mapped tail pages in gerneric fast gup implementaiton") Signed-off-by: Jann Horn Reviewed-by: John Hubbard Cc: Matthew Wilcox Cc: Kirill A. Shutemov Cc: Jan Kara Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 38a5c79ea17b534a15f133787ac7d923a18046b1 Author: Christophe JAILLET Date: Mon Jun 21 21:46:13 2021 +0530 bus: mhi: pci-generic: Add missing 'pci_disable_pcie_error_reporting()' calls commit a25d144fb883c73506ba384de476bbaff8220a95 upstream. If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it must be undone by a corresponding 'pci_disable_pcie_error_reporting()' call Add the missing call in the error handling path of the probe and in the remove function. Cc: Fixes: b012ee6bfe2a ("mhi: pci_generic: Add PCI error handlers") Signed-off-by: Christophe JAILLET Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/f70c14701f4922d67e717633c91b6c481b59f298.1623445348.git.christophe.jaillet@wanadoo.fr Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20210621161616.77524-6-manivannan.sadhasivam@linaro.org Signed-off-by: Greg Kroah-Hartman commit b98470e38ae27d4e73b2c23ea9c754c4e2670b1e Author: Baochen Qiang Date: Mon Jun 21 21:46:11 2021 +0530 bus: mhi: Wait for M2 state during system resume commit 02b49cd1174527e611768fc2ce0f75a74dfec7ae upstream. During system resume, MHI host triggers M3->M0 transition and then waits for target device to enter M0 state. Once done, the device queues a state change event into ctrl event ring and notifies MHI host by raising an interrupt, where a tasklet is scheduled to process this event. In most cases, the tasklet is served timely and wait operation succeeds. However, there are cases where CPU is busy and cannot serve this tasklet for some time. Once delay goes long enough, the device moves itself to M1 state and also interrupts MHI host after inserting a new state change event to ctrl ring. Later when CPU finally has time to process the ring, there will be two events: 1. For M3->M0 event, which is the first event to be processed queued first. The tasklet handler serves the event, updates device state to M0 and wakes up the task. 2. For M0->M1 event, which is processed later, the tasklet handler triggers M1->M2 transition and updates device state to M2 directly, then wakes up the MHI host (if it is still sleeping on this wait queue). Note that although MHI host has been woken up while processing the first event, it may still has no chance to run before the second event is processed. In other words, MHI host has to keep waiting till timeout causing the M0 state to be missed. kernel log here: ... Apr 15 01:45:14 test-NUC8i7HVK kernel: [ 4247.911251] mhi 0000:06:00.0: Entered with PM state: M3, MHI state: M3 Apr 15 01:45:14 test-NUC8i7HVK kernel: [ 4247.917762] mhi 0000:06:00.0: State change event to state: M0 Apr 15 01:45:14 test-NUC8i7HVK kernel: [ 4247.917767] mhi 0000:06:00.0: State change event to state: M1 Apr 15 01:45:14 test-NUC8i7HVK kernel: [ 4338.788231] mhi 0000:06:00.0: Did not enter M0 state, MHI state: M2, PM state: M2 ... Fix this issue by simply adding M2 as a valid state for resume. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Cc: stable@vger.kernel.org Fixes: 0c6b20a1d720 ("bus: mhi: core: Add support for MHI suspend and resume") Signed-off-by: Baochen Qiang Reviewed-by: Hemant Kumar Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20210524040312.14409-1-bqiang@codeaurora.org [mani: slightly massaged the commit message] Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20210621161616.77524-4-manivannan.sadhasivam@linaro.org Signed-off-by: Greg Kroah-Hartman commit 0b509e3ec35df9a6207bb85edb8451f54770af7b Author: Loic Poulain Date: Mon Jun 21 21:46:10 2021 +0530 bus: mhi: core: Fix power down latency commit 44b1eba44dc537edf076f131f1eeee7544d0e04f upstream. On graceful power-down/disable transition, when an MHI reset is performed, the MHI device loses its context, including interrupt configuration. However, the current implementation is waiting for event(irq) driven state change to confirm reset has been completed, which never happens, and causes reset timeout, leading to unexpected high latency of the mhi_power_down procedure (up to 45 seconds). Fix that by moving to the recently introduced poll_reg_field method, waiting for the reset bit to be cleared, in the same way as the power_on procedure. Cc: stable@vger.kernel.org Fixes: a6e2e3522f29 ("bus: mhi: core: Add support for PM state transitions") Signed-off-by: Loic Poulain Reviewed-by: Bhaumik Bhatt Reviewed-by: Manivannan Sadhasivam Reviewed-by: Hemant Kumar Link: https://lore.kernel.org/r/1620029090-8975-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20210621161616.77524-3-manivannan.sadhasivam@linaro.org Signed-off-by: Greg Kroah-Hartman commit 0530021455af9c2a3073cd41ecf5f9a4168a34ac Author: Zhang Xiaoxu Date: Sat Jun 26 15:50:42 2021 +0800 SUNRPC: Should wake up the privileged task firstly. commit 5483b904bf336948826594610af4c9bbb0d9e3aa upstream. When find a task from wait queue to wake up, a non-privileged task may be found out, rather than the privileged. This maybe lead a deadlock same as commit dfe1fe75e00e ("NFSv4: Fix deadlock between nfs4_evict_inode() and nfs4_opendata_get_inode()"): Privileged delegreturn task is queued to privileged list because all the slots are assigned. If there has no enough slot to wake up the non-privileged batch tasks(session less than 8 slot), then the privileged delegreturn task maybe lost waked up because the found out task can't get slot since the session is on draining. So we should treate the privileged task as the emergency task, and execute it as for as we can. Reported-by: Hulk Robot Fixes: 5fcdfacc01f3 ("NFSv4: Return delegations synchronously in evict_inode") Cc: stable@vger.kernel.org Signed-off-by: Zhang Xiaoxu Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit e66509e7c90ab72dec838594fbfa128f1a0a5730 Author: Zhang Xiaoxu Date: Sat Jun 26 15:50:41 2021 +0800 SUNRPC: Fix the batch tasks count wraparound. commit fcb170a9d825d7db4a3fb870b0300f5a40a8d096 upstream. The 'queue->nr' will wraparound from 0 to 255 when only current priority queue has tasks. This maybe lead a deadlock same as commit dfe1fe75e00e ("NFSv4: Fix deadlock between nfs4_evict_inode() and nfs4_opendata_get_inode()"): Privileged delegreturn task is queued to privileged list because all the slots are assigned. When non-privileged task complete and release the slot, a non-privileged maybe picked out. It maybe allocate slot failed when the session on draining. If the 'queue->nr' has wraparound to 255, and no enough slot to service it, then the privileged delegreturn will lost to wake up. So we should avoid the wraparound on 'queue->nr'. Reported-by: Hulk Robot Fixes: 5fcdfacc01f3 ("NFSv4: Return delegations synchronously in evict_inode") Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Zhang Xiaoxu Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 18836fcf7a291d19cc05161e898c6f8416dd32c9 Author: Abinaya Kalaiselvan Date: Wed Jun 23 20:10:44 2021 +0530 mac80211: fix NULL ptr dereference during mesh peer connection for non HE devices commit 95f83ee8d857f006813755e89a126f1048b001e8 upstream. "sband->iftype_data" is not assigned with any value for non HE supported devices, which causes NULL pointer access during mesh peer connection in those devices. Fix this by accessing the pointer after HE capabilities condition check. Cc: stable@vger.kernel.org Fixes: 7f7aa94bcaf0 (mac80211: reduce peer HE MCS/NSS to own capabilities) Signed-off-by: Abinaya Kalaiselvan Link: https://lore.kernel.org/r/1624459244-4497-1-git-send-email-akalaise@codeaurora.org Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 4cc6ec81f98711cc3173a272177830bda244320b Author: Felix Fietkau Date: Sat Jun 19 12:15:17 2021 +0200 mac80211: remove iwlwifi specific workaround that broke sta NDP tx commit e41eb3e408de27982a5f8f50b2dd8002bed96908 upstream. Sending nulldata packets is important for sw AP link probing and detecting 4-address mode links. The checks that dropped these packets were apparently added to work around an iwlwifi firmware bug with multi-TID aggregation. Fixes: 41cbb0f5a295 ("mac80211: add support for HE") Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau Link: https://lore.kernel.org/r/20210619101517.90806-1-nbd@nbd.name Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 9e59c8d4172cb1330456b1664aca12998506e529 Author: Stephane Grosjean Date: Wed Jun 23 16:26:00 2021 +0200 can: peak_pciefd: pucan_handle_status(): fix a potential starvation issue in TX path commit b17233d385d0b6b43ecf81d43008cb1bbb008166 upstream. Rather than just indicating that transmission can start, this patch requires the explicit flushing of the network TX queue when the driver is informed by the device that it can transmit, next to its configuration. In this way, if frames have already been written by the application, they will actually be transmitted. Fixes: ffd137f7043c ("can: peak/pcie_fd: remove useless code when interface starts") Link: https://lore.kernel.org/r/20210623142600.149904-1-s.grosjean@peak-system.com Cc: linux-stable Signed-off-by: Stephane Grosjean Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 54dc7c15743eac57e95cceccb255ffde204798d7 Author: Oleksij Rempel Date: Thu Jun 17 15:06:23 2021 +0200 can: j1939: j1939_sk_init(): set SOCK_RCU_FREE to call sk_destruct() after RCU is done commit 22c696fed25c63c7f67508309820358b94a96b6d upstream. Set SOCK_RCU_FREE to let RCU to call sk_destruct() on completion. Without this patch, we will run in to j1939_can_recv() after priv was freed by j1939_sk_release()->j1939_sk_sock_destruct() Fixes: 25fe97cb7620 ("can: j1939: move j1939_priv_put() into sk_destruct callback") Link: https://lore.kernel.org/r/20210617130623.12705-1-o.rempel@pengutronix.de Cc: linux-stable Reported-by: Thadeu Lima de Souza Cascardo Reported-by: syzbot+bdf710cfc41c186fdff3@syzkaller.appspotmail.com Signed-off-by: Oleksij Rempel Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit ebf91625b3e404bd2b4b694c7ee71c1e8f8bd08f Author: Oliver Hartkopp Date: Fri Jun 18 19:37:13 2021 +0200 can: isotp: isotp_release(): omit unintended hrtimer restart on socket release commit 14a4696bc3118ba49da28f79280e1d55603aa737 upstream. When closing the isotp socket, the potentially running hrtimers are canceled before removing the subscription for CAN identifiers via can_rx_unregister(). This may lead to an unintended (re)start of a hrtimer in isotp_rcv_cf() and isotp_rcv_fc() in the case that a CAN frame is received by isotp_rcv() while the subscription removal is processed. However, isotp_rcv() is called under RCU protection, so after calling can_rx_unregister, we may call synchronize_rcu in order to wait for any RCU read-side critical sections to finish. This prevents the reception of CAN frames after hrtimer_cancel() and therefore the unintended (re)start of the hrtimers. Link: https://lore.kernel.org/r/20210618173713.2296-1-socketcan@hartkopp.net Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol") Cc: linux-stable Signed-off-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 2e934deaa8fd8a21a07d31f96cc588be8df0ddad Author: Oliver Hartkopp Date: Fri Jun 18 19:36:45 2021 +0200 can: gw: synchronize rcu operations before removing gw job entry commit fb8696ab14adadb2e3f6c17c18ed26b3ecd96691 upstream. can_can_gw_rcv() is called under RCU protection, so after calling can_rx_unregister(), we have to call synchronize_rcu in order to wait for any RCU read-side critical sections to finish before removing the kmem_cache entry with the referenced gw job entry. Link: https://lore.kernel.org/r/20210618173645.2238-1-socketcan@hartkopp.net Fixes: c1aabdf379bc ("can-gw: add netlink based CAN routing") Cc: linux-stable Signed-off-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 014f8baa9d240c4cf7180d37abd625fd4a4527c8 Author: Thadeu Lima de Souza Cascardo Date: Sat Jun 19 13:18:13 2021 -0300 can: bcm: delay release of struct bcm_op after synchronize_rcu() commit d5f9023fa61ee8b94f37a93f08e94b136cf1e463 upstream. can_rx_register() callbacks may be called concurrently to the call to can_rx_unregister(). The callbacks and callback data, though, are protected by RCU and the struct sock reference count. So the callback data is really attached to the life of sk, meaning that it should be released on sk_destruct. However, bcm_remove_op() calls tasklet_kill(), and RCU callbacks may be called under RCU softirq, so that cannot be used on kernels before the introduction of HRTIMER_MODE_SOFT. However, bcm_rx_handler() is called under RCU protection, so after calling can_rx_unregister(), we may call synchronize_rcu() in order to wait for any RCU read-side critical sections to finish. That is, bcm_rx_handler() won't be called anymore for those ops. So, we only free them, after we do that synchronize_rcu(). Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol") Link: https://lore.kernel.org/r/20210619161813.2098382-1-cascardo@canonical.com Cc: linux-stable Reported-by: syzbot+0f7e7e5e2f4f40fa89c0@syzkaller.appspotmail.com Reported-by: Norbert Slusarek Signed-off-by: Thadeu Lima de Souza Cascardo Acked-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 42da0c84419c092aa0b4c0811970e165d175fcc9 Author: Stephen Brennan Date: Wed Jun 23 16:21:14 2021 -0700 ext4: use ext4_grp_locked_error in mb_find_extent commit cd84bbbac12a173a381a64c6ec8b76a5277b87b5 upstream. Commit 5d1b1b3f492f ("ext4: fix BUG when calling ext4_error with locked block group") introduces ext4_grp_locked_error to handle unlocking a group in error cases. Otherwise, there is a possibility of a sleep while atomic. However, since 43c73221b3b1 ("ext4: replace BUG_ON with WARN_ON in mb_find_extent()"), mb_find_extent() has contained a ext4_error() call while a group spinlock is held. Replace this with ext4_grp_locked_error. Fixes: 43c73221b3b1 ("ext4: replace BUG_ON with WARN_ON in mb_find_extent()") Cc: # 4.14+ Signed-off-by: Stephen Brennan Reviewed-by: Lukas Czerner Reviewed-by: Junxiao Bi Link: https://lore.kernel.org/r/20210623232114.34457-1-stephen.s.brennan@oracle.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit e59789c9cdb8cd703c576e09f203dfed0917916c Author: Pan Dong Date: Tue May 25 15:36:56 2021 +0800 ext4: fix avefreec in find_group_orlov commit c89849cc0259f3d33624cc3bd127685c3c0fa25d upstream. The avefreec should be average free clusters instead of average free blocks, otherwize Orlov's allocator will not work properly when bigalloc enabled. Cc: stable@kernel.org Signed-off-by: Pan Dong Link: https://lore.kernel.org/r/20210525073656.31594-1-pandong.peter@bytedance.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 0b2f4710e9dc95b0e1a435d15df7fa851d833d3b Author: Zhang Yi Date: Sat May 22 18:30:44 2021 +0800 ext4: remove check for zero nr_to_scan in ext4_es_scan() commit e5e7010e5444d923e4091cafff61d05f2d19cada upstream. After converting fs shrinkers to new scan/count API, we are no longer pass zero nr_to_scan parameter to detect the number of objects to free, just remove this check. Fixes: 1ab6c4997e04 ("fs: convert fs shrinkers to new scan/count API") Cc: stable@vger.kernel.org # 3.12+ Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20210522103045.690103-2-yi.zhang@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 74983f8c0d03f036ff9bb9e426c9fa10b462683d Author: Zhang Yi Date: Sat May 22 18:30:45 2021 +0800 ext4: correct the cache_nr in tracepoint ext4_es_shrink_exit commit 4fb7c70a889ead2e91e184895ac6e5354b759135 upstream. The cache_cnt parameter of tracepoint ext4_es_shrink_exit means the remaining cache count after shrink, but now it is the cache count before shrink, fix it by read sbi->s_extent_cache_cnt again. Fixes: 1ab6c4997e04 ("fs: convert fs shrinkers to new scan/count API") Cc: stable@vger.kernel.org # 3.12+ Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20210522103045.690103-3-yi.zhang@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 9785e209bc203199f1bd809f1bcbbff1b18ddcb5 Author: Yang Yingliang Date: Mon May 10 19:10:51 2021 +0800 ext4: return error code when ext4_fill_flex_info() fails commit 8f6840c4fd1e7bd715e403074fb161c1a04cda73 upstream. After commit c89128a00838 ("ext4: handle errors on ext4_commit_super"), 'ret' may be set to 0 before calling ext4_fill_flex_info(), if ext4_fill_flex_info() fails ext4_mount() doesn't return error code, it makes 'root' is null which causes crash in legacy_get_tree(). Fixes: c89128a00838 ("ext4: handle errors on ext4_commit_super") Reported-by: Hulk Robot Cc: # v4.18+ Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20210510111051.55650-1-yangyingliang@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 1e60f8ff27bee2ff05d5f83bdd6a311a047fb7c1 Author: Jan Kara Date: Mon Apr 12 12:23:33 2021 +0200 ext4: fix overflow in ext4_iomap_alloc() commit d0b040f5f2557b2f507c01e88ad8cff424fdc6a9 upstream. A code in iomap alloc may overflow block number when converting it to byte offset. Luckily this is mostly harmless as we will just use more expensive method of writing using unwritten extents even though we are writing beyond i_size. Cc: stable@kernel.org Fixes: 378f32bab371 ("ext4: introduce direct I/O write using iomap infrastructure") Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20210412102333.2676-4-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit befdd44d46329dc8ab9459c891287cc29f2ef4bf Author: Anirudh Rayabharam Date: Fri May 7 00:26:54 2021 +0530 ext4: fix kernel infoleak via ext4_extent_header commit ce3aba43599f0b50adbebff133df8d08a3d5fffe upstream. Initialize eh_generation of struct ext4_extent_header to prevent leaking info to userspace. Fixes KMSAN kernel-infoleak bug reported by syzbot at: http://syzkaller.appspot.com/bug?id=78e9ad0e6952a3ca16e8234724b2fa92d041b9b8 Cc: stable@kernel.org Reported-by: syzbot+2dcfeaf8cb49b05e8f1a@syzkaller.appspotmail.com Fixes: a86c61812637 ("[PATCH] ext3: add extent map support") Signed-off-by: Anirudh Rayabharam Link: https://lore.kernel.org/r/20210506185655.7118-1-mail@anirudhrb.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 573d64e85e0dd67be2fa89b6f346e34ef5a28618 Author: Zhang Yi Date: Fri May 7 15:19:04 2021 +0800 ext4: cleanup in-core orphan list if ext4_truncate() failed to get a transaction handle commit b9a037b7f3c401d3c63e0423e56aef606b1ffaaf upstream. In ext4_orphan_cleanup(), if ext4_truncate() failed to get a transaction handle, it didn't remove the inode from the in-core orphan list, which may probably trigger below error dump in ext4_destroy_inode() during the final iput() and could lead to memory corruption on the later orphan list changes. EXT4-fs (sda): Inode 6291467 (00000000b8247c67): orphan list check failed! 00000000b8247c67: 0001f30a 00000004 00000000 00000023 ............#... 00000000e24cde71: 00000006 014082a3 00000000 00000000 ......@......... 0000000072c6a5ee: 00000000 00000000 00000000 00000000 ................ ... This patch fix this by cleanup in-core orphan list manually if ext4_truncate() return error. Cc: stable@kernel.org Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20210507071904.160808-1-yi.zhang@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 806f5845757edbf974b29b90eb9f7f94ca45fa57 Author: David Sterba Date: Tue Jul 7 18:30:06 2020 +0200 btrfs: clear defrag status of a root if starting transaction fails commit 6819703f5a365c95488b07066a8744841bf14231 upstream. The defrag loop processes leaves in batches and starting transaction for each. The whole defragmentation on a given root is protected by a bit but in case the transaction fails, the bit is not cleared In case the transaction fails the bit would prevent starting defragmentation again, so make sure it's cleared. CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Qu Wenruo Reviewed-by: Anand Jain Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 1720dde8dfecc4d395e88bc2a08105f83b5e7d61 Author: Naohiro Aota Date: Mon Jun 21 10:21:14 2021 +0900 btrfs: fix unbalanced unlock in qgroup_account_snapshot() commit 44365827cccc1441d4187509257e5276af133a49 upstream. qgroup_account_snapshot() is trying to unlock the not taken tree_log_mutex in a error path. Since ret != 0 in this case, we can just return from here. Fixes: 2a4d84c11a87 ("btrfs: move delayed ref flushing for qgroup into qgroup helper") CC: stable@vger.kernel.org # 5.12+ Reviewed-by: Qu Wenruo Signed-off-by: Naohiro Aota Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 14265d0b84ebd9ea2c5a144f6fb98a2c10df137c Author: David Sterba Date: Mon Jun 14 12:45:18 2021 +0200 btrfs: compression: don't try to compress if we don't have enough pages commit f2165627319ffd33a6217275e5690b1ab5c45763 upstream. The early check if we should attempt compression does not take into account the number of input pages. It can happen that there's only one page, eg. a tail page after some ranges of the BTRFS_MAX_UNCOMPRESSED have been processed, or an isolated page that won't be converted to an inline extent. The single page would be compressed but a later check would drop it again because the result size must be at least one block shorter than the input. That can never work with just one page. CC: stable@vger.kernel.org # 4.4+ Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 661907edc07cd65a0c163e14393acbbe0a2462e0 Author: Filipe Manana Date: Wed Jun 9 11:25:03 2021 +0100 btrfs: send: fix invalid path for unlink operations after parent orphanization commit d8ac76cdd1755b21e8c008c28d0b7251c0b14986 upstream. During an incremental send operation, when processing the new references for the current inode, we might send an unlink operation for another inode that has a conflicting path and has more than one hard link. However this path was computed and cached before we processed previous new references for the current inode. We may have orphanized a directory of that path while processing a previous new reference, in which case the path will be invalid and cause the receiver process to fail. The following reproducer triggers the problem and explains how/why it happens in its comments: $ cat test-send-unlink.sh #!/bin/bash DEV=/dev/sdi MNT=/mnt/sdi mkfs.btrfs -f $DEV >/dev/null mount $DEV $MNT # Create our test files and directory. Inode 259 (file3) has two hard # links. touch $MNT/file1 touch $MNT/file2 touch $MNT/file3 mkdir $MNT/A ln $MNT/file3 $MNT/A/hard_link # Filesystem looks like: # # . (ino 256) # |----- file1 (ino 257) # |----- file2 (ino 258) # |----- file3 (ino 259) # |----- A/ (ino 260) # |---- hard_link (ino 259) # # Now create the base snapshot, which is going to be the parent snapshot # for a later incremental send. btrfs subvolume snapshot -r $MNT $MNT/snap1 btrfs send -f /tmp/snap1.send $MNT/snap1 # Move inode 257 into directory inode 260. This results in computing the # path for inode 260 as "/A" and caching it. mv $MNT/file1 $MNT/A/file1 # Move inode 258 (file2) into directory inode 260, with a name of # "hard_link", moving first inode 259 away since it currently has that # location and name. mv $MNT/A/hard_link $MNT/tmp mv $MNT/file2 $MNT/A/hard_link # Now rename inode 260 to something else (B for example) and then create # a hard link for inode 258 that has the old name and location of inode # 260 ("/A"). mv $MNT/A $MNT/B ln $MNT/B/hard_link $MNT/A # Filesystem now looks like: # # . (ino 256) # |----- tmp (ino 259) # |----- file3 (ino 259) # |----- B/ (ino 260) # | |---- file1 (ino 257) # | |---- hard_link (ino 258) # | # |----- A (ino 258) # Create another snapshot of our subvolume and use it for an incremental # send. btrfs subvolume snapshot -r $MNT $MNT/snap2 btrfs send -f /tmp/snap2.send -p $MNT/snap1 $MNT/snap2 # Now unmount the filesystem, create a new one, mount it and try to # apply both send streams to recreate both snapshots. umount $DEV mkfs.btrfs -f $DEV >/dev/null mount $DEV $MNT # First add the first snapshot to the new filesystem by applying the # first send stream. btrfs receive -f /tmp/snap1.send $MNT # The incremental receive operation below used to fail with the # following error: # # ERROR: unlink A/hard_link failed: No such file or directory # # This is because when send is processing inode 257, it generates the # path for inode 260 as "/A", since that inode is its parent in the send # snapshot, and caches that path. # # Later when processing inode 258, it first processes its new reference # that has the path of "/A", which results in orphanizing inode 260 # because there is a a path collision. This results in issuing a rename # operation from "/A" to "/o260-6-0". # # Finally when processing the new reference "B/hard_link" for inode 258, # it notices that it collides with inode 259 (not yet processed, because # it has a higher inode number), since that inode has the name # "hard_link" under the directory inode 260. It also checks that inode # 259 has two hardlinks, so it decides to issue a unlink operation for # the name "hard_link" for inode 259. However the path passed to the # unlink operation is "/A/hard_link", which is incorrect since currently # "/A" does not exists, due to the orphanization of inode 260 mentioned # before. The path is incorrect because it was computed and cached # before the orphanization. This results in the receiver to fail with # the above error. btrfs receive -f /tmp/snap2.send $MNT umount $MNT When running the test, it fails like this: $ ./test-send-unlink.sh Create a readonly snapshot of '/mnt/sdi' in '/mnt/sdi/snap1' At subvol /mnt/sdi/snap1 Create a readonly snapshot of '/mnt/sdi' in '/mnt/sdi/snap2' At subvol /mnt/sdi/snap2 At subvol snap1 At snapshot snap2 ERROR: unlink A/hard_link failed: No such file or directory Fix this by recomputing a path before issuing an unlink operation when processing the new references for the current inode if we previously have orphanized a directory. A test case for fstests will follow soon. CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit c90d10b45928dce15e917f8dbcda248b79f8130e Author: Johannes Thumshirn Date: Fri Apr 30 15:34:18 2021 +0200 btrfs: zoned: bail out if we can't read a reliable write pointer commit 06e1e7f4223c98965fb721b4b1e12083cfbe777e upstream. If we can't read a reliable write pointer from a sequential zone fail creating the block group with an I/O error. Also if the read write pointer is beyond the end of the respective zone, fail the creation of the block group on this zone with an I/O error. While this could also happen in real world scenarios with misbehaving drives, this issue addresses a problem uncovered by fstests' test case generic/475. CC: stable@vger.kernel.org # 5.12+ Signed-off-by: Johannes Thumshirn Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 2f57967716f424f33d6440519732afa1dd9ccd8e Author: Naohiro Aota Date: Fri Apr 30 15:34:17 2021 +0200 btrfs: zoned: print message when zone sanity check type fails commit 47cdfb5e1dd60422ec2cbc53b667f73ff9a411dc upstream. This extends patch 784daf2b9628 ("btrfs: zoned: sanity check zone type"), the message was supposed to be there but was lost during merge. We want to make the error noticeable so add it. Fixes: 784daf2b9628 ("btrfs: zoned: sanity check zone type") CC: stable@vger.kernel.org # 5.12+ Signed-off-by: Naohiro Aota Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit acae585838aacb5720c4b1b98b2264bf7ab4b62e Author: Ludovic Desroches Date: Fri Oct 25 10:42:10 2019 +0200 ARM: dts: at91: sama5d4: fix pinctrl muxing commit 253adffb0e98eaf6da2e7cf73ae68695e21f2f3c upstream. Fix pinctrl muxing, PD28, PD29 and PD31 can be muxed to peripheral A. It allows to use SCK0, SCK1 and SPI0_NPCS2 signals. Signed-off-by: Ludovic Desroches Fixes: 679f8d92bb01 ("ARM: at91/dt: sama5d4: add pioD pin mux mask and enable pioD") Cc: stable@vger.kernel.org # v4.4+ Reviewed-by: Claudiu Beznea Signed-off-by: Nicolas Ferre Link: https://lore.kernel.org/r/20191025084210.14726-1-ludovic.desroches@microchip.com Signed-off-by: Greg Kroah-Hartman commit e2d7f388bbf71591b6a1711da3e8eb0404532cdc Author: Linus Walleij Date: Sun Jun 13 14:33:56 2021 +0200 ARM: dts: ux500: Fix LED probing commit 7749510c459c10c431d746a4749e7c9cf2899156 upstream. The Ux500 HREF LEDs have not been probing properly for a while as this was introduce: ret = of_property_read_u32(np, "color", &led_color); if (ret) return ret; Since the device tree did not define the new invented color attribute, probe was failing. Define color attributes for the LEDs so they work again. Link: https://lore.kernel.org/r/20210613123356.880933-1-linus.walleij@linaro.org Fixes: 92a81562e695 ("leds: lp55xx: Add multicolor framework support to lp55xx") Cc: stable@vger.kernel.org Cc: Dan Murphy Signed-off-by: Linus Walleij Signed-off-by: Olof Johansson Signed-off-by: Greg Kroah-Hartman commit d6c8a2650306eb11cc07998ef29f28e9714451ab Author: Yang Jihong Date: Fri Apr 30 09:26:59 2021 +0800 arm_pmu: Fix write counter incorrect in ARMv7 big-endian mode commit fdbef8c4e68ad423416aa6cc93d1616d6f8ac5b3 upstream. Commit 3a95200d3f89 ("arm_pmu: Change API to support 64bit counter values") changes the input "value" type from 32-bit to 64-bit, which introduces the following problem: ARMv7 PMU counters is 32-bit width, in big-endian mode, write counter uses high 32-bit, which writes an incorrect value. Before: Performance counter stats for 'ls': 2.22 msec task-clock # 0.675 CPUs utilized 0 context-switches # 0.000 K/sec 0 cpu-migrations # 0.000 K/sec 49 page-faults # 0.022 M/sec 2150476593 cycles # 966.663 GHz 2148588788 instructions # 1.00 insn per cycle 2147745484 branches # 965435.074 M/sec 2147508540 branch-misses # 99.99% of all branches None of the above hw event counters are correct. Solution: "value" forcibly converted to 32-bit type before being written to PMU register. After: Performance counter stats for 'ls': 2.09 msec task-clock # 0.681 CPUs utilized 0 context-switches # 0.000 K/sec 0 cpu-migrations # 0.000 K/sec 46 page-faults # 0.022 M/sec 2807301 cycles # 1.344 GHz 1060159 instructions # 0.38 insn per cycle 250496 branches # 119.914 M/sec 23192 branch-misses # 9.26% of all branches Fixes: 3a95200d3f89 ("arm_pmu: Change API to support 64bit counter values") Cc: Signed-off-by: Yang Jihong Acked-by: Mark Rutland Link: https://lore.kernel.org/r/20210430012659.232110-1-yangjihong1@huawei.com Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 2497ef4cc77bf6429c7cffb24dc45eeee43aa856 Author: Joerg Roedel Date: Mon Apr 26 10:17:48 2021 +0200 crypto: ccp - Annotate SEV Firmware file names commit c8671c7dc7d51125ab9f651697866bf4a9132277 upstream. Annotate the firmware files CCP might need using MODULE_FIRMWARE(). This will get them included into an initrd when CCP is also included there. Otherwise the CCP module will not find its firmware when loaded before the root-fs is mounted. This can cause problems when the pre-loaded SEV firmware is too old to support current SEV and SEV-ES virtualization features. Fixes: e93720606efd ("crypto: ccp - Allow SEV firmware to be chosen based on Family and Model") Cc: stable@vger.kernel.org # v4.20+ Acked-by: Tom Lendacky Signed-off-by: Joerg Roedel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit ef70c1c3cee5ab939e8cce1a6e4fc0e89405f341 Author: Kees Cook Date: Wed Jun 16 13:34:59 2021 -0700 crypto: nx - Fix memcpy() over-reading in nonce commit 74c66120fda6596ad57f41e1607b3a5d51ca143d upstream. Fix typo in memcpy() where size should be CTR_RFC3686_NONCE_SIZE. Fixes: 030f4e968741 ("crypto: nx - Fix reentrancy bugs") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 81acf1015233b3ee1d9834ba4fcca087a75c0c1b Author: Alexander Larkin Date: Sun Jul 4 22:39:36 2021 -0700 Input: joydev - prevent use of not validated data in JSIOCSBTNMAP ioctl commit f8f84af5da9ee04ef1d271528656dac42a090d00 upstream. Even though we validate user-provided inputs we then traverse past validated data when applying the new map. The issue was originally discovered by Murray McAllister with this simple POC (if the following is executed by an unprivileged user it will instantly panic the system): int main(void) { int fd, ret; unsigned int buffer[10000]; fd = open("/dev/input/js0", O_RDONLY); if (fd == -1) printf("Error opening file\n"); ret = ioctl(fd, JSIOCSBTNMAP & ~IOCSIZE_MASK, &buffer); printf("%d\n", ret); } The solution is to traverse internal buffer which is guaranteed to only contain valid date when constructing the map. Fixes: 182d679b2298 ("Input: joydev - prevent potential read overflow in ioctl") Fixes: 999b874f4aa3 ("Input: joydev - validate axis/button maps before clobbering current ones") Reported-by: Murray McAllister Suggested-by: Linus Torvalds Signed-off-by: Alexander Larkin Link: https://lore.kernel.org/r/20210620120030.1513655-1-avlarkin82@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 4f73f383f4f9c8f15dbae4113b6d0f2c83aba04a Author: Takashi Iwai Date: Sun May 30 21:43:36 2021 -0700 Input: elants_i2c - fix NULL dereference at probing commit b9c0ebb867d67cc4e9e1a7a2abf0ac9a2cc02051 upstream. The recent change in elants_i2c driver to support more chips introduced a regression leading to Oops at probing. The driver reads id->driver_data, but the id may be NULL depending on the device type the driver gets bound. Replace the driver data extraction with the device_get_match_data() helper, and define the driver data in OF table, too. Fixes: 9517b95bdc46 ("Input: elants_i2c - add support for eKTF3624") BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1186454 Signed-off-by: Takashi Iwai Cc: Link: https://lore.kernel.org/r/20210528071024.26450-1-tiwai@suse.de Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit fcc4582ff286bd6d89753fc103c355c411242aad Author: Al Viro Date: Wed Jun 2 14:48:21 2021 -0400 iov_iter_fault_in_readable() should do nothing in xarray case commit 0e8f0d67401589a141950856902c7d0ec8d9c985 upstream. ... and actually should just check it's given an iovec-backed iterator in the first place. Cc: stable@vger.kernel.org Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 3854f9c612ae54295b076a478591b5e5987d52d4 Author: Al Viro Date: Thu Apr 29 20:42:25 2021 -0400 teach copy_page_to_iter() to handle compound pages commit 08aa64796016cb47b2ef3d0924653b4d944b0d65 upstream. In situation when copy_page_to_iter() got a compound page the current code would only work on systems with no CONFIG_HIGHMEM. It *is* the majority of real-world setups, or we would've drown in bug reports by now. Still needs fixing. Current variant works for solitary page; rename that to __copy_page_to_iter() and turn the handling of compound pages into a loop over subpages. Cc: stable@vger.kernel.org Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 64c430ea07a40dba6a277f3e9518d174269d1542 Author: Al Viro Date: Tue Apr 27 12:34:04 2021 -0400 copy_page_to_iter(): fix ITER_DISCARD case commit a506abc7b644d71966a75337d5a534f531b3cdc4 upstream. we need to advance the iterator... Cc: stable@vger.kernel.org Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit baf1972e79010cff444a9d08f1e744686858cec8 Author: Kees Cook Date: Wed Jun 23 13:39:28 2021 -0700 selftests/lkdtm: Avoid needing explicit sub-shell commit 04831e892b41618914b2123ae3b4fa77252e8656 upstream. Some environments do not set $SHELL when running tests. There's no need to use $SHELL here anyway, since "cat" can be used to receive any delivered signals from the kernel. Additionally avoid using bash-isms in the command, and record stderr for posterity. Fixes: 46d1a0f03d66 ("selftests/lkdtm: Add tests for LKDTM targets") Cc: stable@vger.kernel.org Suggested-by: Guillaume Tucker Suggested-by: David Laight Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20210623203936.3151093-2-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 9e4ac5eba03500f4e27b99b7b1974c4b84ce9634 Author: Desmond Cheong Zhi Xi Date: Mon Jun 28 19:33:52 2021 -0700 ntfs: fix validity check for file name attribute commit d98e4d95411bbde2220a7afa38dcc9c14d71acbe upstream. When checking the file name attribute, we want to ensure that it fits within the bounds of ATTR_RECORD. To do this, we should check that (attr record + file name offset + file name length) < (attr record + attr record length). However, the original check did not include the file name offset in the calculation. This means that corrupted on-disk metadata might not caught by the incorrect file name check, and lead to an invalid memory access. An example can be seen in the crash report of a memory corruption error found by Syzbot: https://syzkaller.appspot.com/bug?id=a1a1e379b225812688566745c3e2f7242bffc246 Adding the file name offset to the validity check fixes this error and passes the Syzbot reproducer test. Link: https://lkml.kernel.org/r/20210614050540.289494-1-desmondcheongzx@gmail.com Signed-off-by: Desmond Cheong Zhi Xi Reported-by: syzbot+213ac8bb98f7f4420840@syzkaller.appspotmail.com Tested-by: syzbot+213ac8bb98f7f4420840@syzkaller.appspotmail.com Acked-by: Anton Altaparmakov Cc: Shuah Khan Cc: Greg Kroah-Hartman Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d089a9af0cfa3a87ce10aa5ec603f67788e8adf8 Author: Andreas Gruenbacher Date: Mon Jun 28 19:14:50 2021 +0800 gfs2: Fix error handling in init_statfs commit 5d49d3508b3c67201bd3e1bf7f4ef049111b7051 upstream. On an error path, init_statfs calls iput(pn) after pn has already been put. Fix that by setting pn to NULL after the initial iput. Fixes: 97fd734ba17e ("gfs2: lookup local statfs inodes prior to journal recovery") Cc: stable@vger.kernel.org # v5.10+ Reported-by: Jing Xiangfeng Signed-off-by: Andreas Gruenbacher Signed-off-by: Greg Kroah-Hartman commit 396a707096cec54a91993104f21b9f6f95bdc825 Author: Andreas Gruenbacher Date: Mon Jun 21 22:28:50 2021 +0200 gfs2: Fix underflow in gfs2_page_mkwrite commit d3c51c55cb9274dd43c156f1f26b5eb4d5f2d58c upstream. On filesystems with a block size smaller than PAGE_SIZE and non-empty files smaller then PAGE_SIZE, gfs2_page_mkwrite could end up allocating excess blocks beyond the end of the file, similar to fallocate. This doesn't make sense; fix it. Reported-by: Bob Peterson Fixes: 184b4e60853d ("gfs2: Fix end-of-file handling in gfs2_page_mkwrite") Cc: stable@vger.kernel.org # v5.5+ Signed-off-by: Andreas Gruenbacher Signed-off-by: Greg Kroah-Hartman commit 73b4b15fa758dffaa180f90e44930f34ce7eeeba Author: Mike Rapoport Date: Mon Jun 28 19:33:26 2021 -0700 mm/page_alloc: fix memory map initialization for descending nodes commit 122e093c1734361dedb64f65c99b93e28e4624f4 upstream. On systems with memory nodes sorted in descending order, for instance Dell Precision WorkStation T5500, the struct pages for higher PFNs and respectively lower nodes, could be overwritten by the initialization of struct pages corresponding to the holes in the memory sections. For example for the below memory layout [ 0.245624] Early memory node ranges [ 0.248496] node 1: [mem 0x0000000000001000-0x0000000000090fff] [ 0.251376] node 1: [mem 0x0000000000100000-0x00000000dbdf8fff] [ 0.254256] node 1: [mem 0x0000000100000000-0x0000001423ffffff] [ 0.257144] node 0: [mem 0x0000001424000000-0x0000002023ffffff] the range 0x1424000000 - 0x1428000000 in the beginning of node 0 starts in the middle of a section and will be considered as a hole during the initialization of the last section in node 1. The wrong initialization of the memory map causes panic on boot when CONFIG_DEBUG_VM is enabled. Reorder loop order of the memory map initialization so that the outer loop will always iterate over populated memory regions in the ascending order and the inner loop will select the zone corresponding to the PFN range. This way initialization of the struct pages for the memory holes will be always done for the ranges that are actually not populated. [akpm@linux-foundation.org: coding style fixes] Link: https://lkml.kernel.org/r/YNXlMqBbL+tBG7yq@kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=213073 Link: https://lkml.kernel.org/r/20210624062305.10940-1-rppt@kernel.org Fixes: 0740a50b9baa ("mm/page_alloc.c: refactor initialization of struct page for holes in memory layout") Signed-off-by: Mike Rapoport Cc: Boris Petkov Cc: Robert Shteynfeld Cc: Baoquan He Cc: Vlastimil Babka Cc: David Hildenbrand Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6f648906e86e0eda256792e8cfc7eb9181c5b306 Author: Zhangjiantao (Kirin, nanjing) Date: Thu Jun 17 18:03:54 2021 +0300 xhci: solve a double free problem while doing s4 commit b31d9d6d7abbf6483b871b6370bc31c930d53f54 upstream. when system is doing s4, the process of xhci_resume may be as below: 1、xhci_mem_cleanup 2、xhci_init->xhci_mem_init->xhci_mem_cleanup(when memory is not enough). xhci_mem_cleanup will be executed twice when system is out of memory. xhci->port_caps is freed in xhci_mem_cleanup,but it isn't set to NULL. It will be freed twice when xhci_mem_cleanup is called the second time. We got following bug when system resumes from s4: kernel BUG at mm/slub.c:309! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP CPU: 0 PID: 5929 Tainted: G S W 5.4.96-arm64-desktop #1 pc : __slab_free+0x5c/0x424 lr : kfree+0x30c/0x32c Call trace: __slab_free+0x5c/0x424 kfree+0x30c/0x32c xhci_mem_cleanup+0x394/0x3cc xhci_mem_init+0x9ac/0x1070 xhci_init+0x8c/0x1d0 xhci_resume+0x1cc/0x5fc xhci_plat_resume+0x64/0x70 platform_pm_thaw+0x28/0x60 dpm_run_callback+0x54/0x24c device_resume+0xd0/0x200 async_resume+0x24/0x60 async_run_entry_fn+0x44/0x110 process_one_work+0x1f0/0x490 worker_thread+0x5c/0x450 kthread+0x158/0x160 ret_from_fork+0x10/0x24 Original patch that caused this issue was backported to 4.4 stable, so this should be backported to 4.4 stabe as well. Fixes: cf0ee7c60c89 ("xhci: Fix memory leak when caching protocol extended capability PSI tables - take 2") Cc: stable@vger.kernel.org # v4.4+ Signed-off-by: Jiantao Zhang Signed-off-by: Tao Xue Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210617150354.1512157-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 2802e5d7072e8fd1a3eadee3c15dece9005aeabe Author: Jing Xiangfeng Date: Thu Jun 17 15:32:26 2021 +0800 usb: typec: Add the missed altmode_id_remove() in typec_register_altmode() commit 03026197bb657d784220b040c6173267a0375741 upstream. typec_register_altmode() misses to call altmode_id_remove() in an error path. Add the missed function call to fix it. Fixes: 8a37d87d72f0 ("usb: typec: Bus type for alternate modes") Cc: stable Acked-by: Heikki Krogerus Signed-off-by: Jing Xiangfeng Link: https://lore.kernel.org/r/20210617073226.47599-1-jingxiangfeng@huawei.com Signed-off-by: Greg Kroah-Hartman commit ec357da5b47fcec2d805e78a8f41f4c2f42647ec Author: Kyle Tso Date: Wed Jun 16 17:01:02 2021 +0800 usb: typec: tcpm: Relax disconnect threshold during power negotiation commit 2b537cf877eae6d2f2f102052290676e40b74a1d upstream. If the voltage is being decreased in power negotiation, the Source will set the power supply to operate at the new voltage level before sending PS_RDY. Relax the threshold before sending Request Message so that it will not race with Source which begins to adjust the voltage right after it sends Accept Message (PPS) or tSrcTransition (25~35ms) after it sends Accept Message (non-PPS). The real threshold will be set after Sink receives PS_RDY Message. Fixes: f321a02caebd ("usb: typec: tcpm: Implement enabling Auto Discharge disconnect support") Cc: stable Cc: Badhri Jagan Sridharan Reviewed-by: Badhri Jagan Sridharan Acked-by: Heikki Krogerus Signed-off-by: Kyle Tso Link: https://lore.kernel.org/r/20210616090102.1897674-1-kyletso@google.com Signed-off-by: Greg Kroah-Hartman commit d864070b33a6ec94c4a870d24c88ea95d4d77f85 Author: Badhri Jagan Sridharan Date: Tue Jun 15 10:43:23 2021 -0700 usb: typec: tcpci: Fix up sink disconnect thresholds for PD commit 4288debeaa4e21d8dd5132739ffba2d343892bbf upstream. "Table 4-3 VBUS Sink Characteristics" of "Type-C Cable and Connector Specification" defines the disconnect voltage thresholds of various configurations. This change fixes the disconnect threshold voltage calculation based on vSinkPD_min and vSinkDisconnectPD as defined by the table. Fixes: e1a97bf80a022 ("usb: typec: tcpci: Implement Auto discharge disconnect callbacks") Cc: stable Acked-by: Heikki Krogerus Signed-off-by: Badhri Jagan Sridharan Link: https://lore.kernel.org/r/20210615174323.1160132-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman commit f077ba7a104d344c80235d4d8f5134581cd5a027 Author: Minas Harutyunyan Date: Thu Jun 17 09:55:24 2021 -0700 usb: dwc3: Fix debugfs creation flow commit 84524d1232ecca7cf8678e851b254f05cff4040a upstream. Creation EP's debugfs called earlier than debugfs folder for dwc3 device created. As result EP's debugfs are created in '/sys/kernel/debug' instead of '/sys/kernel/debug/usb/dwc3.1.auto'. Moved dwc3_debugfs_init() function call before calling dwc3_core_init_mode() to allow create dwc3 debugfs parent before creating EP's debugfs's. Fixes: 8d396bb0a5b6 ("usb: dwc3: debugfs: Add and remove endpoint dirs dynamically") Cc: stable Reviewed-by: Jack Pham Signed-off-by: Minas Harutyunyan Link: https://lore.kernel.org/r/01fafb5b2d8335e98e6eadbac61fc796bdf3ec1a.1623948457.git.Minas.Harutyunyan@synopsys.com Signed-off-by: Greg Kroah-Hartman commit 4df012c3c86635865669c5a8ec44fc21f825fee5 Author: Hannu Hartikainen Date: Tue Jun 22 17:14:54 2021 +0300 USB: cdc-acm: blacklist Heimann USB Appset device commit 4897807753e078655a78de39ed76044d784f3e63 upstream. The device (32a7:0000 Heimann Sensor GmbH USB appset demo) claims to be a CDC-ACM device in its descriptors but in fact is not. If it is run with echo disabled it returns garbled data, probably due to something that happens in the TTY layer. And when run with echo enabled (the default), it will mess up the calibration data of the sensor the first time any data is sent to the device. In short, I had a bad time after connecting the sensor and trying to get it to work. I hope blacklisting it in the cdc-acm driver will save someone else a bit of trouble. Signed-off-by: Hannu Hartikainen Cc: stable Link: https://lore.kernel.org/r/20210622141454.337948-1-hannu@hrtk.in Signed-off-by: Greg Kroah-Hartman commit ed76fed8175417637984cf16806651acf67c0956 Author: Moritz Fischer Date: Tue Jun 15 08:37:58 2021 -0700 usb: renesas-xhci: Fix handling of unknown ROM state commit d143825baf15f204dac60acdf95e428182aa3374 upstream. The ROM load sometimes seems to return an unknown status (RENESAS_ROM_STATUS_NO_RESULT) instead of success / fail. If the ROM load indeed failed this leads to failures when trying to communicate with the controller later on. Attempt to load firmware using RAM load in those cases. Fixes: 2478be82de44 ("usb: renesas-xhci: Add ROM loader for uPD720201") Cc: stable@vger.kernel.org Cc: Mathias Nyman Cc: Greg Kroah-Hartman Cc: Vinod Koul Tested-by: Vinod Koul Reviewed-by: Vinod Koul Signed-off-by: Moritz Fischer Link: https://lore.kernel.org/r/20210615153758.253572-1-mdf@kernel.org Signed-off-by: Greg Kroah-Hartman commit a55093941e38113dd6f5f5d5d2705fec3018f332 Author: Linyu Yuan Date: Wed Jun 16 19:51:42 2021 +0800 usb: gadget: eem: fix echo command packet response issue commit 4249d6fbc10fd997abdf8a1ea49c0389a0edf706 upstream. when receive eem echo command, it will send a response, but queue this response to the usb request which allocate from gadget device endpoint zero, and transmit the request to IN endpoint of eem interface. on dwc3 gadget, it will trigger following warning in function __dwc3_gadget_ep_queue(), if (WARN(req->dep != dep, "request %pK belongs to '%s'\n", &req->request, req->dep->name)) return -EINVAL; fix it by allocating a usb request from IN endpoint of eem interface, and transmit the usb request to same IN endpoint of eem interface. Signed-off-by: Linyu Yuan Cc: stable Link: https://lore.kernel.org/r/20210616115142.34075-1-linyyuan@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit 15e94ea49beae8a3d690e797d53384fd77fa1394 Author: Pavel Skripkin Date: Thu Jun 17 21:51:30 2021 +0300 net: can: ems_usb: fix use-after-free in ems_usb_disconnect() commit ab4a0b8fcb9a95c02909b62049811bd2e586aaa4 upstream. In ems_usb_disconnect() dev pointer, which is netdev private data, is used after free_candev() call: | if (dev) { | unregister_netdev(dev->netdev); | free_candev(dev->netdev); | | unlink_all_urbs(dev); | | usb_free_urb(dev->intr_urb); | | kfree(dev->intr_in_buffer); | kfree(dev->tx_msg_buffer); | } Fix it by simply moving free_candev() at the end of the block. Fail log: | BUG: KASAN: use-after-free in ems_usb_disconnect | Read of size 8 at addr ffff88804e041008 by task kworker/1:2/2895 | | CPU: 1 PID: 2895 Comm: kworker/1:2 Not tainted 5.13.0-rc5+ #164 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.4 | Workqueue: usb_hub_wq hub_event | Call Trace: | dump_stack (lib/dump_stack.c:122) | print_address_description.constprop.0.cold (mm/kasan/report.c:234) | kasan_report.cold (mm/kasan/report.c:420 mm/kasan/report.c:436) | ems_usb_disconnect (drivers/net/can/usb/ems_usb.c:683 drivers/net/can/usb/ems_usb.c:1058) Fixes: 702171adeed3 ("ems_usb: Added support for EMS CPC-USB/ARM7 CAN/USB interface") Link: https://lore.kernel.org/r/20210617185130.5834-1-paskripkin@gmail.com Cc: linux-stable Signed-off-by: Pavel Skripkin Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 7763d4aaebafba951a222655e3356b863bef15d6 Author: Johan Hovold Date: Mon May 24 10:02:59 2021 -0700 Input: usbtouchscreen - fix control-request directions commit 41e81022a04a0294c55cfa7e366bc14b9634c66e upstream. The direction of the pipe argument must match the request-type direction bit or control requests may fail depending on the host-controller-driver implementation. Fix the four control requests which erroneously used usb_rcvctrlpipe(). Fixes: 1d3e20236d7a ("[PATCH] USB: usbtouchscreen: unified USB touchscreen driver") Fixes: 24ced062a296 ("usbtouchscreen: add support for DMC TSC-10/25 devices") Fixes: 9e3b25837a20 ("Input: usbtouchscreen - add support for e2i touchscreen controller") Signed-off-by: Johan Hovold Cc: stable@vger.kernel.org # 2.6.17 Link: https://lore.kernel.org/r/20210524092048.4443-1-johan@kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 82d7e9597e6da4d9044949d895f73f7df2220444 Author: Pavel Skripkin Date: Fri May 7 14:50:43 2021 +0200 media: dvb-usb: fix wrong definition commit c680ed46e418e9c785d76cf44eb33bfd1e8cf3f6 upstream. syzbot reported WARNING in vmalloc. The problem was in zero size passed to vmalloc. The root case was in wrong cxusb_bluebird_lgz201_properties definition. adapter array has only 1 entry, but num_adapters was 2. Call Trace: __vmalloc_node mm/vmalloc.c:2963 [inline] vmalloc+0x67/0x80 mm/vmalloc.c:2996 dvb_dmx_init+0xe4/0xb90 drivers/media/dvb-core/dvb_demux.c:1251 dvb_usb_adapter_dvb_init+0x564/0x860 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:184 dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:86 [inline] dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:184 [inline] dvb_usb_device_init.cold+0xc94/0x146e drivers/media/usb/dvb-usb/dvb-usb-init.c:308 cxusb_probe+0x159/0x5e0 drivers/media/usb/dvb-usb/cxusb.c:1634 Fixes: 4d43e13f723e ("V4L/DVB (4643): Multi-input patch for DVB-USB device") Cc: stable@vger.kernel.org Reported-by: syzbot+7336195c02c1bd2f64e1@syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit efad996fc1c3bc6b91b1b65c57e270bb07c1fa5b Author: Frank Schäfer Date: Sat Jul 3 15:54:16 2021 +0200 ALSA: hda/realtek: fix mute led of the HP Pavilion 15-eh1xxx series commit 42334fbc219eb110e054cedf9e553a142f735b11 upstream. The HP Pavilion 15-eh1xxx series uses the HP mainboard 88D0 with ALC287 and needs the ALC287_FIXUP_HP_GPIO_LED quirk to make the mute led working. Tested with a HP Pavilion 15-eh1557ng. Signed-off-by: Frank Schäfer Cc: Link: https://lore.kernel.org/r/20210703135416.13151-1-fschaefer.oss@googlemail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1ccc1686b3cc54c5038a26acf7ef1b9a28930993 Author: Jeremy Szu Date: Fri Jun 25 21:34:13 2021 +0800 ALSA: hda/realtek: fix mute/micmute LEDs for HP EliteBook 830 G8 Notebook PC commit dfc2e8ae4066a95c7f9c2bb2dfa26651feaa6b83 upstream. The HP EliteBook 830 G8 Notebook PC using ALC285 codec which using 0x04 to control mute LED and 0x01 to control micmute LED. Therefore, add a quirk to make it works. Signed-off-by: Jeremy Szu Cc: Link: https://lore.kernel.org/r/20210625133414.26760-1-jeremy.szu@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e4ca3c1dc37071c509543d5b892cb0d812aa038b Author: Takashi Iwai Date: Wed Jun 23 14:20:22 2021 +0200 ALSA: hda/realtek: Apply LED fixup for HP Dragonfly G1, too commit 0ac05b25c3dd8299204ae9d50c1c2f7f05eef08f upstream. HP Dragonfly G1 (SSID 103c:861f) also requires the same quirk for the mute and mic-mute LED just as Dragonfly G2 model. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=213329 Cc: Link: https://lore.kernel.org/r/20210623122022.26179-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 29e622eb3d63a726544524cc8ecdb5f170a7667a Author: Takashi Iwai Date: Sun Jun 20 08:59:52 2021 +0200 ALSA: hda/realtek: Fix bass speaker DAC mapping for Asus UM431D commit f8fbcdfb0665de60997d9746809e1704ed782bbc upstream. Asus Zenbook 14 UM431D has two speaker pins and a headphone pin, and the auto-parser ends up assigning the bass to the third DAC 0x06. Although the tone comes out, it's inconvenient because this DAC has no volume control unlike two other DACs. For obtaining the volume control for the bass speaker, this patch enforces the mapping to let both front and bass speaker pins sharing the same DAC. It's not ideal but a little bit of improvement. Since we've already applied the same workaround for another ASUS machine, we just need to hook the chain to the existing quirk. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212547 Cc: Link: https://lore.kernel.org/r/20210620065952.18948-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 85aa18d63acecd35c7ef399a03bb1c4bd8b61c68 Author: Elia Devito Date: Sat Jun 19 22:41:04 2021 +0200 ALSA: hda/realtek: Improve fixup for HP Spectre x360 15-df0xxx commit 434591b2a77def0e78abfa38e5d7c4bca954e68a upstream. On HP Spectre x360 15-df0xxx, after system boot with plugged headset, the headset mic are not detected. Moving pincfg and DAC's config to single fixup function fix this. [ The actual bug in the original code was that it used a chain to ALC286_FIXUP_SPEAKER2_TO_DAC1, and it contains not only the DAC1 route fix but also another chain to ALC269_FIXUP_THINKPAD_ACPI. I thought the latter one is harmless for non-Thinkpad, but it doesn't seem so; it contains again yet another chain to ALC269_FIXUP_SKI_IGNORE, and this might be bad for some machines, including this HP machine. -- tiwai ] Signed-off-by: Elia Devito Cc: Link: https://lore.kernel.org/r/20210619204105.5682-1-eliadevito@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5f33519ffa29f8ff978d674c6d23638ac3936197 Author: Jeremy Szu Date: Fri Jun 18 01:14:20 2021 +0800 ALSA: hda/realtek: fix mute/micmute LEDs for HP EliteBook x360 830 G8 commit c3d2c88209e85045a364e80fe12a6cde16745b72 upstream. The HP EliteBook x360 830 G8 using ALC285 codec which using 0x04 to control mute LED and 0x01 to control micmute LED. Therefore, add a quirk to make it works. Signed-off-by: Jeremy Szu Cc: Link: https://lore.kernel.org/r/20210617171422.16652-1-jeremy.szu@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 496df16507add73f633f8291cdb2408eaaab320c Author: Takashi Iwai Date: Fri Jun 18 18:17:20 2021 +0200 ALSA: hda/realtek: Add another ALC236 variant support commit 1948fc065a89f18d057b8ffaef6d7242ad99edb8 upstream. The codec chip 10ec:0230 is another variant of ALC236, combined with a card reader. Apply the equivalent setup as 10ec:0236. BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1184869 Cc: Link: https://lore.kernel.org/r/20210618161720.28694-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6e4b638ba2b5b851f95cfe9061223b347edf5506 Author: Andy Chi Date: Thu Jul 1 17:14:15 2021 +0800 ALSA: hda/realtek: fix mute/micmute LEDs for HP ProBook 630 G8 commit fb3acdb2ba289aa06a5a995b3abef409bfe0a220 upstream. The HP ProBook 630 G8 using ALC236 codec which using 0x02 to control mute LED and 0x01 to control micmute LED. Therefore, add a quirk to make it works. Signed-off-by: Andy Chi Cc: Link: https://lore.kernel.org/r/20210701091417.9696-3-andy.chi@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit be688c0763bf616886cd6d028f48b0bf39f80e2e Author: Andy Chi Date: Thu Jul 1 17:14:14 2021 +0800 ALSA: hda/realtek: fix mute/micmute LEDs for HP ProBook 445 G8 commit a3b7f9b8fa2967e1b3c2a402301715124c90306b upstream. The HP ProBook 445 G8 using ALC236 codec. COEF index 0x34 bit 5 is used to control the playback mute LED, but the microphone mute LED is controlled using pin VREF instead of a COEF index. Therefore, add a quirk to make it works. Signed-off-by: Andy Chi Cc: Link: https://lore.kernel.org/r/20210701091417.9696-2-andy.chi@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2b7c96d5d7c2c04f206db88f118c6db9dd9f7973 Author: Andy Chi Date: Thu Jul 1 17:14:13 2021 +0800 ALSA: hda/realtek: fix mute/micmute LEDs for HP ProBook 450 G8 commit 2b70b264d34d398c77a5936e317336f00cf5badb upstream. The HP ProBook 450 G8 using ALC236 codec which using 0x02 to control mute LED and 0x01 to control micmute LED. Therefore, add a quirk to make it works. Signed-off-by: Andy Chi Cc: Link: https://lore.kernel.org/r/20210701091417.9696-1-andy.chi@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 61d14781e51e7bc19fbd0711417a683ea43dc749 Author: Takashi Iwai Date: Thu Jul 8 11:07:38 2021 +0200 ALSA: intel8x0: Fix breakage at ac97 clock measurement commit 24d1e49415be546470b20429d748e240d0518b7e upstream. The recent workaround for the wild interrupts in commit c1f0616124c4 ("ALSA: intel8x0: Don't update period unless prepared") leaded to a regression, causing the interrupt storm during ac97 clock measurement at the driver probe. We need to handle the interrupt while the clock measurement as well as the proper PCM streams. Fixes: c1f0616124c4 ("ALSA: intel8x0: Don't update period unless prepared") Reported-and-tested-by: Max Filippov Tested-by: Sergey Senozhatsky Cc: Link: https://lore.kernel.org/r/CAMo8BfKKMQkcsbOQaeEjq_FsJhdK=fn598dvh7YOcZshUSOH=g@mail.gmail.com Link: https://lore.kernel.org/r/20210708090738.1569-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d36a88504d8791470e47a33cbe8962f719a27f94 Author: Takashi Iwai Date: Wed Jun 23 02:30:49 2021 +0930 ALSA: usb-audio: scarlett2: Fix wrong resume call commit 785b6f29a795f109685f286b91e0250c206fbffb upstream. The current way of the scarlett2 mixer code managing the usb_mixer_elem_info object is wrong in two ways: it passes its internal index to the head.id field, and the val_type field is uninitialized. This ended up with the wrong execution at the resume because a bogus unit id is passed wrongly. Also, in the later code extensions, we'll have more mixer elements, and passing the index will overflow the unit id size (of 256). This patch corrects those issues. It introduces a new value type, USB_MIXER_BESPOKEN, which indicates a non-standard mixer element, and use this type for all scarlett2 mixer elements, as well as initializing the fixed unit id 0 for avoiding the overflow. Tested-by: Geoffrey D. Bennett Signed-off-by: Geoffrey D. Bennett Cc: Link: https://lore.kernel.org/r/49721219f45b7e175e729b0d9d9c142fd8f4342a.1624379707.git.g@b4.vu Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 493cce3d1f608c9ce5bd761b7e16071b463bbce6 Author: Takashi Sakamoto Date: Mon Jun 14 17:31:33 2021 +0900 ALSA: firewire-motu: fix stream format for MOTU 8pre FireWire commit fc36ef80ca2c68b2c9df06178048f08280e4334f upstream. My previous refactoring for ALSA firewire-motu driver brought regression to handle MOTU 8pre FireWire. The packet format is not operated correctly. Cc: Fixes: dfbaa4dc11eb ("ALSA: firewire-motu: add model-specific table of chunk count") Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20210614083133.39753-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 61f57e686753dd4a8362825b86a01affd3f741ee Author: Takashi Iwai Date: Tue Jun 22 11:06:47 2021 +0200 ALSA: usb-audio: Fix OOB access at proc output commit 362372ceb6556f338e230f2d90af27b47f82365a upstream. At extending the available mixer values for 32bit types, we forgot to add the corresponding entries for the format dump in the proc output. This may result in OOB access. Here adds the missing entries. Fixes: bc18e31c3042 ("ALSA: usb-audio: Fix parameter block size for UAC2 control requests") Cc: Link: https://lore.kernel.org/r/20210622090647.14021-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f446bfac9d780d47126d99b249c15dd3cf434a9e Author: Daehwan Jung Date: Wed Jun 16 18:34:55 2021 +0900 ALSA: usb-audio: fix rate on Ozone Z90 USB headset commit aecc19ec404bdc745c781058ac97a373731c3089 upstream. It mislabels its 96 kHz altsetting and that's why it causes some noise Signed-off-by: Daehwan Jung Cc: Link: https://lore.kernel.org/r/1623836097-61918-1-git-send-email-dh10.jung@samsung.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4448de6006fb23332840fd59e88994b14dc0db1f Author: Takashi Sakamoto Date: Fri Jun 18 13:04:47 2021 +0900 ALSA: bebob: fix rx packet format for Yamaha GO44/GO46, Terratec Phase 24/x24 commit 6b6c17fe6fa58900fa69dd000d5333b679e5e33e upstream. Below devices reports zero as the number of channels for external output plug with MIDI type: * Yamaha GO44/GO46 * Terratec Phase 24/X24 As a result, rx packet format is invalid and they generate silent sound. This is a regression added in v5.13. This commit fixes the bug, addressed at a commit 1bd1b3be8655 ("ALSA: bebob: perform sequence replay for media clock recovery"). Cc: Fixes: 5c6ea94f2b7c ("ALSA: bebob: detect the number of available MIDI ports") Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20210618040447.113306-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 146017a7174840d67ca9da8777e17c19ea8b359a Author: Szymon Janc Date: Tue May 18 16:54:36 2021 +0200 Bluetooth: Remove spurious error message commit 1c58e933aba23f68c0d3f192f7cc6eed8fabd694 upstream. Even with rate limited reporting this is very spammy and since it is remote device that is providing bogus data there is no need to report this as error. Since real_len variable was used only to allow conditional error message it is now also removed. [72454.143336] bt_err_ratelimited: 10 callbacks suppressed [72454.143337] Bluetooth: hci0: advertising data len corrected [72454.296314] Bluetooth: hci0: advertising data len corrected [72454.892329] Bluetooth: hci0: advertising data len corrected [72455.051319] Bluetooth: hci0: advertising data len corrected [72455.357326] Bluetooth: hci0: advertising data len corrected [72455.663295] Bluetooth: hci0: advertising data len corrected [72455.787278] Bluetooth: hci0: advertising data len corrected [72455.942278] Bluetooth: hci0: advertising data len corrected [72456.094276] Bluetooth: hci0: advertising data len corrected [72456.249137] Bluetooth: hci0: advertising data len corrected [72459.416333] bt_err_ratelimited: 13 callbacks suppressed [72459.416334] Bluetooth: hci0: advertising data len corrected [72459.721334] Bluetooth: hci0: advertising data len corrected [72460.011317] Bluetooth: hci0: advertising data len corrected [72460.327171] Bluetooth: hci0: advertising data len corrected [72460.638294] Bluetooth: hci0: advertising data len corrected [72460.946350] Bluetooth: hci0: advertising data len corrected [72461.225320] Bluetooth: hci0: advertising data len corrected [72461.690322] Bluetooth: hci0: advertising data len corrected [72462.118318] Bluetooth: hci0: advertising data len corrected [72462.427319] Bluetooth: hci0: advertising data len corrected [72464.546319] bt_err_ratelimited: 7 callbacks suppressed [72464.546319] Bluetooth: hci0: advertising data len corrected [72464.857318] Bluetooth: hci0: advertising data len corrected [72465.163332] Bluetooth: hci0: advertising data len corrected [72465.278331] Bluetooth: hci0: advertising data len corrected [72465.432323] Bluetooth: hci0: advertising data len corrected [72465.891334] Bluetooth: hci0: advertising data len corrected [72466.045334] Bluetooth: hci0: advertising data len corrected [72466.197321] Bluetooth: hci0: advertising data len corrected [72466.340318] Bluetooth: hci0: advertising data len corrected [72466.498335] Bluetooth: hci0: advertising data len corrected [72469.803299] bt_err_ratelimited: 10 callbacks suppressed Signed-off-by: Szymon Janc Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=203753 Cc: stable@vger.kernel.org Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit ab4e95250d9cf69fd03ddc1a9224715172eb7534 Author: Connor Abbott Date: Fri May 7 14:27:33 2021 +0200 Bluetooth: btqca: Don't modify firmware contents in-place commit b43ca511178ed0ab6fd2405df28cf9e100273020 upstream. struct firmware::data is marked const, and when the firmware is compressed with xz (default at least with Fedora) it's mapped read-only which results in a crash: BUG: unable to handle page fault for address: ffffae57c0ca5047 PGD 100000067 P4D 100000067 PUD 1001ce067 PMD 10165a067 PTE 8000000112bba161 Oops: 0003 [#1] SMP NOPTI CPU: 3 PID: 204 Comm: kworker/u17:0 Not tainted 5.12.1-test+ #1 Hardware name: Dell Inc. XPS 13 9310/0F7M4C, BIOS 1.2.5 12/10/2020 Workqueue: hci0 hci_power_on [bluetooth] RIP: 0010:qca_download_firmware+0x27c/0x4e0 [btqca] Code: 1b 75 04 80 48 0c 01 0f b7 c6 8d 54 02 0c 41 39 d7 0f 8e 62 fe ff ff 48 63 c2 4c 01 e8 0f b7 38 0f b7 70 02 66 83 ff 11 75 d3 <80> 48 0c 80 41 83 fc 03 7e 6e 88 58 0d eb ce 41 0f b6 45 0e 48 8b RSP: 0018:ffffae57c08dfc68 EFLAGS: 00010246 RAX: ffffae57c0ca503b RBX: 000000000000000e RCX: 0000000000000000 RDX: 0000000000000037 RSI: 0000000000000006 RDI: 0000000000000011 RBP: ffff978d9949e000 R08: ffff978d84ed7540 R09: ffffae57c0ca5000 R10: 000000000010cd00 R11: 0000000000000001 R12: 0000000000000005 R13: ffffae57c0ca5004 R14: ffff978d98ca8680 R15: 00000000000016a9 FS: 0000000000000000(0000) GS:ffff9794ef6c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffae57c0ca5047 CR3: 0000000113d5a004 CR4: 0000000000770ee0 PKRU: 55555554 Call Trace: qca_uart_setup+0x2cb/0x1390 [btqca] ? qca_read_soc_version+0x136/0x220 [btqca] qca_setup+0x288/0xab0 [hci_uart] hci_dev_do_open+0x1f3/0x780 [bluetooth] ? try_to_wake_up+0x1c1/0x4f0 hci_power_on+0x3f/0x200 [bluetooth] process_one_work+0x1ec/0x380 worker_thread+0x53/0x3e0 ? process_one_work+0x380/0x380 kthread+0x11b/0x140 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x1f/0x30 Modules linked in: llc ip_set nf_tables nfnetlink snd_soc_skl_hda_dsp(+) ip6table_filter snd_soc_hdac_hdmi ip6_tables qrtr_mhi iptable_filter snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic s> dell_wmi_sysman(+) dell_smbios snd dcdbas mhi vfat videobuf2_vmalloc i2c_i801 videobuf2_memops videobuf2_v4l2 dell_wmi_descriptor fat wmi_bmof soundcore i2c_smbus videobuf2_common libarc4 mei_me mei hid_se> i2c_hid_acpi i2c_hid video pinctrl_tigerlake fuse CR2: ffffae57c0ca5047 This also seems to fix a failure to suspend due to the firmware download on bootup getting interrupted by the crash: Bluetooth: hci0: SSR or FW download time out PM: dpm_run_callback(): acpi_subsys_suspend+0x0/0x60 returns -110 PM: Device serial0-0 failed to suspend: error -110 PM: Some devices failed to suspend, or early wake event detected Fixes: 83e8196 ("Bluetooth: btqca: Introduce generic QCA ROME support") Cc: Venkata Lakshmi Narayana Gubba Cc: stable@vger.kernel.org Signed-off-by: Connor Abbott Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 13dbf9944e367c76e14925ef8b069a9db9038b27 Author: Pavel Skripkin Date: Mon May 3 13:06:05 2021 +0300 Bluetooth: hci_qca: fix potential GPF commit 59f90f1351282ea2dbd0c59098fd9bb2634e920e upstream. In qca_power_shutdown() qcadev local variable is initialized by hu->serdev.dev private data, but hu->serdev can be NULL and there is a check for it. Since, qcadev is not used before if (!hu->serdev) return; we can move its initialization after this "if" to prevent GPF. Fixes: 5559904ccc08 ("Bluetooth: hci_qca: Add QCA Rome power off support to the qca_power_shutdown()") Cc: stable@vger.kernel.org # v5.6+ Cc: Rocky Liao Signed-off-by: Pavel Skripkin Reviewed-by: Johan Hovold Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman