March 2018 - Linux-stable-mirror

[merged] mm-vmalloc-add-interfaces-to-free-unmapped-page-table.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/vmalloc: add interfaces to free unmapped page table has been removed from the -mm tree. Its filename was mm-vmalloc-add-interfaces-to-free-unmapped-page-table.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Toshi Kani <toshi.kani(a)hpe.com> Subject: mm/vmalloc: add interfaces to free unmapped page table On architectures with CONFIG_HAVE_ARCH_HUGE_VMAP set, ioremap() may create pud/pmd mappings. Kernel panic was observed on arm64 systems with Cortex-A75 in the following steps as described by Hanjun Guo. 1. ioremap a 4K size, valid page table will build, 2. iounmap it, pte0 will set to 0; 3. ioremap the same address with 2M size, pgd/pmd is unchanged, then set the a new value for pmd; 4. pte0 is leaked; 5. CPU may meet exception because the old pmd is still in TLB, which will lead to kernel panic. This panic is not reproducible on x86. INVLPG, called from iounmap, purges all levels of entries associated with purged address on x86. x86 still has memory leak. The patch changes the ioremap path to free unmapped page table(s) since doing so in the unmap path has the following issues: - The iounmap() path is shared with vunmap(). Since vmap() only supports pte mappings, making vunmap() to free a pte page is an overhead for regular vmap users as they do not need a pte page freed up. - Checking if all entries in a pte page are cleared in the unmap path is racy, and serializing this check is expensive. - The unmap path calls free_vmap_area_noflush() to do lazy TLB purges. Clearing a pud/pmd entry before the lazy TLB purges needs extra TLB purge. Add two interfaces, pud_free_pmd_page() and pmd_free_pte_page(), which clear a given pud/pmd entry and free up a page for the lower level entries. This patch implements their stub functions on x86 and arm64, which work as workaround. [akpm(a)linux-foundation.org: fix typo in pmd_free_pte_page() stub] Link: http://lkml.kernel.org/r/20180314180155.19492-2-toshi.kani@hpe.com Fixes: e61ce6ade404e ("mm: change ioremap to set up huge I/O mappings") Reported-by: Lei Li <lious.lilei(a)hisilicon.com> Signed-off-by: Toshi Kani <toshi.kani(a)hpe.com> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Wang Xuefeng <wxf.wang(a)hisilicon.com> Cc: Will Deacon <will.deacon(a)arm.com> Cc: Hanjun Guo <guohanjun(a)huawei.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: "H. Peter Anvin" <hpa(a)zytor.com> Cc: Borislav Petkov <bp(a)suse.de> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Chintan Pandya <cpandya(a)codeaurora.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/arm64/mm/mmu.c | 10 ++++++++++ arch/x86/mm/pgtable.c | 24 ++++++++++++++++++++++++ include/asm-generic/pgtable.h | 10 ++++++++++ lib/ioremap.c | 6 ++++-- 4 files changed, 48 insertions(+), 2 deletions(-) diff -puN arch/arm64/mm/mmu.c~mm-vmalloc-add-interfaces-to-free-unmapped-page-table arch/arm64/mm/mmu.c --- a/arch/arm64/mm/mmu.c~mm-vmalloc-add-interfaces-to-free-unmapped-page-table +++ a/arch/arm64/mm/mmu.c @@ -972,3 +972,13 @@ int pmd_clear_huge(pmd_t *pmdp) pmd_clear(pmdp); return 1; } + +int pud_free_pmd_page(pud_t *pud) +{ + return pud_none(*pud); +} + +int pmd_free_pte_page(pmd_t *pmd) +{ + return pmd_none(*pmd); +} diff -puN arch/x86/mm/pgtable.c~mm-vmalloc-add-interfaces-to-free-unmapped-page-table arch/x86/mm/pgtable.c --- a/arch/x86/mm/pgtable.c~mm-vmalloc-add-interfaces-to-free-unmapped-page-table +++ a/arch/x86/mm/pgtable.c @@ -702,4 +702,28 @@ int pmd_clear_huge(pmd_t *pmd) return 0; } + +/** + * pud_free_pmd_page - Clear pud entry and free pmd page. + * @pud: Pointer to a PUD. + * + * Context: The pud range has been unmaped and TLB purged. + * Return: 1 if clearing the entry succeeded. 0 otherwise. + */ +int pud_free_pmd_page(pud_t *pud) +{ + return pud_none(*pud); +} + +/** + * pmd_free_pte_page - Clear pmd entry and free pte page. + * @pmd: Pointer to a PMD. + * + * Context: The pmd range has been unmaped and TLB purged. + * Return: 1 if clearing the entry succeeded. 0 otherwise. + */ +int pmd_free_pte_page(pmd_t *pmd) +{ + return pmd_none(*pmd); +} #endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */ diff -puN include/asm-generic/pgtable.h~mm-vmalloc-add-interfaces-to-free-unmapped-page-table include/asm-generic/pgtable.h --- a/include/asm-generic/pgtable.h~mm-vmalloc-add-interfaces-to-free-unmapped-page-table +++ a/include/asm-generic/pgtable.h @@ -983,6 +983,8 @@ int pud_set_huge(pud_t *pud, phys_addr_t int pmd_set_huge(pmd_t *pmd, phys_addr_t addr, pgprot_t prot); int pud_clear_huge(pud_t *pud); int pmd_clear_huge(pmd_t *pmd); +int pud_free_pmd_page(pud_t *pud); +int pmd_free_pte_page(pmd_t *pmd); #else /* !CONFIG_HAVE_ARCH_HUGE_VMAP */ static inline int p4d_set_huge(p4d_t *p4d, phys_addr_t addr, pgprot_t prot) { @@ -1008,6 +1010,14 @@ static inline int pmd_clear_huge(pmd_t * { return 0; } +static inline int pud_free_pmd_page(pud_t *pud) +{ + return 0; +} +static inline int pmd_free_pte_page(pmd_t *pmd) +{ + return 0; +} #endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */ #ifndef __HAVE_ARCH_FLUSH_PMD_TLB_RANGE diff -puN lib/ioremap.c~mm-vmalloc-add-interfaces-to-free-unmapped-page-table lib/ioremap.c --- a/lib/ioremap.c~mm-vmalloc-add-interfaces-to-free-unmapped-page-table +++ a/lib/ioremap.c @@ -91,7 +91,8 @@ static inline int ioremap_pmd_range(pud_ if (ioremap_pmd_enabled() && ((next - addr) == PMD_SIZE) && - IS_ALIGNED(phys_addr + addr, PMD_SIZE)) { + IS_ALIGNED(phys_addr + addr, PMD_SIZE) && + pmd_free_pte_page(pmd)) { if (pmd_set_huge(pmd, phys_addr + addr, prot)) continue; } @@ -117,7 +118,8 @@ static inline int ioremap_pud_range(p4d_ if (ioremap_pud_enabled() && ((next - addr) == PUD_SIZE) && - IS_ALIGNED(phys_addr + addr, PUD_SIZE)) { + IS_ALIGNED(phys_addr + addr, PUD_SIZE) && + pud_free_pmd_page(pud)) { if (pud_set_huge(pud, phys_addr + addr, prot)) continue; } _ Patches currently in -mm which might be from toshi.kani(a)hpe.com are

6 years, 9 months

1
0
0 0

[merged] h8300-remove-extranous-__big_endian-definition.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: h8300: remove extraneous __BIG_ENDIAN definition has been removed from the -mm tree. Its filename was h8300-remove-extranous-__big_endian-definition.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Arnd Bergmann <arnd(a)arndb.de> Subject: h8300: remove extraneous __BIG_ENDIAN definition A bugfix I did earlier caused a build regression on h8300, which defines the __BIG_ENDIAN macro in a slightly different way than the generic code: arch/h8300/include/asm/byteorder.h:5:0: warning: "__BIG_ENDIAN" redefined We don't need to define it here, as the same macro is already provided by the linux/byteorder/big_endian.h, and that version does not conflict. While this is a v4.16 regression, my earlier patch also got backported to the 4.14 and 4.15 stable kernels, so we need the fixup there as well. Link: http://lkml.kernel.org/r/20180313120752.2645129-1-arnd@arndb.de Fixes: 101110f6271c ("Kbuild: always define endianess in kconfig.h") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Cc: Yoshinori Sato <ysato(a)users.sourceforge.jp> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/h8300/include/asm/byteorder.h | 1 - 1 file changed, 1 deletion(-) diff -puN arch/h8300/include/asm/byteorder.h~h8300-remove-extranous-__big_endian-definition arch/h8300/include/asm/byteorder.h --- a/arch/h8300/include/asm/byteorder.h~h8300-remove-extranous-__big_endian-definition +++ a/arch/h8300/include/asm/byteorder.h @@ -2,7 +2,6 @@ #ifndef __H8300_BYTEORDER_H__ #define __H8300_BYTEORDER_H__ -#define __BIG_ENDIAN __ORDER_BIG_ENDIAN__ #include <linux/byteorder/big_endian.h> #endif _ Patches currently in -mm which might be from arnd(a)arndb.de are

6 years, 9 months

1
0
0 0

[merged] hugetlbfs-check-for-pgoff-value-overflow.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: hugetlbfs: check for pgoff value overflow has been removed from the -mm tree. Its filename was hugetlbfs-check-for-pgoff-value-overflow.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Mike Kravetz <mike.kravetz(a)oracle.com> Subject: hugetlbfs: check for pgoff value overflow A vma with vm_pgoff large enough to overflow a loff_t type when converted to a byte offset can be passed via the remap_file_pages system call. The hugetlbfs mmap routine uses the byte offset to calculate reservations and file size. A sequence such as: mmap(0x20a00000, 0x600000, 0, 0x66033, -1, 0); remap_file_pages(0x20a00000, 0x600000, 0, 0x20000000000000, 0); will result in the following when task exits/file closed, kernel BUG at mm/hugetlb.c:749! Call Trace: hugetlbfs_evict_inode+0x2f/0x40 evict+0xcb/0x190 __dentry_kill+0xcb/0x150 __fput+0x164/0x1e0 task_work_run+0x84/0xa0 exit_to_usermode_loop+0x7d/0x80 do_syscall_64+0x18b/0x190 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 The overflowed pgoff value causes hugetlbfs to try to set up a mapping with a negative range (end < start) that leaves invalid state which causes the BUG. The previous overflow fix to this code was incomplete and did not take the remap_file_pages system call into account. [mike.kravetz(a)oracle.com: v3] Link: http://lkml.kernel.org/r/20180309002726.7248-1-mike.kravetz@oracle.com [akpm(a)linux-foundation.org: include mmdebug.h] [akpm(a)linux-foundation.org: fix -ve left shift count on sh] Link: http://lkml.kernel.org/r/20180308210502.15952-1-mike.kravetz@oracle.com Fixes: 045c7a3f53d9 ("hugetlbfs: fix offset overflow in hugetlbfs mmap") Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com> Reported-by: Nic Losby <blurbdust(a)gmail.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: "Kirill A . Shutemov" <kirill.shutemov(a)linux.intel.com> Cc: Yisheng Xie <xieyisheng1(a)huawei.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/hugetlbfs/inode.c | 17 ++++++++++++++--- mm/hugetlb.c | 7 +++++++ 2 files changed, 21 insertions(+), 3 deletions(-) diff -puN fs/hugetlbfs/inode.c~hugetlbfs-check-for-pgoff-value-overflow fs/hugetlbfs/inode.c --- a/fs/hugetlbfs/inode.c~hugetlbfs-check-for-pgoff-value-overflow +++ a/fs/hugetlbfs/inode.c @@ -108,6 +108,16 @@ static void huge_pagevec_release(struct pagevec_reinit(pvec); } +/* + * Mask used when checking the page offset value passed in via system + * calls. This value will be converted to a loff_t which is signed. + * Therefore, we want to check the upper PAGE_SHIFT + 1 bits of the + * value. The extra bit (- 1 in the shift value) is to take the sign + * bit into account. + */ +#define PGOFF_LOFFT_MAX \ + (((1UL << (PAGE_SHIFT + 1)) - 1) << (BITS_PER_LONG - (PAGE_SHIFT + 1))) + static int hugetlbfs_file_mmap(struct file *file, struct vm_area_struct *vma) { struct inode *inode = file_inode(file); @@ -127,12 +137,13 @@ static int hugetlbfs_file_mmap(struct fi vma->vm_ops = &hugetlb_vm_ops; /* - * Offset passed to mmap (before page shift) could have been - * negative when represented as a (l)off_t. + * page based offset in vm_pgoff could be sufficiently large to + * overflow a (l)off_t when converted to byte offset. */ - if (((loff_t)vma->vm_pgoff << PAGE_SHIFT) < 0) + if (vma->vm_pgoff & PGOFF_LOFFT_MAX) return -EINVAL; + /* must be huge page aligned */ if (vma->vm_pgoff & (~huge_page_mask(h) >> PAGE_SHIFT)) return -EINVAL; diff -puN mm/hugetlb.c~hugetlbfs-check-for-pgoff-value-overflow mm/hugetlb.c --- a/mm/hugetlb.c~hugetlbfs-check-for-pgoff-value-overflow +++ a/mm/hugetlb.c @@ -18,6 +18,7 @@ #include <linux/bootmem.h> #include <linux/sysfs.h> #include <linux/slab.h> +#include <linux/mmdebug.h> #include <linux/sched/signal.h> #include <linux/rmap.h> #include <linux/string_helpers.h> @@ -4374,6 +4375,12 @@ int hugetlb_reserve_pages(struct inode * struct resv_map *resv_map; long gbl_reserve; + /* This should never happen */ + if (from > to) { + VM_WARN(1, "%s called with a negative range\n", __func__); + return -EINVAL; + } + /* * Only apply hugepage reservation if asked. At fault time, an * attempt will be made for VM_NORESERVE to allocate a page _ Patches currently in -mm which might be from mike.kravetz(a)oracle.com are shm-add-split-function-to-shm_vm_ops.patch mm-hugetlbfs-move-hugetlbfs_i-outside-ifdef-config_hugetlbfs.patch mm-memfd-split-out-memfd-for-use-by-multiple-filesystems.patch mm-memfd-remove-memfd-code-from-shmem-files-and-use-new-memfd-files.patch mm-make-start_isolate_page_range-fail-if-already-isolated.patch

6 years, 9 months

1
0
0 0

[merged] lockdep-fix-fs_reclaim-warning.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: lockdep: fix fs_reclaim warning has been removed from the -mm tree. Its filename was lockdep-fix-fs_reclaim-warning.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Subject: lockdep: fix fs_reclaim warning Dave Jones reported fs_reclaim lockdep warnings. ============================================ WARNING: possible recursive locking detected 4.15.0-rc9-backup-debug+ #1 Not tainted -------------------------------------------- sshd/24800 is trying to acquire lock: (fs_reclaim){+.+.}, at: [<0000000084f438c2>] fs_reclaim_acquire.part.102+0x5/0x30 but task is already holding lock: (fs_reclaim){+.+.}, at: [<0000000084f438c2>] fs_reclaim_acquire.part.102+0x5/0x30 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(fs_reclaim); lock(fs_reclaim); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by sshd/24800: #0: (sk_lock-AF_INET6){+.+.}, at: [<000000001a069652>] tcp_sendmsg+0x19/0x40 #1: (fs_reclaim){+.+.}, at: [<0000000084f438c2>] fs_reclaim_acquire.part.102+0x5/0x30 stack backtrace: CPU: 3 PID: 24800 Comm: sshd Not tainted 4.15.0-rc9-backup-debug+ #1 Call Trace: dump_stack+0xbc/0x13f __lock_acquire+0xa09/0x2040 lock_acquire+0x12e/0x350 fs_reclaim_acquire.part.102+0x29/0x30 kmem_cache_alloc+0x3d/0x2c0 alloc_extent_state+0xa7/0x410 __clear_extent_bit+0x3ea/0x570 try_release_extent_mapping+0x21a/0x260 __btrfs_releasepage+0xb0/0x1c0 btrfs_releasepage+0x161/0x170 try_to_release_page+0x162/0x1c0 shrink_page_list+0x1d5a/0x2fb0 shrink_inactive_list+0x451/0x940 shrink_node_memcg.constprop.88+0x4c9/0x5e0 shrink_node+0x12d/0x260 try_to_free_pages+0x418/0xaf0 __alloc_pages_slowpath+0x976/0x1790 __alloc_pages_nodemask+0x52c/0x5c0 new_slab+0x374/0x3f0 ___slab_alloc.constprop.81+0x47e/0x5a0 __slab_alloc.constprop.80+0x32/0x60 __kmalloc_track_caller+0x267/0x310 __kmalloc_reserve.isra.40+0x29/0x80 __alloc_skb+0xee/0x390 sk_stream_alloc_skb+0xb8/0x340 tcp_sendmsg_locked+0x8e6/0x1d30 tcp_sendmsg+0x27/0x40 inet_sendmsg+0xd0/0x310 sock_write_iter+0x17a/0x240 __vfs_write+0x2ab/0x380 vfs_write+0xfb/0x260 SyS_write+0xb6/0x140 do_syscall_64+0x1e5/0xc05 entry_SYSCALL64_slow_path+0x25/0x25 This warning is caused by commit d92a8cfcb37ecd13 ("locking/lockdep: Rework FS_RECLAIM annotation") which replaced lockdep_set_current_reclaim_state()/ lockdep_clear_current_reclaim_state() in __perform_reclaim() and lockdep_trace_alloc() in slab_pre_alloc_hook() with fs_reclaim_acquire()/ fs_reclaim_release(). Since __kmalloc_reserve() from __alloc_skb() adds __GFP_NOMEMALLOC | __GFP_NOWARN to gfp_mask, and all reclaim path simply propagates __GFP_NOMEMALLOC, fs_reclaim_acquire() in slab_pre_alloc_hook() is trying to grab the 'fake' lock again when __perform_reclaim() already grabbed the 'fake' lock. The /* this guy won't enter reclaim */ if ((current->flags & PF_MEMALLOC) && !(gfp_mask & __GFP_NOMEMALLOC)) return false; test which causes slab_pre_alloc_hook() to try to grab the 'fake' lock was added by commit cf40bd16fdad42c0 ("lockdep: annotate reclaim context (__GFP_NOFS)"). But that test is outdated because PF_MEMALLOC thread won't enter reclaim regardless of __GFP_NOMEMALLOC after commit 341ce06f69abfafa ("page allocator: calculate the alloc_flags for allocation only once") added the PF_MEMALLOC safeguard ( /* Avoid recursion of direct reclaim */ if (p->flags & PF_MEMALLOC) goto nopage; in __alloc_pages_slowpath()). Thus, let's fix outdated test by removing __GFP_NOMEMALLOC test and allow __need_fs_reclaim() to return false. Link: http://lkml.kernel.org/r/201802280650.FJC73911.FOSOMLJVFFQtHO@I-love.SAKURA… Fixes: d92a8cfcb37ecd13 ("locking/lockdep: Rework FS_RECLAIM annotation") Signed-off-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp> Reported-by: Dave Jones <davej(a)codemonkey.org.uk> Tested-by: Dave Jones <davej(a)codemonkey.org.uk> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Nick Piggin <npiggin(a)gmail.com> Cc: Ingo Molnar <mingo(a)elte.hu> Cc: Nikolay Borisov <nborisov(a)suse.com> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: <stable(a)vger.kernel.org> [4.14+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/page_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN mm/page_alloc.c~lockdep-fix-fs_reclaim-warning mm/page_alloc.c --- a/mm/page_alloc.c~lockdep-fix-fs_reclaim-warning +++ a/mm/page_alloc.c @@ -3596,7 +3596,7 @@ static bool __need_fs_reclaim(gfp_t gfp_ return false; /* this guy won't enter reclaim */ - if ((current->flags & PF_MEMALLOC) && !(gfp_mask & __GFP_NOMEMALLOC)) + if (current->flags & PF_MEMALLOC) return false; /* We're only interested __GFP_FS allocations for now */ _ Patches currently in -mm which might be from penguin-kernel(a)I-love.SAKURA.ne.jp are dentry-fix-kmemcheck-splat-at-take_dentry_name_snapshot.patch mmvmscan-dont-pretend-forward-progress-upon-shrinker_rwsem-contention.patch mmoom_reaper-check-for-mmf_oom_skip-before-complain.patch mmvmscan-mark-register_shrinker-as-__must_check.patch

6 years, 9 months

1
0
0 0

[PATCH] drm/i915: Fix hibernation with ACPI S0 target state

by Imre Deak

After commit dd9f31c7a3887950cbd0d49eb9d43f7a1518a356 Author: Imre Deak <imre.deak(a)intel.com> Date: Wed Aug 16 17:46:07 2017 +0300 drm/i915/gen9+: Set same power state before hibernation image save/restore during hibernation/suspend the power domain functionality got disabled, after which resume could leave it incorrectly disabled if the ACPI target state was S0 during suspend and i915 was not loaded by the loader kernel. This was caused by not considering if we resumed from hibernation as the condition for power domains reiniting. Fix this by simply tracking if we suspended power domains during system suspend and reinit power domains accordingly during resume. This will result in reiniting power domains always when resuming from hibernation, regardless of the platform and whether or not i915 is loaded by the loader kernel. The reason we didn't catch this earlier is that the enabled/disabled state of power domains during PMSG_FREEZE/PMSG_QUIESCE is platform and kernel config dependent: on my SKL the target state is S4 during PMSG_FREEZE and (with the driver loaded in the loader kernel) S0 during PMSG_QUIESCE. On the reporter's machine it's S0 during PMSG_FREEZE but (contrary to this) power domains are not initialized during PMSG_QUIESCE since i915 is not loaded in the loader kernel, or it's loaded but without the DMC firmware being available. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105196 Reported-and-tested-by: amn-bas(a)hotmail.com Fixes: dd9f31c7a388 ("drm/i915/gen9+: Set same power state before hibernation image save/restore") Cc: amn-bas(a)hotmail.com Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Imre Deak <imre.deak(a)intel.com> --- drivers/gpu/drm/i915/i915_drv.c | 22 ++++++++++------------ drivers/gpu/drm/i915/i915_drv.h | 2 +- 2 files changed, 11 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index a7d3275f45d2..f706cff4f01b 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1612,15 +1612,12 @@ static int i915_drm_suspend_late(struct drm_device *dev, bool hibernation) { struct drm_i915_private *dev_priv = to_i915(dev); struct pci_dev *pdev = dev_priv->drm.pdev; - bool fw_csr; int ret; disable_rpm_wakeref_asserts(dev_priv); intel_display_set_init_power(dev_priv, false); - fw_csr = !IS_GEN9_LP(dev_priv) && !hibernation && - suspend_to_idle(dev_priv) && dev_priv->csr.dmc_payload; /* * In case of firmware assisted context save/restore don't manually * deinit the power domains. This also means the CSR/DMC firmware will @@ -1628,8 +1625,11 @@ static int i915_drm_suspend_late(struct drm_device *dev, bool hibernation) * also enable deeper system power states that would be blocked if the * firmware was inactive. */ - if (!fw_csr) + if (IS_GEN9_LP(dev_priv) || hibernation || !suspend_to_idle(dev_priv) || + dev_priv->csr.dmc_payload == NULL) { intel_power_domains_suspend(dev_priv); + dev_priv->power_domains_suspended = true; + } ret = 0; if (IS_GEN9_LP(dev_priv)) @@ -1641,8 +1641,10 @@ static int i915_drm_suspend_late(struct drm_device *dev, bool hibernation) if (ret) { DRM_ERROR("Suspend complete failed: %d\n", ret); - if (!fw_csr) + if (dev_priv->power_domains_suspended) { intel_power_domains_init_hw(dev_priv, true); + dev_priv->power_domains_suspended = false; + } goto out; } @@ -1663,8 +1665,6 @@ static int i915_drm_suspend_late(struct drm_device *dev, bool hibernation) if (!(hibernation && INTEL_GEN(dev_priv) < 6)) pci_set_power_state(pdev, PCI_D3hot); - dev_priv->suspended_to_idle = suspend_to_idle(dev_priv); - out: enable_rpm_wakeref_asserts(dev_priv); @@ -1831,8 +1831,7 @@ static int i915_drm_resume_early(struct drm_device *dev) intel_uncore_resume_early(dev_priv); if (IS_GEN9_LP(dev_priv)) { - if (!dev_priv->suspended_to_idle) - gen9_sanitize_dc_state(dev_priv); + gen9_sanitize_dc_state(dev_priv); bxt_disable_dc9(dev_priv); } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) { hsw_disable_pc8(dev_priv); @@ -1840,8 +1839,7 @@ static int i915_drm_resume_early(struct drm_device *dev) intel_uncore_sanitize(dev_priv); - if (IS_GEN9_LP(dev_priv) || - !(dev_priv->suspended_to_idle && dev_priv->csr.dmc_payload)) + if (dev_priv->power_domains_suspended) intel_power_domains_init_hw(dev_priv, true); else intel_display_set_init_power(dev_priv, true); @@ -1851,7 +1849,7 @@ static int i915_drm_resume_early(struct drm_device *dev) enable_rpm_wakeref_asserts(dev_priv); out: - dev_priv->suspended_to_idle = false; + dev_priv->power_domains_suspended = false; return ret; } diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index c9c3b2ba6a86..3acc4bbec6b2 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1851,7 +1851,7 @@ struct drm_i915_private { u32 bxt_phy_grc; u32 suspend_count; - bool suspended_to_idle; + bool power_domains_suspended; struct i915_suspend_saved_registers regfile; struct vlv_s0ix_state vlv_s0ix_state; -- 2.13.2

6 years, 9 months

2
2
0 0

[PATCH] usb: dwc3: gadget: Fix list_del corruption in dwc3_ep_dequeue

by Jack Pham

From: Mayank Rana <mrana(a)codeaurora.org> dwc3_ep_dequeue() waits for completion of End Transfer command using wait_event_lock_irq(), which will release the dwc3->lock while waiting and reacquire after completion. This allows a potential race condition with ep_disable() which also removes all requests from started_list and pending_list. The check for NULL r->trb should catch this but currently it exits to the wrong 'out1' label which calls dwc3_gadget_giveback(). Since its list entry was already removed, if CONFIG_DEBUG_LIST is enabled a 'list_del corruption' bug is thrown since its next/prev pointers are already LIST_POISON1/2. If r->trb is NULL it should simply exit to 'out0'. Fixes: cf3113d893d4 ("usb: dwc3: gadget: properly increment dequeue pointer on ep_dequeue") Cc: stable(a)vger.kernel.org Signed-off-by: Mayank Rana <mrana(a)codeaurora.org> Signed-off-by: Jack Pham <jackp(a)codeaurora.org> --- drivers/usb/dwc3/gadget.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 2bda4eb..1238a97 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -1417,7 +1417,7 @@ static int dwc3_gadget_ep_dequeue(struct usb_ep *ep, dwc->lock); if (!r->trb) - goto out1; + goto out0; if (r->num_pending_sgs) { struct dwc3_trb *trb; -- 2.9.1.200.gb1ec08f

6 years, 9 months

1
1
0 0

[PATCH] crypto: arm,arm64 - Fix random regeneration of S_shipped

by Leonard Crestez

The decision to rebuild .S_shipped is made based on the relative timestamps of .S_shipped and .pl files but git makes this essentially random. This means that the perl script might run anyway (usually at most once per checkout), defeating the whole purpose of _shipped. Fix by skipping the rule unless explicit make variables are provided: REGENERATE_ARM_CRYPTO or REGENERATE_ARM64_CRYPTO. This can produce nasty occasional build failures downstream, for example for toolchains with broken perl. The solution is minimally intrusive to make it easier to push into stable. Another report on a similar issue here: https://lkml.org/lkml/2018/3/8/1379 Signed-off-by: Leonard Crestez <leonard.crestez(a)nxp.com> Cc: <stable(a)vger.kernel.org> --- arch/arm/crypto/Makefile | 2 ++ arch/arm64/crypto/Makefile | 2 ++ 2 files changed, 4 insertions(+) Not clear if this needs to go through crypto or arm but all commits in these directories start with "crypto:". My problems were only on arm64 because of a yocto toolchain which ships a version of perl which fails on "use integer;". CC stable because this can cause trouble for downstream packagers. diff --git a/arch/arm/crypto/Makefile b/arch/arm/crypto/Makefile index 30ef8e2..c9919c2 100644 --- a/arch/arm/crypto/Makefile +++ b/arch/arm/crypto/Makefile @@ -47,20 +47,22 @@ sha256-arm-y := sha256-core.o sha256_glue.o $(sha256-arm-neon-y) sha512-arm-neon-$(CONFIG_KERNEL_MODE_NEON) := sha512-neon-glue.o sha512-arm-y := sha512-core.o sha512-glue.o $(sha512-arm-neon-y) sha1-arm-ce-y := sha1-ce-core.o sha1-ce-glue.o sha2-arm-ce-y := sha2-ce-core.o sha2-ce-glue.o aes-arm-ce-y := aes-ce-core.o aes-ce-glue.o ghash-arm-ce-y := ghash-ce-core.o ghash-ce-glue.o crct10dif-arm-ce-y := crct10dif-ce-core.o crct10dif-ce-glue.o crc32-arm-ce-y:= crc32-ce-core.o crc32-ce-glue.o chacha20-neon-y := chacha20-neon-core.o chacha20-neon-glue.o +ifdef REGENERATE_ARM_CRYPTO quiet_cmd_perl = PERL $@ cmd_perl = $(PERL) $(<) > $(@) $(src)/sha256-core.S_shipped: $(src)/sha256-armv4.pl $(call cmd,perl) $(src)/sha512-core.S_shipped: $(src)/sha512-armv4.pl $(call cmd,perl) +endif .PRECIOUS: $(obj)/sha256-core.S $(obj)/sha512-core.S diff --git a/arch/arm64/crypto/Makefile b/arch/arm64/crypto/Makefile index cee9b8d9..dfe651b 100644 --- a/arch/arm64/crypto/Makefile +++ b/arch/arm64/crypto/Makefile @@ -60,20 +60,22 @@ obj-$(CONFIG_CRYPTO_AES_ARM64_BS) += aes-neon-bs.o aes-neon-bs-y := aes-neonbs-core.o aes-neonbs-glue.o AFLAGS_aes-ce.o := -DINTERLEAVE=4 AFLAGS_aes-neon.o := -DINTERLEAVE=4 CFLAGS_aes-glue-ce.o := -DUSE_V8_CRYPTO_EXTENSIONS $(obj)/aes-glue-%.o: $(src)/aes-glue.c FORCE $(call if_changed_rule,cc_o_c) +ifdef REGENERATE_ARM64_CRYPTO quiet_cmd_perlasm = PERLASM $@ cmd_perlasm = $(PERL) $(<) void $(@) $(src)/sha256-core.S_shipped: $(src)/sha512-armv8.pl $(call cmd,perlasm) $(src)/sha512-core.S_shipped: $(src)/sha512-armv8.pl $(call cmd,perlasm) +endif .PRECIOUS: $(obj)/sha256-core.S $(obj)/sha512-core.S -- 2.7.4

6 years, 9 months

4
3
0 0

patch "USB:fix USB3 devices behind USB3 hubs not resuming at hibernate thaw" added to usb-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB:fix USB3 devices behind USB3 hubs not resuming at hibernate thaw to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-next 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 also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From 64627388b50158fd24d6ad88132525b95a5ef573 Mon Sep 17 00:00:00 2001 From: Zhengjun Xing <zhengjun.xing(a)linux.intel.com> Date: Wed, 21 Mar 2018 13:29:42 +0800 Subject: USB:fix USB3 devices behind USB3 hubs not resuming at hibernate thaw MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit USB3 hubs don't support global suspend. USB3 specification 10.10, Enhanced SuperSpeed hubs only support selective suspend and resume, they do not support global suspend/resume where the hub downstream facing ports states are not affected. When system enters hibernation it first enters freeze process where only the root hub enters suspend, usb_port_suspend() is not called for other devices, and suspend status flags are not set for them. Other devices are expected to suspend globally. Some external USB3 hubs will suspend the downstream facing port at global suspend. These devices won't be resumed at thaw as the suspend status flag is not set. A USB3 removable hard disk connected through a USB3 hub that won't resume at thaw will fail to synchronize SCSI cache, return “cmd cmplt err -71” error, and needs a 60 seconds timeout which causing system hang for 60s before the USB host reset the port for the USB3 removable hard disk to recover. Fix this by always calling usb_port_suspend() during freeze for USB3 devices. Signed-off-by: Zhengjun Xing <zhengjun.xing(a)linux.intel.com> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/core/generic.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/usb/core/generic.c b/drivers/usb/core/generic.c index 83c14dda6300..bc8242bc4564 100644 --- a/drivers/usb/core/generic.c +++ b/drivers/usb/core/generic.c @@ -210,8 +210,13 @@ static int generic_suspend(struct usb_device *udev, pm_message_t msg) if (!udev->parent) rc = hcd_bus_suspend(udev, msg); - /* Non-root devices don't need to do anything for FREEZE or PRETHAW */ - else if (msg.event == PM_EVENT_FREEZE || msg.event == PM_EVENT_PRETHAW) + /* + * Non-root USB2 devices don't need to do anything for FREEZE + * or PRETHAW. USB3 devices don't support global suspend and + * needs to be selectively suspended. + */ + else if ((msg.event == PM_EVENT_FREEZE || msg.event == PM_EVENT_PRETHAW) + && (udev->speed < USB_SPEED_SUPER)) rc = 0; else rc = usb_port_suspend(udev, msg); -- 2.16.2

6 years, 9 months

1
0
0 0

l2tp stable request

by Daniel Rosenberg

f3c66d4e144a0904ea9b95d23ed9f8eb38c11bfb l2tp: prevent creation of sessions on terminated tunnels 9ee369a405c57613d7c83a3967780c3e30c52ecc l2tp: initialise session's refcount before making it reachable dbdbc73b44782e22b3b4b6e8b51e7a3d245f3086 l2tp: fix duplicate session creation 61b9a047729bb230978178bca6729689d0c50ca2 l2tp: fix race in l2tp_recv_common() For v3.18+. It requires some minor backporting. Without these, I'm seeing a null pointer in l2tp_session_create. These logs are from a 3.18 kernel, although I was able to hit it on a 4.4 kernel I tested as well. [ 376.388847] c1 11731 Unable to handle kernel NULL pointer dereference at virtual address 0000006c [ 376.388892] c1 11731 pgd = ffffffc093138000 [ 376.388908] [0000006c] *pgd=000000010add3003, *pud=000000010add3003, *pmd=0000000000000000 [ 376.388955] c1 11731 Internal error: Oops: 96000006 [#1] PREEMPT SMP [ 376.388987] c1 11731 CPU: 1 PID: 11731 Comm: 0 Tainted: G B W 3.18.31-g3021f2f-00001-gea07e56-dirty #35 [ 376.389005] c1 11731 Hardware name: HTC Corporation. MSM8996pro v1.1 + PMI8996 Marlin A (DT) [ 376.389024] c1 11731 task: ffffffc09f582880 ti: ffffffc089ea4000 task.ti: ffffffc089ea4000 [ 376.389062] c1 11731 PC is at l2tp_session_create+0x39c/0x5b8 [ 376.389081] c1 11731 LR is at l2tp_session_create+0x394/0x5b8 [ 376.389097] c1 11731 pc : [<ffffffc00127bbd4>] lr : [<ffffffc00127bbcc>] pstate: 20000145 [ 376.389112] c1 11731 sp : ffffffc089ea7ca0 [ 376.389127] x29: ffffffc089ea7ca0 x28: ffffffc03982fbf8 [ 376.389154] x27: 0000000000000000 x26: ffffffc03982fca0 [ 376.389180] x25: ffffffc099190ea8 x24: ffffffc03982fca8 [ 376.389205] x23: ffffffc03982fbf0 x22: 0000000000000000 [ 376.389230] x21: ffffffc03982fc98 x20: ffffffc099190e00 [ 376.389254] x19: ffffffc03982fb80 x18: ffffffc001bd00e0 [ 376.389277] x17: 0000000033293c44 x16: 000000006e1d9948 [ 376.389301] x15: 0000000000000000 x14: 000000000000000a [ 376.389324] x13: ffffffc0b982fc03 x12: 0000000000000000 [ 376.389347] x11: 0000000000000000 x10: ffffffc03982fc0d [ 376.389370] x9 : 00000000fffffffb x8 : ffffff8807305fb0 [ 376.389393] x7 : fcfcfcfcfcfcfcfc x6 : ffffffc03982fba4 [ 376.389415] x5 : 000000000000ffff x4 : ffffffc0019480db [ 376.389438] x3 : 1ffffff8132321e9 x2 : dfffff9000000000 [ 376.389461] x1 : 0000000000000000 x0 : 000000000000006c [ 376.389486] c1 11731 [ 376.389486] c1 11731 PC: 0xffffffc00127bad4: [ 376.389504] bad4 7900627b 91004b00 97bd0420 7940271b 9100d260 97bd043a 79006a7b 91004300 [ 376.389574] baf4 97bd041a 7940231b 9100ca60 97bd0434 7900667b 91007300 97bd044e b9401f1b [ 376.389641] bb14 91008260 97bd0469 b900227b 91005301 91006260 b9801f02 97bd05c4 9100a300 [ 376.389708] bb34 97bd0444 b9402b1b 9100b260 97bd045f b9002e7b 91008301 91009260 b9802b02 [ 376.389777] bb54 97bd05ba 97baedb0 9104a278 aa1903e0 97bd0438 b940aa80 7100081f 540009c1 [ 376.389843] bb74 97baeda9 aa1803e0 97bd048b 90ffffe0 91383000 f9009660 97baeda3 b940aa81 [ 376.389910] bb94 aa1303e0 97fffb38 91020262 885f7c40 11000400 88017c40 35ffffa1 9104a282 [ 376.389976] bbb4 885f7c40 11000400 88017c40 35ffffa1 91052280 97bd045b f940a680 9101b000 [ 376.390042] bbd4 885f7c01 11000421 88027c01 35ffffa2 9100629b aa1b03e0 94028720 52800020 [ 376.390107] bbf4 72b3c6e0 1b007ec0 b9006ba0 f94037a0 d35c7c16 910012c0 8b160e96 f90033a0 [ 376.390174] bc14 8b000e80 97bd0447 f94012d8 aa1703e0 97bd0461 f9003a78 b40000b8 97baed7a [ 376.390240] bc34 91002300 97bd045c f9000717 97baed76 f90012d7 aa1c03e0 97bd0457 f94033a0 [ 376.390306] bc54 8b000e80 f9003e60 aa1b03e0 94028827 aa1903e0 97bd03f7 b940aa80 7100081f [ 376.390372] bc74 54000920 97baed68 91048280 97bd042d f9409296 b50001d6 97baed63 e7f001f2 [ 376.390439] bc94 97baed61 aa1503e0 97bd0408 12bfe000 17ffff16 97baed5c aa1803e0 97bd043e [ 376.390508] bcb4 b0ffffe0 910f2000 17ffffb3 97baed56 d00065e0 b943a814 97ba0a9c 9134a2c0 [ 376.390576] c1 11731 [ 376.390576] c1 11731 LR: 0xffffffc00127bacc: [ 376.390594] bacc 9100c260 97bd0440 7900627b 91004b00 97bd0420 7940271b 9100d260 97bd043a [ 376.390662] baec 79006a7b 91004300 97bd041a 7940231b 9100ca60 97bd0434 7900667b 91007300 [ 376.390728] bb0c 97bd044e b9401f1b 91008260 97bd0469 b900227b 91005301 91006260 b9801f02 [ 376.390795] bb2c 97bd05c4 9100a300 97bd0444 b9402b1b 9100b260 97bd045f b9002e7b 91008301 [ 376.390862] bb4c 91009260 b9802b02 97bd05ba 97baedb0 9104a278 aa1903e0 97bd0438 b940aa80 [ 376.390929] bb6c 7100081f 540009c1 97baeda9 aa1803e0 97bd048b 90ffffe0 91383000 f9009660 [ 376.390995] bb8c 97baeda3 b940aa81 aa1303e0 97fffb38 91020262 885f7c40 11000400 88017c40 [ 376.391061] bbac 35ffffa1 9104a282 885f7c40 11000400 88017c40 35ffffa1 91052280 97bd045b [ 376.391128] bbcc f940a680 9101b000 885f7c01 11000421 88027c01 35ffffa2 9100629b aa1b03e0 [ 376.391195] bbec 94028720 52800020 72b3c6e0 1b007ec0 b9006ba0 f94037a0 d35c7c16 910012c0 [ 376.391262] bc0c 8b160e96 f90033a0 8b000e80 97bd0447 f94012d8 aa1703e0 97bd0461 f9003a78 [ 376.391328] bc2c b40000b8 97baed7a 91002300 97bd045c f9000717 97baed76 f90012d7 aa1c03e0 [ 376.391394] bc4c 97bd0457 f94033a0 8b000e80 f9003e60 aa1b03e0 94028827 aa1903e0 97bd03f7 [ 376.391461] bc6c b940aa80 7100081f 54000920 97baed68 91048280 97bd042d f9409296 b50001d6 [ 376.391528] bc8c 97baed63 e7f001f2 97baed61 aa1503e0 97bd0408 12bfe000 17ffff16 97baed5c [ 376.391594] bcac aa1803e0 97bd043e b0ffffe0 910f2000 17ffffb3 97baed56 d00065e0 b943a814 [ 376.391663] c1 11731 [ 376.391663] c1 11731 SP: 0xffffffc089ea7ba0: [ 376.391680] 7ba0 019480db ffffffc0 0000ffff 00000000 3982fba4 ffffffc0 fcfcfcfc fcfcfcfc [ 376.391747] 7bc0 07305fb0 ffffff88 fffffffb 00000000 3982fc0d ffffffc0 00000000 00000000 [ 376.391814] 7be0 00000000 00000000 b982fc03 ffffffc0 0000000a 00000000 00000000 00000000 [ 376.391880] 7c00 6e1d9948 00000000 33293c44 00000000 01bd00e0 ffffffc0 3982fb80 ffffffc0 [ 376.391947] 7c20 99190e00 ffffffc0 3982fc98 ffffffc0 00000000 00000000 3982fbf0 ffffffc0 [ 376.392013] 7c40 3982fca8 ffffffc0 99190ea8 ffffffc0 3982fca0 ffffffc0 00000000 00000000 [ 376.392078] 7c60 3982fbf8 ffffffc0 89ea7ca0 ffffffc0 0127bbcc ffffffc0 89ea7ca0 ffffffc0 [ 376.392144] 7c80 0127bbd4 ffffffc0 20000145 00000000 3982fc98 ffffffc0 00000000 00000000 [ 376.392212] 7ca0 89ea7d10 ffffffc0 0127dc2c ffffffc0 4261c200 ffffffc0 00000000 00000000 [ 376.392278] 7cc0 00000000 00000000 00000000 00000000 00000004 00000000 fffffff4 00000000 [ 376.392344] 7ce0 4261c230 ffffffc0 00000004 00000000 00000002 00000000 4261c212 ffffffc0 [ 376.392410] 7d00 89ea7d10 ffffffc0 00000000 ffffffc0 89ea7e00 ffffffc0 00ffd790 ffffffc0 [ 376.392478] 7d20 2aff8400 ffffffc0 00000026 00000000 3cf07980 ffffffc0 01bd0000 ffffffc0 [ 376.392544] 7d40 0127d9cc ffffffc0 00000015 00000000 00000119 00000000 000000cb 00000000 [ 376.392611] 7d60 01326000 ffffffc0 89ea4000 ffffffc0 01bd0000 ffffffc0 4261c448 ffffffc0 [ 376.392680] 7d80 00000003 00000000 99190e00 ffffffc0 ffffffff ffffffff 000cfb30 ffffffc0 [ 376.392747] c1 11731 [ 376.392765] c1 11731 Process 0 (pid: 11731, stack limit = 0xffffffc089ea4058) [ 376.392784] c1 11731 Context switch saved registers(0xffffffc09f582ec0 to 0xffffffc09f582f28) [ 376.392804] c1 11731 2ec0: a5f51b00 ffffffc0 9f582880 ffffffc0 89ea4000 ffffffc0 23966c00 ffffffc0 [ 376.392824] c1 11731 2ee0: 7345e780 ffffffc0 01c20000 ffffffc0 89ea7ac0 ffffffc0 019fe400 ffffffc0 [ 376.392842] c1 11731 2f00: 019fe400 ffffffc0 a5f51b00 ffffffc0 89ea7aa0 ffffffc0 89ea7aa0 ffffffc0 [ 376.392857] c1 11731 2f20: 00087574 ffffffc0 [ 376.392870] c1 11731 Call trace: [ 376.392904] c1 11731 [<ffffffc00127bbd4>] l2tp_session_create+0x39c/0x5b8 [ 376.392923] c1 11731 [<ffffffc00127dc2c>] pppol2tp_connect+0x260/0x698 [ 376.392952] c1 11731 [<ffffffc000ffd790>] SyS_connect+0xcc/0x144 [ 376.392971] c1 11731 Code: 91052280 97bd045b f940a680 9101b000 (885f7c01) [ 376.402888] c1 11731 ---[ end trace 7e40566c5e647ab7 ]--- [ 376.446227] c1 11731 Kernel panic - not syncing: Fatal exception

6 years, 9 months

2
1
0 0

patch "USB:fix USB3 devices behind USB3 hubs not resuming at hibernate thaw" added to usb-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB:fix USB3 devices behind USB3 hubs not resuming at hibernate thaw to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-testing 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 be merged to the usb-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. >From 64627388b50158fd24d6ad88132525b95a5ef573 Mon Sep 17 00:00:00 2001 From: Zhengjun Xing <zhengjun.xing(a)linux.intel.com> Date: Wed, 21 Mar 2018 13:29:42 +0800 Subject: USB:fix USB3 devices behind USB3 hubs not resuming at hibernate thaw MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit USB3 hubs don't support global suspend. USB3 specification 10.10, Enhanced SuperSpeed hubs only support selective suspend and resume, they do not support global suspend/resume where the hub downstream facing ports states are not affected. When system enters hibernation it first enters freeze process where only the root hub enters suspend, usb_port_suspend() is not called for other devices, and suspend status flags are not set for them. Other devices are expected to suspend globally. Some external USB3 hubs will suspend the downstream facing port at global suspend. These devices won't be resumed at thaw as the suspend status flag is not set. A USB3 removable hard disk connected through a USB3 hub that won't resume at thaw will fail to synchronize SCSI cache, return “cmd cmplt err -71” error, and needs a 60 seconds timeout which causing system hang for 60s before the USB host reset the port for the USB3 removable hard disk to recover. Fix this by always calling usb_port_suspend() during freeze for USB3 devices. Signed-off-by: Zhengjun Xing <zhengjun.xing(a)linux.intel.com> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/core/generic.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/usb/core/generic.c b/drivers/usb/core/generic.c index 83c14dda6300..bc8242bc4564 100644 --- a/drivers/usb/core/generic.c +++ b/drivers/usb/core/generic.c @@ -210,8 +210,13 @@ static int generic_suspend(struct usb_device *udev, pm_message_t msg) if (!udev->parent) rc = hcd_bus_suspend(udev, msg); - /* Non-root devices don't need to do anything for FREEZE or PRETHAW */ - else if (msg.event == PM_EVENT_FREEZE || msg.event == PM_EVENT_PRETHAW) + /* + * Non-root USB2 devices don't need to do anything for FREEZE + * or PRETHAW. USB3 devices don't support global suspend and + * needs to be selectively suspended. + */ + else if ((msg.event == PM_EVENT_FREEZE || msg.event == PM_EVENT_PRETHAW) + && (udev->speed < USB_SPEED_SUPER)) rc = 0; else rc = usb_port_suspend(udev, msg); -- 2.16.2

6 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2018