4.14.256-rc1 review
Subsystems (4)
Greg Kroah-Hartman
maintainerPATCH 177/251 scsi: qla2xxx: Turn off target reset during issue_lip
In reply to Greg Kroah-HartmanFrom: Quinn Tran <[email protected]>
[ Upstream commit 0b7a9fd934a68ebfc1019811b7bdc1742072ad7b ]
When user uses issue_lip to do link bounce, driver sends additional target reset to remote device before resetting the link. The target reset would affect other paths with active I/Os. This patch will remove the unnecessary target reset.
--- drivers/scsi/qla2xxx/qla_gbl.h | 2 -- drivers/scsi/qla2xxx/qla_mr.c | 23 ----------------------- drivers/scsi/qla2xxx/qla_os.c | 27 ++------------------------- 3 files changed, 2 insertions(+), 50 deletions(-)
drivers/scsi/qla2xxx/qla_gbl.h +0 -2
@@ -132,7 +132,6 @@ extern int ql2xasynctmfenable;extern int ql2xgffidenable;extern int ql2xenabledif;extern int ql2xenablehba_err_chk; -extern int ql2xtargetreset;extern int ql2xdontresethba;extern uint64_t ql2xmaxlun;extern int ql2xmdcapmask;
@@ -724,7 +723,6 @@ extern void qlafx00_abort_iocb(srb_t *, struct abort_iocb_entry_fx00 *);extern void qlafx00_fxdisc_iocb (srb_t *,struct fxdisc_entry_fx00 *);extern void qlafx00_timer_routine (scsi_qla_host_t *);extern int qlafx00_rescan_isp (scsi_qla_host_t *); -extern int qlafx00_loop_reset (scsi_qla_host_t *vha);/* qla82xx related functions */
drivers/scsi/qla2xxx/qla_mr.c +0 -23
@@ -739,29 +739,6 @@ qlafx00_lun_reset(fc_port_t *fcport, uint64_t l, int tag)return qla2x00_async_tm_cmd (fcport,TCF_LUN_RESET , l, tag); } -int -qlafx00_loop_reset (scsi_qla_host_t *vha) -{ -int ret; -struct fc_port *fcport; -struct qla_hw_data *ha = vha->hw; - -if (ql2xtargetreset) { -list_for_each_entry (fcport, &vha->vp_fcports, list) { -if (fcport->port_type !=FCT_TARGET ) -continue ; - - ret = ha->isp_ops->target_reset (fcport,0 ,0 ); -if (ret !=QLA_SUCCESS ) { -ql_dbg (ql_dbg_taskm, vha,0x803d , -"Bus Reset failed: Reset=%d " -"d_id=%x.\n" , ret, fcport->d_id.b24); - } - } - } -return QLA_SUCCESS ; -} -int qlafx00_iospace_config (struct qla_hw_data *ha) {
drivers/scsi/qla2xxx/qla_os.c +2 -25
@@ -188,12 +188,6 @@ MODULE_PARM_DESC(ql2xdbwr," 0 -- Regular doorbell.\n" " 1 -- CAMRAM doorbell (faster).\n"); -int ql2xtargetreset =1 ; -module_param (ql2xtargetreset, int,S_IRUGO ); -MODULE_PARM_DESC (ql2xtargetreset, -"Enable target reset." -"Default is 1 - use hw defaults." ); -int ql2xgffidenable;module_param (ql2xgffidenable, int,S_IRUGO ); MODULE_PARM_DESC(ql2xgffidenable,
@@ -1652,27 +1646,10 @@ int qla2x00_loop_reset(scsi_qla_host_t *vha) {int ret; -struct fc_port *fcport;struct qla_hw_data *ha = vha->hw; -if (IS_QLAFX00 (ha)) { -return qlafx00_loop_reset (vha); - } - -if (ql2xtargetreset ==1 && ha->flags.enable_target_reset) { -list_for_each_entry (fcport, &vha->vp_fcports, list) { -if (fcport->port_type !=FCT_TARGET ) -continue ; - - ret = ha->isp_ops->target_reset (fcport,0 ,0 ); -if (ret !=QLA_SUCCESS ) { -ql_dbg (ql_dbg_taskm, vha,0x802c , -"Bus Reset failed: Reset=%d " -"d_id=%x.\n" , ret, fcport->d_id.b24); - } - } - } - +if (IS_QLAFX00 (ha)) +return QLA_SUCCESS ;if (ha->flags.enable_lip_full_login && !IS_CNA_CAPABLE (ha)) {atomic_set (&vha->loop_state,LOOP_DOWN );
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 178/251 i2c: xlr: Fix a resource leak in the error handling path of xlr_i2c_probe()
In reply to Greg Kroah-HartmanFrom: Christophe JAILLET <[email protected]>
[ Upstream commit 7f98960c046ee1136e7096aee168eda03aef8a5d ]
A successful 'clk_prepare()' call should be balanced by a corresponding 'clk_unprepare()' call in the error handling path of the probe, as already done in the remove function.
More specifically, 'clk_prepare_enable()' is used, but 'clk_disable()' is also already called. So just the unprepare step has still to be done.
Update the error handling path accordingly.
--- drivers/i2c/busses/i2c-xlr.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/i2c/busses/i2c-xlr.c +5 -1
@@ -434,11 +434,15 @@ static int xlr_i2c_probe(struct platform_device *pdev)i2c_set_adapdata (&priv->adap, priv); ret =i2c_add_numbered_adapter (&priv->adap);if (ret <0 ) -return ret; + goto err_unprepare_clk;platform_set_drvdata (pdev, priv);dev_info (&priv->adap.dev,"Added I2C Bus.\n" );return 0 ; + +err_unprepare_clk: +clk_unprepare (clk); +return ret; }static int xlr_i2c_remove (struct platform_device *pdev)
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 179/251 xen-pciback: Fix return in pm_ctrl_init()
In reply to Greg Kroah-HartmanFrom: YueHaibing <[email protected]>
[ Upstream commit 4745ea2628bb43a7ec34b71763b5a56407b33990 ]
Return NULL instead of passing to ERR_PTR while err is zero, this fix smatch warnings:drivers/xen/xen-pciback/conf_space_capability.c:163
pm_ctrl_init() warn: passing zero to 'ERR_PTR'
--- drivers/xen/xen-pciback/conf_space_capability.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/xen/xen-pciback/conf_space_capability.c +1 -1
@@ -160,7 +160,7 @@ static void *pm_ctrl_init(struct pci_dev *dev, int offset) } out: -return ERR_PTR (err); +return err ?ERR_PTR (err) :NULL ; }static const struct config_field caplist_pm[] = {
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 180/251 net: davinci_emac: Fix interrupt pacing disable
In reply to Greg Kroah-HartmanFrom: Maxim Kiselev <[email protected]>
[ Upstream commit d52bcb47bdf971a59a2467975d2405fcfcb2fa19 ]
This patch allows to use 0 for coal->rx_coalesce_usecs param to disable rx irq coalescing.
Previously we could enable rx irq coalescing via ethtool (For ex: ethtool -C eth0 rx-usecs 2000) but we couldn't disable it because this part rejects 0 value:
if (!coal->rx_coalesce_usecs)
return -EINVAL;--- drivers/net/ethernet/ti/davinci_emac.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-)
drivers/net/ethernet/ti/davinci_emac.c +14 -2
@@ -426,8 +426,20 @@ static int emac_set_coalesce(struct net_device *ndev,u32 int_ctrl, num_interrupts =0 ;u32 prescale =0 , addnl_dvdr =1 , coal_intvl =0 ; -if (!coal->rx_coalesce_usecs) -return -EINVAL ; +if (!coal->rx_coalesce_usecs) { + priv->coal_intvl =0 ; + +switch (priv->version) { +case EMAC_VERSION_2 : +emac_ctrl_write (EMAC_DM646X_CMINTCTRL ,0 ); +break ; +default : +emac_ctrl_write (EMAC_CTRL_EWINTTCNT ,0 ); +break ; + } + +return 0 ; + } coal_intvl = coal->rx_coalesce_usecs;
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 181/251 net: vlan: fix a UAF in vlan_dev_real_dev()
In reply to Greg Kroah-HartmanFrom: Ziyang Xuan <[email protected]>
[ Upstream commit 563bcbae3ba233c275c244bfce2efe12938f5363 ]
The real_dev of a vlan net_device may be freed after unregister_vlan_dev(). Access the real_dev continually by vlan_dev_real_dev() will trigger the UAF problem for the real_dev like following:
==================================================================
BUG: KASAN: use-after-free in vlan_dev_real_dev+0xf9/0x120 Call Trace: kasan_report.cold+0x83/0xdf vlan_dev_real_dev+0xf9/0x120 is_eth_port_of_netdev_filter.part.0+0xb1/0x2c0 is_eth_port_of_netdev_filter+0x28/0x40 ib_enum_roce_netdev+0x1a3/0x300 ib_enum_all_roce_netdevs+0xc7/0x140 netdevice_event_work_handler+0x9d/0x210
...
Freed by task 9288: kasan_save_stack+0x1b/0x40 kasan_set_track+0x1c/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0xfc/0x130 slab_free_freelist_hook+0xdd/0x240 kfree+0xe4/0x690 kvfree+0x42/0x50 device_release+0x9f/0x240 kobject_put+0x1c8/0x530 put_device+0x1b/0x30 free_netdev+0x370/0x540 ppp_destroy_interface+0x313/0x3d0
...
Move the put_device(real_dev) to vlan_dev_free(). Ensure real_dev not be freed before vlan_dev unregistered.
--- net/8021q/vlan.c | 3 --- net/8021q/vlan_dev.c | 3 +++ 2 files changed, 3 insertions(+), 3 deletions(-)
net/8021q/vlan.c +0 -3
@@ -112,9 +112,6 @@ void unregister_vlan_dev(struct net_device *dev, struct list_head *head) }vlan_vid_del (real_dev, vlan->vlan_proto, vlan_id); - -/* Get rid of the vlan's reference to real_dev */ -dev_put (real_dev); } int vlan_check_real_dev(struct net_device *real_dev,
net/8021q/vlan_dev.c +3 -0
@@ -814,6 +814,9 @@ static void vlan_dev_free(struct net_device *dev)free_percpu (vlan->vlan_pcpu_stats); vlan->vlan_pcpu_stats =NULL ; + +/* Get rid of the vlan's reference to real_dev */ +dev_put (vlan->real_dev); }void vlan_setup (struct net_device *dev)
Signature · 1 line
2.33.0
Re: [PATCH 4.14 181/251] net: vlan: fix a UAF in vlan_dev_real_dev()
Quoted 45 lines · Greg Kroah-Hartman
From: Ziyang Xuan <[email protected]>
[ Upstream commit
563bcbae3ba233c275c244bfce2efe12938f5363]The
real_devof a vlannet_devicemay be freed afterunregister_vlan_dev(). Access thereal_devcontinually byvlan_dev_real_dev()will trigger the UAF problem for thereal_devlike following:==================================================================
BUG: KASAN: use-after-free in vlan_dev_real_dev+0xf9/0x120 Call Trace: kasan_report.cold+0x83/0xdf vlan_dev_real_dev+0xf9/0x120 is_eth_port_of_netdev_filter.part.0+0xb1/0x2c0 is_eth_port_of_netdev_filter+0x28/0x40 ib_enum_roce_netdev+0x1a3/0x300 ib_enum_all_roce_netdevs+0xc7/0x140 netdevice_event_work_handler+0x9d/0x210...
Freed by task 9288: kasan_save_stack+0x1b/0x40 kasan_set_track+0x1c/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0xfc/0x130 slab_free_freelist_hook+0xdd/0x240 kfree+0xe4/0x690 kvfree+0x42/0x50 device_release+0x9f/0x240 kobject_put+0x1c8/0x530 put_device+0x1b/0x30 free_netdev+0x370/0x540 ppp_destroy_interface+0x313/0x3d0...
Move the
put_device(real_dev)tovlan_dev_free(). Ensurereal_devnot be freed beforevlan_devunregistered.Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")Reported-by [email protected]Signed-off-by Ziyang Xuan <[email protected]>Reviewed-by Jason Gunthorpe <[email protected]>Signed-off-by David S. Miller <[email protected]>Signed-off-by Sasha Levin <[email protected]>
Quoted 4 lines
--- net/8021q/vlan.c | 3 --- net/8021q/vlan_dev.c | 3 +++ 2 files changed, 3 insertions(+), 3 deletions(-)
This patch is known to be broken, it should not be backported
Jason
Greg Kroah-Hartman
maintainerRe: [PATCH 4.14 181/251] net: vlan: fix a UAF in vlan_dev_real_dev()
Quoted 51 lines · Jason Gunthorpe
Quoted 45 lines · Greg Kroah-Hartman
From: Ziyang Xuan <[email protected]>
[ Upstream commit
563bcbae3ba233c275c244bfce2efe12938f5363]The
real_devof a vlannet_devicemay be freed afterunregister_vlan_dev(). Access thereal_devcontinually byvlan_dev_real_dev()will trigger the UAF problem for thereal_devlike following:==================================================================
BUG: KASAN: use-after-free in vlan_dev_real_dev+0xf9/0x120 Call Trace: kasan_report.cold+0x83/0xdf vlan_dev_real_dev+0xf9/0x120 is_eth_port_of_netdev_filter.part.0+0xb1/0x2c0 is_eth_port_of_netdev_filter+0x28/0x40 ib_enum_roce_netdev+0x1a3/0x300 ib_enum_all_roce_netdevs+0xc7/0x140 netdevice_event_work_handler+0x9d/0x210...
Freed by task 9288: kasan_save_stack+0x1b/0x40 kasan_set_track+0x1c/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0xfc/0x130 slab_free_freelist_hook+0xdd/0x240 kfree+0xe4/0x690 kvfree+0x42/0x50 device_release+0x9f/0x240 kobject_put+0x1c8/0x530 put_device+0x1b/0x30 free_netdev+0x370/0x540 ppp_destroy_interface+0x313/0x3d0...
Move the
put_device(real_dev)tovlan_dev_free(). Ensurereal_devnot be freed beforevlan_devunregistered.Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")Reported-by [email protected]Signed-off-by Ziyang Xuan <[email protected]>Reviewed-by Jason Gunthorpe <[email protected]>Signed-off-by David S. Miller <[email protected]>Signed-off-by Sasha Levin <[email protected]>Quoted 4 lines
--- net/8021q/vlan.c | 3 --- net/8021q/vlan_dev.c | 3 +++ 2 files changed, 3 insertions(+), 3 deletions(-)
Quoted 1 line
This patch is known to be broken, it should not be backported
It is already in a bunch of branches :(
What is the upstream revert of this commit in Linus's tree?
thanks,
greg k-h
Re: [PATCH 4.14 181/251] net: vlan: fix a UAF in vlan_dev_real_dev()
Quoted 51 lines · Greg Kroah-Hartman
Quoted 50 lines · Jason Gunthorpe
Quoted 48 lines · Greg Kroah-Hartman
From: Ziyang Xuan <[email protected]>
[ Upstream commit
563bcbae3ba233c275c244bfce2efe12938f5363]The
real_devof a vlannet_devicemay be freed afterunregister_vlan_dev(). Access thereal_devcontinually byvlan_dev_real_dev()will trigger the UAF problem for thereal_devlike following:==================================================================
BUG: KASAN: use-after-free in vlan_dev_real_dev+0xf9/0x120 Call Trace: kasan_report.cold+0x83/0xdf vlan_dev_real_dev+0xf9/0x120 is_eth_port_of_netdev_filter.part.0+0xb1/0x2c0 is_eth_port_of_netdev_filter+0x28/0x40 ib_enum_roce_netdev+0x1a3/0x300 ib_enum_all_roce_netdevs+0xc7/0x140 netdevice_event_work_handler+0x9d/0x210...
Freed by task 9288: kasan_save_stack+0x1b/0x40 kasan_set_track+0x1c/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0xfc/0x130 slab_free_freelist_hook+0xdd/0x240 kfree+0xe4/0x690 kvfree+0x42/0x50 device_release+0x9f/0x240 kobject_put+0x1c8/0x530 put_device+0x1b/0x30 free_netdev+0x370/0x540 ppp_destroy_interface+0x313/0x3d0...
Move the
put_device(real_dev)tovlan_dev_free(). Ensurereal_devnot be freed beforevlan_devunregistered.Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")Reported-by [email protected]Signed-off-by Ziyang Xuan <[email protected]>Reviewed-by Jason Gunthorpe <[email protected]>Signed-off-by David S. Miller <[email protected]>Signed-off-by Sasha Levin <[email protected]>net/8021q/vlan.c | 3 --- net/8021q/vlan_dev.c | 3 +++ 2 files changed, 3 insertions(+), 3 deletions(-)
Quoted 5 lines
Quoted 1 line
This patch is known to be broken, it should not be backported
It is already in a bunch of branches :(
What is the upstream revert of this commit in Linus's tree?
It isn't in a Linus released kernel yet, Ziyang and Petr are working on fixing it.
Jason
Greg Kroah-Hartman
maintainerRe: [PATCH 4.14 181/251] net: vlan: fix a UAF in vlan_dev_real_dev()
Quoted 52 lines · Jason Gunthorpe
Quoted 51 lines · Greg Kroah-Hartman
Quoted 50 lines · Jason Gunthorpe
Quoted 48 lines · Greg Kroah-Hartman
From: Ziyang Xuan <[email protected]>
[ Upstream commit
563bcbae3ba233c275c244bfce2efe12938f5363]The
real_devof a vlannet_devicemay be freed afterunregister_vlan_dev(). Access thereal_devcontinually byvlan_dev_real_dev()will trigger the UAF problem for thereal_devlike following:==================================================================
BUG: KASAN: use-after-free in vlan_dev_real_dev+0xf9/0x120 Call Trace: kasan_report.cold+0x83/0xdf vlan_dev_real_dev+0xf9/0x120 is_eth_port_of_netdev_filter.part.0+0xb1/0x2c0 is_eth_port_of_netdev_filter+0x28/0x40 ib_enum_roce_netdev+0x1a3/0x300 ib_enum_all_roce_netdevs+0xc7/0x140 netdevice_event_work_handler+0x9d/0x210...
Freed by task 9288: kasan_save_stack+0x1b/0x40 kasan_set_track+0x1c/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0xfc/0x130 slab_free_freelist_hook+0xdd/0x240 kfree+0xe4/0x690 kvfree+0x42/0x50 device_release+0x9f/0x240 kobject_put+0x1c8/0x530 put_device+0x1b/0x30 free_netdev+0x370/0x540 ppp_destroy_interface+0x313/0x3d0...
Move the
put_device(real_dev)tovlan_dev_free(). Ensurereal_devnot be freed beforevlan_devunregistered.Fixes 1da177e4c3f4 ("Linux-2.6.12-rc2")Reported-by [email protected]Signed-off-by Ziyang Xuan <[email protected]>Reviewed-by Jason Gunthorpe <[email protected]>Signed-off-by David S. Miller <[email protected]>Signed-off-by Sasha Levin <[email protected]>net/8021q/vlan.c | 3 --- net/8021q/vlan_dev.c | 3 +++ 2 files changed, 3 insertions(+), 3 deletions(-)
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
This patch is known to be broken, it should not be backported
It is already in a bunch of branches :(
What is the upstream revert of this commit in Linus's tree?
It isn't in a Linus released kernel yet, Ziyang and Petr are working on fixing it.
Ok, dropping it from the 4.14 and 4.19 queues now, hopefully it gets fixed in Linus's tree soon.
thanks,
greg k-h
Greg Kroah-Hartman
maintainerPATCH 182/251 ACPI: PMIC: Fix intel_pmic_regs_handler() read accesses
In reply to Greg Kroah-HartmanFrom: Hans de Goede <[email protected]>
[ Upstream commit 009a789443fe4c8e6b1ecb7c16b4865c026184cd ]
The handling of PMIC register reads through writing 0 to address 4 of the OpRegion is wrong. Instead of returning the read value through the value64, which is a no-op for function == ACPI_WRITE calls, store the value and then on a subsequent function == ACPI_READ with address == 3 (the address for the value field of the OpRegion) return the stored value.
This has been tested on a Xiaomi Mi Pad 2 and makes the ACPI battery dev there mostly functional (unfortunately there are still other issues).
Here are the SET() / GET() functions of the PMIC ACPI device, which use this OpRegion, which clearly show the new behavior to be correct:
OperationRegion (REGS, 0x8F, Zero, 0x50)
Field (REGS, ByteAcc, NoLock, Preserve)
{
CLNT, 8,
SA, 8,
OFF, 8,
VAL, 8,
RWM, 8
}Method (GET, 3, Serialized)
{
If ((AVBE == One))
{
CLNT = Arg0
SA = Arg1
OFF = Arg2
RWM = Zero
If ((AVBG == One))
{
GPRW = Zero
}
}
Return (VAL) /* \_SB_.PCI0.I2C7.PMI5.VAL_ */
}Method (SET, 4, Serialized)
{
If ((AVBE == One))
{
CLNT = Arg0
SA = Arg1
OFF = Arg2
VAL = Arg3
RWM = One
If ((AVBG == One))
{
GPRW = One
}
}
}
--- drivers/acpi/pmic/intel_pmic.c | 51 +++++++++++++++++++--------------- 1 file changed, 28 insertions(+), 23 deletions(-)
drivers/acpi/pmic/intel_pmic.c +28 -23
@@ -216,31 +216,36 @@ static acpi_status intel_pmic_regs_handler(u32 function, void *handler_context, void *region_context) { struct intel_pmic_opregion *opregion = region_context; -int result =0 ; +int result = -EINVAL ; + +if (function ==ACPI_WRITE ) { +switch (address) { +case 0 : +return AE_OK ; +case 1 : + opregion->ctx.addr |= (*value64 &0xff ) <<8 ; +return AE_OK ; +case 2 : + opregion->ctx.addr |= *value64 &0xff ; +return AE_OK ; +case 3 : + opregion->ctx.val = *value64 &0xff ; +return AE_OK ; +case 4 : +if (*value64) { + result =regmap_write (opregion->regmap, opregion->ctx.addr, + opregion->ctx.val); + }else { + result =regmap_read (opregion->regmap, opregion->ctx.addr, + &opregion->ctx.val); + } + opregion->ctx.addr =0 ; + } + } -switch (address) { -case 0 : -return AE_OK ; -case 1 : - opregion->ctx.addr |= (*value64 &0xff ) <<8 ; +if (function ==ACPI_READ && address ==3 ) { + *value64 = opregion->ctx.val;return AE_OK ; -case 2 : - opregion->ctx.addr |= *value64 &0xff ; -return AE_OK ; -case 3 : - opregion->ctx.val = *value64 &0xff ; -return AE_OK ; -case 4 : -if (*value64) { - result =regmap_write (opregion->regmap, opregion->ctx.addr, - opregion->ctx.val); - }else { - result =regmap_read (opregion->regmap, opregion->ctx.addr, - &opregion->ctx.val); -if (result ==0 ) - *value64 = opregion->ctx.val; - } -memset (&opregion->ctx,0x00 ,sizeof (opregion->ctx)); }if (result <0 ) {
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 183/251 bonding: Fix a use-after-free problem when bond_sysfs_slave_add() failed
In reply to Greg Kroah-HartmanFrom: Huang Guobin <[email protected]>
[ Upstream commit b93c6a911a3fe926b00add28f3b932007827c4ca ]
When I do fuzz test for bonding device interface, I got the following use-after-free Calltrace:
==================================================================
BUG: KASAN: use-after-free in bond_enslave+0x1521/0x24f0
Read of size 8 at addr ffff88825bc11c00 by task ifenslave/7365
CPU: 5 PID: 7365 Comm: ifenslave Tainted: G E 5.15.0-rc1+ #13
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014
Call Trace:
dump_stack_lvl+0x6c/0x8b
print_address_description.constprop.0+0x48/0x70
kasan_report.cold+0x82/0xdb
__asan_load8+0x69/0x90
bond_enslave+0x1521/0x24f0
bond_do_ioctl+0x3e0/0x450
dev_ifsioc+0x2ba/0x970
dev_ioctl+0x112/0x710
sock_do_ioctl+0x118/0x1b0
sock_ioctl+0x2e0/0x490
__x64_sys_ioctl+0x118/0x150
do_syscall_64+0x35/0xb0
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f19159cf577
Code: b3 66 90 48 8b 05 11 89 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 78
RSP: 002b:00007ffeb3083c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007ffeb3084bca RCX: 00007f19159cf577
RDX: 00007ffeb3083ce0 RSI: 0000000000008990 RDI: 0000000000000003
RBP: 00007ffeb3084bc4 R08: 0000000000000040 R09: 0000000000000000
R10: 00007ffeb3084bc0 R11: 0000000000000246 R12: 00007ffeb3083ce0
R13: 0000000000000000 R14: 0000000000000000 R15: 00007ffeb3083cb0
Allocated by task 7365:
kasan_save_stack+0x23/0x50
__kasan_kmalloc+0x83/0xa0
kmem_cache_alloc_trace+0x22e/0x470
bond_enslave+0x2e1/0x24f0
bond_do_ioctl+0x3e0/0x450
dev_ifsioc+0x2ba/0x970
dev_ioctl+0x112/0x710
sock_do_ioctl+0x118/0x1b0
sock_ioctl+0x2e0/0x490
__x64_sys_ioctl+0x118/0x150
do_syscall_64+0x35/0xb0
entry_SYSCALL_64_after_hwframe+0x44/0xae
Freed by task 7365:
kasan_save_stack+0x23/0x50
kasan_set_track+0x20/0x30
kasan_set_free_info+0x24/0x40
__kasan_slab_free+0xf2/0x130
kfree+0xd1/0x5c0
slave_kobj_release+0x61/0x90
kobject_put+0x102/0x180
bond_sysfs_slave_add+0x7a/0xa0
bond_enslave+0x11b6/0x24f0
bond_do_ioctl+0x3e0/0x450
dev_ifsioc+0x2ba/0x970
dev_ioctl+0x112/0x710
sock_do_ioctl+0x118/0x1b0
sock_ioctl+0x2e0/0x490
__x64_sys_ioctl+0x118/0x150
do_syscall_64+0x35/0xb0
entry_SYSCALL_64_after_hwframe+0x44/0xae
Last potentially related work creation:
kasan_save_stack+0x23/0x50
kasan_record_aux_stack+0xb7/0xd0
insert_work+0x43/0x190
__queue_work+0x2e3/0x970
delayed_work_timer_fn+0x3e/0x50
call_timer_fn+0x148/0x470
run_timer_softirq+0x8a8/0xc50
__do_softirq+0x107/0x55f
Second to last potentially related work creation:
kasan_save_stack+0x23/0x50
kasan_record_aux_stack+0xb7/0xd0
insert_work+0x43/0x190
__queue_work+0x2e3/0x970
__queue_delayed_work+0x130/0x180
queue_delayed_work_on+0xa7/0xb0
bond_enslave+0xe25/0x24f0
bond_do_ioctl+0x3e0/0x450
dev_ifsioc+0x2ba/0x970
dev_ioctl+0x112/0x710
sock_do_ioctl+0x118/0x1b0
sock_ioctl+0x2e0/0x490
__x64_sys_ioctl+0x118/0x150
do_syscall_64+0x35/0xb0
entry_SYSCALL_64_after_hwframe+0x44/0xae
The buggy address belongs to the object at ffff88825bc11c00
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 0 bytes inside of
1024-byte region [ffff88825bc11c00, ffff88825bc12000)
The buggy address belongs to the page:
page:ffffea00096f0400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x25bc10
head:ffffea00096f0400 order:3 compound_mapcount:0 compound_pincount:0
flags: 0x57ff00000010200(slab|head|node=1|zone=2|lastcpupid=0x7ff)
raw: 057ff00000010200 ffffea0009a71c08 ffff888240001968 ffff88810004dbc0
raw: 0000000000000000 00000000000a000a 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88825bc11b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88825bc11b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88825bc11c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88825bc11c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88825bc11d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================Put new_slave in bond_sysfs_slave_add() will cause use-after-free problems when new_slave is accessed in the subsequent error handling process. Since new_slave will be put in the subsequent error handling process, remove the unnecessary put to fix it.
In addition, when sysfs_create_file() fails, if some files have been crea- ted successfully, we need to call sysfs_remove_file() to remove them. Since there are sysfs_create_files() & sysfs_remove_files() can be used, use these two functions instead.
--- drivers/net/bonding/bond_sysfs_slave.c | 36 ++++++++------------------ 1 file changed, 11 insertions(+), 25 deletions(-)
drivers/net/bonding/bond_sysfs_slave.c +11 -25
@@ -112,15 +112,15 @@ static ssize_t ad_partner_oper_port_state_show(struct slave *slave, char *buf) }static SLAVE_ATTR_RO (ad_partner_oper_port_state); -static const struct slave_attribute *slave_attrs[] = { - &slave_attr_state, - &slave_attr_mii_status, - &slave_attr_link_failure_count, - &slave_attr_perm_hwaddr, - &slave_attr_queue_id, - &slave_attr_ad_aggregator_id, - &slave_attr_ad_actor_oper_port_state, - &slave_attr_ad_partner_oper_port_state, +static const struct attribute *slave_attrs[] = { + &slave_attr_state.attr, + &slave_attr_mii_status.attr, + &slave_attr_link_failure_count.attr, + &slave_attr_perm_hwaddr.attr, + &slave_attr_queue_id.attr, + &slave_attr_ad_aggregator_id.attr, + &slave_attr_ad_actor_oper_port_state.attr, + &slave_attr_ad_partner_oper_port_state.attr,NULL };
@@ -141,24 +141,10 @@ const struct sysfs_ops slave_sysfs_ops = {int bond_sysfs_slave_add (struct slave *slave) { -const struct slave_attribute **a; -int err; - -for (a = slave_attrs; *a; ++a) { - err =sysfs_create_file (&slave->kobj, &((*a)->attr)); -if (err) { -kobject_put (&slave->kobj); -return err; - } - } - -return 0 ; +return sysfs_create_files (&slave->kobj, slave_attrs); }void bond_sysfs_slave_del (struct slave *slave) { -const struct slave_attribute **a; - -for (a = slave_attrs; *a; ++a) -sysfs_remove_file (&slave->kobj, &((*a)->attr)); +sysfs_remove_files (&slave->kobj, slave_attrs); }
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 184/251 mm/zsmalloc.c: close race window between zs_pool_dec_isolated() and zs_unregister_migration()
In reply to Greg Kroah-HartmanFrom: Miaohe Lin <[email protected]>
[ Upstream commit afe8605ca45424629fdddfd85984b442c763dc47 ]
There is one possible race window between zs_pool_dec_isolated() and zs_unregister_migration() because wait_for_isolated_drain() checks the isolated count without holding class->lock and there is no order inside zs_pool_dec_isolated(). Thus the below race window could be possible:
zs_pool_dec_isolated zs_unregister_migration
check pool->destroying != 0
pool->destroying = true;
smp_mb();
wait_for_isolated_drain()
wait for pool->isolated_pages == 0
atomic_long_dec(&pool->isolated_pages);
atomic_long_read(&pool->isolated_pages) == 0Since we observe the pool->destroying (false) before atomic_long_dec() for pool->isolated_pages, waking pool->migration_wait up is missed.
Fix this by ensure checking pool->destroying happens after the atomic_long_dec(&pool->isolated_pages).
--- mm/zsmalloc.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
mm/zsmalloc.c +4 -3
@@ -1901,10 +1901,11 @@ static inline void zs_pool_dec_isolated(struct zs_pool *pool)VM_BUG_ON (atomic_long_read (&pool->isolated_pages) <=0 );atomic_long_dec (&pool->isolated_pages);/* -* There's no possibility of racing, since wait_for_isolated_drain() -* checks the isolated count under &class->lock after enqueuing -* on migration_wait. +* Checking pool->destroying must happen after atomic_long_dec() +* for pool->isolated_pages above. Paired with the smp_mb() in +* zs_unregister_migration(). */ +smp_mb__after_atomic ();if (atomic_long_read (&pool->isolated_pages) ==0 && pool->destroying)wake_up_all (&pool->migration_wait); }
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 185/251 llc: fix out-of-bound array index in llc_sk_dev_hash()
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
[ Upstream commit 8ac9dfd58b138f7e82098a4e0a0d46858b12215b ]
Both ifindex and LLC_SK_DEV_HASH_ENTRIES are signed.
This means that (ifindex % LLC_SK_DEV_HASH_ENTRIES) is negative if @ifindex is negative.
We could simply make LLC_SK_DEV_HASH_ENTRIES unsigned.
In this patch I chose to use hash_32() to get more entropy from @ifindex, like llc_sk_laddr_hashfn().
UBSAN: array-index-out-of-bounds in ./include/net/llc.h:75:26 index -43 is out of range for type 'hlist_head [64]' CPU: 1 PID: 20999 Comm: syz-executor.3 Not tainted 5.15.0-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 ubsan_epilogue+0xb/0x5a lib/ubsan.c:151 __ubsan_handle_out_of_bounds.cold+0x62/0x6c lib/ubsan.c:291 llc_sk_dev_hash include/net/llc.h:75 [inline] llc_sap_add_socket+0x49c/0x520 net/llc/llc_conn.c:697 llc_ui_bind+0x680/0xd70 net/llc/af_llc.c:404 __sys_bind+0x1e9/0x250 net/socket.c:1693 __do_sys_bind net/socket.c:1704 [inline] __se_sys_bind net/socket.c:1702 [inline] __x64_sys_bind+0x6f/0xb0 net/socket.c:1702 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 RIP: 0033:0x7fa503407ae9
--- include/net/llc.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
include/net/llc.h +3 -1
@@ -72,7 +72,9 @@ struct llc_sap {static inline struct hlist_head *llc_sk_dev_hash (struct llc_sap *sap,int ifindex) { -return &sap->sk_dev_hash[ifindex %LLC_SK_DEV_HASH_ENTRIES ]; +u32 bucket =hash_32 (ifindex,LLC_SK_DEV_HASH_BITS ); + +return &sap->sk_dev_hash[bucket]; } static inline
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 186/251 nfc: pn533: Fix double free when pn533_fill_fragment_skbs() fails
In reply to Greg Kroah-HartmanFrom: Chengfeng Ye <[email protected]>
[ Upstream commit 9fec40f850658e00a14a7dd9e06f7fbc7e59cc4a ]
skb is already freed by dev_kfree_skb in pn533_fill_fragment_skbs, but follow error handler branch when pn533_fill_fragment_skbs() fails, skb is freed again, results in double free issue. Fix this by not free skb in error path of pn533_fill_fragment_skbs.
--- drivers/nfc/pn533/pn533.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/nfc/pn533/pn533.c +3 -3
@@ -2084,7 +2084,7 @@ static int pn533_fill_fragment_skbs(struct pn533 *dev, struct sk_buff *skb) frag =pn533_alloc_skb (dev, frag_size);if (!frag) {skb_queue_purge (&dev->fragment_skb); -break ; +return -ENOMEM ; }if (!dev->tgt_mode) {
@@ -2154,7 +2154,7 @@ static int pn533_transceive(struct nfc_dev *nfc_dev,/* jumbo frame ? */ if (skb->len >PN533_CMD_DATAEXCH_DATA_MAXLEN ) { rc =pn533_fill_fragment_skbs (dev, skb); -if (rc <=0 ) +if (rc <0 ) goto error; skb =skb_dequeue (&dev->fragment_skb);
@@ -2226,7 +2226,7 @@ static int pn533_tm_send(struct nfc_dev *nfc_dev, struct sk_buff *skb)/* let's split in multiple chunks if size's too big */ if (skb->len >PN533_CMD_DATAEXCH_DATA_MAXLEN ) { rc =pn533_fill_fragment_skbs (dev, skb); -if (rc <=0 ) +if (rc <0 ) goto error;/* get the first skb */
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 187/251 vsock: prevent unnecessary refcnt inc for nonblocking connect
In reply to Greg Kroah-HartmanFrom: Eiichi Tsukata <[email protected]>
[ Upstream commit c7cd82b90599fa10915f41e3dd9098a77d0aa7b6 ]
Currently vosck_connect() increments sock refcount for nonblocking socket each time it's called, which can lead to memory leak if it's called multiple times because connect timeout function decrements sock refcount only once.
Fixes it by making vsock_connect() return -EALREADY immediately when sock state is already SS_CONNECTING.
--- net/vmw_vsock/af_vsock.c | 2 ++ 1 file changed, 2 insertions(+)
net/vmw_vsock/af_vsock.c +2 -0
@@ -1166,6 +1166,8 @@ static int vsock_stream_connect(struct socket *sock, struct sockaddr *addr,* non-blocking call. */ err = -EALREADY ; +if (flags &O_NONBLOCK ) + goto out;break ;default : if ((sk->sk_state == TCP_LISTEN) ||
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 188/251 USB: chipidea: fix interrupt deadlock
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit 9aaa81c3366e8393a62374e3a1c67c69edc07b8a upstream.
Chipidea core was calling the interrupt handler from non-IRQ context with interrupts enabled, something which can lead to a deadlock if there's an actual interrupt trying to take a lock that's already held (e.g. the controller lock in udc_irq()).
Add a wrapper that can be used to fake interrupts instead of calling the handler directly.
--- drivers/usb/chipidea/core.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-)
drivers/usb/chipidea/core.c +14 -5
@@ -535,7 +535,7 @@ int hw_device_reset(struct ci_hdrc *ci)return 0 ; } -static irqreturn_t ci_irq (int irq,void *data) +static irqreturn_t ci_irq_handler (int irq,void *data) {struct ci_hdrc *ci = data;irqreturn_t ret =IRQ_NONE ;
@@ -588,6 +588,15 @@ static irqreturn_t ci_irq(int irq, voidreturn ret; } +static void ci_irq (struct ci_hdrc *ci) +{ +unsigned long flags; + +local_irq_save (flags); +ci_irq_handler (ci->irq, ci); +local_irq_restore (flags); +} +static int ci_cable_notifier (struct notifier_block *nb,unsigned long event,void *ptr) {
@@ -597,7 +606,7 @@ static int ci_cable_notifier(struct noti cbl->connected = event; cbl->changed = true; -ci_irq (ci->irq, ci); +ci_irq (ci);return NOTIFY_DONE ; }
@@ -1051,7 +1060,7 @@ static int ci_hdrc_probe(struct platform } } - ret =devm_request_irq (dev, ci->irq, ci_irq,IRQF_SHARED , + ret =devm_request_irq (dev, ci->irq, ci_irq_handler,IRQF_SHARED , ci->platdata->name, ci);if (ret) goto stop;
@@ -1175,11 +1184,11 @@ static void ci_extcon_wakeup_int(structif (!IS_ERR (cable_id->edev) && ci->is_otg && (otgsc &OTGSC_IDIE ) && (otgsc &OTGSC_IDIS )) -ci_irq (ci->irq, ci); +ci_irq (ci);if (!IS_ERR (cable_vbus->edev) && ci->is_otg && (otgsc &OTGSC_BSVIE ) && (otgsc &OTGSC_BSVIS )) -ci_irq (ci->irq, ci); +ci_irq (ci); }static int ci_controller_resume (struct device *dev)
Greg Kroah-Hartman
maintainerPATCH 189/251 ARM: 9155/1: fix early early_iounmap()
In reply to Greg Kroah-HartmanFrom: Michał Mirosław <[email protected]>
commit 0d08e7bf0d0d1a29aff7b16ef516f7415eb1aa05 upstream.
Currently __set_fixmap() bails out with a warning when called in early boot from early_iounmap(). Fix it, and while at it, make the comment a bit easier to understand.
--- arch/arm/mm/mmu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm/mm/mmu.c +2 -2
@@ -416,9 +416,9 @@ void __set_fixmap(enum fixed_addresses i FIXADDR_END);BUG_ON (idx >= __end_of_fixed_addresses); -/* we only support device mappings until pgprot_kernel has been set */ +/* We support only device mappings before pgprot_kernel is set. */ if (WARN_ON (pgprot_val (prot) !=pgprot_val (FIXMAP_PAGE_IO ) && -pgprot_val (pgprot_kernel) ==0 )) +pgprot_val (prot) &&pgprot_val (pgprot_kernel) ==0 ))return ;if (pgprot_val (prot))
Greg Kroah-Hartman
maintainerPATCH 190/251 ARM: 9156/1: drop cc-option fallbacks for architecture selection
In reply to Greg Kroah-HartmanFrom: Arnd Bergmann <[email protected]>
commit 418ace9992a7647c446ed3186df40cf165b67298 upstream.
Naresh and Antonio ran into a build failure with latest Debian armhf compilers, with lots of output like
tmp/ccY3nOAs.s:2215: Error: selected processor does not support `cpsid i' in ARM mode
As it turns out, $(cc-option) fails early here when the FPU is not selected before CPU architecture is selected, as the compiler option check runs before enabling -msoft-float, which causes a problem when testing a target architecture level without an FPU:
cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU
Passing e.g. -march=armv6k+fp in place of -march=armv6k would avoid this issue, but the fallback logic is already broken because all supported compilers (gcc-5 and higher) are much more recent than these options, and building with -march=armv5t as a fallback no longer works.
The best way forward that I see is to just remove all the checks, which also has the nice side-effect of slightly improving the startup time for 'make'.
The -mtune=marvell-f option was apparently never supported by any mainline compiler, and the custom Codesourcery gcc build that did support is now too old to build kernels, so just use -mtune=xscale unconditionally for those.
This should be safe to apply on all stable kernels, and will be required in order to keep building them with gcc-11 and higher.
--- arch/arm/Makefile | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-)
arch/arm/Makefile +11 -11
@@ -66,15 +66,15 @@ KBUILD_CFLAGS += $(call cc-option,-fno-i # Note that GCC does not numerically define an architecture version # macro, but instead defines a whole series of macros which makes # testing for a specific architecture or later rather impossible. -arch-$(CONFIG_CPU_32v7M) =-D__LINUX_ARM_ARCH__=7 -march=armv7-m -Wa,-march=armv7-m -arch-$(CONFIG_CPU_32v7) =-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7-a) -arch-$(CONFIG_CPU_32v6) =-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6,-march=armv5t -Wa$(comma)-march=armv6) +arch-$(CONFIG_CPU_32v7M) =-D__LINUX_ARM_ARCH__=7 -march=armv7-m +arch-$(CONFIG_CPU_32v7) =-D__LINUX_ARM_ARCH__=7 -march=armv7-a +arch-$(CONFIG_CPU_32v6) =-D__LINUX_ARM_ARCH__=6 -march=armv6 # Only override the compiler option if ARMv6. The ARMv6K extensions are # always available in ARMv7 ifeq ($(CONFIG_CPU_32v6),y) -arch-$(CONFIG_CPU_32v6K) =-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6k,-march=armv5t -Wa$(comma)-march=armv6k) +arch-$(CONFIG_CPU_32v6K) =-D__LINUX_ARM_ARCH__=6 -march=armv6k endif -arch-$(CONFIG_CPU_32v5) =-D__LINUX_ARM_ARCH__=5 $(call cc-option,-march=armv5te,-march=armv4t) +arch-$(CONFIG_CPU_32v5) =-D__LINUX_ARM_ARCH__=5 -march=armv5te arch-$(CONFIG_CPU_32v4T) =-D__LINUX_ARM_ARCH__=4 -march=armv4t arch-$(CONFIG_CPU_32v4) =-D__LINUX_ARM_ARCH__=4 -march=armv4 arch-$(CONFIG_CPU_32v3) =-D__LINUX_ARM_ARCH__=3 -march=armv3
@@ -88,7 +88,7 @@ tune-$(CONFIG_CPU_ARM720T) =-mtune=arm7t tune-$(CONFIG_CPU_ARM740T) =-mtune=arm7tdmi tune-$(CONFIG_CPU_ARM9TDMI) =-mtune=arm9tdmi tune-$(CONFIG_CPU_ARM940T) =-mtune=arm9tdmi -tune-$(CONFIG_CPU_ARM946E) =$(call cc-option,-mtune=arm9e,-mtune=arm9tdmi) +tune-$(CONFIG_CPU_ARM946E) =-mtune=arm9e tune-$(CONFIG_CPU_ARM920T) =-mtune=arm9tdmi tune-$(CONFIG_CPU_ARM922T) =-mtune=arm9tdmi tune-$(CONFIG_CPU_ARM925T) =-mtune=arm9tdmi
@@ -96,11 +96,11 @@ tune-$(CONFIG_CPU_ARM926T) =-mtune=arm9t tune-$(CONFIG_CPU_FA526) =-mtune=arm9tdmi tune-$(CONFIG_CPU_SA110) =-mtune=strongarm110 tune-$(CONFIG_CPU_SA1100) =-mtune=strongarm1100 -tune-$(CONFIG_CPU_XSCALE) =$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-mcpu=xscale -tune-$(CONFIG_CPU_XSC3) =$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-mcpu=xscale -tune-$(CONFIG_CPU_FEROCEON) =$(call cc-option,-mtune=marvell-f,-mtune=xscale) -tune-$(CONFIG_CPU_V6) =$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm) -tune-$(CONFIG_CPU_V6K) =$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm) +tune-$(CONFIG_CPU_XSCALE) =-mtune=xscale +tune-$(CONFIG_CPU_XSC3) =-mtune=xscale +tune-$(CONFIG_CPU_FEROCEON) =-mtune=xscale +tune-$(CONFIG_CPU_V6) =-mtune=arm1136j-s +tune-$(CONFIG_CPU_V6K) =-mtune=arm1136j-s # Evaluate tune cc-option calls now tune-y := $(tune-y)
Greg Kroah-Hartman
maintainerPATCH 191/251 powerpc/lib: Add helper to check if offset is within conditional branch range
In reply to Greg Kroah-HartmanFrom: "Naveen N. Rao" <[email protected]>
upstream commit 4549c3ea3160fa8b3f37dfe2f957657bb265eda9
Add a helper to check if a given offset is within the branch range for a powerpc conditional branch instruction, and update some sites to use the new helper.
--- arch/powerpc/include/asm/code-patching.h | 1 + arch/powerpc/lib/code-patching.c | 7 ++++++- arch/powerpc/net/bpf_jit.h | 7 +------ 3 files changed, 8 insertions(+), 7 deletions(-)
arch/powerpc/include/asm/code-patching.h +1 -0
@@ -25,6 +25,7 @@#define BRANCH_ABSOLUTE 0x2bool is_offset_in_branch_range (long offset); +bool is_offset_in_cond_branch_range (long offset);unsigned int create_branch (const unsigned int *addr,unsigned long target,int flags); unsigned int create_cond_branch(const unsigned int *addr,
arch/powerpc/lib/code-patching.c +6 -1
@@ -244,6 +244,11 @@ bool is_offset_in_branch_range(long offsreturn (offset >=-0x2000000 && offset <=0x1fffffc && !(offset &0x3 )); } +bool is_offset_in_cond_branch_range (long offset) +{ +return offset >=-0x8000 && offset <=0x7fff && !(offset &0x3 ); +} +/* * Helper to check if a given instruction is a conditional branch * Derived from the conditional checks in analyse_instr()
@@ -297,7 +302,7 @@ unsigned int create_cond_branch(const un offset = offset - (unsigned long )addr;/* Check we can represent the target in the instruction format */ -if (offset <-0x8000 || offset >0x7FFF || offset &0x3 ) +if (!is_offset_in_cond_branch_range (offset))return 0 ;/* Mask out the flags and target, so they don't step on each other. */
arch/powerpc/net/bpf_jit.h +1 -6
@@ -221,11 +221,6 @@#define PPC_FUNC_ADDR (d,i) do { PPC_LI32(d, i); } while(0)#endif -static inline bool is_nearbranch (int offset) -{ -return (offset <32768 ) && (offset >=-32768 ); -} -/* * The fly in the ointment of code size changing from pass to pass is * avoided by padding the short branch case with a NOP. If code size differs
@@ -234,7 +229,7 @@ static inline bool is_nearbranch(int off* state. */ #define PPC_BCC (cond, dest) do { \ - if (is_nearbranch((dest) - (ctx->idx * 4))) { \ + if (is_offset_in_cond_branch_range((long)(dest) - (ctx->idx * 4))) { \ PPC_BCC_SHORT(cond, dest); \ PPC_NOP(); \ } else { \
Greg Kroah-Hartman
maintainerPATCH 192/251 powerpc/bpf: Validate branch ranges
In reply to Greg Kroah-HartmanFrom: "Naveen N. Rao" <[email protected]>
upstream commit 3832ba4e283d7052b783dab8311df7e3590fed93
Add checks to ensure that we never emit branch instructions with truncated branch offsets.
--- arch/powerpc/net/bpf_jit.h | 26 ++++++++++++++++++++------ arch/powerpc/net/bpf_jit_comp64.c | 10 +++++++--- 2 files changed, 27 insertions(+), 9 deletions(-)
arch/powerpc/net/bpf_jit.h +20 -6
@@ -15,6 +15,7 @@#ifndef __ASSEMBLY__#include <asm/types.h> +#include <asm/code-patching.h> #ifdef PPC64_ELF_ABI_v1#define FUNCTION_DESCR_SIZE 24
@@ -176,13 +177,26 @@#define PPC_NEG (d, a) EMIT(PPC_INST_NEG | ___PPC_RT(d) | ___PPC_RA(a))/* Long jump; (unconditional 'branch') */ -#define PPC_JMP (dest) EMIT(PPC_INST_BRANCH | \ - (((dest) - (ctx->idx * 4)) & 0x03fffffc)) +#define PPC_JMP (dest) \ + do { \ + long offset = (long)(dest) - (ctx->idx * 4); \ + if (!is_offset_in_branch_range(offset)) { \ + pr_err_ratelimited("Branch offset 0x%lx (@%u) out of range\n", offset, ctx->idx); \ + return -ERANGE; \ + } \ + EMIT(PPC_INST_BRANCH | (offset & 0x03fffffc)); \ + } while (0)/* "cond" here covers BO:BI fields. */ -#define PPC_BCC_SHORT (cond, dest) EMIT(PPC_INST_BRANCH_COND | \ - (((cond) & 0x3ff) << 16) | \ - (((dest) - (ctx->idx * 4)) & \ - 0xfffc)) +#define PPC_BCC_SHORT (cond, dest) \ + do { \ + long offset = (long)(dest) - (ctx->idx * 4); \ + if (!is_offset_in_cond_branch_range(offset)) { \ + pr_err_ratelimited("Conditional branch offset 0x%lx (@%u) out of range\n", offset, ctx->idx); \ + return -ERANGE; \ + } \ + EMIT(PPC_INST_BRANCH_COND | (((cond) & 0x3ff) << 16) | (offset & 0xfffc)); \ + } while (0) +/* Sign-extended 32-bit immediate load */ #define PPC_LI32 (d, i) do { \ if ((int)(uintptr_t)(i) >= -32768 && \
arch/powerpc/net/bpf_jit_comp64.c +7 -3
@@ -235,7 +235,7 @@ static void bpf_jit_emit_func_call(u32 *PPC_BLRL (); } -static void bpf_jit_emit_tail_call (u32 *image,struct codegen_context *ctx,u32 out) +static int bpf_jit_emit_tail_call (u32 *image,struct codegen_context *ctx,u32 out) {/* * By now, the eBPF program has already setup parameters in r3, r4 and r5
@@ -296,7 +296,9 @@ static void bpf_jit_emit_tail_call(u32 *bpf_jit_emit_common_epilogue (image, ctx);PPC_BCTR (); +/* out: */ +return 0 ; }/* Assemble the body code between the prologue & epilogue */
@@ -306,7 +308,7 @@ static int bpf_jit_build_body(struct bpf {const struct bpf_insn *insn = fp->insnsi;int flen = fp->len; -int i; +int i, ret;/* Start of epilogue code - will only be valid 2nd pass onwards */ u32 exit_addr = addrs[flen];
@@ -956,7 +958,9 @@ common_load:*/ case BPF_JMP |BPF_TAIL_CALL : ctx->seen |=SEEN_TAILCALL ; -bpf_jit_emit_tail_call (image, ctx, addrs[i +1 ]); + ret =bpf_jit_emit_tail_call (image, ctx, addrs[i +1 ]); +if (ret <0 ) +return ret;break ;default :
Greg Kroah-Hartman
maintainerPATCH 193/251 powerpc/bpf: Fix BPF_SUB when imm == 0x80000000
In reply to Greg Kroah-HartmanFrom: "Naveen N. Rao" <[email protected]>
upstream commit 5855c4c1f415ca3ba1046e77c0b3d3dfc96c9025
We aren't handling subtraction involving an immediate value of 0x80000000 properly. Fix the same.
--- arch/powerpc/net/bpf_jit_comp64.c | 27 +++++++++++++++++---------- 1 file changed, 17 insertions(+), 10 deletions(-)
arch/powerpc/net/bpf_jit_comp64.c +17 -10
@@ -359,18 +359,25 @@ static int bpf_jit_build_body(struct bpfPPC_SUB (dst_reg, dst_reg, src_reg); goto bpf_alu32_trunc;case BPF_ALU |BPF_ADD |BPF_K :/* (u32) dst += (u32) imm */ -case BPF_ALU |BPF_SUB |BPF_K :/* (u32) dst -= (u32) imm */ case BPF_ALU64 |BPF_ADD |BPF_K :/* dst += imm */ +if (!imm) { + goto bpf_alu32_trunc; + }else if (imm >=-32768 && imm <32768 ) { +PPC_ADDI (dst_reg, dst_reg,IMM_L (imm)); + }else { +PPC_LI32 (b2p[TMP_REG_1 ], imm); +PPC_ADD (dst_reg, dst_reg, b2p[TMP_REG_1 ]); + } + goto bpf_alu32_trunc; +case BPF_ALU |BPF_SUB |BPF_K :/* (u32) dst -= (u32) imm */ case BPF_ALU64 |BPF_SUB |BPF_K :/* dst -= imm */ -if (BPF_OP (code) ==BPF_SUB ) - imm = -imm; -if (imm) { -if (imm >=-32768 && imm <32768 ) -PPC_ADDI (dst_reg, dst_reg,IMM_L (imm)); -else { -PPC_LI32 (b2p[TMP_REG_1 ], imm); -PPC_ADD (dst_reg, dst_reg, b2p[TMP_REG_1 ]); - } +if (!imm) { + goto bpf_alu32_trunc; + }else if (imm >-32768 && imm <=32768 ) { +PPC_ADDI (dst_reg, dst_reg,IMM_L (-imm)); + }else { +PPC_LI32 (b2p[TMP_REG_1 ], imm); +PPC_SUB (dst_reg, dst_reg, b2p[TMP_REG_1 ]); } goto bpf_alu32_trunc;case BPF_ALU |BPF_MUL |BPF_X :/* (u32) dst *= (u32) src */
Greg Kroah-Hartman
maintainerPATCH 194/251 mm, oom: pagefault_out_of_memory: dont force global OOM for dying tasks
In reply to Greg Kroah-HartmanFrom: Vasily Averin <[email protected]>
commit 0b28179a6138a5edd9d82ad2687c05b3773c387b upstream.
Patch series "memcg: prohibit unconditional exceeding the limit of dying tasks", v3.
Memory cgroup charging allows killed or exiting tasks to exceed the hard limit. It can be misused and allowed to trigger global OOM from inside a memcg-limited container. On the other hand if memcg fails allocation, called from inside #PF handler it triggers global OOM from inside pagefault_out_of_memory().
To prevent these problems this patchset:
(a) removes execution of out_of_memory() from pagefault_out_of_memory(), becasue nobody can explain why it is necessary.
(b) allow memcg to fail allocation of dying/killed tasks.
This patch (of 3):
Any allocation failure during the #PF path will return with VM_FAULT_OOM which in turn results in pagefault_out_of_memory which in turn executes out_out_memory() and can kill a random task.
An allocation might fail when the current task is the oom victim and there are no memory reserves left. The OOM killer is already handled at the page allocator level for the global OOM and at the charging level for the memcg one. Both have much more information about the scope of allocation/charge request. This means that either the OOM killer has been invoked properly and didn't lead to the allocation success or it has been skipped because it couldn't have been invoked. In both cases triggering it from here is pointless and even harmful.
It makes much more sense to let the killed task die rather than to wake up an eternally hungry oom-killer and send him to choose a fatter victim for breakfast.
--- mm/oom_kill.c | 3 +++ 1 file changed, 3 insertions(+)
mm/oom_kill.c +3 -0
@@ -1112,6 +1112,9 @@ void pagefault_out_of_memory(void)if (mem_cgroup_oom_synchronize (true))return ; +if (fatal_signal_pending (current)) +return ; +if (!mutex_trylock (&oom_lock))return ;out_of_memory (&oc);
Greg Kroah-Hartman
maintainerPATCH 195/251 mm, oom: do not trigger out_of_memory from the #PF
In reply to Greg Kroah-HartmanFrom: Michal Hocko <[email protected]>
commit 60e2793d440a3ec95abb5d6d4fc034a4b480472d upstream.
Any allocation failure during the #PF path will return with VM_FAULT_OOM which in turn results in pagefault_out_of_memory. This can happen for 2 different reasons. a) Memcg is out of memory and we rely on mem_cgroup_oom_synchronize to perform the memcg OOM handling or b) normal allocation fails.
The latter is quite problematic because allocation paths already trigger out_of_memory and the page allocator tries really hard to not fail allocations. Anyway, if the OOM killer has been already invoked there is no reason to invoke it again from the #PF path. Especially when the OOM condition might be gone by that time and we have no way to find out other than allocate.
Moreover if the allocation failed and the OOM killer hasn't been invoked then we are unlikely to do the right thing from the #PF context because we have already lost the allocation context and restictions and therefore might oom kill a task from a different NUMA domain.
This all suggests that there is no legitimate reason to trigger out_of_memory from pagefault_out_of_memory so drop it. Just to be sure that no #PF path returns with VM_FAULT_OOM without allocation print a warning that this is happening before we restart the #PF.
[VvS: #PF allocation can hit into limit of cgroup v1 kmem controller. This is a local problem related to memcg, however, it causes unnecessary global OOM kills that are repeated over and over again and escalate into a real disaster. This has been broken since kmem accounting has been introduced for cgroup v1 (3.8). There was no kmem specific reclaim for the separate limit so the only way to handle kmem hard limit was to return with ENOMEM. In upstream the problem will be fixed by removing the outdated kmem limit, however stable and LTS kernels cannot do it and are still affected. This patch fixes the problem and should be backported into stable/LTS.]
--- mm/oom_kill.c | 22 ++++++++-------------- 1 file changed, 8 insertions(+), 14 deletions(-)
mm/oom_kill.c +8 -14
@@ -1095,19 +1095,15 @@ bool out_of_memory(struct oom_control *o }/* -* The pagefault handler calls here because it is out of memory, so kill a -* memory-hogging task. If oom_lock is held by somebody else, a parallel oom -* killing is already in progress so do nothing. +* The pagefault handler calls here because some allocation has failed. We have +* to take care of the memcg OOM here because this is the only safe context without +* any locks held but let the oom killer triggered from the allocation context care +* about the global OOM. */ void pagefault_out_of_memory (void ) { -struct oom_control oc = { - .zonelist =NULL , - .nodemask =NULL , - .memcg =NULL , - .gfp_mask =0 , - .order =0 , - }; + static DEFINE_RATELIMIT_STATE(pfoom_rs, DEFAULT_RATELIMIT_INTERVAL, + DEFAULT_RATELIMIT_BURST);if (mem_cgroup_oom_synchronize (true))return ;
@@ -1115,8 +1111,6 @@ void pagefault_out_of_memory(void)if (fatal_signal_pending (current))return ; -if (!mutex_trylock (&oom_lock)) -return ; -out_of_memory (&oc); -mutex_unlock (&oom_lock); +if (__ratelimit (&pfoom_rs)) +pr_warn ("Huh VM_FAULT_OOM leaked out to the #PF handler. Retrying PF\n" ); }
Greg Kroah-Hartman
maintainerPATCH 196/251 s390/cio: check the subchannel validity for dev_busid
In reply to Greg Kroah-HartmanFrom: Vineeth Vijayan <[email protected]>
commit a4751f157c194431fae9e9c493f456df8272b871 upstream.
Check the validity of subchanel before reading other fields in the schib.
--- drivers/s390/cio/css.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/s390/cio/css.c +2 -2
@@ -337,8 +337,8 @@ static ssize_t dev_busid_show(struct devstruct subchannel *sch =to_subchannel (dev);struct pmcw *pmcw = &sch->schib.pmcw; -if ((pmcw->st ==SUBCHANNEL_TYPE_IO || - pmcw->st ==SUBCHANNEL_TYPE_MSG ) && pmcw->dnv) +if ((pmcw->st ==SUBCHANNEL_TYPE_IO && pmcw->dnv) || + (pmcw->st ==SUBCHANNEL_TYPE_MSG && pmcw->w))return sysfs_emit (buf,"0.%x.%04x\n" , sch->schid.ssid, pmcw->dev);else
Greg Kroah-Hartman
maintainerPATCH 197/251 PCI: Add PCI_EXP_DEVCTL_PAYLOAD_* macros
In reply to Greg Kroah-HartmanFrom: Pali Rohár <[email protected]>
commit 460275f124fb072dca218a6b43b6370eebbab20d upstream.
Define a macro PCI_EXP_DEVCTL_PAYLOAD_* for every possible Max Payload Size in linux/pci_regs.h, in the same style as PCI_EXP_DEVCTL_READRQ_*.
--- include/uapi/linux/pci_regs.h | 6 ++++++ 1 file changed, 6 insertions(+)
include/uapi/linux/pci_regs.h +6 -0
@@ -497,6 +497,12 @@#define PCI_EXP_DEVCTL_URRE 0x0008/* Unsupported Request Reporting En. */ #define PCI_EXP_DEVCTL_RELAX_EN 0x0010/* Enable relaxed ordering */ #define PCI_EXP_DEVCTL_PAYLOAD 0x00e0/* Max_Payload_Size */ +#define PCI_EXP_DEVCTL_PAYLOAD_128B 0x0000/* 128 Bytes */ +#define PCI_EXP_DEVCTL_PAYLOAD_256B 0x0020/* 256 Bytes */ +#define PCI_EXP_DEVCTL_PAYLOAD_512B 0x0040/* 512 Bytes */ +#define PCI_EXP_DEVCTL_PAYLOAD_1024B 0x0060/* 1024 Bytes */ +#define PCI_EXP_DEVCTL_PAYLOAD_2048B 0x0080/* 2048 Bytes */ +#define PCI_EXP_DEVCTL_PAYLOAD_4096B 0x00a0/* 4096 Bytes */ #define PCI_EXP_DEVCTL_EXT_TAG 0x0100/* Extended Tag Field Enable */ #define PCI_EXP_DEVCTL_PHANTOM 0x0200/* Phantom Functions Enable */ #define PCI_EXP_DEVCTL_AUX_PME 0x0400/* Auxiliary Power PM Enable */
Greg Kroah-Hartman
maintainerPATCH 198/251 ext4: fix lazy initialization next schedule time computation in more granular unit
In reply to Greg Kroah-HartmanFrom: Shaoying Xu <[email protected]>
commit 39fec6889d15a658c3a3ebb06fd69d3584ddffd3 upstream.
Ext4 file system has default lazy inode table initialization setup once it is mounted. However, it has issue on computing the next schedule time that makes the timeout same amount in jiffies but different real time in secs if with various HZ values. Therefore, fix by measuring the current time in a more granular unit nanoseconds and make the next schedule time independent of the HZ value.
--- fs/ext4/super.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
fs/ext4/super.c +4 -5
@@ -2952,8 +2952,8 @@ static int ext4_run_li_request(struct exstruct ext4_group_desc *gdp =NULL ;ext4_group_t group, ngroups;struct super_block *sb; -unsigned long timeout =0 ;int ret =0 ; +u64 start_time; sb = elr->lr_super; ngroups =EXT4_SB (sb)->s_groups_count;
@@ -2973,13 +2973,12 @@ static int ext4_run_li_request(struct ex ret =1 ;if (!ret) { - timeout = jiffies; + start_time =ktime_get_real_ns (); ret =ext4_init_inode_table (sb, group, elr->lr_timeout ?0 :1 );if (elr->lr_timeout ==0 ) { - timeout = (jiffies - timeout) * - elr->lr_sbi->s_li_wait_mult; - elr->lr_timeout = timeout; + elr->lr_timeout =nsecs_to_jiffies ((ktime_get_real_ns () - start_time) * + elr->lr_sbi->s_li_wait_mult); } elr->lr_next_sched = jiffies + elr->lr_timeout; elr->lr_next_group = group +1 ;
Greg Kroah-Hartman
maintainerPATCH 199/251 tracing: Resize tgid_map to pid_max, not PID_MAX_DEFAULT
In reply to Greg Kroah-HartmanFrom: Paul Burton <[email protected]>
commit 4030a6e6a6a4a42ff8c18414c9e0c93e24cc70b8 upstream.
Currently tgid_map is sized at PID_MAX_DEFAULT entries, which means that on systems where pid_max is configured higher than PID_MAX_DEFAULT the ftrace record-tgid option doesn't work so well. Any tasks with PIDs higher than PID_MAX_DEFAULT are simply not recorded in tgid_map, and don't show up in the saved_tgids file.
In particular since systemd v243 & above configure pid_max to its highest possible 1<<22 value by default on 64 bit systems this renders the record-tgids option of little use.
Increase the size of tgid_map to the configured pid_max instead, allowing it to cover the full range of PIDs up to the maximum value of PID_MAX_LIMIT if the system is configured that way.
On 64 bit systems with pid_max == PID_MAX_LIMIT this will increase the size of tgid_map from 256KiB to 16MiB. Whilst this 64x increase in memory overhead sounds significant 64 bit systems are presumably best placed to accommodate it, and since tgid_map is only allocated when the record-tgid option is actually used presumably the user would rather it spends sufficient memory to actually record the tgids they expect.
The size of tgid_map could also increase for CONFIG_BASE_SMALL=y configurations, but these seem unlikely to be systems upon which people are both configuring a large pid_max and running ftrace with record-tgid anyway.
Of note is that we only allocate tgid_map once, the first time that the record-tgid option is enabled. Therefore its size is only set once, to the value of pid_max at the time the record-tgid option is first enabled. If a user increases pid_max after that point, the saved_tgids file will not contain entries for any tasks with pids beyond the earlier value of pid_max.
--- kernel/trace/trace.c | 62 ++++++++++++++++++++++++++++++++++++++------------- 1 file changed, 47 insertions(+), 15 deletions(-)
kernel/trace/trace.c +47 -15
@@ -1723,8 +1723,15 @@ void tracing_reset_all_online_cpus(void) } } +/* +* The tgid_map array maps from pid to tgid; i.e. the value stored at index i +* is the tgid last observed corresponding to pid=i. +*/ static int *tgid_map; +/* The maximum valid index into tgid_map. */ +static size_t tgid_map_max; +#define SAVED_CMDLINES_DEFAULT 128#define NO_CMDLINE_MAP UINT_MAXstatic arch_spinlock_t trace_cmdline_lock = __ARCH_SPIN_LOCK_UNLOCKED;
@@ -1996,24 +2003,41 @@ void trace_find_cmdline(int pid, char copreempt_enable (); } +static int *trace_find_tgid_ptr (int pid) +{ +/* +* Pairs with the smp_store_release in set_tracer_flag() to ensure that +* if we observe a non-NULL tgid_map then we also observe the correct +* tgid_map_max. +*/ +int *map =smp_load_acquire (&tgid_map); + +if (unlikely (!map || pid > tgid_map_max)) +return NULL ; + +return &map[pid]; +} +int trace_find_tgid (int pid) { -if (unlikely (!tgid_map || !pid || pid >PID_MAX_DEFAULT )) -return 0 ; +int *ptr =trace_find_tgid_ptr (pid); -return tgid_map[pid]; +return ptr ? *ptr :0 ; }static int trace_save_tgid (struct task_struct *tsk) { +int *ptr; +/* treat recording of idle task as a success */ if (!tsk->pid)return 1 ; -if (unlikely (!tgid_map || tsk->pid >PID_MAX_DEFAULT )) + ptr =trace_find_tgid_ptr (tsk->pid); +if (!ptr)return 0 ; - tgid_map[tsk->pid] = tsk->tgid; + *ptr = tsk->tgid;return 1 ; }
@@ -4353,6 +4377,8 @@ int trace_keep_overwrite(struct tracer *int set_tracer_flag (struct trace_array *tr,unsigned int mask,int enabled) { +int *map; +if ((mask ==TRACE_ITER_RECORD_TGID ) || (mask ==TRACE_ITER_RECORD_CMD ))lockdep_assert_held (&event_mutex);
@@ -4375,9 +4401,19 @@ int set_tracer_flag(struct trace_array *trace_event_enable_cmd_record (enabled);if (mask ==TRACE_ITER_RECORD_TGID ) { -if (!tgid_map) - tgid_map =kzalloc ((PID_MAX_DEFAULT +1 ) *sizeof (*tgid_map), -GFP_KERNEL ); +if (!tgid_map) { + tgid_map_max = pid_max; + map =kzalloc ((tgid_map_max +1 ) *sizeof (*tgid_map), +GFP_KERNEL ); + +/* +* Pairs with smp_load_acquire() in +* trace_find_tgid_ptr() to ensure that if it observes +* the tgid_map we just allocated then it also observes +* the corresponding tgid_map_max value. +*/ +smp_store_release (&tgid_map, map); + }if (!tgid_map) { tr->trace_flags &= ~TRACE_ITER_RECORD_TGID ;return -ENOMEM ;
@@ -4752,18 +4788,14 @@ static void *saved_tgids_next(struct seq {int pid = ++(*pos); -if (pid >PID_MAX_DEFAULT ) -return NULL ; - -return &tgid_map[pid]; +return trace_find_tgid_ptr (pid); }static void *saved_tgids_start (struct seq_file *m,loff_t *pos) { -if (!tgid_map || *pos >PID_MAX_DEFAULT ) -return NULL ; +int pid = *pos; -return &tgid_map[*pos]; +return trace_find_tgid_ptr (pid); }static void saved_tgids_stop (struct seq_file *m,void *v)
Greg Kroah-Hartman
maintainerPATCH 200/251 parisc/entry: fix trace test in syscall exit path
In reply to Greg Kroah-HartmanFrom: Sven Schnelle <[email protected]>
commit 3ec18fc7831e7d79e2d536dd1f3bc0d3ba425e8a upstream.
commit 8779e05ba8aa ("parisc: Fix ptrace check on syscall return") fixed testing of TI_FLAGS. This uncovered a bug in the test mask. syscall_restore_rfi is only used when the kernel needs to exit to usespace with single or block stepping and the recovery counter enabled. The test however used _TIF_SYSCALL_TRACE_MASK, which includes a lot of bits that shouldn't be tested here.
Fix this by using TIF_SINGLESTEP and TIF_BLOCKSTEP directly.
I encountered this bug by enabling syscall tracepoints. Both in qemu and on real hardware. As soon as i enabled the tracepoint (sys_exit_read, but i guess it doesn't really matter which one), i got random page faults in userspace almost immediately.
--- arch/parisc/kernel/entry.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/parisc/kernel/entry.S +1 -1
@@ -1850,7 +1850,7 @@ syscall_restore: /* Are we being ptraced? */ LDREG TI_FLAGS-THREAD_SZ_ALGN-FRAME_SIZE(%r30),%r19 - ldi _TIF_SYSCALL_TRACE_MASK,%r2 + ldi _TIF_SINGLESTEP|_TIF_BLOCKSTEP,%r2 and,COND(=) %r19,%r2,%r0 b,n syscall_restore_rfi
Greg Kroah-Hartman
maintainerPATCH 201/251 PCI/MSI: Destroy sysfs before freeing entries
In reply to Greg Kroah-HartmanFrom: Thomas Gleixner <[email protected]>
commit 3735459037114d31e5acd9894fad9aed104231a0 upstream.
free_msi_irqs() frees the MSI entries before destroying the sysfs entries which are exposing them. Nothing prevents a concurrent free while a sysfs file is read and accesses the possibly freed entry.
Move the sysfs release ahead of freeing the entries.
--- drivers/pci/msi.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-)
drivers/pci/msi.c +12 -12
@@ -372,18 +372,6 @@ static void free_msi_irqs(struct pci_devfor (i =0 ; i < entry->nvec_used; i++)BUG_ON (irq_has_action (entry->irq + i)); -pci_msi_teardown_msi_irqs (dev); - -list_for_each_entry_safe (entry, tmp, msi_list, list) { -if (entry->msi_attrib.is_msix) { -if (list_is_last (&entry->list, msi_list)) -iounmap (entry->mask_base); - } - -list_del (&entry->list); -free_msi_entry (entry); - } -if (dev->msi_irq_groups) {sysfs_remove_groups (&dev->dev.kobj, dev->msi_irq_groups); msi_attrs = dev->msi_irq_groups[0 ]->attrs;
@@ -399,6 +387,18 @@ static void free_msi_irqs(struct pci_devkfree (dev->msi_irq_groups); dev->msi_irq_groups =NULL ; } + +pci_msi_teardown_msi_irqs (dev); + +list_for_each_entry_safe (entry, tmp, msi_list, list) { +if (entry->msi_attrib.is_msix) { +if (list_is_last (&entry->list, msi_list)) +iounmap (entry->mask_base); + } + +list_del (&entry->list); +free_msi_entry (entry); + } }static void pci_intx_for_msi (struct pci_dev *dev,int enable)
Greg Kroah-Hartman
maintainerPATCH 202/251 arm64: zynqmp: Fix serial compatible string
In reply to Greg Kroah-HartmanFrom: Michal Simek <[email protected]>
[ Upstream commit 812fa2f0e9d33564bd0131a69750e0d165f4c82a ]
Based on commit 65a2c14d4f00 ("dt-bindings: serial: convert Cadence UART bindings to YAML") compatible string should look like differently that's why fix it to be aligned with dt binding.
--- arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm64/boot/dts/xilinx/zynqmp.dtsi +2 -2
@@ -573,7 +573,7 @@ }; uart0: serial@ff000000 { - compatible = "cdns,uart-r1p12", "xlnx,xuartps"; + compatible = "xlnx,zynqmp-uart", "cdns,uart-r1p12"; status = "disabled"; interrupt-parent = <&gic>; interrupts = <0 21 4>;
@@ -582,7 +582,7 @@ }; uart1: serial@ff010000 { - compatible = "cdns,uart-r1p12", "xlnx,xuartps"; + compatible = "xlnx,zynqmp-uart", "cdns,uart-r1p12"; status = "disabled"; interrupt-parent = <&gic>; interrupts = <0 22 4>;
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 203/251 scsi: lpfc: Fix list_add() corruption in lpfc_drain_txq()
In reply to Greg Kroah-HartmanFrom: James Smart <[email protected]>
[ Upstream commit 99154581b05c8fb22607afb7c3d66c1bace6aa5d ]
When parsing the txq list in lpfc_drain_txq(), the driver attempts to pass the requests to the adapter. If such an attempt fails, a local "fail_msg" string is set and a log message output. The job is then added to a completions list for cancellation.
Processing of any further jobs from the txq list continues, but since "fail_msg" remains set, jobs are added to the completions list regardless of whether a wqe was passed to the adapter. If successfully added to txcmplq, jobs are added to both lists resulting in list corruption.
Fix by clearing the fail_msg string after adding a job to the completions list. This stops the subsequent jobs from being added to the completions list unless they had an appropriate failure.
--- drivers/scsi/lpfc/lpfc_sli.c | 1 + 1 file changed, 1 insertion(+)
drivers/scsi/lpfc/lpfc_sli.c +1 -0
@@ -18777,6 +18777,7 @@ lpfc_drain_txq(struct lpfc_hba *phba) fail_msg, piocbq->iotag, piocbq->sli4_xritag);list_add_tail (&piocbq->list, &completions); + fail_msg =NULL ; }spin_unlock_irqrestore (&pring->ring_lock, iflags); }
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 204/251 usb: musb: tusb6010: check return value after calling platform_get_resource()
In reply to Greg Kroah-HartmanFrom: Yang Yingliang <[email protected]>
[ Upstream commit 14651496a3de6807a17c310f63c894ea0c5d858e ]
It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value.
--- drivers/usb/musb/tusb6010.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/usb/musb/tusb6010.c +5 -0
@@ -1108,6 +1108,11 @@ static int tusb_musb_init(struct musb *musb)/* dma address for async dma */ mem =platform_get_resource (pdev,IORESOURCE_MEM ,0 ); +if (!mem) { +pr_debug ("no async dma resource?\n" ); + ret = -ENODEV ; + goto done; + } musb->async = mem->start;/* dma address for sync dma */
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 205/251 scsi: advansys: Fix kernel pointer leak
In reply to Greg Kroah-HartmanFrom: Guo Zhi <[email protected]>
[ Upstream commit d4996c6eac4c81b8872043e9391563f67f13e406 ]
Pointers should be printed with %p or %px rather than cast to 'unsigned long' and printed with %lx.
Change %lx to %p to print the hashed pointer.
--- drivers/scsi/advansys.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/scsi/advansys.c +2 -2
@@ -3370,8 +3370,8 @@ static void asc_prt_adv_board_info(struct seq_file *m, struct Scsi_Host *shost) shost->host_no);seq_printf (m, -" iop_base 0x%lx, cable_detect: %X, err_code %u\n" , - (unsigned long )v->iop_base, +" iop_base 0x%p, cable_detect: %X, err_code %u\n" , + v->iop_base,AdvReadWordRegister (iop_base,IOPW_SCSI_CFG1 ) &CABLE_DETECT , v->err_code);
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 206/251 ARM: dts: omap: fix gpmc,mux-add-data type
In reply to Greg Kroah-HartmanFrom: Roger Quadros <[email protected]>
[ Upstream commit 51b9e22ffd3c4c56cbb7caae9750f70e55ffa603 ]
gpmc,mux-add-data is not boolean.
Fixes the below errors flagged by dtbs_check.
"ethernet@4,0:gpmc,mux-add-data: True is not of type 'array'"
--- arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi | 2 +- arch/arm/boot/dts/omap3-overo-tobiduo-common.dtsi | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi +1 -1
@@ -29,7 +29,7 @@ compatible = "smsc,lan9221","smsc,lan9115"; bank-width = <2>; - gpmc,mux-add-data; + gpmc,mux-add-data = <0>; gpmc,cs-on-ns = <0>; gpmc,cs-rd-off-ns = <42>; gpmc,cs-wr-off-ns = <36>;
arch/arm/boot/dts/omap3-overo-tobiduo-common.dtsi +1 -1
@@ -25,7 +25,7 @@ compatible = "smsc,lan9221","smsc,lan9115"; bank-width = <2>; - gpmc,mux-add-data; + gpmc,mux-add-data = <0>; gpmc,cs-on-ns = <0>; gpmc,cs-rd-off-ns = <42>; gpmc,cs-wr-off-ns = <36>;
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 207/251 usb: host: ohci-tmio: check return value after calling platform_get_resource()
In reply to Greg Kroah-HartmanFrom: Yang Yingliang <[email protected]>
[ Upstream commit 9eff2b2e59fda25051ab36cd1cb5014661df657b ]
It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value.
--- drivers/usb/host/ohci-tmio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/host/ohci-tmio.c +1 -1
@@ -199,7 +199,7 @@ static int ohci_hcd_tmio_drv_probe(struct platform_device *dev)if (usb_disabled ())return -ENODEV ; -if (!cell) +if (!cell || !regs || !config || !sram)return -EINVAL ;if (irq <0 )
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 208/251 tty: tty_buffer: Fix the softlockup issue in flush_to_ldisc
In reply to Greg Kroah-HartmanFrom: Guanghui Feng <[email protected]>
[ Upstream commit 3968ddcf05fb4b9409cd1859feb06a5b0550a1c1 ]
When running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a soft lockup, which look like this one:
Workqueue: events_unbound flush_to_ldisc Call trace: dump_backtrace+0x0/0x1ec show_stack+0x24/0x30 dump_stack+0xd0/0x128 panic+0x15c/0x374 watchdog_timer_fn+0x2b8/0x304 __run_hrtimer+0x88/0x2c0 __hrtimer_run_queues+0xa4/0x120 hrtimer_interrupt+0xfc/0x270 arch_timer_handler_phys+0x40/0x50 handle_percpu_devid_irq+0x94/0x220 __handle_domain_irq+0x88/0xf0 gic_handle_irq+0x84/0xfc el1_irq+0xc8/0x180 slip_unesc+0x80/0x214 [slip] tty_ldisc_receive_buf+0x64/0x80 tty_port_default_receive_buf+0x50/0x90 flush_to_ldisc+0xbc/0x110 process_one_work+0x1d4/0x4b0 worker_thread+0x180/0x430 kthread+0x11c/0x120
In the testcase pty04, The first process call the write syscall to send data to the pty master. At the same time, the workqueue will do the flush_to_ldisc to pop data in a loop until there is no more data left. When the sender and workqueue running in different core, the sender sends data fastly in full time which will result in workqueue doing work in loop for a long time and occuring softlockup in flush_to_ldisc with kernel configured without preempt. So I add need_resched check and cond_resched in the flush_to_ldisc loop to avoid it.
--- drivers/tty/tty_buffer.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/tty/tty_buffer.c +3 -0
@@ -528,6 +528,9 @@ static void flush_to_ldisc(struct work_struct *work)if (!count)break ; head->read += count; + +if (need_resched ()) +cond_resched (); }mutex_unlock (&buf->lock);
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 209/251 MIPS: sni: Fix the build
In reply to Greg Kroah-HartmanFrom: Bart Van Assche <[email protected]>
[ Upstream commit c91cf42f61dc77b289784ea7b15a8531defa41c0 ]
This patch fixes the following gcc 10 build error:
arch/mips/sni/time.c: In function ‘a20r_set_periodic’:arch/mips/sni/time.c:15:26: error: unsigned conversion from ‘int’ to ‘u8’ {aka ‘volatile unsigned char’} changes value from ‘576’ to ‘64’ [-Werror=overflow]
15 | #define SNI_COUNTER0_DIV ((SNI_CLOCK_TICK_RATE / SNI_COUNTER2_DIV) / HZ)
| ^arch/mips/sni/time.c:21:45: note: in expansion of macro ‘SNI_COUNTER0_DIV’
21 | *(volatile u8 *)(A20R_PT_CLOCK_BASE + 0) = SNI_COUNTER0_DIV;
| ^~~~~~~~~~~~~~~~--- arch/mips/sni/time.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/mips/sni/time.c +2 -2
@@ -18,14 +18,14 @@ static int a20r_set_periodic(struct clock_event_device *evt) { *(volatile u8 *)(A20R_PT_CLOCK_BASE +12 ) =0x34 ;wmb (); - *(volatile u8 *)(A20R_PT_CLOCK_BASE +0 ) =SNI_COUNTER0_DIV ; + *(volatile u8 *)(A20R_PT_CLOCK_BASE +0 ) =SNI_COUNTER0_DIV &0xff ;wmb (); *(volatile u8 *)(A20R_PT_CLOCK_BASE +0 ) =SNI_COUNTER0_DIV >>8 ;wmb (); *(volatile u8 *)(A20R_PT_CLOCK_BASE +12 ) =0xb4 ;wmb (); - *(volatile u8 *)(A20R_PT_CLOCK_BASE +8 ) =SNI_COUNTER2_DIV ; + *(volatile u8 *)(A20R_PT_CLOCK_BASE +8 ) =SNI_COUNTER2_DIV &0xff ;wmb (); *(volatile u8 *)(A20R_PT_CLOCK_BASE +8 ) =SNI_COUNTER2_DIV >>8 ;wmb ();
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 210/251 scsi: target: Fix ordered tag handling
In reply to Greg Kroah-HartmanFrom: Mike Christie <[email protected]>
[ Upstream commit ed1227e080990ffec5bf39006ec8a57358e6689a ]
This patch fixes the following bugs:
1. If there are multiple ordered cmds queued and multiple simple cmds completing, target_restart_delayed_cmds() could be called on different CPUs and each instance could start a ordered cmd. They could then run in different orders than they were queued.
2. target_restart_delayed_cmds() and target_handle_task_attr() can race where:
1. target_handle_task_attr() has passed the simple_cmds == 0 check.
2. transport_complete_task_attr() then decrements simple_cmds to 0.
3. transport_complete_task_attr() runs target_restart_delayed_cmds() and it does not see any cmds on the delayed_cmd_list.
4. target_handle_task_attr() adds the cmd to the delayed_cmd_list.
The cmd will then end up timing out.
3. If we are sent > 1 ordered cmds and simple_cmds == 0, we can execute them out of order, because target_handle_task_attr() will hit that simple_cmds check first and return false for all ordered cmds sent.
4. We run target_restart_delayed_cmds() after every cmd completion, so if there is more than 1 simple cmd running, we start executing ordered cmds after that first cmd instead of waiting for all of them to complete.
5. Ordered cmds are not supposed to start until HEAD OF QUEUE and all older cmds have completed, and not just simple.
6. It's not a bug but it doesn't make sense to take the delayed_cmd_lock for every cmd completion when ordered cmds are almost never used. Just replacing that lock with an atomic increases IOPs by up to 10% when completions are spread over multiple CPUs and there are multiple sessions/ mqs/thread accessing the same device.
This patch moves the queued delayed handling to a per device work to serialze the cmd executions for each device and adds a new counter to track HEAD_OF_QUEUE and SIMPLE cmds. We can then check the new counter to determine when to run the work on the completion path.
--- drivers/target/target_core_device.c | 2 + drivers/target/target_core_internal.h | 1 + drivers/target/target_core_transport.c | 76 ++++++++++++++++++-------- include/target/target_core_base.h | 6 +- 4 files changed, 61 insertions(+), 24 deletions(-)
drivers/target/target_core_device.c +2 -0
@@ -791,6 +791,8 @@ struct se_device *target_alloc_device(struct se_hba *hba, const char *name)INIT_LIST_HEAD (&dev->t10_alua.lba_map_list);spin_lock_init (&dev->t10_alua.lba_map_lock); +INIT_WORK (&dev->delayed_cmd_work, target_do_delayed_work); + dev->t10_wwn.t10_dev = dev; dev->t10_alua.t10_dev = dev;
drivers/target/target_core_internal.h +1 -0
@@ -149,6 +149,7 @@ void transport_clear_lun_ref(struct se_lun *);void transport_send_task_abort (struct se_cmd *);sense_reason_t target_cmd_size_check (struct se_cmd *cmd,unsigned int size);void target_qf_do_work (struct work_struct *work); +void target_do_delayed_work (struct work_struct *work);bool target_check_wce (struct se_device *dev);bool target_check_fua (struct se_device *dev);void __target_execute_cmd (struct se_cmd *,bool );
drivers/target/target_core_transport.c +54 -22
142 lines not on this page · raw message
include/target/target_core_base.h +4 -2
@@ -771,8 +771,9 @@ struct se_device {atomic_long_t read_bytes;atomic_long_t write_bytes;/* Active commands on this virtual SE device */ -atomic_t simple_cmds; -atomic_t dev_ordered_sync; +atomic_t non_ordered; +bool ordered_sync_in_progress; +atomic_t delayed_cmd_count;atomic_t dev_qf_count;u32 export_count;spinlock_t delayed_cmd_lock;
@@ -795,6 +796,7 @@ struct se_device {struct list_head dev_tmr_list;struct workqueue_struct *tmr_wq;struct work_struct qf_work_queue; +struct work_struct delayed_cmd_work;struct list_head delayed_cmd_list;struct list_head state_list;struct list_head qf_cmd_list;
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 211/251 scsi: target: Fix alua_tg_pt_gps_count tracking
In reply to Greg Kroah-HartmanFrom: Mike Christie <[email protected]>
[ Upstream commit 1283c0d1a32bb924324481586b5d6e8e76f676ba ]
We can't free the tg_pt_gp in core_alua_set_tg_pt_gp_id() because it's still accessed via configfs. Its release must go through the normal configfs/refcount process.
The max alua_tg_pt_gps_count check should probably have been done in core_alua_allocate_tg_pt_gp(), but with the current code userspace could have created 0x0000ffff + 1 groups, but only set the id for 0x0000ffff. Then it could have deleted a group with an ID set, and then set the ID for that extra group and it would work ok.
It's unlikely, but just in case this patch continues to allow that type of behavior, and just fixes the kfree() while in use bug.
--- drivers/target/target_core_alua.c | 1 - 1 file changed, 1 deletion(-)
drivers/target/target_core_alua.c +0 -1
@@ -1711,7 +1711,6 @@ int core_alua_set_tg_pt_gp_id(pr_err ("Maximum ALUA alua_tg_pt_gps_count:" " 0x0000ffff reached\n" );spin_unlock (&dev->t10_alua.tg_pt_gps_lock); -kmem_cache_free (t10_alua_tg_pt_gp_cache, tg_pt_gp);return -ENOSPC ; } again:
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 212/251 powerpc/5200: dts: fix memory node unit name
In reply to Greg Kroah-HartmanFrom: Anatolij Gustschin <[email protected]>
[ Upstream commit aed2886a5e9ffc8269a4220bff1e9e030d3d2eb1 ]
Fixes build warnings:
Warning (unit_address_vs_reg): /memory: node has a reg or ranges property, but no unit name
--- arch/powerpc/boot/dts/charon.dts | 2 +- arch/powerpc/boot/dts/digsy_mtc.dts | 2 +- arch/powerpc/boot/dts/lite5200.dts | 2 +- arch/powerpc/boot/dts/lite5200b.dts | 2 +- arch/powerpc/boot/dts/media5200.dts | 2 +- arch/powerpc/boot/dts/mpc5200b.dtsi | 2 +- arch/powerpc/boot/dts/o2d.dts | 2 +- arch/powerpc/boot/dts/o2d.dtsi | 2 +- arch/powerpc/boot/dts/o2dnt2.dts | 2 +- arch/powerpc/boot/dts/o3dnt.dts | 2 +- arch/powerpc/boot/dts/pcm032.dts | 2 +- arch/powerpc/boot/dts/tqm5200.dts | 2 +- 12 files changed, 12 insertions(+), 12 deletions(-)
arch/powerpc/boot/dts/charon.dts +1 -1
@@ -39,7 +39,7 @@ }; }; - memory { + memory@0 { device_type = "memory"; reg = <0x00000000 0x08000000>; // 128MB };
arch/powerpc/boot/dts/digsy_mtc.dts +1 -1
@@ -20,7 +20,7 @@ model = "intercontrol,digsy-mtc"; compatible = "intercontrol,digsy-mtc"; - memory { + memory@0 { reg = <0x00000000 0x02000000>; // 32MB };
arch/powerpc/boot/dts/lite5200.dts +1 -1
@@ -36,7 +36,7 @@ }; }; - memory { + memory@0 { device_type = "memory"; reg = <0x00000000 0x04000000>; // 64MB };
arch/powerpc/boot/dts/lite5200b.dts +1 -1
@@ -35,7 +35,7 @@ led4 { gpios = <&gpio_simple 2 1>; }; }; - memory { + memory@0 { reg = <0x00000000 0x10000000>; // 256MB };
arch/powerpc/boot/dts/media5200.dts +1 -1
@@ -36,7 +36,7 @@ }; }; - memory { + memory@0 { reg = <0x00000000 0x08000000>; // 128MB RAM };
arch/powerpc/boot/dts/mpc5200b.dtsi +1 -1
@@ -37,7 +37,7 @@ }; }; - memory: memory { + memory: memory@0 { device_type = "memory"; reg = <0x00000000 0x04000000>; // 64MB };
arch/powerpc/boot/dts/o2d.dts +1 -1
@@ -16,7 +16,7 @@ model = "ifm,o2d"; compatible = "ifm,o2d"; - memory { + memory@0 { reg = <0x00000000 0x08000000>; // 128MB };
arch/powerpc/boot/dts/o2d.dtsi +1 -1
@@ -23,7 +23,7 @@ model = "ifm,o2d"; compatible = "ifm,o2d"; - memory { + memory@0 { reg = <0x00000000 0x04000000>; // 64MB };
arch/powerpc/boot/dts/o2dnt2.dts +1 -1
@@ -16,7 +16,7 @@ model = "ifm,o2dnt2"; compatible = "ifm,o2d"; - memory { + memory@0 { reg = <0x00000000 0x08000000>; // 128MB };
arch/powerpc/boot/dts/o3dnt.dts +1 -1
@@ -16,7 +16,7 @@ model = "ifm,o3dnt"; compatible = "ifm,o2d"; - memory { + memory@0 { reg = <0x00000000 0x04000000>; // 64MB };
arch/powerpc/boot/dts/pcm032.dts +1 -1
@@ -26,7 +26,7 @@ model = "phytec,pcm032"; compatible = "phytec,pcm032"; - memory { + memory@0 { reg = <0x00000000 0x08000000>; // 128MB };
arch/powerpc/boot/dts/tqm5200.dts +1 -1
@@ -36,7 +36,7 @@ }; }; - memory { + memory@0 { device_type = "memory"; reg = <0x00000000 0x04000000>; // 64MB };
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 213/251 ALSA: gus: fix null pointer dereference on pointer block
In reply to Greg Kroah-HartmanFrom: Chengfeng Ye <[email protected]>
[ Upstream commit a0d21bb3279476c777434c40d969ea88ca64f9aa ]
The pointer block return from snd_gf1_dma_next_block could be null, so there is a potential null pointer dereference issue. Fix this by adding a null check before dereference.
--- sound/isa/gus/gus_dma.c | 2 ++ 1 file changed, 2 insertions(+)
sound/isa/gus/gus_dma.c +2 -0
@@ -141,6 +141,8 @@ static void snd_gf1_dma_interrupt(struct snd_gus_card * gus) } block =snd_gf1_dma_next_block (gus);spin_unlock (&gus->dma_lock); +if (!block) +return ;snd_gf1_dma_program (gus, block->addr, block->buf_addr, block->count, (unsigned short ) block->cmd);kfree (block);#if 0
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 214/251 powerpc/dcr: Use cmplwi instead of 3-argument cmpli
In reply to Greg Kroah-HartmanFrom: Michael Ellerman <[email protected]>
[ Upstream commit fef071be57dc43679a32d5b0e6ee176d6f12e9f2 ]
In dcr-low.S we use cmpli with three arguments, instead of four arguments as defined in the ISA:
cmpli cr0,r3,1024
This appears to be a PPC440-ism, looking at the "PPC440x5 CPU Core User’s Manual" it shows cmpli having no L field, but implied to be 0 due to the core being 32-bit. It mentions that the ISA defines four arguments and recommends using cmplwi.
It also corresponds to the old POWER instruction set, which had no L field there, a reserved bit instead.
dcr-low.S is only built 32-bit, because it is only built when DCR_NATIVE=y, which is only selected by 40x and 44x. Looking at the generated code (with gcc/gas) we see cmplwi as expected.
Although gas is happy with the 3-argument version when building for 32-bit, the LLVM assembler is not and errors out with:
arch/powerpc/sysdev/dcr-low.S:27:10: error: invalid operand for instruction
cmpli 0,%r3,1024; ...
^
Switch to the cmplwi extended opcode, which avoids any confusion when reading the ISA, fixes the issue with the LLVM assembler, and also means the code could be built 64-bit in future (though that's very unlikely).
--- arch/powerpc/sysdev/dcr-low.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/sysdev/dcr-low.S +1 -1
@@ -15,7 +15,7 @@ #include <asm/export.h> #define DCR_ACCESS_PROLOG(table) \ - cmpli cr0,r3,1024; \ + cmplwi cr0,r3,1024; \ rlwinm r3,r3,4,18,27; \ lis r5,table@h; \ ori r5,r5,table@l; \
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 215/251 sh: check return code of request_irq
In reply to Greg Kroah-HartmanFrom: Nick Desaulniers <[email protected]>
[ Upstream commit 0e38225c92c7964482a8bb6b3e37fde4319e965c ]
request_irq is marked __must_check, but the call in shx3_prepare_cpus has a void return type, so it can't propagate failure to the caller. Follow cues from hexagon and just print an error.
--- arch/sh/kernel/cpu/sh4a/smp-shx3.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
arch/sh/kernel/cpu/sh4a/smp-shx3.c +3 -2
@@ -76,8 +76,9 @@ static void shx3_prepare_cpus(unsigned int max_cpus)BUILD_BUG_ON (SMP_MSG_NR >=8 );for (i =0 ; i <SMP_MSG_NR ; i++) -request_irq (104 + i, ipi_interrupt_handler, -IRQF_PERCPU ,"IPI" , (void *)(long )i); +if (request_irq (104 + i, ipi_interrupt_handler, +IRQF_PERCPU ,"IPI" , (void *)(long )i)) +pr_err ("Failed to request irq %d\n" , i);for (i =0 ; i < max_cpus; i++)set_cpu_present (i, true);
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 216/251 maple: fix wrong return value of maple_bus_init().
In reply to Greg Kroah-HartmanFrom: Lu Wei <[email protected]>
[ Upstream commit bde82ee391fa6d3ad054313c4aa7b726d32515ce ]
If KMEM_CACHE or maple_alloc_dev failed, the maple_bus_init() will return 0 rather than error, because the retval is not changed after KMEM_CACHE or maple_alloc_dev failed.
--- drivers/sh/maple/maple.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/sh/maple/maple.c +4 -1
@@ -835,8 +835,10 @@ static int __init maple_bus_init(void) maple_queue_cache =KMEM_CACHE (maple_buffer,SLAB_HWCACHE_ALIGN ); -if (!maple_queue_cache) +if (!maple_queue_cache) { + retval = -ENOMEM ; goto cleanup_bothirqs; + }INIT_LIST_HEAD (&maple_waitq);INIT_LIST_HEAD (&maple_sentq);
@@ -849,6 +851,7 @@ static int __init maple_bus_init(void)if (!mdev[i]) {while (i-- >0 )maple_free_dev (mdev[i]); + retval = -ENOMEM ; goto cleanup_cache; } baseunits[i] = mdev[i];
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 217/251 sh: fix kconfig unmet dependency warning for FRAME_POINTER
In reply to Greg Kroah-HartmanFrom: Randy Dunlap <[email protected]>
[ Upstream commit fda1bc533094a7db68b11e7503d2c6c73993d12a ]
FRAME_POINTER depends on DEBUG_KERNEL so DWARF_UNWINDER should depend on DEBUG_KERNEL before selecting FRAME_POINTER.
WARNING: unmet direct dependencies detected for FRAME_POINTER
Depends on [n]: DEBUG_KERNEL [=n] && (M68K || UML || SUPERH [=y]) || ARCH_WANT_FRAME_POINTERS [=n] Selected by [y]:
- DWARF_UNWINDER [=y]
--- arch/sh/Kconfig.debug | 1 + 1 file changed, 1 insertion(+)
arch/sh/Kconfig.debug +1 -0
@@ -61,6 +61,7 @@ config DUMP_CODE config DWARF_UNWINDER bool "Enable the DWARF unwinder for stacktraces" + depends on DEBUG_KERNEL select FRAME_POINTER depends on SUPERH32 default n
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 218/251 sh: define __BIG_ENDIAN for math-emu
In reply to Greg Kroah-HartmanFrom: Randy Dunlap <[email protected]>
[ Upstream commit b929926f01f2d14635345d22eafcf60feed1085e ]
Fix this by defining both ENDIAN macros in <asm/sfp-machine.h> so that they can be utilized in <math-emu/soft-fp.h> according to the latter's comment:
/* Allow sfp-machine to have its own byte order definitions. */
(This is what is done in arch/nds32/include/asm/sfp-machine.h.)
This placates these build warnings:
In file included from ../arch/sh/math-emu/math.c:23:.../include/math-emu/single.h:50:21: warning: "__BIG_ENDIAN" is not defined, evaluates to 0 [-Wundef]
50 | #if __BYTE_ORDER == __BIG_ENDIAN
In file included from ../arch/sh/math-emu/math.c:24:.../include/math-emu/double.h:59:21: warning: "__BIG_ENDIAN" is not defined, evaluates to 0 [-Wundef]
59 | #if __BYTE_ORDER == __BIG_ENDIAN
--- arch/sh/include/asm/sfp-machine.h | 8 ++++++++ 1 file changed, 8 insertions(+)
arch/sh/include/asm/sfp-machine.h +8 -0
@@ -25,6 +25,14 @@#ifndef _SFP_MACHINE_H#define _SFP_MACHINE_H +#ifdef __BIG_ENDIAN__ +#define __BYTE_ORDER __BIG_ENDIAN +#define __LITTLE_ENDIAN 0 +#else +#define __BYTE_ORDER __LITTLE_ENDIAN +#define __BIG_ENDIAN 0 +#endif +#define _FP_W_TYPE_SIZE 32#define _FP_W_TYPE unsigned long#define _FP_WS_TYPE signed long
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 219/251 mips: BCM63XX: ensure that CPU_SUPPORTS_32BIT_KERNEL is set
In reply to Greg Kroah-HartmanFrom: Randy Dunlap <[email protected]>
[ Upstream commit 5eeaafc8d69373c095e461bdb39e5c9b62228ac5 ]
Several header files need info on CONFIG_32BIT or CONFIG_64BIT, but kconfig symbol BCM63XX does not provide that info. This leads to many build errors, e.g.:
arch/mips/include/asm/page.h:196:13: error: use of undeclared identifier 'CAC_BASE'
return x - PAGE_OFFSET + PHYS_OFFSET;
arch/mips/include/asm/mach-generic/spaces.h:91:23: note: expanded from macro 'PAGE_OFFSET'
#define PAGE_OFFSET (CAC_BASE + PHYS_OFFSET)
arch/mips/include/asm/io.h:134:28: error: use of undeclared identifier 'CAC_BASE'
return (void *)(address + PAGE_OFFSET - PHYS_OFFSET);
arch/mips/include/asm/mach-generic/spaces.h:91:23: note: expanded from macro 'PAGE_OFFSET'
#define PAGE_OFFSET (CAC_BASE + PHYS_OFFSET)arch/mips/include/asm/uaccess.h:82:10: error: use of undeclared identifier '__UA_LIMIT'
return (__UA_LIMIT & (addr | (addr + size) | __ua_size(size))) == 0;
Selecting the SYS_HAS_CPU_BMIPS* symbols causes SYS_HAS_CPU_BMIPS to be set, which then selects CPU_SUPPORT_32BIT_KERNEL, which causes CONFIG_32BIT to be set. (a bit more indirect than v1 [RFC].)
--- arch/mips/Kconfig | 3 +++ 1 file changed, 3 insertions(+)
arch/mips/Kconfig +3 -0
@@ -273,6 +273,9 @@ config BCM63XX select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_BIG_ENDIAN select SYS_HAS_EARLY_PRINTK + select SYS_HAS_CPU_BMIPS32_3300 + select SYS_HAS_CPU_BMIPS4350 + select SYS_HAS_CPU_BMIPS4380 select SWAP_IO_SPACE select GPIOLIB select HAVE_CLK
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 220/251 sched/core: Mitigate race cpus_share_cache()/update_top_cache_domain()
In reply to Greg Kroah-HartmanFrom: Vincent Donnefort <[email protected]>
[ Upstream commit 42dc938a590c96eeb429e1830123fef2366d9c80 ]
Nothing protects the access to the per_cpu variable sd_llc_id. When testing the same CPU (i.e. this_cpu == that_cpu), a race condition exists with update_top_cache_domain(). One scenario being:
CPU1 CPU2
==================================================================
per_cpu(sd_llc_id, CPUX) => 0
partition_sched_domains_locked()
detach_destroy_domains()
cpus_share_cache(CPUX, CPUX) update_top_cache_domain(CPUX)
per_cpu(sd_llc_id, CPUX) => 0
per_cpu(sd_llc_id, CPUX) = CPUX
per_cpu(sd_llc_id, CPUX) => CPUX
return false
ttwu_queue_cond() wouldn't catch smp_processor_id() == cpu and the result is a warning triggered from ttwu_queue_wakelist().
Avoid a such race in cpus_share_cache() by always returning true when this_cpu == that_cpu.
--- kernel/sched/core.c | 3 +++ 1 file changed, 3 insertions(+)
kernel/sched/core.c +3 -0
@@ -1852,6 +1852,9 @@ out:bool cpus_share_cache (int this_cpu,int that_cpu) { +if (this_cpu == that_cpu) +return true; +return per_cpu (sd_llc_id, this_cpu) ==per_cpu (sd_llc_id, that_cpu); }#endif /* CONFIG_SMP */
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 221/251 net: bnx2x: fix variable dereferenced before check
In reply to Greg Kroah-HartmanFrom: Pavel Skripkin <[email protected]>
[ Upstream commit f8885ac89ce310570e5391fe0bf0ec9c7c9b4fdc ]
Smatch says:
bnx2x_init_ops.h:640 bnx2x_ilt_client_mem_op() warn: variable dereferenced before check 'ilt' (see line 638)
Move ilt_cli variable initialization _after_ ilt validation, because it's unsafe to deref the pointer before validation check.
--- drivers/net/ethernet/broadcom/bnx2x/bnx2x_init_ops.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/net/ethernet/broadcom/bnx2x/bnx2x_init_ops.h +3 -1
@@ -635,11 +635,13 @@ static int bnx2x_ilt_client_mem_op(struct bnx2x *bp, int cli_num, {int i, rc;struct bnx2x_ilt *ilt =BP_ILT (bp); -struct ilt_client_info *ilt_cli = &ilt->clients[cli_num]; +struct ilt_client_info *ilt_cli;if (!ilt || !ilt->lines)return -1 ; + ilt_cli = &ilt->clients[cli_num]; +if (ilt_cli->flags & (ILT_CLIENT_SKIP_INIT |ILT_CLIENT_SKIP_MEM ))return 0 ;
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 222/251 iavf: Fix for the false positive ASQ/ARQ errors while issuing VF reset
In reply to Greg Kroah-HartmanFrom: Surabhi Boob <[email protected]>
[ Upstream commit 321421b57a12e933f92b228e0e6d0b2c6541f41d ]
While issuing VF Reset from the guest OS, the VF driver prints logs about critical / Overflow error detection. This is not an actual error since the VF_MBX_ARQLEN register is set to all FF's for a short period of time and the VF would catch the bits set if it was reading the register during that spike of time. This patch introduces an additional check to ignore this condition since the VF is in reset.
--- drivers/net/ethernet/intel/i40evf/i40evf_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/intel/i40evf/i40evf_main.c +1 -1
@@ -2027,7 +2027,7 @@ static void i40evf_adminq_task(struct work_struct *work)/* check for error indications */ val =rd32 (hw, hw->aq.arq.len); -if (val ==0xdeadbeef )/* indicates device in reset */ +if (val ==0xdeadbeef || val ==0xffffffff )/* device in reset */ goto freedom; oldval = val;if (val &I40E_VF_ARQLEN1_ARQVFE_MASK ) {
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 223/251 MIPS: generic/yamon-dt: fix uninitialized variable error
In reply to Greg Kroah-HartmanFrom: Colin Ian King <[email protected]>
[ Upstream commit 255e51da15baed47531beefd02f222e4dc01f1c1 ]
In the case where fw_getenv returns an error when fetching values for ememsizea and memsize then variable phys_memsize is not assigned a variable and will be uninitialized on a zero check of phys_memsize. Fix this by initializing phys_memsize to zero.
Cleans up cppcheck error:arch/mips/generic/yamon-dt.c:100:7: error: Uninitialized variable: phys_memsize [uninitvar]
--- arch/mips/generic/yamon-dt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/mips/generic/yamon-dt.c +1 -1
@@ -81,7 +81,7 @@ static unsigned int __init gen_fdt_mem_array(__init int yamon_dt_append_memory (void *fdt,const struct yamon_mem_region *regions) { -unsigned long phys_memsize, memsize; +unsigned long phys_memsize =0 , memsize;__be32 mem_array[2 *MAX_MEM_ARRAY_ENTRIES ];unsigned int mem_entries;int i, err, mem_off;
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 224/251 mips: bcm63xx: add support for clk_get_parent()
In reply to Greg Kroah-HartmanFrom: Randy Dunlap <[email protected]>
[ Upstream commit e8f67482e5a4bc8d0b65d606d08cb60ee123b468 ]
BCM63XX selects HAVE_LEGACY_CLK but does not provide/support clk_get_parent(), so add a simple implementation of that function so that callers of it will build without errors.
Fixes these build errors:
mips-linux-ld: drivers/iio/adc/ingenic-adc.o: in function `jz4770_adc_init_clk_div':
ingenic-adc.c:(.text+0xe4): undefined reference to `clk_get_parent'
mips-linux-ld: drivers/iio/adc/ingenic-adc.o: in function `jz4725b_adc_init_clk_div':
ingenic-adc.c:(.text+0x1b8): undefined reference to `clk_get_parent'
--- arch/mips/bcm63xx/clk.c | 6 ++++++ 1 file changed, 6 insertions(+)
arch/mips/bcm63xx/clk.c +6 -0
@@ -337,6 +337,12 @@ void clk_disable(struct clk *clk)EXPORT_SYMBOL (clk_disable); +struct clk *clk_get_parent (struct clk *clk) +{ +return NULL ; +} +EXPORT_SYMBOL (clk_get_parent); +unsigned long clk_get_rate (struct clk *clk) {if (!clk)
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 225/251 mips: lantiq: add support for clk_get_parent()
In reply to Greg Kroah-HartmanFrom: Randy Dunlap <[email protected]>
[ Upstream commit fc1aabb088860d6cf9dd03612b7a6f0de91ccac2 ]
Provide a simple implementation of clk_get_parent() in the lantiq subarch so that callers of it will build without errors.
Fixes this build error:
ERROR: modpost: "clk_get_parent" [drivers/iio/adc/ingenic-adc.ko] undefined!
--- arch/mips/lantiq/clk.c | 6 ++++++ 1 file changed, 6 insertions(+)
arch/mips/lantiq/clk.c +6 -0
@@ -160,6 +160,12 @@ void clk_deactivate(struct clk *clk) }EXPORT_SYMBOL (clk_deactivate); +struct clk *clk_get_parent (struct clk *clk) +{ +return NULL ; +} +EXPORT_SYMBOL (clk_get_parent); +static inline u32 get_counter_resolution (void ) {u32 res;
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 226/251 platform/x86: hp_accel: Fix an error handling path in lis3lv02d_probe()
In reply to Greg Kroah-HartmanFrom: Christophe JAILLET <[email protected]>
[ Upstream commit c961a7d2aa23ae19e0099fbcdf1040fb760eea83 ]
If 'led_classdev_register()' fails, some additional resources should be released.
Add the missing 'i8042_remove_filter()' and 'lis3lv02d_remove_fs()' calls that are already in the remove function but are missing here.
--- drivers/platform/x86/hp_accel.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/platform/x86/hp_accel.c +2 -0
@@ -383,9 +383,11 @@ static int lis3lv02d_add(struct acpi_device *device)INIT_WORK (&hpled_led.work, delayed_set_status_worker); ret =led_classdev_register (NULL , &hpled_led.led_classdev);if (ret) { +i8042_remove_filter (hp_accel_i8042_filter);lis3lv02d_joystick_disable (&lis3_dev);lis3lv02d_poweroff (&lis3_dev);flush_work (&hpled_led.work); +lis3lv02d_remove_fs (&lis3_dev);return ret; }
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 227/251 net: virtio_net_hdr_to_skb: count transport header in UFO
In reply to Greg Kroah-HartmanFrom: Jonathan Davies <[email protected]>
[ Upstream commit cf9acc90c80ecbee00334aa85d92f4e74014bcff ]
virtio_net_hdr_to_skb does not set the skb's gso_size and gso_type correctly for UFO packets received via virtio-net that are a little over the GSO size. This can lead to problems elsewhere in the networking stack, e.g. ovs_vport_send dropping over-sized packets if gso_size is not set.
This is due to the comparison
if (skb->len - p_off > gso_size)
not properly accounting for the transport layer header.
p_off includes the size of the transport layer header (thlen), so skb->len - p_off is the size of the TCP/UDP payload.
gso_size is read from the virtio-net header. For UFO, fragmentation happens at the IP level so does not need to include the UDP header.
Hence the calculation could be comparing a TCP/UDP payload length with an IP payload length, causing legitimate virtio-net packets to have lack gso_type/gso_size information.
Example: a UDP packet with payload size 1473 has IP payload size 1481. If the guest used UFO, it is not fragmented and the virtio-net header's flags indicate that it is a GSO frame (VIRTIO_NET_HDR_GSO_UDP), with gso_size = 1480 for an MTU of 1500. skb->len will be 1515 and p_off will be 42, so skb->len - p_off = 1473. Hence the comparison fails, and shinfo->gso_size and gso_type are not set as they should be.
Instead, add the UDP header length before comparing to gso_size when using UFO. In this way, it is the size of the IP payload that is compared to gso_size.
--- include/linux/virtio_net.h | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
include/linux/virtio_net.h +6 -1
@@ -118,10 +118,15 @@ retry:if (hdr->gso_type !=VIRTIO_NET_HDR_GSO_NONE ) {u16 gso_size =__virtio16_to_cpu (little_endian, hdr->gso_size); +unsigned int nh_off = p_off;struct skb_shared_info *shinfo =skb_shinfo (skb); +/* UFO may not include transport header in gso_size. */ +if (gso_type &SKB_GSO_UDP ) + nh_off -= thlen; +/* Too small packets are not really GSO ones. */ -if (skb->len - p_off > gso_size) { +if (skb->len - nh_off > gso_size) { shinfo->gso_size = gso_size; shinfo->gso_type = gso_type;
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 228/251 i40e: Fix NULL ptr dereference on VSI filter sync
In reply to Greg Kroah-HartmanFrom: Michal Maloszewski <[email protected]>
[ Upstream commit 37d9e304acd903a445df8208b8a13d707902dea6 ]
Remove the reason of null pointer dereference in sync VSI filters. Added new I40E_VSI_RELEASING flag to signalize deleting and releasing of VSI resources to sync this thread with sync filters subtask. Without this patch it is possible to start update the VSI filter list after VSI is removed, that's causing a kernel oops.
--- drivers/net/ethernet/intel/i40e/i40e.h | 1 + drivers/net/ethernet/intel/i40e/i40e_main.c | 5 +++-- 2 files changed, 4 insertions(+), 2 deletions(-)
drivers/net/ethernet/intel/i40e/i40e.h +1 -0
@@ -163,6 +163,7 @@ enum i40e_vsi_state_t { __I40E_VSI_OVERFLOW_PROMISC, __I40E_VSI_REINIT_REQUESTED, __I40E_VSI_DOWN_REQUESTED, + __I40E_VSI_RELEASING,/* This must be last as it determines the size of the BITMAP */ __I40E_VSI_STATE_SIZE__, };
drivers/net/ethernet/intel/i40e/i40e_main.c +3 -2
@@ -2415,7 +2415,8 @@ static void i40e_sync_filters_subtask(struct i40e_pf *pf)for (v =0 ; v < pf->num_alloc_vsi; v++) {if (pf->vsi[v] && - (pf->vsi[v]->flags &I40E_VSI_FLAG_FILTER_CHANGED )) { + (pf->vsi[v]->flags &I40E_VSI_FLAG_FILTER_CHANGED ) && + !test_bit (__I40E_VSI_RELEASING, pf->vsi[v]->state)) {int ret =i40e_sync_vsi_filters (pf->vsi[v]);if (ret) {
@@ -10098,7 +10099,7 @@ int i40e_vsi_release(struct i40e_vsi *vsi)dev_info (&pf->pdev->dev,"Can't remove PF VSI\n" );return -ENODEV ; } - +set_bit (__I40E_VSI_RELEASING, vsi->state); uplink_seid = vsi->uplink_seid;if (vsi->type !=I40E_VSI_SRIOV ) {if (vsi->netdev_registered) {
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 229/251 NFC: reorganize the functions in nci_request
In reply to Greg Kroah-HartmanFrom: Lin Ma <[email protected]>
[ Upstream commit 86cdf8e38792545161dbe3350a7eced558ba4d15 ]
There is a possible data race as shown below:
thread-A in nci_request() | thread-B in nci_close_device()
| mutex_lock(&ndev->req_lock);
test_bit(NCI_UP, &ndev->flags); |
... | test_and_clear_bit(NCI_UP, &ndev->flags)
mutex_lock(&ndev->req_lock); |
|This race will allow __nci_request() to be awaked while the device is getting removed.
Similar to commit e2cb6b891ad2 ("bluetooth: eliminate the potential race condition when removing the HCI controller"). this patch alters the function sequence in nci_request() to prevent the data races between the nci_close_device().
--- net/nfc/nci/core.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
net/nfc/nci/core.c +7 -4
@@ -156,12 +156,15 @@ inline int nci_request(struct nci_dev *ndev, {int rc; -if (!test_bit (NCI_UP , &ndev->flags)) -return -ENETDOWN ; -/* Serialize all requests */ mutex_lock (&ndev->req_lock); - rc =__nci_request (ndev, req, opt, timeout); +/* check the state after obtaing the lock against any races +* from nci_close_device when the device gets removed. +*/ +if (test_bit (NCI_UP , &ndev->flags)) + rc =__nci_request (ndev, req, opt, timeout); +else + rc = -ENETDOWN ;mutex_unlock (&ndev->req_lock);return rc;
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 230/251 NFC: reorder the logic in nfc_{un,}register_device
In reply to Greg Kroah-HartmanFrom: Lin Ma <[email protected]>
[ Upstream commit 3e3b5dfcd16a3e254aab61bd1e8c417dd4503102 ]
There is a potential UAF between the unregistration routine and the NFC netlink operations.
The race that cause that UAF can be shown as below:
(FREE) | (USE)
nfcmrvl_nci_unregister_dev | nfc_genl_dev_up
nci_close_device |
nci_unregister_device | nfc_get_device
nfc_unregister_device | nfc_dev_up
rfkill_destory |
device_del | rfkill_blocked
... | ...The root cause for this race is concluded below:
1. The rfkill_blocked (USE) in nfc_dev_up is supposed to be placed after the device_is_registered check.
2. Since the netlink operations are possible just after the device_add in nfc_register_device, the nfc_dev_up() can happen anywhere during the rfkill creation process, which leads to data race.
This patch reorder these actions to permit
1. Once device_del is finished, the nfc_dev_up cannot dereference the rfkill object.
2. The rfkill_register need to be placed after the device_add of nfc_dev because the parent device need to be created first. So this patch keeps the order but inject device_lock to prevent the data race.
--- net/nfc/core.c | 32 ++++++++++++++++++-------------- 1 file changed, 18 insertions(+), 14 deletions(-)
net/nfc/core.c +18 -14
@@ -106,13 +106,13 @@ int nfc_dev_up(struct nfc_dev *dev)device_lock (&dev->dev); -if (dev->rfkill &&rfkill_blocked (dev->rfkill)) { - rc = -ERFKILL ; +if (!device_is_registered (&dev->dev)) { + rc = -ENODEV ; goto error; } -if (!device_is_registered (&dev->dev)) { - rc = -ENODEV ; +if (dev->rfkill &&rfkill_blocked (dev->rfkill)) { + rc = -ERFKILL ; goto error; }
@@ -1133,11 +1133,7 @@ int nfc_register_device(struct nfc_dev *dev)if (rc)pr_err ("Could not register llcp device\n" ); - rc =nfc_genl_device_added (dev); -if (rc) -pr_debug ("The userspace won't be notified that the device %s was added\n" , -dev_name (&dev->dev)); - +device_lock (&dev->dev); dev->rfkill =rfkill_alloc (dev_name (&dev->dev), &dev->dev,RFKILL_TYPE_NFC , &nfc_rfkill_ops, dev);if (dev->rfkill) {
@@ -1146,6 +1142,12 @@ int nfc_register_device(struct nfc_dev *dev) dev->rfkill =NULL ; } } +device_unlock (&dev->dev); + + rc =nfc_genl_device_added (dev); +if (rc) +pr_debug ("The userspace won't be notified that the device %s was added\n" , +dev_name (&dev->dev));return 0 ; }
@@ -1162,10 +1164,17 @@ void nfc_unregister_device(struct nfc_dev *dev)pr_debug ("dev_name=%s\n" ,dev_name (&dev->dev)); + rc =nfc_genl_device_removed (dev); +if (rc) +pr_debug ("The userspace won't be notified that the device %s " +"was removed\n" ,dev_name (&dev->dev)); + +device_lock (&dev->dev);if (dev->rfkill) {rfkill_unregister (dev->rfkill);rfkill_destroy (dev->rfkill); } +device_unlock (&dev->dev);if (dev->ops->check_presence) {device_lock (&dev->dev);
@@ -1175,11 +1184,6 @@ void nfc_unregister_device(struct nfc_dev *dev)cancel_work_sync (&dev->check_pres_work); } - rc =nfc_genl_device_removed (dev); -if (rc) -pr_debug ("The userspace won't be notified that the device %s " -"was removed\n" ,dev_name (&dev->dev)); -nfc_llcp_unregister_device (dev);mutex_lock (&nfc_devlist_mutex);
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 231/251 perf bench: Fix two memory leaks detected with ASan
In reply to Greg Kroah-HartmanFrom: Sohaib Mohamed <[email protected]>
[ Upstream commit 92723ea0f11d92496687db8c9725248e9d1e5e1d ]
ASan reports memory leaks while running:
$ perf bench sched all
--- tools/perf/bench/sched-messaging.c | 4 ++++ 1 file changed, 4 insertions(+)
tools/perf/bench/sched-messaging.c +4 -0
@@ -226,6 +226,8 @@ static unsigned int group(pthread_t *pth, snd_ctx->out_fds[i] = fds[1 ];if (!thread_mode)close (fds[0 ]); + +free (ctx); }/* Now we have all the fds, fork the senders */
@@ -242,6 +244,8 @@ static unsigned int group(pthread_t *pth,for (i =0 ; i < num_fds; i++)close (snd_ctx->out_fds[i]); +free (snd_ctx); +/* Return number of children to reap */ return num_fds *2 ; }
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 232/251 perf/x86/intel/uncore: Fix filter_tid mask for CHA events on Skylake Server
In reply to Greg Kroah-HartmanFrom: Alexander Antonov <[email protected]>
[ Upstream commit e324234e0aa881b7841c7c713306403e12b069ff ]
According Uncore Reference Manual: any of the CHA events may be filtered by Thread/Core-ID by using tid modifier in CHA Filter 0 Register. Update skx_cha_hw_config() to follow Uncore Guide.
--- arch/x86/events/intel/uncore_snbep.c | 3 +++ 1 file changed, 3 insertions(+)
arch/x86/events/intel/uncore_snbep.c +3 -0
@@ -3383,6 +3383,9 @@ static int skx_cha_hw_config(struct intel_uncore_box *box, struct perf_event *evstruct hw_perf_event_extra *reg1 = &event->hw.extra_reg;struct extra_reg *er;int idx =0 ; +/* Any of the CHA events may be filtered by Thread/Core-ID.*/ +if (event->hw.config &SNBEP_CBO_PMON_CTL_TID_EN ) + idx =SKX_CHA_MSR_PMON_BOX_FILTER_TID ;for (er = skx_uncore_cha_extra_regs; er->msr; er++) {if (er->event != (event->hw.config & er->config_mask))
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 233/251 perf/x86/intel/uncore: Fix IIO event constraints for Skylake Server
In reply to Greg Kroah-HartmanFrom: Alexander Antonov <[email protected]>
[ Upstream commit 3866ae319c846a612109c008f43cba80b8c15e86 ]
According to the latest uncore document, COMP_BUF_OCCUPANCY (0xd5) event can be collected on 2-3 counters. Update uncore IIO event constraints for Skylake Server.
--- arch/x86/events/intel/uncore_snbep.c | 1 + 1 file changed, 1 insertion(+)
arch/x86/events/intel/uncore_snbep.c +1 -0
@@ -3453,6 +3453,7 @@ static struct event_constraint skx_uncore_iio_constraints[] = {UNCORE_EVENT_CONSTRAINT (0xc0 ,0xc ),UNCORE_EVENT_CONSTRAINT (0xc5 ,0xc ),UNCORE_EVENT_CONSTRAINT (0xd4 ,0xc ), +UNCORE_EVENT_CONSTRAINT (0xd5 ,0xc ), EVENT_CONSTRAINT_END };
Signature · 1 line
2.33.0
Greg Kroah-Hartman
maintainerPATCH 234/251 tun: fix bonding active backup with arp monitoring
In reply to Greg Kroah-HartmanFrom: Nicolas Dichtel <[email protected]>
commit a31d27fbed5d518734cb60956303eb15089a7634 upstream.
As stated in the bonding doc, trans_start must be set manually for drivers using NETIF_F_LLTX:
Drivers that use NETIF_F_LLTX flag must also update netdev_queue->trans_start. If they do not, then the ARP monitor will immediately fail any slaves using that driver, and those slaves will stay down.
--- drivers/net/tun.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/net/tun.c +5 -0
@@ -858,6 +858,7 @@ static netdev_tx_t tun_net_xmit(struct s {struct tun_struct *tun =netdev_priv (dev);int txq = skb->queue_mapping; +struct netdev_queue *queue;struct tun_file *tfile;u32 numqueues =0 ;
@@ -916,6 +917,10 @@ static netdev_tx_t tun_net_xmit(struct sif (skb_array_produce (&tfile->tx_array, skb)) goto drop; +/* NETIF_F_LLTX requires to do our own update of trans_start */ + queue =netdev_get_tx_queue (dev, txq); + queue->trans_start = jiffies; +/* Notify and wake up reader process */ if (tfile->flags &TUN_FASYNC )kill_fasync (&tfile->fasync,SIGIO ,POLL_IN );
Greg Kroah-Hartman
maintainerPATCH 235/251 hexagon: export raw I/O routines for modules
In reply to Greg Kroah-HartmanFrom: Nathan Chancellor <[email protected]>
commit ffb92ce826fd801acb0f4e15b75e4ddf0d189bde upstream.
Patch series "Fixes for ARCH=hexagon allmodconfig", v2.
This series fixes some issues noticed with ARCH=hexagon allmodconfig.
This patch (of 3):
When building ARCH=hexagon allmodconfig, the following errors occur:
ERROR: modpost: "__raw_readsl" [drivers/i3c/master/svc-i3c-master.ko] undefined!
ERROR: modpost: "__raw_writesl" [drivers/i3c/master/dw-i3c-master.ko] undefined!
ERROR: modpost: "__raw_readsl" [drivers/i3c/master/dw-i3c-master.ko] undefined!
ERROR: modpost: "__raw_writesl" [drivers/i3c/master/i3c-master-cdns.ko] undefined!
ERROR: modpost: "__raw_readsl" [drivers/i3c/master/i3c-master-cdns.ko] undefined!
Export these symbols so that modules can use them without any errors.
--- arch/hexagon/lib/io.c | 4 ++++ 1 file changed, 4 insertions(+)
arch/hexagon/lib/io.c +4 -0
@@ -40,6 +40,7 @@ void __raw_readsw(const void __iomem *ad *dst++ = *src; } +EXPORT_SYMBOL (__raw_readsw);/* * __raw_writesw - read words a short at a time
@@ -60,6 +61,7 @@ void __raw_writesw(void __iomem *addr, c } +EXPORT_SYMBOL (__raw_writesw);/* Pretty sure len is pre-adjusted for the length of the access already */ void __raw_readsl (const void __iomem *addr,void *data,int len)
@@ -75,6 +77,7 @@ void __raw_readsl(const void __iomem *ad } +EXPORT_SYMBOL (__raw_readsl);void __raw_writesl (void __iomem *addr,const void *data,int len) {
@@ -89,3 +92,4 @@ void __raw_writesl(void __iomem *addr, c } +EXPORT_SYMBOL (__raw_writesl);
Greg Kroah-Hartman
maintainerPATCH 236/251 mm: kmemleak: slob: respect SLAB_NOLEAKTRACE flag
In reply to Greg Kroah-HartmanFrom: Rustam Kovhaev <[email protected]>
commit 34dbc3aaf5d9e89ba6cc5e24add9458c21ab1950 upstream.
When kmemleak is enabled for SLOB, system does not boot and does not print anything to the console. At the very early stage in the boot process we hit infinite recursion from kmemleak_init() and eventually kernel crashes.
kmemleak_init() specifies SLAB_NOLEAKTRACE for KMEM_CACHE(), but kmem_cache_create_usercopy() removes it because CACHE_CREATE_MASK is not valid for SLOB.
Let's fix CACHE_CREATE_MASK and make kmemleak work with SLOB
--- mm/slab.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
mm/slab.h +1 -1
@@ -146,7 +146,7 @@ static inline unsigned long kmem_cache_f#define SLAB_CACHE_FLAGS (SLAB_NOLEAKTRACE | SLAB_RECLAIM_ACCOUNT | \ SLAB_TEMPORARY | SLAB_ACCOUNT)#else -#define SLAB_CACHE_FLAGS (0) +#define SLAB_CACHE_FLAGS (SLAB_NOLEAKTRACE)#endif /* Common flags available with current configuration */
Greg Kroah-Hartman
maintainerPATCH 237/251 btrfs: fix memory ordering between normal and ordered work functions
In reply to Greg Kroah-HartmanFrom: Nikolay Borisov <[email protected]>
commit 45da9c1767ac31857df572f0a909fbe88fd5a7e9 upstream.
Ordered work functions aren't guaranteed to be handled by the same thread which executed the normal work functions. The only way execution between normal/ordered functions is synchronized is via the WORK_DONE_BIT, unfortunately the used bitops don't guarantee any ordering whatsoever.
This manifested as seemingly inexplicable crashes on ARM64, where async_chunk::inode is seen as non-null in async_cow_submit which causes submit_compressed_extents to be called and crash occurs because async_chunk::inode suddenly became NULL. The call trace was similar to:
pc : submit_compressed_extents+0x38/0x3d0
lr : async_cow_submit+0x50/0xd0
sp : ffff800015d4bc20 <registers omitted for brevity>
Call trace:
submit_compressed_extents+0x38/0x3d0
async_cow_submit+0x50/0xd0
run_ordered_work+0xc8/0x280
btrfs_work_helper+0x98/0x250
process_one_work+0x1f0/0x4ac
worker_thread+0x188/0x504
kthread+0x110/0x114
ret_from_fork+0x10/0x18Fix this by adding respective barrier calls which ensure that all accesses preceding setting of WORK_DONE_BIT are strictly ordered before setting the flag. At the same time add a read barrier after reading of WORK_DONE_BIT in run_ordered_work which ensures all subsequent loads would be strictly ordered after reading the bit. This in turn ensures are all accesses before WORK_DONE_BIT are going to be strictly ordered before any access that can occur in ordered_func.
--- fs/btrfs/async-thread.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
fs/btrfs/async-thread.c +14 -0
@@ -283,6 +283,13 @@ static void run_ordered_work(struct __bt ordered_list);if (!test_bit (WORK_DONE_BIT , &work->flags))break ; +/* +* Orders all subsequent loads after reading WORK_DONE_BIT, +* paired with the smp_mb__before_atomic in btrfs_work_helper +* this guarantees that the ordered function will see all +* updates from ordinary work function. +*/ +smp_rmb ();/* * we are going to call the ordered done function, but
@@ -368,6 +375,13 @@ static void normal_work_helper(struct btthresh_exec_hook (wq); work->func (work);if (need_order) { +/* +* Ensures all memory accesses done in the work function are +* ordered before setting the WORK_DONE_BIT. Ensuring the thread +* which is going to executed the ordered work sees them. +* Pairs with the smp_rmb in run_ordered_work. +*/ +smp_mb__before_atomic ();set_bit (WORK_DONE_BIT , &work->flags);run_ordered_work (wq, work); }
Greg Kroah-Hartman
maintainerPATCH 238/251 parisc/sticon: fix reverse colors
In reply to Greg Kroah-HartmanFrom: Sven Schnelle <[email protected]>
commit bec05f33ebc1006899c6d3e59a00c58881fe7626 upstream.
sticon_build_attr() checked the reverse argument and flipped background and foreground color, but returned the non-reverse value afterwards. Fix this and also add two local variables for foreground and background color to make the code easier to read.
--- drivers/video/console/sticon.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/video/console/sticon.c +6 -6
@@ -291,13 +291,13 @@ static unsigned long sticon_getxy(structstatic u8 sticon_build_attr (struct vc_data *conp,u8 color,u8 intens,u8 blink,u8 underline,u8 reverse,u8 italic) { -u8 attr = ((color &0x70 ) >>1 ) | ((color &7 )); +u8 fg = color &7 ; +u8 bg = (color &0x70 ) >>4 ; -if (reverse) { - color = ((color >>3 ) &0x7 ) | ((color &0x7 ) <<3 ); - } - -return attr; +if (reverse) +return (fg <<3 ) | bg; +else +return (bg <<3 ) | fg; }static void sticon_invert_region (struct vc_data *conp,u16 *p,int count)
Greg Kroah-Hartman
maintainerPATCH 239/251 cfg80211: call cfg80211_stop_ap when switch from P2P_GO type
In reply to Greg Kroah-HartmanFrom: Nguyen Dinh Phi <[email protected]>
commit 563fbefed46ae4c1f70cffb8eb54c02df480b2c2 upstream.
If the userspace tools switch from NL80211_IFTYPE_P2P_GO to NL80211_IFTYPE_ADHOC via send_msg(NL80211_CMD_SET_INTERFACE), it does not call the cleanup cfg80211_stop_ap(), this leads to the initialization of in-use data. For example, this path re-init the sdata->assigned_chanctx_list while it is still an element of assigned_vifs list, and makes that linked list corrupt.
--- net/wireless/util.c | 1 + 1 file changed, 1 insertion(+)
net/wireless/util.c +1 -0
@@ -1026,6 +1026,7 @@ int cfg80211_change_iface(struct cfg8021switch (otype) {case NL80211_IFTYPE_AP : +case NL80211_IFTYPE_P2P_GO :cfg80211_stop_ap (rdev, dev, true);break ;case NL80211_IFTYPE_ADHOC :
Greg Kroah-Hartman
maintainerPATCH 240/251 drm/udl: fix control-message timeout
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit 5591c8f79db1729d9c5ac7f5b4d3a5c26e262d93 upstream.
USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ.
--- drivers/gpu/drm/udl/udl_connector.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/udl/udl_connector.c +1 -1
@@ -37,7 +37,7 @@ static u8 *udl_get_edid(struct udl_devic ret =usb_control_msg (udl->udev,usb_rcvctrlpipe (udl->udev,0 ), (0x02 ), (0x80 | (0x02 <<5 )), i <<8 ,0xA1 , rbuf,2 , -HZ ); +1000 );if (ret <1 ) {DRM_ERROR ("Read EDID byte %d failed err %x\n" , i, ret); goto error;
Greg Kroah-Hartman
maintainerPATCH 241/251 drm/amdgpu: fix set scaling mode Full/Full aspect/Center not works on vga and dvi connectors
In reply to Greg Kroah-HartmanFrom: hongao <[email protected]>
commit bf552083916a7f8800477b5986940d1c9a31b953 upstream.
amdgpu_connector_vga_get_modes missed function amdgpu_get_native_mode which assign amdgpu_encoder->native_mode with *preferred_mode result in amdgpu_encoder->native_mode.clock always be 0. That will cause amdgpu_connector_set_property returned early on:
if ((rmx_type != DRM_MODE_SCALE_NONE) &&
(amdgpu_encoder->native_mode.clock == 0))
when we try to set scaling mode Full/Full aspect/Center.
Add the missing function to amdgpu_connector_vga_get_mode can fix this. It also works on dvi connectors because amdgpu_connector_dvi_helper_funcs.get_mode use the same method.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c +1 -0
@@ -844,6 +844,7 @@ static int amdgpu_connector_vga_get_modeamdgpu_connector_get_edid (connector); ret =amdgpu_connector_ddc_get_modes (connector); +amdgpu_get_native_mode (connector);return ret; }
Greg Kroah-Hartman
maintainerPATCH 242/251 perf/core: Avoid put_page() when GUP fails
In reply to Greg Kroah-HartmanFrom: Greg Thelen <[email protected]>
commit 4716023a8f6a0f4a28047f14dd7ebdc319606b84 upstream.
PEBS PERF_SAMPLE_PHYS_ADDR events use perf_virt_to_phys() to convert PMU sampled virtual addresses to physical using get_user_page_fast_only() and page_to_phys().
Some get_user_page_fast_only() error cases return false, indicating no page reference, but still initialize the output page pointer with an unreferenced page. In these error cases perf_virt_to_phys() calls put_page(). This causes page reference count underflow, which can lead to unintentional page sharing.
Fix perf_virt_to_phys() to only put_page() if get_user_page_fast_only() returns a referenced page.
--- kernel/events/core.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
kernel/events/core.c +5 -5
@@ -6110,7 +6110,6 @@ void perf_output_sample(struct perf_outpstatic u64 perf_virt_to_phys (u64 virt) {u64 phys_addr =0 ; -struct page *p =NULL ;if (!virt)return 0 ;
@@ -6129,14 +6128,15 @@ static u64 perf_virt_to_phys(u64 virt)* If failed, leave phys_addr as 0. */ if (current->mm !=NULL ) { +struct page *p; +pagefault_disable (); -if (__get_user_pages_fast (virt,1 ,0 , &p) ==1 ) +if (__get_user_pages_fast (virt,1 ,0 , &p) ==1 ) { phys_addr =page_to_phys (p) + virt %PAGE_SIZE ; +put_page (p); + }pagefault_enable (); } - -if (p) -put_page (p); }return phys_addr;
Greg Kroah-Hartman
maintainerPATCH 243/251 batman-adv: mcast: fix duplicate mcast packets in BLA backbone from LAN
In reply to Greg Kroah-HartmanFrom: Linus L�ssing <[email protected]>
commit 3236d215ad38a3f5372e65cd1e0a52cf93d3c6a2 upstream.
Scenario:
* Multicast frame send from a BLA backbone (multiple nodes with their bat0 bridged together, with BLA enabled)
Issue:
* BLA backbone nodes receive the frame multiple times on bat0
For multicast frames received via batman-adv broadcast packets the originator of the broadcast packet is checked before decapsulating and forwarding the frame to bat0 (batadv_bla_is_backbone_gw()-> batadv_recv_bcast_packet()). If it came from a node which shares the same BLA backbone with us then it is not forwarded to bat0 to avoid a loop.
When sending a multicast frame in a non-4-address batman-adv unicast packet we are currently missing this check - and cannot do so because the batman-adv unicast packet has no originator address field.
However, we can simply fix this on the sender side by only sending the multicast frame via unicasts to interested nodes which do not share the same BLA backbone with us. This also nicely avoids some unnecessary transmissions on mesh side.
Note that no infinite loop was observed, probably because of dropping via batadv_interface_tx()->batadv_bla_tx(). However the duplicates still utterly confuse switches/bridges, ICMPv6 duplicate address detection and neighbor discovery and therefore leads to long delays before being able to establish TCP connections, for instance. And it also leads to the Linux bridge printing messages like:
"br-lan: received packet on eth1 with own address as source address ..."
[ bp: 4.14 backport: drop usage in non-existing batadv_mcast_forw_*,
correct fixes line ]
--- net/batman-adv/multicast.c | 31 +++++++++++++++++++++++++++++++ net/batman-adv/multicast.h | 15 +++++++++++++++ net/batman-adv/soft-interface.c | 5 ++--- 3 files changed, 48 insertions(+), 3 deletions(-)
net/batman-adv/multicast.c +31 -0
@@ -55,10 +55,12 @@#include <net/ip.h> #include <net/ipv6.h> +#include "bridge_loop_avoidance.h" #include "hard-interface.h" #include "hash.h" #include "log.h" #include "packet.h" +#include "send.h" #include "translation-table.h" #include "tvlv.h"
@@ -1291,6 +1293,35 @@ void batadv_mcast_free(struct batadv_pri }/** +* batadv_mcast_forw_send_orig() - send a multicast packet to an originator +* @bat_priv: the bat priv with all the soft interface information +* @skb: the multicast packet to send +* @vid: the vlan identifier +* @orig_node: the originator to send the packet to +* +* Return: NET_XMIT_DROP in case of error or NET_XMIT_SUCCESS otherwise. +*/ +int batadv_mcast_forw_send_orig (struct batadv_priv *bat_priv, +struct sk_buff *skb, +unsigned short vid, +struct batadv_orig_node *orig_node) +{ +/* Avoid sending multicast-in-unicast packets to other BLA +* gateways - they already got the frame from the LAN side +* we share with them. +* TODO: Refactor to take BLA into account earlier, to avoid +* reducing the mcast_fanout count. +*/ +if (batadv_bla_is_backbone_gw_orig (bat_priv, orig_node->orig, vid)) { +dev_kfree_skb (skb); +return NET_XMIT_SUCCESS ; + } + +return batadv_send_skb_unicast (bat_priv, skb,BATADV_UNICAST ,0 , + orig_node, vid); +} + +/** * batadv_mcast_purge_orig - reset originator global mcast state modifications * @orig: the originator which is going to get purged */
net/batman-adv/multicast.h +15 -0
@@ -43,6 +43,11 @@ enum batadv_forw_mode batadv_mcast_forw_mode(struct batadv_priv *bat_priv, struct sk_buff *skb, struct batadv_orig_node **mcast_single_orig); +int batadv_mcast_forw_send_orig (struct batadv_priv *bat_priv, +struct sk_buff *skb, +unsigned short vid, +struct batadv_orig_node *orig_node); +void batadv_mcast_init (struct batadv_priv *bat_priv);int batadv_mcast_flags_seq_print_text (struct seq_file *seq,void *offset);
@@ -65,6 +70,16 @@ static inline int batadv_mcast_init(strureturn 0 ; } +static inline int +batadv_mcast_forw_send_orig (struct batadv_priv *bat_priv, +struct sk_buff *skb, +unsigned short vid, +struct batadv_orig_node *orig_node) +{ +kfree_skb (skb); +return NET_XMIT_DROP ; +} +static inline void batadv_mcast_free (struct batadv_priv *bat_priv) { }
net/batman-adv/soft-interface.c +2 -3
@@ -359,9 +359,8 @@ send: goto dropped; ret =batadv_send_skb_via_gw (bat_priv, skb, vid); }else if (mcast_single_orig) { - ret =batadv_send_skb_unicast (bat_priv, skb, -BATADV_UNICAST ,0 , - mcast_single_orig, vid); + ret =batadv_mcast_forw_send_orig (bat_priv, skb, vid, + mcast_single_orig); }else {if (batadv_dat_snoop_outgoing_arp_request (bat_priv, skb))
Greg Kroah-Hartman
maintainerPATCH 244/251 batman-adv: mcast: fix duplicate mcast packets from BLA backbone to mesh
In reply to Greg Kroah-HartmanFrom: Linus L�ssing <[email protected]>
commit 2369e827046920ef0599e6a36b975ac5c0a359c2 upstream.
Scenario:
* Multicast frame send from BLA backbone gateways (multiple nodes with their bat0 bridged together, with BLA enabled) sharing the same LAN to nodes in the mesh
Issue:
* Nodes receive the frame multiple times on bat0 from the mesh, once from each foreign BLA backbone gateway which shares the same LAN with another
For multicast frames via batman-adv broadcast packets coming from the same BLA backbone but from different backbone gateways duplicates are currently detected via a CRC history of previously received packets.
However this CRC so far was not performed for multicast frames received via batman-adv unicast packets. Fixing this by appyling the same check for such packets, too.
Room for improvements in the future: Ideally we would introduce the possibility to not only claim a client, but a complete originator, too. This would allow us to only send a multicast-in-unicast packet from a BLA backbone gateway claiming the node and by that avoid potential redundant transmissions in the first place.
--- net/batman-adv/bridge_loop_avoidance.c | 105 +++++++++++++++++++++++++++------ 1 file changed, 88 insertions(+), 17 deletions(-)
net/batman-adv/bridge_loop_avoidance.c +88 -17
@@ -1598,13 +1598,16 @@ int batadv_bla_init(struct batadv_priv * }/** -* batadv_bla_check_bcast_duplist - Check if a frame is in the broadcast dup. +* batadv_bla_check_duplist() - Check if a frame is in the broadcast dup. * @bat_priv: the bat priv with all the soft interface information -* @skb: contains the bcast_packet to be checked -* -* check if it is on our broadcast list. Another gateway might -* have sent the same packet because it is connected to the same backbone, -* so we have to remove this duplicate. +* @skb: contains the multicast packet to be checked +* @payload_ptr: pointer to position inside the head buffer of the skb +* marking the start of the data to be CRC'ed +* @orig: originator mac address, NULL if unknown +* +* Check if it is on our broadcast list. Another gateway might have sent the +* same packet because it is connected to the same backbone, so we have to +* remove this duplicate. * * This is performed by checking the CRC, which will tell us * with a good chance that it is the same packet. If it is furthermore
@@ -1613,19 +1616,17 @@ int batadv_bla_init(struct batadv_priv ** * Return: true if a packet is in the duplicate list, false otherwise. */ -bool batadv_bla_check_bcast_duplist (struct batadv_priv *bat_priv, -struct sk_buff *skb) +static bool batadv_bla_check_duplist (struct batadv_priv *bat_priv, +struct sk_buff *skb,u8 *payload_ptr, +const u8 *orig) { -int i, curr; -__be32 crc; -struct batadv_bcast_packet *bcast_packet;struct batadv_bcast_duplist_entry *entry;bool ret = false; - - bcast_packet = (struct batadv_bcast_packet *)skb->data; +int i, curr; +__be32 crc;/* calculate the crc ... */ - crc =batadv_skb_crc32 (skb, (u8 *)(bcast_packet +1 )); + crc =batadv_skb_crc32 (skb, payload_ptr);spin_lock_bh (&bat_priv->bla.bcast_duplist_lock);
@@ -1644,8 +1645,21 @@ bool batadv_bla_check_bcast_duplist(struif (entry->crc != crc)continue ; -if (batadv_compare_eth (entry->orig, bcast_packet->orig)) -continue ; +/* are the originators both known and not anonymous? */ +if (orig && !is_zero_ether_addr (orig) && + !is_zero_ether_addr (entry->orig)) { +/* If known, check if the new frame came from +* the same originator: +* We are safe to take identical frames from the +* same orig, if known, as multiplications in +* the mesh are detected via the (orig, seqno) pair. +* So we can be a bit more liberal here and allow +* identical frames from the same orig which the source +* host might have sent multiple times on purpose. +*/ +if (batadv_compare_eth (entry->orig, orig)) +continue ; + }/* this entry seems to match: same crc, not too old, * and from another gw. therefore return true to forbid it.
@@ -1661,7 +1675,14 @@ bool batadv_bla_check_bcast_duplist(stru entry = &bat_priv->bla.bcast_duplist[curr]; entry->crc = crc; entry->entrytime = jiffies; -ether_addr_copy (entry->orig, bcast_packet->orig); + +/* known originator */ +if (orig) +ether_addr_copy (entry->orig, orig); +/* anonymous originator */ +else +eth_zero_addr (entry->orig); + bat_priv->bla.bcast_duplist_curr = curr; out:
@@ -1671,6 +1692,48 @@ out: }/** +* batadv_bla_check_ucast_duplist() - Check if a frame is in the broadcast dup. +* @bat_priv: the bat priv with all the soft interface information +* @skb: contains the multicast packet to be checked, decapsulated from a +* unicast_packet +* +* Check if it is on our broadcast list. Another gateway might have sent the +* same packet because it is connected to the same backbone, so we have to +* remove this duplicate. +* +* Return: true if a packet is in the duplicate list, false otherwise. +*/ +static bool batadv_bla_check_ucast_duplist (struct batadv_priv *bat_priv, +struct sk_buff *skb) +{ +return batadv_bla_check_duplist (bat_priv, skb, (u8 *)skb->data,NULL ); +} + +/** +* batadv_bla_check_bcast_duplist() - Check if a frame is in the broadcast dup. +* @bat_priv: the bat priv with all the soft interface information +* @skb: contains the bcast_packet to be checked +* +* Check if it is on our broadcast list. Another gateway might have sent the +* same packet because it is connected to the same backbone, so we have to +* remove this duplicate. +* +* Return: true if a packet is in the duplicate list, false otherwise. +*/ +bool batadv_bla_check_bcast_duplist (struct batadv_priv *bat_priv, +struct sk_buff *skb) +{ +struct batadv_bcast_packet *bcast_packet; +u8 *payload_ptr; + + bcast_packet = (struct batadv_bcast_packet *)skb->data; + payload_ptr = (u8 *)(bcast_packet +1 ); + +return batadv_bla_check_duplist (bat_priv, skb, payload_ptr, + bcast_packet->orig); +} + +/** * batadv_bla_is_backbone_gw_orig - Check if the originator is a gateway for * the VLAN identified by vid. * @bat_priv: the bat priv with all the soft interface information
@@ -1884,6 +1947,14 @@ bool batadv_bla_rx(struct batadv_priv *b packet_type == BATADV_UNICAST) goto handled; +/* potential duplicates from foreign BLA backbone gateways via +* multicast-in-unicast packets +*/ +if (is_multicast_ether_addr (ethhdr->h_dest) && + packet_type ==BATADV_UNICAST && +batadv_bla_check_ucast_duplist (bat_priv, skb)) + goto handled; +ether_addr_copy (search_claim.addr, ethhdr->h_source); search_claim.vid = vid; claim =batadv_claim_hash_find (bat_priv, &search_claim);
Greg Kroah-Hartman
maintainerPATCH 245/251 batman-adv: Consider fragmentation for needed_headroom
In reply to Greg Kroah-HartmanFrom: Sven Eckelmann <[email protected]>
commit 4ca23e2c2074465bff55ea14221175fecdf63c5f upstream.
If a batman-adv packets has to be fragmented, then the original batman-adv packet header is not stripped away. Instead, only a new header is added in front of the packet after it was split.
This size must be considered to avoid cost intensive reallocations during the transmission through the various device layers.
--- net/batman-adv/hard-interface.c | 3 +++ 1 file changed, 3 insertions(+)
net/batman-adv/hard-interface.c +3 -0
@@ -558,6 +558,9 @@ static void batadv_hardif_recalc_extra_s needed_headroom = lower_headroom + (lower_header_len -ETH_HLEN ); needed_headroom +=batadv_max_header_len (); +/* fragmentation headers don't strip the unicast/... header */ + needed_headroom +=sizeof (struct batadv_frag_packet ); + soft_iface->needed_headroom = needed_headroom; soft_iface->needed_tailroom = lower_tailroom; }
Greg Kroah-Hartman
maintainerPATCH 246/251 batman-adv: Reserve needed_*room for fragments
In reply to Greg Kroah-HartmanFrom: Sven Eckelmann <[email protected]>
commit c5cbfc87558168ef4c3c27ce36eba6b83391db19 upstream.
The batadv net_device is trying to propagate the needed_headroom and needed_tailroom from the lower devices. This is needed to avoid cost intensive reallocations using pskb_expand_head during the transmission.
But the fragmentation code split the skb's without adding extra room at the end/beginning of the various fragments. This reduced the performance of transmissions over complex scenarios (batadv on vxlan on wireguard) because the lower devices had to perform the reallocations at least once.
--- net/batman-adv/fragmentation.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-)
net/batman-adv/fragmentation.c +10 -5
@@ -402,6 +402,7 @@ out:/** * batadv_frag_create - create a fragment from skb +* @net_dev: outgoing device for fragment * @skb: skb to create fragment from * @frag_head: header to use in new fragment * @fragment_size: size of new fragment
@@ -412,22 +413,25 @@ out:* * Return: the new fragment, NULL on error. */ -static struct sk_buff *batadv_frag_create (struct sk_buff *skb, +static struct sk_buff *batadv_frag_create (struct net_device *net_dev, +struct sk_buff *skb,struct batadv_frag_packet *frag_head,unsigned int fragment_size) { +unsigned int ll_reserved =LL_RESERVED_SPACE (net_dev); +unsigned int tailroom = net_dev->needed_tailroom;struct sk_buff *skb_fragment;unsigned int header_size =sizeof (*frag_head);unsigned int mtu = fragment_size + header_size; - skb_fragment =netdev_alloc_skb (NULL , mtu +ETH_HLEN ); + skb_fragment =dev_alloc_skb (ll_reserved + mtu + tailroom);if (!skb_fragment) goto err; skb_fragment->priority = skb->priority;/* Eat the last mtu-bytes of the skb */ -skb_reserve (skb_fragment, header_size +ETH_HLEN ); +skb_reserve (skb_fragment, ll_reserved + header_size);skb_split (skb, skb_fragment, skb->len - fragment_size);/* Add the header */
@@ -450,11 +454,12 @@ int batadv_frag_send_packet(struct sk_bustruct batadv_orig_node *orig_node, struct batadv_neigh_node *neigh_node) { + struct net_device *net_dev = neigh_node->if_incoming->net_dev;struct batadv_priv *bat_priv;struct batadv_hard_iface *primary_if =NULL ;struct batadv_frag_packet frag_header;struct sk_buff *skb_fragment; -unsigned int mtu = neigh_node->if_incoming->net_dev->mtu; +unsigned int mtu = net_dev->mtu;unsigned int header_size =sizeof (frag_header);unsigned int max_fragment_size, num_fragments;int ret;
@@ -514,7 +519,7 @@ int batadv_frag_send_packet(struct sk_bu goto put_primary_if; } - skb_fragment =batadv_frag_create (skb, &frag_header, + skb_fragment =batadv_frag_create (net_dev, skb, &frag_header, max_fragment_size);if (!skb_fragment) { ret = -ENOMEM ;
Greg Kroah-Hartman
maintainerPATCH 247/251 batman-adv: Dont always reallocate the fragmentation skb head
In reply to Greg Kroah-HartmanFrom: Sven Eckelmann <[email protected]>
commit 992b03b88e36254e26e9a4977ab948683e21bd9f upstream.
When a packet is fragmented by batman-adv, the original batman-adv header is not modified. Only a new fragmentation is inserted between the original one and the ethernet header. The code must therefore make sure that it has a writable region of this size in the skbuff head.
But it is not useful to always reallocate the skbuff by this size even when there would be more than enough headroom still in the skb. The reallocation is just to costly during in this codepath.
--- net/batman-adv/fragmentation.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
net/batman-adv/fragmentation.c +6 -5
@@ -538,13 +538,14 @@ int batadv_frag_send_packet(struct sk_bu frag_header.no++; } -/* Make room for the fragment header. */ -if (batadv_skb_head_push (skb, header_size) <0 || -pskb_expand_head (skb, header_size +ETH_HLEN ,0 ,GFP_ATOMIC ) <0 ) { - ret = -ENOMEM ; +/* make sure that there is at least enough head for the fragmentation +* and ethernet headers +*/ + ret =skb_cow_head (skb,ETH_HLEN + header_size); +if (ret <0 ) goto put_primary_if; - } +skb_push (skb, header_size);memcpy (skb->data, &frag_header, header_size);/* Send the last fragment */
Greg Kroah-Hartman
maintainerPATCH 248/251 RDMA/netlink: Add __maybe_unused to static inline in C file
In reply to Greg Kroah-HartmanFrom: Leon Romanovsky <[email protected]>
commit 83dde7498fefeb920b1def317421262317d178e5 upstream.
Like other commits in the tree add __maybe_unused to a static inline in a C file because some clang compilers will complain about unused code:
Quoted 1 line
Quoted 1 line
drivers/infiniband/core/nldev.c:2543:1: warning: unused function '__chk_RDMA_NL_NLDEV'
MODULE_ALIAS_RDMA_NETLINK(RDMA_NL_NLDEV, 5); ^
--- include/rdma/rdma_netlink.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/rdma/rdma_netlink.h +1 -1
@@ -24,7 +24,7 @@ enum rdma_nl_flags {* constant as well and the compiler checks they are the same. */ #define MODULE_ALIAS_RDMA_NETLINK (_index, _val) \ - static inline void __chk_##_index(void) \ + static inline void __maybe_unused __chk_##_index(void) \ { \ BUILD_BUG_ON(_index != _val); \ } \
Greg Kroah-Hartman
maintainerPATCH 249/251 ASoC: DAPM: Cover regression by kctl change notification fix
In reply to Greg Kroah-HartmanFrom: Takashi Iwai <[email protected]>
commit 827b0913a9d9d07a0c3e559dbb20ca4d6d285a54 upstream.
The recent fix for DAPM to correct the kctl change notification by the commit 5af82c81b2c4 ("ASoC: DAPM: Fix missing kctl change notifications") caused other regressions since it changed the behavior of snd_soc_dapm_set_pin() that is called from several API functions. Formerly it returned always 0 for success, but now it returns 0 or 1.
This patch addresses it, restoring the old behavior of snd_soc_dapm_set_pin() while keeping the fix in snd_soc_dapm_put_pin_switch().
--- sound/soc/soc-dapm.c | 29 +++++++++++++++++++++++------ 1 file changed, 23 insertions(+), 6 deletions(-)
sound/soc/soc-dapm.c +23 -6
@@ -2491,8 +2491,13 @@ static struct snd_soc_dapm_widget *dapm_return NULL ; } -static int snd_soc_dapm_set_pin (struct snd_soc_dapm_context *dapm, -const char *pin,int status) +/* +* set the DAPM pin status: +* returns 1 when the value has been updated, 0 when unchanged, or a negative +* error code; called from kcontrol put callback +*/ +static int __snd_soc_dapm_set_pin (struct snd_soc_dapm_context *dapm, +const char *pin,int status) {struct snd_soc_dapm_widget *w =dapm_find_widget (dapm, pin, true);int ret =0 ;
@@ -2518,6 +2523,18 @@ static int snd_soc_dapm_set_pin(struct sreturn ret; } +/* +* similar as __snd_soc_dapm_set_pin(), but returns 0 when successful; +* called from several API functions below +*/ +static int snd_soc_dapm_set_pin (struct snd_soc_dapm_context *dapm, +const char *pin,int status) +{ +int ret =__snd_soc_dapm_set_pin (dapm, pin, status); + +return ret <0 ? ret :0 ; +} +/** * snd_soc_dapm_sync_unlocked - scan and power dapm paths * @dapm: DAPM context
@@ -3445,10 +3462,10 @@ int snd_soc_dapm_put_pin_switch(struct sconst char *pin = (const char *)kcontrol->private_value;int ret; -if (ucontrol->value.integer.value[0 ]) - ret =snd_soc_dapm_enable_pin (&card->dapm, pin); -else - ret =snd_soc_dapm_disable_pin (&card->dapm, pin); +mutex_lock_nested (&card->dapm_mutex,SND_SOC_DAPM_CLASS_RUNTIME ); + ret =__snd_soc_dapm_set_pin (&card->dapm, pin, + !!ucontrol->value.integer.value[0 ]); +mutex_unlock (&card->dapm_mutex);snd_soc_dapm_sync (&card->dapm);return ret;
Greg Kroah-Hartman
maintainerPATCH 250/251 usb: max-3421: Use driver data instead of maintaining a list of bound devices
In reply to Greg Kroah-HartmanFrom: Uwe Kleine-König <[email protected]>
commit fc153aba3ef371d0d76eb88230ed4e0dee5b38f2 upstream.
Instead of maintaining a single-linked list of devices that must be searched linearly in .remove() just use spi_set_drvdata() to remember the link between the spi device and the driver struct. Then the global list and the next member can be dropped.
This simplifies the driver, reduces the memory footprint and the time to search the list. Also it makes obvious that there is always a corresponding driver struct for a given device in .remove(), so the error path for !max3421_hcd can be dropped, too.
As a side effect this fixes a data inconsistency when .probe() races with itself for a second max3421 device in manipulating max3421_hcd_list. A similar race is fixed in .remove(), too.
--- drivers/usb/host/max3421-hcd.c | 25 +++++-------------------- 1 file changed, 5 insertions(+), 20 deletions(-)
drivers/usb/host/max3421-hcd.c +5 -20
@@ -121,8 +121,6 @@ struct max3421_hcd {struct task_struct *spi_thread; -struct max3421_hcd *next; -enum max3421_rh_state rh_state;/* lower 16 bits contain port status, upper 16 bits the change mask: */ u32 port_status;
@@ -170,8 +168,6 @@ struct max3421_ep {u8 retransmit;/* packet needs retransmission */ }; -static struct max3421_hcd *max3421_hcd_list; -#define MAX3421_FIFO_SIZE 64#define MAX3421_SPI_DIR_RD 0/* read register from MAX3421 */
@@ -1835,9 +1831,8 @@ max3421_probe(struct spi_device *spi) }set_bit (HCD_FLAG_POLL_RH , &hcd->flags); max3421_hcd =hcd_to_max3421 (hcd); - max3421_hcd->next = max3421_hcd_list; - max3421_hcd_list = max3421_hcd;INIT_LIST_HEAD (&max3421_hcd->ep_list); +spi_set_drvdata (spi, max3421_hcd); max3421_hcd->tx =kmalloc (sizeof (*max3421_hcd->tx),GFP_KERNEL );if (!max3421_hcd->tx)
@@ -1882,28 +1877,18 @@ error:static int max3421_remove (struct spi_device *spi) { -struct max3421_hcd *max3421_hcd =NULL , **prev; -struct usb_hcd *hcd =NULL ; +struct max3421_hcd *max3421_hcd; +struct usb_hcd *hcd;unsigned long flags; -for (prev = &max3421_hcd_list; *prev; prev = &(*prev)->next) { - max3421_hcd = *prev; - hcd =max3421_to_hcd (max3421_hcd); -if (hcd->self.controller == &spi->dev) -break ; - } -if (!max3421_hcd) { -dev_err (&spi->dev,"no MAX3421 HCD found for SPI device %p\n" , - spi); -return -ENODEV ; - } + max3421_hcd =spi_get_drvdata (spi); + hcd =max3421_to_hcd (max3421_hcd);usb_remove_hcd (hcd);spin_lock_irqsave (&max3421_hcd->lock, flags);kthread_stop (max3421_hcd->spi_thread); - *prev = max3421_hcd->next;spin_unlock_irqrestore (&max3421_hcd->lock, flags);
Greg Kroah-Hartman
maintainerPATCH 251/251 hugetlbfs: flush TLBs correctly after huge_pmd_unshare
In reply to Greg Kroah-HartmanFrom: Nadav Amit <[email protected]>
commit a4a118f2eead1d6c49e00765de89878288d4b890 upstream.
When __unmap_hugepage_range() calls to huge_pmd_unshare() succeed, a TLB flush is missing. This TLB flush must be performed before releasing the i_mmap_rwsem, in order to prevent an unshared PMDs page from being released and reused before the TLB flush took place.
Arguably, a comprehensive solution would use mmu_gather interface to batch the TLB flushes and the PMDs page release, however it is not an easy solution: (1) try_to_unmap_one() and try_to_migrate_one() also call huge_pmd_unshare() and they cannot use the mmu_gather interface; and (2) deferring the release of the page reference for the PMDs page until after i_mmap_rwsem is dropeed can confuse huge_pmd_unshare() into thinking PMDs are shared when they are not.
Fix __unmap_hugepage_range() by adding the missing TLB flush, and forcing a flush when unshare is successful.
--- include/asm-generic/tlb.h | 6 ++++++ mm/hugetlb.c | 19 +++++++++++++++++++ 2 files changed, 25 insertions(+)
include/asm-generic/tlb.h +6 -0
@@ -196,6 +196,12 @@ static inline void tlb_remove_check_page#define tlb_end_vma __tlb_end_vma#endif +static inline void tlb_flush_pmd_range (struct mmu_gather *tlb, +unsigned long address,unsigned long size) +{ +__tlb_adjust_range (tlb, address, size); +} +#ifndef __tlb_remove_tlb_entry#define __tlb_remove_tlb_entry (tlb, ptep, address) do { } while (0)#endif
mm/hugetlb.c +19 -0
@@ -3386,6 +3386,7 @@ void __unmap_hugepage_range(struct mmu_gunsigned long sz =huge_page_size (h);const unsigned long mmun_start = start;/* For mmu_notifiers */ const unsigned long mmun_end = end;/* For mmu_notifiers */ +bool force_flush = false;WARN_ON (!is_vm_hugetlb_page (vma));BUG_ON (start & ~huge_page_mask (h));
@@ -3407,6 +3408,8 @@ void __unmap_hugepage_range(struct mmu_g ptl =huge_pte_lock (h, mm, ptep);if (huge_pmd_unshare (mm, &address, ptep)) {spin_unlock (ptl); +tlb_flush_pmd_range (tlb, address &PUD_MASK ,PUD_SIZE ); + force_flush = true;continue ; }
@@ -3463,6 +3466,22 @@ void __unmap_hugepage_range(struct mmu_g }mmu_notifier_invalidate_range_end (mm, mmun_start, mmun_end);tlb_end_vma (tlb, vma); + +/* +* If we unshared PMDs, the TLB flush was not recorded in mmu_gather. We +* could defer the flush until now, since by holding i_mmap_rwsem we +* guaranteed that the last refernece would not be dropped. But we must +* do the flushing before we return, as otherwise i_mmap_rwsem will be +* dropped and the last reference to the shared PMDs page might be +* dropped as well. +* +* In theory we could defer the freeing of the PMD pages as well, but +* huge_pmd_unshare() relies on the exact page_count for the PMD page to +* detect sharing, so we cannot defer the release of the page either. +* Instead, do flush now. +*/ +if (force_flush) +tlb_flush_mmu (tlb); } void __unmap_hugepage_range_final(struct mmu_gather *tlb,
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.256 release. There are 251 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 Fri, 26 Nov 2021 11:56:36 +0000. Anything received after that time might be too late.
Building s390:defconfig ... failed
--------------
Error log:mm/hugetlb.c: In function '__unmap_hugepage_range':mm/hugetlb.c:3411:4: error: implicit declaration of function 'tlb_flush_pmd_range'
The problem also affects 'sh' builds, and possibly others.
Guenter
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.256 release. There are 251 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 Fri, 26 Nov 2021 11:56:36 +0000. Anything received after that time might be too late.
Build results:
total: 168 pass: 161 fail: 7 Failed builds: ia64:defconfig s390:defconfig s390:allmodconfig s390:performance_defconfig sh:dreamcast_defconfig sh:microdev_defconfig sh:shx3_defconfig Qemu test results: total: 423 pass: 418 fail: 5
Failed tests:
s390:defconfig:nolocktests:smp2:net,default:initrd s390:defconfig:nolocktests:smp2:virtio-blk-ccw:net,virtio-net-pci:rootfs s390:defconfig:nolocktests:smp2:scsi[virtio-ccw]:net,default:rootfs s390:defconfig:nolocktests:virtio-pci:net,virtio-net-pci:rootfs s390:defconfig:nolocktests:scsi[virtio-pci]:net,default:rootfs
mm/hugetlb.c: In function '__unmap_hugepage_range':mm/hugetlb.c:3411:25: error: implicit declaration of function 'tlb_flush_pmd_range'
Guenter
Greg Kroah-Hartman
maintainerQuoted 29 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.256 release. There are 251 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 Fri, 26 Nov 2021 11:56:36 +0000. Anything received after that time might be too late.
Build results:
total: 168 pass: 161 fail: 7 Failed builds: ia64:defconfig s390:defconfig s390:allmodconfig s390:performance_defconfig sh:dreamcast_defconfig sh:microdev_defconfig sh:shx3_defconfig Qemu test results: total: 423 pass: 418 fail: 5Failed tests:
s390:defconfig:nolocktests:smp2:net,default:initrd s390:defconfig:nolocktests:smp2:virtio-blk-ccw:net,virtio-net-pci:rootfs s390:defconfig:nolocktests:smp2:scsi[virtio-ccw]:net,default:rootfs s390:defconfig:nolocktests:virtio-pci:net,virtio-net-pci:rootfs s390:defconfig:nolocktests:scsi[virtio-pci]:net,default:rootfs
Quoted 2 lines
mm/hugetlb.c: In function '__unmap_hugepage_range':mm/hugetlb.c:3411:25: error: implicit declaration of function 'tlb_flush_pmd_range'
Should be fixed in -rc1.
thanks,
greg k-h
Greg Kroah-Hartman
maintainerQuoted 30 lines · Greg Kroah-Hartman
Quoted 29 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.256 release. There are 251 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 Fri, 26 Nov 2021 11:56:36 +0000. Anything received after that time might be too late.
Build results:
total: 168 pass: 161 fail: 7 Failed builds: ia64:defconfig s390:defconfig s390:allmodconfig s390:performance_defconfig sh:dreamcast_defconfig sh:microdev_defconfig sh:shx3_defconfig Qemu test results: total: 423 pass: 418 fail: 5Failed tests:
s390:defconfig:nolocktests:smp2:net,default:initrd s390:defconfig:nolocktests:smp2:virtio-blk-ccw:net,virtio-net-pci:rootfs s390:defconfig:nolocktests:smp2:scsi[virtio-ccw]:net,default:rootfs s390:defconfig:nolocktests:virtio-pci:net,virtio-net-pci:rootfs s390:defconfig:nolocktests:scsi[virtio-pci]:net,default:rootfs
Quoted 4 lines
Quoted 2 lines
mm/hugetlb.c: In function '__unmap_hugepage_range':mm/hugetlb.c:3411:25: error: implicit declaration of function 'tlb_flush_pmd_range'Should be fixed in -rc1.
{sigh} -rc2 I mean.
thanks,
greg k-h
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.256 release. There are 251 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 Fri, 26 Nov 2021 11:56:36 +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/v4.x/stable-review/patch-4.14.256-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.thanks,
greg k-h
FYI,
New warnings on Linux 4.14.256-rc1 on arm and arm64 (defconfig+7) with gcc-11.
drivers/soc/tegra/pmc.c: In function 'tegra_powergate_power_up':drivers/soc/tegra/pmc.c:423:1: warning: label 'powergate_off' defined but not used [-Wunused-label]
423 | powergate_off:
| ^~~~~~~~~~~~~
--
Linaro LKFT
https://lkft.linaro.org
Greg Kroah-Hartman
maintainerQuoted 25 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.256 release. There are 251 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 Fri, 26 Nov 2021 11:56:36 +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/v4.x/stable-review/patch-4.14.256-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.thanks,
greg k-h
FYI,
New warnings on Linux 4.14.256-rc1 on arm and arm64 (defconfig+7) with gcc-11.
Quoted 8 lines
drivers/soc/tegra/pmc.c: In function 'tegra_powergate_power_up':drivers/soc/tegra/pmc.c:423:1: warning: label 'powergate_off' defined but not used [-Wunused-label]
423 |powergate_off:| ^~~~~~~~~~~~~
Now fixed, thanks.
greg k-h
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.256 release. There are 251 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 Fri, 26 Nov 2021 11:56:36 +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/v4.x/stable-review/patch-4.14.256-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v4.14:
8 builds: 8 pass, 0 fail
16 boots: 16 pass, 0 fail
32 tests: 32 pass, 0 failLinux version: 4.14.256-rc1-g520f0138724e
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
Jon