* FAILED: patch "[PATCH] dm mpath: requeue after a small delay if blk_get_request()" failed to apply to 4.9-stable tree
From: gregkh @ 2017-05-22 15:55 UTC (permalink / raw)
To: bart.vanassche, snitzer; +Cc: stable
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@vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 06eb061f48594aa369f6e852b352410298b317a8 Mon Sep 17 00:00:00 2001
From: Bart Van Assche <bart.vanassche@sandisk.com>
Date: Fri, 7 Apr 2017 16:50:44 -0700
Subject: [PATCH] dm mpath: requeue after a small delay if blk_get_request()
fails
If blk_get_request() returns ENODEV then multipath_clone_and_map()
causes a request to be requeued immediately. This can cause a kworker
thread to spend 100% of the CPU time of a single core in
__blk_mq_run_hw_queue() and also can cause device removal to never
finish.
Avoid this by only requeuing after a delay if blk_get_request() fails.
Additionally, reduce the requeue delay.
Cc: stable@vger.kernel.org # 4.9+
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
diff --git a/drivers/md/dm-mpath.c b/drivers/md/dm-mpath.c
index 7f223dbed49f..a4cc4d42117b 100644
--- a/drivers/md/dm-mpath.c
+++ b/drivers/md/dm-mpath.c
@@ -484,7 +484,6 @@ static int multipath_clone_and_map(struct dm_target *ti, struct request *rq,
struct request **__clone)
{
struct multipath *m = ti->private;
- int r = DM_MAPIO_REQUEUE;
size_t nr_bytes = blk_rq_bytes(rq);
struct pgpath *pgpath;
struct block_device *bdev;
@@ -503,7 +502,7 @@ static int multipath_clone_and_map(struct dm_target *ti, struct request *rq,
} else if (test_bit(MPATHF_QUEUE_IO, &m->flags) ||
test_bit(MPATHF_PG_INIT_REQUIRED, &m->flags)) {
pg_init_all_paths(m);
- return r;
+ return DM_MAPIO_REQUEUE;
}
memset(mpio, 0, sizeof(*mpio));
@@ -517,7 +516,7 @@ static int multipath_clone_and_map(struct dm_target *ti, struct request *rq,
GFP_ATOMIC);
if (IS_ERR(clone)) {
/* EBUSY, ENODEV or EWOULDBLOCK: requeue */
- return r;
+ return DM_MAPIO_DELAY_REQUEUE;
}
clone->bio = clone->biotail = NULL;
clone->rq_disk = bdev->bd_disk;
diff --git a/drivers/md/dm-rq.c b/drivers/md/dm-rq.c
index 28955b94d2b2..90756a56c4d3 100644
--- a/drivers/md/dm-rq.c
+++ b/drivers/md/dm-rq.c
@@ -280,7 +280,7 @@ static void dm_requeue_original_request(struct dm_rq_target_io *tio, bool delay_
if (!rq->q->mq_ops)
dm_old_requeue_request(rq);
else
- dm_mq_delay_requeue_request(rq, delay_requeue ? 5000 : 0);
+ dm_mq_delay_requeue_request(rq, delay_requeue ? 100/*ms*/ : 0);
rq_completed(md, rw, false);
}
^ permalink raw reply related
* [PATCH] cmdline: fix get_options() overflow while parsing ranges
From: Ilya Matveychikov @ 2017-05-22 15:53 UTC (permalink / raw)
To: linux-kernel; +Cc: stable
When using get_options() it's possible to specify a range of numbers,
like 1-100500. The problem is that it doesn't track array size while
calling internally to get_range() which iterates over the range and
fills the memory with numbers.
Signed-off-by: Ilya V. Matveychikov <matvejchikov@gmail.com>
---
lib/cmdline.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/cmdline.c b/lib/cmdline.c
index 8f13cf7..79069d7 100644
--- a/lib/cmdline.c
+++ b/lib/cmdline.c
@@ -22,14 +22,14 @@
* the values[M, M+1, ..., N] into the ints array in get_options.
*/
-static int get_range(char **str, int *pint)
+static int get_range(char **str, int *pint, int n)
{
int x, inc_counter, upper_range;
(*str)++;
upper_range = simple_strtol((*str), NULL, 0);
inc_counter = upper_range - *pint;
- for (x = *pint; x < upper_range; x++)
+ for (x = *pint; n && x < upper_range; x++, n--)
*pint++ = x;
return inc_counter;
}
@@ -96,7 +96,7 @@ char *get_options(const char *str, int nints, int *ints)
break;
if (res == 3) {
int range_nums;
- range_nums = get_range((char **)&str, ints + i);
+ range_nums = get_range((char **)&str, ints + i, nints - i);
if (range_nums < 0)
break;
/*
--
2.7.4
^ permalink raw reply related
* FAILED: patch "[PATCH] infiniband: call ipv6 route lookup via the stub interface" failed to apply to 3.18-stable tree
From: gregkh @ 2017-05-22 15:52 UTC (permalink / raw)
To: pabeni, dledford; +Cc: stable
The patch below does not apply to the 3.18-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@vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From eea40b8f624f25cbc02d55f2d93203f60cee9341 Mon Sep 17 00:00:00 2001
From: Paolo Abeni <pabeni@redhat.com>
Date: Fri, 28 Apr 2017 11:20:01 +0200
Subject: [PATCH] infiniband: call ipv6 route lookup via the stub interface
The infiniband address handle can be triggered to resolve an ipv6
address in response to MAD packets, regardless of the ipv6
module being disabled via the kernel command line argument.
That will cause a call into the ipv6 routing code, which is not
initialized, and a conseguent oops.
This commit addresses the above issue replacing the direct lookup
call with an indirect one via the ipv6 stub, which is properly
initialized according to the ipv6 status (e.g. if ipv6 is
disabled, the routing lookup fails gracefully)
Cc: stable@vger.kernel.org # 3.12+
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
index 329d08c884f6..523d24320100 100644
--- a/drivers/infiniband/core/addr.c
+++ b/drivers/infiniband/core/addr.c
@@ -444,8 +444,8 @@ static int addr6_resolve(struct sockaddr_in6 *src_in,
fl6.saddr = src_in->sin6_addr;
fl6.flowi6_oif = addr->bound_dev_if;
- dst = ip6_route_output(addr->net, NULL, &fl6);
- if ((ret = dst->error))
+ ret = ipv6_stub->ipv6_dst_lookup(addr->net, NULL, &dst, &fl6);
+ if (ret < 0)
goto put;
rt = (struct rt6_info *)dst;
^ permalink raw reply related
* FAILED: patch "[PATCH] vTPM: Fix missing NULL check" failed to apply to 4.9-stable tree
From: gregkh @ 2017-05-22 15:51 UTC (permalink / raw)
To: honclo, jarkko.sakkinen, stable; +Cc: stable
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@vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 31574d321c70f6d3b40fe98f9b2eafd9a903fef9 Mon Sep 17 00:00:00 2001
From: "Hon Ching \\(Vicky\\) Lo" <honclo@linux.vnet.ibm.com>
Date: Wed, 15 Mar 2017 01:28:07 -0400
Subject: [PATCH] vTPM: Fix missing NULL check
The current code passes the address of tpm_chip as the argument to
dev_get_drvdata() without prior NULL check in
tpm_ibmvtpm_get_desired_dma. This resulted an oops during kernel
boot when vTPM is enabled in Power partition configured in active
memory sharing mode.
The vio_driver's get_desired_dma() is called before the probe(), which
for vtpm is tpm_ibmvtpm_probe, and it's this latter function that
initializes the driver and set data. Attempting to get data before
the probe() caused the problem.
This patch adds a NULL check to the tpm_ibmvtpm_get_desired_dma.
fixes: 9e0d39d8a6a0 ("tpm: Remove useless priv field in struct tpm_vendor_specific")
Cc: <stable@vger.kernel.org>
Signed-off-by: Hon Ching(Vicky) Lo <honclo@linux.vnet.ibm.com>
Reviewed-by: Jarkko Sakkine <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index 1b9d61ffe991..f01d083eced2 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -299,6 +299,8 @@ static int tpm_ibmvtpm_remove(struct vio_dev *vdev)
}
kfree(ibmvtpm);
+ /* For tpm_ibmvtpm_get_desired_dma */
+ dev_set_drvdata(&vdev->dev, NULL);
return 0;
}
@@ -313,14 +315,16 @@ static int tpm_ibmvtpm_remove(struct vio_dev *vdev)
static unsigned long tpm_ibmvtpm_get_desired_dma(struct vio_dev *vdev)
{
struct tpm_chip *chip = dev_get_drvdata(&vdev->dev);
- struct ibmvtpm_dev *ibmvtpm = dev_get_drvdata(&chip->dev);
+ struct ibmvtpm_dev *ibmvtpm;
/*
* ibmvtpm initializes at probe time, so the data we are
* asking for may not be set yet. Estimate that 4K required
* for TCE-mapped buffer in addition to CRQ.
*/
- if (!ibmvtpm)
+ if (chip)
+ ibmvtpm = dev_get_drvdata(&chip->dev);
+ else
return CRQ_RES_BUF_SIZE + PAGE_SIZE;
return CRQ_RES_BUF_SIZE + ibmvtpm->rtce_size;
^ permalink raw reply related
* [PATCH v2 2/2] iommu/arm-smmu: Plumb in new ACPI identifiers
From: Robin Murphy @ 2017-05-22 15:06 UTC (permalink / raw)
To: will.deacon, joro
Cc: iommu, linux-arm-kernel, linux-acpi, gakula, linu.cherian,
rrichter, lorenzo.pieralisi, hanjun.guo, john.garry,
shameerali.kolothum.thodi, gabriele.paoloni, stable
In-Reply-To: <11ef7d28c535c01d42b7b3c8e632934f0e0f1048.1495459319.git.robin.murphy@arm.com>
Revision C of IORT now allows us to identify ARM MMU-401 and the Cavium
ThunderX implementation. Wire them up so that we can probe these models
once firmware starts using the new codes, and so that the appropriate
features and quirks get enabled when we do.
For the sake of backports and mitigating sychronisation problems with
the ACPICA headers, we'll carry a backup copy of the new definitions
locally for the short term to make life simpler.
CC: stable@vger.kernel.org # 4.10
Acked-by: Robert Richter <rrichter@cavium.com>
Tested-by: Robert Richter <rrichter@cavium.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
v2: Add local backup definitions
This is ready to go regardless of patch 1. The stable backport is in likely
anticipation of machines with updated firmware paired with stable distro
kernels, which would be unable to recognise and probe the SMMU otherwise.
Robin.
drivers/iommu/arm-smmu.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 7ec30b08b3bd..79b9bb7d4783 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -312,6 +312,14 @@ enum arm_smmu_implementation {
CAVIUM_SMMUV2,
};
+/* Until ACPICA headers cover IORT rev. C */
+#ifndef ACPI_IORT_SMMU_CORELINK_MMU401
+#define ACPI_IORT_SMMU_CORELINK_MMU401 0x4
+#endif
+#ifndef ACPI_IORT_SMMU_CAVIUM_SMMUV2
+#define ACPI_IORT_SMMU_CAVIUM_SMMUV2 0x5
+#endif
+
struct arm_smmu_s2cr {
struct iommu_group *group;
int count;
@@ -2073,6 +2081,10 @@ static int acpi_smmu_get_data(u32 model, struct arm_smmu_device *smmu)
smmu->version = ARM_SMMU_V1;
smmu->model = GENERIC_SMMU;
break;
+ case ACPI_IORT_SMMU_CORELINK_MMU401:
+ smmu->version = ARM_SMMU_V1_64K;
+ smmu->model = GENERIC_SMMU;
+ break;
case ACPI_IORT_SMMU_V2:
smmu->version = ARM_SMMU_V2;
smmu->model = GENERIC_SMMU;
@@ -2081,6 +2093,10 @@ static int acpi_smmu_get_data(u32 model, struct arm_smmu_device *smmu)
smmu->version = ARM_SMMU_V2;
smmu->model = ARM_MMU500;
break;
+ case ACPI_IORT_SMMU_CAVIUM_SMMUV2:
+ smmu->version = ARM_SMMU_V2;
+ smmu->model = CAVIUM_SMMUV2;
+ break;
default:
ret = -ENODEV;
}
--
2.12.2.dirty
^ permalink raw reply related
* [PATCH v3 2/3] nvme: avoid to use blk_mq_abort_requeue_list()
From: Ming Lei @ 2017-05-22 15:05 UTC (permalink / raw)
To: Jens Axboe, Keith Busch, Christoph Hellwig, Sagi Grimberg
Cc: linux-nvme, Zhang Yi, linux-block, Johannes Thumshirn, Ming Lei,
stable
In-Reply-To: <20170522150505.452-1-ming.lei@redhat.com>
NVMe may add request into requeue list simply and not kick off the
requeue if hw queues are stopped. Then blk_mq_abort_requeue_list()
is called in both nvme_kill_queues() and nvme_ns_remove() for
dealing with this issue.
Unfortunately blk_mq_abort_requeue_list() is absolutely a
race maker, for example, one request may be requeued during
the aborting. So this patch just calls blk_mq_kick_requeue_list() in
nvme_kill_queues() to handle this issue like what nvme_start_queues()
does. Now all requests in requeue list when queues are stopped will be
handled by blk_mq_kick_requeue_list() when queues are restarted, either
in nvme_start_queues() or in nvme_kill_queues().
Cc: stable@vger.kernel.org
Reported-by: Zhang Yi <yizhan@redhat.com>
Reviewed-by: Keith Busch <keith.busch@intel.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
---
drivers/nvme/host/core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 40d5e4a9e8d7..04e115834702 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -2098,7 +2098,6 @@ static void nvme_ns_remove(struct nvme_ns *ns)
if (ns->ndev)
nvme_nvm_unregister_sysfs(ns);
del_gendisk(ns->disk);
- blk_mq_abort_requeue_list(ns->queue);
blk_cleanup_queue(ns->queue);
}
@@ -2436,7 +2435,6 @@ void nvme_kill_queues(struct nvme_ctrl *ctrl)
continue;
revalidate_disk(ns->disk);
blk_set_queue_dying(ns->queue);
- blk_mq_abort_requeue_list(ns->queue);
/*
* Forcibly start all queues to avoid having stuck requests.
@@ -2444,6 +2442,9 @@ void nvme_kill_queues(struct nvme_ctrl *ctrl)
* when the final removal happens.
*/
blk_mq_start_hw_queues(ns->queue);
+
+ /* draining requests in requeue list */
+ blk_mq_kick_requeue_list(ns->queue);
}
mutex_unlock(&ctrl->namespaces_mutex);
}
--
2.9.4
^ permalink raw reply related
* [PATCH v3 1/3] nvme: use blk_mq_start_hw_queues() in nvme_kill_queues()
From: Ming Lei @ 2017-05-22 15:05 UTC (permalink / raw)
To: Jens Axboe, Keith Busch, Christoph Hellwig, Sagi Grimberg
Cc: linux-nvme, Zhang Yi, linux-block, Johannes Thumshirn, Ming Lei,
stable
In-Reply-To: <20170522150505.452-1-ming.lei@redhat.com>
Inside nvme_kill_queues(), we have to start hw queues for
draining requests in sw queues, .dispatch list and requeue list,
so use blk_mq_start_hw_queues() instead of blk_mq_start_stopped_hw_queues()
which only run queues if queues are stopped, but the queues may have
been started already, for example nvme_start_queues() is called in reset work
function.
blk_mq_start_hw_queues() run hw queues in current context, instead
of running asynchronously like before. Given nvme_kill_queues() is
run from either remove context or reset worker context, both are fine
to run hw queue directly. And the mutex of namespaces_mutex isn't a
problem too becasue nvme_start_freeze() runs hw queue in this way
already.
Cc: stable@vger.kernel.org
Reported-by: Zhang Yi <yizhan@redhat.com>
Reviewed-by: Keith Busch <keith.busch@intel.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
---
drivers/nvme/host/core.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index d5e0906262ea..40d5e4a9e8d7 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -2437,7 +2437,13 @@ void nvme_kill_queues(struct nvme_ctrl *ctrl)
revalidate_disk(ns->disk);
blk_set_queue_dying(ns->queue);
blk_mq_abort_requeue_list(ns->queue);
- blk_mq_start_stopped_hw_queues(ns->queue, true);
+
+ /*
+ * Forcibly start all queues to avoid having stuck requests.
+ * Note that we must ensure the queues are not stopped
+ * when the final removal happens.
+ */
+ blk_mq_start_hw_queues(ns->queue);
}
mutex_unlock(&ctrl->namespaces_mutex);
}
--
2.9.4
^ permalink raw reply related
* Patch "ARM: tegra: paz00: Mark panel regulator as enabled on boot" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-22 15:03 UTC (permalink / raw)
To: marvin24, gregkh, treding, zombah; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ARM: tegra: paz00: Mark panel regulator as enabled on boot
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm-tegra-paz00-mark-panel-regulator-as-enabled-on-boot.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 0c18927f51f4d390abdcf385bff5f995407ee732 Mon Sep 17 00:00:00 2001
From: Marc Dietrich <marvin24@gmx.de>
Date: Fri, 9 Dec 2016 10:20:38 +0100
Subject: ARM: tegra: paz00: Mark panel regulator as enabled on boot
From: Marc Dietrich <marvin24@gmx.de>
commit 0c18927f51f4d390abdcf385bff5f995407ee732 upstream.
Current U-Boot enables the display already. Marking the regulator as
enabled on boot fixes sporadic panel initialization failures.
Signed-off-by: Marc Dietrich <marvin24@gmx.de>
Tested-by: Misha Komarovskiy <zombah@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/tegra20-paz00.dts | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -569,6 +569,7 @@
regulator-name = "+3VS,vdd_pnl";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
gpio = <&gpio TEGRA_GPIO(A, 4) GPIO_ACTIVE_HIGH>;
enable-active-high;
};
Patches currently in stable-queue which might be from marvin24@gmx.de are
queue-4.9/arm-tegra-paz00-mark-panel-regulator-as-enabled-on-boot.patch
^ permalink raw reply
* Patch "ARM: tegra: paz00: Mark panel regulator as enabled on boot" has been added to the 4.4-stable tree
From: gregkh @ 2017-05-22 15:02 UTC (permalink / raw)
To: marvin24, gregkh, treding, zombah; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ARM: tegra: paz00: Mark panel regulator as enabled on boot
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm-tegra-paz00-mark-panel-regulator-as-enabled-on-boot.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 0c18927f51f4d390abdcf385bff5f995407ee732 Mon Sep 17 00:00:00 2001
From: Marc Dietrich <marvin24@gmx.de>
Date: Fri, 9 Dec 2016 10:20:38 +0100
Subject: ARM: tegra: paz00: Mark panel regulator as enabled on boot
From: Marc Dietrich <marvin24@gmx.de>
commit 0c18927f51f4d390abdcf385bff5f995407ee732 upstream.
Current U-Boot enables the display already. Marking the regulator as
enabled on boot fixes sporadic panel initialization failures.
Signed-off-by: Marc Dietrich <marvin24@gmx.de>
Tested-by: Misha Komarovskiy <zombah@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/tegra20-paz00.dts | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -565,6 +565,7 @@
regulator-name = "+3VS,vdd_pnl";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
gpio = <&gpio TEGRA_GPIO(A, 4) GPIO_ACTIVE_HIGH>;
enable-active-high;
};
Patches currently in stable-queue which might be from marvin24@gmx.de are
queue-4.4/arm-tegra-paz00-mark-panel-regulator-as-enabled-on-boot.patch
^ permalink raw reply
* Re: [PATCH v2 1/3] nvme: use blk_mq_start_hw_queues() in nvme_kill_queues()
From: Ming Lei @ 2017-05-22 14:49 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jens Axboe, linux-block, Sagi Grimberg, Johannes Thumshirn,
linux-nvme, Keith Busch, stable, Zhang Yi
In-Reply-To: <20170522125140.GE11869@lst.de>
On Mon, May 22, 2017 at 02:51:40PM +0200, Christoph Hellwig wrote:
> On Mon, May 22, 2017 at 09:35:58AM +0800, Ming Lei wrote:
> > In theory, it should be OK to stop and start queues again before the final
> > removal, so how about the following:
> >
> > * Note: We must make sure to not put the queues into being stopped
> > forever from now until the final removal.
>
> Maybe:
> * Note that we must ensure the queues are not stopped
> * when the final removal happens.
>
> ?
Yeah, that is it, :-)
Thanks,
Ming
^ permalink raw reply
* Re: [PATCH 2/2] dax: Fix race between colliding PMD & PTE entries
From: Jan Kara @ 2017-05-22 14:44 UTC (permalink / raw)
To: Ross Zwisler
Cc: Andrew Morton, linux-kernel, Darrick J. Wong, Alexander Viro,
Christoph Hellwig, Dan Williams, Dave Hansen, Jan Kara,
Matthew Wilcox, linux-fsdevel, linux-mm, linux-nvdimm,
Kirill A . Shutemov, Pawel Lebioda, Dave Jiang, Xiong Zhou,
Eryu Guan, stable
In-Reply-To: <20170517171639.14501-2-ross.zwisler@linux.intel.com>
On Wed 17-05-17 11:16:39, Ross Zwisler wrote:
> We currently have two related PMD vs PTE races in the DAX code. These can
> both be easily triggered by having two threads reading and writing
> simultaneously to the same private mapping, with the key being that private
> mapping reads can be handled with PMDs but private mapping writes are
> always handled with PTEs so that we can COW.
>
> Here is the first race:
>
> CPU 0 CPU 1
>
> (private mapping write)
> __handle_mm_fault()
> create_huge_pmd() - FALLBACK
> handle_pte_fault()
> passes check for pmd_devmap()
>
> (private mapping read)
> __handle_mm_fault()
> create_huge_pmd()
> dax_iomap_pmd_fault() inserts PMD
>
> dax_iomap_pte_fault() does a PTE fault, but we already have a DAX PMD
> installed in our page tables at this spot.
>
> Here's the second race:
>
> CPU 0 CPU 1
>
> (private mapping write)
> __handle_mm_fault()
> create_huge_pmd() - FALLBACK
> (private mapping read)
> __handle_mm_fault()
> passes check for pmd_none()
> create_huge_pmd()
>
> handle_pte_fault()
> dax_iomap_pte_fault() inserts PTE
> dax_iomap_pmd_fault() inserts PMD,
> but we already have a PTE at
> this spot.
>
> The core of the issue is that while there is isolation between faults to
> the same range in the DAX fault handlers via our DAX entry locking, there
> is no isolation between faults in the code in mm/memory.c. This means for
> instance that this code in __handle_mm_fault() can run:
>
> if (pmd_none(*vmf.pmd) && transparent_hugepage_enabled(vma)) {
> ret = create_huge_pmd(&vmf);
>
> But by the time we actually get to run the fault handler called by
> create_huge_pmd(), the PMD is no longer pmd_none() because a racing PTE
> fault has installed a normal PMD here as a parent. This is the cause of
> the 2nd race. The first race is similar - there is the following check in
> handle_pte_fault():
>
> } else {
> /* See comment in pte_alloc_one_map() */
> if (pmd_devmap(*vmf->pmd) || pmd_trans_unstable(vmf->pmd))
> return 0;
>
> So if a pmd_devmap() PMD (a DAX PMD) has been installed at vmf->pmd, we
> will bail and retry the fault. This is correct, but there is nothing
> preventing the PMD from being installed after this check but before we
> actually get to the DAX PTE fault handlers.
>
> In my testing these races result in the following types of errors:
>
> BUG: Bad rss-counter state mm:ffff8800a817d280 idx:1 val:1
> BUG: non-zero nr_ptes on freeing mm: 15
>
> Fix this issue by having the DAX fault handlers verify that it is safe to
> continue their fault after they have taken an entry lock to block other
> racing faults.
>
> Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> Reported-by: Pawel Lebioda <pawel.lebioda@intel.com>
> Cc: stable@vger.kernel.org
>
> ---
>
> I've written a new xfstest for this race, which I will send in response to
> this patch series. This series has also survived an xfstest run without
> any new issues.
>
> ---
> fs/dax.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/fs/dax.c b/fs/dax.c
> index c22eaf1..3cc02d1 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -1155,6 +1155,15 @@ static int dax_iomap_pte_fault(struct vm_fault *vmf,
> }
>
> /*
> + * It is possible, particularly with mixed reads & writes to private
> + * mappings, that we have raced with a PMD fault that overlaps with
> + * the PTE we need to set up. Now that we have a locked mapping entry
> + * we can safely unmap the huge PMD so that we can install our PTE in
> + * our page tables.
> + */
> + split_huge_pmd(vmf->vma, vmf->pmd, vmf->address);
> +
Can we just check the PMD and if is isn't as we want it, bail out and retry
the fault? IMHO it will be more obvious that way (and also more in line
like these races are handled for the classical THP). Otherwise the patch
looks good to me.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH v3 11/11] arm64: hugetlb: Cleanup setup_hugepagesz
From: Punit Agrawal @ 2017-05-22 14:39 UTC (permalink / raw)
To: will.deacon, catalin.marinas
Cc: Steve Capper, linux-arm-kernel, mark.rutland, David Woods, stable,
Punit Agrawal
In-Reply-To: <20170522143958.12867-1-punit.agrawal@arm.com>
From: Steve Capper <steve.capper@arm.com>
Replace a lot of if statements with switch and case labels to make it
much clearer which huge page sizes are supported.
Also, we prevent PUD_SIZE from being used on systems not running with
4KB PAGE_SIZE. Before if one supplied PUD_SIZE in these circumstances,
then unusuable huge page sizes would be in use.
Fixes: 084bd29810a5 ("ARM64: mm: HugeTLB support.")
Cc: David Woods <dwoods@mellanox.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Steve Capper <steve.capper@arm.com>
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
---
arch/arm64/mm/hugetlbpage.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index a10dfbd0ffd5..b5dc7cca3f45 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -381,20 +381,20 @@ static __init int setup_hugepagesz(char *opt)
{
unsigned long ps = memparse(opt, &opt);
- if (ps == PMD_SIZE) {
- hugetlb_add_hstate(PMD_SHIFT - PAGE_SHIFT);
- } else if (ps == PUD_SIZE) {
- hugetlb_add_hstate(PUD_SHIFT - PAGE_SHIFT);
- } else if (ps == (PAGE_SIZE * CONT_PTES)) {
- hugetlb_add_hstate(CONT_PTE_SHIFT);
- } else if (ps == (PMD_SIZE * CONT_PMDS)) {
- hugetlb_add_hstate((PMD_SHIFT + CONT_PMD_SHIFT) - PAGE_SHIFT);
- } else {
- hugetlb_bad_size();
- pr_err("hugepagesz: Unsupported page size %lu K\n", ps >> 10);
- return 0;
+ switch (ps) {
+#ifdef CONFIG_ARM64_4K_PAGES
+ case PUD_SIZE:
+#endif
+ case PMD_SIZE * CONT_PMDS:
+ case PMD_SIZE:
+ case PAGE_SIZE * CONT_PTES:
+ hugetlb_add_hstate(ilog2(ps) - PAGE_SHIFT);
+ return 1;
}
- return 1;
+
+ hugetlb_bad_size();
+ pr_err("hugepagesz: Unsupported page size %lu K\n", ps >> 10);
+ return 0;
}
__setup("hugepagesz=", setup_hugepagesz);
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 1/2] mm: avoid spurious 'bad pmd' warning messages
From: Jan Kara @ 2017-05-22 14:40 UTC (permalink / raw)
To: Ross Zwisler
Cc: Andrew Morton, linux-kernel, Darrick J. Wong, Alexander Viro,
Christoph Hellwig, Dan Williams, Dave Hansen, Jan Kara,
Matthew Wilcox, linux-fsdevel, linux-mm, linux-nvdimm,
Kirill A . Shutemov, Pawel Lebioda, Dave Jiang, Xiong Zhou,
Eryu Guan, stable
In-Reply-To: <20170517171639.14501-1-ross.zwisler@linux.intel.com>
On Wed 17-05-17 11:16:38, Ross Zwisler wrote:
> When the pmd_devmap() checks were added by:
>
> commit 5c7fb56e5e3f ("mm, dax: dax-pmd vs thp-pmd vs hugetlbfs-pmd")
>
> to add better support for DAX huge pages, they were all added to the end of
> if() statements after existing pmd_trans_huge() checks. So, things like:
>
> - if (pmd_trans_huge(*pmd))
> + if (pmd_trans_huge(*pmd) || pmd_devmap(*pmd))
>
> When further checks were added after pmd_trans_unstable() checks by:
>
> commit 7267ec008b5c ("mm: postpone page table allocation until we have page
> to map")
>
> they were also added at the end of the conditional:
>
> + if (pmd_trans_unstable(fe->pmd) || pmd_devmap(*fe->pmd))
>
> This ordering is fine for pmd_trans_huge(), but doesn't work for
> pmd_trans_unstable(). This is because DAX huge pages trip the bad_pmd()
> check inside of pmd_none_or_trans_huge_or_clear_bad() (called by
> pmd_trans_unstable()), which prints out a warning and returns 1. So, we do
> end up doing the right thing, but only after spamming dmesg with suspicious
> looking messages:
>
> mm/pgtable-generic.c:39: bad pmd ffff8808daa49b88(84000001006000a5)
>
> Reorder these checks so that pmd_devmap() is checked first, avoiding the
> error messages.
>
> Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> Fixes: commit 7267ec008b5c ("mm: postpone page table allocation until we have page to map")
> Cc: stable@vger.kernel.org
With the change requested by Dave this looks good to me. You can add:
Reviewed-by: Jan Kara <jack@suse.cz>
Honza
> ---
> mm/memory.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/memory.c b/mm/memory.c
> index 6ff5d72..1ee269d 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3061,7 +3061,7 @@ static int pte_alloc_one_map(struct vm_fault *vmf)
> * through an atomic read in C, which is what pmd_trans_unstable()
> * provides.
> */
> - if (pmd_trans_unstable(vmf->pmd) || pmd_devmap(*vmf->pmd))
> + if (pmd_devmap(*vmf->pmd) || pmd_trans_unstable(vmf->pmd))
> return VM_FAULT_NOPAGE;
>
> vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, vmf->address,
> @@ -3690,7 +3690,7 @@ static int handle_pte_fault(struct vm_fault *vmf)
> vmf->pte = NULL;
> } else {
> /* See comment in pte_alloc_one_map() */
> - if (pmd_trans_unstable(vmf->pmd) || pmd_devmap(*vmf->pmd))
> + if (pmd_devmap(*vmf->pmd) || pmd_trans_unstable(vmf->pmd))
> return 0;
> /*
> * A regular pmd is established and it can't morph into a huge
> --
> 2.9.4
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 2/2] dax: Fix race between colliding PMD & PTE entries
From: Jan Kara @ 2017-05-22 14:37 UTC (permalink / raw)
To: Ross Zwisler
Cc: Jan Kara, Andrew Morton, linux-kernel, Darrick J. Wong,
Alexander Viro, Christoph Hellwig, Dan Williams, Dave Hansen,
Matthew Wilcox, linux-fsdevel, linux-mm, linux-nvdimm,
Kirill A . Shutemov, Pawel Lebioda, Dave Jiang, Xiong Zhou,
Eryu Guan, stable
In-Reply-To: <20170518212939.GA28029@linux.intel.com>
On Thu 18-05-17 15:29:39, Ross Zwisler wrote:
> On Thu, May 18, 2017 at 09:50:37AM +0200, Jan Kara wrote:
> > On Wed 17-05-17 11:16:39, Ross Zwisler wrote:
> > > We currently have two related PMD vs PTE races in the DAX code. These can
> > > both be easily triggered by having two threads reading and writing
> > > simultaneously to the same private mapping, with the key being that private
> > > mapping reads can be handled with PMDs but private mapping writes are
> > > always handled with PTEs so that we can COW.
> > >
> > > Here is the first race:
> > >
> > > CPU 0 CPU 1
> > >
> > > (private mapping write)
> > > __handle_mm_fault()
> > > create_huge_pmd() - FALLBACK
> > > handle_pte_fault()
> > > passes check for pmd_devmap()
> > >
> > > (private mapping read)
> > > __handle_mm_fault()
> > > create_huge_pmd()
> > > dax_iomap_pmd_fault() inserts PMD
> > >
> > > dax_iomap_pte_fault() does a PTE fault, but we already have a DAX PMD
> > > installed in our page tables at this spot.
> > >
> > >
> > > Here's the second race:
> > >
> > > CPU 0 CPU 1
> > >
> > > (private mapping write)
> > > __handle_mm_fault()
> > > create_huge_pmd() - FALLBACK
> > > (private mapping read)
> > > __handle_mm_fault()
> > > passes check for pmd_none()
> > > create_huge_pmd()
> > >
> > > handle_pte_fault()
> > > dax_iomap_pte_fault() inserts PTE
> > > dax_iomap_pmd_fault() inserts PMD,
> > > but we already have a PTE at
> > > this spot.
> >
> > So I don't see how this second scenario can happen. dax_iomap_pmd_fault()
> > will call grab_mapping_entry(). That will either find PTE entry in the
> > radix tree -> EEXIST and we retry the fault. Or we will not find PTE entry
> > -> try to insert PMD entry which collides with the PTE entry -> EEXIST and
> > we retry the fault. Am I missing something?
>
> Yep, sorry, I guess I needed a few extra steps in my flow (the initial private
> mapping read by CPU 0):
>
>
> CPU 0 CPU 1
>
> (private mapping read)
> __handle_mm_fault()
> passes check for pmd_none()
> create_huge_pmd()
> dax_iomap_pmd_fault() inserts PMD
>
> (private mapping write)
> __handle_mm_fault()
> create_huge_pmd() - FALLBACK
> (private mapping read)
> __handle_mm_fault()
> passes check for pmd_none()
> create_huge_pmd()
>
> handle_pte_fault()
> dax_iomap_pte_fault() inserts PTE
> dax_iomap_pmd_fault() inserts PMD,
> but we already have a PTE at
> this spot.
>
> So what happens is that CPU 0 inserts a DAX PMD into the radix tree that has
> real storage backing, and all PTE and PMD faults just use that same PMD radix
> tree entry for locking and dirty tracking.
OK, I see now. So essentially it's the same catch as the other case -
grab_mapping_entry() returns PMD entry on CPU0 although we asked for PTE
entry.
> > The first scenario seems to be possible. dax_iomap_pmd_fault() will create
> > PMD entry in the radix tree. Then dax_iomap_pte_fault() will come, do
> > grab_mapping_entry(), there it sees entry is PMD but we are doing PTE fault
> > so I'd think that pmd_downgrade = true... But actually the condition there
> > doesn't trigger in this case. And that's a catch that although we asked
> > grab_mapping_entry() for PTE, we've got PMD back and that screws us later.
>
> Yep, it was a concious decision when implementing the PMD support to allow one
> thread to use PMDs and another to use PTEs in the same range, as long as the
> thread faulting in PMDs is the first to insert into the radix tree. A PMD
> radix tree entry will be inserted and used for locking and dirty tracking, and
> each thread or process can fault in either PTEs or PMDs into its own address
> space as needed.
Well, for *threads* it doesn't really make good sense to mix PMDs and PTEs
as they share page tables. However for *processes* it makes some sense to
allow one process to use PTEs and another process to use PMDs. And I
remember we were discussing this in the past.
> We can revisit this, if you think it is incorrect. The option you outline
> below would basically mean that if any thread were to fault in a PTE in a
> range, all threads and processes would be forced to use PTEs because we would
> use PTEs in the radix tree.
Well, I don't think it is necessarily incorrect. I just think it is more
difficult to get it right (as current bugs show) so I'm just considering
whether the complexity is worth it.
> This is cleaner...I'm not sure if the use case of having two threads accessing
> the same area, one with PTEs and one with PMDs, is actually prevalent. It's
> also maybe a bit weird that the current behavior varies based on which thread
> faulted first - if the PTE thread faults first, it'll insert a PTE into the
> radix tree and everyone will just use PTEs.
So for two *threads*, I don't think that is a sensible use-case. We just
have to get it right. For two *processes* it makes sense - your DB might
want to use PMDs while your backup program may just use PTEs. So thinking
more about it I guess it is worth the effort to make the mixed case work
efficiently.
> > Actually I'm not convinced your patch quite fixes this because
> > dax_load_hole() or dax_insert_mapping_entry() will modify the passed entry
> > with the assumption that it's PTE entry and so they will likely corrupt the
> > entry in the radix tree.
>
> I don't think we can ever call dax_load_hole() if we have a DAX PMD entry in
> the radix tree, because we have a block mapping from the filesystem.
>
> For dax_insert_mapping_entry(), we do the right thing. From the comments
> above the function:
>
> * If we happen to be trying to insert a PTE and there is a PMD
> * already in the tree, we will skip the insertion and just dirty the PMD as
> * appropriate. If we happen to be trying to insert a PTE and there is a PMD
> * already in the tree, we will skip the insertion and just dirty the PMD as
> * appropriate.
Yeah, on the first reading I missed that we won't modify the radix tree in
that particular case. Frankly, I think we should somewhat clean up that
code to make things more obvious but let's leave that for a bit later. For
now the code looks correct.
> > So I think to fix the first case we should rather modify
> > grab_mapping_entry() to properly go through the pmd_downgrade path once we
> > find PMD entry and we do PTE fault.
> >
> > What do you think?
>
> That could also work, though I do think the fix as submitted is correct.
> I think it comes down to whether we want to keep the behavior where a thread
> faulting in a PTEs will use an existing PMD entry in the radix tree, instead
> of making all other threads fall back to PTEs.
>
> I think either way solves this issue for the DAX case...but do you understand
> how this is solved for other fault handlers? They don't have any isolation
> between faults either in the mm/memory.c code, and are susceptible to the same
> races. How do they deal with the fact that by the time they get to their PTE
> fault handler, a racing PMD fault handler in another thread could have
> inserted a PMD into their page tables, and vice versa?
So normal fault path uses alloc_set_pte() for installing new PTE. And that
uses pte_alloc_one_map() which checks whether PMD is still suitable for
inserting a PTE. If not, we return VM_FAULT_NOPAGE. Probably it would be
cleanest to factor our common parts of PTE and PMD insertion so that we can
use these functions both from DAX and generic fault paths.
Anyway, I'll have a look at your fixes with fresh eyes as they could be the
right way to go as a quick fix. Refactoring and cleanups can come later.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v3] drm: mxsfb_crtc: Reset the eLCDIF controller
From: Marek Vasut @ 2017-05-22 14:20 UTC (permalink / raw)
To: Fabio Estevam, Fabio Estevam
Cc: Stefan Agner, Sascha Hauer, DRI mailing list, stable
In-Reply-To: <CAOMZO5C-YjQUrSBXPx+Ap1js-eJxoEmXDFc4K6eB66V7JYWOgA@mail.gmail.com>
On 05/22/2017 03:55 PM, Fabio Estevam wrote:
> Hi Marek,
>
> On Fri, May 5, 2017 at 3:01 PM, Fabio Estevam <fabio.estevam@nxp.com> wrote:
>> According to the eLCDIF initialization steps listed in the MX6SX
>> Reference Manual the eLCDIF block reset is mandatory.
>>
>> Without performing the eLCDIF reset the display shows garbage content
>> when the kernel boots.
>>
>> In earlier tests this issue has not been observed because the bootloader
>> was previously showing a splash screen and the bootloader display driver
>> does properly implement the eLCDIF reset.
>>
>> Add the eLCDIF reset to the driver, so that it can operate correctly
>> independently of the bootloader.
>>
>> Tested on a imx6sx-sdb board.
>>
>> Cc: <stable@vger.kernel.org>
>> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
>> ---
>> Changes since v2:
>>
>> - Remove unneeded udelay(1) - Marek
>
> Any comments about v3?
>
IMO it's OK.
Reviewed-by: Marek Vasut <marex@denx.de>
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH v3 1/2] dmaengine: ep93xx: Always start from BASE0
From: Alexander Sverdlin @ 2017-05-22 14:05 UTC (permalink / raw)
To: dmaengine; +Cc: Alexander Sverdlin, Dan Williams, Vinod Koul, stable
In-Reply-To: <20170522140523.24281-1-alexander.sverdlin@gmail.com>
The current buffer is being reset to zero on device_free_chan_resources()
but not on device_terminate_all(). It could happen that HW is restarted and
expects BASE0 to be used, but the driver is not synchronized and will start
from BASE1. One solution is to reset the buffer explicitly in
m2p_hw_setup().
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Cc: stable@vger.kernel.org
---
drivers/dma/ep93xx_dma.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/dma/ep93xx_dma.c b/drivers/dma/ep93xx_dma.c
index d37e8dda8079..deb009c3121f 100644
--- a/drivers/dma/ep93xx_dma.c
+++ b/drivers/dma/ep93xx_dma.c
@@ -323,6 +323,8 @@ static int m2p_hw_setup(struct ep93xx_dma_chan *edmac)
| M2P_CONTROL_ENABLE;
m2p_set_control(edmac, control);
+ edmac->buffer = 0;
+
return 0;
}
--
2.12.2
^ permalink raw reply related
* [PATCH v3 2/2] dmaengine: ep93xx: Don't drain the transfers in terminate_all()
From: Alexander Sverdlin @ 2017-05-22 14:05 UTC (permalink / raw)
To: dmaengine; +Cc: Alexander Sverdlin, Dan Williams, Vinod Koul, stable
In-Reply-To: <20170522140523.24281-1-alexander.sverdlin@gmail.com>
Draining the transfers in terminate_all callback happens with IRQs disabled,
therefore induces huge latency:
irqsoff latency trace v1.1.5 on 4.11.0
--------------------------------------------------------------------
latency: 39770 us, #57/57, CPU#0 | (M:preempt VP:0, KP:0, SP:0 HP:0)
-----------------
| task: process-129 (uid:0 nice:0 policy:2 rt_prio:50)
-----------------
=> started at: _snd_pcm_stream_lock_irqsave
=> ended at: snd_pcm_stream_unlock_irqrestore
_------=> CPU#
/ _-----=> irqs-off
| / _----=> need-resched
|| / _---=> hardirq/softirq
||| / _--=> preempt-depth
|||| / delay
cmd pid ||||| time | caller
\ / ||||| \ | /
process-129 0d.s. 3us : _snd_pcm_stream_lock_irqsave
process-129 0d.s1 9us : snd_pcm_stream_lock <-_snd_pcm_stream_lock_irqsave
process-129 0d.s1 15us : preempt_count_add <-snd_pcm_stream_lock
process-129 0d.s2 22us : preempt_count_add <-snd_pcm_stream_lock
process-129 0d.s3 32us : snd_pcm_update_hw_ptr0 <-snd_pcm_period_elapsed
process-129 0d.s3 41us : soc_pcm_pointer <-snd_pcm_update_hw_ptr0
process-129 0d.s3 50us : dmaengine_pcm_pointer <-soc_pcm_pointer
process-129 0d.s3 58us+: snd_dmaengine_pcm_pointer_no_residue <-dmaengine_pcm_pointer
process-129 0d.s3 96us : update_audio_tstamp <-snd_pcm_update_hw_ptr0
process-129 0d.s3 103us : snd_pcm_update_state <-snd_pcm_update_hw_ptr0
process-129 0d.s3 112us : xrun <-snd_pcm_update_state
process-129 0d.s3 119us : snd_pcm_stop <-xrun
process-129 0d.s3 126us : snd_pcm_action <-snd_pcm_stop
process-129 0d.s3 134us : snd_pcm_action_single <-snd_pcm_action
process-129 0d.s3 141us : snd_pcm_pre_stop <-snd_pcm_action_single
process-129 0d.s3 150us : snd_pcm_do_stop <-snd_pcm_action_single
process-129 0d.s3 157us : soc_pcm_trigger <-snd_pcm_do_stop
process-129 0d.s3 166us : snd_dmaengine_pcm_trigger <-soc_pcm_trigger
process-129 0d.s3 175us : ep93xx_dma_terminate_all <-snd_dmaengine_pcm_trigger
process-129 0d.s3 182us : preempt_count_add <-ep93xx_dma_terminate_all
process-129 0d.s4 189us*: m2p_hw_shutdown <-ep93xx_dma_terminate_all
process-129 0d.s4 39472us : m2p_hw_setup <-ep93xx_dma_terminate_all
... rest skipped...
process-129 0d.s. 40080us : <stack trace>
=> ep93xx_dma_tasklet
=> tasklet_action
=> __do_softirq
=> irq_exit
=> __handle_domain_irq
=> vic_handle_irq
=> __irq_usr
=> 0xb66c6668
Just abort the transfers and warn if the HW state is not what we expect.
Move draining into device_synchronize callback.
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Cc: stable@vger.kernel.org
---
drivers/dma/ep93xx_dma.c | 37 +++++++++++++++++++++++++++++++++----
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/ep93xx_dma.c b/drivers/dma/ep93xx_dma.c
index deb009c3121f..ec240592f5c8 100644
--- a/drivers/dma/ep93xx_dma.c
+++ b/drivers/dma/ep93xx_dma.c
@@ -201,6 +201,7 @@ struct ep93xx_dma_engine {
struct dma_device dma_dev;
bool m2m;
int (*hw_setup)(struct ep93xx_dma_chan *);
+ void (*hw_synchronize)(struct ep93xx_dma_chan *);
void (*hw_shutdown)(struct ep93xx_dma_chan *);
void (*hw_submit)(struct ep93xx_dma_chan *);
int (*hw_interrupt)(struct ep93xx_dma_chan *);
@@ -333,21 +334,27 @@ static inline u32 m2p_channel_state(struct ep93xx_dma_chan *edmac)
return (readl(edmac->regs + M2P_STATUS) >> 4) & 0x3;
}
-static void m2p_hw_shutdown(struct ep93xx_dma_chan *edmac)
+static void m2p_hw_synchronize(struct ep93xx_dma_chan *edmac)
{
+ unsigned long flags;
u32 control;
+ spin_lock_irqsave(&edmac->lock, flags);
control = readl(edmac->regs + M2P_CONTROL);
control &= ~(M2P_CONTROL_STALLINT | M2P_CONTROL_NFBINT);
m2p_set_control(edmac, control);
+ spin_unlock_irqrestore(&edmac->lock, flags);
while (m2p_channel_state(edmac) >= M2P_STATE_ON)
- cpu_relax();
+ schedule();
+}
+static void m2p_hw_shutdown(struct ep93xx_dma_chan *edmac)
+{
m2p_set_control(edmac, 0);
- while (m2p_channel_state(edmac) == M2P_STATE_STALL)
- cpu_relax();
+ while (m2p_channel_state(edmac) != M2P_STATE_IDLE)
+ dev_warn(chan2dev(edmac), "M2P: Not yet IDLE\n");
}
static void m2p_fill_desc(struct ep93xx_dma_chan *edmac)
@@ -1163,6 +1170,26 @@ ep93xx_dma_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t dma_addr,
}
/**
+ * ep93xx_dma_synchronize - Synchronizes the termination of transfers to the
+ * current context.
+ * @chan: channel
+ *
+ * Synchronizes the DMA channel termination to the current context. When this
+ * function returns it is guaranteed that all transfers for previously issued
+ * descriptors have stopped and and it is safe to free the memory associated
+ * with them. Furthermore it is guaranteed that all complete callback functions
+ * for a previously submitted descriptor have finished running and it is safe to
+ * free resources accessed from within the complete callbacks.
+ */
+static void ep93xx_dma_synchronize(struct dma_chan *chan)
+{
+ struct ep93xx_dma_chan *edmac = to_ep93xx_dma_chan(chan);
+
+ if (edmac->edma->hw_synchronize)
+ edmac->edma->hw_synchronize(edmac);
+}
+
+/**
* ep93xx_dma_terminate_all - terminate all transactions
* @chan: channel
*
@@ -1325,6 +1352,7 @@ static int __init ep93xx_dma_probe(struct platform_device *pdev)
dma_dev->device_prep_slave_sg = ep93xx_dma_prep_slave_sg;
dma_dev->device_prep_dma_cyclic = ep93xx_dma_prep_dma_cyclic;
dma_dev->device_config = ep93xx_dma_slave_config;
+ dma_dev->device_synchronize = ep93xx_dma_synchronize;
dma_dev->device_terminate_all = ep93xx_dma_terminate_all;
dma_dev->device_issue_pending = ep93xx_dma_issue_pending;
dma_dev->device_tx_status = ep93xx_dma_tx_status;
@@ -1342,6 +1370,7 @@ static int __init ep93xx_dma_probe(struct platform_device *pdev)
} else {
dma_cap_set(DMA_PRIVATE, dma_dev->cap_mask);
+ edma->hw_synchronize = m2p_hw_synchronize;
edma->hw_setup = m2p_hw_setup;
edma->hw_shutdown = m2p_hw_shutdown;
edma->hw_submit = m2p_hw_submit;
--
2.12.2
^ permalink raw reply related
* Re: [PATCH v3] drm: mxsfb_crtc: Reset the eLCDIF controller
From: Fabio Estevam @ 2017-05-22 13:55 UTC (permalink / raw)
To: Fabio Estevam
Cc: Marek Vasut, Stefan Agner, Sascha Hauer, DRI mailing list, stable
In-Reply-To: <1494007301-14535-1-git-send-email-fabio.estevam@nxp.com>
Hi Marek,
On Fri, May 5, 2017 at 3:01 PM, Fabio Estevam <fabio.estevam@nxp.com> wrote:
> According to the eLCDIF initialization steps listed in the MX6SX
> Reference Manual the eLCDIF block reset is mandatory.
>
> Without performing the eLCDIF reset the display shows garbage content
> when the kernel boots.
>
> In earlier tests this issue has not been observed because the bootloader
> was previously showing a splash screen and the bootloader display driver
> does properly implement the eLCDIF reset.
>
> Add the eLCDIF reset to the driver, so that it can operate correctly
> independently of the bootloader.
>
> Tested on a imx6sx-sdb board.
>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> Changes since v2:
>
> - Remove unneeded udelay(1) - Marek
Any comments about v3?
^ permalink raw reply
* Re: ARM: tegra: paz00: Mark panel regulator as enabled on boot
From: Greg KH @ 2017-05-22 13:52 UTC (permalink / raw)
To: Marc Dietrich; +Cc: stable
In-Reply-To: <2509690.GzIdWdQo4p@fb07-iapwap2>
On Mon, May 22, 2017 at 02:34:20PM +0200, Marc Dietrich wrote:
> commit 0c18927f51f4d390abdcf385bff5f995407ee732 upstream.
>
> Current U-Boot enables the display already. Marking the regulator as
> enabled on boot fixes sporadic panel initialization failures.
>
> Should be applied to 4.1+.
Looks good, thanks.
greg k-h
^ permalink raw reply
* Re: [PATCH v2 1/3] nvme: use blk_mq_start_hw_queues() in nvme_kill_queues()
From: Christoph Hellwig @ 2017-05-22 12:51 UTC (permalink / raw)
To: Ming Lei
Cc: Christoph Hellwig, Jens Axboe, linux-block, Sagi Grimberg,
Johannes Thumshirn, linux-nvme, Keith Busch, stable, Zhang Yi
In-Reply-To: <20170522013557.GD15872@ming.t460p>
On Mon, May 22, 2017 at 09:35:58AM +0800, Ming Lei wrote:
> In theory, it should be OK to stop and start queues again before the final
> removal, so how about the following:
>
> * Note: We must make sure to not put the queues into being stopped
> forever from now until the final removal.
Maybe:
* Note that we must ensure the queues are not stopped
* when the final removal happens.
?
^ permalink raw reply
* ARM: tegra: paz00: Mark panel regulator as enabled on boot
From: Marc Dietrich @ 2017-05-22 12:34 UTC (permalink / raw)
To: stable
[-- Attachment #1: Type: text/plain, Size: 219 bytes --]
commit 0c18927f51f4d390abdcf385bff5f995407ee732 upstream.
Current U-Boot enables the display already. Marking the regulator as
enabled on boot fixes sporadic panel initialization failures.
Should be applied to 4.1+.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v4] usb: usbip: set buffer pointers to NULL after free
From: Michael Grzeschik @ 2017-05-22 11:02 UTC (permalink / raw)
To: linux-usb; +Cc: shuah, valentina.manea.m, gregkh, kernel, oneukum, stable
The usbip stack dynamically allocates the transfer_buffer and
setup_packet of each urb that got generated by the tcp to usb stub code.
As these pointers are always used only once we will set them to NULL
after use. This is done likewise to the free_urb code in vudc_dev.c.
This patch fixes double kfree situations where the usbip remote side
added the URB_FREE_BUFFER.
Cc: stable@vger.kernel.org
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
---
v1 -> v2: - rephrased patch subject from:
"usb: usbip: avoid the usb layer to kfree our allocated buffer"
- changed to always let urb_destoy remove the transfer_buffer
v2 -> v3: - added stable to cc
- wrapped long line with over 80 chars
v3 -> v4: - rephrades patch subject from usb:
"usbip: let urb_destroy kfree the transfer_buffer"
- setting buffer pointers to NULL
instead of omitting flag URB_FREE_BUFFER
drivers/usb/usbip/stub_main.c | 4 ++++
drivers/usb/usbip/stub_tx.c | 4 ++++
2 files changed, 8 insertions(+)
diff --git a/drivers/usb/usbip/stub_main.c b/drivers/usb/usbip/stub_main.c
index 44ab43fc4fcc7..af10f7b131a49 100644
--- a/drivers/usb/usbip/stub_main.c
+++ b/drivers/usb/usbip/stub_main.c
@@ -262,7 +262,11 @@ void stub_device_cleanup_urbs(struct stub_device *sdev)
kmem_cache_free(stub_priv_cache, priv);
kfree(urb->transfer_buffer);
+ urb->transfer_buffer = NULL;
+
kfree(urb->setup_packet);
+ urb->setup_packet = NULL;
+
usb_free_urb(urb);
}
}
diff --git a/drivers/usb/usbip/stub_tx.c b/drivers/usb/usbip/stub_tx.c
index 6b1e8c3f0e4b2..be50cef645d8a 100644
--- a/drivers/usb/usbip/stub_tx.c
+++ b/drivers/usb/usbip/stub_tx.c
@@ -28,7 +28,11 @@ static void stub_free_priv_and_urb(struct stub_priv *priv)
struct urb *urb = priv->urb;
kfree(urb->setup_packet);
+ urb->setup_packet = NULL;
+
kfree(urb->transfer_buffer);
+ urb->transfer_buffer = NULL;
+
list_del(&priv->list);
kmem_cache_free(stub_priv_cache, priv);
usb_free_urb(urb);
--
2.11.0
^ permalink raw reply related
* Patch "watchdog: pcwd_usb: fix NULL-deref at probe" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-22 10:24 UTC (permalink / raw)
To: johan, gregkh, linux, wim; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
watchdog: pcwd_usb: fix NULL-deref at probe
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
watchdog-pcwd_usb-fix-null-deref-at-probe.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 46c319b848268dab3f0e7c4a5b6e9146d3bca8a4 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan@kernel.org>
Date: Mon, 13 Mar 2017 13:49:45 +0100
Subject: watchdog: pcwd_usb: fix NULL-deref at probe
From: Johan Hovold <johan@kernel.org>
commit 46c319b848268dab3f0e7c4a5b6e9146d3bca8a4 upstream.
Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/watchdog/pcwd_usb.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/watchdog/pcwd_usb.c
+++ b/drivers/watchdog/pcwd_usb.c
@@ -630,6 +630,9 @@ static int usb_pcwd_probe(struct usb_int
return -ENODEV;
}
+ if (iface_desc->desc.bNumEndpoints < 1)
+ return -ENODEV;
+
/* check out the endpoint: it has to be Interrupt & IN */
endpoint = &iface_desc->endpoint[0].desc;
Patches currently in stable-queue which might be from johan@kernel.org are
queue-4.9/watchdog-pcwd_usb-fix-null-deref-at-probe.patch
^ permalink raw reply
* Patch "USB: core: replace %p with %pK" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-22 10:24 UTC (permalink / raw)
To: vskrishn, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
USB: core: replace %p with %pK
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
usb-core-replace-p-with-pk.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 2f964780c03b73de269b08d12aff96a9618d13f3 Mon Sep 17 00:00:00 2001
From: Vamsi Krishna Samavedam <vskrishn@codeaurora.org>
Date: Tue, 16 May 2017 14:38:08 +0200
Subject: USB: core: replace %p with %pK
From: Vamsi Krishna Samavedam <vskrishn@codeaurora.org>
commit 2f964780c03b73de269b08d12aff96a9618d13f3 upstream.
Format specifier %p can leak kernel addresses while not valuing the
kptr_restrict system settings. When kptr_restrict is set to (1), kernel
pointers printed using the %pK format specifier will be replaced with
Zeros. Debugging Note : &pK prints only Zeros as address. If you need
actual address information, write 0 to kptr_restrict.
echo 0 > /proc/sys/kernel/kptr_restrict
[Found by poking around in a random vendor kernel tree, it would be nice
if someone would actually send these types of patches upstream - gkh]
Signed-off-by: Vamsi Krishna Samavedam <vskrishn@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/core/devio.c | 14 +++++++-------
drivers/usb/core/hcd.c | 4 ++--
drivers/usb/core/urb.c | 2 +-
3 files changed, 10 insertions(+), 10 deletions(-)
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -481,11 +481,11 @@ static void snoop_urb(struct usb_device
if (userurb) { /* Async */
if (when == SUBMIT)
- dev_info(&udev->dev, "userurb %p, ep%d %s-%s, "
+ dev_info(&udev->dev, "userurb %pK, ep%d %s-%s, "
"length %u\n",
userurb, ep, t, d, length);
else
- dev_info(&udev->dev, "userurb %p, ep%d %s-%s, "
+ dev_info(&udev->dev, "userurb %pK, ep%d %s-%s, "
"actual_length %u status %d\n",
userurb, ep, t, d, length,
timeout_or_status);
@@ -1905,7 +1905,7 @@ static int proc_reapurb(struct usb_dev_s
if (as) {
int retval;
- snoop(&ps->dev->dev, "reap %p\n", as->userurb);
+ snoop(&ps->dev->dev, "reap %pK\n", as->userurb);
retval = processcompl(as, (void __user * __user *)arg);
free_async(as);
return retval;
@@ -1922,7 +1922,7 @@ static int proc_reapurbnonblock(struct u
as = async_getcompleted(ps);
if (as) {
- snoop(&ps->dev->dev, "reap %p\n", as->userurb);
+ snoop(&ps->dev->dev, "reap %pK\n", as->userurb);
retval = processcompl(as, (void __user * __user *)arg);
free_async(as);
} else {
@@ -2053,7 +2053,7 @@ static int proc_reapurb_compat(struct us
if (as) {
int retval;
- snoop(&ps->dev->dev, "reap %p\n", as->userurb);
+ snoop(&ps->dev->dev, "reap %pK\n", as->userurb);
retval = processcompl_compat(as, (void __user * __user *)arg);
free_async(as);
return retval;
@@ -2070,7 +2070,7 @@ static int proc_reapurbnonblock_compat(s
as = async_getcompleted(ps);
if (as) {
- snoop(&ps->dev->dev, "reap %p\n", as->userurb);
+ snoop(&ps->dev->dev, "reap %pK\n", as->userurb);
retval = processcompl_compat(as, (void __user * __user *)arg);
free_async(as);
} else {
@@ -2499,7 +2499,7 @@ static long usbdev_do_ioctl(struct file
#endif
case USBDEVFS_DISCARDURB:
- snoop(&dev->dev, "%s: DISCARDURB %p\n", __func__, p);
+ snoop(&dev->dev, "%s: DISCARDURB %pK\n", __func__, p);
ret = proc_unlinkurb(ps, p);
break;
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1722,7 +1722,7 @@ int usb_hcd_unlink_urb (struct urb *urb,
if (retval == 0)
retval = -EINPROGRESS;
else if (retval != -EIDRM && retval != -EBUSY)
- dev_dbg(&udev->dev, "hcd_unlink_urb %p fail %d\n",
+ dev_dbg(&udev->dev, "hcd_unlink_urb %pK fail %d\n",
urb, retval);
usb_put_dev(udev);
}
@@ -1889,7 +1889,7 @@ rescan:
/* kick hcd */
unlink1(hcd, urb, -ESHUTDOWN);
dev_dbg (hcd->self.controller,
- "shutdown urb %p ep%d%s%s\n",
+ "shutdown urb %pK ep%d%s%s\n",
urb, usb_endpoint_num(&ep->desc),
is_in ? "in" : "out",
({ char *s;
--- a/drivers/usb/core/urb.c
+++ b/drivers/usb/core/urb.c
@@ -333,7 +333,7 @@ int usb_submit_urb(struct urb *urb, gfp_
if (!urb || !urb->complete)
return -EINVAL;
if (urb->hcpriv) {
- WARN_ONCE(1, "URB %p submitted while active\n", urb);
+ WARN_ONCE(1, "URB %pK submitted while active\n", urb);
return -EBUSY;
}
Patches currently in stable-queue which might be from vskrishn@codeaurora.org are
queue-4.9/usb-core-replace-p-with-pk.patch
^ permalink raw reply
* Patch "ALSA: hda: Fix cpu lockup when stopping the cmd dmas" has been added to the 4.9-stable tree
From: gregkh @ 2017-05-22 10:24 UTC (permalink / raw)
To: jeeja.kp; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ALSA: hda: Fix cpu lockup when stopping the cmd dmas
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
alsa-hda-fix-cpu-lockup-when-stopping-the-cmd-dmas.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 960013762df0a214b57f2fce655422fb52bdfd2c Mon Sep 17 00:00:00 2001
From: Jeeja KP <jeeja.kp@intel.com>
Date: Wed, 10 May 2017 11:51:58 +0530
Subject: ALSA: hda: Fix cpu lockup when stopping the cmd dmas
From: Jeeja KP <jeeja.kp@intel.com>
commit 960013762df0a214b57f2fce655422fb52bdfd2c upstream.
Using jiffies in hdac_wait_for_cmd_dmas() to determine when to time out
when interrupts are off (snd_hdac_bus_stop_cmd_io()/spin_lock_irq())
causes hard lockup so unlock while waiting using jiffies.
---<-snip->---
<0>[ 1211.603046] NMI watchdog: Watchdog detected hard LOCKUP on cpu 3
<4>[ 1211.603047] Modules linked in: snd_hda_intel i915 vgem
<4>[ 1211.603053] irq event stamp: 13366
<4>[ 1211.603053] hardirqs last enabled at (13365):
...
<4>[ 1211.603059] Call Trace:
<4>[ 1211.603059] ? delay_tsc+0x3d/0xc0
<4>[ 1211.603059] __delay+0xa/0x10
<4>[ 1211.603060] __const_udelay+0x31/0x40
<4>[ 1211.603060] snd_hdac_bus_stop_cmd_io+0x96/0xe0 [snd_hda_core]
<4>[ 1211.603060] ? azx_dev_disconnect+0x20/0x20 [snd_hda_intel]
<4>[ 1211.603061] snd_hdac_bus_stop_chip+0xb1/0x100 [snd_hda_core]
<4>[ 1211.603061] azx_stop_chip+0x9/0x10 [snd_hda_codec]
<4>[ 1211.603061] azx_suspend+0x72/0x220 [snd_hda_intel]
<4>[ 1211.603061] pci_pm_suspend+0x71/0x140
<4>[ 1211.603062] dpm_run_callback+0x6f/0x330
<4>[ 1211.603062] ? pci_pm_freeze+0xe0/0xe0
<4>[ 1211.603062] __device_suspend+0xf9/0x370
<4>[ 1211.603062] ? dpm_watchdog_set+0x60/0x60
<4>[ 1211.603063] async_suspend+0x1a/0x90
<4>[ 1211.603063] async_run_entry_fn+0x34/0x160
<4>[ 1211.603063] process_one_work+0x1f4/0x6d0
<4>[ 1211.603063] ? process_one_work+0x16e/0x6d0
<4>[ 1211.603064] worker_thread+0x49/0x4a0
<4>[ 1211.603064] kthread+0x107/0x140
<4>[ 1211.603064] ? process_one_work+0x6d0/0x6d0
<4>[ 1211.603065] ? kthread_create_on_node+0x40/0x40
<4>[ 1211.603065] ret_from_fork+0x2e/0x40
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100419
Fixes: 38b19ed7f81ec ("ALSA: hda: fix to wait for RIRB & CORB DMA to set")
Reported-by: Marta Lofstedt <marta.lofstedt@intel.com>
Suggested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/hda/hdac_controller.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/sound/hda/hdac_controller.c
+++ b/sound/hda/hdac_controller.c
@@ -106,7 +106,11 @@ void snd_hdac_bus_stop_cmd_io(struct hda
/* disable ringbuffer DMAs */
snd_hdac_chip_writeb(bus, RIRBCTL, 0);
snd_hdac_chip_writeb(bus, CORBCTL, 0);
+ spin_unlock_irq(&bus->reg_lock);
+
hdac_wait_for_cmd_dmas(bus);
+
+ spin_lock_irq(&bus->reg_lock);
/* disable unsolicited responses */
snd_hdac_chip_updatel(bus, GCTL, AZX_GCTL_UNSOL, 0);
spin_unlock_irq(&bus->reg_lock);
Patches currently in stable-queue which might be from jeeja.kp@intel.com are
queue-4.9/alsa-hda-fix-cpu-lockup-when-stopping-the-cmd-dmas.patch
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox