March 2020 - Linux-stable-mirror

[merged] mm-avoid-data-corruption-on-cow-fault-into-pfn-mapped-vma.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: avoid data corruption on CoW fault into PFN-mapped VMA has been removed from the -mm tree. Its filename was mm-avoid-data-corruption-on-cow-fault-into-pfn-mapped-vma.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: "Kirill A. Shutemov" <kirill(a)shutemov.name> Subject: mm: avoid data corruption on CoW fault into PFN-mapped VMA Jeff Moyer has reported that one of xfstests triggers a warning when run on DAX-enabled filesystem: WARNING: CPU: 76 PID: 51024 at mm/memory.c:2317 wp_page_copy+0xc40/0xd50 ... wp_page_copy+0x98c/0xd50 (unreliable) do_wp_page+0xd8/0xad0 __handle_mm_fault+0x748/0x1b90 handle_mm_fault+0x120/0x1f0 __do_page_fault+0x240/0xd70 do_page_fault+0x38/0xd0 handle_page_fault+0x10/0x30 The warning happens on failed __copy_from_user_inatomic() which tries to copy data into a CoW page. This happens because of race between MADV_DONTNEED and CoW page fault: CPU0 CPU1 handle_mm_fault() do_wp_page() wp_page_copy() do_wp_page() madvise(MADV_DONTNEED) zap_page_range() zap_pte_range() ptep_get_and_clear_full() <TLB flush> __copy_from_user_inatomic() sees empty PTE and fails WARN_ON_ONCE(1) clear_page() The solution is to re-try __copy_from_user_inatomic() under PTL after checking that PTE is matches the orig_pte. The second copy attempt can still fail, like due to non-readable PTE, but there's nothing reasonable we can do about, except clearing the CoW page. Link: http://lkml.kernel.org/r/20200218154151.13349-1-kirill.shutemov@linux.intel… Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Reported-by: Jeff Moyer <jmoyer(a)redhat.com> Tested-by: Jeff Moyer <jmoyer(a)redhat.com> Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: Justin He <Justin.He(a)arm.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memory.c | 35 +++++++++++++++++++++++++++-------- 1 file changed, 27 insertions(+), 8 deletions(-) --- a/mm/memory.c~mm-avoid-data-corruption-on-cow-fault-into-pfn-mapped-vma +++ a/mm/memory.c @@ -2257,7 +2257,7 @@ static inline bool cow_user_page(struct bool ret; void *kaddr; void __user *uaddr; - bool force_mkyoung; + bool locked = false; struct vm_area_struct *vma = vmf->vma; struct mm_struct *mm = vma->vm_mm; unsigned long addr = vmf->address; @@ -2282,11 +2282,11 @@ static inline bool cow_user_page(struct * On architectures with software "accessed" bits, we would * take a double page fault, so mark it accessed here. */ - force_mkyoung = arch_faults_on_old_pte() && !pte_young(vmf->orig_pte); - if (force_mkyoung) { + if (arch_faults_on_old_pte() && !pte_young(vmf->orig_pte)) { pte_t entry; vmf->pte = pte_offset_map_lock(mm, vmf->pmd, addr, &vmf->ptl); + locked = true; if (!likely(pte_same(*vmf->pte, vmf->orig_pte))) { /* * Other thread has already handled the fault @@ -2310,18 +2310,37 @@ static inline bool cow_user_page(struct * zeroes. */ if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE)) { + if (locked) + goto warn; + + /* Re-validate under PTL if the page is still mapped */ + vmf->pte = pte_offset_map_lock(mm, vmf->pmd, addr, &vmf->ptl); + locked = true; + if (!likely(pte_same(*vmf->pte, vmf->orig_pte))) { + /* The PTE changed under us. Retry page fault. */ + ret = false; + goto pte_unlock; + } + /* - * Give a warn in case there can be some obscure - * use-case + * The same page can be mapped back since last copy attampt. + * Try to copy again under PTL. */ - WARN_ON_ONCE(1); - clear_page(kaddr); + if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE)) { + /* + * Give a warn in case there can be some obscure + * use-case + */ +warn: + WARN_ON_ONCE(1); + clear_page(kaddr); + } } ret = true; pte_unlock: - if (force_mkyoung) + if (locked) pte_unmap_unlock(vmf->pte, vmf->ptl); kunmap_atomic(kaddr); flush_dcache_page(dst); _ Patches currently in -mm which might be from kirill(a)shutemov.name are mm-filemap-fix-a-data-race-in-filemap_fault.patch

