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

Re: Patch "ALSA: pcm: Return 0 when size < start_threshold in capture" has been added to the 4.19-stable tree

by Ricardo Biehl Pasquali

On Wed, Sep 11, 2019 at 05:30:33AM -0400, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > ALSA: pcm: Return 0 when size < start_threshold in capture > > to the 4.19-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > alsa-pcm-return-0-when-size-start_threshold-in-captu.patch > and it can be found in the queue-4.19 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. Hi Sasha. This patch was reverted by the commit 932a81519572156a88db ("ALSA: pcm: Comment why read blocks when PCM is not running"): This avoids bringing back the problem introduced by 62ba568f7aef ("ALSA: pcm: Return 0 when size < start_threshold in capture") and fixed in 00a399cad1a0 ("ALSA: pcm: Revert capture stream behavior change in blocking mode"), which prevented the user from starting capture from another thread. Should this be queued anyway? If yes, I think it should also be queued the fix and the commit above. pasquali

5 years, 8 months

2
2
0 0

stable-rc/linux-4.9.y boot: 108 boots: 0 failed, 100 passed with 8 offline (v4.9.192-13-g16ee77790651)

by kernelci.org bot

stable-rc/linux-4.9.y boot: 108 boots: 0 failed, 100 passed with 8 offline (v4.9.192-13-g16ee77790651) 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.192-13-… Tree: stable-rc Branch: linux-4.9.y Git Describe: v4.9.192-13-g16ee77790651 Git Commit: 16ee777906517071e80ccaf459debe0f51ba75e7 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 55 unique boards, 22 SoC families, 14 builds out of 197 Offline Platforms: arm64: defconfig: gcc-8 apq8016-sbc: 1 offline lab arm: multi_v7_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab qcom-apq8064-ifc6410: 1 offline lab sun5i-r8-chip: 1 offline lab davinci_all_defconfig: gcc-8 dm365evm,legacy: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab qcom-apq8064-ifc6410: 1 offline lab sunxi_defconfig: gcc-8 sun5i-r8-chip: 1 offline lab --- For more info write to <info(a)kernelci.org>

5 years, 8 months

1
0
0 0

stable-rc/linux-4.14.y boot: 123 boots: 0 failed, 114 passed with 9 offline (v4.14.143-20-g570d97484537)

by kernelci.org bot

stable-rc/linux-4.14.y boot: 123 boots: 0 failed, 114 passed with 9 offline (v4.14.143-20-g570d97484537) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.143-2… Tree: stable-rc Branch: linux-4.14.y Git Describe: v4.14.143-20-g570d97484537 Git Commit: 570d97484537c5a83b2e252ad55e56f1749d8c6e Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 66 unique boards, 23 SoC families, 13 builds out of 201 Offline Platforms: arm64: defconfig: gcc-8 apq8016-sbc: 1 offline lab arm: multi_v7_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab qcom-apq8064-ifc6410: 1 offline lab sun5i-r8-chip: 1 offline lab davinci_all_defconfig: gcc-8 dm365evm,legacy: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab qcom-apq8064-ifc6410: 1 offline lab sunxi_defconfig: gcc-8 sun5i-r8-chip: 1 offline lab sun7i-a20-bananapi: 1 offline lab --- For more info write to <info(a)kernelci.org>

5 years, 8 months

1
0
0 0

stable-rc/linux-4.19.y boot: 129 boots: 0 failed, 121 passed with 8 offline (v4.19.72-193-g7ce5ae7d905a)

by kernelci.org bot

stable-rc/linux-4.19.y boot: 129 boots: 0 failed, 121 passed with 8 offline (v4.19.72-193-g7ce5ae7d905a) 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.72-19… Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.72-193-g7ce5ae7d905a Git Commit: 7ce5ae7d905a43fcd6d7f3207a7a11d3b4271f28 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 75 unique boards, 25 SoC families, 15 builds out of 206 Offline Platforms: arm64: defconfig: gcc-8 apq8016-sbc: 1 offline lab arm: multi_v7_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab qcom-apq8064-ifc6410: 1 offline lab sun5i-r8-chip: 1 offline lab davinci_all_defconfig: gcc-8 dm365evm,legacy: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab qcom-apq8064-ifc6410: 1 offline lab sunxi_defconfig: gcc-8 sun5i-r8-chip: 1 offline lab --- For more info write to <info(a)kernelci.org>

