--- /dev/null
+From 660564fc9a92a893a14f255be434f7ea0b967901 Mon Sep 17 00:00:00 2001
+From: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
+Date: Thu, 21 Apr 2022 15:54:02 +0300
+Subject: ASoC: dmaengine: Restore NULL prepare_slave_config() callback
+
+From: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
+
+commit 660564fc9a92a893a14f255be434f7ea0b967901 upstream.
+
+As pointed out by Sascha Hauer, this patch changes:
+if (pmc->config && !pcm->config->prepare_slave_config)
+ <do nothing>
+to:
+if (pmc->config && !pcm->config->prepare_slave_config)
+ snd_dmaengine_pcm_prepare_slave_config()
+
+This breaks the drivers that do not need a call to
+dmaengine_slave_config(). Drivers that still need to call
+snd_dmaengine_pcm_prepare_slave_config(), but have a NULL
+pcm->config->prepare_slave_config should use
+snd_dmaengine_pcm_prepare_slave_config() as their prepare_slave_config
+callback.
+
+Fixes: 9a1e13440a4f ("ASoC: dmaengine: do not use a NULL prepare_slave_config() callback")
+Reported-by: Sascha Hauer <sha@pengutronix.de>
+Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
+Link: https://lore.kernel.org/r/20220421125403.2180824-1-codrin.ciubotariu@microchip.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/soc-generic-dmaengine-pcm.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/sound/soc/soc-generic-dmaengine-pcm.c
++++ b/sound/soc/soc-generic-dmaengine-pcm.c
+@@ -82,10 +82,10 @@ static int dmaengine_pcm_hw_params(struc
+
+ memset(&slave_config, 0, sizeof(slave_config));
+
+- if (pcm->config && pcm->config->prepare_slave_config)
+- prepare_slave_config = pcm->config->prepare_slave_config;
+- else
++ if (!pcm->config)
+ prepare_slave_config = snd_dmaengine_pcm_prepare_slave_config;
++ else
++ prepare_slave_config = pcm->config->prepare_slave_config;
+
+ if (prepare_slave_config) {
+ int ret = prepare_slave_config(substream, params, &slave_config);
--- /dev/null
+From eb5773201b1c5d603424bd21f161c8c2d1075b42 Mon Sep 17 00:00:00 2001
+From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
+Date: Thu, 21 Apr 2022 11:23:28 -0500
+Subject: ASoC: soc-ops: fix error handling
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
+
+commit eb5773201b1c5d603424bd21f161c8c2d1075b42 upstream.
+
+cppcheck throws the following warning:
+
+sound/soc/soc-ops.c:461:8: style: Variable 'ret' is assigned a value
+that is never used. [unreadVariable]
+ ret = err;
+ ^
+
+This seems to be a missing change in the return value.
+
+Fixes: 7f3d90a351968 ("ASoC: ops: Fix stereo change notifications in snd_soc_put_volsw_sx()")
+Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
+Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
+Reviewed-by: Rander Wang <rander.wang@intel.com>
+Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
+Link: https://lore.kernel.org/r/20220421162328.302017-1-pierre-louis.bossart@linux.intel.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/soc-ops.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/sound/soc/soc-ops.c
++++ b/sound/soc/soc-ops.c
+@@ -461,7 +461,7 @@ int snd_soc_put_volsw_sx(struct snd_kcon
+ ret = err;
+ }
+ }
+- return err;
++ return ret;
+ }
+ EXPORT_SYMBOL_GPL(snd_soc_put_volsw_sx);
+
--- /dev/null
+From aafa025c76dcc7d1a8c8f0bdefcbe4eb480b2f6a Mon Sep 17 00:00:00 2001
+From: Javier Martinez Canillas <javierm@redhat.com>
+Date: Mon, 2 May 2022 15:50:14 +0200
+Subject: fbdev: Make fb_release() return -ENODEV if fbdev was unregistered
+
+From: Javier Martinez Canillas <javierm@redhat.com>
+
+commit aafa025c76dcc7d1a8c8f0bdefcbe4eb480b2f6a upstream.
+
+A reference to the framebuffer device struct fb_info is stored in the file
+private data, but this reference could no longer be valid and must not be
+accessed directly. Instead, the file_fb_info() accessor function must be
+used since it does sanity checking to make sure that the fb_info is valid.
+
+This can happen for example if the registered framebuffer device is for a
+driver that just uses a framebuffer provided by the system firmware. In
+that case, the fbdev core would unregister the framebuffer device when a
+real video driver is probed and ask to remove conflicting framebuffers.
+
+The bug has been present for a long time but commit 27599aacbaef ("fbdev:
+Hot-unplug firmware fb devices on forced removal") unmasked it since the
+fbdev core started unregistering the framebuffers' devices associated.
+
+Fixes: 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal")
+Reported-by: Maxime Ripard <maxime@cerno.tech>
+Reported-by: Junxiao Chang <junxiao.chang@intel.com>
+Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
+Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
+Link: https://patchwork.freedesktop.org/patch/msgid/20220502135014.377945-1-javierm@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/video/fbdev/core/fbmem.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/video/fbdev/core/fbmem.c
++++ b/drivers/video/fbdev/core/fbmem.c
+@@ -1436,7 +1436,10 @@ fb_release(struct inode *inode, struct f
+ __acquires(&info->lock)
+ __releases(&info->lock)
+ {
+- struct fb_info * const info = file->private_data;
++ struct fb_info * const info = file_fb_info(file);
++
++ if (!info)
++ return -ENODEV;
+
+ lock_fb_info(info);
+ if (info->fbops->fb_release)
--- /dev/null
+From e5f6e5d554ac274f9c8ba60078103d0425b93c19 Mon Sep 17 00:00:00 2001
+From: Baruch Siach <baruch@tkos.co.il>
+Date: Mon, 11 Apr 2022 09:23:40 +0300
+Subject: gpio: mvebu: drop pwm base assignment
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Baruch Siach <baruch@tkos.co.il>
+
+commit e5f6e5d554ac274f9c8ba60078103d0425b93c19 upstream.
+
+pwmchip_add() unconditionally assigns the base ID dynamically. Commit
+f9a8ee8c8bcd1 ("pwm: Always allocate PWM chip base ID dynamically")
+dropped all base assignment from drivers under drivers/pwm/. It missed
+this driver. Fix that.
+
+Fixes: f9a8ee8c8bcd1 ("pwm: Always allocate PWM chip base ID dynamically")
+Signed-off-by: Baruch Siach <baruch@tkos.co.il>
+Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
+Acked-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpio/gpio-mvebu.c | 7 -------
+ 1 file changed, 7 deletions(-)
+
+--- a/drivers/gpio/gpio-mvebu.c
++++ b/drivers/gpio/gpio-mvebu.c
+@@ -871,13 +871,6 @@ static int mvebu_pwm_probe(struct platfo
+ mvpwm->chip.dev = dev;
+ mvpwm->chip.ops = &mvebu_pwm_ops;
+ mvpwm->chip.npwm = mvchip->chip.ngpio;
+- /*
+- * There may already be some PWM allocated, so we can't force
+- * mvpwm->chip.base to a fixed point like mvchip->chip.base.
+- * So, we let pwmchip_add() do the numbering and take the next free
+- * region.
+- */
+- mvpwm->chip.base = -1;
+
+ spin_lock_init(&mvpwm->lock);
+
--- /dev/null
+From dba785798526a3282cc4d0f0ea751883715dbbb4 Mon Sep 17 00:00:00 2001
+From: Puyou Lu <puyou.lu@gmail.com>
+Date: Fri, 6 May 2022 16:06:30 +0800
+Subject: gpio: pca953x: fix irq_stat not updated when irq is disabled (irq_mask not set)
+
+From: Puyou Lu <puyou.lu@gmail.com>
+
+commit dba785798526a3282cc4d0f0ea751883715dbbb4 upstream.
+
+When one port's input state get inverted (eg. from low to hight) after
+pca953x_irq_setup but before setting irq_mask (by some other driver such as
+"gpio-keys"), the next inversion of this port (eg. from hight to low) will not
+be triggered any more (because irq_stat is not updated at the first time). Issue
+should be fixed after this commit.
+
+Fixes: 89ea8bbe9c3e ("gpio: pca953x.c: add interrupt handling capability")
+Signed-off-by: Puyou Lu <puyou.lu@gmail.com>
+Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpio/gpio-pca953x.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpio/gpio-pca953x.c
++++ b/drivers/gpio/gpio-pca953x.c
+@@ -762,11 +762,11 @@ static bool pca953x_irq_pending(struct p
+ bitmap_xor(cur_stat, new_stat, old_stat, gc->ngpio);
+ bitmap_and(trigger, cur_stat, chip->irq_mask, gc->ngpio);
+
++ bitmap_copy(chip->irq_stat, new_stat, gc->ngpio);
++
+ if (bitmap_empty(trigger, gc->ngpio))
+ return false;
+
+- bitmap_copy(chip->irq_stat, new_stat, gc->ngpio);
+-
+ bitmap_and(cur_stat, chip->irq_trig_fall, old_stat, gc->ngpio);
+ bitmap_and(old_stat, chip->irq_trig_raise, new_stat, gc->ngpio);
+ bitmap_or(new_stat, old_stat, cur_stat, gc->ngpio);
--- /dev/null
+From 171865dab096da1ab980a32eeea5d1b88cd7bc50 Mon Sep 17 00:00:00 2001
+From: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
+Date: Thu, 21 Apr 2022 18:42:28 +0900
+Subject: gpio: visconti: Fix fwnode of GPIO IRQ
+
+From: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
+
+commit 171865dab096da1ab980a32eeea5d1b88cd7bc50 upstream.
+
+The fwnode of GPIO IRQ must be set to its own fwnode, not the fwnode of the
+parent IRQ. Therefore, this sets own fwnode instead of the parent IRQ fwnode to
+GPIO IRQ's.
+
+Fixes: 2ad74f40dacc ("gpio: visconti: Add Toshiba Visconti GPIO support")
+Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
+Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpio/gpio-visconti.c | 7 ++-----
+ 1 file changed, 2 insertions(+), 5 deletions(-)
+
+--- a/drivers/gpio/gpio-visconti.c
++++ b/drivers/gpio/gpio-visconti.c
+@@ -130,7 +130,6 @@ static int visconti_gpio_probe(struct pl
+ struct gpio_irq_chip *girq;
+ struct irq_domain *parent;
+ struct device_node *irq_parent;
+- struct fwnode_handle *fwnode;
+ int ret;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+@@ -150,14 +149,12 @@ static int visconti_gpio_probe(struct pl
+ }
+
+ parent = irq_find_host(irq_parent);
++ of_node_put(irq_parent);
+ if (!parent) {
+ dev_err(dev, "No IRQ parent domain\n");
+ return -ENODEV;
+ }
+
+- fwnode = of_node_to_fwnode(irq_parent);
+- of_node_put(irq_parent);
+-
+ ret = bgpio_init(&priv->gpio_chip, dev, 4,
+ priv->base + GPIO_IDATA,
+ priv->base + GPIO_OSET,
+@@ -180,7 +177,7 @@ static int visconti_gpio_probe(struct pl
+
+ girq = &priv->gpio_chip.irq;
+ girq->chip = irq_chip;
+- girq->fwnode = fwnode;
++ girq->fwnode = of_node_to_fwnode(dev->of_node);
+ girq->parent_domain = parent;
+ girq->child_to_parent_hwirq = visconti_gpio_child_to_parent_hwirq;
+ girq->populate_parent_alloc_arg = visconti_gpio_populate_parent_fwspec;
--- /dev/null
+From 7b2666ce445c700b8dcee994da44ddcf050a0842 Mon Sep 17 00:00:00 2001
+From: Armin Wolf <W_Armin@gmx.de>
+Date: Thu, 7 Apr 2022 12:13:12 +0200
+Subject: hwmon: (adt7470) Fix warning on module removal
+
+From: Armin Wolf <W_Armin@gmx.de>
+
+commit 7b2666ce445c700b8dcee994da44ddcf050a0842 upstream.
+
+When removing the adt7470 module, a warning might be printed:
+
+do not call blocking ops when !TASK_RUNNING; state=1
+set at [<ffffffffa006052b>] adt7470_update_thread+0x7b/0x130 [adt7470]
+
+This happens because adt7470_update_thread() can leave the kthread in
+TASK_INTERRUPTIBLE state when the kthread is being stopped before
+the call of set_current_state(). Since kthread_exit() might sleep in
+exit_signals(), the warning is printed.
+Fix that by using schedule_timeout_interruptible() and removing
+the call of set_current_state().
+This causes TASK_INTERRUPTIBLE to be set after kthread_should_stop()
+which might cause the kthread to exit.
+
+Reported-by: Zheyu Ma <zheyuma97@gmail.com>
+Fixes: 93cacfd41f82 (hwmon: (adt7470) Allow faster removal)
+Signed-off-by: Armin Wolf <W_Armin@gmx.de>
+Tested-by: Zheyu Ma <zheyuma97@gmail.com>
+Link: https://lore.kernel.org/r/20220407101312.13331-1-W_Armin@gmx.de
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/hwmon/adt7470.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/hwmon/adt7470.c
++++ b/drivers/hwmon/adt7470.c
+@@ -19,6 +19,7 @@
+ #include <linux/log2.h>
+ #include <linux/kthread.h>
+ #include <linux/regmap.h>
++#include <linux/sched.h>
+ #include <linux/slab.h>
+ #include <linux/util_macros.h>
+
+@@ -294,11 +295,10 @@ static int adt7470_update_thread(void *p
+ adt7470_read_temperatures(data);
+ mutex_unlock(&data->lock);
+
+- set_current_state(TASK_INTERRUPTIBLE);
+ if (kthread_should_stop())
+ break;
+
+- schedule_timeout(msecs_to_jiffies(data->auto_update_interval));
++ schedule_timeout_interruptible(msecs_to_jiffies(data->auto_update_interval));
+ }
+
+ return 0;
--- /dev/null
+From 75d2b2b06bd8407d03a3f126bc8b95eb356906c7 Mon Sep 17 00:00:00 2001
+From: Adam Wujek <dev_public@wujek.eu>
+Date: Wed, 20 Apr 2022 14:51:25 +0000
+Subject: hwmon: (pmbus) disable PEC if not enabled
+
+From: Adam Wujek <dev_public@wujek.eu>
+
+commit 75d2b2b06bd8407d03a3f126bc8b95eb356906c7 upstream.
+
+Explicitly disable PEC when the client does not support it.
+The problematic scenario is the following. A device with enabled PEC
+support is up and running and a kernel driver is loaded.
+Then the driver is unloaded (or device unbound), the HW device
+is reconfigured externally (e.g. by i2cset) to advertise itself as not
+supporting PEC. Without a new code, at the second load of the driver
+(or bind) the "flags" variable is not updated to avoid PEC usage. As a
+consequence the further communication with the device is done with
+the PEC enabled, which is wrong and may fail.
+
+The implementation first disable the I2C_CLIENT_PEC flag, then the old
+code enable it if needed.
+
+Fixes: 4e5418f787ec ("hwmon: (pmbus_core) Check adapter PEC support")
+Signed-off-by: Adam Wujek <dev_public@wujek.eu>
+Link: https://lore.kernel.org/r/20220420145059.431061-1-dev_public@wujek.eu
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/hwmon/pmbus/pmbus_core.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/hwmon/pmbus/pmbus_core.c b/drivers/hwmon/pmbus/pmbus_core.c
+index b2618b1d529e..d93574d6a1fb 100644
+--- a/drivers/hwmon/pmbus/pmbus_core.c
++++ b/drivers/hwmon/pmbus/pmbus_core.c
+@@ -2326,6 +2326,9 @@ static int pmbus_init_common(struct i2c_client *client, struct pmbus_data *data,
+ data->has_status_word = true;
+ }
+
++ /* Make sure PEC is disabled, will be enabled later if needed */
++ client->flags &= ~I2C_CLIENT_PEC;
++
+ /* Enable PEC if the controller and bus supports it */
+ if (!(data->flags & PMBUS_NO_CAPABILITY)) {
+ ret = i2c_smbus_read_byte_data(client, PMBUS_CAPABILITY);
+--
+2.36.1
+
--- /dev/null
+From a15932f4377062364d22096afe25bc579134a1c3 Mon Sep 17 00:00:00 2001
+From: Yang Yingliang <yangyingliang@huawei.com>
+Date: Mon, 25 Apr 2022 17:08:26 +0800
+Subject: iommu/dart: check return value after calling platform_get_resource()
+
+From: Yang Yingliang <yangyingliang@huawei.com>
+
+commit a15932f4377062364d22096afe25bc579134a1c3 upstream.
+
+It will cause null-ptr-deref in resource_size(), if platform_get_resource()
+returns NULL, move calling resource_size() after devm_ioremap_resource() that
+will check 'res' to avoid null-ptr-deref.
+And use devm_platform_get_and_ioremap_resource() to simplify code.
+
+Fixes: 46d1fb072e76 ("iommu/dart: Add DART iommu driver")
+Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
+Reviewed-by: Sven Peter <sven@svenpeter.dev>
+Link: https://lore.kernel.org/r/20220425090826.2532165-1-yangyingliang@huawei.com
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/apple-dart.c | 9 ++++-----
+ 1 file changed, 4 insertions(+), 5 deletions(-)
+
+--- a/drivers/iommu/apple-dart.c
++++ b/drivers/iommu/apple-dart.c
+@@ -832,16 +832,15 @@ static int apple_dart_probe(struct platf
+ dart->dev = dev;
+ spin_lock_init(&dart->lock);
+
+- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
++ dart->regs = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
++ if (IS_ERR(dart->regs))
++ return PTR_ERR(dart->regs);
++
+ if (resource_size(res) < 0x4000) {
+ dev_err(dev, "MMIO region too small (%pr)\n", res);
+ return -EINVAL;
+ }
+
+- dart->regs = devm_ioremap_resource(dev, res);
+- if (IS_ERR(dart->regs))
+- return PTR_ERR(dart->regs);
+-
+ dart->irq = platform_get_irq(pdev, 0);
+ if (dart->irq < 0)
+ return -ENODEV;
--- /dev/null
+From da8669ff41fa31573375c9a4180f5c080677204b Mon Sep 17 00:00:00 2001
+From: Lu Baolu <baolu.lu@linux.intel.com>
+Date: Sat, 23 Apr 2022 16:23:30 +0800
+Subject: iommu/vt-d: Drop stop marker messages
+
+From: Lu Baolu <baolu.lu@linux.intel.com>
+
+commit da8669ff41fa31573375c9a4180f5c080677204b upstream.
+
+The page fault handling framework in the IOMMU core explicitly states
+that it doesn't handle PCI PASID Stop Marker and the IOMMU drivers must
+discard them before reporting faults. This handles Stop Marker messages
+in prq_event_thread() before reporting events to the core.
+
+The VT-d driver explicitly drains the pending page requests when a CPU
+page table (represented by a mm struct) is unbound from a PASID according
+to the procedures defined in the VT-d spec. The Stop Marker messages do
+not need a response. Hence, it is safe to drop the Stop Marker messages
+silently if any of them is found in the page request queue.
+
+Fixes: d5b9e4bfe0d88 ("iommu/vt-d: Report prq to io-pgfault framework")
+Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
+Reviewed-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
+Reviewed-by: Kevin Tian <kevin.tian@intel.com>
+Link: https://lore.kernel.org/r/20220421113558.3504874-1-baolu.lu@linux.intel.com
+Link: https://lore.kernel.org/r/20220423082330.3897867-2-baolu.lu@linux.intel.com
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/intel/svm.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/iommu/intel/svm.c
++++ b/drivers/iommu/intel/svm.c
+@@ -978,6 +978,10 @@ bad_req:
+ goto bad_req;
+ }
+
++ /* Drop Stop Marker message. No need for a response. */
++ if (unlikely(req->lpig && !req->rd_req && !req->wr_req))
++ goto prq_advance;
++
+ if (!svm || svm->pasid != req->pasid) {
+ /*
+ * It can't go away, because the driver is not permitted
--- /dev/null
+From fc3d3db07b35885f238e1fa06b9f04a8fa7a62d0 Mon Sep 17 00:00:00 2001
+From: Moshe Shemesh <moshe@nvidia.com>
+Date: Mon, 11 Apr 2022 20:38:44 +0300
+Subject: net/mlx5: Avoid double clear or set of sync reset requested
+
+From: Moshe Shemesh <moshe@nvidia.com>
+
+commit fc3d3db07b35885f238e1fa06b9f04a8fa7a62d0 upstream.
+
+Double clear of reset requested state can lead to NULL pointer as it
+will try to delete the timer twice. This can happen for example on a
+race between abort from FW and pci error or reset. Avoid such case using
+test_and_clear_bit() to verify only one time reset requested state clear
+flow. Similarly use test_and_set_bit() to verify only one time reset
+requested state set flow.
+
+Fixes: 7dd6df329d4c ("net/mlx5: Handle sync reset abort event")
+Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
+Reviewed-by: Maher Sanalla <msanalla@nvidia.com>
+Reviewed-by: Shay Drory <shayd@nvidia.com>
+Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/mellanox/mlx5/core/fw_reset.c | 28 ++++++++++++++-------
+ 1 file changed, 19 insertions(+), 9 deletions(-)
+
+--- a/drivers/net/ethernet/mellanox/mlx5/core/fw_reset.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/fw_reset.c
+@@ -134,14 +134,19 @@ static void mlx5_stop_sync_reset_poll(st
+ del_timer_sync(&fw_reset->timer);
+ }
+
+-static void mlx5_sync_reset_clear_reset_requested(struct mlx5_core_dev *dev, bool poll_health)
++static int mlx5_sync_reset_clear_reset_requested(struct mlx5_core_dev *dev, bool poll_health)
+ {
+ struct mlx5_fw_reset *fw_reset = dev->priv.fw_reset;
+
++ if (!test_and_clear_bit(MLX5_FW_RESET_FLAGS_RESET_REQUESTED, &fw_reset->reset_flags)) {
++ mlx5_core_warn(dev, "Reset request was already cleared\n");
++ return -EALREADY;
++ }
++
+ mlx5_stop_sync_reset_poll(dev);
+- clear_bit(MLX5_FW_RESET_FLAGS_RESET_REQUESTED, &fw_reset->reset_flags);
+ if (poll_health)
+ mlx5_start_health_poll(dev);
++ return 0;
+ }
+
+ #define MLX5_RESET_POLL_INTERVAL (HZ / 10)
+@@ -185,13 +190,17 @@ static int mlx5_fw_reset_set_reset_sync_
+ return mlx5_reg_mfrl_set(dev, MLX5_MFRL_REG_RESET_LEVEL3, 0, 2, false);
+ }
+
+-static void mlx5_sync_reset_set_reset_requested(struct mlx5_core_dev *dev)
++static int mlx5_sync_reset_set_reset_requested(struct mlx5_core_dev *dev)
+ {
+ struct mlx5_fw_reset *fw_reset = dev->priv.fw_reset;
+
++ if (test_and_set_bit(MLX5_FW_RESET_FLAGS_RESET_REQUESTED, &fw_reset->reset_flags)) {
++ mlx5_core_warn(dev, "Reset request was already set\n");
++ return -EALREADY;
++ }
+ mlx5_stop_health_poll(dev, true);
+- set_bit(MLX5_FW_RESET_FLAGS_RESET_REQUESTED, &fw_reset->reset_flags);
+ mlx5_start_sync_reset_poll(dev);
++ return 0;
+ }
+
+ static void mlx5_fw_live_patch_event(struct work_struct *work)
+@@ -220,7 +229,9 @@ static void mlx5_sync_reset_request_even
+ err ? "Failed" : "Sent");
+ return;
+ }
+- mlx5_sync_reset_set_reset_requested(dev);
++ if (mlx5_sync_reset_set_reset_requested(dev))
++ return;
++
+ err = mlx5_fw_reset_set_reset_sync_ack(dev);
+ if (err)
+ mlx5_core_warn(dev, "PCI Sync FW Update Reset Ack Failed. Error code: %d\n", err);
+@@ -320,7 +331,8 @@ static void mlx5_sync_reset_now_event(st
+ struct mlx5_core_dev *dev = fw_reset->dev;
+ int err;
+
+- mlx5_sync_reset_clear_reset_requested(dev, false);
++ if (mlx5_sync_reset_clear_reset_requested(dev, false))
++ return;
+
+ mlx5_core_warn(dev, "Sync Reset now. Device is going to reset.\n");
+
+@@ -349,10 +361,8 @@ static void mlx5_sync_reset_abort_event(
+ reset_abort_work);
+ struct mlx5_core_dev *dev = fw_reset->dev;
+
+- if (!test_bit(MLX5_FW_RESET_FLAGS_RESET_REQUESTED, &fw_reset->reset_flags))
++ if (mlx5_sync_reset_clear_reset_requested(dev, true))
+ return;
+-
+- mlx5_sync_reset_clear_reset_requested(dev, true);
+ mlx5_core_warn(dev, "PCI Sync FW Update Reset Aborted.\n");
+ }
+
--- /dev/null
+From cb7786a76ea39f394f0a059787fe24fa8e340fb6 Mon Sep 17 00:00:00 2001
+From: Moshe Shemesh <moshe@nvidia.com>
+Date: Mon, 11 Apr 2022 21:31:06 +0300
+Subject: net/mlx5: Fix deadlock in sync reset flow
+
+From: Moshe Shemesh <moshe@nvidia.com>
+
+commit cb7786a76ea39f394f0a059787fe24fa8e340fb6 upstream.
+
+The sync reset flow can lead to the following deadlock when
+poll_sync_reset() is called by timer softirq and waiting on
+del_timer_sync() for the same timer. Fix that by moving the part of the
+flow that waits for the timer to reset_reload_work.
+
+It fixes the following kernel Trace:
+RIP: 0010:del_timer_sync+0x32/0x40
+...
+Call Trace:
+ <IRQ>
+ mlx5_sync_reset_clear_reset_requested+0x26/0x50 [mlx5_core]
+ poll_sync_reset.cold+0x36/0x52 [mlx5_core]
+ call_timer_fn+0x32/0x130
+ __run_timers.part.0+0x180/0x280
+ ? tick_sched_handle+0x33/0x60
+ ? tick_sched_timer+0x3d/0x80
+ ? ktime_get+0x3e/0xa0
+ run_timer_softirq+0x2a/0x50
+ __do_softirq+0xe1/0x2d6
+ ? hrtimer_interrupt+0x136/0x220
+ irq_exit+0xae/0xb0
+ smp_apic_timer_interrupt+0x7b/0x140
+ apic_timer_interrupt+0xf/0x20
+ </IRQ>
+
+Fixes: 3c5193a87b0f ("net/mlx5: Use del_timer_sync in fw reset flow of halting poll")
+Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
+Reviewed-by: Maher Sanalla <msanalla@nvidia.com>
+Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/mellanox/mlx5/core/fw_reset.c | 34 ++++++++++-----------
+ 1 file changed, 17 insertions(+), 17 deletions(-)
+
+--- a/drivers/net/ethernet/mellanox/mlx5/core/fw_reset.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/fw_reset.c
+@@ -111,22 +111,6 @@ static void mlx5_fw_reset_complete_reloa
+ }
+ }
+
+-static void mlx5_sync_reset_reload_work(struct work_struct *work)
+-{
+- struct mlx5_fw_reset *fw_reset = container_of(work, struct mlx5_fw_reset,
+- reset_reload_work);
+- struct mlx5_core_dev *dev = fw_reset->dev;
+- int err;
+-
+- mlx5_enter_error_state(dev, true);
+- mlx5_unload_one(dev);
+- err = mlx5_health_wait_pci_up(dev);
+- if (err)
+- mlx5_core_err(dev, "reset reload flow aborted, PCI reads still not working\n");
+- fw_reset->ret = err;
+- mlx5_fw_reset_complete_reload(dev);
+-}
+-
+ static void mlx5_stop_sync_reset_poll(struct mlx5_core_dev *dev)
+ {
+ struct mlx5_fw_reset *fw_reset = dev->priv.fw_reset;
+@@ -149,6 +133,23 @@ static int mlx5_sync_reset_clear_reset_r
+ return 0;
+ }
+
++static void mlx5_sync_reset_reload_work(struct work_struct *work)
++{
++ struct mlx5_fw_reset *fw_reset = container_of(work, struct mlx5_fw_reset,
++ reset_reload_work);
++ struct mlx5_core_dev *dev = fw_reset->dev;
++ int err;
++
++ mlx5_sync_reset_clear_reset_requested(dev, false);
++ mlx5_enter_error_state(dev, true);
++ mlx5_unload_one(dev);
++ err = mlx5_health_wait_pci_up(dev);
++ if (err)
++ mlx5_core_err(dev, "reset reload flow aborted, PCI reads still not working\n");
++ fw_reset->ret = err;
++ mlx5_fw_reset_complete_reload(dev);
++}
++
+ #define MLX5_RESET_POLL_INTERVAL (HZ / 10)
+ static void poll_sync_reset(struct timer_list *t)
+ {
+@@ -163,7 +164,6 @@ static void poll_sync_reset(struct timer
+
+ if (fatal_error) {
+ mlx5_core_warn(dev, "Got Device Reset\n");
+- mlx5_sync_reset_clear_reset_requested(dev, false);
+ queue_work(fw_reset->wq, &fw_reset->reset_reload_work);
+ return;
+ }
--- /dev/null
+From b069e14fff46c8da9fcc79957f8acaa3e2dfdb6b Mon Sep 17 00:00:00 2001
+From: Paul Blakey <paulb@nvidia.com>
+Date: Tue, 29 Mar 2022 17:42:46 +0300
+Subject: net/mlx5e: CT: Fix queued up restore put() executing after relevant ft release
+
+From: Paul Blakey <paulb@nvidia.com>
+
+commit b069e14fff46c8da9fcc79957f8acaa3e2dfdb6b upstream.
+
+__mlx5_tc_ct_entry_put() queues release of tuple related to some ct FT,
+if that is the last reference to that tuple, the actual deletion of
+the tuple can happen after the FT is already destroyed and freed.
+
+Flush the used workqueue before destroying the ct FT.
+
+Fixes: a2173131526d ("net/mlx5e: CT: manage the lifetime of the ct entry object")
+Reviewed-by: Oz Shlomo <ozsh@nvidia.com>
+Signed-off-by: Paul Blakey <paulb@nvidia.com>
+Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/mellanox/mlx5/core/en/tc_ct.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_ct.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_ct.c
+@@ -1699,6 +1699,8 @@ mlx5_tc_ct_flush_ft_entry(void *ptr, voi
+ static void
+ mlx5_tc_ct_del_ft_cb(struct mlx5_tc_ct_priv *ct_priv, struct mlx5_ct_ft *ft)
+ {
++ struct mlx5e_priv *priv;
++
+ if (!refcount_dec_and_test(&ft->refcount))
+ return;
+
+@@ -1708,6 +1710,8 @@ mlx5_tc_ct_del_ft_cb(struct mlx5_tc_ct_p
+ rhashtable_free_and_destroy(&ft->ct_entries_ht,
+ mlx5_tc_ct_flush_ft_entry,
+ ct_priv);
++ priv = netdev_priv(ct_priv->netdev);
++ flush_workqueue(priv->wq);
+ mlx5_tc_ct_free_pre_ct_tables(ft);
+ mapping_remove(ct_priv->zone_mapping, ft->zone_restore_id);
+ kfree(ft);
--- /dev/null
+From ada09af92e621ab500dd80a16d1d0299a18a1180 Mon Sep 17 00:00:00 2001
+From: Vlad Buslov <vladbu@nvidia.com>
+Date: Mon, 28 Mar 2022 15:54:52 +0300
+Subject: net/mlx5e: Don't match double-vlan packets if cvlan is not set
+
+From: Vlad Buslov <vladbu@nvidia.com>
+
+commit ada09af92e621ab500dd80a16d1d0299a18a1180 upstream.
+
+Currently, match VLAN rule also matches packets that have multiple VLAN
+headers. This behavior is similar to buggy flower classifier behavior that
+has recently been fixed. Fix the issue by matching on
+outer_second_cvlan_tag with value 0 which will cause the HW to verify the
+packet doesn't contain second vlan header.
+
+Fixes: 699e96ddf47f ("net/mlx5e: Support offloading tc double vlan headers match")
+Signed-off-by: Vlad Buslov <vladbu@nvidia.com>
+Reviewed-by: Maor Dickman <maord@nvidia.com>
+Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+@@ -2291,6 +2291,17 @@ static int __parse_cls_flower(struct mlx
+ match.key->vlan_priority);
+
+ *match_level = MLX5_MATCH_L2;
++
++ if (!flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_CVLAN) &&
++ match.mask->vlan_eth_type &&
++ MLX5_CAP_FLOWTABLE_TYPE(priv->mdev,
++ ft_field_support.outer_second_vid,
++ fs_type)) {
++ MLX5_SET(fte_match_set_misc, misc_c,
++ outer_second_cvlan_tag, 1);
++ spec->match_criteria_enable |=
++ MLX5_MATCH_MISC_PARAMETERS;
++ }
+ }
+ } else if (*match_level != MLX5_MATCH_NONE) {
+ /* cvlan_tag enabled in match criteria and
--- /dev/null
+From c4d963a588a6e7c4ef31160e80697ae8e5a47746 Mon Sep 17 00:00:00 2001
+From: Mark Zhang <markzhang@nvidia.com>
+Date: Wed, 6 Apr 2022 10:30:21 +0300
+Subject: net/mlx5e: Fix the calling of update_buffer_lossy() API
+
+From: Mark Zhang <markzhang@nvidia.com>
+
+commit c4d963a588a6e7c4ef31160e80697ae8e5a47746 upstream.
+
+The arguments of update_buffer_lossy() is in a wrong order. Fix it.
+
+Fixes: 88b3d5c90e96 ("net/mlx5e: Fix port buffers cell size value")
+Signed-off-by: Mark Zhang <markzhang@nvidia.com>
+Reviewed-by: Maor Gottlieb <maorg@nvidia.com>
+Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/mellanox/mlx5/core/en/port_buffer.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/ethernet/mellanox/mlx5/core/en/port_buffer.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/en/port_buffer.c
+@@ -309,8 +309,8 @@ int mlx5e_port_manual_buffer_config(stru
+ if (err)
+ return err;
+
+- err = update_buffer_lossy(max_mtu, curr_pfc_en, prio2buffer, port_buff_cell_sz,
+- xoff, &port_buffer, &update_buffer);
++ err = update_buffer_lossy(max_mtu, curr_pfc_en, prio2buffer, xoff,
++ port_buff_cell_sz, &port_buffer, &update_buffer);
+ if (err)
+ return err;
+ }
--- /dev/null
+From b781bff882d16175277ca129c382886cb4c74a2c Mon Sep 17 00:00:00 2001
+From: Moshe Tal <moshet@nvidia.com>
+Date: Wed, 9 Feb 2022 19:23:56 +0200
+Subject: net/mlx5e: Fix trust state reset in reload
+
+From: Moshe Tal <moshet@nvidia.com>
+
+commit b781bff882d16175277ca129c382886cb4c74a2c upstream.
+
+Setting dscp2prio during the driver reload can cause dcb ieee app list to
+be not empty after the reload finish and as a result to a conflict between
+the priority trust state reported by the app and the state in the device
+register.
+
+Reset the dcb ieee app list on initialization in case this is
+conflicting with the register status.
+
+Fixes: 2a5e7a1344f4 ("net/mlx5e: Add dcbnl dscp to priority support")
+Signed-off-by: Moshe Tal <moshet@nvidia.com>
+Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
+@@ -1198,6 +1198,16 @@ static int mlx5e_trust_initialize(struct
+ if (err)
+ return err;
+
++ if (priv->dcbx_dp.trust_state == MLX5_QPTS_TRUST_PCP && priv->dcbx.dscp_app_cnt) {
++ /*
++ * Align the driver state with the register state.
++ * Temporary state change is required to enable the app list reset.
++ */
++ priv->dcbx_dp.trust_state = MLX5_QPTS_TRUST_DSCP;
++ mlx5e_dcbnl_delete_app(priv);
++ priv->dcbx_dp.trust_state = MLX5_QPTS_TRUST_PCP;
++ }
++
+ mlx5e_params_calc_trust_tx_min_inline_mode(priv->mdev, &priv->channels.params,
+ priv->dcbx_dp.trust_state);
+
--- /dev/null
+From 4071bf121d59944d5cd2238de0642f3d7995a997 Mon Sep 17 00:00:00 2001
+From: Duoming Zhou <duoming@zju.edu.cn>
+Date: Wed, 4 May 2022 13:58:47 +0800
+Subject: NFC: netlink: fix sleep in atomic bug when firmware download timeout
+
+From: Duoming Zhou <duoming@zju.edu.cn>
+
+commit 4071bf121d59944d5cd2238de0642f3d7995a997 upstream.
+
+There are sleep in atomic bug that could cause kernel panic during
+firmware download process. The root cause is that nlmsg_new with
+GFP_KERNEL parameter is called in fw_dnld_timeout which is a timer
+handler. The call trace is shown below:
+
+BUG: sleeping function called from invalid context at include/linux/sched/mm.h:265
+Call Trace:
+kmem_cache_alloc_node
+__alloc_skb
+nfc_genl_fw_download_done
+call_timer_fn
+__run_timers.part.0
+run_timer_softirq
+__do_softirq
+...
+
+The nlmsg_new with GFP_KERNEL parameter may sleep during memory
+allocation process, and the timer handler is run as the result of
+a "software interrupt" that should not call any other function
+that could sleep.
+
+This patch changes allocation mode of netlink message from GFP_KERNEL
+to GFP_ATOMIC in order to prevent sleep in atomic bug. The GFP_ATOMIC
+flag makes memory allocation operation could be used in atomic context.
+
+Fixes: 9674da8759df ("NFC: Add firmware upload netlink command")
+Fixes: 9ea7187c53f6 ("NFC: netlink: Rename CMD_FW_UPLOAD to CMD_FW_DOWNLOAD")
+Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
+Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://lore.kernel.org/r/20220504055847.38026-1-duoming@zju.edu.cn
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/nfc/netlink.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/net/nfc/netlink.c
++++ b/net/nfc/netlink.c
+@@ -1244,7 +1244,7 @@ int nfc_genl_fw_download_done(struct nfc
+ struct sk_buff *msg;
+ void *hdr;
+
+- msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
++ msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC);
+ if (!msg)
+ return -ENOMEM;
+
+@@ -1260,7 +1260,7 @@ int nfc_genl_fw_download_done(struct nfc
+
+ genlmsg_end(msg, hdr);
+
+- genlmsg_multicast(&nfc_genl_family, msg, 0, 0, GFP_KERNEL);
++ genlmsg_multicast(&nfc_genl_family, msg, 0, 0, GFP_ATOMIC);
+
+ return 0;
+
--- /dev/null
+From d270453a0d9ec10bb8a802a142fb1b3601a83098 Mon Sep 17 00:00:00 2001
+From: Duoming Zhou <duoming@zju.edu.cn>
+Date: Fri, 29 Apr 2022 20:45:51 +0800
+Subject: nfc: nfcmrvl: main: reorder destructive operations in nfcmrvl_nci_unregister_dev to avoid bugs
+
+From: Duoming Zhou <duoming@zju.edu.cn>
+
+commit d270453a0d9ec10bb8a802a142fb1b3601a83098 upstream.
+
+There are destructive operations such as nfcmrvl_fw_dnld_abort and
+gpio_free in nfcmrvl_nci_unregister_dev. The resources such as firmware,
+gpio and so on could be destructed while the upper layer functions such as
+nfcmrvl_fw_dnld_start and nfcmrvl_nci_recv_frame is executing, which leads
+to double-free, use-after-free and null-ptr-deref bugs.
+
+There are three situations that could lead to double-free bugs.
+
+The first situation is shown below:
+
+ (Thread 1) | (Thread 2)
+nfcmrvl_fw_dnld_start |
+ ... | nfcmrvl_nci_unregister_dev
+ release_firmware() | nfcmrvl_fw_dnld_abort
+ kfree(fw) //(1) | fw_dnld_over
+ | release_firmware
+ ... | kfree(fw) //(2)
+ | ...
+
+The second situation is shown below:
+
+ (Thread 1) | (Thread 2)
+nfcmrvl_fw_dnld_start |
+ ... |
+ mod_timer |
+ (wait a time) |
+ fw_dnld_timeout | nfcmrvl_nci_unregister_dev
+ fw_dnld_over | nfcmrvl_fw_dnld_abort
+ release_firmware | fw_dnld_over
+ kfree(fw) //(1) | release_firmware
+ ... | kfree(fw) //(2)
+
+The third situation is shown below:
+
+ (Thread 1) | (Thread 2)
+nfcmrvl_nci_recv_frame |
+ if(..->fw_download_in_progress)|
+ nfcmrvl_fw_dnld_recv_frame |
+ queue_work |
+ |
+fw_dnld_rx_work | nfcmrvl_nci_unregister_dev
+ fw_dnld_over | nfcmrvl_fw_dnld_abort
+ release_firmware | fw_dnld_over
+ kfree(fw) //(1) | release_firmware
+ | kfree(fw) //(2)
+
+The firmware struct is deallocated in position (1) and deallocated
+in position (2) again.
+
+The crash trace triggered by POC is like below:
+
+BUG: KASAN: double-free or invalid-free in fw_dnld_over
+Call Trace:
+ kfree
+ fw_dnld_over
+ nfcmrvl_nci_unregister_dev
+ nci_uart_tty_close
+ tty_ldisc_kill
+ tty_ldisc_hangup
+ __tty_hangup.part.0
+ tty_release
+ ...
+
+What's more, there are also use-after-free and null-ptr-deref bugs
+in nfcmrvl_fw_dnld_start. If we deallocate firmware struct, gpio or
+set null to the members of priv->fw_dnld in nfcmrvl_nci_unregister_dev,
+then, we dereference firmware, gpio or the members of priv->fw_dnld in
+nfcmrvl_fw_dnld_start, the UAF or NPD bugs will happen.
+
+This patch reorders destructive operations after nci_unregister_device
+in order to synchronize between cleanup routine and firmware download
+routine.
+
+The nci_unregister_device is well synchronized. If the device is
+detaching, the firmware download routine will goto error. If firmware
+download routine is executing, nci_unregister_device will wait until
+firmware download routine is finished.
+
+Fixes: 3194c6870158 ("NFC: nfcmrvl: add firmware download support")
+Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/nfc/nfcmrvl/main.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/nfc/nfcmrvl/main.c
++++ b/drivers/nfc/nfcmrvl/main.c
+@@ -183,6 +183,7 @@ void nfcmrvl_nci_unregister_dev(struct n
+ {
+ struct nci_dev *ndev = priv->ndev;
+
++ nci_unregister_device(ndev);
+ if (priv->ndev->nfc_dev->fw_download_in_progress)
+ nfcmrvl_fw_dnld_abort(priv);
+
+@@ -191,7 +192,6 @@ void nfcmrvl_nci_unregister_dev(struct n
+ if (gpio_is_valid(priv->config.reset_n_io))
+ gpio_free(priv->config.reset_n_io);
+
+- nci_unregister_device(ndev);
+ nci_free_device(ndev);
+ kfree(priv);
+ }
--- /dev/null
+From da5c0f119203ad9728920456a0f52a6d850c01cd Mon Sep 17 00:00:00 2001
+From: Duoming Zhou <duoming@zju.edu.cn>
+Date: Fri, 29 Apr 2022 20:45:50 +0800
+Subject: nfc: replace improper check device_is_registered() in netlink related functions
+
+From: Duoming Zhou <duoming@zju.edu.cn>
+
+commit da5c0f119203ad9728920456a0f52a6d850c01cd upstream.
+
+The device_is_registered() in nfc core is used to check whether
+nfc device is registered in netlink related functions such as
+nfc_fw_download(), nfc_dev_up() and so on. Although device_is_registered()
+is protected by device_lock, there is still a race condition between
+device_del() and device_is_registered(). The root cause is that
+kobject_del() in device_del() is not protected by device_lock.
+
+ (cleanup task) | (netlink task)
+ |
+nfc_unregister_device | nfc_fw_download
+ device_del | device_lock
+ ... | if (!device_is_registered)//(1)
+ kobject_del//(2) | ...
+ ... | device_unlock
+
+The device_is_registered() returns the value of state_in_sysfs and
+the state_in_sysfs is set to zero in kobject_del(). If we pass check in
+position (1), then set zero in position (2). As a result, the check
+in position (1) is useless.
+
+This patch uses bool variable instead of device_is_registered() to judge
+whether the nfc device is registered, which is well synchronized.
+
+Fixes: 3e256b8f8dfa ("NFC: add nfc subsystem core")
+Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/nfc/core.c | 29 ++++++++++++++---------------
+ 1 file changed, 14 insertions(+), 15 deletions(-)
+
+--- a/net/nfc/core.c
++++ b/net/nfc/core.c
+@@ -38,7 +38,7 @@ int nfc_fw_download(struct nfc_dev *dev,
+
+ device_lock(&dev->dev);
+
+- if (!device_is_registered(&dev->dev)) {
++ if (dev->shutting_down) {
+ rc = -ENODEV;
+ goto error;
+ }
+@@ -94,7 +94,7 @@ int nfc_dev_up(struct nfc_dev *dev)
+
+ device_lock(&dev->dev);
+
+- if (!device_is_registered(&dev->dev)) {
++ if (dev->shutting_down) {
+ rc = -ENODEV;
+ goto error;
+ }
+@@ -142,7 +142,7 @@ int nfc_dev_down(struct nfc_dev *dev)
+
+ device_lock(&dev->dev);
+
+- if (!device_is_registered(&dev->dev)) {
++ if (dev->shutting_down) {
+ rc = -ENODEV;
+ goto error;
+ }
+@@ -207,7 +207,7 @@ int nfc_start_poll(struct nfc_dev *dev,
+
+ device_lock(&dev->dev);
+
+- if (!device_is_registered(&dev->dev)) {
++ if (dev->shutting_down) {
+ rc = -ENODEV;
+ goto error;
+ }
+@@ -246,7 +246,7 @@ int nfc_stop_poll(struct nfc_dev *dev)
+
+ device_lock(&dev->dev);
+
+- if (!device_is_registered(&dev->dev)) {
++ if (dev->shutting_down) {
+ rc = -ENODEV;
+ goto error;
+ }
+@@ -291,7 +291,7 @@ int nfc_dep_link_up(struct nfc_dev *dev,
+
+ device_lock(&dev->dev);
+
+- if (!device_is_registered(&dev->dev)) {
++ if (dev->shutting_down) {
+ rc = -ENODEV;
+ goto error;
+ }
+@@ -335,7 +335,7 @@ int nfc_dep_link_down(struct nfc_dev *de
+
+ device_lock(&dev->dev);
+
+- if (!device_is_registered(&dev->dev)) {
++ if (dev->shutting_down) {
+ rc = -ENODEV;
+ goto error;
+ }
+@@ -401,7 +401,7 @@ int nfc_activate_target(struct nfc_dev *
+
+ device_lock(&dev->dev);
+
+- if (!device_is_registered(&dev->dev)) {
++ if (dev->shutting_down) {
+ rc = -ENODEV;
+ goto error;
+ }
+@@ -448,7 +448,7 @@ int nfc_deactivate_target(struct nfc_dev
+
+ device_lock(&dev->dev);
+
+- if (!device_is_registered(&dev->dev)) {
++ if (dev->shutting_down) {
+ rc = -ENODEV;
+ goto error;
+ }
+@@ -495,7 +495,7 @@ int nfc_data_exchange(struct nfc_dev *de
+
+ device_lock(&dev->dev);
+
+- if (!device_is_registered(&dev->dev)) {
++ if (dev->shutting_down) {
+ rc = -ENODEV;
+ kfree_skb(skb);
+ goto error;
+@@ -552,7 +552,7 @@ int nfc_enable_se(struct nfc_dev *dev, u
+
+ device_lock(&dev->dev);
+
+- if (!device_is_registered(&dev->dev)) {
++ if (dev->shutting_down) {
+ rc = -ENODEV;
+ goto error;
+ }
+@@ -601,7 +601,7 @@ int nfc_disable_se(struct nfc_dev *dev,
+
+ device_lock(&dev->dev);
+
+- if (!device_is_registered(&dev->dev)) {
++ if (dev->shutting_down) {
+ rc = -ENODEV;
+ goto error;
+ }
+@@ -1134,6 +1134,7 @@ int nfc_register_device(struct nfc_dev *
+ dev->rfkill = NULL;
+ }
+ }
++ dev->shutting_down = false;
+ device_unlock(&dev->dev);
+
+ rc = nfc_genl_device_added(dev);
+@@ -1166,12 +1167,10 @@ void nfc_unregister_device(struct nfc_de
+ rfkill_unregister(dev->rfkill);
+ rfkill_destroy(dev->rfkill);
+ }
++ dev->shutting_down = true;
+ device_unlock(&dev->dev);
+
+ if (dev->ops->check_presence) {
+- device_lock(&dev->dev);
+- dev->shutting_down = true;
+- device_unlock(&dev->dev);
+ del_timer_sync(&dev->check_pres_timer);
+ cancel_work_sync(&dev->check_pres_work);
+ }
--- /dev/null
+From 00c94ebec5925593c0377b941289224469e72ac7 Mon Sep 17 00:00:00 2001
+From: Trond Myklebust <trond.myklebust@hammerspace.com>
+Date: Mon, 25 Apr 2022 18:04:27 -0400
+Subject: NFSv4: Don't invalidate inode attributes on delegation return
+
+From: Trond Myklebust <trond.myklebust@hammerspace.com>
+
+commit 00c94ebec5925593c0377b941289224469e72ac7 upstream.
+
+There is no need to declare attributes such as the ctime, mtime and
+block size invalid when we're just returning a delegation, so it is
+inappropriate to call nfs_post_op_update_inode_force_wcc().
+Instead, just call nfs_refresh_inode() after faking up the change
+attribute. We know that the GETATTR op occurs before the DELEGRETURN, so
+we are safe when doing this.
+
+Fixes: 0bc2c9b4dca9 ("NFSv4: Don't discard the attributes returned by asynchronous DELEGRETURN")
+Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/nfs/nfs4proc.c | 12 +++++++++++-
+ 1 file changed, 11 insertions(+), 1 deletion(-)
+
+--- a/fs/nfs/nfs4proc.c
++++ b/fs/nfs/nfs4proc.c
+@@ -366,6 +366,14 @@ static void nfs4_setup_readdir(u64 cooki
+ kunmap_atomic(start);
+ }
+
++static void nfs4_fattr_set_prechange(struct nfs_fattr *fattr, u64 version)
++{
++ if (!(fattr->valid & NFS_ATTR_FATTR_PRECHANGE)) {
++ fattr->pre_change_attr = version;
++ fattr->valid |= NFS_ATTR_FATTR_PRECHANGE;
++ }
++}
++
+ static void nfs4_test_and_free_stateid(struct nfs_server *server,
+ nfs4_stateid *stateid,
+ const struct cred *cred)
+@@ -6558,7 +6566,9 @@ static void nfs4_delegreturn_release(voi
+ pnfs_roc_release(&data->lr.arg, &data->lr.res,
+ data->res.lr_ret);
+ if (inode) {
+- nfs_post_op_update_inode_force_wcc(inode, &data->fattr);
++ nfs4_fattr_set_prechange(&data->fattr,
++ inode_peek_iversion_raw(inode));
++ nfs_refresh_inode(inode, &data->fattr);
+ nfs_iput_and_deactive(inode);
+ }
+ kfree(calldata);
--- /dev/null
+From 1c9043ae0667a43bd87beeebbdd4bed674713629 Mon Sep 17 00:00:00 2001
+From: Mustafa Ismail <mustafa.ismail@intel.com>
+Date: Mon, 25 Apr 2022 13:17:03 -0500
+Subject: RDMA/irdma: Fix possible crash due to NULL netdev in notifier
+
+From: Mustafa Ismail <mustafa.ismail@intel.com>
+
+commit 1c9043ae0667a43bd87beeebbdd4bed674713629 upstream.
+
+For some net events in irdma_net_event notifier, the netdev can be NULL
+which will cause a crash in rdma_vlan_dev_real_dev. Fix this by moving
+all processing to the NETEVENT_NEIGH_UPDATE case where the netdev is
+guaranteed to not be NULL.
+
+Fixes: 6702bc147448 ("RDMA/irdma: Fix netdev notifications for vlan's")
+Link: https://lore.kernel.org/r/20220425181703.1634-4-shiraz.saleem@intel.com
+Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com>
+Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/hw/irdma/utils.c | 21 +++++++++------------
+ 1 file changed, 9 insertions(+), 12 deletions(-)
+
+--- a/drivers/infiniband/hw/irdma/utils.c
++++ b/drivers/infiniband/hw/irdma/utils.c
+@@ -258,18 +258,16 @@ int irdma_net_event(struct notifier_bloc
+ u32 local_ipaddr[4] = {};
+ bool ipv4 = true;
+
+- real_dev = rdma_vlan_dev_real_dev(netdev);
+- if (!real_dev)
+- real_dev = netdev;
+-
+- ibdev = ib_device_get_by_netdev(real_dev, RDMA_DRIVER_IRDMA);
+- if (!ibdev)
+- return NOTIFY_DONE;
+-
+- iwdev = to_iwdev(ibdev);
+-
+ switch (event) {
+ case NETEVENT_NEIGH_UPDATE:
++ real_dev = rdma_vlan_dev_real_dev(netdev);
++ if (!real_dev)
++ real_dev = netdev;
++ ibdev = ib_device_get_by_netdev(real_dev, RDMA_DRIVER_IRDMA);
++ if (!ibdev)
++ return NOTIFY_DONE;
++
++ iwdev = to_iwdev(ibdev);
+ p = (__be32 *)neigh->primary_key;
+ if (neigh->tbl->family == AF_INET6) {
+ ipv4 = false;
+@@ -290,13 +288,12 @@ int irdma_net_event(struct notifier_bloc
+ irdma_manage_arp_cache(iwdev->rf, neigh->ha,
+ local_ipaddr, ipv4,
+ IRDMA_ARP_DELETE);
++ ib_device_put(ibdev);
+ break;
+ default:
+ break;
+ }
+
+- ib_device_put(ibdev);
+-
+ return NOTIFY_DONE;
+ }
+
--- /dev/null
+From 7b8943b821bafab492f43aafbd006b57c6b65845 Mon Sep 17 00:00:00 2001
+From: Tatyana Nikolova <tatyana.e.nikolova@intel.com>
+Date: Mon, 25 Apr 2022 13:17:01 -0500
+Subject: RDMA/irdma: Flush iWARP QP if modified to ERR from RTR state
+
+From: Tatyana Nikolova <tatyana.e.nikolova@intel.com>
+
+commit 7b8943b821bafab492f43aafbd006b57c6b65845 upstream.
+
+When connection establishment fails in iWARP mode, an app can drain the
+QPs and hang because flush isn't issued when the QP is modified from RTR
+state to error. Issue a flush in this case using function
+irdma_cm_disconn().
+
+Update irdma_cm_disconn() to do flush when cm_id is NULL, which is the
+case when the QP is in RTR state and there is an error in the connection
+establishment.
+
+Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs")
+Link: https://lore.kernel.org/r/20220425181703.1634-2-shiraz.saleem@intel.com
+Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com>
+Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/hw/irdma/cm.c | 16 +++++-----------
+ drivers/infiniband/hw/irdma/verbs.c | 4 ++--
+ 2 files changed, 7 insertions(+), 13 deletions(-)
+
+--- a/drivers/infiniband/hw/irdma/cm.c
++++ b/drivers/infiniband/hw/irdma/cm.c
+@@ -3465,12 +3465,6 @@ static void irdma_cm_disconn_true(struct
+ }
+
+ cm_id = iwqp->cm_id;
+- /* make sure we havent already closed this connection */
+- if (!cm_id) {
+- spin_unlock_irqrestore(&iwqp->lock, flags);
+- return;
+- }
+-
+ original_hw_tcp_state = iwqp->hw_tcp_state;
+ original_ibqp_state = iwqp->ibqp_state;
+ last_ae = iwqp->last_aeq;
+@@ -3492,11 +3486,11 @@ static void irdma_cm_disconn_true(struct
+ disconn_status = -ECONNRESET;
+ }
+
+- if ((original_hw_tcp_state == IRDMA_TCP_STATE_CLOSED ||
+- original_hw_tcp_state == IRDMA_TCP_STATE_TIME_WAIT ||
+- last_ae == IRDMA_AE_RDMAP_ROE_BAD_LLP_CLOSE ||
+- last_ae == IRDMA_AE_BAD_CLOSE ||
+- last_ae == IRDMA_AE_LLP_CONNECTION_RESET || iwdev->rf->reset)) {
++ if (original_hw_tcp_state == IRDMA_TCP_STATE_CLOSED ||
++ original_hw_tcp_state == IRDMA_TCP_STATE_TIME_WAIT ||
++ last_ae == IRDMA_AE_RDMAP_ROE_BAD_LLP_CLOSE ||
++ last_ae == IRDMA_AE_BAD_CLOSE ||
++ last_ae == IRDMA_AE_LLP_CONNECTION_RESET || iwdev->rf->reset || !cm_id) {
+ issue_close = 1;
+ iwqp->cm_id = NULL;
+ qp->term_flags = 0;
+--- a/drivers/infiniband/hw/irdma/verbs.c
++++ b/drivers/infiniband/hw/irdma/verbs.c
+@@ -1617,13 +1617,13 @@ int irdma_modify_qp(struct ib_qp *ibqp,
+
+ if (issue_modify_qp && iwqp->ibqp_state > IB_QPS_RTS) {
+ if (dont_wait) {
+- if (iwqp->cm_id && iwqp->hw_tcp_state) {
++ if (iwqp->hw_tcp_state) {
+ spin_lock_irqsave(&iwqp->lock, flags);
+ iwqp->hw_tcp_state = IRDMA_TCP_STATE_CLOSED;
+ iwqp->last_aeq = IRDMA_AE_RESET_SENT;
+ spin_unlock_irqrestore(&iwqp->lock, flags);
+- irdma_cm_disconn(iwqp);
+ }
++ irdma_cm_disconn(iwqp);
+ } else {
+ int close_timer_started;
+
--- /dev/null
+From 2df6d895907b2f5dfbc558cbff7801bba82cb3cc Mon Sep 17 00:00:00 2001
+From: Shiraz Saleem <shiraz.saleem@intel.com>
+Date: Mon, 25 Apr 2022 13:17:02 -0500
+Subject: RDMA/irdma: Reduce iWARP QP destroy time
+
+From: Shiraz Saleem <shiraz.saleem@intel.com>
+
+commit 2df6d895907b2f5dfbc558cbff7801bba82cb3cc upstream.
+
+QP destroy is synchronous and waits for its refcnt to be decremented in
+irdma_cm_node_free_cb (for iWARP) which fires after the RCU grace period
+elapses.
+
+Applications running a large number of connections are exposed to high
+wait times on destroy QP for events like SIGABORT.
+
+The long pole for this wait time is the firing of the call_rcu callback
+during a CM node destroy which can be slow. It holds the QP reference
+count and blocks the destroy QP from completing.
+
+call_rcu only needs to make sure that list walkers have a reference to the
+cm_node object before freeing it and thus need to wait for grace period
+elapse. The rest of the connection teardown in irdma_cm_node_free_cb is
+moved out of the grace period wait in irdma_destroy_connection. Also,
+replace call_rcu with a simple kfree_rcu as it just needs to do a kfree on
+the cm_node
+
+Fixes: 146b9756f14c ("RDMA/irdma: Add connection manager")
+Link: https://lore.kernel.org/r/20220425181703.1634-3-shiraz.saleem@intel.com
+Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/hw/irdma/cm.c | 10 ++++------
+ 1 file changed, 4 insertions(+), 6 deletions(-)
+
+--- a/drivers/infiniband/hw/irdma/cm.c
++++ b/drivers/infiniband/hw/irdma/cm.c
+@@ -2305,10 +2305,8 @@ err:
+ return NULL;
+ }
+
+-static void irdma_cm_node_free_cb(struct rcu_head *rcu_head)
++static void irdma_destroy_connection(struct irdma_cm_node *cm_node)
+ {
+- struct irdma_cm_node *cm_node =
+- container_of(rcu_head, struct irdma_cm_node, rcu_head);
+ struct irdma_cm_core *cm_core = cm_node->cm_core;
+ struct irdma_qp *iwqp;
+ struct irdma_cm_info nfo;
+@@ -2356,7 +2354,6 @@ static void irdma_cm_node_free_cb(struct
+ }
+
+ cm_core->cm_free_ah(cm_node);
+- kfree(cm_node);
+ }
+
+ /**
+@@ -2384,8 +2381,9 @@ void irdma_rem_ref_cm_node(struct irdma_
+
+ spin_unlock_irqrestore(&cm_core->ht_lock, flags);
+
+- /* wait for all list walkers to exit their grace period */
+- call_rcu(&cm_node->rcu_head, irdma_cm_node_free_cb);
++ irdma_destroy_connection(cm_node);
++
++ kfree_rcu(cm_node, rcu_head);
+ }
+
+ /**
--- /dev/null
+From ef91271c65c12d36e4c2b61c61d4849fb6d11aa0 Mon Sep 17 00:00:00 2001
+From: Cheng Xu <chengyou@linux.alibaba.com>
+Date: Sun, 24 Apr 2022 16:01:03 +0800
+Subject: RDMA/siw: Fix a condition race issue in MPA request processing
+
+From: Cheng Xu <chengyou@linux.alibaba.com>
+
+commit ef91271c65c12d36e4c2b61c61d4849fb6d11aa0 upstream.
+
+The calling of siw_cm_upcall and detaching new_cep with its listen_cep
+should be atomistic semantics. Otherwise siw_reject may be called in a
+temporary state, e,g, siw_cm_upcall is called but the new_cep->listen_cep
+has not being cleared.
+
+This fixes a WARN:
+
+ WARNING: CPU: 7 PID: 201 at drivers/infiniband/sw/siw/siw_cm.c:255 siw_cep_put+0x125/0x130 [siw]
+ CPU: 2 PID: 201 Comm: kworker/u16:22 Kdump: loaded Tainted: G E 5.17.0-rc7 #1
+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
+ Workqueue: iw_cm_wq cm_work_handler [iw_cm]
+ RIP: 0010:siw_cep_put+0x125/0x130 [siw]
+ Call Trace:
+ <TASK>
+ siw_reject+0xac/0x180 [siw]
+ iw_cm_reject+0x68/0xc0 [iw_cm]
+ cm_work_handler+0x59d/0xe20 [iw_cm]
+ process_one_work+0x1e2/0x3b0
+ worker_thread+0x50/0x3a0
+ ? rescuer_thread+0x390/0x390
+ kthread+0xe5/0x110
+ ? kthread_complete_and_exit+0x20/0x20
+ ret_from_fork+0x1f/0x30
+ </TASK>
+
+Fixes: 6c52fdc244b5 ("rdma/siw: connection management")
+Link: https://lore.kernel.org/r/d528d83466c44687f3872eadcb8c184528b2e2d4.1650526554.git.chengyou@linux.alibaba.com
+Reported-by: Luis Chamberlain <mcgrof@kernel.org>
+Reviewed-by: Bernard Metzler <bmt@zurich.ibm.com>
+Signed-off-by: Cheng Xu <chengyou@linux.alibaba.com>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/sw/siw/siw_cm.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/drivers/infiniband/sw/siw/siw_cm.c
++++ b/drivers/infiniband/sw/siw/siw_cm.c
+@@ -968,14 +968,15 @@ static void siw_accept_newconn(struct si
+
+ siw_cep_set_inuse(new_cep);
+ rv = siw_proc_mpareq(new_cep);
+- siw_cep_set_free(new_cep);
+-
+ if (rv != -EAGAIN) {
+ siw_cep_put(cep);
+ new_cep->listen_cep = NULL;
+- if (rv)
++ if (rv) {
++ siw_cep_set_free(new_cep);
+ goto error;
++ }
+ }
++ siw_cep_set_free(new_cep);
+ }
+ return;
+
--- /dev/null
+From 2bfed7d2ffa5d86c462d3e2067f2832eaf8c04c7 Mon Sep 17 00:00:00 2001
+From: Jann Horn <jannh@google.com>
+Date: Sat, 19 Mar 2022 02:00:11 +0100
+Subject: selftests/seccomp: Don't call read() on TTY from background pgrp
+
+From: Jann Horn <jannh@google.com>
+
+commit 2bfed7d2ffa5d86c462d3e2067f2832eaf8c04c7 upstream.
+
+Since commit 92d25637a3a4 ("kselftest: signal all child processes"), tests
+are executed in background process groups. This means that trying to read
+from stdin now throws SIGTTIN when stdin is a TTY, which breaks some
+seccomp selftests that try to use read(0, NULL, 0) as a dummy syscall.
+
+The simplest way to fix that is probably to just use -1 instead of 0 as
+the dummy read()'s FD.
+
+Fixes: 92d25637a3a4 ("kselftest: signal all child processes")
+Signed-off-by: Jann Horn <jannh@google.com>
+Signed-off-by: Kees Cook <keescook@chromium.org>
+Link: https://lore.kernel.org/r/20220319010011.1374622-1-jannh@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/testing/selftests/seccomp/seccomp_bpf.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/tools/testing/selftests/seccomp/seccomp_bpf.c
++++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
+@@ -955,7 +955,7 @@ TEST(ERRNO_valid)
+ ASSERT_EQ(0, ret);
+
+ EXPECT_EQ(parent, syscall(__NR_getppid));
+- EXPECT_EQ(-1, read(0, NULL, 0));
++ EXPECT_EQ(-1, read(-1, NULL, 0));
+ EXPECT_EQ(E2BIG, errno);
+ }
+
+@@ -974,7 +974,7 @@ TEST(ERRNO_zero)
+
+ EXPECT_EQ(parent, syscall(__NR_getppid));
+ /* "errno" of 0 is ok. */
+- EXPECT_EQ(0, read(0, NULL, 0));
++ EXPECT_EQ(0, read(-1, NULL, 0));
+ }
+
+ /*
+@@ -995,7 +995,7 @@ TEST(ERRNO_capped)
+ ASSERT_EQ(0, ret);
+
+ EXPECT_EQ(parent, syscall(__NR_getppid));
+- EXPECT_EQ(-1, read(0, NULL, 0));
++ EXPECT_EQ(-1, read(-1, NULL, 0));
+ EXPECT_EQ(4095, errno);
+ }
+
+@@ -1026,7 +1026,7 @@ TEST(ERRNO_order)
+ ASSERT_EQ(0, ret);
+
+ EXPECT_EQ(parent, syscall(__NR_getppid));
+- EXPECT_EQ(-1, read(0, NULL, 0));
++ EXPECT_EQ(-1, read(-1, NULL, 0));
+ EXPECT_EQ(12, errno);
+ }
+
+@@ -2579,7 +2579,7 @@ void *tsync_sibling(void *data)
+ ret = prctl(PR_GET_NO_NEW_PRIVS, 0, 0, 0, 0);
+ if (!ret)
+ return (void *)SIBLING_EXIT_NEWPRIVS;
+- read(0, NULL, 0);
++ read(-1, NULL, 0);
+ return (void *)SIBLING_EXIT_UNKILLED;
+ }
+
can-grcan-use-ofdev-dev-when-allocating-dma-memory.patch
can-grcan-grcan_probe-fix-broken-system-id-check-for-errata-workaround-needs.patch
can-grcan-only-use-the-napi-poll-budget-for-rx.patch
+nfc-replace-improper-check-device_is_registered-in-netlink-related-functions.patch
+nfc-nfcmrvl-main-reorder-destructive-operations-in-nfcmrvl_nci_unregister_dev-to-avoid-bugs.patch
+nfc-netlink-fix-sleep-in-atomic-bug-when-firmware-download-timeout.patch
+gpio-mvebu-drop-pwm-base-assignment.patch
+gpio-visconti-fix-fwnode-of-gpio-irq.patch
+gpio-pca953x-fix-irq_stat-not-updated-when-irq-is-disabled-irq_mask-not-set.patch
+hwmon-adt7470-fix-warning-on-module-removal.patch
+hwmon-pmbus-disable-pec-if-not-enabled.patch
+asoc-dmaengine-restore-null-prepare_slave_config-callback.patch
+asoc-soc-ops-fix-error-handling.patch
+iommu-vt-d-drop-stop-marker-messages.patch
+iommu-dart-check-return-value-after-calling-platform_get_resource.patch
+fbdev-make-fb_release-return-enodev-if-fbdev-was-unregistered.patch
+net-mlx5e-fix-trust-state-reset-in-reload.patch
+net-mlx5e-don-t-match-double-vlan-packets-if-cvlan-is-not-set.patch
+net-mlx5e-ct-fix-queued-up-restore-put-executing-after-relevant-ft-release.patch
+net-mlx5e-fix-the-calling-of-update_buffer_lossy-api.patch
+net-mlx5-avoid-double-clear-or-set-of-sync-reset-requested.patch
+net-mlx5-fix-deadlock-in-sync-reset-flow.patch
+selftests-seccomp-don-t-call-read-on-tty-from-background-pgrp.patch
+sunrpc-release-the-transport-of-a-relocated-task-with-an-assigned-transport.patch
+rdma-siw-fix-a-condition-race-issue-in-mpa-request-processing.patch
+rdma-irdma-flush-iwarp-qp-if-modified-to-err-from-rtr-state.patch
+rdma-irdma-reduce-iwarp-qp-destroy-time.patch
+rdma-irdma-fix-possible-crash-due-to-null-netdev-in-notifier.patch
+nfsv4-don-t-invalidate-inode-attributes-on-delegation-return.patch
btrfs-do-not-bug_on-on-failure-to-update-inode-when-setting-xattr.patch
--- /dev/null
+From e13433b4416fa31a24e621cbbbb39227a3d651dd Mon Sep 17 00:00:00 2001
+From: Olga Kornievskaia <kolga@netapp.com>
+Date: Thu, 21 Apr 2022 10:32:34 -0400
+Subject: SUNRPC release the transport of a relocated task with an assigned transport
+
+From: Olga Kornievskaia <kolga@netapp.com>
+
+commit e13433b4416fa31a24e621cbbbb39227a3d651dd upstream.
+
+A relocated task must release its previous transport.
+
+Fixes: 82ee41b85cef1 ("SUNRPC don't resend a task on an offlined transport")
+Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
+Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/sunrpc/clnt.c | 11 +++++++----
+ 1 file changed, 7 insertions(+), 4 deletions(-)
+
+--- a/net/sunrpc/clnt.c
++++ b/net/sunrpc/clnt.c
+@@ -1065,10 +1065,13 @@ rpc_task_get_next_xprt(struct rpc_clnt *
+ static
+ void rpc_task_set_transport(struct rpc_task *task, struct rpc_clnt *clnt)
+ {
+- if (task->tk_xprt &&
+- !(test_bit(XPRT_OFFLINE, &task->tk_xprt->state) &&
+- (task->tk_flags & RPC_TASK_MOVEABLE)))
+- return;
++ if (task->tk_xprt) {
++ if (!(test_bit(XPRT_OFFLINE, &task->tk_xprt->state) &&
++ (task->tk_flags & RPC_TASK_MOVEABLE)))
++ return;
++ xprt_release(task);
++ xprt_put(task->tk_xprt);
++ }
+ if (task->tk_flags & RPC_TASK_NO_ROUND_ROBIN)
+ task->tk_xprt = rpc_task_get_first_xprt(clnt);
+ else
projects / thirdparty / kernel / stable-queue.git / commitdiff