4 years, 7 months

1
0
0 0

[merged] mm-fix-possible-pmd-dirty-bit-lost-in-set_pmd_migration_entry.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: fix possible PMD dirty bit lost in set_pmd_migration_entry() has been removed from the -mm tree. Its filename was mm-fix-possible-pmd-dirty-bit-lost-in-set_pmd_migration_entry.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Huang Ying <ying.huang(a)intel.com> Subject: mm: fix possible PMD dirty bit lost in set_pmd_migration_entry() In set_pmd_migration_entry(), pmdp_invalidate() is used to change PMD atomically. But the PMD is read before that with an ordinary memory reading. If the THP (transparent huge page) is written between the PMD reading and pmdp_invalidate(), the PMD dirty bit may be lost, and cause data corruption. The race window is quite small, but still possible in theory, so need to be fixed. The race is fixed via using the return value of pmdp_invalidate() to get the original content of PMD, which is a read/modify/write atomic operation. So no THP writing can occur in between. The race has been introduced when the THP migration support is added in the commit 616b8371539a ("mm: thp: enable thp migration in generic path"). But this fix depends on the commit d52605d7cb30 ("mm: do not lose dirty and accessed bits in pmdp_invalidate()"). So it's easy to be backported after v4.16. But the race window is really small, so it may be fine not to backport the fix at all. Link: http://lkml.kernel.org/r/20200220075220.2327056-1-ying.huang@intel.com Signed-off-by: "Huang, Ying" <ying.huang(a)intel.com> Reviewed-by: William Kucharski <william.kucharski(a)oracle.com> Acked-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Reviewed-by: Zi Yan <ziy(a)nvidia.com> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/huge_memory.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/mm/huge_memory.c~mm-fix-possible-pmd-dirty-bit-lost-in-set_pmd_migration_entry +++ a/mm/huge_memory.c @@ -3043,8 +3043,7 @@ void set_pmd_migration_entry(struct page return; flush_cache_range(vma, address, address + HPAGE_PMD_SIZE); - pmdval = *pvmw->pmd; - pmdp_invalidate(vma, address, pvmw->pmd); + pmdval = pmdp_invalidate(vma, address, pvmw->pmd); if (pmd_dirty(pmdval)) set_page_dirty(page); entry = make_migration_entry(page, pmd_write(pmdval)); _ Patches currently in -mm which might be from ying.huang(a)intel.com are

4 years, 7 months

1
0
0 0

