4.10: lockdep warning when rebooting #128
Comments
|
dup of #70 The work is never initialized because its only used for nand, but the work is flushed. |
|
You can hide this by turning off |
shenki
pushed a commit
that referenced
this issue
May 5, 2020
…p PTE entries commit 36b7840 upstream. H_PAGE_THP_HUGE is used to differentiate between a THP hugepage and hugetlb hugepage entries. The difference is WRT how we handle hash fault on these address. THP address enables MPSS in segments. We want to manage devmap hugepage entries similar to THP pt entries. Hence use H_PAGE_THP_HUGE for devmap huge PTE entries. With current code while handling hash PTE fault, we do set is_thp = true when finding devmap PTE huge PTE entries. Current code also does the below sequence we setting up huge devmap entries. entry = pmd_mkhuge(pfn_t_pmd(pfn, prot)); if (pfn_t_devmap(pfn)) entry = pmd_mkdevmap(entry); In that case we would find both H_PAGE_THP_HUGE and PAGE_DEVMAP set for huge devmap PTE entries. This results in false positive error like below. kernel BUG at /home/kvaneesh/src/linux/mm/memory.c:4321! Oops: Exception in kernel mode, sig: 5 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules linked in: CPU: 56 PID: 67996 Comm: t_mmap_dio Not tainted 5.6.0-rc4-59640-g371c804dedbc #128 .... NIP [c00000000044c9e4] __follow_pte_pmd+0x264/0x900 LR [c0000000005d45f8] dax_writeback_one+0x1a8/0x740 Call Trace: str_spec.74809+0x22ffb4/0x2d116c (unreliable) dax_writeback_one+0x1a8/0x740 dax_writeback_mapping_range+0x26c/0x700 ext4_dax_writepages+0x150/0x5a0 do_writepages+0x68/0x180 __filemap_fdatawrite_range+0x138/0x180 file_write_and_wait_range+0xa4/0x110 ext4_sync_file+0x370/0x6e0 vfs_fsync_range+0x70/0xf0 sys_msync+0x220/0x2e0 system_call+0x5c/0x68 This is because our pmd_trans_huge check doesn't exclude _PAGE_DEVMAP. To make this all consistent, update pmd_mkdevmap to set H_PAGE_THP_HUGE and pmd_trans_huge check now excludes _PAGE_DEVMAP correctly. Fixes: ebd3119 ("powerpc/mm: Add devmap support for ppc64") Cc: stable@vger.kernel.org # v4.13+ Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200313094842.351830-1-aneesh.kumar@linux.ibm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
shenki
pushed a commit
that referenced
this issue
Oct 30, 2020
[ Upstream commit 22f7609 ] The cstate->num_mixers member is only set to a non-zero value once dpu_encoder_virt_mode_set() is called, but the atomic check function can be called by userspace before that. Let's avoid the div-by-zero here and inside _dpu_crtc_setup_lm_bounds() by skipping this part of the atomic check if dpu_encoder_virt_mode_set() hasn't been called yet. This fixes an UBSAN warning: UBSAN: Undefined behaviour in drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:860:31 division by zero CPU: 7 PID: 409 Comm: frecon Tainted: G S 5.4.31 #128 Hardware name: Google Trogdor (rev0) (DT) Call trace: dump_backtrace+0x0/0x14c show_stack+0x20/0x2c dump_stack+0xa0/0xd8 __ubsan_handle_divrem_overflow+0xec/0x110 dpu_crtc_atomic_check+0x97c/0x9d4 drm_atomic_helper_check_planes+0x160/0x1c8 drm_atomic_helper_check+0x54/0xbc drm_atomic_check_only+0x6a8/0x880 drm_atomic_commit+0x20/0x5c drm_atomic_helper_set_config+0x98/0xa0 drm_mode_setcrtc+0x308/0x5dc drm_ioctl_kernel+0x9c/0x114 drm_ioctl+0x2ac/0x4b0 drm_compat_ioctl+0xe8/0x13c __arm64_compat_sys_ioctl+0x184/0x324 el0_svc_common+0xa4/0x154 el0_svc_compat_handler+0x Cc: Abhinav Kumar <abhinavk@codeaurora.org> Cc: Jeykumar Sankaran <jsanka@codeaurora.org> Cc: Jordan Crouse <jcrouse@codeaurora.org> Cc: Sean Paul <seanpaul@chromium.org> Fixes: 25fdd59 ("drm/msm: Add SDM845 DPU support") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
amboar
pushed a commit
to amboar/linux
that referenced
this issue
Nov 26, 2020
[ Upstream commit 22f7609 ] The cstate->num_mixers member is only set to a non-zero value once dpu_encoder_virt_mode_set() is called, but the atomic check function can be called by userspace before that. Let's avoid the div-by-zero here and inside _dpu_crtc_setup_lm_bounds() by skipping this part of the atomic check if dpu_encoder_virt_mode_set() hasn't been called yet. This fixes an UBSAN warning: UBSAN: Undefined behaviour in drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:860:31 division by zero CPU: 7 PID: 409 Comm: frecon Tainted: G S 5.4.31 openbmc#128 Hardware name: Google Trogdor (rev0) (DT) Call trace: dump_backtrace+0x0/0x14c show_stack+0x20/0x2c dump_stack+0xa0/0xd8 __ubsan_handle_divrem_overflow+0xec/0x110 dpu_crtc_atomic_check+0x97c/0x9d4 drm_atomic_helper_check_planes+0x160/0x1c8 drm_atomic_helper_check+0x54/0xbc drm_atomic_check_only+0x6a8/0x880 drm_atomic_commit+0x20/0x5c drm_atomic_helper_set_config+0x98/0xa0 drm_mode_setcrtc+0x308/0x5dc drm_ioctl_kernel+0x9c/0x114 drm_ioctl+0x2ac/0x4b0 drm_compat_ioctl+0xe8/0x13c __arm64_compat_sys_ioctl+0x184/0x324 el0_svc_common+0xa4/0x154 el0_svc_compat_handler+0x Cc: Abhinav Kumar <abhinavk@codeaurora.org> Cc: Jeykumar Sankaran <jsanka@codeaurora.org> Cc: Jordan Crouse <jcrouse@codeaurora.org> Cc: Sean Paul <seanpaul@chromium.org> Fixes: 25fdd59 ("drm/msm: Add SDM845 DPU support") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
amboar
pushed a commit
that referenced
this issue
Aug 30, 2024
commit 9a2fa14 upstream. copy_fd_bitmaps(new, old, count) is expected to copy the first count/BITS_PER_LONG bits from old->full_fds_bits[] and fill the rest with zeroes. What it does is copying enough words (BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest. That works fine, *if* all bits past the cutoff point are clear. Otherwise we are risking garbage from the last word we'd copied. For most of the callers that is true - expand_fdtable() has count equal to old->max_fds, so there's no open descriptors past count, let alone fully occupied words in ->open_fds[], which is what bits in ->full_fds_bits[] correspond to. The other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds), which is the smallest multiple of BITS_PER_LONG that covers all opened descriptors below max_fds. In the common case (copying on fork()) max_fds is ~0U, so all opened descriptors will be below it and we are fine, by the same reasons why the call in expand_fdtable() is safe. Unfortunately, there is a case where max_fds is less than that and where we might, indeed, end up with junk in ->full_fds_bits[] - close_range(from, to, CLOSE_RANGE_UNSHARE) with * descriptor table being currently shared * 'to' being above the current capacity of descriptor table * 'from' being just under some chunk of opened descriptors. In that case we end up with observably wrong behaviour - e.g. spawn a child with CLONE_FILES, get all descriptors in range 0..127 open, then close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending up with descriptor #128, despite #64 being observably not open. The minimally invasive fix would be to deal with that in dup_fd(). If this proves to add measurable overhead, we can go that way, but let's try to fix copy_fd_bitmaps() first. * new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size). * make copy_fd_bitmaps() take the bitmap size in words, rather than bits; it's 'count' argument is always a multiple of BITS_PER_LONG, so we are not losing any information, and that way we can use the same helper for all three bitmaps - compiler will see that count is a multiple of BITS_PER_LONG for the large ones, so it'll generate plain memcpy()+memset(). Reproducer added to tools/testing/selftests/core/close_range_test.c Cc: stable@vger.kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The text was updated successfully, but these errors were encountered: