This is a note to let you know that I've just added the patch titled
drm/ttm: check the return value of kzalloc
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-ttm-check-the-return-value-of-kzalloc.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Feb 28 16:19:30 CET 2018
From: Xiongwei Song <sxwjean(a)gmail.com>
Date: Tue, 2 Jan 2018 21:24:55 +0800
Subject: drm/ttm: check the return value of kzalloc
From: Xiongwei Song <sxwjean(a)gmail.com>
[ Upstream commit 19d859a7205bc59ffc38303eb25ae394f61d21dc ]
In the function ttm_page_alloc_init, kzalloc call is made for variable
_manager, we need to check its return value, it may return NULL.
Signed-off-by: Xiongwei Song <sxwjean(a)gmail.com>
Reviewed-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -818,6 +818,8 @@ int ttm_page_alloc_init(struct ttm_mem_g
pr_info("Initializing pool allocator\n");
_manager = kzalloc(sizeof(*_manager), GFP_KERNEL);
+ if (!_manager)
+ return -ENOMEM;
ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc");
Patches currently in stable-queue which might be from sxwjean(a)gmail.com are
queue-4.4/drm-ttm-check-the-return-value-of-kzalloc.patch
This is a note to let you know that I've just added the patch titled
drm/nouveau/pci: do a msi rearm on init
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-nouveau-pci-do-a-msi-rearm-on-init.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Feb 28 16:19:30 CET 2018
From: Karol Herbst <kherbst(a)redhat.com>
Date: Fri, 24 Nov 2017 03:56:26 +0100
Subject: drm/nouveau/pci: do a msi rearm on init
From: Karol Herbst <kherbst(a)redhat.com>
[ Upstream commit a121027d2747168df0aac0c3da35509eea39f61c ]
On my GP107 when I load nouveau after unloading it, for some reason the
GPU stopped sending or the CPU stopped receiving interrupts if MSI was
enabled.
Doing a rearm once before getting any interrupts fixes this.
Signed-off-by: Karol Herbst <kherbst(a)redhat.com>
Reviewed-by: Thierry Reding <treding(a)nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c
@@ -127,6 +127,13 @@ nvkm_pci_init(struct nvkm_subdev *subdev
return ret;
pci->irq = pdev->irq;
+
+ /* Ensure MSI interrupts are armed, for the case where there are
+ * already interrupts pending (for whatever reason) at load time.
+ */
+ if (pci->msi)
+ pci->func->msi_rearm(pci);
+
return ret;
}
Patches currently in stable-queue which might be from kherbst(a)redhat.com are
queue-4.4/drm-nouveau-pci-do-a-msi-rearm-on-init.patch
This is a note to let you know that I've just added the patch titled
can: flex_can: Correct the checking for frame length in flexcan_start_xmit()
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
can-flex_can-correct-the-checking-for-frame-length-in-flexcan_start_xmit.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Feb 28 16:19:30 CET 2018
From: Luu An Phu <phu.luuan(a)nxp.com>
Date: Tue, 2 Jan 2018 10:44:18 +0700
Subject: can: flex_can: Correct the checking for frame length in flexcan_start_xmit()
From: Luu An Phu <phu.luuan(a)nxp.com>
[ Upstream commit 13454c14550065fcc1705d6bd4ee6d40e057099f ]
The flexcan_start_xmit() function compares the frame length with data
register length to write frame content into data[0] and data[1]
register. Data register length is 4 bytes and frame maximum length is 8
bytes.
Fix the check that compares frame length with 3. Because the register
length is 4.
Signed-off-by: Luu An Phu <phu.luuan(a)nxp.com>
Reviewed-by: Oliver Hartkopp <socketcan(a)hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/flexcan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -493,7 +493,7 @@ static int flexcan_start_xmit(struct sk_
data = be32_to_cpup((__be32 *)&cf->data[0]);
flexcan_write(data, ®s->mb[FLEXCAN_TX_BUF_ID].data[0]);
}
- if (cf->can_dlc > 3) {
+ if (cf->can_dlc > 4) {
data = be32_to_cpup((__be32 *)&cf->data[4]);
flexcan_write(data, ®s->mb[FLEXCAN_TX_BUF_ID].data[1]);
}
Patches currently in stable-queue which might be from phu.luuan(a)nxp.com are
queue-4.4/can-flex_can-correct-the-checking-for-frame-length-in-flexcan_start_xmit.patch
This is a note to let you know that I've just added the patch titled
bnxt_en: Fix the 'Invalid VF' id check in bnxt_vf_ndo_prep routine.
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bnxt_en-fix-the-invalid-vf-id-check-in-bnxt_vf_ndo_prep-routine.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Feb 28 16:19:30 CET 2018
From: Venkat Duvvuru <venkatkumar.duvvuru(a)broadcom.com>
Date: Thu, 4 Jan 2018 18:46:55 -0500
Subject: bnxt_en: Fix the 'Invalid VF' id check in bnxt_vf_ndo_prep routine.
From: Venkat Duvvuru <venkatkumar.duvvuru(a)broadcom.com>
[ Upstream commit 78f300049335ae81a5cc6b4b232481dc5e1f9d41 ]
In bnxt_vf_ndo_prep (which is called by bnxt_get_vf_config ndo), there is a
check for "Invalid VF id". Currently, the check is done against max_vfs.
However, the user doesn't always create max_vfs. So, the check should be
against the created number of VFs. The number of bnxt_vf_info structures
that are allocated in bnxt_alloc_vf_resources routine is the "number of
requested VFs". So, if an "invalid VF id" falls between the requested
number of VFs and the max_vfs, the driver will be dereferencing an invalid
pointer.
Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
Signed-off-by: Venkat Devvuru <venkatkumar.duvvuru(a)broadcom.com>
Signed-off-by: Michael Chan <michael.chan(a)broadcom.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
@@ -29,7 +29,7 @@ static int bnxt_vf_ndo_prep(struct bnxt
netdev_err(bp->dev, "vf ndo called though sriov is disabled\n");
return -EINVAL;
}
- if (vf_id >= bp->pf.max_vfs) {
+ if (vf_id >= bp->pf.active_vfs) {
netdev_err(bp->dev, "Invalid VF id %d\n", vf_id);
return -EINVAL;
}
Patches currently in stable-queue which might be from venkatkumar.duvvuru(a)broadcom.com are
queue-4.4/bnxt_en-fix-the-invalid-vf-id-check-in-bnxt_vf_ndo_prep-routine.patch
This is a note to let you know that I've just added the patch titled
bnx2x: Improve reliability in case of nested PCI errors
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bnx2x-improve-reliability-in-case-of-nested-pci-errors.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Feb 28 16:19:30 CET 2018
From: "Guilherme G. Piccoli" <gpiccoli(a)linux.vnet.ibm.com>
Date: Fri, 22 Dec 2017 13:01:39 -0200
Subject: bnx2x: Improve reliability in case of nested PCI errors
From: "Guilherme G. Piccoli" <gpiccoli(a)linux.vnet.ibm.com>
[ Upstream commit f7084059a9cb9e56a186e1677b1dcffd76c2cd24 ]
While in recovery process of PCI error (called EEH on PowerPC arch),
another PCI transaction could be corrupted causing a situation of
nested PCI errors. Also, this scenario could be reproduced with
error injection mechanisms (for debug purposes).
We observe that in case of nested PCI errors, bnx2x might attempt to
initialize its shmem and cause a kernel crash due to bad addresses
read from MCP. Multiple different stack traces were observed depending
on the point the second PCI error happens.
This patch avoids the crashes by:
* failing PCI recovery in case of nested errors (since multiple
PCI errors in a row are not expected to lead to a functional
adapter anyway), and by,
* preventing access to adapter FW when MCP is failed (we mark it as
failed when shmem cannot get initialized properly).
Reported-by: Abdul Haleem <abdhalee(a)linux.vnet.ibm.com>
Signed-off-by: Guilherme G. Piccoli <gpiccoli(a)linux.vnet.ibm.com>
Acked-by: Shahed Shaikh <Shahed.Shaikh(a)cavium.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 4 ++--
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 14 +++++++++++++-
2 files changed, 15 insertions(+), 3 deletions(-)
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -3052,7 +3052,7 @@ int bnx2x_nic_unload(struct bnx2x *bp, i
del_timer_sync(&bp->timer);
- if (IS_PF(bp)) {
+ if (IS_PF(bp) && !BP_NOMCP(bp)) {
/* Set ALWAYS_ALIVE bit in shmem */
bp->fw_drv_pulse_wr_seq |= DRV_PULSE_ALWAYS_ALIVE;
bnx2x_drv_pulse(bp);
@@ -3134,7 +3134,7 @@ int bnx2x_nic_unload(struct bnx2x *bp, i
bp->cnic_loaded = false;
/* Clear driver version indication in shmem */
- if (IS_PF(bp))
+ if (IS_PF(bp) && !BP_NOMCP(bp))
bnx2x_update_mng_version(bp);
/* Check if there are pending parity attentions. If there are - set
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -9570,6 +9570,15 @@ static int bnx2x_init_shmem(struct bnx2x
do {
bp->common.shmem_base = REG_RD(bp, MISC_REG_SHARED_MEM_ADDR);
+
+ /* If we read all 0xFFs, means we are in PCI error state and
+ * should bail out to avoid crashes on adapter's FW reads.
+ */
+ if (bp->common.shmem_base == 0xFFFFFFFF) {
+ bp->flags |= NO_MCP_FLAG;
+ return -ENODEV;
+ }
+
if (bp->common.shmem_base) {
val = SHMEM_RD(bp, validity_map[BP_PORT(bp)]);
if (val & SHR_MEM_VALIDITY_MB)
@@ -14214,7 +14223,10 @@ static pci_ers_result_t bnx2x_io_slot_re
BNX2X_ERR("IO slot reset --> driver unload\n");
/* MCP should have been reset; Need to wait for validity */
- bnx2x_init_shmem(bp);
+ if (bnx2x_init_shmem(bp)) {
+ rtnl_unlock();
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
if (IS_PF(bp) && SHMEM2_HAS(bp, drv_capabilities_flag)) {
u32 v;
Patches currently in stable-queue which might be from gpiccoli(a)linux.vnet.ibm.com are
queue-4.4/bnx2x-improve-reliability-in-case-of-nested-pci-errors.patch
This is a note to let you know that I've just added the patch titled
ARM: dts: ls1021a: fix incorrect clock references
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-dts-ls1021a-fix-incorrect-clock-references.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Feb 28 16:19:30 CET 2018
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Thu, 21 Dec 2017 22:35:19 +0100
Subject: ARM: dts: ls1021a: fix incorrect clock references
From: Arnd Bergmann <arnd(a)arndb.de>
[ Upstream commit 506e8a912661c97b41adc8a286b875d01323ec45 ]
dtc warns about two 'clocks' properties that have an extraneous '1'
at the end:
arch/arm/boot/dts/ls1021a-qds.dtb: Warning (clocks_property): arch/arm/boot/dts/ls1021a-twr.dtb: Warning (clocks_property): Property 'clocks', cell 1 is not a phandle reference in /soc/i2c@2180000/mux@77/i2c@4/sgtl5000@2a
arch/arm/boot/dts/ls1021a-qds.dtb: Warning (clocks_property): Missing property '#clock-cells' in node /soc/interrupt-controller@1400000 or bad phandle (referred from /soc/i2c@2180000/mux@77/i2c@4/sgtl5000@2a:clocks[1])
Property 'clocks', cell 1 is not a phandle reference in /soc/i2c@2190000/sgtl5000@a
arch/arm/boot/dts/ls1021a-twr.dtb: Warning (clocks_property): Missing property '#clock-cells' in node /soc/interrupt-controller@1400000 or bad phandle (referred from /soc/i2c@2190000/sgtl5000@a:clocks[1])
The clocks that get referenced here are fixed-rate, so they do not
take any argument, and dtc interprets the next cell as a phandle, which
is invalid.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/boot/dts/ls1021a-qds.dts | 2 +-
arch/arm/boot/dts/ls1021a-twr.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm/boot/dts/ls1021a-qds.dts
+++ b/arch/arm/boot/dts/ls1021a-qds.dts
@@ -215,7 +215,7 @@
reg = <0x2a>;
VDDA-supply = <®_3p3v>;
VDDIO-supply = <®_3p3v>;
- clocks = <&sys_mclk 1>;
+ clocks = <&sys_mclk>;
};
};
};
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -167,7 +167,7 @@
reg = <0x0a>;
VDDA-supply = <®_3p3v>;
VDDIO-supply = <®_3p3v>;
- clocks = <&sys_mclk 1>;
+ clocks = <&sys_mclk>;
};
};
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.4/arm-dts-ls1021a-fix-incorrect-clock-references.patch
This is a note to let you know that I've just added the patch titled
ARM: 8731/1: Fix csum_partial_copy_from_user() stack mismatch
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-8731-1-fix-csum_partial_copy_from_user-stack-mismatch.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Feb 28 16:19:30 CET 2018
From: Chunyan Zhang <zhang.lyra(a)gmail.com>
Date: Fri, 1 Dec 2017 03:51:04 +0100
Subject: ARM: 8731/1: Fix csum_partial_copy_from_user() stack mismatch
From: Chunyan Zhang <zhang.lyra(a)gmail.com>
[ Upstream commit 36b0cb84ee858f02c256d26f0cb4229c78e3399e ]
An additional 'ip' will be pushed to the stack, for restoring the
DACR later, if CONFIG_CPU_SW_DOMAIN_PAN defined.
However, the fixup still get the err_ptr by add #8*4 to sp, which
results in the fact that the code area pointed by the LR will be
overwritten, or the kernel will crash if CONFIG_DEBUG_RODATA is enabled.
This patch fixes the stack mismatch.
Fixes: a5e090acbf54 ("ARM: software-based priviledged-no-access support")
Signed-off-by: Lvqiang Huang <Lvqiang.Huang(a)spreadtrum.com>
Signed-off-by: Chunyan Zhang <zhang.lyra(a)gmail.com>
Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/lib/csumpartialcopyuser.S | 4 ++++
1 file changed, 4 insertions(+)
--- a/arch/arm/lib/csumpartialcopyuser.S
+++ b/arch/arm/lib/csumpartialcopyuser.S
@@ -85,7 +85,11 @@
.pushsection .text.fixup,"ax"
.align 4
9001: mov r4, #-EFAULT
+#ifdef CONFIG_CPU_SW_DOMAIN_PAN
+ ldr r5, [sp, #9*4] @ *err_ptr
+#else
ldr r5, [sp, #8*4] @ *err_ptr
+#endif
str r4, [r5]
ldmia sp, {r1, r2} @ retrieve dst, len
add r2, r2, r1
Patches currently in stable-queue which might be from zhang.lyra(a)gmail.com are
queue-4.4/arm-8731-1-fix-csum_partial_copy_from_user-stack-mismatch.patch
This is a note to let you know that I've just added the patch titled
xfs: quota: check result of register_shrinker()
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xfs-quota-check-result-of-register_shrinker.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Feb 28 16:16:23 CET 2018
From: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
Date: Thu, 21 Dec 2017 13:18:26 -0800
Subject: xfs: quota: check result of register_shrinker()
From: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
[ Upstream commit 3a3882ff26fbdbaf5f7e13f6a0bccfbf7121041d ]
xfs_qm_init_quotainfo() does not check result of register_shrinker()
which was tagged as __must_check recently, reported by sparse.
Signed-off-by: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
[darrick: move xfs_qm_destroy_quotainos nearer xfs_qm_init_quotainos]
Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/xfs/xfs_qm.c | 45 +++++++++++++++++++++++++++++----------------
1 file changed, 29 insertions(+), 16 deletions(-)
--- a/fs/xfs/xfs_qm.c
+++ b/fs/xfs/xfs_qm.c
@@ -49,7 +49,7 @@
STATIC int xfs_qm_init_quotainos(xfs_mount_t *);
STATIC int xfs_qm_init_quotainfo(xfs_mount_t *);
-
+STATIC void xfs_qm_destroy_quotainos(xfs_quotainfo_t *qi);
STATIC void xfs_qm_dqfree_one(struct xfs_dquot *dqp);
/*
* We use the batch lookup interface to iterate over the dquots as it
@@ -662,9 +662,17 @@ xfs_qm_init_quotainfo(
qinf->qi_shrinker.scan_objects = xfs_qm_shrink_scan;
qinf->qi_shrinker.seeks = DEFAULT_SEEKS;
qinf->qi_shrinker.flags = SHRINKER_NUMA_AWARE;
- register_shrinker(&qinf->qi_shrinker);
+
+ error = register_shrinker(&qinf->qi_shrinker);
+ if (error)
+ goto out_free_inos;
+
return 0;
+out_free_inos:
+ mutex_destroy(&qinf->qi_quotaofflock);
+ mutex_destroy(&qinf->qi_tree_lock);
+ xfs_qm_destroy_quotainos(qinf);
out_free_lru:
list_lru_destroy(&qinf->qi_lru);
out_free_qinf:
@@ -673,7 +681,6 @@ out_free_qinf:
return error;
}
-
/*
* Gets called when unmounting a filesystem or when all quotas get
* turned off.
@@ -690,19 +697,7 @@ xfs_qm_destroy_quotainfo(
unregister_shrinker(&qi->qi_shrinker);
list_lru_destroy(&qi->qi_lru);
-
- if (qi->qi_uquotaip) {
- IRELE(qi->qi_uquotaip);
- qi->qi_uquotaip = NULL; /* paranoia */
- }
- if (qi->qi_gquotaip) {
- IRELE(qi->qi_gquotaip);
- qi->qi_gquotaip = NULL;
- }
- if (qi->qi_pquotaip) {
- IRELE(qi->qi_pquotaip);
- qi->qi_pquotaip = NULL;
- }
+ xfs_qm_destroy_quotainos(qi);
mutex_destroy(&qi->qi_tree_lock);
mutex_destroy(&qi->qi_quotaofflock);
kmem_free(qi);
@@ -1574,6 +1569,24 @@ error_rele:
}
STATIC void
+xfs_qm_destroy_quotainos(
+ xfs_quotainfo_t *qi)
+{
+ if (qi->qi_uquotaip) {
+ IRELE(qi->qi_uquotaip);
+ qi->qi_uquotaip = NULL; /* paranoia */
+ }
+ if (qi->qi_gquotaip) {
+ IRELE(qi->qi_gquotaip);
+ qi->qi_gquotaip = NULL;
+ }
+ if (qi->qi_pquotaip) {
+ IRELE(qi->qi_pquotaip);
+ qi->qi_pquotaip = NULL;
+ }
+}
+
+STATIC void
xfs_qm_dqfree_one(
struct xfs_dquot *dqp)
{
Patches currently in stable-queue which might be from akaraliou.dev(a)gmail.com are
queue-3.18/xfs-quota-fix-missed-destroy-of-qi_tree_lock.patch
queue-3.18/xfs-quota-check-result-of-register_shrinker.patch
This is a note to let you know that I've just added the patch titled
xfs: quota: fix missed destroy of qi_tree_lock
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xfs-quota-fix-missed-destroy-of-qi_tree_lock.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Feb 28 16:16:23 CET 2018
From: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
Date: Thu, 21 Dec 2017 13:18:26 -0800
Subject: xfs: quota: fix missed destroy of qi_tree_lock
From: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
[ Upstream commit 2196881566225f3c3428d1a5f847a992944daa5b ]
xfs_qm_destroy_quotainfo() does not destroy quotainfo->qi_tree_lock
while destroys quotainfo->qi_quotaofflock.
Signed-off-by: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/xfs/xfs_qm.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/xfs/xfs_qm.c
+++ b/fs/xfs/xfs_qm.c
@@ -703,6 +703,7 @@ xfs_qm_destroy_quotainfo(
IRELE(qi->qi_pquotaip);
qi->qi_pquotaip = NULL;
}
+ mutex_destroy(&qi->qi_tree_lock);
mutex_destroy(&qi->qi_quotaofflock);
kmem_free(qi);
mp->m_quotainfo = NULL;
Patches currently in stable-queue which might be from akaraliou.dev(a)gmail.com are
queue-3.18/xfs-quota-fix-missed-destroy-of-qi_tree_lock.patch
queue-3.18/xfs-quota-check-result-of-register_shrinker.patch