- Linux-stable-mirror - lists.linaro.org

+ hugetlbfs-fix-anon-huge-page-migration-race.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: hugetlbfs: fix anon huge page migration race has been added to the -mm tree. Its filename is hugetlbfs-fix-anon-huge-page-migration-race.patch This patch should soon appear at https://ozlabs.org/~akpm/mmots/broken-out/hugetlbfs-fix-anon-huge-page-migr… and later at https://ozlabs.org/~akpm/mmotm/broken-out/hugetlbfs-fix-anon-huge-page-migr… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Mike Kravetz <mike.kravetz(a)oracle.com> Subject: hugetlbfs: fix anon huge page migration race Qian Cai reported the following BUG in [1] [ 6147.019063][T45242] LTP: starting move_pages12 [ 6147.475680][T64921] BUG: unable to handle page fault for address: ffffffffffffffe0 ... [ 6147.525866][T64921] RIP: 0010:anon_vma_interval_tree_iter_first+0xa2/0x170 avc_start_pgoff at mm/interval_tree.c:63 [ 6147.620914][T64921] Call Trace: [ 6147.624078][T64921] rmap_walk_anon+0x141/0xa30 rmap_walk_anon at mm/rmap.c:1864 [ 6147.628639][T64921] try_to_unmap+0x209/0x2d0 try_to_unmap at mm/rmap.c:1763 [ 6147.633026][T64921] ? rmap_walk_locked+0x140/0x140 [ 6147.637936][T64921] ? page_remove_rmap+0x1190/0x1190 [ 6147.643020][T64921] ? page_not_mapped+0x10/0x10 [ 6147.647668][T64921] ? page_get_anon_vma+0x290/0x290 [ 6147.652664][T64921] ? page_mapcount_is_zero+0x10/0x10 [ 6147.657838][T64921] ? hugetlb_page_mapping_lock_write+0x97/0x180 [ 6147.663972][T64921] migrate_pages+0x1005/0x1fb0 [ 6147.668617][T64921] ? remove_migration_pte+0xac0/0xac0 [ 6147.673875][T64921] move_pages_and_store_status.isra.47+0xd7/0x1a0 [ 6147.680181][T64921] ? migrate_pages+0x1fb0/0x1fb0 [ 6147.685002][T64921] __x64_sys_move_pages+0xa5c/0x1100 [ 6147.690176][T64921] ? trace_hardirqs_on+0x20/0x1b5 [ 6147.695084][T64921] ? move_pages_and_store_status.isra.47+0x1a0/0x1a0 [ 6147.701653][T64921] ? rcu_read_lock_sched_held+0xaa/0xd0 [ 6147.707088][T64921] ? switch_fpu_return+0x196/0x400 [ 6147.712083][T64921] ? lockdep_hardirqs_on_prepare+0x38c/0x550 [ 6147.717954][T64921] ? do_syscall_64+0x24/0x310 [ 6147.722513][T64921] do_syscall_64+0x5f/0x310 [ 6147.726897][T64921] ? trace_hardirqs_off+0x12/0x1a0 [ 6147.731894][T64921] ? asm_exc_page_fault+0x8/0x30 [ 6147.736714][T64921] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Hugh Dickens diagnosed this as a migration bug caused by code introduced to use i_mmap_rwsem for pmd sharing synchronization. Specifically, the routine unmap_and_move_huge_page() is always passing the TTU_RMAP_LOCKED flag to try_to_unmap() while holding i_mmap_rwsem. This is wrong for anon pages as the anon_vma_lock should be held in this case. Further analysis suggested that i_mmap_rwsem was not required to he held at all when calling try_to_unmap for anon pages as an anon page could never be part of a shared pmd mapping. Discussion also revealed that the hack in hugetlb_page_mapping_lock_write to drop page lock and acquire i_mmap_rwsem is wrong. There is no way to keep mapping valid while dropping page lock. This patch does the following: - Do not take i_mmap_rwsem and set TTU_RMAP_LOCKED for anon pages when calling try_to_unmap. - Remove the hacky code in hugetlb_page_mapping_lock_write. The routine will now simply do a 'trylock' while still holding the page lock. If the trylock fails, it will return NULL. This could impact the callers: - migration calling code will receive -EAGAIN and retry up to the hard coded limit (10). - memory error code will treat the page as BUSY. This will force killing (SIGKILL) instead of SIGBUS any mapping tasks. Do note that this change in behavior only happens when there is a race. None of the standard kernel testing suites actually hit this race, but it is possible. [1] https://lore.kernel.org/lkml/20200708012044.GC992@lca.pw/ [2] https://lore.kernel.org/linux-mm/alpine.LSU.2.11.2010071833100.2214@eggly.a… Link: https://lkml.kernel.org/r/20201105195058.78401-1-mike.kravetz@oracle.com Fixes: c0d0381ade79 ("hugetlbfs: use i_mmap_rwsem for more pmd sharing synchronization") Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com> Reported-by: Qian Cai <cai(a)lca.pw> Suggested-by: Hugh Dickins <hughd(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/hugetlb.c | 90 ++---------------------------------------- mm/memory-failure.c | 36 +++++++--------- mm/migrate.c | 46 +++++++++++---------- mm/rmap.c | 5 -- 4 files changed, 48 insertions(+), 129 deletions(-) --- a/mm/hugetlb.c~hugetlbfs-fix-anon-huge-page-migration-race +++ a/mm/hugetlb.c @@ -1568,103 +1568,23 @@ int PageHeadHuge(struct page *page_head) } /* - * Find address_space associated with hugetlbfs page. - * Upon entry page is locked and page 'was' mapped although mapped state - * could change. If necessary, use anon_vma to find vma and associated - * address space. The returned mapping may be stale, but it can not be - * invalid as page lock (which is held) is required to destroy mapping. - */ -static struct address_space *_get_hugetlb_page_mapping(struct page *hpage) -{ - struct anon_vma *anon_vma; - pgoff_t pgoff_start, pgoff_end; - struct anon_vma_chain *avc; - struct address_space *mapping = page_mapping(hpage); - - /* Simple file based mapping */ - if (mapping) - return mapping; - - /* - * Even anonymous hugetlbfs mappings are associated with an - * underlying hugetlbfs file (see hugetlb_file_setup in mmap - * code). Find a vma associated with the anonymous vma, and - * use the file pointer to get address_space. - */ - anon_vma = page_lock_anon_vma_read(hpage); - if (!anon_vma) - return mapping; /* NULL */ - - /* Use first found vma */ - pgoff_start = page_to_pgoff(hpage); - pgoff_end = pgoff_start + pages_per_huge_page(page_hstate(hpage)) - 1; - anon_vma_interval_tree_foreach(avc, &anon_vma->rb_root, - pgoff_start, pgoff_end) { - struct vm_area_struct *vma = avc->vma; - - mapping = vma->vm_file->f_mapping; - break; - } - - anon_vma_unlock_read(anon_vma); - return mapping; -} - -/* * Find and lock address space (mapping) in write mode. * - * Upon entry, the page is locked which allows us to find the mapping - * even in the case of an anon page. However, locking order dictates - * the i_mmap_rwsem be acquired BEFORE the page lock. This is hugetlbfs - * specific. So, we first try to lock the sema while still holding the - * page lock. If this works, great! If not, then we need to drop the - * page lock and then acquire i_mmap_rwsem and reacquire page lock. Of - * course, need to revalidate state along the way. + * Upon entry, the page is locked which means that page_mapping() is + * stable. Due to locking order, we can only trylock_write. If we can + * not get the lock, simply return NULL to caller. */ struct address_space *hugetlb_page_mapping_lock_write(struct page *hpage) { - struct address_space *mapping, *mapping2; + struct address_space *mapping = page_mapping(hpage); - mapping = _get_hugetlb_page_mapping(hpage); -retry: if (!mapping) return mapping; - /* - * If no contention, take lock and return - */ if (i_mmap_trylock_write(mapping)) return mapping; - /* - * Must drop page lock and wait on mapping sema. - * Note: Once page lock is dropped, mapping could become invalid. - * As a hack, increase map count until we lock page again. - */ - atomic_inc(&hpage->_mapcount); - unlock_page(hpage); - i_mmap_lock_write(mapping); - lock_page(hpage); - atomic_add_negative(-1, &hpage->_mapcount); - - /* verify page is still mapped */ - if (!page_mapped(hpage)) { - i_mmap_unlock_write(mapping); - return NULL; - } - - /* - * Get address space again and verify it is the same one - * we locked. If not, drop lock and retry. - */ - mapping2 = _get_hugetlb_page_mapping(hpage); - if (mapping2 != mapping) { - i_mmap_unlock_write(mapping); - mapping = mapping2; - goto retry; - } - - return mapping; + return NULL; } pgoff_t __basepage_index(struct page *page) --- a/mm/memory-failure.c~hugetlbfs-fix-anon-huge-page-migration-race +++ a/mm/memory-failure.c @@ -1057,27 +1057,25 @@ static bool hwpoison_user_mappings(struc if (!PageHuge(hpage)) { unmap_success = try_to_unmap(hpage, ttu); } else { - /* - * For hugetlb pages, try_to_unmap could potentially call - * huge_pmd_unshare. Because of this, take semaphore in - * write mode here and set TTU_RMAP_LOCKED to indicate we - * have taken the lock at this higer level. - * - * Note that the call to hugetlb_page_mapping_lock_write - * is necessary even if mapping is already set. It handles - * ugliness of potentially having to drop page lock to obtain - * i_mmap_rwsem. - */ - mapping = hugetlb_page_mapping_lock_write(hpage); - - if (mapping) { - unmap_success = try_to_unmap(hpage, + if (!PageAnon(hpage)) { + /* + * For hugetlb pages in shared mappings, try_to_unmap + * could potentially call huge_pmd_unshare. Because of + * this, take semaphore in write mode here and set + * TTU_RMAP_LOCKED to indicate we have taken the lock + * at this higer level. + */ + mapping = hugetlb_page_mapping_lock_write(hpage); + if (mapping) { + unmap_success = try_to_unmap(hpage, ttu|TTU_RMAP_LOCKED); - i_mmap_unlock_write(mapping); + i_mmap_unlock_write(mapping); + } else { + pr_info("Memory failure: %#lx: could not lock mapping for mapped huge page\n", pfn); + unmap_success = false; + } } else { - pr_info("Memory failure: %#lx: could not find mapping for mapped huge page\n", - pfn); - unmap_success = false; + unmap_success = try_to_unmap(hpage, ttu); } } if (!unmap_success) --- a/mm/migrate.c~hugetlbfs-fix-anon-huge-page-migration-race +++ a/mm/migrate.c @@ -1328,34 +1328,38 @@ static int unmap_and_move_huge_page(new_ goto put_anon; if (page_mapped(hpage)) { - /* - * try_to_unmap could potentially call huge_pmd_unshare. - * Because of this, take semaphore in write mode here and - * set TTU_RMAP_LOCKED to let lower levels know we have - * taken the lock. - */ - mapping = hugetlb_page_mapping_lock_write(hpage); - if (unlikely(!mapping)) - goto unlock_put_anon; - - try_to_unmap(hpage, - TTU_MIGRATION|TTU_IGNORE_MLOCK|TTU_IGNORE_ACCESS| - TTU_RMAP_LOCKED); + bool mapping_locked = false; + enum ttu_flags ttu = TTU_MIGRATION|TTU_IGNORE_MLOCK| + TTU_IGNORE_ACCESS; + + if (!PageAnon(hpage)) { + /* + * In shared mappings, try_to_unmap could potentially + * call huge_pmd_unshare. Because of this, take + * semaphore in write mode here and set TTU_RMAP_LOCKED + * to let lower levels know we have taken the lock. + */ + mapping = hugetlb_page_mapping_lock_write(hpage); + if (unlikely(!mapping)) + goto unlock_put_anon; + + mapping_locked = true; + ttu |= TTU_RMAP_LOCKED; + } + + try_to_unmap(hpage, ttu); page_was_mapped = 1; - /* - * Leave mapping locked until after subsequent call to - * remove_migration_ptes() - */ + + if (mapping_locked) + i_mmap_unlock_write(mapping); } if (!page_mapped(hpage)) rc = move_to_new_page(new_hpage, hpage, mode); - if (page_was_mapped) { + if (page_was_mapped) remove_migration_ptes(hpage, - rc == MIGRATEPAGE_SUCCESS ? new_hpage : hpage, true); - i_mmap_unlock_write(mapping); - } + rc == MIGRATEPAGE_SUCCESS ? new_hpage : hpage, false); unlock_put_anon: unlock_page(new_hpage); --- a/mm/rmap.c~hugetlbfs-fix-anon-huge-page-migration-race +++ a/mm/rmap.c @@ -1413,9 +1413,6 @@ static bool try_to_unmap_one(struct page /* * If sharing is possible, start and end will be adjusted * accordingly. - * - * If called for a huge page, caller must hold i_mmap_rwsem - * in write mode as it is possible to call huge_pmd_unshare. */ adjust_range_if_pmd_sharing_possible(vma, &range.start, &range.end); @@ -1462,7 +1459,7 @@ static bool try_to_unmap_one(struct page subpage = page - page_to_pfn(page) + pte_pfn(*pvmw.pte); address = pvmw.address; - if (PageHuge(page)) { + if (PageHuge(page) && !PageAnon(page)) { /* * To call huge_pmd_unshare, i_mmap_rwsem must be * held in write mode. Caller needs to explicitly _ Patches currently in -mm which might be from mike.kravetz(a)oracle.com are hugetlbfs-fix-anon-huge-page-migration-race.patch

4 years, 11 months

1
0
0 0

[PATCH] compiler-clang: remove version check for BPF Tracing

by Nick Desaulniers

bpftrace parses the kernel headers and uses Clang under the hood. Remove the version check when __BPF_TRACING__ is defined (as bpftrace does) so that this tool can continue to parse kernel headers, even with older clang sources. Cc: <stable(a)vger.kernel.org> Fixes: commit 1f7a44f63e6c ("compiler-clang: add build check for clang 10.0.1") Reported-by: Chen Yu <yu.chen.surf(a)gmail.com> Reported-by: Jarkko Sakkinen <jarkko(a)kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers(a)google.com> --- include/linux/compiler-clang.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h index dd7233c48bf3..98cff1b4b088 100644 --- a/include/linux/compiler-clang.h +++ b/include/linux/compiler-clang.h @@ -8,8 +8,10 @@ + __clang_patchlevel__) #if CLANG_VERSION < 100001 +#ifndef __BPF_TRACING__ # error Sorry, your version of Clang is too old - please use 10.0.1 or newer. #endif +#endif /* Compiler specific definitions for Clang compiler */ -- 2.29.1.341.ge80a0c044ae-goog

4 years, 11 months

6
7
0 0

stable-rc/queue/4.9 baseline: 145 runs, 1 regressions (v4.9.241-93-gd72fda650314)

by kernelci.org bot

stable-rc/queue/4.9 baseline: 145 runs, 1 regressions (v4.9.241-93-gd72fda650314) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ----------------------+------+--------------+----------+-----------------+------------ at91-sama5d4_xplained | arm | lab-baylibre | gcc-8 | sama5_defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F4.9/kernel/v4.9.241-… Test: baseline Tree: stable-rc Branch: queue/4.9 Describe: v4.9.241-93-gd72fda650314 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: d72fda650314bad8a108f72e4e271c56603b7e7a Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ----------------------+------+--------------+----------+-----------------+------------ at91-sama5d4_xplained | arm | lab-baylibre | gcc-8 | sama5_defconfig | 1 Details: https://kernelci.org/test/plan/id/5fa5561f400ccdc2f0db8894 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: sama5_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.241-93-gd72fda650314… HTML log: https://storage.kernelci.org//stable-rc/queue-4.9/v4.9.241-93-gd72fda650314… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/5fa5561f400ccdc2f0db8895 failing since 8 days (last pass: v4.9.240-139-gd719c4ad8056, first fail: v4.9.240-139-g65bd9a74252c)

4 years, 11 months

1
0
0 0

[PATCH 2/5] KVM: arm64: Don't hide ID registers from userspace

by Marc Zyngier

From: Andrew Jones <drjones(a)redhat.com> ID registers are RAZ until they've been allocated a purpose, but that doesn't mean they should be removed from the KVM_GET_REG_LIST list. So far we only have one register, SYS_ID_AA64ZFR0_EL1, that is hidden from userspace when its function, SVE, is not present. Expose SYS_ID_AA64ZFR0_EL1 to userspace as RAZ when SVE is not implemented. Removing the userspace visibility checks is enough to reexpose it, as it will already return zero to userspace when SVE is not present. The register already behaves as RAZ for the guest when SVE is not present. Fixes: 73433762fcae ("KVM: arm64/sve: System register context switch and access support") Reported-by: 张东旭 <xu910121(a)sina.com> Signed-off-by: Andrew Jones <drjones(a)redhat.com> Signed-off-by: Marc Zyngier <maz(a)kernel.org> Cc: stable(a)vger.kernel.org#v5.2+ Link: https://lore.kernel.org/r/20201105091022.15373-2-drjones@redhat.com --- arch/arm64/kvm/sys_regs.c | 18 +----------------- 1 file changed, 1 insertion(+), 17 deletions(-) diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c index 983994f01a63..3af306e6b9cd 100644 --- a/arch/arm64/kvm/sys_regs.c +++ b/arch/arm64/kvm/sys_regs.c @@ -1193,16 +1193,6 @@ static unsigned int sve_visibility(const struct kvm_vcpu *vcpu, return REG_HIDDEN_USER | REG_HIDDEN_GUEST; } -/* Visibility overrides for SVE-specific ID registers */ -static unsigned int sve_id_visibility(const struct kvm_vcpu *vcpu, - const struct sys_reg_desc *rd) -{ - if (vcpu_has_sve(vcpu)) - return 0; - - return REG_HIDDEN_USER; -} - /* Generate the emulated ID_AA64ZFR0_EL1 value exposed to the guest */ static u64 guest_id_aa64zfr0_el1(const struct kvm_vcpu *vcpu) { @@ -1229,9 +1219,6 @@ static int get_id_aa64zfr0_el1(struct kvm_vcpu *vcpu, { u64 val; - if (WARN_ON(!vcpu_has_sve(vcpu))) - return -ENOENT; - val = guest_id_aa64zfr0_el1(vcpu); return reg_to_user(uaddr, &val, reg->id); } @@ -1244,9 +1231,6 @@ static int set_id_aa64zfr0_el1(struct kvm_vcpu *vcpu, int err; u64 val; - if (WARN_ON(!vcpu_has_sve(vcpu))) - return -ENOENT; - err = reg_from_user(&val, uaddr, id); if (err) return err; @@ -1509,7 +1493,7 @@ static const struct sys_reg_desc sys_reg_descs[] = { ID_SANITISED(ID_AA64PFR1_EL1), ID_UNALLOCATED(4,2), ID_UNALLOCATED(4,3), - { SYS_DESC(SYS_ID_AA64ZFR0_EL1), access_id_aa64zfr0_el1, .get_user = get_id_aa64zfr0_el1, .set_user = set_id_aa64zfr0_el1, .visibility = sve_id_visibility }, + { SYS_DESC(SYS_ID_AA64ZFR0_EL1), access_id_aa64zfr0_el1, .get_user = get_id_aa64zfr0_el1, .set_user = set_id_aa64zfr0_el1, }, ID_UNALLOCATED(4,5), ID_UNALLOCATED(4,6), ID_UNALLOCATED(4,7), -- 2.28.0

4 years, 11 months

1
0
0 0

stable-rc/queue/4.14 baseline: 169 runs, 3 regressions (v4.14.204-3-g260838f69ee7e)

by kernelci.org bot

stable-rc/queue/4.14 baseline: 169 runs, 3 regressions (v4.14.204-3-g260838f69ee7e) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions -----------------+--------+--------------+----------+------------------+------------ qemu_i386 | i386 | lab-baylibre | gcc-8 | i386_defconfig | 1 qemu_x86_64 | x86_64 | lab-baylibre | gcc-8 | x86_64_defconfig | 1 qemu_x86_64-uefi | x86_64 | lab-baylibre | gcc-8 | x86_64_defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F4.14/kernel/v4.14.20… Test: baseline Tree: stable-rc Branch: queue/4.14 Describe: v4.14.204-3-g260838f69ee7e URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 260838f69ee7e908d8e885748336a3c45803d023 Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions -----------------+--------+--------------+----------+------------------+------------ qemu_i386 | i386 | lab-baylibre | gcc-8 | i386_defconfig | 1 Details: https://kernelci.org/test/plan/id/5fa5479245b76698d7db8859 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: i386_defconfig Compiler: gcc-8 (gcc (Debian 8.3.0-6) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.204-3-g260838f69ee… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.204-3-g260838f69ee… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/5fa5479245b76698d7db885a new failure (last pass: v4.14.204-2-g7fda2804efba) platform | arch | lab | compiler | defconfig | regressions -----------------+--------+--------------+----------+------------------+------------ qemu_x86_64 | x86_64 | lab-baylibre | gcc-8 | x86_64_defconfig | 1 Details: https://kernelci.org/test/plan/id/5fa54a0b5a4938684bdb887a Results: 0 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig Compiler: gcc-8 (gcc (Debian 8.3.0-6) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.204-3-g260838f69ee… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.204-3-g260838f69ee… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/5fa54a0b5a4938684bdb887b new failure (last pass: v4.14.204-2-g7fda2804efba) platform | arch | lab | compiler | defconfig | regressions -----------------+--------+--------------+----------+------------------+------------ qemu_x86_64-uefi | x86_64 | lab-baylibre | gcc-8 | x86_64_defconfig | 1 Details: https://kernelci.org/test/plan/id/5fa54a0c5a4938684bdb8882 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: x86_64_defconfig Compiler: gcc-8 (gcc (Debian 8.3.0-6) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.204-3-g260838f69ee… HTML log: https://storage.kernelci.org//stable-rc/queue-4.14/v4.14.204-3-g260838f69ee… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/5fa54a0c5a4938684bdb8883 new failure (last pass: v4.14.204-2-g7fda2804efba)

