- May 11, 2023
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20230508094432.603705160@linuxfoundation.org Tested-by:
Ronald Warsow <rwarsow@gmx.de> Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Tested-by:
Ron Economos <re@w6rz.net> Tested-by:
Justin M. Forbes <jforbes@fedoraproject.org> Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Bagas Sanjaya <bagasdotme@gmail.com> Tested-by:
Markus Reichelt <lkt+2023@mareichelt.com> Link: https://lore.kernel.org/r/20230509030705.399628514@linuxfoundation.org Tested-by:
Rudi Heitbaum <rudi@heitbaum.com> Tested-by:
Conor Dooley <conor.dooley@microchip.com> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Chris Paterson (CIP) <chris.paterson2@renesas.com> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Pablo Neira Ayuso authored
commit c1592a89 upstream. Toggle deleted anonymous sets as inactive in the next generation, so users cannot perform any update on it. Clear the generation bitmask in case the transaction is aborted. The following KASAN splat shows a set element deletion for a bound anonymous set that has been already removed in the same transaction. [ 64.921510] ================================================================== [ 64.923123] BUG: KASAN: wild-memory-access in nf_tables_commit+0xa24/0x1490 [nf_tables] [ 64.924745] Write of size 8 at addr dead000000000122 by task test/890 [ 64.927903] CPU: 3 PID: 890 Comm: test Not tainted 6.3.0+ #253 [ 64.931120] Call Trace: [ 64.932699] <TASK> [ 64.934292] dump_stack_lvl+0x33/0x50 [ 64.935908] ? nf_tables_commit+0xa24/0x1490 [nf_tables] [ 64.937551] kasan_report+0xda/0x120 [ 64.939186] ? nf_tables_commit+0xa24/0x1490 [nf_tables] [ 64.940814] nf_tables_commit+0xa24/0x1490 [nf_tables] [ 64.942452] ? __kasan_slab_alloc+0x2d/0x60 [ 64.944070] ? nf_tables_setelem_notify+0x190/0x190 [nf_tables] [ 64.945710] ? kasan_set_track+0x21/0x30 [ 64.947323] nfnetlink_rcv_batch+0x709/0xd90 [nfnetlink] [ 64.948898] ? nfnetlink_rcv_msg+0x480/0x480 [nfnetlink] Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Pierre Gondois authored
commit 35223401 upstream. fetch_cache_info() tries to get the number of cache leaves/levels for each CPU in order to pre-allocate memory for cacheinfo struct. Allocating this memory later triggers a: 'BUG: sleeping function called from invalid context' in PREEMPT_RT kernels. If there is no cache related information available in DT or ACPI, fetch_cache_info() fails and an error message is printed: 'Early cacheinfo failed, ret = ...' Not having cache information should be a valid configuration. Remove the error message if fetch_cache_info() fails with -ENOENT. Suggested-by:
Pierre Gondois <pierre.gondois@arm.com> Reviewed-by:
Sudeep Holla <sudeep.holla@arm.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Thomas Gleixner authored
commit 0af462f1 upstream. The recent fix to ensure atomicity of lookup and allocation inadvertently broke the pool refill mechanism. Prior to that change debug_objects_activate() and debug_objecs_assert_init() invoked debug_objecs_init() to set up the tracking object for statically initialized objects. That's not longer the case and debug_objecs_init() is now the only place which does pool refills. Depending on the number of statically initialized objects this can be enough to actually deplete the pool, which was observed by Ido via a debugobjects OOM warning. Restore the old behaviour by adding explicit refill opportunities to debug_objects_activate() and debug_objecs_assert_init(). Fixes: 63a75969 ("debugobject: Prevent init race with static objects") Reported-by:
Ido Schimmel <idosch@nvidia.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Tested-by:
-
Paulo Alcantara authored
commit 6be2ea33 upstream. Now that a DFS tcon manages its own list of DFS referrals and sessions, there is no point in having a single worker to refresh referrals of all DFS tcons. Make it faster and less prone to race conditions when having several mounts by queueing a worker per DFS tcon that will take care of refreshing only the DFS referrals related to it. Cc: stable@vger.kernel.org # v6.2+ Signed-off-by:
Paulo Alcantara (SUSE) <pc@manguebit.com> Signed-off-by:
Steve French <stfrench@microsoft.com> Signed-off-by:
-
Paulo Alcantara authored
commit 3dc9c433 upstream. Protect access of TCP_Server_Info::{origin,leaf}_fullpath when matching DFS connections, and get rid of TCP_Server_Info::current_fullpath while we're at it. Cc: stable@vger.kernel.org # v6.2+ Signed-off-by:
-
Paulo Alcantara authored
commit ee20d7c6 upstream. Protect access of TCP_Server_Info::hostname when building the ipc tree name as it might get freed in cifsd thread and thus causing an use-after-free bug in __tree_connect_dfs_target(). Also, while at it, update status of IPC tcon on success and then avoid any extra tree connects. Cc: stable@vger.kernel.org # v6.2+ Signed-off-by:
-
Paulo Alcantara authored
commit 8e355415 upstream. When matching DFS connections, we can't rely on the values set in cifs_sb_info::prepath and cifs_tcon::tree_name as they might change during DFS failover. The DFS referrals related to a specific DFS tcon are already matched earlier in match_server(), therefore we can safely skip those checks altogether as the connection is guaranteed to be unique for the DFS tcon. Besides, when creating or finding an SMB session, make sure to also refcount any DFS root session related to it (cifs_ses::dfs_root_ses), so if a new DFS mount ends up reusing the connection from the old mount while there was an umount(2) still in progress (e.g. umount(2) -> cifs_umount() -> reconnect -> cifs_put_tcon()), the connection could potentially be put right after the umount(2) finished. Patch has minor update to include fix for unused variable issue noted by the kernel test robot Reported-by:
kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/oe-kbuild-all/202305041040.j7W2xQSy-lkp@intel.com/ Cc: stable@vger.kernel.org # v6.2+ Signed-off-by:
-
Paulo Alcantara authored
commit 5bff9f74 upstream. Use @ses->ses_lock to protect access of @ses->ses_status. Cc: stable@vger.kernel.org Signed-off-by:
-
Paulo Alcantara authored
commit 90c49fce upstream. TCP_Server_Info::hostname may be updated once or many times during reconnect, so protect its access outside reconnect path as well and then prevent any potential use-after-free bugs. Cc: stable@vger.kernel.org Signed-off-by:
-
Tobias Holl authored
commit 776617db upstream. Pages that are from the same folio do not necessarily need to be consecutive. In that case, we cannot consolidate them into a single bvec entry. Before applying the huge page optimization from commit 57bebf80 ("io_uring/rsrc: optimise registered huge pages"), check that the memory is actually consecutive. Cc: stable@vger.kernel.org Fixes: 57bebf80 ("io_uring/rsrc: optimise registered huge pages") Signed-off-by:
Tobias Holl <tobias@tholl.xyz> [axboe: formatting] Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Adrian Hunter authored
commit 430635a0 upstream. After a standalone CBR (not associated with TSC), update the cycles reference timestamp and reset the cycle count, so that CYC timestamps are calculated relative to that point with the new frequency. Fixes: cc336186 ("perf tools: Add Intel PT support for decoding CYC packets") Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230403154831.8651-2-adrian.hunter@intel.com Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Adrian Hunter authored
commit 1f9f33cc upstream. kallsyms is not completely in address order. In find_entire_kern_cb(), calculate the kernel end from the maximum address not the last symbol. Example: Before: $ sudo cat /proc/kallsyms | grep ' [twTw] ' | tail -1 ffffffffc00b8bd0 t bpf_prog_6deef7357e7b4530 [bpf] $ sudo cat /proc/kallsyms | grep ' [twTw] ' | sort | tail -1 ffffffffc15e0cc0 t iwl_mvm_exit [iwlmvm] $ perf.d093603a05aa record -v --kcore -e intel_pt// --filter 'filter *' -- uname |& grep filter Address filter: filter 0xffffffff93200000/0x2ceba000 After: $ perf.8fb0f7a01f8e record -v --kcore -e intel_pt// --filter 'filter *' -- uname |& grep filter Address filter: filter 0xffffffff93200000/0x2e3e2000 Fixes: 1b36c03e ("perf record: Add support for using symbols in address filters") Signed-off-by:
-
Li Lingfeng authored
commit 38d11da5 upstream. Commit fa247089 ("dm: requeue IO if mapping table not yet available") added a detection of whether the mapping table is available in the IO submission process. If the mapping table is unavailable, it returns BLK_STS_RESOURCE and requeues the IO. This can lead to the following deadlock problem: dm create mount ioctl(DM_DEV_CREATE_CMD) ioctl(DM_TABLE_LOAD_CMD) do_mount vfs_get_tree ext4_get_tree get_tree_bdev sget_fc alloc_super // got &s->s_umount down_write_nested(&s->s_umount, ...); ext4_fill_super ext4_load_super ext4_read_bh submit_bio // submit and wait io end ioctl(DM_DEV_SUSPEND_CMD) dev_suspend do_resume dm_suspend __dm_suspend lock_fs freeze_bdev get_active_super grab_super // wait for &s->s_umount down_write(&s->s_umount); dm_swap_table __bind // set md->map(can't get here) IO will be continuously requeued while holding the lock since mapping table is NULL. At the same time, mapping table won't be set since the lock is not available. Like request-based DM, bio-based DM also has the same problem. It's not proper to just abort IO if the mapping table not available. So clear DM_SKIP_LOCKFS_FLAG when the mapping table is NULL, this allows the DM table to be loaded and the IO submitted upon resume. Fixes: fa247089 ("dm: requeue IO if mapping table not yet available") Cc: stable@vger.kernel.org Signed-off-by:
Li Lingfeng <lilingfeng3@huawei.com> Signed-off-by:
Mike Snitzer <snitzer@kernel.org> Signed-off-by:
-
Mike Snitzer authored
commit 3d32aaa7 upstream. syzkaller found the following problematic rwsem locking (with write lock already held): down_read+0x9d/0x450 kernel/locking/rwsem.c:1509 dm_get_inactive_table+0x2b/0xc0 drivers/md/dm-ioctl.c:773 __dev_status+0x4fd/0x7c0 drivers/md/dm-ioctl.c:844 table_clear+0x197/0x280 drivers/md/dm-ioctl.c:1537 In table_clear, it first acquires a write lock https://elixir.bootlin.com/linux/v6.2/source/drivers/md/dm-ioctl.c#L1520 down_write(&_hash_lock); Then before the lock is released at L1539, there is a path shown above: table_clear -> __dev_status -> dm_get_inactive_table -> down_read https://elixir.bootlin.com/linux/v6.2/source/drivers/md/dm-ioctl.c#L773 down_read(&_hash_lock); It tries to acquire the same read lock again, resulting in the deadlock problem. Fix this by moving table_clear()'s __dev_status() call to after its up_write(&_hash_lock); Cc: stable@vger.kernel.org Reported-by:
Zheng Zhang <zheng.zhang@email.ucr.edu> Signed-off-by:
-
Mikulas Patocka authored
commit 98dba02d upstream. This command will crash with NULL pointer dereference: dmsetup create flakey --table \ "0 `blockdev --getsize /dev/ram0` flakey /dev/ram0 0 0 1 2 corrupt_bio_byte 512" Fix the crash by checking if arg_name is non-NULL before comparing it. Cc: stable@vger.kernel.org Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
-
Mike Snitzer authored
commit 6b79a428 upstream. Otherwise the journal_io_cache will leak if dm_register_target() fails. Cc: stable@vger.kernel.org Signed-off-by:
-
Mike Snitzer authored
commit 6827af4a upstream. Otherwise the _hydration_cache will leak if dm_register_target() fails. Cc: stable@vger.kernel.org Signed-off-by:
-
Yeongjin Gil authored
commit e8c5d45f upstream. In verity_end_io(), if bi_status is not BLK_STS_OK, it can be return directly. But if FEC configured, it is desired to correct the data page through verity_verify_io. And the return value will be converted to blk_status and passed to verity_finish_io(). BTW, when a bit is set in v->validated_blocks, verity_verify_io() skips verification regardless of I/O error for the corresponding bio. In this case, the I/O error could not be returned properly, and as a result, there is a problem that abnormal data could be read for the corresponding block. To fix this problem, when an I/O error occurs, do not skip verification even if the bit related is set in v->validated_blocks. Fixes: 843f38d3 ("dm verity: add 'check_at_most_once' option to only validate hashes once") Cc: stable@vger.kernel.org Reviewed-by:
Sungjong Seo <sj1557.seo@samsung.com> Signed-off-by:
Yeongjin Gil <youngjin.gil@samsung.com> Signed-off-by:
-
Cindy Lu authored
commit c82729e0 upstream. While using the vdpa device with vIOMMU enabled in the guest VM, when the vdpa device bind to vfio-pci and run testpmd then system will fail to unmap. The test process is Load guest VM --> attach to virtio driver--> bind to vfio-pci driver So the mapping process is 1)batched mode map to normal MR 2)batched mode unmapped the normal MR 3)unmapped all the memory 4)mapped to iommu MR This error happened in step 3). The iotlb was freed in step 2) and the function vhost_vdpa_process_iotlb_msg will return fail Which causes failure. To fix this, we will not remove the AS while the iotlb->nmaps is 0. This will free in the vhost_vdpa_clean Cc: stable@vger.kernel.org Fixes: aaca8373 ("vhost-vdpa: support ASID based IOTLB API") Signed-off-by:
Cindy Lu <lulu@redhat.com> Message-Id: <20230420151734.860168-1-lulu@redhat.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Peter Xu authored
commit 5a2f8d22 upstream. Patch series "mm/hugetlb: More fixes around uffd-wp vs fork() / RO pins", v2. This patch (of 6): There're a bunch of things that were wrong: - Reading uffd-wp bit from a swap entry should use pte_swp_uffd_wp() rather than huge_pte_uffd_wp(). - When copying over a pte, we should drop uffd-wp bit when !EVENT_FORK (aka, when !userfaultfd_wp(dst_vma)). - When doing early CoW for private hugetlb (e.g. when the parent page was pinned), uffd-wp bit should be properly carried over if necessary. No bug reported probably because most people do not even care about these corner cases, but they are still bugs and can be exposed by the recent unit tests introduced, so fix all of them in one shot. Link: https://lkml.kernel.org/r/20230417195317.898696-1-peterx@redhat.com Link: https://lkml.kernel.org/r/20230417195317.898696-2-peterx@redhat.com Fixes: bc70fbf2 ("mm/hugetlb: handle uffd-wp during fork()") Signed-off-by:
Peter Xu <peterx@redhat.com> Reviewed-by:
David Hildenbrand <david@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Axel Rasmussen <axelrasmussen@google.com> Cc: Mika Penttilä <mpenttil@redhat.com> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: Nadav Amit <nadav.amit@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Lorenzo Stoakes authored
commit 00ca0f2e upstream. The refactoring in commit f4e9e0e6 ("mm/mempolicy: fix use-after-free of VMA iterator") introduces a subtle bug which arises when attempting to apply a new NUMA policy across a range of VMAs in mbind_range(). The refactoring passes a **prev pointer to keep track of the previous VMA in order to reduce duplication, and in all but one case it keeps this correctly updated. The bug arises when a VMA within the specified range has an equivalent policy as determined by mpol_equal() - which unlike other cases, does not update prev. This can result in a situation where, later in the iteration, a VMA is found whose policy does need to change. At this point, vma_merge() is invoked with prev pointing to a VMA which is before the previous VMA. Since vma_merge() discovers the curr VMA by looking for the one immediately after prev, it will now be in a situation where this VMA is incorrect and the merge will not proceed correctly. This is checked in the VM_WARN_ON() invariant case with end > curr->vm_end, which, if a merge is possible, results in a warning (if CONFIG_DEBUG_VM is specified). I note that vma_merge() performs these invariant checks only after merge_prev/merge_next are checked, which is debatable as it hides this issue if no merge is possible even though a buggy situation has arisen. The solution is simply to update the prev pointer even when policies are equal. This caused a bug to arise in the 6.2.y stable tree, and this patch resolves this bug. Link: https://lkml.kernel.org/r/83f1d612acb519d777bebf7f3359317c4e7f4265.1682866629.git.lstoakes@gmail.com Fixes: f4e9e0e6 ("mm/mempolicy: fix use-after-free of VMA iterator") Signed-off-by:
Lorenzo Stoakes <lstoakes@gmail.com> Reported-by:
kernel test robot <oliver.sang@intel.com> Link: https://lore.kernel.org/oe-lkp/202304292203.44ddeff6-oliver.sang@intel.com Cc: Liam R. Howlett <Liam.Howlett@oracle.com> Cc: Mel Gorman <mgorman@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Hugh Dickins authored
commit 3647ebcf upstream. I know nothing of ia64 htlbpage_to_page(), but guess that the p4d line should be using taddr rather than addr, like everywhere else. Link: https://lkml.kernel.org/r/732eae88-3beb-246-2c72-281de786740@google.com Fixes: c03ab9e3 ("ia64: add support for folded p4d page tables") Signed-off-by:
Hugh Dickins <hughd@google.com> Acked-by:
Mike Kravetz <mike.kravetz@oracle.com> Acked-by:
Mike Rapoport (IBM) <rppt@kernel.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Stefan Haberland authored
commit d8898ee5 upstream. The DASD driver does not kick the requeue list when requeuing IO requests to the blocklayer. This might lead to hanging blockdevice when there is no other trigger for this. Fix by automatically kick the requeue list when requeuing DASD requests to the blocklayer. Fixes: e443343e ("s390/dasd: blk-mq conversion") CC: stable@vger.kernel.org # 4.14+ Signed-off-by:
Stefan Haberland <sth@linux.ibm.com> Reviewed-by:
Jan Hoeppner <hoeppner@linux.ibm.com> Reviewed-by:
Halil Pasic <pasic@linux.ibm.com> Link: https://lore.kernel.org/r/20230405142017.2446986-8-sth@linux.ibm.com Signed-off-by:
-
Qu Wenruo authored
commit 604e6681 upstream. Since the introduction of scrub interface, the only flag that we support is BTRFS_SCRUB_READONLY. Thus there is no sanity checks, if there are some undefined flags passed in, we just ignore them. This is problematic if we want to introduce new scrub flags, as we have no way to determine if such flags are supported. Address the problem by introducing a check for the flags, and if unsupported flags are set, return -EOPNOTSUPP to inform the user space. This check should be backported for all supported kernels before any new scrub flags are introduced. CC: stable@vger.kernel.org # 4.14+ Reviewed-by:
Anand Jain <anand.jain@oracle.com> Signed-off-by:
Qu Wenruo <wqu@suse.com> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
Peng Liu authored
commit 7362042f upstream. Below incompatibilities between Python2 and Python3 made lx-timerlist fail to run under Python3. o xrange() is replaced by range() in Python3 o bytes and str are different types in Python3 o the return value of Inferior.read_memory() is memoryview object in Python3 akpm: cc stable so that older kernels are properly debuggable under newer Python. Link: https://lkml.kernel.org/r/TYCP286MB2146EE1180A4D5176CBA8AB2C6819@TYCP286MB2146.JPNP286.PROD.OUTLOOK.COM Signed-off-by:
Peng Liu <liupeng17@lenovo.com> Reviewed-by:
Jan Kiszka <jan.kiszka@siemens.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Kieran Bingham <kbingham@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Marc Dionne authored
[ Upstream commit 9ea4eff4 ] afs_read_dir fetches an amount of data that's based on what the inode size is thought to be. If the file on the server is larger than what was fetched, the code rechecks i_size and retries. If the local i_size was not properly updated, this can lead to an endless loop of fetching i_size from the server and noticing each time that the size is larger on the server. If it is known that the remote size is larger than i_size, bump up the fetch size to that size. Fixes: f3ddee8d ("afs: Fix directory handling") Signed-off-by:
Marc Dionne <marc.dionne@auristor.com> Signed-off-by:
David Howells <dhowells@redhat.com> cc: linux-afs@lists.infradead.org Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
David Howells authored
[ Upstream commit 45f66fa0 ] Fix afs_getattr() to report the server's idea of the file size of a directory rather than the local size. The local size may differ as we edit the local copy to avoid having to redownload it and we may end up with a differently structured blob of a different size. However, if the directory is discarded from the pagecache we then download it again and the user may see the directory file size apparently change. Fixes: 63a4681f ("afs: Locally edit directory data for mkdir/create/unlink/...") Signed-off-by:
-
Marc Dionne authored
[ Upstream commit d7f74e9a ] If the data version returned from the server is larger than expected, the local data is invalidated, but we may still want to note the remote file size. Since we're setting change_size, we have to also set data_changed for the i_size to get updated. Fixes: 3f4aa981 ("afs: Fix EOF corruption") Signed-off-by:
-
Chen Yu authored
[ Upstream commit 5904de0d ] The system refused to do a test_resume because it found that the swap device has already been taken by someone else. Specifically, the swsusp_check()->blkdev_get_by_dev(FMODE_EXCL) is supposed to do this check. Steps to reproduce: dd if=/dev/zero of=/swapfile bs=$(cat /proc/meminfo | awk '/MemTotal/ {print $2}') count=1024 conv=notrunc mkswap /swapfile swapon /swapfile swap-offset /swapfile echo 34816 > /sys/power/resume_offset echo test_resume > /sys/power/disk echo disk > /sys/power/state PM: Using 3 thread(s) for compression PM: Compressing and saving image data (293150 pages)... PM: Image saving progress: 0% PM: Image saving progress: 10% ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: configured for UDMA/100 ata2: SATA link down (SStatus 0 SControl 300) ata5: SATA link down (SStatus 0 SControl 300) ata6: SATA link down (SStatus 0 SControl 300) ata3: SATA link down (SStatus 0 SControl 300) ata4: SATA link down (SStatus 0 SControl 300) PM: Image saving progress: 20% PM: Image saving progress: 30% PM: Image saving progress: 40% PM: Image saving progress: 50% pcieport 0000:00:02.5: pciehp: Slot(0-5): No device found PM: Image saving progress: 60% PM: Image saving progress: 70% PM: Image saving progress: 80% PM: Image saving progress: 90% PM: Image saving done PM: hibernation: Wrote 1172600 kbytes in 2.70 seconds (434.29 MB/s) PM: S| PM: hibernation: Basic memory bitmaps freed PM: Image not found (code -16) This is because when using the swapfile as the hibernation storage, the block device where the swapfile is located has already been mounted by the OS distribution(usually mounted as the rootfs). This is not an issue for normal hibernation, because software_resume()->swsusp_check() happens before the block device(rootfs) mount. But it is a problem for the test_resume mode. Because when test_resume happens, the block device has been mounted already. Thus remove the FMODE_EXCL for test_resume mode. This would not be a problem because in test_resume stage, the processes have already been frozen, and the race condition described in Commit 39fbef4b ("PM: hibernate: Get block device exclusively in swsusp_check()") is unlikely to happen. Fixes: 39fbef4b ("PM: hibernate: Get block device exclusively in swsusp_check()") Reported-by:
Yifan Li <yifan2.li@intel.com> Suggested-by:
Pavankumar Kondeti <quic_pkondeti@quicinc.com> Tested-by:
Wendy Wang <wendy.wang@intel.com> Signed-off-by:
Chen Yu <yu.c.chen@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Chen Yu authored
[ Upstream commit 08169a16 ] There is need to check snapshot_test and open block device in different mode, so as to avoid the race condition. No functional changes intended. Suggested-by:
-
Hans de Goede authored
[ Upstream commit 9b04d997 ] The CPR3 power resource on the Toshiba Click Mini toggles a GPIO which is called SISP (for SIS touchscreen power?) on/off. This CPR3 power resource is not listed in any _PR? lists, let alone in a _PR0 list for the SIS0817 touchscreen ACPI device which needs it. Before commit a1224f34 ("ACPI: PM: Check states of power resources during initialization") this was not an issue because since nothing referenced the CPR3 power resource its state was always ACPI_POWER_RESOURCE_STATE_UNKNOWN and power resources with this state get ignored by acpi_turn_off_unused_power_resources(). This clearly is a bug in the DSDT of this device. Add a DMI quirk to make acpi_turn_off_unused_power_resources() a no-op on this model to fix the touchscreen no longer working since kernel 5.16 . This quirk also causes 2 other power resources to not get turned off, but the _OFF method on these already was a no-op, so this makes no difference for the other 2 power resources. Fixes: a1224f34 ("ACPI: PM: Check states of power resources during initialization") Reported-by:
Gé Koerkamp <ge.koerkamp@gmail.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=216946 Link: https://lore.kernel.org/regressions/32a14a8a-9795-4c8c-7e00-da9012f548f8@leemhuis.info/ Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit e078180d ] The "map_sz" is the number of elements in the "m" array so the > comparison needs to be changed to >= to prevent an out of bounds read. Fixes: 09574cca ("hte: Add Tegra194 HTE kernel provider") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Acked-by:
Dipen Patel <dipenp@nvidia.com> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 6680c835 ] Without the extra #include, this driver produces a build failure in some configurations. drivers/hte/hte-tegra194-test.c:96:34: error: array type has incomplete element type 'struct of_device_id' 96 | static const struct of_device_id tegra_hte_test_of_match[] = { Fixes: 9a75a7cd ("hte: Add Tegra HTE test driver") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
-
Charles Keepax authored
[ Upstream commit 972c91fd ] This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as a module. Fixes: 3f65555c ("mfd: arizona: Split of_match table into I2C and SPI versions") Signed-off-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by:
Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230323134138.834369-1-ckeepax@opensource.cirrus.com Signed-off-by:
-
Colin Foster authored
[ Upstream commit f0484d2f ] Ocelot chips (VSC7511, VSC7512, VSC7513, VSC7514) don't support bulk read operations over SPI. Many SPI buses have hardware that can optimize consecutive reads. Essentially an address is written to the chip, and if the SPI controller continues to toggle the clock, subsequent register values are reported. This can lead to significant optimizations, because the time between "address is written to the chip" and "chip starts to report data" can often take a fixed amount of time. When support for Ocelot chips were added in commit f3e89362 ("mfd: ocelot: Add support for the vsc7512 chip via spi") it was believed that this optimization was supported. However it is not. Most register transactions with the Ocelot chips are not done in bulk, so this bug could go unnoticed. The one scenario where bulk register operations _are_ performed is when polling port statistics counters, which was added in commit d87b1c08 ("net: mscc: ocelot: use bulk reads for stats"). Things get slightly more complicated here... A bug was introduced in commit d4c36765 ("net: mscc: ocelot: keep ocelot_stat_layout by reg address, not offset") that broke the optimization of bulk reads. This means that when Ethernet support for the VSC7512 chip was added in commit 3d7316ac ("net: dsa: ocelot: add external ocelot switch control") things were actually working "as expected". The bulk read opmtimization was discovered, and fixed in commit 6acc72a4 ("net: mscc: ocelot: fix stats region batching") and the timing optimizations for SPI were noticed. A bulk read went from ~14ms to ~2ms. But this timing improvement came at the cost of every register reading zero due the fact that bulk reads don't work. The read timings increase back to 13-14ms, but that's a price worth paying in order to receive valid data. This is verified in a DSA setup (cpsw-new switch tied to port 0 on the VSC7512, after having been running overnight) Rx Octets: 16222055 # Counters from CPSW switch Tx Octets: 12034702 Net Octets: 28256757 p00_rx_octets: 12034702 # Counters from Ocelot switch p00_rx_frames_below_65_octets: 0 p00_rx_frames_65_to_127_octets: 88188 p00_rx_frames_128_to_255_octets: 13 p00_rx_frames_256_to_511_octets: 0 p00_rx_frames_512_to_1023_octets: 0 p00_rx_frames_over_1526_octets: 3306 p00_tx_octets: 16222055 Fixes: f3e89362 ("mfd: ocelot: Add support for the vsc7512 chip via spi") Signed-off-by:
Colin Foster <colin.foster@in-advantage.com> Signed-off-by:
-
Matthias Schiffer authored
[ Upstream commit f376c479 ] It seems that this driver was developed based on preliminary documentation. Report the correct names for all TQMxE39x variants, as they are used by the released hardware revisions: - Fix names for TQMxE39C1/C2 board IDs - Distinguish TQMxE39M and TQMxE39S, which use the same board ID The TQMxE39M/S are distinguished using the SAUC (Sanctioned Alternate Uses Configuration) register of the GPIO controller. This also prepares for the correct handling of the differences between the GPIO controllers of our COMe and SMARC modules. Fixes: 2f17dd34 ("mfd: tqmx86: IO controller with I2C, Wachdog and GPIO") Signed-off-by:
Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Matthias Schiffer authored
[ Upstream commit 051c69ff ] Registers 0x160..0x17f are unassigned. Use 0x180 as base register and update offets accordingly. Also change the size of the range to include 0x19f. While 0x19f is currently reserved for future extensions, so are several of the previous registers up to 0x19e, and it is weird to leave out just the last one. Fixes: 2f17dd34 ("mfd: tqmx86: IO controller with I2C, Wachdog and GPIO") Signed-off-by:
-
Matthias Schiffer authored
[ Upstream commit 1be1b236 ] The I2C_DETECT register is at IO port 0x1a7, which is outside the range passed to devm_ioport_map() for io_base, and was only working because there aren't actually any bounds checks for IO port accesses. Extending the range does not seem like a good solution here, as it would then conflict with the IO resource assigned to the I2C controller. As this is just a one-off access during probe, use a simple inb() instead. While we're at it, drop the unused define TQMX86_REG_I2C_INT_EN. Fixes: 2f17dd34 ("mfd: tqmx86: IO controller with I2C, Wachdog and GPIO") Signed-off-by:
-
Kang Chen authored
[ Upstream commit f05c7b7d ] Smatch reports: 1. mtk_thermal_probe() warn: 'apmixed_base' from of_iomap() not released. 2. mtk_thermal_probe() warn: 'auxadc_base' from of_iomap() not released. The original code forgets to release iomap resource when handling errors, fix it by switch to devm_of_iomap. Fixes: 89945047 ("thermal: mediatek: Add tsensor support for V2 thermal system") Signed-off-by:
Kang Chen <void0red@hust.edu.cn> Reviewed-by:
Dongliang Mu <dzm91@hust.edu.cn> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20230419020749.621257-1-void0red@hust.edu.cn Signed-off-by:
-