5 years, 8 months

1
0
0 0

stable-rc/linux-5.2.y boot: 140 boots: 1 failed, 130 passed with 9 offline (v5.2.14-36-gfda53119ddbd)

by kernelci.org bot

stable-rc/linux-5.2.y boot: 140 boots: 1 failed, 130 passed with 9 offline (v5.2.14-36-gfda53119ddbd) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.2.y/kernel/v5.2.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.2.y/kernel/v5.2.14-36-g… Tree: stable-rc Branch: linux-5.2.y Git Describe: v5.2.14-36-gfda53119ddbd Git Commit: fda53119ddbde247a9eef68ecc9de569ec7a7d6b Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 84 unique boards, 28 SoC families, 17 builds out of 209 Boot Failure Detected: arm64: defconfig: gcc-8: rk3399-firefly: 1 failed lab Offline Platforms: arm64: defconfig: gcc-8 apq8016-sbc: 1 offline lab arm: multi_v7_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab qcom-apq8064-ifc6410: 1 offline lab sun5i-r8-chip: 1 offline lab davinci_all_defconfig: gcc-8 dm365evm,legacy: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab qcom-apq8064-ifc6410: 1 offline lab sunxi_defconfig: gcc-8 sun5i-r8-chip: 1 offline lab sun7i-a20-bananapi: 1 offline lab --- For more info write to <info(a)kernelci.org>

5 years, 8 months

1
0
0 0

+ memcg-kmem-do-not-fail-__gfp_nofail-charges.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: memcg, kmem: do not fail __GFP_NOFAIL charges has been added to the -mm tree. Its filename is memcg-kmem-do-not-fail-__gfp_nofail-charges.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/memcg-kmem-do-not-fail-__gfp_nofai… and later at http://ozlabs.org/~akpm/mmotm/broken-out/memcg-kmem-do-not-fail-__gfp_nofai… 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: Michal Hocko <mhocko(a)suse.com> Subject: memcg, kmem: do not fail __GFP_NOFAIL charges Thomas has noticed the following NULL ptr dereference when using cgroup v1 kmem limit: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 3 PID: 16923 Comm: gtk-update-icon Not tainted 4.19.51 #42 Hardware name: Gigabyte Technology Co., Ltd. Z97X-Gaming G1/Z97X-Gaming G1, BIOS F9 07/31/2015 RIP: 0010:create_empty_buffers+0x24/0x100 Code: cd 0f 1f 44 00 00 0f 1f 44 00 00 41 54 49 89 d4 ba 01 00 00 00 55 53 48 89 fb e8 97 fe ff ff 48 89 c5 48 89 c2 eb 03 48 89 ca <48> 8b 4a 08 4c 09 22 48 85 c9 75 f1 48 89 6a 08 48 8b 43 18 48 8d RSP: 0018:ffff927ac1b37bf8 EFLAGS: 00010286 RAX: 0000000000000000 RBX: fffff2d4429fd740 RCX: 0000000100097149 RDX: 0000000000000000 RSI: 0000000000000082 RDI: ffff9075a99fbe00 RBP: 0000000000000000 R08: fffff2d440949cc8 R09: 00000000000960c0 R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000000 R13: ffff907601f18360 R14: 0000000000002000 R15: 0000000000001000 FS: 00007fb55b288bc0(0000) GS:ffff90761f8c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000007aebc002 CR4: 00000000001606e0 Call Trace: create_page_buffers+0x4d/0x60 __block_write_begin_int+0x8e/0x5a0 ? ext4_inode_attach_jinode.part.82+0xb0/0xb0 ? jbd2__journal_start+0xd7/0x1f0 ext4_da_write_begin+0x112/0x3d0 generic_perform_write+0xf1/0x1b0 ? file_update_time+0x70/0x140 __generic_file_write_iter+0x141/0x1a0 ext4_file_write_iter+0xef/0x3b0 __vfs_write+0x17e/0x1e0 vfs_write+0xa5/0x1a0 ksys_write+0x57/0xd0 do_syscall_64+0x55/0x160 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Tetsuo then noticed that this is because the __memcg_kmem_charge_memcg fails __GFP_NOFAIL charge when the kmem limit is reached. This is a wrong behavior because nofail allocations are not allowed to fail. Normal charge path simply forces the charge even if that means to cross the limit. Kmem accounting should be doing the same. Link: http://lkml.kernel.org/r/20190906125608.32129-1-mhocko@kernel.org Signed-off-by: Michal Hocko <mhocko(a)suse.com> Reported-by: Thomas Lindroth <thomas.lindroth(a)gmail.com> Debugged-by: Tetsuo Handa <penguin-kernel(a)i-love.sakura.ne.jp> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Vladimir Davydov <vdavydov.dev(a)gmail.com> Cc: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Cc: Thomas Lindroth <thomas.lindroth(a)gmail.com> Cc: Shakeel Butt <shakeelb(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memcontrol.c | 10 ++++++++++ 1 file changed, 10 insertions(+) --- a/mm/memcontrol.c~memcg-kmem-do-not-fail-__gfp_nofail-charges +++ a/mm/memcontrol.c @@ -2821,6 +2821,16 @@ int __memcg_kmem_charge_memcg(struct pag if (!cgroup_subsys_on_dfl(memory_cgrp_subsys) && !page_counter_try_charge(&memcg->kmem, nr_pages, &counter)) { + + /* + * Enforce __GFP_NOFAIL allocation because callers are not + * prepared to see failures and likely do not have any failure + * handling code. + */ + if (gfp & __GFP_NOFAIL) { + page_counter_charge(&memcg->kmem, nr_pages); + return 0; + } cancel_charge(memcg, nr_pages); return -ENOMEM; } _ Patches currently in -mm which might be from mhocko(a)suse.com are memcg-kmem-do-not-fail-__gfp_nofail-charges.patch mm-oom-consider-present-pages-for-the-node-size.patch

5 years, 8 months

1
0
0 0

stable-rc/linux-4.4.y boot: 95 boots: 1 failed, 86 passed with 8 offline (v4.4.192-7-g1976d5fc6a71)

by kernelci.org bot

stable-rc/linux-4.4.y boot: 95 boots: 1 failed, 86 passed with 8 offline (v4.4.192-7-g1976d5fc6a71) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.192-7-g… Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.192-7-g1976d5fc6a71 Git Commit: 1976d5fc6a71831ea31130965b571294ead2795e Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 46 unique boards, 18 SoC families, 13 builds out of 190 Boot Failure Detected: arm64: defconfig: gcc-8: qcom-qdf2400: 1 failed lab Offline Platforms: arm64: defconfig: gcc-8 apq8016-sbc: 1 offline lab arm: multi_v7_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab qcom-apq8064-ifc6410: 1 offline lab sun5i-r8-chip: 1 offline lab davinci_all_defconfig: gcc-8 dm365evm,legacy: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab qcom-apq8064-ifc6410: 1 offline lab sunxi_defconfig: gcc-8 sun5i-r8-chip: 1 offline lab --- For more info write to <info(a)kernelci.org>

5 years, 8 months

1
0
0 0

+ z3fold-fix-retry-mechanism-in-page-reclaim.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: z3fold: fix retry mechanism in page reclaim has been added to the -mm tree. Its filename is z3fold-fix-retry-mechanism-in-page-reclaim.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/z3fold-fix-retry-mechanism-in-page… and later at http://ozlabs.org/~akpm/mmotm/broken-out/z3fold-fix-retry-mechanism-in-page… 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: Vitaly Wool <vitalywool(a)gmail.com> Subject: z3fold: fix retry mechanism in page reclaim z3fold_page_reclaim()'s retry mechanism is broken: on a second iteration it will have zhdr from the first one so that zhdr is no longer in line with struct page. That leads to crashes when the system is stressed. Fix that by moving zhdr assignment up. While at it, protect against using already freed handles by using own local slots structure in z3fold_page_reclaim(). Link: http://lkml.kernel.org/r/20190908162919.830388dc7404d1e2c80f4095@gmail.com Signed-off-by: Vitaly Wool <vitalywool(a)gmail.com> Reported-by: Markus Linnala <markus.linnala(a)gmail.com> Reported-by: Chris Murphy <bugzilla(a)colorremedies.com> Reported-by: Agustin Dall'Alba <agustin(a)dallalba.com.ar> Cc: "Maciej S. Szmigiero" <mail(a)maciej.szmigiero.name> Cc: Shakeel Butt <shakeelb(a)google.com> Cc: Henry Burns <henrywolfeburns(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/z3fold.c | 49 ++++++++++++++++++++++++++++++++++--------------- 1 file changed, 34 insertions(+), 15 deletions(-) --- a/mm/z3fold.c~z3fold-fix-retry-mechanism-in-page-reclaim +++ a/mm/z3fold.c @@ -366,9 +366,10 @@ static inline int __idx(struct z3fold_he * Encodes the handle of a particular buddy within a z3fold page * Pool lock should be held as this function accesses first_num */ -static unsigned long encode_handle(struct z3fold_header *zhdr, enum buddy bud) +static unsigned long __encode_handle(struct z3fold_header *zhdr, + struct z3fold_buddy_slots *slots, + enum buddy bud) { - struct z3fold_buddy_slots *slots; unsigned long h = (unsigned long)zhdr; int idx = 0; @@ -385,11 +386,15 @@ static unsigned long encode_handle(struc if (bud == LAST) h |= (zhdr->last_chunks << BUDDY_SHIFT); - slots = zhdr->slots; slots->slot[idx] = h; return (unsigned long)&slots->slot[idx]; } +static unsigned long encode_handle(struct z3fold_header *zhdr, enum buddy bud) +{ + return __encode_handle(zhdr, zhdr->slots, bud); +} + /* Returns the z3fold page where a given handle is stored */ static inline struct z3fold_header *handle_to_z3fold_header(unsigned long h) { @@ -624,6 +629,7 @@ static void do_compact_page(struct z3fol } if (unlikely(PageIsolated(page) || + test_bit(PAGE_CLAIMED, &page->private) || test_bit(PAGE_STALE, &page->private))) { z3fold_page_unlock(zhdr); return; @@ -1100,6 +1106,7 @@ static int z3fold_reclaim_page(struct z3 struct z3fold_header *zhdr = NULL; struct page *page = NULL; struct list_head *pos; + struct z3fold_buddy_slots slots; unsigned long first_handle = 0, middle_handle = 0, last_handle = 0; spin_lock(&pool->lock); @@ -1118,16 +1125,22 @@ static int z3fold_reclaim_page(struct z3 /* this bit could have been set by free, in which case * we pass over to the next page in the pool. */ - if (test_and_set_bit(PAGE_CLAIMED, &page->private)) + if (test_and_set_bit(PAGE_CLAIMED, &page->private)) { + page = NULL; continue; + } - if (unlikely(PageIsolated(page))) + if (unlikely(PageIsolated(page))) { + clear_bit(PAGE_CLAIMED, &page->private); + page = NULL; continue; + } + zhdr = page_address(page); if (test_bit(PAGE_HEADLESS, &page->private)) break; - zhdr = page_address(page); if (!z3fold_page_trylock(zhdr)) { + clear_bit(PAGE_CLAIMED, &page->private); zhdr = NULL; continue; /* can't evict at this point */ } @@ -1145,26 +1158,30 @@ static int z3fold_reclaim_page(struct z3 if (!test_bit(PAGE_HEADLESS, &page->private)) { /* - * We need encode the handles before unlocking, since - * we can race with free that will set - * (first|last)_chunks to 0 + * We need encode the handles before unlocking, and + * use our local slots structure because z3fold_free + * can zero out zhdr->slots and we can't do much + * about that */ first_handle = 0; last_handle = 0; middle_handle = 0; if (zhdr->first_chunks) - first_handle = encode_handle(zhdr, FIRST); + first_handle = __encode_handle(zhdr, &slots, + FIRST); if (zhdr->middle_chunks) - middle_handle = encode_handle(zhdr, MIDDLE); + middle_handle = __encode_handle(zhdr, &slots, + MIDDLE); if (zhdr->last_chunks) - last_handle = encode_handle(zhdr, LAST); + last_handle = __encode_handle(zhdr, &slots, + LAST); /* * it's safe to unlock here because we hold a * reference to this page */ z3fold_page_unlock(zhdr); } else { - first_handle = encode_handle(zhdr, HEADLESS); + first_handle = __encode_handle(zhdr, &slots, HEADLESS); last_handle = middle_handle = 0; } @@ -1194,9 +1211,9 @@ next: spin_lock(&pool->lock); list_add(&page->lru, &pool->lru); spin_unlock(&pool->lock); + clear_bit(PAGE_CLAIMED, &page->private); } else { z3fold_page_lock(zhdr); - clear_bit(PAGE_CLAIMED, &page->private); if (kref_put(&zhdr->refcount, release_z3fold_page_locked)) { atomic64_dec(&pool->pages_nr); @@ -1211,6 +1228,7 @@ next: list_add(&page->lru, &pool->lru); spin_unlock(&pool->lock); z3fold_page_unlock(zhdr); + clear_bit(PAGE_CLAIMED, &page->private); } /* We started off locked to we need to lock the pool back */ @@ -1315,7 +1333,8 @@ static bool z3fold_page_isolate(struct p VM_BUG_ON_PAGE(!PageMovable(page), page); VM_BUG_ON_PAGE(PageIsolated(page), page); - if (test_bit(PAGE_HEADLESS, &page->private)) + if (test_bit(PAGE_HEADLESS, &page->private) || + test_bit(PAGE_CLAIMED, &page->private)) return false; zhdr = page_address(page); _ Patches currently in -mm which might be from vitalywool(a)gmail.com are revert-mm-z3foldc-fix-race-between-migration-and-destruction.patch z3fold-fix-retry-mechanism-in-page-reclaim.patch

5 years, 8 months

1
0
0 0

✅ PASS: Stable queue: queue-5.2

by CKI Project

Hello, We ran automated tests on a patchset that was proposed for merging into this kernel tree. The patches were applied to: Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Commit: 997fee5473ce - Linux 5.2.14 The results of these automated tests are provided below. Overall result: PASSED Merge: OK Compile: OK Tests: OK All kernel binaries, config files, and logs are available for download here: https://artifacts.cki-project.org/pipelines/157953 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 `-' ______________________________________________________________________________ Merge testing ------------- We cloned this repository and checked out the following commit: Repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Commit: 997fee5473ce - Linux 5.2.14 We grabbed the ddfea0b99563 commit of the stable queue repository. We then merged the patchset with `git am`: gpio-pca953x-correct-type-of-reg_direction.patch gpio-pca953x-use-pca953x_read_regs-instead-of-regmap_bulk_read.patch alsa-hda-fix-potential-endless-loop-at-applying-quirks.patch alsa-hda-realtek-fix-overridden-device-specific-initialization.patch alsa-hda-realtek-add-quirk-for-hp-pavilion-15.patch alsa-hda-realtek-enable-internal-speaker-headset-mic-of-asus-ux431fl.patch alsa-hda-realtek-fix-the-problem-of-two-front-mics-on-a-thinkcentre.patch sched-fair-don-t-assign-runtime-for-throttled-cfs_rq.patch drm-vmwgfx-fix-double-free-in-vmw_recv_msg.patch drm-nouveau-sec2-gp102-add-missing-module_firmwares.patch vhost-test-fix-build-for-vhost-test.patch vhost-test-fix-build-for-vhost-test-again.patch powerpc-64e-drop-stale-call-to-smp_processor_id-which-hangs-smp-startup.patch powerpc-tm-fix-fp-vmx-unavailable-exceptions-inside-a-transaction.patch powerpc-tm-fix-restoring-fp-vmx-facility-incorrectly-on-interrupts.patch batman-adv-fix-uninit-value-in-batadv_netlink_get_ifindex.patch batman-adv-only-read-ogm-tvlv_len-after-buffer-len-check.patch bcache-only-clear-btree_node_dirty-bit-when-it-is-se.patch bcache-add-comments-for-mutex_lock-b-write_lock.patch bcache-fix-race-in-btree_flush_write.patch ib-rdmavt-add-new-completion-inline.patch ib-rdmavt-qib-hfi1-convert-to-new-completion-api.patch ib-hfi1-unreserve-a-flushed-opfn-request.patch drm-i915-disable-sampler_state-prefetching-on-all-ge.patch drm-i915-userptr-acquire-the-page-lock-around-set_pa.patch drm-i915-make-sure-cdclk-is-high-enough-for-dp-audio.patch mmc-sdhci-sprd-fix-the-incorrect-soft-reset-operatio.patch usb-chipidea-imx-add-imx7ulp-support.patch usb-chipidea-imx-fix-eprobe_defer-support-during-dri.patch virtio-s390-fix-race-on-airq_areas.patch drm-i915-support-flags-in-whitlist-was.patch drm-i915-support-whitelist-workarounds-on-all-engine.patch drm-i915-whitelist-ps_-depth-invocation-_count.patch drm-i915-add-whitelist-workarounds-for-icl.patch drm-i915-icl-whitelist-ps_-depth-invocation-_count.patch Compile testing --------------- We compiled the kernel for 3 architectures: aarch64: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg ppc64le: 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 [0] ✅ selinux-policy: serge-testsuite [1] ✅ storage: software RAID testing [2] Host 2: ✅ Boot test [0] ✅ Podman system integration test (as root) [3] ✅ Podman system integration test (as user) [3] ✅ jvm test suite [4] ✅ AMTU (Abstract Machine Test Utility) [5] ✅ LTP: openposix test suite [6] ✅ Networking socket: fuzz [7] ✅ audit: audit testsuite test [8] ✅ httpd: mod_ssl smoke sanity [9] ✅ iotop: sanity [10] ✅ tuned: tune-processes-through-perf [11] ✅ Usex - version 1.9-29 [12] ✅ stress: stress-ng [13] 🚧 ✅ LTP lite [14] 🚧 ✅ ALSA PCM loopback test [15] 🚧 ✅ ALSA Control (mixer) Userspace Element test [16] ppc64le: Host 1: ✅ Boot test [0] ✅ Podman system integration test (as root) [3] ✅ Podman system integration test (as user) [3] ✅ jvm test suite [4] ✅ AMTU (Abstract Machine Test Utility) [5] ✅ LTP: openposix test suite [6] ✅ Networking socket: fuzz [7] ✅ audit: audit testsuite test [8] ✅ httpd: mod_ssl smoke sanity [9] ✅ iotop: sanity [10] ✅ tuned: tune-processes-through-perf [11] ✅ Usex - version 1.9-29 [12] 🚧 ✅ LTP lite [14] 🚧 ✅ ALSA PCM loopback test [15] 🚧 ✅ ALSA Control (mixer) Userspace Element test [16] Host 2: ✅ Boot test [0] ✅ selinux-policy: serge-testsuite [1] ✅ storage: software RAID testing [2] x86_64: Host 1: ✅ Boot test [0] ✅ selinux-policy: serge-testsuite [1] ✅ storage: software RAID testing [2] Host 2: ⚡ Internal infrastructure issues prevented one or more tests (marked with ⚡⚡⚡) from running on this architecture. This is not the fault of the kernel that was tested. ✅ Boot test [0] ✅ Podman system integration test (as root) [3] ✅ Podman system integration test (as user) [3] ✅ jvm test suite [4] ✅ AMTU (Abstract Machine Test Utility) [5] ✅ LTP: openposix test suite [6] ✅ Networking socket: fuzz [7] ✅ audit: audit testsuite test [8] ✅ httpd: mod_ssl smoke sanity [9] ✅ iotop: sanity [10] ✅ tuned: tune-processes-through-perf [11] ✅ pciutils: sanity smoke test [17] ✅ Usex - version 1.9-29 [12] ✅ stress: stress-ng [13] 🚧 ⚡⚡⚡ LTP lite [14] 🚧 ⚡⚡⚡ ALSA PCM loopback test [15] 🚧 ✅ ALSA Control (mixer) Userspace Element test [16] Test source: 💚 Pull requests are welcome for new tests or improvements to existing tests! [0]: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… [1]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/packages/se… [2]: https://github.com/CKI-project/tests-beaker/archive/master.zip#storage/swra… [3]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/container/p… [4]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/jvm [5]: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu [6]: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… [7]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/networking/… [8]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/aud… [9]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/htt… [10]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/iot… [11]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/tun… [12]: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us… [13]: https://github.com/CKI-project/tests-beaker/archive/master.zip#stress/stres… [14]: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… [15]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/sound/aloop [16]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/sound/user-… [17]: https://github.com/CKI-project/tests-beaker/archive/master.zip#pciutils/san… 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.

5 years, 8 months

1
0
0 0

+ revert-mm-z3foldc-fix-race-between-migration-and-destruction.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: Revert "mm/z3fold.c: fix race between migration and destruction" has been added to the -mm tree. Its filename is revert-mm-z3foldc-fix-race-between-migration-and-destruction.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/revert-mm-z3foldc-fix-race-between… and later at http://ozlabs.org/~akpm/mmotm/broken-out/revert-mm-z3foldc-fix-race-between… 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: Vitaly Wool <vitalywool(a)gmail.com> Subject: Revert "mm/z3fold.c: fix race between migration and destruction" With the original commit applied, z3fold_zpool_destroy() may get blocked on wait_event() for indefinite time. Revert this commit for the time being to get rid of this problem since the issue the original commit addresses is less severe. Link: http://lkml.kernel.org/r/20190910123142.7a9c8d2de4d0acbc0977c602@gmail.com Fixes: d776aaa9895eb6eb77 ("mm/z3fold.c: fix race between migration and destruction") Reported-by: Agust�n Dall'Alba <agustin(a)dallalba.com.ar> Signed-off-by: Vitaly Wool <vitalywool(a)gmail.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Vitaly Wool <vitalywool(a)gmail.com> Cc: Shakeel Butt <shakeelb(a)google.com> Cc: Jonathan Adams <jwadams(a)google.com> Cc: Henry Burns <henrywolfeburns(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/z3fold.c | 90 -------------------------------------------------- 1 file changed, 90 deletions(-) --- a/mm/z3fold.c~revert-mm-z3foldc-fix-race-between-migration-and-destruction +++ a/mm/z3fold.c @@ -41,7 +41,6 @@ #include <linux/workqueue.h> #include <linux/slab.h> #include <linux/spinlock.h> -#include <linux/wait.h> #include <linux/zpool.h> #include <linux/magic.h> @@ -146,8 +145,6 @@ struct z3fold_header { * @release_wq: workqueue for safe page release * @work: work_struct for safe page release * @inode: inode for z3fold pseudo filesystem - * @destroying: bool to stop migration once we start destruction - * @isolated: int to count the number of pages currently in isolation * * This structure is allocated at pool creation time and maintains metadata * pertaining to a particular z3fold pool. @@ -166,11 +163,8 @@ struct z3fold_pool { const struct zpool_ops *zpool_ops; struct workqueue_struct *compact_wq; struct workqueue_struct *release_wq; - struct wait_queue_head isolate_wait; struct work_struct work; struct inode *inode; - bool destroying; - int isolated; }; /* @@ -775,7 +769,6 @@ static struct z3fold_pool *z3fold_create goto out_c; spin_lock_init(&pool->lock); spin_lock_init(&pool->stale_lock); - init_waitqueue_head(&pool->isolate_wait); pool->unbuddied = __alloc_percpu(sizeof(struct list_head)*NCHUNKS, 2); if (!pool->unbuddied) goto out_pool; @@ -815,15 +808,6 @@ out: return NULL; } -static bool pool_isolated_are_drained(struct z3fold_pool *pool) -{ - bool ret; - - spin_lock(&pool->lock); - ret = pool->isolated == 0; - spin_unlock(&pool->lock); - return ret; -} /** * z3fold_destroy_pool() - destroys an existing z3fold pool * @pool: the z3fold pool to be destroyed @@ -833,22 +817,6 @@ static bool pool_isolated_are_drained(st static void z3fold_destroy_pool(struct z3fold_pool *pool) { kmem_cache_destroy(pool->c_handle); - /* - * We set pool-> destroying under lock to ensure that - * z3fold_page_isolate() sees any changes to destroying. This way we - * avoid the need for any memory barriers. - */ - - spin_lock(&pool->lock); - pool->destroying = true; - spin_unlock(&pool->lock); - - /* - * We need to ensure that no pages are being migrated while we destroy - * these workqueues, as migration can queue work on either of the - * workqueues. - */ - wait_event(pool->isolate_wait, !pool_isolated_are_drained(pool)); /* * We need to destroy pool->compact_wq before pool->release_wq, @@ -1339,28 +1307,6 @@ static u64 z3fold_get_pool_size(struct z return atomic64_read(&pool->pages_nr); } -/* - * z3fold_dec_isolated() expects to be called while pool->lock is held. - */ -static void z3fold_dec_isolated(struct z3fold_pool *pool) -{ - assert_spin_locked(&pool->lock); - VM_BUG_ON(pool->isolated <= 0); - pool->isolated--; - - /* - * If we have no more isolated pages, we have to see if - * z3fold_destroy_pool() is waiting for a signal. - */ - if (pool->isolated == 0 && waitqueue_active(&pool->isolate_wait)) - wake_up_all(&pool->isolate_wait); -} - -static void z3fold_inc_isolated(struct z3fold_pool *pool) -{ - pool->isolated++; -} - static bool z3fold_page_isolate(struct page *page, isolate_mode_t mode) { struct z3fold_header *zhdr; @@ -1387,34 +1333,6 @@ static bool z3fold_page_isolate(struct p spin_lock(&pool->lock); if (!list_empty(&page->lru)) list_del(&page->lru); - /* - * We need to check for destruction while holding pool->lock, as - * otherwise destruction could see 0 isolated pages, and - * proceed. - */ - if (unlikely(pool->destroying)) { - spin_unlock(&pool->lock); - /* - * If this page isn't stale, somebody else holds a - * reference to it. Let't drop our refcount so that they - * can call the release logic. - */ - if (unlikely(kref_put(&zhdr->refcount, - release_z3fold_page_locked))) { - /* - * If we get here we have kref problems, so we - * should freak out. - */ - WARN(1, "Z3fold is experiencing kref problems\n"); - z3fold_page_unlock(zhdr); - return false; - } - z3fold_page_unlock(zhdr); - return false; - } - - - z3fold_inc_isolated(pool); spin_unlock(&pool->lock); z3fold_page_unlock(zhdr); return true; @@ -1483,10 +1401,6 @@ static int z3fold_page_migrate(struct ad queue_work_on(new_zhdr->cpu, pool->compact_wq, &new_zhdr->work); - spin_lock(&pool->lock); - z3fold_dec_isolated(pool); - spin_unlock(&pool->lock); - page_mapcount_reset(page); put_page(page); return 0; @@ -1506,14 +1420,10 @@ static void z3fold_page_putback(struct p INIT_LIST_HEAD(&page->lru); if (kref_put(&zhdr->refcount, release_z3fold_page_locked)) { atomic64_dec(&pool->pages_nr); - spin_lock(&pool->lock); - z3fold_dec_isolated(pool); - spin_unlock(&pool->lock); return; } spin_lock(&pool->lock); list_add(&page->lru, &pool->lru); - z3fold_dec_isolated(pool); spin_unlock(&pool->lock); z3fold_page_unlock(zhdr); } _ Patches currently in -mm which might be from vitalywool(a)gmail.com are revert-mm-z3foldc-fix-race-between-migration-and-destruction.patch

5 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror