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

FAILED: patch "[PATCH] mm: zswap: properly synchronize freeing resources during CPU" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-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-6.1.y git checkout FETCH_HEAD git cherry-pick -x 12dcb0ef540629a281533f9dedc1b6b8e14cfb65 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025012014-sardine-hardwood-6828@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 12dcb0ef540629a281533f9dedc1b6b8e14cfb65 Mon Sep 17 00:00:00 2001 From: Yosry Ahmed <yosryahmed(a)google.com> Date: Wed, 8 Jan 2025 22:24:41 +0000 Subject: [PATCH] mm: zswap: properly synchronize freeing resources during CPU hotunplug 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 some of the resources attached to the acomp_ctx are freed during hotunplug in zswap_cpu_comp_dead() (i.e. acomp_ctx.buffer, acomp_ctx.req, or acomp_ctx.acomp). 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. Use the acomp_ctx.mutex to synchronize CPU hotplug callbacks allocating and freeing resources with compression/decompression paths. Make sure that acomp_ctx.req is NULL when the resources are freed. In the compression/decompression paths, check if acomp_ctx.req is NULL after acquiring the mutex (meaning the CPU was offlined) and retry on the new CPU. The initialization of acomp_ctx.mutex is moved from the CPU hotplug callback to the pool initialization where it belongs (where the mutex is allocated). In addition to adding clarity, this makes sure that CPU hotplug cannot reinitialize a mutex that is already locked by compression/decompression. Previously a fix was attempted by holding cpus_read_lock() [1]. This would have caused a potential deadlock as it is possible for code already holding the lock to fall into reclaim and enter zswap (causing a deadlock). A fix was also attempted using SRCU for synchronization, but Johannes pointed out that synchronize_srcu() cannot be used in CPU hotplug notifiers [2]. Alternative fixes that were considered/attempted and could have worked: - Refcounting the per-CPU acomp_ctx. This involves complexity in handling the race between the refcount dropping to zero in zswap_[de]compress() and the refcount being re-initialized when the CPU is onlined. - Disabling migration before getting the per-CPU acomp_ctx [3], but that's discouraged and is a much bigger hammer than needed, and could result in subtle performance issues. [1]https://lkml.kernel.org/20241219212437.2714151-1-yosryahmed@google.com/ [2]https://lkml.kernel.org/20250107074724.1756696-2-yosryahmed@google.com/ [3]https://lkml.kernel.org/20250107222236.2715883-2-yosryahmed@google.com/ [yosryahmed(a)google.com: remove comment] Link: https://lkml.kernel.org/r/CAJD7tkaxS1wjn+swugt8QCvQ-rVF5RZnjxwPGX17k8x9zSMa… Link: https://lkml.kernel.org/r/20250108222441.3622031-1-yosryahmed@google.com Fixes: 1ec3b5fe6eec ("mm/zswap: move to use crypto_acomp API for hardware acceleration") Signed-off-by: Yosry Ahmed <yosryahmed(a)google.com> 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: Barry Song <baohua(a)kernel.org> Cc: Chengming Zhou <chengming.zhou(a)linux.dev> Cc: Kanchana P Sridhar <kanchana.p.sridhar(a)intel.com> Cc: Nhat Pham <nphamcs(a)gmail.com> Cc: Vitaly Wool <vitalywool(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/mm/zswap.c b/mm/zswap.c index f6316b66fb23..30f5a27a6862 100644 --- a/mm/zswap.c +++ b/mm/zswap.c @@ -251,7 +251,7 @@ static struct zswap_pool *zswap_pool_create(char *type, char *compressor) struct zswap_pool *pool; char name[38]; /* 'zswap' + 32 char (max) num + \0 */ gfp_t gfp = __GFP_NORETRY | __GFP_NOWARN | __GFP_KSWAPD_RECLAIM; - int ret; + int ret, cpu; if (!zswap_has_pool) { /* if either are unset, pool initialization failed, and we @@ -285,6 +285,9 @@ static struct zswap_pool *zswap_pool_create(char *type, char *compressor) goto error; } + for_each_possible_cpu(cpu) + mutex_init(&per_cpu_ptr(pool->acomp_ctx, cpu)->mutex); + ret = cpuhp_state_add_instance(CPUHP_MM_ZSWP_POOL_PREPARE, &pool->node); if (ret) @@ -821,11 +824,12 @@ static int zswap_cpu_comp_prepare(unsigned int cpu, struct hlist_node *node) struct acomp_req *req; int ret; - mutex_init(&acomp_ctx->mutex); - + mutex_lock(&acomp_ctx->mutex); acomp_ctx->buffer = kmalloc_node(PAGE_SIZE * 2, GFP_KERNEL, cpu_to_node(cpu)); - if (!acomp_ctx->buffer) - return -ENOMEM; + if (!acomp_ctx->buffer) { + ret = -ENOMEM; + goto buffer_fail; + } acomp = crypto_alloc_acomp_node(pool->tfm_name, 0, 0, cpu_to_node(cpu)); if (IS_ERR(acomp)) { @@ -855,12 +859,15 @@ static int zswap_cpu_comp_prepare(unsigned int cpu, struct hlist_node *node) acomp_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG, crypto_req_done, &acomp_ctx->wait); + mutex_unlock(&acomp_ctx->mutex); return 0; req_fail: crypto_free_acomp(acomp_ctx->acomp); acomp_fail: kfree(acomp_ctx->buffer); +buffer_fail: + mutex_unlock(&acomp_ctx->mutex); return ret; } @@ -869,17 +876,45 @@ static int zswap_cpu_comp_dead(unsigned int cpu, struct hlist_node *node) struct zswap_pool *pool = hlist_entry(node, struct zswap_pool, node); struct crypto_acomp_ctx *acomp_ctx = per_cpu_ptr(pool->acomp_ctx, cpu); + mutex_lock(&acomp_ctx->mutex); if (!IS_ERR_OR_NULL(acomp_ctx)) { if (!IS_ERR_OR_NULL(acomp_ctx->req)) acomp_request_free(acomp_ctx->req); + acomp_ctx->req = NULL; if (!IS_ERR_OR_NULL(acomp_ctx->acomp)) crypto_free_acomp(acomp_ctx->acomp); kfree(acomp_ctx->buffer); } + mutex_unlock(&acomp_ctx->mutex); return 0; } +static struct crypto_acomp_ctx *acomp_ctx_get_cpu_lock(struct zswap_pool *pool) +{ + struct crypto_acomp_ctx *acomp_ctx; + + for (;;) { + acomp_ctx = raw_cpu_ptr(pool->acomp_ctx); + mutex_lock(&acomp_ctx->mutex); + if (likely(acomp_ctx->req)) + return acomp_ctx; + /* + * It is possible that we were migrated to a different CPU after + * getting the per-CPU ctx but before the mutex was acquired. If + * the old CPU got offlined, zswap_cpu_comp_dead() could have + * already freed ctx->req (among other things) and set it to + * NULL. Just try again on the new CPU that we ended up on. + */ + mutex_unlock(&acomp_ctx->mutex); + } +} + +static void acomp_ctx_put_unlock(struct crypto_acomp_ctx *acomp_ctx) +{ + mutex_unlock(&acomp_ctx->mutex); +} + static bool zswap_compress(struct page *page, struct zswap_entry *entry, struct zswap_pool *pool) { @@ -893,10 +928,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); - - mutex_lock(&acomp_ctx->mutex); - + acomp_ctx = acomp_ctx_get_cpu_lock(pool); dst = acomp_ctx->buffer; sg_init_table(&input, 1); sg_set_page(&input, page, PAGE_SIZE, 0); @@ -949,7 +981,7 @@ static bool zswap_compress(struct page *page, struct zswap_entry *entry, else if (alloc_ret) zswap_reject_alloc_fail++; - mutex_unlock(&acomp_ctx->mutex); + acomp_ctx_put_unlock(acomp_ctx); return comp_ret == 0 && alloc_ret == 0; } @@ -960,9 +992,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); - mutex_lock(&acomp_ctx->mutex); - + acomp_ctx = acomp_ctx_get_cpu_lock(entry->pool); src = zpool_map_handle(zpool, entry->handle, ZPOOL_MM_RO); /* * If zpool_map_handle is atomic, we cannot reliably utilize its mapped buffer @@ -986,10 +1016,10 @@ static void zswap_decompress(struct zswap_entry *entry, struct folio *folio) acomp_request_set_params(acomp_ctx->req, &input, &output, entry->length, PAGE_SIZE); BUG_ON(crypto_wait_req(crypto_acomp_decompress(acomp_ctx->req), &acomp_ctx->wait)); BUG_ON(acomp_ctx->req->dlen != PAGE_SIZE); - mutex_unlock(&acomp_ctx->mutex); if (src != acomp_ctx->buffer) zpool_unmap_handle(zpool, entry->handle); + acomp_ctx_put_unlock(acomp_ctx); } /*********************************

10 months

1
0
0 0

[PATCH 5.10] xfs: add bounds checking to xlog_recover_process_data

by Denis Arefev

From: lei lu <llfamsec(a)gmail.com> commit fb63435b7c7dc112b1ae1baea5486e0a6e27b196 upstream. There is a lack of verification of the space occupied by fixed members of xlog_op_header in the xlog_recover_process_data. We can create a crafted image to trigger an out of bounds read by following these steps: 1) Mount an image of xfs, and do some file operations to leave records 2) Before umounting, copy the image for subsequent steps to simulate abnormal exit. Because umount will ensure that tail_blk and head_blk are the same, which will result in the inability to enter xlog_recover_process_data 3) Write a tool to parse and modify the copied image in step 2 4) Make the end of the xlog_op_header entries only 1 byte away from xlog_rec_header->h_size 5) xlog_rec_header->h_num_logops++ 6) Modify xlog_rec_header->h_crc Fix: Add a check to make sure there is sufficient space to access fixed members of xlog_op_header. Signed-off-by: lei lu <llfamsec(a)gmail.com> Reviewed-by: Dave Chinner <dchinner(a)redhat.com> Reviewed-by: Darrick J. Wong <djwong(a)kernel.org> Signed-off-by: Chandan Babu R <chandanbabu(a)kernel.org> Signed-off-by: Denis Arefev <arefev(a)swemel.ru> --- Backport fix for CVE-2024-41014 Link: https://nvd.nist.gov/vuln/detail/cve-2024-41014 --- fs/xfs/xfs_log_recover.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c index e61f28ce3e44..eafe76f304ef 100644 --- a/fs/xfs/xfs_log_recover.c +++ b/fs/xfs/xfs_log_recover.c @@ -2419,7 +2419,10 @@ xlog_recover_process_data( ohead = (struct xlog_op_header *)dp; dp += sizeof(*ohead); - ASSERT(dp <= end); + if (dp > end) { + xfs_warn(log->l_mp, "%s: op header overrun", __func__); + return -EFSCORRUPTED; + } /* errors will abort recovery */ error = xlog_recover_process_ophdr(log, rhash, rhead, ohead, -- 2.43.0

10 months

1
0
0 0

[PATCH 5.10] drm/radeon: check bo_va->bo is non-NULL before using it

by Denis Arefev

From: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> commit 6fb15dcbcf4f212930350eaee174bb60ed40a536 upstream. The call to radeon_vm_clear_freed might clear bo_va->bo, so we have to check it before dereferencing it. Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> Acked-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> [Denis: minor fix to resolve merge conflict.] Signed-off-by: Denis Arefev <arefev(a)swemel.ru> --- Backport fix CVE-2024-41060 Link: https://nvd.nist.gov/vuln/detail/CVE-2024-41060 --- drivers/gpu/drm/radeon/radeon_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c index 75053917d213..51b6f38b5c47 100644 --- a/drivers/gpu/drm/radeon/radeon_gem.c +++ b/drivers/gpu/drm/radeon/radeon_gem.c @@ -582,7 +582,7 @@ static void radeon_gem_va_update_vm(struct radeon_device *rdev, if (r) goto error_unlock; - if (bo_va->it.start) + if (bo_va->it.start && bo_va->bo) r = radeon_vm_bo_update(rdev, bo_va, &bo_va->bo->tbo.mem); error_unlock: -- 2.43.0

10 months

1
0
0 0

[PATCH] ibmvnic: Add tx check to prevent skb leak

by Denis Arefev

From: Nick Child <nnac123(a)linux.ibm.com> From: Nick Child <nnac123(a)linux.ibm.com> commit 0983d288caf984de0202c66641577b739caad561 upstream. Below is a summary of how the driver stores a reference to an skb during transmit: tx_buff[free_map[consumer_index]]->skb = new_skb; free_map[consumer_index] = IBMVNIC_INVALID_MAP; consumer_index ++; Where variable data looks like this: free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3] consumer_index^ tx_buff == [skb=null, skb=<ptr>, skb=<ptr>, skb=null, skb=null] The driver has checks to ensure that free_map[consumer_index] pointed to a valid index but there was no check to ensure that this index pointed to an unused/null skb address. So, if, by some chance, our free_map and tx_buff lists become out of sync then we were previously risking an skb memory leak. This could then cause tcp congestion control to stop sending packets, eventually leading to ETIMEDOUT. Therefore, add a conditional to ensure that the skb address is null. If not then warn the user (because this is still a bug that should be patched) and free the old pointer to prevent memleak/tcp problems. Signed-off-by: Nick Child <nnac123(a)linux.ibm.com> Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> [Denis: minor fix to resolve merge conflict.] Signed-off-by: Denis Arefev <arefev(a)swemel.ru> --- Backport fix for CVE-2024-41066 Link: https://nvd.nist.gov/vuln/detail/CVE-2024-41066 --- drivers/net/ethernet/ibm/ibmvnic.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c index 84da6ccaf339..439796975cbf 100644 --- a/drivers/net/ethernet/ibm/ibmvnic.c +++ b/drivers/net/ethernet/ibm/ibmvnic.c @@ -1625,6 +1625,18 @@ static netdev_tx_t ibmvnic_xmit(struct sk_buff *skb, struct net_device *netdev) (tx_pool->consumer_index + 1) % tx_pool->num_buffers; tx_buff = &tx_pool->tx_buff[index]; + + /* Sanity checks on our free map to make sure it points to an index + * that is not being occupied by another skb. If skb memory is + * not freed then we see congestion control kick in and halt tx. + */ + if (unlikely(tx_buff->skb)) { + dev_warn_ratelimited(dev, "TX free map points to untracked skb (%s %d idx=%d)\n", + skb_is_gso(skb) ? "tso_pool" : "tx_pool", + queue_num, bufidx); + dev_kfree_skb_any(tx_buff->skb); + } + tx_buff->skb = skb; tx_buff->data_dma[0] = data_dma_addr; tx_buff->data_len[0] = skb->len; -- 2.43.0

10 months

1
0
0 0

[PATCH 5.10] fou: remove warn in gue_gro_receive on unsupported protocol

by Denis Arefev

From: Willem de Bruijn <willemb(a)google.com> commit dd89a81d850fa9a65f67b4527c0e420d15bf836c upstream. Drop the WARN_ON_ONCE inn gue_gro_receive if the encapsulated type is not known or does not have a GRO handler. Such a packet is easily constructed. Syzbot generates them and sets off this warning. Remove the warning as it is expected and not actionable. The warning was previously reduced from WARN_ON to WARN_ON_ONCE in commit 270136613bf7 ("fou: Do WARN_ON_ONCE in gue_gro_receive for bad proto callbacks"). Signed-off-by: Willem de Bruijn <willemb(a)google.com> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Link: https://lore.kernel.org/r/20240614122552.1649044-1-willemdebruijn.kernel@gm… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Denis Arefev <arefev(a)swemel.ru> --- Backport fix for CVE-2024-44940 Link: https://www.cve.org/CVERecord/?id=CVE-2024-44940 --- net/ipv4/fou.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv4/fou.c b/net/ipv4/fou.c index 1d67df4d8ed6..b1a8e4eec3f6 100644 --- a/net/ipv4/fou.c +++ b/net/ipv4/fou.c @@ -453,7 +453,7 @@ static struct sk_buff *gue_gro_receive(struct sock *sk, offloads = NAPI_GRO_CB(skb)->is_ipv6 ? inet6_offloads : inet_offloads; ops = rcu_dereference(offloads[proto]); - if (WARN_ON_ONCE(!ops || !ops->callbacks.gro_receive)) + if (!ops || !ops->callbacks.gro_receive) goto out; pp = call_gro_receive(ops->callbacks.gro_receive, head, skb); -- 2.43.0

10 months

1
0
0 0

[PATCH 1/1] iommu/vt-d: Make intel_iommu_drain_pasid_prq() cover faults for RID

by Lu Baolu

This driver supports page faults on PCI RID since commit <9f831c16c69e> ("iommu/vt-d: Remove the pasid present check in prq_event_thread") by allowing the reporting of page faults with the pasid_present field cleared to the upper layer for further handling. The fundamental assumption here is that the detach or replace operations act as a fence for page faults. This implies that all pending page faults associated with a specific RID or PASID are flushed when a domain is detached or replaced from a device RID or PASID. However, the intel_iommu_drain_pasid_prq() helper does not correctly handle faults for RID. This leads to faults potentially remaining pending in the iommu hardware queue even after the domain is detached, thereby violating the aforementioned assumption. Fix this issue by extending intel_iommu_drain_pasid_prq() to cover faults for RID. Fixes: 9f831c16c69e ("iommu/vt-d: Remove the pasid present check in prq_event_thread") Cc: stable(a)vger.kernel.org Suggested-by: Kevin Tian <kevin.tian(a)intel.com> Signed-off-by: Lu Baolu <baolu.lu(a)linux.intel.com> --- drivers/iommu/intel/prq.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/intel/prq.c b/drivers/iommu/intel/prq.c index c2d792db52c3..043f02d7b460 100644 --- a/drivers/iommu/intel/prq.c +++ b/drivers/iommu/intel/prq.c @@ -87,7 +87,8 @@ void intel_iommu_drain_pasid_prq(struct device *dev, u32 pasid) struct page_req_dsc *req; req = &iommu->prq[head / sizeof(*req)]; - if (!req->pasid_present || req->pasid != pasid) { + if (req->rid != sid || + (req->pasid_present && req->pasid != pasid)) { head = (head + sizeof(*req)) & PRQ_RING_MASK; continue; } -- 2.43.0

10 months

3
3
0 0

Integrated Systems Europe 2025 Exhibitors List!

by Grace Green

Hi, Are you interested in the latest attendee and exhibitor lists for Integrated Systems Europe 2025? This comprehensive database now includes last-minute registrants, providing you with up-to-date and actionable insights. Event Details: Dates: 04 - 07 Feb 2025 Location: Fira Barcelona Gran Via, Barcelona, Spain Exhibitors: 1,460 Attendees: 73,891 Data fields: Induvial Email address, Cell Phone Number, Contact Name, Job Title, Company Name, Company website, Physical Address and more), Would you like details on the attendees list, exhibitors list, or both? Let me know, and I’ll be happy to share pricing details and answer any questions. Looking forward to hearing from you! Best regards, Grace Green Sr. Demand Generation P.S. If you’d prefer not to receive updates, simply reply with “NO.”

10 months

1
0
0 0

[PATCH] cpufreq: s3c64xx: Fix compilation warning

by Viresh Kumar

The driver generates following warning when regulator support isn't enabled in the kernel. Fix it. drivers/cpufreq/s3c64xx-cpufreq.c: In function 's3c64xx_cpufreq_set_target': >> drivers/cpufreq/s3c64xx-cpufreq.c:55:22: warning: variable 'old_freq' set but not used [-Wunused-but-set-variable] 55 | unsigned int old_freq, new_freq; | ^~~~~~~~ >> drivers/cpufreq/s3c64xx-cpufreq.c:54:30: warning: variable 'dvfs' set but not used [-Wunused-but-set-variable] 54 | struct s3c64xx_dvfs *dvfs; | ^~~~ Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202501191803.CtfT7b2o-lkp@intel.com/ Cc: <stable(a)vger.kernel.org> # v5.4+ Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- drivers/cpufreq/s3c64xx-cpufreq.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/cpufreq/s3c64xx-cpufreq.c b/drivers/cpufreq/s3c64xx-cpufreq.c index c6bdfc308e99..8fc43a74cefb 100644 --- a/drivers/cpufreq/s3c64xx-cpufreq.c +++ b/drivers/cpufreq/s3c64xx-cpufreq.c @@ -51,15 +51,16 @@ static struct cpufreq_frequency_table s3c64xx_freq_table[] = { static int s3c64xx_cpufreq_set_target(struct cpufreq_policy *policy, unsigned int index) { - struct s3c64xx_dvfs *dvfs; - unsigned int old_freq, new_freq; + unsigned int new_freq = s3c64xx_freq_table[index].frequency; int ret; +#ifdef CONFIG_REGULATOR + struct s3c64xx_dvfs *dvfs; + unsigned int old_freq; + old_freq = clk_get_rate(policy->clk) / 1000; - new_freq = s3c64xx_freq_table[index].frequency; dvfs = &s3c64xx_dvfs_table[s3c64xx_freq_table[index].driver_data]; -#ifdef CONFIG_REGULATOR if (vddarm && new_freq > old_freq) { ret = regulator_set_voltage(vddarm, dvfs->vddarm_min, -- 2.31.1.272.g89b43f80a514

10 months

1
0
0 0

Kernel bug found in linux6.9-rc7

by ffhgfv

Hello, I found a bug titled “ kernel BUG in ocfs2_refcount_cal_cow_clusters” with modified syzkaller in the Linux6.9-rc7 relegated to oracle cluster file system. If you fix this issue, please add the following tag to the commit: Reported-by:jianzhou zhao <xnxc22xnxc22(a)qq.com> , xingwei lee < xrivendell7(a)gmail.com> ------------[ cut here ]------------ Title: 'kernel BUG in ocfs2_refcount_cal_cow_clusters'  ocfs2: Mounting device (7,0) on (node local, slot 0) with writeback data mode. kernel BUG at fs/ocfs2/refcounttree.c:2684! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 7960 Comm: syz-executor385 Not tainted 6.9.0-rc7 #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:ocfs2_refcount_cal_cow_clusters+0x667/0x960 fs/ocfs2/refcounttree.c:2684 Code: f3 45 86 48 c7 c6 c0 32 5a 85 4d 8b 44 24 18 48 8b 48 40 48 8b 78 28 e8 67 29 05 00 41 89 c4 e9 e5 fd ff ff e8 4a 14 40 ff 90 <0f> 0b e8 42 14 40 ff 48 8b 55 a8 44 89 e8 44 89 fb 44 29 f8 89 02 RSP: 0018:ffff8880462cfba0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8880528b04d0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff8880462cfc18 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000 FS:  0000555576e563c0(0000) GS:ffff88807ec00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002000d000 CR3: 0000000045e3e000 CR4: 0000000000750ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace:  <TASK>  ocfs2_refcount_cow_hunk+0x98/0x550 fs/ocfs2/refcounttree.c:3394  ocfs2_refcount_cow+0x65/0x2e0 fs/ocfs2/refcounttree.c:3476  ocfs2_prepare_inode_for_write.isra.0+0x630/0x970 fs/ocfs2/file.c:2326  ocfs2_file_write_iter+0x23d/0xb10 fs/ocfs2/file.c:2435  call_write_iter include/linux/fs.h:2110 [inline]  new_sync_write fs/read_write.c:497 [inline]  vfs_write+0x5a0/0x6e0 fs/read_write.c:590  ksys_write+0x9b/0x160 fs/read_write.c:643  __do_sys_write fs/read_write.c:655 [inline]  __se_sys_write fs/read_write.c:652 [inline]  __x64_sys_write+0x21/0x40 fs/read_write.c:652  x64_sys_call+0x1889/0x2680 arch/x86/include/generated/asm/syscalls_64.h:2  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xa8/0x1f0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fb511ea303d Code: c3 e8 c7 24 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff6b9aefa8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fb511ea303d RDX: 0000000000000001 RSI: 0000000020000280 RDI: 0000000000000009 RBP: 00007fff6b9af040 R08: 0000000000000140 R09: 0000000000000140 R10: 0000000000000140 R11: 0000000000000246 R12: 0000000000000000 R13: 00000000000f4240 R14: 00007fff6b9aefc4 R15: 00007fff6b9aefd0  </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:ocfs2_refcount_cal_cow_clusters+0x667/0x960 fs/ocfs2/refcounttree.c:2684 Code: f3 45 86 48 c7 c6 c0 32 5a 85 4d 8b 44 24 18 48 8b 48 40 48 8b 78 28 e8 67 29 05 00 41 89 c4 e9 e5 fd ff ff e8 4a 14 40 ff 90 <0f> 0b e8 42 14 40 ff 48 8b 55 a8 44 89 e8 44 89 fb 44 29 f8 89 02 RSP: 0018:ffff8880462cfba0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8880528b04d0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff8880462cfc18 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000 FS:  0000555576e563c0(0000) GS:ffff88807ec00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002000d000 CR3: 0000000045e3e000 CR4: 0000000000750ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 ================================================================== The commit of the kernel I used is “dd5a440a31fae6e459c0d6271dddd62825505361”  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dd5a440a31fae6e459c0d6271dddd62825505361 Kernel config: https://syzkaller.appspot.com/text?tag=KernelConfig&x=7144… Complier: gcc 11.4.0 The repro is shown in annex repro.c.txt I hope it helps. Best regards Jianzhou Zhao, Xingwei Lee.

10 months

2
2
0 0

BUG ? exc_page_fault() was optimized out of fred_hwexc() by gcc with default kernel build option (-O2).

by Ethan Zhao

Hi, Xin, Peter While checking the asm code of arch/x86/entry/entry_fred.o about function fred_hwexc(), found the code was generated as following : 0000000000000200 <fred_hwexc.constprop.0>: 200: 0f b6 87 a4 00 00 00 movzbl 0xa4(%rdi),%eax 207: 3c 0e cmp $0xe,%al /* match X86_TRAP_PF */ 209: 75 05 jne 210 <fred_hwexc.constprop.0+0x10> 20b: e9 00 00 00 00 jmp 210 <fred_hwexc.constprop.0+0x10> 210: 3c 0b cmp $0xb,%al 212: 74 6a je 27e <fred_hwexc.constprop.0+0x7e> 214: 77 17 ja 22d <fred_hwexc.constprop.0+0x2d> 216: 3c 06 cmp $0x6,%al 218: 0f 84 83 00 00 00 je 2a1 <fred_hwexc.constprop.0+0xa1> 21e: 76 29 jbe 249 <fred_hwexc.constprop.0+0x49> 220: 3c 08 cmp $0x8,%al 222: 74 78 je 29c <fred_hwexc.constprop.0+0x9c> 224: 3c 0a cmp $0xa,%al 226: 75 18 jne 240 <fred_hwexc.constprop.0+0x40> 228: e9 00 00 00 00 jmp 22d <fred_hwexc.constprop.0+0x2d> 22d: 3c 11 cmp $0x11,%al 22f: 74 66 je 297 <fred_hwexc.constprop.0+0x97> 231: 76 2c jbe 25f <fred_hwexc.constprop.0+0x5f> 233: 3c 13 cmp $0x13,%al 235: 74 5b je 292 <fred_hwexc.constprop.0+0x92> 237: 3c 15 cmp $0x15,%al 239: 75 1b jne 256 <fred_hwexc.constprop.0+0x56> 23b: e9 00 00 00 00 jmp 240 <fred_hwexc.constprop.0+0x40> 240: 3c 07 cmp $0x7,%al 242: 75 49 jne 28d <fred_hwexc.constprop.0+0x8d> 244: e9 00 00 00 00 jmp 249 <fred_hwexc.constprop.0+0x49> 249: 3c 01 cmp $0x1,%al 24b: 74 3b je 288 <fred_hwexc.constprop.0+0x88> 24d: 3c 05 cmp $0x5,%al 24f: 75 1b jne 26c <fred_hwexc.constprop.0+0x6c> 251: e9 00 00 00 00 jmp 256 <fred_hwexc.constprop.0+0x56> 256: 3c 12 cmp $0x12,%al 258: 75 33 jne 28d <fred_hwexc.constprop.0+0x8d> 25a: e9 00 00 00 00 jmp 25f <fred_hwexc.constprop.0+0x5f> seems the following calling to exc_page_fault() was optimized out from fred_hwexc() by gcc, if(likely(regs->fred_ss.vector==X86_TRAP_PF)) returnexc_page_fault(regs,error_code); gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04) GNU objdump (GNU Binutils) 2.43 default kernel config. .config:CONFIG_X86_FRED=y my understanding, -O2 is the default kernel KBUILD_CFLAGS So, Are there any workaround needed to make the kernel works with default build ? or just as Peter said in another loop, manually loading some event bits to make the over-smart gcc behave normally ？or fall back to -O(ption)0 ? Any idea, much appreciated ! Thanks, Ethan

10 months

3
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror