December 2024 - Linux-stable-mirror

FAILED: patch "[PATCH] zram: fix uninitialized ZRAM not releasing backing device" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x 74363ec674cb172d8856de25776c8f3103f05e2f # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024122336-lustfully-gurgle-a07f@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 74363ec674cb172d8856de25776c8f3103f05e2f Mon Sep 17 00:00:00 2001 From: Kairui Song <kasong(a)tencent.com> Date: Tue, 10 Dec 2024 00:57:16 +0800 Subject: [PATCH] zram: fix uninitialized ZRAM not releasing backing device Setting backing device is done before ZRAM initialization. If we set the backing device, then remove the ZRAM module without initializing the device, the backing device reference will be leaked and the device will be hold forever. Fix this by always reset the ZRAM fully on rmmod or reset store. Link: https://lkml.kernel.org/r/20241209165717.94215-3-ryncsn@gmail.com Fixes: 013bf95a83ec ("zram: add interface to specif backing device") Signed-off-by: Kairui Song <kasong(a)tencent.com> Reported-by: Desheng Wu <deshengwu(a)tencent.com> Suggested-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> Reviewed-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c index e86cc3d2f4d2..45df5eeabc5e 100644 --- a/drivers/block/zram/zram_drv.c +++ b/drivers/block/zram/zram_drv.c @@ -1444,12 +1444,16 @@ static void zram_meta_free(struct zram *zram, u64 disksize) size_t num_pages = disksize >> PAGE_SHIFT; size_t index; + if (!zram->table) + return; + /* Free all pages that are still in this zram device */ for (index = 0; index < num_pages; index++) zram_free_page(zram, index); zs_destroy_pool(zram->mem_pool); vfree(zram->table); + zram->table = NULL; } static bool zram_meta_alloc(struct zram *zram, u64 disksize) @@ -2326,11 +2330,6 @@ static void zram_reset_device(struct zram *zram) zram->limit_pages = 0; - if (!init_done(zram)) { - up_write(&zram->init_lock); - return; - } - set_capacity_and_notify(zram->disk, 0); part_stat_set_all(zram->disk->part0, 0);

6 months, 1 week

1
0
0 0

FAILED: patch "[PATCH] zram: fix uninitialized ZRAM not releasing backing device" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 74363ec674cb172d8856de25776c8f3103f05e2f # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024122336-italicize-cusp-3f6c@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 74363ec674cb172d8856de25776c8f3103f05e2f Mon Sep 17 00:00:00 2001 From: Kairui Song <kasong(a)tencent.com> Date: Tue, 10 Dec 2024 00:57:16 +0800 Subject: [PATCH] zram: fix uninitialized ZRAM not releasing backing device Setting backing device is done before ZRAM initialization. If we set the backing device, then remove the ZRAM module without initializing the device, the backing device reference will be leaked and the device will be hold forever. Fix this by always reset the ZRAM fully on rmmod or reset store. Link: https://lkml.kernel.org/r/20241209165717.94215-3-ryncsn@gmail.com Fixes: 013bf95a83ec ("zram: add interface to specif backing device") Signed-off-by: Kairui Song <kasong(a)tencent.com> Reported-by: Desheng Wu <deshengwu(a)tencent.com> Suggested-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> Reviewed-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c index e86cc3d2f4d2..45df5eeabc5e 100644 --- a/drivers/block/zram/zram_drv.c +++ b/drivers/block/zram/zram_drv.c @@ -1444,12 +1444,16 @@ static void zram_meta_free(struct zram *zram, u64 disksize) size_t num_pages = disksize >> PAGE_SHIFT; size_t index; + if (!zram->table) + return; + /* Free all pages that are still in this zram device */ for (index = 0; index < num_pages; index++) zram_free_page(zram, index); zs_destroy_pool(zram->mem_pool); vfree(zram->table); + zram->table = NULL; } static bool zram_meta_alloc(struct zram *zram, u64 disksize) @@ -2326,11 +2330,6 @@ static void zram_reset_device(struct zram *zram) zram->limit_pages = 0; - if (!init_done(zram)) { - up_write(&zram->init_lock); - return; - } - set_capacity_and_notify(zram->disk, 0); part_stat_set_all(zram->disk->part0, 0);

6 months, 1 week

1
0
0 0

FAILED: patch "[PATCH] zram: fix uninitialized ZRAM not releasing backing device" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 74363ec674cb172d8856de25776c8f3103f05e2f # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024122335-italicize-barge-aaae@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 74363ec674cb172d8856de25776c8f3103f05e2f Mon Sep 17 00:00:00 2001 From: Kairui Song <kasong(a)tencent.com> Date: Tue, 10 Dec 2024 00:57:16 +0800 Subject: [PATCH] zram: fix uninitialized ZRAM not releasing backing device Setting backing device is done before ZRAM initialization. If we set the backing device, then remove the ZRAM module without initializing the device, the backing device reference will be leaked and the device will be hold forever. Fix this by always reset the ZRAM fully on rmmod or reset store. Link: https://lkml.kernel.org/r/20241209165717.94215-3-ryncsn@gmail.com Fixes: 013bf95a83ec ("zram: add interface to specif backing device") Signed-off-by: Kairui Song <kasong(a)tencent.com> Reported-by: Desheng Wu <deshengwu(a)tencent.com> Suggested-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> Reviewed-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c index e86cc3d2f4d2..45df5eeabc5e 100644 --- a/drivers/block/zram/zram_drv.c +++ b/drivers/block/zram/zram_drv.c @@ -1444,12 +1444,16 @@ static void zram_meta_free(struct zram *zram, u64 disksize) size_t num_pages = disksize >> PAGE_SHIFT; size_t index; + if (!zram->table) + return; + /* Free all pages that are still in this zram device */ for (index = 0; index < num_pages; index++) zram_free_page(zram, index); zs_destroy_pool(zram->mem_pool); vfree(zram->table); + zram->table = NULL; } static bool zram_meta_alloc(struct zram *zram, u64 disksize) @@ -2326,11 +2330,6 @@ static void zram_reset_device(struct zram *zram) zram->limit_pages = 0; - if (!init_done(zram)) { - up_write(&zram->init_lock); - return; - } - set_capacity_and_notify(zram->disk, 0); part_stat_set_all(zram->disk->part0, 0);

6 months, 1 week

1
0
0 0

Re: [PATCH net] mptcp: fix TCP options overflow.

by Matthieu Baerts

Hi Paolo, On 21/12/2024 09:51, Paolo Abeni wrote: > Syzbot reported the following splat: (...) > Eric noted a probable shinfo->nr_frags corruption, which indeed > occurs. > > The root cause is a buggy MPTCP option len computation in some > circumstances: the ADD_ADDR option should be mutually exclusive > with DSS since the blamed commit. > > Still, mptcp_established_options_add_addr() tries to set the > relevant info in mptcp_out_options, if the remaining space is > large enough even when DSS is present. > > Since the ADD_ADDR infos and the DSS share the same union > fields, adding first corrupts the latter. In the worst-case > scenario, such corruption increases the DSS binary layout, > exceeding the computed length and possibly overwriting the > skb shared info. > > Address the issue by enforcing mutual exclusion in > mptcp_established_options_add_addr(), too. Thank you for the investigation and the fix, it looks good to me: Reviewed-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> > Reported-by: syzbot+38a095a81f30d82884c1(a)syzkaller.appspotmail.com If you don't mind, can you please add these two tags when applying the patches to help to track the backports? Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/538 Cc: stable(a)vger.kernel.org > Fixes: 1bff1e43a30e ("mptcp: optimize out option generation") > Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Cheers, Matt -- Sponsored by the NGI0 Core fund.

6 months, 1 week

2
1
0 0

[PATCH] mm: zswap: fix race between [de]compression and CPU hotunplug

by Yosry Ahmed

In zswap_compress() and zswap_decompress(), the per-CPU acomp_ctx of the current CPU at the beginning of the operation is retrieved and used throughout. However, since neither preemption nor migration are disabled, it is possible that the operation continues on a different CPU. If the original CPU is hotunplugged while the acomp_ctx is still in use, we run into a UAF bug as the resources attached to the acomp_ctx are freed during hotunplug in zswap_cpu_comp_dead(). The problem was introduced in commit 1ec3b5fe6eec ("mm/zswap: move to use crypto_acomp API for hardware acceleration") when the switch to the crypto_acomp API was made. Prior to that, the per-CPU crypto_comp was retrieved using get_cpu_ptr() which disables preemption and makes sure the CPU cannot go away from under us. Preemption cannot be disabled with the crypto_acomp API as a sleepable context is needed. Commit 8ba2f844f050 ("mm/zswap: change per-cpu mutex and buffer to per-acomp_ctx") increased the UAF surface area by making the per-CPU buffers dynamic, adding yet another resource that can be freed from under zswap compression/decompression by CPU hotunplug. There are a few ways to fix this: (a) Add a refcount for acomp_ctx. (b) Disable migration while using the per-CPU acomp_ctx. (c) Disable CPU hotunplug while using the per-CPU acomp_ctx by holding the CPUs read lock. Implement (c) since it's simpler than (a), and (b) involves using migrate_disable() which is apparently undesired (see huge comment in include/linux/preempt.h). Fixes: 1ec3b5fe6eec ("mm/zswap: move to use crypto_acomp API for hardware acceleration") Reported-by: Johannes Weiner <hannes(a)cmpxchg.org> Closes: https://lore.kernel.org/lkml/20241113213007.GB1564047@cmpxchg.org/ Reported-by: Sam Sun <samsun1006219(a)gmail.com> Closes: https://lore.kernel.org/lkml/CAEkJfYMtSdM5HceNsXUDf5haghD5+o2e7Qv4OcuruL4tP… Cc: <stable(a)vger.kernel.org> Signed-off-by: Yosry Ahmed <yosryahmed(a)google.com> --- mm/zswap.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/mm/zswap.c b/mm/zswap.c index f6316b66fb236..5a27af8d86ea9 100644 --- a/mm/zswap.c +++ b/mm/zswap.c @@ -880,6 +880,18 @@ static int zswap_cpu_comp_dead(unsigned int cpu, struct hlist_node *node) return 0; } +/* Prevent CPU hotplug from freeing up the per-CPU acomp_ctx resources */ +static struct crypto_acomp_ctx *acomp_ctx_get_cpu(struct crypto_acomp_ctx __percpu *acomp_ctx) +{ + cpus_read_lock(); + return raw_cpu_ptr(acomp_ctx); +} + +static void acomp_ctx_put_cpu(void) +{ + cpus_read_unlock(); +} + static bool zswap_compress(struct page *page, struct zswap_entry *entry, struct zswap_pool *pool) { @@ -893,8 +905,7 @@ static bool zswap_compress(struct page *page, struct zswap_entry *entry, gfp_t gfp; u8 *dst; - acomp_ctx = raw_cpu_ptr(pool->acomp_ctx); - + acomp_ctx = acomp_ctx_get_cpu(pool->acomp_ctx); mutex_lock(&acomp_ctx->mutex); dst = acomp_ctx->buffer; @@ -950,6 +961,7 @@ static bool zswap_compress(struct page *page, struct zswap_entry *entry, zswap_reject_alloc_fail++; mutex_unlock(&acomp_ctx->mutex); + acomp_ctx_put_cpu(); return comp_ret == 0 && alloc_ret == 0; } @@ -960,7 +972,7 @@ static void zswap_decompress(struct zswap_entry *entry, struct folio *folio) struct crypto_acomp_ctx *acomp_ctx; u8 *src; - acomp_ctx = raw_cpu_ptr(entry->pool->acomp_ctx); + acomp_ctx = acomp_ctx_get_cpu(entry->pool->acomp_ctx); mutex_lock(&acomp_ctx->mutex); src = zpool_map_handle(zpool, entry->handle, ZPOOL_MM_RO); @@ -990,6 +1002,7 @@ static void zswap_decompress(struct zswap_entry *entry, struct folio *folio) if (src != acomp_ctx->buffer) zpool_unmap_handle(zpool, entry->handle); + acomp_ctx_put_cpu(); } /********************************* -- 2.47.1.613.gc27f4b7a9f-goog

6 months, 1 week

4
3
0 0

[PATCH 2/2] mm/damon/core: fix ignored quota goals and filters of newly committed schemes

by SeongJae Park

damon_commit_schemes() ignores quota goals and filters of the newly committed schemes. This makes users confused about the behaviors. Correctly handle those inputs. Fixes: 9cb3d0b9dfce ("mm/damon/core: implement DAMON context commit function") Cc: <stable(a)vger.kernel.org> Signed-off-by: SeongJae Park <sj(a)kernel.org> --- mm/damon/core.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/mm/damon/core.c b/mm/damon/core.c index 931e8e4b1333..5192ee29f6cf 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -868,6 +868,11 @@ static int damon_commit_schemes(struct damon_ctx *dst, struct damon_ctx *src) NUMA_NO_NODE); if (!new_scheme) return -ENOMEM; + err = damos_commit(new_scheme, src_scheme); + if (err) { + damon_destroy_scheme(new_scheme); + return err; + } damon_add_scheme(dst, new_scheme); } return 0; -- 2.39.5

6 months, 1 week

1
0
0 0

[PATCH 1/2] mm/damon/core: fix new damon_target objects leaks on damon_commit_targets()

by SeongJae Park

When new DAMON targets are added via damon_commit_targets(), the newly created targets are not deallocated when updating the internal data (damon_commit_target()) is failed. Worse yet, even if the setup is successfully done, the new target is not linked to the context. Hence, the new targets are always leaked regardless of the internal data setup failure. Fix the leaks. Fixes: 9cb3d0b9dfce ("mm/damon/core: implement DAMON context commit function") Cc: <stable(a)vger.kernel.org> Signed-off-by: SeongJae Park <sj(a)kernel.org> --- mm/damon/core.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/mm/damon/core.c b/mm/damon/core.c index a71703e05300..931e8e4b1333 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -961,8 +961,11 @@ static int damon_commit_targets( return -ENOMEM; err = damon_commit_target(new_target, false, src_target, damon_target_has_pid(src)); - if (err) + if (err) { + damon_destroy_target(new_target); return err; + } + damon_add_target(dst, new_target); } return 0; } -- 2.39.5

6 months, 1 week

1
0
0 0

netfilter regression on aarch64 16k page size

by Amby ＠ Hyperbeam

Greetings, We are seeing a regression in 6.6.66 which I have narrowed down to this commit: stable: 86c27603514cb8ead29857365cdd145404ee9706 upstream: 7ffc7481153bbabf3332c6a19b289730c7e1edf5 Kernel version: 6.6.66 on aarch64 with 16k page size Last known good version: 6.6.65 Steps to repro: - run a 16k page size kernel (check with getconf PAGESIZE) - try to load an nftables config file on the problem Expected: - no errors Actual: - system enters a broken state, with the following trace in dmesg: [ 40.939230] Unable to handle kernel paging request at virtual address ffff00015ad7e4cc [ 40.939841] Mem abort info: [ 40.940079] ESR = 0x0000000096000021 [ 40.940389] EC = 0x25: DABT (current EL), IL = 32 bits [ 40.940820] SET = 0, FnV = 0 [ 40.941042] EA = 0, S1PTW = 0 [ 40.941289] FSC = 0x21: alignment fault [ 40.941570] Data abort info: [ 40.941805] ISV = 0, ISS = 0x00000021, ISS2 = 0x00000000 [ 40.942229] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 40.942857] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 40.943313] swapper pgtable: 16k pages, 48-bit VAs, pgdp=00000000474f0000 [ 40.943865] [ffff00015ad7e4cc] pgd=180000043f7e8003, p4d=180000043f7e8003, pud=180000043f7e4003, pmd=180000043f52c003, pte=006800019ad7cf07 [ 40.945664] Internal error: Oops: 0000000096000021 [#1] SMP [ 40.946055] Modules linked in: zstd zram zsmalloc nf_log_syslog nft_log nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables crct10dif_ce polyval_ce polyval_generic ghash_ce tcp_bbr sch_fq fuse nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock bpf_preload qemu_fw_cfg ip_tables squashfs virtio_net net_failover virtio_blk gpio_keys failover virtio_mmio virtio_scsi virtio_console virtio_balloon virtio_gpu virtio_dma_buf megaraid_sas [ 40.950262] CPU: 7 PID: 116 Comm: kworker/7:1 Not tainted 6.6.67-1-lts #1 [ 40.951542] Hardware name: netcup KVM Server, BIOS VPS 2000 ARM G11 08/07/2024 [ 40.952287] Workqueue: events_power_efficient nft_rhash_gc [nf_tables] [ 40.952798] pstate: 20401005 (nzCv daif +PAN -UAO -TCO -DIT +SSBS BTYPE=--) [ 40.953401] pc : nft_rhash_gc+0x208/0x2c0 [nf_tables] [ 40.954054] lr : nft_rhash_gc+0x134/0x2c0 [nf_tables] [ 40.954806] sp : ffff800081fb3cf0 [ 40.955138] x29: ffff800081fb3d50 x28: 0000000000000000 x27: 0000000000000000 [ 40.955974] x26: ffff0000cc760ef0 x25: ffff0000ccba9c80 x24: ffff0000cc758f78 [ 40.956750] x23: 0000000000000010 x22: ffff0000ca789000 x21: ffff0000cc760f78 [ 40.957455] x20: ffffd62d3ac3be40 x19: ffff00015ad7e4c0 x18: 0000000000000000 [ 40.959005] x17: 0000000000000000 x16: ffffd62d37926880 x15: 000000400002fef8 [ 40.959614] x14: ffffffffffffffff x13: 0000000000000030 x12: ffff0000cc760ef0 [ 40.960197] x11: 0000000000000000 x10: ffff800081fb3d08 x9 : ffff0000cba89fe0 [ 40.960739] x8 : 0000000000000003 x7 : 0000000000000000 x6 : 0000000000000000 [ 40.961287] x5 : 0000000000000040 x4 : ffff0000cba89ff0 x3 : ffff00015ad7e4c0 [ 40.961814] x2 : ffff00015ad7e4cc x1 : ffff00015ad7e4cc x0 : 0000000000000004 [ 40.962339] Call trace: [ 40.962531] nft_rhash_gc+0x208/0x2c0 [nf_tables] [ 40.962911] process_one_work+0x178/0x3e0 [ 40.963710] worker_thread+0x2ac/0x3e0 [ 40.964530] kthread+0xf0/0x108 [ 40.966259] ret_from_fork+0x10/0x20 [ 40.967287] Code: 54fff9a4 d503201f d2800080 91003261 (f820303f) [ 40.968245] ---[ end trace 0000000000000000 ]--- faddr2line gave me the following: nft_rhash_gc+0x208/0x2c0: __lse_atomic64_or at /root/gg/setup/linux-lts/src/linux-6.6.67/./arch/arm64/include/asm/atomic_lse.h:132 (inlined by) arch_atomic64_or at /root/gg/setup/linux-lts/src/linux-6.6.67/./arch/arm64/include/asm/atomic.h:65 (inlined by) raw_atomic64_or at /root/gg/setup/linux-lts/src/linux-6.6.67/./include/linux/atomic/atomic-arch-fallback.h:3771 (inlined by) raw_atomic_long_or at /root/gg/setup/linux-lts/src/linux-6.6.67/./include/linux/atomic/atomic-long.h:1069 (inlined by) arch_set_bit at /root/gg/setup/linux-lts/src/linux-6.6.67/./include/asm-generic/bitops/atomic.h:18 (inlined by) set_bit at /root/gg/setup/linux-lts/src/linux-6.6.67/./include/asm-generic/bitops/instrumented-atomic.h:29 (inlined by) nft_set_elem_dead at /root/gg/setup/linux-lts/src/linux-6.6.67/./include/net/netfilter/nf_tables.h:1576 (inlined by) nft_rhash_gc at /root/gg/setup/linux-lts/src/linux-6.6.67/net/netfilter/nft_set_hash.c:375 By looking at the diff between 6.6.65 and 6.6.66 I was able to narrow it down to the above commit and I can confirm that reverting it fixes the issue. Best -- Amby Balaji Co-founder & CTO Hyperbeam, Inc.

6 months, 1 week

2
5
0 0

[PATCH 1/2] fs/proc: do_task_stat: Fix ESP not readable during coredump

by Nam Cao

Commit 0a1eb2d474ed ("fs/proc: Stop reporting eip and esp in /proc/PID/stat") disabled stack pointer reading, because it is generally dangerous to do so. Commit fd7d56270b52 ("fs/proc: Report eip/esp in /prod/PID/stat for coredumping") made an exception for coredumping thread, because for this case it is safe. The exception was later extended to all threads in a coredumping process by commit cb8f381f1613 ("fs/proc/array.c: allow reporting eip/esp for all coredumping threads"). The above two commits determine if a task is core dumping by checking the PF_EXITING and PF_DUMPCORE flags. However, commit 92307383082d ("coredump: Don't perform any cleanups before dumping core") moved coredump to happen earlier and before PF_EXITING is set. Thus, the check of the PF_EXITING flag no longer works. Instead, use task->signal->core_state to determine if coredump is happening. This pointer is set at the beginning of coredump and is cleared once coredump is done. Thus, while this pointer is not NULL, it is safe to read ESP. Fixes: 92307383082d ("coredump: Don't perform any cleanups before dumping core") Signed-off-by: Nam Cao <namcao(a)linutronix.de> Cc: <stable(a)vger.kernel.org> Cc: Eric W. Biederman <ebiederm(a)xmission.com> --- fs/proc/array.c | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/fs/proc/array.c b/fs/proc/array.c index 34a47fb0c57f..2f1dbfcf143d 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -489,25 +489,8 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns, vsize = eip = esp = 0; permitted = ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS | PTRACE_MODE_NOAUDIT); mm = get_task_mm(task); - if (mm) { + if (mm) vsize = task_vsize(mm); - /* - * esp and eip are intentionally zeroed out. There is no - * non-racy way to read them without freezing the task. - * Programs that need reliable values can use ptrace(2). - * - * The only exception is if the task is core dumping because - * a program is not able to use ptrace(2) in that case. It is - * safe because the task has stopped executing permanently. - */ - if (permitted && (task->flags & (PF_EXITING|PF_DUMPCORE))) { - if (try_get_task_stack(task)) { - eip = KSTK_EIP(task); - esp = KSTK_ESP(task); - put_task_stack(task); - } - } - } sigemptyset(&sigign); sigemptyset(&sigcatch); @@ -534,6 +517,23 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns, ppid = task_tgid_nr_ns(task->real_parent, ns); pgid = task_pgrp_nr_ns(task, ns); + /* + * esp and eip are intentionally zeroed out. There is no + * non-racy way to read them without freezing the task. + * Programs that need reliable values can use ptrace(2). + * + * The only exception is if the task is core dumping because + * a program is not able to use ptrace(2) in that case. It is + * safe because the task has stopped executing permanently. + */ + if (permitted && task->signal->core_state) { + if (try_get_task_stack(task)) { + eip = KSTK_EIP(task); + esp = KSTK_ESP(task); + put_task_stack(task); + } + } + unlock_task_sighand(task, &flags); } -- 2.39.5

6 months, 1 week

4
6
0 0

[PATCH v2, 2/2] usb: typec: tcpm: fix the sender response time issue

by joswang

From: Jos Wang <joswang(a)lenovo.com> According to the USB PD3 CTS specification (https://usb.org/document-library/ usb-power-delivery-compliance-test-specification-0/ USB_PD3_CTS_Q4_2024_OR.zip), the requirements for tSenderResponse are different in PD2 and PD3 modes, see Table 19 Timing Table & Calculations. For PD2 mode, the tSenderResponse min 24ms and max 30ms; for PD3 mode, the tSenderResponse min 27ms and max 33ms. For the "TEST.PD.PROT.SRC.2 Get_Source_Cap No Request" test item, after receiving the Source_Capabilities Message sent by the UUT, the tester deliberately does not send a Request Message in order to force the SenderResponse timer on the Source UUT to timeout. The Tester checks that a Hard Reset is detected between tSenderResponse min and max，the delay is between the last bit of the GoodCRC Message EOP has been sent and the first bit of Hard Reset SOP has been received. The current code does not distinguish between PD2 and PD3 modes, and tSenderResponse defaults to 60ms. This will cause this test item and the following tests to fail: TEST.PD.PROT.SRC3.2 SenderResponseTimer Timeout TEST.PD.PROT.SNK.6 SenderResponseTimer Timeout Considering factors such as SOC performance, i2c rate, and the speed of PD chip sending data, "pd2-sender-response-time-ms" and "pd3-sender-response-time-ms" DT time properties are added to allow users to define platform timing. For values that have not been explicitly defined in DT using this property, a default value of 27ms for PD2 tSenderResponse and 30ms for PD3 tSenderResponse is set. Fixes: 2eadc33f40d4 ("typec: tcpm: Add core support for sink side PPS") Cc: stable(a)vger.kernel.org Signed-off-by: Jos Wang <joswang(a)lenovo.com> --- v1 -> v2: - modify the commit message - patch 1/2 and patch 2/2 are placed in the same thread drivers/usb/typec/tcpm/tcpm.c | 50 +++++++++++++++++++++++------------ include/linux/usb/pd.h | 3 ++- 2 files changed, 35 insertions(+), 18 deletions(-) diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index 6021eeb903fe..3a159bfcf382 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -314,12 +314,16 @@ struct pd_data { * @sink_wait_cap_time: Deadline (in ms) for tTypeCSinkWaitCap timer * @ps_src_wait_off_time: Deadline (in ms) for tPSSourceOff timer * @cc_debounce_time: Deadline (in ms) for tCCDebounce timer + * @pd2_sender_response_time: Deadline (in ms) for pd20 tSenderResponse timer + * @pd3_sender_response_time: Deadline (in ms) for pd30 tSenderResponse timer */ struct pd_timings { u32 sink_wait_cap_time; u32 ps_src_off_time; u32 cc_debounce_time; u32 snk_bc12_cmpletion_time; + u32 pd2_sender_response_time; + u32 pd3_sender_response_time; }; struct tcpm_port { @@ -3776,7 +3780,9 @@ static bool tcpm_send_queued_message(struct tcpm_port *port) } else if (port->pwr_role == TYPEC_SOURCE) { tcpm_ams_finish(port); tcpm_set_state(port, HARD_RESET_SEND, - PD_T_SENDER_RESPONSE); + port->negotiated_rev >= PD_REV30 ? + port->timings.pd3_sender_response_time : + port->timings.pd2_sender_response_time); } else { tcpm_ams_finish(port); } @@ -4619,6 +4625,9 @@ static void run_state_machine(struct tcpm_port *port) enum typec_pwr_opmode opmode; unsigned int msecs; enum tcpm_state upcoming_state; + u32 sender_response_time = port->negotiated_rev >= PD_REV30 ? + port->timings.pd3_sender_response_time : + port->timings.pd2_sender_response_time; if (port->tcpc->check_contaminant && port->state != CHECK_CONTAMINANT) port->potential_contaminant = ((port->enter_state == SRC_ATTACH_WAIT && @@ -5113,7 +5122,7 @@ static void run_state_machine(struct tcpm_port *port) tcpm_set_state(port, SNK_WAIT_CAPABILITIES, 0); } else { tcpm_set_state_cond(port, hard_reset_state(port), - PD_T_SENDER_RESPONSE); + sender_response_time); } break; case SNK_NEGOTIATE_PPS_CAPABILITIES: @@ -5135,7 +5144,7 @@ static void run_state_machine(struct tcpm_port *port) tcpm_set_state(port, SNK_READY, 0); } else { tcpm_set_state_cond(port, hard_reset_state(port), - PD_T_SENDER_RESPONSE); + sender_response_time); } break; case SNK_TRANSITION_SINK: @@ -5387,7 +5396,7 @@ static void run_state_machine(struct tcpm_port *port) port->message_id_prime = 0; port->rx_msgid_prime = -1; tcpm_pd_send_control(port, PD_CTRL_SOFT_RESET, TCPC_TX_SOP_PRIME); - tcpm_set_state_cond(port, ready_state(port), PD_T_SENDER_RESPONSE); + tcpm_set_state_cond(port, ready_state(port), sender_response_time); } else { port->message_id = 0; port->rx_msgid = -1; @@ -5398,7 +5407,7 @@ static void run_state_machine(struct tcpm_port *port) tcpm_set_state_cond(port, hard_reset_state(port), 0); else tcpm_set_state_cond(port, hard_reset_state(port), - PD_T_SENDER_RESPONSE); + sender_response_time); } break; @@ -5409,8 +5418,7 @@ static void run_state_machine(struct tcpm_port *port) port->send_discover = true; port->send_discover_prime = false; } - tcpm_set_state_cond(port, DR_SWAP_SEND_TIMEOUT, - PD_T_SENDER_RESPONSE); + tcpm_set_state_cond(port, DR_SWAP_SEND_TIMEOUT, sender_response_time); break; case DR_SWAP_ACCEPT: tcpm_pd_send_control(port, PD_CTRL_ACCEPT, TCPC_TX_SOP); @@ -5444,7 +5452,7 @@ static void run_state_machine(struct tcpm_port *port) tcpm_set_state(port, ERROR_RECOVERY, 0); break; } - tcpm_set_state_cond(port, FR_SWAP_SEND_TIMEOUT, PD_T_SENDER_RESPONSE); + tcpm_set_state_cond(port, FR_SWAP_SEND_TIMEOUT, sender_response_time); break; case FR_SWAP_SEND_TIMEOUT: tcpm_set_state(port, ERROR_RECOVERY, 0); @@ -5475,8 +5483,7 @@ static void run_state_machine(struct tcpm_port *port) break; case PR_SWAP_SEND: tcpm_pd_send_control(port, PD_CTRL_PR_SWAP, TCPC_TX_SOP); - tcpm_set_state_cond(port, PR_SWAP_SEND_TIMEOUT, - PD_T_SENDER_RESPONSE); + tcpm_set_state_cond(port, PR_SWAP_SEND_TIMEOUT, sender_response_time); break; case PR_SWAP_SEND_TIMEOUT: tcpm_swap_complete(port, -ETIMEDOUT); @@ -5574,8 +5581,7 @@ static void run_state_machine(struct tcpm_port *port) break; case VCONN_SWAP_SEND: tcpm_pd_send_control(port, PD_CTRL_VCONN_SWAP, TCPC_TX_SOP); - tcpm_set_state(port, VCONN_SWAP_SEND_TIMEOUT, - PD_T_SENDER_RESPONSE); + tcpm_set_state(port, VCONN_SWAP_SEND_TIMEOUT, sender_response_time); break; case VCONN_SWAP_SEND_TIMEOUT: tcpm_swap_complete(port, -ETIMEDOUT); @@ -5656,23 +5662,21 @@ static void run_state_machine(struct tcpm_port *port) break; case GET_STATUS_SEND: tcpm_pd_send_control(port, PD_CTRL_GET_STATUS, TCPC_TX_SOP); - tcpm_set_state(port, GET_STATUS_SEND_TIMEOUT, - PD_T_SENDER_RESPONSE); + tcpm_set_state(port, GET_STATUS_SEND_TIMEOUT, sender_response_time); break; case GET_STATUS_SEND_TIMEOUT: tcpm_set_state(port, ready_state(port), 0); break; case GET_PPS_STATUS_SEND: tcpm_pd_send_control(port, PD_CTRL_GET_PPS_STATUS, TCPC_TX_SOP); - tcpm_set_state(port, GET_PPS_STATUS_SEND_TIMEOUT, - PD_T_SENDER_RESPONSE); + tcpm_set_state(port, GET_PPS_STATUS_SEND_TIMEOUT, sender_response_time); break; case GET_PPS_STATUS_SEND_TIMEOUT: tcpm_set_state(port, ready_state(port), 0); break; case GET_SINK_CAP: tcpm_pd_send_control(port, PD_CTRL_GET_SINK_CAP, TCPC_TX_SOP); - tcpm_set_state(port, GET_SINK_CAP_TIMEOUT, PD_T_SENDER_RESPONSE); + tcpm_set_state(port, GET_SINK_CAP_TIMEOUT, sender_response_time); break; case GET_SINK_CAP_TIMEOUT: port->sink_cap_done = true; @@ -7109,6 +7113,18 @@ static void tcpm_fw_get_timings(struct tcpm_port *port, struct fwnode_handle *fw ret = fwnode_property_read_u32(fwnode, "sink-bc12-completion-time-ms", &val); if (!ret) port->timings.snk_bc12_cmpletion_time = val; + + ret = fwnode_property_read_u32(fwnode, "pd2-sender-response-time-ms", &val); + if (!ret) + port->timings.pd2_sender_response_time = val; + else + port->timings.pd2_sender_response_time = PD_T_PD2_SENDER_RESPONSE; + + ret = fwnode_property_read_u32(fwnode, "pd3-sender-response-time-ms", &val); + if (!ret) + port->timings.pd3_sender_response_time = val; + else + port->timings.pd3_sender_response_time = PD_T_PD3_SENDER_RESPONSE; } static int tcpm_fw_get_caps(struct tcpm_port *port, struct fwnode_handle *fwnode) diff --git a/include/linux/usb/pd.h b/include/linux/usb/pd.h index d50098fb16b5..9c599e851b9a 100644 --- a/include/linux/usb/pd.h +++ b/include/linux/usb/pd.h @@ -457,7 +457,6 @@ static inline unsigned int rdo_max_power(u32 rdo) #define PD_T_NO_RESPONSE 5000 /* 4.5 - 5.5 seconds */ #define PD_T_DB_DETECT 10000 /* 10 - 15 seconds */ #define PD_T_SEND_SOURCE_CAP 150 /* 100 - 200 ms */ -#define PD_T_SENDER_RESPONSE 60 /* 24 - 30 ms, relaxed */ #define PD_T_RECEIVER_RESPONSE 15 /* 15ms max */ #define PD_T_SOURCE_ACTIVITY 45 #define PD_T_SINK_ACTIVITY 135 @@ -491,6 +490,8 @@ static inline unsigned int rdo_max_power(u32 rdo) #define PD_T_CC_DEBOUNCE 200 /* 100 - 200 ms */ #define PD_T_PD_DEBOUNCE 20 /* 10 - 20 ms */ #define PD_T_TRY_CC_DEBOUNCE 15 /* 10 - 20 ms */ +#define PD_T_PD2_SENDER_RESPONSE 27 /* PD20 spec 24 - 30 ms */ +#define PD_T_PD3_SENDER_RESPONSE 30 /* PD30 spec 27 - 33 ms */ #define PD_N_CAPS_COUNT (PD_T_NO_RESPONSE / PD_T_SEND_SOURCE_CAP) #define PD_N_HARD_RESET_COUNT 2 -- 2.17.1

6 months, 1 week

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2024