From 7e98d9baec5ebffa7b963e2113b2f53babd655b3 Mon Sep 17 00:00:00 2001 From: Sasha Levin Date: Mon, 1 Jun 2020 23:31:02 -0400 Subject: [PATCH] Fixes for 4.14 Signed-off-by: Sasha Levin --- ...ending-do-not-lose-pending-affinity-.patch | 93 +++++++++++++++++++ ...quest-object-use-after-free-in-send-.patch | 93 +++++++++++++++++++ queue-4.14/series | 2 + 3 files changed, 188 insertions(+) create mode 100644 queue-4.14/genirq-generic_pending-do-not-lose-pending-affinity-.patch create mode 100644 queue-4.14/scsi-zfcp-fix-request-object-use-after-free-in-send-.patch diff --git a/queue-4.14/genirq-generic_pending-do-not-lose-pending-affinity-.patch b/queue-4.14/genirq-generic_pending-do-not-lose-pending-affinity-.patch new file mode 100644 index 00000000000..690bdb48413 --- /dev/null +++ b/queue-4.14/genirq-generic_pending-do-not-lose-pending-affinity-.patch @@ -0,0 +1,93 @@ +From 15453d29b67a8a26aa072b97984e07d2b138b073 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 4 Jun 2018 17:33:54 +0200 +Subject: genirq/generic_pending: Do not lose pending affinity update + +From: Thomas Gleixner + +[ Upstream commit a33a5d2d16cb84bea8d5f5510f3a41aa48b5c467 ] + +The generic pending interrupt mechanism moves interrupts from the interrupt +handler on the original target CPU to the new destination CPU. This is +required for x86 and ia64 due to the way the interrupt delivery and +acknowledge works if the interrupts are not remapped. + +However that update can fail for various reasons. Some of them are valid +reasons to discard the pending update, but the case, when the previous move +has not been fully cleaned up is not a legit reason to fail. + +Check the return value of irq_do_set_affinity() for -EBUSY, which indicates +a pending cleanup, and rearm the pending move in the irq dexcriptor so it's +tried again when the next interrupt arrives. + +Fixes: 996c591227d9 ("x86/irq: Plug vector cleanup race") +Signed-off-by: Thomas Gleixner +Tested-by: Song Liu +Cc: Joerg Roedel +Cc: Peter Zijlstra +Cc: Song Liu +Cc: Dmitry Safonov <0x7f454c46@gmail.com> +Cc: stable@vger.kernel.org +Cc: Mike Travis +Cc: Borislav Petkov +Cc: Tariq Toukan +Link: https://lkml.kernel.org/r/20180604162224.386544292@linutronix.de +Signed-off-by: Sasha Levin +--- + kernel/irq/migration.c | 26 +++++++++++++++++++------- + 1 file changed, 19 insertions(+), 7 deletions(-) + +diff --git a/kernel/irq/migration.c b/kernel/irq/migration.c +index 86ae0eb80b53..8b8cecd18cce 100644 +--- a/kernel/irq/migration.c ++++ b/kernel/irq/migration.c +@@ -38,17 +38,18 @@ bool irq_fixup_move_pending(struct irq_desc *desc, bool force_clear) + void irq_move_masked_irq(struct irq_data *idata) + { + struct irq_desc *desc = irq_data_to_desc(idata); +- struct irq_chip *chip = desc->irq_data.chip; ++ struct irq_data *data = &desc->irq_data; ++ struct irq_chip *chip = data->chip; + +- if (likely(!irqd_is_setaffinity_pending(&desc->irq_data))) ++ if (likely(!irqd_is_setaffinity_pending(data))) + return; + +- irqd_clr_move_pending(&desc->irq_data); ++ irqd_clr_move_pending(data); + + /* + * Paranoia: cpu-local interrupts shouldn't be calling in here anyway. + */ +- if (irqd_is_per_cpu(&desc->irq_data)) { ++ if (irqd_is_per_cpu(data)) { + WARN_ON(1); + return; + } +@@ -73,9 +74,20 @@ void irq_move_masked_irq(struct irq_data *idata) + * For correct operation this depends on the caller + * masking the irqs. + */ +- if (cpumask_any_and(desc->pending_mask, cpu_online_mask) < nr_cpu_ids) +- irq_do_set_affinity(&desc->irq_data, desc->pending_mask, false); +- ++ if (cpumask_any_and(desc->pending_mask, cpu_online_mask) < nr_cpu_ids) { ++ int ret; ++ ++ ret = irq_do_set_affinity(data, desc->pending_mask, false); ++ /* ++ * If the there is a cleanup pending in the underlying ++ * vector management, reschedule the move for the next ++ * interrupt. Leave desc->pending_mask intact. ++ */ ++ if (ret == -EBUSY) { ++ irqd_set_move_pending(data); ++ return; ++ } ++ } + cpumask_clear(desc->pending_mask); + } + +-- +2.25.1 + diff --git a/queue-4.14/scsi-zfcp-fix-request-object-use-after-free-in-send-.patch b/queue-4.14/scsi-zfcp-fix-request-object-use-after-free-in-send-.patch new file mode 100644 index 00000000000..3242b056876 --- /dev/null +++ b/queue-4.14/scsi-zfcp-fix-request-object-use-after-free-in-send-.patch @@ -0,0 +1,93 @@ +From 888cf514a3463a58b5d0eb8917dd494a57c41ddf Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 2 Jul 2019 23:02:01 +0200 +Subject: scsi: zfcp: fix request object use-after-free in send path causing + wrong traces + +From: Benjamin Block + +[ Upstream commit 106d45f350c7cac876844dc685845cba4ffdb70b ] + +When tracing instances where we open and close WKA ports, we also pass the +request-ID of the respective FSF command. + +But after successfully sending the FSF command we must not use the +request-object anymore, as this might result in an use-after-free (see +"zfcp: fix request object use-after-free in send path causing seqno +errors" ). + +To fix this add a new variable that caches the request-ID before sending +the request. This won't change during the hand-off to the FCP channel, +and so it's safe to trace this cached request-ID later, instead of using +the request object. + +Signed-off-by: Benjamin Block +Fixes: d27a7cb91960 ("zfcp: trace on request for open and close of WKA port") +Cc: #2.6.38+ +Reviewed-by: Steffen Maier +Reviewed-by: Jens Remus +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + drivers/s390/scsi/zfcp_fsf.c | 10 ++++++++-- + 1 file changed, 8 insertions(+), 2 deletions(-) + +diff --git a/drivers/s390/scsi/zfcp_fsf.c b/drivers/s390/scsi/zfcp_fsf.c +index 94d1bcc83fa2..119238faf1ac 100644 +--- a/drivers/s390/scsi/zfcp_fsf.c ++++ b/drivers/s390/scsi/zfcp_fsf.c +@@ -1594,6 +1594,7 @@ int zfcp_fsf_open_wka_port(struct zfcp_fc_wka_port *wka_port) + { + struct zfcp_qdio *qdio = wka_port->adapter->qdio; + struct zfcp_fsf_req *req; ++ unsigned long req_id = 0; + int retval = -EIO; + + spin_lock_irq(&qdio->req_q_lock); +@@ -1616,6 +1617,8 @@ int zfcp_fsf_open_wka_port(struct zfcp_fc_wka_port *wka_port) + hton24(req->qtcb->bottom.support.d_id, wka_port->d_id); + req->data = wka_port; + ++ req_id = req->req_id; ++ + zfcp_fsf_start_timer(req, ZFCP_FSF_REQUEST_TIMEOUT); + retval = zfcp_fsf_req_send(req); + if (retval) +@@ -1623,7 +1626,7 @@ int zfcp_fsf_open_wka_port(struct zfcp_fc_wka_port *wka_port) + out: + spin_unlock_irq(&qdio->req_q_lock); + if (!retval) +- zfcp_dbf_rec_run_wka("fsowp_1", wka_port, req->req_id); ++ zfcp_dbf_rec_run_wka("fsowp_1", wka_port, req_id); + return retval; + } + +@@ -1649,6 +1652,7 @@ int zfcp_fsf_close_wka_port(struct zfcp_fc_wka_port *wka_port) + { + struct zfcp_qdio *qdio = wka_port->adapter->qdio; + struct zfcp_fsf_req *req; ++ unsigned long req_id = 0; + int retval = -EIO; + + spin_lock_irq(&qdio->req_q_lock); +@@ -1671,6 +1675,8 @@ int zfcp_fsf_close_wka_port(struct zfcp_fc_wka_port *wka_port) + req->data = wka_port; + req->qtcb->header.port_handle = wka_port->handle; + ++ req_id = req->req_id; ++ + zfcp_fsf_start_timer(req, ZFCP_FSF_REQUEST_TIMEOUT); + retval = zfcp_fsf_req_send(req); + if (retval) +@@ -1678,7 +1684,7 @@ int zfcp_fsf_close_wka_port(struct zfcp_fc_wka_port *wka_port) + out: + spin_unlock_irq(&qdio->req_q_lock); + if (!retval) +- zfcp_dbf_rec_run_wka("fscwp_1", wka_port, req->req_id); ++ zfcp_dbf_rec_run_wka("fscwp_1", wka_port, req_id); + return retval; + } + +-- +2.25.1 + diff --git a/queue-4.14/series b/queue-4.14/series index cc5b10a2508..1865bb379b1 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -72,3 +72,5 @@ rxrpc-fix-transport-sockopts-to-get-ipv4-errors-on-an-ipv6-socket.patch kvm-vmx-check-for-existence-of-secondary-exec-controls-before-accessing.patch net-hns-fix-unsigned-comparison-to-less-than-zero.patch net-hns-fixes-the-missing-put_device-in-positive-leg-for-roce-reset.patch +genirq-generic_pending-do-not-lose-pending-affinity-.patch +scsi-zfcp-fix-request-object-use-after-free-in-send-.patch -- 2.47.3