From: Chao Yu <chao(a)kernel.org>
commit 96cfeb0389530ae32ade8a48ae3ae1ac3b6c009d upstream.
It should wait all existing dio write IOs before block removal,
otherwise, previous direct write IO may overwrite data in the
block which may be reused by other inode.
Cc: stable(a)vger.kernel.org
Signed-off-by: Chao Yu <chao(a)kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org>
Signed-off-by: Alva Lan <alvalan9(a)foxmail.com>
---
fs/f2fs/file.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 3bab52d33e80..5e2a0cb8d24d 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -1048,6 +1048,13 @@ int f2fs_setattr(struct user_namespace *mnt_userns, struct dentry *dentry,
return err;
}
+ /*
+ * wait for inflight dio, blocks should be removed after
+ * IO completion.
+ */
+ if (attr->ia_size < old_size)
+ inode_dio_wait(inode);
+
f2fs_down_write(&F2FS_I(inode)->i_gc_rwsem[WRITE]);
filemap_invalidate_lock(inode->i_mapping);
@@ -1880,6 +1887,12 @@ static long f2fs_fallocate(struct file *file, int mode,
if (ret)
goto out;
+ /*
+ * wait for inflight dio, blocks should be removed after IO
+ * completion.
+ */
+ inode_dio_wait(inode);
+
if (mode & FALLOC_FL_PUNCH_HOLE) {
if (offset >= inode->i_size)
goto out;
--
2.43.0
After devm_request_irq() fails with error in
pci_endpoint_test_request_irq(), pci_endpoint_test_free_irq_vectors() is
called assuming that all IRQs have been released.
However some requested IRQs remain unreleased, so there are still
/proc/irq/* entries remaining and we encounters WARN() with the following
message:
remove_proc_entry: removing non-empty directory 'irq/30', leaking at
least 'pci-endpoint-test.0'
WARNING: CPU: 0 PID: 202 at fs/proc/generic.c:719 remove_proc_entry
+0x190/0x19c
And show the call trace that led to this issue:
[ 12.050005] Call trace:
[ 12.051226] remove_proc_entry+0x190/0x19c (P)
[ 12.053448] unregister_irq_proc+0xd0/0x104
[ 12.055541] free_desc+0x4c/0xd0
[ 12.057155] irq_free_descs+0x68/0x90
[ 12.058984] irq_domain_free_irqs+0x15c/0x1bc
[ 12.061161] msi_domain_free_locked.part.0+0x184/0x1d4
[ 12.063728] msi_domain_free_irqs_all_locked+0x64/0x8c
[ 12.066296] pci_msi_teardown_msi_irqs+0x48/0x54
[ 12.068604] pci_free_msi_irqs+0x18/0x38
[ 12.070564] pci_free_irq_vectors+0x64/0x8c
[ 12.072654] pci_endpoint_test_ioctl+0x870/0x1068
[ 12.075006] __arm64_sys_ioctl+0xb0/0xe8
[ 12.076967] invoke_syscall+0x48/0x110
[ 12.078841] el0_svc_common.constprop.0+0x40/0xe8
[ 12.081192] do_el0_svc+0x20/0x2c
[ 12.082848] el0_svc+0x30/0xd0
[ 12.084376] el0t_64_sync_handler+0x144/0x168
[ 12.086553] el0t_64_sync+0x198/0x19c
[ 12.088383] ---[ end trace 0000000000000000 ]---
To solve this issue, set the number of remaining IRQs to test->num_irqs
and release IRQs in advance by calling pci_endpoint_test_release_irq().
Cc: stable(a)vger.kernel.org
Fixes: e03327122e2c ("pci_endpoint_test: Add 2 ioctl commands")
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko(a)socionext.com>
---
drivers/misc/pci_endpoint_test.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
index d5ac71a49386..bbcccd425700 100644
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -259,6 +259,9 @@ static int pci_endpoint_test_request_irq(struct pci_endpoint_test *test)
break;
}
+ test->num_irqs = i;
+ pci_endpoint_test_release_irq(test);
+
return ret;
}
--
2.25.1
Add locking to `vf610_gpio_direction_input|output()` functions. Without
this locking, a race condition exists between concurrent calls to these
functions, potentially leading to incorrect GPIO direction settings.
To verify the correctness of this fix, a `trylock` patch was applied,
where after a couple of reboots the race was confirmed. I.e., one user
had to wait before acquiring the lock. With this patch the race has not
been encountered. It's worth mentioning that any type of debugging
(printing, tracing, etc.) would "resolve"/hide the issue.
Fixes: 659d8a62311f ("gpio: vf610: add imx7ulp support")
Signed-off-by: Johan Korsnes <johan.korsnes(a)remarkable.no>
Reviewed-by: Linus Walleij <linus.walleij(a)linaro.org>
Reviewed-by: Haibo Chen <haibo.chen(a)nxp.com>
Cc: Bartosz Golaszewski <brgl(a)bgdev.pl>
Cc: stable(a)vger.kernel.org
---
v3
- Use guards from cleanup.h for spinlock
- Added linux-stable to cc
- Added Fixes: tags
v2
- Added description on correcctness to commit text
- Added Reviewed-by from Walleij and Haibo
---
drivers/gpio/gpio-vf610.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/gpio/gpio-vf610.c b/drivers/gpio/gpio-vf610.c
index c4f34a347cb6..c36a9dbccd4d 100644
--- a/drivers/gpio/gpio-vf610.c
+++ b/drivers/gpio/gpio-vf610.c
@@ -36,6 +36,7 @@ struct vf610_gpio_port {
struct clk *clk_port;
struct clk *clk_gpio;
int irq;
+ spinlock_t lock; /* protect gpio direction registers */
};
#define GPIO_PDOR 0x00
@@ -124,6 +125,7 @@ static int vf610_gpio_direction_input(struct gpio_chip *chip, unsigned int gpio)
u32 val;
if (port->sdata->have_paddr) {
+ guard(spinlock_irqsave)(&port->lock);
val = vf610_gpio_readl(port->gpio_base + GPIO_PDDR);
val &= ~mask;
vf610_gpio_writel(val, port->gpio_base + GPIO_PDDR);
@@ -142,6 +144,7 @@ static int vf610_gpio_direction_output(struct gpio_chip *chip, unsigned int gpio
vf610_gpio_set(chip, gpio, value);
if (port->sdata->have_paddr) {
+ guard(spinlock_irqsave)(&port->lock);
val = vf610_gpio_readl(port->gpio_base + GPIO_PDDR);
val |= mask;
vf610_gpio_writel(val, port->gpio_base + GPIO_PDDR);
@@ -297,6 +300,7 @@ static int vf610_gpio_probe(struct platform_device *pdev)
return -ENOMEM;
port->sdata = device_get_match_data(dev);
+ spin_lock_init(&port->lock);
dual_base = port->sdata->have_dual_base;
--
2.43.0
It is observed that on some systems an initial PPM reset during the boot
phase can trigger a timeout:
[ 6.482546] ucsi_acpi USBC000:00: failed to reset PPM!
[ 6.482551] ucsi_acpi USBC000:00: error -ETIMEDOUT: PPM init failed
Still, increasing the timeout value, albeit being the most straightforward
solution, eliminates the problem: the initial PPM reset may take up to
~8000-10000ms on some Lenovo laptops. When it is reset after the above
period of time (or even if ucsi_reset_ppm() is not called overall), UCSI
works as expected.
Moreover, if the ucsi_acpi module is loaded/unloaded manually after the
system has booted, reading the CCI values and resetting the PPM works
perfectly, without any timeout. Thus it's only a boot-time issue.
The reason for this behavior is not clear but it may be the consequence
of some tricks that the firmware performs or be an actual firmware bug.
As a workaround, increase the timeout to avoid failing the UCSI
initialization prematurely.
Fixes: b1b59e16075f ("usb: typec: ucsi: Increase command completion timeout value")
Cc: stable(a)vger.kernel.org
Signed-off-by: Fedor Pchelkin <boddah8794(a)gmail.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com>
---
Add Heikki's Reviewed-by tag.
drivers/usb/typec/ucsi/ucsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c
index 0fe1476f4c29..7a56d3f840d7 100644
--- a/drivers/usb/typec/ucsi/ucsi.c
+++ b/drivers/usb/typec/ucsi/ucsi.c
@@ -25,7 +25,7 @@
* difficult to estimate the time it takes for the system to process the command
* before it is actually passed to the PPM.
*/
-#define UCSI_TIMEOUT_MS 5000
+#define UCSI_TIMEOUT_MS 10000
/*
* UCSI_SWAP_TIMEOUT_MS - Timeout for role swap requests
--
2.48.1
The infra-iommu node in mt8195.dtsi was triggering a CHECK_DTBS error due
to an excessively long 'interrupts' property. The error message was:
infra-iommu@10315000: interrupts: [[0, 795, 4, 0], [0, 796, 4, 0],
[0, 797, 4, 0], [0, 798, 4, 0], [0, 799, 4, 0]]
is too long
To address this issue, update the compatbile matching rule for
'interrupts' property. This change allows flexibility in the number
of interrupts for new SoCs like MT8195.
The purpose of these 5 interrupts is also added into description.
Fixes: bca28426805d ("dt-bindings: iommu: mediatek: Convert IOMMU to DT schema")
Signed-off-by: Macpaul Lin <macpaul.lin(a)mediatek.com>
Reviewed-by: Rob Herring (Arm) <robh(a)kernel.org>
---
.../bindings/iommu/mediatek,iommu.yaml | 28 ++++++++++++++++++-
1 file changed, 27 insertions(+), 1 deletion(-)
Changes for v2:
- commit message: re-formatting and add a description of adding 5 interrupts.
- add 'description' and 'maxItems: 5' for 'interrupt' property of
'mt8195-iommu-infra'
- others keeps 'maxItems: 1'
Changes for v3:
- Refine the description for 'interrupts' property and fixes the compatible
matching rules.
- Refine commit message.
Changes for v4:
- add missing 'minItems: 5' to 'mediatek,mt8195-iommu-infra'.
Thanks the explanation from Conor and Krzysztof.
Changes for v5:
- Repharse the description for interrupts property of MT8195.
Changes for v6:
- Remove maxItems for mt8195-iommu-infra.
- Add 'Reviewed-by' tag from Rob. Thanks for the review.
diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
index ea6b0f5f24de..eeb39f5acf7e 100644
--- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
+++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
@@ -96,7 +96,16 @@ properties:
maxItems: 1
interrupts:
- maxItems: 1
+ description: |
+ Usually, the IOMMU requires only one interrupt.
+
+ The infra IOMMU in MT8195 has five banks: each features one set
+ of APB registers. One for the normal world (set 0), three for the
+ protected world (sets 1-3), and one for the secure world (set 4).
+ and each set has its own interrupt. Therefore, five interrupts
+ are needed.
+ minItems: 1
+ maxItems: 5
clocks:
items:
@@ -210,6 +219,23 @@ allOf:
required:
- mediatek,larbs
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mediatek,mt8195-iommu-infra
+
+ then:
+ properties:
+ interrupts:
+ minItems: 5
+
+ else:
+ properties:
+ interrupts:
+ maxItems: 1
+
additionalProperties: false
examples:
--
2.45.2