5.4.220-rc1 review
Subsystems (6)
Greg Kroah-Hartman
maintainerPATCH 155/255 scsi: libsas: Fix use-after-free bug in smp_execute_task_sg()
In reply to Greg Kroah-HartmanFrom: Duoming Zhou <[email protected]>
[ Upstream commit 46ba53c30666717cb06c2b3c5d896301cd00d0c0 ]
When executing SMP task failed, the smp_execute_task_sg() calls del_timer() to delete "slow_task->timer". However, if the timer handler sas_task_internal_timedout() is running, the del_timer() in smp_execute_task_sg() will not stop it and a UAF will happen. The process is shown below:
(thread 1) | (thread 2)
smp_execute_task_sg() | sas_task_internal_timedout()
... |
del_timer() |
... | ...
sas_free_task(task) |
kfree(task->slow_task) //FREE|
| task->slow_task->... //USEFix by calling del_timer_sync() in smp_execute_task_sg(), which makes sure the timer handler have finished before the "task->slow_task" is deallocated.
--- drivers/scsi/libsas/sas_expander.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/scsi/libsas/sas_expander.c +1 -1
@@ -85,7 +85,7 @@ static int smp_execute_task_sg(struct domain_device *dev, res = i->dft->lldd_execute_task (task,GFP_KERNEL );if (res) { -del_timer (&task->slow_task->timer); +del_timer_sync (&task->slow_task->timer);pr_notice ("executing SMP task failed:%d\n" , res);break ; }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 156/255 fsi: core: Check error number after calling ida_simple_get
In reply to Greg Kroah-HartmanFrom: Jiasheng Jiang <[email protected]>
[ Upstream commit 35af9fb49bc5c6d61ef70b501c3a56fe161cce3e ]
If allocation fails, the ida_simple_get() will return error number. So master->idx could be error number and be used in dev_set_name(). Therefore, it should be better to check it and return error if fails, like the ida_simple_get() in __fsi_get_new_minor().
--- drivers/fsi/fsi-core.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/fsi/fsi-core.c +3 -0
@@ -1271,6 +1271,9 @@ int fsi_master_register(struct fsi_master *master)mutex_init (&master->scan_lock); master->idx =ida_simple_get (&master_ida,0 ,INT_MAX ,GFP_KERNEL ); +if (master->idx <0 ) +return master->idx; +dev_set_name (&master->dev,"fsi%d" , master->idx); rc =device_register (&master->dev);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 157/255 mfd: intel_soc_pmic: Fix an error handling path in intel_soc_pmic_i2c_probe()
In reply to Greg Kroah-HartmanFrom: Christophe JAILLET <[email protected]>
[ Upstream commit 48749cabba109397b4e7dd556e85718ec0ec114d ]
The commit in Fixes: has added a pwm_add_table() call in the probe() and a pwm_remove_table() call in the remove(), but forget to update the error handling path of the probe.
Add the missing pwm_remove_table() call.
--- drivers/mfd/intel_soc_pmic_core.c | 1 + 1 file changed, 1 insertion(+)
drivers/mfd/intel_soc_pmic_core.c +1 -0
@@ -111,6 +111,7 @@ static int intel_soc_pmic_i2c_probe(struct i2c_client *i2c,return 0 ; err_del_irq_chip: +pwm_remove_table (crc_pwm_lookup,ARRAY_SIZE (crc_pwm_lookup));regmap_del_irq_chip (pmic->irq, pmic->irq_chip_data);return ret; }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 158/255 mfd: fsl-imx25: Fix an error handling path in mx25_tsadc_setup_irq()
In reply to Greg Kroah-HartmanFrom: Christophe JAILLET <[email protected]>
[ Upstream commit 3fa9e4cfb55da512ebfd57336fde468830719298 ]
If devm_of_platform_populate() fails, some resources need to be released.
Introduce a mx25_tsadc_unset_irq() function that undoes mx25_tsadc_setup_irq() and call it both from the new error handling path of the probe and in the remove function.
--- drivers/mfd/fsl-imx25-tsadc.c | 32 ++++++++++++++++++++++++-------- 1 file changed, 24 insertions(+), 8 deletions(-)
drivers/mfd/fsl-imx25-tsadc.c +24 -8
@@ -84,6 +84,19 @@ static int mx25_tsadc_setup_irq(struct platform_device *pdev,return 0 ; } +static int mx25_tsadc_unset_irq (struct platform_device *pdev) +{ +struct mx25_tsadc *tsadc =platform_get_drvdata (pdev); +int irq =platform_get_irq (pdev,0 ); + +if (irq) { +irq_set_chained_handler_and_data (irq,NULL ,NULL ); +irq_domain_remove (tsadc->domain); + } + +return 0 ; +} +static void mx25_tsadc_setup_clk (struct platform_device *pdev,struct mx25_tsadc *tsadc) {
@@ -171,18 +184,21 @@ static int mx25_tsadc_probe(struct platform_device *pdev)platform_set_drvdata (pdev, tsadc); -return devm_of_platform_populate (dev); + ret =devm_of_platform_populate (dev); +if (ret) + goto err_irq; + +return 0 ; + +err_irq: +mx25_tsadc_unset_irq (pdev); + +return ret; }static int mx25_tsadc_remove (struct platform_device *pdev) { -struct mx25_tsadc *tsadc =platform_get_drvdata (pdev); -int irq =platform_get_irq (pdev,0 ); - -if (irq) { -irq_set_chained_handler_and_data (irq,NULL ,NULL ); -irq_domain_remove (tsadc->domain); - } +mx25_tsadc_unset_irq (pdev);return 0 ; }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 159/255 mfd: lp8788: Fix an error handling path in lp8788_probe()
In reply to Greg Kroah-HartmanFrom: Christophe JAILLET <[email protected]>
[ Upstream commit becfdcd75126b20b8ec10066c5e85b34f8994ad5 ]
Should an error occurs in mfd_add_devices(), some resources need to be released, as already done in the .remove() function.
Add an error handling path and a lp8788_irq_exit() call to undo a previous lp8788_irq_init().
--- drivers/mfd/lp8788.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
drivers/mfd/lp8788.c +10 -2
@@ -195,8 +195,16 @@ static int lp8788_probe(struct i2c_client *cl, const struct i2c_device_id *id)if (ret)return ret; -return mfd_add_devices (lp->dev,-1 , lp8788_devs, -ARRAY_SIZE (lp8788_devs),NULL ,0 ,NULL ); + ret =mfd_add_devices (lp->dev,-1 , lp8788_devs, +ARRAY_SIZE (lp8788_devs),NULL ,0 ,NULL ); +if (ret) + goto err_exit_irq; + +return 0 ; + +err_exit_irq: +lp8788_irq_exit (lp); +return ret; }static int lp8788_remove (struct i2c_client *cl)
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 160/255 mfd: lp8788: Fix an error handling path in lp8788_irq_init() and lp8788_irq_init()
In reply to Greg Kroah-HartmanFrom: Christophe JAILLET <[email protected]>
[ Upstream commit 557244f6284f30613f2d61f14b579303165876c3 ]
In lp8788_irq_init(), if an error occurs after a successful irq_domain_add_linear() call, it must be undone by a corresponding irq_domain_remove() call.
irq_domain_remove() should also be called in lp8788_irq_exit() for the same reason.
--- drivers/mfd/lp8788-irq.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/mfd/lp8788-irq.c +3 -0
@@ -175,6 +175,7 @@ int lp8788_irq_init(struct lp8788 *lp, int irq)IRQF_TRIGGER_FALLING |IRQF_ONESHOT , "lp8788-irq", irqd);if (ret) { +irq_domain_remove (lp->irqdm);dev_err (lp->dev,"failed to create a thread for IRQ_N\n" );return ret; }
@@ -188,4 +189,6 @@ void lp8788_irq_exit(struct lp8788 *lp) {if (lp->irq)free_irq (lp->irq, lp->irqdm); +if (lp->irqdm) +irq_domain_remove (lp->irqdm); }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 161/255 mfd: fsl-imx25: Fix check for platform_get_irq() errors
In reply to Greg Kroah-HartmanFrom: Dan Carpenter <[email protected]>
[ Upstream commit 75db7907355ca5e2ff606e9dd3e86b6c3a455fe2 ]
The mx25_tsadc_remove() function assumes all non-zero returns are success but the platform_get_irq() function returns negative on error and positive non-zero values on success. It never returns zero, but if it did then treat that as a success.
--- drivers/mfd/fsl-imx25-tsadc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/mfd/fsl-imx25-tsadc.c +2 -2
@@ -69,7 +69,7 @@ static int mx25_tsadc_setup_irq(struct platform_device *pdev,int irq; irq =platform_get_irq (pdev,0 ); -if (irq <=0 ) +if (irq <0 )return irq; tsadc->domain = irq_domain_add_simple(np, 2, 0, &mx25_tsadc_domain_ops,
@@ -89,7 +89,7 @@ static int mx25_tsadc_unset_irq(struct platform_device *pdev)struct mx25_tsadc *tsadc =platform_get_drvdata (pdev);int irq =platform_get_irq (pdev,0 ); -if (irq) { +if (irq >=0 ) {irq_set_chained_handler_and_data (irq,NULL ,NULL );irq_domain_remove (tsadc->domain); }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 162/255 mfd: sm501: Add check for platform_driver_register()
In reply to Greg Kroah-HartmanFrom: Jiasheng Jiang <[email protected]>
[ Upstream commit 8325a6c24ad78b8c1acc3c42b098ee24105d68e5 ]
As platform_driver_register() can return error numbers, it should be better to check platform_driver_register() and deal with the exception.
--- drivers/mfd/sm501.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/mfd/sm501.c +6 -1
@@ -1733,7 +1733,12 @@ static struct platform_driver sm501_plat_driver = {static int __init sm501_base_init (void ) { -platform_driver_register (&sm501_plat_driver); +int ret; + + ret =platform_driver_register (&sm501_plat_driver); +if (ret <0 ) +return ret; +return pci_register_driver (&sm501_pci_driver); }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 163/255 clk: mediatek: mt8183: mfgcfg: Propagate rate changes to parent
In reply to Greg Kroah-HartmanFrom: Chen-Yu Tsai <[email protected]>
[ Upstream commit 9f94f545f258b15bfa6357eb62e1e307b712851e ]
The only clock in the MT8183 MFGCFG block feeds the GPU. Propagate its rate change requests to its parent, so that DVFS for the GPU can work properly.
--- drivers/clk/mediatek/clk-mt8183-mfgcfg.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/clk/mediatek/clk-mt8183-mfgcfg.c +3 -3
@@ -18,9 +18,9 @@ static const struct mtk_gate_regs mfg_cg_regs = { .sta_ofs = 0x0, }; -#define GATE_MFG (_id, _name, _parent, _shift) \ - GATE_MTK(_id, _name, _parent, &mfg_cg_regs, _shift, \ - &mtk_clk_gate_ops_setclr) +#define GATE_MFG (_id, _name, _parent, _shift) \ + GATE_MTK_FLAGS(_id, _name, _parent, &mfg_cg_regs, _shift, \ + &mtk_clk_gate_ops_setclr, CLK_SET_RATE_PARENT)static const struct mtk_gate mfg_clks[] = {GATE_MFG (CLK_MFG_BG3D ,"mfg_bg3d" ,"mfg_sel" ,0 )
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 164/255 dmaengine: ioat: stop mod_timer from resurrecting deleted timer in __cleanup()
In reply to Greg Kroah-HartmanFrom: Dave Jiang <[email protected]>
[ Upstream commit 898ec89dbb55b8294695ad71694a0684e62b2a73 ]
User reports observing timer event report channel halted but no error observed in CHANERR register. The driver finished self-test and released channel resources. Debug shows that __cleanup() can call mod_timer() after the timer has been deleted and thus resurrect the timer. While harmless, it causes suprious error message to be emitted. Use mod_timer_pending() call to prevent deleted timer from being resurrected.
--- drivers/dma/ioat/dma.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/dma/ioat/dma.c +3 -3
@@ -653,7 +653,7 @@ static void __cleanup(struct ioatdma_chan *ioat_chan, dma_addr_t phys_complete)if (active - i ==0 ) {dev_dbg (to_dev (ioat_chan),"%s: cancel completion timeout\n" , __func__); -mod_timer (&ioat_chan->timer, jiffies +IDLE_TIMEOUT ); +mod_timer_pending (&ioat_chan->timer, jiffies +IDLE_TIMEOUT ); }/* microsecond delay by sysfs variable per pending descriptor */
@@ -679,7 +679,7 @@ static void ioat_cleanup(struct ioatdma_chan *ioat_chan)if (chanerr & (IOAT_CHANERR_HANDLE_MASK |IOAT_CHANERR_RECOVER_MASK )) { -mod_timer (&ioat_chan->timer, jiffies +IDLE_TIMEOUT ); +mod_timer_pending (&ioat_chan->timer, jiffies +IDLE_TIMEOUT );ioat_eh (ioat_chan); } }
@@ -876,7 +876,7 @@ static void check_active(struct ioatdma_chan *ioat_chan) }if (test_and_clear_bit (IOAT_CHAN_ACTIVE , &ioat_chan->state)) -mod_timer (&ioat_chan->timer, jiffies +IDLE_TIMEOUT ); +mod_timer_pending (&ioat_chan->timer, jiffies +IDLE_TIMEOUT ); }void ioat_timer_event (struct timer_list *t)
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 165/255 spmi: pmic-arb: correct duplicate APID to PPID mapping logic
In reply to Greg Kroah-HartmanFrom: David Collins <[email protected]>
[ Upstream commit 1f1693118c2476cb1666ad357edcf3cf48bf9b16 ]
Correct the way that duplicate PPID mappings are handled for PMIC arbiter v5. The final APID mapped to a given PPID should be the one which has write owner = APPS EE, if it exists, or if not that, then the first APID mapped to the PPID, if it exists.
--- drivers/spmi/spmi-pmic-arb.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-)
drivers/spmi/spmi-pmic-arb.c +7 -6
@@ -887,7 +887,8 @@ static int pmic_arb_read_apid_map_v5(struct spmi_pmic_arb *pmic_arb)* version 5, there is more than one APID mapped to each PPID. * The owner field for each of these mappings specifies the EE which is * allowed to write to the APID. The owner of the last (highest) APID -* for a given PPID will receive interrupts from the PPID. +* which has the IRQ owner bit set for a given PPID will receive +* interrupts from the PPID. */ for (i =0 ; ; i++, apidd++) { offset = pmic_arb->ver_ops->apid_map_offset (i);
@@ -910,16 +911,16 @@ static int pmic_arb_read_apid_map_v5(struct spmi_pmic_arb *pmic_arb) apid = pmic_arb->ppid_to_apid[ppid] & ~PMIC_ARB_APID_VALID ; prev_apidd = &pmic_arb->apid_data[apid]; -if (valid && is_irq_ee && - prev_apidd->write_ee == pmic_arb->ee) { +if (!valid || apidd->write_ee == pmic_arb->ee) { +/* First PPID mapping or one for this EE */ + pmic_arb->ppid_to_apid[ppid] = i |PMIC_ARB_APID_VALID ; + }else if (valid && is_irq_ee && + prev_apidd->write_ee == pmic_arb->ee) {/* * Duplicate PPID mapping after the one for this EE; * override the irq owner */ prev_apidd->irq_ee = apidd->irq_ee; - }else if (!valid || is_irq_ee) { -/* First PPID mapping or duplicate for another EE */ - pmic_arb->ppid_to_apid[ppid] = i |PMIC_ARB_APID_VALID ; } apidd->ppid = ppid;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 166/255 clk: bcm2835: fix bcm2835_clock_rate_from_divisor declaration
In reply to Greg Kroah-HartmanFrom: Stefan Wahren <[email protected]>
[ Upstream commit 0b919a3728691c172312dee99ba654055ccd8c84 ]
The return value of bcm2835_clock_rate_from_divisor is always unsigned and also all caller expect this. So fix the declaration accordingly.
--- drivers/clk/bcm/clk-bcm2835.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/clk/bcm/clk-bcm2835.c +3 -3
@@ -967,9 +967,9 @@ static u32 bcm2835_clock_choose_div(struct clk_hw *hw,return div; } -static long bcm2835_clock_rate_from_divisor (struct bcm2835_clock *clock, -unsigned long parent_rate, -u32 div) +static unsigned long bcm2835_clock_rate_from_divisor (struct bcm2835_clock *clock, +unsigned long parent_rate, +u32 div) {const struct bcm2835_clock_data *data = clock->data;u64 temp;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 167/255 clk: ti: dra7-atl: Fix reference leak in of_dra7_atl_clk_probe
In reply to Greg Kroah-HartmanFrom: Miaoqian Lin <[email protected]>
[ Upstream commit 9c59a01caba26ec06fefd6ca1f22d5fd1de57d63 ]
pm_runtime_get_sync() will increment pm usage counter. Forgetting to putting operation will result in reference leak. Add missing pm_runtime_put_sync in some error paths.
--- drivers/clk/ti/clk-dra7-atl.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/clk/ti/clk-dra7-atl.c +6 -3
@@ -252,14 +252,16 @@ static int of_dra7_atl_clk_probe(struct platform_device *pdev)if (rc) {pr_err ("%s: failed to lookup atl clock %d\n" , __func__, i); -return -EINVAL ; + ret = -EINVAL ; + goto pm_put; } clk =of_clk_get_from_provider (&clkspec);if (IS_ERR (clk)) {pr_err ("%s: failed to get atl clock %d from provider\n" , __func__, i); -return PTR_ERR (clk); + ret =PTR_ERR (clk); + goto pm_put; } cdesc =to_atl_desc (__clk_get_hw (clk));
@@ -292,8 +294,9 @@ static int of_dra7_atl_clk_probe(struct platform_device *pdev)if (cdesc->enabled)atl_clk_enable (__clk_get_hw (clk)); } -pm_runtime_put_sync (cinfo->dev); +pm_put: +pm_runtime_put_sync (cinfo->dev);return ret; }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 168/255 clk: ast2600: BCLK comes from EPLL
In reply to Greg Kroah-HartmanFrom: Joel Stanley <[email protected]>
[ Upstream commit b8c1dc9c00b252b3be853720a71b05ed451ddd9f ]
This correction was made in the u-boot SDK recently. There are no in-tree users of this clock so the impact is minimal.
--- drivers/clk/clk-ast2600.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/clk-ast2600.c +1 -1
@@ -579,7 +579,7 @@ static int aspeed_g6_clk_probe(struct platform_device *pdev)regmap_write (map,0x308 ,0x12000 );/* 3x3 = 9 */ /* P-Bus (BCLK) clock divider */ - hw =clk_hw_register_divider_table (dev,"bclk" ,"hpll" ,0 , + hw =clk_hw_register_divider_table (dev,"bclk" ,"epll" ,0 , scu_g6_base +ASPEED_G6_CLK_SELECTION1 ,20 ,3 ,0 , ast2600_div_table, &aspeed_g6_clk_lock);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 169/255 mailbox: bcm-ferxrm-mailbox: Fix error check for dma_map_sg
In reply to Greg Kroah-HartmanFrom: Jack Wang <[email protected]>
[ Upstream commit 6b207ce8a96a71e966831e3a13c38143ba9a73c1 ]
dma_map_sg return 0 on error, fix the error check, and return -EIO to caller.
--- drivers/mailbox/bcm-flexrm-mailbox.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/mailbox/bcm-flexrm-mailbox.c +4 -4
@@ -632,15 +632,15 @@ static int flexrm_spu_dma_map(struct device *dev, struct brcm_message *msg) rc =dma_map_sg (dev, msg->spu.src,sg_nents (msg->spu.src),DMA_TO_DEVICE ); -if (rc <0 ) -return rc; +if (!rc) +return -EIO ; rc =dma_map_sg (dev, msg->spu.dst,sg_nents (msg->spu.dst),DMA_FROM_DEVICE ); -if (rc <0 ) { +if (!rc) {dma_unmap_sg (dev, msg->spu.src,sg_nents (msg->spu.src),DMA_TO_DEVICE ); -return rc; +return -EIO ; }return 0 ;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 170/255 powerpc/math_emu/efp: Include module.h
In reply to Greg Kroah-HartmanFrom: Nathan Chancellor <[email protected]>
[ Upstream commit cfe0d370e0788625ce0df3239aad07a2506c1796 ]
When building with a recent version of clang, there are a couple of errors around the call to module_init():
arch/powerpc/math-emu/math_efp.c:927:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int] module_init(spe_mathemu_init);
^
int
arch/powerpc/math-emu/math_efp.c:927:13: error: a parameter list without types is only allowed in a function definition
module_init(spe_mathemu_init);
^2 errors generated.
module_init() is a macro, which is not getting expanded because module.h is not included in this file. Add the include so that the macro can expand properly, clearing up the build failure.
--- arch/powerpc/math-emu/math_efp.c | 1 + 1 file changed, 1 insertion(+)
arch/powerpc/math-emu/math_efp.c +1 -0
@@ -17,6 +17,7 @@#include <linux/types.h> #include <linux/prctl.h> +#include <linux/module.h> #include <linux/uaccess.h> #include <asm/reg.h>
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 171/255 powerpc/sysdev/fsl_msi: Add missing of_node_put()
In reply to Greg Kroah-HartmanFrom: Liang He <[email protected]>
[ Upstream commit def435c04ee984a5f9ed2711b2bfe946936c6a21 ]
In fsl_setup_msi_irqs(), use of_node_put() to drop the reference returned by of_parse_phandle().
--- arch/powerpc/sysdev/fsl_msi.c | 2 ++ 1 file changed, 2 insertions(+)
arch/powerpc/sysdev/fsl_msi.c +2 -0
@@ -211,8 +211,10 @@ static int fsl_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)dev_err (&pdev->dev,"node %pOF has an invalid fsl,msi phandle %u\n" , hose->dn, np->phandle); +of_node_put (np);return -EINVAL ; } +of_node_put (np); }for_each_pci_msi_entry (entry, pdev) {
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 172/255 powerpc/pci_dn: Add missing of_node_put()
In reply to Greg Kroah-HartmanFrom: Liang He <[email protected]>
[ Upstream commit 110a1fcb6c4d55144d8179983a475f17a1d6f832 ]
In pci_add_device_node_info(), use of_node_put() to drop the reference to 'parent' returned by of_get_parent() to keep refcount balance.
--- arch/powerpc/kernel/pci_dn.c | 1 + 1 file changed, 1 insertion(+)
arch/powerpc/kernel/pci_dn.c +1 -0
@@ -325,6 +325,7 @@ struct pci_dn *pci_add_device_node_info(struct pci_controller *hose,INIT_LIST_HEAD (&pdn->list); parent =of_get_parent (dn); pdn->parent = parent ?PCI_DN (parent) :NULL ; +of_node_put (parent);if (pdn->parent)list_add_tail (&pdn->list, &pdn->parent->child_list);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 173/255 powerpc/powernv: add missing of_node_put() in opal_export_attrs()
In reply to Greg Kroah-HartmanFrom: Zheng Yongjun <[email protected]>
[ Upstream commit 71a92e99c47900cc164620948b3863382cec4f1a ]
After using 'np' returned by of_find_node_by_path(), of_node_put() need be called to decrease the refcount.
--- arch/powerpc/platforms/powernv/opal.c | 1 + 1 file changed, 1 insertion(+)
arch/powerpc/platforms/powernv/opal.c +1 -0
@@ -776,6 +776,7 @@ static void opal_export_attrs(void) kobj =kobject_create_and_add ("exports" , opal_kobj);if (!kobj) {pr_warn ("kobject_create_and_add() of exports failed\n" ); +of_node_put (np);return ; }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 174/255 x86/hyperv: Fix struct hv_enlightened_vmcs definition
In reply to Greg Kroah-HartmanFrom: Vitaly Kuznetsov <[email protected]>
[ Upstream commit ea9da788a61e47e7ab9cbad397453e51cd82ac0d ]
Section 1.9 of TLFS v6.0b says:
"All structures are padded in such a way that fields are aligned naturally (that is, an 8-byte field is aligned to an offset of 8 bytes and so on)".
'struct enlightened_vmcs' has a glitch:
...
struct {
u32 nested_flush_hypercall:1; /* 836: 0 4 */
u32 msr_bitmap:1; /* 836: 1 4 */
u32 reserved:30; /* 836: 2 4 */
} hv_enlightenments_control; /* 836 4 */
u32 hv_vp_id; /* 840 4 */
u64 hv_vm_id; /* 844 8 */
u64 partition_assist_page; /* 852 8 */...
And the observed values in 'partition_assist_page' make no sense at all. Fix the layout by padding the structure properly.
--- arch/x86/include/asm/hyperv-tlfs.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/x86/include/asm/hyperv-tlfs.h +2 -2
@@ -721,7 +721,7 @@ struct hv_enlightened_vmcs {u64 guest_rip;u32 hv_clean_fields; -u32 hv_padding_32; +u32 padding32_1;u32 hv_synthetic_controls;struct {u32 nested_flush_hypercall:1 ;
@@ -729,7 +729,7 @@ struct hv_enlightened_vmcs { u32 reserved:30; }__packed hv_enlightenments_control;u32 hv_vp_id; - +u32 padding32_2;u64 hv_vm_id;u64 partition_assist_page;u64 padding64_4[4 ];
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 175/255 powerpc/64s: Fix GENERIC_CPU build flags for PPC970 / G5
In reply to Greg Kroah-HartmanFrom: Nicholas Piggin <[email protected]>
[ Upstream commit 58ec7f06b74e0d6e76c4110afce367c8b5f0837d ]
Big-endian GENERIC_CPU supports 970, but builds with -mcpu=power5. POWER5 is ISA v2.02 whereas 970 is v2.01 plus Altivec. 2.02 added the popcntb instruction which a compiler might use.
Use -mcpu=power4.
--- arch/powerpc/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/Makefile +1 -1
@@ -155,7 +155,7 @@ CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=power8 CFLAGS-$(CONFIG_GENERIC_CPU) += $(call cc-option,-mtune=power9,-mtune=power8) else CFLAGS-$(CONFIG_GENERIC_CPU) += $(call cc-option,-mtune=power7,$(call cc-option,-mtune=power5)) -CFLAGS-$(CONFIG_GENERIC_CPU) += $(call cc-option,-mcpu=power5,-mcpu=power4) +CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=power4 endif else ifdef CONFIG_PPC_BOOK3E_64 CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=powerpc64
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 176/255 powerpc: Fix SPE Power ISA properties for e500v1 platforms
In reply to Greg Kroah-HartmanFrom: Pali Rohár <[email protected]>
[ Upstream commit 37b9345ce7f4ab17538ea62def6f6d430f091355 ]
Commit 2eb28006431c ("powerpc/e500v2: Add Power ISA properties to comply with ePAPR 1.1") introduced new include file e500v2_power_isa.dtsi and should have used it for all e500v2 platforms. But apparently it was used also for e500v1 platforms mpc8540, mpc8541, mpc8555 and mpc8560.
e500v1 cores compared to e500v2 do not support double precision floating point SPE instructions. Hence power-isa-sp.fd should not be set on e500v1 platforms, which is in e500v2_power_isa.dtsi include file.
Fix this issue by introducing a new e500v1_power_isa.dtsi include file and use it in all e500v1 device tree files.
--- .../boot/dts/fsl/e500v1_power_isa.dtsi | 51 +++++++++++++++++++ arch/powerpc/boot/dts/fsl/mpc8540ads.dts | 2 +- arch/powerpc/boot/dts/fsl/mpc8541cds.dts | 2 +- arch/powerpc/boot/dts/fsl/mpc8555cds.dts | 2 +- arch/powerpc/boot/dts/fsl/mpc8560ads.dts | 2 +- 5 files changed, 55 insertions(+), 4 deletions(-) create mode 100644 arch/powerpc/boot/dts/fsl/e500v1_power_isa.dtsi
arch/powerpc/boot/dts/fsl/e500v1_power_isa.dtsi new file +51 -0
@@ -0,0 +1,51 @@ +/* + * e500v1 Power ISA Device Tree Source (include) + * + * Copyright 2012 Freescale Semiconductor Inc. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions are met: + * * Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * * Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * * Neither the name of Freescale Semiconductor nor the + * names of its contributors may be used to endorse or promote products + * derived from this software without specific prior written permission. + * + * + * ALTERNATIVELY, this software may be distributed under the terms of the + * GNU General Public License ("GPL") as published by the Free Software + * Foundation, either version 2 of that License or (at your option) any + * later version. + * + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +/ { + cpus { + power-isa-version = "2.03"; + power-isa-b; // Base + power-isa-e; // Embedded + power-isa-atb; // Alternate Time Base + power-isa-cs; // Cache Specification + power-isa-e.le; // Embedded.Little-Endian + power-isa-e.pm; // Embedded.Performance Monitor + power-isa-ecl; // Embedded Cache Locking + power-isa-mmc; // Memory Coherence + power-isa-sp; // Signal Processing Engine + power-isa-sp.fs; // SPE.Embedded Float Scalar Single + power-isa-sp.fv; // SPE.Embedded Float Vector + mmu-type = "power-embedded"; + }; +};
arch/powerpc/boot/dts/fsl/mpc8540ads.dts +1 -1
@@ -7,7 +7,7 @@ /dts-v1/; -/include/ "e500v2_power_isa.dtsi" +/include/ "e500v1_power_isa.dtsi" / { model = "MPC8540ADS";
arch/powerpc/boot/dts/fsl/mpc8541cds.dts +1 -1
@@ -7,7 +7,7 @@ /dts-v1/; -/include/ "e500v2_power_isa.dtsi" +/include/ "e500v1_power_isa.dtsi" / { model = "MPC8541CDS";
arch/powerpc/boot/dts/fsl/mpc8555cds.dts +1 -1
@@ -7,7 +7,7 @@ /dts-v1/; -/include/ "e500v2_power_isa.dtsi" +/include/ "e500v1_power_isa.dtsi" / { model = "MPC8555CDS";
arch/powerpc/boot/dts/fsl/mpc8560ads.dts +1 -1
@@ -7,7 +7,7 @@ /dts-v1/; -/include/ "e500v2_power_isa.dtsi" +/include/ "e500v1_power_isa.dtsi" / { model = "MPC8560ADS";
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 177/255 cgroup/cpuset: Enable update_tasks_cpumask() on top_cpuset
In reply to Greg Kroah-HartmanFrom: Waiman Long <[email protected]>
[ Upstream commit ec5fbdfb99d18482619ac42605cb80fbb56068ee ]
Previously, update_tasks_cpumask() is not supposed to be called with top cpuset. With cpuset partition that takes CPUs away from the top cpuset, adjusting the cpus_mask of the tasks in the top cpuset is necessary. Percpu kthreads, however, are ignored.
--- kernel/cgroup/cpuset.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-)
kernel/cgroup/cpuset.c +11 -7
@@ -33,6 +33,7 @@#include <linux/interrupt.h> #include <linux/kernel.h> #include <linux/kmod.h> +#include <linux/kthread.h> #include <linux/list.h> #include <linux/mempolicy.h> #include <linux/mm.h>
@@ -1057,10 +1058,18 @@ static void update_tasks_cpumask(struct cpuset *cs) {struct css_task_iter it;struct task_struct *task; +bool top_cs = cs == &top_cpuset;css_task_iter_start (&cs->css,0 , &it); -while ((task =css_task_iter_next (&it))) +while ((task =css_task_iter_next (&it))) { +/* +* Percpu kthreads in top_cpuset are ignored +*/ +if (top_cs && (task->flags &PF_KTHREAD ) && +kthread_is_per_cpu (task)) +continue ;set_cpus_allowed_ptr (task, cs->effective_cpus); + }css_task_iter_end (&it); }
@@ -2014,12 +2023,7 @@ static int update_prstate(struct cpuset *cs, int val)update_flag (CS_CPU_EXCLUSIVE , cs,0 ); } -/* -* Update cpumask of parent's tasks except when it is the top -* cpuset as some system daemons cannot be mapped to other CPUs. -*/ -if (parent != &top_cpuset) -update_tasks_cpumask (parent); +update_tasks_cpumask (parent);if (parent->child_ecpus_count)update_sibling_cpumasks (parent, cs, &tmp);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 178/255 iommu/omap: Fix buffer overflow in debugfs
In reply to Greg Kroah-HartmanFrom: Dan Carpenter <[email protected]>
[ Upstream commit 184233a5202786b20220acd2d04ddf909ef18f29 ]
There are two issues here:
1) The "len" variable needs to be checked before the very first write. Otherwise if omap2_iommu_dump_ctx() with "bytes" less than 32 it is a buffer overflow.
2) The snprintf() function returns the number of bytes that *would* have been copied if there were enough space. But we want to know the number of bytes which were *actually* copied so use scnprintf() instead.
--- drivers/iommu/omap-iommu-debug.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/iommu/omap-iommu-debug.c +3 -3
@@ -32,12 +32,12 @@ static inline bool is_omap_iommu_detached(struct omap_iommu *obj)ssize_t bytes; \const char *str ="%20s: %08x\n" ; \const int maxcol =32 ; \ - bytes =snprintf (p, maxcol, str,__stringify (name), \ +if (len < maxcol) \ + goto out; \ + bytes =scnprintf (p, maxcol, str,__stringify (name), \ iommu_read_reg(obj, MMU_##name)); \ p += bytes; \ len -= bytes; \ -if (len < maxcol) \ - goto out; \ }while (0 ) static ssize_t
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 179/255 crypto: akcipher - default implementation for setting a private key
In reply to Greg Kroah-HartmanFrom: Ignat Korchagin <[email protected]>
[ Upstream commit bc155c6c188c2f0c5749993b1405673d25a80389 ]
Changes from v1:
* removed the default implementation from set_pub_key: it is assumed that an implementation must always have this callback defined as there are no use case for an algorithm, which doesn't need a public key
Many akcipher implementations (like ECDSA) support only signature verifications, so they don't have all callbacks defined.
Commit 78a0324f4a53 ("crypto: akcipher - default implementations for request callbacks") introduced default callbacks for sign/verify operations, which just return an error code.
However, these are not enough, because before calling sign the caller would likely call set_priv_key first on the instantiated transform (as the in-kernel testmgr does). This function does not have a default stub, so the kernel crashes, when trying to set a private key on an akcipher, which doesn't support signature generation.
I've noticed this, when trying to add a KAT vector for ECDSA signature to the testmgr.
With this patch the testmgr returns an error in dmesg (as it should) instead of crashing the kernel NULL ptr dereference.
--- crypto/akcipher.c | 8 ++++++++ 1 file changed, 8 insertions(+)
crypto/akcipher.c +8 -0
@@ -119,6 +119,12 @@ static int akcipher_default_op(struct akcipher_request *req)return -ENOSYS ; } +static int akcipher_default_set_key (struct crypto_akcipher *tfm, +const void *key,unsigned int keylen) +{ +return -ENOSYS ; +} +int crypto_register_akcipher (struct akcipher_alg *alg) {struct crypto_alg *base = &alg->base;
@@ -131,6 +137,8 @@ int crypto_register_akcipher(struct akcipher_alg *alg) alg->encrypt = akcipher_default_op;if (!alg->decrypt) alg->decrypt = akcipher_default_op; +if (!alg->set_priv_key) + alg->set_priv_key = akcipher_default_set_key;akcipher_prepare_alg (alg);return crypto_register_alg (base);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 180/255 crypto: ccp - Release dma channels before dmaengine unrgister
In reply to Greg Kroah-HartmanFrom: Koba Ko <[email protected]>
[ Upstream commit 68dbe80f5b510c66c800b9e8055235c5b07e37d1 ]
A warning is shown during shutdown,
__dma_async_device_channel_unregister called while 2 clients hold a reference
WARNING: CPU: 15 PID: 1 at drivers/dma/dmaengine.c:1110 __dma_async_device_channel_unregister+0xb7/0xc0
Call dma_release_channel for occupied channles before dma_async_device_unregister.
--- drivers/crypto/ccp/ccp-dmaengine.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/crypto/ccp/ccp-dmaengine.c +5 -1
@@ -642,6 +642,10 @@ static void ccp_dma_release(struct ccp_device *ccp)for (i =0 ; i < ccp->cmd_q_count; i++) { chan = ccp->ccp_dma_chan + i; dma_chan = &chan->dma_chan; + +if (dma_chan->client_count) +dma_release_channel (dma_chan); +tasklet_kill (&chan->cleanup_tasklet);list_del_rcu (&dma_chan->device_node); }
@@ -767,8 +771,8 @@ void ccp_dmaengine_unregister(struct ccp_device *ccp)if (!dmaengine)return ; -dma_async_device_unregister (dma_dev);ccp_dma_release (ccp); +dma_async_device_unregister (dma_dev);kmem_cache_destroy (ccp->dma_desc_cache);kmem_cache_destroy (ccp->dma_cmd_cache);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 181/255 iommu/iova: Fix module config properly
In reply to Greg Kroah-HartmanFrom: Robin Murphy <[email protected]>
[ Upstream commit 4f58330fcc8482aa90674e1f40f601e82f18ed4a ]
IOMMU_IOVA is intended to be an optional library for users to select as and when they desire. Since it can be a module now, this means that built-in code which has chosen not to select it should not fail to link if it happens to have selected as a module by someone else. Replace IS_ENABLED() with IS_REACHABLE() to do the right thing.
--- include/linux/iova.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/iova.h +1 -1
@@ -132,7 +132,7 @@ static inline unsigned long iova_pfn(struct iova_domain *iovad, dma_addr_t iova)return iova >>iova_shift (iovad); } -#if IS_ENABLED (CONFIG_IOMMU_IOVA ) +#if IS_REACHABLE (CONFIG_IOMMU_IOVA )int iova_cache_get (void );void iova_cache_put (void );
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 182/255 kbuild: remove the target in signal traps when interrupted
In reply to Greg Kroah-HartmanFrom: Masahiro Yamada <[email protected]>
[ Upstream commit a7f3257da8a86b96fb9bf1bba40ae0bbd7f1885a ]
When receiving some signal, GNU Make automatically deletes the target if it has already been changed by the interrupted recipe.
If the target is possibly incomplete due to interruption, it must be deleted so that it will be remade from scratch on the next run of make. Otherwise, the target would remain corrupted permanently because its timestamp had already been updated.
Thanks to this behavior of Make, you can stop the build any time by pressing Ctrl-C, and just run 'make' to resume it.
Kbuild also relies on this feature, but it is equivalently important for any build systems that make decisions based on timestamps (if you want to support Ctrl-C reliably).
However, this does not always work as claimed; Make immediately dies with Ctrl-C if its stderr goes into a pipe.
[Test Makefile]
foo:
echo hello > $@
sleep 3
echo world >> $@
[Test Result]
$ make # hit Ctrl-C
echo hello > foo
sleep 3
^Cmake: *** Deleting file 'foo'
make: *** [Makefile:3: foo] Interrupt $ make 2>&1 | cat # hit Ctrl-C
echo hello > foo
sleep 3
^C$ # 'foo' is often left-overThe reason is because SIGINT is sent to the entire process group. In this example, SIGINT kills 'cat', and 'make' writes the message to the closed pipe, then dies with SIGPIPE before cleaning the target.
A typical bad scenario (as reported by [1], [2]) is to save build log by using the 'tee' command:
$ make 2>&1 | tee log
This can be problematic for any build systems based on Make, so I hope it will be fixed in GNU Make. The maintainer of GNU Make stated this is a long-standing issue and difficult to fix [3]. It has not been fixed yet as of writing.
So, we cannot rely on Make cleaning the target. We can do it by ourselves, in signal traps.
As far as I understand, Make takes care of SIGHUP, SIGINT, SIGQUIT, and SITERM for the target removal. I added the traps for them, and also for SIGPIPE just in case cmd_* rule prints something to stdout or stderr (but I did not observe an actual case where SIGPIPE was triggered).
[Note 1]
The trap handler might be worth explaining.
rm -f $@; trap - $(sig); kill -s $(sig) $$
This lets the shell kill itself by the signal it caught, so the parent process can tell the child has exited on the signal. Generally, this is a proper manner for handling signals, in case the calling program (like Bash) may monitor WIFSIGNALED() and WTERMSIG() for WCE although this may not be a big deal here because GNU Make handles SIGHUP, SIGINT, SIGQUIT in WUE and SIGTERM in IUE.
IUE - Immediate Unconditional Exit
WUE - Wait and Unconditional Exit
WCE - Wait and Cooperative Exit
For details, see "Proper handling of SIGINT/SIGQUIT" [4].
[Note 2]
Reverting 392885ee82d3 ("kbuild: let fixdep directly write to .*.cmd files") would directly address [1], but it only saves if_changed_dep. As reported in [2], all commands that use redirection can potentially leave an empty (i.e. broken) target.
[Note 3]
Another (even safer) approach might be to always write to a temporary file, and rename it to $@ at the end of the recipe.
<command> > $(tmp-target) mv $(tmp-target) $@
It would require a lot of Makefile changes, and result in ugly code, so I did not take it.
[Note 4]
A little more thoughts about a pattern rule with multiple targets (or a grouped target).
%.x %.y: %.z
<recipe>When interrupted, GNU Make deletes both %.x and %.y, while this solution only deletes $@. Probably, this is not a big deal. The next run of make will execute the rule again to create $@ along with the other files.
[1]: https://lore.kernel.org/all/[email protected]/
[2]: https://lore.kernel.org/all/[email protected]/
[3]: https://lists.gnu.org/archive/html/help-make/2021-06/msg00001.html
[4]: https://www.cons.org/cracauer/sigint.html
--- scripts/Kbuild.include | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-)
scripts/Kbuild.include +22 -1
@@ -187,8 +187,29 @@ echo-cmd = $(if $($(quiet)cmd_$(1)),\ quiet_redirect := silent_redirect := exec >/dev/null; +# Delete the target on interruption +# +# GNU Make automatically deletes the target if it has already been changed by +# the interrupted recipe. So, you can safely stop the build by Ctrl-C (Make +# will delete incomplete targets), and resume it later. +# +# However, this does not work when the stderr is piped to another program, like +# $ make >&2 | tee log +# Make dies with SIGPIPE before cleaning the targets. +# +# To address it, we clean the target in signal traps. +# +# Make deletes the target when it catches SIGHUP, SIGINT, SIGQUIT, SIGTERM. +# So, we cover them, and also SIGPIPE just in case. +# +# Of course, this is unneeded for phony targets. +delete-on-interrupt = \ + $(if $(filter-out $(PHONY), $@), \ + $(foreach sig, HUP INT QUIT TERM PIPE, \ + trap 'rm -f $@; trap - $(sig); kill -s $(sig) $$$$' $(sig);)) + # printing commands -cmd = @set -e; $(echo-cmd) $($(quiet)redirect) $(cmd_$(1)) +cmd = @set -e; $(echo-cmd) $($(quiet)redirect) $(delete-on-interrupt) $(cmd_$(1)) ### # if_changed - execute command if any prerequisite is newer than
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 183/255 crypto: cavium - prevent integer overflow loading firmware
In reply to Greg Kroah-HartmanFrom: Dan Carpenter <[email protected]>
[ Upstream commit 2526d6bf27d15054bb0778b2f7bc6625fd934905 ]
The "code_length" value comes from the firmware file. If your firmware is untrusted realistically there is probably very little you can do to protect yourself. Still we try to limit the damage as much as possible. Also Smatch marks any data read from the filesystem as untrusted and prints warnings if it not capped correctly.
The "ntohl(ucode->code_length) * 2" multiplication can have an integer overflow.
--- drivers/crypto/cavium/cpt/cptpf_main.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/crypto/cavium/cpt/cptpf_main.c +4 -2
@@ -254,6 +254,7 @@ static int cpt_ucode_load_fw(struct cpt_device *cpt, const u8 *fw, bool is_ae)const struct firmware *fw_entry;struct device *dev = &cpt->pdev->dev;struct ucode_header *ucode; +unsigned int code_length;struct microcode *mcode;int j, ret =0 ;
@@ -264,11 +265,12 @@ static int cpt_ucode_load_fw(struct cpt_device *cpt, const u8 *fw, bool is_ae) ucode = (struct ucode_header *)fw_entry->data; mcode = &cpt->mcode[cpt->next_mc_idx];memcpy (mcode->version, (u8 *)fw_entry->data,CPT_UCODE_VERSION_SZ ); - mcode->code_size =ntohl (ucode->code_length) *2 ; -if (!mcode->code_size) { + code_length =ntohl (ucode->code_length); +if (code_length ==0 || code_length >=INT_MAX /2 ) { ret = -EINVAL ; goto fw_release; } + mcode->code_size = code_length *2 ; mcode->is_ae = is_ae; mcode->core_mask =0ULL ;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 184/255 f2fs: fix race condition on setting FI_NO_EXTENT flag
In reply to Greg Kroah-HartmanFrom: Zhang Qilong <[email protected]>
[ Upstream commit 07725adc55c0a414c10acb5c8c86cea34b95ddef ]
The following scenarios exist.
process A: process B:
->f2fs_drop_extent_tree ->f2fs_update_extent_cache_range
->f2fs_update_extent_tree_range
->write_lock
->set_inode_flag
->is_inode_flag_set
->__free_extent_tree // Shouldn't
// have been
// cleaned up
// here->write_lock
In this case, the "FI_NO_EXTENT" flag is set between f2fs_update_extent_tree_range and is_inode_flag_set by other process. it leads to clearing the whole exten tree which should not have happened. And we fix it by move the setting it to the range of write_lock.
--- fs/f2fs/extent_cache.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
fs/f2fs/extent_cache.c +1 -2
@@ -729,9 +729,8 @@ void f2fs_drop_extent_tree(struct inode *inode)if (!f2fs_may_extent_tree (inode))return ; -set_inode_flag (inode,FI_NO_EXTENT ); -write_lock (&et->lock); +set_inode_flag (inode,FI_NO_EXTENT );__free_extent_tree (sbi, et);if (et->largest.len) { et->largest.len =0 ;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 185/255 ACPI: video: Add Toshiba Satellite/Portege Z830 quirk
In reply to Greg Kroah-HartmanFrom: Arvid Norlander <[email protected]>
[ Upstream commit 574160b8548deff8b80b174f03201e94ab8431e2 ]
Toshiba Satellite Z830 needs the quirk video_disable_backlight_sysfs_if for proper backlight control after suspend/resume cycles.
Toshiba Portege Z830 is simply the same laptop rebranded for certain markets (I looked through the manual to other language sections to confirm this) and thus also needs this quirk.
Thanks to Hans de Goede for suggesting this fix.
--- drivers/acpi/acpi_video.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
drivers/acpi/acpi_video.c +16 -0
@@ -498,6 +498,22 @@ static const struct dmi_system_id video_dmi_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "SATELLITE R830"), }, }, + { + .callback = video_disable_backlight_sysfs_if, + .ident = "Toshiba Satellite Z830", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"), + DMI_MATCH(DMI_PRODUCT_NAME, "SATELLITE Z830"), + }, + }, + { + .callback = video_disable_backlight_sysfs_if, + .ident = "Toshiba Portege Z830", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"), + DMI_MATCH(DMI_PRODUCT_NAME, "PORTEGE Z830"), + }, + }, /* * Some machine's _DOD IDs don't have bit 31(Device ID Scheme) set * but the IDs actually follow the Device ID Scheme.
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 186/255 MIPS: BCM47XX: Cast memcmp() of function to (void *)
In reply to Greg Kroah-HartmanFrom: Kees Cook <[email protected]>
[ Upstream commit 0dedcf6e3301836eb70cfa649052e7ce4fcd13ba ]
Clang is especially sensitive about argument type matching when using __overloaded functions (like memcmp(), etc). Help it see that function pointers are just "void *". Avoids this error:
arch/mips/bcm47xx/prom.c:89:8: error: no matching function for call to 'memcmp'
if (!memcmp(prom_init, prom_init + mem, 32))
^~~~~~include/linux/string.h:156:12: note: candidate function not viable: no known conversion from 'void (void)' to 'const void *' for 1st argument extern int memcmp(const void *,const void *,__kernel_size_t);
--- arch/mips/bcm47xx/prom.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/mips/bcm47xx/prom.c +2 -2
@@ -85,7 +85,7 @@ static __init void prom_init_mem(void)pr_debug ("Assume 128MB RAM\n" );break ; } -if (!memcmp (prom_init, prom_init + mem,32 )) +if (!memcmp ((void *)prom_init, (void *)prom_init + mem,32 ))break ; } lowmem = mem;
@@ -162,7 +162,7 @@ void __init bcm47xx_prom_highmem_init(void) off =EXTVBASE +__pa (off);for (extmem =128 <<20 ; extmem <512 <<20 ; extmem <<=1 ) { -if (!memcmp (prom_init, (void *)(off + extmem),16 )) +if (!memcmp ((void *)prom_init, (void *)(off + extmem),16 ))break ; } extmem -= lowmem;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 187/255 powercap: intel_rapl: fix UBSAN shift-out-of-bounds issue
In reply to Greg Kroah-HartmanFrom: Chao Qin <[email protected]>
[ Upstream commit 2d93540014387d1c73b9ccc4d7895320df66d01b ]
When value < time_unit, the parameter of ilog2() will be zero and the return value is -1. u64(-1) is too large for shift exponent and then will trigger shift-out-of-bounds:
shift exponent 18446744073709551615 is too large for 32-bit type 'int'
Call Trace: rapl_compute_time_window_core rapl_write_data_raw set_time_window store_constraint_time_window_us
--- drivers/powercap/intel_rapl_common.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/powercap/intel_rapl_common.c +3 -0
@@ -885,6 +885,9 @@ static u64 rapl_compute_time_window_core(struct rapl_package *rp, u64 value, y = value &0x1f ; value = (1 << y) * (4 + f) * rp->time_unit /4 ; }else { +if (value < rp->time_unit) +return 0 ; +do_div (value, rp->time_unit); y =ilog2 (value); f =div64_u64 (4 * (value - (1 << y)),1 << y);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 188/255 thermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crash
In reply to Greg Kroah-HartmanFrom: Srinivas Pandruvada <[email protected]>
[ Upstream commit 68b99e94a4a2db6ba9b31fe0485e057b9354a640 ]
When CPU 0 is offline and intel_powerclamp is used to inject idle, it generates kernel BUG:
BUG: using smp_processor_id() in preemptible [00000000] code: bash/15687 caller is debug_smp_processor_id+0x17/0x20 CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57 Call Trace: <TASK> dump_stack_lvl+0x49/0x63 dump_stack+0x10/0x16 check_preemption_disabled+0xdd/0xe0 debug_smp_processor_id+0x17/0x20 powerclamp_set_cur_state+0x7f/0xf9 [intel_powerclamp]
...
...
Here CPU 0 is the control CPU by default and changed to the current CPU, if CPU 0 offlined. This check has to be performed under cpus_read_lock(), hence the above warning.
Use get_cpu() instead of smp_processor_id() to avoid this BUG.
--- drivers/thermal/intel/intel_powerclamp.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/thermal/intel/intel_powerclamp.c +4 -2
@@ -535,8 +535,10 @@ static int start_power_clamp(void)/* prefer BSP */ control_cpu =0 ; -if (!cpu_online (control_cpu)) - control_cpu =smp_processor_id (); +if (!cpu_online (control_cpu)) { + control_cpu =get_cpu (); +put_cpu (); + } clamping = true;schedule_delayed_work (&poll_pkg_cstate_work,0 );
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 189/255 x86/entry: Work around Clang __bdos() bug
In reply to Greg Kroah-HartmanFrom: Kees Cook <[email protected]>
[ Upstream commit 3e1730842f142add55dc658929221521a9ea62b6 ]
Clang produces a false positive when building with CONFIG_FORTIFY_SOURCE=y and CONFIG_UBSAN_BOUNDS=y when operating on an array with a dynamic offset. Work around this by using a direct assignment of an empty instance. Avoids this warning:
../include/linux/fortify-string.h:309:4: warning: call to __write_overflow_field declared with 'warn ing' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wat tribute-warning]
__write_overflow_field(p_size_field, size);
^which was isolated to the memset() call in xen_load_idt().
Note that this looks very much like another bug that was worked around:
https://github.com/ClangBuiltLinux/linux/issues/1592
--- arch/x86/xen/enlighten_pv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
arch/x86/xen/enlighten_pv.c +2 -1
@@ -759,6 +759,7 @@ static void xen_load_idt(const struct desc_ptr *desc) {static DEFINE_SPINLOCK (lock);static struct trap_info traps[257 ]; +static const struct trap_info zero = { };unsigned out;trace_xen_cpu_load_idt (desc);
@@ -768,7 +769,7 @@ static void xen_load_idt(const struct desc_ptr *desc)memcpy (this_cpu_ptr (&idt_desc), desc,sizeof (idt_desc)); out =xen_convert_trap_info (desc, traps, false); -memset (&traps[out],0 ,sizeof (traps[0 ])); + traps[out] = zero;xen_mc_flush ();if (HYPERVISOR_set_trap_table (traps))
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 190/255 NFSD: Return nfserr_serverfault if splice_ok but buf->pages have data
In reply to Greg Kroah-HartmanFrom: Anna Schumaker <[email protected]>
[ Upstream commit 06981d560606ac48d61e5f4fff6738b925c93173 ]
This was discussed with Chuck as part of this patch set. Returning nfserr_resource was decided to not be the best error message here, and he suggested changing to nfserr_serverfault instead.
--- fs/nfsd/nfs4xdr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/nfsd/nfs4xdr.c +1 -1
@@ -3600,7 +3600,7 @@ nfsd4_encode_read(struct nfsd4_compoundres *resp, __be32 nfserr,if (resp->xdr.buf->page_len &&test_bit (RQ_SPLICE_OK , &resp->rqstp->rq_flags)) {WARN_ON_ONCE (1 ); -return nfserr_resource; +return nfserr_serverfault; }xdr_commit_encode (xdr);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 191/255 wifi: brcmfmac: fix invalid address access when enabling SCAN log level
In reply to Greg Kroah-HartmanFrom: Wright Feng <[email protected]>
[ Upstream commit aa666b68e73fc06d83c070d96180b9010cf5a960 ]
The variable i is changed when setting random MAC address and causes invalid address access when printing the value of pi->reqs[i]->reqid.
We replace reqs index with ri to fix the issue.
[ 136.726473] Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000000 [ 136.737365] Mem abort info: [ 136.740172] ESR = 0x96000004 [ 136.743359] Exception class = DABT (current EL), IL = 32 bits [ 136.749294] SET = 0, FnV = 0 [ 136.752481] EA = 0, S1PTW = 0 [ 136.755635] Data abort info: [ 136.758514] ISV = 0, ISS = 0x00000004 [ 136.762487] CM = 0, WnR = 0 [ 136.765522] user pgtable: 4k pages, 48-bit VAs, pgdp = 000000005c4e2577 [ 136.772265] [0000000000000000] pgd=0000000000000000 [ 136.777160] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 136.782732] Modules linked in: brcmfmac(O) brcmutil(O) cfg80211(O) compat(O) [ 136.789788] Process wificond (pid: 3175, stack limit = 0x00000000053048fb) [ 136.796664] CPU: 3 PID: 3175 Comm: wificond Tainted: G O 4.19.42-00001-g531a5f5 #1 [ 136.805532] Hardware name: Freescale i.MX8MQ EVK (DT) [ 136.810584] pstate: 60400005 (nZCv daif +PAN -UAO) [ 136.815429] pc : brcmf_pno_config_sched_scans+0x6cc/0xa80 [brcmfmac] [ 136.821811] lr : brcmf_pno_config_sched_scans+0x67c/0xa80 [brcmfmac] [ 136.828162] sp : ffff00000e9a3880 [ 136.831475] x29: ffff00000e9a3890 x28: ffff800020543400 [ 136.836786] x27: ffff8000b1008880 x26: ffff0000012bf6a0 [ 136.842098] x25: ffff80002054345c x24: ffff800088d22400 [ 136.847409] x23: ffff0000012bf638 x22: ffff0000012bf6d8 [ 136.852721] x21: ffff8000aced8fc0 x20: ffff8000ac164400 [ 136.858032] x19: ffff00000e9a3946 x18: 0000000000000000 [ 136.863343] x17: 0000000000000000 x16: 0000000000000000 [ 136.868655] x15: ffff0000093f3b37 x14: 0000000000000050 [ 136.873966] x13: 0000000000003135 x12: 0000000000000000 [ 136.879277] x11: 0000000000000000 x10: ffff000009a61888 [ 136.884589] x9 : 000000000000000f x8 : 0000000000000008 [ 136.889900] x7 : 303a32303d726464 x6 : ffff00000a1f957d [ 136.895211] x5 : 0000000000000000 x4 : ffff00000e9a3942 [ 136.900523] x3 : 0000000000000000 x2 : ffff0000012cead8 [ 136.905834] x1 : ffff0000012bf6d8 x0 : 0000000000000000 [ 136.911146] Call trace: [ 136.913623] brcmf_pno_config_sched_scans+0x6cc/0xa80 [brcmfmac] [ 136.919658] brcmf_pno_start_sched_scan+0xa4/0x118 [brcmfmac] [ 136.925430] brcmf_cfg80211_sched_scan_start+0x80/0xe0 [brcmfmac] [ 136.931636] nl80211_start_sched_scan+0x140/0x308 [cfg80211] [ 136.937298] genl_rcv_msg+0x358/0x3f4 [ 136.940960] netlink_rcv_skb+0xb4/0x118 [ 136.944795] genl_rcv+0x34/0x48 [ 136.947935] netlink_unicast+0x264/0x300 [ 136.951856] netlink_sendmsg+0x2e4/0x33c [ 136.955781] __sys_sendto+0x120/0x19c
--- .../net/wireless/broadcom/brcm80211/brcmfmac/pno.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c +6 -6
@@ -154,12 +154,12 @@ static int brcmf_pno_set_random(struct brcmf_if *ifp, struct brcmf_pno_info *pi)struct brcmf_pno_macaddr_le pfn_mac;u8 *mac_addr =NULL ;u8 *mac_mask =NULL ; -int err, i; +int err, i, ri; -for (i =0 ; i < pi->n_reqs; i++) -if (pi->reqs[i]->flags &NL80211_SCAN_FLAG_RANDOM_ADDR ) { - mac_addr = pi->reqs[i]->mac_addr; - mac_mask = pi->reqs[i]->mac_addr_mask; +for (ri =0 ; ri < pi->n_reqs; ri++) +if (pi->reqs[ri]->flags &NL80211_SCAN_FLAG_RANDOM_ADDR ) { + mac_addr = pi->reqs[ri]->mac_addr; + mac_mask = pi->reqs[ri]->mac_addr_mask;break ; }
@@ -181,7 +181,7 @@ static int brcmf_pno_set_random(struct brcmf_if *ifp, struct brcmf_pno_info *pi) pfn_mac.mac[0 ] |=0x02 ;brcmf_dbg (SCAN ,"enabling random mac: reqid=%llu mac=%pM\n" , - pi->reqs[i]->reqid, pfn_mac.mac); + pi->reqs[ri]->reqid, pfn_mac.mac); err =brcmf_fil_iovar_data_set (ifp,"pfn_macaddr" , &pfn_mac,sizeof (pfn_mac));if (err)
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 192/255 bpftool: Clear errno after libcaps checks
In reply to Greg Kroah-HartmanFrom: Quentin Monnet <[email protected]>
[ Upstream commit cea558855c39b7f1f02ff50dcf701ca6596bc964 ]
When bpftool is linked against libcap, the library runs a "constructor" function to compute the number of capabilities of the running kernel [0], at the beginning of the execution of the program. As part of this, it performs multiple calls to prctl(). Some of these may fail, and set errno to a non-zero value:
# strace -e prctl ./bpftool version
prctl(PR_CAPBSET_READ, CAP_MAC_OVERRIDE) = 1
prctl(PR_CAPBSET_READ, 0x30 /* CAP_??? */) = -1 EINVAL (Invalid argument)
prctl(PR_CAPBSET_READ, CAP_CHECKPOINT_RESTORE) = 1
prctl(PR_CAPBSET_READ, 0x2c /* CAP_??? */) = -1 EINVAL (Invalid argument)
prctl(PR_CAPBSET_READ, 0x2a /* CAP_??? */) = -1 EINVAL (Invalid argument)
prctl(PR_CAPBSET_READ, 0x29 /* CAP_??? */) = -1 EINVAL (Invalid argument)
** fprintf added at the top of main(): we have errno == 1
./bpftool v7.0.0
using libbpf v1.0
features: libbfd, libbpf_strict, skeletons
+++ exited with 0 +++This has been addressed in libcap 2.63 [1], but until this version is available everywhere, we can fix it on bpftool side.
Let's clean errno at the beginning of the main() function, to make sure that these checks do not interfere with the batch mode, where we error out if errno is set after a bpftool command.
[0] https://git.kernel.org/pub/scm/libs/libcap/libcap.git/tree/libcap/cap_alloc.c?h=libcap-2.65#n20
[1] https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=f25a1b7e69f7b33e6afb58b3e38f3450b7d2d9a0
--- tools/bpf/bpftool/main.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
tools/bpf/bpftool/main.c +10 -0
@@ -364,6 +364,16 @@ int main(int argc, char **argv)setlinebuf (stdout); +#ifdef USE_LIBCAP +/* Libcap < 2.63 hooks before main() to compute the number of +* capabilities of the running kernel, and doing so it calls prctl() +* which may fail and set errno to non-zero. +* Let's reset errno to make sure this does not interfere with the +* batch mode. +*/ + errno =0 ; +#endif + last_do_help = do_help; pretty_output = false; json_output = false;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 193/255 openvswitch: Fix double reporting of drops in dropwatch
In reply to Greg Kroah-HartmanFrom: Mike Pattrick <[email protected]>
[ Upstream commit 1100248a5c5ccd57059eb8d02ec077e839a23826 ]
Frames sent to userspace can be reported as dropped in ovs_dp_process_packet, however, if they are dropped in the netlink code then netlink_attachskb will report the same frame as dropped.
This patch checks for error codes which indicate that the frame has already been freed.
--- net/openvswitch/datapath.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-)
net/openvswitch/datapath.c +10 -3
@@ -236,10 +236,17 @@ void ovs_dp_process_packet(struct sk_buff *skb, struct sw_flow_key *key) upcall.portid =ovs_vport_find_upcall_portid (p, skb); upcall.mru =OVS_CB (skb)->mru; error =ovs_dp_upcall (dp, skb, key, &upcall,0 ); -if (unlikely (error)) -kfree_skb (skb); -else +switch (error) { +case 0 : +case -EAGAIN : +case -ERESTARTSYS : +case -EINTR :consume_skb (skb); +break ; +default : +kfree_skb (skb); +break ; + } stats_counter = &stats->n_missed; goto out; }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 194/255 openvswitch: Fix overreporting of drops in dropwatch
In reply to Greg Kroah-HartmanFrom: Mike Pattrick <[email protected]>
[ Upstream commit c21ab2afa2c64896a7f0e3cbc6845ec63dcfad2e ]
Currently queue_userspace_packet will call kfree_skb for all frames, whether or not an error occurred. This can result in a single dropped frame being reported as multiple drops in dropwatch. This functions caller may also call kfree_skb in case of an error. This patch will consume the skbs instead and allow caller's to use kfree_skb.
--- net/openvswitch/datapath.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
net/openvswitch/datapath.c +3 -2
@@ -532,8 +532,9 @@ static int queue_userspace_packet(struct datapath *dp, struct sk_buff *skb, out:if (err)skb_tx_error (skb); -kfree_skb (user_skb); -kfree_skb (nskb); +consume_skb (user_skb); +consume_skb (nskb); +return err; }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 195/255 tcp: annotate data-race around tcp_md5sig_pool_populated
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
[ Upstream commit aacd467c0a576e5e44d2de4205855dc0fe43f6fb ]
tcp_md5sig_pool_populated can be read while another thread changes its value.
The race has no consequence because allocations are protected with tcp_md5sig_mutex.
This patch adds READ_ONCE() and WRITE_ONCE() to document the race and silence KCSAN.
--- net/ipv4/tcp.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
net/ipv4/tcp.c +10 -4
@@ -3770,12 +3770,16 @@ static void __tcp_alloc_md5sig_pool(void)* to memory. See smp_rmb() in tcp_get_md5sig_pool() */ smp_wmb (); - tcp_md5sig_pool_populated = true; +/* Paired with READ_ONCE() from tcp_alloc_md5sig_pool() +* and tcp_get_md5sig_pool(). +*/ +WRITE_ONCE (tcp_md5sig_pool_populated, true); }bool tcp_alloc_md5sig_pool (void ) { -if (unlikely (!tcp_md5sig_pool_populated)) { +/* Paired with WRITE_ONCE() from __tcp_alloc_md5sig_pool() */ +if (unlikely (!READ_ONCE (tcp_md5sig_pool_populated))) {mutex_lock (&tcp_md5sig_mutex);if (!tcp_md5sig_pool_populated) {
@@ -3786,7 +3790,8 @@ bool tcp_alloc_md5sig_pool(void)mutex_unlock (&tcp_md5sig_mutex); } -return tcp_md5sig_pool_populated; +/* Paired with WRITE_ONCE() from __tcp_alloc_md5sig_pool() */ +return READ_ONCE (tcp_md5sig_pool_populated); }EXPORT_SYMBOL (tcp_alloc_md5sig_pool);
@@ -3802,7 +3807,8 @@ struct tcp_md5sig_pool *tcp_get_md5sig_pool(void) {local_bh_disable (); -if (tcp_md5sig_pool_populated) { +/* Paired with WRITE_ONCE() from __tcp_alloc_md5sig_pool() */ +if (READ_ONCE (tcp_md5sig_pool_populated)) {/* coupled with smp_wmb() in __tcp_alloc_md5sig_pool() */ smp_rmb ();return this_cpu_ptr (&tcp_md5sig_pool);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 196/255 wifi: ath9k: avoid uninit memory read in ath9k_htc_rx_msg()
In reply to Greg Kroah-HartmanFrom: Tetsuo Handa <[email protected]>
[ Upstream commit b383e8abed41cc6ff1a3b34de75df9397fa4878c ]
syzbot is reporting uninit value at ath9k_htc_rx_msg() [1], for ioctl(USB_RAW_IOCTL_EP_WRITE) can call ath9k_hif_usb_rx_stream() with pkt_len = 0 but ath9k_hif_usb_rx_stream() uses __dev_alloc_skb(pkt_len + 32, GFP_ATOMIC) based on an assumption that pkt_len is valid. As a result, ath9k_hif_usb_rx_stream() allocates skb with uninitialized memory and ath9k_htc_rx_msg() is reading from uninitialized memory.
Since bytes accessed by ath9k_htc_rx_msg() is not known until ath9k_htc_rx_msg() is called, it would be difficult to check minimal valid pkt_len at "if (pkt_len > 2 * MAX_RX_BUF_SIZE) {" line in ath9k_hif_usb_rx_stream().
We have two choices. One is to workaround by adding __GFP_ZERO so that ath9k_htc_rx_msg() sees 0 if pkt_len is invalid. The other is to let ath9k_htc_rx_msg() validate pkt_len before accessing. This patch chose the latter.
Note that I'm not sure threshold condition is correct, for I can't find details on possible packet length used by this protocol.
--- drivers/net/wireless/ath/ath9k/htc_hst.c | 43 +++++++++++++++--------- 1 file changed, 28 insertions(+), 15 deletions(-)
drivers/net/wireless/ath/ath9k/htc_hst.c +28 -15
@@ -364,33 +364,27 @@ void ath9k_htc_txcompletion_cb(struct htc_target *htc_handle, }static void ath9k_htc_fw_panic_report (struct htc_target *htc_handle, -struct sk_buff *skb) +struct sk_buff *skb,u32 len) {uint32_t *pattern = (uint32_t *)skb->data; -switch (*pattern) { -case 0x33221199 : - { +if (*pattern ==0x33221199 && len >=sizeof (struct htc_panic_bad_vaddr )) {struct htc_panic_bad_vaddr *htc_panic; htc_panic = (struct htc_panic_bad_vaddr *) skb->data;dev_err (htc_handle->dev,"ath: firmware panic! " "exccause: 0x%08x; pc: 0x%08x; badvaddr: 0x%08x.\n" , htc_panic->exccause, htc_panic->pc, htc_panic->badvaddr); -break ; - } -case 0x33221299 : - { +return ; + } +if (*pattern ==0x33221299 ) {struct htc_panic_bad_epid *htc_panic; htc_panic = (struct htc_panic_bad_epid *) skb->data;dev_err (htc_handle->dev,"ath: firmware panic! " "bad epid: 0x%08x\n" , htc_panic->epid); -break ; - } -default : -dev_err (htc_handle->dev,"ath: unknown panic pattern!\n" ); -break ; +return ; } +dev_err (htc_handle->dev,"ath: unknown panic pattern!\n" ); }/*
@@ -411,16 +405,26 @@ void ath9k_htc_rx_msg(struct htc_target *htc_handle,if (!htc_handle || !skb)return ; +/* A valid message requires len >= 8. +* +* sizeof(struct htc_frame_hdr) == 8 +* sizeof(struct htc_ready_msg) == 8 +* sizeof(struct htc_panic_bad_vaddr) == 16 +* sizeof(struct htc_panic_bad_epid) == 8 +*/ +if (unlikely (len <sizeof (struct htc_frame_hdr ))) + goto invalid; htc_hdr = (struct htc_frame_hdr *) skb->data; epid = htc_hdr->endpoint_id;if (epid ==0x99 ) { -ath9k_htc_fw_panic_report (htc_handle, skb); +ath9k_htc_fw_panic_report (htc_handle, skb, len);kfree_skb (skb);return ; }if (epid <0 || epid >=ENDPOINT_MAX ) { +invalid:if (pipe_id !=USB_REG_IN_PIPE )dev_kfree_skb_any (skb);else
@@ -432,21 +436,30 @@ void ath9k_htc_rx_msg(struct htc_target *htc_handle,/* Handle trailer */ if (htc_hdr->flags &HTC_FLAGS_RECV_TRAILER ) { -if (be32_to_cpu (*(__be32 *) skb->data) ==0x00C60000 ) +if (be32_to_cpu (*(__be32 *) skb->data) ==0x00C60000 ) {/* Move past the Watchdog pattern */ htc_hdr = (struct htc_frame_hdr *)(skb->data +4 ); + len -=4 ; + } }/* Get the message ID */ +if (unlikely (len <sizeof (struct htc_frame_hdr ) +sizeof (__be16))) + goto invalid; msg_id = (__be16 *) ((void *) htc_hdr +sizeof (struct htc_frame_hdr ));/* Now process HTC messages */ switch (be16_to_cpu (*msg_id)) {case HTC_MSG_READY_ID : +if (unlikely (len <sizeof (struct htc_ready_msg ))) + goto invalid;htc_process_target_rdy (htc_handle, htc_hdr);break ;case HTC_MSG_CONNECT_SERVICE_RESPONSE_ID : +if (unlikely (len <sizeof (struct htc_frame_hdr ) + +sizeof (struct htc_conn_svc_rspmsg ))) + goto invalid;htc_process_conn_rsp (htc_handle, htc_hdr);break ;default :
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 197/255 xfrm: Update ipcomp_scratches with NULL when freed
In reply to Greg Kroah-HartmanFrom: Khalid Masum <[email protected]>
[ Upstream commit 8a04d2fc700f717104bfb95b0f6694e448a4537f ]
Currently if ipcomp_alloc_scratches() fails to allocate memory ipcomp_scratches holds obsolete address. So when we try to free the percpu scratches using ipcomp_free_scratches() it tries to vfree non existent vm area. Described below:
static void * __percpu *ipcomp_alloc_scratches(void)
{
...
scratches = alloc_percpu(void *);
if (!scratches)
return NULL;
ipcomp_scratches does not know about this allocation failure.
Therefore holding the old obsolete address.
...
}So when we free,
static void ipcomp_free_scratches(void)
{
...
scratches = ipcomp_scratches;Assigning obsolete address from ipcomp_scratches
if (!scratches)
return;
for_each_possible_cpu(i)
vfree(*per_cpu_ptr(scratches, i));
Trying to free non existent page, causing warning: trying to vfree
existent vm area.
...
}Fix this breakage by updating ipcomp_scrtches with NULL when scratches is freed
--- net/xfrm/xfrm_ipcomp.c | 1 + 1 file changed, 1 insertion(+)
net/xfrm/xfrm_ipcomp.c +1 -0
@@ -212,6 +212,7 @@ static void ipcomp_free_scratches(void)vfree (*per_cpu_ptr (scratches, i));free_percpu (scratches); + ipcomp_scratches =NULL ; }static void *__percpu *ipcomp_alloc_scratches (void )
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 198/255 wifi: brcmfmac: fix use-after-free bug in brcmf_netdev_start_xmit()
In reply to Greg Kroah-HartmanFrom: Alexander Coffin <[email protected]>
[ Upstream commit 3f42faf6db431e04bf942d2ebe3ae88975723478 ]
Quoted 1 line
ret =
brcmf_proto_tx_queue_data(drvr, ifp->ifidx, skb);
may be schedule, and then complete before the line
Quoted 1 line
ndev->stats.tx_bytes+=skb->len;
[ 46.912801] ================================================================== [ 46.920552] BUG: KASAN: use-after-free in brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac] [ 46.928673] Read of size 4 at addr ffffff803f5882e8 by task systemd-resolve/328 [ 46.935991] [ 46.937514] CPU: 1 PID: 328 Comm: systemd-resolve Tainted: G O 5.4.199-[REDACTED] #1 [ 46.947255] Hardware name: [REDACTED] [ 46.954568] Call trace: [ 46.957037] dump_backtrace+0x0/0x2b8 [ 46.960719] show_stack+0x24/0x30 [ 46.964052] dump_stack+0x128/0x194 [ 46.967557] print_address_description.isra.0+0x64/0x380 [ 46.972877] __kasan_report+0x1d4/0x240 [ 46.976723] kasan_report+0xc/0x18 [ 46.980138] __asan_report_load4_noabort+0x18/0x20 [ 46.985027] brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac] [ 46.990613] dev_hard_start_xmit+0x1bc/0xda0 [ 46.994894] sch_direct_xmit+0x198/0xd08 [ 46.998827] __qdisc_run+0x37c/0x1dc0 [ 47.002500] __dev_queue_xmit+0x1528/0x21f8 [ 47.006692] dev_queue_xmit+0x24/0x30 [ 47.010366] neigh_resolve_output+0x37c/0x678 [ 47.014734] ip_finish_output2+0x598/0x2458 [ 47.018927] __ip_finish_output+0x300/0x730 [ 47.023118] ip_output+0x2e0/0x430 [ 47.026530] ip_local_out+0x90/0x140 [ 47.030117] igmpv3_sendpack+0x14c/0x228 [ 47.034049] igmpv3_send_cr+0x384/0x6b8 [ 47.037895] igmp_ifc_timer_expire+0x4c/0x118 [ 47.042262] call_timer_fn+0x1cc/0xbe8 [ 47.046021] __run_timers+0x4d8/0xb28 [ 47.049693] run_timer_softirq+0x24/0x40 [ 47.053626] __do_softirq+0x2c0/0x117c [ 47.057387] irq_exit+0x2dc/0x388 [ 47.060715] __handle_domain_irq+0xb4/0x158 [ 47.064908] gic_handle_irq+0x58/0xb0 [ 47.068581] el0_irq_naked+0x50/0x5c [ 47.072162] [ 47.073665] Allocated by task 328: [ 47.077083] save_stack+0x24/0xb0 [ 47.080410] __kasan_kmalloc.isra.0+0xc0/0xe0 [ 47.084776] kasan_slab_alloc+0x14/0x20 [ 47.088622] kmem_cache_alloc+0x15c/0x468 [ 47.092643] __alloc_skb+0xa4/0x498 [ 47.096142] igmpv3_newpack+0x158/0xd78 [ 47.099987] add_grhead+0x210/0x288 [ 47.103485] add_grec+0x6b0/0xb70 [ 47.106811] igmpv3_send_cr+0x2e0/0x6b8 [ 47.110657] igmp_ifc_timer_expire+0x4c/0x118 [ 47.115027] call_timer_fn+0x1cc/0xbe8 [ 47.118785] __run_timers+0x4d8/0xb28 [ 47.122457] run_timer_softirq+0x24/0x40 [ 47.126389] __do_softirq+0x2c0/0x117c [ 47.130142] [ 47.131643] Freed by task 180: [ 47.134712] save_stack+0x24/0xb0 [ 47.138041] __kasan_slab_free+0x108/0x180 [ 47.142146] kasan_slab_free+0x10/0x18 [ 47.145904] slab_free_freelist_hook+0xa4/0x1b0 [ 47.150444] kmem_cache_free+0x8c/0x528 [ 47.154292] kfree_skbmem+0x94/0x108 [ 47.157880] consume_skb+0x10c/0x5a8 [ 47.161466] __dev_kfree_skb_any+0x88/0xa0 [ 47.165598] brcmu_pkt_buf_free_skb+0x44/0x68 [brcmutil] [ 47.171023] brcmf_txfinalize+0xec/0x190 [brcmfmac] [ 47.176016] brcmf_proto_bcdc_txcomplete+0x1c0/0x210 [brcmfmac] [ 47.182056] brcmf_sdio_sendfromq+0x8dc/0x1e80 [brcmfmac] [ 47.187568] brcmf_sdio_dpc+0xb48/0x2108 [brcmfmac] [ 47.192529] brcmf_sdio_dataworker+0xc8/0x238 [brcmfmac] [ 47.197859] process_one_work+0x7fc/0x1a80 [ 47.201965] worker_thread+0x31c/0xc40 [ 47.205726] kthread+0x2d8/0x370 [ 47.208967] ret_from_fork+0x10/0x18 [ 47.212546] [ 47.214051] The buggy address belongs to the object at ffffff803f588280 [ 47.214051] which belongs to the cache skbuff_head_cache of size 208 [ 47.227086] The buggy address is located 104 bytes inside of [ 47.227086] 208-byte region [ffffff803f588280, ffffff803f588350) [ 47.238814] The buggy address belongs to the page: [ 47.243618] page:ffffffff00dd6200 refcount:1 mapcount:0 mapping:ffffff804b6bf800 index:0xffffff803f589900 compound_mapcount: 0 [ 47.255007] flags: 0x10200(slab|head) [ 47.258689] raw: 0000000000010200 ffffffff00dfa980 0000000200000002 ffffff804b6bf800 [ 47.266439] raw: ffffff803f589900 0000000080190018 00000001ffffffff 0000000000000000 [ 47.274180] page dumped because: kasan: bad access detected [ 47.279752] [ 47.281251] Memory state around the buggy address: [ 47.286051] ffffff803f588180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 47.293277] ffffff803f588200: fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 47.300502] >ffffff803f588280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 47.307723] ^ [ 47.314343] ffffff803f588300: fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc fc [ 47.321569] ffffff803f588380: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb [ 47.328789] ==================================================================
--- drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c +2 -1
@@ -290,6 +290,7 @@ static netdev_tx_t brcmf_netdev_start_xmit(struct sk_buff *skb,struct brcmf_pub *drvr = ifp->drvr;struct ethhdr *eh;int head_delta; +unsigned int tx_bytes = skb->len;brcmf_dbg (DATA ,"Enter, bsscfgidx=%d\n" , ifp->bsscfgidx);
@@ -361,7 +362,7 @@ static netdev_tx_t brcmf_netdev_start_xmit(struct sk_buff *skb, ndev->stats.tx_dropped++; }else { ndev->stats.tx_packets++; - ndev->stats.tx_bytes += skb->len; + ndev->stats.tx_bytes += tx_bytes; }/* Return ok: we always eat the packet */
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 199/255 Bluetooth: L2CAP: initialize delayed works at l2cap_chan_create()
In reply to Greg Kroah-HartmanFrom: Tetsuo Handa <[email protected]>
[ Upstream commit 2d2cb3066f2c90cd8ca540b36ba7a55e7f2406e0 ]
syzbot is reporting cancel_delayed_work() without INIT_DELAYED_WORK() at l2cap_chan_del() [1], for CONF_NOT_COMPLETE flag (which meant to prevent l2cap_chan_del() from calling cancel_delayed_work()) is cleared by timer which fires before l2cap_chan_del() is called by closing file descriptor created by socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_L2CAP).
l2cap_bredr_sig_cmd(L2CAP_CONF_REQ) and l2cap_bredr_sig_cmd(L2CAP_CONF_RSP) are calling l2cap_ertm_init(chan), and they call l2cap_chan_ready() (which clears CONF_NOT_COMPLETE flag) only when l2cap_ertm_init(chan) succeeded.
l2cap_sock_init() does not call l2cap_ertm_init(chan), and it instead sets CONF_NOT_COMPLETE flag by calling l2cap_chan_set_defaults(). However, when connect() is requested, "command 0x0409 tx timeout" happens after 2 seconds
from connect() request, and CONF_NOT_COMPLETE flag is cleared after 4
seconds from connect() request, for l2cap_conn_start() from l2cap_info_timeout() callback scheduled by
schedule_delayed_work(&conn->info_timer, L2CAP_INFO_TIMEOUT);
in l2cap_connect() is calling l2cap_chan_ready().
Fix this problem by initializing delayed works used by L2CAP_MODE_ERTM mode as soon as l2cap_chan_create() allocates a channel, like I did in commit be8597239379f0f5 ("Bluetooth: initialize skb_queue_head at l2cap_chan_create()").
--- net/bluetooth/l2cap_core.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
net/bluetooth/l2cap_core.c +6 -4
@@ -60,6 +60,9 @@ static void l2cap_send_disconn_req(struct l2cap_chan *chan, int err);static void l2cap_tx (struct l2cap_chan *chan,struct l2cap_ctrl *control,struct sk_buff_head *skbs,u8 event); +static void l2cap_retrans_timeout (struct work_struct *work); +static void l2cap_monitor_timeout (struct work_struct *work); +static void l2cap_ack_timeout (struct work_struct *work);static inline u8 bdaddr_type (u8 link_type,u8 bdaddr_type) {
@@ -475,6 +478,9 @@ struct l2cap_chan *l2cap_chan_create(void)write_unlock (&chan_list_lock);INIT_DELAYED_WORK (&chan->chan_timer, l2cap_chan_timeout); +INIT_DELAYED_WORK (&chan->retrans_timer, l2cap_retrans_timeout); +INIT_DELAYED_WORK (&chan->monitor_timer, l2cap_monitor_timeout); +INIT_DELAYED_WORK (&chan->ack_timer, l2cap_ack_timeout); chan->state =BT_OPEN ;
@@ -3163,10 +3169,6 @@ int l2cap_ertm_init(struct l2cap_chan *chan) chan->rx_state =L2CAP_RX_STATE_RECV ; chan->tx_state =L2CAP_TX_STATE_XMIT ; -INIT_DELAYED_WORK (&chan->retrans_timer, l2cap_retrans_timeout); -INIT_DELAYED_WORK (&chan->monitor_timer, l2cap_monitor_timeout); -INIT_DELAYED_WORK (&chan->ack_timer, l2cap_ack_timeout); -skb_queue_head_init (&chan->srej_q); err =l2cap_seq_list_init (&chan->srej_list, chan->tx_win);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 200/255 Bluetooth: hci_sysfs: Fix attempting to call device_add multiple times
In reply to Greg Kroah-HartmanFrom: Luiz Augusto von Dentz <[email protected]>
[ Upstream commit 448a496f760664d3e2e79466aa1787e6abc922b5 ]
device_add shall not be called multiple times as stated in its documentation:
'Do not call this routine or device_register() more than once for any device structure'
Syzkaller reports a bug as follows [1]:
------------[ cut here ]------------ kernel BUG at lib/list_debug.c:33! invalid opcode: 0000 [#1] PREEMPT SMP KASAN [...] Call Trace: <TASK> __list_add include/linux/list.h:69 [inline] list_add_tail include/linux/list.h:102 [inline] kobj_kset_join lib/kobject.c:164 [inline] kobject_add_internal+0x18f/0x8f0 lib/kobject.c:214 kobject_add_varg lib/kobject.c:358 [inline] kobject_add+0x150/0x1c0 lib/kobject.c:410 device_add+0x368/0x1e90 drivers/base/core.c:3452 hci_conn_add_sysfs+0x9b/0x1b0 net/bluetooth/hci_sysfs.c:53 hci_le_cis_estabilished_evt+0x57c/0xae0 net/bluetooth/hci_event.c:6799 hci_le_meta_evt+0x2b8/0x510 net/bluetooth/hci_event.c:7110 hci_event_func net/bluetooth/hci_event.c:7440 [inline] hci_event_packet+0x63d/0xfd0 net/bluetooth/hci_event.c:7495 hci_rx_work+0xae7/0x1230 net/bluetooth/hci_core.c:4007 process_one_work+0x991/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK>
--- net/bluetooth/hci_sysfs.c | 3 +++ 1 file changed, 3 insertions(+)
net/bluetooth/hci_sysfs.c +3 -0
@@ -48,6 +48,9 @@ void hci_conn_add_sysfs(struct hci_conn *conn)BT_DBG ("conn %p" , conn); +if (device_is_registered (&conn->dev)) +return ; +dev_set_name (&conn->dev,"%s:%d" , hdev->name, conn->handle);if (device_add (&conn->dev) <0 ) {
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 201/255 can: bcm: check the result of can_send() in bcm_can_tx()
In reply to Greg Kroah-HartmanFrom: Ziyang Xuan <[email protected]>
[ Upstream commit 3fd7bfd28cfd68ae80a2fe92ea1615722cc2ee6e ]
If can_send() fail, it should not update frames_abs counter in bcm_can_tx(). Add the result check for can_send() in bcm_can_tx().
--- net/can/bcm.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
net/can/bcm.c +4 -3
@@ -276,6 +276,7 @@ static void bcm_can_tx(struct bcm_op *op)struct sk_buff *skb;struct net_device *dev;struct canfd_frame *cf = op->frames + op->cfsiz * op->currframe; +int err;/* no target device? => exit */ if (!op->ifindex)
@@ -300,11 +301,11 @@ static void bcm_can_tx(struct bcm_op *op)/* send with loopback */ skb->dev = dev;can_skb_set_owner (skb, op->sk); -can_send (skb,1 ); + err =can_send (skb,1 ); +if (!err) + op->frames_abs++; -/* update statistics */ op->currframe++; - op->frames_abs++;/* reached last frame? */ if (op->currframe >= op->nframes)
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 202/255 wifi: rt2x00: dont run Rt5592 IQ calibration on MT7620
In reply to Greg Kroah-HartmanFrom: Daniel Golle <[email protected]>
[ Upstream commit d3aad83d05aec0cfd7670cf0028f2ad4b81de92e ]
The function rt2800_iq_calibrate is intended for Rt5592 only. Don't call it for MT7620 which has it's own calibration functions.
--- drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/wireless/ralink/rt2x00/rt2800lib.c +2 -1
@@ -4355,7 +4355,8 @@ static void rt2800_config_channel(struct rt2x00_dev *rt2x00dev, reg = (rf->channel <=14 ?0x1c :0x24 ) +2 *rt2x00dev->lna_gain;rt2800_bbp_write_with_rx_chain (rt2x00dev,66 , reg); -rt2800_iq_calibrate (rt2x00dev, rf->channel); +if (rt2x00_rt (rt2x00dev,RT5592 )) +rt2800_iq_calibrate (rt2x00dev, rf->channel); } bbp =rt2800_bbp_read (rt2x00dev,4 );
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 203/255 wifi: rt2x00: set correct TX_SW_CFG1 MAC register for MT7620
In reply to Greg Kroah-HartmanFrom: Daniel Golle <[email protected]>
[ Upstream commit eeb50acf15762b61921f9df18663f839f387c054 ]
Set correct TX_SW_CFG1 MAC register as it is done also in v3 of the vendor driver[1].
--- drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless/ralink/rt2x00/rt2800lib.c +1 -1
@@ -5852,7 +5852,7 @@ static int rt2800_init_registers(struct rt2x00_dev *rt2x00dev)rt2800_register_write (rt2x00dev,TX_SW_CFG0 ,0x00000404 ); }else if (rt2x00_rt (rt2x00dev,RT6352 )) {rt2800_register_write (rt2x00dev,TX_SW_CFG0 ,0x00000401 ); -rt2800_register_write (rt2x00dev,TX_SW_CFG1 ,0x000C0000 ); +rt2800_register_write (rt2x00dev,TX_SW_CFG1 ,0x000C0001 );rt2800_register_write (rt2x00dev,TX_SW_CFG2 ,0x00000000 );rt2800_register_write (rt2x00dev,TX_ALC_VGA3 ,0x00000000 );rt2800_register_write (rt2x00dev,TX0_BB_GAIN_ATTEN ,0x0 );
Signature · 1 line
2.35.1
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.220 release. There are 255 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 26 Oct 2022 11:29:24 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.220-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.4:
10 builds: 10 pass, 0 fail
26 boots: 26 pass, 0 fail
59 tests: 59 pass, 0 failLinux version: 5.4.220-rc1-gf49f12b65484
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04Jon
Signature · 1 line
nvpublic
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.220 release. There are 255 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 26 Oct 2022 11:29:24 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.220-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Greg Kroah-Hartman
maintainerPATCH 204/255 wifi: rt2x00: set VGC gain for both chains of MT7620
In reply to Greg Kroah-HartmanFrom: Daniel Golle <[email protected]>
[ Upstream commit 0e09768c085709e10ece3b68f6ac921d3f6a9caa ]
Set bbp66 for all chains of the MT7620.
--- drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/wireless/ralink/rt2x00/rt2800lib.c +2 -1
@@ -5629,7 +5629,8 @@ static inline void rt2800_set_vgc(struct rt2x00_dev *rt2x00dev,if (qual->vgc_level != vgc_level) {if (rt2x00_rt (rt2x00dev,RT3572 ) ||rt2x00_rt (rt2x00dev,RT3593 ) || -rt2x00_rt (rt2x00dev,RT3883 )) { +rt2x00_rt (rt2x00dev,RT3883 ) || +rt2x00_rt (rt2x00dev,RT6352 )) {rt2800_bbp_write_with_rx_chain (rt2x00dev,66 , vgc_level); }else if (rt2x00_rt (rt2x00dev,RT5592 )) {
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 205/255 wifi: rt2x00: set SoC wmac clock register
In reply to Greg Kroah-HartmanFrom: Daniel Golle <[email protected]>
[ Upstream commit cbde6ed406a51092d9e8a2df058f5f8490f27443 ]
Instead of using the default value 33 (pci), set US_CYC_CNT init based on Programming guide:
If available, set chipset bus clock with fallback to cpu clock/3.
--- .../net/wireless/ralink/rt2x00/rt2800lib.c | 21 +++++++++++++++++++ 1 file changed, 21 insertions(+)
drivers/net/wireless/ralink/rt2x00/rt2800lib.c +21 -0
@@ -6115,6 +6115,27 @@ static int rt2800_init_registers(struct rt2x00_dev *rt2x00dev) reg =rt2800_register_read (rt2x00dev,US_CYC_CNT );rt2x00_set_field32 (®,US_CYC_CNT_CLOCK_CYCLE ,125 );rt2800_register_write (rt2x00dev,US_CYC_CNT , reg); + }else if (rt2x00_is_soc (rt2x00dev)) { +struct clk *clk =clk_get_sys ("bus" ,NULL ); +int rate; + +if (IS_ERR (clk)) { + clk =clk_get_sys ("cpu" ,NULL ); + +if (IS_ERR (clk)) { + rate =125 ; + }else { + rate =clk_get_rate (clk) /3000000 ; +clk_put (clk); + } + }else { + rate =clk_get_rate (clk) /1000000 ; +clk_put (clk); + } + + reg =rt2800_register_read (rt2x00dev,US_CYC_CNT ); +rt2x00_set_field32 (®,US_CYC_CNT_CLOCK_CYCLE , rate); +rt2800_register_write (rt2x00dev,US_CYC_CNT , reg); } reg =rt2800_register_read (rt2x00dev,HT_FBK_CFG0 );
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 206/255 wifi: rt2x00: correctly set BBP register 86 for MT7620
In reply to Greg Kroah-HartmanFrom: Daniel Golle <[email protected]>
[ Upstream commit c9aada64fe6493461127f1522d7e2f01792d2424 ]
Instead of 0 set the correct value for BBP register 86 for MT7620.
--- drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/net/wireless/ralink/rt2x00/rt2800lib.c +4 -1
@@ -4154,7 +4154,10 @@ static void rt2800_config_channel(struct rt2x00_dev *rt2x00dev,rt2800_bbp_write (rt2x00dev,62 ,0x37 - rt2x00dev->lna_gain);rt2800_bbp_write (rt2x00dev,63 ,0x37 - rt2x00dev->lna_gain);rt2800_bbp_write (rt2x00dev,64 ,0x37 - rt2x00dev->lna_gain); -rt2800_bbp_write (rt2x00dev,86 ,0 ); +if (rt2x00_rt (rt2x00dev,RT6352 )) +rt2800_bbp_write (rt2x00dev,86 ,0x38 ); +else +rt2800_bbp_write (rt2x00dev,86 ,0 ); }if (rf->channel <=14 ) {
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 207/255 net: If sock is dead dont access socks sk_wq in sk_stream_wait_memory
In reply to Greg Kroah-HartmanFrom: Liu Jian <[email protected]>
[ Upstream commit 3f8ef65af927db247418d4e1db49164d7a158fc5 ]
Fixes the below NULL pointer dereference:
[...]
[ 14.471200] Call Trace: [ 14.471562] <TASK> [ 14.471882] lock_acquire+0x245/0x2e0 [ 14.472416] ? remove_wait_queue+0x12/0x50 [ 14.473014] ? _raw_spin_lock_irqsave+0x17/0x50 [ 14.473681] _raw_spin_lock_irqsave+0x3d/0x50 [ 14.474318] ? remove_wait_queue+0x12/0x50 [ 14.474907] remove_wait_queue+0x12/0x50 [ 14.475480] sk_stream_wait_memory+0x20d/0x340 [ 14.476127] ? do_wait_intr_irq+0x80/0x80 [ 14.476704] do_tcp_sendpages+0x287/0x600 [ 14.477283] tcp_bpf_push+0xab/0x260 [ 14.477817] tcp_bpf_sendmsg_redir+0x297/0x500 [ 14.478461] ? __local_bh_enable_ip+0x77/0xe0 [ 14.479096] tcp_bpf_send_verdict+0x105/0x470 [ 14.479729] tcp_bpf_sendmsg+0x318/0x4f0 [ 14.480311] sock_sendmsg+0x2d/0x40 [ 14.480822] ____sys_sendmsg+0x1b4/0x1c0 [ 14.481390] ? copy_msghdr_from_user+0x62/0x80 [ 14.482048] ___sys_sendmsg+0x78/0xb0 [ 14.482580] ? vmf_insert_pfn_prot+0x91/0x150 [ 14.483215] ? __do_fault+0x2a/0x1a0 [ 14.483738] ? do_fault+0x15e/0x5d0 [ 14.484246] ? __handle_mm_fault+0x56b/0x1040 [ 14.484874] ? lock_is_held_type+0xdf/0x130 [ 14.485474] ? find_held_lock+0x2d/0x90 [ 14.486046] ? __sys_sendmsg+0x41/0x70 [ 14.486587] __sys_sendmsg+0x41/0x70 [ 14.487105] ? intel_pmu_drain_pebs_core+0x350/0x350 [ 14.487822] do_syscall_64+0x34/0x80 [ 14.488345] entry_SYSCALL_64_after_hwframe+0x63/0xcd [...]
The test scenario has the following flow:
thread1 thread2
----------- ---------------
tcp_bpf_sendmsg
tcp_bpf_send_verdict
tcp_bpf_sendmsg_redir sock_close
tcp_bpf_push_locked __sock_release
tcp_bpf_push //inet_release
do_tcp_sendpages sock->ops->release
sk_stream_wait_memory // tcp_close
sk_wait_event sk->sk_prot->close
release_sock(__sk);
***
lock_sock(sk);
__tcp_close
sock_orphan(sk)
sk->sk_wq = NULL
release_sock
****
lock_sock(__sk);
remove_wait_queue(sk_sleep(sk), &wait);
sk_sleep(sk)
//NULL pointer dereference
&rcu_dereference_raw(sk->sk_wq)->waitWhile waiting for memory in thread1, the socket is released with its wait queue because thread2 has closed it. This caused by tcp_bpf_send_verdict didn't increase the f_count of psock->sk_redir->sk_socket->file in thread1.
We should check if SOCK_DEAD flag is set on wakeup in sk_stream_wait_memory before accessing the wait queue.
--- net/core/stream.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/core/stream.c +2 -1
@@ -159,7 +159,8 @@ int sk_stream_wait_memory(struct sock *sk, long *timeo_p) *timeo_p = current_timeo; } out: -remove_wait_queue (sk_sleep (sk), &wait); +if (!sock_flag (sk,SOCK_DEAD )) +remove_wait_queue (sk_sleep (sk), &wait);return err; do_error:
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 208/255 Bluetooth: L2CAP: Fix user-after-free
In reply to Greg Kroah-HartmanFrom: Luiz Augusto von Dentz <[email protected]>
[ Upstream commit 35fcbc4243aad7e7d020b7c1dfb14bb888b20a4f ]
This uses l2cap_chan_hold_unless_zero() after calling __l2cap_get_chan_blah() to prevent the following trace:
Bluetooth: l2cap_core.c:static void l2cap_chan_destroy(struct kref *kref)
Bluetooth: chan 0000000023c4974d
Bluetooth: parent 00000000ae861c08
==================================================================
BUG: KASAN: use-after-free in __mutex_waiter_is_first kernel/locking/mutex.c:191 [inline] BUG: KASAN: use-after-free in __mutex_lock_common kernel/locking/mutex.c:671 [inline] BUG: KASAN: use-after-free in __mutex_lock+0x278/0x400 kernel/locking/mutex.c:729 Read of size 8 at addr ffff888006a49b08 by task kworker/u3:2/389
--- net/bluetooth/l2cap_core.c | 7 +++++++ 1 file changed, 7 insertions(+)
net/bluetooth/l2cap_core.c +7 -0
@@ -4066,6 +4066,12 @@ static int l2cap_connect_create_rsp(struct l2cap_conn *conn, } } + chan =l2cap_chan_hold_unless_zero (chan); +if (!chan) { + err = -EBADSLT ; + goto unlock; + } + err =0 ;l2cap_chan_lock (chan);
@@ -4095,6 +4101,7 @@ static int l2cap_connect_create_rsp(struct l2cap_conn *conn, }l2cap_chan_unlock (chan); +l2cap_chan_put (chan); unlock:mutex_unlock (&conn->chan_lock);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 209/255 r8152: Rate limit overflow messages
In reply to Greg Kroah-HartmanFrom: Andrew Gaul <[email protected]>
[ Upstream commit 93e2be344a7db169b7119de21ac1bf253b8c6907 ]
My system shows almost 10 million of these messages over a 24-hour period which pollutes my logs.
--- drivers/net/usb/r8152.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/net/usb/r8152.c +3 -1
@@ -1479,7 +1479,9 @@ static void intr_callback(struct urb *urb) "Stop submitting intr, status %d\n", status);return ;case -EOVERFLOW : -netif_info (tp, intr, tp->netdev,"intr status -EOVERFLOW\n" ); +if (net_ratelimit ()) +netif_info (tp, intr, tp->netdev, +"intr status -EOVERFLOW\n" ); goto resubmit;/* -EPIPE: should clear the halt */ default :
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 210/255 drm/nouveau/nouveau_bo: fix potential memory leak in nouveau_bo_alloc()
In reply to Greg Kroah-HartmanFrom: Jianglei Nie <[email protected]>
[ Upstream commit 6dc548745d5b5102e3c53dc5097296ac270b6c69 ]
nouveau_bo_alloc() allocates a memory chunk for "nvbo" with kzalloc(). When some error occurs, "nvbo" should be released. But when WARN_ON(pi < 0)) equals true, the function return ERR_PTR without releasing the "nvbo", which will lead to a memory leak.
We should release the "nvbo" with kfree() if WARN_ON(pi < 0)) equals true.
--- drivers/gpu/drm/nouveau/nouveau_bo.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/gpu/drm/nouveau/nouveau_bo.c +3 -1
@@ -276,8 +276,10 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int *align, u32 flags,break ; } -if (WARN_ON (pi <0 )) +if (WARN_ON (pi <0 )) { +kfree (nvbo);return ERR_PTR (-EINVAL ); + }/* Disable compression if suitable settings couldn't be found. */ if (nvbo->comp && !vmm->page[pi].comp) {
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 211/255 drm: Use size_t type for len variable in drm_copy_field()
In reply to Greg Kroah-HartmanFrom: Javier Martinez Canillas <[email protected]>
[ Upstream commit 94dc3471d1b2b58b3728558d0e3f264e9ce6ff59 ]
The strlen() function returns a size_t which is an unsigned int on 32-bit arches and an unsigned long on 64-bit arches. But in the drm_copy_field() function, the strlen() return value is assigned to an 'int len' variable.
Later, the len variable is passed as copy_from_user() third argument that is an unsigned long parameter as well.
In theory, this can lead to an integer overflow via type conversion. Since the assignment happens to a signed int lvalue instead of a size_t lvalue.
In practice though, that's unlikely since the values copied are set by DRM drivers and not controlled by userspace. But using a size_t for len is the correct thing to do anyways.
--- drivers/gpu/drm/drm_ioctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/drm_ioctl.c +1 -1
@@ -473,7 +473,7 @@ EXPORT_SYMBOL(drm_invalid_op);*/ static int drm_copy_field (char __user *buf,size_t *buf_len,const char *value) { -int len; +size_t len;/* don't overflow userbuf */ len =strlen (value);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 212/255 drm: Prevent drm_copy_field() to attempt copying a NULL pointer
In reply to Greg Kroah-HartmanFrom: Javier Martinez Canillas <[email protected]>
[ Upstream commit f6ee30407e883042482ad4ad30da5eaba47872ee ]
There are some struct drm_driver fields that are required by drivers since drm_copy_field() attempts to copy them to user-space via DRM_IOCTL_VERSION.
But it can be possible that a driver has a bug and did not set some of the fields, which leads to drm_copy_field() attempting to copy a NULL pointer:
[ +10.395966] Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000000
[ +0.010955] Mem abort info: [ +0.002835] ESR = 0x0000000096000004 [ +0.003872] EC = 0x25: DABT (current EL), IL = 32 bits [ +0.005395] SET = 0, FnV = 0 [ +0.003113] EA = 0, S1PTW = 0 [ +0.003182] FSC = 0x04: level 0 translation fault [ +0.004964] Data abort info: [ +0.002919] ISV = 0, ISS = 0x00000004 [ +0.003886] CM = 0, WnR = 0 [ +0.003040] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000115dad000 [ +0.006536] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ +0.006925] Internal error: Oops: 96000004 [#1] SMP ... [ +0.011113] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ +0.007061] pc : __pi_strlen+0x14/0x150 [ +0.003895] lr : drm_copy_field+0x30/0x1a4 [ +0.004156] sp : ffff8000094b3a50 [ +0.003355] x29: ffff8000094b3a50 x28: ffff8000094b3b70 x27: 0000000000000040 [ +0.007242] x26: ffff443743c2ba00 x25: 0000000000000000 x24: 0000000000000040 [ +0.007243] x23: ffff443743c2ba00 x22: ffff8000094b3b70 x21: 0000000000000000 [ +0.007241] x20: 0000000000000000 x19: ffff8000094b3b90 x18: 0000000000000000 [ +0.007241] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaab14b9af40 [ +0.007241] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ +0.007239] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa524ad67d4d8 [ +0.007242] x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : 6c6e6263606e7141 [ +0.007239] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ +0.007241] x2 : 0000000000000000 x1 : ffff8000094b3b90 x0 : 0000000000000000 [ +0.007240] Call trace: [ +0.002475] __pi_strlen+0x14/0x150 [ +0.003537] drm_version+0x84/0xac [ +0.003448] drm_ioctl_kernel+0xa8/0x16c [ +0.003975] drm_ioctl+0x270/0x580 [ +0.003448] __arm64_sys_ioctl+0xb8/0xfc [ +0.003978] invoke_syscall+0x78/0x100 [ +0.003799] el0_svc_common.constprop.0+0x4c/0xf4 [ +0.004767] do_el0_svc+0x38/0x4c [ +0.003357] el0_svc+0x34/0x100 [ +0.003185] el0t_64_sync_handler+0x11c/0x150 [ +0.004418] el0t_64_sync+0x190/0x194 [ +0.003716] Code: 92402c04 b200c3e8 f13fc09f 5400088c (a9400c02) [ +0.006180] ---[ end trace 0000000000000000 ]---
--- drivers/gpu/drm/drm_ioctl.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/gpu/drm/drm_ioctl.c +6 -0
@@ -475,6 +475,12 @@ static int drm_copy_field(char __user *buf, size_t *buf_len, const char *value) {size_t len; +/* don't attempt to copy a NULL pointer */ +if (WARN_ONCE (!value,"BUG: the value to copy was not set!" )) { + *buf_len =0 ; +return 0 ; + } +/* don't overflow userbuf */ len =strlen (value);if (len > *buf_len)
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 213/255 drm/amd/display: fix overflow on MIN_I64 definition
In reply to Greg Kroah-HartmanFrom: David Gow <[email protected]>
[ Upstream commit 6ae0632d17759852c07e2d1e0a31c728eb6ba246 ]
The definition of MIN_I64 in bw_fixed.c can cause gcc to whinge about integer overflow, because it is treated as a positive value, which is then negated. The temporary positive value is not necessarily representable.
This causes the following warning:../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/calcs/bw_fixed.c:30:19:
warning: integer overflow in expression ‘-9223372036854775808’ of type ‘long long int’ results in ‘-9223372036854775808’ [-Woverflow]
30 | (int64_t)(-(1LL << 63))
| ^
Writing out (-MAX_I64 - 1) works instead.
--- drivers/gpu/drm/amd/display/dc/calcs/bw_fixed.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/gpu/drm/amd/display/dc/calcs/bw_fixed.c +3 -3
@@ -26,12 +26,12 @@#include "bw_fixed.h" -#define MIN_I64 \ - (int64_t)(-(1LL << 63)) -#define MAX_I64 \ (int64_t)((1ULL << 63) - 1) +#define MIN_I64 \ + (-MAX_I64 - 1) +#define FRACTIONAL_PART_MASK \ ((1ULL << BW_FIXED_BITS_PER_FRACTIONAL_PART) - 1)
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 214/255 drm/vc4: vec: Fix timings for VEC modes
In reply to Greg Kroah-HartmanFrom: Mateusz Kwiatkowski <[email protected]>
[ Upstream commit 30d7565be96b3946c18a1ce3fd538f7946839092 ]
This commit fixes vertical timings of the VEC (composite output) modes to accurately represent the 525-line ("NTSC") and 625-line ("PAL") ITU-R standards.
Previous timings were actually defined as 502 and 601 lines, resulting in non-standard 62.69 Hz and 52 Hz signals being generated, respectively.
--- drivers/gpu/drm/vc4/vc4_vec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/vc4/vc4_vec.c +2 -2
@@ -256,7 +256,7 @@ static void vc4_vec_ntsc_j_mode_set(struct vc4_vec *vec)static const struct drm_display_mode ntsc_mode = {DRM_MODE ("720x480" ,DRM_MODE_TYPE_DRIVER ,13500 ,720 ,720 +14 ,720 +14 +64 ,720 +14 +64 +60 ,0 , -480 ,480 +3 ,480 +3 +3 ,480 +3 +3 +16 ,0 , +480 ,480 +7 ,480 +7 +6 ,525 ,0 ,DRM_MODE_FLAG_INTERLACE ) };
@@ -278,7 +278,7 @@ static void vc4_vec_pal_m_mode_set(struct vc4_vec *vec)static const struct drm_display_mode pal_mode = {DRM_MODE ("720x576" ,DRM_MODE_TYPE_DRIVER ,13500 ,720 ,720 +20 ,720 +20 +64 ,720 +20 +64 +60 ,0 , -576 ,576 +2 ,576 +2 +3 ,576 +2 +3 +20 ,0 , +576 ,576 +4 ,576 +4 +6 ,625 ,0 ,DRM_MODE_FLAG_INTERLACE ) };
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 215/255 drm: panel-orientation-quirks: Add quirk for Anbernic Win600
In reply to Greg Kroah-HartmanFrom: Maya Matuszczyk <[email protected]>
[ Upstream commit 770e19076065e079a32f33eb11be2057c87f1cde ]
This device is another x86 gaming handheld, and as (hopefully) there is only one set of DMI IDs it's using DMI_EXACT_MATCH
--- drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/gpu/drm/drm_panel_orientation_quirks.c +6 -0
@@ -128,6 +128,12 @@ static const struct dmi_system_id orientation_data[] = { DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "One S1003"), }, .driver_data = (void *)&lcd800x1280_rightside_up, + }, { /* Anbernic Win600 */ + .matches = { +DMI_EXACT_MATCH (DMI_BOARD_VENDOR ,"Anbernic" ), + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Win600"), + }, + .driver_data = (void *)&lcd720x1280_rightside_up, }, { /* Asus T100HA */ .matches = { DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 216/255 platform/x86: msi-laptop: Change DMI match / alias strings to fix module autoloading
In reply to Greg Kroah-HartmanFrom: Hans de Goede <[email protected]>
[ Upstream commit 2a2565272a3628e45d61625e36ef17af7af4e3de ]
On a MSI S270 with Fedora 37 x86_64 / systemd-251.4 the module does not properly autoload.
This is likely caused by issues with how systemd-udevd handles the single quote char (') which is part of the sys_vendor / chassis_vendor strings on this laptop. As a workaround remove the single quote char + everything behind it from the sys_vendor + chassis_vendor matches. This fixes the module not autoloading.
--- drivers/platform/x86/msi-laptop.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-)
drivers/platform/x86/msi-laptop.c +3 -5
@@ -596,11 +596,10 @@ static const struct dmi_system_id msi_dmi_table[] __initconst = { { .ident = "MSI S270", .matches = { -DMI_MATCH (DMI_SYS_VENDOR ,"MICRO-STAR INT'L CO.,LTD" ), +DMI_MATCH (DMI_SYS_VENDOR ,"MICRO-STAR INT" ),DMI_MATCH (DMI_PRODUCT_NAME ,"MS-1013" ),DMI_MATCH (DMI_PRODUCT_VERSION ,"0131" ), -DMI_MATCH (DMI_CHASSIS_VENDOR , -"MICRO-STAR INT'L CO.,LTD" ) +DMI_MATCH (DMI_CHASSIS_VENDOR ,"MICRO-STAR INT" ) }, .driver_data = &quirk_old_ec_model, .callback = dmi_check_cb
@@ -633,8 +632,7 @@ static const struct dmi_system_id msi_dmi_table[] __initconst = {DMI_MATCH (DMI_SYS_VENDOR ,"NOTEBOOK" ),DMI_MATCH (DMI_PRODUCT_NAME ,"SAM2000" ),DMI_MATCH (DMI_PRODUCT_VERSION ,"0131" ), -DMI_MATCH (DMI_CHASSIS_VENDOR , -"MICRO-STAR INT'L CO.,LTD" ) +DMI_MATCH (DMI_CHASSIS_VENDOR ,"MICRO-STAR INT" ) }, .driver_data = &quirk_old_ec_model, .callback = dmi_check_cb
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 217/255 drm/amdgpu: fix initial connector audio value
In reply to Greg Kroah-HartmanFrom: hongao <[email protected]>
[ Upstream commit 4bb71fce58f30df3f251118291d6b0187ce531e6 ]
This got lost somewhere along the way, This fixes
audio not working until set_property was called.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c +6 -1
@@ -1646,10 +1646,12 @@ amdgpu_connector_add(struct amdgpu_device *adev, adev->mode_info.dither_property, AMDGPU_FMT_DITHER_DISABLE); -if (amdgpu_audio !=0 ) +if (amdgpu_audio !=0 ) {drm_object_attach_property (&amdgpu_connector->base.base, adev->mode_info.audio_property,AMDGPU_AUDIO_AUTO ); + amdgpu_connector->audio =AMDGPU_AUDIO_AUTO ; + } subpixel_order = SubPixelHorizontalRGB; connector->interlace_allowed = true;
@@ -1771,6 +1773,7 @@ amdgpu_connector_add(struct amdgpu_device *adev,drm_object_attach_property (&amdgpu_connector->base.base, adev->mode_info.audio_property,AMDGPU_AUDIO_AUTO ); + amdgpu_connector->audio =AMDGPU_AUDIO_AUTO ; } drm_object_attach_property(&amdgpu_connector->base.base, adev->mode_info.dither_property,
@@ -1824,6 +1827,7 @@ amdgpu_connector_add(struct amdgpu_device *adev,drm_object_attach_property (&amdgpu_connector->base.base, adev->mode_info.audio_property,AMDGPU_AUDIO_AUTO ); + amdgpu_connector->audio =AMDGPU_AUDIO_AUTO ; } drm_object_attach_property(&amdgpu_connector->base.base, adev->mode_info.dither_property,
@@ -1874,6 +1878,7 @@ amdgpu_connector_add(struct amdgpu_device *adev,drm_object_attach_property (&amdgpu_connector->base.base, adev->mode_info.audio_property,AMDGPU_AUDIO_AUTO ); + amdgpu_connector->audio =AMDGPU_AUDIO_AUTO ; } drm_object_attach_property(&amdgpu_connector->base.base, adev->mode_info.dither_property,
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 218/255 mmc: sdhci-msm: add compatible string check for sdm670
In reply to Greg Kroah-HartmanFrom: Richard Acayan <[email protected]>
[ Upstream commit 4de95950d970c71a9e82a24573bb7a44fd95baa1 ]
The Snapdragon 670 has the same quirk as Snapdragon 845 (needing to restore the dll config). Add a compatible string check to detect the need for this.
--- drivers/mmc/host/sdhci-msm.c | 1 + 1 file changed, 1 insertion(+)
drivers/mmc/host/sdhci-msm.c +1 -0
@@ -1755,6 +1755,7 @@ static const struct sdhci_msm_variant_info sdm845_sdhci_var = {static const struct of_device_id sdhci_msm_dt_match[] = { {.compatible ="qcom,sdhci-msm-v4" , .data = &sdhci_msm_mci_var}, {.compatible ="qcom,sdhci-msm-v5" , .data = &sdhci_msm_v5_var}, + {.compatible ="qcom,sdm670-sdhci" , .data = &sdm845_sdhci_var}, {.compatible ="qcom,sdm845-sdhci" , .data = &sdm845_sdhci_var}, {}, };
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 219/255 ARM: dts: imx7d-sdb: config the max pressure for tsc2046
In reply to Greg Kroah-HartmanFrom: Haibo Chen <[email protected]>
[ Upstream commit e7c4ebe2f9cd68588eb24ba4ed122e696e2d5272 ]
Use the general touchscreen method to config the max pressure for touch tsc2046(data sheet suggest 8 bit pressure), otherwise, for ABS_PRESSURE, when config the same max and min value, weston will meet the following issue,
[17:19:39.183] event1 - ADS7846 Touchscreen: is tagged by udev as: Touchscreen [17:19:39.183] event1 - ADS7846 Touchscreen: kernel bug: device has min == max on ABS_PRESSURE [17:19:39.183] event1 - ADS7846 Touchscreen: was rejected [17:19:39.183] event1 - not using input device '/dev/input/event1'
This will then cause the APP weston-touch-calibrator can't list touch devices.
root@imx6ul7d:~# weston-touch-calibrator could not load cursor 'dnd-move' could not load cursor 'dnd-copy' could not load cursor 'dnd-none' No devices listed.
And accroding to binding Doc, "ti,x-max", "ti,y-max", "ti,pressure-max" belong to the deprecated properties, so remove them. Also for "ti,x-min", "ti,y-min", "ti,x-plate-ohms", the value set in dts equal to the default value in driver, so are redundant, also remove here.
--- arch/arm/boot/dts/imx7d-sdb.dts | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-)
arch/arm/boot/dts/imx7d-sdb.dts +1 -6
@@ -177,12 +177,7 @@ interrupt-parent = <&gpio2>; interrupts = <29 0>; pendown-gpio = <&gpio2 29 GPIO_ACTIVE_HIGH>; - ti,x-min = /bits/ 16 <0>; - ti,x-max = /bits/ 16 <0>; - ti,y-min = /bits/ 16 <0>; - ti,y-max = /bits/ 16 <0>; - ti,pressure-max = /bits/ 16 <0>; - ti,x-plate-ohms = /bits/ 16 <400>; + touchscreen-max-pressure = <255>; wakeup-source; }; };
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 220/255 ARM: dts: imx6q: add missing properties for sram
In reply to Greg Kroah-HartmanFrom: Alexander Stein <[email protected]>
[ Upstream commit b11d083c5dcec7c42fe982c854706d404ddd3a5f ]
All 3 properties are required by sram.yaml. Fixes the dtbs_check warning:
sram@900000: '#address-cells' is a required property sram@900000: '#size-cells' is a required property sram@900000: 'ranges' is a required property
--- arch/arm/boot/dts/imx6q.dtsi | 3 +++ 1 file changed, 3 insertions(+)
arch/arm/boot/dts/imx6q.dtsi +3 -0
@@ -158,6 +158,9 @@ ocram: sram@900000 { compatible = "mmio-sram"; reg = <0x00900000 0x40000>; + ranges = <0 0x00900000 0x40000>; + #address-cells = <1>; + #size-cells = <1>; clocks = <&clks IMX6QDL_CLK_OCRAM>; };
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 221/255 ARM: dts: imx6dl: add missing properties for sram
In reply to Greg Kroah-HartmanFrom: Alexander Stein <[email protected]>
[ Upstream commit f5848b95633d598bacf0500e0108dc5961af88c0 ]
All 3 properties are required by sram.yaml. Fixes the dtbs_check warning:
sram@900000: '#address-cells' is a required property sram@900000: '#size-cells' is a required property sram@900000: 'ranges' is a required property
--- arch/arm/boot/dts/imx6dl.dtsi | 3 +++ 1 file changed, 3 insertions(+)
arch/arm/boot/dts/imx6dl.dtsi +3 -0
@@ -81,6 +81,9 @@ ocram: sram@900000 { compatible = "mmio-sram"; reg = <0x00900000 0x20000>; + ranges = <0 0x00900000 0x20000>; + #address-cells = <1>; + #size-cells = <1>; clocks = <&clks IMX6QDL_CLK_OCRAM>; };
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 222/255 ARM: dts: imx6qp: add missing properties for sram
In reply to Greg Kroah-HartmanFrom: Alexander Stein <[email protected]>
[ Upstream commit 088fe5237435ee2f7ed4450519b2ef58b94c832f ]
All 3 properties are required by sram.yaml. Fixes the dtbs_check warning:
sram@940000: '#address-cells' is a required property sram@940000: '#size-cells' is a required property sram@940000: 'ranges' is a required property
--- arch/arm/boot/dts/imx6qp.dtsi | 6 ++++++ 1 file changed, 6 insertions(+)
arch/arm/boot/dts/imx6qp.dtsi +6 -0
@@ -9,12 +9,18 @@ ocram2: sram@940000 { compatible = "mmio-sram"; reg = <0x00940000 0x20000>; + ranges = <0 0x00940000 0x20000>; + #address-cells = <1>; + #size-cells = <1>; clocks = <&clks IMX6QDL_CLK_OCRAM>; }; ocram3: sram@960000 { compatible = "mmio-sram"; reg = <0x00960000 0x20000>; + ranges = <0 0x00960000 0x20000>; + #address-cells = <1>; + #size-cells = <1>; clocks = <&clks IMX6QDL_CLK_OCRAM>; };
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 223/255 ARM: dts: imx6sl: add missing properties for sram
In reply to Greg Kroah-HartmanFrom: Alexander Stein <[email protected]>
[ Upstream commit 60c9213a1d9941a8b33db570796c3f9be8984974 ]
All 3 properties are required by sram.yaml. Fixes the dtbs_check warning:
sram@900000: '#address-cells' is a required property sram@900000: '#size-cells' is a required property sram@900000: 'ranges' is a required property
--- arch/arm/boot/dts/imx6sl.dtsi | 3 +++ 1 file changed, 3 insertions(+)
arch/arm/boot/dts/imx6sl.dtsi +3 -0
@@ -121,6 +121,9 @@ ocram: sram@900000 { compatible = "mmio-sram"; reg = <0x00900000 0x20000>; + ranges = <0 0x00900000 0x20000>; + #address-cells = <1>; + #size-cells = <1>; clocks = <&clks IMX6SL_CLK_OCRAM>; };
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 224/255 ARM: dts: imx6sll: add missing properties for sram
In reply to Greg Kroah-HartmanFrom: Alexander Stein <[email protected]>
[ Upstream commit 7492a83ed9b7a151e2dd11d64b06da7a7f0fa7f9 ]
All 3 properties are required by sram.yaml. Fixes the dtbs_check warning:
sram@900000: '#address-cells' is a required property sram@900000: '#size-cells' is a required property sram@900000: 'ranges' is a required property
--- arch/arm/boot/dts/imx6sll.dtsi | 3 +++ 1 file changed, 3 insertions(+)
arch/arm/boot/dts/imx6sll.dtsi +3 -0
@@ -123,6 +123,9 @@ ocram: sram@900000 { compatible = "mmio-sram"; reg = <0x00900000 0x20000>; + ranges = <0 0x00900000 0x20000>; + #address-cells = <1>; + #size-cells = <1>; }; intc: interrupt-controller@a01000 {
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 225/255 ARM: dts: imx6sx: add missing properties for sram
In reply to Greg Kroah-HartmanFrom: Alexander Stein <[email protected]>
[ Upstream commit 415432c008b2bce8138841356ba444631cabaa50 ]
All 3 properties are required by sram.yaml. Fixes the dtbs_check warning:
sram@900000: '#address-cells' is a required property sram@900000: '#size-cells' is a required property sram@900000: 'ranges' is a required property
--- arch/arm/boot/dts/imx6sx.dtsi | 6 ++++++ 1 file changed, 6 insertions(+)
arch/arm/boot/dts/imx6sx.dtsi +6 -0
@@ -163,12 +163,18 @@ ocram_s: sram@8f8000 { compatible = "mmio-sram"; reg = <0x008f8000 0x4000>; + ranges = <0 0x008f8000 0x4000>; + #address-cells = <1>; + #size-cells = <1>; clocks = <&clks IMX6SX_CLK_OCRAM_S>; }; ocram: sram@900000 { compatible = "mmio-sram"; reg = <0x00900000 0x20000>; + ranges = <0 0x00900000 0x20000>; + #address-cells = <1>; + #size-cells = <1>; clocks = <&clks IMX6SX_CLK_OCRAM>; };
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 226/255 btrfs: scrub: try to fix super block errors
In reply to Greg Kroah-HartmanFrom: Qu Wenruo <[email protected]>
[ Upstream commit f9eab5f0bba76742af654f33d517bf62a0db8f12 ]
[BUG]
The following script shows that, although scrub can detect super block errors, it never tries to fix it:
mkfs.btrfs -f -d raid1 -m raid1 $dev1 $dev2 xfs_io -c "pwrite 67108864 4k" $dev2
mount $dev1 $mnt
btrfs scrub start -B $dev2
btrfs scrub start -Br $dev2
umount $mnt
The first scrub reports the super error correctly:
scrub done for f3289218-abd3-41ac-a630-202f766c0859
Scrub started: Tue Aug 2 14:44:11 2022
Status: finished
Duration: 0:00:00
Total to scrub: 1.26GiB
Rate: 0.00B/s
Error summary: super=1
Corrected: 0
Uncorrectable: 0
Unverified: 0But the second read-only scrub still reports the same super error:
Scrub started: Tue Aug 2 14:44:11 2022
Status: finished
Duration: 0:00:00
Total to scrub: 1.26GiB
Rate: 0.00B/s
Error summary: super=1
Corrected: 0
Uncorrectable: 0
Unverified: 0[CAUSE]
The comments already shows that super block can be easily fixed by committing a transaction:
/*
* If we find an error in a super block, we just report it.
* They will get written with the next transaction commit
* anyway
*/
But the truth is, such assumption is not always true, and since scrub should try to repair every error it found (except for read-only scrub), we should really actively commit a transaction to fix this.
[FIX]
Just commit a transaction if we found any super block errors, after everything else is done.
We cannot do this just after scrub_supers(), as btrfs_commit_transaction() will try to pause and wait for the running scrub, thus we can not call it with scrub_lock hold.
--- fs/btrfs/scrub.c | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+)
fs/btrfs/scrub.c +36 -0
@@ -3849,6 +3849,7 @@ int btrfs_scrub_dev(struct btrfs_fs_info *fs_info, u64 devid, u64 start,int ret;struct btrfs_device *dev;unsigned int nofs_flag; +bool need_commit = false;if (btrfs_fs_closing (fs_info))return -EAGAIN ;
@@ -3961,6 +3962,12 @@ int btrfs_scrub_dev(struct btrfs_fs_info *fs_info, u64 devid, u64 start,*/ nofs_flag =memalloc_nofs_save ();if (!is_dev_replace) { +u64 old_super_errors; + +spin_lock (&sctx->stat_lock); + old_super_errors = sctx->stat.super_errors; +spin_unlock (&sctx->stat_lock); +btrfs_info (fs_info,"scrub: started on devid %llu" , devid);/* * by holding device list mutex, we can
@@ -3969,6 +3976,16 @@ int btrfs_scrub_dev(struct btrfs_fs_info *fs_info, u64 devid, u64 start,mutex_lock (&fs_info->fs_devices->device_list_mutex); ret =scrub_supers (sctx, dev);mutex_unlock (&fs_info->fs_devices->device_list_mutex); + +spin_lock (&sctx->stat_lock); +/* +* Super block errors found, but we can not commit transaction +* at current context, since btrfs_commit_transaction() needs +* to pause the current running scrub (hold by ourselves). +*/ +if (sctx->stat.super_errors > old_super_errors && !sctx->readonly) + need_commit = true; +spin_unlock (&sctx->stat_lock); }if (!ret)
@@ -3995,6 +4012,25 @@ int btrfs_scrub_dev(struct btrfs_fs_info *fs_info, u64 devid, u64 start,scrub_workers_put (fs_info);scrub_put_ctx (sctx); +/* +* We found some super block errors before, now try to force a +* transaction commit, as scrub has finished. +*/ +if (need_commit) { +struct btrfs_trans_handle *trans; + + trans =btrfs_start_transaction (fs_info->tree_root,0 ); +if (IS_ERR (trans)) { + ret =PTR_ERR (trans); +btrfs_err (fs_info, +"scrub: failed to start transaction to fix super block errors: %d" , ret); +return ret; + } + ret =btrfs_commit_transaction (trans); +if (ret <0 ) +btrfs_err (fs_info, +"scrub: failed to commit transaction to fix super block errors: %d" , ret); + }return ret; out:scrub_workers_put (fs_info);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 227/255 clk: zynqmp: Fix stack-out-of-bounds in strncpy`
In reply to Greg Kroah-HartmanFrom: Ian Nam <[email protected]>
[ Upstream commit dd80fb2dbf1cd8751efbe4e53e54056f56a9b115 ]
"BUG: KASAN: stack-out-of-bounds in strncpy+0x30/0x68"
Linux-ATF interface is using 16 bytes of SMC payload. In case clock name is longer than 15 bytes, string terminated NULL character will not be received by Linux. Add explicit NULL character at last byte to fix issues when clock name is longer.
This fixes below bug reported by KASAN:
==================================================================
BUG: KASAN: stack-out-of-bounds in strncpy+0x30/0x68 Read of size 1 at addr ffff0008c89a7410 by task swapper/0/1 CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.4.0-00396-g81ef9e7-dirty #3 Hardware name: Xilinx Versal vck190 Eval board revA (QSPI) (DT) Call trace: dump_backtrace+0x0/0x1e8 show_stack+0x14/0x20 dump_stack+0xd4/0x108 print_address_description.isra.0+0xbc/0x37c __kasan_report+0x144/0x198 kasan_report+0xc/0x18 __asan_load1+0x5c/0x68 strncpy+0x30/0x68 zynqmp_clock_probe+0x238/0x7b8 platform_drv_probe+0x6c/0xc8 really_probe+0x14c/0x418 driver_probe_device+0x74/0x130 __device_attach_driver+0xc4/0xe8 bus_for_each_drv+0xec/0x150 __device_attach+0x160/0x1d8 device_initial_probe+0x10/0x18 bus_probe_device+0xe0/0xf0 device_add+0x528/0x950 of_device_add+0x5c/0x80 of_platform_device_create_pdata+0x120/0x168 of_platform_bus_create+0x244/0x4e0 of_platform_populate+0x50/0xe8 zynqmp_firmware_probe+0x370/0x3a8 platform_drv_probe+0x6c/0xc8 really_probe+0x14c/0x418 driver_probe_device+0x74/0x130 device_driver_attach+0x94/0xa0 __driver_attach+0x70/0x108 bus_for_each_dev+0xe4/0x158 driver_attach+0x30/0x40 bus_add_driver+0x21c/0x2b8 driver_register+0xbc/0x1d0 __platform_driver_register+0x7c/0x88 zynqmp_firmware_driver_init+0x1c/0x24 do_one_initcall+0xa4/0x234 kernel_init_freeable+0x1b0/0x24c kernel_init+0x10/0x110 ret_from_fork+0x10/0x18 The buggy address belongs to the page: page:ffff0008f9be1c88 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 raw: 0008d00000000000 ffff0008f9be1c90 ffff0008f9be1c90 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff page dumped because: kasan: bad access detected
addr ffff0008c89a7410 is located in stack of task swapper/0/1 at offset 112 in frame:
zynqmp_clock_probe+0x0/0x7b8
this frame has 3 objects:
[32, 44) 'response'
[64, 80) 'ret_payload'
[96, 112) 'name'
Memory state around the buggy address:
ffff0008c89a7300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff0008c89a7380: 00 00 00 00 f1 f1 f1 f1 00 04 f2 f2 00 00 f2 f2
>ffff0008c89a7400: 00 00 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
^
ffff0008c89a7480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff0008c89a7500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================--- drivers/clk/zynqmp/clkc.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/clk/zynqmp/clkc.c +7 -0
@@ -679,6 +679,13 @@ static void zynqmp_get_clock_info(void)FIELD_PREP (CLK_ATTR_NODE_INDEX , i);zynqmp_pm_clock_get_name (clock[i].clk_id, &name); + +/* +* Terminate with NULL character in case name provided by firmware +* is longer and truncated due to size limit. +*/ + name.name[sizeof (name.name) -1 ] ='\0' ; +if (!strcmp (name.name,RESERVED_CLK_NAME ))continue ;strncpy (clock[i].clk_name, name.name,MAX_NAME_LEN );
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 228/255 media: cx88: Fix a null-ptr-deref bug in buffer_prepare()
In reply to Greg Kroah-HartmanFrom: Zheyu Ma <[email protected]>
[ Upstream commit 2b064d91440b33fba5b452f2d1b31f13ae911d71 ]
When the driver calls cx88_risc_buffer() to prepare the buffer, the function call may fail, resulting in a empty buffer and null-ptr-deref later in buffer_queue().
The following log can reveal it:
[ 41.822762] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI [ 41.824488] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 41.828027] RIP: 0010:buffer_queue+0xc2/0x500 [ 41.836311] Call Trace: [ 41.836945] __enqueue_in_driver+0x141/0x360 [ 41.837262] vb2_start_streaming+0x62/0x4a0 [ 41.838216] vb2_core_streamon+0x1da/0x2c0 [ 41.838516] __vb2_init_fileio+0x981/0xbc0 [ 41.839141] __vb2_perform_fileio+0xbf9/0x1120 [ 41.840072] vb2_fop_read+0x20e/0x400 [ 41.840346] v4l2_read+0x215/0x290 [ 41.840603] vfs_read+0x162/0x4c0
Fix this by checking the return value of cx88_risc_buffer()
[hverkuil: fix coding style issues]
--- drivers/media/pci/cx88/cx88-vbi.c | 9 +++--- drivers/media/pci/cx88/cx88-video.c | 43 +++++++++++++++-------------- 2 files changed, 26 insertions(+), 26 deletions(-)
drivers/media/pci/cx88/cx88-vbi.c +4 -5
@@ -144,11 +144,10 @@ static int buffer_prepare(struct vb2_buffer *vb)return -EINVAL ;vb2_set_plane_payload (vb,0 , size); -cx88_risc_buffer (dev->pci, &buf->risc, sgt->sgl, -0 ,VBI_LINE_LENGTH * lines, -VBI_LINE_LENGTH ,0 , - lines); -return 0 ; +return cx88_risc_buffer (dev->pci, &buf->risc, sgt->sgl, +0 ,VBI_LINE_LENGTH * lines, +VBI_LINE_LENGTH ,0 , + lines); }static void buffer_finish (struct vb2_buffer *vb)
drivers/media/pci/cx88/cx88-video.c +22 -21
70 lines not on this page · raw message
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 229/255 clk: zynqmp: pll: rectify rate rounding in zynqmp_pll_round_rate
In reply to Greg Kroah-HartmanFrom: Quanyang Wang <[email protected]>
[ Upstream commit 30eaf02149ecc3c5815e45d27187bf09e925071d ]
The function zynqmp_pll_round_rate is used to find a most appropriate PLL frequency which the hardware can generate according to the desired frequency. For example, if the desired frequency is 297MHz, considering the limited range from PS_PLL_VCO_MIN (1.5GHz) to PS_PLL_VCO_MAX (3.0GHz) of PLL, zynqmp_pll_round_rate should return 1.872GHz (297MHz * 5).
There are two problems with the current code of zynqmp_pll_round_rate:
1) When the rate is below PS_PLL_VCO_MIN, it can't find a correct rate when the parameter "rate" is an integer multiple of *prate, in other words, if "f" is zero, zynqmp_pll_round_rate won't return a valid frequency which is from PS_PLL_VCO_MIN to PS_PLL_VCO_MAX. For example, *prate is 33MHz and the rate is 660MHz, zynqmp_pll_round_rate will not boost up rate and just return 660MHz, and this will cause clk_calc_new_rates failure since zynqmp_pll_round_rate returns an invalid rate out of its boundaries.
2) Even if the rate is higher than PS_PLL_VCO_MIN, there is still a risk that zynqmp_pll_round_rate returns an invalid rate because the function DIV_ROUND_CLOSEST makes some loss in the fractional part. If the parent clock *prate is 33333333Hz and we want to set the PLL rate to 1.5GHz, this function will return 1499999985Hz by using the formula below:
value = *prate * DIV_ROUND_CLOSEST(rate, *prate)).
This value is also invalid since it's slightly smaller than PS_PLL_VCO_MIN. because DIV_ROUND_CLOSEST makes some loss in the fractional part.
--- drivers/clk/zynqmp/pll.c | 31 +++++++++++++++---------------- 1 file changed, 15 insertions(+), 16 deletions(-)
drivers/clk/zynqmp/pll.c +15 -16
@@ -98,26 +98,25 @@ static long zynqmp_pll_round_rate(struct clk_hw *hw, unsigned long rate, unsigned long *prate) {u32 fbdiv; -long rate_div, f; +u32 mult, div; -/* Enable the fractional mode if needed */ - rate_div = (rate *FRAC_DIV ) / *prate; - f = rate_div %FRAC_DIV ; -if (f) { -if (rate >PS_PLL_VCO_MAX ) { - fbdiv = rate /PS_PLL_VCO_MAX ; - rate = rate / (fbdiv +1 ); - } -if (rate <PS_PLL_VCO_MIN ) { - fbdiv =DIV_ROUND_UP (PS_PLL_VCO_MIN , rate); - rate = rate * fbdiv; - } -return rate; +/* Let rate fall inside the range PS_PLL_VCO_MIN ~ PS_PLL_VCO_MAX */ +if (rate >PS_PLL_VCO_MAX ) { + div =DIV_ROUND_UP (rate,PS_PLL_VCO_MAX ); + rate = rate / div; + } +if (rate <PS_PLL_VCO_MIN ) { + mult =DIV_ROUND_UP (PS_PLL_VCO_MIN , rate); + rate = rate * mult; } fbdiv =DIV_ROUND_CLOSEST (rate, *prate); - fbdiv =clamp_t (u32, fbdiv,PLL_FBDIV_MIN ,PLL_FBDIV_MAX ); -return *prate * fbdiv; +if (fbdiv <PLL_FBDIV_MIN || fbdiv >PLL_FBDIV_MAX ) { + fbdiv =clamp_t (u32, fbdiv,PLL_FBDIV_MIN ,PLL_FBDIV_MAX ); + rate = *prate * fbdiv; + } + +return rate; }/**
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 230/255 scsi: 3w-9xxx: Avoid disabling device if failing to enable it
In reply to Greg Kroah-HartmanFrom: Letu Ren <[email protected]>
[ Upstream commit 7eff437b5ee1309b34667844361c6bbb5c97df05 ]
The original code will "goto out_disable_device" and call pci_disable_device() if pci_enable_device() fails. The kernel will generate a warning message like "3w-9xxx 0000:00:05.0: disabling already-disabled device".
We shouldn't disable a device that failed to be enabled. A simple return is fine.
--- drivers/scsi/3w-9xxx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/scsi/3w-9xxx.c +1 -1
@@ -2014,7 +2014,7 @@ static int twa_probe(struct pci_dev *pdev, const struct pci_device_id *dev_id) retval =pci_enable_device (pdev);if (retval) {TW_PRINTK (host,TW_DRIVER ,0x34 ,"Failed to enable pci device" ); - goto out_disable_device; +return -ENODEV ; }pci_set_master (pdev);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 231/255 nbd: Fix hung when signal interrupts nbd_start_device_ioctl()
In reply to Greg Kroah-HartmanFrom: Shigeru Yoshida <[email protected]>
[ Upstream commit 1de7c3cf48fc41cd95adb12bd1ea9033a917798a ]
syzbot reported hung task [1]. The following program is a simplified version of the reproducer:
int main(void)
{
int sv[2], fd;
if (socketpair(AF_UNIX, SOCK_STREAM, 0, sv) < 0)
return 1;
if ((fd = open("/dev/nbd0", 0)) < 0)
return 1;
if (ioctl(fd, NBD_SET_SIZE_BLOCKS, 0x81) < 0)
return 1;
if (ioctl(fd, NBD_SET_SOCK, sv[0]) < 0)
return 1;
if (ioctl(fd, NBD_DO_IT) < 0)
return 1;
return 0;
}When signal interrupt nbd_start_device_ioctl() waiting the condition atomic_read(&config->recv_threads) == 0, the task can hung because it waits the completion of the inflight IOs.
This patch fixes the issue by clearing queue, not just shutdown, when signal interrupt nbd_start_device_ioctl().
--- drivers/block/nbd.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/block/nbd.c +4 -2
@@ -1327,10 +1327,12 @@ static int nbd_start_device_ioctl(struct nbd_device *nbd, struct block_device *bmutex_unlock (&nbd->config_lock); ret =wait_event_interruptible (config->recv_wq,atomic_read (&config->recv_threads) ==0 ); -if (ret) +if (ret) {sock_shutdown (nbd); -flush_workqueue (nbd->recv_workq); +nbd_clear_que (nbd); + } +flush_workqueue (nbd->recv_workq);mutex_lock (&nbd->config_lock);nbd_bdev_reset (bdev);/* user requested, ignore socket errors */
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 232/255 power: supply: adp5061: fix out-of-bounds read in adp5061_get_chg_type()
In reply to Greg Kroah-HartmanFrom: Wei Yongjun <[email protected]>
[ Upstream commit 9d47e01b9d807808224347935562f7043a358054 ]
ADP5061_CHG_STATUS_1_CHG_STATUS is masked with 0x07, which means a length of 8, but adp5061_chg_type array size is 4, may end up reading 4 elements beyond the end of the adp5061_chg_type[] array.
--- drivers/power/supply/adp5061.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/power/supply/adp5061.c +3 -3
@@ -427,11 +427,11 @@ static int adp5061_get_chg_type(struct adp5061_state *st,if (ret <0 )return ret; - chg_type = adp5061_chg_type[ADP5061_CHG_STATUS_1_CHG_STATUS (status1)]; -if (chg_type >ADP5061_CHG_FAST_CV ) + chg_type =ADP5061_CHG_STATUS_1_CHG_STATUS (status1); +if (chg_type >=ARRAY_SIZE (adp5061_chg_type)) val->intval =POWER_SUPPLY_STATUS_UNKNOWN ;else - val->intval = chg_type; + val->intval = adp5061_chg_type[chg_type];return ret; }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 233/255 staging: vt6655: fix potential memory leak
In reply to Greg Kroah-HartmanFrom: Nam Cao <[email protected]>
[ Upstream commit c8ff91535880d41b49699b3829fb6151942de29e ]
In function device_init_td0_ring, memory is allocated for member td_info of priv->apTD0Rings[i], with i increasing from 0. In case of allocation failure, the memory is freed in reversed order, with i decreasing to 0. However, the case i=0 is left out and thus memory is leaked.
Modify the memory freeing loop to include the case i=0.
--- drivers/staging/vt6655/device_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/staging/vt6655/device_main.c +1 -1
@@ -670,7 +670,7 @@ static int device_init_td0_ring(struct vnt_private *priv)return 0 ; err_free_desc: -while (--i) { +while (i--) { desc = &priv->apTD0Rings[i];kfree (desc->td_info); }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 234/255 ata: libahci_platform: Sanity check the DT child nodes number
In reply to Greg Kroah-HartmanFrom: Serge Semin <[email protected]>
[ Upstream commit 3c132ea6508b34956e5ed88d04936983ec230601 ]
Having greater than AHCI_MAX_PORTS (32) ports detected isn't that critical from the further AHCI-platform initialization point of view since exceeding the ports upper limit will cause allocating more resources than will be used afterwards. But detecting too many child DT-nodes doesn't seem right since it's very unlikely to have it on an ordinary platform. In accordance with the AHCI specification there can't be more than 32 ports implemented at least due to having the CAP.NP field of 5 bits wide and the PI register of dword size. Thus if such situation is found the DTB must have been corrupted and the data read from it shouldn't be reliable. Let's consider that as an erroneous situation and halt further resources allocation.
Note it's logically more correct to have the nports set only after the initialization value is checked for being sane. So while at it let's make sure nports is assigned with a correct value.
--- drivers/ata/libahci_platform.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)
drivers/ata/libahci_platform.c +12 -2
@@ -451,14 +451,24 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev, } } - hpriv->nports = child_nodes =of_get_child_count (dev->of_node); +/* +* Too many sub-nodes most likely means having something wrong with +* the firmware. +*/ + child_nodes =of_get_child_count (dev->of_node); +if (child_nodes >AHCI_MAX_PORTS ) { + rc = -EINVAL ; + goto err_out; + }/* * If no sub-node was found, we still need to set nports to * one in order to be able to use the * ahci_platform_[en|dis]able_[phys|regulators] functions. */ -if (!child_nodes) +if (child_nodes) + hpriv->nports = child_nodes; +else hpriv->nports =1 ; hpriv->phys =devm_kcalloc (dev, hpriv->nports,sizeof (*hpriv->phys),GFP_KERNEL );
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 235/255 bcache: fix set_at_max_writeback_rate() for multiple attached devices
In reply to Greg Kroah-HartmanFrom: Coly Li <[email protected]>
[ Upstream commit d2d05b88035d2d51a5bb6c5afec88a0880c73df4 ]
Inside set_at_max_writeback_rate() the calculation in following if() check is wrong,
if (atomic_inc_return(&c->idle_counter) < atomic_read(&c->attached_dev_nr) * 6)
Because each attached backing device has its own writeback thread running and increasing c->idle_counter, the counter increates much faster than expected. The correct calculation should be,
(counter / dev_nr) < dev_nr * 6
which equals to,
counter < dev_nr * dev_nr * 6
This patch fixes the above mistake with correct calculation, and helper routine idle_counter_exceeded() is added to make code be more clear.
--- drivers/md/bcache/writeback.c | 73 +++++++++++++++++++++++++---------- 1 file changed, 52 insertions(+), 21 deletions(-)
drivers/md/bcache/writeback.c +52 -21
@@ -119,27 +119,61 @@ static void __update_writeback_rate(struct cached_dev *dc) dc->writeback_rate_target = target; } +static bool idle_counter_exceeded (struct cache_set *c) +{ +int counter, dev_nr; + +/* +* If c->idle_counter is overflow (idel for really long time), +* reset as 0 and not set maximum rate this time for code +* simplicity. +*/ + counter =atomic_inc_return (&c->idle_counter); +if (counter <=0 ) { +atomic_set (&c->idle_counter,0 ); +return false; + } + + dev_nr =atomic_read (&c->attached_dev_nr); +if (dev_nr ==0 ) +return false; + +/* +* c->idle_counter is increased by writeback thread of all +* attached backing devices, in order to represent a rough +* time period, counter should be divided by dev_nr. +* Otherwise the idle time cannot be larger with more backing +* device attached. +* The following calculation equals to checking +* (counter / dev_nr) < (dev_nr * 6) +*/ +if (counter < (dev_nr * dev_nr *6 )) +return false; + +return true; +} + +/* +* Idle_counter is increased every time when update_writeback_rate() is +* called. If all backing devices attached to the same cache set have +* identical dc->writeback_rate_update_seconds values, it is about 6 +* rounds of update_writeback_rate() on each backing device before +* c->at_max_writeback_rate is set to 1, and then max wrteback rate set +* to each dc->writeback_rate.rate. +* In order to avoid extra locking cost for counting exact dirty cached +* devices number, c->attached_dev_nr is used to calculate the idle +* throushold. It might be bigger if not all cached device are in write- +* back mode, but it still works well with limited extra rounds of +* update_writeback_rate(). +*/ static bool set_at_max_writeback_rate (struct cache_set *c,struct cached_dev *dc) {/* Don't set max writeback rate if gc is running */ if (!c->gc_mark_valid)return false; -/* -* Idle_counter is increased everytime when update_writeback_rate() is -* called. If all backing devices attached to the same cache set have -* identical dc->writeback_rate_update_seconds values, it is about 6 -* rounds of update_writeback_rate() on each backing device before -* c->at_max_writeback_rate is set to 1, and then max wrteback rate set -* to each dc->writeback_rate.rate. -* In order to avoid extra locking cost for counting exact dirty cached -* devices number, c->attached_dev_nr is used to calculate the idle -* throushold. It might be bigger if not all cached device are in write- -* back mode, but it still works well with limited extra rounds of -* update_writeback_rate(). -*/ -if (atomic_inc_return (&c->idle_counter) < -atomic_read (&c->attached_dev_nr) *6 ) + +if (!idle_counter_exceeded (c))return false;if (atomic_read (&c->at_max_writeback_rate) !=1 )
@@ -153,13 +187,10 @@ static bool set_at_max_writeback_rate(struct cache_set *c, dc->writeback_rate_change =0 ;/* -* Check c->idle_counter and c->at_max_writeback_rate agagain in case -* new I/O arrives during before set_at_max_writeback_rate() returns. -* Then the writeback rate is set to 1, and its new value should be -* decided via __update_writeback_rate(). +* In case new I/O arrives during before +* set_at_max_writeback_rate() returns. */ -if ((atomic_read (&c->idle_counter) < -atomic_read (&c->attached_dev_nr) *6 ) || +if (!idle_counter_exceeded (c) || !atomic_read (&c->at_max_writeback_rate))return false;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 236/255 HID: roccat: Fix use-after-free in roccat_read()
In reply to Greg Kroah-HartmanFrom: Hyunwoo Kim <[email protected]>
[ Upstream commit cacdb14b1c8d3804a3a7d31773bc7569837b71a4 ]
roccat_report_event() is responsible for registering roccat-related reports in struct roccat_device.
int roccat_report_event(int minor, u8 const *data)
{
struct roccat_device *device;
struct roccat_reader *reader;
struct roccat_report *report;
uint8_t *new_value;
device = devices[minor];
new_value = kmemdup(data, device->report_size, GFP_ATOMIC);
if (!new_value)
return -ENOMEM;
report = &device->cbuf[device->cbuf_end];
/* passing NULL is safe */
kfree(report->value);
...The registered report is stored in the struct roccat_device member "struct roccat_report cbuf[ROCCAT_CBUF_SIZE];".
If more reports are received than the "ROCCAT_CBUF_SIZE" value, kfree() the saved report from cbuf[0] and allocates a new reprot. Since there is no lock when this kfree() is performed, kfree() can be performed even while reading the saved report.
static ssize_t roccat_read(struct file *file, char __user *buffer,
size_t count, loff_t *ppos)
{
struct roccat_reader *reader = file->private_data;
struct roccat_device *device = reader->device;
struct roccat_report *report;
ssize_t retval = 0, len;
DECLARE_WAITQUEUE(wait, current);
mutex_lock(&device->cbuf_lock);
...
report = &device->cbuf[reader->cbuf_start];
/*
* If report is larger than requested amount of data, rest of report
* is lost!
*/
len = device->report_size > count ? count : device->report_size;
if (copy_to_user(buffer, report->value, len)) {
retval = -EFAULT;
goto exit_unlock;
}
...The roccat_read() function receives the device->cbuf report and delivers it to the user through copy_to_user().
If the N+ROCCAT_CBUF_SIZE th report is received while copying of the Nth report->value is in progress, the pointer that copy_to_user() is working on is kfree()ed and UAF read may occur. (race condition)
Since the device node of this driver does not set separate permissions, this is not a security vulnerability, but because it is used for requesting screen display of profile or dpi settings,
a user using the roccat device can apply udev to this device node or There is a possibility to use it by giving.
--- drivers/hid/hid-roccat.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/hid/hid-roccat.c +4 -0
@@ -257,6 +257,8 @@ int roccat_report_event(int minor, u8 const *data)if (!new_value)return -ENOMEM ; +mutex_lock (&device->cbuf_lock); + report = &device->cbuf[device->cbuf_end];/* passing NULL is safe */
@@ -276,6 +278,8 @@ int roccat_report_event(int minor, u8 const *data) reader->cbuf_start = (reader->cbuf_start +1 ) %ROCCAT_CBUF_SIZE ; } +mutex_unlock (&device->cbuf_lock); +wake_up_interruptible (&device->wait);return 0 ; }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 237/255 md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d
In reply to Greg Kroah-HartmanFrom: Logan Gunthorpe <[email protected]>
[ Upstream commit 5e2cf333b7bd5d3e62595a44d598a254c697cd74 ]
A complicated deadlock exists when using the journal and an elevated group_thrtead_cnt. It was found with loop devices, but its not clear whether it can be seen with real disks. The deadlock can occur simply by writing data with an fio script.
When the deadlock occurs, multiple threads will hang in different ways:
1) The group threads will hang in the blk-wbt code with bios waiting to
be submitted to the block layer:
io_schedule+0x70/0xb0
rq_qos_wait+0x153/0x210
wbt_wait+0x115/0x1b0
io_schedule+0x70/0xb0
rq_qos_wait+0x153/0x210
wbt_wait+0x115/0x1b0
__rq_qos_throttle+0x38/0x60
blk_mq_submit_bio+0x589/0xcd0
wbt_wait+0x115/0x1b0
__rq_qos_throttle+0x38/0x60
blk_mq_submit_bio+0x589/0xcd0
__submit_bio+0xe6/0x100
submit_bio_noacct_nocheck+0x42e/0x470
submit_bio_noacct+0x4c2/0xbb0
ops_run_io+0x46b/0x1a30
handle_stripe+0xcd3/0x36b0
handle_active_stripes.constprop.0+0x6f6/0xa60
raid5_do_work+0x177/0x330
Or:
io_schedule+0x70/0xb0
rq_qos_wait+0x153/0x210
wbt_wait+0x115/0x1b0
__rq_qos_throttle+0x38/0x60
blk_mq_submit_bio+0x589/0xcd0
__submit_bio+0xe6/0x100
submit_bio_noacct_nocheck+0x42e/0x470
submit_bio_noacct+0x4c2/0xbb0
flush_deferred_bios+0x136/0x170
raid5_do_work+0x262/0x330 2) The r5l_reclaim thread will hang in the same way, submitting a
bio to the block layer:
io_schedule+0x70/0xb0
rq_qos_wait+0x153/0x210
wbt_wait+0x115/0x1b0
__rq_qos_throttle+0x38/0x60
blk_mq_submit_bio+0x589/0xcd0
__submit_bio+0xe6/0x100
submit_bio_noacct_nocheck+0x42e/0x470
submit_bio_noacct+0x4c2/0xbb0
submit_bio+0x3f/0xf0
md_super_write+0x12f/0x1b0
md_update_sb.part.0+0x7c6/0xff0
md_update_sb+0x30/0x60
r5l_do_reclaim+0x4f9/0x5e0
r5l_reclaim_thread+0x69/0x30b
However, before hanging, the MD_SB_CHANGE_PENDING flag will be
set for sb_flags in r5l_write_super_and_discard_space(). This
flag will never be cleared because the submit_bio() call never
returns. 3) Due to the MD_SB_CHANGE_PENDING flag being set, handle_stripe() will do no processing on any pending stripes and re-set STRIPE_HANDLE. This will cause the raid5d thread to enter an infinite loop, constantly trying to handle the same stripes stuck in the queue.
The raid5d thread has a blk_plug that holds a number of bios that are also stuck waiting seeing the thread is in a loop that never schedules. These bios have been accounted for by blk-wbt thus preventing the other threads above from continuing when they try to submit bios. --Deadlock.
To fix this, add the same wait_event() that is used in raid5_do_work() to raid5d() such that if MD_SB_CHANGE_PENDING is set, the thread will schedule and wait until the flag is cleared. The schedule action will flush the plug which will allow the r5l_reclaim thread to continue, thus preventing the deadlock.
However, md_check_recovery() calls can also clear MD_SB_CHANGE_PENDING from the same thread and can thus deadlock if the thread is put to sleep. So avoid waiting if md_check_recovery() is being called in the loop.
It's not clear when the deadlock was introduced, but the similar wait_event() call in raid5_do_work() was added in 2017 by this commit:
16d997b78b15 ("md/raid5: simplfy delaying of writes while metadata
is updated.")
--- drivers/md/raid5.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
drivers/md/raid5.c +12 -0
@@ -36,6 +36,7 @@*/ #include <linux/blkdev.h> +#include <linux/delay.h> #include <linux/kthread.h> #include <linux/raid/pq.h> #include <linux/async_tx.h>
@@ -6334,7 +6335,18 @@ static void raid5d(struct md_thread *thread)spin_unlock_irq (&conf->device_lock);md_check_recovery (mddev);spin_lock_irq (&conf->device_lock); + +/* +* Waiting on MD_SB_CHANGE_PENDING below may deadlock +* seeing md_check_recovery() is needed to clear +* the flag when using mdmon. +*/ +continue ; } + +wait_event_lock_irq (mddev->sb_wait, + !test_bit (MD_SB_CHANGE_PENDING , &mddev->sb_flags), + conf->device_lock); }pr_debug ("%d stripes handled\n" , handled);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 238/255 usb: host: xhci: Fix potential memory leak in xhci_alloc_stream_info()
In reply to Greg Kroah-HartmanFrom: Jianglei Nie <[email protected]>
[ Upstream commit 7e271f42a5cc3768cd2622b929ba66859ae21f97 ]
xhci_alloc_stream_info() allocates stream context array for stream_info ->stream_ctx_array with xhci_alloc_stream_ctx(). When some error occurs, stream_info->stream_ctx_array is not released, which will lead to a memory leak.
We can fix it by releasing the stream_info->stream_ctx_array with xhci_free_stream_ctx() on the error path to avoid the potential memory leak.
--- drivers/usb/host/xhci-mem.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/usb/host/xhci-mem.c +6 -1
@@ -650,7 +650,7 @@ struct xhci_stream_info *xhci_alloc_stream_info(struct xhci_hcd *xhci, num_stream_ctxs, &stream_info->ctx_array_dma, mem_flags);if (!stream_info->stream_ctx_array) - goto cleanup_ctx; + goto cleanup_ring_array;memset (stream_info->stream_ctx_array,0 ,sizeof (struct xhci_stream_ctx )*num_stream_ctxs);
@@ -711,6 +711,11 @@ struct xhci_stream_info *xhci_alloc_stream_info(struct xhci_hcd *xhci, }xhci_free_command (xhci, stream_info->free_streams_command); cleanup_ctx: +xhci_free_stream_ctx (xhci, + stream_info->num_stream_ctxs, + stream_info->stream_ctx_array, + stream_info->ctx_array_dma); +cleanup_ring_array:kfree (stream_info->stream_rings); cleanup_info:kfree (stream_info);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 239/255 usb: musb: Fix musb_gadget.c rxstate overflow bug
In reply to Greg Kroah-HartmanFrom: Robin Guo <[email protected]>
[ Upstream commit eea4c860c3b366369eff0489d94ee4f0571d467d ]
The usb function device call musb_gadget_queue() adds the passed request to musb_ep::req_list,If the (request->length > musb_ep->packet_sz) and (is_buffer_mapped(req) return false),the rxstate() will copy all data in fifo to request->buf which may cause request->buf out of bounds.
Fix it by add the length check :
fifocnt = min_t(unsigned, request->length - request->actual, fifocnt);
--- drivers/usb/musb/musb_gadget.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/usb/musb/musb_gadget.c +3 -0
@@ -760,6 +760,9 @@ static void rxstate(struct musb *musb, struct musb_request *req)musb_writew (epio,MUSB_RXCSR , csr); buffer_aint_mapped: + fifo_count = min_t(unsigned int, + request->length - request->actual, + (unsigned int )fifo_count);musb_read_fifo (musb_ep->hw_ep, fifo_count, (u8 *) (request->buf + request->actual)); request->actual += fifo_count;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 240/255 Revert "usb: storage: Add quirk for Samsung Fit flash"
In reply to Greg Kroah-HartmanFrom: sunghwan jung <[email protected]>
[ Upstream commit ad5dbfc123e6ffbbde194e2a4603323e09f741ee ]
This reverts commit 86d92f5465958752481269348d474414dccb1552, which fix the timeout issue for "Samsung Fit Flash".
But the commit affects not only "Samsung Fit Flash" but also other usb storages that use the same controller and causes severe performance regression.
# hdparm -t /dev/sda (without the quirk) Timing buffered disk reads: 622 MB in 3.01 seconds = 206.66 MB/sec
# hdparm -t /dev/sda (with the quirk) Timing buffered disk reads: 220 MB in 3.00 seconds = 73.32 MB/sec
The commit author mentioned that "Issue was reproduced after device has bad block", so this quirk should be applied when we have the timeout issue with a device that has bad blocks.
We revert the commit so that we apply this quirk by adding kernel paramters using a bootloader or other ways when we really need it, without the performance regression with devices that don't have the issue.
--- drivers/usb/storage/unusual_devs.h | 6 ------ 1 file changed, 6 deletions(-)
drivers/usb/storage/unusual_devs.h +0 -6
@@ -1275,12 +1275,6 @@ UNUSUAL_DEV( 0x090a, 0x1200, 0x0000, 0x9999, USB_SC_RBC, USB_PR_BULK, NULL, 0 ), -UNUSUAL_DEV (0x090c ,0x1000 ,0x1100 ,0x1100 , -"Samsung" , -"Flash Drive FIT" , -USB_SC_DEVICE ,USB_PR_DEVICE ,NULL , -US_FL_MAX_SECTORS_64 ), -/* aeb */ UNUSUAL_DEV( 0x090c, 0x1132, 0x0000, 0xffff, "Feiya",
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 241/255 staging: rtl8723bs: fix a potential memory leak in rtw_init_cmd_priv()
In reply to Greg Kroah-HartmanFrom: Xiaoke Wang <[email protected]>
[ Upstream commit 708056fba733a73d926772ea4ce9a42d240345da ]
In rtw_init_cmd_priv(), if pcmdpriv->rsp_allocated_buf is allocated in failure, then pcmdpriv->cmd_allocated_buf will be not properly released. Besides, considering there are only two error paths and the first one can directly return, so we do not need implicitly jump to the exit tag to execute the error handler.
So this patch added kfree(pcmdpriv->cmd_allocated_buf); on the error path to release the resource and simplified the return logic of rtw_init_cmd_priv(). As there is no proper device to test with, no runtime testing was performed.
--- drivers/staging/rtl8723bs/core/rtw_cmd.c | 16 ++++++---------- 1 file changed, 6 insertions(+), 10 deletions(-)
drivers/staging/rtl8723bs/core/rtw_cmd.c +6 -10
@@ -165,8 +165,6 @@ No irqsave is necessary.int rtw_init_cmd_priv (struct cmd_priv *pcmdpriv) { -int res =0 ; -init_completion (&pcmdpriv->cmd_queue_comp);init_completion (&pcmdpriv->terminate_cmdthread_comp);
@@ -178,18 +176,16 @@ int rtw_init_cmd_priv(struct cmd_priv *pcmdpriv) pcmdpriv->cmd_allocated_buf =rtw_zmalloc (MAX_CMDSZ +CMDBUFF_ALIGN_SZ ); -if (!pcmdpriv->cmd_allocated_buf) { - res = -ENOMEM ; - goto exit; - } +if (!pcmdpriv->cmd_allocated_buf) +return -ENOMEM ; pcmdpriv->cmd_buf = pcmdpriv->cmd_allocated_buf +CMDBUFF_ALIGN_SZ - ((SIZE_PTR )(pcmdpriv->cmd_allocated_buf) & (CMDBUFF_ALIGN_SZ -1 )); pcmdpriv->rsp_allocated_buf =rtw_zmalloc (MAX_RSPSZ +4 );if (!pcmdpriv->rsp_allocated_buf) { - res = -ENOMEM ; - goto exit; +kfree (pcmdpriv->cmd_allocated_buf); +return -ENOMEM ; } pcmdpriv->rsp_buf = pcmdpriv->rsp_allocated_buf +4 - ((SIZE_PTR )(pcmdpriv->rsp_allocated_buf) &3 );
@@ -197,8 +193,8 @@ int rtw_init_cmd_priv(struct cmd_priv *pcmdpriv) pcmdpriv->cmd_issued_cnt = pcmdpriv->cmd_done_cnt = pcmdpriv->rsp_cnt =0 ;mutex_init (&pcmdpriv->sctx_mutex); -exit: -return res; + +return 0 ; }static void c2h_wk_callback (_workitem *work);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 242/255 nvme: copy firmware_rev on each init
In reply to Greg Kroah-HartmanFrom: Keith Busch <[email protected]>
[ Upstream commit a8eb6c1ba48bddea82e8d74cbe6e119f006be97d ]
The firmware revision can change on after a reset so copy the most recent info each time instead of just the first time, otherwise the sysfs firmware_rev entry may contain stale data.
--- drivers/nvme/host/core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/nvme/host/core.c +2 -1
@@ -2671,7 +2671,6 @@ static int nvme_init_subsystem(struct nvme_ctrl *ctrl, struct nvme_id_ctrl *id)nvme_init_subnqn (subsys, ctrl, id);memcpy (subsys->serial, id->sn,sizeof (subsys->serial));memcpy (subsys->model, id->mn,sizeof (subsys->model)); -memcpy (subsys->firmware_rev, id->fr,sizeof (subsys->firmware_rev)); subsys->vendor_id =le16_to_cpu (id->vid); subsys->cmic = id->cmic; subsys->awupf =le16_to_cpu (id->awupf);
@@ -2824,6 +2823,8 @@ int nvme_init_identify(struct nvme_ctrl *ctrl) ctrl->quirks |= core_quirks[i].quirks; } } +memcpy (ctrl->subsys->firmware_rev, id->fr, +sizeof (ctrl->subsys->firmware_rev));if (force_apst && (ctrl->quirks &NVME_QUIRK_NO_DEEPEST_PS )) {dev_warn (ctrl->device,"forcibly allowing all power states due to nvme_core.force_apst -- use at your own risk\n" );
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 243/255 nvmet-tcp: add bounds check on Transfer Tag
In reply to Greg Kroah-HartmanFrom: Varun Prakash <[email protected]>
[ Upstream commit b6a545ffa2c192b1e6da4a7924edac5ba9f4ea2b ]
ttag is used as an index to get cmd in nvmet_tcp_handle_h2c_data_pdu(), add a bounds check to avoid out-of-bounds access.
--- drivers/nvme/target/tcp.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
drivers/nvme/target/tcp.c +9 -2
@@ -858,10 +858,17 @@ static int nvmet_tcp_handle_h2c_data_pdu(struct nvmet_tcp_queue *queue)struct nvme_tcp_data_pdu *data = &queue->pdu.data;struct nvmet_tcp_cmd *cmd; -if (likely (queue->nr_cmds)) +if (likely (queue->nr_cmds)) { +if (unlikely (data->ttag >= queue->nr_cmds)) { +pr_err ("queue %d: received out of bound ttag %u, nr_cmds %u\n" , + queue->idx, data->ttag, queue->nr_cmds); +nvmet_tcp_fatal_error (queue); +return -EPROTO ; + } cmd = &queue->cmds[data->ttag]; -else + }else { cmd = &queue->connect; + }if (le32_to_cpu (data->data_offset) != cmd->rbytes_done) { pr_err("ttag %u unexpected data offset %u (expected %u)\n",
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 244/255 usb: idmouse: fix an uninit-value in idmouse_open
In reply to Greg Kroah-HartmanFrom: Dongliang Mu <[email protected]>
[ Upstream commit bce2b0539933e485d22d6f6f076c0fcd6f185c4c ]
In idmouse_create_image, if any ftip_command fails, it will go to the reset label. However, this leads to the data in bulk_in_buffer[HEADER..IMGSIZE] uninitialized. And the check for valid image incurs an uninitialized dereference.
Fix this by moving the check before reset label since this check only be valid if the data after bulk_in_buffer[HEADER] has concrete data.
Note that this is found by KMSAN, so only kernel compilation is tested.
--- drivers/usb/misc/idmouse.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/usb/misc/idmouse.c +4 -4
@@ -178,10 +178,6 @@ static int idmouse_create_image(struct usb_idmouse *dev) bytes_read += bulk_read; } -/* reset the device */ -reset: -ftip_command (dev,FTIP_RELEASE ,0 ,0 ); -/* check for valid image */ /* right border should be black (0x00) */ for (bytes_read =sizeof (HEADER )-1 +WIDTH -1 ; bytes_read <IMGSIZE ; bytes_read +=WIDTH )
@@ -193,6 +189,10 @@ static int idmouse_create_image(struct usb_idmouse *dev)if (dev->bulk_in_buffer[bytes_read] !=0xFF )return -EAGAIN ; +/* reset the device */ +reset: +ftip_command (dev,FTIP_RELEASE ,0 ,0 ); +/* should be IMGSIZE == 65040 */ dev_dbg (&dev->interface->dev,"read %d bytes fingerprint data\n" , bytes_read);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 245/255 clk: bcm2835: Make peripheral PLLC critical
In reply to Greg Kroah-HartmanFrom: Maxime Ripard <[email protected]>
[ Upstream commit 6c5422851d8be8c7451e968fd2e6da41b6109e17 ]
When testing for a series affecting the VEC, it was discovered that turning off and on the VEC clock is crashing the system.
It turns out that, when disabling the VEC clock, it's the only child of the PLLC-per clock which will also get disabled. The source of the crash is PLLC-per being disabled.
It's likely that some other device might not take a clock reference that it actually needs, but it's unclear which at this point. Let's make PLLC-per critical so that we don't have that crash.
--- drivers/clk/bcm/clk-bcm2835.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/bcm/clk-bcm2835.c +1 -1
@@ -1756,7 +1756,7 @@ static const struct bcm2835_clk_desc clk_desc_array[] = { .load_mask = CM_PLLC_LOADPER, .hold_mask = CM_PLLC_HOLDPER, .fixed_divider = 1, - .flags = CLK_SET_RATE_PARENT), + .flags = CLK_IS_CRITICAL | CLK_SET_RATE_PARENT),/* * PLLD is the display PLL, used to drive DSI display panels.
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 246/255 perf intel-pt: Fix segfault in intel_pt_print_info() with uClibc
In reply to Greg Kroah-HartmanFrom: Adrian Hunter <[email protected]>
commit 5a3d47071f0ced0431ef82a5fb6bd077ed9493db upstream.
uClibc segfaulted because NULL was passed as the format to fprintf().
That happened because one of the format strings was missing and intel_pt_print_info() didn't check that before calling fprintf().
Add the missing format string, and check format is not NULL before calling fprintf().
--- tools/perf/util/intel-pt.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
tools/perf/util/intel-pt.c +7 -2
@@ -3038,6 +3038,7 @@ static const char * const intel_pt_info_ [INTEL_PT_SNAPSHOT_MODE] = " Snapshot mode %"PRId64"\n", [INTEL_PT_PER_CPU_MMAPS] = " Per-cpu maps %"PRId64"\n", [INTEL_PT_MTC_BIT] = " MTC bit %#"PRIx64"\n", + [INTEL_PT_MTC_FREQ_BITS] = " MTC freq bits %#"PRIx64"\n", [INTEL_PT_TSC_CTC_N] = " TSC:CTC numerator %"PRIu64"\n", [INTEL_PT_TSC_CTC_D] = " TSC:CTC denominator %"PRIu64"\n", [INTEL_PT_CYC_BIT] = " CYC bit %#"PRIx64"\n",
@@ -3052,8 +3053,12 @@ static void intel_pt_print_info(__u64 *aif (!dump_trace)return ; -for (i = start; i <= finish; i++) -fprintf (stdout, intel_pt_info_fmts[i], arr[i]); +for (i = start; i <= finish; i++) { +const char *fmt = intel_pt_info_fmts[i]; + +if (fmt) +fprintf (stdout, fmt, arr[i]); + } }static void intel_pt_print_info_str (const char *name,const char *str)
Greg Kroah-Hartman
maintainerPATCH 247/255 io_uring/af_unix: defer registered files gc to io_uring release
In reply to Greg Kroah-HartmanFrom: Pavel Begunkov <[email protected]>
[ upstream commit 0091bfc81741b8d3aeb3b7ab8636f911b2de6e80 ]
Instead of putting io_uring's registered files in unix_gc() we want it to be done by io_uring itself. The trick here is to consider io_uring registered files for cycle detection but not actually putting them down. Because io_uring can't register other ring instances, this will remove all refs to the ring file triggering the ->release path and clean up with io_ring_ctx_free().
--- fs/io_uring.c | 1 + include/linux/skbuff.h | 2 ++ net/unix/garbage.c | 20 ++++++++++++++++++++ 3 files changed, 23 insertions(+)
fs/io_uring.c +1 -0
@@ -3172,6 +3172,7 @@ static int __io_sqe_files_scm(struct io_ } skb->sk = sk; + skb->scm_io_uring =1 ; skb->destructor = io_destruct_skb; fpl->user =get_uid (ctx->user);
include/linux/skbuff.h +2 -0
@@ -659,6 +659,7 @@ typedef unsigned char *sk_buff_data_t;* @wifi_acked: whether frame was acked on wifi or not * @no_fcs: Request NIC to treat last 4 bytes as Ethernet FCS * @csum_not_inet: use CRC32c to resolve CHECKSUM_PARTIAL +* @scm_io_uring: SKB holds io_uring registered files * @dst_pending_confirm: need to confirm neighbour * @decrypted: Decrypted SKB * @napi_id: id of the NAPI struct this skb came from
@@ -824,6 +825,7 @@ struct sk_buff {#ifdef CONFIG_TLS_DEVICE __u8 decrypted:1;#endif + __u8 scm_io_uring:1;#ifdef CONFIG_NET_SCHED __u16 tc_index;/* traffic control index */
net/unix/garbage.c +20 -0
@@ -204,6 +204,7 @@ void wait_for_unix_gc(void)/* The external entry point: unix_gc() */ void unix_gc (void ) { +struct sk_buff *next_skb, *skb;struct unix_sock *u;struct unix_sock *next;struct sk_buff_head hitlist;
@@ -297,11 +298,30 @@ void unix_gc(void)spin_unlock (&unix_gc_lock); +/* We need io_uring to clean its registered files, ignore all io_uring +* originated skbs. It's fine as io_uring doesn't keep references to +* other io_uring instances and so killing all other files in the cycle +* will put all io_uring references forcing it to go through normal +* release.path eventually putting registered files. +*/ + skb_queue_walk_safe(&hitlist, skb, next_skb) { +if (skb->scm_io_uring) { +__skb_unlink (skb, &hitlist); +skb_queue_tail (&skb->sk->sk_receive_queue, skb); + } + } +/* Here we are. Hitlist is filled. Die. */ __skb_queue_purge (&hitlist);spin_lock (&unix_gc_lock); +/* There could be io_uring registered files, just push them back to +* the inflight list +*/ +list_for_each_entry_safe (u, next, &gc_candidates, link) +list_move_tail (&u->link, &gc_inflight_list); +/* All candidates should have been detached by now. */ BUG_ON (!list_empty (&gc_candidates));
Quoted 10 lines
This is the start of the stable review cycle for the 5.4.220 release. There are 255 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 26 Oct 2022 11:29:24 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.220-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my x86_64 and ARM64 test systems. No errors or regressions.
Thanks.
Greg Kroah-Hartman
maintainerPATCH 248/255 net: ieee802154: return -EINVAL for unknown addr type
In reply to Greg Kroah-HartmanFrom: Alexander Aring <[email protected]>
commit 30393181fdbc1608cc683b4ee99dcce05ffcc8c7 upstream.
This patch adds handling to return -EINVAL for an unknown addr type. The current behaviour is to return 0 as successful but the size of an unknown addr type is not defined and should return an error like -EINVAL.
--- include/net/ieee802154_netdev.h | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
include/net/ieee802154_netdev.h +9 -3
@@ -185,21 +185,27 @@ static inline int ieee802154_sockaddr_check_size(struct sockaddr_ieee802154 *daddr, int len) {struct ieee802154_addr_sa *sa; +int ret =0 ; sa = &daddr->addr;if (len <IEEE802154_MIN_NAMELEN )return -EINVAL ;switch (sa->addr_type) { +case IEEE802154_ADDR_NONE : +break ;case IEEE802154_ADDR_SHORT :if (len <IEEE802154_NAMELEN_SHORT ) -return -EINVAL ; + ret = -EINVAL ;break ;case IEEE802154_ADDR_LONG :if (len <IEEE802154_NAMELEN_LONG ) -return -EINVAL ; + ret = -EINVAL ; +break ; +default : + ret = -EINVAL ;break ; } -return 0 ; +return ret; } static inline void ieee802154_addr_from_sa(struct ieee802154_addr *a,
Greg Kroah-Hartman
maintainerPATCH 249/255 Revert "net/ieee802154: reject zero-sized raw_sendmsg()"
In reply to Greg Kroah-HartmanFrom: Alexander Aring <[email protected]>
[ Upstream commit 2eb2756f6c9e9621e022d78321ce40a62c4520b5 ]
This reverts commit 3a4d061c699bd3eedc80dc97a4b2a2e1af83c6f5.
There is a v2 which does return zero if zero length is given.
--- net/ieee802154/socket.c | 3 --- 1 file changed, 3 deletions(-)
net/ieee802154/socket.c +0 -3
@@ -252,9 +252,6 @@ static int raw_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)return -EOPNOTSUPP ; } -if (!size) -return -EINVAL ; -lock_sock (sk);if (!sk->sk_bound_dev_if) dev =dev_getfirstbyhwtype (sock_net (sk),ARPHRD_IEEE802154 );
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 250/255 net/ieee802154: dont warn zero-sized raw_sendmsg()
In reply to Greg Kroah-HartmanFrom: Tetsuo Handa <[email protected]>
[ Upstream commit b12e924a2f5b960373459c8f8a514f887adf5cac ]
syzbot is hitting skb_assert_len() warning at __dev_queue_xmit() [1], for PF_IEEE802154 socket's zero-sized raw_sendmsg() request is hitting __dev_queue_xmit() with skb->len == 0.
Since PF_IEEE802154 socket's zero-sized raw_sendmsg() request was able to return 0, don't call __dev_queue_xmit() if packet length is 0.
----------
#include <sys/socket.h>
#include <netinet/in.h>
int main(int argc, char *argv[])
{
struct sockaddr_in addr = { .sin_family = AF_INET, .sin_addr.s_addr = htonl(INADDR_LOOPBACK) };
struct iovec iov = { };
struct msghdr hdr = { .msg_name = &addr, .msg_namelen = sizeof(addr), .msg_iov = &iov, .msg_iovlen = 1 };
sendmsg(socket(PF_IEEE802154, SOCK_RAW, 0), &hdr, 0);
return 0;
}
----------Note that this might be a sign that commit fd1894224407c484 ("bpf: Don't redirect packets with invalid pkt_len") should be reverted, for skb->len == 0 was acceptable for at least PF_IEEE802154 socket.
--- net/ieee802154/socket.c | 4 ++++ 1 file changed, 4 insertions(+)
net/ieee802154/socket.c +4 -0
@@ -273,6 +273,10 @@ static int raw_sendmsg(struct sock *sk, struct msghdr *msg, size_t size) err = -EMSGSIZE ; goto out_dev; } +if (!size) { + err =0 ; + goto out_dev; + } hlen =LL_RESERVED_SPACE (dev); tlen = dev->needed_tailroom;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 251/255 ext4: continue to expand file system when the target size doesnt reach
In reply to Greg Kroah-HartmanFrom: Jerry Lee 李修賢 <[email protected]>
commit df3cb754d13d2cd5490db9b8d536311f8413a92e upstream.
When expanding a file system from (16TiB-2MiB) to 18TiB, the operation exits early which leads to result inconsistency between resize2fs and Ext4 kernel driver.
=== before ===
○ → resize2fs /dev/mapper/thin
resize2fs 1.45.5 (07-Jan-2020)
Filesystem at /dev/mapper/thin is mounted on /mnt/test; on-line resizing required old_desc_blocks = 2048, new_desc_blocks = 2304
The filesystem on /dev/mapper/thin is now 4831837696 (4k) blocks long.
[ 865.186308] EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none. [ 912.091502] dm-4: detected capacity change from 34359738368 to 38654705664 [ 970.030550] dm-5: detected capacity change from 34359734272 to 38654701568 [ 1000.012751] EXT4-fs (dm-5): resizing filesystem from 4294966784 to 4831837696 blocks [ 1000.012878] EXT4-fs (dm-5): resized filesystem to 4294967296
=== after ===
[ 129.104898] EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none. [ 143.773630] dm-4: detected capacity change from 34359738368 to 38654705664 [ 198.203246] dm-5: detected capacity change from 34359734272 to 38654701568 [ 207.918603] EXT4-fs (dm-5): resizing filesystem from 4294966784 to 4831837696 blocks [ 207.918754] EXT4-fs (dm-5): resizing filesystem from 4294967296 to 4831837696 blocks [ 207.918758] EXT4-fs (dm-5): Converting file system to meta_bg [ 207.918790] EXT4-fs (dm-5): resizing filesystem from 4294967296 to 4831837696 blocks [ 221.454050] EXT4-fs (dm-5): resized to 4658298880 blocks [ 227.634613] EXT4-fs (dm-5): resized filesystem to 4831837696
--- fs/ext4/resize.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/ext4/resize.c +1 -1
@@ -2090,7 +2090,7 @@ retry: goto out; } -if (ext4_blocks_count (es) == n_blocks_count) +if (ext4_blocks_count (es) == n_blocks_count && n_blocks_count_retry ==0 ) goto out; err =ext4_alloc_flex_bg_array (sb, n_group +1 );
Greg Kroah-Hartman
maintainerPATCH 252/255 md: Replace snprintf with scnprintf
In reply to Greg Kroah-HartmanFrom: Saurabh Sengar <[email protected]>
commit 1727fd5015d8f93474148f94e34cda5aa6ad4a43 upstream.
Current code produces a warning as shown below when total characters in the constituent block device names plus the slashes exceeds 200. snprintf() returns the number of characters generated from the given input, which could cause the expression “200 – len” to wrap around to a large positive number. Fix this by using scnprintf() instead, which returns the actual number of characters written into the buffer.
[ 1513.267938] ------------[ cut here ]------------ [ 1513.267943] WARNING: CPU: 15 PID: 37247 at <snip>/lib/vsprintf.c:2509 vsnprintf+0x2c8/0x510 [ 1513.267944] Modules linked in: <snip> [ 1513.267969] CPU: 15 PID: 37247 Comm: mdadm Not tainted 5.4.0-1085-azure #90~18.04.1-Ubuntu [ 1513.267969] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022 [ 1513.267971] RIP: 0010:vsnprintf+0x2c8/0x510 <-snip-> [ 1513.267982] Call Trace: [ 1513.267986] snprintf+0x45/0x70 [ 1513.267990] ? disk_name+0x71/0xa0 [ 1513.267993] dump_zones+0x114/0x240 [raid0] [ 1513.267996] ? _cond_resched+0x19/0x40 [ 1513.267998] raid0_run+0x19e/0x270 [raid0] [ 1513.268000] md_run+0x5e0/0xc50 [ 1513.268003] ? security_capable+0x3f/0x60 [ 1513.268005] do_md_run+0x19/0x110 [ 1513.268006] md_ioctl+0x195e/0x1f90 [ 1513.268007] blkdev_ioctl+0x91f/0x9f0 [ 1513.268010] block_ioctl+0x3d/0x50 [ 1513.268012] do_vfs_ioctl+0xa9/0x640 [ 1513.268014] ? __fput+0x162/0x260 [ 1513.268016] ksys_ioctl+0x75/0x80 [ 1513.268017] __x64_sys_ioctl+0x1a/0x20 [ 1513.268019] do_syscall_64+0x5e/0x200 [ 1513.268021] entry_SYSCALL_64_after_hwframe+0x44/0xa9
--- drivers/md/raid0.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/md/raid0.c +2 -2
@@ -63,8 +63,8 @@ static void dump_zones(struct mddev *mddint len =0 ;for (k =0 ; k < conf->strip_zone[j].nb_dev; k++) - len +=snprintf (line+len,200 -len,"%s%s" , k?"/" :"" , -bdevname (conf->devlist[j*raid_disks + len +=scnprintf (line+len,200 -len,"%s%s" , k?"/" :"" , +bdevname (conf->devlist[j*raid_disks + k]->bdev, b));pr_debug ("md: zone%d=[%s]\n" , j, line);
Greg Kroah-Hartman
maintainerPATCH 253/255 efi: libstub: drop pointless get_memory_map() call
In reply to Greg Kroah-HartmanFrom: Ard Biesheuvel <[email protected]>
commit d80ca810f096ff66f451e7a3ed2f0cd9ef1ff519 upstream.
Currently, the non-x86 stub code calls get_memory_map() redundantly, given that the data it returns is never used anywhere. So drop the call.
--- drivers/firmware/efi/libstub/fdt.c | 8 -------- 1 file changed, 8 deletions(-)
drivers/firmware/efi/libstub/fdt.c +0 -8
@@ -291,14 +291,6 @@ efi_status_t allocate_new_fdt_and_exit_b goto fail; } -/* -* Now that we have done our final memory allocation (and free) -* we can get the memory map key needed for exit_boot_services(). -*/ - status =efi_get_memory_map (sys_table, &map); -if (status !=EFI_SUCCESS ) - goto fail_free_new_fdt; - status =update_fdt (sys_table, (void *)fdt_addr, fdt_size, (void *)*new_fdt_addr,MAX_FDT_SIZE , cmdline_ptr, initrd_addr, initrd_size);
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.220 release. There are 255 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 26 Oct 2022 11:29:24 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.220-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Greg Kroah-Hartman
maintainerPATCH 254/255 inet: fully convert sk->sk_rx_dst to RCU rules
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
commit 8f905c0e7354ef261360fb7535ea079b1082c105 upstream.
syzbot reported various issues around early demux, one being included in this changelog [1]
sk->sk_rx_dst is using RCU protection without clearly documenting it.
And following sequences in tcp_v4_do_rcv()/tcp_v6_do_rcv() are not following standard RCU rules.
[a] dst_release(dst);
[b] sk->sk_rx_dst = NULL;
They look wrong because a delete operation of RCU protected pointer is supposed to clear the pointer before
the call_rcu()/synchronize_rcu() guarding actual memory freeing.
In some cases indeed, dst could be freed before [b] is done.
We could cheat by clearing sk_rx_dst before calling dst_release(), but this seems the right time to stick to standard RCU annotations and debugging facilities.
[1]
BUG: KASAN: use-after-free in dst_check include/net/dst.h:470 [inline]
BUG: KASAN: use-after-free in tcp_v4_early_demux+0x95b/0x960 net/ipv4/tcp_ipv4.c:1792
Read of size 2 at addr ffff88807f1cb73a by task syz-executor.5/9204
CPU: 0 PID: 9204 Comm: syz-executor.5 Not tainted 5.16.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_address_description.constprop.0.cold+0x8d/0x320 mm/kasan/report.c:247
__kasan_report mm/kasan/report.c:433 [inline]
kasan_report.cold+0x83/0xdf mm/kasan/report.c:450
dst_check include/net/dst.h:470 [inline]
tcp_v4_early_demux+0x95b/0x960 net/ipv4/tcp_ipv4.c:1792
ip_rcv_finish_core.constprop.0+0x15de/0x1e80 net/ipv4/ip_input.c:340
ip_list_rcv_finish.constprop.0+0x1b2/0x6e0 net/ipv4/ip_input.c:583
ip_sublist_rcv net/ipv4/ip_input.c:609 [inline]
ip_list_rcv+0x34e/0x490 net/ipv4/ip_input.c:644
__netif_receive_skb_list_ptype net/core/dev.c:5508 [inline]
__netif_receive_skb_list_core+0x549/0x8e0 net/core/dev.c:5556
__netif_receive_skb_list net/core/dev.c:5608 [inline]
netif_receive_skb_list_internal+0x75e/0xd80 net/core/dev.c:5699
gro_normal_list net/core/dev.c:5853 [inline]
gro_normal_list net/core/dev.c:5849 [inline]
napi_complete_done+0x1f1/0x880 net/core/dev.c:6590
virtqueue_napi_complete drivers/net/virtio_net.c:339 [inline]
virtnet_poll+0xca2/0x11b0 drivers/net/virtio_net.c:1557
__napi_poll+0xaf/0x440 net/core/dev.c:7023
napi_poll net/core/dev.c:7090 [inline]
net_rx_action+0x801/0xb40 net/core/dev.c:7177
__do_softirq+0x29b/0x9c2 kernel/softirq.c:558
invoke_softirq kernel/softirq.c:432 [inline]
__irq_exit_rcu+0x123/0x180 kernel/softirq.c:637
irq_exit_rcu+0x5/0x20 kernel/softirq.c:649
common_interrupt+0x52/0xc0 arch/x86/kernel/irq.c:240
asm_common_interrupt+0x1e/0x40 arch/x86/include/asm/idtentry.h:629
RIP: 0033:0x7f5e972bfd57
Code: 39 d1 73 14 0f 1f 80 00 00 00 00 48 8b 50 f8 48 83 e8 08 48 39 ca 77 f3 48 39 c3 73 3e 48 89 13 48 8b 50 f8 48 89 38 49 8b 0e <48> 8b 3e 48 83 c3 08 48 83 c6 08 eb bc 48 39 d1 72 9e 48 39 d0 73
RSP: 002b:00007fff8a413210 EFLAGS: 00000283
RAX: 00007f5e97108990 RBX: 00007f5e97108338 RCX: ffffffff81d3aa45
RDX: ffffffff81d3aa45 RSI: 00007f5e97108340 RDI: ffffffff81d3aa45
RBP: 00007f5e97107eb8 R08: 00007f5e97108d88 R09: 0000000093c2e8d9
R10: 0000000000000000 R11: 0000000000000000 R12: 00007f5e97107eb0
R13: 00007f5e97108338 R14: 00007f5e97107ea8 R15: 0000000000000019
</TASK>
Allocated by task 13:
kasan_save_stack+0x1e/0x50 mm/kasan/common.c:38
kasan_set_track mm/kasan/common.c:46 [inline]
set_alloc_info mm/kasan/common.c:434 [inline]
__kasan_slab_alloc+0x90/0xc0 mm/kasan/common.c:467
kasan_slab_alloc include/linux/kasan.h:259 [inline]
slab_post_alloc_hook mm/slab.h:519 [inline]
slab_alloc_node mm/slub.c:3234 [inline]
slab_alloc mm/slub.c:3242 [inline]
kmem_cache_alloc+0x202/0x3a0 mm/slub.c:3247
dst_alloc+0x146/0x1f0 net/core/dst.c:92
rt_dst_alloc+0x73/0x430 net/ipv4/route.c:1613
ip_route_input_slow+0x1817/0x3a20 net/ipv4/route.c:2340
ip_route_input_rcu net/ipv4/route.c:2470 [inline]
ip_route_input_noref+0x116/0x2a0 net/ipv4/route.c:2415
ip_rcv_finish_core.constprop.0+0x288/0x1e80 net/ipv4/ip_input.c:354
ip_list_rcv_finish.constprop.0+0x1b2/0x6e0 net/ipv4/ip_input.c:583
ip_sublist_rcv net/ipv4/ip_input.c:609 [inline]
ip_list_rcv+0x34e/0x490 net/ipv4/ip_input.c:644
__netif_receive_skb_list_ptype net/core/dev.c:5508 [inline]
__netif_receive_skb_list_core+0x549/0x8e0 net/core/dev.c:5556
__netif_receive_skb_list net/core/dev.c:5608 [inline]
netif_receive_skb_list_internal+0x75e/0xd80 net/core/dev.c:5699
gro_normal_list net/core/dev.c:5853 [inline]
gro_normal_list net/core/dev.c:5849 [inline]
napi_complete_done+0x1f1/0x880 net/core/dev.c:6590
virtqueue_napi_complete drivers/net/virtio_net.c:339 [inline]
virtnet_poll+0xca2/0x11b0 drivers/net/virtio_net.c:1557
__napi_poll+0xaf/0x440 net/core/dev.c:7023
napi_poll net/core/dev.c:7090 [inline]
net_rx_action+0x801/0xb40 net/core/dev.c:7177
__do_softirq+0x29b/0x9c2 kernel/softirq.c:558
Freed by task 13:
kasan_save_stack+0x1e/0x50 mm/kasan/common.c:38
kasan_set_track+0x21/0x30 mm/kasan/common.c:46
kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370
____kasan_slab_free mm/kasan/common.c:366 [inline]
____kasan_slab_free mm/kasan/common.c:328 [inline]
__kasan_slab_free+0xff/0x130 mm/kasan/common.c:374
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:1723 [inline]
slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1749
slab_free mm/slub.c:3513 [inline]
kmem_cache_free+0xbd/0x5d0 mm/slub.c:3530
dst_destroy+0x2d6/0x3f0 net/core/dst.c:127
rcu_do_batch kernel/rcu/tree.c:2506 [inline]
rcu_core+0x7ab/0x1470 kernel/rcu/tree.c:2741
__do_softirq+0x29b/0x9c2 kernel/softirq.c:558
Last potentially related work creation:
kasan_save_stack+0x1e/0x50 mm/kasan/common.c:38
__kasan_record_aux_stack+0xf5/0x120 mm/kasan/generic.c:348
__call_rcu kernel/rcu/tree.c:2985 [inline]
call_rcu+0xb1/0x740 kernel/rcu/tree.c:3065
dst_release net/core/dst.c:177 [inline]
dst_release+0x79/0xe0 net/core/dst.c:167
tcp_v4_do_rcv+0x612/0x8d0 net/ipv4/tcp_ipv4.c:1712
sk_backlog_rcv include/net/sock.h:1030 [inline]
__release_sock+0x134/0x3b0 net/core/sock.c:2768
release_sock+0x54/0x1b0 net/core/sock.c:3300
tcp_sendmsg+0x36/0x40 net/ipv4/tcp.c:1441
inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819
sock_sendmsg_nosec net/socket.c:704 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:724
sock_write_iter+0x289/0x3c0 net/socket.c:1057
call_write_iter include/linux/fs.h:2162 [inline]
new_sync_write+0x429/0x660 fs/read_write.c:503
vfs_write+0x7cd/0xae0 fs/read_write.c:590
ksys_write+0x1ee/0x250 fs/read_write.c:643
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
The buggy address belongs to the object at ffff88807f1cb700
which belongs to the cache ip_dst_cache of size 176
The buggy address is located 58 bytes inside of
176-byte region [ffff88807f1cb700, ffff88807f1cb7b0)
The buggy address belongs to the page:
page:ffffea0001fc72c0 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x7f1cb
flags: 0xfff00000000200(slab|node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000000200 dead000000000100 dead000000000122 ffff8881413bb780
raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112a20(GFP_ATOMIC|__GFP_NOWARN|__GFP_NORETRY|__GFP_HARDWALL), pid 5, ts 108466983062, free_ts 108048976062
prep_new_page mm/page_alloc.c:2418 [inline]
get_page_from_freelist+0xa72/0x2f50 mm/page_alloc.c:4149
__alloc_pages+0x1b2/0x500 mm/page_alloc.c:5369
alloc_pages+0x1a7/0x300 mm/mempolicy.c:2191
alloc_slab_page mm/slub.c:1793 [inline]
allocate_slab mm/slub.c:1930 [inline]
new_slab+0x32d/0x4a0 mm/slub.c:1993
___slab_alloc+0x918/0xfe0 mm/slub.c:3022
__slab_alloc.constprop.0+0x4d/0xa0 mm/slub.c:3109
slab_alloc_node mm/slub.c:3200 [inline]
slab_alloc mm/slub.c:3242 [inline]
kmem_cache_alloc+0x35c/0x3a0 mm/slub.c:3247
dst_alloc+0x146/0x1f0 net/core/dst.c:92
rt_dst_alloc+0x73/0x430 net/ipv4/route.c:1613
__mkroute_output net/ipv4/route.c:2564 [inline]
ip_route_output_key_hash_rcu+0x921/0x2d00 net/ipv4/route.c:2791
ip_route_output_key_hash+0x18b/0x300 net/ipv4/route.c:2619
__ip_route_output_key include/net/route.h:126 [inline]
ip_route_output_flow+0x23/0x150 net/ipv4/route.c:2850
ip_route_output_key include/net/route.h:142 [inline]
geneve_get_v4_rt+0x3a6/0x830 drivers/net/geneve.c:809
geneve_xmit_skb drivers/net/geneve.c:899 [inline]
geneve_xmit+0xc4a/0x3540 drivers/net/geneve.c:1082
__netdev_start_xmit include/linux/netdevice.h:4994 [inline]
netdev_start_xmit include/linux/netdevice.h:5008 [inline]
xmit_one net/core/dev.c:3590 [inline]
dev_hard_start_xmit+0x1eb/0x920 net/core/dev.c:3606
__dev_queue_xmit+0x299a/0x3650 net/core/dev.c:4229
page last free stack trace:
reset_page_owner include/linux/page_owner.h:24 [inline]
free_pages_prepare mm/page_alloc.c:1338 [inline]
free_pcp_prepare+0x374/0x870 mm/page_alloc.c:1389
free_unref_page_prepare mm/page_alloc.c:3309 [inline]
free_unref_page+0x19/0x690 mm/page_alloc.c:3388
qlink_free mm/kasan/quarantine.c:146 [inline]
qlist_free_all+0x5a/0xc0 mm/kasan/quarantine.c:165
kasan_quarantine_reduce+0x180/0x200 mm/kasan/quarantine.c:272
__kasan_slab_alloc+0xa2/0xc0 mm/kasan/common.c:444
kasan_slab_alloc include/linux/kasan.h:259 [inline]
slab_post_alloc_hook mm/slab.h:519 [inline]
slab_alloc_node mm/slub.c:3234 [inline]
kmem_cache_alloc_node+0x255/0x3f0 mm/slub.c:3270
__alloc_skb+0x215/0x340 net/core/skbuff.c:414
alloc_skb include/linux/skbuff.h:1126 [inline]
alloc_skb_with_frags+0x93/0x620 net/core/skbuff.c:6078
sock_alloc_send_pskb+0x783/0x910 net/core/sock.c:2575
mld_newpack+0x1df/0x770 net/ipv6/mcast.c:1754
add_grhead+0x265/0x330 net/ipv6/mcast.c:1857
add_grec+0x1053/0x14e0 net/ipv6/mcast.c:1995
mld_send_initial_cr.part.0+0xf6/0x230 net/ipv6/mcast.c:2242
mld_send_initial_cr net/ipv6/mcast.c:1232 [inline]
mld_dad_work+0x1d3/0x690 net/ipv6/mcast.c:2268
process_one_work+0x9b2/0x1690 kernel/workqueue.c:2298
worker_thread+0x658/0x11f0 kernel/workqueue.c:2445
Memory state around the buggy address:
ffff88807f1cb600: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88807f1cb680: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc
>ffff88807f1cb700: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88807f1cb780: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc
ffff88807f1cb800: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb--- include/net/sock.h | 2 +- net/ipv4/af_inet.c | 2 +- net/ipv4/tcp.c | 3 +-- net/ipv4/tcp_input.c | 2 +- net/ipv4/tcp_ipv4.c | 11 +++++++---- net/ipv4/udp.c | 6 +++--- net/ipv6/tcp_ipv6.c | 11 +++++++---- net/ipv6/udp.c | 4 ++-- 8 files changed, 23 insertions(+), 18 deletions(-)
include/net/sock.h +1 -1
@@ -399,7 +399,7 @@ struct sock {#ifdef CONFIG_XFRM struct xfrm_policy __rcu *sk_policy[2 ];#endif -struct dst_entry *sk_rx_dst; +struct dst_entry __rcu *sk_rx_dst;struct dst_entry __rcu *sk_dst_cache;atomic_t sk_omem_alloc;int sk_sndbuf;
net/ipv4/af_inet.c +1 -1
@@ -157,7 +157,7 @@ void inet_sock_destruct(struct sock *sk)kfree (rcu_dereference_protected (inet->inet_opt,1 ));dst_release (rcu_dereference_protected (sk->sk_dst_cache,1 )); -dst_release (sk->sk_rx_dst); +dst_release (rcu_dereference_protected (sk->sk_rx_dst,1 ));sk_refcnt_debug_dec (sk); }EXPORT_SYMBOL (inet_sock_destruct);
net/ipv4/tcp.c +1 -2
@@ -2654,8 +2654,7 @@ int tcp_disconnect(struct sock *sk, int icsk->icsk_ack.rcv_mss =TCP_MIN_MSS ;memset (&tp->rx_opt,0 ,sizeof (tp->rx_opt));__sk_dst_reset (sk); -dst_release (sk->sk_rx_dst); - sk->sk_rx_dst =NULL ; +dst_release (xchg ((__force struct dst_entry **)&sk->sk_rx_dst,NULL ));tcp_saved_syn_free (tp); tp->compressed_ack =0 ; tp->segs_in =0 ;
net/ipv4/tcp_input.c +1 -1
@@ -5616,7 +5616,7 @@ void tcp_rcv_established(struct sock *sktrace_tcp_probe (sk, skb);tcp_mstamp_refresh (tp); -if (unlikely (!sk->sk_rx_dst)) +if (unlikely (!rcu_access_pointer (sk->sk_rx_dst)))inet_csk (sk)->icsk_af_ops->sk_rx_dst_set (sk, skb);/* * Header prediction.
net/ipv4/tcp_ipv4.c +7 -4
@@ -1570,15 +1570,18 @@ int tcp_v4_do_rcv(struct sock *sk, strucstruct sock *rsk;if (sk->sk_state ==TCP_ESTABLISHED ) {/* Fast path */ -struct dst_entry *dst = sk->sk_rx_dst; +struct dst_entry *dst; + + dst =rcu_dereference_protected (sk->sk_rx_dst, +lockdep_sock_is_held (sk));sock_rps_save_rxhash (sk, skb);sk_mark_napi_id (sk, skb);if (dst) {if (inet_sk (sk)->rx_dst_ifindex != skb->skb_iif || !dst->ops->check (dst,0 )) { +RCU_INIT_POINTER (sk->sk_rx_dst,NULL );dst_release (dst); - sk->sk_rx_dst =NULL ; } }tcp_rcv_established (sk, skb);
@@ -1653,7 +1656,7 @@ int tcp_v4_early_demux(struct sk_buff *s skb->sk = sk; skb->destructor = sock_edemux;if (sk_fullsock (sk)) { -struct dst_entry *dst =READ_ONCE (sk->sk_rx_dst); +struct dst_entry *dst =rcu_dereference (sk->sk_rx_dst);if (dst) dst =dst_check (dst,0 );
@@ -2059,7 +2062,7 @@ void inet_sk_rx_dst_set(struct sock *sk,struct dst_entry *dst =skb_dst (skb);if (dst &&dst_hold_safe (dst)) { - sk->sk_rx_dst = dst; +rcu_assign_pointer (sk->sk_rx_dst, dst);inet_sk (sk)->rx_dst_ifindex = skb->skb_iif; } }
net/ipv4/udp.c +3 -3
@@ -2137,7 +2137,7 @@ bool udp_sk_rx_dst_set(struct sock *sk,struct dst_entry *old;if (dst_hold_safe (dst)) { - old =xchg (&sk->sk_rx_dst, dst); + old =xchg ((__force struct dst_entry **)&sk->sk_rx_dst, dst);dst_release (old);return old != dst; }
@@ -2326,7 +2326,7 @@ int __udp4_lib_rcv(struct sk_buff *skb,struct dst_entry *dst =skb_dst (skb);int ret; -if (unlikely (sk->sk_rx_dst != dst)) +if (unlikely (rcu_dereference (sk->sk_rx_dst) != dst))udp_sk_rx_dst_set (sk, dst); ret =udp_unicast_rcv_skb (sk, skb, uh);
@@ -2484,7 +2484,7 @@ int udp_v4_early_demux(struct sk_buff *s skb->sk = sk; skb->destructor = sock_efree; - dst =READ_ONCE (sk->sk_rx_dst); + dst =rcu_dereference (sk->sk_rx_dst);if (dst) dst =dst_check (dst,0 );
net/ipv6/tcp_ipv6.c +7 -4
@@ -106,7 +106,7 @@ static void inet6_sk_rx_dst_set(struct sif (dst &&dst_hold_safe (dst)) {const struct rt6_info *rt = (const struct rt6_info *)dst; - sk->sk_rx_dst = dst; +rcu_assign_pointer (sk->sk_rx_dst, dst);inet_sk (sk)->rx_dst_ifindex = skb->skb_iif;tcp_inet6_sk (sk)->rx_dst_cookie =rt6_get_cookie (rt); }
@@ -1394,15 +1394,18 @@ static int tcp_v6_do_rcv(struct sock *sk opt_skb =skb_clone (skb,sk_gfp_mask (sk,GFP_ATOMIC ));if (sk->sk_state ==TCP_ESTABLISHED ) {/* Fast path */ -struct dst_entry *dst = sk->sk_rx_dst; +struct dst_entry *dst; + + dst =rcu_dereference_protected (sk->sk_rx_dst, +lockdep_sock_is_held (sk));sock_rps_save_rxhash (sk, skb);sk_mark_napi_id (sk, skb);if (dst) {if (inet_sk (sk)->rx_dst_ifindex != skb->skb_iif || dst->ops->check (dst, np->rx_dst_cookie) ==NULL ) { +RCU_INIT_POINTER (sk->sk_rx_dst,NULL );dst_release (dst); - sk->sk_rx_dst =NULL ; } }
@@ -1753,7 +1756,7 @@ INDIRECT_CALLABLE_SCOPE void tcp_v6_earl skb->sk = sk; skb->destructor = sock_edemux;if (sk_fullsock (sk)) { -struct dst_entry *dst =READ_ONCE (sk->sk_rx_dst); +struct dst_entry *dst =rcu_dereference (sk->sk_rx_dst);if (dst) dst =dst_check (dst,tcp_inet6_sk (sk)->rx_dst_cookie);
net/ipv6/udp.c +2 -2
@@ -889,7 +889,7 @@ int __udp6_lib_rcv(struct sk_buff *skb,struct dst_entry *dst =skb_dst (skb);int ret; -if (unlikely (sk->sk_rx_dst != dst)) +if (unlikely (rcu_dereference (sk->sk_rx_dst) != dst))udp6_sk_rx_dst_set (sk, dst);if (!uh->check && !udp_sk (sk)->no_check6_rx) {
@@ -1001,7 +1001,7 @@ INDIRECT_CALLABLE_SCOPE void udp_v6_earl skb->sk = sk; skb->destructor = sock_efree; - dst =READ_ONCE (sk->sk_rx_dst); + dst =rcu_dereference (sk->sk_rx_dst);if (dst) dst =dst_check (dst,inet6_sk (sk)->rx_dst_cookie);
Greg Kroah-Hartman
maintainerPATCH 255/255 thermal: intel_powerclamp: Use first online CPU as control_cpu
In reply to Greg Kroah-HartmanFrom: Rafael J. Wysocki <[email protected]>
commit 4bb7f6c2781e46fc5bd00475a66df2ea30ef330d upstream.
Commit 68b99e94a4a2 ("thermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crash") fixed an issue related to using smp_processor_id() in preemptible context by replacing it with a pair of get_cpu()/put_cpu(), but what is needed there really is any online CPU and not necessarily the one currently running the code. Arguably, getting the one that's running the code in there is confusing.
For this reason, simply give the control CPU role to the first online one which automatically will be CPU0 if it is online, so one check can be dropped from the code for an added benefit.
--- drivers/thermal/intel/intel_powerclamp.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-)
drivers/thermal/intel/intel_powerclamp.c +1 -5
@@ -534,11 +534,7 @@ static int start_power_clamp(void)get_online_cpus ();/* prefer BSP */ - control_cpu =0 ; -if (!cpu_online (control_cpu)) { - control_cpu =get_cpu (); -put_cpu (); - } + control_cpu =cpumask_first (cpu_online_mask); clamping = true;schedule_delayed_work (&poll_pkg_cstate_work,0 );
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.220 release. There are 255 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 26 Oct 2022 11:29:24 +0000. Anything received after that time might be too late.
5.4.220-rc1 compiled and booted on my x86_64 test system. No errors or regressions.
All the best,
-srw
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.220 release. There are 255 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 26 Oct 2022 11:29:24 +0000. Anything received after that time might be too late.
Build results:
total: 161 pass: 161 fail: 0 Qemu test results: total: 447 pass: 447 fail: 0
Guenter
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.220 release. There are 255 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 26 Oct 2022 11:29:24 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.220-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro's test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 5.4.220-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.4.y
* git commit: f49f12b65484790c4e83771c36bda5027fb7483e
* git describe: v5.4.219-256-gf49f12b65484
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.219-256-gf49f12b65484
## No Test Regressions (compared to v5.4.219)
## No Metric Regressions (compared to v5.4.219)
## No Test Fixes (compared to v5.4.219)
## No Metric Fixes (compared to v5.4.219)
## Test result summary
total: 79483, pass: 68536, fail: 1061, skip: 9474, xfail: 412
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 334 total, 334 passed, 0 failed
* arm64: 64 total, 59 passed, 5 failed
* i386: 31 total, 29 passed, 2 failed
* mips: 56 total, 56 passed, 0 failed
* parisc: 12 total, 12 passed, 0 failed
* powerpc: 63 total, 63 passed, 0 failed
* riscv: 27 total, 26 passed, 1 failed
* s390: 15 total, 15 passed, 0 failed
* sh: 24 total, 24 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x86_64: 57 total, 55 passed, 2 failed
## Test suites summary
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-arm64
* kselftest-arm64/arm64.btitest.bti_c_func
* kselftest-arm64/arm64.btitest.bti_j_func
* kselftest-arm64/arm64.btitest.bti_jc_func
* kselftest-arm64/arm64.btitest.bti_none_func
* kselftest-arm64/arm64.btitest.nohint_func
* kselftest-arm64/arm64.btitest.paciasp_func
* kselftest-arm64/arm64.nobtitest.bti_c_func
* kselftest-arm64/arm64.nobtitest.bti_j_func
* kselftest-arm64/arm64.nobtitest.bti_jc_func
* kselftest-arm64/arm64.nobtitest.bti_none_func
* kselftest-arm64/arm64.nobtitest.nohint_func
* kselftest-arm64/arm64.nobtitest.paciasp_func
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-open-posix-tests
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* packetdrill
* perf
* perf/Zstd-perf.data-compression
* rcutorture
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org