4 years, 11 months

1
0
0 0

patch "serial: txx9: add missing platform_driver_unregister() on error in" added to tty-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: txx9: add missing platform_driver_unregister() on error in to my tty git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git in the tty-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 0c5fc92622ed5531ff324b20f014e9e3092f0187 Mon Sep 17 00:00:00 2001 From: Qinglang Miao <miaoqinglang(a)huawei.com> Date: Tue, 3 Nov 2020 16:49:42 +0800 Subject: serial: txx9: add missing platform_driver_unregister() on error in serial_txx9_init Add the missing platform_driver_unregister() before return from serial_txx9_init in the error handling case when failed to register serial_txx9_pci_driver with macro ENABLE_SERIAL_TXX9_PCI defined. Fixes: ab4382d27412 ("tty: move drivers/serial/ to drivers/tty/serial/") Signed-off-by: Qinglang Miao <miaoqinglang(a)huawei.com> Link: https://lore.kernel.org/r/20201103084942.109076-1-miaoqinglang@huawei.com Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/serial_txx9.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/tty/serial/serial_txx9.c b/drivers/tty/serial/serial_txx9.c index b4d89e31730e..7a07e7272de1 100644 --- a/drivers/tty/serial/serial_txx9.c +++ b/drivers/tty/serial/serial_txx9.c @@ -1280,6 +1280,9 @@ static int __init serial_txx9_init(void) #ifdef ENABLE_SERIAL_TXX9_PCI ret = pci_register_driver(&serial_txx9_pci_driver); + if (ret) { + platform_driver_unregister(&serial_txx9_plat_driver); + } #endif if (ret == 0) goto out; -- 2.29.2

4 years, 11 months

1
0
0 0

patch "tty: fix crash in release_tty if tty->port is not set" added to tty-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tty: fix crash in release_tty if tty->port is not set to my tty git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git in the tty-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 4466d6d2f80c1193e0845d110277c56da77a6418 Mon Sep 17 00:00:00 2001 From: Matthias Reichl <hias(a)horus.com> Date: Thu, 5 Nov 2020 13:34:32 +0100 Subject: tty: fix crash in release_tty if tty->port is not set Commit 2ae0b31e0face ("tty: don't crash in tty_init_dev when missing tty_port") didn't fully prevent the crash as the cleanup path in tty_init_dev() calls release_tty() which dereferences tty->port without checking it for non-null. Add tty->port checks to release_tty to avoid the kernel crash. Fixes: 2ae0b31e0face ("tty: don't crash in tty_init_dev when missing tty_port") Signed-off-by: Matthias Reichl <hias(a)horus.com> Link: https://lore.kernel.org/r/20201105123432.4448-1-hias@horus.com Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/tty_io.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c index 7a4c02548fb3..9f8b9a567b35 100644 --- a/drivers/tty/tty_io.c +++ b/drivers/tty/tty_io.c @@ -1515,10 +1515,12 @@ static void release_tty(struct tty_struct *tty, int idx) tty->ops->shutdown(tty); tty_save_termios(tty); tty_driver_remove_tty(tty->driver, tty); - tty->port->itty = NULL; + if (tty->port) + tty->port->itty = NULL; if (tty->link) tty->link->port->itty = NULL; - tty_buffer_cancel_work(tty->port); + if (tty->port) + tty_buffer_cancel_work(tty->port); if (tty->link) tty_buffer_cancel_work(tty->link->port); -- 2.29.2

4 years, 11 months

1
0
0 0

patch "tty: serial: imx: enable earlycon by default if IMX_SERIAL_CONSOLE is" added to tty-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tty: serial: imx: enable earlycon by default if IMX_SERIAL_CONSOLE is to my tty git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git in the tty-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 427627a23c3e86e31113f9db9bfdca41698a0ee5 Mon Sep 17 00:00:00 2001 From: Lucas Stach <l.stach(a)pengutronix.de> Date: Thu, 5 Nov 2020 21:40:26 +0100 Subject: tty: serial: imx: enable earlycon by default if IMX_SERIAL_CONSOLE is enabled Since 699cc4dfd140 (tty: serial: imx: add imx earlycon driver), the earlycon part of imx serial is a separate driver and isn't necessarily enabled anymore when the console is enabled. This causes users to loose the earlycon functionality when upgrading their kenrel configuration via oldconfig. Enable earlycon by default when IMX_SERIAL_CONSOLE is enabled. Fixes: 699cc4dfd140 (tty: serial: imx: add imx earlycon driver) Reviewed-by: Fabio Estevam <festevam(a)gmail.com> Reviewed-by: Fugang Duan <fugang.duan(a)nxp.com> Signed-off-by: Lucas Stach <l.stach(a)pengutronix.de> Link: https://lore.kernel.org/r/20201105204026.1818219-1-l.stach@pengutronix.de Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index 1044fc387691..28f22e58639c 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -522,6 +522,7 @@ config SERIAL_IMX_EARLYCON depends on OF select SERIAL_EARLYCON select SERIAL_CORE_CONSOLE + default y if SERIAL_IMX_CONSOLE help If you have enabled the earlycon on the Freescale IMX CPU you can make it the earlycon by answering Y to this option. -- 2.29.2

4 years, 11 months

1
0
0 0

patch "serial: 8250_mtk: Fix uart_get_baud_rate warning" added to tty-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: 8250_mtk: Fix uart_get_baud_rate warning to my tty git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git in the tty-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 912ab37c798770f21b182d656937072b58553378 Mon Sep 17 00:00:00 2001 From: Claire Chang <tientzu(a)chromium.org> Date: Mon, 2 Nov 2020 20:07:49 +0800 Subject: serial: 8250_mtk: Fix uart_get_baud_rate warning Mediatek 8250 port supports speed higher than uartclk / 16. If the baud rates in both the new and the old termios setting are higher than uartclk / 16, the WARN_ON in uart_get_baud_rate() will be triggered. Passing NULL as the old termios so uart_get_baud_rate() will use uartclk / 16 - 1 as the new baud rate which will be replaced by the original baud rate later by tty_termios_encode_baud_rate() in mtk8250_set_termios(). Fixes: 551e553f0d4a ("serial: 8250_mtk: Fix high-speed baud rates clamping") Signed-off-by: Claire Chang <tientzu(a)chromium.org> Link: https://lore.kernel.org/r/20201102120749.374458-1-tientzu@chromium.org Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/8250/8250_mtk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/8250/8250_mtk.c b/drivers/tty/serial/8250/8250_mtk.c index 41f4120abdf2..fa876e2c13e5 100644 --- a/drivers/tty/serial/8250/8250_mtk.c +++ b/drivers/tty/serial/8250/8250_mtk.c @@ -317,7 +317,7 @@ mtk8250_set_termios(struct uart_port *port, struct ktermios *termios, */ baud = tty_termios_baud_rate(termios); - serial8250_do_set_termios(port, termios, old); + serial8250_do_set_termios(port, termios, NULL); tty_termios_encode_baud_rate(termios, baud, baud); -- 2.29.2

4 years, 11 months

1
0
0 0

stable-rc/queue/5.4 baseline: 200 runs, 2 regressions (v5.4.75-10-g67af28cd92c3)

by kernelci.org bot

stable-rc/queue/5.4 baseline: 200 runs, 2 regressions (v5.4.75-10-g67af28cd92c3) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ----------------------+------+--------------+----------+--------------------+------------ at91-sama5d4_xplained | arm | lab-baylibre | gcc-8 | sama5_defconfig | 1 stm32mp157c-dk2 | arm | lab-baylibre | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/job/stable-rc/branch/queue%2F5.4/kernel/v5.4.75-1… Test: baseline Tree: stable-rc Branch: queue/5.4 Describe: v5.4.75-10-g67af28cd92c3 URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git SHA: 67af28cd92c335d52d54b9a5652b87df0f217dde Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ----------------------+------+--------------+----------+--------------------+------------ at91-sama5d4_xplained | arm | lab-baylibre | gcc-8 | sama5_defconfig | 1 Details: https://kernelci.org/test/plan/id/5fa54278adb109f4a3db8866 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: sama5_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.75-10-g67af28cd92c3/… HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.75-10-g67af28cd92c3/… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/5fa54278adb109f4a3db8867 failing since 8 days (last pass: v5.4.72-409-gbbe9df5e07cf, first fail: v5.4.72-409-ga6e47f533653) platform | arch | lab | compiler | defconfig | regressions ----------------------+------+--------------+----------+--------------------+------------ stm32mp157c-dk2 | arm | lab-baylibre | gcc-8 | multi_v7_defconfig | 1 Details: https://kernelci.org/test/plan/id/5fa545b43ba3117fa6db8871 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig Compiler: gcc-8 (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0) Plain log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.75-10-g67af28cd92c3/… HTML log: https://storage.kernelci.org//stable-rc/queue-5.4/v5.4.75-10-g67af28cd92c3/… Rootfs: http://storage.kernelci.org/images/rootfs/buildroot/kci-2020.05-4-g97706c5d… * baseline.login: https://kernelci.org/test/case/id/5fa545b43ba3117fa6db8872 failing since 11 days (last pass: v5.4.72-54-gc97bc0eb3ef2, first fail: v5.4.72-402-g22eb6f319bc6)

4 years, 11 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror