From: Keith Busch <kbusch(a)kernel.org>
stable inclusion
from stable-v5.10.166
commit 5f10f7efe0fc97c0ee2112a1032914f6fb2f940c
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7R4BC
CVE: NA
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id…
--------------------------------
[ Upstream commit 1c5842085851f786eba24a39ecd02650ad892064 ]
Polling the completion can progress the request state to IDLE, either
inline with the completion, or through softirq. Either way, the state
may not be COMPLETED, so don't check for that. We only care if the state
isn't IN_FLIGHT.
This is fixing an issue where the driver aborts an IO that we just
completed. Seeing the "aborting" message instead of "polled" is very
misleading as to where the timeout problem resides.
Fixes: bf392a5dc02a9b ("nvme-pci: Remove tag from process cq")
Signed-off-by: Keith Busch <kbusch(a)kernel.org>
Signed-off-by: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
Signed-off-by: Yong Hu <yong.hu(a)windriver.com>
---
drivers/nvme/host/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index fbbbfdea076a..bbf6ce4b82ac 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -1291,7 +1291,7 @@ static enum blk_eh_timer_return nvme_timeout(struct request *req, bool reserved)
else
nvme_poll_irqdisable(nvmeq);
- if (blk_mq_request_completed(req)) {
+ if (blk_mq_rq_state(req) != MQ_RQ_IN_FLIGHT) {
dev_warn(dev->ctrl.device,
"I/O %d QID %d timeout, completion polled\n",
req->tag, nvmeq->qid);
--
2.34.1
hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7ZMCB
CVE: NA
--------------------------------
CPU hotplug callbacks race against distribute_cfs_runtime(),
when the QOS_SCHED feature is enabled, there may be
situations where the cfs_rq-> runtime_remaining == 1
and cfs_rq is QOS_THROTTLED.
Turn off the Qos_throttle when the CPU is offline.
No longer allocate time to cfs_rq in this scenario to fix the warning.
Fixes: fbea24f5894e ("sched/qos: Don't unthrottle cfs_rq when cfs_rq is throttled by qos")
Signed-off-by: Xia Fukun <xiafukun(a)huawei.com>
---
kernel/sched/fair.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index e9afb1e6ca4c..1c78e2f29901 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4783,6 +4783,19 @@ static u64 distribute_cfs_runtime(struct cfs_bandwidth *cfs_b, u64 remaining)
if (!cfs_rq_throttled(cfs_rq))
goto next;
+ /*
+ * CPU hotplug callbacks race against distribute_cfs_runtime()
+ * when the QOS_SCHED feature is enabled, there may be
+ * situations where the runtime_remaining > 0.
+ * Qos_sched does not care whether the cfs_rq has time left,
+ * so no longer allocate time to cfs_rq in this scenario.
+ */
+#ifdef CONFIG_QOS_SCHED
+ if (cfs_rq->throttled == QOS_THROTTLED &&
+ cfs_rq->runtime_remaining > 0)
+ goto next;
+#endif
+
/* By the above check, this should never be true */
SCHED_WARN_ON(cfs_rq->runtime_remaining > 0);
@@ -7754,6 +7767,10 @@ static bool check_qos_cfs_rq(struct cfs_rq *cfs_rq)
if (unlikely(cfs_rq && cfs_rq->tg->qos_level < 0 &&
!sched_idle_cpu(smp_processor_id()) &&
cfs_rq->h_nr_running == cfs_rq->idle_h_nr_running)) {
+
+ if (!rq_of(cfs_rq)->online)
+ return false;
+
throttle_qos_cfs_rq(cfs_rq);
return true;
}
--
2.34.1