[merged] mm-numa-fix-bad-pmd-by-atomically-check-for-pmd_trans_huge-when-marking-page-tables-prot_numa.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm, numa: fix bad pmd by atomically check for pmd_trans_huge when marking page tables prot_numa has been removed from the -mm tree. Its filename was mm-numa-fix-bad-pmd-by-atomically-check-for-pmd_trans_huge-when-marking-page-tables-prot_numa.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Mel Gorman <mgorman(a)techsingularity.net> Subject: mm, numa: fix bad pmd by atomically check for pmd_trans_huge when marking page tables prot_numa : A user reported a bug against a distribution kernel while running a : proprietary workload described as "memory intensive that is not swapping" : that is expected to apply to mainline kernels. The workload is : read/write/modifying ranges of memory and checking the contents. They : reported that within a few hours that a bad PMD would be reported followed : by a memory corruption where expected data was all zeros. A partial : report of the bad PMD looked like : : [ 5195.338482] ../mm/pgtable-generic.c:33: bad pmd ffff8888157ba008(000002e0396009e2) : [ 5195.341184] ------------[ cut here ]------------ : [ 5195.356880] kernel BUG at ../mm/pgtable-generic.c:35! : .... : [ 5195.410033] Call Trace: : [ 5195.410471] [<ffffffff811bc75d>] change_protection_range+0x7dd/0x930 : [ 5195.410716] [<ffffffff811d4be8>] change_prot_numa+0x18/0x30 : [ 5195.410918] [<ffffffff810adefe>] task_numa_work+0x1fe/0x310 : [ 5195.411200] [<ffffffff81098322>] task_work_run+0x72/0x90 : [ 5195.411246] [<ffffffff81077139>] exit_to_usermode_loop+0x91/0xc2 : [ 5195.411494] [<ffffffff81003a51>] prepare_exit_to_usermode+0x31/0x40 : [ 5195.411739] [<ffffffff815e56af>] retint_user+0x8/0x10 : : Decoding revealed that the PMD was a valid prot_numa PMD and the bad PMD : was a false detection. The bug does not trigger if automatic NUMA : balancing or transparent huge pages is disabled. : : The bug is due a race in change_pmd_range between a pmd_trans_huge and : pmd_nond_or_clear_bad check without any locks held. During the : pmd_trans_huge check, a parallel protection update under lock can have : cleared the PMD and filled it with a prot_numa entry between the transhuge : check and the pmd_none_or_clear_bad check. : : While this could be fixed with heavy locking, it's only necessary to make : a copy of the PMD on the stack during change_pmd_range and avoid races. A : new helper is created for this as the check if quite subtle and the : existing similar helpful is not suitable. This passed 154 hours of : testing (usually triggers between 20 minutes and 24 hours) without : detecting bad PMDs or corruption. A basic test of an autonuma-intensive : workload showed no significant change in behaviour. Although Mel withdrew the patch on the face of LKML comment https://lkml.org/lkml/2017/4/10/922 the race window aforementioned is still open, and we have reports of Linpack test reporting bad residuals after the bad PMD warning is observed. In addition to that, bad rss-counter and non-zero pgtables assertions are triggered on mm teardown for the task hitting the bad PMD. host kernel: mm/pgtable-generic.c:40: bad pmd 00000000b3152f68(8000000d2d2008e7) .... host kernel: BUG: Bad rss-counter state mm:00000000b583043d idx:1 val:512 host kernel: BUG: non-zero pgtables_bytes on freeing mm: 4096 The issue is observed on a v4.18-based distribution kernel, but the race window is expected to be applicable to mainline kernels, as well. [akpm(a)linux-foundation.org: fix comment typo, per Rafael] Link: http://lkml.kernel.org/r/20200216191800.22423-1-aquini@redhat.com Signed-off-by: Mel Gorman <mgorman(a)techsingularity.net> Signed-off-by: Rafael Aquini <aquini(a)redhat.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com> Cc: Zi Yan <zi.yan(a)cs.rutgers.edu> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/mprotect.c | 38 ++++++++++++++++++++++++++++++++++++-- 1 file changed, 36 insertions(+), 2 deletions(-) --- a/mm/mprotect.c~mm-numa-fix-bad-pmd-by-atomically-check-for-pmd_trans_huge-when-marking-page-tables-prot_numa +++ a/mm/mprotect.c @@ -161,6 +161,31 @@ static unsigned long change_pte_range(st return pages; } +/* + * Used when setting automatic NUMA hinting protection where it is + * critical that a numa hinting PMD is not confused with a bad PMD. + */ +static inline int pmd_none_or_clear_bad_unless_trans_huge(pmd_t *pmd) +{ + pmd_t pmdval = pmd_read_atomic(pmd); + + /* See pmd_none_or_trans_huge_or_clear_bad for info on barrier */ +#ifdef CONFIG_TRANSPARENT_HUGEPAGE + barrier(); +#endif + + if (pmd_none(pmdval)) + return 1; + if (pmd_trans_huge(pmdval)) + return 0; + if (unlikely(pmd_bad(pmdval))) { + pmd_clear_bad(pmd); + return 1; + } + + return 0; +} + static inline unsigned long change_pmd_range(struct vm_area_struct *vma, pud_t *pud, unsigned long addr, unsigned long end, pgprot_t newprot, int dirty_accountable, int prot_numa) @@ -178,8 +203,17 @@ static inline unsigned long change_pmd_r unsigned long this_pages; next = pmd_addr_end(addr, end); - if (!is_swap_pmd(*pmd) && !pmd_trans_huge(*pmd) && !pmd_devmap(*pmd) - && pmd_none_or_clear_bad(pmd)) + + /* + * Automatic NUMA balancing walks the tables with mmap_sem + * held for read. It's possible a parallel update to occur + * between pmd_trans_huge() and a pmd_none_or_clear_bad() + * check leading to a false positive and clearing. + * Hence, it's necessary to atomically read the PMD value + * for all the checks. + */ + if (!is_swap_pmd(*pmd) && !pmd_devmap(*pmd) && + pmd_none_or_clear_bad_unless_trans_huge(pmd)) goto next; /* invoke the mmu notifier if the pmd is populated */ _ Patches currently in -mm which might be from mgorman(a)techsingularity.net are

