September 2024 - Linux-stable-mirror

[PATCH 2/2] mm/hugetlb.c: Fix UAF of vma in hugetlb fault pathway

by Vishal Moola (Oracle)

Syzbot reports a UAF in hugetlb_fault(). This happens because vmf_anon_prepare() could drop the per-VMA lock and allow the current VMA to be freed before hugetlb_vma_unlock_read() is called. We can fix this by using a modified version of vmf_anon_prepare() that doesn't release the VMA lock on failure, and then release it ourselves after hugetlb_vma_unlock_read(). Reported-by: syzbot+2dab93857ee95f2eeb08(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-mm/00000000000067c20b06219fbc26@google.com/ Fixes: 9acad7ba3e25 ("hugetlb: use vmf_anon_prepare() instead of anon_vma_prepare()") Signed-off-by: Vishal Moola (Oracle) <vishal.moola(a)gmail.com> Cc: <stable(a)vger.kernel.org> --- mm/hugetlb.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 5c77defad295..190fa05635f4 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -5915,7 +5915,7 @@ static vm_fault_t hugetlb_wp(struct folio *pagecache_folio, * When the original hugepage is shared one, it does not have * anon_vma prepared. */ - ret = vmf_anon_prepare(vmf); + ret = __vmf_anon_prepare(vmf); if (unlikely(ret)) goto out_release_all; @@ -6114,7 +6114,7 @@ static vm_fault_t hugetlb_no_page(struct address_space *mapping, } if (!(vma->vm_flags & VM_MAYSHARE)) { - ret = vmf_anon_prepare(vmf); + ret = __vmf_anon_prepare(vmf); if (unlikely(ret)) goto out; } @@ -6245,6 +6245,14 @@ static vm_fault_t hugetlb_no_page(struct address_space *mapping, folio_unlock(folio); out: hugetlb_vma_unlock_read(vma); + + /* + * We must check to release the per-VMA lock. __vmf_anon_prepare() is + * the only way ret can be set to VM_FAULT_RETRY. + */ + if (unlikely(ret & VM_FAULT_RETRY)) + vma_end_read(vma); + mutex_unlock(&hugetlb_fault_mutex_table[hash]); return ret; @@ -6466,6 +6474,14 @@ vm_fault_t hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma, } out_mutex: hugetlb_vma_unlock_read(vma); + + /* + * We must check to release the per-VMA lock. __vmf_anon_prepare() in + * hugetlb_wp() is the only way ret can be set to VM_FAULT_RETRY. + */ + if (unlikely(ret & VM_FAULT_RETRY)) + vma_end_read(vma); + mutex_unlock(&hugetlb_fault_mutex_table[hash]); /* * Generally it's safe to hold refcount during waiting page lock. But -- 2.45.0

2 hours, 45 minutes

1
0
0 0

[PATCH stable-6.10 regression] Revert "soundwire: stream: fix programming slave ports for non-continous port maps"

by Peter Ujfalusi

The prop->src_dpn_prop and prop.sink_dpn_prop is allocated for the _number_ of ports and it is forced as 0 index based. The original code was correct while the change to walk the bits and use their position as index into the arrays is not correct. For exmple we can have the prop.source_ports=0x2, which means we have one port, but the prop.src_dpn_prop[1] is accessing outside of the allocated memory. This reverts commit 6fa78e9c41471fe43052cd6feba6eae1b0277ae3. Cc: stable(a)vger.kernel.org # 6.10.y Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> --- Hi, The reverted patch causes major regression on soundwire causing all audio to fail. Interestingly the patch is only in 6.10.8 and 6.10.9, not in mainline or linux-next. soundwire sdw-master-0-1: Program transport params failed: -22 soundwire sdw-master-0-1: Program params failed: -22 SDW1-Playback: ASoC: error at snd_soc_link_prepare on SDW1-Playback: -22 Regards, Peter drivers/soundwire/stream.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/soundwire/stream.c b/drivers/soundwire/stream.c index 00191b1d2260..4e9e7d2a942d 100644 --- a/drivers/soundwire/stream.c +++ b/drivers/soundwire/stream.c @@ -1286,18 +1286,18 @@ struct sdw_dpn_prop *sdw_get_slave_dpn_prop(struct sdw_slave *slave, unsigned int port_num) { struct sdw_dpn_prop *dpn_prop; - unsigned long mask; + u8 num_ports; int i; if (direction == SDW_DATA_DIR_TX) { - mask = slave->prop.source_ports; + num_ports = hweight32(slave->prop.source_ports); dpn_prop = slave->prop.src_dpn_prop; } else { - mask = slave->prop.sink_ports; + num_ports = hweight32(slave->prop.sink_ports); dpn_prop = slave->prop.sink_dpn_prop; } - for_each_set_bit(i, &mask, 32) { + for (i = 0; i < num_ports; i++) { if (dpn_prop[i].num == port_num) return &dpn_prop[i]; } -- 2.46.0

3 hours, 11 minutes

5
5
0 0

[PATCH net] netkit: Ensure current->bpf_net_context is set in netkit_xmit()

by Jordan Rife

When operating Cilium in netkit mode with BPF-based host routing, calls to bpf_redirect() cause a kernel panic. [ 52.247646] BUG: kernel NULL pointer dereference, address: 0000000000000038 ... [ 52.247727] RIP: 0010:bpf_redirect+0x18/0x80 ... [ 52.247986] Call Trace: [ 52.247990] <TASK> [ 52.248002] ? show_regs+0x6c/0x80 [ 52.248024] ? __die+0x24/0x80 [ 52.248029] ? page_fault_oops+0x155/0x570 [ 52.248047] ? fib_rules_lookup+0x112/0x270 [ 52.248056] ? do_user_addr_fault+0x4b2/0x870 [ 52.248063] ? exc_page_fault+0x82/0x1b0 [ 52.248090] ? asm_exc_page_fault+0x27/0x30 [ 52.248103] ? bpf_redirect+0x18/0x80 [ 52.248109] bpf_prog_f0698aabaf44c832_tail_handle_ipv4+0x173f/0x2707 [ 52.248119] ? sbitmap_find_bit+0xe3/0x270 [ 52.248129] netkit_xmit+0x177/0x3c0 [ 52.248139] dev_hard_start_xmit+0x62/0x1d0 [ 52.248149] __dev_queue_xmit+0x241/0xf30 [ 52.248155] ? alloc_skb_with_frags+0x60/0x280 [ 52.248164] ? __check_object_size+0x2a2/0x310 [ 52.248173] ? ip_generic_getfrag+0x63/0x110 [ 52.248181] ip_finish_output2+0x2cf/0x560 [ 52.248187] __ip_finish_output+0xb6/0x180 [ 52.248193] ip_finish_output+0x29/0x120 [ 52.248198] ip_output+0x5f/0x100 [ 52.248204] ? __pfx_ip_finish_output+0x10/0x10 [ 52.248210] ip_send_skb+0x98/0xb0 [ 52.248215] udp_send_skb+0x146/0x370 Setting a breakpoint inside bpf_net_ctx_get_ri() confirms that current->bpf_net_context is NULL right before the panic. (gdb) p $lx_current().bpf_net_context $4 = (struct bpf_net_context *) 0x0 <fixed_percpu_data> (gdb) disassemble bpf_redirect Dump of assembler code for function bpf_redirect: 0xffffffff81f085e0 <+0>: nopl 0x0(%rax,%rax,1) 0xffffffff81f085e5 <+5>: mov %gs:0x7e12d593(%rip),%rax 0xffffffff81f085ed <+13>: push %rbp 0xffffffff81f085ee <+14>: mov 0x23d0(%rax),%rax => 0xffffffff81f085f5 <+21>: mov %rsp,%rbp 0xffffffff81f085f8 <+24>: mov 0x38(%rax),%edx ... (gdb) continue Continuing. Thread 1 hit Breakpoint 1, panic ... 288 { (gdb) commit 401cb7dae813 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.") recently moved bpf_redirect_info into bpf_net_context, a new member of task_struct. Currently, current->bpf_net_context is set and then cleared inside sch_handle_egress() where tcx_run() and tc_run() execute, but it looks like netkit_xmit() was missed leaving current->bpf_net_context uninitialized when it runs. This patch ensures that current->bpf_net_context is initialized while running netkit_xmit(). Signed-off-by: Jordan Rife <jrife(a)google.com> Fixes: 401cb7dae813 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.") Cc: stable(a)vger.kernel.org --- drivers/net/netkit.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/netkit.c b/drivers/net/netkit.c index d0036a856039..92ac0cb5a327 100644 --- a/drivers/net/netkit.c +++ b/drivers/net/netkit.c @@ -65,6 +65,7 @@ static struct netkit *netkit_priv(const struct net_device *dev) static netdev_tx_t netkit_xmit(struct sk_buff *skb, struct net_device *dev) { + struct bpf_net_context __bpf_net_ctx, *bpf_net_ctx; struct netkit *nk = netkit_priv(dev); enum netkit_action ret = READ_ONCE(nk->policy); netdev_tx_t ret_dev = NET_XMIT_SUCCESS; @@ -73,6 +74,7 @@ static netdev_tx_t netkit_xmit(struct sk_buff *skb, struct net_device *dev) int len = skb->len; rcu_read_lock(); + bpf_net_ctx = bpf_net_ctx_set(&__bpf_net_ctx); peer = rcu_dereference(nk->peer); if (unlikely(!peer || !(peer->flags & IFF_UP) || !pskb_may_pull(skb, ETH_HLEN) || @@ -109,6 +111,7 @@ static netdev_tx_t netkit_xmit(struct sk_buff *skb, struct net_device *dev) ret_dev = NET_XMIT_DROP; break; } + bpf_net_ctx_clear(bpf_net_ctx); rcu_read_unlock(); return ret_dev; } -- 2.46.0.662.g92d0881bb0-goog

3 hours, 18 minutes

2
1
0 0

[PATCH v3] i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition

by Kaixin Wang

In the svc_i3c_master_probe function, &master->hj_work is bound with svc_i3c_master_hj_work, &master->ibi_work is bound with svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work can start the hj_work, svc_i3c_master_irq_handler can start the ibi_work. If we remove the module which will call svc_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | svc_i3c_master_hj_work svc_i3c_master_remove | i3c_master_unregister(&master->base)| device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in svc_i3c_master_remove. Fixes: 0f74f8b6675c ("i3c: Make i3c_master_unregister() return void") Cc: stable(a)vger.kernel.org Signed-off-by: Kaixin Wang <kxwang23(a)m.fudan.edu.cn> Reviewed-by: Miquel Raynal <miquel.raynal(a)bootlin.com> --- v3: - add the tag "Cc: stable(a)vger.kernel.org" in the sign-off area - Link to v2: https://lore.kernel.org/r/20240914154030.180-1-kxwang23@m.fudan.edu.cn v2: - add fixes tag and cc stable, suggested by Frank - add Reviewed-by label from Miquel - Link to v1: https://lore.kernel.org/r/20240911150135.839946-1-kxwang23@m.fudan.edu.cn --- drivers/i3c/master/svc-i3c-master.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/i3c/master/svc-i3c-master.c b/drivers/i3c/master/svc-i3c-master.c index 0a68fd1b81d4..e084ba648b4a 100644 --- a/drivers/i3c/master/svc-i3c-master.c +++ b/drivers/i3c/master/svc-i3c-master.c @@ -1775,6 +1775,7 @@ static void svc_i3c_master_remove(struct platform_device *pdev) { struct svc_i3c_master *master = platform_get_drvdata(pdev); + cancel_work_sync(&master->hj_work); i3c_master_unregister(&master->base); pm_runtime_dont_use_autosuspend(&pdev->dev); -- 2.39.1.windows.1

5 hours, 47 minutes

1
0
0 0

[PATCH v4 2/2] ufs: core: requeue aborted request

by peter.wang＠mediatek.com

From: Peter Wang <peter.wang(a)mediatek.com> ufshcd_abort_all froce abort all on-going command and the host will automatically fill in the OCS field of the corresponding response with OCS_ABORTED based on different working modes. MCQ mode: aborts a command using SQ cleanup, The host controller will post a Completion Queue entry with OCS = ABORTED. SDB mode: aborts a command using UTRLCLR. Task Management response which means a Transfer Request was aborted. For these two cases, set a flag to notify SCSI to requeue the command after receiving response with OCS_ABORTED. Fixes: ab248643d3d6 ("scsi: ufs: core: Add error handling for MCQ mode") Cc: stable(a)vger.kernel.org Signed-off-by: Peter Wang <peter.wang(a)mediatek.com> --- drivers/ufs/core/ufshcd.c | 34 +++++++++++++++++++--------------- include/ufs/ufshcd.h | 3 +++ 2 files changed, 22 insertions(+), 15 deletions(-) diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c index a6f818cdef0e..615da47c1727 100644 --- a/drivers/ufs/core/ufshcd.c +++ b/drivers/ufs/core/ufshcd.c @@ -3006,6 +3006,7 @@ static int ufshcd_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *cmd) ufshcd_prepare_lrbp_crypto(scsi_cmd_to_rq(cmd), lrbp); lrbp->req_abort_skip = false; + lrbp->abort_initiated_by_err = false; ufshcd_comp_scsi_upiu(hba, lrbp); @@ -5404,7 +5405,10 @@ ufshcd_transfer_rsp_status(struct ufs_hba *hba, struct ufshcd_lrb *lrbp, } break; case OCS_ABORTED: - result |= DID_ABORT << 16; + if (lrbp->abort_initiated_by_err) + result |= DID_REQUEUE << 16; + else + result |= DID_ABORT << 16; break; case OCS_INVALID_COMMAND_STATUS: result |= DID_REQUEUE << 16; @@ -6471,26 +6475,12 @@ static bool ufshcd_abort_one(struct request *rq, void *priv) struct scsi_device *sdev = cmd->device; struct Scsi_Host *shost = sdev->host; struct ufs_hba *hba = shost_priv(shost); - struct ufshcd_lrb *lrbp = &hba->lrb[tag]; - struct ufs_hw_queue *hwq; - unsigned long flags; *ret = ufshcd_try_to_abort_task(hba, tag); dev_err(hba->dev, "Aborting tag %d / CDB %#02x %s\n", tag, hba->lrb[tag].cmd ? hba->lrb[tag].cmd->cmnd[0] : -1, *ret ? "failed" : "succeeded"); - /* Release cmd in MCQ mode if abort succeeds */ - if (hba->mcq_enabled && (*ret == 0)) { - hwq = ufshcd_mcq_req_to_hwq(hba, scsi_cmd_to_rq(lrbp->cmd)); - if (!hwq) - return 0; - spin_lock_irqsave(&hwq->cq_lock, flags); - if (ufshcd_cmd_inflight(lrbp->cmd)) - ufshcd_release_scsi_cmd(hba, lrbp); - spin_unlock_irqrestore(&hwq->cq_lock, flags); - } - return *ret == 0; } @@ -7561,6 +7551,20 @@ int ufshcd_try_to_abort_task(struct ufs_hba *hba, int tag) goto out; } + /* + * When the host software receives a "FUNCTION COMPLETE", set flag + * to requeue command after receive response with OCS_ABORTED + * SDB mode: UTRLCLR Task Management response which means a Transfer + * Request was aborted. + * MCQ mode: Host will post to CQ with OCS_ABORTED after SQ cleanup + * This flag is set because ufshcd_abort_all forcibly aborts all + * commands, and the host will automatically fill in the OCS field + * of the corresponding response with OCS_ABORTED. + * Therefore, upon receiving this response, it needs to be requeued. + */ + if (!err) + lrbp->abort_initiated_by_err = true; + err = ufshcd_clear_cmd(hba, tag); if (err) dev_err(hba->dev, "%s: Failed clearing cmd at tag %d, err %d\n", diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h index 0fd2aebac728..15b357672ca5 100644 --- a/include/ufs/ufshcd.h +++ b/include/ufs/ufshcd.h @@ -173,6 +173,8 @@ struct ufs_pm_lvl_states { * @crypto_key_slot: the key slot to use for inline crypto (-1 if none) * @data_unit_num: the data unit number for the first block for inline crypto * @req_abort_skip: skip request abort task flag + * @abort_initiated_by_err: The flag is specifically used to handle aborts + * caused by errors due to host/device communication */ struct ufshcd_lrb { struct utp_transfer_req_desc *utr_descriptor_ptr; @@ -202,6 +204,7 @@ struct ufshcd_lrb { #endif bool req_abort_skip; + bool abort_initiated_by_err; }; /** -- 2.45.2

6 hours, 12 minutes

3
8
0 0

[PATCH v2] i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition

by Kaixin Wang

In the svc_i3c_master_probe function, &master->hj_work is bound with svc_i3c_master_hj_work, &master->ibi_work is bound with svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work can start the hj_work, svc_i3c_master_irq_handler can start the ibi_work. If we remove the module which will call svc_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | svc_i3c_master_hj_work svc_i3c_master_remove | i3c_master_unregister(&master->base)| device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in svc_i3c_master_remove. Fixes: 0f74f8b6675c ("i3c: Make i3c_master_unregister() return void") Signed-off-by: Kaixin Wang <kxwang23(a)m.fudan.edu.cn> Reviewed-by: Miquel Raynal <miquel.raynal(a)bootlin.com> --- v2: - add fixes tag and cc stable, suggested by Frank - add Reviewed-by label from Miquel - Link to v1: https://lore.kernel.org/r/20240911150135.839946-1-kxwang23@m.fudan.edu.cn --- drivers/i3c/master/svc-i3c-master.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/i3c/master/svc-i3c-master.c b/drivers/i3c/master/svc-i3c-master.c index 0a68fd1b81d4..e084ba648b4a 100644 --- a/drivers/i3c/master/svc-i3c-master.c +++ b/drivers/i3c/master/svc-i3c-master.c @@ -1775,6 +1775,7 @@ static void svc_i3c_master_remove(struct platform_device *pdev) { struct svc_i3c_master *master = platform_get_drvdata(pdev); + cancel_work_sync(&master->hj_work); i3c_master_unregister(&master->base); pm_runtime_dont_use_autosuspend(&pdev->dev); -- 2.39.1.windows.1

6 hours, 39 minutes

2
1
0 0

[PATCH 0/7] iio: light: veml6030: fix issues and add support for veml6035

by Javier Carrasco

This series updates the driver for the veml6030 ALS and adds support for the veml6035, which shares most of its functionality with the former. The most relevant updates for the veml6030 are the resolution correction to meet the datasheet update that took place with Rev 1.7, 28-Nov-2023, and a fix to avoid a segmentation fault when reading the in_illuminance_period_available attribute. Vishay does not host the Product Information Notification where the resolution correction was introduced, but it can still be found online[1], and the corrected value is the one listed on the latest version of the datasheet[2] (Rev. 1.7, 28-Nov-2023) and application note[3] (Rev. 17-Jan-2024). Link: https://www.farnell.com/datasheets/4379688.pdf [1] Link: https://www.vishay.com/docs/84366/veml6030.pdf [2] Link: https://www.vishay.com/docs/84367/designingveml6030.pdf [3] Signed-off-by: Javier Carrasco <javier.carrasco.cruz(a)gmail.com> --- Javier Carrasco (7): dt-bindings: iio: light: veml6030: rename to add manufacturer dt-bindings: iio: light: veml6030: add veml6035 iio: light: veml6030: fix IIO device retrieval from embedded device iio: light: veml6030: make use of regmap_set_bits() iio: light: veml6030: update sensor resolution iio: light: veml6030: add set up delay after any power on sequence iio: light: veml6030: add support for veml6035 .../light/{veml6030.yaml => vishay,veml6030.yaml} | 42 ++- drivers/iio/light/veml6030.c | 323 ++++++++++++++++++--- 2 files changed, 319 insertions(+), 46 deletions(-) --- base-commit: 5acd9952f95fb4b7da6d09a3be39195a80845eb6 change-id: 20240903-veml6035-7a91bc088c6f Best regards, -- Javier Carrasco <javier.carrasco.cruz(a)gmail.com>

7 hours, 35 minutes

2
2
0 0

RE: Patch "riscv: dts: starfive: jh7110-common: Fix lower rate of CPUfreq by setting PLL0 rate to 1.5GHz" has been added to the 6.10-stable tree

by Xingyu Wu

On 13/09/2024 22:12, Sasha Levin wrote: > > This is a note to let you know that I've just added the patch titled > > riscv: dts: starfive: jh7110-common: Fix lower rate of CPUfreq by setting PLL0 > rate to 1.5GHz > > to the 6.10-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable- > queue.git;a=summary > > The filename of the patch is: > riscv-dts-starfive-jh7110-common-fix-lower-rate-of-c.patch > and it can be found in the queue-6.10 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 only has the part of DTS without the clock driver patch[1]. [1]: https://lore.kernel.org/all/20240826080430.179788-2-xingyu.wu@starfivetech.… I don't know your plan about this driver patch, or maybe I missed it. But the DTS changes really needs the driver patch to work and you should add the driver patch. Thanks, Xingyu Wu > > > commit 67b60bf9777bd340c7179adb5376dcdd3f0c260c > Author: Xingyu Wu <xingyu.wu(a)starfivetech.com> > Date: Mon Aug 26 16:04:30 2024 +0800 > > riscv: dts: starfive: jh7110-common: Fix lower rate of CPUfreq by setting PLL0 > rate to 1.5GHz > > [ Upstream commit 61f2e8a3a94175dbbaad6a54f381b2a505324610 ] > > CPUfreq supports 4 cpu frequency loads on 375/500/750/1500MHz. > But now PLL0 rate is 1GHz and the cpu frequency loads become > 250/333/500/1000MHz in fact. > > The PLL0 rate should be default set to 1.5GHz and set the > cpu_core rate to 500MHz in safe. > > Fixes: e2c510d6d630 ("riscv: dts: starfive: Add cpu scaling for JH7110 SoC") > Signed-off-by: Xingyu Wu <xingyu.wu(a)starfivetech.com> > Reviewed-by: Hal Feng <hal.feng(a)starfivetech.com> > Signed-off-by: Conor Dooley <conor.dooley(a)microchip.com> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/arch/riscv/boot/dts/starfive/jh7110-common.dtsi > b/arch/riscv/boot/dts/starfive/jh7110-common.dtsi > index 68d16717db8c..51d85f447626 100644 > --- a/arch/riscv/boot/dts/starfive/jh7110-common.dtsi > +++ b/arch/riscv/boot/dts/starfive/jh7110-common.dtsi > @@ -354,6 +354,12 @@ spi_dev0: spi@0 { > }; > }; > > +&syscrg { > + assigned-clocks = <&syscrg JH7110_SYSCLK_CPU_CORE>, > + <&pllclk JH7110_PLLCLK_PLL0_OUT>; > + assigned-clock-rates = <500000000>, <1500000000>; }; > + > &sysgpio { > i2c0_pins: i2c0-0 { > i2c-pins {

11 hours, 54 minutes

3
5
0 0

[PATCH] power: supply: sysfs: enable is_writeable check during sysfs creation

by Andreas Kemnade

The files in sysfs are created during device_add(). psy->use_cnt is not incremented yet. So attributes are created readonly without checking desc->property_is_writeable() and writeable files are readonly. To fix this, revert back to calling desc->property_is_writeable() directly without using the helper. Fixes: be6299c6e55e ("power: supply: sysfs: use power_supply_property_is_writeable()") Signed-off-by: Andreas Kemnade <andreas(a)kemnade.info> Cc: stable(a)vger.kernel.org # 6.11 --- drivers/power/supply/power_supply_sysfs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/power/supply/power_supply_sysfs.c b/drivers/power/supply/power_supply_sysfs.c index 3e63d165b2f70..b86e11bdc07ef 100644 --- a/drivers/power/supply/power_supply_sysfs.c +++ b/drivers/power/supply/power_supply_sysfs.c @@ -379,7 +379,8 @@ static umode_t power_supply_attr_is_visible(struct kobject *kobj, int property = psy->desc->properties[i]; if (property == attrno) { - if (power_supply_property_is_writeable(psy, property) > 0) + if (psy->desc->property_is_writeable && + psy->desc->property_is_writeable(psy, property) > 0) mode |= S_IWUSR; return mode; -- 2.39.2

13 hours, 58 minutes

2
1
0 0

[PATCH v3 3/3] block: fix ordering between checking BLK_MQ_S_STOPPED and adding requests

by Muchun Song

Supposing first scenario with a virtio_blk driver. CPU0 CPU1 blk_mq_try_issue_directly() __blk_mq_issue_directly() q->mq_ops->queue_rq() virtio_queue_rq() blk_mq_stop_hw_queue() virtblk_done() blk_mq_request_bypass_insert() 1) store blk_mq_start_stopped_hw_queue() clear_bit(BLK_MQ_S_STOPPED) 3) store blk_mq_run_hw_queue() if (!blk_mq_hctx_has_pending()) 4) load return blk_mq_sched_dispatch_requests() blk_mq_run_hw_queue() if (!blk_mq_hctx_has_pending()) return blk_mq_sched_dispatch_requests() if (blk_mq_hctx_stopped()) 2) load return __blk_mq_sched_dispatch_requests() Supposing another scenario. CPU0 CPU1 blk_mq_requeue_work() blk_mq_insert_request() 1) store virtblk_done() blk_mq_start_stopped_hw_queue() blk_mq_run_hw_queues() clear_bit(BLK_MQ_S_STOPPED) 3) store blk_mq_run_hw_queue() if (!blk_mq_hctx_has_pending()) 4) load return blk_mq_sched_dispatch_requests() if (blk_mq_hctx_stopped()) 2) load continue blk_mq_run_hw_queue() Both scenarios are similar, the full memory barrier should be inserted between 1) and 2), as well as between 3) and 4) to make sure that either CPU0 sees BLK_MQ_S_STOPPED is cleared or CPU1 sees dispatch list. Otherwise, either CPU will not rerun the hardware queue causing starvation of the request. The easy way to fix it is to add the essential full memory barrier into helper of blk_mq_hctx_stopped(). In order to not affect the fast path (hardware queue is not stopped most of the time), we only insert the barrier into the slow path. Actually, only slow path needs to care about missing of dispatching the request to the low-level device driver. Fixes: 320ae51feed5 ("blk-mq: new multi-queue block IO queueing mechanism") Cc: stable(a)vger.kernel.org Cc: Muchun Song <muchun.song(a)linux.dev> Signed-off-by: Muchun Song <songmuchun(a)bytedance.com> Reviewed-by: Ming Lei <ming.lei(a)redhat.com> --- block/blk-mq.c | 6 ++++++ block/blk-mq.h | 13 +++++++++++++ 2 files changed, 19 insertions(+) diff --git a/block/blk-mq.c b/block/blk-mq.c index ff6df6c7eeb25..b90c1680cb780 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -2413,6 +2413,12 @@ void blk_mq_start_stopped_hw_queue(struct blk_mq_hw_ctx *hctx, bool async) return; clear_bit(BLK_MQ_S_STOPPED, &hctx->state); + /* + * Pairs with the smp_mb() in blk_mq_hctx_stopped() to order the + * clearing of BLK_MQ_S_STOPPED above and the checking of dispatch + * list in the subsequent routine. + */ + smp_mb__after_atomic(); blk_mq_run_hw_queue(hctx, async); } EXPORT_SYMBOL_GPL(blk_mq_start_stopped_hw_queue); diff --git a/block/blk-mq.h b/block/blk-mq.h index 260beea8e332c..f36f3bff70d86 100644 --- a/block/blk-mq.h +++ b/block/blk-mq.h @@ -228,6 +228,19 @@ static inline struct blk_mq_tags *blk_mq_tags_from_data(struct blk_mq_alloc_data static inline bool blk_mq_hctx_stopped(struct blk_mq_hw_ctx *hctx) { + /* Fast path: hardware queue is not stopped most of the time. */ + if (likely(!test_bit(BLK_MQ_S_STOPPED, &hctx->state))) + return false; + + /* + * This barrier is used to order adding of dispatch list before and + * the test of BLK_MQ_S_STOPPED below. Pairs with the memory barrier + * in blk_mq_start_stopped_hw_queue() so that dispatch code could + * either see BLK_MQ_S_STOPPED is cleared or dispatch list is not + * empty to avoid missing dispatching requests. + */ + smp_mb(); + return test_bit(BLK_MQ_S_STOPPED, &hctx->state); } -- 2.20.1

14 hours, 57 minutes

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2024