The patch below does not apply to the 5.10-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From f094a39c6ba168f2df1edfd1731cca377af5f442 Mon Sep 17 00:00:00 2001
From: Christian Borntraeger <borntraeger(a)linux.ibm.com>
Date: Mon, 17 Jan 2022 18:40:32 +0100
Subject: [PATCH] s390/nmi: handle vector validity failures for KVM guests
The machine check validity bit tells about the context. If a KVM guest
was running the bit tells about the guest validity and the host state is
not affected. As a guest can disable the guest validity this might
result in unwanted host errors on machine checks.
Cc: stable(a)vger.kernel.org
Fixes: c929500d7a5a ("s390/nmi: s390: New low level handling for machine check happening in guest")
Signed-off-by: Christian Borntraeger <borntraeger(a)linux.ibm.com>
Reviewed-by: Heiko Carstens <hca(a)linux.ibm.com>
Signed-off-by: Heiko Carstens <hca(a)linux.ibm.com>
diff --git a/arch/s390/kernel/nmi.c b/arch/s390/kernel/nmi.c
index 147c0d5fd9b4..651a51914e34 100644
--- a/arch/s390/kernel/nmi.c
+++ b/arch/s390/kernel/nmi.c
@@ -264,7 +264,14 @@ static int notrace s390_validate_registers(union mci mci, int umode)
/* Validate vector registers */
union ctlreg0 cr0;
- if (!mci.vr) {
+ /*
+ * The vector validity must only be checked if not running a
+ * KVM guest. For KVM guests the machine check is forwarded by
+ * KVM and it is the responsibility of the guest to take
+ * appropriate actions. The host vector or FPU values have been
+ * saved by KVM and will be restored by KVM.
+ */
+ if (!mci.vr && !test_cpu_flag(CIF_MCCK_GUEST)) {
/*
* Vector registers can't be restored. If the kernel
* currently uses vector registers the system is
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 1ea1d6a847d2b1d17fefd9196664b95f052a0775 Mon Sep 17 00:00:00 2001
From: Christian Borntraeger <borntraeger(a)linux.ibm.com>
Date: Thu, 13 Jan 2022 11:44:19 +0100
Subject: [PATCH] s390/nmi: handle guarded storage validity failures for KVM
guests
machine check validity bits reflect the state of the machine check. If a
guest does not make use of guarded storage, the validity bit might be
off. We can not use the host CR bit to decide if the validity bit must
be on. So ignore "invalid" guarded storage controls for KVM guests in
the host and rely on the machine check being forwarded to the guest. If
no other errors happen from a host perspective everything is fine and no
process must be killed and the host can continue to run.
Cc: stable(a)vger.kernel.org
Fixes: c929500d7a5a ("s390/nmi: s390: New low level handling for machine check happening in guest")
Reported-by: Carsten Otte <cotte(a)de.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger(a)linux.ibm.com>
Tested-by: Carsten Otte <cotte(a)de.ibm.com>
Reviewed-by: Heiko Carstens <hca(a)linux.ibm.com>
Signed-off-by: Heiko Carstens <hca(a)linux.ibm.com>
diff --git a/arch/s390/kernel/nmi.c b/arch/s390/kernel/nmi.c
index 0c9e894913dc..147c0d5fd9b4 100644
--- a/arch/s390/kernel/nmi.c
+++ b/arch/s390/kernel/nmi.c
@@ -307,11 +307,21 @@ static int notrace s390_validate_registers(union mci mci, int umode)
if (cr2.gse) {
if (!mci.gs) {
/*
- * Guarded storage register can't be restored and
- * the current processes uses guarded storage.
- * It has to be terminated.
+ * 2 cases:
+ * - machine check in kernel or userspace
+ * - machine check while running SIE (KVM guest)
+ * For kernel or userspace the userspace values of
+ * guarded storage control can not be recreated, the
+ * process must be terminated.
+ * For SIE the guest values of guarded storage can not
+ * be recreated. This is either due to a bug or due to
+ * GS being disabled in the guest. The guest will be
+ * notified by KVM code and the guests machine check
+ * handling must take care of this. The host values
+ * are saved by KVM and are not affected.
*/
- kill_task = 1;
+ if (!test_cpu_flag(CIF_MCCK_GUEST))
+ kill_task = 1;
} else {
load_gs_cb((struct gs_cb *)mcesa->guarded_storage_save_area);
}
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 1ea1d6a847d2b1d17fefd9196664b95f052a0775 Mon Sep 17 00:00:00 2001
From: Christian Borntraeger <borntraeger(a)linux.ibm.com>
Date: Thu, 13 Jan 2022 11:44:19 +0100
Subject: [PATCH] s390/nmi: handle guarded storage validity failures for KVM
guests
machine check validity bits reflect the state of the machine check. If a
guest does not make use of guarded storage, the validity bit might be
off. We can not use the host CR bit to decide if the validity bit must
be on. So ignore "invalid" guarded storage controls for KVM guests in
the host and rely on the machine check being forwarded to the guest. If
no other errors happen from a host perspective everything is fine and no
process must be killed and the host can continue to run.
Cc: stable(a)vger.kernel.org
Fixes: c929500d7a5a ("s390/nmi: s390: New low level handling for machine check happening in guest")
Reported-by: Carsten Otte <cotte(a)de.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger(a)linux.ibm.com>
Tested-by: Carsten Otte <cotte(a)de.ibm.com>
Reviewed-by: Heiko Carstens <hca(a)linux.ibm.com>
Signed-off-by: Heiko Carstens <hca(a)linux.ibm.com>
diff --git a/arch/s390/kernel/nmi.c b/arch/s390/kernel/nmi.c
index 0c9e894913dc..147c0d5fd9b4 100644
--- a/arch/s390/kernel/nmi.c
+++ b/arch/s390/kernel/nmi.c
@@ -307,11 +307,21 @@ static int notrace s390_validate_registers(union mci mci, int umode)
if (cr2.gse) {
if (!mci.gs) {
/*
- * Guarded storage register can't be restored and
- * the current processes uses guarded storage.
- * It has to be terminated.
+ * 2 cases:
+ * - machine check in kernel or userspace
+ * - machine check while running SIE (KVM guest)
+ * For kernel or userspace the userspace values of
+ * guarded storage control can not be recreated, the
+ * process must be terminated.
+ * For SIE the guest values of guarded storage can not
+ * be recreated. This is either due to a bug or due to
+ * GS being disabled in the guest. The guest will be
+ * notified by KVM code and the guests machine check
+ * handling must take care of this. The host values
+ * are saved by KVM and are not affected.
*/
- kill_task = 1;
+ if (!test_cpu_flag(CIF_MCCK_GUEST))
+ kill_task = 1;
} else {
load_gs_cb((struct gs_cb *)mcesa->guarded_storage_save_area);
}
The patch below does not apply to the 5.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 1ea1d6a847d2b1d17fefd9196664b95f052a0775 Mon Sep 17 00:00:00 2001
From: Christian Borntraeger <borntraeger(a)linux.ibm.com>
Date: Thu, 13 Jan 2022 11:44:19 +0100
Subject: [PATCH] s390/nmi: handle guarded storage validity failures for KVM
guests
machine check validity bits reflect the state of the machine check. If a
guest does not make use of guarded storage, the validity bit might be
off. We can not use the host CR bit to decide if the validity bit must
be on. So ignore "invalid" guarded storage controls for KVM guests in
the host and rely on the machine check being forwarded to the guest. If
no other errors happen from a host perspective everything is fine and no
process must be killed and the host can continue to run.
Cc: stable(a)vger.kernel.org
Fixes: c929500d7a5a ("s390/nmi: s390: New low level handling for machine check happening in guest")
Reported-by: Carsten Otte <cotte(a)de.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger(a)linux.ibm.com>
Tested-by: Carsten Otte <cotte(a)de.ibm.com>
Reviewed-by: Heiko Carstens <hca(a)linux.ibm.com>
Signed-off-by: Heiko Carstens <hca(a)linux.ibm.com>
diff --git a/arch/s390/kernel/nmi.c b/arch/s390/kernel/nmi.c
index 0c9e894913dc..147c0d5fd9b4 100644
--- a/arch/s390/kernel/nmi.c
+++ b/arch/s390/kernel/nmi.c
@@ -307,11 +307,21 @@ static int notrace s390_validate_registers(union mci mci, int umode)
if (cr2.gse) {
if (!mci.gs) {
/*
- * Guarded storage register can't be restored and
- * the current processes uses guarded storage.
- * It has to be terminated.
+ * 2 cases:
+ * - machine check in kernel or userspace
+ * - machine check while running SIE (KVM guest)
+ * For kernel or userspace the userspace values of
+ * guarded storage control can not be recreated, the
+ * process must be terminated.
+ * For SIE the guest values of guarded storage can not
+ * be recreated. This is either due to a bug or due to
+ * GS being disabled in the guest. The guest will be
+ * notified by KVM code and the guests machine check
+ * handling must take care of this. The host values
+ * are saved by KVM and are not affected.
*/
- kill_task = 1;
+ if (!test_cpu_flag(CIF_MCCK_GUEST))
+ kill_task = 1;
} else {
load_gs_cb((struct gs_cb *)mcesa->guarded_storage_save_area);
}
The patch below does not apply to the 5.10-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 1ea1d6a847d2b1d17fefd9196664b95f052a0775 Mon Sep 17 00:00:00 2001
From: Christian Borntraeger <borntraeger(a)linux.ibm.com>
Date: Thu, 13 Jan 2022 11:44:19 +0100
Subject: [PATCH] s390/nmi: handle guarded storage validity failures for KVM
guests
machine check validity bits reflect the state of the machine check. If a
guest does not make use of guarded storage, the validity bit might be
off. We can not use the host CR bit to decide if the validity bit must
be on. So ignore "invalid" guarded storage controls for KVM guests in
the host and rely on the machine check being forwarded to the guest. If
no other errors happen from a host perspective everything is fine and no
process must be killed and the host can continue to run.
Cc: stable(a)vger.kernel.org
Fixes: c929500d7a5a ("s390/nmi: s390: New low level handling for machine check happening in guest")
Reported-by: Carsten Otte <cotte(a)de.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger(a)linux.ibm.com>
Tested-by: Carsten Otte <cotte(a)de.ibm.com>
Reviewed-by: Heiko Carstens <hca(a)linux.ibm.com>
Signed-off-by: Heiko Carstens <hca(a)linux.ibm.com>
diff --git a/arch/s390/kernel/nmi.c b/arch/s390/kernel/nmi.c
index 0c9e894913dc..147c0d5fd9b4 100644
--- a/arch/s390/kernel/nmi.c
+++ b/arch/s390/kernel/nmi.c
@@ -307,11 +307,21 @@ static int notrace s390_validate_registers(union mci mci, int umode)
if (cr2.gse) {
if (!mci.gs) {
/*
- * Guarded storage register can't be restored and
- * the current processes uses guarded storage.
- * It has to be terminated.
+ * 2 cases:
+ * - machine check in kernel or userspace
+ * - machine check while running SIE (KVM guest)
+ * For kernel or userspace the userspace values of
+ * guarded storage control can not be recreated, the
+ * process must be terminated.
+ * For SIE the guest values of guarded storage can not
+ * be recreated. This is either due to a bug or due to
+ * GS being disabled in the guest. The guest will be
+ * notified by KVM code and the guests machine check
+ * handling must take care of this. The host values
+ * are saved by KVM and are not affected.
*/
- kill_task = 1;
+ if (!test_cpu_flag(CIF_MCCK_GUEST))
+ kill_task = 1;
} else {
load_gs_cb((struct gs_cb *)mcesa->guarded_storage_save_area);
}
The patch below does not apply to the 5.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 0735e639f129dff455aeb91da291f5c578cc33db Mon Sep 17 00:00:00 2001
From: Mohammad Athari Bin Ismail <mohammad.athari.ismail(a)intel.com>
Date: Wed, 26 Jan 2022 17:47:23 +0800
Subject: [PATCH] net: stmmac: skip only stmmac_ptp_register when resume from
suspend
When resume from suspend, besides skipping PTP registration, it also
skipping PTP HW initialization. This could cause PTP clock not able to
operate properly when resume from suspend.
To fix this, only stmmac_ptp_register() is skipped when resume from
suspend.
Fixes: fe1319291150 ("stmmac: Don't init ptp again when resume from suspend/hibernation")
Cc: <stable(a)vger.kernel.org> # 5.15.x
Signed-off-by: Mohammad Athari Bin Ismail <mohammad.athari.ismail(a)intel.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 25c802344356..639a753266e6 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -915,8 +915,6 @@ static int stmmac_init_ptp(struct stmmac_priv *priv)
priv->hwts_tx_en = 0;
priv->hwts_rx_en = 0;
- stmmac_ptp_register(priv);
-
return 0;
}
@@ -3242,7 +3240,7 @@ static int stmmac_fpe_start_wq(struct stmmac_priv *priv)
/**
* stmmac_hw_setup - setup mac in a usable state.
* @dev : pointer to the device structure.
- * @init_ptp: initialize PTP if set
+ * @ptp_register: register PTP if set
* Description:
* this is the main function to setup the HW in a usable state because the
* dma engine is reset, the core registers are configured (e.g. AXI,
@@ -3252,7 +3250,7 @@ static int stmmac_fpe_start_wq(struct stmmac_priv *priv)
* 0 on success and an appropriate (-)ve integer as defined in errno.h
* file on failure.
*/
-static int stmmac_hw_setup(struct net_device *dev, bool init_ptp)
+static int stmmac_hw_setup(struct net_device *dev, bool ptp_register)
{
struct stmmac_priv *priv = netdev_priv(dev);
u32 rx_cnt = priv->plat->rx_queues_to_use;
@@ -3309,13 +3307,13 @@ static int stmmac_hw_setup(struct net_device *dev, bool init_ptp)
stmmac_mmc_setup(priv);
- if (init_ptp) {
- ret = stmmac_init_ptp(priv);
- if (ret == -EOPNOTSUPP)
- netdev_warn(priv->dev, "PTP not supported by HW\n");
- else if (ret)
- netdev_warn(priv->dev, "PTP init failed\n");
- }
+ ret = stmmac_init_ptp(priv);
+ if (ret == -EOPNOTSUPP)
+ netdev_warn(priv->dev, "PTP not supported by HW\n");
+ else if (ret)
+ netdev_warn(priv->dev, "PTP init failed\n");
+ else if (ptp_register)
+ stmmac_ptp_register(priv);
priv->eee_tw_timer = STMMAC_DEFAULT_TWT_LS;
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 0735e639f129dff455aeb91da291f5c578cc33db Mon Sep 17 00:00:00 2001
From: Mohammad Athari Bin Ismail <mohammad.athari.ismail(a)intel.com>
Date: Wed, 26 Jan 2022 17:47:23 +0800
Subject: [PATCH] net: stmmac: skip only stmmac_ptp_register when resume from
suspend
When resume from suspend, besides skipping PTP registration, it also
skipping PTP HW initialization. This could cause PTP clock not able to
operate properly when resume from suspend.
To fix this, only stmmac_ptp_register() is skipped when resume from
suspend.
Fixes: fe1319291150 ("stmmac: Don't init ptp again when resume from suspend/hibernation")
Cc: <stable(a)vger.kernel.org> # 5.15.x
Signed-off-by: Mohammad Athari Bin Ismail <mohammad.athari.ismail(a)intel.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 25c802344356..639a753266e6 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -915,8 +915,6 @@ static int stmmac_init_ptp(struct stmmac_priv *priv)
priv->hwts_tx_en = 0;
priv->hwts_rx_en = 0;
- stmmac_ptp_register(priv);
-
return 0;
}
@@ -3242,7 +3240,7 @@ static int stmmac_fpe_start_wq(struct stmmac_priv *priv)
/**
* stmmac_hw_setup - setup mac in a usable state.
* @dev : pointer to the device structure.
- * @init_ptp: initialize PTP if set
+ * @ptp_register: register PTP if set
* Description:
* this is the main function to setup the HW in a usable state because the
* dma engine is reset, the core registers are configured (e.g. AXI,
@@ -3252,7 +3250,7 @@ static int stmmac_fpe_start_wq(struct stmmac_priv *priv)
* 0 on success and an appropriate (-)ve integer as defined in errno.h
* file on failure.
*/
-static int stmmac_hw_setup(struct net_device *dev, bool init_ptp)
+static int stmmac_hw_setup(struct net_device *dev, bool ptp_register)
{
struct stmmac_priv *priv = netdev_priv(dev);
u32 rx_cnt = priv->plat->rx_queues_to_use;
@@ -3309,13 +3307,13 @@ static int stmmac_hw_setup(struct net_device *dev, bool init_ptp)
stmmac_mmc_setup(priv);
- if (init_ptp) {
- ret = stmmac_init_ptp(priv);
- if (ret == -EOPNOTSUPP)
- netdev_warn(priv->dev, "PTP not supported by HW\n");
- else if (ret)
- netdev_warn(priv->dev, "PTP init failed\n");
- }
+ ret = stmmac_init_ptp(priv);
+ if (ret == -EOPNOTSUPP)
+ netdev_warn(priv->dev, "PTP not supported by HW\n");
+ else if (ret)
+ netdev_warn(priv->dev, "PTP init failed\n");
+ else if (ptp_register)
+ stmmac_ptp_register(priv);
priv->eee_tw_timer = STMMAC_DEFAULT_TWT_LS;
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 0735e639f129dff455aeb91da291f5c578cc33db Mon Sep 17 00:00:00 2001
From: Mohammad Athari Bin Ismail <mohammad.athari.ismail(a)intel.com>
Date: Wed, 26 Jan 2022 17:47:23 +0800
Subject: [PATCH] net: stmmac: skip only stmmac_ptp_register when resume from
suspend
When resume from suspend, besides skipping PTP registration, it also
skipping PTP HW initialization. This could cause PTP clock not able to
operate properly when resume from suspend.
To fix this, only stmmac_ptp_register() is skipped when resume from
suspend.
Fixes: fe1319291150 ("stmmac: Don't init ptp again when resume from suspend/hibernation")
Cc: <stable(a)vger.kernel.org> # 5.15.x
Signed-off-by: Mohammad Athari Bin Ismail <mohammad.athari.ismail(a)intel.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 25c802344356..639a753266e6 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -915,8 +915,6 @@ static int stmmac_init_ptp(struct stmmac_priv *priv)
priv->hwts_tx_en = 0;
priv->hwts_rx_en = 0;
- stmmac_ptp_register(priv);
-
return 0;
}
@@ -3242,7 +3240,7 @@ static int stmmac_fpe_start_wq(struct stmmac_priv *priv)
/**
* stmmac_hw_setup - setup mac in a usable state.
* @dev : pointer to the device structure.
- * @init_ptp: initialize PTP if set
+ * @ptp_register: register PTP if set
* Description:
* this is the main function to setup the HW in a usable state because the
* dma engine is reset, the core registers are configured (e.g. AXI,
@@ -3252,7 +3250,7 @@ static int stmmac_fpe_start_wq(struct stmmac_priv *priv)
* 0 on success and an appropriate (-)ve integer as defined in errno.h
* file on failure.
*/
-static int stmmac_hw_setup(struct net_device *dev, bool init_ptp)
+static int stmmac_hw_setup(struct net_device *dev, bool ptp_register)
{
struct stmmac_priv *priv = netdev_priv(dev);
u32 rx_cnt = priv->plat->rx_queues_to_use;
@@ -3309,13 +3307,13 @@ static int stmmac_hw_setup(struct net_device *dev, bool init_ptp)
stmmac_mmc_setup(priv);
- if (init_ptp) {
- ret = stmmac_init_ptp(priv);
- if (ret == -EOPNOTSUPP)
- netdev_warn(priv->dev, "PTP not supported by HW\n");
- else if (ret)
- netdev_warn(priv->dev, "PTP init failed\n");
- }
+ ret = stmmac_init_ptp(priv);
+ if (ret == -EOPNOTSUPP)
+ netdev_warn(priv->dev, "PTP not supported by HW\n");
+ else if (ret)
+ netdev_warn(priv->dev, "PTP init failed\n");
+ else if (ptp_register)
+ stmmac_ptp_register(priv);
priv->eee_tw_timer = STMMAC_DEFAULT_TWT_LS;
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 0735e639f129dff455aeb91da291f5c578cc33db Mon Sep 17 00:00:00 2001
From: Mohammad Athari Bin Ismail <mohammad.athari.ismail(a)intel.com>
Date: Wed, 26 Jan 2022 17:47:23 +0800
Subject: [PATCH] net: stmmac: skip only stmmac_ptp_register when resume from
suspend
When resume from suspend, besides skipping PTP registration, it also
skipping PTP HW initialization. This could cause PTP clock not able to
operate properly when resume from suspend.
To fix this, only stmmac_ptp_register() is skipped when resume from
suspend.
Fixes: fe1319291150 ("stmmac: Don't init ptp again when resume from suspend/hibernation")
Cc: <stable(a)vger.kernel.org> # 5.15.x
Signed-off-by: Mohammad Athari Bin Ismail <mohammad.athari.ismail(a)intel.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 25c802344356..639a753266e6 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -915,8 +915,6 @@ static int stmmac_init_ptp(struct stmmac_priv *priv)
priv->hwts_tx_en = 0;
priv->hwts_rx_en = 0;
- stmmac_ptp_register(priv);
-
return 0;
}
@@ -3242,7 +3240,7 @@ static int stmmac_fpe_start_wq(struct stmmac_priv *priv)
/**
* stmmac_hw_setup - setup mac in a usable state.
* @dev : pointer to the device structure.
- * @init_ptp: initialize PTP if set
+ * @ptp_register: register PTP if set
* Description:
* this is the main function to setup the HW in a usable state because the
* dma engine is reset, the core registers are configured (e.g. AXI,
@@ -3252,7 +3250,7 @@ static int stmmac_fpe_start_wq(struct stmmac_priv *priv)
* 0 on success and an appropriate (-)ve integer as defined in errno.h
* file on failure.
*/
-static int stmmac_hw_setup(struct net_device *dev, bool init_ptp)
+static int stmmac_hw_setup(struct net_device *dev, bool ptp_register)
{
struct stmmac_priv *priv = netdev_priv(dev);
u32 rx_cnt = priv->plat->rx_queues_to_use;
@@ -3309,13 +3307,13 @@ static int stmmac_hw_setup(struct net_device *dev, bool init_ptp)
stmmac_mmc_setup(priv);
- if (init_ptp) {
- ret = stmmac_init_ptp(priv);
- if (ret == -EOPNOTSUPP)
- netdev_warn(priv->dev, "PTP not supported by HW\n");
- else if (ret)
- netdev_warn(priv->dev, "PTP init failed\n");
- }
+ ret = stmmac_init_ptp(priv);
+ if (ret == -EOPNOTSUPP)
+ netdev_warn(priv->dev, "PTP not supported by HW\n");
+ else if (ret)
+ netdev_warn(priv->dev, "PTP init failed\n");
+ else if (ptp_register)
+ stmmac_ptp_register(priv);
priv->eee_tw_timer = STMMAC_DEFAULT_TWT_LS;
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 0735e639f129dff455aeb91da291f5c578cc33db Mon Sep 17 00:00:00 2001
From: Mohammad Athari Bin Ismail <mohammad.athari.ismail(a)intel.com>
Date: Wed, 26 Jan 2022 17:47:23 +0800
Subject: [PATCH] net: stmmac: skip only stmmac_ptp_register when resume from
suspend
When resume from suspend, besides skipping PTP registration, it also
skipping PTP HW initialization. This could cause PTP clock not able to
operate properly when resume from suspend.
To fix this, only stmmac_ptp_register() is skipped when resume from
suspend.
Fixes: fe1319291150 ("stmmac: Don't init ptp again when resume from suspend/hibernation")
Cc: <stable(a)vger.kernel.org> # 5.15.x
Signed-off-by: Mohammad Athari Bin Ismail <mohammad.athari.ismail(a)intel.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 25c802344356..639a753266e6 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -915,8 +915,6 @@ static int stmmac_init_ptp(struct stmmac_priv *priv)
priv->hwts_tx_en = 0;
priv->hwts_rx_en = 0;
- stmmac_ptp_register(priv);
-
return 0;
}
@@ -3242,7 +3240,7 @@ static int stmmac_fpe_start_wq(struct stmmac_priv *priv)
/**
* stmmac_hw_setup - setup mac in a usable state.
* @dev : pointer to the device structure.
- * @init_ptp: initialize PTP if set
+ * @ptp_register: register PTP if set
* Description:
* this is the main function to setup the HW in a usable state because the
* dma engine is reset, the core registers are configured (e.g. AXI,
@@ -3252,7 +3250,7 @@ static int stmmac_fpe_start_wq(struct stmmac_priv *priv)
* 0 on success and an appropriate (-)ve integer as defined in errno.h
* file on failure.
*/
-static int stmmac_hw_setup(struct net_device *dev, bool init_ptp)
+static int stmmac_hw_setup(struct net_device *dev, bool ptp_register)
{
struct stmmac_priv *priv = netdev_priv(dev);
u32 rx_cnt = priv->plat->rx_queues_to_use;
@@ -3309,13 +3307,13 @@ static int stmmac_hw_setup(struct net_device *dev, bool init_ptp)
stmmac_mmc_setup(priv);
- if (init_ptp) {
- ret = stmmac_init_ptp(priv);
- if (ret == -EOPNOTSUPP)
- netdev_warn(priv->dev, "PTP not supported by HW\n");
- else if (ret)
- netdev_warn(priv->dev, "PTP init failed\n");
- }
+ ret = stmmac_init_ptp(priv);
+ if (ret == -EOPNOTSUPP)
+ netdev_warn(priv->dev, "PTP not supported by HW\n");
+ else if (ret)
+ netdev_warn(priv->dev, "PTP init failed\n");
+ else if (ptp_register)
+ stmmac_ptp_register(priv);
priv->eee_tw_timer = STMMAC_DEFAULT_TWT_LS;
Hi,
I'm not sure when patches get picked from Linus' branch, just in case
please add the following fixes to 5.16.4. They fix a few user visible
bugs in defrag, all apply cleanly. Thanks.
6b34cd8e175b btrfs: fix too long loop when defragging a 1 byte file
b767c2fc787e btrfs: allow defrag to be interruptible
484167da7773 btrfs: defrag: fix wrong number of defragged sectors
c080b4144b9d btrfs: defrag: properly update range->start for autodefrag
0cb5950f3f3b btrfs: fix deadlock when reserving space during defrag
3c9d31c71594 btrfs: add back missing dirty page rate limiting to defrag
From: D Scott Phillips <scott(a)os.amperecomputing.com>
commit 38e0257e0e6f4fef2aa2966b089b56a8b1cfb75c upstream.
The erratum 1418040 workaround enables CNTVCT_EL1 access trapping in EL0
when executing compat threads. The workaround is applied when switching
between tasks, but the need for the workaround could also change at an
exec(), when a non-compat task execs a compat binary or vice versa. Apply
the workaround in arch_setup_new_exec().
This leaves a small window of time between SET_PERSONALITY and
arch_setup_new_exec where preemption could occur and confuse the old
workaround logic that compares TIF_32BIT between prev and next. Instead, we
can just read cntkctl to make sure it's in the state that the next task
needs. I measured cntkctl read time to be about the same as a mov from a
general-purpose register on N1. Update the workaround logic to examine the
current value of cntkctl instead of the previous task's compat state.
Fixes: d49f7d7376d0 ("arm64: Move handling of erratum 1418040 into C code")
Cc: <stable(a)vger.kernel.org> # 5.9.x
Signed-off-by: D Scott Phillips <scott(a)os.amperecomputing.com>
Reviewed-by: Marc Zyngier <maz(a)kernel.org>
Link: https://lore.kernel.org/r/20211220234114.3926-1-scott@os.amperecomputing.com
Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com>
---
arch/arm64/kernel/process.c | 39 +++++++++++++++----------------------
1 file changed, 16 insertions(+), 23 deletions(-)
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index f7c42a7d09b6..c108d96a22db 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -515,34 +515,26 @@ static void entry_task_switch(struct task_struct *next)
/*
* ARM erratum 1418040 handling, affecting the 32bit view of CNTVCT.
- * Assuming the virtual counter is enabled at the beginning of times:
- *
- * - disable access when switching from a 64bit task to a 32bit task
- * - enable access when switching from a 32bit task to a 64bit task
+ * Ensure access is disabled when switching to a 32bit task, ensure
+ * access is enabled when switching to a 64bit task.
*/
-static void erratum_1418040_thread_switch(struct task_struct *prev,
- struct task_struct *next)
+static void erratum_1418040_thread_switch(struct task_struct *next)
{
- bool prev32, next32;
- u64 val;
-
- if (!IS_ENABLED(CONFIG_ARM64_ERRATUM_1418040))
- return;
-
- prev32 = is_compat_thread(task_thread_info(prev));
- next32 = is_compat_thread(task_thread_info(next));
-
- if (prev32 == next32 || !this_cpu_has_cap(ARM64_WORKAROUND_1418040))
+ if (!IS_ENABLED(CONFIG_ARM64_ERRATUM_1418040) ||
+ !this_cpu_has_cap(ARM64_WORKAROUND_1418040))
return;
- val = read_sysreg(cntkctl_el1);
-
- if (!next32)
- val |= ARCH_TIMER_USR_VCT_ACCESS_EN;
+ if (is_compat_thread(task_thread_info(next)))
+ sysreg_clear_set(cntkctl_el1, ARCH_TIMER_USR_VCT_ACCESS_EN, 0);
else
- val &= ~ARCH_TIMER_USR_VCT_ACCESS_EN;
+ sysreg_clear_set(cntkctl_el1, 0, ARCH_TIMER_USR_VCT_ACCESS_EN);
+}
- write_sysreg(val, cntkctl_el1);
+static void erratum_1418040_new_exec(void)
+{
+ preempt_disable();
+ erratum_1418040_thread_switch(current);
+ preempt_enable();
}
/*
@@ -560,7 +552,7 @@ __notrace_funcgraph struct task_struct *__switch_to(struct task_struct *prev,
entry_task_switch(next);
uao_thread_switch(next);
ssbs_thread_switch(next);
- erratum_1418040_thread_switch(prev, next);
+ erratum_1418040_thread_switch(next);
/*
* Complete any pending TLB or cache maintenance on this CPU in case
@@ -619,6 +611,7 @@ void arch_setup_new_exec(void)
current->mm->context.flags = is_compat_task() ? MMCF_AARCH32 : 0;
ptrauth_thread_init_user(current);
+ erratum_1418040_new_exec();
}
#ifdef CONFIG_ARM64_TAGGED_ADDR_ABI
On Thu, Jan 27, 2022 at 1:44 PM Martin Faltesek <mfaltesek(a)google.com> wrote:
+stable@
>
> +gregkh(a)linuxfoundation.org
>
> ddbcd0c58a6a is upstream fix for this and needs to be applied to affected stable releases.
>
My little tool tells me that this is only needed in v5.10.y.
Guenter
> On Thu, Jan 27, 2022 at 3:21 PM Martin Faltesek <mfaltesek(a)google.com> wrote:
>>
>> Hi Bryan,
>>
>> I was merging this patch into our code base that was in 5.10.94:
>>
>> commit eeefa2eae8fc82ad757a2241b9f82ac33e99e6b4
>> Author: Bryan O'Donoghue <bryan.odonoghue(a)linaro.org>
>> AuthorDate: Fri Feb 5 19:11:49 2021 +0100
>> Commit: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
>> CommitDate: Thu Jan 27 10:53:51 2022 +0100
>>
>> media: venus: core, venc, vdec: Fix probe dependency error
>>
>>
>>
>> @@ -364,11 +365,14 @@ static int venus_remove(struct platform_device *pdev)
>> pm_runtime_disable(dev);
>>
>> if (pm_ops->core_put)
>> - pm_ops->core_put(dev);
>> + pm_ops->core_put(core);
>> +
>> + v4l2_device_unregister(&core->v4l2_dev);
>>
>> hfi_destroy(core);
>>
>> v4l2_device_unregister(&core->v4l2_dev);
>> +
>> mutex_destroy(&core->pm_lock);
>> mutex_destroy(&core->lock);
>> venus_dbgfs_deinit(core);
>>
>> This section introduces unregistering twice, before and after destroy.
>> I think there must be a patch that fixed this since this error does
>> not exist in linus's tree.
>> I'm guessing there might be a missing patch you'd want to grab.
>>
>> Can you comment on this?
>>
>> Thanks,
>>
>> Martin
Stopping tasklet and hrtimer rely on the active state of tasklet and
hrtimer sequentially in bcm_remove_op(), the op object will be freed
if they are all unactive. Assume the hrtimer timeout is short, the
hrtimer cb has been excuted after tasklet conditional judgment which
must be false after last round tasklet_kill() and before condition
hrtimer_active(), it is false when execute to hrtimer_active(). Bug
is triggerd, because the stopping action is end and the op object
will be freed, but the tasklet is scheduled. The resources of the op
object will occur UAF bug.
Move hrtimer_cancel() behind tasklet_kill() and switch 'while () {...}'
to 'do {...} while ()' to fix the op UAF problem.
Fixes: a06393ed0316 ("can: bcm: fix hrtimer/tasklet termination in bcm op removal")
Reported-by: syzbot+5ca851459ed04c778d1d(a)syzkaller.appspotmail.com
Cc: stable(a)vger.kernel.org
Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com>
---
net/can/bcm.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/net/can/bcm.c b/net/can/bcm.c
index 369326715b9c..bfb507223468 100644
--- a/net/can/bcm.c
+++ b/net/can/bcm.c
@@ -761,21 +761,21 @@ static struct bcm_op *bcm_find_op(struct list_head *ops,
static void bcm_remove_op(struct bcm_op *op)
{
if (op->tsklet.func) {
- while (test_bit(TASKLET_STATE_SCHED, &op->tsklet.state) ||
- test_bit(TASKLET_STATE_RUN, &op->tsklet.state) ||
- hrtimer_active(&op->timer)) {
- hrtimer_cancel(&op->timer);
+ do {
tasklet_kill(&op->tsklet);
- }
+ hrtimer_cancel(&op->timer);
+ } while (test_bit(TASKLET_STATE_SCHED, &op->tsklet.state) ||
+ test_bit(TASKLET_STATE_RUN, &op->tsklet.state) ||
+ hrtimer_active(&op->timer));
}
if (op->thrtsklet.func) {
- while (test_bit(TASKLET_STATE_SCHED, &op->thrtsklet.state) ||
- test_bit(TASKLET_STATE_RUN, &op->thrtsklet.state) ||
- hrtimer_active(&op->thrtimer)) {
- hrtimer_cancel(&op->thrtimer);
+ do {
tasklet_kill(&op->thrtsklet);
- }
+ hrtimer_cancel(&op->thrtimer);
+ } while (test_bit(TASKLET_STATE_SCHED, &op->thrtsklet.state) ||
+ test_bit(TASKLET_STATE_RUN, &op->thrtsklet.state) ||
+ hrtimer_active(&op->thrtimer));
}
if ((op->frames) && (op->frames != &op->sframe))
--
2.25.1
I'm announcing the release of the 5.4.175 kernel.
All users of the 5.4 kernel series must upgrade.
The updated 5.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.4.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Makefile | 2
arch/arm/boot/dts/bcm283x.dtsi | 1
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 3
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 10 +
drivers/gpu/drm/i915/gt/intel_gt.c | 99 ++++++++++
drivers/gpu/drm/i915/gt/intel_gt.h | 2
drivers/gpu/drm/i915/gt/intel_gt_types.h | 2
drivers/gpu/drm/i915/i915_reg.h | 11 +
drivers/gpu/drm/i915/i915_vma.c | 4
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 5
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 33 +--
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2
drivers/mmc/host/sdhci-esdhc-imx.c | 3
drivers/pinctrl/bcm/pinctrl-bcm2835.c | 209 +++++++++++++++++++----
fs/select.c | 63 +++---
kernel/rcu/tree.c | 7
17 files changed, 366 insertions(+), 92 deletions(-)
Florian Fainelli (2):
pinctrl: bcm2835: Match BCM7211 compatible string
pinctrl: bcm2835: Add support for wake-up interrupts
Greg Kroah-Hartman (1):
Linux 5.4.175
Jan Kara (1):
select: Fix indefinitely sleeping task in poll_schedule_timeout()
Mathias Krause (1):
drm/vmwgfx: Fix stale file descriptors on failed usercopy
Paul E. McKenney (1):
rcu: Tighten rcu_advance_cbs_nowake() checks
Phil Elwell (2):
pinctrl: bcm2835: Change init order for gpio hogs
ARM: dts: gpio-ranges property is now required
Stefan Wahren (3):
pinctrl: bcm2835: Drop unused define
pinctrl: bcm2835: Refactor platform data
pinctrl: bcm2835: Add support for all GPIOs on BCM2711
Tim Harvey (1):
mmc: sdhci-esdhc-imx: disable CMDQ support
Tvrtko Ursulin (1):
drm/i915: Flush TLBs before releasing backing store
I'm announcing the release of the 4.19.227 kernel.
All users of the 4.19 kernel series must upgrade.
The updated 4.19.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.19.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Makefile | 2
drivers/gpu/drm/i915/i915_drv.h | 2
drivers/gpu/drm/i915/i915_gem.c | 83 ++++++++++++++++++++++++++++++++
drivers/gpu/drm/i915/i915_gem_object.h | 1
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/i915_vma.c | 4 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 5 -
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 34 ++++++-------
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2
fs/select.c | 63 ++++++++++++------------
net/bridge/br_device.c | 2
12 files changed, 153 insertions(+), 53 deletions(-)
Greg Kroah-Hartman (1):
Linux 4.19.227
Jan Kara (1):
select: Fix indefinitely sleeping task in poll_schedule_timeout()
Mathias Krause (1):
drm/vmwgfx: Fix stale file descriptors on failed usercopy
Nikolay Aleksandrov (1):
net: bridge: clear bridge's private skb space on xmit
Tvrtko Ursulin (1):
drm/i915: Flush TLBs before releasing backing store
I'm announcing the release of the 4.14.264 kernel.
All users of the 4.14 kernel series must upgrade.
The updated 4.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.14.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Makefile | 2
drivers/gpu/drm/i915/i915_drv.h | 2
drivers/gpu/drm/i915/i915_gem.c | 84 +++++++++++++++++++++++++++++++-
drivers/gpu/drm/i915/i915_gem_object.h | 1
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/i915_vma.c | 4 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 5 -
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 34 ++++++------
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2
net/can/bcm.c | 20 +++----
11 files changed, 128 insertions(+), 34 deletions(-)
Greg Kroah-Hartman (1):
Linux 4.14.264
Mathias Krause (1):
drm/vmwgfx: Fix stale file descriptors on failed usercopy
Tvrtko Ursulin (1):
drm/i915: Flush TLBs before releasing backing store
Ziyang Xuan (1):
can: bcm: fix UAF of bcm op
I'm announcing the release of the 4.9.299 kernel.
All users of the 4.9 kernel series must upgrade.
The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Documentation/virtual/kvm/mmu.txt | 4 -
Makefile | 2
arch/arm/Kconfig.debug | 44 +++++++++-----
arch/x86/kvm/paging_tmpl.h | 44 +++++++++-----
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/i915_gem.c | 72 ++++++++++++++++++++++++
drivers/gpu/drm/i915/i915_gem_gtt.c | 4 +
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/media/firewire/firedtv-avc.c | 14 +++-
drivers/media/firewire/firedtv-ci.c | 2
drivers/staging/android/ion/ion-ioctl.c | 96 ++++++++++++++++++++++++++++----
drivers/staging/android/ion/ion.c | 19 ++++--
drivers/staging/android/ion/ion.h | 4 +
drivers/staging/android/ion/ion_priv.h | 4 +
fs/nfs/nfs4client.c | 82 ++++++++++++++-------------
lib/Kconfig.debug | 6 +-
16 files changed, 310 insertions(+), 98 deletions(-)
Dan Carpenter (1):
media: firewire: firedtv-avc: fix a buffer overflow in avc_ca_pmt()
Daniel Rosenberg (2):
ion: Fix use after free during ION_IOC_ALLOC
ion: Protect kref from userspace manipulation
Greg Kroah-Hartman (1):
Linux 4.9.299
Lai Jiangshan (1):
KVM: X86: MMU: Use the correct inherited permissions to get shadow page
Lee Jones (1):
ion: Do not 'put' ION handle until after its final use
Paolo Bonzini (1):
KVM: nVMX: fix EPT permissions as reported in exit qualification
Stefan Agner (1):
ARM: 8800/1: use choice for kernel unwinders
Trond Myklebust (1):
NFSv4: Initialise connection to the server in nfs4_alloc_client()
Tvrtko Ursulin (1):
drm/i915: Flush TLBs before releasing backing store
I'm announcing the release of the 4.4.301 kernel.
All users of the 4.4 kernel series must upgrade.
The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.4.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Makefile | 2
drivers/gpu/drm/i915/i915_drv.h | 5 ++
drivers/gpu/drm/i915/i915_gem.c | 89 ++++++++++++++++++++++++++++++++++++
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 +
drivers/gpu/drm/i915/i915_reg.h | 6 ++
5 files changed, 104 insertions(+), 1 deletion(-)
Greg Kroah-Hartman (1):
Linux 4.4.301
Tvrtko Ursulin (1):
drm/i915: Flush TLBs before releasing backing store
On Fri, Jan 28, 2022 at 10:17:55PM +0300, Sergey Shtylyov wrote:
> My experience tells they do.
Let's ask them:
@stable folks, do you guys take patches based only on Fixes: tags
nowadays or you still require CC:stable to be present in the commit
message?
> See my other mail...
Which other mail?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
This is the start of the stable review cycle for the 4.4.301 release.
There are 1 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 Sat, 29 Jan 2022 18:02:51 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.301-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.4.301-rc1
Tvrtko Ursulin <tvrtko.ursulin(a)intel.com>
drm/i915: Flush TLBs before releasing backing store
-------------
Diffstat:
Makefile | 4 +-
drivers/gpu/drm/i915/i915_drv.h | 5 +++
drivers/gpu/drm/i915/i915_gem.c | 89 +++++++++++++++++++++++++++++++++++++
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ++
drivers/gpu/drm/i915/i915_reg.h | 6 +++
5 files changed, 105 insertions(+), 2 deletions(-)
This is the start of the stable review cycle for the 4.9.299 release.
There are 9 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 Sat, 29 Jan 2022 18:02:51 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.299-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.9.299-rc1
Lee Jones <lee.jones(a)linaro.org>
ion: Do not 'put' ION handle until after its final use
Daniel Rosenberg <drosen(a)google.com>
ion: Protect kref from userspace manipulation
Daniel Rosenberg <drosen(a)google.com>
ion: Fix use after free during ION_IOC_ALLOC
Stefan Agner <stefan(a)agner.ch>
ARM: 8800/1: use choice for kernel unwinders
Lai Jiangshan <laijs(a)linux.alibaba.com>
KVM: X86: MMU: Use the correct inherited permissions to get shadow page
Paolo Bonzini <pbonzini(a)redhat.com>
KVM: nVMX: fix EPT permissions as reported in exit qualification
Trond Myklebust <trond.myklebust(a)hammerspace.com>
NFSv4: Initialise connection to the server in nfs4_alloc_client()
Dan Carpenter <dan.carpenter(a)oracle.com>
media: firewire: firedtv-avc: fix a buffer overflow in avc_ca_pmt()
Tvrtko Ursulin <tvrtko.ursulin(a)intel.com>
drm/i915: Flush TLBs before releasing backing store
-------------
Diffstat:
Documentation/virtual/kvm/mmu.txt | 4 +-
Makefile | 4 +-
arch/arm/Kconfig.debug | 44 +++++++++------
arch/x86/kvm/paging_tmpl.h | 44 +++++++++------
drivers/gpu/drm/i915/i915_drv.h | 5 +-
drivers/gpu/drm/i915/i915_gem.c | 72 +++++++++++++++++++++++++
drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++
drivers/gpu/drm/i915/i915_reg.h | 6 +++
drivers/media/firewire/firedtv-avc.c | 14 +++--
drivers/media/firewire/firedtv-ci.c | 2 +
drivers/staging/android/ion/ion-ioctl.c | 96 +++++++++++++++++++++++++++++----
drivers/staging/android/ion/ion.c | 19 +++++--
drivers/staging/android/ion/ion.h | 4 ++
drivers/staging/android/ion/ion_priv.h | 4 ++
fs/nfs/nfs4client.c | 82 ++++++++++++++--------------
lib/Kconfig.debug | 6 +--
16 files changed, 311 insertions(+), 99 deletions(-)
When HCE(Host Controller Error) is set, it means an internal
error condition has been detected. Software needs to re-initialize
the HC, so add this check in xhci resume.
Cc: stable(a)vger.kernel.org
Signed-off-by: Puma Hsu <pumahsu(a)google.com>
---
v2: Follow Sergey Shtylyov <s.shtylyov(a)omp.ru>'s comment.
v3: Add stable(a)vger.kernel.org for stable release.
v4: Refine the commit message.
v5: Add a debug log. Follow Mathias Nyman <mathias.nyman(a)linux.intel.com>'s comment.
drivers/usb/host/xhci.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index dc357cabb265..41f594f0f73f 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1146,8 +1146,10 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
temp = readl(&xhci->op_regs->status);
}
- /* If restore operation fails, re-initialize the HC during resume */
- if ((temp & STS_SRE) || hibernated) {
+ /* If restore operation fails or HC error is detected, re-initialize the HC during resume */
+ if ((temp & (STS_SRE | STS_HCE)) || hibernated) {
+ xhci_warn(xhci, "re-initialize HC during resume, USBSTS:%s\n",
+ xhci_decode_usbsts(str, temp));
if ((xhci->quirks & XHCI_COMP_MODE_QUIRK) &&
!(xhci_all_ports_seen_u0(xhci))) {
--
2.34.1.703.g22d0c6ccf7-goog
This is the start of the stable review cycle for the 4.19.227 release.
There are 3 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 Sat, 29 Jan 2022 18:02:51 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.227-r…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.19.227-rc1
Jan Kara <jack(a)suse.cz>
select: Fix indefinitely sleeping task in poll_schedule_timeout()
Nikolay Aleksandrov <nikolay(a)cumulusnetworks.com>
net: bridge: clear bridge's private skb space on xmit
Tvrtko Ursulin <tvrtko.ursulin(a)intel.com>
drm/i915: Flush TLBs before releasing backing store
-------------
Diffstat:
Makefile | 4 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_gem.c | 83 ++++++++++++++++++++++++++++++++++
drivers/gpu/drm/i915/i915_gem_object.h | 1 +
drivers/gpu/drm/i915/i915_reg.h | 6 +++
drivers/gpu/drm/i915/i915_vma.c | 4 ++
fs/select.c | 63 ++++++++++++++------------
net/bridge/br_device.c | 2 +
8 files changed, 133 insertions(+), 32 deletions(-)
Quoting Ariadne Conill:
"In several other operating systems, it is a hard requirement that the
first argument to execve(2) be the name of a program, thus prohibiting
a scenario where argc < 1. POSIX 2017 also recommends this behaviour,
but it is not an explicit requirement[1]:
The argument arg0 should point to a filename string that is
associated with the process being started by one of the exec
functions.
...
Interestingly, Michael Kerrisk opened an issue about this in 2008[2],
but there was no consensus to support fixing this issue then.
Hopefully now that CVE-2021-4034 shows practical exploitative use[3]
of this bug in a shellcode, we can reconsider."
An examination of existing[4] users of execve(..., NULL, NULL) shows
mostly test code, or example rootkit code. While rejecting a NULL argv
would be preferred, it looks like the main cause of userspace confusion
is an assumption that argc >= 1, and buggy programs may skip argv[0]
when iterating. To protect against userspace bugs of this nature, insert
an extra NULL pointer in argv when argc == 0, so that argv[1] != envp[0].
Note that this is only done in the argc == 0 case because some userspace
programs expect to find envp at exactly argv[argc]. The overlap of these
two misguided assumptions is believed to be zero.
[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html
[2] https://bugzilla.kernel.org/show_bug.cgi?id=8408
[3] https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt
[4] https://codesearch.debian.net/search?q=execve%5C+*%5C%28%5B%5E%2C%5D%2B%2C+…
Reported-by: Ariadne Conill <ariadne(a)dereferenced.org>
Reported-by: Michael Kerrisk <mtk.manpages(a)gmail.com>
Cc: Matthew Wilcox <willy(a)infradead.org>
Cc: Christian Brauner <brauner(a)kernel.org>
Cc: Rich Felker <dalias(a)libc.org>
Cc: Eric Biederman <ebiederm(a)xmission.com>
Cc: Alexander Viro <viro(a)zeniv.linux.org.uk>
Cc: linux-fsdevel(a)vger.kernel.org
Cc: stable(a)vger.kernel.org
Signed-off-by: Kees Cook <keescook(a)chromium.org>
---
fs/binfmt_elf.c | 10 +++++++++-
fs/exec.c | 7 ++++++-
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 605017eb9349..e456c48658ad 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -297,7 +297,8 @@ create_elf_tables(struct linux_binprm *bprm, const struct elfhdr *exec,
ei_index = elf_info - (elf_addr_t *)mm->saved_auxv;
sp = STACK_ADD(p, ei_index);
- items = (argc + 1) + (envc + 1) + 1;
+ /* Make room for extra pointer when argc == 0. See below. */
+ items = (min(argc, 1) + 1) + (envc + 1) + 1;
bprm->p = STACK_ROUND(sp, items);
/* Point sp at the lowest address on the stack */
@@ -326,6 +327,13 @@ create_elf_tables(struct linux_binprm *bprm, const struct elfhdr *exec,
/* Populate list of argv pointers back to argv strings. */
p = mm->arg_end = mm->arg_start;
+ /*
+ * Include an extra NULL pointer in argv when argc == 0 so
+ * that argv[1] != envp[0] to help userspace programs from
+ * mishandling argc == 0. See fs/exec.c bprm_stack_limits().
+ */
+ if (argc == 0 && put_user(0, sp++))
+ return -EFAULT;
while (argc-- > 0) {
size_t len;
if (put_user((elf_addr_t)p, sp++))
diff --git a/fs/exec.c b/fs/exec.c
index 79f2c9483302..0b36384e55b1 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -495,8 +495,13 @@ static int bprm_stack_limits(struct linux_binprm *bprm)
* the stack. They aren't stored until much later when we can't
* signal to the parent that the child has run out of stack space.
* Instead, calculate it here so it's possible to fail gracefully.
+ *
+ * In the case of argc < 1, make sure there is a NULL pointer gap
+ * between argv and envp to ensure confused userspace programs don't
+ * start processing from argv[1], thinking argc can never be 0,
+ * to block them from walking envp by accident. See fs/binfmt_elf.c.
*/
- ptr_size = (bprm->argc + bprm->envc) * sizeof(void *);
+ ptr_size = (min(bprm->argc, 1) + bprm->envc) * sizeof(void *);
if (limit <= ptr_size)
return -E2BIG;
limit -= ptr_size;
--
2.30.2
From: Peter Collingbourne <pcc(a)google.com>
Subject: mm, kasan: use compare-exchange operation to set KASAN page tag
It has been reported that the tag setting operation on newly-allocated
pages can cause the page flags to be corrupted when performed concurrently
with other flag updates as a result of the use of non-atomic operations.
Fix the problem by using a compare-exchange loop to update the tag.
Link: https://lkml.kernel.org/r/20220120020148.1632253-1-pcc@google.com
Link: https://linux-review.googlesource.com/id/I456b24a2b9067d93968d43b4bb3351c0c…
Fixes: 2813b9c02962 ("kasan, mm, arm64: tag non slab memory allocated via pagealloc")
Signed-off-by: Peter Collingbourne <pcc(a)google.com>
Reviewed-by: Andrey Konovalov <andreyknvl(a)gmail.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
include/linux/mm.h | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
--- a/include/linux/mm.h~mm-use-compare-exchange-operation-to-set-kasan-page-tag
+++ a/include/linux/mm.h
@@ -1506,11 +1506,18 @@ static inline u8 page_kasan_tag(const st
static inline void page_kasan_tag_set(struct page *page, u8 tag)
{
- if (kasan_enabled()) {
- tag ^= 0xff;
- page->flags &= ~(KASAN_TAG_MASK << KASAN_TAG_PGSHIFT);
- page->flags |= (tag & KASAN_TAG_MASK) << KASAN_TAG_PGSHIFT;
- }
+ unsigned long old_flags, flags;
+
+ if (!kasan_enabled())
+ return;
+
+ tag ^= 0xff;
+ old_flags = READ_ONCE(page->flags);
+ do {
+ flags = old_flags;
+ flags &= ~(KASAN_TAG_MASK << KASAN_TAG_PGSHIFT);
+ flags |= (tag & KASAN_TAG_MASK) << KASAN_TAG_PGSHIFT;
+ } while (unlikely(!try_cmpxchg(&page->flags, &old_flags, flags)));
}
static inline void page_kasan_tag_reset(struct page *page)
_
This is the start of the stable review cycle for the 5.16.4 release.
There are 9 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 Sat, 29 Jan 2022 18:02:51 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.16.4-rc1…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.16.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 5.16.4-rc1
Russell King <russell.king(a)oracle.com>
arm64/bpf: Remove 128MB limit for BPF JIT programs
Jan Kara <jack(a)suse.cz>
select: Fix indefinitely sleeping task in poll_schedule_timeout()
Paul E. McKenney <paulmck(a)kernel.org>
rcu: Tighten rcu_advance_cbs_nowake() checks
Shakeel Butt <shakeelb(a)google.com>
memcg: better bounds on the memcg stats updates
Manish Chopra <manishc(a)marvell.com>
bnx2x: Invalidate fastpath HSI version for VFs
Manish Chopra <manishc(a)marvell.com>
bnx2x: Utilize firmware 7.13.21.0
Pavel Begunkov <asml.silence(a)gmail.com>
io_uring: fix not released cached task refs
Mario Limonciello <mario.limonciello(a)amd.com>
drm/amd/display: reset dcn31 SMU mailbox on failures
Tvrtko Ursulin <tvrtko.ursulin(a)intel.com>
drm/i915: Flush TLBs before releasing backing store
-------------
Diffstat:
Makefile | 4 +-
arch/arm64/include/asm/extable.h | 9 --
arch/arm64/include/asm/memory.h | 5 +-
arch/arm64/kernel/traps.c | 2 +-
arch/arm64/mm/ptdump.c | 2 -
arch/arm64/net/bpf_jit_comp.c | 7 +-
.../drm/amd/display/dc/clk_mgr/dcn31/dcn31_smu.c | 6 ++
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 1 +
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 10 ++
drivers/gpu/drm/i915/gt/intel_gt.c | 102 +++++++++++++++++++++
drivers/gpu/drm/i915/gt/intel_gt.h | 2 +
drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 +
drivers/gpu/drm/i915/i915_reg.h | 11 +++
drivers/gpu/drm/i915/i915_vma.c | 3 +
drivers/gpu/drm/i915/intel_uncore.c | 26 +++++-
drivers/gpu/drm/i915/intel_uncore.h | 2 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 11 ++-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 6 +-
.../net/ethernet/broadcom/bnx2x/bnx2x_fw_defs.h | 2 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h | 3 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 75 ++++++++++-----
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 13 ++-
fs/io_uring.c | 34 ++++---
fs/select.c | 63 +++++++------
kernel/rcu/tree.c | 7 +-
mm/memcontrol.c | 20 ++--
26 files changed, 318 insertions(+), 110 deletions(-)
This is the start of the stable review cycle for the 5.15.18 release.
There are 12 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 Sat, 29 Jan 2022 18:02:51 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.18-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 5.15.18-rc1
Russell King <russell.king(a)oracle.com>
arm64/bpf: Remove 128MB limit for BPF JIT programs
Harry Wentland <harry.wentland(a)amd.com>
drm/amdgpu: Use correct VIEWPORT_DIMENSION for DCN2
Jan Kara <jack(a)suse.cz>
select: Fix indefinitely sleeping task in poll_schedule_timeout()
Paul E. McKenney <paulmck(a)kernel.org>
rcu: Tighten rcu_advance_cbs_nowake() checks
Shakeel Butt <shakeelb(a)google.com>
memcg: better bounds on the memcg stats updates
Shakeel Butt <shakeelb(a)google.com>
memcg: unify memcg stat flushing
Shakeel Butt <shakeelb(a)google.com>
memcg: flush stats only if updated
Manish Chopra <manishc(a)marvell.com>
bnx2x: Invalidate fastpath HSI version for VFs
Manish Chopra <manishc(a)marvell.com>
bnx2x: Utilize firmware 7.13.21.0
Pavel Begunkov <asml.silence(a)gmail.com>
io_uring: fix not released cached task refs
Mario Limonciello <mario.limonciello(a)amd.com>
drm/amd/display: reset dcn31 SMU mailbox on failures
Tvrtko Ursulin <tvrtko.ursulin(a)intel.com>
drm/i915: Flush TLBs before releasing backing store
-------------
Diffstat:
Makefile | 4 +-
arch/arm64/include/asm/extable.h | 9 --
arch/arm64/include/asm/memory.h | 5 +-
arch/arm64/kernel/traps.c | 2 +-
arch/arm64/mm/extable.c | 13 ++-
arch/arm64/mm/ptdump.c | 2 -
arch/arm64/net/bpf_jit_comp.c | 7 +-
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 14 ++-
.../drm/amd/display/dc/clk_mgr/dcn31/dcn31_smu.c | 6 ++
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 1 +
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 10 ++
drivers/gpu/drm/i915/gt/intel_gt.c | 102 +++++++++++++++++++++
drivers/gpu/drm/i915/gt/intel_gt.h | 2 +
drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 +
drivers/gpu/drm/i915/i915_reg.h | 11 +++
drivers/gpu/drm/i915/i915_vma.c | 3 +
drivers/gpu/drm/i915/intel_uncore.c | 26 +++++-
drivers/gpu/drm/i915/intel_uncore.h | 2 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 11 ++-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 6 +-
.../net/ethernet/broadcom/bnx2x/bnx2x_fw_defs.h | 2 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h | 3 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 75 ++++++++++-----
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 13 ++-
fs/io_uring.c | 34 ++++---
fs/select.c | 63 +++++++------
kernel/rcu/tree.c | 7 +-
mm/memcontrol.c | 99 ++++++++++++++------
28 files changed, 396 insertions(+), 138 deletions(-)
This is the start of the stable review cycle for the 5.10.95 release.
There are 6 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 Sat, 29 Jan 2022 18:02:51 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.95-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 5.10.95-rc1
Jan Kara <jack(a)suse.cz>
select: Fix indefinitely sleeping task in poll_schedule_timeout()
David Matlack <dmatlack(a)google.com>
KVM: x86/mmu: Fix write-protection of PTs mapped by the TDP MMU
Paul E. McKenney <paulmck(a)kernel.org>
rcu: Tighten rcu_advance_cbs_nowake() checks
Manish Chopra <manishc(a)marvell.com>
bnx2x: Invalidate fastpath HSI version for VFs
Manish Chopra <manishc(a)marvell.com>
bnx2x: Utilize firmware 7.13.21.0
Tvrtko Ursulin <tvrtko.ursulin(a)intel.com>
drm/i915: Flush TLBs before releasing backing store
-------------
Diffstat:
Makefile | 4 +-
arch/x86/kvm/mmu/tdp_mmu.c | 6 +-
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 1 +
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 10 ++
drivers/gpu/drm/i915/gt/intel_gt.c | 102 +++++++++++++++++++++
drivers/gpu/drm/i915/gt/intel_gt.h | 2 +
drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 +
drivers/gpu/drm/i915/i915_reg.h | 11 +++
drivers/gpu/drm/i915/i915_vma.c | 3 +
drivers/gpu/drm/i915/intel_uncore.c | 26 +++++-
drivers/gpu/drm/i915/intel_uncore.h | 2 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 11 ++-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 6 +-
.../net/ethernet/broadcom/bnx2x/bnx2x_fw_defs.h | 2 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h | 3 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 75 ++++++++++-----
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 13 ++-
fs/select.c | 63 +++++++------
kernel/rcu/tree.c | 7 +-
19 files changed, 277 insertions(+), 72 deletions(-)
This is the start of the stable review cycle for the 5.4.175 release.
There are 11 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 Sat, 29 Jan 2022 18:02:51 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.175-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 5.4.175-rc1
Jan Kara <jack(a)suse.cz>
select: Fix indefinitely sleeping task in poll_schedule_timeout()
Tim Harvey <tharvey(a)gateworks.com>
mmc: sdhci-esdhc-imx: disable CMDQ support
Phil Elwell <phil(a)raspberrypi.com>
ARM: dts: gpio-ranges property is now required
Phil Elwell <phil(a)raspberrypi.com>
pinctrl: bcm2835: Change init order for gpio hogs
Florian Fainelli <f.fainelli(a)gmail.com>
pinctrl: bcm2835: Add support for wake-up interrupts
Florian Fainelli <f.fainelli(a)gmail.com>
pinctrl: bcm2835: Match BCM7211 compatible string
Stefan Wahren <stefan.wahren(a)i2se.com>
pinctrl: bcm2835: Add support for all GPIOs on BCM2711
Stefan Wahren <stefan.wahren(a)i2se.com>
pinctrl: bcm2835: Refactor platform data
Stefan Wahren <stefan.wahren(a)i2se.com>
pinctrl: bcm2835: Drop unused define
Paul E. McKenney <paulmck(a)kernel.org>
rcu: Tighten rcu_advance_cbs_nowake() checks
Tvrtko Ursulin <tvrtko.ursulin(a)intel.com>
drm/i915: Flush TLBs before releasing backing store
-------------
Diffstat:
Makefile | 4 +-
arch/arm/boot/dts/bcm283x.dtsi | 1 +
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 3 +
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 10 ++
drivers/gpu/drm/i915/gt/intel_gt.c | 99 +++++++++++
drivers/gpu/drm/i915/gt/intel_gt.h | 2 +
drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 +
drivers/gpu/drm/i915/i915_reg.h | 11 ++
drivers/gpu/drm/i915/i915_vma.c | 4 +
drivers/mmc/host/sdhci-esdhc-imx.c | 3 +-
drivers/pinctrl/bcm/pinctrl-bcm2835.c | 209 +++++++++++++++++++----
fs/select.c | 63 +++----
kernel/rcu/tree.c | 7 +-
13 files changed, 346 insertions(+), 72 deletions(-)
Dear Friend,
I know that this mail will come to you as a surprise as we have never
met before, but need not to worry as I am contacting you independently
of my investigation and no one is informed of this communication.
I need your urgent assistance in transferring the sum of $11.3million
immediately to your private account.The money has been here in our
Bank lying dormant for years now without anybody coming for the claim of it.
I want to release the money to you as the relative to our deceased
customer (the account owner) who died a long with his supposed NEXT OF
KIN since 16th October 2005. The Banking laws here does not allow such
money to stay more than 16 years, because the money will be recalled
to the Bank treasury account as unclaimed fund.
By indicating your interest I will send you the full details on how
the business will be executed.
Please respond urgently and delete if you are not interested.
Best Regards,
Mr. Duna Wattara.
From: D Scott Phillips <scott(a)os.amperecomputing.com>
commit 38e0257e0e6f4fef2aa2966b089b56a8b1cfb75c upstream.
The erratum 1418040 workaround enables CNTVCT_EL1 access trapping in EL0
when executing compat threads. The workaround is applied when switching
between tasks, but the need for the workaround could also change at an
exec(), when a non-compat task execs a compat binary or vice versa. Apply
the workaround in arch_setup_new_exec().
This leaves a small window of time between SET_PERSONALITY and
arch_setup_new_exec where preemption could occur and confuse the old
workaround logic that compares TIF_32BIT between prev and next. Instead, we
can just read cntkctl to make sure it's in the state that the next task
needs. I measured cntkctl read time to be about the same as a mov from a
general-purpose register on N1. Update the workaround logic to examine the
current value of cntkctl instead of the previous task's compat state.
Fixes: d49f7d7376d0 ("arm64: Move handling of erratum 1418040 into C code")
Cc: <stable(a)vger.kernel.org> # 5.9.x
Signed-off-by: D Scott Phillips <scott(a)os.amperecomputing.com>
Reviewed-by: Marc Zyngier <maz(a)kernel.org>
Link: https://lore.kernel.org/r/20211220234114.3926-1-scott@os.amperecomputing.com
Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com>
---
arch/arm64/kernel/process.c | 39 +++++++++++++++----------------------
1 file changed, 16 insertions(+), 23 deletions(-)
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index f61ef46ebff7..d07fbc21f14c 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -500,34 +500,26 @@ static void entry_task_switch(struct task_struct *next)
/*
* ARM erratum 1418040 handling, affecting the 32bit view of CNTVCT.
- * Assuming the virtual counter is enabled at the beginning of times:
- *
- * - disable access when switching from a 64bit task to a 32bit task
- * - enable access when switching from a 32bit task to a 64bit task
+ * Ensure access is disabled when switching to a 32bit task, ensure
+ * access is enabled when switching to a 64bit task.
*/
-static void erratum_1418040_thread_switch(struct task_struct *prev,
- struct task_struct *next)
+static void erratum_1418040_thread_switch(struct task_struct *next)
{
- bool prev32, next32;
- u64 val;
-
- if (!IS_ENABLED(CONFIG_ARM64_ERRATUM_1418040))
- return;
-
- prev32 = is_compat_thread(task_thread_info(prev));
- next32 = is_compat_thread(task_thread_info(next));
-
- if (prev32 == next32 || !this_cpu_has_cap(ARM64_WORKAROUND_1418040))
+ if (!IS_ENABLED(CONFIG_ARM64_ERRATUM_1418040) ||
+ !this_cpu_has_cap(ARM64_WORKAROUND_1418040))
return;
- val = read_sysreg(cntkctl_el1);
-
- if (!next32)
- val |= ARCH_TIMER_USR_VCT_ACCESS_EN;
+ if (is_compat_thread(task_thread_info(next)))
+ sysreg_clear_set(cntkctl_el1, ARCH_TIMER_USR_VCT_ACCESS_EN, 0);
else
- val &= ~ARCH_TIMER_USR_VCT_ACCESS_EN;
+ sysreg_clear_set(cntkctl_el1, 0, ARCH_TIMER_USR_VCT_ACCESS_EN);
+}
- write_sysreg(val, cntkctl_el1);
+static void erratum_1418040_new_exec(void)
+{
+ preempt_disable();
+ erratum_1418040_thread_switch(current);
+ preempt_enable();
}
/*
@@ -546,7 +538,7 @@ __notrace_funcgraph struct task_struct *__switch_to(struct task_struct *prev,
uao_thread_switch(next);
ptrauth_thread_switch(next);
ssbs_thread_switch(next);
- erratum_1418040_thread_switch(prev, next);
+ erratum_1418040_thread_switch(next);
/*
* Complete any pending TLB or cache maintenance on this CPU in case
@@ -605,6 +597,7 @@ void arch_setup_new_exec(void)
current->mm->context.flags = is_compat_task() ? MMCF_AARCH32 : 0;
ptrauth_thread_init_user(current);
+ erratum_1418040_new_exec();
}
#ifdef CONFIG_ARM64_TAGGED_ADDR_ABI
From: Tom Zanussi <zanussi(a)kernel.org>
During expression parsing, a new expression field is created which
should inherit the properties of the operands, such as size and
is_signed.
is_signed propagation was missing, causing spurious errors with signed
operands. Add it in parse_expr() and parse_unary() to fix the problem.
Link: https://lkml.kernel.org/r/f4dac08742fd7a0920bf80a73c6c44042f5eaa40.16433197…
Cc: stable(a)vger.kernel.org
Fixes: 100719dcef447 ("tracing: Add simple expression support to hist triggers")
Reported-by: Yordan Karadzhov <ykaradzhov(a)vmware.com>
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215513
Signed-off-by: Tom Zanussi <zanussi(a)kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org>
---
kernel/trace/trace_events_hist.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
index b894d68082ea..ada87bfb5bb8 100644
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -2503,6 +2503,8 @@ static struct hist_field *parse_unary(struct hist_trigger_data *hist_data,
(HIST_FIELD_FL_TIMESTAMP | HIST_FIELD_FL_TIMESTAMP_USECS);
expr->fn = hist_field_unary_minus;
expr->operands[0] = operand1;
+ expr->size = operand1->size;
+ expr->is_signed = operand1->is_signed;
expr->operator = FIELD_OP_UNARY_MINUS;
expr->name = expr_str(expr, 0);
expr->type = kstrdup_const(operand1->type, GFP_KERNEL);
@@ -2719,6 +2721,7 @@ static struct hist_field *parse_expr(struct hist_trigger_data *hist_data,
/* The operand sizes should be the same, so just pick one */
expr->size = operand1->size;
+ expr->is_signed = operand1->is_signed;
expr->operator = field_op;
expr->type = kstrdup_const(operand1->type, GFP_KERNEL);
--
2.33.0
From: Xiaoke Wang <xkernel.wang(a)foxmail.com>
kfree() is missing on an error path to free the memory allocated by
kstrdup():
p = param = kstrdup(data->params[i], GFP_KERNEL);
So it is better to free it via kfree(p).
Link: https://lkml.kernel.org/r/tencent_C52895FD37802832A3E5B272D05008866F0A@qq.c…
Cc: stable(a)vger.kernel.org
Fixes: d380dcde9a07c ("tracing: Fix now invalid var_ref_vals assumption in trace action")
Signed-off-by: Xiaoke Wang <xkernel.wang(a)foxmail.com>
Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org>
---
kernel/trace/trace_events_hist.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
index 5e6a988a8a51..cd9610688ddc 100644
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -3935,6 +3935,7 @@ static int trace_action_create(struct hist_trigger_data *hist_data,
var_ref_idx = find_var_ref_idx(hist_data, var_ref);
if (WARN_ON(var_ref_idx < 0)) {
+ kfree(p);
ret = var_ref_idx;
goto err;
}
--
2.33.0
hallo Greg
5.16.4-rc1
compiles, boots and runs on my x86_64
(Intel i5-11400, Fedora 35)
Thanks
Tested-by: Ronald Warsow <rwarsow(a)gmx.de>
regards
Ronald
Hello
I'm "Mrs Mimi Hassan." married to Mr. Hassan( an International
Contractor and Oil Merchant/ jointly in Exposition of Agro Equipment
) who died in Burkina Faso attack, and i was diagnosed of cancer, about
2 years ago,and my husband informed me that he deposited the sum of
(22.3Million USD Only) with a company) in OUAGADOUGOU BURKINA
FASO.I want you to help me to use this money for a charity project before
I pass on, for the Poor, Less-privileged and ORPHANAGES in
your country. Please kindly respond quickly for further details.
thanks
Mrs Mimi Hassan.
We observed an issue with NXP 5.15 LTS kernel that dma_alloc_coherent()
may fail sometimes when there're multiple processes trying to allocate
CMA memory.
This issue can be very easily reproduced on MX6Q SDB board with latest
linux-next kernel by writing a test module creating 16 or 32 threads
allocating random size of CMA memory in parallel at the background.
Or simply enabling CONFIG_CMA_DEBUG, you can see endless of CMA alloc
retries during booting:
[ 1.452124] cma: cma_alloc(): memory range at (ptrval) is busy,retrying
....
(thousands of reties)
NOTE: MX6 has CONFIG_FORCE_MAX_ZONEORDER=14 which means MAX_ORDER is
13 (32M).
The root cause of this issue is that since commit a4efc174b382
("mm/cma.c: remove redundant cma_mutex lock"), CMA supports concurrent
memory allocation.
It's possible that the pageblock process A try to alloc has already
been isolated by the allocation of process B during memory migration.
When there're multi process allocating CMA memory in parallel, it's
likely that other the remain pageblocks may have also been isolated,
then CMA alloc fail finally during the first round of scanning of the
whole available CMA bitmap.
This patchset introduces a retry mechanism to rescan CMA bitmap for -EBUSY
error in case the target pageblock may has been temporarily isolated
by others and released later.
It also improves the CMA allocation performance by trying the next
pageblock during reties rather than looping in the same pageblock
which is in -EBUSY state.
Theoretically, this issue can be easily reproduced on ARMv7 platforms
with big MAX_ORDER/pageblock
e.g. 1G RAM(320M reserved CMA) and 32M pageblock ARM platform:
Page block order: 13
Pages per block: 8192
The following test is based on linux-next: next-20211213.
Without the fix, it's easily fail.
# insmod cma_alloc.ko pnum=16
[ 274.322369] CMA alloc test enter: thread number: 16
[ 274.329948] cpu: 0, pid: 692, index 4 pages 144
[ 274.330143] cpu: 1, pid: 694, index 2 pages 44
[ 274.330359] cpu: 2, pid: 695, index 7 pages 757
[ 274.330760] cpu: 2, pid: 696, index 4 pages 144
[ 274.330974] cpu: 2, pid: 697, index 6 pages 512
[ 274.331223] cpu: 2, pid: 698, index 6 pages 512
[ 274.331499] cpu: 2, pid: 699, index 2 pages 44
[ 274.332228] cpu: 2, pid: 700, index 0 pages 7
[ 274.337421] cpu: 0, pid: 701, index 1 pages 38
[ 274.337618] cpu: 2, pid: 702, index 0 pages 7
[ 274.344669] cpu: 1, pid: 703, index 0 pages 7
[ 274.344807] cpu: 3, pid: 704, index 6 pages 512
[ 274.348269] cpu: 2, pid: 705, index 5 pages 148
[ 274.349490] cma: cma_alloc: reserved: alloc failed, req-size: 38 pages, ret: -16
[ 274.366292] cpu: 1, pid: 706, index 4 pages 144
[ 274.366562] cpu: 0, pid: 707, index 3 pages 128
[ 274.367356] cma: cma_alloc: reserved: alloc failed, req-size: 128 pages, ret: -16
[ 274.367370] cpu: 0, pid: 707, index 3 pages 128 failed
[ 274.371148] cma: cma_alloc: reserved: alloc failed, req-size: 148 pages, ret: -16
[ 274.375348] cma: cma_alloc: reserved: alloc failed, req-size: 144 pages, ret: -16
[ 274.384256] cpu: 2, pid: 708, index 0 pages 7
....
With the fix, 32 threads allocating in parallel can pass overnight
stress test.
root@imx6qpdlsolox:~# insmod cma_alloc.ko pnum=32
[ 112.976809] cma_alloc: loading out-of-tree module taints kernel.
[ 112.984128] CMA alloc test enter: thread number: 32
[ 112.989748] cpu: 2, pid: 707, index 6 pages 512
[ 112.994342] cpu: 1, pid: 708, index 6 pages 512
[ 112.995162] cpu: 0, pid: 709, index 3 pages 128
[ 112.995867] cpu: 2, pid: 710, index 0 pages 7
[ 112.995910] cpu: 3, pid: 711, index 2 pages 44
[ 112.996005] cpu: 3, pid: 712, index 7 pages 757
[ 112.996098] cpu: 3, pid: 713, index 7 pages 757
...
[41877.368163] cpu: 1, pid: 737, index 2 pages 44
[41877.369388] cpu: 1, pid: 736, index 3 pages 128
[41878.486516] cpu: 0, pid: 737, index 2 pages 44
[41878.486515] cpu: 2, pid: 739, index 4 pages 144
[41878.486622] cpu: 1, pid: 736, index 3 pages 128
[41878.486948] cpu: 2, pid: 735, index 7 pages 757
[41878.487279] cpu: 2, pid: 738, index 4 pages 144
[41879.526603] cpu: 1, pid: 739, index 3 pages 128
[41879.606491] cpu: 2, pid: 737, index 3 pages 128
[41879.606550] cpu: 0, pid: 736, index 0 pages 7
[41879.612271] cpu: 2, pid: 738, index 4 pages 144
...
v1:
https://patchwork.kernel.org/project/linux-mm/cover/20211215080242.3034856-…
Dong Aisheng (2):
mm: cma: fix allocation may fail sometimes
mm: cma: try next MAX_ORDER_NR_PAGES during retry
mm/cma.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
--
2.25.1
From: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Currently we allow DRRS on IVB PCH ports, but we're missing a
few programming steps meaning it is guaranteed to not work.
And on HSW DRRS is not supported on anything but port A ever
as only transcoder EDP has the M2/N2 registers (though I'm
not sure if HSW ever has eDP on any other port).
Starting from BDW all transcoders have the dynamically
reprogrammable M/N registers so DRRS could work on any
port.
Stop initializing DRRS on ports where it cannot possibly work.
Cc: stable(a)vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_drrs.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c b/drivers/gpu/drm/i915/display/intel_drrs.c
index 53f014b4436b..9f673255578e 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.c
+++ b/drivers/gpu/drm/i915/display/intel_drrs.c
@@ -413,6 +413,7 @@ intel_drrs_init(struct intel_connector *connector,
struct drm_display_mode *fixed_mode)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_encoder *encoder = connector->encoder;
struct drm_display_mode *downclock_mode = NULL;
INIT_DELAYED_WORK(&dev_priv->drrs.work, intel_drrs_downclock_work);
@@ -424,6 +425,13 @@ intel_drrs_init(struct intel_connector *connector,
return NULL;
}
+ if ((DISPLAY_VER(dev_priv) < 8 && !HAS_GMCH(dev_priv)) &&
+ encoder->port != PORT_A) {
+ drm_dbg_kms(&dev_priv->drm,
+ "DRRS only supported on eDP port A\n");
+ return NULL;
+ }
+
if (dev_priv->vbt.drrs_type != SEAMLESS_DRRS_SUPPORT) {
drm_dbg_kms(&dev_priv->drm, "VBT doesn't support DRRS\n");
return NULL;
--
2.34.1
Currently, SD card fails to mount due to the following pinctrl error:
[ 11.170000] imx23-pinctrl 80018000.pinctrl: pin SSP1_DETECT already requested by 80018000.pinctrl; cannot claim for 80010000.spi
[ 11.180000] imx23-pinctrl 80018000.pinctrl: pin-65 (80010000.spi) status -22
[ 11.190000] imx23-pinctrl 80018000.pinctrl: could not request pin 65 (SSP1_DETECT) from group mmc0-pins-fixup.0 on device 80018000.pinctrl
[ 11.200000] mxs-mmc 80010000.spi: Error applying setting, reverse things back
Fix it by removing the MX23_PAD_SSP1_DETECT pin from the hog group as it
is already been used by the mmc0-pins-fixup pinctrl group.
With this change the rootfs can be mounted and the imx23-evk board can
boot successfully.
Cc: <stable(a)vger.kernel.org>
Fixes: bc3875f1a61e ("ARM: dts: mxs: modify mx23/mx28 dts files to use pinctrl headers")
Signed-off-by: Fabio Estevam <festevam(a)gmail.com>
---
arch/arm/boot/dts/imx23-evk.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx23-evk.dts b/arch/arm/boot/dts/imx23-evk.dts
index 8cbaf1c81174..3b609d987d88 100644
--- a/arch/arm/boot/dts/imx23-evk.dts
+++ b/arch/arm/boot/dts/imx23-evk.dts
@@ -79,7 +79,6 @@ hog_pins_a: hog@0 {
MX23_PAD_LCD_RESET__GPIO_1_18
MX23_PAD_PWM3__GPIO_1_29
MX23_PAD_PWM4__GPIO_1_30
- MX23_PAD_SSP1_DETECT__SSP1_DETECT
>;
fsl,drive-strength = <MXS_DRIVE_4mA>;
fsl,voltage = <MXS_VOLTAGE_HIGH>;
--
2.25.1
[TLDR: I'm adding this regression to regzbot, the Linux kernel
regression tracking bot; most text you find below is compiled from a few
templates paragraphs some of you might have seen already.]
Hi, this is your Linux kernel regression tracker speaking.
Adding the regression mailing list to the list of recipients, as it
should be in the loop for all regressions, as explained here:
https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html
On 28.01.22 00:49, Bjorn Helgaas wrote:
> [+cc Thomas, Pali]
CCing also Greg and the stable list, as this is a issue in a stable kernel.
Anyway:
> On Thu, Jan 27, 2022 at 10:52:43PM +0000, bugzilla-daemon(a)bugzilla.kernel.org wrote:
>> https://bugzilla.kernel.org/show_bug.cgi?id=215540
>>
>> Bug ID: 215540
>> Summary: mvebu: no pcie devices detected on turris omnia
>> (5.16.3 regression)
>> Product: Drivers
>> Version: 2.5
>> Kernel Version: 5.16.3
>> Hardware: ARM
>> OS: Linux
>> Tree: Mainline
>> Status: NEW
>> Severity: normal
>> Priority: P1
>> Component: PCI
>> Assignee: drivers_pci(a)kernel-bugs.osdl.org
>> Reporter: jpalus(a)fastmail.com
>> Regression: No
>>
>> After kernel upgrade from 5.16.1 to 5.16.3 Turris Omnia (Armada 385)
>> no longer detects pcie devices (wifi/msata). Haven't tried 5.16.2
>> but it doesn't seem to have any relevant changes, while 5.16.3
>> carries a few.
To be sure this issue doesn't fall through the cracks unnoticed, I'm
adding it to regzbot, my Linux kernel regression tracking bot:
#regzbot ^introduced v5.16.1..v5.16.3
#regzbot title mvebu: no pcie devices detected on turris omnia
#regzbot from: Jan Palus <jpalus(a)fastmail.com>
#regzbot ignore-activity
#regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=215540
Ciao, Thorsten (wearing his 'Linux kernel regression tracker' hat)
P.S.: As a Linux kernel regression tracker I'm getting a lot of reports
on my table. I can only look briefly into most of them. Unfortunately
therefore I sometimes will get things wrong or miss something important.
I hope that's not the case here; if you think it is, don't hesitate to
tell me about it in a public reply, that's in everyone's interest.
BTW, I have no personal interest in this issue, which is tracked using
regzbot, my Linux kernel regression tracking bot
(https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting
this mail to get things rolling again and hence don't need to be CC on
all further activities wrt to this regression.
> Here are some of the dmesg diffs between v5.16.1 (good) and v5.16.3
> (bad):
>
> pci 0000:00:01.0: [11ab:6820] type 01 class 0x060400
> -pci 0000:00:01.0: reg 0x38: [mem 0x00000000-0x000007ff pref]
> pci 0000:00:02.0: [11ab:6820] type 01 class 0x060400
> -pci 0000:00:02.0: reg 0x38: [mem 0x00000000-0x000007ff pref]
> pci 0000:00:03.0: [11ab:6820] type 01 class 0x060400
> -pci 0000:00:03.0: reg 0x38: [mem 0x00000000-0x000007ff pref]
>
> That means both kernels *discovered* the devices, but v5.16.3 couldn't
> size the BARs.
>
> Between v5.16.1 and v5.16.3, there were several changes to mvebu and
> the root port emulation it uses (though the devices above are on the
> root bus and shouldn't be below a root port):
>
> 71ceae67ef9b ("PCI: pci-bridge-emul: Set PCI_STATUS_CAP_LIST for PCIe device")
> 2c8683fbf143 ("PCI: pci-bridge-emul: Correctly set PCIe capabilities")
> 6863f571a546 ("PCI: pci-bridge-emul: Fix definitions of reserved bits")
> 9e6e6e641f26 ("PCI: pci-bridge-emul: Properly mark reserved PCIe bits in PCI config space")
> 174a6ab8722e ("PCI: pci-bridge-emul: Make expansion ROM Base Address register read-only")
> ce16d4b7e5f6 ("PCI: mvebu: Fix support for DEVCAP2, DEVCTL2 and LNKCTL2 registers on emulated bridge")
> 004408c5b7b4 ("PCI: mvebu: Fix support for PCI_EXP_RTSTA on emulated bridge")
> e9dd0d0efece ("PCI: mvebu: Fix support for PCI_EXP_DEVCTL on emulated bridge")
> 802d9ee9cbd3 ("PCI: mvebu: Fix support for PCI_BRIDGE_CTL_BUS_RESET on emulated bridge")
> 4523e727c349 ("PCI: mvebu: Setup PCIe controller to Root Complex mode")
> 7cde9bf07316 ("PCI: mvebu: Fix configuring secondary bus of PCIe Root Port via emulated bridge")
> 3de91c80b70a ("PCI: mvebu: Fix support for bus mastering and PCI_COMMAND on emulated bridge")
> d9bfeaab65b3 ("PCI: mvebu: Do not modify PCI IO type bits in conf_write")
> e7e52bc07021 ("PCI: mvebu: Check for errors from pci_bridge_emul_init() call")
>
> I think these are all from Pali (cc'd), so he'll likely see the
> problem.
>
>> 5.16.3:
>> $ dmesg|grep -i pci
>> [ 0.075893] PCI: CLS 0 bytes, default 64
>> [ 0.127393] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
>> [ 0.127679] mvebu-pcie soc:pcie: host bridge /soc/pcie ranges:
>> [ 0.127723] mvebu-pcie soc:pcie: MEM 0x00f1080000..0x00f1081fff ->
>> 0x0000080000
>> [ 0.127743] mvebu-pcie soc:pcie: MEM 0x00f1040000..0x00f1041fff ->
>> 0x0000040000
>> [ 0.127760] mvebu-pcie soc:pcie: MEM 0x00f1044000..0x00f1045fff ->
>> 0x0000044000
>> [ 0.127775] mvebu-pcie soc:pcie: MEM 0x00f1048000..0x00f1049fff ->
>> 0x0000048000
>> [ 0.127790] mvebu-pcie soc:pcie: MEM 0xffffffffffffffff..0x00fffffffe
>> -> 0x0100000000
>> [ 0.127804] mvebu-pcie soc:pcie: IO 0xffffffffffffffff..0x00fffffffe
>> -> 0x0100000000
>> [ 0.127819] mvebu-pcie soc:pcie: MEM 0xffffffffffffffff..0x00fffffffe
>> -> 0x0200000000
>> [ 0.127833] mvebu-pcie soc:pcie: IO 0xffffffffffffffff..0x00fffffffe
>> -> 0x0200000000
>> [ 0.127847] mvebu-pcie soc:pcie: MEM 0xffffffffffffffff..0x00fffffffe
>> -> 0x0300000000
>> [ 0.127861] mvebu-pcie soc:pcie: IO 0xffffffffffffffff..0x00fffffffe
>> -> 0x0300000000
>> [ 0.127875] mvebu-pcie soc:pcie: MEM 0xffffffffffffffff..0x00fffffffe
>> -> 0x0400000000
>> [ 0.127886] mvebu-pcie soc:pcie: IO 0xffffffffffffffff..0x00fffffffe
>> -> 0x0400000000
>> [ 0.128145] mvebu-pcie soc:pcie: PCI host bridge to bus 0000:00
>> [ 0.128162] pci_bus 0000:00: root bus resource [bus 00-ff]
>> [ 0.128174] pci_bus 0000:00: root bus resource [mem 0xf1080000-0xf1081fff]
>> (bus address [0x00080000-0x00081fff])
>> [ 0.128183] pci_bus 0000:00: root bus resource [mem 0xf1040000-0xf1041fff]
>> (bus address [0x00040000-0x00041fff])
>> [ 0.128191] pci_bus 0000:00: root bus resource [mem 0xf1044000-0xf1045fff]
>> (bus address [0x00044000-0x00045fff])
>> [ 0.128199] pci_bus 0000:00: root bus resource [mem 0xf1048000-0xf1049fff]
>> (bus address [0x00048000-0x00049fff])
>> [ 0.128206] pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]
>> [ 0.128212] pci_bus 0000:00: root bus resource [io 0x1000-0xeffff]
>> [ 0.128354] pci 0000:00:01.0: [11ab:6820] type 01 class 0x060400
>> [ 0.128634] pci 0000:00:02.0: [11ab:6820] type 01 class 0x060400
>> [ 0.128866] pci 0000:00:03.0: [11ab:6820] type 01 class 0x060400
>> [ 0.129958] PCI: bus0: Fast back to back transfers disabled
>> [ 0.129979] pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]),
>> reconfiguring
>> [ 0.129994] pci 0000:00:02.0: bridge configuration invalid ([bus 00-00]),
>> reconfiguring
>> [ 0.130004] pci 0000:00:03.0: bridge configuration invalid ([bus 01-00]),
>> reconfiguring
>> [ 0.131172] PCI: bus1: Fast back to back transfers enabled
>> [ 0.131198] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
>> [ 0.131363] pci 0000:02:00.0: [11ab:6820] type 00 class 0x058000
>> [ 0.131386] pci 0000:02:00.0: reg 0x10: [mem 0xf1000000-0xf10fffff]
>> [ 0.131401] pci 0000:02:00.0: reg 0x18: [mem 0x00000000-0x7fffffff]
>> [ 0.131459] pci 0000:02:00.0: supports D1 D2
>> [ 0.132655] PCI: bus2: Fast back to back transfers disabled
>> [ 0.132681] pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 02
>> [ 0.132831] pci 0000:03:00.0: [11ab:6820] type 00 class 0x058000
>> [ 0.132853] pci 0000:03:00.0: reg 0x10: [mem 0xf1000000-0xf10fffff]
>> [ 0.132868] pci 0000:03:00.0: reg 0x18: [mem 0x00000000-0x7fffffff]
>> [ 0.132926] pci 0000:03:00.0: supports D1 D2
>> [ 0.134166] PCI: bus3: Fast back to back transfers disabled
>> [ 0.134194] pci_bus 0000:03: busn_res: [bus 03-ff] end is updated to 03
>> [ 0.134303] pci 0000:00:02.0: BAR 14: no space for [mem size 0xc0000000]
>> [ 0.134318] pci 0000:00:02.0: BAR 14: failed to assign [mem size 0xc0000000]
>> [ 0.134329] pci 0000:00:03.0: BAR 14: no space for [mem size 0xc0000000]
>> [ 0.134337] pci 0000:00:03.0: BAR 14: failed to assign [mem size 0xc0000000]
>> [ 0.134348] pci 0000:00:01.0: PCI bridge to [bus 01]
>> [ 0.134364] pci 0000:02:00.0: BAR 2: no space for [mem size 0x80000000]
>> [ 0.134372] pci 0000:02:00.0: BAR 2: failed to assign [mem size 0x80000000]
>> [ 0.134379] pci 0000:02:00.0: BAR 0: no space for [mem size 0x00100000]
>> [ 0.134385] pci 0000:02:00.0: BAR 0: failed to assign [mem size 0x00100000]
>> [ 0.134393] pci 0000:00:02.0: PCI bridge to [bus 02]
>> [ 0.134406] pci 0000:03:00.0: BAR 2: no space for [mem size 0x80000000]
>> [ 0.134413] pci 0000:03:00.0: BAR 2: failed to assign [mem size 0x80000000]
>> [ 0.134420] pci 0000:03:00.0: BAR 0: no space for [mem size 0x00100000]
>> [ 0.134426] pci 0000:03:00.0: BAR 0: failed to assign [mem size 0x00100000]
>> [ 0.134433] pci 0000:00:03.0: PCI bridge to [bus 03]
>>
>> 5.16.1:
>> [ 0.127673] mvebu-pcie soc:pcie: host bridge /soc/pcie ranges:
>> [ 0.127717] mvebu-pcie soc:pcie: MEM 0x00f1080000..0x00f1081fff ->
>> 0x0000080000
>> [ 0.127737] mvebu-pcie soc:pcie: MEM 0x00f1040000..0x00f1041fff ->
>> 0x0000040000
>> [ 0.127753] mvebu-pcie soc:pcie: MEM 0x00f1044000..0x00f1045fff ->
>> 0x0000044000
>> [ 0.127768] mvebu-pcie soc:pcie: MEM 0x00f1048000..0x00f1049fff ->
>> 0x0000048000
>> [ 0.127783] mvebu-pcie soc:pcie: MEM 0xffffffffffffffff..0x00fffffffe
>> -> 0x0100000000
>> [ 0.127798] mvebu-pcie soc:pcie: IO 0xffffffffffffffff..0x00fffffffe
>> -> 0x0100000000
>> [ 0.127812] mvebu-pcie soc:pcie: MEM 0xffffffffffffffff..0x00fffffffe
>> -> 0x0200000000
>> [ 0.127826] mvebu-pcie soc:pcie: IO 0xffffffffffffffff..0x00fffffffe
>> -> 0x0200000000
>> [ 0.127839] mvebu-pcie soc:pcie: MEM 0xffffffffffffffff..0x00fffffffe
>> -> 0x0300000000
>> [ 0.127853] mvebu-pcie soc:pcie: IO 0xffffffffffffffff..0x00fffffffe
>> -> 0x0300000000
>> [ 0.127867] mvebu-pcie soc:pcie: MEM 0xffffffffffffffff..0x00fffffffe
>> -> 0x0400000000
>> [ 0.127877] mvebu-pcie soc:pcie: IO 0xffffffffffffffff..0x00fffffffe
>> -> 0x0400000000
>> [ 0.128140] mvebu-pcie soc:pcie: PCI host bridge to bus 0000:00
>> [ 0.128157] pci_bus 0000:00: root bus resource [bus 00-ff]
>> [ 0.128170] pci_bus 0000:00: root bus resource [mem 0xf1080000-0xf1081fff]
>> (bus address [0x00080000-0x00081fff])
>> [ 0.128179] pci_bus 0000:00: root bus resource [mem 0xf1040000-0xf1041fff]
>> (bus address [0x00040000-0x00041fff])
>> [ 0.128187] pci_bus 0000:00: root bus resource [mem 0xf1044000-0xf1045fff]
>> (bus address [0x00044000-0x00045fff])
>> [ 0.128196] pci_bus 0000:00: root bus resource [mem 0xf1048000-0xf1049fff]
>> (bus address [0x00048000-0x00049fff])
>> [ 0.128203] pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]
>> [ 0.128210] pci_bus 0000:00: root bus resource [io 0x1000-0xeffff]
>> [ 0.128341] pci 0000:00:01.0: [11ab:6820] type 01 class 0x060400
>> [ 0.128362] pci 0000:00:01.0: reg 0x38: [mem 0x00000000-0x000007ff pref]
>> [ 0.128631] pci 0000:00:02.0: [11ab:6820] type 01 class 0x060400
>> [ 0.128655] pci 0000:00:02.0: reg 0x38: [mem 0x00000000-0x000007ff pref]
>> [ 0.128871] pci 0000:00:03.0: [11ab:6820] type 01 class 0x060400
>> [ 0.128893] pci 0000:00:03.0: reg 0x38: [mem 0x00000000-0x000007ff pref]
>> [ 0.129975] pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]),
>> reconfiguring
>> [ 0.129989] pci 0000:00:02.0: bridge configuration invalid ([bus 00-00]),
>> reconfiguring
>> [ 0.129999] pci 0000:00:03.0: bridge configuration invalid ([bus 00-00]),
>> reconfiguring
>> [ 0.131184] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
>> [ 0.131344] pci 0000:02:00.0: [168c:003c] type 00 class 0x028000
>> [ 0.131375] pci 0000:02:00.0: reg 0x10: [mem 0x00000000-0x001fffff 64bit]
>> [ 0.131408] pci 0000:02:00.0: reg 0x30: [mem 0x00000000-0x0000ffff pref]
>> [ 0.131507] pci 0000:02:00.0: supports D1
>> [ 0.131515] pci 0000:02:00.0: PME# supported from D0 D1 D3hot
>> [ 0.131734] pci 0000:00:02.0: ASPM: current common clock configuration is
>> inconsistent, reconfiguring
>> [ 0.131753] pci 0000:00:02.0: ASPM: Bridge does not support changing Link
>> Speed to 2.5 GT/s
>> [ 0.131759] pci 0000:00:02.0: ASPM: Retrain Link at higher speed is
>> disallowed by quirk
>> [ 0.131765] pci 0000:00:02.0: ASPM: Could not configure common clock
>> [ 0.132832] pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 02
>> [ 0.132993] pci 0000:03:00.0: [168c:002e] type 00 class 0x028000
>> [ 0.133027] pci 0000:03:00.0: reg 0x10: [mem 0x00000000-0x0000ffff 64bit]
>> [ 0.133152] pci 0000:03:00.0: supports D1
>> [ 0.133161] pci 0000:03:00.0: PME# supported from D0 D1 D3hot
>> [ 0.133396] pci 0000:00:03.0: ASPM: current common clock configuration is
>> inconsistent, reconfiguring
>> [ 0.133413] pci 0000:00:03.0: ASPM: Bridge does not support changing Link
>> Speed to 2.5 GT/s
>> [ 0.133421] pci 0000:00:03.0: ASPM: Retrain Link at higher speed is
>> disallowed by quirk
>> [ 0.133427] pci 0000:00:03.0: ASPM: Could not configure common clock
>> [ 0.134545] pci_bus 0000:03: busn_res: [bus 03-ff] end is updated to 03
>> [ 0.134655] pci 0000:00:02.0: BAR 14: assigned [mem 0xe0000000-0xe02fffff]
>> [ 0.134673] pci 0000:00:03.0: BAR 14: assigned [mem 0xe0300000-0xe03fffff]
>> [ 0.134685] pci 0000:00:01.0: BAR 6: assigned [mem 0xe0400000-0xe04007ff
>> pref]
>> [ 0.134696] pci 0000:00:02.0: BAR 6: assigned [mem 0xe0500000-0xe05007ff
>> pref]
>> [ 0.134706] pci 0000:00:03.0: BAR 6: assigned [mem 0xe0600000-0xe06007ff
>> pref]
>> [ 0.134717] pci 0000:00:01.0: PCI bridge to [bus 01]
>> [ 0.134737] pci 0000:02:00.0: BAR 0: assigned [mem 0xe0000000-0xe01fffff
>> 64bit]
>> [ 0.134755] pci 0000:02:00.0: BAR 6: assigned [mem 0xe0200000-0xe020ffff
>> pref]
>> [ 0.134764] pci 0000:00:02.0: PCI bridge to [bus 02]
>> [ 0.134772] pci 0000:00:02.0: bridge window [mem 0xe0000000-0xe02fffff]
>> [ 0.134784] pci 0000:03:00.0: BAR 0: assigned [mem 0xe0300000-0xe030ffff
>> 64bit]
>> [ 0.134798] pci 0000:00:03.0: PCI bridge to [bus 03]
>> [ 0.134806] pci 0000:00:03.0: bridge window [mem 0xe0300000-0xe03fffff]
>> [ 0.134997] pcieport 0000:00:02.0: enabling device (0140 -> 0142)
>> [ 0.135084] pcieport 0000:00:03.0: enabling device (0140 -> 0142)
>>
>> --
>> You may reply to this email to add a comment.
>>
>> You are receiving this mail because:
>> You are watching the assignee of the bug.
---
Additional information about regzbot:
If you want to know more about regzbot, check out its web-interface, the
getting start guide, and/or the references documentation:
https://linux-regtracking.leemhuis.info/regzbot/https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.mdhttps://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md
The last two documents will explain how you can interact with regzbot
yourself if your want to.
Hint for reporters: when reporting a regression it's in your interest to
tell #regzbot about it in the report, as that will ensure the regression
gets on the radar of regzbot and the regression tracker. That's in your
interest, as they will make sure the report won't fall through the
cracks unnoticed.
Hint for developers: you normally don't need to care about regzbot once
it's involved. Fix the issue as you normally would, just remember to
include a 'Link:' tag to the report in the commit message, as explained
in Documentation/process/submitting-patches.rst
That aspect was recently was made more explicit in commit 1f57bd42b77c:
https://git.kernel.org/linus/1f57bd42b77c
Stopping tasklet and hrtimer rely on the active state of tasklet and
hrtimer sequentially in bcm_remove_op(), the op object will be freed
if they are all unactive. Assume the hrtimer timeout is short, the
hrtimer cb has been excuted after tasklet conditional judgment which
must be false after last round tasklet_kill() and before condition
hrtimer_active(), it is false when execute to hrtimer_active(). Bug
is triggerd, because the stopping action is end and the op object
will be freed, but the tasklet is scheduled. The resources of the op
object will occur UAF bug.
Move hrtimer_cancel() behind tasklet_kill() and switch 'while () {...}'
to 'do {...} while ()' to fix the op UAF problem.
Fixes: a06393ed0316 ("can: bcm: fix hrtimer/tasklet termination in bcm op removal")
Reported-by: syzbot+5ca851459ed04c778d1d(a)syzkaller.appspotmail.com
Cc: stable(a)vger.kernel.org
Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com>
---
net/can/bcm.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/net/can/bcm.c b/net/can/bcm.c
index 3e131dc5f0e5..549ee0de456f 100644
--- a/net/can/bcm.c
+++ b/net/can/bcm.c
@@ -737,21 +737,21 @@ static struct bcm_op *bcm_find_op(struct list_head *ops, canid_t can_id,
static void bcm_remove_op(struct bcm_op *op)
{
if (op->tsklet.func) {
- while (test_bit(TASKLET_STATE_SCHED, &op->tsklet.state) ||
- test_bit(TASKLET_STATE_RUN, &op->tsklet.state) ||
- hrtimer_active(&op->timer)) {
- hrtimer_cancel(&op->timer);
+ do {
tasklet_kill(&op->tsklet);
- }
+ hrtimer_cancel(&op->timer);
+ } while (test_bit(TASKLET_STATE_SCHED, &op->tsklet.state) ||
+ test_bit(TASKLET_STATE_RUN, &op->tsklet.state) ||
+ hrtimer_active(&op->timer));
}
if (op->thrtsklet.func) {
- while (test_bit(TASKLET_STATE_SCHED, &op->thrtsklet.state) ||
- test_bit(TASKLET_STATE_RUN, &op->thrtsklet.state) ||
- hrtimer_active(&op->thrtimer)) {
- hrtimer_cancel(&op->thrtimer);
+ do {
tasklet_kill(&op->thrtsklet);
- }
+ hrtimer_cancel(&op->thrtimer);
+ } while (test_bit(TASKLET_STATE_SCHED, &op->thrtsklet.state) ||
+ test_bit(TASKLET_STATE_RUN, &op->thrtsklet.state) ||
+ hrtimer_active(&op->thrtimer));
}
if ((op->frames) && (op->frames != &op->sframe))
--
2.25.1
From: Palmer Dabbelt <palmer(a)rivosinc.com>
The SBI spec defines SBI calls as following the standard calling
convention, but we don't actually inform GCC of that when making an
ecall. Unfortunately this does actually manifest for the more complex
SBI call wrappers, for example sbi_s, for example sbi_send_ipi_v02()
uses t1.
This patch just marks sbi_ecall() as noinline, which implicitly enforces
the standard calling convention.
Fixes : b9dcd9e41587 ("RISC-V: Add basic support for SBI v0.2")
Cc: stable(a)vger.kernel.org
Reported-by: Atish Patra <atishp(a)rivosinc.com>
Signed-off-by: Palmer Dabbelt <palmer(a)rivosinc.com>
---
This is more of a stop-gap fix than anything else, but it's small enough
that it should be straight-forward to back port to stable. This bug has
existed forever, in theory, but none of this was specified in SBI-0.1
so the backport to the introduction of 0.2 should be sufficient.
No extant versions OpenSBI or BBL will manifest issues here, as they
save all registers, but the spec is quite explicit so we're better off
getting back in line sooner rather than later.
There'll be some marginal performance impact here. I'll send a
follow-on to clean up the SBI call wrappers in a way that allows
inlining without violating the spec, but that'll be a bigger change and
thus isn't really suitable for stable.
---
arch/riscv/kernel/sbi.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/riscv/kernel/sbi.c b/arch/riscv/kernel/sbi.c
index f72527fcb347..7be586f5dc69 100644
--- a/arch/riscv/kernel/sbi.c
+++ b/arch/riscv/kernel/sbi.c
@@ -21,6 +21,11 @@ static int (*__sbi_rfence)(int fid, const struct cpumask *cpu_mask,
unsigned long start, unsigned long size,
unsigned long arg4, unsigned long arg5) __ro_after_init;
+/*
+ * This ecall stub can't be inlined because we're relying on the presence of a
+ * function call to enforce the calling convention.
+ */
+noinline
struct sbiret sbi_ecall(int ext, int fid, unsigned long arg0,
unsigned long arg1, unsigned long arg2,
unsigned long arg3, unsigned long arg4,
--
2.34.1
The patch titled
Subject: mm/util.c: make kvfree() safe for calling while holding spinlocks
has been added to the -mm tree. Its filename is
mm-utilc-make-kvfree-safe-for-calling-while-holding-spinlocks.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/mm-utilc-make-kvfree-safe-for-cal…
and later at
https://ozlabs.org/~akpm/mmotm/broken-out/mm-utilc-make-kvfree-safe-for-cal…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Manfred Spraul <manfred(a)colorfullife.com>
Subject: mm/util.c: make kvfree() safe for calling while holding spinlocks
One codepath in find_alloc_undo() calls kvfree() while holding a spinlock.
Since vfree() can sleep this is a bug.
Previously, the code path used kfree(), and kfree() is safe to be called
while holding a spinlock.
Minghao proposed to fix this by updating find_alloc_undo().
Alternate proposal to fix this: Instead of changing find_alloc_undo(),
change kvfree() so that the same rules as for kfree() apply: Having
different rules for kfree() and kvfree() just asks for bugs.
Disadvantage: Releasing vmalloc'ed memory will be delayed a bit.
Link: https://lkml.kernel.org/r/20211222194828.15320-1-manfred@colorfullife.com
Link: https://lore.kernel.org/all/20211222081026.484058-1-chi.minghao@zte.com.cn/
Fixes: fc37a3b8b438 ("[PATCH] ipc sem: use kvmalloc for sem_undo allocation")
Signed-off-by: Manfred Spraul <manfred(a)colorfullife.com>
Reported-by: Zeal Robot <zealci(a)zte.com.cn>
Reported-by: Minghao Chi <chi.minghao(a)zte.com.cn>
Cc: Vasily Averin <vvs(a)virtuozzo.com>
Cc: CGEL ZTE <cgel.zte(a)gmail.com>
Cc: Shakeel Butt <shakeelb(a)google.com>
Cc: Randy Dunlap <rdunlap(a)infradead.org>
Cc: Davidlohr Bueso <dbueso(a)suse.de>
Cc: Bhaskar Chowdhury <unixbhaskar(a)gmail.com>
Cc: Arnd Bergmann <arnd(a)arndb.de>
Cc: Uladzislau Rezki <urezki(a)gmail.com>
Cc: Michal Hocko <mhocko(a)kernel.org>
Cc: <1vier1(a)web.de>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/util.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/mm/util.c~mm-utilc-make-kvfree-safe-for-calling-while-holding-spinlocks
+++ a/mm/util.c
@@ -603,12 +603,12 @@ EXPORT_SYMBOL(kvmalloc_node);
* It is slightly more efficient to use kfree() or vfree() if you are certain
* that you know which one to use.
*
- * Context: Either preemptible task context or not-NMI interrupt.
+ * Context: Any context except NMI interrupt.
*/
void kvfree(const void *addr)
{
if (is_vmalloc_addr(addr))
- vfree(addr);
+ vfree_atomic(addr);
else
kfree(addr);
}
_
Patches currently in -mm which might be from manfred(a)colorfullife.com are
mm-utilc-make-kvfree-safe-for-calling-while-holding-spinlocks.patch
The patch titled
Subject: mm/util.c: make kvfree() safe for calling while holding spinlocks
has been removed from the -mm tree. Its filename was
mm-utilc-make-kvfree-safe-for-calling-while-holding-spinlocks.patch
This patch was dropped because an alternative patch was merged
------------------------------------------------------
From: Manfred Spraul <manfred(a)colorfullife.com>
Subject: mm/util.c: make kvfree() safe for calling while holding spinlocks
One codepath in find_alloc_undo() calls kvfree() while holding a spinlock.
Since vfree() can sleep this is a bug.
Previously, the code path used kfree(), and kfree() is safe to be called
while holding a spinlock.
Minghao proposed to fix this by updating find_alloc_undo().
Alternate proposal to fix this: Instead of changing find_alloc_undo(),
change kvfree() so that the same rules as for kfree() apply: Having
different rules for kfree() and kvfree() just asks for bugs.
Disadvantage: Releasing vmalloc'ed memory will be delayed a bit.
Link: https://lkml.kernel.org/r/20211222194828.15320-1-manfred@colorfullife.com
Link: https://lore.kernel.org/all/20211222081026.484058-1-chi.minghao@zte.com.cn/
Fixes: fc37a3b8b438 ("[PATCH] ipc sem: use kvmalloc for sem_undo allocation")
Signed-off-by: Manfred Spraul <manfred(a)colorfullife.com>
Reported-by: Zeal Robot <zealci(a)zte.com.cn>
Reported-by: Minghao Chi <chi.minghao(a)zte.com.cn>
Cc: Vasily Averin <vvs(a)virtuozzo.com>
Cc: CGEL ZTE <cgel.zte(a)gmail.com>
Cc: Shakeel Butt <shakeelb(a)google.com>
Cc: Randy Dunlap <rdunlap(a)infradead.org>
Cc: Davidlohr Bueso <dbueso(a)suse.de>
Cc: Bhaskar Chowdhury <unixbhaskar(a)gmail.com>
Cc: Arnd Bergmann <arnd(a)arndb.de>
Cc: Uladzislau Rezki <urezki(a)gmail.com>
Cc: Michal Hocko <mhocko(a)kernel.org>
Cc: <1vier1(a)web.de>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/util.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/mm/util.c~mm-utilc-make-kvfree-safe-for-calling-while-holding-spinlocks
+++ a/mm/util.c
@@ -603,12 +603,12 @@ EXPORT_SYMBOL(kvmalloc_node);
* It is slightly more efficient to use kfree() or vfree() if you are certain
* that you know which one to use.
*
- * Context: Either preemptible task context or not-NMI interrupt.
+ * Context: Any context except NMI interrupt.
*/
void kvfree(const void *addr)
{
if (is_vmalloc_addr(addr))
- vfree(addr);
+ vfree_atomic(addr);
else
kfree(addr);
}
_
Patches currently in -mm which might be from manfred(a)colorfullife.com are
[Public]
Hi,
Can you please bring
commit 7c5f641a5914ce0303b06bcfcd7674ee64aeebe9 ("ata: libahci: Adjust behavior when StorageD3Enable _DSD is set")
and
commit 1527f69204fe35f341cb599f1cb01bd02daf4374 ("ata: ahci: Add Green Sardine vendor ID as board_ahci_mobile")
to 5.15.y? These help suspend to idle failures with supported SATA disks and should make sense for LTS Kernel.
Thanks,
One codepath in find_alloc_undo() calls kvfree() while holding a spinlock.
Since vfree() can sleep this is a bug.
Previously, the code path used kfree(), and kfree() is safe to be called
while holding a spinlock.
Minghao proposed to fix this by updating find_alloc_undo().
Alternate proposal to fix this: Instead of changing find_alloc_undo(),
change kvfree() so that the same rules as for kfree() apply:
Having different rules for kfree() and kvfree() just asks for bugs.
Disadvantage: Releasing vmalloc'ed memory will be delayed a bit.
Reported-by: Zeal Robot <zealci(a)zte.com.cn>
Reported-by: Minghao Chi <chi.minghao(a)zte.com.cn>
Link: https://lore.kernel.org/all/20211222081026.484058-1-chi.minghao@zte.com.cn/
Fixes: fc37a3b8b438 ("[PATCH] ipc sem: use kvmalloc for sem_undo allocation")
Cc: stable(a)vger.kernel.org
Signed-off-by: Manfred Spraul <manfred(a)colorfullife.com>
---
mm/util.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/util.c b/mm/util.c
index 741ba32a43ac..7f9181998835 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -610,12 +610,12 @@ EXPORT_SYMBOL(kvmalloc_node);
* It is slightly more efficient to use kfree() or vfree() if you are certain
* that you know which one to use.
*
- * Context: Either preemptible task context or not-NMI interrupt.
+ * Context: Any context except NMI interrupt.
*/
void kvfree(const void *addr)
{
if (is_vmalloc_addr(addr))
- vfree(addr);
+ vfree_atomic(addr);
else
kfree(addr);
}
--
2.33.1
For some reason this file isn't using the appropriate register
headers for DCN headers, which means that on DCN2 we're getting
the VIEWPORT_DIMENSION offset wrong.
This means that we're not correctly carving out the framebuffer
memory correctly for a framebuffer allocated by EFI and
therefore see corruption when loading amdgpu before the display
driver takes over control of the framebuffer scanout.
Fix this by checking the DCE_HWIP and picking the correct offset
accordingly.
Long-term we should expose this info from DC as GMC shouldn't
need to know about DCN registers.
Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com>
(cherry picked from commit dc5d4aff2e99c312df8abbe1ee9a731d2913bc1b)
---
This is backported from 5.17-rc1, but doesn't backport cleanly because
v5.16 changed to IP version harvesting for ASIC detection. 5.15.y doesn't
have this.
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index 5551359d5dfd..a4adbbf3acab 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -72,6 +72,9 @@
#define mmDCHUBBUB_SDPIF_MMIO_CNTRL_0 0x049d
#define mmDCHUBBUB_SDPIF_MMIO_CNTRL_0_BASE_IDX 2
+#define mmHUBP0_DCSURF_PRI_VIEWPORT_DIMENSION_DCN2 0x05ea
+#define mmHUBP0_DCSURF_PRI_VIEWPORT_DIMENSION_DCN2_BASE_IDX 2
+
static const char *gfxhub_client_ids[] = {
"CB",
@@ -1103,6 +1106,8 @@ static unsigned gmc_v9_0_get_vbios_fb_size(struct amdgpu_device *adev)
u32 d1vga_control = RREG32_SOC15(DCE, 0, mmD1VGA_CONTROL);
unsigned size;
+ /* TODO move to DC so GMC doesn't need to hard-code DCN registers */
+
if (REG_GET_FIELD(d1vga_control, D1VGA_CONTROL, D1VGA_MODE_ENABLE)) {
size = AMDGPU_VBIOS_VGA_ALLOCATION;
} else {
@@ -1110,7 +1115,6 @@ static unsigned gmc_v9_0_get_vbios_fb_size(struct amdgpu_device *adev)
switch (adev->asic_type) {
case CHIP_RAVEN:
- case CHIP_RENOIR:
viewport = RREG32_SOC15(DCE, 0, mmHUBP0_DCSURF_PRI_VIEWPORT_DIMENSION);
size = (REG_GET_FIELD(viewport,
HUBP0_DCSURF_PRI_VIEWPORT_DIMENSION, PRI_VIEWPORT_HEIGHT) *
@@ -1118,6 +1122,14 @@ static unsigned gmc_v9_0_get_vbios_fb_size(struct amdgpu_device *adev)
HUBP0_DCSURF_PRI_VIEWPORT_DIMENSION, PRI_VIEWPORT_WIDTH) *
4);
break;
+ case CHIP_RENOIR:
+ viewport = RREG32_SOC15(DCE, 0, mmHUBP0_DCSURF_PRI_VIEWPORT_DIMENSION_DCN2);
+ size = (REG_GET_FIELD(viewport,
+ HUBP0_DCSURF_PRI_VIEWPORT_DIMENSION, PRI_VIEWPORT_HEIGHT) *
+ REG_GET_FIELD(viewport,
+ HUBP0_DCSURF_PRI_VIEWPORT_DIMENSION, PRI_VIEWPORT_WIDTH) *
+ 4);
+ break;
case CHIP_VEGA10:
case CHIP_VEGA12:
case CHIP_VEGA20:
--
2.25.1
commit 7c8a4742c4abe205ec9daf416c9d42fd6b406e8e upstream.
When the TDP MMU is write-protection GFNs for page table protection (as
opposed to for dirty logging, or due to the HVA not being writable), it
checks if the SPTE is already write-protected and if so skips modifying
the SPTE and the TLB flush.
This behavior is incorrect because it fails to check if the SPTE
is write-protected for page table protection, i.e. fails to check
that MMU-writable is '0'. If the SPTE was write-protected for dirty
logging but not page table protection, the SPTE could locklessly be made
writable, and vCPUs could still be running with writable mappings cached
in their TLB.
Fix this by only skipping setting the SPTE if the SPTE is already
write-protected *and* MMU-writable is already clear. Technically,
checking only MMU-writable would suffice; a SPTE cannot be writable
without MMU-writable being set. But check both to be paranoid and
because it arguably yields more readable code.
Fixes: 46044f72c382 ("kvm: x86/mmu: Support write protection for nesting in tdp MMU")
Cc: stable(a)vger.kernel.org
Signed-off-by: David Matlack <dmatlack(a)google.com>
Message-Id: <20220113233020.3986005-2-dmatlack(a)google.com>
Reviewed-by: Sean Christopherson <seanjc(a)google.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
---
arch/x86/kvm/mmu/tdp_mmu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c
index f2ddf663e72e..7e08efb06839 100644
--- a/arch/x86/kvm/mmu/tdp_mmu.c
+++ b/arch/x86/kvm/mmu/tdp_mmu.c
@@ -1130,12 +1130,12 @@ static bool write_protect_gfn(struct kvm *kvm, struct kvm_mmu_page *root,
bool spte_set = false;
tdp_root_for_each_leaf_pte(iter, root, gfn, gfn + 1) {
- if (!is_writable_pte(iter.old_spte))
- break;
-
new_spte = iter.old_spte &
~(PT_WRITABLE_MASK | SPTE_MMU_WRITEABLE);
+ if (new_spte == iter.old_spte)
+ break;
+
tdp_mmu_set_spte(kvm, &iter, new_spte);
spte_set = true;
}
base-commit: fd187a4925578f8743d4f266c821c7544d3cddae
--
2.35.0.rc0.227.g00780c9af4-goog
Hi all,
This patch series is intended to backport the fix from Phil "pinctrl:
bcm2835: Change init order for gpio hogs" into the 5.4 tree since the
blamed commit:
73345a18d464b ("pinctrl: bcm2835: Pass irqchip when adding gpiochip")
is in 5.4. To get there, I did backport a number of changes in order for
the commit "pinctrl: bcm2835: Change init order for gpio hogs" to apply
cleanly with no hunks.
Those should have no functional impact since we do not have support for
7211 or 2711 in the upstream stable 5.4.
Both the pinctrl *and* the DTS changes must be taken in lockstep
otherwise the GPIO pins are simply not usable unfortunately.
Thanks!
Florian Fainelli (2):
pinctrl: bcm2835: Match BCM7211 compatible string
pinctrl: bcm2835: Add support for wake-up interrupts
Phil Elwell (2):
pinctrl: bcm2835: Change init order for gpio hogs
ARM: dts: gpio-ranges property is now required
Stefan Wahren (3):
pinctrl: bcm2835: Drop unused define
pinctrl: bcm2835: Refactor platform data
pinctrl: bcm2835: Add support for all GPIOs on BCM2711
arch/arm/boot/dts/bcm283x.dtsi | 1 +
drivers/pinctrl/bcm/pinctrl-bcm2835.c | 209 +++++++++++++++++++++-----
2 files changed, 175 insertions(+), 35 deletions(-)
--
2.25.1
Hello,
We've seen a significant perf degradation when reading a tmpfs file
swapped into zram between 5.10 and 5.15. The source of the issue is:
* aa48e47e3906: memcg: infrastructure to flush memcg stats
There's a couple of commits that helps to bridge the gap in 5.16:
* 11192d9c124d: memcg: flush stats only if updated
* fd25a9e0e23b: memcg: unify memcg stat flushing
Both of these apply cleanly and Shakeel (the author) has okayed the
backport from his end. He also suggested backporting the following:
* 5b3be698a872: memcg: better bounds on the memcg stats updates
I personally did not test this one, but it applies cleanly, so there's
probably no harm. I cc'd Shakeel in case you want confirmation on
that. It's not a part of any tag yet.
Please backport all three (or at least the first two) to 5.15 LTS.
Thanks!
There is a syzkaller problem for Linux 4.19 last for over 1 year:
https://www.syzkaller.appspot.com/bug?id=288ae4752bb930c26369d675316de03102…
Mainline patch 7d850abd5f4e(net: bridge: add support for port isolation)
introduces the BR_ISOLATED feature, a pair of ports with the BR_ISOLATED
option set cannot communicate with each other.
This feature applies only to ingress flow, not egress flow. However, the
function br_skb_isolated that checks if an interface is isolated will be
used not only for the ingress path, but also for the egress path.
Since Linux-4.19 not merge the mainline patch fd65e5a95d0838(net: bridge:
clear bridge's private skb space on xmit), the value of skb->cb is unde-
fined because it is not initialized. Therefore, checking
BR_INPUT_SKB_CB(skb)->src_port_isolated on the egress path will access an
undefined value, resulting in an error in the judgment of br_skb_isolated.
UBSAN triggers an alarm by finding undefined
BR_INPUT_SKB_CB(skb)->src_port_isolated.
So cherry-pick mainline patch fd65e5a95d0838(net: bridge: clear bridge's
private skb space on xmit) to Linux 4.19 to fix it.
Nikolay Aleksandrov (1):
net: bridge: clear bridge's private skb space on xmit
net/bridge/br_device.c | 2 ++
1 file changed, 2 insertions(+)
--
2.25.1
From: Stefan Agner <stefan(a)agner.ch>
commit f9b58e8c7d031b0daa5c9a9ee27f5a4028ba53ac upstream.
While in theory multiple unwinders could be compiled in, it does
not make sense in practise. Use a choice to make the unwinder
selection mutually exclusive and mandatory.
Already before this commit it has not been possible to deselect
FRAME_POINTER. Remove the obsolete comment.
Furthermore, to produce a meaningful backtrace with FRAME_POINTER
enabled the kernel needs a specific function prologue:
mov ip, sp
stmfd sp!, {fp, ip, lr, pc}
sub fp, ip, #4
To get to the required prologue gcc uses apcs and no-sched-prolog.
This compiler options are not available on clang, and clang is not
able to generate the required prologue. Make the FRAME_POINTER
config symbol depending on !clang.
Suggested-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Stefan Agner <stefan(a)agner.ch>
Reviewed-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk>
Signed-off-by: Anders Roxell <anders.roxell(a)linaro.org>
---
arch/arm/Kconfig.debug | 44 +++++++++++++++++++++++++++---------------
lib/Kconfig.debug | 6 +++---
2 files changed, 31 insertions(+), 19 deletions(-)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 8349a171a8f3..e1d21c6449ea 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -15,30 +15,42 @@ config ARM_PTDUMP
kernel.
If in doubt, say "N"
-# RMK wants arm kernels compiled with frame pointers or stack unwinding.
-# If you know what you are doing and are willing to live without stack
-# traces, you can get a slightly smaller kernel by setting this option to
-# n, but then RMK will have to kill you ;).
-config FRAME_POINTER
- bool
- depends on !THUMB2_KERNEL
- default y if !ARM_UNWIND || FUNCTION_GRAPH_TRACER
+choice
+ prompt "Choose kernel unwinder"
+ default UNWINDER_ARM if AEABI && !FUNCTION_GRAPH_TRACER
+ default UNWINDER_FRAME_POINTER if !AEABI || FUNCTION_GRAPH_TRACER
+ help
+ This determines which method will be used for unwinding kernel stack
+ traces for panics, oopses, bugs, warnings, perf, /proc/<pid>/stack,
+ livepatch, lockdep, and more.
+
+config UNWINDER_FRAME_POINTER
+ bool "Frame pointer unwinder"
+ depends on !THUMB2_KERNEL && !CC_IS_CLANG
+ select ARCH_WANT_FRAME_POINTERS
+ select FRAME_POINTER
help
- If you say N here, the resulting kernel will be slightly smaller and
- faster. However, if neither FRAME_POINTER nor ARM_UNWIND are enabled,
- when a problem occurs with the kernel, the information that is
- reported is severely limited.
+ This option enables the frame pointer unwinder for unwinding
+ kernel stack traces.
-config ARM_UNWIND
- bool "Enable stack unwinding support (EXPERIMENTAL)"
+config UNWINDER_ARM
+ bool "ARM EABI stack unwinder"
depends on AEABI
- default y
+ select ARM_UNWIND
help
This option enables stack unwinding support in the kernel
using the information automatically generated by the
compiler. The resulting kernel image is slightly bigger but
the performance is not affected. Currently, this feature
- only works with EABI compilers. If unsure say Y.
+ only works with EABI compilers.
+
+endchoice
+
+config ARM_UNWIND
+ bool
+
+config FRAME_POINTER
+ bool
config OLD_MCOUNT
bool
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index bc5ff3a53d4a..e7addfcd302f 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1091,7 +1091,7 @@ config LOCKDEP
bool
depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
select STACKTRACE
- select FRAME_POINTER if !MIPS && !PPC && !ARM_UNWIND && !S390 && !MICROBLAZE && !ARC && !SCORE
+ select FRAME_POINTER if !MIPS && !PPC && !ARM && !S390 && !MICROBLAZE && !ARC && !SCORE
select KALLSYMS
select KALLSYMS_ALL
@@ -1670,7 +1670,7 @@ config FAULT_INJECTION_STACKTRACE_FILTER
depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT
depends on !X86_64
select STACKTRACE
- select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND && !ARC && !SCORE
+ select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM && !ARC && !SCORE
help
Provide stacktrace filter for fault-injection capabilities
@@ -1679,7 +1679,7 @@ config LATENCYTOP
depends on DEBUG_KERNEL
depends on STACKTRACE_SUPPORT
depends on PROC_FS
- select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND && !ARC
+ select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM && !ARC
select KALLSYMS
select KALLSYMS_ALL
select STACKTRACE
--
2.34.1
From: Dan Carpenter <dan.carpenter(a)oracle.com>
commit 35d2969ea3c7d32aee78066b1f3cf61a0d935a4e upstream.
The bounds checking in avc_ca_pmt() is not strict enough. It should
be checking "read_pos + 4" because it's reading 5 bytes. If the
"es_info_length" is non-zero then it reads a 6th byte so there needs to
be an additional check for that.
I also added checks for the "write_pos". I don't think these are
required because "read_pos" and "write_pos" are tied together so
checking one ought to be enough. But they make the code easier to
understand for me. The check on write_pos is:
if (write_pos + 4 >= sizeof(c->operand) - 4) {
The first "+ 4" is because we're writing 5 bytes and the last " - 4"
is to leave space for the CRC.
The other problem is that "length" can be invalid. It comes from
"data_length" in fdtv_ca_pmt().
Cc: stable(a)vger.kernel.org
Reported-by: Luo Likang <luolikang(a)nsfocus.com>
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org>
[bwh: Backported to 4.9: adjust context]
Signed-off-by: Ben Hutchings <ben(a)decadent.org.uk>
---
drivers/media/firewire/firedtv-avc.c | 14 +++++++++++---
drivers/media/firewire/firedtv-ci.c | 2 ++
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/media/firewire/firedtv-avc.c b/drivers/media/firewire/firedtv-avc.c
index 280b5ffea592..3a373711f5ad 100644
--- a/drivers/media/firewire/firedtv-avc.c
+++ b/drivers/media/firewire/firedtv-avc.c
@@ -1169,7 +1169,11 @@ int avc_ca_pmt(struct firedtv *fdtv, char *msg, int length)
read_pos += program_info_length;
write_pos += program_info_length;
}
- while (read_pos < length) {
+ while (read_pos + 4 < length) {
+ if (write_pos + 4 >= sizeof(c->operand) - 4) {
+ ret = -EINVAL;
+ goto out;
+ }
c->operand[write_pos++] = msg[read_pos++];
c->operand[write_pos++] = msg[read_pos++];
c->operand[write_pos++] = msg[read_pos++];
@@ -1181,13 +1185,17 @@ int avc_ca_pmt(struct firedtv *fdtv, char *msg, int length)
c->operand[write_pos++] = es_info_length >> 8;
c->operand[write_pos++] = es_info_length & 0xff;
if (es_info_length > 0) {
+ if (read_pos >= length) {
+ ret = -EINVAL;
+ goto out;
+ }
pmt_cmd_id = msg[read_pos++];
if (pmt_cmd_id != 1 && pmt_cmd_id != 4)
dev_err(fdtv->device, "invalid pmt_cmd_id %d "
"at stream level\n", pmt_cmd_id);
- if (es_info_length > sizeof(c->operand) - 4 -
- write_pos) {
+ if (es_info_length > sizeof(c->operand) - 4 - write_pos ||
+ es_info_length > length - read_pos) {
ret = -EINVAL;
goto out;
}
diff --git a/drivers/media/firewire/firedtv-ci.c b/drivers/media/firewire/firedtv-ci.c
index edbb30fdd9d9..93fb4b7312af 100644
--- a/drivers/media/firewire/firedtv-ci.c
+++ b/drivers/media/firewire/firedtv-ci.c
@@ -138,6 +138,8 @@ static int fdtv_ca_pmt(struct firedtv *fdtv, void *arg)
} else {
data_length = msg->msg[3];
}
+ if (data_length > sizeof(msg->msg) - data_pos)
+ return -EINVAL;
return avc_ca_pmt(fdtv, &msg->msg[data_pos], data_length);
}
Paul,
I believe commit 614ddad17f22a22e035e2ea37a04815f50362017 (slated for
5.17) should be queued for all 5.4+ stable branches as it fixes a
serious lockup bug. FWIW I have verified it applies cleanly on all 4
branches.
Does that make sense to you?
Guillaume.
--
Guillaume Morin <guillaume(a)morinfr.org>
Hi,
Can commit 83293f7f3d15fc56e86bd5067a2c88b6b233ac3a ("drm/amd/display:
reset dcn31 SMU mailbox on failures") please come back to 5.15.y and
5.16.y? This will make identifying and recovering potential FW problems
easier.
Thanks,
The patch below does not apply to the 5.10-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 802d4d207e75d7208ff75adb712b556c1e91cf1c Mon Sep 17 00:00:00 2001
From: Manish Chopra <manishc(a)marvell.com>
Date: Fri, 17 Dec 2021 08:55:52 -0800
Subject: [PATCH] bnx2x: Invalidate fastpath HSI version for VFs
Commit 0a6890b9b4df ("bnx2x: Utilize FW 7.13.15.0.")
added validation for fastpath HSI versions for different
client init which was not meant for SR-IOV VF clients, which
resulted in firmware asserts when running VF clients with
different fastpath HSI version.
This patch along with the new firmware support in patch #1
fixes this behavior in order to not validate fastpath HSI
version for the VFs.
Fixes: 0a6890b9b4df ("bnx2x: Utilize FW 7.13.15.0.")
Signed-off-by: Manish Chopra <manishc(a)marvell.com>
Signed-off-by: Prabhakar Kushwaha <pkushwaha(a)marvell.com>
Signed-off-by: Alok Prasad <palok(a)marvell.com>
Signed-off-by: Ariel Elior <aelior(a)marvell.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
index 74a8931ce1d1..11d15cd03600 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
@@ -758,9 +758,18 @@ static void bnx2x_vf_igu_reset(struct bnx2x *bp, struct bnx2x_virtf *vf)
void bnx2x_vf_enable_access(struct bnx2x *bp, u8 abs_vfid)
{
+ u16 abs_fid;
+
+ abs_fid = FW_VF_HANDLE(abs_vfid);
+
/* set the VF-PF association in the FW */
- storm_memset_vf_to_pf(bp, FW_VF_HANDLE(abs_vfid), BP_FUNC(bp));
- storm_memset_func_en(bp, FW_VF_HANDLE(abs_vfid), 1);
+ storm_memset_vf_to_pf(bp, abs_fid, BP_FUNC(bp));
+ storm_memset_func_en(bp, abs_fid, 1);
+
+ /* Invalidate fp_hsi version for vfs */
+ if (bp->fw_cap & FW_CAP_INVALIDATE_VF_FP_HSI)
+ REG_WR8(bp, BAR_XSTRORM_INTMEM +
+ XSTORM_ETH_FUNCTION_INFO_FP_HSI_VALID_E2_OFFSET(abs_fid), 0);
/* clear vf errors*/
bnx2x_vf_semi_clear_err(bp, abs_vfid);
Stopping tasklet and hrtimer rely on the active state of tasklet and
hrtimer sequentially in bcm_remove_op(), the op object will be freed
if they are all unactive. Assume the hrtimer timeout is short, the
hrtimer cb has been excuted after tasklet conditional judgment which
must be false after last round tasklet_kill() and before condition
hrtimer_active(), it is false when execute to hrtimer_active(). Bug
is triggerd, because the stopping action is end and the op object
will be freed, but the tasklet is scheduled. The resources of the op
object will occur UAF bug.
Move hrtimer_cancel() behind tasklet_kill() and switch 'while () {...}'
to 'do {...} while ()' to fix the op UAF problem.
Fixes: a06393ed0316 ("can: bcm: fix hrtimer/tasklet termination in bcm op removal")
Reported-by: syzbot+5ca851459ed04c778d1d(a)syzkaller.appspotmail.com
Cc: stable(a)vger.kernel.org
Signed-off-by: Ziyang Xuan <william.xuanziyang(a)huawei.com>
---
net/can/bcm.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/net/can/bcm.c b/net/can/bcm.c
index 324c4cdc003e..b3f3b02ffd42 100644
--- a/net/can/bcm.c
+++ b/net/can/bcm.c
@@ -762,21 +762,21 @@ static struct bcm_op *bcm_find_op(struct list_head *ops,
static void bcm_remove_op(struct bcm_op *op)
{
if (op->tsklet.func) {
- while (test_bit(TASKLET_STATE_SCHED, &op->tsklet.state) ||
- test_bit(TASKLET_STATE_RUN, &op->tsklet.state) ||
- hrtimer_active(&op->timer)) {
- hrtimer_cancel(&op->timer);
+ do {
tasklet_kill(&op->tsklet);
- }
+ hrtimer_cancel(&op->timer);
+ } while (test_bit(TASKLET_STATE_SCHED, &op->tsklet.state) ||
+ test_bit(TASKLET_STATE_RUN, &op->tsklet.state) ||
+ hrtimer_active(&op->timer));
}
if (op->thrtsklet.func) {
- while (test_bit(TASKLET_STATE_SCHED, &op->thrtsklet.state) ||
- test_bit(TASKLET_STATE_RUN, &op->thrtsklet.state) ||
- hrtimer_active(&op->thrtimer)) {
- hrtimer_cancel(&op->thrtimer);
+ do {
tasklet_kill(&op->thrtsklet);
- }
+ hrtimer_cancel(&op->thrtimer);
+ } while (test_bit(TASKLET_STATE_SCHED, &op->thrtsklet.state) ||
+ test_bit(TASKLET_STATE_RUN, &op->thrtsklet.state) ||
+ hrtimer_active(&op->thrtimer));
}
if ((op->frames) && (op->frames != &op->sframe))
--
2.25.1
Hi Dear,
My name is Lisa Williams, I am from the United States of America, Its
my pleasure to contact you for new and special friendship, I will be
glad to see your reply for us to know each other better and exchange
pictures.
Yours
Lisa
This patch series to fix PTP issue in stmmac related to:
1/ PTP clock source configuration during initialization.
2/ PTP initialization during resume from suspend.
Mohammad Athari Bin Ismail (2):
net: stmmac: configure PTP clock source prior to PTP initialization
net: stmmac: skip only stmmac_ptp_register when resume from suspend
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 23 ++++++++++---------
.../net/ethernet/stmicro/stmmac/stmmac_ptp.c | 3 ---
2 files changed, 12 insertions(+), 14 deletions(-)
--
2.17.1
Good Day
I Am Andrew Bailey Governor Bank of England (https://en.wikipedia.org/wiki/Andrew_Bailey_%28banker%29)
I have a proposal for you, if you know you can Handle this,
Contact me through my private email:(ande.bailey@mail2world.com)
with your full names and address, phone numbers for more details. I await your reply,
Regards,
Andrew Bailey.
The file now rightfully throws up a big warning that it should never be
included, so remove it from the header_check test.
Fixes: f23653fe6447 ("tty: Partially revert the removal of the Cyclades public API")
Cc: stable <stable(a)vger.kernel.org>
Cc: Masahiro Yamada <masahiroy(a)kernel.org>
Reported-by: Stephen Rothwell <sfr(a)canb.auug.org.au>
Reported-by: kernel test robot <lkp(a)intel.com>
Cc: "Maciej W. Rozycki" <macro(a)embecosm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
As the offending commit is in the tty.git tree, I'll take this through
there as well.
usr/include/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/usr/include/Makefile b/usr/include/Makefile
index 7be7468c177b..83822c33e9e7 100644
--- a/usr/include/Makefile
+++ b/usr/include/Makefile
@@ -28,6 +28,7 @@ no-header-test += linux/am437x-vpfe.h
no-header-test += linux/android/binder.h
no-header-test += linux/android/binderfs.h
no-header-test += linux/coda.h
+no-header-test += linux/cyclades.h
no-header-test += linux/errqueue.h
no-header-test += linux/fsmap.h
no-header-test += linux/hdlc/ioctl.h
--
2.35.0
Greetings,
I am Mr. Ahmed Hassan, I need your urgent assistance in transferring
the sum of $11.3million immediately to your private account.The money
has been here in our Bank lying dormant for years now without anybody
coming for the claim of it.
I want to release the money to you as the relative to our deceased
customer (the account owner) who died a long with his supposed NEXT OF
KIN since 16th October 2005. The Banking laws here does not allow such
money to stay more than 17 years, because the money will be recalled
to the Bank treasury account as unclaimed fund.
By indicating your interest I will send you the full details on how
the business will be executed.
Please respond urgently and delete if you are not interested.
Best Regards,
Mr. Ahmed Hassan
This is a note to let you know that I've just added the patch titled
kbuild: remove include/linux/cyclades.h from header file check
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
From d1ad2721b1eb05d54e81393a7ebc332d4a35c68f Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Date: Thu, 27 Jan 2022 08:33:04 +0100
Subject: kbuild: remove include/linux/cyclades.h from header file check
The file now rightfully throws up a big warning that it should never be
included, so remove it from the header_check test.
Fixes: f23653fe6447 ("tty: Partially revert the removal of the Cyclades public API")
Cc: stable <stable(a)vger.kernel.org>
Cc: Masahiro Yamada <masahiroy(a)kernel.org>
Cc: "Maciej W. Rozycki" <macro(a)embecosm.com>
Reported-by: Stephen Rothwell <sfr(a)canb.auug.org.au>
Reported-by: kernel test robot <lkp(a)intel.com>
Link: https://lore.kernel.org/r/20220127073304.42399-1-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
usr/include/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/usr/include/Makefile b/usr/include/Makefile
index 7be7468c177b..83822c33e9e7 100644
--- a/usr/include/Makefile
+++ b/usr/include/Makefile
@@ -28,6 +28,7 @@ no-header-test += linux/am437x-vpfe.h
no-header-test += linux/android/binder.h
no-header-test += linux/android/binderfs.h
no-header-test += linux/coda.h
+no-header-test += linux/cyclades.h
no-header-test += linux/errqueue.h
no-header-test += linux/fsmap.h
no-header-test += linux/hdlc/ioctl.h
--
2.35.0
Dzień dobry,
dostrzegam możliwość współpracy z Państwa firmą.
Świadczymy kompleksową obsługę inwestycji w fotowoltaikę, która obniża koszty energii elektrycznej nawet o 90%.
Czy są Państwo zainteresowani weryfikacją wstępnych propozycji?
Pozdrawiam,
Marek Dranski
In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memcpy(), memmove(), and memset(), avoid
intentionally writing across neighboring fields. Wrap the target region
in struct_group(). This additionally fixes a theoretical misalignment
of the copy (since the size of "buf" changes between 64-bit and 32-bit,
but this is likely never built for 64-bit).
FWIW, I think this code is totally broken on 64-bit (which appears to
not be a "real" build configuration): it would either always fail (with
an uninitialized data->buf_size) or would cause corruption in userspace
due to the copy_to_user() in the call path against an uninitialized
data->buf value:
omap3isp_stat_request_statistics_time32(...)
struct omap3isp_stat_data data64;
...
omap3isp_stat_request_statistics(stat, &data64);
int omap3isp_stat_request_statistics(struct ispstat *stat,
struct omap3isp_stat_data *data)
...
buf = isp_stat_buf_get(stat, data);
static struct ispstat_buffer *isp_stat_buf_get(struct ispstat *stat,
struct omap3isp_stat_data *data)
...
if (buf->buf_size > data->buf_size) {
...
return ERR_PTR(-EINVAL);
}
...
rval = copy_to_user(data->buf,
buf->virt_addr,
buf->buf_size);
Regardless, additionally initialize data64 to be zero-filled to avoid
undefined behavior.
Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Cc: Mauro Carvalho Chehab <mchehab(a)kernel.org>
Cc: Arnd Bergmann <arnd(a)arndb.de>
Cc: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Cc: linux-media(a)vger.kernel.org
Fixes: 378e3f81cb56 ("media: omap3isp: support 64-bit version of omap3isp_stat_data")
Cc: stable(a)vger.kernel.org
Reviewed-by: Gustavo A. R. Silva <gustavoars(a)kernel.org>
Link: https://lore.kernel.org/lkml/20211215220505.GB21862@embeddedor
Signed-off-by: Kees Cook <keescook(a)chromium.org>
---
I will carry this in my tree unless someone else wants to pick it up. It's
one of the last remaining clean-ups needed for the next step in memcpy()
hardening.
---
drivers/media/platform/omap3isp/ispstat.c | 5 +++--
include/uapi/linux/omap3isp.h | 21 +++++++++++++--------
2 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/omap3isp/ispstat.c b/drivers/media/platform/omap3isp/ispstat.c
index 5b9b57f4d9bf..68cf68dbcace 100644
--- a/drivers/media/platform/omap3isp/ispstat.c
+++ b/drivers/media/platform/omap3isp/ispstat.c
@@ -512,7 +512,7 @@ int omap3isp_stat_request_statistics(struct ispstat *stat,
int omap3isp_stat_request_statistics_time32(struct ispstat *stat,
struct omap3isp_stat_data_time32 *data)
{
- struct omap3isp_stat_data data64;
+ struct omap3isp_stat_data data64 = { };
int ret;
ret = omap3isp_stat_request_statistics(stat, &data64);
@@ -521,7 +521,8 @@ int omap3isp_stat_request_statistics_time32(struct ispstat *stat,
data->ts.tv_sec = data64.ts.tv_sec;
data->ts.tv_usec = data64.ts.tv_usec;
- memcpy(&data->buf, &data64.buf, sizeof(*data) - sizeof(data->ts));
+ data->buf = (uintptr_t)data64.buf;
+ memcpy(&data->frame, &data64.frame, sizeof(data->frame));
return 0;
}
diff --git a/include/uapi/linux/omap3isp.h b/include/uapi/linux/omap3isp.h
index 87b55755f4ff..d9db7ad43890 100644
--- a/include/uapi/linux/omap3isp.h
+++ b/include/uapi/linux/omap3isp.h
@@ -162,6 +162,7 @@ struct omap3isp_h3a_aewb_config {
* struct omap3isp_stat_data - Statistic data sent to or received from user
* @ts: Timestamp of returned framestats.
* @buf: Pointer to pass to user.
+ * @buf_size: Size of buffer.
* @frame_number: Frame number of requested stats.
* @cur_frame: Current frame number being processed.
* @config_counter: Number of the configuration associated with the data.
@@ -176,10 +177,12 @@ struct omap3isp_stat_data {
struct timeval ts;
#endif
void __user *buf;
- __u32 buf_size;
- __u16 frame_number;
- __u16 cur_frame;
- __u16 config_counter;
+ __struct_group(/* no tag */, frame, /* no attrs */,
+ __u32 buf_size;
+ __u16 frame_number;
+ __u16 cur_frame;
+ __u16 config_counter;
+ );
};
#ifdef __KERNEL__
@@ -189,10 +192,12 @@ struct omap3isp_stat_data_time32 {
__s32 tv_usec;
} ts;
__u32 buf;
- __u32 buf_size;
- __u16 frame_number;
- __u16 cur_frame;
- __u16 config_counter;
+ __struct_group(/* no tag */, frame, /* no attrs */,
+ __u32 buf_size;
+ __u16 frame_number;
+ __u16 cur_frame;
+ __u16 config_counter;
+ );
};
#endif
--
2.30.2
The patch titled
Subject: mm/pgtable: define pte_index so that preprocessor could recognize it
has been added to the -mm tree. Its filename is
mm-pgtable-define-pte_index-so-that-preprocessor-could-recognize-it.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/mm-pgtable-define-pte_index-so-th…
and later at
https://ozlabs.org/~akpm/mmotm/broken-out/mm-pgtable-define-pte_index-so-th…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Mike Rapoport <rppt(a)linux.ibm.com>
Subject: mm/pgtable: define pte_index so that preprocessor could recognize it
Since commit 974b9b2c68f3 ("mm: consolidate pte_index() and pte_offset_*()
definitions") pte_index is a static inline and there is no define for it
that can be recognized by the preprocessor. As a result,
vm_insert_pages() uses slower loop over vm_insert_page() instead of
insert_pages() that amortizes the cost of spinlock operations when
inserting multiple pages.
Link: https://lkml.kernel.org/r/20220111145457.20748-1-rppt@kernel.org
Fixes: 974b9b2c68f3 ("mm: consolidate pte_index() and pte_offset_*() definitions")
Signed-off-by: Mike Rapoport <rppt(a)linux.ibm.com>
Reported-by: Christian Dietrich <stettberger(a)dokucode.de>
Reviewed-by: Khalid Aziz <khalid.aziz(a)oracle.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
include/linux/pgtable.h | 1 +
1 file changed, 1 insertion(+)
--- a/include/linux/pgtable.h~mm-pgtable-define-pte_index-so-that-preprocessor-could-recognize-it
+++ a/include/linux/pgtable.h
@@ -62,6 +62,7 @@ static inline unsigned long pte_index(un
{
return (address >> PAGE_SHIFT) & (PTRS_PER_PTE - 1);
}
+#define pte_index pte_index
#ifndef pmd_index
static inline unsigned long pmd_index(unsigned long address)
_
Patches currently in -mm which might be from rppt(a)linux.ibm.com are
mm-pgtable-define-pte_index-so-that-preprocessor-could-recognize-it.patch
The patch titled
Subject: coredump: also dump first pages of non-executable ELF libraries
has been added to the -mm tree. Its filename is
coredump-also-dump-first-pages-of-non-executable-elf-libraries.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/coredump-also-dump-first-pages-of…
and later at
https://ozlabs.org/~akpm/mmotm/broken-out/coredump-also-dump-first-pages-of…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Jann Horn <jannh(a)google.com>
Subject: coredump: also dump first pages of non-executable ELF libraries
When I rewrote the VMA dumping logic for coredumps, I changed it to
recognize ELF library mappings based on the file being executable instead
of the mapping having an ELF header. But turns out, distros ship many ELF
libraries as non-executable, so the heuristic goes wrong...
Restore the old behavior where FILTER(ELF_HEADERS) dumps the first page of
any offset-0 readable mapping that starts with the ELF magic.
This fix is technically layer-breaking a bit, because it checks for
something ELF-specific in fs/coredump.c; but since we probably want to
share this between standard ELF and FDPIC ELF anyway, I guess it's fine?
And this also keeps the change small for backporting.
Link: https://lkml.kernel.org/r/20220126025739.2014888-1-jannh@google.com
Fixes: 429a22e776a2 ("coredump: rework elf/elf_fdpic vma_dump_size() into c=
ommon helper")
Signed-off-by: Jann Horn <jannh(a)google.com>
Reported-by: Bill Messmer <wmessmer(a)microsoft.com>
Cc: "Eric W . Biederman" <ebiederm(a)xmission.com>
Cc: Al Viro <viro(a)zeniv.linux.org.uk>
Cc: Randy Dunlap <rdunlap(a)infradead.org>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/coredump.c | 39 ++++++++++++++++++++++++++++++++++-----
1 file changed, 34 insertions(+), 5 deletions(-)
--- a/fs/coredump.c~coredump-also-dump-first-pages-of-non-executable-elf-libraries
+++ a/fs/coredump.c
@@ -42,6 +42,7 @@
#include <linux/path.h>
#include <linux/timekeeping.h>
#include <linux/sysctl.h>
+#include <linux/elf.h>
#include <linux/uaccess.h>
#include <asm/mmu_context.h>
@@ -980,6 +981,8 @@ static bool always_dump_vma(struct vm_ar
return false;
}
+#define DUMP_SIZE_MAYBE_ELFHDR_PLACEHOLDER 1
+
/*
* Decide how much of @vma's contents should be included in a core dump.
*/
@@ -1039,9 +1042,20 @@ static unsigned long vma_dump_size(struc
* dump the first page to aid in determining what was mapped here.
*/
if (FILTER(ELF_HEADERS) &&
- vma->vm_pgoff == 0 && (vma->vm_flags & VM_READ) &&
- (READ_ONCE(file_inode(vma->vm_file)->i_mode) & 0111) != 0)
- return PAGE_SIZE;
+ vma->vm_pgoff == 0 && (vma->vm_flags & VM_READ)) {
+ if ((READ_ONCE(file_inode(vma->vm_file)->i_mode) & 0111) != 0)
+ return PAGE_SIZE;
+
+ /*
+ * ELF libraries aren't always executable.
+ * We'll want to check whether the mapping starts with the ELF
+ * magic, but not now - we're holding the mmap lock,
+ * so copy_from_user() doesn't work here.
+ * Use a placeholder instead, and fix it up later in
+ * dump_vma_snapshot().
+ */
+ return DUMP_SIZE_MAYBE_ELFHDR_PLACEHOLDER;
+ }
#undef FILTER
@@ -1116,8 +1130,6 @@ int dump_vma_snapshot(struct coredump_pa
m->end = vma->vm_end;
m->flags = vma->vm_flags;
m->dump_size = vma_dump_size(vma, cprm->mm_flags);
-
- vma_data_size += m->dump_size;
}
mmap_write_unlock(mm);
@@ -1127,6 +1139,23 @@ int dump_vma_snapshot(struct coredump_pa
return -EFAULT;
}
+ for (i = 0; i < *vma_count; i++) {
+ struct core_vma_metadata *m = (*vma_meta) + i;
+
+ if (m->dump_size == DUMP_SIZE_MAYBE_ELFHDR_PLACEHOLDER) {
+ char elfmag[SELFMAG];
+
+ if (copy_from_user(elfmag, (void __user *)m->start, SELFMAG) ||
+ memcmp(elfmag, ELFMAG, SELFMAG) != 0) {
+ m->dump_size = 0;
+ } else {
+ m->dump_size = PAGE_SIZE;
+ }
+ }
+
+ vma_data_size += m->dump_size;
+ }
+
*vma_data_size_ptr = vma_data_size;
return 0;
}
_
Patches currently in -mm which might be from jannh(a)google.com are
coredump-also-dump-first-pages-of-non-executable-elf-libraries.patch
The patch titled
Subject: mm/debug_vm_pgtable: remove pte entry from the page table
has been added to the -mm tree. Its filename is
mm-debug_vm_pgtable-remove-pte-entry-from-the-page-table.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/mm-debug_vm_pgtable-remove-pte-en…
and later at
https://ozlabs.org/~akpm/mmotm/broken-out/mm-debug_vm_pgtable-remove-pte-en…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Pasha Tatashin <pasha.tatashin(a)soleen.com>
Subject: mm/debug_vm_pgtable: remove pte entry from the page table
Patch series "page table check fixes and cleanups", v4.
Two fixes:
mm/debug_vm_pgtable: remove pte entry from the page table
- remove a pte entry from the page table at the end of
debug_vm_pgtable pte test
mm/khugepaged: unify collapse pmd clear, flush and free
mm/page_table_check: check entries at pmd levels
- check pmd level in page_table_check for PTE regular entries
prior to freeing.
repro.c: https://gist.github.com/soleen/fdcd501d5df103976245fe84e9535087
config: https://gist.github.com/soleen/8a56f923c2fea9ce9c75b4e2517d4162
qemu_script: https://gist.github.com/soleen/f4be4795826b7ab1a51ae659582e179c
base image:
https://storage.googleapis.com/syzkaller/wheezy.imghttps://storage.googleapis.com/syzkaller/wheezy.img.key
Small cleanup:
mm/page_table_check: use unsigned long for page counters and cleanup
This patch (of 4):
The pte entry that is used in pte_advanced_tests() is never removed from
the page table at the end of the test.
The issue is detected by page_table_check, to repro compile kernel with
the following configs:
CONFIG_DEBUG_VM_PGTABLE=y
CONFIG_PAGE_TABLE_CHECK=y
CONFIG_PAGE_TABLE_CHECK_ENFORCED=y
During the boot the following BUG is printed:
[ 2.262821] debug_vm_pgtable: [debug_vm_pgtable ]: Validating
architecture page table helpers
[ 2.276826] ------------[ cut here ]------------
[ 2.280426] kernel BUG at mm/page_table_check.c:162!
[ 2.284118] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[ 2.287787] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
5.16.0-11413-g2c271fe77d52 #3
[ 2.293226] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org
04/01/2014
...
The entry should be properly removed from the page table before the page
is released to the free list.
Link: https://lkml.kernel.org/r/20220126183637.1840960-2-pasha.tatashin@soleen.com
Fixes: a5c3b9ffb0f4 ("mm/debug_vm_pgtable: add tests validating advanced arch page table helpers")
Signed-off-by: Pasha Tatashin <pasha.tatashin(a)soleen.com>
Reviewed-by: Zi Yan <ziy(a)nvidia.com>
Tested-by: Zi Yan <ziy(a)nvidia.com>
Acked-by: David Rientjes <rientjes(a)google.com>
Cc: Paul Turner <pjt(a)google.com>
Cc: Wei Xu <weixugc(a)google.com>
Cc: Greg Thelen <gthelen(a)google.com>
Cc: Ingo Molnar <mingo(a)redhat.com>
Cc: Will Deacon <will(a)kernel.org>
Cc: Mike Rapoport <rppt(a)kernel.org>
Cc: Dave Hansen <dave.hansen(a)linux.intel.com>
Cc: H. Peter Anvin <hpa(a)zytor.com>
Cc: Aneesh Kumar K.V <aneesh.kumar(a)linux.ibm.com>
Cc: Jiri Slaby <jirislaby(a)kernel.org>
Cc: Muchun Song <songmuchun(a)bytedance.com>
Cc: Hugh Dickins <hughd(a)google.com>
Cc: Anshuman Khandual <anshuman.khandual(a)arm.com>
Cc: <stable(a)vger.kernel.org> [5.9+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/debug_vm_pgtable.c | 2 ++
1 file changed, 2 insertions(+)
--- a/mm/debug_vm_pgtable.c~mm-debug_vm_pgtable-remove-pte-entry-from-the-page-table
+++ a/mm/debug_vm_pgtable.c
@@ -171,6 +171,8 @@ static void __init pte_advanced_tests(st
ptep_test_and_clear_young(args->vma, args->vaddr, args->ptep);
pte = ptep_get(args->ptep);
WARN_ON(pte_young(pte));
+
+ ptep_get_and_clear_full(args->mm, args->vaddr, args->ptep, 1);
}
static void __init pte_savedwrite_tests(struct pgtable_debug_args *args)
_
Patches currently in -mm which might be from pasha.tatashin(a)soleen.com are
mm-debug_vm_pgtable-remove-pte-entry-from-the-page-table.patch
mm-page_table_check-use-unsigned-long-for-page-counters-and-cleanup.patch
mm-khugepaged-unify-collapse-pmd-clear-flush-and-free.patch
mm-page_table_check-check-entries-at-pmd-levels.patch
The patch titled
Subject: fs/exec: require argv[0] presence in do_execveat_common()
has been added to the -mm tree. Its filename is
fs-exec-require-argv-presence-in-do_execveat_common.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/fs-exec-require-argv-presence-in-…
and later at
https://ozlabs.org/~akpm/mmotm/broken-out/fs-exec-require-argv-presence-in-…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Ariadne Conill <ariadne(a)dereferenced.org>
Subject: fs/exec: require argv[0] presence in do_execveat_common()
In several other operating systems, it is a hard requirement that the
second argument to execve(2) be the name of a program, thus prohibiting a
scenario where argc < 1. POSIX 2017 also recommends this behaviour, but
it is not an explicit requirement[0]:
The argument arg0 should point to a filename string that is
associated with the process being started by one of the exec
functions.
To ensure that execve(2) with argc < 1 is not a useful tool for shellcode
to use, we can validate this in do_execveat_common() and fail for this
scenario, effectively blocking successful exploitation of CVE-2021-4034
and similar bugs which depend on execve(2) working with argc < 1.
We use -EINVAL for this case, mirroring recent changes to FreeBSD and
OpenBSD. -EINVAL is also used by QNX for this, while Solaris uses
-EFAULT.
In earlier versions of the patch, it was proposed that we create a fake
argv for applications to use when argc < 1, but it was concluded that it
would be better to just fail the execve(2) in these cases, as launching a
process with an empty or NULL argv[0] was likely to just cause more
problems.
Interestingly, Michael Kerrisk opened an issue about this in 2008[1], but
there was no consensus to support fixing this issue then. Hopefully now
that CVE-2021-4034 shows practical exploitative use[2] of this bug in a
shellcode, we can reconsider.
This issue is being tracked in the KSPP issue tracker[3].
There are a few[4][5] minor edge cases (primarily in test suites) that are
caught by this, but we plan to work with the projects to fix those edge
cases.
[0]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=8408
[2]: https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt
[3]: https://github.com/KSPP/linux/issues/176
[4]: https://codesearch.debian.net/search?q=execve%5C+*%5C%28%5B%5E%2C%5D%2B%2C+…
[5]: https://codesearch.debian.net/search?q=execlp%3F%5Cs*%5C%28%5B%5E%2C%5D%2B%…
Link: https://lkml.kernel.org/r/20220127000724.15106-1-ariadne@dereferenced.org
Signed-off-by: Ariadne Conill <ariadne(a)dereferenced.org>
Reported-by: Michael Kerrisk <mtk.manpages(a)gmail.com>
Cc: Matthew Wilcox <willy(a)infradead.org>
Cc: Christian Brauner <brauner(a)kernel.org>
Cc: Rich Felker <dalias(a)libc.org>
Cc: Eric Biederman <ebiederm(a)xmission.com>
Cc: Alexander Viro <viro(a)zeniv.linux.org.uk>
Cc: Kees Cook <keescook(a)chromium.org>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/exec.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/fs/exec.c~fs-exec-require-argv-presence-in-do_execveat_common
+++ a/fs/exec.c
@@ -1897,6 +1897,10 @@ static int do_execveat_common(int fd, st
}
retval = count(argv, MAX_ARG_STRINGS);
+ if (retval == 0) {
+ pr_warn_once("Attempted to run process '%s' with NULL argv\n", bprm->filename);
+ retval = -EINVAL;
+ }
if (retval < 0)
goto out_free;
bprm->argc = retval;
_
Patches currently in -mm which might be from ariadne(a)dereferenced.org are
fs-exec-require-argv-presence-in-do_execveat_common.patch
--
Good Day,
I'm Mr. Ali Moses, how are you doing hope you are in good health, the
Board director try to reach you on phone several times Meanwhile, your
number was not connecting. before he ask me to send you an email to
hear from you if you are fine. hoping to hear from you soonest.
Thanks
Mr. Ali Moses
Sincerely
Dr. Irene Lam
The backport to 5.10.92:
commit c39d68ab3836 ("md: revert io stats accounting") is slightly
different with upstream, remove unrelated change to be in sync
with upstream.
Cc: Guoqing Jiang <guoqing.jiang(a)linux.dev>
Cc: Song Liu <song(a)kernel.org>
Cc: Guillaume Morin <guillaume(a)morinfr.org>
Signed-off-by: Jack Wang <jinpu.wang(a)ionos.com>
---
drivers/md/md.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index cc3876500c4b..887f07beed1b 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -485,21 +485,11 @@ static blk_qc_t md_submit_bio(struct bio *bio)
return BLK_QC_T_NONE;
}
- /*
- * save the sectors now since our bio can
- * go away inside make_request
- */
- sectors = bio_sectors(bio);
/* bio could be mergeable after passing to underlayer */
bio->bi_opf &= ~REQ_NOMERGE;
md_handle_request(mddev, bio);
- part_stat_lock();
- part_stat_inc(&mddev->gendisk->part0, ios[sgrp]);
- part_stat_add(&mddev->gendisk->part0, sectors[sgrp], sectors);
- part_stat_unlock();
-
return BLK_QC_T_NONE;
}
--
2.25.1
This is the start of the stable review cycle for the 5.10.92 release.
There are 25 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 Sun, 16 Jan 2022 08:15:33 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.92-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 5.10.92-rc1
Arnd Bergmann <arnd(a)arndb.de>
staging: greybus: fix stack size warning with UBSAN
Nathan Chancellor <nathan(a)kernel.org>
drm/i915: Avoid bitwise vs logical OR warning in snb_wm_latency_quirk()
Nathan Chancellor <nathan(a)kernel.org>
staging: wlan-ng: Avoid bitwise vs logical OR warning in hfa384x_usb_throttlefn()
Ricardo Ribalda <ribalda(a)chromium.org>
media: Revert "media: uvcvideo: Set unique vdev name based in type"
Dominik Brodowski <linux(a)dominikbrodowski.net>
random: fix crash on multiple early calls to add_bootloader_randomness()
Eric Biggers <ebiggers(a)google.com>
random: fix data race on crng init time
Eric Biggers <ebiggers(a)google.com>
random: fix data race on crng_node_pool
Brian Silverman <brian.silverman(a)bluerivertech.com>
can: gs_usb: gs_can_start_xmit(): zero-initialize hf->{flags,reserved}
Marc Kleine-Budde <mkl(a)pengutronix.de>
can: isotp: convert struct tpcon::{idx,len} to unsigned int
Marc Kleine-Budde <mkl(a)pengutronix.de>
can: gs_usb: fix use of uninitialized variable, detach device on reception of invalid USB data
Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
mfd: intel-lpss: Fix too early PM enablement in the ACPI ->probe()
Daniel Borkmann <daniel(a)iogearbox.net>
veth: Do not record rx queue hint in veth_xmit
Adrian Hunter <adrian.hunter(a)intel.com>
mmc: sdhci-pci: Add PCI ID for Intel ADL
Sven Eckelmann <sven(a)narfation.org>
ath11k: Fix buffer overflow when scanning with extraie
Alan Stern <stern(a)rowland.harvard.edu>
USB: Fix "slab-out-of-bounds Write" bug in usb_hcd_poll_rh_status
Alan Stern <stern(a)rowland.harvard.edu>
USB: core: Fix bug in resuming hub's handling of wakeup requests
Paul Cercueil <paul(a)crapouillou.net>
ARM: dts: exynos: Fix BCM4330 Bluetooth reset polarity in I9100
Johan Hovold <johan(a)kernel.org>
Bluetooth: bfusb: fix division by zero in send path
Aaron Ma <aaron.ma(a)canonical.com>
Bluetooth: btusb: Add support for Foxconn QCA 0xe0d0
Aaron Ma <aaron.ma(a)canonical.com>
Bluetooth: btusb: Add support for Foxconn MT7922A
Zijun Hu <quic_zijuhu(a)quicinc.com>
Bluetooth: btusb: Add two more Bluetooth parts for WCN6855
Mark-YW.Chen <mark-yw.chen(a)mediatek.com>
Bluetooth: btusb: fix memory leak in btusb_mtk_submit_wmt_recv_urb()
Daniel Borkmann <daniel(a)iogearbox.net>
bpf: Fix out of bounds access from invalid *_or_null type verification
Frederic Weisbecker <frederic(a)kernel.org>
workqueue: Fix unbind_workers() VS wq_worker_running() race
Guoqing Jiang <jgq516(a)gmail.com>
md: revert io stats accounting
-------------
Diffstat:
Makefile | 4 +-
arch/arm/boot/dts/exynos4210-i9100.dts | 2 +-
drivers/bluetooth/bfusb.c | 3 +
drivers/bluetooth/btusb.c | 22 ++++++
drivers/char/random.c | 117 ++++++++++++++++++-------------
drivers/gpu/drm/i915/intel_pm.c | 6 +-
drivers/md/md.c | 57 ++++-----------
drivers/md/md.h | 1 -
drivers/media/usb/uvc/uvc_driver.c | 7 +-
drivers/mfd/intel-lpss-acpi.c | 7 +-
drivers/mmc/host/sdhci-pci-core.c | 1 +
drivers/mmc/host/sdhci-pci.h | 1 +
drivers/net/can/usb/gs_usb.c | 5 +-
drivers/net/veth.c | 1 -
drivers/net/wireless/ath/ath11k/wmi.c | 6 +-
drivers/staging/greybus/audio_topology.c | 92 ++++++++++++------------
drivers/staging/wlan-ng/hfa384x_usb.c | 22 +++---
drivers/usb/core/hcd.c | 9 ++-
drivers/usb/core/hub.c | 2 +-
kernel/bpf/verifier.c | 6 +-
kernel/workqueue.c | 9 +++
net/can/isotp.c | 4 +-
22 files changed, 207 insertions(+), 177 deletions(-)
Greetings,
I sent this mail praying it will find you in a good condition, since I
myself am in a very critical health condition in which I sleep every
night without knowing if I may be alive to see the next day. I am
Mrs.Anderson Theresa, a widow suffering from a long time illness. I
have some funds I inherited from my late husband, the sum of
($11,000,000.00, Eleven Million Dollars) my Doctor told me recently
that I have serious sickness which is a cancer problem. What disturbs
me most is my stroke sickness. Having known my condition, I decided to
donate this fund to a good person that will utilize it the way I am
going to instruct herein. I need a very honest God.
fearing a person who can claim this money and use it for Charity
works, for orphanages, widows and also build schools for less
privileges that will be named after my late husband if possible and to
promote the word of God and the effort that the house of God is
maintained. I do not want a situation where this money will be used in
an ungodly manner. That's why I' making this decision. I'm not afraid
of death so I know where I'm going. I accept this decision because I
do not have any child who will inherit this money after I die. Please
I want your sincere and urgent answer to know if you will be able to
execute this project, and I will give you more information on how the
fund will be transferred to your bank account. I am waiting for your
reply.
May God Bless you,
Mrs.Anderson Theresa,
In ex_handler_load_unaligned_zeropad() we erroneously extract the data and
addr register indices from ex->type rather than ex->data. As ex->type will
contain EX_TYPE_LOAD_UNALIGNED_ZEROPAD (i.e. 4):
* We'll always treat X0 as the address register, since EX_DATA_REG_ADDR is
extracted from bits [9:5]. Thus, we may attempt to dereference an
arbitrary address as X0 may hold an arbitrary value.
* We'll always treat X4 as the data register, since EX_DATA_REG_DATA is
extracted from bits [4:0]. Thus we will corrupt X4 and cause arbitrary
behaviour within load_unaligned_zeropad() and its caller.
Fix this by extracting both values from ex->data as originally intended.
On an MTE-enabled QEMU image we are hitting the following crash:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
Call trace:
fixup_exception+0xc4/0x108
__do_kernel_fault+0x3c/0x268
do_tag_check_fault+0x3c/0x104
do_mem_abort+0x44/0xf4
el1_abort+0x40/0x64
el1h_64_sync_handler+0x60/0xa0
el1h_64_sync+0x7c/0x80
link_path_walk+0x150/0x344
path_openat+0xa0/0x7dc
do_filp_open+0xb8/0x168
do_sys_openat2+0x88/0x17c
__arm64_sys_openat+0x74/0xa0
invoke_syscall+0x48/0x148
el0_svc_common+0xb8/0xf8
do_el0_svc+0x28/0x88
el0_svc+0x24/0x84
el0t_64_sync_handler+0x88/0xec
el0t_64_sync+0x1b4/0x1b8
Code: f8695a69 71007d1f 540000e0 927df12a (f940014a)
Fixes: 753b32368705 ("arm64: extable: add load_unaligned_zeropad() handler")
Cc: <stable(a)vger.kernel.org> # 5.16.x
Reviewed-by: Mark Rutland <mark.rutland(a)arm.com>
Signed-off-by: Evgenii Stepanov <eugenis(a)google.com>
---
arch/arm64/mm/extable.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/mm/extable.c b/arch/arm64/mm/extable.c
index c0181e60cc98..489455309695 100644
--- a/arch/arm64/mm/extable.c
+++ b/arch/arm64/mm/extable.c
@@ -40,8 +40,8 @@ static bool
ex_handler_load_unaligned_zeropad(const struct exception_table_entry *ex,
struct pt_regs *regs)
{
- int reg_data = FIELD_GET(EX_DATA_REG_DATA, ex->type);
- int reg_addr = FIELD_GET(EX_DATA_REG_ADDR, ex->type);
+ int reg_data = FIELD_GET(EX_DATA_REG_DATA, ex->data);
+ int reg_addr = FIELD_GET(EX_DATA_REG_ADDR, ex->data);
unsigned long data, addr, offset;
addr = pt_regs_read_reg(regs, reg_addr);
--
2.35.0.rc0.227.g00780c9af4-goog
In uniphier_spi_remove(), there is a wrong code to get private data from
the platform device, so the driver can't be removed properly.
The driver should get spi_master from the platform device and retrieve
the private data from it.
Cc: <stable(a)vger.kernel.org>
Fixes: 5ba155a4d4cc ("spi: add SPI controller driver for UniPhier SoC")
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko(a)socionext.com>
---
drivers/spi/spi-uniphier.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/spi/spi-uniphier.c b/drivers/spi/spi-uniphier.c
index 8900e51e1a1c..342ee8d2c476 100644
--- a/drivers/spi/spi-uniphier.c
+++ b/drivers/spi/spi-uniphier.c
@@ -767,12 +767,13 @@ static int uniphier_spi_probe(struct platform_device *pdev)
static int uniphier_spi_remove(struct platform_device *pdev)
{
- struct uniphier_spi_priv *priv = platform_get_drvdata(pdev);
+ struct spi_master *master = platform_get_drvdata(pdev);
+ struct uniphier_spi_priv *priv = spi_master_get_devdata(master);
- if (priv->master->dma_tx)
- dma_release_channel(priv->master->dma_tx);
- if (priv->master->dma_rx)
- dma_release_channel(priv->master->dma_rx);
+ if (master->dma_tx)
+ dma_release_channel(master->dma_tx);
+ if (master->dma_rx)
+ dma_release_channel(master->dma_rx);
clk_disable_unprepare(priv->clk);
--
2.7.4
hello greg,
compile failed for 5.16.3-rc2 related.
a relevent file attached.
Tested-by : Jeffrin Jose T <jeffrin(a)rajagiritech.edu.in>
--
software engineer
rajagiri school of engineering and technology - autonomous
Vijay reported that the "unclobbered_vdso_oversubscribed" selftest
triggers the softlockup detector.
Actual SGX systems have 128GB of enclave memory or more. The
"unclobbered_vdso_oversubscribed" selftest creates one enclave which
consumes all of the enclave memory on the system. Tearing down such a
large enclave takes around a minute, most of it in the loop where
the EREMOVE instruction is applied to each individual 4k enclave page.
Spending one minute in a loop triggers the softlockup detector.
Add a cond_resched() to give other tasks a chance to run and placate
the softlockup detector.
Cc: stable(a)vger.kernel.org
Fixes: 1728ab54b4be ("x86/sgx: Add a page reclaimer")
Reported-by: Vijay Dhanraj <vijay.dhanraj(a)intel.com>
Acked-by: Dave Hansen <dave.hansen(a)linux.intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre(a)intel.com>
---
Softlockup message:
watchdog: BUG: soft lockup - CPU#7 stuck for 22s! [test_sgx:11502]
Kernel panic - not syncing: softlockup: hung tasks
<snip>
sgx_encl_release+0x86/0x1c0
sgx_release+0x11c/0x130
__fput+0xb0/0x280
____fput+0xe/0x10
task_work_run+0x6c/0xc0
exit_to_user_mode_prepare+0x1eb/0x1f0
syscall_exit_to_user_mode+0x1d/0x50
do_syscall_64+0x46/0xb0
entry_SYSCALL_64_after_hwframe+0x44/0xae
Changes since V1:
- V1: https://lore.kernel.org/lkml/1aa037705e5aa209d8b7a075873c6b4190327436.16425…
- Add comment provided by Jarkko.
arch/x86/kernel/cpu/sgx/encl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
index 001808e3901c..48afe96ae0f0 100644
--- a/arch/x86/kernel/cpu/sgx/encl.c
+++ b/arch/x86/kernel/cpu/sgx/encl.c
@@ -410,6 +410,8 @@ void sgx_encl_release(struct kref *ref)
}
kfree(entry);
+ /* Invoke scheduler to prevent soft lockups. */
+ cond_resched();
}
xa_destroy(&encl->page_array);
--
2.25.1
Vijay reported that the "unclobbered_vdso_oversubscribed" selftest
triggers the softlockup detector.
Actual SGX systems have 128GB of enclave memory or more. The
"unclobbered_vdso_oversubscribed" selftest creates one enclave which
consumes all of the enclave memory on the system. Tearing down such a
large enclave takes around a minute, most of it in the loop where
the EREMOVE instruction is applied to each individual 4k enclave page.
Spending one minute in a loop triggers the softlockup detector.
Add a cond_resched() to give other tasks a chance to run and placate
the softlockup detector.
Cc: stable(a)vger.kernel.org
Fixes: 1728ab54b4be ("x86/sgx: Add a page reclaimer")
Reported-by: Vijay Dhanraj <vijay.dhanraj(a)intel.com>
Acked-by: Dave Hansen <dave.hansen(a)linux.intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre(a)intel.com>
---
Softlockup message:
watchdog: BUG: soft lockup - CPU#7 stuck for 22s! [test_sgx:11502]
Kernel panic - not syncing: softlockup: hung tasks
<snip>
sgx_encl_release+0x86/0x1c0
sgx_release+0x11c/0x130
__fput+0xb0/0x280
____fput+0xe/0x10
task_work_run+0x6c/0xc0
exit_to_user_mode_prepare+0x1eb/0x1f0
syscall_exit_to_user_mode+0x1d/0x50
do_syscall_64+0x46/0xb0
entry_SYSCALL_64_after_hwframe+0x44/0xae
arch/x86/kernel/cpu/sgx/encl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
index 001808e3901c..ab2b79327a8a 100644
--- a/arch/x86/kernel/cpu/sgx/encl.c
+++ b/arch/x86/kernel/cpu/sgx/encl.c
@@ -410,6 +410,7 @@ void sgx_encl_release(struct kref *ref)
}
kfree(entry);
+ cond_resched();
}
xa_destroy(&encl->page_array);
--
2.25.1
Fix a user API regression introduced with commit f76edd8f7ce0 ("tty:
cyclades, remove this orphan"), which removed a part of the API and
caused compilation errors for user programs using said part, such as
GCC 9 in its libsanitizer component[1]:
.../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:160:10: fatal error: linux/cyclades.h: No such file or directory
160 | #include <linux/cyclades.h>
| ^~~~~~~~~~~~~~~~~~
compilation terminated.
make[4]: *** [Makefile:664: sanitizer_platform_limits_posix.lo] Error 1
As the absolute minimum required bring `struct cyclades_monitor' and
ioctl numbers back then so as to make the library build again. Add a
preprocessor warning as to the obsolescence of the features provided.
References:
[1] GCC PR sanitizer/100379, "cyclades.h is removed from linux kernel
header files", <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100379>
Signed-off-by: Maciej W. Rozycki <macro(a)embecosm.com>
Fixes: f76edd8f7ce0 ("tty: cyclades, remove this orphan")
Cc: stable(a)vger.kernel.org # v5.13+
---
Changes from v2:
- Add #warning directives.
Changes from v1:
- Adjust heading from "tty: Revert the removal of the Cyclades public API".
- Only revert `struct cyclades_monitor' and ioctl numbers.
- Properly format the change given that it's not a plain revert anymore.
---
include/uapi/linux/cyclades.h | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
linux-uapi-cyclades.diff
Index: linux/include/uapi/linux/cyclades.h
===================================================================
--- /dev/null
+++ linux/include/uapi/linux/cyclades.h
@@ -0,0 +1,35 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+
+#ifndef _UAPI_LINUX_CYCLADES_H
+#define _UAPI_LINUX_CYCLADES_H
+
+#warning "Support for features provided by this header has been removed"
+#warning "Please consider updating your code"
+
+struct cyclades_monitor {
+ unsigned long int_count;
+ unsigned long char_count;
+ unsigned long char_max;
+ unsigned long char_last;
+};
+
+#define CYGETMON 0x435901
+#define CYGETTHRESH 0x435902
+#define CYSETTHRESH 0x435903
+#define CYGETDEFTHRESH 0x435904
+#define CYSETDEFTHRESH 0x435905
+#define CYGETTIMEOUT 0x435906
+#define CYSETTIMEOUT 0x435907
+#define CYGETDEFTIMEOUT 0x435908
+#define CYSETDEFTIMEOUT 0x435909
+#define CYSETRFLOW 0x43590a
+#define CYGETRFLOW 0x43590b
+#define CYSETRTSDTR_INV 0x43590c
+#define CYGETRTSDTR_INV 0x43590d
+#define CYZSETPOLLCYCLE 0x43590e
+#define CYZGETPOLLCYCLE 0x43590f
+#define CYGETCD1400VER 0x435910
+#define CYSETWAIT 0x435912
+#define CYGETWAIT 0x435913
+
+#endif /* _UAPI_LINUX_CYCLADES_H */
From: Eric Biggers <ebiggers(a)google.com>
In many cases, keyctl_pkey_params_get_2() is validating the user buffer
lengths against the wrong algorithm properties. Fix it to check against
the correct properties.
Probably this wasn't noticed before because for all asymmetric keys of
the "public_key" subtype, max_data_size == max_sig_size == max_enc_size
== max_dec_size. However, this isn't necessarily true for the
"asym_tpm" subtype (it should be, but it's not strictly validated). Of
course, future key types could have different values as well.
Fixes: 00d60fd3b932 ("KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver #2]")
Cc: <stable(a)vger.kernel.org> # v4.20+
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
---
security/keys/keyctl_pkey.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/security/keys/keyctl_pkey.c b/security/keys/keyctl_pkey.c
index 5de0d599a274..97bc27bbf079 100644
--- a/security/keys/keyctl_pkey.c
+++ b/security/keys/keyctl_pkey.c
@@ -135,15 +135,23 @@ static int keyctl_pkey_params_get_2(const struct keyctl_pkey_params __user *_par
switch (op) {
case KEYCTL_PKEY_ENCRYPT:
+ if (uparams.in_len > info.max_dec_size ||
+ uparams.out_len > info.max_enc_size)
+ return -EINVAL;
+ break;
case KEYCTL_PKEY_DECRYPT:
if (uparams.in_len > info.max_enc_size ||
uparams.out_len > info.max_dec_size)
return -EINVAL;
break;
case KEYCTL_PKEY_SIGN:
+ if (uparams.in_len > info.max_data_size ||
+ uparams.out_len > info.max_sig_size)
+ return -EINVAL;
+ break;
case KEYCTL_PKEY_VERIFY:
- if (uparams.in_len > info.max_sig_size ||
- uparams.out_len > info.max_data_size)
+ if (uparams.in_len > info.max_data_size ||
+ uparams.in2_len > info.max_sig_size)
return -EINVAL;
break;
default:
@@ -151,7 +159,7 @@ static int keyctl_pkey_params_get_2(const struct keyctl_pkey_params __user *_par
}
params->in_len = uparams.in_len;
- params->out_len = uparams.out_len;
+ params->out_len = uparams.out_len; /* Note: same as in2_len */
return 0;
}
base-commit: feb7a43de5ef625ad74097d8fd3481d5dbc06a59
--
2.34.1
The patch below does not apply to the 5.16-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From ea6fa4961aab8f90a8aa03575a98b4bda368d4b6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mateusz=20Jo=C5=84czyk?= <mat.jonczyk(a)o2.pl>
Date: Fri, 10 Dec 2021 21:01:26 +0100
Subject: [PATCH] rtc: mc146818-lib: fix RTC presence check
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
To prevent an infinite loop in mc146818_get_time(),
commit 211e5db19d15 ("rtc: mc146818: Detect and handle broken RTCs")
added a check for RTC availability. Together with a later fix, it
checked if bit 6 in register 0x0d is cleared.
This, however, caused a false negative on a motherboard with an AMD
SB710 southbridge; according to the specification [1], bit 6 of register
0x0d of this chipset is a scratchbit. This caused a regression in Linux
5.11 - the RTC was determined broken by the kernel and not used by
rtc-cmos.c [3]. This problem was also reported in Fedora [4].
As a better alternative, check whether the UIP ("Update-in-progress")
bit is set for longer then 10ms. If that is the case, then apparently
the RTC is either absent (and all register reads return 0xff) or broken.
Also limit the number of loop iterations in mc146818_get_time() to 10 to
prevent an infinite loop there.
The functions mc146818_get_time() and mc146818_does_rtc_work() will be
refactored later in this patch series, in order to fix a separate
problem with reading / setting the RTC alarm time. This is done so to
avoid a confusion about what is being fixed when.
In a previous approach to this problem, I implemented a check whether
the RTC_HOURS register contains a value <= 24. This, however, sometimes
did not work correctly on my Intel Kaby Lake laptop. According to
Intel's documentation [2], "the time and date RAM locations (0-9) are
disconnected from the external bus" during the update cycle so reading
this register without checking the UIP bit is incorrect.
[1] AMD SB700/710/750 Register Reference Guide, page 308,
https://developer.amd.com/wordpress/media/2012/10/43009_sb7xx_rrg_pub_1.00.…
[2] 7th Generation Intel ® Processor Family I/O for U/Y Platforms [...] Datasheet
Volume 1 of 2, page 209
Intel's Document Number: 334658-006,
https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/7th…
[3] Functions in arch/x86/kernel/rtc.c apparently were using it.
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1936688
Fixes: 211e5db19d15 ("rtc: mc146818: Detect and handle broken RTCs")
Fixes: ebb22a059436 ("rtc: mc146818: Dont test for bit 0-5 in Register D")
Signed-off-by: Mateusz Jończyk <mat.jonczyk(a)o2.pl>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Alessandro Zummo <a.zummo(a)towertech.it>
Cc: Alexandre Belloni <alexandre.belloni(a)bootlin.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni(a)bootlin.com>
Link: https://lore.kernel.org/r/20211210200131.153887-5-mat.jonczyk@o2.pl
diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index d0f58cca5c20..b90a603d6b12 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -800,16 +800,14 @@ cmos_do_probe(struct device *dev, struct resource *ports, int rtc_irq)
rename_region(ports, dev_name(&cmos_rtc.rtc->dev));
- spin_lock_irq(&rtc_lock);
-
- /* Ensure that the RTC is accessible. Bit 6 must be 0! */
- if ((CMOS_READ(RTC_VALID) & 0x40) != 0) {
- spin_unlock_irq(&rtc_lock);
- dev_warn(dev, "not accessible\n");
+ if (!mc146818_does_rtc_work()) {
+ dev_warn(dev, "broken or not accessible\n");
retval = -ENXIO;
goto cleanup1;
}
+ spin_lock_irq(&rtc_lock);
+
if (!(flags & CMOS_RTC_FLAGS_NOFREQ)) {
/* force periodic irq to CMOS reset default of 1024Hz;
*
diff --git a/drivers/rtc/rtc-mc146818-lib.c b/drivers/rtc/rtc-mc146818-lib.c
index ccd974b8a75a..d8e67a01220e 100644
--- a/drivers/rtc/rtc-mc146818-lib.c
+++ b/drivers/rtc/rtc-mc146818-lib.c
@@ -8,10 +8,36 @@
#include <linux/acpi.h>
#endif
+/*
+ * If the UIP (Update-in-progress) bit of the RTC is set for more then
+ * 10ms, the RTC is apparently broken or not present.
+ */
+bool mc146818_does_rtc_work(void)
+{
+ int i;
+ unsigned char val;
+ unsigned long flags;
+
+ for (i = 0; i < 10; i++) {
+ spin_lock_irqsave(&rtc_lock, flags);
+ val = CMOS_READ(RTC_FREQ_SELECT);
+ spin_unlock_irqrestore(&rtc_lock, flags);
+
+ if ((val & RTC_UIP) == 0)
+ return true;
+
+ mdelay(1);
+ }
+
+ return false;
+}
+EXPORT_SYMBOL_GPL(mc146818_does_rtc_work);
+
unsigned int mc146818_get_time(struct rtc_time *time)
{
unsigned char ctrl;
unsigned long flags;
+ unsigned int iter_count = 0;
unsigned char century = 0;
bool retry;
@@ -20,13 +46,13 @@ unsigned int mc146818_get_time(struct rtc_time *time)
#endif
again:
- spin_lock_irqsave(&rtc_lock, flags);
- /* Ensure that the RTC is accessible. Bit 6 must be 0! */
- if (WARN_ON_ONCE((CMOS_READ(RTC_VALID) & 0x40) != 0)) {
- spin_unlock_irqrestore(&rtc_lock, flags);
+ if (iter_count > 10) {
memset(time, 0, sizeof(*time));
return -EIO;
}
+ iter_count++;
+
+ spin_lock_irqsave(&rtc_lock, flags);
/*
* Check whether there is an update in progress during which the
diff --git a/include/linux/mc146818rtc.h b/include/linux/mc146818rtc.h
index 0661af17a758..69c80c4325bf 100644
--- a/include/linux/mc146818rtc.h
+++ b/include/linux/mc146818rtc.h
@@ -123,6 +123,7 @@ struct cmos_rtc_board_info {
#define RTC_IO_EXTENT_USED RTC_IO_EXTENT
#endif /* ARCH_RTC_LOCATION */
+bool mc146818_does_rtc_work(void);
unsigned int mc146818_get_time(struct rtc_time *time);
int mc146818_set_time(struct rtc_time *time);
This is a note to let you know that I've just added the patch titled
serial: stm32: prevent TDR register overwrite when sending x_char
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
From d3d079bde07e1b7deaeb57506dc0b86010121d17 Mon Sep 17 00:00:00 2001
From: Valentin Caron <valentin.caron(a)foss.st.com>
Date: Tue, 11 Jan 2022 17:44:40 +0100
Subject: serial: stm32: prevent TDR register overwrite when sending x_char
When sending x_char in stm32_usart_transmit_chars(), driver can overwrite
the value of TDR register by the value of x_char. If this happens, the
previous value that was present in TDR register will not be sent through
uart.
This code checks if the previous value in TDR register is sent before
writing the x_char value into register.
Fixes: 48a6092fb41f ("serial: stm32-usart: Add STM32 USART Driver")
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Valentin Caron <valentin.caron(a)foss.st.com>
Link: https://lore.kernel.org/r/20220111164441.6178-2-valentin.caron@foss.st.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/stm32-usart.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
index 1f89ab0e49ac..c1b8828451c8 100644
--- a/drivers/tty/serial/stm32-usart.c
+++ b/drivers/tty/serial/stm32-usart.c
@@ -550,11 +550,23 @@ static void stm32_usart_transmit_chars(struct uart_port *port)
struct stm32_port *stm32_port = to_stm32_port(port);
const struct stm32_usart_offsets *ofs = &stm32_port->info->ofs;
struct circ_buf *xmit = &port->state->xmit;
+ u32 isr;
+ int ret;
if (port->x_char) {
if (stm32_usart_tx_dma_started(stm32_port) &&
stm32_usart_tx_dma_enabled(stm32_port))
stm32_usart_clr_bits(port, ofs->cr3, USART_CR3_DMAT);
+
+ /* Check that TDR is empty before filling FIFO */
+ ret =
+ readl_relaxed_poll_timeout_atomic(port->membase + ofs->isr,
+ isr,
+ (isr & USART_SR_TXE),
+ 10, 1000);
+ if (ret)
+ dev_warn(port->dev, "1 character may be erased\n");
+
writel_relaxed(port->x_char, port->membase + ofs->tdr);
port->x_char = 0;
port->icount.tx++;
--
2.35.0
This is a note to let you know that I've just added the patch titled
serial: stm32: fix software flow control transfer
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
From 037b91ec7729524107982e36ec4b40f9b174f7a2 Mon Sep 17 00:00:00 2001
From: Valentin Caron <valentin.caron(a)foss.st.com>
Date: Tue, 11 Jan 2022 17:44:41 +0100
Subject: serial: stm32: fix software flow control transfer
x_char is ignored by stm32_usart_start_tx() when xmit buffer is empty.
Fix start_tx condition to allow x_char to be sent.
Fixes: 48a6092fb41f ("serial: stm32-usart: Add STM32 USART Driver")
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Erwan Le Ray <erwan.leray(a)foss.st.com>
Signed-off-by: Valentin Caron <valentin.caron(a)foss.st.com>
Link: https://lore.kernel.org/r/20220111164441.6178-3-valentin.caron@foss.st.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/stm32-usart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
index c1b8828451c8..9570002d07e7 100644
--- a/drivers/tty/serial/stm32-usart.c
+++ b/drivers/tty/serial/stm32-usart.c
@@ -742,7 +742,7 @@ static void stm32_usart_start_tx(struct uart_port *port)
struct serial_rs485 *rs485conf = &port->rs485;
struct circ_buf *xmit = &port->state->xmit;
- if (uart_circ_empty(xmit))
+ if (uart_circ_empty(xmit) && !port->x_char)
return;
if (rs485conf->flags & SER_RS485_ENABLED) {
--
2.35.0
n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010.
See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.…
The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to
the newer 27.010 here. Chapter 5.2.7.3 states that DC1 (XON) and DC3 (XOFF)
are the control characters defined in ISO/IEC 646. These shall be quoted if
seen in the data stream to avoid interpretation as flow control characters.
ISO/IEC 646 refers to the set of ISO standards described as the ISO
7-bit coded character set for information interchange. Its final version
is also known as ITU T.50.
See https://www.itu.int/rec/T-REC-T.50-199209-I/en
To abide the standard it is needed to quote DC1 and DC3 correctly if these
are seen as data bytes and not as control characters. The current
implementation already tries to enforce this but fails to catch all
defined cases. 3GPP 27.010 chapter 5.2.7.3 clearly states that the most
significant bit shall be ignored for DC1 and DC3 handling. The current
implementation handles only the case with the most significant bit set 0.
Cases in which DC1 and DC3 have the most significant bit set 1 are left
unhandled.
This patch fixes this by masking the data bytes with ISO_IEC_646_MASK (only
the 7 least significant bits set 1) before comparing them with XON
(a.k.a. DC1) and XOFF (a.k.a. DC3) when testing which byte values need
quotation via byte stuffing.
Fixes: e1eaea46bb40 (tty: n_gsm line discipline, 2010-03-26)
Cc: stable(a)vger.kernel.org
Signed-off-by: Daniel Starke <daniel.starke(a)siemens.com>
---
drivers/tty/n_gsm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index ba27b274c967..0b1808e3a912 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -322,6 +322,7 @@ static int addr_cnt;
#define GSM1_ESCAPE_BITS 0x20
#define XON 0x11
#define XOFF 0x13
+#define ISO_IEC_646_MASK 0x7F
static const struct tty_port_operations gsm_port_ops;
@@ -531,7 +532,8 @@ static int gsm_stuff_frame(const u8 *input, u8 *output, int len)
int olen = 0;
while (len--) {
if (*input == GSM1_SOF || *input == GSM1_ESCAPE
- || *input == XON || *input == XOFF) {
+ || (*input & ISO_IEC_646_MASK) == XON
+ || (*input & ISO_IEC_646_MASK) == XOFF) {
*output++ = GSM1_ESCAPE;
*output++ = *input++ ^ GSM1_ESCAPE_BITS;
olen++;
--
2.25.1