--- /dev/null
+From b93dfa6bda4d4e88e5386490f2b277a26958f9d3 Mon Sep 17 00:00:00 2001
+From: Dan Williams <dan.j.williams@intel.com>
+Date: Wed, 11 Aug 2021 11:53:37 -0700
+Subject: ACPI: NFIT: Fix support for virtual SPA ranges
+
+From: Dan Williams <dan.j.williams@intel.com>
+
+commit b93dfa6bda4d4e88e5386490f2b277a26958f9d3 upstream.
+
+Fix the NFIT parsing code to treat a 0 index in a SPA Range Structure as
+a special case and not match Region Mapping Structures that use 0 to
+indicate that they are not mapped. Without this fix some platform BIOS
+descriptions of "virtual disk" ranges do not result in the pmem driver
+attaching to the range.
+
+Details:
+In addition to typical persistent memory ranges, the ACPI NFIT may also
+convey "virtual" ranges. These ranges are indicated by a UUID in the SPA
+Range Structure of UUID_VOLATILE_VIRTUAL_DISK, UUID_VOLATILE_VIRTUAL_CD,
+UUID_PERSISTENT_VIRTUAL_DISK, or UUID_PERSISTENT_VIRTUAL_CD. The
+critical difference between virtual ranges and UUID_PERSISTENT_MEMORY,
+is that virtual do not support associations with Region Mapping
+Structures. For this reason the "index" value of virtual SPA Range
+Structures is allowed to be 0. If a platform BIOS decides to represent
+NVDIMMs with disconnected "Region Mapping Structures" (range-index ==
+0), the kernel may falsely associate them with standalone ranges where
+the "SPA Range Structure Index" is also zero. When this happens the
+driver may falsely require labels where "virtual disks" are expected to
+be label-less. I.e. "label-less" is where the namespace-range ==
+region-range and the pmem driver attaches with no user action to create
+a namespace.
+
+Cc: Jacek Zloch <jacek.zloch@intel.com>
+Cc: Lukasz Sobieraj <lukasz.sobieraj@intel.com>
+Cc: "Lee, Chun-Yi" <jlee@suse.com>
+Cc: <stable@vger.kernel.org>
+Fixes: c2f32acdf848 ("acpi, nfit: treat virtual ramdisk SPA as pmem region")
+Reported-by: Krzysztof Rusocki <krzysztof.rusocki@intel.com>
+Reported-by: Damian Bassa <damian.bassa@intel.com>
+Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
+Link: https://lore.kernel.org/r/162870796589.2521182.1240403310175570220.stgit@dwillia2-desk3.amr.corp.intel.com
+Signed-off-by: Dan Williams <dan.j.williams@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/nfit/core.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/acpi/nfit/core.c
++++ b/drivers/acpi/nfit/core.c
+@@ -2973,6 +2973,9 @@ static int acpi_nfit_register_region(str
+ struct acpi_nfit_memory_map *memdev = nfit_memdev->memdev;
+ struct nd_mapping_desc *mapping;
+
++ /* range index 0 == unmapped in SPA or invalid-SPA */
++ if (memdev->range_index == 0 || spa->range_index == 0)
++ continue;
+ if (memdev->range_index != spa->range_index)
+ continue;
+ if (count >= ND_MAX_MAPPINGS) {
--- /dev/null
+From 2e6b836312a477d647a7920b56810a5a25f6c856 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Wed, 28 Jul 2021 13:23:50 +0200
+Subject: ASoC: intel: atom: Fix reference to PCM buffer address
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 2e6b836312a477d647a7920b56810a5a25f6c856 upstream.
+
+PCM buffers might be allocated dynamically when the buffer
+preallocation failed or a larger buffer is requested, and it's not
+guaranteed that substream->dma_buffer points to the actually used
+buffer. The address should be retrieved from runtime->dma_addr,
+instead of substream->dma_buffer (and shouldn't use virt_to_phys).
+
+Also, remove the line overriding runtime->dma_area superfluously,
+which was already set up at the PCM buffer allocation.
+
+Cc: Cezary Rojewski <cezary.rojewski@intel.com>
+Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Link: https://lore.kernel.org/r/20210728112353.6675-3-tiwai@suse.de
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/intel/atom/sst-mfld-platform-pcm.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/sound/soc/intel/atom/sst-mfld-platform-pcm.c
++++ b/sound/soc/intel/atom/sst-mfld-platform-pcm.c
+@@ -127,7 +127,7 @@ static void sst_fill_alloc_params(struct
+ snd_pcm_uframes_t period_size;
+ ssize_t periodbytes;
+ ssize_t buffer_bytes = snd_pcm_lib_buffer_bytes(substream);
+- u32 buffer_addr = virt_to_phys(substream->dma_buffer.area);
++ u32 buffer_addr = substream->runtime->dma_addr;
+
+ channels = substream->runtime->channels;
+ period_size = substream->runtime->period_size;
+@@ -233,7 +233,6 @@ static int sst_platform_alloc_stream(str
+ /* set codec params and inform SST driver the same */
+ sst_fill_pcm_params(substream, ¶m);
+ sst_fill_alloc_params(substream, &alloc_params);
+- substream->runtime->dma_area = substream->dma_buffer.area;
+ str_params.sparams = param;
+ str_params.aparams = alloc_params;
+ str_params.codec = SST_CODEC_TYPE_PCM;
--- /dev/null
+From 42bc62c9f1d3d4880bdc27acb5ab4784209bb0b0 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Wed, 28 Jul 2021 13:23:51 +0200
+Subject: ASoC: xilinx: Fix reference to PCM buffer address
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 42bc62c9f1d3d4880bdc27acb5ab4784209bb0b0 upstream.
+
+PCM buffers might be allocated dynamically when the buffer
+preallocation failed or a larger buffer is requested, and it's not
+guaranteed that substream->dma_buffer points to the actually used
+buffer. The driver needs to refer to substream->runtime->dma_addr
+instead for the buffer address.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Link: https://lore.kernel.org/r/20210728112353.6675-4-tiwai@suse.de
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/xilinx/xlnx_formatter_pcm.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/sound/soc/xilinx/xlnx_formatter_pcm.c
++++ b/sound/soc/xilinx/xlnx_formatter_pcm.c
+@@ -461,8 +461,8 @@ static int xlnx_formatter_pcm_hw_params(
+
+ stream_data->buffer_size = size;
+
+- low = lower_32_bits(substream->dma_buffer.addr);
+- high = upper_32_bits(substream->dma_buffer.addr);
++ low = lower_32_bits(runtime->dma_addr);
++ high = upper_32_bits(runtime->dma_addr);
+ writel(low, stream_data->mmio + XLNX_AUD_BUFF_ADDR_LSB);
+ writel(high, stream_data->mmio + XLNX_AUD_BUFF_ADDR_MSB);
+
--- /dev/null
+From bf2ba432213fade50dd39f2e348085b758c0726e Mon Sep 17 00:00:00 2001
+From: Luis Henriques <lhenriques@suse.de>
+Date: Tue, 6 Jul 2021 14:52:41 +0100
+Subject: ceph: reduce contention in ceph_check_delayed_caps()
+
+From: Luis Henriques <lhenriques@suse.de>
+
+commit bf2ba432213fade50dd39f2e348085b758c0726e upstream.
+
+Function ceph_check_delayed_caps() is called from the mdsc->delayed_work
+workqueue and it can be kept looping for quite some time if caps keep
+being added back to the mdsc->cap_delay_list. This may result in the
+watchdog tainting the kernel with the softlockup flag.
+
+This patch breaks this loop if the caps have been recently (i.e. during
+the loop execution). Any new caps added to the list will be handled in
+the next run.
+
+Also, allow schedule_delayed() callers to explicitly set the delay value
+instead of defaulting to 5s, so we can ensure that it runs soon
+afterward if it looks like there is more work.
+
+Cc: stable@vger.kernel.org
+URL: https://tracker.ceph.com/issues/46284
+Signed-off-by: Luis Henriques <lhenriques@suse.de>
+Reviewed-by: Jeff Layton <jlayton@kernel.org>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ceph/caps.c | 17 ++++++++++++++++-
+ fs/ceph/mds_client.c | 25 ++++++++++++++++---------
+ fs/ceph/super.h | 2 +-
+ 3 files changed, 33 insertions(+), 11 deletions(-)
+
+--- a/fs/ceph/caps.c
++++ b/fs/ceph/caps.c
+@@ -4053,12 +4053,20 @@ bad:
+
+ /*
+ * Delayed work handler to process end of delayed cap release LRU list.
++ *
++ * If new caps are added to the list while processing it, these won't get
++ * processed in this run. In this case, the ci->i_hold_caps_max will be
++ * returned so that the work can be scheduled accordingly.
+ */
+-void ceph_check_delayed_caps(struct ceph_mds_client *mdsc)
++unsigned long ceph_check_delayed_caps(struct ceph_mds_client *mdsc)
+ {
+ struct inode *inode;
+ struct ceph_inode_info *ci;
+ int flags = CHECK_CAPS_NODELAY;
++ struct ceph_mount_options *opt = mdsc->fsc->mount_options;
++ unsigned long delay_max = opt->caps_wanted_delay_max * HZ;
++ unsigned long loop_start = jiffies;
++ unsigned long delay = 0;
+
+ dout("check_delayed_caps\n");
+ while (1) {
+@@ -4068,6 +4076,11 @@ void ceph_check_delayed_caps(struct ceph
+ ci = list_first_entry(&mdsc->cap_delay_list,
+ struct ceph_inode_info,
+ i_cap_delay_list);
++ if (time_before(loop_start, ci->i_hold_caps_max - delay_max)) {
++ dout("%s caps added recently. Exiting loop", __func__);
++ delay = ci->i_hold_caps_max;
++ break;
++ }
+ if ((ci->i_ceph_flags & CEPH_I_FLUSH) == 0 &&
+ time_before(jiffies, ci->i_hold_caps_max))
+ break;
+@@ -4084,6 +4097,8 @@ void ceph_check_delayed_caps(struct ceph
+ }
+ }
+ spin_unlock(&mdsc->cap_delay_lock);
++
++ return delay;
+ }
+
+ /*
+--- a/fs/ceph/mds_client.c
++++ b/fs/ceph/mds_client.c
+@@ -4049,22 +4049,29 @@ static void maybe_recover_session(struct
+ }
+
+ /*
+- * delayed work -- periodically trim expired leases, renew caps with mds
++ * delayed work -- periodically trim expired leases, renew caps with mds. If
++ * the @delay parameter is set to 0 or if it's more than 5 secs, the default
++ * workqueue delay value of 5 secs will be used.
+ */
+-static void schedule_delayed(struct ceph_mds_client *mdsc)
++static void schedule_delayed(struct ceph_mds_client *mdsc, unsigned long delay)
+ {
+- int delay = 5;
+- unsigned hz = round_jiffies_relative(HZ * delay);
+- schedule_delayed_work(&mdsc->delayed_work, hz);
++ unsigned long max_delay = HZ * 5;
++
++ /* 5 secs default delay */
++ if (!delay || (delay > max_delay))
++ delay = max_delay;
++ schedule_delayed_work(&mdsc->delayed_work,
++ round_jiffies_relative(delay));
+ }
+
+ static void delayed_work(struct work_struct *work)
+ {
+- int i;
+ struct ceph_mds_client *mdsc =
+ container_of(work, struct ceph_mds_client, delayed_work.work);
++ unsigned long delay;
+ int renew_interval;
+ int renew_caps;
++ int i;
+
+ dout("mdsc delayed_work\n");
+
+@@ -4119,7 +4126,7 @@ static void delayed_work(struct work_str
+ }
+ mutex_unlock(&mdsc->mutex);
+
+- ceph_check_delayed_caps(mdsc);
++ delay = ceph_check_delayed_caps(mdsc);
+
+ ceph_queue_cap_reclaim_work(mdsc);
+
+@@ -4127,7 +4134,7 @@ static void delayed_work(struct work_str
+
+ maybe_recover_session(mdsc);
+
+- schedule_delayed(mdsc);
++ schedule_delayed(mdsc, delay);
+ }
+
+ int ceph_mdsc_init(struct ceph_fs_client *fsc)
+@@ -4600,7 +4607,7 @@ void ceph_mdsc_handle_mdsmap(struct ceph
+ mdsc->mdsmap->m_epoch);
+
+ mutex_unlock(&mdsc->mutex);
+- schedule_delayed(mdsc);
++ schedule_delayed(mdsc, 0);
+ return;
+
+ bad_unlock:
+--- a/fs/ceph/super.h
++++ b/fs/ceph/super.h
+@@ -1064,7 +1064,7 @@ extern void ceph_flush_snaps(struct ceph
+ extern bool __ceph_should_report_size(struct ceph_inode_info *ci);
+ extern void ceph_check_caps(struct ceph_inode_info *ci, int flags,
+ struct ceph_mds_session *session);
+-extern void ceph_check_delayed_caps(struct ceph_mds_client *mdsc);
++extern unsigned long ceph_check_delayed_caps(struct ceph_mds_client *mdsc);
+ extern void ceph_flush_dirty_caps(struct ceph_mds_client *mdsc);
+ extern int ceph_drop_caps_for_unlink(struct inode *inode);
+ extern int ceph_encode_inode_release(void **p, struct inode *inode,
--- /dev/null
+From 86ff25ed6cd8240d18df58930bd8848b19fce308 Mon Sep 17 00:00:00 2001
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Date: Thu, 29 Jul 2021 16:35:32 +0200
+Subject: i2c: dev: zero out array used for i2c reads from userspace
+
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+commit 86ff25ed6cd8240d18df58930bd8848b19fce308 upstream.
+
+If an i2c driver happens to not provide the full amount of data that a
+user asks for, it is possible that some uninitialized data could be sent
+to userspace. While all in-kernel drivers look to be safe, just be sure
+by initializing the buffer to zero before it is passed to the i2c driver
+so that any future drivers will not have this issue.
+
+Also properly copy the amount of data recvieved to the userspace buffer,
+as pointed out by Dan Carpenter.
+
+Reported-by: Eric Dumazet <edumazet@google.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Wolfram Sang <wsa@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/i2c/i2c-dev.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/i2c/i2c-dev.c
++++ b/drivers/i2c/i2c-dev.c
+@@ -141,7 +141,7 @@ static ssize_t i2cdev_read(struct file *
+ if (count > 8192)
+ count = 8192;
+
+- tmp = kmalloc(count, GFP_KERNEL);
++ tmp = kzalloc(count, GFP_KERNEL);
+ if (tmp == NULL)
+ return -ENOMEM;
+
+@@ -150,7 +150,8 @@ static ssize_t i2cdev_read(struct file *
+
+ ret = i2c_master_recv(client, tmp, count);
+ if (ret >= 0)
+- ret = copy_to_user(buf, tmp, count) ? -EFAULT : ret;
++ if (copy_to_user(buf, tmp, ret))
++ ret = -EFAULT;
+ kfree(tmp);
+ return ret;
+ }
--- /dev/null
+From 5afc1540f13804a31bb704b763308e17688369c5 Mon Sep 17 00:00:00 2001
+From: Colin Ian King <colin.king@canonical.com>
+Date: Fri, 30 Jul 2021 08:16:51 +0100
+Subject: iio: adc: Fix incorrect exit of for-loop
+
+From: Colin Ian King <colin.king@canonical.com>
+
+commit 5afc1540f13804a31bb704b763308e17688369c5 upstream.
+
+Currently the for-loop that scans for the optimial adc_period iterates
+through all the possible adc_period levels because the exit logic in
+the loop is inverted. I believe the comparison should be swapped and
+the continue replaced with a break to exit the loop at the correct
+point.
+
+Addresses-Coverity: ("Continue has no effect")
+Fixes: e08e19c331fb ("iio:adc: add iio driver for Palmas (twl6035/7) gpadc")
+Signed-off-by: Colin Ian King <colin.king@canonical.com>
+Link: https://lore.kernel.org/r/20210730071651.17394-1-colin.king@canonical.com
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/adc/palmas_gpadc.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/iio/adc/palmas_gpadc.c
++++ b/drivers/iio/adc/palmas_gpadc.c
+@@ -656,8 +656,8 @@ static int palmas_adc_wakeup_configure(s
+
+ adc_period = adc->auto_conversion_period;
+ for (i = 0; i < 16; ++i) {
+- if (((1000 * (1 << i)) / 32) < adc_period)
+- continue;
++ if (((1000 * (1 << i)) / 32) >= adc_period)
++ break;
+ }
+ if (i > 0)
+ i--;
--- /dev/null
+From 9898cb24e454602beb6e17bacf9f97b26c85c955 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= <u.kleine-koenig@pengutronix.de>
+Date: Fri, 9 Jul 2021 12:11:10 +0200
+Subject: iio: adc: ti-ads7950: Ensure CS is deasserted after reading channels
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
+
+commit 9898cb24e454602beb6e17bacf9f97b26c85c955 upstream.
+
+The ADS7950 requires that CS is deasserted after each SPI word. Before
+commit e2540da86ef8 ("iio: adc: ti-ads7950: use SPI_CS_WORD to reduce
+CPU usage") the driver used a message with one spi transfer per channel
+where each but the last one had .cs_change set to enforce a CS toggle.
+This was wrongly translated into a message with a single transfer and
+.cs_change set which results in a CS toggle after each word but the
+last which corrupts the first adc conversion of all readouts after the
+first readout.
+
+Fixes: e2540da86ef8 ("iio: adc: ti-ads7950: use SPI_CS_WORD to reduce CPU usage")
+Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
+Reviewed-by: David Lechner <david@lechnology.com>
+Tested-by: David Lechner <david@lechnology.com>
+Cc: <Stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210709101110.1814294-1-u.kleine-koenig@pengutronix.de
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/adc/ti-ads7950.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/drivers/iio/adc/ti-ads7950.c
++++ b/drivers/iio/adc/ti-ads7950.c
+@@ -569,7 +569,6 @@ static int ti_ads7950_probe(struct spi_d
+ st->ring_xfer.tx_buf = &st->tx_buf[0];
+ st->ring_xfer.rx_buf = &st->rx_buf[0];
+ /* len will be set later */
+- st->ring_xfer.cs_change = true;
+
+ spi_message_add_tail(&st->ring_xfer, &st->ring_msg);
+
--- /dev/null
+From 84edec86f449adea9ee0b4912a79ab8d9d65abb7 Mon Sep 17 00:00:00 2001
+From: Chris Lesiak <chris.lesiak@licor.com>
+Date: Mon, 14 Jun 2021 09:18:20 -0500
+Subject: iio: humidity: hdc100x: Add margin to the conversion time
+
+From: Chris Lesiak <chris.lesiak@licor.com>
+
+commit 84edec86f449adea9ee0b4912a79ab8d9d65abb7 upstream.
+
+The datasheets have the following note for the conversion time
+specification: "This parameter is specified by design and/or
+characterization and it is not tested in production."
+
+Parts have been seen that require more time to do 14-bit conversions for
+the relative humidity channel. The result is ENXIO due to the address
+phase of a transfer not getting an ACK.
+
+Delay an additional 1 ms per conversion to allow for additional margin.
+
+Fixes: 4839367d99e3 ("iio: humidity: add HDC100x support")
+Signed-off-by: Chris Lesiak <chris.lesiak@licor.com>
+Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
+Link: https://lore.kernel.org/r/20210614141820.2034827-1-chris.lesiak@licor.com
+Cc: <Stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/humidity/hdc100x.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/iio/humidity/hdc100x.c
++++ b/drivers/iio/humidity/hdc100x.c
+@@ -24,6 +24,8 @@
+ #include <linux/iio/trigger_consumer.h>
+ #include <linux/iio/triggered_buffer.h>
+
++#include <linux/time.h>
++
+ #define HDC100X_REG_TEMP 0x00
+ #define HDC100X_REG_HUMIDITY 0x01
+
+@@ -165,7 +167,7 @@ static int hdc100x_get_measurement(struc
+ struct iio_chan_spec const *chan)
+ {
+ struct i2c_client *client = data->client;
+- int delay = data->adc_int_us[chan->address];
++ int delay = data->adc_int_us[chan->address] + 1*USEC_PER_MSEC;
+ int ret;
+ __be16 val;
+
+@@ -322,7 +324,7 @@ static irqreturn_t hdc100x_trigger_handl
+ struct iio_dev *indio_dev = pf->indio_dev;
+ struct hdc100x_data *data = iio_priv(indio_dev);
+ struct i2c_client *client = data->client;
+- int delay = data->adc_int_us[0] + data->adc_int_us[1];
++ int delay = data->adc_int_us[0] + data->adc_int_us[1] + 2*USEC_PER_MSEC;
+ int ret;
+
+ /* dual read starts at temp register */
--- /dev/null
+From d9cee9f85b22fab88d2b76d2e92b18e3d0e6aa8c Mon Sep 17 00:00:00 2001
+From: Dan Williams <dan.j.williams@intel.com>
+Date: Fri, 30 Jul 2021 09:46:04 -0700
+Subject: libnvdimm/region: Fix label activation vs errors
+
+From: Dan Williams <dan.j.williams@intel.com>
+
+commit d9cee9f85b22fab88d2b76d2e92b18e3d0e6aa8c upstream.
+
+There are a few scenarios where init_active_labels() can return without
+registering deactivate_labels() to run when the region is disabled. In
+particular label error injection creates scenarios where a DIMM is
+disabled, but labels on other DIMMs in the region become activated.
+
+Arrange for init_active_labels() to always register deactivate_labels().
+
+Reported-by: Krzysztof Kensicki <krzysztof.kensicki@intel.com>
+Cc: <stable@vger.kernel.org>
+Fixes: bf9bccc14c05 ("libnvdimm: pmem label sets and namespace instantiation.")
+Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
+Link: https://lore.kernel.org/r/162766356450.3223041.1183118139023841447.stgit@dwillia2-desk3.amr.corp.intel.com
+Signed-off-by: Dan Williams <dan.j.williams@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/nvdimm/namespace_devs.c | 17 +++++++++++------
+ 1 file changed, 11 insertions(+), 6 deletions(-)
+
+--- a/drivers/nvdimm/namespace_devs.c
++++ b/drivers/nvdimm/namespace_devs.c
+@@ -2486,7 +2486,7 @@ static void deactivate_labels(void *regi
+
+ static int init_active_labels(struct nd_region *nd_region)
+ {
+- int i;
++ int i, rc = 0;
+
+ for (i = 0; i < nd_region->ndr_mappings; i++) {
+ struct nd_mapping *nd_mapping = &nd_region->mapping[i];
+@@ -2505,13 +2505,14 @@ static int init_active_labels(struct nd_
+ else if (test_bit(NDD_ALIASING, &nvdimm->flags))
+ /* fail, labels needed to disambiguate dpa */;
+ else
+- return 0;
++ continue;
+
+ dev_err(&nd_region->dev, "%s: is %s, failing probe\n",
+ dev_name(&nd_mapping->nvdimm->dev),
+ test_bit(NDD_LOCKED, &nvdimm->flags)
+ ? "locked" : "disabled");
+- return -ENXIO;
++ rc = -ENXIO;
++ goto out;
+ }
+ nd_mapping->ndd = ndd;
+ atomic_inc(&nvdimm->busy);
+@@ -2545,13 +2546,17 @@ static int init_active_labels(struct nd_
+ break;
+ }
+
+- if (i < nd_region->ndr_mappings) {
++ if (i < nd_region->ndr_mappings)
++ rc = -ENOMEM;
++
++out:
++ if (rc) {
+ deactivate_labels(nd_region);
+- return -ENOMEM;
++ return rc;
+ }
+
+ return devm_add_action_or_reset(&nd_region->dev, deactivate_labels,
+- nd_region);
++ nd_region);
+ }
+
+ int nd_region_register_namespaces(struct nd_region *nd_region, int *err)
--- /dev/null
+iio-adc-ti-ads7950-ensure-cs-is-deasserted-after-reading-channels.patch
+iio-humidity-hdc100x-add-margin-to-the-conversion-time.patch
+iio-adc-fix-incorrect-exit-of-for-loop.patch
+asoc-xilinx-fix-reference-to-pcm-buffer-address.patch
+asoc-intel-atom-fix-reference-to-pcm-buffer-address.patch
+i2c-dev-zero-out-array-used-for-i2c-reads-from-userspace.patch
+ceph-reduce-contention-in-ceph_check_delayed_caps.patch
+acpi-nfit-fix-support-for-virtual-spa-ranges.patch
+libnvdimm-region-fix-label-activation-vs-errors.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