4 years, 7 months

1
0
0 0

❌ FAIL: Test report for kernel 5.5.8-c302816.cki (stable-queue)

by CKI Project

Hello, We ran automated tests on a recent commit from this kernel tree: Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Commit: c302816fcfff - block, bfq: do not insert oom queue into position tree The results of these automated tests are provided below. Overall result: FAILED (see details below) Merge: OK Compile: OK Tests: FAILED All kernel binaries, config files, and logs are available for download here: https://cki-artifacts.s3.us-east-2.amazonaws.com/index.html?prefix=dataware… One or more kernel tests failed: s390x: ❌ LTP ❌ stress: stress-ng We hope that these logs can help you find the problem quickly. For the full detail on our testing procedures, please scroll to the bottom of this message. Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Compile testing --------------- We compiled the kernel for 4 architectures: aarch64: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg ppc64le: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg s390x: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg x86_64: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg Hardware testing ---------------- We booted each kernel and ran the following tests: aarch64: Host 1: ✅ Boot test ✅ xfstests - ext4 ✅ xfstests - xfs ✅ selinux-policy: serge-testsuite ✅ lvm thinp sanity ✅ storage: software RAID testing 🚧 ✅ Storage blktests Host 2: ✅ Boot test ✅ Podman system integration test - as root ✅ Podman system integration test - as user ✅ LTP ✅ Loopdev Sanity ✅ Memory function: memfd_create ✅ AMTU (Abstract Machine Test Utility) ✅ Networking bridge: sanity ✅ Ethernet drivers sanity ✅ Networking MACsec: sanity ✅ Networking socket: fuzz ✅ Networking sctp-auth: sockopts test ✅ Networking: igmp conformance test ✅ Networking route: pmtu ✅ Networking route_func - local ✅ Networking route_func - forward ✅ Networking TCP: keepalive test ✅ Networking UDP: socket ✅ Networking tunnel: geneve basic test ✅ Networking tunnel: gre basic ✅ L2TP basic test ✅ Networking tunnel: vxlan basic ✅ Networking ipsec: basic netns - transport ✅ Networking ipsec: basic netns - tunnel ✅ audit: audit testsuite test ✅ httpd: mod_ssl smoke sanity ✅ tuned: tune-processes-through-perf ✅ ALSA PCM loopback test ✅ ALSA Control (mixer) Userspace Element test ✅ storage: SCSI VPD ✅ trace: ftrace/tracer 🚧 ✅ CIFS Connectathon 🚧 ✅ POSIX pjd-fstest suites 🚧 ✅ jvm - DaCapo Benchmark Suite 🚧 ✅ jvm - jcstress tests 🚧 ✅ Memory function: kaslr 🚧 ✅ LTP: openposix test suite 🚧 ✅ Networking vnic: ipvlan/basic 🚧 ✅ iotop: sanity 🚧 ✅ Usex - version 1.9-29 🚧 ✅ storage: dm/common ppc64le: Host 1: ✅ Boot test ✅ Podman system integration test - as root ✅ Podman system integration test - as user ✅ LTP ✅ Loopdev Sanity ✅ Memory function: memfd_create ✅ AMTU (Abstract Machine Test Utility) ✅ Networking bridge: sanity ✅ Ethernet drivers sanity ✅ Networking MACsec: sanity ✅ Networking socket: fuzz ✅ Networking sctp-auth: sockopts test ✅ Networking route: pmtu ✅ Networking route_func - local ✅ Networking route_func - forward ✅ Networking TCP: keepalive test ✅ Networking UDP: socket ✅ Networking tunnel: geneve basic test ✅ Networking tunnel: gre basic ✅ L2TP basic test ✅ Networking tunnel: vxlan basic ✅ Networking ipsec: basic netns - tunnel ✅ audit: audit testsuite test ✅ httpd: mod_ssl smoke sanity ✅ tuned: tune-processes-through-perf ✅ ALSA PCM loopback test ✅ ALSA Control (mixer) Userspace Element test ✅ trace: ftrace/tracer 🚧 ✅ CIFS Connectathon 🚧 ✅ POSIX pjd-fstest suites 🚧 ✅ jvm - DaCapo Benchmark Suite 🚧 ✅ jvm - jcstress tests 🚧 ✅ Memory function: kaslr 🚧 ✅ LTP: openposix test suite 🚧 ✅ Networking vnic: ipvlan/basic 🚧 ✅ iotop: sanity 🚧 ✅ Usex - version 1.9-29 🚧 ✅ storage: dm/common Host 2: ✅ Boot test ✅ xfstests - ext4 ✅ xfstests - xfs ✅ selinux-policy: serge-testsuite ✅ lvm thinp sanity ✅ storage: software RAID testing 🚧 ✅ IPMI driver test 🚧 ✅ IPMItool loop stress test 🚧 ✅ Storage blktests s390x: Host 1: ✅ Boot test ✅ Podman system integration test - as root ✅ Podman system integration test - as user ❌ LTP ⚡⚡⚡ Loopdev Sanity ⚡⚡⚡ Memory function: memfd_create ⚡⚡⚡ Networking bridge: sanity ⚡⚡⚡ Ethernet drivers sanity ⚡⚡⚡ Networking MACsec: sanity ⚡⚡⚡ Networking sctp-auth: sockopts test ⚡⚡⚡ Networking route: pmtu ⚡⚡⚡ Networking route_func - local ⚡⚡⚡ Networking route_func - forward ⚡⚡⚡ Networking TCP: keepalive test ⚡⚡⚡ Networking UDP: socket ⚡⚡⚡ Networking tunnel: geneve basic test ⚡⚡⚡ Networking tunnel: gre basic ⚡⚡⚡ L2TP basic test ⚡⚡⚡ Networking tunnel: vxlan basic ⚡⚡⚡ Networking ipsec: basic netns - transport ⚡⚡⚡ Networking ipsec: basic netns - tunnel ⚡⚡⚡ audit: audit testsuite test ⚡⚡⚡ httpd: mod_ssl smoke sanity ⚡⚡⚡ tuned: tune-processes-through-perf ⚡⚡⚡ trace: ftrace/tracer 🚧 ⚡⚡⚡ CIFS Connectathon 🚧 ⚡⚡⚡ POSIX pjd-fstest suites 🚧 ⚡⚡⚡ jvm - DaCapo Benchmark Suite 🚧 ⚡⚡⚡ jvm - jcstress tests 🚧 ⚡⚡⚡ Memory function: kaslr 🚧 ⚡⚡⚡ LTP: openposix test suite 🚧 ⚡⚡⚡ Networking vnic: ipvlan/basic 🚧 ⚡⚡⚡ iotop: sanity 🚧 ⚡⚡⚡ Usex - version 1.9-29 🚧 ⚡⚡⚡ storage: dm/common Host 2: ✅ Boot test ✅ selinux-policy: serge-testsuite ❌ stress: stress-ng 🚧 ⚡⚡⚡ Storage blktests x86_64: Host 1: ✅ Boot test ✅ Storage SAN device stress - megaraid_sas Host 2: ✅ Boot test ✅ xfstests - ext4 ✅ xfstests - xfs ✅ selinux-policy: serge-testsuite ✅ lvm thinp sanity ✅ storage: software RAID testing ✅ stress: stress-ng 🚧 ✅ IOMMU boot test 🚧 ✅ IPMI driver test 🚧 ✅ IPMItool loop stress test 🚧 ✅ Storage blktests Host 3: ✅ Boot test ✅ Storage SAN device stress - mpt3sas driver Host 4: ✅ Boot test ✅ Podman system integration test - as root ✅ Podman system integration test - as user ✅ LTP ✅ Loopdev Sanity ✅ Memory function: memfd_create ✅ AMTU (Abstract Machine Test Utility) ✅ Networking bridge: sanity ✅ Ethernet drivers sanity ✅ Networking MACsec: sanity ✅ Networking socket: fuzz ✅ Networking sctp-auth: sockopts test ✅ Networking: igmp conformance test ✅ Networking route: pmtu ✅ Networking route_func - local ✅ Networking route_func - forward ✅ Networking TCP: keepalive test ✅ Networking UDP: socket ✅ Networking tunnel: geneve basic test ✅ Networking tunnel: gre basic ✅ L2TP basic test ✅ Networking tunnel: vxlan basic ✅ Networking ipsec: basic netns - transport ✅ Networking ipsec: basic netns - tunnel ✅ audit: audit testsuite test ✅ httpd: mod_ssl smoke sanity ✅ tuned: tune-processes-through-perf ✅ pciutils: sanity smoke test ✅ ALSA PCM loopback test ✅ ALSA Control (mixer) Userspace Element test ✅ storage: SCSI VPD ✅ trace: ftrace/tracer 🚧 ✅ CIFS Connectathon 🚧 ✅ POSIX pjd-fstest suites 🚧 ✅ jvm - DaCapo Benchmark Suite 🚧 ✅ jvm - jcstress tests 🚧 ✅ Memory function: kaslr 🚧 ✅ LTP: openposix test suite 🚧 ✅ Networking vnic: ipvlan/basic 🚧 ✅ iotop: sanity 🚧 ✅ Usex - version 1.9-29 🚧 ✅ storage: dm/common Test sources: https://github.com/CKI-project/tests-beaker 💚 Pull requests are welcome for new tests or improvements to existing tests! Waived tests ------------ If the test run included waived tests, they are marked with 🚧. Such tests are executed but their results are not taken into account. Tests are waived when their results are not reliable enough, e.g. when they're just introduced or are being fixed. Testing timeout --------------- We aim to provide a report within reasonable timeframe. Tests that haven't finished running yet are marked with ⏱.

4 years, 7 months

2
1
0 0

[PATCH 2/6] ASoC: jz4740-i2s: Fix divider written at incorrect offset in register

by Paul Cercueil

The 4-bit divider value was written at offset 8, while the jz4740 programming manual locates it at offset 0. Fixes: 26b0aad80a86 ("ASoC: jz4740: Add dynamic sampling rate support to jz4740-i2s") Cc: stable(a)vger.kernel.org Signed-off-by: Paul Cercueil <paul(a)crapouillou.net> --- sound/soc/jz4740/jz4740-i2s.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/jz4740/jz4740-i2s.c b/sound/soc/jz4740/jz4740-i2s.c index 9d5405881209..434737b2b2b2 100644 --- a/sound/soc/jz4740/jz4740-i2s.c +++ b/sound/soc/jz4740/jz4740-i2s.c @@ -83,7 +83,7 @@ #define JZ_AIC_I2S_STATUS_BUSY BIT(2) #define JZ_AIC_CLK_DIV_MASK 0xf -#define I2SDIV_DV_SHIFT 8 +#define I2SDIV_DV_SHIFT 0 #define I2SDIV_DV_MASK (0xf << I2SDIV_DV_SHIFT) #define I2SDIV_IDV_SHIFT 8 #define I2SDIV_IDV_MASK (0xf << I2SDIV_IDV_SHIFT) -- 2.25.1

4 years, 7 months

1
0
0 0

[PATCH] pid: Fix error return value in some cases

by minyard＠acm.org

From: Corey Minyard <cminyard(a)mvista.com> Recent changes to alloc_pid() allow the pid number to be specified on the command line. If set_tid_size is set, then the code scanning the levels will hard-set retval to -EPERM, overriding it's previous -ENOMEM value. After the code scanning the levels, there are error returns that do not set retval, assuming it is still set to -ENOMEM. In the first place, pid_ns_prepare_proc() returns its own error, just use that. In the second place: if (!(ns->pid_allocated & PIDNS_ADDING)) goto out_unlock; a return value of -ENOMEM is probably wrong, since that means that the namespace is in deletion while this happened. -EINVAL is probably a better choice. Fixes: 49cb2fc42ce4 "fork: extend clone3() to support setting a PID" Signed-off-by: Corey Minyard <cminyard(a)mvista.com> Cc: <stable(a)vger.kernel.org> # 5.5 Cc: Adrian Reber <areber(a)redhat.com> Cc: Christian Brauner <christian.brauner(a)ubuntu.com> Cc: Oleg Nesterov <oleg(a)redhat.com> Cc: Dmitry Safonov <0x7f454c46(a)gmail.com> Cc: Andrei Vagin <avagin(a)gmail.com> Cc: Christian Brauner <christian.brauner(a)ubuntu.com> --- kernel/pid.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/kernel/pid.c b/kernel/pid.c index 0f4ecb57214c..1921f7f4b236 100644 --- a/kernel/pid.c +++ b/kernel/pid.c @@ -248,7 +248,8 @@ struct pid *alloc_pid(struct pid_namespace *ns, pid_t *set_tid, } if (unlikely(is_child_reaper(pid))) { - if (pid_ns_prepare_proc(ns)) + retval = pid_ns_prepare_proc(ns); + if (retval) goto out_free; } @@ -261,8 +262,10 @@ struct pid *alloc_pid(struct pid_namespace *ns, pid_t *set_tid, upid = pid->numbers + ns->level; spin_lock_irq(&pidmap_lock); - if (!(ns->pid_allocated & PIDNS_ADDING)) + if (!(ns->pid_allocated & PIDNS_ADDING)) { + retval = -EINVAL; goto out_unlock; + } for ( ; upid >= pid->numbers; --upid) { /* Make the PID visible to find_pid_ns. */ idr_replace(&upid->ns->idr, pid, upid->nr); -- 2.17.1

4 years, 7 months

2
1
0 0

[PATCH 1/2] xhci: Do not open code __print_symbolic() in xhci trace events

by Mathias Nyman

From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org> libtraceevent (used by perf and trace-cmd) failed to parse the xhci_urb_dequeue trace event. This is because the user space trace event format parsing is not a full C compiler. It can handle some basic logic, but is not meant to be able to handle everything C can do. In cases where a trace event field needs to be converted from a number to a string, there's the __print_symbolic() macro that should be used: See samples/trace_events/trace-events-sample.h Some xhci trace events open coded the __print_symbolic() causing the user spaces tools to fail to parse it. This has to be replaced with __print_symbolic() instead. CC: stable(a)vger.kernel.org Reported-by: Tzvetomir Stoyanov <tstoyanov(a)vmware.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=206531 Fixes: 5abdc2e6e12ff ("usb: host: xhci: add urb_enqueue/dequeue/giveback tracers") Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- drivers/usb/host/xhci-trace.h | 23 ++++++----------------- 1 file changed, 6 insertions(+), 17 deletions(-) diff --git a/drivers/usb/host/xhci-trace.h b/drivers/usb/host/xhci-trace.h index 56eb867803a6..b19582b2a72c 100644 --- a/drivers/usb/host/xhci-trace.h +++ b/drivers/usb/host/xhci-trace.h @@ -289,23 +289,12 @@ DECLARE_EVENT_CLASS(xhci_log_urb, ), TP_printk("ep%d%s-%s: urb %p pipe %u slot %d length %d/%d sgs %d/%d stream %d flags %08x", __entry->epnum, __entry->dir_in ? "in" : "out", - ({ char *s; - switch (__entry->type) { - case USB_ENDPOINT_XFER_INT: - s = "intr"; - break; - case USB_ENDPOINT_XFER_CONTROL: - s = "control"; - break; - case USB_ENDPOINT_XFER_BULK: - s = "bulk"; - break; - case USB_ENDPOINT_XFER_ISOC: - s = "isoc"; - break; - default: - s = "UNKNOWN"; - } s; }), __entry->urb, __entry->pipe, __entry->slot_id, + __print_symbolic(__entry->type, + { USB_ENDPOINT_XFER_INT, "intr" }, + { USB_ENDPOINT_XFER_CONTROL, "control" }, + { USB_ENDPOINT_XFER_BULK, "bulk" }, + { USB_ENDPOINT_XFER_ISOC, "isoc" }), + __entry->urb, __entry->pipe, __entry->slot_id, __entry->actual, __entry->length, __entry->num_mapped_sgs, __entry->num_sgs, __entry->stream, __entry->flags ) -- 2.17.1

4 years, 7 months

1
0
0 0

stable-rc/linux-4.19.y boot: 103 boots: 3 failed, 96 passed with 3 offline, 1 untried/unknown (v4.19.108)

by kernelci.org bot

stable-rc/linux-4.19.y boot: 103 boots: 3 failed, 96 passed with 3 offline, 1 untried/unknown (v4.19.108) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.108/ Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.108 Git Commit: 7472c4028e2357202949f99ad94c5a5a34f95666 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 74 unique boards, 23 SoC families, 18 builds out of 206 Boot Regressions Detected: arm: qcom_defconfig: gcc-8: qcom-apq8064-cm-qs600: lab-baylibre-seattle: failing since 26 days (last pass: v4.19.101 - first fail: v4.19.102-96-g0632821fe218) sunxi_defconfig: gcc-8: sun4i-a10-cubieboard: lab-baylibre-seattle: new failure (last pass: v4.19.107-88-g619f84afab6a) arm64: defconfig: gcc-8: meson-axg-s400: lab-baylibre-seattle: new failure (last pass: v4.19.107-88-g619f84afab6a) Boot Failures Detected: arm: multi_v7_defconfig: gcc-8: sun4i-a10-cubieboard: 1 failed lab sunxi_defconfig: gcc-8: sun4i-a10-cubieboard: 1 failed lab sama5_defconfig: gcc-8: at91-sama5d4_xplained: 1 failed lab Offline Platforms: arm: multi_v7_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab arm64: defconfig: gcc-8 meson-axg-s400: 1 offline lab --- For more info write to <info(a)kernelci.org>

4 years, 7 months

1
0
0 0

stable-rc/linux-4.9.y boot: 36 boots: 1 failed, 34 passed with 1 untried/unknown (v4.9.215)

by kernelci.org bot

stable-rc/linux-4.9.y boot: 36 boots: 1 failed, 34 passed with 1 untried/unknown (v4.9.215) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.215/ Tree: stable-rc Branch: linux-4.9.y Git Describe: v4.9.215 Git Commit: 4cd444443b6f3732fbe0552315cc5e5b35112a85 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 26 unique boards, 11 SoC families, 12 builds out of 197 Boot Regressions Detected: arm: bcm2835_defconfig: gcc-8: bcm2836-rpi-2-b: lab-collabora: new failure (last pass: v4.9.214-163-g176b68c72aeb) sunxi_defconfig: gcc-8: sun8i-h3-orangepi-pc: lab-clabbe: new failure (last pass: v4.9.214-163-g176b68c72aeb) Boot Failure Detected: arm: sama5_defconfig: gcc-8: at91-sama5d4_xplained: 1 failed lab --- For more info write to <info(a)kernelci.org>

4 years, 7 months

1
0
0 0

[PATCH 1/3] drm/i915/execlists: Enable timeslice on partial virtual engine dequeue

by Chris Wilson

If we stop filling the ELSP due to an incompatible virtual engine request, check if we should enable the timeslice on behalf of the queue. This fixes the case where we are inspecting the last->next element when we know that the last element is the last request in the execution queue, and so decided we did not need to enable timeslicing despite the intent to do so! Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing") Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala(a)linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Cc: <stable(a)vger.kernel.org> # v5.4+ --- drivers/gpu/drm/i915/gt/intel_lrc.c | 29 ++++++++++++++++++----------- 1 file changed, 18 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index 13941d1c0a4a..a1d268880cfe 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -1757,11 +1757,9 @@ need_timeslice(struct intel_engine_cs *engine, const struct i915_request *rq) if (!intel_engine_has_timeslices(engine)) return false; - if (list_is_last(&rq->sched.link, &engine->active.requests)) - return false; - - hint = max(rq_prio(list_next_entry(rq, sched.link)), - engine->execlists.queue_priority_hint); + hint = engine->execlists.queue_priority_hint; + if (!list_is_last(&rq->sched.link, &engine->active.requests)) + hint = max(hint, rq_prio(list_next_entry(rq, sched.link))); return hint >= effective_prio(rq); } @@ -1803,6 +1801,18 @@ static void set_timeslice(struct intel_engine_cs *engine) set_timer_ms(&engine->execlists.timer, active_timeslice(engine)); } +static void start_timeslice(struct intel_engine_cs *engine) +{ + struct intel_engine_execlists *execlists = &engine->execlists; + + execlists->switch_priority_hint = execlists->queue_priority_hint; + + if (timer_pending(&execlists->timer)) + return; + + set_timer_ms(&execlists->timer, timeslice(engine)); +} + static void record_preemption(struct intel_engine_execlists *execlists) { (void)I915_SELFTEST_ONLY(execlists->preempt_hang.count++); @@ -1966,11 +1976,7 @@ static void execlists_dequeue(struct intel_engine_cs *engine) * Even if ELSP[1] is occupied and not worthy * of timeslices, our queue might be. */ - if (!execlists->timer.expires && - need_timeslice(engine, last)) - set_timer_ms(&execlists->timer, - timeslice(engine)); - + start_timeslice(engine); return; } } @@ -2005,7 +2011,8 @@ static void execlists_dequeue(struct intel_engine_cs *engine) if (last && !can_merge_rq(last, rq)) { spin_unlock(&ve->base.active.lock); - return; /* leave this for another */ + start_timeslice(engine); + return; /* leave this for another sibling */ } ENGINE_TRACE(engine, -- 2.25.1

4 years, 7 months

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2020